Criar um processo colaborativo de gerenciamento de incidentes

Last reviewed 2023-08-08 UTC

Neste documento, o framework de arquitetura do Google Cloud fornece práticas recomendadas para gerenciar serviços e definir processos para responder a incidentes. Os incidentes ocorrem em todos os serviços. Portanto, você precisa de um processo bem documentado para responder de maneira eficiente a esses problemas e atenuá-los.

Visão geral do gerenciamento de incidente

É inevitável que seu sistema bem projetado acabe falhando em atender aos SLOs. Na ausência de um SLO, seus clientes definem vagamente qual é o nível de serviço aceitável da experiência anterior. Os clientes encaminham para seu suporte técnico ou grupo semelhante, independentemente do que está no SLA.

Para atender adequadamente seus clientes, estabeleça e teste regularmente um plano de gerenciamento de incidentes. O plano pode ser tão curto quanto uma lista de verificação de página única com dez itens. Esse processo ajuda a equipe a reduzir o tempo de detecção (TTD) e o tempo de mitigação (TTM).

O TTM é preferencial em vez do TTR, em que o R para reparo ou recuperação é usado com frequência para indicar uma correção completa em comparação com a mitigação. O TTM enfatiza a mitigação rápida para encerrar rapidamente o impacto do cliente sobre uma interrupção e, em seguida, inicia o processo muitas vezes mais longo para corrigir o problema por completo.

Um sistema bem projetado com operações excelentes aumenta o tempo entre falhas (TBF, na sigla em inglês). Em outras palavras, os princípios operacionais da confiabilidade, incluindo um bom gerenciamento de incidentes, visam reduzir as falhas com frequência.

Para executar serviços confiáveis, aplique as práticas recomendadas a seguir no processo de gerenciamento de incidentes.

Atribuir propriedade de serviço clara

Todos os serviços e as respectivas dependências críticas precisam ter proprietários claros responsáveis pela aderência aos SLOs. Se houver reorganizações ou desgaste de equipes, o lead de engenheiro deve garantir que a propriedade seja explicitamente entregue a uma nova equipe, juntamente com a documentação e o treinamento conforme necessário. Os proprietários de um serviço precisam ser facilmente detectáveis por outras equipes.

Reduzir o tempo de detecção (TTD) com alertas bem ajustados

Antes de reduzir o TTD, revise e implemente as recomendações no Incorporar a observabilidade na infraestrutura e em aplicativos e defina suas metas de confiabilidade seções da categoria de confiabilidade do framework de arquitetura. Por exemplo, elimine a ambiguidade entre problemas de aplicativos e de nuvem.

Um conjunto bem ajustado de SLIs alerta a equipe no momento certo sem sobrecarga de alertas. Para mais informações, consulte a seção Criar alertas eficientes da categoria de confiabilidade do framework de arquitetura ou Ajustar as métricas de SLI: lições de vida do CRE.

Reduzir o tempo de mitigação (TTM) com planos e treinamento de gerenciamento de incidentes.

Para reduzir o TTM, defina um plano de gerenciamento de incidentes documentado e bem treinado. Tenha dados disponíveis sobre o que mudou no ambiente. Certifique-se de que as equipes conheçam as mitigações genéricas que podem aplicar rapidamente para minimizar o TTM. Essas técnicas de mitigação incluem drenagem, reversão de alterações, aumento de recursos e degradação da qualidade do serviço.

Conforme discutido em outro documento da categoria de confiabilidade do Framework de arquitetura, crie processos e ferramentas operacionais confiáveis para oferecer suporte à reversão rápida e segura de alterações.

Projetar layouts e conteúdo de painel para minimizar o TTM

Organize o layout e a navegação do painel de serviços para que um operador possa determinar em um ou dois minutos se o serviço e todas as suas dependências críticas estão em execução. Para identificar rapidamente possíveis causas de problemas, os operadores precisam verificar todos os gráficos no painel para procurar rapidamente aqueles que mudam significativamente no momento do alerta.

