Gerenciamento de incidentes para equipes de alta velocidade
Compreendendo os níveis de gravidade do incidente
Identificar e priorizar incidentes para uma resolução mais rápida
Existem três verdades fundamentais do gerenciamento de incidentes.
A primeira é que incidentes são inevitáveis — ainda mais para empresas que estão em constante crescimento e inovação.
A segunda é que uma prática de gerenciamento de incidentes forte é vital para negócios saudáveis (e uma prática fraca custa muito para as empresas tanto em tempo dos funcionários quanto em satisfação e receitas dos negócios).
A terceira é que nem todos os incidentes são criados iguais. Perder dados de um banco de dados não é o mesmo que perder dados de todos os bancos de dados. Lidar com uma interrupção que afeta 20% dos usuários é totalmente diferente de lidar com uma interrupção que afeta 90% ou 100%. Lidar com uma interrupção do sistema durante o horário de pico é muito mais estressante do que lidar com uma quando a maioria dos clientes está dormindo. Mesmo dois incidentes que parecem idênticos no papel são únicos quando olhamos de perto.
Gerenciamento de incidentes para equipes de alta velocidade
Acelere o fluxo de informações entre as equipes de operações e de desenvolvimento para responder e restaurar sistemas quando ocorrerem incidentes com o Jira Service Management.
É por esses motivos que as empresas com programas robustos de gerenciamento de incidentes têm níveis de gravidade de incidentes bem definidos e práticas recomendadas claras para priorizar os incidentes à medida que eles surgem.
Quais são os níveis de gravidade?
Os níveis de gravidade de incidentes são uma medição do impacto que eles têm nos negócios. Em geral, quanto menor o número de gravidade, maior é o impacto do incidente.
Por exemplo: na Atlassian, a gente define um incidente GRAV-1 (gravidade 1) como “um incidente crítico com impacto muito alto”. Pode ser uma perda de dados do cliente, uma violação de segurança ou interrupção para todos os clientes de um serviço voltado para o cliente.
Um incidente GRAV-2 é um “incidente grave com impacto significativo”, incluindo quando um serviço voltado para o cliente está inativo para um subconjunto de clientes ou uma função crítica dentro de um sistema não está funcionando.
E um incidente GRAV-3 é “um incidente leve com baixo impacto”, como uma falha no sistema que está causando pequenos inconvenientes aos clientes.
Na Atlassian, incidentes GRAV-3 podem ser tratados durante o dia/horário de trabalho, enquanto os incidentes GRAV-1 e GRAV-2 geram um alerta para profissionais de plantão para uma correção imediata, não importa a hora do dia.
| Gravidade | Descrição | Exemplos |
|---|---|---|
| 1 | Um incidente crítico com impacto muito alto |
|
| 2 | Um incidente grande com impacto significativo |
|
| 3 | Um incidente menor com impacto baixo |
|
Os níveis de gravidade são úteis para compreender o impacto com rapidez e definir prioridades para as equipes de TI e DevOps.
Quanto mais bem definidos forem os níveis de gravidade, maior vai ser a probabilidade de que a equipe esteja em sincronia e possa ter uma reação rápida e adequada quando os incidentes acontecerem. Sem níveis de gravidade bem definidos, é fácil perder tempo vital definindo e explicando a urgência de um incidente, quando poderia estar resolvendo o incidente.
Quando e onde os níveis de gravidade são úteis?
O valor central dos níveis de gravidade é que eles poupam tempo para as equipes. Uma equipe com níveis de gravidade e um roteiro claro para abordar cada nível está pronta para a dedicação imediata a uma correção. Se a equipe não tiver níveis de gravidade, é provável que ela gaste os primeiros minutos cruciais de um incidente grave descobrindo a importância dele, quem deve lidar com ele e como lidar com ele.
Quanto mais crítico for o incidente, mais importante vai ser poupar o máximo de tempo possível planejando com antecedência não apenas com planos de resolução de incidente e comunicação, como também níveis claros de gravidade e prioridades.
Qual é a diferença entre gravidade e prioridade?
À primeira vista, a gravidade do incidente parece ser a mesma da prioridade do incidente. Afinal, um incidente grave com consequências terríveis deve ser tratado antes de um incidente menos grave, certo?
Mas a verdade é que, para a maioria das empresas, é mais complicado.
A gravidade é uma medida de impacto. Que impacto o incidente tem sobre os usuários? O incidente derruba todo o sistema deles? Impede a conclusão de uma tarefa fundamental? Ou talvez seja apenas irritante e torna as tarefas mais difíceis?
A prioridade, por outro lado, é uma medida da urgência. Com que rapidez precisamos corrigir esse item? Qual item precisa ser corrigido primeiro?
Às vezes, as duas medidas estão em alinhamento perfeito. É provável que um incidente de alta gravidade que derruba toda a empresa também seja a maior prioridade na qual as equipes de DevOps e TI devem se concentrar.
Porém, às vezes a prioridade e a gravidade não se alinham. Por exemplo: digamos que haja um erro de digitação no título na página inicial do seu site. Este é um item de baixa gravidade porque ele não afeta a função do site. Os usuários ainda podem fazer o que precisam fazer. Os funcionários ainda podem fazer o que precisam fazer.
No entanto, a empresa pode ver a correção como de alta prioridade por motivos de padrão de marca, porque causa confusão ou porque prejudica a imagem da empresa. Assim, esse incidente pode ser de baixa gravidade e alta prioridade.
Da mesma forma, digamos que haja um incidente que esteja fazendo o aplicativo falhar. Ele é de alta gravidade porque impede que os usuários façam o que precisam fazer. Porém, digamos que o incidente esteja afetando apenas 0,05% dos seus usuários. Se houver outros incidentes com impacto mais amplo, um item como esse pode não ser a prioridade máxima, mesmo que em geral as palavras “o sistema está falhando” signifiquem que todos devem botar a mão na massa.
Ambas as medidas são importantes no gerenciamento de incidentes, mas é importante reconhecer quando elas se alinham e quando não se alinham. A alta gravidade não leva algo direto para o topo da lista de prioridades, e a alta prioridade nem sempre significa que um sistema está inativo.
Como a prioridade é mais acionável do que a gravidade, é a principal medida que usamos. E como a gravidade em geral é um fator chave que impulsiona a prioridade, estabelecemos definições claras no manual de incidentes para a prática de gerenciamento de incidentes.
Definindo os níveis de gravidade de incidente para sua empresa
Nem todos os incidentes são criados iguais e nem todas as empresas lidam com eles da mesma maneira. Ao definir níveis de gravidade e os processos e as expectativas em torno deles, além do impacto de um incidente, você vai precisar considerar:
- O tamanho da sua equipe de tecnologia
- On-call Schedules
- Os horários do dia de alto e baixo tráfegos para o seu serviço
- A frequência dos incidentes
Por quê? Porque cada um desses fatores pode afetar o modo como você define os níveis de gravidade.
Por exemplo, um aplicativo que atende os mercados locais em um único fuso horário pode ter uma grande lacuna de uso entre 2 e 7 da manhã. Então, se todo o seu sistema ficar inativo às 3 da manhã, o nível de gravidade vai ser o mesmo que o de uma interrupção do sistema durante o horário de pico?
E quanto a uma startup com uma equipe pequena e muitos do que podemos considerar incidentes de GRAV-3? Ela deve usar uma categoria de GRAV-3 e deixar a equipe descobrir quais incidentes têm prioridade quando três acontecem de uma só vez? Ou deve fazer a divisão em GRAV-3, 4 ou até 5 para distinguir entre uma perda parcial de funcionalidade em um sistema voltado para o cliente, problemas de desempenho e algo ainda menor, como um bug que não afeta a usabilidade do sistema, mas que precisa ser corrigido em algum momento?
O importante aqui é entender os seus negócios, a sua equipe e que tipo de definições de nível de gravidade e prioridades funcionam para você.
| Nível 3 da Atlassian | Nível 4 | Nível 5 | |
|---|---|---|---|
| GRAV-1 | Um incidente crítico com impacto muito alto. | ||
| GRAV-2 | Um incidente grave com impacto significativo. | ||
| GRAV-3 | Um incidente leve com baixo impacto. Por exemplo: um bug do sistema está criando um pequeno inconveniente para os clientes. | Um incidente com o potencial de se tornar um incidente grave se não for resolvido logo. | |
| GRAV-4 | Uma solicitação de suporte que é irritante para o cliente, mas não afeta a função geral do sistema. | Um incidente leve que afeta a usabilidade do produto, mas não o interrompe. | |
| GRAV-5 | Bugs ou problemas de suporte que não afetam a usabilidade do produto. | ||
É essencial ter uma solução de gerenciamento de incidentes para escalar os incidentes, para que as equipes certas possam se reunir e iniciar a resolução de imediato.
Descubra como todos os recursos de gerenciamento de incidentes do Jira Service Management, incluindo alertas e agendamento de plantão, comunicação colaborativa e recursos robustos de relatórios e análises, permitem que as equipes respondam, resolvam e aprendam com os incidentes.
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