Dziiiiiiin! A las 3 a.m., ves un sueño maravilloso y, de repente, una campana. Esta semana estás de servicio, y aparentemente sucedió algo. Un sistema automatizado está llamando para averiguar cuál es el problema. Este es un punto importante en la administración de sistemas informáticos modernos, pero veamos cómo hacer que las notificaciones sean más convenientes para las personas.
Conozca la filosofía de monitoreo que nació durante varias décadas de mis deberes en varios equipos de monitoreo. Fue influenciado en gran parte por la verdadera biblia de Rob Evashchuk My Philosophy on Alerting , incluida en el libro de Google SRE , y el libro Consideraciones para el diseño de alertas de John Alspo.
Kelly Dunn , Aridzhit Mukheryi y Maxim Petazzoni : gracias por la ayuda en la edición de la publicación.
¿Qué es un CASO?
Decidí crear un acrónimo hermoso como el método USE de Brendan Gregg o el método RED de Tom Wilkie . Yo llamo a esto el método CASE . Describe cuatro puntos a los que debe prestar atención cuando trabaja con monitoreo automático:
Si usa CASE, trata las notificaciones con indiferencia saludable y no despierta a las personas por la noche. El monitoreo debe ser evaluado regularmente por su utilidad y efectividad. Cuando una persona recibe una notificación, tendrá mejores modelos mentales y más confianza.
Para que sea más fácil de recordar, imagine que necesita un CASO [es decir, un caso, el motivo es un comentario del intérprete ] para justificar cada alerta. : gafas de sol:
¿Y por qué es eso todo?
El deber puede ser un tormento . Por muchas razones Y CASE no los eliminará a todos. Pero con eso por la noche te despertarás de mejores notificaciones. Este método cubre varios procesos organizacionales que también ayudarán en este asunto.
La belleza de los métodos RED y USE es que con su ayuda no solo sabemos cómo trabajar, sino que también hablamos el mismo idioma entre nosotros. Espero que con el método CASE sea más fácil discutir las notificaciones que protegen nuestros sistemas, pero no dar descanso a los colegas.
La conclusión es que debe crear una cultura en la organización donde las notificaciones se traten con una indiferencia saludable. Se pueden crear notificaciones en el caso, pero no el hecho de que no perderán valor más adelante. ¿Por qué configuramos esta notificación? ¿Se han revisado sus criterios hace mucho tiempo? Con CASE, estas preguntas pueden ser respondidas.
Context-Heavy - enlace de contexto
Las 3 am no es el mejor momento para leer mensajes que tienen muchas palabras de moda. Para responder de manera efectiva, necesita información. Idealmente, esta debería ser información sobre un problema específico, en el que el contexto es claro de inmediato, y debe configurar las notificaciones para que sea posible. Estas son "observación" y "orientación" del ciclo NORD . No es una pena pasar tiempo en esta configuración, porque distraer constantemente a una persona es aún más costoso. Respetemos unos a otros.
Los problemas tienen muchas fuentes. Especialmente fantasmas.
¿Cómo ayudar al asistente? El oficial de servicio ve la notificación primero, por lo que construye todas las hipótesis basadas en ella. Luego mira las instrucciones y los paneles, pero ¿hay siempre información en un aviso específico y no solo información general? Alspo aconseja "pensar en cómo interpretar la notificación o responder a ella" (diapositiva 29) 1 . Una buena notificación se centra en el operador y no solo se configura en un valor umbral.
Por lo tanto, aquí hay ideas para mejorar el contexto de notificación:
- Muestre al usuario algo útil y creado específicamente, y no solo instrucciones comunes o un tablero de instrumentos. Anteriormente, los chicos y yo usábamos paneles para investigar, configurados para notificaciones específicas. Esto ayudará si se conoce el problema, y solo confundirá en otros casos. Aquí necesitas encontrar un equilibrio.
- Cuéntanos sobre el historial de notificaciones: ¿es nuevo? ¿A menudo funciona? ¿Es estacional?
- Mostrar cambios recientes en el estado del sistema. ¿Ha cambiado algo recientemente? (Por ejemplo, implementar o habilitar / deshabilitar la funcionalidad).
- Muestre la relación y brinde información para el modelo mental: las dependencias del sistema deben ser claramente visibles, preferiblemente con una indicación de operabilidad.
- Asociar rápidamente al usuario con el equipo: ¿ve incidentes actuales o puede averiguar quién más en la empresa recibió la notificación? ¿Está activado el programa de gestión de incidentes ?
Idealmente, un programa de gestión de incidentes proporciona consejos sobre cómo mejorar el contexto de notificación cuando se investigan incidentes. ¡Siempre hay algo en lo que trabajar!
Accionable - valor práctico
¿Debería el asistente hacer algo en respuesta a la notificación? Si no se necesita hacer nada o no está claro qué hacer, ¿por qué se ha despertado? Es necesario evitar las notificaciones que entran en servicio y no requieren acción.
Que hacer Que necesitas
Anteriormente, cuando los sistemas eran simples y los equipos pequeños, configuramos el monitoreo para mantenernos actualizados. La notificación de que la carga en el montón ha aumentado nos dará contexto si el servicio funciona mal. A gran escala, tales notificaciones solo confundirán, porque nuestros sistemas siempre funcionan en un estado de degradación de gravedad variable. Esto lleva rápidamente a la fatiga de las notificaciones y, por supuesto, a una pérdida de sensibilidad. Por lo tanto, el asistente ignora o incluso filtra tales notificaciones y no siempre responde a ellas según sea necesario. ¡No caigas en esta trampa! No configure todas las notificaciones seguidas, para que luego pueda enviarlas por correo a alguna carpeta olvidada.
Así es como se ve un aviso con valor práctico:
- Una notificación requiere acción, no solo informar las noticias.
- Esta acción es difícil o arriesgada de automatizar. Si la acción se puede automatizar, tómala y automatiza, ¡deja de molestar a las personas!
- El aviso contiene recomendaciones urgentes en forma de un acuerdo de nivel de servicio (SLA) o tiempo de recuperación objetivo (RTO). Luego, el asistente puede utilizar el programa de gestión de incidentes en la organización.
Quiero aclarar: no estoy diciendo que las notificaciones deben venir solo en los SLO más importantes (objetivos de nivel de servicio, metas de nivel de servicio) para la API. El monitoreo de SLO está constantemente fragmentado y dividido y requiere el mismo enfoque para todos los servicios. Está claro que hará un seguimiento de los SLO más importantes para los clientes que le pagan. Pero las infraestructuras de SLO, como las bases de datos, también necesitan ser monitoreadas. Pronto tendrá que tratar con clientes internos y apoyarlos. Y así sucesivamente hasta el infinito.
Basado en síntomas: concéntrese en los síntomas
Te guste o no, trabajas en un sistema distribuido (Kavaj) 2 . Como resultado, utiliza diferentes tácticas para aislar los servicios y protegerlos de fallas (Trainor et al.) 3. Y aunque una recolección de basura prolongada o una consulta cuidadosa a la base de datos indica problemas, no hay necesidad de apresurarse a solucionarlos si los usuarios no tienen problemas en el futuro cercano.
Estas son señales importantes y pueden ser de valor práctico, pero si no interfieren con los usuarios, entonces esto no es tan urgente como para distraer al asistente. Las notificaciones basadas en causas son instantáneas de nuestros modelos mentales de falla del sistema. Es mejor hacer un seguimiento de los síntomas importantes que tratar de enumerar todas las causas posibles de una falla.
Para que las notificaciones tengan un valor práctico, concéntrese en los indicadores de rendimiento que son importantes para los usuarios. Evashchuk llama a esto "monitoreo para los usuarios". Recuerde que esta filosofía debe aplicarse en toda la organización. Si el servicio tiene problemas urgentes en algún lugar profundo de la infraestructura, el equipo apropiado se ocupará de ellos. La protección de los sistemas contra tales fallas es un tema completamente separado (Trainer et al., Una sección sobre estrategias para minimizar las dependencias críticas) 3 .
Los síntomas no son tan volátiles.
Richard Cook recuerda que en los sistemas complejos hay muchas fallas, deficiencias y problemas 4 . Tratando de enumerar todas las causas posibles: trabajo de parto sisifo. Intenta describir los problemas y cambian todo el tiempo. Cindy Sridharan cree que "los sistemas no tienen que estar en perfectas condiciones cada segundo" y es mejor utilizar un enfoque más humano ( "Observabilidad de sistemas distribuidos" , 7) 5 .
Evitar notificaciones de incidentes
Por lo general, las notificaciones por motivos se configuran para corregir incidentes. Y estas notificaciones limitadas sobre el hecho de lo que sucedió crean una falsa sensación de confianza, porque cada vez que el sistema presenta nuevas formas de romper.
No se deje engañar por notificaciones de razones. Piensa mejor
- ¿Por qué la notificación basada en síntomas no notó el problema?
- ¿Sería útil mejorar el contexto para el usuario?
- ¿Cómo mejorar las herramientas de monitoreo para diagnosticar más rápido y no acumular notificaciones sobre lo sucedido?
Las herramientas de monitoreo para el diagnóstico solo ayudarán si las toma como una forma de pasar de un síntoma a una solución. Sin estos comentarios, simplemente se sentirá abrumado con notificaciones tardías y diagramas sobre fallas pasadas, y ni una palabra sobre las futuras. Para una organización, esta es una gran oportunidad para pasar de la defensa al ataque. Y los desarrolladores y gerentes de producto tendrán las mismas expectativas y objetivos claros. Caso - CASO (: guiño :) - para cada notificación es clara.
Notificaciones basadas en tolerancia moderada
A veces, nuestro sistema casi no nos deja otra opción en términos de notificaciones basadas en el motivo. Y a veces los asistentes son conscientes de que un síntoma necesariamente conducirá a un mal funcionamiento, lo que significa que tiene un valor práctico. Quizás no esté seguro de lo que está sucediendo y esté configurando notificaciones para el reaseguro. Esperemos que esta acción se requiera temporalmente hasta que cambiemos el sistema para resolver el problema de la degradación del rendimiento.
Tenga en cuenta otros componentes de CASE cuando lidie con tales situaciones. Si esto es temporal, no significa que no pueda pensar con la cabeza.
Evaluado - Calificación
Cualquier cambio en el sistema (nuevo código, nueva infraestructura, cualquier cosa nueva) amplía el rango de fallas (Cook, 3). 4 ¿Sigue funcionando esta notificación como se esperaba? Los modelos de sistemas mentales claros y relevantes y la experiencia de responder a algunas notificaciones en apoyo de un enfoque preventivo son características clave de una organización orientada al aprendizaje . Los defectos en los sistemas están en constante evolución, y debemos seguirlos.
Debe evaluar constantemente la calidad de cada notificación para que funcionen como se espera. Queridos líderes! ¡Será mucho más fácil para sus equipos si los ayuda a configurar este proceso! Aquí hay algunas ideas para evaluar:
- Utilice la ingeniería del caos , los días de juego u otros métodos de prueba de notificación. ¡El equipo puede hacer esto solo sin usar un sistema de gestión de incidentes de peso pesado!
- Incluya la recopilación de datos en todas las notificaciones de incidentes en el programa de gestión de incidentes. Marque útiles, dañinos, inapropiados, incomprensibles, etc. Úselos como comentarios.
- Las notificaciones correctas son poco frecuentes y se revisan cuidadosamente. Asegúrese de que todos los enlaces funcionen, apunte al contexto correcto, etc.
- Si la notificación nunca se dispara o se dispara con demasiada frecuencia, algo está mal. Repare o quítelo. ¡Cuidado con la pasividad o actividad excesiva!
- Establecer marcas de tiempo de vencimiento para notificaciones. Si la fecha de vencimiento ha pasado, evalúe el aviso utilizando el método CASE y actualice la marca de tiempo. Verifique regularmente la fecha de vencimiento, como con los alimentos.
- Simplifique el proceso de mejora de las notificaciones. Utilice la supervisión en forma de código y almacene notificaciones en el repositorio de Git. Pool solicita ayuda para atraer a un equipo, y tendrás un historial de notificaciones pasadas. Y dejará de tener miedo de cambiar las notificaciones o pedir permiso a los responsables de ellas.
- Configure las notificaciones de comentarios, incluso si se trata solo de un formulario de Google , para que las personas en servicio marquen las notificaciones como inútiles o intrusivas. Incruste un enlace o llamado a la acción en la notificación misma y verifique regularmente los comentarios.
- Establezca una regla en el equipo: deje que los asistentes trabajen para simplificar el deber cuando hay poco trabajo. Deja que todo se vuelva un poco mejor después de ti que antes.
Conclusión
Creo que el método CASE ayuda a los desarrolladores y las organizaciones a discutir la configuración y el envío de notificaciones automáticas. Un desarrollador puede comenzar a evaluar las notificaciones utilizando el método CASE, y luego toda la organización se unirá a él con otros desarrolladores, programas de gestión y gestión de incidentes para mantener las notificaciones en buenas condiciones. No se necesitan herramientas especiales o procesos complejos para esto.
Toda la industria debería pensar en el factor humano mientras está de servicio sin comprometer el servicio al cliente de primera clase. Todas estas herramientas y prácticas pueden y deben mejorarse. Espero que el método CASE ayude con esto.
¡Disfruta de notificaciones mejoradas!
