Você olha para o relógio, vários pensamentos passando por sua cabeça. Por que eu? Porque agora? Qual foi o último resultado do teste de invasão? Como você leva a equipe para fora desta catástrofe de TI e sobrevive para contar sobre ela? Esta é minha história, minha luta pessoal com as “leis Murphy” da TI e como todos podemos nos beneficiar disso.
Era uma segunda-feira, com a qual você sabe que precisa ser extremamente cuidadoso. É sempre o início de semana de trabalho ou bem no meio da noite. (Nenhuma catástrofe de TI acontece quando é conveniente para você, certo? Eles sempre se agrupam e se aglomeram nos momentos mais difíceis.) De qualquer forma, é segunda-feira o fim do dia e vários sistemas simplesmente escurecem. Você obtém aquele toque específico que configurou para o PagerDuty e ele simplesmente não para de tocar. Você sente '"A sensação”. Você sabe que está se conectando a uma situação ruim. Ah, e ele já está no meio do seu limite (como é o caso também do Covid-19) e as coisas estão difíceis.
Conectando-se à VPN (suspiro de alívio, a solução VPN dupla em 2 centros de dados diferentes está funcionando) e os painéis básicos mostram que os serviços front-end estão operacionais, mas o procedimento de sala de guerra foi acionado. Isso significa que o monitoramento definido para um evento de tempo de inatividade em grande escala foi correspondido. Enquanto você está se conectando à video chamada, você recebe a seguinte mensagem no canal do grupo de trabalho para incidentes de produção - “Não há energia no data center de back-end”. Agora tudo começa a cair no lugar, os vários alertas, os serviços que estão fora do ar e todas as possíveis coisas ruins que ainda estão por vir. Espere, mais uma coisa chama sua atenção. É a mensagem direta do grupo de logística do data center no telefone. Agora, você já sabe que não há energia, então esta mensagem agora é uma prioridade mais alta do que outras e você abre esse tópico: há algum texto e uma imagem. Pulando o texto, você abre a imagem e vê que os bombeiros estão no data center. Muitas coisas passam pela sua mente, mas pelo menos não tem mangueiras e você não vê água em lugar nenhum da imagem.
Gerente de crise
Em primeiro lugar, sou o gerente de crise, portanto, obter informações e priorizar ações é meu trabalho. Eu diria algo como “Aviar, Navegar, Comunicar”, apenas para IT / SRE, mas não encontrei a sigla mágica que funciona para mim. Então, o que é importante ao gerenciar um incidente de TI em grande escala que pode evoluir para um tempo de inatividade total dos negócios ?:
Quais serviços são afetados?
Qual é o motivo da interrupção do serviço?
Qual é o impacto comercial de cada interrupção do serviço? (para priorizar as próximas etapas)
Temos um plano para consertá-lo (cada interrupção que você identificar)?
Qual é a melhor maneira de comunicar à organização (e aos clientes, se necessário) o que sabemos e o que esperar?
As prioridades
Agora, nossa maior prioridade é a segurança e a vida humana. Isso pode soar pretensioso, pois somos uma empresa de software e não gerenciamos sistemas de suporte de vida, mas operamos centros de dados e são locais de alta energia com riscos de incêndio e sistemas de supressão de incêndio que não são amigáveis aos humanos. Portanto, quando ficar claro que todos estão seguros e a equipe do data center não está em risco, nossa próxima prioridade é colocar os serviços de impacto comercial novamente online. Seja por meio do plano de DR ou apenas pela força bruta em meio aos desafios, é claro que há muito trabalho pela frente. Desde certificar-se de que temos forças-tarefa trabalhando nos problemas certos (são duas questões para gerenciar, montar a força-tarefa e priorizar as tarefas) para garantir que a consciência situacional seja a mais completa possível.
Antes de mergulhar no plano de jogo e neste incidente específico, é importante entender a regra do gerente de crise. O que essa pessoa faz e por que precisamos dessa pessoa sem mãos no teclado no teclado. Os engenheiros e cientista são mais do que capazes de resolver problemas, problemas complexos, especialmente se fizerem parte da equipe que está escrevendo o código. Nos últimos anos, com o movimento DevOps, tornou-se cada vez mais aceitável ter codificadores disponíveis e não apenas a equipe SRE. Algo parecido com “você construiu, é sua responsabilidade mantê-lo operacional”. Os cientistas, engenheiros (e especificamente os programadores entre eles) agora também fazem parte da equipe que garante que os serviços estejam funcionando. Ter pessoas de origens diferentes, equipes diferentes e abordagens diferentes para a resolução de problemas é ótimo! Também é um desafio. Resolver problemas na produção é muito diferente de trabalhar em um projeto. A pressão de tempo, as necessidades de SLA, as comunicações com a empresa e os diferentes grupos trabalhando para resolver o incidente agora também são fatores para fazer as coisas acontecerem. É por isso que você quer um gerente de crise. Depois de cruzar algum limite de escala (cada organização precisa definir esse limite), você deseja ter essa posição bem definida, para ajudar a direcionar o esforço de trabalho e trazer o problema para uma resolução rápida.
Os problemas de TI não são novidade. Até mesmo o termo “insetos” remonta à contra-almirante Grace Hopper dos anos 50 e às missões Apollo e outros lugares há mais de 50 anos. Com o surgimento do comércio eletrônico e dos serviços de Internet, o domínio do gerenciamento de serviços passou do trabalho de poucos para uma necessidade comercial que agora atinge quase todos os negócios. Encontrar estruturas ou metodologias de solução de incidentes de TI está bem documentado no ITSM, ITIL e outros padrões. Um que achei fácil de usar para os não iniciados está aqui (obrigado Atlassian pela publicação). Em nossa organização de TI, a regra dos gerentes de incidentes não é definida, mas definida no momento com base na disponibilidade do pessoal de plantão. Dito isso, temos uma pequena lista de pessoas de plantão que podem atuar nessa capacidade.
Resolvendo o problema
Voltando ao nosso incidente, então os bombeiros estão no local, já está claro que não temos energia. A lista de serviços afetados é quase sempre bem definida (eu escrevo principalmente, pois os serviços que executaram failover para DR podem não estar se mantendo ao longo do tempo). Já temos uma sala de guerra no grupo de trabalho aberta e ativa e meu primeiro movimento como gerente de incidentes é digitar mensagens no canal relevante. Essa escolha é motivada por dois fatores: a necessidade de se comunicar o máximo possível na organização e a necessidade de atrair mais pessoas, mesmo que elas não estejam de plantão (também conhecido como - todos no convés). Em seguida, precisamos definir as prioridades de acordo com as necessidades do negócio. Isso é muito específico para cada negócio, portanto, vou compartilhar em linhas gerais que as necessidades vêm de SLAs, custo, processamento on-line e off-line. Então, embora o sistema de faturamento ou sistemas de backup sejam super importantes,
Qual é o próximo passo? Definir as equipes da força-tarefa para as tarefas priorizadas e entender se há recursos compartilhados entre eles, ou seja, se alguma força-tarefa precisa de um recurso que está em uso por outra (pode definitivamente ser pessoas, pois habilidades de rede são necessárias ou o equipe de logística do data center é convocada para ações físicas). Enquanto trabalho nas alocações de recursos da força-tarefa, certifico-me de documentar tudo nos canais da equipe, para que fique claro para qualquer pessoa da organização quem está trabalhando em quê. A ideia principal aqui é que cada força-tarefa precisa ter alguma interação com a empresa para garantir que o conhecimento da situação seja preciso. Enquanto as equipes entram em ação (de preferência em outras vídeos chamadas), uma pessoa de cada força-tarefa atua como a ligação para a sala de guerra principal.
Enquanto estamos terminando nossa execução de DR e trazendo os serviços de volta, a energia é restaurada no data center e agora temos novos caminhos de ação abertos para nós. Deixamos o site de DR como o site principal no fim de semana ou voltamos para o site principal? A situação ideal seria apenas configurar o site principal como o novo DR e certificar-se de que os sistemas estão online e operacionais. Além disso, certifique-se de que os serviços de menor prioridade estejam online novamente.
Superando uma crise
Há muitos detalhes, muito trabalho e uma parte disso é apenas o início. Garantir que as longas horas de vídeo chamadas, perguntando às pessoas o que pode e deve ser feito, não sejam esquecidas. Certifique-se de que está tudo documentado e enquanto as pessoas falam, você digita febrilmente no teclado para que outras pessoas saibam o que está acontecendo. No entanto, ele se resume a areia. A capacidade de continuar enquanto o caminho para a disponibilidade do serviço nem sempre está claro. Sim, você deve sempre ter um plano, um DR, uma cultura de engenharia do caos, a capacidade de falhar parcialmente e não ter todos os serviços quebrando quando algo não está funcionando. No entanto, nem sempre é esse o caso. E ainda há Murphy: qualquer bom plano ou sistema bem documentado sempre terá algumas maneiras novas e inexploradas de falhar. É nesse ponto que você precisa ter certeza de que a linguagem de gerenciamento de incidentes de TI é clara. Que haja vocabulário para falar sobre impactos nos negócios, tempo para resolver, forças-tarefa, contato de comunicação e documentação meticulosa. Se isso não ajudar a resolver o problema mais rápido, com certeza o ajudará a aprender como fazer isso da próxima vez. Sempre existe a próxima vez.
Essa próxima vez é algo para o qual você precisa se preparar. Quando passamos por uma crise de TI, especialmente se foi “artificial” (como a maioria deles), é importante aprender com esse erro. Em uma citação atribuída a Winston Churchill “Nunca deixe uma boa crise ir para o lixo”, você pode encontrar a personificação da ideia por trás de uma autópsia. Ou seja, se você já perseverou, sofreu as dificuldades e consertou alguma coisa, use isso para melhorar. Caso contrário, você estará agravando as perdas com a crise. Você não apenas perde receita ou confiança do cliente, mas também perde uma oportunidade de aprendizado e aumenta as chances de o mesmo problema acontecer novamente.
Nosso data center não pegou fogo. A fiação defeituosa em nosso sistema de supressão de incêndio acionou o alarme de incêndio que, por sua vez, cortou a energia e explodiu o circuito elétrico "ofensivo" com um agente de supressão. É por sua vez chamamos os bombeiros que apurou a duração do apagão do data center os bombeiros se certificaram de que a qualidade do ar tinha voltado ao normal, entendendo que o sistema de backup de supressão de incêndio está à altura da tarefa para o retorno às operações normais). Eu só posso imaginar qual foi minha reação quando vi aquelas fotos dos bombeiros, meu foco no gerenciamento de incidentes foi tão intenso, eu só me lembro do mundo desacelerando para que eu tivesse todas as equipes da força-tarefa alinhadas e a sensação de adrenalina correndo por todos nós na tentativa de manter todos os sistemas críticos de negócios em funcionamento.
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.
