Gestão de serviços de TI e ITIL 4 (catálogo, incidentes, problemas, mudanças e configuração)

Do zero

Na lição de COBIT, o ITIL 4 apareceu como o manual da equipe de manutenção do condomínio. Agora vamos abrir esse manual. Imagine a zeladoria de um prédio grande:

• O quadro da portaria lista o que o condomínio oferece: reserva do salão, entrega de encomendas, cópia da chave da garagem, conserto na área comum. Diz quem pode pedir, como pedir e em quanto tempo sai. É o catálogo de serviços.
• A portaria recebe todo pedido e toda reclamação, por interfone, aplicativo ou no balcão. É a central de serviço, o ponto único de contato.
• O elevador parou com gente dentro. O zelador não vai estudar o motor agora: tira as pessoas e faz o elevador andar. É um incidente, e a meta é restaurar o serviço o mais rápido possível.
• O elevador para toda vez que chove. Alguém precisa descobrir por quê: a calha entupida joga água na casa de máquinas. Essa causa é o problema. Enquanto o conserto não sai, o zelador desliga o elevador social antes da chuva e libera o de serviço: é a solução de contorno. Causa conhecida e ainda não corrigida é um erro conhecido.
• Trocar a calha mexe no telhado, custa dinheiro e pode dar errado. O síndico avalia o risco, autoriza e marca a data (não no dia da mudança do 302). É a habilitação de mudança.
• A planta do prédio mostra que a bomba do subsolo abastece as duas torres e que o elevador social depende do disjuntor 12. Sem ela, a obra na calha poderia desligar algo sem ninguém saber. É o gerenciamento de configuração.
• Reservar o salão de festas não é defeito nenhum: é um pedido que faz parte do serviço normal. É uma requisição de serviço, não um incidente.

Frase para guardar: incidente: fazer voltar a funcionar; problema: descobrir por que quebra; mudança: mexer com o risco avaliado e autorizado; configuração: saber o que depende do quê; catálogo: dizer o que se oferece e como pedir.

Em 1 minuto

O texto do ITIL 4 não está em fontes/ (é pago). As definições abaixo são paráfrases das do ITIL 4 Foundation (AXELOS, 2019), e os nomes em português seguem o uso comum em cursos e provas, que pode diferir da tradução oficial [CONFERIR].

A base: serviço, valor e o sistema de valor

• Serviço: meio de possibilitar a cocriação de valor, facilitando os resultados que o cliente quer, sem que ele tenha de gerenciar custos e riscos específicos. Provedor e consumidor criam o valor juntos.
• Utilidade × garantia: utilidade é o que o serviço faz (adequado ao propósito); garantia é como ele funciona, em disponibilidade, capacidade, segurança e continuidade (adequado ao uso). Um serviço precisa dos dois.
• Sistema de Valor de Serviço (SVS): transforma oportunidade e demanda em valor. Tem cinco componentes: princípios orientadores, governança, cadeia de valor de serviço, práticas e melhoria contínua.
• Cadeia de valor de serviço, com seis atividades: planejar, melhorar, engajar, desenho e transição, obter/construir e entrega e suporte. Elas se combinam em fluxos de valor diferentes; não são uma sequência fixa.
• 4 dimensões: organizações e pessoas; informação e tecnologia; parceiros e fornecedores; fluxos de valor e processos. Fatores externos (políticos, econômicos, sociais, tecnológicos, legais e ambientais, o PESTLE) atuam sobre todas.
• 7 princípios orientadores: foco no valor; começar de onde está; progredir iterativamente com feedback; colaborar e promover visibilidade; pensar e trabalhar de forma holística; manter simples e prático; otimizar e automatizar.
• 34 práticas, em três grupos: 14 de gerenciamento geral, 17 de gerenciamento de serviço e 3 de gerenciamento técnico [CONFERIR]. Prática é mais que processo: é um conjunto de recursos da organização para realizar um trabalho ou alcançar um objetivo, e cada prática tem recursos das quatro dimensões (pessoas, informação e tecnologia, fornecedores, fluxos e processos).

           OPORTUNIDADE e DEMANDA
                     │
                     ▼
┌───── SISTEMA DE VALOR DE SERVIÇO (SVS) ─────┐
│ Princípios orientadores (7)                 │
│ Governança                                  │
│ Cadeia de valor de serviço:                 │
│   planejar · melhorar · engajar             │
│   desenho e transição · obter/construir     │
│   entrega e suporte                         │
│ Práticas (34)                               │
│ Melhoria contínua                           │
└─────────────────────────────────────────────┘
                     │
                     ▼
                   VALOR

