O que é política de escalonamento?

Principais conclusões: uma política de escalonamento define quem é notificado quando um alerta de incidente é disparado, para quem o incidente é repassado caso o responsável inicial não esteja disponível ou não consiga resolvê-lo, e como essas transferências ocorrem — variando, em geral, de acordo com a gravidade, a duração e o escopo.

• O que é: um caminho documentado, registrado com frequência em uma matriz de escalonamento, que utiliza três tipos de escalonamento: hierárquico (por nível de senioridade), funcional (por área de especialização) e automático (por regra, quando um alerta não é reconhecido dentro do prazo).

• Por que isso é importante: sem isso, a resolução de incidentes trava enquanto as pessoas tentam descobrir a quem recorrer; com isso, o responsável adequado é acionado em questão de minutos, e ninguém é contatado por um motivo indevido.

• Como o Jira Service Management ajuda: o cronograma de plantão e os alertas permitem que as equipes definam regras de escalonamento por serviço e gravidade, escalonem na mesma hora alertas não reconhecidos e façam o escalonamento dentro do registro do incidente para que cada transferência seja rastreada.

Uma política de escalonamento é o plano documentado que define o que acontece quando a primeira pessoa notificada sobre um incidente não consegue resolvê-lo sozinha: quem é notificado primeiro, quem assume a responsabilidade caso essa pessoa esteja indisponível ou não consiga solucionar o problema, com que rapidez ocorre a transferência de responsabilidade e por meio de qual canal. É o complemento de um cronograma de plantão — o cronograma diz quem está disponível, a política diz como o incidente é repassado entre eles.

O melhor cenário é que o engenheiro de plantão resolva um incidente por conta própria. Quando há uma frequência de casos em que a resolução exige uma equipe maior, conhecimento especializado ou competências de nível mais sênior, é necessário que qualquer organização com mais de alguns profissionais técnicos tenha um plano de escalonamento. Este guia aborda os tipos de escalonamento, a matriz de escalonamento e as práticas recomendadas para criar uma política eficaz.

O que é escalonamento de incidentes?

O escalonamento de incidentes ocorre quando um funcionário não consegue resolver um incidente e precisa entregar a tarefa a um funcionário mais experiente ou especializado.

O que é política de escalonamento?

As perguntas parecem simples, mas quanto maior a organização e mais complexo o ecossistema de tecnologia, mais as respostas exigem informações detalhadas. Por exemplo, ao determinar quem deve ser notificado quando um alerta de incidente é recebido, a resposta pode variar não só de acordo com quem está de plantão ou disponível, mas também com os níveis de gravidade, a duração do incidente etc. 

Para algumas empresas, um único funcionário de plantão pode ser o primeiro notificado, seja qual for a gravidade do incidente. Para outras, pode fazer sentido alertar um desenvolvedor júnior se o incidente for um GRAV-3 e notificar um funcionário mais sênior ou equipe especializada se for GRAV-1.

Da mesma forma, algumas empresas podem confiar no primeiro respondente para escalonar um incidente quando necessário. Outras podem acionar um escalonamento automático para um desenvolvedor mais sênior ou equipe especializada se um incidente exceder um certo período de tempo ou se começar a afetar um número maior de sistemas ou usuários.

A política de escalonamento deve abordar não apenas como e para quem a empresa vai escalonar incidentes, mas também se há nuances com base no tipo de incidente, nível de gravidade, duração e escopo do incidente.

Processos de escalonamento de incidentes

Para empresas que seguem as práticas recomendadas de ITSM, em geral, a central de atendimento está no centro do escalonamento de incidente. Se o primeiro respondente não conseguir resolver o incidente, ele volta para a central de atendimento, a qual encaminha o item para a próxima linha de defesa apropriada. Usando o Jira Service Management, os respondentes podem escalar incidentes dentro do ticket do incidente. Os respondentes têm acesso aos fluxos de trabalho para orientar o processo de resolução e podem implementar a automação ou personalizar as ações conforme necessário. A designação do nível de gravidade pode direcionar os respondentes ao fluxo de trabalho apropriado.

Outras empresas, como o Google, colocam um SRE responsável por incidentes e esse funcionário é responsável por qualquer escalonamento necessário (além de congelar novos lançamentos no caso de um incidente pressionar a equipe além do limite de tempo de inatividade aceitável de acordo com o SLA/SLO).

Ainda para outras empresas, o primeiro respondente pode ser um desenvolvedor ou gerenciador de incidentes, ou pode haver vários primeiros pontos de contato (em especial quando surge um alerta de incidente de alta gravidade), e o escalonamento pode ocorrer por meio de processos predefinidos dentro dessas equipes e entre elas.

Se o processo passa pela central de atendimento, é facilitado por um SRE ou é automático nos sistemas de rastreamento de incidentes, em geral, existem três caminhos que as políticas de escalonamento seguem.

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 organizações 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 existe uma única maneira de desenvolver a matriz da sua empresa.

Práticas recomendadas para a elaboração de uma política de escalonamento

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, é provável que você precise dele, não importa o horário 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.