icetray - Fotolia

Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

Construya un proceso de gestión de parches para mantenerse fresco en una crisis de TI

El tiempo es esencial durante una gran crisis de TI, pero apresurarse para solucionar un problema puede hacer más daño que beneficio. Asegure el control de versiones, la documentación y las pruebas para una implementación efectiva de parches.

Algo ha salido mal. Las caras del personal de la mesa de ayuda están inundadas de la luz roja que se refleja desde sus tableros. Los sonidos de los usuarios llorando y rechinando los dientes, ya que no pueden realizar sus trabajos, llenan la oficina.

"Solo arréglenlo", piensan los usuarios. Pero, para los equipos de TI, es más fácil decirlo que hacerlo.

Entonces, ¿dónde debería comenzar el proceso de resolución?

En la búsqueda de una solución rápida, es tentador recurrir a los desarrolladores estrellas de rock y asignarles el problema. A veces, este proceso de administración de parches funciona bien, al menos en la superficie. Los desarrolladores encuentran rápidamente el problema y lo solucionan, y los usuarios pueden continuar con su trabajo.

Sin embargo, este método es defectuoso, ya que carece de un registro de auditoría, no necesariamente llega a la causa raíz del problema y puede dejar a los equipos luchando si surge un problema similar nuevamente.

Comience con lo básico

Para establecer un proceso exitoso de administración de parches, incluso en tiempos de crisis de TI, comience con un análisis adecuado de la causa raíz. Los desarrolladores no deben meterse con las cosas solo porque pueden estar rotas. Use herramientas de diagnóstico para identificar el problema exacto y dónde se encuentra.

Si se trata de un problema de software, use las herramientas de DevOps adecuadas, como CloudBees Jenkins, Atlassian, Chef y Puppet para resolver el problema. Confirme que el control de versión está en su lugar y asegúrese de que todos los desarrolladores documenten lo que hacen y los cambios que hicieron y por qué.

Pruebe, pruebe, pruebe

No empuje la solución de los desarrolladores directamente en el entorno de operaciones. Los desarrolladores deben probar el parche primero, y luego se debe probar nuevamente, como lo haría con cualquier otra pieza de software. Asegúrese de probar contra el entorno de producción más realista posible. Esto es más fácil cuando una organización utiliza máquinas virtuales o contenedores con una plataforma de nube. Los desarrolladores o los equipos de operaciones de TI pueden crear un entorno virtual y probar el parche allí, sin ningún efecto directo sobre el funcionamiento, o, en el caso de una crisis, el entorno de producción que no funciona.

Si algo parece un problema potencial o una vulnerabilidad en la prueba, envíe el código a los desarrolladores junto con el análisis de la prueba. Es mucho mejor iterar un par de veces y hacerlo bien que acelerar el proceso de administración de parches y arriesgarse a más incidentes en el futuro.

Incluso cuando un parche se ve bien y se desempeña bien en las pruebas, no solo lo despliegue, tire el interruptor y relájese. Asegúrese de que haya un punto conocido para revertir, en caso de otro problema. El control de la version completa, junto con los puntos de reversión en todo el sistema, permite a los desarrolladores volver a una versión anterior y proporcionar cierta continuidad comercial cuando se produce un problema.

Despliegue el parche

Después de que los equipos escriben y prueban un parche para abordar una causa raíz totalmente identificada, es hora de implementar la solución. Si no funciona, retroceda a una posición conocida para la continuidad, como se mencionó anteriormente. Si el problema o uno similar vuelve a ocurrir en el futuro, existe una documentación completa de la solución para referencia.

Un proceso similar de administración de parches puede aplicarse también a problemas de hardware: Identificar la causa raíz; crear un boleto de problemas adecuado; restringir el acceso al equipo identificado a un administrador/ingeniero definido; asegurar la documentación de cambio; pruebe el arreglo antes de que lo utilicen los clientes o las cargas de trabajo; y despliegue el parche, con un plan B, según sea necesario.

Si bien este proceso puede parecer que ralentiza el arreglo requerido, en última instancia evita que los desarrolladores tengan que luchar para resolver el mismo problema más de una vez. Por supuesto, la excepción es cuando un desarrollador identifica correctamente la causa exacta de un problema y lo arregla completamente en el primer intento, pero esto es raro.

En lugar de terminar con un lío de códigos cambiados en una serie de áreas diferentes que podrían convertirse en problemas nuevos y no relacionados, un proceso de administración de parches adecuado en tiempos de crisis de TI asegura su trabajo.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close