As práticas do edital (propósito de cada uma, em paráfrase)

• Gerenciamento de catálogo de serviços: oferecer uma fonte única de informações consistentes sobre todos os serviços e ofertas de serviço, disponível ao público pertinente. O catálogo pode ter visões diferentes: a do usuário (o que posso pedir), a do cliente (metas e custos) e a das equipes de TI (serviços de apoio) [CONFERIR].
• Central de serviço: capturar a demanda por resolução de incidentes e por requisições de serviço. É o ponto único de contato do provedor com os usuários, por telefone, portal, chat, chatbot, e-mail ou balcão. Pede empatia e conhecimento do negócio, não só técnica.
• Gerenciamento de requisição de serviço: apoiar a qualidade acordada do serviço, atendendo de forma eficaz e amigável os pedidos pré-definidos feitos pelos usuários, como acesso, equipamento, informação ou troca de toner. A requisição faz parte da entrega normal do serviço; não é falha.
• Gerenciamento de nível de serviço: fixar metas claras, baseadas no negócio, e acompanhar a entrega contra elas. O acordo de nível de serviço (ANS, em inglês SLA) é o acordo documentado entre provedor e cliente sobre os serviços e o nível esperado. Cuidado com o efeito melancia: indicadores verdes por fora, usuário insatisfeito por dentro [CONFERIR].
• Gerenciamento de incidentes: minimizar o impacto negativo dos incidentes, restaurando a operação normal do serviço o mais rápido possível. Todo incidente é registrado e priorizado por uma classificação acordada, para que os de maior impacto no negócio sejam resolvidos primeiro. Na prática, a classificação costuma cruzar impacto (quantos e quanto são afetados) e urgência (quão rápido o dano cresce), uma matriz herdada do ITIL v3. Os incidentes graves têm procedimento próprio.
• Gerenciamento de problemas: reduzir a probabilidade e o impacto dos incidentes, identificando as causas reais e potenciais e gerenciando soluções de contorno e erros conhecidos. Tem três fases: identificação do problema (análise de tendências, incidentes repetidos, avisos de fornecedores), controle do problema (análise, registro de contornos e de erros conhecidos) e controle do erro (busca da solução definitiva, que pode virar uma mudança, se o custo e o risco compensarem).
• Habilitação de mudança (change enablement; o livro de 2019 a chamava de controle de mudança) [CONFERIR]: maximizar o número de mudanças bem-sucedidas, avaliando os riscos, autorizando as mudanças e gerenciando o cronograma de mudanças. Quem autoriza é a autoridade de mudança, definida por tipo de mudança: alguém que decide rápido, muitas vezes com automação, nas de baixo risco; até a alta direção nas de risco muito alto. Em organizações de alta velocidade, o ITIL 4 aponta como prática comum descentralizar a autorização, com revisão por pares. Há três tipos: padrão, normal e emergencial.
• Gerenciamento de configuração de serviço: garantir que informação precisa e confiável sobre a configuração dos serviços e dos itens de configuração (IC) que os sustentam esteja disponível quando e onde for preciso, incluindo as relações entre eles. Os registros costumam ficar numa CMDB (banco de dados de gerenciamento de configuração). Só vale guardar o nível de detalhe que compensa o custo de mantê-lo atualizado.

Exemplo concreto: as segundas-feiras do sistema de prestação de contas

O cenário é fictício. Os órgãos estaduais enviam as prestações de contas ao Tribunal por um sistema web, e o prazo de envio vence hoje, às 18h.

1. Segunda, 8h40. Central de serviço. Chegam 30 chamados em 10 minutos: “o envio da prestação de contas dá erro”. O atendente registra, liga os chamados a um só incidente e o classifica: impacto alto (todos os órgãos) e urgência alta (o prazo vence hoje). Prioridade 1, tratado como incidente grave.
2. 9h10. Gerenciamento de incidentes. A equipe de banco de dados vê o disco do servidor BD-02 cheio, apaga logs antigos e reinicia o serviço. O sistema volta, os usuários confirmam e o incidente é encerrado. Ninguém sabe ainda por que o disco encheu, e tudo bem: a meta era restaurar.
3. Terça. Gerenciamento de problemas: identificação. Pela análise de tendências, um analista nota que é a quarta segunda seguida com o mesmo incidente. Ele abre um registro de problema.
4. Quarta. Controle do problema. A análise mostra a causa: o job semanal de exportação grava logs sem rotação e lota o disco todo domingo à noite. A equipe registra o erro conhecido e a solução de contorno (apagar os logs antigos) na base de conhecimento. Se cair de novo, a central resolve em minutos.
5. Quinta. Controle do erro. A solução definitiva é ligar a rotação de logs e ampliar o disco. O custo é pequeno perto do dano de cada queda, então ela vira uma requisição de mudança.
6. Habilitação de mudança, com a CMDB. É uma mudança normal. Antes de autorizar, a autoridade de mudança consulta a CMDB: o BD-02 sustenta também o sistema de ponto eletrônico. A mudança fica para sábado, às 22h, entra no cronograma de mudanças, e os usuários dos dois sistemas são avisados. Depois, a revisão confirma o sucesso e o problema é encerrado.
7. Nas semanas seguintes. Uma servidora recém-chegada pede acesso ao sistema: é uma requisição de serviço, atendida como o catálogo prevê. Um alerta de “disco em 85%” é um evento: avisa antes que vire incidente.

