Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Etapa 5: Responder y aprender

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

La etapa Responda y aprenda se centra en las prácticas que puede implementar para responder mejor a los eventos disruptivos en sus aplicaciones. También incluye prácticas que le ayudarán a extraer 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 es evitar que los clientes y la empresa sufran más daños lo antes posible. Una vez que la aplicación se haya recuperado, el siguiente paso es entender qué ha ocurrido e identificar las medidas 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 el deterioro de la aplicación y los efectos de la interrupción en la aplicación, los clientes y la empresa. Estos informes se convierten en valiosos recursos de aprendizaje y deberían compartirse ampliamente en toda la empresa.

Un buen informe de análisis de incidentes, como el documentado en el proceso de corrección de errores (COE) de Amazon, sigue un formato estandarizado e intenta capturar, con el mayor detalle posible, las condiciones que provocaron el deterioro de la aplicación. El informe detalla una serie de eventos con fecha determinada y captura datos cuantitativos (a menudo métricas y capturas de pantalla de los paneles de control) que describen el estado mensurable 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 les llevó a sacar sus conclusiones. El informe también debe detallar el rendimiento de los diferentes indicadores, por ejemplo, qué alarmas se emitieron, si esas alarmas reflejaban 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 cronología también incluye los manuales de ejecución o las automatizaciones que se iniciaron y cómo ayudaron a la aplicación a recuperar un estado útil. Estos elementos del cronograma ayudan a su equipo a comprender la eficacia de las respuestas automatizadas y de los operadores, incluida la rapidez con la que abordaron el problema y su eficacia a la hora de mitigar la interrupción.

Esta imagen detallada de un acontecimiento 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 otros 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.

Un repositorio de informes detallados de incidentes también se convierte en una fuente de material de formación para los operadores. Los equipos pueden utilizar un informe de incidentes para inspirarse en un día de juego de mesa o en directo, en el que los equipos reciben información que reproduce la cronología recogida en el informe. Los operadores pueden analizar el escenario con información parcial de la cronología y describir las medidas que tomarían. A continuación, el moderador del día del partido podrá orientar 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 anticipar y solucionar los problemas con mayor facilidad.

Un equipo centralizado responsable 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 capacitar a los equipos sobre cómo completar el informe de análisis de incidentes. El equipo de confiabilidad debe revisar periódicamente los informes para detectar tendencias en toda la empresa que puedan abordarse mediante bibliotecas de software, patrones de arquitectura o cambios en los procesos del equipo.

Realizar revisiones operativas

Como se explica en la etapa 4: Operate, las revisiones operativas son una oportunidad para revisar las versiones recientes de funciones, los incidentes y las métricas operativas. La revisión operativa también es una oportunidad para compartir lo aprendido a partir de los lanzamientos de funciones y los incidentes con la comunidad de ingenieros de su organización en general. Durante la revisión operativa, los equipos analizan los despliegues de funciones que se han revertido, los incidentes que se han producido y la forma en que se han gestionado. Esto brinda a los ingenieros de toda la organización la oportunidad de aprender de las experiencias de otros y de hacer preguntas.

Dirija sus reseñas operativas a la comunidad de ingenieros de su empresa para que puedan obtener más información sobre las aplicaciones de TI que gestionan la empresa y los tipos de problemas a los que pueden enfrentarse. Llevarán consigo estos conocimientos a la hora de diseñar, implementar e implementar otras aplicaciones para la empresa.

Revisar el rendimiento de las alarmas

Las alarmas, tal como se explicó en la fase de operación, pueden provocar 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 los operadores.  Una aplicación tendrá numerosas alarmas configuradas para monitorear 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 debe dedicar a interpretar o diagnosticar la interrupción específica 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 deben interpretar primero la información que transmite la alarma. La información puede consistir en 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 emitido 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 requieren que un operador las analice y diagnostique. Su equipo debería trabajar para reducir el número de alarmas generales a fin de mejorar los tiempos de respuesta y reducir el tiempo medio de reparación (MTTR). Lo ideal sería que hubiera una one-to-one relación entre una alarma y una respuesta automática o realizada por una persona.  

Falsos positivos

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

Falsos negativos

Durante un incidente, las alarmas que están configuradas para alertar durante el incidente pueden 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 emitido pero que no se activaron. Deberías esforzarte 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 alarmas adicionales que se refieran a la misma interrupción, pero que se activen por 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 provoque varias alarmas.  Periódicamente, o como parte de un análisis de incidentes, debe revisar las alarmas y alertas que se emitieron.  Si los operadores recibieron alertas duplicadas, cree alarmas agregadas para consolidarlas en un único mensaje de alerta.

Realización de revisiones de métricas

Su equipo debe recopilar métricas operativas sobre su aplicación, como el número de incidentes por gravedad por 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 subsanar y el número de tickets creados, de alertas enviadas y de páginas generadas. Revise estas métricas al menos una vez al mes para comprender la carga que supone para el personal operativo, la signal-to-noise proporción a la que se enfrentan (por ejemplo, alertas informativas frente a alertas procesables) y si el equipo está mejorando su capacidad para operar las aplicaciones que están bajo su control. Utilice esta revisión para comprender las tendencias en los aspectos mensurables del equipo de operaciones. Solicita ideas al equipo sobre cómo mejorar estas métricas.  

Proporcionar formación y capacitación

Es difícil capturar una descripción detallada de una aplicación y su entorno que provocó un incidente o un comportamiento inesperado. Además, modelar la resiliencia de la aplicación para anticipar estos escenarios no siempre es sencillo. Su organización debería invertir en materiales de capacitación y capacitación para que sus equipos de operaciones y desarrolladores participen en actividades como la modelización de la 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 anticipar los fallos 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.

Crear 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 se ha deteriorado. Usa la misma estructura de informes estandarizada para recopilar el resultado de los caóticos experimentos y de los días de juego. El informe representa una instantánea de la aplicación y su 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.  

Luego, 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ó el deterioro de las aplicaciones. 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, puedes utilizar los informes como material de formación o como escenarios para los días de juego o para hacer experimentos caóticos, a fin de mejorar la intuición del equipo operativo y su capacidad para solucionar problemas.

Implementar la resiliencia en profundidad

Como se mencionó anteriormente, una organización avanzada implementará múltiples respuestas a una alarma. No hay garantía de que una respuesta sea efectiva, por lo que, si se agrupan las respuestas por capas, una aplicación estará mejor preparada para fallar sin problemas. Te recomendamos que implementes al menos dos respuestas para cada indicador a fin de garantizar que una respuesta individual 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 fue efectiva. No debes ejecutar varias respuestas en capas a una sola alarma. En su lugar, utilice una alarma que indique si una respuesta no ha tenido éxito y, de ser así, inicie la siguiente respuesta en capas.