ITIL 4 — práticas: incidente × problema, mudança (padrão/normal/emergencial), SLA, CMDB

A ideia que organiza o assunto

Um sistema caiu às nove da manhã. Sobre esse mesmo fato a ITIL faz três perguntas diferentes, e cada pergunta tem dono:

O serviço está fora do acordado? Faça-o voltar. É o gerenciamento de incidentes. Meta: restaurar a operação normal o mais rápido possível, minimizando o impacto no negócio.
Por que ele caiu? Faça com que não caia de novo. É o gerenciamento de problemas. Meta: reduzir a probabilidade e o impacto dos incidentes identificando as causas reais.
O usuário só pediu alguma coisa prevista? É o gerenciamento de requisições de serviço. Nada quebrou — não há operação normal a restaurar.

Incidente e problema não são fases de um mesmo tratamento: são objetos distintos, que correm em paralelo e podem terminar em momentos diferentes. O incidente termina quando o serviço volta — ainda que a causa continue desconhecida e o serviço tenha voltado por uma solução de contorno. Fechar incidente com contorno é prática correta, não fracasso. O problema termina quando a causa é eliminada, o que pode levar semanas e exige passar pelo gerenciamento de mudanças.

Isso não é pano de fundo, é o método de resolver a prova. Dos 36 itens errados deste tópico, 18 mantêm a descrição perfeitamente correta e apenas penduram nela o nome da prática errada. Por isso a regra de leitura é sempre a mesma: leia primeiro o objetivo descrito, depois o nome que o item deu a ele. Se a frase diz restaurar rapidamente, o dono é o incidente; se diz causa, recorrência ou erro conhecido, o dono é o problema — não importa qual nome a banca escreveu.

Por que se usa (e o que custa)

Separar restauração de causa compra velocidade. A central pode reiniciar o serviço, aplicar um contorno conhecido e devolver o usuário ao trabalho em minutos, sem esperar diagnóstico. O preço é que a causa sobrevive: sem alimentar o gerenciamento de problemas com o que se aprendeu, a organização paga o mesmo incidente indefinidamente. Por isso as métricas de problema se medem em incidentes evitados, e não em tempo de atendimento.

O gerenciamento de mudanças faz o negócio inverso: compra segurança com atraso. Cada avaliação de risco e cada autorização custam tempo que o negócio nem sempre tem. A resposta da ITIL a esse custo são os três tipos de mudança — não uma exceção ao controle, mas três ritos distintos para o mesmo controle.

Como funciona

Incidente. Interrupção não planejada de um serviço ou redução da qualidade acordada — a segunda metade da definição é a que decide itens: lentidão só é incidente se ultrapassar a meta do acordo de nível de serviço. O fluxo vai da detecção e do registro à classificação e priorização (por impacto e urgência), diagnóstico, escalonamento quando necessário, resolução, encerramento e revisão do incidente — que continua sendo do gerenciamento de incidentes, não migra para o problema. Na classificação inicial o agente já pode indicar solução previamente definida para aquele tipo de incidente.

Problema. Causa, ou causa potencial, de um ou mais incidentes. A prática tem três fases: identificação do problema, controle do problema (análise e documentação de soluções de contorno) e controle de erro (gerir o erro conhecido até a eliminação, o que se faz abrindo requisição de mudança). Atua de forma reativa, sobre incidentes já ocorridos, e proativa, sobre riscos ainda não materializados. O gerenciamento de problemas não altera o ambiente por conta própria: ele propõe, o gerenciamento de mudanças implanta.

Erro conhecido é problema já analisado, com causa documentada e, em regra, solução de contorno registrada. Cuidado com o par vizinho do glossário: erro é a falha ou vulnerabilidade que pode causar incidentes; falha é a perda da capacidade de operar conforme a especificação.

Requisição de serviço. Solicitação de usuário que inicia uma ação de serviço já acordada, parte normal da prestação: pedido de informação, de acesso, de item padronizado, de reinício previsto. É padronizável e, de preferência, automatizada. A central de serviços não é nenhuma dessas práticas: é o ponto único de contato que recebe incidente e requisição e encaminha cada um ao seu dono.

Mudança. Adição, modificação ou remoção de qualquer coisa que possa afetar serviços — inclusive a criação de um serviço novo, e não apenas a alteração do que já está em produção. Três tipos:

