Etapa 5: respuesta y aprendizaje

La forma en que la aplicación responde a eventos disruptivos influye en su fiabilidad. Aprender de la experiencia y de la forma en que la aplicación ha respondido a las interrupciones en el pasado también es fundamental para mejorar su fiabilidad. 

La etapa de respuesta y aprendizaje se centra en las prácticas que puede implementar para responder mejor a los eventos disruptivos que se producen en las aplicaciones. También incluye prácticas que lo ayudarán a obtener el máximo provecho de las experiencias de sus ingenieros y equipos de operaciones.

Creación de informes de análisis de incidentes

Cuando se produce un incidente, la primera acción consiste en evitar lo antes posible que los clientes y la empresa sufran más daños. Una vez que la aplicación se haya recuperado, el siguiente paso es entender lo que ha sucedido e identificar los pasos necesarios para evitar que vuelva a ocurrir. Este análisis posterior al incidente suele plasmarse en un informe que documenta el conjunto de eventos que provocaron la avería de la aplicación y los efectos de las interrupciones en la aplicación, los clientes y la empresa. Estos informes se convierten en valiosos artefactos de aprendizaje y deben compartirse ampliamente con toda la empresa.

Los buenos informe de análisis de incidentes, como el que se documenta en el proceso de corrección de errores (COE) de Amazon, siguen un formato estandarizado e intentan capturar, con el mayor detalle posible, las condiciones que provocaron la avería en la aplicación. El informe detalla una serie de eventos con marca de tiempo y captura datos cuantitativos (a menudo, métricas y capturas de pantalla de los paneles de control de supervisión) que describen el estado medible de la aplicación a lo largo del tiempo. El informe debe reflejar los procesos de pensamiento de los operadores e ingenieros que tomaron medidas y la información que los llevó a sacar sus conclusiones. En el informe también se debe detallar el rendimiento de los diferentes indicadores; por ejemplo, qué alarmas se emitieron, si esas alarmas reflejaron con precisión el estado de la aplicación, el intervalo de tiempo entre los eventos y las alarmas resultantes y el tiempo necesario para resolver el incidente. La escala de tiempo también refleja los manuales de procedimientos o las automatizaciones que se iniciaron y cómo ayudaron a la aplicación a recuperar un estado útil. Estos elementos de la escala de tiempo ayudan a su equipo a comprender la eficacia de las respuestas automatizadas y de los operadores, como la rapidez con la que abordaron el problema y su eficacia a la hora de mitigar la interrupción.

Esta imagen detallada de un evento histórico es una poderosa herramienta educativa. Los equipos deben almacenar estos informes en un repositorio central que esté disponible para toda la empresa para que otras personas puedan revisar los eventos y aprender de ellos. Esto puede mejorar la intuición de sus equipos sobre lo que puede salir mal en la producción.

Los repositorios de informes detallados de incidentes también se convierten en una fuente de material de formación para los operadores. Los equipos pueden utilizar los informes de incidentes como inspiración para un día de ejercicios prácticos o de juego en vivo en el que los equipos reciben información que reproduce la escala de tiempo recogida en el informe. Los operadores pueden repetir el escenario con información parcial de la escala de tiempo y describir las medidas que tomarían. A continuación, el moderador del día de juego podrá aportar orientación sobre la respuesta de la aplicación en función de las acciones del operador. Esto desarrolla las habilidades de solución de problemas de los operadores para que puedan anticiparse y solucionar los problemas con mayor facilidad.

Un equipo centralizado encargado de la fiabilidad de las aplicaciones debe mantener estos informes en una biblioteca centralizada a la que pueda acceder toda la organización. Este equipo también debe ser responsable de mantener la plantilla del informe y de formar a los equipos sobre cómo rellenar el informe de análisis de incidentes. El equipo de fiabilidad tiene que revisar los informes periódicamente para detectar tendencias en toda la empresa que puedan abordarse mediante bibliotecas de software, patrones de arquitectura o cambios en los procesos del equipo.

