Las interrupciones de la producción pueden ser estresantes, pero también pueden dar lugar a valiosas lecciones. He aquí algunos consejos sobre cómo realizar una autopsia para evitar que se repita.
Trabajar en TI tiene muchos beneficios; muchas oportunidades de empleo, un trabajo interesante y desafiante y la capacidad de involucrarse con una gran cantidad de tecnología de punta.
La otra cara de la moneda puede ser largas noches, problemas molestos y -probablemente temidos sobre todo por todos los profesionales de TI- una interrupción de la producción, en la que los sistemas o servicios críticos no están disponibles, ya sea por acción humana o por fallo técnico.
No hay mayor estrés en TI que el de ser el responsable de volver a encender las luces, especialmente cuando la fuente del problema no está clara. Las preocupaciones adicionales sobre el empleo en curso tampoco ayudan en nada.
Resolver el problema a menudo es motivo de celebración – y con razón – pero es importante no sólo pasar alegremente al siguiente tema. Un corte de producción es una condición seria que merece una introspección significativa para ayudar a salvaguardar la compañía y la carrera de uno contra una repetición del problema, o ser impactado por uno similar.
Aquí hay 10 maneras de sacar el máximo provecho de una interrupción de la producción y avanzar de manera constructiva.
1. Recopilar la información
Utilice los registros del sistema, los testimonios humanos, cualquier rastro de correo electrónico o mensajería instantánea disponible y todos los demás datos relacionados para averiguar todo lo posible sobre el apagón. Es probable que la información electrónica sea el tipo más confiable, especialmente porque a menudo incluye marcas de tiempo que le ayudan a seguir un rastro cronológico para trazar el mapa del incidente. Un sistema de registro centralizado como Splunk puede ser un gran activo aquí, ya que proporciona un portal único para buscar archivos de registro agregados.
Más información sobre ciberseguridad
2. Identificar la causa de fondo
No basta con mirar los datos y decir»algo se estrelló». ¿Qué causó el accidente? ¿Fue un error humano, una fuga de memoria, un componente de hardware defectuoso, un mal firmware, un parche defectuoso o algún otro elemento? Si es posible, involucre al proveedor, ya que por lo general puede concentrarse en la causa de tales problemas mucho más rápido que el personal de TI promedio que hace malabarismos con múltiples responsabilidades y talentos.
3. Determinar el impacto
Este debería ser un paso fácil. ¿Qué sistemas o servicios se vieron afectados por el apagón? ¿Estaba el correo electrónico caído? ¿No había varios servidores de archivos disponibles? ¿Ha fallado una base de datos? ¿Hubo alguna dependencia? ¿Cuánto tiempo duró el corte y se utilizaron (o estuvieron disponibles) alternativas para mitigar el efecto sobre la compañía, los empleados o los clientes?
La evaluación del impacto no se limita a determinar dónde se encontraba la «zona cero», sino que ayuda a desarrollar medidas preventivas que se discuten más adelante.
4. Evaluar las acciones del personal
Esto es más complicado que el paso anterior. Es importante describir las acciones que el personal tomó antes, durante y después del apagón. Los archivos de registro pueden ayudar a armar el rompecabezas si este es un territorio ambiguo. El comando «history» en el sistema Linux es una mina de oro de información y los Event Logs en Windows también pueden ser útiles.
Es por eso que recomiendo que el personal mantenga un registro escrito de los pasos que tomó durante este tipo de incidentes – incluso en algo tan simple como una ventana de Bloc de Notas – junto con el tiempo involucrado. En tiempos de crisis, muchos profesionales de TI entran en pánico y lanzan todo a un problema con la esperanza de una solución rápida. Sin embargo, el inconveniente de este enfoque es la dificultad para determinar qué es lo que realmente soluciona el problema.
Este paso puede implicar una medida de culpa o señalar con el dedo, particularmente si el apagón fue causado por un error humano o por no prevenir el incidente a pesar de la advertencia previa. Si el corte fue causado deliberadamente por una intención maliciosa (algo ciertamente infrecuente y probablemente difícil de establecer) entonces se debe aplicar alguna medida de disciplina, dependiendo de los estándares gerenciales y de recursos humanos. Sin embargo, no se apresure a juzgar hasta que por lo menos haya pasado el paso siete.
5. Determinar si las salvaguardias existentes han fracasado
En mi experiencia, una causa común de las interrupciones en la producción es que las medidas de seguridad que se pusieron en marcha para evitar tales incidentes no funcionaron o fueron ignoradas.
Por ejemplo, el volumen de registro de un servidor Exchange se llena, lo que obliga al servidor a apagarse. Se habían enviado correos electrónicos al personal durante algún tiempo para alertarles de que el espacio en disco era escaso, pero estos se filtraban a otra carpeta y pasaban desapercibidos. O, tal vez las alertas fueron configuradas para ser enviadas a un individuo en lugar de al grupo, y ese individuo es el antiguo administrador de correo electrónico y ya no está en la compañía. Podría ser que el personal no fuera notificado por correo electrónico de que un sistema estaba muerto, ya que las notificaciones se basaban en ese mismo sistema y en un servidor independiente.
El punto aquí es ver lo que podría haber evitado el apagón y lo que se puede hacer para remediarlo en el futuro.
6. Determinar cómo mejorar los procesos tecnológicos
Tal vez se dio cuenta en el paso anterior de que no había fallado ninguna medida de protección (¡o que no había medidas de protección!), pero aún así no había suficientes medidas preventivas. Aquí es donde los pasos anteriores aportarán valor, ya que ahora se puede determinar lo que hay que hacer para evitar que la empresa vuelva a terminar en el mismo punto.
Considere la posibilidad de implementar monitoreo y alertas adicionales, como aprovechar las capacidades de mensajería de texto para ponerse en contacto con el personal de TI inmediatamente cuando se detecten problemas potenciales. Tal vez se pueda introducir o mejorar la redundancia para que un solo servidor se ejecute en un clúster o una configuración activa/pasiva para que un fallo en el servidor no cause tiempo de inactividad del servicio. El uso de varios ISP con varias puertas de enlace de Internet puede ayudar a que el tráfico de la red siga fluyendo si se produce una interrupción del ISP o si falla un enrutador ascendente. Incluso la realización de visitas físicas diarias a un centro de datos puede resultar útil para detectar luces de advertencia o descubrir alarmas en un sistema que experimenta problemas.
VER: Parcheando WannaCrypt: Despachos desde el frente
7. Determinar cómo mejorar los procesos humanos
La parte tecnológica es sólo la mitad del plan de mejora. Las mejores prácticas humanas a menudo van de la mano con la prevención de apagones futuros, especialmente si éstos fueron causados por errores humanos o mala conducta.
Considere si un sistema de «aprobación por pares» – en el que una persona teclea un comando y la otra persona verifica que es correcto antes de presionar la tecla Intro – podría ser útil. ¿Es necesario introducir una gestión del cambio, en la que los cambios propuestos se describan y se presenten para su aprobación? ¿El personal que trabaja en los sistemas a altas horas de la noche y está sujeto a fatiga que causa un lapso de tiempo en la atención o en el juicio? ¿Necesita el personal capacitación adicional para ayudar a perfeccionar sus habilidades?
Incluso hábitos simples como escribir «hostname -f» en un sistema Linux o «set» en un sistema Windows para confirmar que el nombre del host es correcto antes de tomar acción sobre él puede servir como una protección útil.
8. Implementar y probar las mejoras
Ponga en práctica los cambios propuestos, documente las mejoras y notifique al personal de los detalles y cómo administrarlos (si corresponde) para que se conviertan en las nuevas normas en el futuro.
Pero no confíe ciegamente en que esto funcionará y no hay necesidad de preocuparse más. Compruebe los cambios durante una ventana de mantenimiento acordada. Por ejemplo, con el ejemplo del servidor Exchange con el volumen de registro completo, copie un conjunto de archivos grandes en la unidad para llevarlo a un nivel que debería activar una alerta (por ejemplo, 75% lleno) y confirmar que se ha contactado con el personal adecuado.
9. Decidir a quién notificar
Este puede ser uno de los pasos más difíciles que se enumeran a continuación. Ahora que el incidente está siendo adecuadamente envuelto y puesto a punto, notificar a los usuarios o clientes de una interrupción de la producción puede ser un paso necesario incluso después de que se haya resuelto para que entiendan lo que sucedió y lo que se está haciendo al respecto.
Es fundamental mantener a las personas relevantes al tanto para mantener la credibilidad, exponer las ramificaciones del apagón y discutir qué medidas de seguridad se están tomando para evitar que un apagón de esta naturaleza vuelva a ocurrir, o para facilitar una recuperación más rápida la próxima vez.
Aunque nadie se haya dado cuenta de que el apagón ocurrió en primer lugar, es mejor informarles después del hecho que arriesgarse a que alguien se dé cuenta – junto con el hecho de que usted no aborde el asunto más tarde.
10. Muévase y ajústelo según sea necesario
Un corte de producción puede ser costoso, lento, frustrante e incluso embarazoso. Muchos profesionales de TI han recibido un golpe en su ego y reputación (o en la percepción de la misma) y les ha resultado difícil dejar atrás estos episodios y seguir adelante.
Sin embargo, es importante hacerlo por el bien de la moral y de la carrera de cada uno, por no mencionar el hecho de no dejar que estos asuntos mermen la capacidad de atención y, por lo tanto, causen más problemas tecnológicos.
Ajustar las mejoras aquí puestas en práctica según sea necesario y tener en cuenta que algunas interrupciones pueden ser inevitables, como puede atestiguar cualquier ISP o compañía telefónica, por lo que la pregunta no debería ser: «¿Pasó algo malo?
Boletín informativo de consejotecnologico.com
Refuerce las defensas de seguridad de TI de su organización manteniéndose al día de las últimas noticias, soluciones y mejores prácticas en materia de ciberseguridad. Entregado los martes y jueves
mismo
Véase también