Usuário ──► CENTRAL DE SERVIÇO: registra e classifica
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
    REQUISIÇÃO              INCIDENTE ──► serviço restaurado
  (pedido normal)               │
                                │ repete ou é grave
                                ▼
                             PROBLEMA ──► erro conhecido
                                │         e solução de contorno
                                │ solução definitiva
                                ▼
                             MUDANÇA ◄── CMDB: o que
                                │        depende do quê
                                ▼
                   avaliar, autorizar, agendar

O serviço no catálogo (metas fictícias, só para o exemplo):

Comparação: os termos e as práticas que se confundem

Questões antigas usam o vocabulário do ITIL v3 [CONFERIR: o ITIL v3 também não está em fontes/]:

A gestão de ativos de TI, o portfólio de serviços e a continuidade estão na lição de portfólio e ativos.

Como a FCC cobra

• O propósito de cada prática, com os das práticas vizinhas como alternativas erradas.
• Requisição de serviço × incidente em situações do dia a dia.
• Central de serviço como ponto único de contato.
• Catálogo de serviços e acordo de nível de serviço.
• Componentes do SVS, atividades da cadeia de valor e as 4 dimensões.
• Vocabulário do ITIL v3 em questões mais antigas.

Pegadinhas

Explique com suas palavras

Explique a um colega da auditoria a diferença entre incidente e problema e por que a correção definitiva passa pela habilitação de mudança e pela CMDB.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Incidente é o sistema parado agora, com usuário reclamando. A equipe de incidentes quer uma coisa só: fazer o serviço voltar o quanto antes, nem que seja reiniciando o servidor. Problema é a causa por trás dos incidentes, como um log que lota o disco toda semana. A equipe de problemas investiga essa causa e, enquanto não corrige, deixa anotado um jeito de contornar: é o erro conhecido com a solução de contorno.

A correção definitiva mexe no ambiente, e mexer pode derrubar outras coisas. Por isso ela vira uma mudança: alguém com autoridade avalia o risco, autoriza e marca a hora certa. Para avaliar o risco, a equipe olha a CMDB, que mostra o que depende do quê. Foi assim que se descobriu que o mesmo servidor também sustentava o sistema de ponto, e que os usuários dele precisavam ser avisados.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso sobre um sistema crítico que cai com frequência, ou sobre a contratação de uma central de serviço, organize a resposta pelas práticas. Descreva o serviço no catálogo, com metas acordadas no ANS. Ponha a central de serviço como ponto único de contato e priorize os incidentes por impacto e urgência. Trate os incidentes repetidos no gerenciamento de problemas, com erro conhecido e solução de contorno na base de conhecimento. Leve a correção definitiva por mudança normal, com análise de impacto na CMDB e janela no cronograma.

Se a central for terceirizada, use como referência a IN SGD/ME nº 94/2022. Ela obriga só os órgãos e entidades do SISP (art. 1º), do qual o TCE-GO não faz parte. Pede, quando possível, pagamento em função dos resultados (art. 18, IV), critérios de aceitação com níveis mínimos de serviço (art. 19, I) e glosa quando a contratada não atingir os valores mínimos aceitáveis (art. 19, III, a).

Fontes da lição

• Edital nº 01/2026, Anexo II, Governança de Tecnologia da Informação (fontes/edital-01-2026.txt).
• AXELOS, ITIL Foundation, ITIL 4 edition (2019) e guias de prática do ITIL 4 [CONFERIR: o texto não está em fontes/; as definições desta lição são paráfrases, e os nomes em português, os do uso comum].
• Instrução Normativa SGD/ME nº 94/2022, art. 1º, art. 2º, XXVI, art. 18, IV, e art. 19, I e III, a (fontes/normas/in-sgd-me-94-2022-contratacoes-tic.txt).