A lista a seguir de gráficos de exemplo pode estar no painel para ajudar a resolver problemas. As pessoas que responderem a incidentes devem ser capazes de visualizá-los em um único lugar:

  • Indicadores de nível de serviço, como solicitações bem-sucedidas divididas pelo total de solicitações válidas
  • Configuração e lançamentos binários
  • Solicitações por segundo para o sistema
  • Respostas de erro por segundo do sistema
  • Solicitações por segundo do sistema para as dependências
  • Respostas de erro por segundo ao sistema a partir das dependências

Outros gráficos comuns para ajudar a resolver problemas incluem latência, saturação, tamanho da solicitação, tamanho da resposta, custo da consulta, uso do pool de linhas de execução e métricas da máquina virtual Java (JVM, na sigla em inglês), quando aplicável. Saturação refere-se à integridade por algum limite, como cota ou tamanho de memória do sistema. A utilização de pool de linhas de execução procura regressões devido ao esgotamento do pool.

Teste o posicionamento desses gráficos em alguns cenários de interrupção para garantir que os gráficos mais importantes estejam próximos ao topo e que a ordem dos gráficos corresponda ao fluxo de trabalho de diagnóstico padrão. Também é possível aplicar o machine learning e a detecção de anomalias estatísticas para encontrar o subconjunto certo desses gráficos.

Documente procedimentos de diagnóstico e mitigação de cenários de interrupção conhecido

Escreva manuais e crie um link para eles a partir das notificações de alerta. Se esses documentos estiverem acessíveis a partir das notificações de alerta, os operadores poderão obter rapidamente as informações necessárias para solucionar e mitigar problemas.

Use post mortems sem culpa para aprender com interrupções e evitar recorrências

Estabeleça uma cultura post mortem sem culpa e um processo de revisão de incidentes. Responsabilidade: significa que sua equipe avalia e documenta o que deu errado de maneira objetiva, sem a necessidade de atribuir a culpa.

Erros são oportunidades de aprendizado, não uma causa para críticas. Sempre tente tornar o sistema mais resiliente para que ele possa se recuperar rapidamente de erros humanos ou, melhor ainda, detectar e evitar erros humanos. Extraia o máximo possível de aprendizado de cada post mortem e faça um acompanhamento cuidadoso em cada item de ação post mortem para tornar as interrupções menos frequentes, aumentando assim o TBF.

Exemplo de plano de gerenciamento de incidentes

Foram detectados problemas de produção, por exemplo, por meio de um alerta ou uma página, ou encaminhados para mim:

  • Devo delegar para outra pessoa?
    • Sim, se você e sua equipe não conseguirem resolver esse problema.
  • Esse problema é uma violação de privacidade ou segurança?
    • Se sim, delegue à equipe de privacidade ou segurança.
  • Este problema é uma emergência ou os SLOs estão em risco?
    • Em caso de dúvida, trate como uma emergência.
  • Devo envolver mais pessoas?
    • Sim, se afetar mais de X% dos clientes ou se levar mais de Y minutos para resolver. Se estiver em dúvida, sempre envolva mais pessoas, especialmente durante o horário comercial.
  • Defina um canal principal de comunicação, como IRC, Hangouts Chat ou Slack.
  • Delegue papéis definidos anteriormente, como os seguintes:
    • Comandante do incidente que é responsável pela coordenação geral.
    • Líder de comunicações responsável por comunicações internas e externas
    • O líder de operações é responsável por mitigar o problema.
  • Defina quando o incidente termina. Esta decisão pode exigir uma confirmação de um representante de suporte ou de outras equipes semelhantes.
  • Colabore no post mortem sem culpa.
  • Participe de uma reunião de análise retrospectiva dos incidentes para discutir as ações necessárias da equipe.

Recomendações

Para aplicar a orientação no framework de arquitetura ao seu próprio ambiente, siga estas recomendações:

A seguir

Saiba mais sobre como criar um processo colaborativo de gerenciamento de incidentes com os seguintes recursos:

Explore outras categorias no Framework de arquitetura, como design do sistema, excelência operacional e segurança, privacidade e conformidade.