Cada equipe está cuidando do status de seus serviços. Os serviços voltados para o cliente são impactados. Novas informações continuam fluindo de diferentes canais e o status da paralisação e os servidores continuam mudando.
Como fazer a lista do servidor afetada?
Como colocar tudo em um só lugar?
Como atribuir responsabilidade a cada um?
Qual é o status de cada servidor?
Como os clientes internos podem receber atualizações de status contínuas?
O que acontece se um servidor foi intencionalmente para baixo antes do incidente?
O que acontece se um problema mais complexo ocorrer e o tempo para lidar com isso demorar mais do que a própria paralisação?
Jeannette Walls disse : "A coisa mais importante na vida é aprender a cair" e, para ser honesto, durante os coronatimes todos nós precisamos de uma lição extra
Lidar com incidentes críticos é sempre uma coisa difícil de fazer. Trabalhar juntos no mesmo espaço (escritórios, lembra disso?) facilitou um pouco a comunicação. A fisicalidade, o fato de todos nós estarem no mesmo lugar e podemos apenas ver ou conversar facilmente, isso tudo fez uma enorme diferença. No tempo do COVID nos encontramos lutando para gerenciar comunicações tão fáceis, isso inibe diretamente nossa capacidade de gerenciar um incidente ainda mais. Tivemos que intensificar nosso jogo.
Nossa jornada começou há alguns meses, tivemos um incidente envolvendo vários servidores e a importância de trabalhar com um sistema central de gerenciamento de tarefas projetado para o gerenciamento de incidentes de TI foi cristalizada. Não é um console, nem o sistema central de alerta. Isso precisava ser uma ferramenta de gerenciamento de crises que aumentasse nossas habilidades em tempo real.
Nosso primeiro julgamento por fogo foi, bem, exatamente isso! Bombeiros invadiram um de nossos data centers. 1500 servidores físicos caíram nesse incidente (você pode ler sobre isso aqui). Durante esse dia conseguimos nos mobilizar mais rápido, responder de forma muito mais coordenada e trazer de volta os serviços mais rápido do que nunca.
PARTE 1: Diga a todos que algo muito ruim aconteceu
O primeiro desafio é garantir que quando algo ruim está acontecendo, todos que precisam saber – saberão (e rápido).
Sim, temos engenheiros de plantão e vários sistemas de alerta. Temos registros, métricas, painéis, pagers, você escolhe, nós temos. Além disso, criamos um serviço de base de regras agregada que monitora todos os tipos de fontes. Quando uma regra é combinada – um conjunto de ações pode ser acionado.
Por exemplo:
paginando vários usuários.
enviando notificações para vários canais.
iniciando uma teleconferência.
Iniciando o "fluxo de incidentes críticos"
PARTE 2: Para a Sala de Guerra
Alarme!
Alarme!
Todas as mãos no convés!
O sistema abre automaticamente a "Sala de Guerra", a placa de incidentes, onde os itens podem ser atribuídos aos engenheiros, a prioridade pode ser definida e o status pode ser atualizado.
Quando pensamos sobre este serviço, queríamos o seguinte:
Ele precisa conectar várias fontes e gerar itens acionáveis.
A interface do usuário tem que fornecer uma visão clara do incidente.
As diferentes partes do sistema devem incorporar ferramentas existentes como #Slack, PagerDurty, Zoom, Hashicorp Consul (para citar alguns).
Decidimos ir com Monday.com como nosso painel e motor de estado de lineitem.
O sistema deve ser fácil de construir, manter e pronto para uso em um curto período de tempo.
O serviço War Room é acionado e gera uma lista de itens, constrói um painel de segunda-feira personalizado e empurra os itens para dentro da placa – juntamente com status, prioridade e outras propriedades. O serviço da Sala de Guerra atualiza os itens do conselho continuamente até que o incidente seja resolvido.
Simples, mas não simplista.
Principais características
Múltiplas fontes
Coleta de dados de várias fontes – sistemas de gerenciamento de ativos, sistemas de alerta etc. e criação de uma lista detalhada de itens que contêm dispositivos físicos e virtuais, implantações, dados de manutenção e muito mais.
O serviço determina a prioridade de cada item e define-o de acordo.
Problemas existentes pré-incidente podem ser filtrados.
Quadro de segunda-feira
Para esta tarefa criamos uma biblioteca Python para segunda-feira para nos ajudar.
Implementamos alguns métodos como:
Placas (criar e arquivar).
Colunas (criar, definir valores).
Grupos (criar, buscar, arquivar).
Itens (buscar, criar, atualizar).
Subitens (criar).
Nós geramos o quadro certo para o incidente
População de itens
Uma vez que a lista de itens é gerada, nós empurramos para segunda-feira e continuamos gerenciando o estado do item para que possamos atualizá-lo em caso de qualquer alteração.
Mantenha as coisas atualizadas
Nós realmente gostamos de nossos dados atualizados. Então, nós nos certificamos de continuar atualizando cada item cada vez que detectamos uma mudança, para que nosso gerente de incidentes possa obter as chamadas certas
Notificações
As notificações são um componente importante do nosso serviço, precisamos realmente ter certeza de que podemos nos comunicar quando precisamos. As mensagens são empurradas automaticamente através de vários canais para facilitar a comunicação simplificada com vários outros clientes internos.
As notificações são enviadas quando o incidente começa ou termina e convidamos as pessoas para as placas e para uma teleconferência. Alterações de status acionam a notificação para proprietários e assinantes.
PARTE 3: Gerencie o incidente
O conselho foi criado e podemos começar a trabalhar.
Mudar a prioridade para onde é necessário
Atribuir /reatribuir o engenheiro certo para a tarefa certa
Obtenha um estado claro do incidente
PARTE 4: Após a tempestade
Uma lição deve ser aprendida
A maioria dos incidentes críticos requer um processo de aprendizagem de aulas para que possamos melhorar. Para ajudar nesta fase, podemos obter um cronograma claro com base no registro da placa. Então isso simplifica o processo de descoberta da linha do tempo, sabemos exatamente o que foi feito, quando e quem fez isso.
O efeito cascata – Acompanhamento dos itens
Muitas vezes, quando o evento principal acabar, todos nós só queremos continuar com os problemas menos urgentes quando o sol está fora. Esta é uma resposta natural quando você é puxado para uma situação de crise. Facilitando essa necessidade, os itens abertos permanecerão abertos após a resolução do incidente. Isso nos mantém no topo das questões menores e garante que o efeito cascata termina bem para todos os envolvidos.
Conclusões e o que você tira disso
Uma vez que o sistema estava online, não havia necessidade de convencer as pessoas a usá-lo, era tão claro quanto valor isso traz para todos que o utilizam. Semanas depois do lançamento e após o primeiro inciendet, o "buy-in" da organização foi impressionante. O sistema agora é usado por todas as equipes de produção voltadas para as equipes, SRE, PD e muito mais.
A automação no SRE é o único caminho. Não há outra maneira de gerenciar os níveis de tarefas e a necessidade de executar tarefas em grandes quantidades de servidores (ou instâncias) se você não tiver automação. Isso é o mesmo para a gestão de incidentes.
A confiabilidade quando violada é sempre um evento caótico. Dentro ou fora da nuvem você sempre precisa encontrar uma maneira de trazer ordem quando vários serviços ou servidores falham e saem de produção. Você precisa de uma maneira de trazer mais recursos SRE para corrigir o problema. A capacidade de multitarefa dos membros da equipe nas diferentes tarefas dentro de uma situação de alta pressão é uma grande vitória. A automação da sala de guerra era a nossa maneira de conseguir.
Melhorar as comunicações é sempre uma boa prática, quando ajuda a reduzir os prazos de incidentes que é ainda melhor.
O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.