Consejos y prácticas recomendadas de respuesta ante incidentes

1. Ten siempre a mano una mochila de emergencia

Un "kit de emergencia" para los encargados de responder ante incidentes contiene toda la información crítica a la que los equipos tienen que acceder con la menor demora posible. Aunque lo más probable es que sea un documento digital, a los encargados de responder a los incidentes les ayuda mucho contar con un punto de partida centralizado.

Esto podría incluir una serie de cosas:

• Planes de respuesta ante incidentes
• Listas de contactos
• Horario(s) de guardia
• Políticas de derivación
• Enlaces a herramientas de conferencias
• Códigos de acceso
• Documentos de políticas
• Documentación técnica y runbooks

2. No huyas de los runbooks

Los runbooks ofrecen orientación sobre los pasos que seguir en una situación concreta. Son especialmente importantes para los equipos que trabajan en rotaciones de guardias en los casos en los que un experto en sistemas podría no estar disponible de inmediato. Con el mantenimiento adecuado, un conjunto de runbooks permite a los equipos responder con mayor rapidez y crear una base de conocimientos compartida sobre las prácticas de respuesta ante incidentes.

3. Abraza el caos y promueve la estabilidad

Chaos Engineering es la práctica consistente en experimentar con los sistemas inyectándoles fallos intencionadamente para comprender cómo pueden desarrollarse sistemas más robustos. Un ejemplo de esto es Chaos Monkey. Desarrollado originalmente en Netflix, Chaos Monkey es una herramienta que prueba la resiliencia de la red dejando los sistemas de producción fuera de línea intencionadamente.

4. Piensa más allá del NOC

Tradicionalmente, los Network Operations Centers (NOCs) actuaban como centro de supervisión y alertas para sistemas de TI a gran escala. Las modernas herramientas de gestión de incidentes permiten optimizar este proceso de forma considerable. Al automatizar los flujos de trabajo de envío de alertas en función de tipos de alertas definidos, programas de equipo y políticas de escalación, se pueden evitar errores humanos o retrasos.

5. Debes aunar, no agravar

No hay nada peor que recibir un aluvión continuo de alertas provenientes de varias herramientas de supervisión. Al centralizar el flujo de alertas a través de una sola herramienta, los equipos pueden filtrar mejor el ruido y, de este modo, concentrarse rápidamente en los asuntos que requieren atención.

6. Recuerda: el conocimiento es poder

Una alerta básica transmite que algo va mal, pero no siempre especifica el qué, lo cual provoca retrasos innecesarios, ya que obliga a los equipos a investigar y determinar la causa. Si complementas las alertas con los pormenores técnicos que expliquen por qué se desencadenó, el proceso de corrección podrá empezar más rápidamente.

7. Ten alertas para las alertas

La frase en latín "quis custodiet ipsos custodes" (¿quién vigila a quien vigila?) identifica un problema universal. Las herramientas de supervisión que emplean los equipos de desarrollo y de TI son igual de vulnerables a los incidentes y al tiempo de inactividad que los sistemas para cuya protección han sido desarrolladas. Los procesos holísticos de generación de alertas garantizan que se revise el estado tanto de los sistemas como de las herramientas que los supervisan.

8. Detén la hemorragia

Los médicos encargados de hacer triaje saben que se arriesgan a que el daño sea mayor si se atascan intentando resolver todas las situaciones a medida que vayan llegando. Se centran en acciones a corto plazo que estabilicen a un paciente lo suficiente como para poder derivarlo a unos cuidados más intensivos. En los ámbitos tecnológicos, las acciones de contención se centran en soluciones temporales (aislar una red, revertir una compilación, reiniciar servidores, etc.) que, como mínimo, limiten el alcance del incidente o, lo que sería más ideal todavía, vuelvan a poner los sistemas en línea.

9. No actúes en solitario

La cultura del heroísmo en los equipos de TI y DevOps es una filosofía que está de capa caída. Ya no está de moda ser el ingeniero solitario que trabaja sin descanso por la noche y los fines de semana porque eres la única persona que puede volver a poner los sistemas en línea. En lugar de eso, los equipos trabajan como su propio nombre indica: en equipo. La solidez de una cadena se mide por su eslabón más débil, por lo que debes trabajar para potenciar a todo el equipo, no solo a una diva solitaria.

10. Sé transparente

Si los usuarios se topan con una perturbación del servicio, lo habitual es que el incidente se dé a conocer en poco tiempo. Para adelantarse a esta eventualidad, los equipos deben contar con un plan de comunicación de incidentes. El objetivo es generar confianza entre los clientes admitiendo públicamente que se está produciendo una perturbación y asegurarles que se están tomando medidas para resolverla. Herramientas como Statuspage son excelentes para distribuir esta información.

11. Aprende de los fracasos

La cifra de equipos de TI y DevOps que afirman que solo dedican tiempo a revisar "interrupciones del servicio graves" es abrumadora. Aunque es un buen comienzo, suele conllevar que se pasen por alto incidentes más pequeños que pueden tener unas consecuencias persistentes. Es posible que no haga falta elaborar un informe extenso para todos los incidentes, pero hacer un análisis retrospectivo siempre resulta útil.

12. Encuentra la causa primordial (¡no hay ninguna causa primordial!)

¿O tal vez sí? A la hora de analizar un incidente, lo raro es que se pueda nombrar una sola causa "primordial". Lo habitual es que los sistemas sean demasiado complejos e interdependientes para poder definir una sola causa primordial de un incidente. Aunque la causa primordial pueda parecer evidente (pongamos por caso un error mecanográfico que provoque el bloqueo de una aplicación), suele haber motivos para entender cuáles son los factores externos que podrían haber permitido que la aplicación se bloqueara (o no haberlo impedido). Debes buscar varias causas primordiales para conocer en mayor profundidad tus incidentes.

13. No acuses a nadie

El objetivo de todo análisis retrospectivo de un incidente debe ser entender qué fue lo que salió mal y qué se puede hacer para evitar incidentes semejantes en el futuro. Es importante destacar que este proceso no debe utilizarse para cargarle la culpa a nadie, ya que los equipos que se centran en el "quién" en vez de en el "qué" dejan que las emociones desvíen el análisis de la verdadera comprensión de lo sucedido.

Una cosita más

En los entornos modernos de gestión de incidentes, el cambio es la única constante, lo que significa que los sistemas se verán sometidos continuamente a estrés de formas nuevas y diferentes. Los equipos que entienden esto también comprenden que la cuestión no es si los sistemas fallarán, sino cuándo lo harán. La adopción de medidas con el fin de prepararse para estos fracasos debería estar reconocida como un componente fundamental del éxito continuo, e integrarse en el ADN de los equipos de ingeniería.