Gerenciamento de incidentes para equipes de alta velocidade
Políticas de escalonamento para o gerenciamento de incidentes eficaz
Quando um incidente ocorre, o melhor cenário é que o engenheiro de plantão ou SRE possa resolver com rapidez e por conta própria.
É claro que, no mundo real, nem sempre é o caso. Às vezes, a resolução exige uma equipe maior, conhecimento especializado ou habilidades mais seniores. É por esse motivo que qualquer empresa com mais de dois profissionais de tecnologia precisa de um plano e uma política para escalonamento de incidentes.
O que é escalonamento de incidentes?
O escalonamento de incidentes é o que acontece 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?
A política de escalonamento responde à pergunta de como a empresa lida com essas entregas. Ela descreve quem deve ser notificado quando um alerta de incidente surge, para quem um incidente deve ser escalonado se o primeiro respondente não estiver disponível, quem deve assumir se ou quando o respondente não puder resolver o item por conta própria e como essas entregas devem acontecer (por meio da central de atendimento? Direto de um técnico para outro? Por meio de uma ferramenta de gerenciamento de incidentes?).
À primeira vista, essas perguntas parecem simples, mas, quanto maior a empresa e quanto mais complexo o ecossistema tecnológico, mais as respostas exigem informações detalhadas. Por exemplo, ao identificar quem deve ser notificado quando um alerta de incidente surge, a resposta pode variar com base não apenas em quem está de plantão ou disponível, mas também com base nos níveis de gravidade, 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 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.
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, é 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.
Configuração de um on-call schedule com o Opsgenie
Neste tutorial, aprenda a configurar um on-call schedule, aplicar regras de substituição, configurar notificações de plantão e muito mais. Tudo no Opsgenie.
Leia este tutorialUma abordagem melhor para cronogramas de plantão
Um cronograma de plantão eficaz é a chave para sustentar uma cultura de plantão saudável. Aprenda sobre erros comuns, tipos de cronogramas de rodízio e como acertar.
Leia este artigo