Dziiiiin! São 3 da manhã, você está tendo um sonho maravilhoso e de repente recebe uma ligação. Você está de plantão esta semana e aparentemente algo aconteceu. O sistema automatizado liga para descobrir o que há de errado. Este é um aspecto importante do gerenciamento de sistemas de computadores modernos, mas vamos ver como tornar as notificações melhores para as pessoas.
Conhecer a filosofia de monitorização, nascida ao longo de várias décadas das minhas funções em diferentes equipas de monitorização. Ela foi amplamente influenciada pela Bíblia real de Rob Evashchuk (Minha Filosofia de Notificação) incluída no livro sobre e livro de John Alspaugh (Notas sobre a configuração de alertas).
, и - obrigado pela sua ajuda na edição da postagem.
O que é CASO?
Eu decidi criar uma abreviatura bonita como ou . eu chamo isso Método CASO. Ele descreve quatro pontos a serem observados ao trabalhar com monitoramento automático:
- (vinculado ao contexto)
- (valor prático)
- (ênfase nos sintomas)
- (nota)
Se você usa CASE, você trata as notificações com uma 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 receber a notificação, ela terá melhores modelos mentais e mais confiança.
Para facilitar a lembrança, imagine que você precisa de um CASO [isto é, um caso, uma razão - nota do tradutor] para justificar cada alerta. :oculos de sol:
E por que tudo isso?
. Por muitas razões. E o CASE não eliminará todos eles. Mas com ele você acordará à noite com notificações melhores. Este método abrange diversos processos organizacionais que também ajudarão nesta questão.
A beleza dos métodos RED e USE é que com a ajuda deles não só sabemos trabalhar, mas também falamos a mesma língua uns com os outros. Minha esperança é que o método CASE facilite a discussão de notificações que protegem nossos sistemas, mas mantêm nossos colegas ocupados.
A questão é que você precisa criar uma cultura em sua organização onde as notificações sejam tratadas com uma indiferença saudável. As notificações podem ser criadas para uma finalidade específica, mas não é fato que não perderão valor posteriormente. Por que configuramos esta notificação? Há quanto tempo seus critérios foram revisados? Com CASE, essas perguntas podem ser respondidas.
Contexto pesado - vinculação de contexto
3 da manhã não é o melhor horário para ler mensagens que contenham muitas palavras inteligentes. Para responder de forma eficaz, você precisa de informações. O ideal é que sejam informações sobre um assunto específico, cujo contexto seja imediatamente claro, e as notificações devem ser configuradas para que isso seja possível. Isto é "observação" e "orientação" de . Não é uma pena perder tempo nessa configuração, porque distrair constantemente uma pessoa sai ainda mais caro. Vamos nos respeitar.
Os problemas têm muitas fontes. Principalmente fantasmas.
Como posso ajudar o oficial de plantão? A primeira coisa que o oficial de plantão vê é uma notificação, então ele constrói todas as hipóteses com base nela. Em seguida, ele analisa as instruções e os painéis, mas sempre há dados sobre uma notificação específica, e não apenas informações gerais? Alspaugh aconselha “pensar em como você pode interpretar ou responder à notificação” (slide 29). Uma boa notificação é focada no plantonista e não apenas configurada por um limite.
Então aqui estão algumas ideias sobre como melhorar o contexto de notificação:
- Mostre ao usuário algo útil e especialmente criado, e não apenas instruções comuns ou um painel. Anteriormente, eu e o pessoal usávamos painéis investigativos configurados para notificações específicas. Isso ajudará se o problema for conhecido, mas apenas confundirá outras pessoas. Precisamos encontrar um equilíbrio aqui.
- Conte-nos sobre a história da notificação: é nova? Funciona com frequência? É sazonal?
- Mostrar alterações recentes no estado do sistema. Alguma coisa mudou recentemente? (Por exemplo, implantação ou ativação/desativação de funcionalidade.)
- Mostre os relacionamentos e forneça informações para o modelo mental: as dependências do sistema devem estar claramente visíveis, de preferência com indicação de funcionalidade.
- Conecte rapidamente o usuário à equipe: eles podem ver os incidentes em andamento ou descobrir quem mais na empresa recebeu uma notificação? Programa ativado?
Idealmente, um programa de gestão de incidentes fornecerá conselhos sobre como melhorar o contexto de notificação das investigações de incidentes. Sempre há algo para trabalhar!
Acionável - valor prático
O oficial de serviço deve fazer algo em resposta à notificação? Se você não precisa fazer nada ou não está claro o que fazer, por que você o acordou? É preciso evitar notificações que incomodem os plantonistas e não exijam ação.
O que devo fazer? O que você quer?
No passado, quando os sistemas eram simples e as equipes pequenas, configuramos o monitoramento apenas para ficar por dentro de tudo. A notificação de que a carga no heap aumentou nos dará contexto se o serviço apresentar mau funcionamento posteriormente. Em grande escala, tais notificações apenas criarão confusão porque os nossos sistemas estão sempre a funcionar num estado de degradação de gravidade variável. Isto leva rapidamente a e, claro, à perda de sensibilidade. Portanto, o plantonista ignora ou até mesmo filtra tais notificações e nem sempre as responde conforme necessário. Não caia nesta armadilha! Não configure todas as notificações seguidas e depois envie-as por e-mail para alguma pasta esquecida.
Esta é a aparência de um aviso com valor prático:
- Uma notificação requer ação, em vez de simplesmente relatar notícias.
- Esta ação é difícil ou arriscada de automatizar. Se uma ação pode ser automatizada, então automatize-a, pare de incomodar as pessoas!
- O aviso contém recomendações urgentes no formato (SLA) ou (RTO). O oficial de serviço pode então ativar o programa de gerenciamento de incidentes da organização.
Quero esclarecer: não estou dizendo que as notificações devem vir apenas para os SLOs (objetivos de nível de serviço) mais importantes da API. O monitoramento do SLO é constantemente fragmentado e dividido e exige a mesma abordagem para todos os serviços. É claro que você acompanhará os SLOs mais importantes para os clientes que pagam a você. Mas os SLOs de infraestrutura, como bancos de dados, também precisam ser monitorados. Em breve você terá que lidar com clientes internos e apoiá-los. E assim por diante, ad infinitum.
Baseado em sintomas - ênfase nos sintomas
Quer você goste ou não, você está trabalhando em um sistema distribuído (Kavaj). Como resultado, você usa diferentes táticas para isolar os serviços e protegê-los contra falhas (Trainor et al.)3. E embora uma coleta de lixo atrasada ou uma consulta de banco de dados paralisada indiquem problemas, não há necessidade de pressa para corrigi-los se os usuários não tiverem problemas no futuro próximo.
Estes são sinais importantes e podem ter valor prático, mas se não perturbarem os utilizadores, então não são urgentes o suficiente para distrair o atendente. Notificações baseadas em causas são instantâneos de nossos modelos mentais sobre uma falha no sistema. É melhor monitorar sintomas importantes do que tentar listar todas as possíveis causas de uma falha.
Para tornar as notificações significativas, concentre-se em , importante para os usuários. Evashchuk chama isso de “monitoramento para usuários”. Lembre-se que esta filosofia deve ser aplicada em toda a organização. Se um serviço tiver problemas urgentes em algum lugar profundo da infraestrutura, a equipe apropriada cuidará deles. Proteger os sistemas contra tais falhas é uma questão totalmente separada (Trainer et al., seção sobre estratégias para minimizar dependências críticas).
Os sintomas não são tão variáveis
Richard Cook nos lembra que sistemas complexos estão cheios de falhas, deficiências e problemas. Tentar listar todos os motivos possíveis é uma tarefa de Sísifo. Você tenta descrever os problemas, mas 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 ( (“Monitoramento de Sistemas Distribuídos”), 7).
Evite notificações após um incidente
Normalmente, as notificações de causas são configuradas para corrigir incidentes. E essas notificações limitadas sobre o ocorrido criam uma falsa sensação de segurança, pois o sistema sempre surge com novas formas de quebrar.
Não se deixe enganar por avisos de causa. Melhor pensar:
- Por que a notificação baseada em sintomas não percebeu o problema?
- Seria útil melhorar o contexto para o usuário?
- Como melhorar as ferramentas de monitoramento para fazer um diagnóstico mais rápido, em vez de acumular notificações sobre o ocorrido?
As ferramentas de monitoramento para diagnóstico só ajudarão se você pensar nelas como uma forma de passar do sintoma à solução. Sem esse feedback, você será simplesmente bombardeado com notificações e gráficos tardios sobre falhas passadas – e nem uma palavra sobre falhas futuras. Esta é uma grande oportunidade para uma organização passar da defesa ao ataque. E os desenvolvedores e gerentes de produto terão as mesmas expectativas e objetivos claros. O caso - CASE (:wink:) - é claro para cada notificação.
Notificações baseadas em motivos são toleráveis com moderação
Às vezes, nosso sistema nos deixa poucas opções em termos de notificações baseadas em causas. E às vezes os plantonistas entendem perfeitamente que um sintoma certamente levará ao fracasso e, portanto, contém valor prático. Talvez você simplesmente não tenha certeza do que está acontecendo e esteja configurando notificações para garantir a segurança. Esperamos que esta ação seja temporária até que possamos alterar o sistema para resolver o problema de desempenho.
Tenha em mente os outros componentes do CASE ao lidar com essas situações. Só porque é temporário não significa que você pode parar de pensar com a cabeça.
Avaliado - avaliação
Quaisquer alterações no sistema (novo código, nova infraestrutura, qualquer coisa nova) ampliam o leque de falhas (Cook, 3). Esta notificação ainda está funcionando conforme o esperado? Modelos mentais claros e atuais de sistemas e experiência em resposta a algumas notificações de suporte - estes são os principais recursos . Os defeitos nos sistemas estão em constante evolução e devemos acompanhá-los.
Você precisa avaliar constantemente a qualidade de cada notificação para garantir que funcionem conforme o esperado. Queridos líderes! Será muito mais fácil para suas equipes se você as ajudar a estabelecer esse processo! Aqui estão algumas ideias de avaliação:
- Usar , ou outros métodos de teste de notificação. A equipe pode fazer isso sozinha, sem precisar depender de um sistema pesado de gerenciamento de incidentes!
- Incorpore a coleta de todas as notificações relacionadas a incidentes em seu programa de gerenciamento de incidentes. Marque como úteis, prejudiciais, inadequados, pouco claros, etc. Use-os como feedback.
- As notificações corretas são acionadas com pouca frequência e são cuidadosamente testadas. Certifique-se de que todos os links funcionem, apontem para o contexto correto, etc.
- Se uma notificação nunca dispara ou dispara com muita frequência, há algo errado com ela. Corrija-o ou remova-o. Cuidado com a passividade ou atividade excessiva!
- Defina carimbos de data/hora de notificação com datas de expiração. Se a data de expiração expirou, avalie a notificação usando o método CASE e atualize o carimbo de data/hora. Assim como os alimentos, verifique regularmente a data de validade.
- Simplifique o processo de melhoria das notificações. Use o monitoramento como código e armazene notificações em um repositório Git. As solicitações pull ajudam a envolver a equipe e fornecem um histórico de notificações anteriores. E você não terá mais medo de alterar notificações ou pedir permissão aos responsáveis por elas.
- Configure feedback para notificações, mesmo que seja simples , para que os oficiais de serviço marquem as notificações como inúteis ou intrusivas. Incorpore um link ou frase de chamariz na própria notificação e revise seus comentários regularmente.
- Estabeleça uma regra na equipe - deixe os plantonistas trabalharem para simplificar o plantão quando há pouco trabalho. Que tudo depois de você seja um pouco melhor do que era antes.
Conclusão
Acredito que o método CASE ajuda desenvolvedores e organizações a discutir a configuração e o envio de notificações automatizadas. Um desenvolvedor pode começar a avaliar notificações usando o método CASE e, em seguida, toda a organização se juntará a outros desenvolvedores, gerenciamento e programas de gerenciamento de incidentes para manter as notificações em boa forma. Isto não requer ferramentas especiais ou processos complexos.
Toda a indústria precisa pensar no fator humano durante o serviço, sem sacrificar o atendimento ao cliente de alto nível. Todas estas ferramentas e práticas podem e devem ser melhoradas. Espero que o método CASE ajude com isso.
Aproveite notificações aprimoradas!
Fonte: habr.com