Políticas de escalonamento para o gerenciamento de incidentes eficaz

Escalonamento hierárquico

O escalonamento hierárquico acontece quando um incidente é passado para uma equipe ou funcionário com base no nível de experiência ou senioridade dentro da empresa.

Por exemplo, o primeiro respondente de plantão pode ser um desenvolvedor júnior novo na equipe. Em uma organização hierárquica, se esse desenvolvedor não conseguir resolver um item, ele vai passar o item para um desenvolvedor mais sênior. Se o desenvolvedor mais sênior também não conseguir resolver o item, ele vai passar de novo para um desenvolvedor mais sênior e assim por diante até que o item seja resolvido.

Escalonamento funcional

O escalonamento funcional ocorre quando um incidente é passado para uma equipe ou funcionário mais capacitado para resolver com base nas habilidades ou conhecimentos de sistemas, e não na senioridade.

Por exemplo, o primeiro respondente de plantão pode ser um desenvolvedor júnior de uma equipe que se concentra no back-end do produto X. Se o funcionário descobrir que o problema central parece ter origem de uma integração com o produto Y, ele pode escalonar o incidente para outro desenvolvedor júnior na equipe Y.

Escalonamento automático

Para equipes que trabalham com uma plataforma como o Opsgenie, também é possível configurar regras que dizem ao sistema para fazer o escalonamento automático de um incidente se o funcionário principal de plantão não confirmar ou não encerrar um alerta.

Algumas equipes podem favorecer um método de escalonamento em vez de outro, mas eles não excluem uns aos outros, e muitas equipes usam uma mistura de escalonamento hierárquico, funcional e automático.

Matriz de escalonamento

Uma matriz de escalonamento é um documento ou sistema que define quando o escalonamento deve acontecer e quem deve lidar com incidentes em cada nível de escalonamento.

O termo é usado em vários setores. O setor de recursos humanos pode ter uma matriz de escalonamento para itens internos. Os call centers podem ter uma matriz de escalonamento para itens de atendimento ao cliente. E as equipes de TI e DevOps podem ter uma ou mais matrizes que ajudam os engenheiros a saber como e quando escalonar um incidente.

O nível de informações em uma matriz varia muito de empresa para empresa. Algumas empresas podem ter um gráfico hierárquico simples, com cada desenvolvedor escalonando para outro com um nível de habilidade mais alto conforme necessário. Outras empresas podem ter matrizes específicas para determinadas situações que informam aos desenvolvedores com quais equipes devem entrar em contato em relação a diferentes tipos de incidentes ou níveis de gravidade diferentes. Como acontece na maioria das vezes no gerenciamento de incidentes, não há uma resposta única para como desenvolver a matriz da sua empresa.

Trate a política de escalonamento como uma diretriz, não como um conjunto rígido e rápido de regras

A tecnologia não é estática, e nem as equipes. O Google sugere que, se o SRE acha que um caso específico exige uma estratégia de escalonamento diferente, ele deve ter a liberdade de tomar essa decisão. A questão aqui não é criar regras inflexíveis, mas criar diretrizes que se aplicam na maioria das situações.

Faça auditoria do cronograma de plantão com frequência

Há alguma lacuna no cronograma? Você tem as pessoas certas de plantão? Você tem as pessoas certas no segundo e terceiro níveis de plantão? Os cronogramas de plantão e a política de escalonamento devem trabalhar juntas para proporcionar um gerenciamento de incidentes mais rápido.

Estabeleça limites inteligentes para escalonamento

Nem todos os incidentes são iguais, o que significa que nem todos os incidentes podem ou devem seguir a mesma política de escalonamento.

Para incidentes leves, talvez você não queira alertar o engenheiro de plantão até o horário de trabalho. Para incidentes graves, é bem provável que você precise desse engenheiro, não importa a hora do dia. No caso de vários incidentes, o engenheiro vai precisar saber o que abordar primeiro e/ou se deve escalonar um incidente para um segundo engenheiro de imediato.

Há um equilíbrio aqui entre garantir que os sistemas tenham a máxima disponibilidade e cumprir as promessas de SLA e as metas de SLO e garantir que os engenheiros não sejam esgotados, sobrecarregados, privados de sono e sujeitos a fadiga de alertas.

Estabeleça processos claros para escalonamento

Ao fazer o escalonamento, o desenvolvedor deve entrar em contato direto com a equipe ou funcionário apropriado ou precisa passar pela central de ajuda? Existe um sistema implementado que o desenvolvedor deve usar? Como você vai acompanhar o escalonamento? Que responsabilidades o primeiro respondente tem para garantir que o incidente seja captado pela próxima pessoa?

Essas perguntas devem ser abordadas com clareza pela política e comunicadas com transparência a todos os desenvolvedores de plantão, a fim de manter os escalonamentos funcionando sem erros e resolver incidentes com mais rapidez.

Saiba mais sobre como o Jira Service Management pode enriquecer a prática de gerenciamento de incidentes oferecendo soluções colaborativas para o escalonamento de incidentes a fim de alcançar resoluções mais rápidas.