Dziiiiiiin! Às três da manhã, você assiste a um sonho maravilhoso e, de repente - um sino. Esta semana você está de plantão, e aparentemente algo aconteceu. Um sistema automatizado está ligando para descobrir qual é o problema. Este é um ponto importante no gerenciamento de sistemas de computadores modernos, mas vamos ver como tornar as notificações mais convenientes para as pessoas.
Familiarize-se com a filosofia de monitoramento que nasceu ao longo de várias décadas de minhas funções em várias equipes de monitoramento. Ela foi influenciada de várias maneiras pela verdadeira Bíblia de Rob Evashchuk, My Philosophy on Alerting , incluída no livro do Google SRE e pelo livro de John Alspo, Considerations for Alert Design .
Kelly Dunn , Aridzhit Mukheryi e Maxim Petazzoni - obrigado pela ajuda na edição do post.
O que é um CASO?
Decidi criar uma sigla bonita, como o método USE de Brendan Gregg ou o método RED de Tom Wilkie . Eu chamo isso de método CASE . Ele descreve quatro pontos nos quais você precisa prestar atenção ao trabalhar com o monitoramento automático:
Se você usa o CASE, trata as notificações com indiferença saudável e não acorda as pessoas à noite. O monitoramento deve ser avaliado regularmente quanto à utilidade e eficácia. Quando uma pessoa recebe uma notificação, ela terá melhores modelos mentais e mais confiança.
Para facilitar a lembrança, imagine que você precise de um CASE [isto é, um caso, o motivo é um comentário do intérprete ] para justificar todo alerta. : óculos de sol:
E por que isso é tudo?
O dever pode ser um tormento . Por muitas razões. E o CASE não eliminará todos eles. Mas com ele à noite, você acordará com notificações melhores. Este método abrange vários processos organizacionais que também ajudarão nesse assunto.
A beleza dos métodos RED e USE é que, com a ajuda deles, sabemos não apenas como trabalhar, mas também falamos o mesmo idioma. Espero que, com o método CASE, seja mais fácil discutir notificações que protegem nossos sistemas, mas não dê descanso aos colegas.
O ponto principal é que você precisa criar uma cultura na organização em que as notificações são tratadas com indiferença saudável. As notificações podem ser criadas no caso, mas não o fato de que elas não perderão valor posteriormente. Por que configuramos esta notificação? Seus critérios foram revisados há muito tempo? Com o CASE, essas perguntas podem ser respondidas.
Contexto-pesado - ligação de contexto
03:00 não é a melhor hora para ler mensagens com muitas chavões. Para responder de forma eficaz, você precisa de informações. Idealmente, essas devem ser informações sobre um problema específico, sobre o qual o contexto é imediatamente claro, e você precisa configurar as notificações para que isso seja possível. Estas são “observação” e “orientação” do ciclo NORD . Não é uma pena gastar tempo com essa configuração, porque distrair constantemente uma pessoa é ainda mais caro. Vamos nos respeitar.
Os problemas têm muitas fontes. Especialmente fantasmas.
Como ajudar o atendente? O oficial de serviço vê a notificação primeiro e cria todas as hipóteses com base nela. Em seguida, ele analisa as instruções e os painéis, mas sempre há informações sobre um aviso específico, e não apenas informações gerais? Alspo aconselha “pensar em como interpretar a notificação ou respondê-la” (slide 29) 1 . Uma boa notificação é focada no atendente e não apenas configurada em um valor limite.
Portanto, aqui estão algumas idéias para melhorar o contexto de notificação:
- Mostre ao usuário algo útil e criado especificamente, e não apenas instruções comuns ou um painel. Anteriormente, os caras e eu usamos painéis para investigar, configurados para notificações específicas. Isso ajudará se o problema for conhecido e apenas confundir em outros casos. Aqui você precisa encontrar um equilíbrio.
- Conte-nos sobre o histórico de notificações: é novo? Isso costuma funcionar? É sazonal?
- Mostrar alterações recentes no status do sistema. Alguma coisa mudou recentemente? (Por exemplo, implante ou ative / desative a funcionalidade.)
- Mostre o relacionamento e forneça informações para o modelo mental: as dependências do sistema devem ser claramente visíveis, de preferência com uma indicação de operacionalidade.
- Associe rapidamente o usuário à equipe: ele vê incidentes atuais ou pode descobrir quem mais na empresa recebeu a notificação? O programa de gerenciamento de incidentes está ativado?
Idealmente, um programa de gerenciamento de incidentes fornece dicas sobre como melhorar o contexto de notificação ao investigar incidentes. Sempre há algo para trabalhar!
Acionável - valor prático
O atendente deve fazer algo em resposta à notificação? Se nada precisa ser feito ou não está claro o que fazer, por que você foi despertado? É necessário evitar notificações que entrem em serviço e não exijam ação.
O que fazer? Do que você precisa?
Anteriormente, quando os sistemas eram simples e as equipes eram pequenas, configuramos o monitoramento para manter-nos atualizados. A notificação de que a carga no heap aumentou aumentará o contexto se o serviço não funcionar corretamente. Em larga escala, essas notificações apenas confundem, porque nossos sistemas sempre funcionam em um estado de degradação de severidade variável. Isso leva rapidamente ao cansaço das notificações e, é claro, à perda de sensibilidade. Portanto, o atendente ignora ou até filtra essas notificações e nem sempre responde a elas conforme necessário. Não caia nessa armadilha! Não configure todas as notificações em sequência, para que você possa enviá-las posteriormente por correio para alguma pasta esquecida por Deus.
Veja como é um aviso com valor prático:
- Uma notificação requer ação, não apenas a comunicação das notícias.
- Essa ação é difícil ou arriscada de automatizar. Se a ação puder ser automatizada, execute e automatize, pare de incomodar as pessoas!
- O aviso contém recomendações urgentes na forma de um contrato de nível de serviço (SLA) ou tempo de recuperação de destino (RTO). Em seguida, o atendente pode usar o programa de gerenciamento de incidentes na organização.
Quero esclarecer: não estou dizendo que as notificações devem vir apenas nos SLOs mais importantes (objetivos de nível de serviço, metas de nível de serviço) da API. O monitoramento SLO é constantemente fragmentado e dividido e requer a mesma abordagem para todos os serviços. É claro que você acompanhará os SLOs mais importantes para os clientes que lhe pagam. Mas as infraestruturas SLO, como bancos de dados, também precisam ser monitoradas. Em breve, você terá que lidar com clientes internos e apoiá-los. E assim por diante ad infinitum.
Baseado em sintomas - foco nos sintomas
Quer você goste ou não, você trabalha em um sistema distribuído (Kavaj) 2 . Como resultado, você usa táticas diferentes para isolar serviços e protegê-los de falhas (Trainor et al.) 3. E embora uma coleta de lixo prolongada ou uma consulta cuidadosa ao banco de dados indique problemas, não há necessidade de se apressar para corrigi-los se os usuários não tiverem problemas no futuro próximo.
Esses são sinais importantes e podem ter um valor prático, mas se não interferem nos usuários, isso não é tão urgente que distraia o atendente. As notificações baseadas em causas são instantâneos de nossos modelos mentais de falha do sistema. É melhor acompanhar os sintomas importantes do que tentar listar todas as possíveis causas de uma falha.
Para que as notificações tenham valor prático, foque nos indicadores de desempenho que são importantes para os usuários. Evashchuk chama isso de "monitoramento para usuários". Lembre-se de que essa filosofia precisa ser aplicada em toda a organização. Se o serviço tiver problemas urgentes em algum lugar profundo da infraestrutura, a equipe apropriada lidará com eles. Proteger os sistemas de tais falhas é uma questão completamente separada (Trainer et al., Uma seção sobre estratégias para minimizar dependências críticas) 3 .
Os sintomas não são tão voláteis
Richard Cook lembra que em sistemas complexos existem muitas falhas, deficiências e problemas 4 . Tentando listar todas as causas possíveis - trabalho sísifo. Você tenta descrever os problemas, e eles mudam o tempo todo. Cindy Sridharan acredita que “os sistemas não precisam estar em perfeitas condições a cada segundo” e é melhor usar uma abordagem mais humana ( “Observabilidade de Sistemas Distribuídos” , 7) 5 .
Evitar notificações de incidentes
Normalmente, as notificações por motivos são configuradas para corrigir incidentes. E essas notificações limitadas sobre o fato do que aconteceu criam um falso senso de confiança, porque toda vez que o sistema cria novas maneiras de quebrar.
Não se deixe enganar por notificações de motivos. Pense melhor:
- Por que a notificação baseada em sintomas não notou o problema?
- Seria útil melhorar o contexto para o usuário?
- Como melhorar as ferramentas de monitoramento para diagnosticar mais rapidamente e não acumular notificações sobre o que aconteceu?
As ferramentas de monitoramento para diagnóstico só ajudarão se você as usar como uma maneira de passar de um sintoma para uma solução. Sem esse feedback, você simplesmente ficará sobrecarregado com notificações e diagramas tardios sobre falhas passadas - e nem uma palavra sobre futuras. Para uma organização, essa é uma ótima oportunidade de ir da defesa ao ataque. E desenvolvedores e gerentes de produto terão as mesmas expectativas e objetivos claros. Case - CASE (: wink :) - para cada notificação é clara.
Notificações moderadas baseadas em tolerância
Às vezes, nosso sistema quase não nos deixa escolha em termos de notificações com base no motivo. E, às vezes, os atendentes estão bem cientes de que um sintoma necessariamente leva a um mau funcionamento, o que significa que ele contém valor prático. Talvez você não tenha certeza do que está acontecendo e esteja configurando notificações para resseguro. Vamos esperar que essa ação seja necessária temporariamente até que alteremos o sistema para resolver o problema de degradação do desempenho.
Esteja ciente de outros componentes CASE ao lidar com essas situações. Se isso é temporário, isso não significa que você não pode pensar com sua cabeça.
Avaliado - Classificação
Quaisquer alterações no sistema (novo código, nova infraestrutura, qualquer coisa nova) expandem a gama de falhas (Cook, 3). 4 Esta notificação ainda funciona conforme o esperado? Modelos claros e relevantes de sistemas mentais e experiência em responder a algumas notificações em apoio a uma abordagem preventiva são os principais recursos de uma organização orientada para a aprendizagem . Defeitos nos sistemas estão em constante evolução, e devemos acompanhá-los.
Você precisa avaliar constantemente a qualidade de cada notificação para que funcionem conforme o esperado. Caros líderes! Será muito mais fácil para suas equipes se você as ajudar a configurar esse processo! Aqui estão algumas idéias para avaliar:
- Use engenharia do caos , dias de jogos ou outros métodos de teste de notificação. A equipe pode fazer isso sozinha sem usar um sistema de gerenciamento de incidentes pesado!
- Inclua a coleta de dados em todas as notificações de incidentes no programa de gerenciamento de incidentes. Marque útil, prejudicial, inadequado, incompreensível, etc. Use-os como um feedback.
- As notificações corretas não são frequentes e são cuidadosamente verificadas. Verifique se todos os links funcionam, aponte para o contexto certo e assim por diante.
- Se a notificação nunca disparar ou disparar com muita frequência, algo está errado com ela. Repare ou remova-o. Cuidado com passividade excessiva ou atividade!
- Defina os carimbos de data e hora de expiração para notificações. Se a data de validade expirou, avalie o aviso usando o método CASE e atualize o carimbo de data / hora. Verifique regularmente a data de validade, como acontece com os alimentos.
- Simplifique o processo de melhoria das notificações. Use o monitoramento na forma de código e armazene as notificações no repositório Git. As solicitações de pool ajudam a atrair uma equipe e você terá um histórico de notificações anteriores. E você deixará de ter medo de alterar as notificações ou pedir permissão aos responsáveis por elas.
- Configure notificações de feedback, mesmo que seja apenas um formulário do Google , para que as pessoas de plantão marquem as notificações como inúteis ou intrusivas. Incorpore um link ou apelo à ação na própria notificação e verifique regularmente o feedback.
- Estabeleça uma regra na equipe - deixe os atendentes trabalharem para simplificar o dever quando houver pouco trabalho. Deixe tudo ficar um pouco melhor depois de você do que era antes.
Conclusão
Acredito que o método CASE ajude desenvolvedores e organizações a discutir a configuração e o envio de notificações automáticas. Um desenvolvedor pode começar a avaliar as notificações usando o método CASE e, em seguida, toda a organização se juntará a ele com outros desenvolvedores, programas de gerenciamento e gerenciamento de incidentes para manter as notificações em boas condições. Não são necessárias ferramentas especiais ou processos complexos para isso.
Toda a indústria deve pensar no fator humano em serviço, sem comprometer o atendimento ao cliente de primeira classe. Todas essas ferramentas e práticas podem e devem ser aprimoradas. Espero que o método CASE ajude com isso.
Desfrute de notificações aprimoradas!
