Pular para o conteúdo principal
A plataforma AIOps do ChatCLI oferece gestão nativa de Service Level Objectives (SLOs) e Service Level Agreements (SLAs) via CRDs Kubernetes. O sistema implementa o modelo de burn rate do Google SRE para alertas inteligentes e rastreia compliance de SLAs com suporte a business hours.

SLO vs SLA: Entendendo a Diferença

AspectoSLO (Service Level Objective)SLA (Service Level Agreement)
DefiniçãoMeta interna de confiabilidade de um serviçoContrato formal com clientes/stakeholders
Quem defineEquipe de engenhariaNegócio + engenharia + jurídico
Consequência de violaçãoAlerta interno, freeze de deploys, revisãoPenalidades contratuais, créditos, multas
Exemplo”99.9% availability em 30 dias""P1 incidents respondidos em 5 minutos”
CRDServiceLevelObjectiveIncidentSLA
A boa prática é definir SLOs mais rigorosos que os SLAs. Se seu SLA garante 99.9%, defina o SLO em 99.95%. Isso cria uma margem de segurança (error budget interno) que permite detectar degradações antes que o SLA seja violado.

ServiceLevelObjective CRD

O ServiceLevelObjective define uma meta de confiabilidade para um serviço, com alertas baseados em burn rate e tracking de error budget.
apiVersion: platform.chatcli.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-gateway-availability
  namespace: production
spec:
  service: api-gateway
  description: "API Gateway deve manter 99.9% de availability em janela de 30 dias"

  indicator:
    type: availability
    prometheusQuery:
      goodQuery: 'sum(rate(http_requests_total{service="api-gateway",code=~"2..|3.."}[5m]))'
      totalQuery: 'sum(rate(http_requests_total{service="api-gateway"}[5m]))'

  target:
    percentage: 99.9
    window: 30d

  burnRateAlerts:
    - name: page-fast-burn
      shortWindow: 1h
      longWindow: 6h
      burnRateThreshold: 14.4
      severity: critical
      notificationPolicy: production-alerts

    - name: ticket-medium-burn
      shortWindow: 6h
      longWindow: 3d
      burnRateThreshold: 6.0
      severity: high
      notificationPolicy: production-alerts

    - name: ticket-slow-burn
      shortWindow: 24h
      longWindow: 3d
      burnRateThreshold: 3.0
      severity: medium

    - name: monitor-gradual-burn
      shortWindow: 72h
      longWindow: 30d
      burnRateThreshold: 1.0
      severity: low

  alertPolicy:
    multiWindowRequired: true
    pageOnBudgetExhausted: true
    budgetWarningThresholds: [50, 25, 10, 0]

status:
  currentValue: 99.92
  errorBudgetTotal: 0.001
  errorBudgetRemaining: 0.0008
  errorBudgetRemainingPercent: 80.0
  burnRate: 1.2
  lastCalculatedAt: "2026-03-19T14:00:00Z"
  condition: Met

Campos do Spec

Raiz

CampoTipoObrigatórioDescrição
servicestringSimNome do serviço monitorado
descriptionstringNãoDescrição legível do SLO
indicatorSLOIndicatorSimDefinição do indicador de nível de serviço (SLI)
targetSLOTargetSimMeta e janela temporal
burnRateAlerts[]BurnRateWindowNãoConfiguração de alertas multi-window
alertPolicySLOAlertPolicyNãoPolítica geral de alertas

SLOIndicator

Define o que medir. O type determina a semântica e as queries Prometheus necessárias.
CampoTipoObrigatórioDescrição
typestringSimavailability, latency, error_rate, throughput
prometheusQueryPrometheusQuerySpecSimQueries PromQL para calcular o SLI
Tipos de indicador:
TipoGood EventsTotal EventsCálculo
availabilityRequests com sucesso (2xx, 3xx)Total de requestsgood / total
latencyRequests abaixo do threshold de latênciaTotal de requestsfast / total
error_rateN/A (invertido)Requests com erro1 - (errors / total)
throughputRequests processados dentro do budgetRequests recebidosprocessed / received
PrometheusQuerySpec:
CampoTipoObrigatórioDescrição
goodQuerystringSimPromQL que retorna a taxa de eventos “bons”
totalQuerystringSimPromQL que retorna a taxa total de eventos
indicator:
  type: availability
  prometheusQuery:
    goodQuery: 'sum(rate(http_requests_total{service="api-gateway",code=~"2..|3.."}[5m]))'
    totalQuery: 'sum(rate(http_requests_total{service="api-gateway"}[5m]))'

SLOTarget

CampoTipoObrigatórioDescrição
percentagefloat64SimMeta em porcentagem (ex: 99.9)
windowdurationSimJanela temporal rolling (ex: 30d, 7d, 24h)

BurnRateWindow

Cada entrada define uma janela de alerta baseada em burn rate.
CampoTipoObrigatórioDescrição
namestringSimNome identificador do alerta
shortWindowdurationSimJanela curta de observação
longWindowdurationSimJanela longa de observação
burnRateThresholdfloat64SimThreshold de burn rate para disparar alerta
severitystringSimcritical, high, medium, low
notificationPolicystringNãoNome da NotificationPolicy para routing

SLOAlertPolicy

CampoTipoPadrãoDescrição
multiWindowRequiredbooltrueRequer que AMBAS as janelas (short E long) excedam o threshold
pageOnBudgetExhaustedbooltrueEnvia page crítico quando error budget chega a 0%
budgetWarningThresholds[]int[50, 25, 10, 0]Porcentagens de budget restante que disparam warnings

Como Funciona o Cálculo (Google SRE Model)

O sistema implementa o modelo de multi-window, multi-burn-rate alerting descrito no livro “Site Reliability Engineering” do Google.

Error Budget

O error budget é a quantidade máxima de “erro” permitida dentro da janela do SLO.
Error Budget = 1 - (target / 100)

Exemplo para SLO de 99.9%:
  Error Budget = 1 - (99.9 / 100) = 0.001 = 0.1%
Em uma janela de 30 dias, isso significa:
Downtime permitido = 30 dias x 24h x 60min x 0.001 = 43.2 minutos
SLO TargetError BudgetDowntime/30d
99%1.0%7h 12min
99.5%0.5%3h 36min
99.9%0.1%43.2 min
99.95%0.05%21.6 min
99.99%0.01%4.32 min

Burn Rate

O burn rate indica a velocidade com que o error budget está sendo consumido.
Burn Rate = error_rate_in_window / error_budget

Onde:
  error_rate_in_window = 1 - (good_events / total_events) [na janela]
  error_budget = 1 - (target / 100)
1

Calcular error rate na janela

Usando as queries Prometheus, calcula-se a proporção de eventos bons vs total na janela especificada.
Exemplo: Na ultima 1h, houve 10.000 requests, 9.950 com sucesso.
error_rate = 1 - (9950 / 10000) = 0.005 = 0.5%
2

Calcular burn rate

Divide o error rate pelo error budget.
burn_rate = 0.005 / 0.001 = 5.0x

Interpretação: O budget está sendo consumido 5x mais rápido que o sustentável.
A esse ritmo, o budget de 30 dias se esgotaria em 6 dias.
3

Verificar multi-window

Para disparar um alerta, AMBAS as janelas (short E long) devem exceder o threshold.
Alerta "page-fast-burn" (threshold 14.4x):
  - Short window (1h): burn_rate = 16.2x  > 14.4  CHECK
  - Long window (6h):  burn_rate = 15.1x  > 14.4  CHECK
  -> ALERTA DISPARADO (ambas excedem)

Se short=16.2x mas long=12.0x:
  -> NÃO dispara (long abaixo do threshold)
  -> Indica spike temporário, não degradação sustentada
4

Classificar e notificar

Com base na severidade configurada, o alerta e roteado para a NotificationPolicy correspondente.

Multi-Window Alerting: Thresholds Padrão

Os thresholds padrão seguem a recomendação do Google SRE para um SLO de 30 dias:
NomeShort WindowLong WindowBurn RateSeveridadeSignificado
page-fast-burn1h6h14.4xCriticalBudget se esgota em ~2 dias. Requer ação imediata.
ticket-medium-burn6h3d6.0xHighBudget se esgota em ~5 dias. Crie ticket urgente.
ticket-slow-burn24h3d3.0xMediumBudget se esgota em ~10 dias. Investigue e planeje.
monitor-gradual-burn72h30d1.0xLowBudget exatamente no ritmo sustentavel. Monitore.
A formula para calcular o threshold: burn_rate_threshold = (window_days / budget_consumption_days). Para um SLO de 30 dias onde você quer alertar quando o budget se esgotaria em 2 dias: 30 / 2.08 = 14.4x.

Exemplo Numérico Completo

Considere um SLO de 99.9% availability em 30 dias para o serviço api-gateway:
Configuração:
  Target: 99.9%
  Window: 30 dias
  Error Budget: 0.1% = 43.2 minutos de downtime

Situação atual (medido pelo Prometheus):
  Últimas 24h: 99.85% availability (0.15% error rate)
  Últimas 6h:  99.80% availability (0.20% error rate)
  Última 1h:   99.70% availability (0.30% error rate)

Cálculo de burn rate por janela:
  1h:  0.003 / 0.001 = 3.0x
  6h:  0.002 / 0.001 = 2.0x
  24h: 0.0015 / 0.001 = 1.5x

Avaliação de alertas:
  page-fast-burn (14.4x):  1h=3.0x < 14.4  -> NÃO dispara
  ticket-medium-burn (6x): 6h=2.0x < 6.0   -> NÃO dispara
  ticket-slow-burn (3x):   24h=1.5x < 3.0  -> NÃO dispara
  monitor-gradual-burn (1x): ambas > 1.0    -> DISPARA (severity: low)

Resultado: Degradação lenta detectada. Não é crítico, mas o budget está
sendo consumido 1.5x mais rápido que o sustentável. A esse ritmo, o
budget de 43.2 minutos se esgotaria em 20 dias (ao inves de 30).

Error budget restante:
  Consumido até agora: ~22 minutos (estimado)
  Restante: 43.2 - 22 = 21.2 minutos
  Porcentagem restante: 49.1%
  -> Warning threshold de 50% quase atingido

Error Budget Tracking

O status do ServiceLevelObjective e atualizado periodicamente pelo reconciler:
CampoTipoDescrição
currentValuefloat64Valor atual do SLI (ex: 99.92%)
errorBudgetTotalfloat64Budget total (ex: 0.001 para 99.9%)
errorBudgetRemainingfloat64Budget restante
errorBudgetRemainingPercentfloat64Porcentagem restante do budget
burnRatefloat64Burn rate atual (janela mais curta)
lastCalculatedAtTimeÚltimo cálculo
conditionstringMet (dentro do SLO), AtRisk (budget < 25%), Violated (budget esgotado)
Condições do SLO: Budget Warning Thresholds: Quando configurados, o sistema envia notificações ao atingir cada threshold:
Budget RestanteAção
50%Notificação informativa
25%Warning: congelar deploys não-essenciais
10%Alerta: foco total em estabilidade
0%Page crítico (se pageOnBudgetExhausted: true)

IncidentSLA CRD

O IncidentSLA define contratos de tempo de resposta e resolução por severidade, com suporte a business hours e tracking de violações.
apiVersion: platform.chatcli.io/v1alpha1
kind: IncidentSLA
metadata:
  name: production-sla
  namespace: production
spec:
  service: api-gateway
  description: "SLA de produção para o API Gateway"

  responseTimes:
    - severity: critical
      maxResponseTime: "5m"
      maxResolutionTime: "1h"
    - severity: high
      maxResponseTime: "15m"
      maxResolutionTime: "4h"
    - severity: medium
      maxResponseTime: "1h"
      maxResolutionTime: "24h"
    - severity: low
      maxResponseTime: "4h"
      maxResolutionTime: "72h"

  businessHours:
    enabled: true
    timezone: "America/Sao_Paulo"
    startHour: 9
    endHour: 18
    workDays: [1, 2, 3, 4, 5]   # Segunda a Sexta (0=Dom, 6=Sab)
    holidays:
      - date: "2026-01-01"
        name: "Ano Novo"
      - date: "2026-04-03"
        name: "Sexta-feira Santa"
      - date: "2026-12-25"
        name: "Natal"

  violationPolicy:
    notificationPolicy: sla-breach-notifications
    escalationPolicy: p0-escalation
    autoEscalateOnBreach: true