padrão — baixo risco, procedimento conhecido, pré-autorizada; dispensa nova avaliação porque já foi avaliada uma vez, ao ser transformada em padrão;
normal — segue o rito completo: agendamento, avaliação de risco e autorização pela autoridade de mudança;
emergencial — rito acelerado, autoridade específica para emergências, documentação que pode ser completada depois. Acelera a autorização; não a suprime.

Nenhum tipo dispensa plano de remediação — o que fazer se a implantação falhar. E mudança vinda de projeto ou de programa não escapa do controle: a integração entre mudança e gerenciamento de projetos existe exatamente para isso.

Nível de serviço. O gerenciamento de nível de serviço define, documenta, negocia e monitora as metas acordadas. Três instrumentos, e a direção do apoio é fixa:

SLA / ANS — provedor × cliente. É a promessa.
OLA / ANO — provedor × outra área da mesma organização. Sustenta a promessa por dentro.
UC / contrato de apoio — provedor × fornecedor externo. Sustenta a promessa por fora.

OLA e UC existem para que o SLA seja cumprido, nunca o contrário. E o SLA é o que define o que é operação normal: sem meta escrita, não há como afirmar que houve degradação.

Utilidade × garantia. Utilidade é a funcionalidade — o que o serviço faz, adequação ao propósito. Garantia é desempenho, disponibilidade, capacidade, continuidade e segurança — como o serviço se comporta, adequação ao uso. Em português as duas expressões soam iguais; na ITIL são opostas.

v3 × v4 no vocabulário. Cadernos anteriores a 2019 falam em processos distribuídos por cinco estágios do ciclo de vida (Estratégia, Desenho, Transição, Operação, Melhoria Continuada); a partir de 2019 fala-se em práticas e em cadeia de valor de serviço. O conteúdo de incidente, problema, mudança e nível de serviço praticamente não mudou entre as duas — o que muda é o rótulo e a casa. Nos itens de v3, guarde a lotação: incidente, problema, evento, acesso e cumprimento de requisição ficam na Operação; nível de serviço, catálogo, capacidade, disponibilidade, continuidade, fornecedor e segurança ficam no Desenho; mudança, liberação e implantação e configuração ficam na Transição.

O que decide os itens

×	resolve-se assim
incidente × problema	restaurar rápido é incidente; causa, recorrência, erro conhecido é problema
incidente × requisição	houve interrupção não planejada ou queda abaixo do acordado? incidente. O usuário pediu algo previsto? requisição
problema × evento	evento detecta e pode até abrir o chamado; quem investiga causa é o problema
problema × mudança	o problema propõe e registra o erro conhecido; a mudança implanta a correção
incidente × mudança	abrir mudança não é etapa obrigatória do diagnóstico do incidente
revisão do incidente × investigação do problema	a revisão é do incidente; a investigação da causa é do problema
SLA × OLA × UC	cliente / área interna / fornecedor externo — e os dois últimos apoiam o primeiro
utilidade × garantia	propósito, o que faz / uso, desempenho e disponibilidade
catálogo × portfólio	catálogo traz o serviço ativo e acordado; portfólio traz também o funil e os obsoletos
catálogo de negócio × catálogo técnico	o cliente vê serviços e processos de negócio; itens de configuração ficam na visão técnica
configuração × liberação	a configuração registra o que existe; a liberação e implantação colocam em produção
mudança padrão × emergencial	a padrão é pré-autorizada; a emergencial é autorizada em rito abreviado
norma × framework	a ISO/IEC 20000 traz requisitos certificáveis e independe de framework; a ITIL é orientação

conceito	definição que a banca cobra literalmente
incidente	interrupção não planejada de um serviço ou redução da qualidade acordada
problema	causa, ou causa potencial, de um ou mais incidentes
erro conhecido	problema com causa documentada e, em regra, solução de contorno registrada
solução de contorno	restabelece o serviço sem eliminar a causa; produzida pelo problema, aplicada pelo incidente
requisição de serviço	solicitação de usuário que é parte normal da entrega do serviço
mudança	adição, modificação ou remoção de qualquer coisa que possa afetar serviços
SLA	acordo documentado entre provedor e cliente com as metas de serviço

Como a CEBRASPE derruba você aqui

