Monitoramento de serviços críticos de TI: como definir o que é crítico antes de monitorar

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado nov/2015Atualizado ago/2026

Abra a lista de itens monitorados do seu ambiente e conte quantos estão marcados como críticos. Em operações de 500 a 1.000 colaboradores, esse número costuma passar da metade do inventário. Quando metade é crítica, nada é.

A conta chega no plantão. O celular toca pelo servidor de homologação com a mesma urgência do gateway de pagamento, o analista aprende a ignorar a notificação, então o alerta que importava desce na tela junto com outros trinta que não importavam.

Classificar criticidade é o trabalho que vem antes de escolher métrica, limiar ou ferramenta. Sem essa etapa, o monitoramento de TI cobre tudo com o mesmo peso e protege pouca coisa de verdade. Este artigo entrega o critério, a escala de níveis e o que muda na operação em cada um deles.

O que é um serviço crítico de TI

Um serviço crítico de TI é aquele cuja indisponibilidade produz efeito imediato e mensurável fora da TI: perda de receita, descumprimento de obrigação legal ou contratual, risco a pessoas, parada de outros serviços que dependem dele. A definição descreve o efeito, não o tamanho do servidor.

Repare na unidade de análise. O item crítico é o serviço, nunca o ativo que o hospeda. Uma mesma máquina virtual pode sustentar a emissão fiscal da empresa e um ambiente de testes: o hardware é o mesmo, a criticidade dos dois serviços é oposta.

Essa troca de unidade muda a pergunta feita ao ambiente. Sai “este servidor está no ar” e entra “o pedido do cliente consegue ser faturado agora”. A primeira pergunta uma tela de infraestrutura responde. A segunda exige saber quais componentes participam da entrega.

O custo de declarar tudo crítico

Inflação de criticidade tem duas faturas. A primeira é a fadiga de alerta: quando todo evento chega com prioridade máxima, o plantonista passa a filtrar por instinto. O filtro humano erra justamente na noite em que o evento é real.

A segunda fatura é orçamentária. Redundância, contrato de suporte 24×7 e janela de recuperação curta custam caro em cada serviço onde são aplicados. Espalhar esse investimento por igual significa proteger de menos o que precisa e proteger demais o que não precisa.

A hierarquia existe para direcionar o dinheiro. A pesquisa mais recente do Uptime Institute mostra que 57% dos operadores tiveram custo acima de US$ 100 mil na interrupção mais recente, com um em cada cinco acima de US$ 1 milhão.

Note que a distribuição é desigual por natureza. Alguns serviços concentram quase todo o prejuízo por minuto parado, o que fica evidente quando a equipe calcula o custo de um downtime serviço por serviço, em vez de tratar o ambiente como bloco único.

Os três eixos que definem criticidade

Classificação defensável usa eixos que qualquer pessoa da mesa consegue verificar. Três bastam para a maioria dos ambientes corporativos. A nota final é o maior valor entre eles, nunca a média dos três.

O primeiro eixo é o impacto financeiro direto: receita que deixa de entrar, produção que para, multa contratual que incide por minuto de indisponibilidade. Ele se responde com número do próprio negócio, não com estimativa da TI.

O segundo é a obrigação externa: exigência legal, regulatória ou de segurança de pessoas. Emissão fiscal, prontuário eletrônico, controle de acesso físico e sistemas com prazo definido em norma entram aqui mesmo quando a receita direta é baixa.

O terceiro é o alcance da dependência: quantos outros serviços param junto. Autenticação, DNS, rede de núcleo e banco de dados compartilhado quase sempre sobem de nível por esse eixo, porque a falha deles derruba a fila inteira atrás.

A janela também classifica

Criticidade tem hora marcada em boa parte dos casos. O sistema de fechamento contábil vira tier máximo nos cinco dias úteis do fechamento, a plataforma de e-commerce muda de nível na semana da Black Friday, o sistema acadêmico concentra risco no período de matrícula.

Registre a janela junto com o nível. Sem isso, ou a operação carrega custo de plantão máximo o ano inteiro, ou descobre no pior dia que o serviço estava classificado pela média. O mesmo raciocínio orienta o desenho de uma jornada crítica do usuário, que olha o caminho completo em vez do componente isolado.

 
Quatro níveis costumam bastar. Escalas com sete graus parecem mais precisas porém param de ser aplicadas no terceiro mês, porque ninguém consegue defender a diferença entre o grau 4 e o grau 5 diante do dono do sistema.

Quem assina a classificação

A TI propõe, a área dona do serviço assina. Essa separação parece burocrática porém resolve o conflito mais comum do exercício: o nível deixa de ser opinião técnica e passa a ser compromisso de quem responde pelo processo.

O efeito prático aparece na conversa sobre custo. Quando o gestor de operações pede tier 1 para o sistema dele, a resposta deixa de ser “não cabe” e passa a ser a lista do que aquele nível exige: coleta em segundos, plantão dedicado, ambiente redundante testado.

