Dziiiiin! Son as 3 da mañá, estás a ter un soño marabilloso e, de súpeto, hai unha chamada. Estás de servizo esta semana e, ao parecer, pasou algo. O sistema automatizado chama para descubrir o que está mal. Este é un aspecto importante da xestión dos sistemas informáticos modernos, pero vexamos como mellorar as notificacións para as persoas.
Coñecer a filosofía do seguimento, nacida ao longo de varias décadas das miñas funcións en diferentes equipos de seguimento. Foi influenciada en gran medida pola verdadeira biblia de Rob Evashchuk (A miña filosofía de notificación) incluído no libro sobre , e libro de John Alspaugh (Notas sobre a configuración de alertas).
, и - Grazas pola túa axuda na edición da publicación.
Que é CASE?
Decidín crear unha fermosa abreviatura como ou . chámolle Método CASE. Describe catro puntos aos que prestar atención cando se traballa coa vixilancia automática:
- (contextualizado)
- (valor práctico)
- (énfase nos síntomas)
- (grado)
Se usas CASE, tratas as notificacións cunha saudable indiferenza e non espertas á xente pola noite. O seguimento debe ser avaliado regularmente para a súa utilidade e eficacia. Cando unha persoa reciba a notificación, terá mellores modelos mentais e máis confianza.
Para facilitar o recordo, imaxina que necesitas un CASO [é dicir, un caso, un motivo - nota do tradutor] para xustificar cada alerta. :gafas de sol:
E por que todo isto?
. Por moitas razóns. E CASE non os eliminará todos. Pero con el, espertarás pola noite con mellores notificacións. Este método abrangue varios procesos organizativos que tamén axudarán neste asunto.
A beleza dos métodos RED e USE é que coa súa axuda non só sabemos traballar, senón que tamén falamos o mesmo idioma entre nós. A miña esperanza é que o método CASE faga máis doado discutir notificacións que protexen os nosos sistemas pero que manteñan ocupados os nosos compañeiros.
A cuestión é que cómpre crear unha cultura na súa organización onde as notificacións sexan tratadas cunha saudable indiferenza. As notificacións pódense crear para un propósito específico, pero non é un feito que non perdan valor máis tarde. Por que configuramos esta notificación? Canto tempo hai que se revisaron os seus criterios? Con CASE pódense responder estas preguntas.
Context-Heavy - vinculación de contexto
As 3 da mañá non é o mellor momento para ler mensaxes que conteñen moitas palabras intelixentes. Para responder de forma eficaz, necesitas información. O ideal é que se trate de información sobre un problema específico, para o cal o contexto estea inmediatamente claro, e as notificacións deberían configurarse para que isto sexa posible. Isto é "observación" e "orientación" de . Non é unha vergoña dedicar tempo a esta configuración, porque distraer constantemente a unha persoa é aínda máis caro. Respectémonos.
Os problemas teñen moitas fontes. Especialmente pantasmas.
Como podo axudar ao oficial de servizo? O primeiro que ve o oficial de servizo é unha notificación, polo que constrúe todas as hipóteses en función da mesma. Despois mira as instrucións e os paneis de control, pero sempre hai datos sobre unha notificación específica, e non só información xeral? Alspaugh aconsella "pensar como podes interpretar ou responder á notificación" (diapositiva 29). Unha boa notificación céntrase na persoa de servizo, non só configurada por un limiar.
Así que aquí tes algunhas ideas sobre como mellorar o contexto de notificación:
- Mostra ao usuario algo útil e creado especialmente, e non só instrucións comúns ou un panel. Anteriormente, os mozos e eu utilizabamos paneis de control de investigación configurados para notificacións específicas. Isto axudará se se coñece o problema, pero só confundirá a outros. Necesitamos atopar un equilibrio aquí.
- Fálanos do historial da notificación: é nova? Funciona a miúdo? É estacional?
- Mostra os cambios recentes no estado do sistema. Cambiou algo recentemente? (Por exemplo, implementación ou activación/desactivación da función).
- Mostrar as relacións e proporcionar información para o modelo mental: as dependencias do sistema deben ser claramente visibles, preferentemente cunha indicación de funcionalidade.
- Conecta rapidamente o usuario co equipo: pode ver incidentes en curso ou pode descubrir quen máis da empresa recibiu unha notificación? Programa activado?
Idealmente, un programa de xestión de incidentes proporcionará consellos sobre como mellorar o contexto de notificación das investigacións de incidentes. Sempre hai algo no que traballar!
Accionable - valor práctico
O oficial de servizo debería facer algo en resposta á notificación? Se non precisa facer nada ou non está claro que facer, por que o espertou? Cómpre evitar as notificacións que molesten aos de garda e que non requiran acción.
Qué debería facer? Que queres?
No pasado, cando os sistemas eran sinxelos e os equipos eran pequenos, configurabamos a supervisión só para estar ao día. A notificación de que a carga no montón aumentou daranos contexto se posteriormente o servizo falla. A gran escala, tales notificacións só crearán confusión porque os nosos sistemas sempre están a funcionar nun estado de degradación de diversa gravidade. Isto leva rapidamente a e, por suposto, á perda de sensibilidade. Polo tanto, o oficial de servizo ignora ou mesmo filtra tales notificacións e non sempre responde a elas segundo sexa necesario. Non caia nesta trampa! Non configures todas as notificacións seguidas e despois envíaas por correo electrónico a algún cartafol abandonado.
Así é o aspecto dun aviso con valor práctico:
- Unha notificación require acción en lugar de simplemente informar de noticias.
- Esta acción é difícil ou arriscada de automatizar. Se se pode automatizar unha acción, automatízaa, deixa de molestar á xente.
- O aviso contén recomendacións urxentes no formulario (SLA) ou (RTO). O oficial de servizo pode entón activar o programa de xestión de incidentes da organización.
Quero aclarar: non digo que as notificacións só deban vir para os SLO (obxectivos de nivel de servizo) máis importantes para a API. O seguimento do SLO está constantemente fragmentado e dividido e require o mesmo enfoque para todos os servizos. Está claro que seguirás os SLO máis importantes para os clientes que che pagan. Pero os SLO de infraestruturas, como as bases de datos, tamén deben ser supervisados. En breve terás que tratar cos clientes internos e apoialos. E así ata o infinito.
Baseado nos síntomas: énfase nos síntomas
Quere ou non, está a traballar nun sistema distribuído (Kavaj). Como resultado, utiliza diferentes tácticas para illar os servizos e protexelos dos fallos (Trainor et al.)3. E aínda que unha recollida de lixo atrasada ou unha consulta de base de datos paralizada indican problemas, non hai que apresurarse para solucionalos se os usuarios non teñen problemas nun futuro próximo.
Estes son sinais importantes e poden ter un valor práctico, pero se non molestan aos usuarios, non é o suficientemente urxente para distraer ao encargado. As notificacións baseadas na causa son instantáneas dos nosos modelos mentais sobre un fallo do sistema. É mellor rastrexar os síntomas importantes que tentar enumerar todas as posibles causas dun fallo.
Para que as notificacións sexan significativas, céntrate en , importante para os usuarios. Evashchuk chama a isto "seguimento dos usuarios". Lembra que esta filosofía debe aplicarse en toda a organización. Se un servizo ten problemas urxentes nalgún lugar profundo da infraestrutura, o equipo adecuado encargarase deles. Protexer os sistemas de tales fallos é unha cuestión totalmente separada (Trainer et al., sección sobre estratexias para minimizar as dependencias críticas).
Os síntomas non son tan variables
Richard Cook lémbranos que os sistemas complexos están cheos de fallos, deficiencias e problemas. Tentar enumerar todas as razóns posibles é unha tarefa de Sísifo. Tentas describir problemas, pero cambian todo o tempo. Cindy Sridharan cre que "os sistemas non teñen que estar en perfectas condicións cada segundo" e é mellor utilizar un enfoque máis humano ( (“Monitorización de sistemas distribuidos”), 7).
Evite as notificacións despois dun incidente
Normalmente, as notificacións de causas configúranse para corrixir incidencias. E estas notificacións limitadas sobre o feito do que pasou crean unha falsa sensación de seguridade, porque o sistema cada vez presenta novas formas de romper.
Non se deixe enganar polos avisos de causa. Mellor pensa:
- Por que a notificación baseada en síntomas non notou o problema?
- Sería útil mellorar o contexto para o usuario?
- Como se poden mellorar as ferramentas de seguimento para facer un diagnóstico máis rápido, en lugar de acumular notificacións sobre o que pasou?
As ferramentas de seguimento para o diagnóstico só axudarán se pensas nelas como unha forma de pasar do síntoma á solución. Sen estes comentarios, simplemente recibirás notificacións tardías e gráficos sobre fallos pasados, e nin unha palabra sobre os futuros. Esta é unha gran oportunidade para que unha organización pase da defensa ao ataque. E os desenvolvedores e xestores de produtos terán as mesmas expectativas e obxectivos claros. O caso - CASE (:wink:) - está claro para cada notificación.
As notificacións baseadas no motivo son tolerables con moderación
Ás veces, o noso sistema déixanos poucas opcións en canto ás notificacións baseadas en causas. E ás veces os de servizo entenden perfectamente que un síntoma definitivamente levará a un fracaso e, polo tanto, contén un valor práctico. Quizais non esteas seguro do que está a pasar e estás configurando notificacións para estar seguro. Esperemos que esta acción sexa temporal ata que poidamos cambiar o sistema para resolver o problema de rendemento.
Ten en conta os demais compoñentes de CASE cando trates con estas situacións. Só porque sexa temporal non significa que poidas deixar de pensar coa cabeza.
Avaliado - avaliación
Calquera cambio no sistema (novo código, nova infraestrutura, calquera cousa nova) amplía o abano de fallos (Cook, 3). Esta notificación segue funcionando como se esperaba? Modelos mentais claros e actuais de sistemas e experiencia respondendo a algunhas notificacións de soporte - Estas son as principais características . Os defectos dos sistemas están en constante evolución, e debemos estar ao día con eles.
Debe avaliar constantemente a calidade de cada notificación para asegurarse de que funcionan como se espera. Queridos líderes! Será moito máis doado para os teus equipos se lles axudas a establecer este proceso. Aquí tes algunhas ideas de avaliación:
- Usar , ou outros métodos de proba de notificación. O equipo pode facelo por si mesmo sen ter que depender dun pesado sistema de xestión de incidentes.
- Incorpore a colección de todas as notificacións relacionadas con incidentes no seu programa de xestión de incidentes. Marca útil, prexudicial, inadecuado, pouco claro, etc. Utilízaos como feedback.
- As notificacións correctas desenvólvense con pouca frecuencia e probáronse coidadosamente. Asegúrate de que todas as ligazóns funcionan, apuntan ao contexto correcto, etc.
- Se unha notificación nunca se dispara ou se dispara con demasiada frecuencia, hai algo mal nela. Reparalo ou eliminalo. Coidado coa pasividade ou actividade excesiva!
- Establece marcas de tempo de notificación con datas de caducidade. Se a data de caducidade caducou, avalía a notificación mediante o método CASE e actualiza a marca de tempo. Do mesmo xeito que a comida, comprobe regularmente a data de caducidade.
- Simplifica o proceso de mellora das notificacións. Usa a supervisión como código e almacena as notificacións nun repositorio de Git. As solicitudes de extracción axudan a involucrar o equipo e ofrecen un historial de notificacións pasadas. E xa non terás medo de cambiar as notificacións nin de pedir permiso aos responsables das mesmas.
- Configura comentarios para notificacións, aínda que sexa sinxelo , para que os axentes de servizo marquen as notificacións como inútiles ou intrusivas. Insire unha ligazón ou chamada á acción na propia notificación e revisa os teus comentarios regularmente.
- Establece unha regra no equipo: deixa que os de garda traballen para simplificar o deber cando hai pouco traballo. Que todo despois de ti sexa un pouco mellor que antes.
Conclusión
Creo que o método CASE axuda aos desenvolvedores e ás organizacións a discutir sobre a configuración e o envío de notificacións automáticas. Un programador pode comezar a avaliar as notificacións mediante o método CASE e, a continuación, toda a organización unirase a outros desenvolvedores, programas de xestión e xestión de incidentes para manter as notificacións en boa forma. Isto non require ferramentas especiais nin procesos complexos.
Toda a industria debe pensar no factor humano mentres está de servizo sen sacrificar o servizo ao cliente de primeira categoría. Todas estas ferramentas e prácticas poden e deben ser melloradas. Espero que o método CASE axude con isto.
Goza de notificacións melloradas!
Fonte: www.habr.com