Gerenciamento de incidentes para equipes de alta velocidade
O futuro do gerenciamento de incidentes de TI, resposta, prevenção
Antes, a equipe encarregada de responder a incidentes de tecnologia era quase sempre de TI. Muitas vezes, uma equipe em um centro de operações de rede, ou NOC, monitorava sistemas e respondia a interrupções. Um fornecedor pode ter criado o software, mas a implantação e operação eram de responsabilidade da equipe de operações de TI do cliente. Hoje, com a proliferação de serviços em nuvem, o fornecedor cria o software e faz a implantação e operação.
No entanto, o gerenciamento de incidentes continua sendo uma prática central de ITSM. E a TI tem um longo histórico de desenvolvimento de diretrizes e gerenciamento de orçamentos, além de carregar todo o fardo de diagnosticar, corrigir, documentar e prevenir incidentes importantes.
É claro que, como acontece com qualquer coisa em tecnologia, o passado não é necessariamente um preditor do futuro — e atualmente a prática do gerenciamento de incidentes está mudando. As equipes de DevOps, SecOps e arquitetura estão se envolvendo mais. Novas tecnologias e produtos interconectados mudaram a forma como gerenciamos incidentes. E mentalidades, práticas e estruturas de equipe estão mudando para acompanhar.
Então, como o gerenciamento de incidentes está mudando e qual é o significado disso para o futuro de funções, produtos, processos e equipes?
Um movimento em direção à descentralização
Volte cinco anos e pergunte a uma equipe de TI responsável pelo gerenciamento de incidentes. A resposta que você quase sempre obteria seria "a gente".
Faça a mesma pergunta agora e é provável que você ouça falar não apenas de TI, mas também de equipes de DevOps, SecOps e de arquitetura. Muitas empresas estão pouco a pouco mudando para a ideia de “você criou, você executa”.
Os benefícios claros dessa abordagem são que ela tira a pressão das equipes de TI e acelera os tempos de resposta, mudando a responsabilidade para as pessoas mais familiarizadas com o código. Assim, o tempo de inatividade é minimizado e a produtividade da equipe é maximizada. Também incentiva um bom código. (Se for você quem acorda às 3 da manhã para resolver um bug, é provável que verifique o código duas ou três vezes na próxima vez que ele for ativado para evitar que a chamada das 3 da manhã aconteça de novo.)
O desafio dessa abordagem é que as empresas ainda precisam de alguma centralização. A liderança precisa de acesso a relatórios e documentação. As partes interessadas da empresa querem atualizações. Elas querem ver as métricas de incidentes, como o tempo médio para resolução e para confirmação de recebimento. Elas esperam atualizações claras de incidentes, relatórios de análises retrospectivas de incidentes e trabalho de correção.
Para muitas empresas que estão conseguindo implantar a descentralização, a resposta a esse desafio é a tecnologia que permite a descentralização e a autonomia da equipe para agilizar a resolução de incidentes e ainda centralizar as informações para manter a empresa sempre atualizada.
O caminho lento para a descentralização
Como com qualquer outra grande mudança que possa interromper os fluxos de trabalho e gerar consequências imprevistas, faz sentido que muitas empresas estejam implantando a descentralização bem devagar.
Elas começam identificando uma equipe que seja uma boa opção cultural para uma mudança como essa e esteja gerenciando um aplicativo ou produto de baixo risco. Em seguida, elas movem o gerenciamento de incidentes para o aplicativo ou produto específico dessa equipe para ela. Elas os treinam, implementam um cronograma de plantão e acompanham seu progresso ao longo do tempo, fazendo perguntas como:
- Eles melhoraram os tempos de recuperação?
- Quais barreiras culturais eles enfrentaram?
- Quais ferramentas a equipe de TI precisou colocar em prática?
- Quais processos eles precisaram comunicar?
- Essa equipe está entregando atualizações melhores do sistema?
- O número de incidentes caiu?
- Se decidirmos lançar essa descentralização para outras equipes, o que podemos tirar dessa execução inicial do teste?
Esses casos de teste funcionam para proporcionar uma base para decidir se uma estrutura de "você criou, você dá suporte" vai ser implementada em toda a empresa e, em caso afirmativo, como implementá-la com eficácia entre as equipes.
Descentralização significa colaboração entre equipes
Esse movimento em direção à descentralização também requer um movimento em direção à colaboração entre equipes. Se o DevOps estiver envolvido no gerenciamento de incidentes, o DevOps vai precisar participar das reuniões do processo de gerenciamento de incidentes de TI. Se a TI ainda estiver ajudando a orientar as práticas de gerenciamento de incidentes, eles precisam se envolver em análises retrospectivas sem apontar culpados por outras equipes.
Cada equipe traz seus próprios pontos fortes para a mesa de gerenciamento de incidentes. As equipes de TI são boas no desenvolvimento de práticas e documentação e seguindo as diretrizes. As equipes de DevOps são boas em mudanças e aprendizado. As equipes de SecOps podem dar uma perspectiva de segurança.
Para promover mais colaboração entre as equipes, as empresas estão compartilhando informações abertamente, promovendo a empatia entre as equipes, se livrando de jogos de culpa entre equipes, usando o bate-papo para manter as equipes conectadas durante incidentes e priorizando revisões de incidentes de que todos possam participar.
A mudança de reativo para proativo
Nas diretrizes da ITIL, normalmente o gerenciamento de incidentes é visto como uma prática separada da prevenção de incidentes. Ambas são peças importantes do quebra-cabeça de ITSM, mas muitas vezes não acontecem em conjunto.
O problema com essa abordagem é que ela mantém o gerenciamento de incidentes em um estado reativo. Os funcionários de plantão são encarregados de apagar incêndios e, assim que o incêndio for apagado, eles passam para o próximo. O único objetivo em mente é a recuperação — fazer o sistema voltar a funcionar.
Mas a recuperação não representa o cenário todo. E mais equipes de TI estão percebendo e adotando essa abordagem ao longo do tempo, dobrando a prevenção no processo de gerenciamento de incidentes e usando métricas como tempo médio para a resolução em vez de tempo médio para recuperação para avaliar seu desempenho.
Essa abordagem geralmente é chamada de gerenciamento de problemas e seu objetivo é aproximar os processos — garantir que as equipes não estejam apenas respondendo a um incêndio e seguindo para outro, mas que respondam, recuperem e aprendam com o incidente, aplicando esses aprendizados ao problema em questão e aos sistemas de produtos e serviços maior que eles estão gerenciando.
Muitas empresas de TI corporativas vão ter uma prática dedicada ao Gerenciamento de problemas. Elas geralmente o tratam como um processo separado para uma equipe separada. Na Atlassian, defendemos dar um passo adiante e usamos uma abordagem combinada, em que as operações de TI e as equipes de desenvolvedores incluem a prática de gerenciamento de problemas em suas práticas de incidentes. Essa abordagem proporciona melhor visibilidade para todo o incidente e garante que a análise de incidentes não aconteça muito depois que o incidente realmente aconteceu.
Porque, a longo prazo, há mais valor na prevenção de incidentes do que em responder a eles rapidamente.
Continuar o curso com processo e documentação
Um dos desafios inerentes a essa mudança para a colaboração entre equipes no gerenciamento de incidentes é que algumas equipes estão mais relaxadas do que outras sobre processo e documentação.
Essa é uma das áreas em que a TI pode oferecer supervisão e valor significativo, mesmo quando outras equipes assumem o gerenciamento de seus próprios produtos. Porque ninguém quer assumir um incidente grave com olhos cansados às 3 da manhã sem um plano sólido.
Ao envolver as equipes no processo de gerenciamento de incidentes, a TI pode ajudá-las a responder às principais perguntas que vão determinar esse plano. Por exemplo:
- Qual é sua resposta a incidentes?
- Quais são os valores que você vai seguir?
- Como você vai responder em caso de incidentes?
- Onde estão as informações de que você precisa para os sistemas críticos aos quais você oferece suporte? Se estiverem em vários sistemas, como você pode reunir essas informações e torná-las facilmente acessíveis a especialistas de plantão?
- Seu processo e documentação são colaborativos e revisáveis pela equipe?
A cultura da sua empresa está pronta para a mudança?
Essa mudança em direção à descentralização, colaboração e uma combinação de gerenciamento de incidentes e problemas requer mais do que simplesmente redistribuir responsabilidades e agendar um profissional de TI para participar de uma análise retrospectiva de DevOps. A chave para o sucesso aqui não está na tecnologia ou mesmo nos processos. Está na criação de uma cultura interna que apoie essas mudanças.
Esta é a parte que muitas empresas tentam pular e é a base para uma transição bem-sucedida. Então, como é uma cultura que dá suporte ao gerenciamento de incidentes descentralizado, colaborativo e focado no futuro?
Na Atlassian, achamos que os principais componentes são:
Abertura e compartilhamento de informações
Se as equipes não sabem e não conseguem acessar o que outras equipes estão fazendo, perdemos oportunidades de boas sacadas que levam a uma melhor comunicação, processos e produtos.
Pensamento centrado no cliente
Quando fazemos perguntas como “o que é realmente melhor para o cliente?”, às vezes as respostas que obtemos não combinam com as práticas atuais. É preciso um foco intencional no cliente para nos levar em direção ao tipo de comunicação, processo e eficiência estrutural que, em última análise, tornam os produtos melhores para os clientes.
Verificações regulares de integridade
Como cada equipe está indo? Como os membros individuais da equipe estão se sentindo? No que a equipe pode melhorar? O que eles estão fazendo com excelência? Na Atlassian, temos um manual de estratégias da equipe que ajuda a checar a saúde das equipes e apresentá-las a novas formas de trabalhar.
Empatia
Se DevOps está apontando para a TI e a TI está olhando para a abordagem mais relaxada do DevOps, não é uma receita para colaboração. Promover a empatia e as conexões entre as equipes é essencial se quisermos que elas se comuniquem, inovem e trabalhem bem juntas.
Empoderamento
As equipes devem ser capacitadas para corrigir problemas com rapidez e tomar decisões sozinhas sempre que possível. Indivíduos dentro dessas equipes devem se sentir capacitados para falar se tiverem uma pergunta, sugestão ou preocupação, não importa a posição na equipe ou os anos de experiência.
Quando os desenvolvedores juniores sentem que podem levantar a mão nas reuniões e sinalizar um item, mesmo quando alguém mais sênior foi responsável por esse código, o resultado são novas ideias inovadoras, processos aprimorados e captura de bugs antes que eles entrem no código.
Aprenda a comunicação de incidentes com o Statuspage
Neste tutorial, você vai ver como usar templates de incidentes para se comunicar com eficácia durante interrupções. Adaptável a muitos tipos de interrupção de serviço.
Leia este tutorialExemplos e templates de comunicação de incidentes
Ao responder a um incidente, os templates de comunicação são inestimáveis. Veja os templates que as equipes usam e mais exemplos de incidentes comuns.
Leia este artigo