status:
  activeIncidents: 2
  totalViolations: 3
  compliancePercentage: 97.5
  violations:
    - issueName: "api-gateway-oom-kill-1771276354"
      severity: critical
      type: resolution_time
      exceededBy: "12m"
      occurredAt: "2026-03-15T14:30:00Z"
  lastCalculatedAt: "2026-03-19T14:00:00Z"

Campos do Spec

Raiz

CampoTipoObrigatórioDescrição
servicestringSimNome do serviço coberto pelo SLA
descriptionstringNãoDescrição do SLA
responseTimes[]ResponseTimeConfigSimTempos máximos por severidade
businessHoursBusinessHoursSpecNãoConfiguração de horário comercial
violationPolicyViolationPolicySpecNãoAções em caso de violação

ResponseTimeConfig

CampoTipoObrigatórioDescrição
severitystringSimcritical, high, medium, low
maxResponseTimedurationSimTempo máximo para primeiro acknowledgement
maxResolutionTimedurationSimTempo máximo para resolução completa
Response time é medido como o tempo entre a criação do Issue (estado Detected) e a primeira transição para Analyzing ou Remediating. Resolution time é medido entre Detected e Resolved.

BusinessHoursSpec

CampoTipoObrigatórioDescrição
enabledboolSimAtiva contagem apenas em horário comercial
timezonestringSimTimezone IANA (ex: America/Sao_Paulo)
startHourintSimHora de início (0-23)
endHourintSimHora de fim (0-23)
workDays[]intSimDias úteis (0=Domingo, 6=Sábado)
holidays[]HolidayNãoFeriados (clock parado nesses dias)

Como o Clock de Business Hours Funciona

O SLA clock conta apenas durante horário comercial. Fora do horário, o clock é pausado automaticamente.
1

Incidente detectado

Issue criado as 17:45 (sexta-feira). Clock inicia.
Horário comercial: 09:00-18:00 (Seg-Sex), timezone America/Sao_Paulo
2

Clock conta 15 minutos (sexta)

De 17:45 até 18:00 = 15 minutos de SLA clock. Clock pausa às 18:00 (fim do horário comercial).
3

Fim de semana: clock pausado

Sábado e domingo inteiros: clock permanece pausado. Tempo SLA acumulado: 15 minutos.
4

Segunda-feira: clock retoma

Clock retoma as 09:00 de segunda-feira. Se o incidente é resolvido às 10:30 de segunda:
  • Sexta: 15 minutos
  • Segunda: 1h30 = 90 minutos
  • Total SLA: 105 minutos (1h45)
5

Avaliação de compliance

Para severidade critical com maxResolutionTime: 1h:
  • Tempo SLA gasto: 1h45 = 105 minutos
  • Limite: 60 minutos
  • VIOLAÇÃO: excedeu por 45 minutos
Para severidade high com maxResolutionTime: 4h:
  • Tempo SLA gasto: 105 minutos
  • Limite: 240 minutos
  • DENTRO DO SLA
Para incidentes critical, considere desabilitar business hours (enabled: false) e usar clock 24/7. Problemas críticos em produção não devem aguardar o próximo dia útil.

ViolationPolicySpec

CampoTipoDescrição
notificationPolicystringNotificationPolicy para enviar alertas de violação
escalationPolicystringEscalationPolicy para escalar violações
autoEscalateOnBreachboolEscalar automaticamente quando SLA e violado

CompliancePercentage Calculation

CompliancePercentage = ((total_incidents - violations) / total_incidents) * 100

Exemplo:
  Total de incidentes no periodo: 120
  Violações: 3
  Compliance = ((120 - 3) / 120) * 100 = 97.5%
O compliance é calculado por severity e agregado:
SeveridadeIncidentesViolaçõesCompliance
Critical5180.0%
High15286.7%
Medium400100.0%
Low600100.0%
Total120397.5%

Exemplos YAML Completos

SLO de 99.9% Availability com Burn Rate Alerting

apiVersion: platform.chatcli.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-gateway-availability-slo
  namespace: production
spec:
  service: api-gateway
  description: "99.9% availability do API Gateway medido por taxa de sucesso HTTP"

  indicator:
    type: availability
    prometheusQuery:
      goodQuery: |
        sum(rate(http_requests_total{
          service="api-gateway",
          code=~"2..|3.."
        }[5m]))
      totalQuery: |
        sum(rate(http_requests_total{
          service="api-gateway"
        }[5m]))

  target:
    percentage: 99.9
    window: 30d

  burnRateAlerts:
    - name: page-immediate
      shortWindow: 1h
      longWindow: 6h
      burnRateThreshold: 14.4
      severity: critical
      notificationPolicy: production-alerts

    - name: ticket-urgent
      shortWindow: 6h
      longWindow: 3d
      burnRateThreshold: 6.0
      severity: high
      notificationPolicy: production-alerts

    - name: ticket-normal
      shortWindow: 24h
      longWindow: 3d
      burnRateThreshold: 3.0
      severity: medium

    - name: monitor
      shortWindow: 72h
      longWindow: 30d
      burnRateThreshold: 1.0
      severity: low

  alertPolicy:
    multiWindowRequired: true
    pageOnBudgetExhausted: true
    budgetWarningThresholds: [50, 25, 10, 0]

SLA P1=5min Response / 1h Resolution (Business Hours)

apiVersion: platform.chatcli.io/v1alpha1
kind: IncidentSLA
metadata:
  name: api-gateway-production-sla
  namespace: production
spec:
  service: api-gateway
  description: "SLA de produção conforme contrato com clientes enterprise"

  responseTimes:
    - severity: critical
      maxResponseTime: "5m"
      maxResolutionTime: "1h"
    - severity: high
      maxResponseTime: "15m"
      maxResolutionTime: "4h"
    - severity: medium
      maxResponseTime: "2h"
      maxResolutionTime: "24h"
    - severity: low
      maxResponseTime: "8h"
      maxResolutionTime: "72h"

  businessHours:
    enabled: true
    timezone: "America/Sao_Paulo"
    startHour: 9
    endHour: 18
    workDays: [1, 2, 3, 4, 5]
    holidays:
      - date: "2026-01-01"
        name: "Confraternização Universal"
      - date: "2026-02-16"
        name: "Carnaval"
      - date: "2026-02-17"
        name: "Carnaval"
      - date: "2026-04-03"
        name: "Sexta-feira Santa"
      - date: "2026-04-21"
        name: "Tiradentes"
      - date: "2026-05-01"
        name: "Dia do Trabalho"
      - date: "2026-09-07"
        name: "Independência"
      - date: "2026-10-12"
        name: "Nossa Senhora Aparecida"
      - date: "2026-11-02"
        name: "Finados"
      - date: "2026-11-15"
        name: "Proclamação da República"
      - date: "2026-12-25"
        name: "Natal"

  violationPolicy:
    notificationPolicy: sla-breach-notifications
    escalationPolicy: p0-escalation
    autoEscalateOnBreach: true
Para severidade critical, mesmo com business hours habilitado, considere criar uma regra separada com businessHours.enabled: false. Problemas P1 geralmente exigem resposta 24/7.

SLO com PrometheusQuery Custom (Latency P99)

apiVersion: platform.chatcli.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: payment-service-latency-slo
  namespace: payments
spec:
  service: payment-service
  description: "99.5% dos requests do Payment Service devem completar em menos de 500ms"

  indicator:
    type: latency
    prometheusQuery:
      goodQuery: |
        sum(rate(http_request_duration_seconds_bucket{
          service="payment-service",
          le="0.5"
        }[5m]))
      totalQuery: |
        sum(rate(http_request_duration_seconds_count{
          service="payment-service"
        }[5m]))

  target:
    percentage: 99.5
    window: 7d

  burnRateAlerts:
    - name: page-latency-spike
      shortWindow: 30m
      longWindow: 3h
      burnRateThreshold: 14.4
      severity: critical
      notificationPolicy: payments-alerts

    - name: ticket-latency-degradation
      shortWindow: 3h
      longWindow: 1d
      burnRateThreshold: 6.0
      severity: high

    - name: monitor-latency-trend
      shortWindow: 12h
      longWindow: 7d
      burnRateThreshold: 1.0
      severity: low

  alertPolicy:
    multiWindowRequired: true
    pageOnBudgetExhausted: true
    budgetWarningThresholds: [25, 10, 0]

Grafana Dashboards