Metade dos itens errados é troca de prática: 18 dos 36. A descrição continua correta e só o nome muda de dono — “implantar o processo gerenciamento de problema” para restaurar o serviço, “O objetivo do gerenciamento de problemas” antes da definição literal de incidente, “tem como foco principal a identificação e resolução da causa raiz dos incidentes” dentro de um item sobre incidentes, “deve ser gerenciada pela prática de gerenciamento de incidente” para uma requisição rotineira, “recomenda-se o processo de gerenciamento de eventos” para incidentes recorrentes. Seis dessas trocas são exatamente incidente × problema, e elas vêm nos dois sentidos — ora dão a causa raiz ao incidente, ora dão a restauração rápida ao problema. Defesa: sublinhe o objetivo descrito antes de ler o nome da prática e julgue o objetivo, nunca o rótulo.

Depois vem a negação de um dever: 7 itens. A banca pega uma exigência real e a dissolve — “prescindindo-se a análise da causa raiz e a prevenção de ocorrência de incidentes”, “dispensa o conhecimento de níveis de serviço e SLA”, “será desnecessário elaborar um plano de mediação”, “sem necessidade de aprovação”, “não deve ser integrado com o gerenciamento de grandes projetos e programas empresariais”. Neste tópico a restrição quase nunca chega como advérbio absoluto: somente derruba um único item em 36. Ela chega como verbo negado — prescinde, dispensa, é desnecessário, não deve, sem necessidade de. Treine o olho para esses verbos, não para sempre e nunca.

O número que confirma isso: das 16 afirmações restritivas do tópico, 15 são Erradas. A única restritiva Certa é “uma solicitação de serviços que não tenha sido originada de um incidente” — e ela é Certa porque a restrição é da definição de cumprimento de requisição, não do examinador. Vale o mesmo para “independentemente da causa raiz do incidente”, também Certo: é a ITIL que diz isso. A pergunta útil nunca é há um absoluto aqui?, e sim de quem é este absoluto — do framework ou de quem escreveu o item.

Terceiro: o par definido, invertido. 4 itens. Utilidade e garantia trocadas (duas vezes), SLA e OLA com o apoio de cabeça para baixo, erro e falha com as definições certas e os rótulos permutados. As definições ficam intactas; só os nomes andam. Defesa: para cada par, recite a definição do primeiro termo antes de ler a do item.

Quarto, e mais sutil: a definição amputada. 3 itens. O item reproduz metade de uma definição oficial e corta a outra — “prescindindo-se da demanda futura” no gerenciamento de capacidade, a lista de contribuições do problema à cadeia de valor sem a atividade melhorar. Defesa: quando o item enunciar uma definição da ITIL, reconstrua a definição inteira de memória e veja o que falta.

Uma coisa que este tópico não faz. A modalidade permissiva não prevê nada aqui: pode e podem aparecem em 2 itens Certos e em 5 Errados. E nenhum item do tópico se decide por número — não há prazo, percentual ou versão alterada entre os 36 errados. Não perca tempo procurando.

Erros clássicos

Achar que fechar incidente com solução de contorno é errado. É o resultado esperado quando a causa ainda não foi eliminada. Item que exija causa raiz para encerrar incidente está errado.

Achar que o incidente vira problema. Ele pode originar um problema, e essa ponte é opcional; o registro do incidente segue a própria vida, com revisão e encerramento próprios.

Dar ao problema a execução da correção. O problema identifica, documenta o erro conhecido e abre requisição de mudança. Quem altera o ambiente é o gerenciamento de mudanças, sempre.

Confundir mudança emergencial com mudança sem controle. Emergencial tem autoridade própria e rito abreviado; pré-autorizada é a padrão, e mesmo ela foi avaliada uma vez.

Inverter quem apoia quem no nível de serviço. OLA e contrato de apoio sustentam o SLA. A recíproca não existe.

Chamar de SLA o acordo entre duas áreas da mesma organização. É OLA. Leia quem são as duas partes antes de nomear o documento.

Trocar utilidade por garantia porque adequado ao uso soa como utilidade. Uso remete a garantia; propósito remete a utilidade.

Dar ao catálogo o funil de serviços. Serviço em desenvolvimento ou aposentado é portfólio. O catálogo só responde pelo serviço ativo e acordado.

Fazer a ISO/IEC 20000 adotar a ITIL. A norma estabelece requisitos auditáveis e é independente de framework; a ITIL é biblioteca de boas práticas e nunca foi certificável para a organização.