Boa parte dos pedidos recua nesse momento, sem discussão de autoridade. Os que permanecem viram investimento defensável, com dono e justificativa registrados.

Documente as três informações mínimas por serviço: nível atribuído, dono no negócio, data da última revisão. Sem o nome do dono, a lista volta a ser um arquivo interno da TI. A próxima discussão então começa do zero, com os mesmos argumentos e nenhum registro para consultar.

Do serviço à lista de dependências

Classificar sem mapear entrega uma lista bonita que a operação não consegue usar. O alerta continua nascendo no componente. Alguém precisa traduzir “fila de mensagens acumulando” para “o pedido não vai fechar”.

O ponto de partida é o catálogo de serviços de TI, que dá nome de negócio a cada entrega. Em seguida vem a relação entre serviço e componentes, que é exatamente o papel do CMDB quando ele é mantido vivo.

Com o mapa pronto, o painel muda de assunto. Em vez de duzentos itens verdes, a tela mostra o estado do serviço e a lista de dependências que sustentam aquele estado. O tempo de diagnóstico cai porque a pergunta “quem quebrou primeiro” já vem respondida na hierarquia.

Em uma das maiores redes de varejo do Brasil, mapeamos os processos críticos com todas as interdependências: TI central, lojas, meios de pagamento, PIX, rede, PDV e self checkout. Antes disso, cada indisponibilidade abria uma sala de guerra com várias equipes tentando descobrir de quem era o problema.

Com 42 lojas no painel consolidado e monitoramento orientado ao processo, as salas de guerra deixaram de existir como rotina e o MTTR caiu. O relato completo desse projeto de varejo descreve o mapeamento aplicado.

O que muda na operação em cada nível

Classificação que não altera comportamento é papelada. O nível precisa mudar coisas verificáveis: com que frequência o dado é coletado, quem é acordado, em quanto tempo alguém responde, o que existe de redundância.

 
Duas colunas dessa tabela costumam gerar discussão. A linha de acionamento é onde o custo de plantão aparece: cada serviço promovido a tier 1 acrescenta motivo de telefone tocando de madrugada, o que conversa diretamente com a régua de severidade de incidentes usada na triagem.

A linha do compromisso publicado é a que dá tração política ao exercício. Quando o nível vira SLA com apuração mensal, a área dona do sistema passa a ter interesse real na classificação, porque ela agora aparece em relatório.

Criticidade envelhece e a lista precisa de revisão

Nenhuma classificação sobrevive intacta a um ano de mudanças. Sistema novo entra, processo migra de área, integração cria dependência que ninguém desenhou. A lista congelada vira ficção em silêncio.

Quatro gatilhos justificam revisão fora do calendário: entrada de sistema em produção, mudança relevante de processo de negócio, incidente que revelou dependência desconhecida, alteração de contrato com cliente ou órgão regulador.

Preveja também o caminho de descida. Revisão que só promove serviço produz inflação garantida em dois anos: sistema legado que perdeu volume, relatório substituído por painel, integração desativada pela metade continuam ocupando plantão de madrugada porque ninguém teve a tarefa de rebaixá-los.

Fora esses gatilhos, uma revisão semestral com as áreas donas resolve. Leve dado para a reunião: minutos de indisponibilidade acumulados por serviço, chamados gerados, alertas disparados e quantos deles viraram ação. Discussão de criticidade sem histórico sempre termina em quem fala mais alto.

Um detalhe operacional facilita a revisão. Guarde o motivo da classificação junto com o nível, em uma linha só. Seis meses depois ninguém lembra por que aquele serviço virou tier 1: o registro evita repetir a discussão do zero.

A referência metodológica desse exercício é a análise de impacto no negócio, descrita no guia SP 800-34 do NIST como o instrumento que identifica sistemas essenciais e define prioridade de recuperação.

Por onde começar na segunda-feira

Comece pequeno para que o exercício termine. Pegue os dez serviços que mais aparecem em chamado no último trimestre e classifique só eles, usando os três eixos: impacto financeiro, obrigação externa, alcance da dependência.

Para cada um, escreva a janela em que ele é crítico e o motivo da nota em uma linha. Esse registro curto é o que sustenta a decisão na próxima discussão de orçamento.

Depois aplique as consequências. Ajuste o intervalo de coleta, o canal de acionamento e o prazo de primeira resposta conforme o nível. Se nada mudar na operação depois da classificação, o exercício foi apenas documental.

Por fim, marque a revisão semestral no calendário junto com as áreas donas dos serviços. Criticidade é decisão de negócio informada pela TI, nunca uma escolha isolada da infraestrutura.

Quer ajuda para mapear os serviços críticos do seu ambiente e traduzir cada nível em cobertura de monitoramento? Fale com um especialista da OpServices.