A plataforma AIOps disponibiliza 4 dashboards Grafana pré-configurados para visualização de SLOs e SLAs:

SLO Overview

Painel unificado com todos os SLOs, valores atuais, error budget restante e burn rate. Inclui heatmap de burn rate por serviço.

Error Budget Burn-Down

Gráfico burn-down do error budget ao longo do tempo. Mostra tendência e projeção de esgotamento. Linhas de referência para cada threshold de warning.

SLA Compliance Report

Relatório de compliance por severidade e período. Tabela com cada incidente, tempos de resposta/resolução e status de compliance. Exportável para PDF.

Incident Timeline

Timeline de incidentes com detecção, análise, remediação e resolução. Correlação visual com SLO burn rate e SLA clock.
Importando os dashboards:
# Os dashboards estão disponíveis como ConfigMaps
kubectl apply -f operator/config/grafana/dashboards/

# Ou importe via API do Grafana
for f in operator/config/grafana/dashboards/*.json; do
  curl -X POST -H "Content-Type: application/json" \
    -H "Authorization: Bearer $GRAFANA_API_KEY" \
    -d @"$f" \
    "https://grafana.company.com/api/dashboards/db"
done

Prometheus Metrics

O sistema de SLOs e SLAs expõe métricas detalhadas:

Métricas de SLO

MétricaTipoLabelsDescrição
chatcli_slo_current_valueGaugeslo, service, namespace, indicator_typeValor atual do SLI (ex: 99.92)
chatcli_slo_target_valueGaugeslo, serviceMeta configurada (ex: 99.9)
chatcli_slo_error_budget_totalGaugeslo, serviceError budget total (ex: 0.001)
chatcli_slo_error_budget_remainingGaugeslo, service, namespaceError budget restante
chatcli_slo_error_budget_remaining_percentGaugeslo, servicePorcentagem restante do budget
chatcli_slo_burn_rateGaugeslo, service, windowBurn rate por janela
chatcli_slo_alerts_fired_totalCounterslo, service, severity, alert_nameTotal de alertas de burn rate disparados
chatcli_slo_conditionGaugeslo, service, conditionEstado atual (1=ativo): Met, AtRisk, Violated

Métricas de SLA

MétricaTipoLabelsDescrição
chatcli_sla_violations_totalCountersla, service, severity, violation_typeTotal de violações de SLA
chatcli_sla_compliance_percentageGaugesla, service, severityPorcentagem de compliance atual
chatcli_sla_response_time_secondsHistogramsla, service, severityDistribuição de tempos de resposta
chatcli_sla_resolution_time_secondsHistogramsla, service, severityDistribuição de tempos de resolução
chatcli_sla_active_incidentsGaugesla, serviceIncidentes ativos no momento
chatcli_sla_business_hours_activeGaugesla, service1 se dentro do horário comercial, 0 se fora
Alertas Prometheus recomendados:
groups:
  - name: chatcli-slo-sla
    rules:
      - alert: SLOBudgetExhausted
        expr: chatcli_slo_error_budget_remaining_percent <= 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Error budget esgotado para SLO {{ $labels.slo }}"
          description: "O serviço {{ $labels.service }} esgotou o error budget. Nenhum downtime adicional é permitido."

      - alert: SLOBudgetLow
        expr: chatcli_slo_error_budget_remaining_percent <= 10 and chatcli_slo_error_budget_remaining_percent > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Error budget baixo ({{ $value }}%) para SLO {{ $labels.slo }}"

      - alert: SLAComplianceBelow95
        expr: chatcli_sla_compliance_percentage < 95
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "SLA compliance abaixo de 95% para {{ $labels.service }}"
          description: "Compliance atual: {{ $value }}%. Revise incidentes recentes e tome ações corretivas."

      - alert: SLAResponseTimeExceeded
        expr: histogram_quantile(0.95, rate(chatcli_sla_response_time_seconds_bucket[1h])) > 300
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 do tempo de resposta SLA excede 5 minutos"

Próximo Passo

Notificações e Escalação

Sistema de notificações multi-canal e escalação automática

Workflow de Aprovação

Controle de mudanças com approval policies e blast radius

AIOps Platform

Deep-dive na arquitetura AIOps

K8s Operator

Configuração e CRDs do operator