Realización de revisiones operativas

Como se explica en la etapa 4: funcionamiento, las revisiones operativas son una oportunidad para revisar los recientes lanzamientos de características, los incidentes y las métricas operativas. La revisión operativa también es una oportunidad para compartir lo que se aprendió a partir de los lanzamientos de características y los incidentes con toda la comunidad de ingenieros de su organización. Durante la revisión operativa, los equipos analizan las implementaciones de características que se han revertido, los incidentes que se han producido y la forma en que se han gestionado. De esta forma, los ingenieros de toda la organización tienen la oportunidad de aprender de las experiencias de otros y de formular preguntas.

Dirija sus revisiones operativas a la comunidad de ingenieros de la empresa de forma que puedan obtener más información sobre las aplicaciones de TI que hacen funcionar a la empresa y los tipos de problemas a los que pueden enfrentarse. Usarán estos conocimientos a la hora de diseñar, implementar y desplegar otras aplicaciones para la empresa.

Revisión el rendimiento de las alarmas

Las alarmas, tal como se explicó en la fase de funcionamiento, pueden generar alertas en el panel de control, la creación de tickets, el envío de correos electrónicos o la creación de llamadas a operadores.  Una aplicación tendrá numerosas alarmas configuradas para supervisar varios aspectos de su funcionamiento. Con el tiempo, la precisión y la eficacia de estas alarmas deberán revisarse para aumentar la precisión de las alarmas, reducir los falsos positivos y consolidar las alertas duplicadas.

Precisión de las alarmas

Las alarmas deben ser lo más específicas posible para reducir el tiempo que se tendrá que dedicar a interpretar o diagnosticar la interrupción en concreto que causó la alarma. Cuando se activa una alarma en respuesta a una avería de la aplicación, los operadores que reciben y responden a la alarma primero tienen que interpretar la información que transmite la alarma. La información puede ser un simple código de error que indica una línea de acción, como un procedimiento de recuperación, o puede incluir líneas de los registros de la aplicación que hay que revisar para entender por qué se ha activado la alarma. A medida que su equipo aprenda a utilizar una aplicación de forma más eficaz, debería refinar estas alarmas para que sean lo más claras y concisas posible.

No se pueden anticipar todas las posibles interrupciones en una aplicación, por lo que siempre habrá alarmas generales que necesitarán que un operador las analice y diagnostique. Su equipo debería esforzarse por reducir la cantidad de alarmas generales a fin de mejorar los tiempos de respuesta y reducir el tiempo medio de reparación (MTTR). Lo ideal es que haya una relación unívoca entre una alarma y una respuesta automática o una respuesta a cargo de una persona.  

Falsos positivos

Con el tiempo, los operadores ignorarán las alarmas que no requieran ninguna acción por su parte, pero que generen alertas en forma de correos electrónicos, páginas o tickets.  Revise las alarmas periódicamente o como parte de un análisis de los incidentes para identificar aquellas que suelen ignorarse o que no requieren ninguna acción por parte de los operadores (falsos positivos).  Debería esforzarse por eliminar la alarma o mejorarla para que emita una alerta útil para los operadores.

Falsos negativos

Durante un incidente, las alarmas que se han configurado para alertar durante el incidente podrían fallar, tal vez debido a un evento que afecte a la aplicación de forma inesperada.  Como parte del análisis de un incidente, debe revisar las alarmas que deberían haberse activado pero que no se han emitido. Debería esforzarse por mejorar estas alarmas para que reflejen mejor las condiciones que podrían surgir a raíz de un evento. Como alternativa, es posible que tenga que crear más alarmas que hagan referencia a la misma interrupción, pero que se activen debido a un síntoma diferente de la interrupción.

Alertas duplicadas

