Implantação de ITIL na operação: guia prático para provedores

O que é implantação de ITIL na operação de um provedor

É escolher, entre as práticas do ITIL, as que resolvem os problemas reais da operação e colocá-las para funcionar com as ferramentas que a equipe já usa. O foco é o processo rodando, não o vocabulário.

O ITIL é um conjunto de boas práticas de gestão de serviços de TI, hoje na versão 4. Ele foi pensado para empresas de todos os tamanhos, mas a versão completa pesa demais para uma equipe de rede de cinco ou dez pessoas.

Num provedor regional, a prática que costuma dar retorno mais rápido é a gestão de mudanças em redes, porque boa parte das quedas começa numa alteração feita sem planejamento, sem aviso e sem caminho de volta.

Por que não implantar o livro inteiro

Cada prática nova pede tempo de pessoas que também atendem quedas. Implantar muitas ao mesmo tempo sobrecarrega a equipe, e o processo é abandonado antes de mostrar resultado.

A saída é tratar o ITIL como cardápio. A operação escolhe o que resolve a dor de hoje, faz funcionar e só depois acrescenta a próxima prática.

Como funciona a implantação de ITIL na operação?

As práticas formam uma corrente em que a saída de uma é a entrada da outra. Incidentes repetidos alimentam problemas, problemas geram mudanças e mudanças atualizam a configuração e os procedimentos.

Os dados que alimentam essa corrente vêm do monitoramento de rede, que marca quando cada falha começou e terminou.

Ferramentas como o Zabbix ou a pilha descrita na implantação de Prometheus fornecem o horário de início das falhas, os gráficos e os alertas que os registros precisam.

Quem faz o quê numa equipe pequena

Num NOC enxuto, uma pessoa acumula vários papéis, e isso não é problema desde que cada papel esteja claro. O que não pode é um papel sem ninguém.

A divisão entre níveis de atendimento ajuda a distribuir esses papéis, como mostra o guia sobre o que é suporte N1, N2 e N3.

Implantação de ITIL na operação passo a passo

A ordem abaixo funciona na maioria dos provedores, uma prática de cada vez. Só avance para a próxima quando a anterior estiver rodando sem cobrança diária.

1. Incidentes: todo chamado técnico registrado com prioridade, horário de início e de fim e o que foi feito.
2. Mudanças: pedido curto, aprovação conforme o risco, janela e plano de volta para as alterações perigosas.
3. Conhecimento: procedimentos escritos para as dez falhas mais comuns, num lugar que todo turno acessa.
4. Problemas: quedas repetidas investigadas até a causa, com dono e próxima ação.
5. Configuração: inventário de equipamentos e diagrama da rede atualizados a cada mudança aprovada.

A implantação de ITIL na operação exige mais constância do que ferramenta. Uma revisão curta por semana, olhando os registros da semana anterior, mantém o processo vivo nos primeiros meses.

Para a quarta etapa, o guia de gestão de problemas no NOC detalha gatilhos, análise de causa e erro conhecido.

Exemplo de pedido de mudança em poucas linhas

O pedido de mudança não precisa de formulário longo para cumprir o papel. Sete campos respondem tudo o que o aprovador e o turno seguinte precisam saber.

Tipo: normal
O que muda: filtro de prefixos na sessão com a operadora B, roteador de borda 1
Por quê: anúncio indevido de rota interna detectado no monitoramento
Risco: perda de rotas da operadora B se o filtro estiver errado
Janela: terça, 00h30 a 01h30
Como confirmar: rotas recebidas e tráfego da operadora B iguais aos de antes
Como voltar: restaurar o filtro anterior, salvo em cópia antes da janela

Se o pedido não cabe nesses campos, provavelmente a mudança deveria ser dividida em partes menores. Mudanças padrão, como ativar cliente, nem chegam a ter pedido: seguem o roteiro já aprovado.

Como adaptar o ITIL sem criar burocracia?

Mantenha só o que evita queda ou poupa tempo, e corte o resto na revisão mensal. Processo que ninguém segue é pior do que processo nenhum, porque dá falsa segurança.

• Mudança padrão pré-aprovada: tarefas rotineiras, como ativar cliente ou trocar plano, não passam por comitê.
• Formulários curtos: só os campos que alguém vai ler depois.
• Ferramenta que a equipe já usa: o sistema de chamados atual costuma bastar no começo.
• Revisão mensal: o passo que não ajudou é cortado ou simplificado.

Quando vale comprar uma ferramenta de gestão de serviços?

Vale quando o processo já roda no sistema de chamados atual e esbarra em limites claros dele. Comprar antes de ter o processo só troca a desordem de lugar.

• Sinal para comprar: a equipe já registra tudo, mas não consegue ligar incidentes a problemas e mudanças.
• Sinal para esperar: os registros ainda dependem de cobrança diária para serem feitos.
• Teste antes: use a ferramenta nova num período curto com uma prática só, antes de migrar tudo.

Na prática: um roteiro em três fases

Dividir a implantação em fases dá à equipe metas curtas e um ponto claro de passagem para a próxima etapa. Cada fase termina quando o sinal de pronto aparece, não numa data fixa.

Os prazos de cada fase dependem do tamanho da equipe e do ponto de partida. [CONFIRMAR prazos com o diagnóstico de cada provedor]

A Táquion Tech trabalha com as práticas que cabem na equipe do provedor, começando quase sempre pelo fluxo de mudanças, e entrega o processo escrito dentro do sistema de chamados que já está em uso.

Erros comuns e como medir o resultado

Os erros mais comuns fazem a equipe abandonar o processo em poucos meses. A medida certa mostra cedo se a implantação está funcionando ou só gerando papel.

Checklist depois de três meses

Três meses de uso dão dados suficientes para uma primeira avaliação honesta. Compare sempre com o período anterior à implantação.

Para clientes corporativos, os mesmos registros alimentam o relatório de SLA, com tempo de indisponibilidade calculado a partir dos horários de cada incidente.

Indicadores que mostram se a operação melhorou

Poucos indicadores, acompanhados todo mês, contam mais que um painel cheio de números. Todos saem dos registros que as próprias práticas criam.

• Tempo de volta do serviço: média entre o início e o fim dos incidentes, separada por tipo de falha.
• Quedas causadas por mudança: quantos incidentes começaram logo depois de uma alteração na rede.
• Mudanças com plano de volta: fatia das mudanças de risco que tinham o caminho de volta escrito.
• Incidentes repetidos: quantas quedas tiveram a mesma causa de outra já registrada.

A tendência importa mais que o valor de um mês isolado. Se as quedas por mudança caem por três meses seguidos, a prática pegou.

Perguntas frequentes sobre implantação de ITIL na operação

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech