HDI Brasil· Gestão de Serviços de TI
Curso de 16h · Integrado ao ITIL 5 e HDI SCC
Observabilidade Aplicada à Gestão de Serviços de TI
Uma operação observável detecta mais cedo, aprende mais rápido, planeja melhor e demonstra valor de forma mensurável.
Em 16 horas, você sai do monitoramento que só avisa para a Observabilidade que explica: alertas acionáveis, dashboards de decisão, runbooks, indicadores e maturidade, integrados a ITIL 5, HDI SCC, SRE, NOC/SOC, GRC e FinOps.
CPU acima de 75% em qualquer servidor, sem impacto, sem dono e sem runbook.
- impacto
- não definido
- dono
- não definido
- runbook
- não definido
Latência P99 da API de autenticação acima de 1,5 segundo por 10 minutos, afetando a jornada de login, com runbook e dono definidos.
- jornada
- login
- dono
- definido
- runbook
- definido
- recuperação
- P99 abaixo do limite por 15 min
Sua operação vive isso?
Oito sintomas de uma operação que ainda só monitora
Se você reconheceu pelo menos um, este curso foi desenhado para a sua realidade. Cada sintoma é tratado em um módulo específico.
“O usuário reclama antes do monitoramento avisar.”
Na operação reativa, a primeira detecção é o chamado. O curso ensina a medir e aumentar o percentual de incidentes detectados antes do usuário.
→ Módulos 10 e 14
“Centenas de alertas, e ninguém sabe qual importa.”
Alert fatigue: quando tudo parece crítico, nada é crítico. Você aprende a criar alertas que orientam ação e a correlacionar eventos em um só incidente.
→ Módulos 4 e 7
“O ticket chega sem informação e a causa raiz demora a aparecer.”
Com Observabilidade, o incidente já nasce enriquecido com serviço afetado, sintomas, métricas, logs, traces, impacto provável e runbook recomendado.
→ Módulo 2
“A infraestrutura está verde e o usuário continua sofrendo.”
A média de resposta pode estar normal enquanto o P99 dispara. Disponibilidade técnica não basta: é preciso medir a experiência percebida.
→ Módulos 1 e 3
“No incidente, cada analista improvisa.”
Sem runbook, cada um faz de um jeito. Sem playbook, as equipes agem sem coordenação. Padronizar reduz erro humano e acelera a resposta.
→ Módulo 6
“NOC, SOC e Engenharia esperando um pelo outro.”
Sem papéis claros, o alerta fica sem dono, a comunicação se perde e o incidente atrasa. A matriz RACI define quem executa, aprova, é consultado e informado.
→ Módulo 9
“Logs guardando CPF e token de sessão.”
Dados de Observabilidade são ativos corporativos. A evidência operacional não pode criar um novo risco de privacidade ou segurança.
→ Módulo 8
“O custo de nuvem e IA sobe sem explicação.”
Observabilidade revela uso real, desperdício e custo por transação, atendimento ou inferência, conectando operação a FinOps.
→ Módulo 16
Quando tudo parece crítico, nada é crítico.
— Módulo 4, sobre alert fatigue
A virada
Da operação reativa à operação preditiva
Observabilidade não é mais um painel. É o que muda a forma como sua operação detecta, planeja e decide.
Resultados esperados
Confiabilidade
Menor MTTD, menor MTTR e melhor previsibilidade operacional.
Experiência
Menos impacto percebido pelo cliente e comunicação mais clara.
Segurança
Maior capacidade de detecção e investigação pelo SOC.
Governança
Menor risco de LGPD, vazamento e coleta excessiva.
Melhoria contínua
Redução de reincidência e maturidade crescente.
Casos que você vai analisar
Oito situações de operação, do sintoma ao aprendizado
O curso conduz do conceito para a aplicação. Estes são alguns dos cenários trabalhados ao longo dos módulos.
A média escondia o problema
Cliente relata lentidão na consulta de saldo, mas a média de resposta está normal.
O P99 subiu para 3 segundos. O trace mostra demora em uma consulta de banco e o log indica timeout intermitente.
A média escondia a cauda de latência. A Observabilidade localizou a dependência que afetava parte dos usuários.
Servidores no ar, usuário insatisfeito
A infraestrutura está disponível, mas o DEX Score cai após a atualização de um aplicativo corporativo.
Os indicadores técnicos não mostravam nada. A experiência percebida, sim.
Disponibilidade técnica não basta. É preciso medir tempo de resposta, erro funcional e satisfação.
Dezenas de alertas, um único incidente
Timeouts em três APIs, queda no checkout e alertas de fila disparam ao mesmo tempo.
Todos os eventos começaram no mesmo minuto e pertencem à jornada de pagamento.
Um único incidente correlacionado, com causa provável no banco de dados saturado.
O log que virou risco
Um log de aplicação registra CPF, e-mail e token de sessão.
Mascarar o CPF, remover o token, limitar acesso por perfil, criptografar o armazenamento e definir retenção.
A evidência operacional não pode criar um novo risco de privacidade ou segurança.
Ataque ou bug?
O NOC identifica erro de autenticação, o SOC suspeita de ataque e a Engenharia aponta falha de aplicação.
NOC coordena a triagem, SOC avalia o risco, Engenharia verifica o código, SRE analisa a confiabilidade e o dono do serviço decide a prioridade.
Papéis claros reduzem conflito e aceleram a resposta.
O incidente que ainda não aconteceu
A latência P99 de uma API crítica cresce toda segunda de manhã. A saturação de conexões sobe 15% por semana após uma campanha.
A capacidade atual suporta dias normais, mas está no limite nos picos. A demanda é projetada para 60 dias.
Nem todo alerta de capacidade é incidente imediato, mas todo sinal persistente de saturação deve alimentar planejamento e melhoria.
A IA errou sem nenhuma falha técnica
Um modelo de priorização passa a classificar incidentes de uma nova aplicação como baixa prioridade. Tudo está no ar.
A Observabilidade de Dados detecta mudança de schema e queda de completude. A Observabilidade de IA mostra redução de precisão.
Um sistema pode estar disponível e ainda gerar dano operacional se consumir dados incompletos ou inconsistentes.
Custo de IA +40% em um mês
Disponibilidade normal e satisfação em alta, mas o custo da plataforma de atendimento com IA cresce 40%.
Mais tokens por conversa, baixa taxa de cache, chamadas redundantes e modelo premium usado em interações simples.
Roteamento entre modelos, cache semântico e limite de contexto: eficiência sem perder qualidade nem experiência.
Quer levar esse raciocínio para a sua operação?
A venda ainda não abriu. Garanta seu lugar na lista de pré-inscrição.
Alertas que geram ação
Menos ruído, mais decisão
Você aprende quando usar cada tipo de alerta e a definir severidade pelo impacto no negócio, não só pelo limite técnico.
01
Thresholds estáticos
Limites fixos, como CPU acima de 90%. Simples, mas geram ruído se ignorarem o contexto.
02
Baselines dinâmicos
Comparam o comportamento atual com a linha histórica do serviço, por horário, dia, sazonalidade ou volume.
03
Detecção de anomalias
Identifica desvios sem depender só de limites estáticos. Útil para padrões desconhecidos e segurança.
04
Alertas por SLO, SLA e experiência
Priorizam impacto no usuário e no negócio, como latência P99 acima do objetivo.
| Exemplo de alerta | Tipo | Severidade sugerida | Ação esperada |
|---|---|---|---|
| CPU acima de 90% por 10 min | Threshold estático | Média | Validar saturação e escala. |
| Latência P99 acima de 2s | SLO / experiência | Alta | Acionar runbook de performance. |
| HTTP 5xx acima de 5% | Erro de aplicação | Alta | Investigar deploy, dependências e logs. |
| Queda de transações acima de 20% | Negócio | Crítica | Acionar sala de crise. |
| Falhas de autenticação +300% | Segurança | Alta / Crítica | Acionar SOC e Segurança. |
Um alerta de qualidade não diz apenas que algo mudou. Ele diz por que importa, qual serviço é afetado, quem deve agir, qual runbook usar e como validar a recuperação.
Alertas devem ser úteis para decidir, não apenas para notificar.
Checklist de qualidade de alertas que você leva
Indicadores
Prove valor com números que a liderança entende
Indicadores transformam percepção em gestão. Você aprende a fórmula, a interpretação e a decisão por trás de cada um.
MTTD
Tempo médio para detectar
Σ tempos de detecção ÷ nº de incidentes
Se está alto, a equipe descobre tarde. Revise alertas e cobertura.
MTTA
Tempo médio para reconhecer
Σ tempos de aceite ÷ nº de incidentes
Se está alto, há fila, falta de dono ou excesso de alertas.
MTTR
Tempo médio para restaurar
Σ tempos de recuperação ÷ nº de incidentes
Se está alto, runbooks, automação, escalonamento ou arquitetura precisam evoluir.
P95 / P99
Experiência no pior caso
Percentil de latência
Se o P99 piora e a média está normal, parte dos usuários está sofrendo.
% antes do usuário
Detecção proativa
Detectados por telemetria ÷ total de incidentes
Mostra se a operação está saindo do modelo dependente de chamado.
Antecipação
Tempo médio de antecipação
Detecção proativa antes do impacto percebido
Traduz Observabilidade em ganho concreto de tempo para a liderança.
Reincidência
Taxa de reincidência
Incidentes recorrentes ÷ total
Se está alta, Problem Management e correção estrutural estão fracos.
Acionáveis
% de alertas acionáveis
Alertas úteis ÷ total de alertas
Se está baixo, há ruído e alert fatigue.
DEX Score
Experiência digital percebida
Índice composto definido pela organização
Se cai com infraestrutura disponível, investigue jornada, endpoint, rede e aplicação.
Na prática
A falha começou às 10h00 e foi detectada às 10h08. MTTD deste incidente: 8 minutos.
Proatividade medida
Exemplo do Módulo 14: em um trimestre, 36 de 60 incidentes relevantes foram detectados antes do chamado do usuário. A detecção proativa subiu de 42% para 60%.
Nenhum indicador deve ser analisado isoladamente. MTTR baixo com reincidência alta pode indicar boa resposta, mas pouca solução definitiva. Volume alto de alertas pode ser boa cobertura ou excesso de ruído.
Use indicadores para priorizar melhoria, nunca para punir equipes.
Dashboards
Um painel para cada decisão
Dashboard não é coleção de gráficos. É ferramenta de decisão: qual serviço está em risco, qual o impacto, o que mudou e quem deve agir.
Pergunta que o curso vai te fazer
Qual pergunta o seu dashboard precisa responder em menos de 30 segundos?
Resposta a incidentes
A anatomia de um runbook que funciona
Em incidentes, tempo é crítico. Você sai com um modelo de oito campos para padronizar diagnóstico, mitigação, escalonamento e evidências.
01
Nome do alerta
Nome padronizado: serviço + sintoma + condição.
02
Sintoma
O que foi observado, sem inferir causa prematuramente.
03
Impacto
Serviço, jornada, usuários, região ou negócio afetado.
04
Diagnóstico
Consultas de métricas, logs, traces, dependências e mudanças recentes.
05
Mitigação
Apenas ações seguras, testadas e autorizadas.
06
Recuperação
Critério objetivo, como P99 normal por 15 minutos.
07
Escalonamento
Quando acionar SRE, Engenharia, SOC, fornecedor ou gestão.
08
Evidências
Gráficos, logs, traces, ticket, horário, responsável e decisão.
Runbook de exemplo · API com alta latência
Validar P99, verificar taxa de erro, abrir o trace, comparar com deploy recente, checar banco e dependências e aplicar mitigação segura. Recuperação: P99 abaixo do limite por 15 minutos e taxa de erro normalizada.
Runbook ou playbook?
O runbook orienta a execução; o playbook organiza pessoas, canais, decisões e comunicação. Sem runbook, cada analista improvisa. Sem playbook, as equipes agem sem coordenação.
Régua de maturidade
Em que nível está a sua operação?
Uma organização pode ter uma plataforma avançada e ainda operar de forma reativa. Você aprende a identificar o próximo passo viável e a montar um plano de 30-60-90 dias.
Nível 1
Básico e reativo
Monitoramento pontual, pouca padronização e dependência individual.
MTTR alto
Mapear serviços críticos.
Nível 2
Estruturado
Alertas e dashboards, com NOC e Suporte atuantes em eventos e incidentes.
MTTD e MTTR
Padronizar runbooks.
Nível 3
Integrado
ITSM, SRE e automação, com problemas, mudanças e SLO e times integrados.
SLO, automação, reincidência
Integrar GRC e segurança.
Nível 4
Preditivo e governado
AIOps, experiência e auto-healing, com melhoria contínua avançada.
DEX, error budget, predição
Otimização contínua.
Diagnóstico de exemplo
Um serviço tem dashboard e alertas, mas não tem runbook nem integração com ITSM. Nível provável: 2. Próximo passo: criar runbooks, vincular alertas a tickets e definir SLOs básicos.
Conteúdo programático
Módulo a módulo
Cada módulo responde a quatro perguntas — o que é, por que importa, como aplicar e quais cuidados observar — e termina com um produto aplicável na sua operação.
01Fundamentos de ObservabilidadeO que é Observabilidade?
Compreender o conceito, diferenciar Monitoramento de Observabilidade e reconhecer métricas, logs, traces, eventos e sintomas.
- Definir quais serviços e jornadas precisam ser observados.
- Padronizar métricas, logs e traces desde o desenho da aplicação.
- Usar correlation ID para conectar a mesma transação em diferentes camadas.
- Usar percentis P95 e P99 para entender os usuários mais impactados.
- Tratar Observabilidade como sinônimo de ferramenta.
- Coletar muitos dados sem contexto ou dono.
- Usar apenas a média de latência para avaliar experiência.
Produto de aprendizagemMapa de sinais
02Observabilidade no contexto do ITIL 5Como ela se conecta ao ITIL 5?
Conectar Observabilidade às práticas de Gestão de Serviços, incluindo eventos, incidentes, problemas, mudanças e melhoria contínua.
- Definir critérios objetivos para evento, alerta, incidente e problema.
- Integrar alertas ao ITSM para abrir ou enriquecer tickets automaticamente.
- Associar cada alerta a serviço, jornada, criticidade, dono e runbook.
- Usar dados históricos para identificar reincidência e abrir Problem Records.
- Abrir incidente para todo evento sem avaliar impacto.
- Tratar reincidência apenas como novo incidente.
- Criar alertas sem vínculo com serviço ou jornada.
Produto de aprendizagemFluxo evento → incidente → problema → mudança
03Conexão com HDI Support Center CertificationComo apoia o HDI SCC?
Explicar como Observabilidade apoia excelência operacional, experiência do usuário, incidentes e problemas no contexto HDI SCC.
- Relacionar eventos monitorados ao item 5.010 Gestão de Eventos.
- Usar jornada, DEX e disponibilidade percebida no item 5.020 Experiência.
- Enriquecer incidentes com evidências para o item 5.060.
- Usar tendências, RCA e reincidência no item 5.130 Problemas.
- Usar apenas SLA técnico para representar experiência.
- Manter evidências soltas fora do ticket.
- Não traduzir indicadores para linguagem de suporte e negócio.
Produto de aprendizagemEvidências por item HDI
04Modelagem de alertasComo criar alertas úteis?
Aprender a criar alertas acionáveis, com prioridade baseada em impacto, urgência, serviço, experiência e risco.
- Usar thresholds estáticos para limites claros e técnicos.
- Usar baselines dinâmicos para serviços com sazonalidade.
- Usar detecção de anomalias para padrões desconhecidos ou segurança.
- Exigir dono, severidade, prioridade, runbook e critério de recuperação.
- Criar alerta para toda métrica coletada.
- Não revisar falsos positivos.
- Não diferenciar severidade técnica de prioridade do negócio.
Produto de aprendizagemModelo de qualidade de alertas
05Dashboards para tomada de decisãoComo desenhar dashboards?
Projetar dashboards adequados para liderança, NOC, SOC, SRE, aplicações, capacidade e experiência do usuário.
- Começar definindo o público-alvo e a decisão que o painel apoia.
- Escolher poucos indicadores realmente relevantes.
- Organizar visão de resumo, tendência e drill-down.
- Revisar mensalmente se o dashboard ainda gera ação.
- Usar o mesmo dashboard para todos os públicos.
- Exibir métricas sem interpretação.
- Criar painéis que ninguém usa.
Produto de aprendizagemPainéis por público e decisão
06Runbooks e playbooksComo responder melhor?
Padronizar diagnóstico, mitigação, comunicação, escalonamento e pós-incidente.
- Criar runbooks para alertas críticos e recorrentes.
- Incluir passos de diagnóstico antes da mitigação.
- Definir critérios objetivos de recuperação e evidências obrigatórias.
- Usar playbooks para incidentes críticos, segurança, comunicação executiva e crise.
- Automatizar antes de testar manualmente.
- Não definir rollback.
- Não revisar o runbook depois de um incidente real.
Produto de aprendizagemRunbook e playbook
07Correlação, filtragem e redução de ruídoComo reduzir ruído?
Entender como eventos de várias camadas podem ser agrupados em incidentes correlacionados.
- Agrupar eventos por serviço, jornada, item de configuração, dependência e tempo.
- Usar correlation ID em logs e traces.
- Aplicar deduplicação e janelas de correlação contra tempestade de alertas.
- Usar AIOps como apoio, mantendo governança sobre decisões automáticas.
- Tratar cada alerta como incidente independente.
- Confiar cegamente em IA sem validação.
- Eliminar alertas importantes junto com o ruído.
Produto de aprendizagemRegras de correlação e deduplicação
08Segurança, GRC e Compliance em ObservabilidadeComo proteger dados?
Entender os riscos dos dados de Observabilidade e aplicar controles de privacidade, segurança, retenção, acesso, auditoria e LGPD.
- Classificar quais dados podem aparecer em logs e traces.
- Proibir senhas, tokens, segredos e dados sensíveis em texto claro.
- Usar mascaramento e anonimização e definir retenção por criticidade.
- Auditar acessos, consultas, exportações e mudanças de configuração.
- Coletar payload completo sem necessidade.
- Manter logs por tempo indefinido.
- Permitir acesso amplo a dados sensíveis.
Produto de aprendizagemControles GRC/LGPD
09Responsabilidades entre equipesQuem faz o quê?
Definir papéis de Suporte, NOC, SOC, SRE, Engenharia, Governança, Segurança e donos de serviço.
- Definir dono para cada serviço e alerta crítico.
- Usar RACI para alerta, incidente, problema, mudança e compliance.
- Criar critérios claros de escalonamento.
- Registrar evidências de decisão, não apenas evidências técnicas.
- Não definir owner de alerta.
- Misturar responsabilidade de execução com aprovação.
- Deixar Governança e Segurança fora dos dados de Observabilidade.
Produto de aprendizagemRACI operacional
10Indicadores de Observabilidade e Gestão de ServiçosComo medir valor?
Medir detecção, resposta, restauração, reincidência, automação, experiência e confiabilidade.
- Definir fórmula, fonte e dono de cada indicador.
- Analisar indicadores por serviço, criticidade e período.
- Combinar métricas técnicas com experiência e impacto de negócio.
- Criar visão operacional e visão executiva dos KPIs.
- Usar KPI como punição.
- Comparar equipes sem contexto de criticidade.
- Não separar incidentes detectados pelo usuário dos detectados automaticamente.
Produto de aprendizagemKPIs e interpretação
11Fluxos integrados práticosComo aplicar em cenários reais?
Aplicar Observabilidade em cenários completos envolvendo API crítica, jornada digital e anomalia de segurança.
- API crítica lenta: P99 acima do limite, traces apontam banco lento.
- Erro em jornada digital: HTTP 5xx no pagamento, logs indicam falha em integração.
- Anomalia de segurança: falhas de login +300%, SOC identifica padrão suspeito.
- Pós-incidente: lições aprendidas, problema, melhoria e revisão de indicadores.
- Encerrar incidente sem lições aprendidas.
- Comunicar apenas tecnicamente para a liderança.
- Não abrir problema em reincidências.
Produto de aprendizagemFluxo integrado
12Maturidade em ObservabilidadeComo evoluir maturidade?
Avaliar o estágio atual e construir plano de evolução com foco em pessoas, processos, tecnologia, dados e governança.
- Avaliar serviços críticos por nível de maturidade.
- Identificar lacunas em pessoas, processos, dados, tecnologia e governança.
- Priorizar a evolução por risco e impacto de negócio.
- Definir um plano de 30-60-90 dias e medir avanço com KPIs.
- Confundir aquisição de ferramenta com maturidade.
- Querer chegar ao nível 4 sem estabilizar fundamentos.
- Não medir valor após as melhorias.
Produto de aprendizagemRoadmap 30-60-90 dias
13Observabilidade integrada a Capacity Management e Availability ManagementComo apoiar capacidade e disponibilidade?
Conectar Observabilidade às práticas de Capacity and Performance Management e Availability Management, com telemetria, tendências, SLIs, SLOs e dados históricos.
- Mapear serviços críticos, jornadas, dependências e pontos únicos de falha.
- Criar baselines por horário, dia da semana, sazonalidade, campanha ou fechamento.
- Usar tendência de consumo para forecast, evitando falta e excesso de recursos.
- Relacionar alertas de saturação a risco de indisponibilidade.
- Usar média de consumo sem analisar picos, percentis e sazonalidade.
- Medir disponibilidade só por servidor ativo, ignorando o usuário.
- Não transformar tendência de saturação em backlog preventivo.
Produto de aprendizagemMapa capacidade-disponibilidade-confiabilidade
14Indicadores de proatividade e maturidade operacionalComo medir proatividade operacional?
Complementar os indicadores tradicionais com métricas que mostrem a evolução para uma operação preventiva, preditiva e orientada por confiabilidade.
- % de incidentes detectados antes do usuário.
- % de incidentes prevenidos por ação preventiva.
- Tempo médio de antecipação.
- % de alertas críticos com runbook válido e % de serviços com SLO definido.
- Qual percentual dos incidentes ainda é descoberto pelo usuário?
- Quais jornadas críticas dependem de reclamação para serem detectadas?
- Como provar que uma ação preventiva evitou um incidente real?
Produto de aprendizagemIndicadores de proatividade e maturidade
15Evolução para Observabilidade de Dados e Inteligência ArtificialComo aplicar Observabilidade em dados e IA?
Introduzir Data Observability, Data Reliability Engineering e Observabilidade aplicada à IA, conectando qualidade, linhagem, freshness, Data SLAs, métricas de modelo, riscos e governança.
- Data Observability: qualidade, freshness, volume, schema, linhagem e impacto downstream.
- Data Reliability Engineering: Data SLI, SLO, SLA, incidentes e postmortems de dados.
- IA em produção: drift de dados e de modelo, qualidade de resposta, abuso e custo.
- Como a Observabilidade gera evidências para o NIST AI RMF.
- Quais dados críticos alimentam decisões operacionais ou modelos de IA?
- Como detectar um modelo disponível, mas operacionalmente menos confiável?
- Que evidências são necessárias para auditar uma decisão automatizada?
Produto de aprendizagemModelo introdutório para Data Observability, DRE e AI RMF
16Observabilidade, FinOps e eficiência operacional em nuvem e IAComo conectar Observabilidade e FinOps?
Relacionar Observabilidade ao monitoramento de consumo, custos, desperdícios, eficiência, unit economics e tomada de decisão em nuvem, dados e IA.
- Custo por transação crítica e por jornada digital.
- Custo por inferência ou por mil tokens em soluções de IA.
- % de recursos ociosos ou superdimensionados.
- Eficiência por SLO: custo por ponto de disponibilidade, latência ou confiabilidade.
- A equipe técnica enxerga custo junto com performance e disponibilidade?
- Quais workloads podem ser otimizados sem afetar o SLO?
- Como medir custo e valor de soluções de IA em produção?
Produto de aprendizagemIndicadores de consumo, custo e eficiência operacional
Integrado ao ITIL 5 e ao HDI SCC
A camada de evidências das suas práticas
Observabilidade não substitui ITIL 5 nem HDI SCC. Ela transforma mudança de estado em evento, evento relevante em alerta, alerta com impacto em incidente e recorrência em problema.
Exemplo do Módulo 2
Erro 5xx aumenta no serviço de pagamento. O alerta vira incidente por impacto na jornada. A terceira ocorrência vira problema. A correção entra como mudança. A melhoria revisa o alerta e o teste sintético.
| Prática ou item | Como a Observabilidade contribui | Evidência sugerida |
|---|---|---|
| ITIL 5 Monitoring and Event Management | Detecta, classifica, correlaciona e prioriza eventos. | Histórico de eventos, regras de alerta e taxa de falsos positivos. |
| ITIL 5 Incident Management | Acelera detecção, triagem, enriquecimento de ticket e recuperação. | Ticket com métricas, logs, traces, timeline e runbook. |
| ITIL 5 Problem Management | Apoia análise de causa raiz, tendências e reincidência. | RCA, Problem Record, erro conhecido e ações preventivas. |
| ITIL 5 Change Enablement | Valida impacto antes, durante e depois de mudanças. | Baseline, comparação pós-deploy e evidência de estabilização. |
| ITIL 5 Continual Improvement | Transforma dados históricos em backlog de melhoria. | Plano de melhoria, owners e indicadores antes e depois. |
| HDI SCC 5.010 Gestão de Eventos | Demonstra gestão de eventos com critérios e evidências. | Dashboards, alertas e registro de tratamento de eventos. |
| HDI SCC 5.020 Experiência | Mede a experiência percebida do usuário. | DEX Score, jornada digital, reclamações e monitoramento sintético. |
| HDI SCC 5.060 Incidentes | Qualifica a resposta a incidentes. | MTTA, MTTR, comunicação e registros de solução. |
| HDI SCC 5.130 Problemas | Reduz reincidência por análise de problema. | RCA, tendências, erros conhecidos e plano corretivo. |
O que você leva
Você não sai só com conceito. Sai com material para aplicar na sua operação.
Modelos, checklists e um roteiro para aplicar a Observabilidade em um serviço crítico da sua empresa.
Modelo de runbook
Os 8 campos de um runbook pronto para incidente real, do nome do alerta às evidências.
Checklist de qualidade de alertas
8 critérios para decidir se um alerta merece existir.
Checklist de governança de logs
Política, inventário, mascaramento, retenção, menor privilégio, auditoria e descarte seguro.
Matriz RACI operacional
Quem executa, aprova, é consultado e informado entre Suporte, NOC, SOC, SRE, Engenharia, Governança, Segurança e dono do serviço.
Catálogo de indicadores
Fórmula e interpretação de MTTD, MTTA, MTTR, reincidência, P95/P99, alertas acionáveis, DEX e automação.
Roteiro de aplicação em serviço crítico
8 passos para aplicar tudo em um serviço da sua empresa e sair com três ações preventivas para os próximos 30 dias.
16 produtos de aprendizagem, um por módulo
Para quem é
Técnico e gerencial, para toda a cadeia de operação
Observabilidade é multidisciplinar. Veja o que muda para cada área.
Centro de Suporte
Recebe o impacto do usuário, registra chamados e comunica status. Passa a qualificar triagem e comunicação com evidências antes de escalar.
NOC
Observa infraestrutura e serviços, reconhece alertas, executa runbooks e aciona escalonamento, com menos ruído e alertas com dono.
SOC
Investiga eventos de segurança, anomalias e acessos suspeitos a partir de logs, métricas e traces.
SRE
Define SLOs, error budget, automação segura e redução de toil, com melhorias estruturais baseadas em dados.
Engenharia
Corrige causas estruturais com erros, traces, deploys e dependências conectados ao impacto.
Governança e Segurança
Definem políticas, controles, evidências, compliance, retenção e segregação de acessos sobre os dados de Observabilidade.
Liderança e Gestão de Serviços
Enxerga risco, impacto, tendência e plano de ação, sem precisar de detalhes de CPU ou logs.
Perguntas frequentes
Dúvidas sobre o curso
Qual a carga horária?
16 horas, distribuídas em 16 módulos que vão dos fundamentos à Observabilidade de dados, IA e FinOps.
Qual a diferença entre monitoramento e Observabilidade?
O monitoramento avisa que um serviço está lento. A Observabilidade ajuda a entender por que ele está lento, a partir dos sinais que o sistema emite — métricas, logs, traces e eventos — conectados entre si.
A Observabilidade substitui o ITIL 5 ou o HDI SCC?
Não. Ela fortalece essas disciplinas com dados confiáveis, visão ponta a ponta, correlação entre sinais e histórico para análise de causa raiz. O curso dedica módulos específicos a essa conexão.
O curso é técnico ou gerencial?
Os dois. Ele foi desenhado para Centro de Suporte, NOC, SOC, SRE, Engenharia, Governança, Segurança e Gestão de Serviços, e vai de alertas e runbooks até dashboards executivos, maturidade e FinOps.
O curso ensina uma ferramenta específica?
Não. Observabilidade é tratada como capacidade organizacional, que conecta tecnologia, operações, engenharia, segurança, governança e negócio — e não como sinônimo de ferramenta.
Vou sair com algo aplicável na minha empresa?
Sim. Cada módulo entrega um produto de aprendizagem, e o curso inclui modelo de runbook, checklists de alertas e de governança de logs, matriz RACI, catálogo de indicadores e um roteiro para aplicar tudo em um serviço crítico.
Pré-inscrição aberta
Cada incidente deixa de ser apenas interrupção e passa a ser fonte de evidência para melhorar serviços, processos, segurança e experiência.
- 16 horas, 16 módulos e 8 casos práticos
- Integrado ao ITIL 5, HDI SCC, SRE, NOC/SOC, GRC e FinOps
- Modelo de runbook, checklists, matriz RACI e catálogo de indicadores
- Roteiro para aplicar em um serviço crítico da sua empresa
Ficha de interesse
A venda deste curso ainda não abriu. Preencha seus dados e nosso time entra em contato para confirmar turma e forma de pagamento.
Falta um clique: envie o e-mail
Se o e-mail não abriu, use uma das opções abaixo ou copie o resumo e envie para falecom@hdibrasil.com.br.