Es probable que una interrupción que afecte a la aplicación provoque varios síntomas y genere varias alarmas.  Periódicamente, o como parte de un análisis de los incidentes, debe revisar las alarmas y alertas que se han emitido.  Si los operadores recibieron alertas duplicadas, cree alarmas agregadas para consolidarlas en un único mensaje de alerta.

Realización de revisiones de métricas

El equipo debe recopilar métricas operativas sobre la aplicación, como el número de incidentes por gravedad al mes, el tiempo que se tarda en detectar el incidente, el tiempo que se tarda en identificar la causa, el tiempo que se tarda en corregir y el número de tickets creados, alertas enviadas y páginas generadas. Revise estas métricas al menos una vez al mes para comprender la carga que supone para el personal operativo, la relación señal/ruido a la que se enfrentan (por ejemplo, la relación entre alertas informativas y alertas útiles) y si el equipo está mejorando su capacidad para poner en funcionamiento las aplicaciones que están bajo su control. Utilice esta revisión para comprender las tendencias en los aspectos medibles del equipo de operaciones. Pida ideas al equipo sobre cómo mejorar estas métricas.  

Prestación de formación y capacitación

Es difícil crear una descripción detallada de una aplicación y el entorno que provocó un incidente o un comportamiento inesperado. Además, crear modelos de resiliencia de la aplicación para anticipar estos escenarios no siempre es sencillo. Su organización debe invertir en materiales de formación y capacitación para que los equipos de operaciones y desarrolladores participen en actividades como la creación de modelos de resiliencia, el análisis de incidentes, las jornadas de juego y los experimentos de ingeniería del caos. Esto mejorará la fidelidad de los informes que producen sus equipos y los conocimientos que recopilan. Los equipos también estarán mejor preparados para anticiparse a los errores sin tener que depender de un grupo de ingenieros más reducido y con más experiencia, que deberán aportar sus conocimientos mediante revisiones programadas.

Creación de una base de conocimientos sobre incidentes

Un informe de incidentes es un resultado estándar de un análisis de incidentes. Debe utilizar el mismo informe o uno similar para documentar los escenarios en los que haya detectado un comportamiento anómalo de una aplicación, incluso si la aplicación no ha tenido ninguna avería. Use la misma estructura de informes estandarizada para recopilar el resultado de los experimentos del caos y de los días de juego. El informe representa una instantánea de la aplicación y el entorno que provocó un incidente o un comportamiento inesperado. Debe almacenar estos informes estandarizados en un repositorio central al que puedan acceder todos los ingenieros de la empresa.  

A continuación, los equipos de operaciones y los desarrolladores pueden buscar en esta base de conocimientos para comprender qué ha interrumpido las aplicaciones en el pasado, qué tipos de situaciones podrían haber provocado la interrupción y qué evitó averías en la aplicación. Esta base de conocimientos se convierte en un acelerador para mejorar las habilidades de sus equipos de operaciones y desarrolladores, y les permite compartir sus conocimientos y experiencias. Además, puede utilizar los informes como material de formación o como escenarios para los días de juego o para los experimentos del caos a fin de mejorar la intuición del equipo operativo y su capacidad para resolver las interrupciones.

Implementación de la resiliencia en profundidad

Como se mencionó anteriormente, las organizaciones avanzadas implementarán varias respuestas a una alarma. No hay ninguna garantía de que una respuesta sea efectiva, por lo que, si se agrupan las respuestas por capas, la aplicación estará mejor preparada para que se produzca un error sin causar problemas. Le recomendamos que implemente al menos dos respuestas para cada indicador a fin de garantizar que una respuesta específica no se convierta en un único punto de error que pueda desembocar en un escenario de recuperación ante desastres.  Estas capas deben crearse en orden de serie, de modo que solo se ejecute una respuesta sucesiva si la respuesta anterior no surtió efecto. No ejecute varias respuestas en capas ante una sola alarma. En su lugar, utilice una alarma que indique si una respuesta no ha funcionado correctamente y, de ser así, inicie la siguiente respuesta en capas.