O futuro do gerenciamento de incidentes de TI, resposta, prevençã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.

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.

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.

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.

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?

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: