Close

O caminho para um gerenciamento de incidentes melhor começa aqui

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.

Logo do OpsGenie

Aprenda a abordagem da Atlassian ao gerenciamento de incidentes

É mais crítico do que nunca ter um processo de gerenciamento de incidentes rápido e simples.

É 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
  • Um serviço voltado para o cliente, como o Jira Cloud, está indisponível a todos os clientes
  • A confidencialidade ou a privacidade foi violada
  • Perda de dados do cliente
2 Um incidente grande com impacto significativo
  • Um serviço voltado para o cliente está indisponível a um subconjunto de clientes
  • Funcionalidade principal (p. ex., git push, criação de item) foi afetada significativamente
3 Um incidente menor com impacto baixo
  • Uma pequena inconveniência aos clientes, com uma solução alternativa disponível
  • Degradação do desempenho utilizável

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 um incidente tem sobre os usuários? O incidente derruba todo o sistema deles? Impede a conclusão de uma tarefa fundamental? Ou talvez apenas os irrita 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 medida primária que a gente usa no Opsgenie. E como a gravidade em geral é um fator chave que impulsiona a prioridade, estabelecemos definições claras no manual de incidentes para a nossa própria 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.

Por exemplo: um serviço voltado para o cliente como o Jira está inativo para todos os clientes.

GRAV-2

Um incidente grave com impacto significativo.

Por exemplo: um serviço voltado para o cliente está inativo para um subconjunto dos clientes.

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.

Por exemplo: perda parcial de funcionalidade para um pequeno subconjunto dos clientes.

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.

Por exemplo: tempos de carregamento mais lentos do que a média.

GRAV-5

Bugs ou problemas de suporte que não afetam a usabilidade do produto.

Por exemplo: um logotipo sendo exibido no lugar errado ou obscurecendo parte da última letra em um título.