¡Dziiiiin! Son las 3 de la mañana, estás teniendo un sueño maravilloso y de repente hay una llamada. Estás de servicio esta semana y aparentemente algo pasó. El sistema automatizado llama para averiguar qué pasa. Este es un aspecto importante de la gestión de sistemas informáticos modernos, pero veamos cómo mejorar las notificaciones para las personas.
Familiarizarse con la filosofía de seguimiento, nacida a lo largo de varias décadas de mis funciones en diferentes equipos de seguimiento. Ella fue influenciada en gran medida por la Biblia real de Rob Evashchuk. (Mi Filosofía de Notificación) incluido en el libro sobre y libro de John Alspaugh (Notas sobre la configuración de alertas).
, и - gracias por tu ayuda para editar la publicación.
¿Qué es el CASO?
Decidí crear una hermosa abreviatura como o . yo lo llamo método CASO. Describe cuatro puntos a los que se debe prestar atención cuando se trabaja con monitoreo automático:
- (Contexto)
- (valor práctico)
- (énfasis en los síntomas)
- (calificación)
Si usa CASE, tratará las notificaciones con una saludable indiferencia y no despertará a la gente por la noche. Se debe evaluar periódicamente la utilidad y eficacia del seguimiento. Cuando una persona recibe la notificación, tendrá mejores modelos mentales y más confianza.
Para que sea más fácil de recordar, imagina que necesitas un CASO [es decir, un caso, una razón - nota del traductor] para justificar cada alerta. :Gafas de sol:
¿Y por qué es todo esto?
. Por muchas razones. Y CASE no los eliminará a todos. Pero con él, te despertarás por la noche con mejores notificaciones. Este método abarca varios procesos organizativos que también ayudarán en esta materia.
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 el método CASE facilite el debate sobre las notificaciones que protegen nuestros sistemas pero mantienen ocupados a nuestros colegas.
El punto es que necesita crear una cultura en su organización donde las notificaciones sean tratadas con una saludable indiferencia. Las notificaciones se pueden crear para un propósito específico, pero no es un hecho que no pierdan valor más adelante. ¿Por qué configuramos esta notificación? ¿Hace cuánto que se revisaron sus criterios? Con CASE, estas preguntas pueden responderse.
Contexto pesado: enlace de contexto
Las 3 a.m. no es el mejor momento para leer mensajes que contienen muchas palabras inteligentes. Para responder eficazmente, necesita información. Idealmente, debería ser información sobre un problema específico, cuyo contexto sea inmediatamente claro, y las notificaciones deberían configurarse para que esto sea posible. Esto es "observación" y "orientación" desde . No es una pena dedicar tiempo a esta configuración, porque distraer constantemente a una persona es aún más caro. Respetémonos unos a otros.
Los problemas tienen muchas fuentes. Especialmente fantasmas.
¿Cómo puedo ayudar al oficial de turno? Lo primero que ve el oficial de guardia es una notificación, por lo que construye todas las hipótesis sobre esta base. Luego mira las instrucciones y los paneles, pero ¿hay siempre datos sobre una notificación específica y no solo información general? Alspaugh aconseja “pensar en cómo podría interpretar o responder a la notificación” (diapositiva 29). Una buena notificación está enfocada a la persona de turno, no solo configurada por un umbral.
Aquí hay algunas ideas sobre cómo mejorar el contexto de notificación:
- Muestre al usuario algo útil y especialmente creado, y no solo instrucciones ordinarias o un panel de control. Anteriormente, los chicos y yo usábamos paneles de investigación configurados para notificaciones específicas. Esto ayudará si se conoce el problema, pero sólo confundirá a los demás. Necesitamos encontrar un equilibrio aquí.
- Cuéntanos sobre el historial de la notificación: ¿es nueva? ¿Funciona con frecuencia? ¿Es estacional?
- Muestra cambios recientes en el estado del sistema. ¿Ha cambiado algo recientemente? (Por ejemplo, implementación o habilitación/deshabilitación de funciones).
- Muestre las relaciones y proporcione información para el modelo mental: las dependencias del sistema deben ser claramente visibles, preferiblemente con una indicación de funcionalidad.
- Conecte rápidamente al usuario con el equipo: ¿puede ver los incidentes en curso o averiguar quién más en la empresa ha recibido una notificación? Programa ¿activado?
Idealmente, un programa de gestión de incidentes brindará asesoramiento sobre cómo mejorar el contexto de notificación de las investigaciones de incidentes. ¡Siempre hay algo en lo que trabajar!
Accionable: valor práctico
¿Debería el oficial de guardia hacer algo en respuesta a la notificación? Si no necesitas hacer nada o no está claro qué hacer, ¿por qué lo despertaste? Debe evitar notificaciones que molesten a quienes están de servicio y no requieran ninguna acción.
¿Qué tengo que hacer? ¿Qué deseas?
En el pasado, cuando los sistemas eran simples y los equipos pequeños, establecíamos el monitoreo solo para estar al tanto de todo. La notificación de que la carga en el montón ha aumentado nos dará contexto si el servicio falla posteriormente. A gran escala, este tipo de notificaciones sólo crearán confusión porque nuestros sistemas siempre funcionan en un estado de degradación de diversa gravedad. Esto lleva rápidamente a y, por supuesto, a la pérdida de sensibilidad. Por lo tanto, el oficial de guardia ignora o incluso filtra dichas notificaciones y no siempre responde a ellas como es necesario. ¡No caigas en esta trampa! No configures todas las notificaciones seguidas y luego las envíes por correo electrónico a alguna carpeta olvidada de Dios.
Así es como se ve un aviso con valor práctico:
- Una notificación requiere acción en lugar de simplemente informar noticias.
- Esta acción es difícil o arriesgada de automatizar. Si una acción se puede automatizar, entonces automatízala, ¡deja de molestar a la gente!
- El aviso contiene recomendaciones urgentes en forma (SLA) o (RTO). Luego, el oficial de servicio puede activar el programa de gestión de incidentes de la organización.
Quiero aclarar: no estoy diciendo que las notificaciones solo deban llegar para los SLO (objetivos de nivel de servicio) más importantes para la API. El monitoreo de SLO está constantemente fragmentado y dividido y requiere el mismo enfoque para todos los servicios. Está claro que realizará un seguimiento de los SLO más importantes para los clientes que le pagan. Pero también es necesario monitorear los SLO de infraestructura, como las bases de datos. Pronto tendrás que tratar con clientes internos y brindarles soporte. Y así hasta el infinito.
Basado en síntomas: énfasis en los síntomas
Te guste o no, estás trabajando en un sistema distribuido (Kavaj). Como resultado, se utilizan diferentes tácticas para aislar los servicios y protegerlos de fallas (Trainor et al.)3. Y aunque una recolección de basura retrasada o una consulta de base de datos detenida 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 tener valor práctico, pero si no molestan a los usuarios, entonces no son lo suficientemente urgentes como para distraer al asistente. Las notificaciones basadas en causas son instantáneas de nuestros modelos mentales sobre una falla del sistema. Es mejor realizar un seguimiento de los síntomas importantes que intentar enumerar todas las posibles causas de una falla.
Para que las notificaciones sean significativas, céntrese en , importante para los usuarios. Evashchuk llama a esto "seguimiento de los usuarios". Recuerde que esta filosofía debe aplicarse en toda la organización. Si un servicio tiene problemas urgentes en algún lugar profundo de la infraestructura, el equipo adecuado se encargará de ellos. Proteger los sistemas de tales fallas es un asunto completamente separado (Trainer et al., sección sobre estrategias para minimizar las dependencias críticas).
Los síntomas no son tan variables.
Richard Cook nos recuerda que los sistemas complejos están llenos de fallos, deficiencias y problemas. Tratar de enumerar todas las posibles razones es una tarea de Sísifo. Intentas describir los problemas, pero cambian todo el tiempo. Cindy Sridharan cree que “los sistemas no tienen por qué estar en perfectas condiciones cada segundo” y es mejor utilizar un enfoque más humano ( (“Monitoreo de sistemas distribuidos”), 7).
Evitar notificaciones tras un incidente
Normalmente, las notificaciones de causas se configuran para corregir incidentes. Y estas notificaciones limitadas sobre lo sucedido crean una falsa sensación de seguridad, porque el sistema cada vez encuentra nuevas formas de romperlo.
No se deje engañar por los avisos de causa. Mejor piensa:
- ¿Por qué la notificación basada en síntomas no detectó el problema?
- ¿Sería útil mejorar el contexto para el usuario?
- ¿Cómo se pueden mejorar las herramientas de seguimiento para hacer un diagnóstico más rápido, en lugar de acumular notificaciones sobre lo sucedido?
Las herramientas de seguimiento para el diagnóstico sólo ayudarán si las considera una forma de pasar del síntoma a la solución. Sin esta retroalimentación, simplemente será bombardeado con notificaciones tardías y gráficos sobre fallas pasadas, y ni una palabra sobre las futuras. Esta es una gran oportunidad para que una organización pase de la defensa al ataque. Y los desarrolladores y gerentes de producto tendrán las mismas expectativas y objetivos claros. El caso - CASE (:wink:) - es claro para cada notificación.
Las notificaciones basadas en motivos son tolerables con moderación
A veces nuestro sistema nos deja pocas opciones en términos de notificaciones basadas en causas. Y a veces los que están de servicio entienden perfectamente que un síntoma conducirá definitivamente a una falla y, por lo tanto, tiene un valor práctico. Tal vez simplemente no esté seguro de lo que está pasando y esté configurando notificaciones para estar seguro. Esperemos que esta acción sea temporal hasta que podamos cambiar el sistema para resolver el problema de rendimiento.
Tenga en cuenta los demás componentes de CASE cuando se enfrente a estas situaciones. El hecho de que sea temporal no significa que puedas dejar de pensar con la cabeza.
Evaluado - evaluación
Cualquier cambio en el sistema (nuevo código, nueva infraestructura, cualquier cosa nueva) amplía el rango de fallas (Cook, 3). ¿Esta notificación sigue funcionando como se esperaba? Modelos mentales claros y actuales de sistemas y experiencia respondiendo a algunas notificaciones de soporte. - estas son las características clave . Los defectos en los sistemas evolucionan constantemente y debemos mantenernos al día.
Debe evaluar constantemente la calidad de cada notificación para asegurarse de que funcione como se espera. ¡Queridos líderes! ¡Será mucho más fácil para tus equipos si les ayudas a establecer este proceso! Aquí hay algunas ideas de evaluación:
- uso , u otros métodos de prueba de notificación. ¡El equipo puede hacerlo por sí mismo sin tener que depender de un pesado sistema de gestión de incidentes!
- Incorpore la recopilación de todas las notificaciones relacionadas con incidentes en su programa de gestión de incidentes. Marque útiles, dañinos, inapropiados, poco claros, etc. Utilícelos como comentarios.
- Las notificaciones correctas se activan con poca frecuencia y se prueban cuidadosamente. Asegúrese de que todos los enlaces funcionen, apunten al contexto correcto, etc.
- Si una notificación nunca se activa o se activa con demasiada frecuencia, hay algún problema con ella. Arreglarlo o eliminarlo. ¡Cuidado con la pasividad o actividad excesiva!
- Establezca marcas de tiempo de notificación con fechas de vencimiento. Si la fecha de vencimiento expiró, evalúe la notificación utilizando el método CASE y actualice la marca de tiempo. Al igual que los alimentos, comprueba periódicamente la fecha de caducidad.
- Simplifica el proceso de mejora de notificaciones. Utilice la supervisión como código y almacene notificaciones en un repositorio Git. Las solicitudes de extracción ayudan a involucrar al equipo y le brindan un historial de notificaciones anteriores. Y ya no tendrás miedo de cambiar las notificaciones o pedir permiso a los responsables de las mismas.
- Configure comentarios para notificaciones, incluso si es simple , para que los oficiales de servicio marquen las notificaciones como inútiles o intrusivas. Inserte un enlace o una llamada a la acción en la propia notificación y revise sus comentarios con regularidad.
- Establezca una regla en el equipo: deje que los de turno trabajen para simplificar el trabajo cuando hay poco trabajo. Deja que todo sea un poco mejor después de ti que antes.
Conclusión
Creo que el método CASE ayuda a los desarrolladores y a las organizaciones a analizar 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 otros desarrolladores, programas de gestión y gestión de incidentes para mantener las notificaciones en buen estado. Esto no requiere herramientas especiales ni procesos complejos.
Toda la industria necesita pensar en el factor humano mientras está de servicio sin sacrificar un servicio al cliente de primer nivel. Todas estas herramientas y prácticas pueden y deben mejorarse. Espero que el método CASE ayude con esto.
¡Disfruta de notificaciones mejoradas!
Fuente: habr.com