Controlo de incidentes
Os incidentes têm um ciclo de vida. Para responder de forma mais eficaz, você precisa ser capaz de acompanhar a evolução do incidente em si, e a evolução da sua resposta a ele, desde o início desse ciclo de vida.
Avaliar o seu conhecimento
Uma boa maneira de avaliar seu procedimento de rastreamento de incidentes usando um incidente específico é fazer a si mesmo uma série de perguntas:
- Quando soube do problema? Se o seu objetivo é reduzir o tempo que a recuperação de incidentes demora, é necessário começar a capturar informações a partir do momento em que se apercebe dos problemas.
- Como descobriu o problema? O seu sistema de monitorização alertou-o sobre o incidente? Teve conhecimento através das queixas dos seus clientes, diretamente ou nas redes sociais?
- Se você está apenas descobrindo o problema, você é o primeiro a saber? Em caso afirmativo, quem é preciso notificar? Em caso negativo, quem mais está ciente do problema?
- Se existem outras pessoas cientes, o que está a ser feito (se algo estiver a ser feito) em relação ao problema? Estão todos a assumir que alguém está a tratar do problema ou alguém começou a tomar medidas para o resolver?
- Quão grave é? Podemos não ter qualquer noção de gravidade ou impacto, e não há lugar para descobrirmos o quão ruim o problema realmente é e quem é afetado.
Estas podem ser perguntas difíceis de responder, se nada estiver a ser controlado.
Uniformize o local onde as informações dos incidentes serão controladas
Existem muitos locais possíveis nos quais pode guardar e partilhar a sua lista de incidentes (ativos ou não) e todas as informações atuais sobre esses incidentes. Estes podem ser tão simples como uma área de ficheiros partilhada com documentos do Word e tão complexos como software e serviços altamente especializados de rastreio de incidentes. Entre esses dois extremos estão os sistemas de emissão de tíquetes e rastreamento de trabalho que você pode pressionar em serviço para essa tarefa. O sistema que escolher é, na verdade, menos importante do que a forma como o utiliza. Não importa qual sistema você usa, todos que possam ter alguma conexão com incidentes (engenheiros, suporte ao cliente, gerenciamento, relações públicas, jurídico e assim por diante) precisam saber onde encontrar o sistema, como levantar um incidente e como acessar os dados quando apropriado. Uma forma certa de falhar no controlo de incidentes é quando as pessoas a que o sistema fornece suporte não sabem como aceder ao mesmo ("Qual é o URL do nosso sistema?") quando precisam.
Neste módulo, usaremos a funcionalidade de item de trabalho do Azure DevOps para nosso sistema de rastreamento de exemplo.
Criar uma bridge de conversação
Para responder a algumas das perguntas da seção Avaliar o que você sabe e iniciar o processo de resposta a incidentes, você deve ter uma maneira de se comunicar com outras pessoas sobre o incidente. Idealmente, este será algum tipo de meio eletrônico de "colaboração em equipe" para conversação, embora as pontes telefônicas também funcionem. Teleconferências/pontes telefônicas são menos preferidas, porque é mais difícil revisar retroativamente a comunicação do incidente (daí o papel "Scribe" mencionado anteriormente).
Seja qual for o meio escolhido, você deve ter certeza de criar um canal exclusivo que seja estritamente limitado à discussão sobre esse incidente e nada mais. É importante manter as discussões irrelevantes fora deste canal, uma vez que tem de conseguir localizar os dados e analisá-los mais tarde na sua análise pós-incidente.
Neste módulo, usaremos o Microsoft Teams como nosso método de comunicação de incidentes.
Automatize o lançamento do controlo de incidentes
Vamos rever as partes que reunimos até agora. Temos:
- Lista das pessoas de plantão (e um rodízio definido para elas).
- Função que podemos atribuir às pessoas que trabalham em um incidente.
- Local específico vamos declarar o incidente e rastreá-lo.
- Canal único para as pessoas que trabalham nesse incidente se comunicarem sobre ele.
Você pode e deve automatizar a criação e o gerenciamento de todas essas coisas na máxima extensão possível. Quando surge um problema urgente, não queremos ter de reformular todos os passos necessários para provocar um incidente, chamar as pessoas certas e controlar o mesmo. Só tem de premir o botão "começar" para começar imediatamente a lidar com o problema.
Utilizar aplicações do Logic Apps para uma automatização sem código
Uma maneira de automatizar sua resposta inicial é usando aplicativos lógicos, que podem simplificar o trabalho de agendamento, automação e orquestração de tarefas, processos de negócios e fluxos de trabalho.
O Logic Apps é um serviço cloud do Azure para criar soluções de integração. Utiliza conectores para criar fluxos de trabalho automatizados. Os gatilhos iniciam o Aplicativo Lógico quando ocorre um evento específico ou quando os dados atendem aos critérios especificados. As ações são as operações realizadas no fluxo de trabalho de aplicação do Logic Apps.
Para nosso exemplo, usaremos os seguintes conectores do Aplicativo Lógico para rastreamento de incidentes:
- Azure Boards (uma parte do Azure DevOps), que você pode usar para criar e rastrear problemas/incidentes.
- Armazenamento do Azure, onde você pode armazenar e recuperar informações sobre quem está de plantão para que possa atribuir as pessoas adequadas para responder ao incidente. Em nosso exemplo, usaremos o Armazenamento de Tabela do Azure porque ele oferece um armazenamento de "chave-valor" muito simples que facilita o armazenamento de uma lista de engenheiros e seu status de plantão.
- Microsoft Teams, que você pode usar para criar um canal de incidentes novo e exclusivo para acompanhar as conversas de suas equipes de engenharia em tempo real enquanto elas se comunicam sobre incidentes específicos. Isso permite que você preserve as interações em relação à linha do tempo dos eventos mais tarde ao executar uma revisão pós-incidente.
Agora vamos combinar tudo com uma aplicação do Logic Apps. Primeiro, dê uma olhada no aplicativo completo, conforme mostrado no Logic Apps Designer, depois vamos percorrê-lo passo a passo.
O primeiro passo é lidar com um gatilho, aquela solicitação HTTP que mencionamos. É feito um pedido HTTP POST à nossa aplicação lógica que contém um payload JSON com as informações sobre o incidente que queremos declarar. Analisamos o payload e enviamos a confirmação de receção:
Com estas informações, criamos um novo item de trabalho na nossa organização do Azure DevOps que representa este incidente.
Em seguida, criará um novo canal do Teams para o incidente:
Uma vez que o canal é criado, o item de trabalho que criamos um momento atrás é atualizado com um link para o novo canal. Isto mantém todas as informações no mesmo local (o item de trabalho) e permite que as pessoas que vão analisá-lo mais tarde saibam como aceder se quiserem aderir a esse canal.
Agora, é hora de trazer a pessoa de plantão para a cena. Realizamos uma pesquisa no Armazenamento de Tabela do Azure para o endereço de email do engenheiro listado como estando de plantão. Isso retorna uma resposta JSON, que analisamos.
Como nossa consulta retornará uma lista, precisamos iterar sobre cada item dessa lista como a próxima etapa. Atribuímos o item de trabalho a cada pessoa (tornam-se agora "proprietárias" do incidente).
Em seguida, como etapa final, enviamos uma mensagem para o canal do Teams com um ponteiro de volta para o item de trabalho para as pessoas que ingressam no canal e querem saber onde as informações autorizadas para esse incidente estão armazenadas.
Esse é apenas um exemplo de como podemos automatizar a configuração dos mecanismos de rastreamento e comunicação de incidentes. Na próxima unidade, vamos aprofundar os aspetos da comunicação em torno de um incidente.