En este documento del framework de arquitectura de Google Cloud, se proporcionan prácticas recomendadas para administrar servicios y definir procesos para responder a los incidentes. Los incidentes ocurren en todos los servicios, por lo que necesitas un proceso bien documentado para responder a estos problemas de manera eficiente y mitigarlos.
Descripción general de la administración de incidentes
Será inevitable que, en el futuro, el sistema bien diseñado presente fallas en sus SLO. Ante la ausencia de un SLO, los clientes pueden definir de manera flexible cuál es el nivel de servicio aceptable en función de su experiencia pasada. Los clientes escalan al grupo de asistencia técnica o a un grupo similar, sin importar lo que incluya tu ANS.
Para brindar un servicio adecuado a tus clientes, establece y prueba con regularidad un plan de administración de incidentes. El plan puede ser tan breve como una lista de tareas de una sola página con diez elementos. Este proceso ayuda a tu equipo a reducir el tiempo de detección (TTD) y el tiempo de mitigación (TTM).
Se prefiere TTM a diferencia de TTR, donde la R para reparación o recuperación se suele usar para hacer referencia a una corrección completa en comparación con una mitigación. TTM destaca la mitigación rápida para finalizar con rapidez el impacto en el cliente de una interrupción y, luego, iniciar el proceso, a menudo, mucho más largo, para solucionar el problema por completo.
Un sistema bien diseñado en el que las operaciones sean excelentes aumentará el tiempo entre fallas (TBF). En otras palabras, los principios operativos de la confiabilidad, incluida una buena administración de incidentes, buscan lograr que las fallas sean menos frecuentes.
Para ejecutar servicios confiables, aplica las siguientes prácticas recomendadas en el proceso de administración de incidentes.
Asigna una propiedad clara del servicio
Todos los servicios y sus dependencias críticas deben tener propietarios claros responsables de cumplir con sus SLO. Si hay reorganizaciones o abandono de equipos, el líder debe asegurarse de que la propiedad se transfiera de forma explícita a un equipo nuevo, junto con la documentación y la capacitación, según sea necesario. Los otros equipos deben poder detectar con facilidad a los propietarios de un servicio.
Reduce el tiempo de detección (TTD) con alertas bien ajustadas
Antes de poder reducir el TTD, revisa y, luego, implementa las recomendaciones que figuran en las secciones Agrega observabilidad a la infraestructura y las aplicaciones y Define tus objetivos de confiabilidad de la categoría de confiabilidad del framework de arquitectura. Por ejemplo, puedes distinguir entre los problemas de la aplicación y los problemas subyacentes de la nube.
Un conjunto de SLI bien ajustado alerta a tu equipo en el momento adecuado sin generar una sobrecarga de alertas. Para obtener más información, consulta la sección Crea alertas eficientes de la categoría de confiabilidad del framework de arquitectura o Ajusta tus métricas de SLI: lecciones de CRE.
Reduce el tiempo de mitigación (TTM) con los planes de administración de incidentes y el entrenamiento.
Para reducir el TTM, define un plan de administración de incidentes documentado y bien implementado. Ten datos disponibles sobre los cambios en el entorno. Asegúrate de que los equipos conozcan las mitigaciones genéricas que puedan aplicar con rapidez para minimizar el TTM. Estas técnicas de mitigación incluyen el desvío, la reversión de cambios, el aumento de tamaño de los recursos y la degradación de la calidad del servicio.
Como se explicó en otro documento del pilar de confiabilidad del framework de arquitectura, crea herramientas y procesos operativos confiables para admitir la reversión segura y rápida de cambios.
Crea diseños y contenido para el panel para minimizar el TTM
Organiza la navegación y el diseño del panel de servicio de modo que un operador pueda determinar en un minuto o dos si el servicio y todas sus dependencias críticas están en ejecución. Para identificar con rapidez las posibles causas de los problemas, los operadores deben poder analizar todos los gráficos en el panel para detectar con rapidez los gráficos que cambian de manera significativa en el momento de la alerta.
Es posible que la siguiente lista de gráficos de ejemplo se encuentre en el panel para ayudarte a solucionar problemas. Los encargados de ofrecer respuestas ante incidentes deben poder verlos en una sola vista:
- Indicadores de nivel de servicio, como solicitudes exitosas divididas por el total de solicitudes válidas
- Configuración y lanzamientos de objetos binarios
- Solicitudes por segundo al sistema
- Respuestas de error por segundo desde el sistema
- Solicitudes por segundo del sistema a sus dependencias
- Respuestas de error por segundo al sistema desde sus dependencias
Otros gráficos comunes que ayudan a solucionar problemas son la latencia, la saturación, el tamaño de la solicitud, el tamaño de la respuesta, el costo de la consulta, el uso del conjunto de subprocesos y las métricas de la máquina virtual de Java (JVM) (cuando corresponda). La saturación hace referencia a la capacidad total según algún límite, como el tamaño de la cuota o de la memoria del sistema. El uso del conjunto de subprocesos busca regresiones debido al agotamiento del grupo.
Prueba la ubicación de estos gráficos en algunas situaciones de interrupción para asegurarte de que los gráficos más importantes estén cerca de la parte superior y de que el orden de los gráficos coincida con tu flujo de trabajo de diagnóstico estándar. También puedes aplicar el aprendizaje automático y la detección de anomalías estadísticas para mostrar el subconjunto correcto de estos gráficos.
Documenta los procedimientos de diagnóstico y la mitigación para situaciones de interrupciones conocidas
Escribe guías y vincula las notificaciones de alertas. Si se puede acceder a estos documentos desde las notificaciones de alerta, los operadores pueden obtener con rapidez la información que necesitan para solucionar problemas y mitigar los problemas.
Usa los análisis retrospectivos libres de responsabilidad para obtener información sobre las interrupciones y evitar las recurrencias
Establece una cultura libre de responsabilidades a posteriori y un proceso de revisión de incidentes. Libre de responsabilidades significa que tu equipo evalúa y documenta lo que salió mal de manera objetiva sin necesidad de culpar a nadie.
Los errores son oportunidades de aprendizaje y no un motivo de crítica. Siempre intenta que el sistema sea más resiliente para que pueda recuperarse con rapidez de los errores humanos o, incluso mejor, detectarlos y prevenirlos. Extrae tanto aprendizaje como sea posible de cada proceso postmortem y haz un seguimiento diligente de cada elemento de acción postmortem para hacer que las interrupciones sean menos frecuentes, lo que aumenta el TBF.
Ejemplo de un plan de administración de incidentes
Se detectaron problemas de producción como, por ejemplo, a través de una alerta o una página, o se escalaron:
- ¿Debo delegar a alguien más?
- Sí, si tú y tu equipo no pueden resolver el problema.
- ¿Es un problema de la privacidad o la violación de la seguridad?
- Si la respuesta es sí, delega la cuestión al equipo de privacidad o seguridad.
- ¿Este problema es una emergencia o están en riesgo los SLO?
- Si tienes dudas, trata la situación como si fuera una emergencia.
- ¿Debo involucrar a más personas?
- Sí, si afecta a más del X% de los clientes o si toma más de Y minutos en resolverse. Si tienes dudas, siempre debes involucrar a más personas, en especial durante el horario de atención.
- Define un canal de comunicación principal, como IRC, Hangouts Chat o Slack.
- Delega funciones definidas con anterioridad, como las siguientes:
- Comandante de incidentes que es responsable de la coordinación general.
- Líder de comunicaciones que es responsable de las comunicaciones internas y externas.
- Líder de operaciones que es responsable de mitigar el problema.
- Define la finalización del incidente. Es posible que esta decisión se requiera la confirmación de un representante del equipo de asistencia o de otros equipos similares.
- Colabora en el proceso libre de responsabilidades a posteriori.
- Asiste a reuniones de revisión de incidentes a posteriori para ofrecerle al personal elementos de acción y debatirlos.
Recomendaciones
Para aplicar la guía en el framework de arquitectura a tu propio entorno, sigue estas recomendaciones:
- Establece un plan de administración de incidentes y capacita a sus equipos para que lo usen.
- Para reducir el TTD, implementa las recomendaciones para agregar observabilidad a la infraestructura y las aplicaciones.
- Crea el panel "¿Qué cambió?" para que lo puedas consultar cuando ocurra un incidente.
- Documenta los fragmentos de consultas o compila un panel de Looker Studio con consultas de registro frecuentes.
- Evalúa Firebase Remote Config para mitigar los problemas de lanzamiento de las aplicaciones para dispositivos móviles.
- Prueba la recuperación de fallas, incluido el restablecimiento de los datos de las copias de seguridad, para disminuir el TTM de un subconjunto de incidentes.
- Diseña y prueba la configuración y las reversiones binarias.
- Replica datos entre regiones para la recuperación ante desastres y usa pruebas de recuperación ante desastres para disminuir el TTM después de interrupciones regionales.
- Diseña una arquitectura multirregional para la resiliencia ante las interrupciones regionales si la empresa necesita una alta disponibilidad que justifique el costo, de modo que se aumente el TBF.
¿Qué sigue?
Obtén más información sobre cómo compilar un proceso colaborativo de administración de incidentes con los siguientes recursos:
- Panel de estado de Google Cloud
- Administración de incidentes en Google
- Proceso de respuesta ante incidentes de datos
- Capítulo del libro de SRE sobre la administración de incidentes
Explora otras categorías en el framework de arquitectura, como el diseño del sistema, la excelencia operativa y la seguridad, la privacidad y el cumplimiento.