AIOps: Setup Produção Completo

Este runbook leva um cluster vazio até uma plataforma AIOps do ChatCLI funcionando. Todos os manifestos abaixo são válidos contra os CRDs atuais. Siga os passos na ordem. A maioria termina com uma verificação para rodar antes de seguir. No final você terá:

o operator em chatcli-system, com API REST, dashboard web, métricas e uma NetworkPolicy opcional;
um servidor ChatCLI (Instance) em chatcli, com credencial, TLS, recursos explícitos e um watcher nas suas cargas de produção;
políticas de notificação, escalação, SLO, SLA e aprovação;
dashboards no Grafana e coleta pelo Prometheus;
um drill de chaos que mostra o pipeline detectando uma falha.

Pré-requisitos

Um cluster Kubernetes e permissão de cluster-admin para a instalação (o chart cria CRDs, ClusterRoles e ClusterRoleBindings).
kubectl, Helm 3.8 ou mais recente (para charts OCI; Helm 4 incluído) e openssl.
Pelo menos uma chave de provedor de LLM (os exemplos usam Anthropic e OpenAI).
Para observabilidade: o Prometheus Operator (para ServiceMonitor) e o Grafana com o sidecar de dashboards. Os dois são opcionais.
A CLI chatcli na sua máquina, para o teste de ponta a ponta do passo 13.

Onde cada recurso fica

O operator procura os recursos em namespaces específicos. Um recurso no namespace errado não dá erro: ele é simplesmente ignorado.

Recurso	Namespace	Por quê
Operator e o Secret de chaves do dashboard `chatcli-operator-secrets`	O namespace do operator (`chatcli-system`)	O operator lê esse Secret de nome fixo no próprio namespace
`Instance` e todo Secret que ela referencia	O namespace dela (`chatcli`)	Referências a Secret num pod são sempre do mesmo namespace
Anomaly, Issue, AIInsight, RemediationPlan, PostMortem	O namespace da carga afetada (`production`)	O operator cria esses objetos lá
`ApprovalPolicy`	O namespace da carga	Só as políticas do namespace do plano são avaliadas
`ServiceLevelObjective`	O namespace da carga	As consultas do SLO ficam no namespace do próprio SLO
`SourceRepository` e o Secret do git	O namespace da carga	O repositório é procurado no namespace do recurso, e o Secret no namespace do repositório
`ChaosExperiment`	O namespace do alvo	A correlação com Issues só procura no namespace do alvo
`NotificationPolicy`, `EscalationPolicy` e os Secrets delas	Qualquer um (esta página usa `chatcli-system`)	Toda política habilitada do cluster é avaliada; os Secrets são lidos do namespace da política
`IncidentSLA`	Qualquer um	Vale a do namespace da Issue; se não houver, uma de qualquer namespace

Só uma Instance por cluster conduz o AIOps. A ponte de alertas do operator se conecta à primeira Instance pronta que encontra em todos os namespaces, e a análise de IA e a remediação usam essa mesma conexão. Com várias Instances prontas, não é definido qual delas é escolhida. Rode uma única Instance com watcher por cluster.

1. Instalar o operator

Escreva um arquivo de values. Todas as chaves abaixo existem no schema do chart, e o schema recusa chaves desconhecidas.

# values-operator.yaml
replicaCount: 2            # leader election ligado; a API REST e o dashboard atendem em todas as réplicas
leaderElect: true

# Prometheus que o operator consulta durante a análise de incidentes (opcional, veja o passo 10)
prometheusUrl: "http://prometheus-operated.monitoring.svc:9090"

serviceMonitor:
  enabled: true            # exige os CRDs do Prometheus Operator
  labels:
    release: kube-prometheus-stack   # o label pelo qual o seu Prometheus seleciona ServiceMonitors

networkPolicy:
  enabled: true
  apiIngressFrom:          # quem pode acessar a API REST e o dashboard (porta 8090)
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
  metricsIngressFrom:      # quem pode coletar a porta de métricas (8080)
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
  egress: restricted       # DNS, 443, o API server, a porta gRPC das Instances, o Prometheus
  kubernetesApiPort: 6443  # use 443 se o seu API server escuta nela
  egressExtraPorts:
    - port: 587            # SMTP para as notificações por email (passo 5)
      protocol: TCP

# O sistema de arquivos raiz é somente leitura; o chart monta um emptyDir
# gravável em /tmp, onde ficam os clones do SourceRepository (passo 4).
# Aumente o limite para repositórios grandes.
tmpVolume:
  sizeLimit: 1Gi

helm install chatcli-operator oci://ghcr.io/diillson/charts/chatcli-operator \
  --version 1.212.2 \
  --namespace chatcli-system --create-namespace \
  -f values-operator.yaml

O chart instala os 17 CRDs, o Deployment do operator, o Service dele (chatcli-operator, portas metrics 8080, health 8081, api 8090), o RBAC de cluster, a ClusterRole chatcli-watcher pré-provisionada e um hook de pre-install/pre-upgrade que reaplica os CRDs a cada helm upgrade. Ele fixa a imagem de servidor usada pelas Instances na mesma release, a menos que a Instance defina spec.image.tag. Verificação:

kubectl get crd -o name | grep -c platform.chatcli.io     # 17
kubectl -n chatcli-system rollout status deploy/chatcli-operator

O chart do operator não tem template de PodDisruptionBudget. Com replicaCount: 2, crie um você mesmo se um drain de nó precisar manter uma réplica no ar (seletor app.kubernetes.io/name: chatcli-operator).

2. Criar os Secrets da Instance

Todos ficam no namespace da Instance.

kubectl create namespace chatcli

# Chaves dos provedores de LLM, carregadas no servidor via envFrom
kubectl -n chatcli create secret generic chatcli-llm-keys \
  --from-literal=ANTHROPIC_API_KEY='<chave-anthropic>' \
  --from-literal=OPENAI_API_KEY='<chave-openai>'

# Token compartilhado do servidor. É obrigatório: no Kubernetes o servidor
# escuta em todas as interfaces e se recusa a subir sem credencial.
kubectl -n chatcli create secret generic chatcli-prod-token \
  --from-literal=token="$(openssl rand -hex 32)"

# Chave de criptografia em repouso do que o servidor grava em ~/.chatcli
kubectl -n chatcli create secret generic chatcli-encryption-key \
  --from-literal=key="$(openssl rand -hex 32)"

O operator observa todos os Secrets que uma Instance referencia. Quando você rotaciona um deles, os pods são recriados automaticamente, porque um hash das chaves referenciadas vai no template do pod.

Certificado TLS

O operator sempre se conecta ao servidor com TLS 1.3. Não existe modo em texto puro: uma Instance sem TLS sobe, mas o operator não consegue alcançá-la (ServerReachable=False), e alertas, análise de IA e remediação param aí. O operator disca <instance>.<namespace>.svc.cluster.local, aqui chatcli-prod.chatcli.svc.cluster.local. O certificado precisa ser válido para esse nome. Se não for assinado por uma CA pública, o Secret também precisa trazer a CA como ca.crt, que o operator usa como raiz de confiança para essa Instance.

cert-manager (recomendado)
openssl (autoassinado)

Um issuer de CA interna grava tls.crt, tls.key e ca.crt no Secret, e renova o certificado. Cada renovação recria os pods da Instance.

# Cria uma CA privada (pule se você já tem uma ClusterIssuer de CA)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-bootstrap
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: chatcli-internal-ca
  namespace: cert-manager        # o namespace de recursos de cluster do cert-manager
spec:
  isCA: true
  commonName: chatcli-internal-ca
  secretName: chatcli-internal-ca
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-bootstrap
    kind: ClusterIssuer
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: chatcli-internal-ca
spec:
  ca:
    secretName: chatcli-internal-ca
---
# O certificado do servidor
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: chatcli-prod-tls
  namespace: chatcli
spec:
  secretName: chatcli-prod-tls
  issuerRef:
    name: chatcli-internal-ca
    kind: ClusterIssuer
  dnsNames:
    - chatcli-prod.chatcli.svc.cluster.local   # o nome que o operator disca
    - chatcli-prod.chatcli.svc
    - chatcli-prod
    - localhost                                # para o teste via port-forward do passo 13
  duration: 2160h      # 90 dias
  renewBefore: 360h    # 15 dias

kubectl -n chatcli wait certificate/chatcli-prod-tls --for=condition=Ready --timeout=2m
kubectl -n chatcli get secret chatcli-prod-tls -o jsonpath='{.data}' | grep -o '"[a-z.]*":' # ca.crt, tls.crt, tls.key

Um certificado autoassinado é a própria CA, então o mesmo arquivo entra como ca.crt. A rotação fica por sua conta.

openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \
  -keyout tls.key -out tls.crt \
  -subj "/CN=chatcli-prod.chatcli.svc.cluster.local" \
  -addext "subjectAltName=DNS:chatcli-prod.chatcli.svc.cluster.local,DNS:chatcli-prod.chatcli.svc,DNS:chatcli-prod,DNS:localhost"

openssl x509 -in tls.crt -noout -ext subjectAltName   # confira os SANs

kubectl -n chatcli create secret generic chatcli-prod-tls \
  --from-file=tls.crt=tls.crt \
  --from-file=tls.key=tls.key \
  --from-file=ca.crt=tls.crt

Emissor	`ca.crt` no Secret	Observações
cert-manager com issuer de CA interna	Gravado pelo cert-manager	Coloque os nomes internos do cluster em `dnsNames`
CA privada (por exemplo AWS Private CA)	Adicione você o bundle da CA como `ca.crt`	Emita o certificado para os nomes internos do cluster
Autoassinado	`ca.crt` = o próprio certificado	A rotação é manual
CA pública (por exemplo Let’s Encrypt)	Não precisa: o operator usa as CAs do sistema	Só funciona se o certificado cobrir `<instance>.<namespace>.svc.cluster.local`, nome que CAs públicas não emitem. Na prática, use uma CA privada para esse trecho interno

Não existe campo na Instance para o endereço que o operator disca. É sempre o nome do Service da Instance acima, na porta spec.server.port. Há overrides para o operator inteiro, da raiz de confiança e de um certificado de cliente (chart security.grpcTLS.*), mas um ca.crt no próprio Secret da Instance é mais simples e tem prioridade sobre eles.

3. Criar a Instance de produção

apiVersion: platform.chatcli.io/v1alpha1
kind: Instance
metadata:
  name: chatcli-prod
  namespace: chatcli
spec:
  replicas: 2
  provider: CLAUDEAI
  model: claude-sonnet-5
  # Sem image.tag: a imagem do servidor fica fixada na release do operator.

  apiKeys:
    name: chatcli-llm-keys          # cada chave deste Secret vira uma variável de ambiente

  fallback:
    enabled: true
    providers:                      # o operator coloca o spec.provider na frente para você
      - name: OPENAI
        model: gpt-6-sol

  server:
    port: 50051
    metricsPort: 9090               # também serve /healthz para as probes do pod; 0 continua sendo 9090
    token:
      name: chatcli-prod-token
      key: token
    tls:
      enabled: true
      secretName: chatcli-prod-tls  # tls.crt, tls.key, ca.crt
    security:
      rateLimitRps: 20              # por identidade autenticada; quem usa o token compartilhado divide um único bucket
      rateLimitBurst: 40

  watcher:
    enabled: true
    interval: "30s"
    window: "2h"
    maxLogLines: 100
    targets:
      - name: api-gateway
        kind: Deployment
        namespace: production
        metricsPort: 8080
        metricsPath: /metrics
      - name: payment-service
        kind: Deployment
        namespace: production
      - name: orders-db
        kind: StatefulSet
        namespace: production

  aiops:
    maxRemediationAttempts: 3       # padrão 5
    dedupTTLMinutes: 30

  # O operator NÃO aplica recursos padrão: defina explicitamente.
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: "1"
      memory: 1Gi

  # Com replicas > 1, deixe a persistência desligada (veja a nota abaixo).
  persistence:
    enabled: false

  features:
    encryptionKeyRef:
      name: chatcli-encryption-key
      key: key
    # caBundleSecretName: corporate-ca   # Secret com ca.crt, para um proxy de saída que inspeciona TLS

  scheduling:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              topologyKey: kubernetes.io/hostname
              labelSelector:
                matchLabels:
                  app.kubernetes.io/name: chatcli
                  app.kubernetes.io/instance: chatcli-prod
    # nodeSelector: {}
    # tolerations: []
    # priorityClassName: <uma PriorityClass existente>

  # Para o provedor BEDROCK no EKS (IRSA): o operator mescla estas anotações
  # na ServiceAccount da Instance.
  # serviceAccount:
  #   annotations:
  #     eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<role-name>

  # extraEnv: []   # variáveis extras para o container do servidor; o log
  #                # já chega ao `kubectl logs` (linhas JSON no stderr)

kubectl apply -f instance.yaml
kubectl -n chatcli get instance chatcli-prod -w

O que o operator cria, e o que não cria:

Um Deployment chatcli-prod cujos pods rodam sem root, com sistema de arquivos raiz somente leitura, sem nenhuma capability, e atendem ao Pod Security Standard restricted. As probes de startup, readiness e liveness chamam GET /healthz na porta de métricas.
Um Service chatcli-prod com as portas grpc e metrics. Com replicas > 1 ele é headless, e o operator balanceia entre os pods.
Uma ServiceAccount e, para alvos do watcher em outros namespaces, um ClusterRoleBinding para chatcli-watcher, para o servidor conseguir ler essas cargas.
Nenhum PodDisruptionBudget, HPA ou NetworkPolicy. Crie você mesmo se precisar (há um exemplo de NetworkPolicy abaixo).

Persistência e réplicas. persistence.enabled: true cria um único PVC ReadWriteOnce (chatcli-prod-sessions) que todas as réplicas montam, e o modo de acesso não pode ser alterado. Com replicas > 1, pods agendados em nós diferentes ficam em ContainerCreating com erro Multi-Attach. Ou mantenha replicas: 1 com persistência, ou rode várias réplicas sem ela, como acima. Com persistência o operator define a estratégia do Deployment como Recreate, então o pod antigo libera o volume antes de o novo subir: cada rollout tem uma breve indisponibilidade. Sem ela a estratégia é RollingUpdate. O pipeline de AIOps não precisa do volume de sessões. Sem ele, as sessões de quem usa chatcli connect duram só enquanto o pod existir.

Fallback. O servidor só monta a cadeia de fallback quando pelo menos dois dos provedores listados têm credencial, e só a usa em requisições que não trazem credencial nem provedor próprios. As requisições do pipeline de AIOps se encaixam.

Uma NetworkPolicy para a Instance, que libera gRPC a partir do namespace do operator e a coleta a partir de monitoring (acrescente os namespaces de quem usa chatcli connect):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: chatcli-prod
  namespace: chatcli
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: chatcli
      app.kubernetes.io/instance: chatcli-prod
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: chatcli-system
      ports:
        - port: 50051
          protocol: TCP
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
      ports:
        - port: 9090          # métricas e /healthz, HTTP puro sem autenticação
          protocol: TCP

Na maioria dos CNIs as probes do kubelet não passam pela NetworkPolicy, mas não em todos. Se os pods falharem no readiness depois de aplicar a política, libere também a porta 9090 a partir do CIDR dos nós.

Verificação: todas as condições estão True e ServerReachable mostra Serving:

kubectl -n chatcli get instance chatcli-prod \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}: {.message}{"\n"}{end}'

AuthenticationConfigured=True CredentialConfigured: ...
OperatorCredentialConfigured=True CredentialAvailable: operator authenticates with spec.server.token
TLSConfigured=True SecretConfigured: server certificate from Secret chatcli-prod-tls
Available=True DeploymentReady: All replicas are ready
ServerReachable=True Serving: server <version> serving (CLAUDEAI/claude-sonnet-5)

A coluna VERSION de kubectl get instance mostra a versão do servidor que o operator leu por último. Uma Instance pronta é sondada de novo a cada cinco minutos, então espere até cinco minutos para ServerReachable refletir uma mudança; depois de uma sondagem que falha, ela é repetida a cada 30 segundos.

4. Vincular repositórios de código (opcional)

Um SourceRepository entrega à IA os commits recentes e o código em volta dos stack traces de uma carga. Crie o repositório, e o Secret do git, no namespace da carga. O operator o clona no emptyDir gravável /tmp dele (valor tmpVolume.sizeLimit do chart, passo 1).

kubectl -n production create secret generic api-gateway-git \
  --from-literal=token='<token-git-somente-leitura>'

apiVersion: platform.chatcli.io/v1alpha1
kind: SourceRepository
metadata:
  name: api-gateway
  namespace: production
spec:
  url: "https://git.example.com/platform/api-gateway.git"
  branch: main
  authType: token            # a chave do Secret precisa se chamar "token"
  secretRef: api-gateway-git
  resource:
    kind: Deployment
    name: api-gateway
    namespace: production
  paths: ["cmd/", "internal/"]
  language: Go
  syncIntervalMinutes: 30

As chaves do Secret dependem do authType: token para token, username e password para basic, ssh-key e known_hosts para ssh. As credenciais HTTPS chegam ao git por um helper GIT_ASKPASS a cada comando e nunca são gravadas no .git/config do clone; um clone feito por uma versão anterior, que guardava o token na URL do origin, tem o token removido do origin e o reflog expirado na próxima sincronização. A imagem do operator traz o openssh-client, e um clone por SSH confere a chave do host do servidor contra o known_hosts do Secret com StrictHostKeyChecking=yes:

ssh-keyscan git.example.com > known_hosts
kubectl -n production create secret generic api-gateway-git \
  --from-file=ssh-key=./deploy_key --from-file=known_hosts=./known_hosts

Sem known_hosts a sincronização por SSH falha (secret ... has no "known_hosts" key), a menos que o SourceRepository defina spec.sshHostKeyPolicy: acceptNew, que confia na chave que o host apresenta no primeiro contato e rejeita uma chave diferente depois (lembrada enquanto durar o pod do operator). O padrão, strict, é a escolha segura: fixe as chaves do host no Secret.

Verificação: kubectl -n production get sourcerepositories mostra o repositório pronto depois da primeira sincronização.

5. Notificações

Coloque URLs de webhook, routing keys e senhas num Secret. Todas as chaves do Secret do secretRef de um canal são mescladas no config dele. Não as coloque no config em si: GET /api/v1/policies/notification devolve o spec inteiro para qualquer chave com papel viewer.

kubectl -n chatcli-system create secret generic notify-slack \
  --from-literal=webhook_url='https://hooks.slack.com/services/<id>'
kubectl -n chatcli-system create secret generic notify-pagerduty \
  --from-literal=routing_key='<routing-key-pagerduty>'
kubectl -n chatcli-system create secret generic notify-smtp \
  --from-literal=smtp_user='aiops@example.com' \
  --from-literal=smtp_password='<senha-smtp>'

apiVersion: platform.chatcli.io/v1alpha1
kind: NotificationPolicy
metadata:
  name: production-notifications
  namespace: chatcli-system
spec:
  enabled: true
  channels:
    - name: slack-incidents
      type: slack
      config:
        channel: "#incidents"
      secretRef:
        name: notify-slack
    - name: pagerduty-critical
      type: pagerduty
      config: {}
      secretRef:
        name: notify-pagerduty
    - name: email-sre
      type: email
      config:
        smtp_host: smtp.example.com
        smtp_port: "587"                 # config é um mapa de strings: coloque números entre aspas
        from: aiops@example.com
        to: "sre@example.com,oncall@example.com"
      secretRef:
        name: notify-smtp
  rules:
    - name: critical-page
      severities: [critical]
      namespaces: [production]           # o namespace do recurso afetado
      states: [Detected, Contained, Escalated, Resolved]
      channels: [pagerduty-critical, slack-incidents]
    - name: high-to-slack
      severities: [critical, high]
      states: [Detected, Remediating, Contained, Resolved, Escalated, Failed]
      channels: [slack-incidents]
    - name: slo-violations
      signalTypes: [slo_violation]       # Issues abertas pelo controller de SLO
      channels: [slack-incidents, email-sre]
  throttle:
    maxPerHour: 20
    deduplicationWindow: "30s"

Mantenha deduplicationWindow curto. Uma notificação dentro da janela é descartada, não enfileirada, então com o padrão de 5m uma Issue que se resolve rápido pode nunca mandar o Resolved para o Slack ou o e-mail. O Resolved para PagerDuty e OpsGenie nunca é limitado, nem pela janela nem pelo maxPerHour, então o page sempre é fechado. Contained significa que a plataforma conteve o impacto (por exemplo, escalou a carga para zero) sem corrigir a causa, e alguém precisa agir: mande esse estado para o pager. Veja Notificações para as chaves de cada canal e os templates.

6. Escalação

Uma escalação começa quando a Issue chega a Escalated, o que acontece quando as tentativas de remediação acabam. Ela para quando a Issue fica Resolved ou quando alguém a reconhece (acknowledge). O operator usa a primeira política habilitada, de qualquer namespace, cujo severities inclua a severidade da Issue.

apiVersion: platform.chatcli.io/v1alpha1
kind: EscalationPolicy
metadata:
  name: production-escalation
  namespace: chatcli-system
spec:
  enabled: true
  severities: [critical, high]
  levels:
    - name: L1-OnCall
      timeoutMinutes: 10
      targets:
        - type: oncall
          name: sre-primary
      notifyChannels: [slack-incidents]
    - name: L2-SRE-Leads
      timeoutMinutes: 20
      targets:
        - type: team
          name: sre-leads
        - type: user
          name: sre-lead@example.com
      notifyChannels: [slack-incidents, pagerduty-critical, email-sre]
      repeatIntervalMinutes: 15          # aciona de novo a cada 15 minutos até o acknowledge ou a resolução

Os targets são só informativos: entram no texto da mensagem, e a mensagem vai para os notifyChannels de cada nível, procurados pelo nome nas NotificationPolicies habilitadas.

Como uma escalação se comporta:

O nível atual fica salvo na Issue (platform.chatcli.io/escalation-level, com escalation-notified-at para o último acionamento). Cada timeoutMinutes sobe um nível, até o último, onde ela fica. chatcli_operator_escalation_level_reached sobe um a cada nível alcançado.
repeatIntervalMinutes reenvia a mensagem do nível atual nesse intervalo; no último nível, continua repetindo. 0 (o padrão) nunca repete.
O acknowledge (dashboard, ou POST /api/v1/incidents/<name>/acknowledge) para a escalação onde ela está: nenhum nível a mais, nenhuma repetição. A EscalationPolicy registra acknowledgedAt e acknowledgedBy (o role da API key de quem chamou) em status.activeEscalations.
O snooze (POST /api/v1/incidents/<name>/snooze com um duration positivo, como "30m") segura todas as notificações da Issue, menos o Resolved, e segura a escalação. O acionamento de nível que cai dentro do snooze é marcado com escalation-pending-notify e sai quando o snooze termina; o timer do nível recomeça nesse momento.
Issues de um drill de chaos nunca escalam.

7. SLOs e SLAs

SLO

Os SLOs são calculados a partir das próprias Issues e Anomalies do operator para o recurso, não a partir do Prometheus. Crie o SLO no namespace da carga.

apiVersion: platform.chatcli.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-gateway-availability
  namespace: production
spec:
  serviceName: api-gateway
  description: "api-gateway mantém 99,9% de disponibilidade em 30 dias"
  enabled: true
  indicator:
    type: availability
    metricSource: issues
    resource:
      kind: Deployment
      name: api-gateway
      namespace: production
  target:
    percentage: 99.9
    window: "30d"
  alertPolicy:
    burnRateWindows:
      - shortWindow: "1h"
        longWindow: "6h"
        burnRateThreshold: 14.4
        severity: critical
      - shortWindow: "6h"
        longWindow: "72h"
        burnRateThreshold: 6
        severity: high
    pageOnBudgetExhausted: false

Uma janela de burn rate que dispara abre uma Issue com signalType: slo_violation, que a regra slo-violations do passo 5 encaminha.

pageOnBudgetExhausted: true abre uma Issue crítica quando o budget chega a zero. Ele só aciona de novo depois que o budget volta a ficar acima de zero e se esgota outra vez; enquanto essa Issue de esgotamento estiver aberta, nenhuma segunda é criada.
As Issues slo_violation do próprio SLO não contam como indisponibilidade, então um acionamento não aprofunda a violação que ele reporta.
metricSource: prometheus não é consultado: o SLI continua sendo calculado a partir de Issues e Anomalies, e o SLO reporta a condição MetricSourceSupported=False. prometheusQuery, latencyPercentile e latencyThresholdMs não são avaliados, e alertPolicy.notificationPolicyRef é reservado: as Issues do SLO são notificadas por toda NotificationPolicy cujas regras casem com elas.

SLA

Vale a IncidentSLA do namespace da Issue. Se não houver, vale uma com a mesma severidade de qualquer namespace, então um conjunto em chatcli-system funciona como padrão do cluster inteiro.

apiVersion: platform.chatcli.io/v1alpha1
kind: IncidentSLA
metadata:
  name: sla-critical
  namespace: chatcli-system
spec:
  severity: critical
  responseTime: "5m"
  resolutionTime: "1h"
  businessHoursOnly: false        # crítico roda num relógio 24/7
---
apiVersion: platform.chatcli.io/v1alpha1
kind: IncidentSLA
metadata:
  name: sla-high
  namespace: chatcli-system
spec:
  severity: high
  responseTime: "15m"
  resolutionTime: "4h"            # dias inteiros podem abrir o valor: "1d", "2d12h"
  businessHoursOnly: true
  businessHours:
    timezone: "America/Sao_Paulo"
    startHour: 9
    endHour: 18
    workDays: ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]

Uma violação fica registrada no status da IncidentSLA, na Issue (platform.chatcli.io/sla-violated, mais platform.chatcli.io/sla-name com a SLA que a contou) e na trilha de auditoria. status.activeViolations volta a cair quando a Issue é resolvida. Uma duração inválida deixa a condição Ready da SLA em False com o motivo InvalidDuration. Uma violação não envia notificação: escalationPolicyRef e notificationPolicyRef são reservados e não são lidos. Alerte com chatcli_operator_sla_violations_total. Veja SLOs e SLAs para o cálculo e os campos de status.

8. Dashboard e chaves da API REST

A API REST e o dashboard web dividem a porta 8090 do Service do operator. Toda chamada em /api/ precisa do header X-API-Key. As chaves vêm do Secret chatcli-operator-secrets (chave api-keys) no namespace do operator. O nome é fixo. Sem ele, toda chamada em /api/ devolve 401.

ADMIN_KEY="$(openssl rand -hex 32)"
VIEWER_KEY="$(openssl rand -hex 32)"

kubectl -n chatcli-system create secret generic chatcli-operator-secrets \
  --from-literal=api-keys="$(cat <<EOF
- key: "${ADMIN_KEY}"
  role: admin
  name: alice
  description: time de plataforma
- key: "${VIEWER_KEY}"
  role: viewer
  description: dashboards somente leitura
EOF
)"

Papel	Pode
`viewer`	Ler tudo (incidentes, SLOs, aprovações, postmortems, analytics, auditoria, políticas)
`operator`	Também reconhecer, adiar e resolver incidentes, aprovar ou rejeitar pedidos, revisar postmortems, criar e editar runbooks
`admin`	Tudo, inclusive apagar runbooks

Qualquer outro nome de papel não dá acesso nenhum. O operator relê o Secret a cada 30 segundos, então mudar chaves não exige restart. Editar o Secret para tirar uma chave revoga essa chave, e uma lista vazia não deixa nenhuma chave válida. Um YAML que não faz parse mantém em vigor o último conjunto de chaves válido (o operator registra isso no log uma vez por versão), então corrija o erro em vez de contar com ele para revogar. Um Secret sem a entrada api-keys cai para o ConfigMap; apagar o Secret e também o ConfigMap chatcli-operator-config revoga todas as chaves em cerca de 30 segundos (401 a partir daí). Um erro de leitura que não seja “não encontrado” mantém as chaves em vigor. A inicialização aplica as mesmas regras da consulta periódica. Cada entrada também aceita um name opcional, a identidade registrada nas aprovações feitas com aquela chave (na falta dele vale o description, e depois uma impressão digital key-<hash>). Um quorum conta cada chave uma vez, então dê a cada aprovador a sua própria chave. Em vez do kubectl, o chart pode gerar o mesmo Secret (--set apiKeys.create=true com apiKeys.entries), mas aí as chaves ficam guardadas na release do Helm. Abra o dashboard:

kubectl -n chatcli-system port-forward svc/chatcli-operator 8090:8090
# http://localhost:8090 — cole uma chave quando pedir; o navegador guarda no localStorage

Para publicar, sirva o dashboard na raiz de um host próprio. O dashboard chama /api/v1/... com caminho absoluto, então um sub-path com rewrite-target carrega a página mas quebra todas as chamadas da API.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: chatcli-dashboard
  namespace: chatcli-system
spec:
  ingressClassName: nginx
  tls:
    - hosts: [aiops.example.com]
      secretName: aiops-example-com-tls
  rules:
    - host: aiops.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: chatcli-operator
                port:
                  name: api

O rate limit da API REST conta as requisições sem chave válida por host de origem (30 por minuto) e cada chave válida separadamente (600 por minuto). Atrás de um ingress, o host de origem é o ingress controller, então todo o tráfego sem autenticação divide um único bucket. Para TLS na própria porta 8090, monte um certificado com extraVolumes/extraVolumeMounts e defina security.apiTLS.certFile/keyFile. Não existe login por SSO ou OIDC: o acesso é só por chave de API.

Notas para outros ingress controllers, TLS servido pelo próprio operator e clusters locais estão em Web Dashboard: Acessar e publicar.

9. Aprovações

Uma ApprovalPolicy controla os RemediationPlans do próprio namespace. Dentro de uma política, vale a primeira regra que casar. Os actionTypes de uma regra casam quando qualquer ação do plano está na lista. Coloque as regras mais rígidas primeiro e termine com uma regra que casa com tudo.

apiVersion: platform.chatcli.io/v1alpha1
kind: ApprovalPolicy
metadata:
  name: production-approvals
  namespace: production
spec:
  enabled: true
  rules:
    - name: node-actions-manual
      match:
        actionTypes: [DrainNode, CordonNode, UncordonNode]
      mode: manual
      timeoutMinutes: 30
    - name: risky-changes-quorum
      match:
        severities: [critical, high]
        actionTypes: [RollbackDeployment, ScaleDeployment, HelmRollback, ApplyManifest, AdjustResources, PatchConfig]
      mode: quorum
      requiredApprovers: 2
      timeoutMinutes: 20
      changeWindow:
        timezone: "America/Sao_Paulo"
        allowedDays: ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]
        startHour: 9
        endHour: 18                      # exclusivo
    - name: risky-changes-manual
      match:
        actionTypes: [RollbackDeployment, ScaleDeployment, HelmRollback, ApplyManifest, AdjustResources, PatchConfig]
      mode: manual
      timeoutMinutes: 30
    - name: low-risk-auto
      match:
        severities: [low, medium]
        actionTypes: [RestartDeployment, DeletePod]
      mode: auto
    - name: everything-else
      match: {}
      mode: manual
      timeoutMinutes: 30

Como ler:

auto sem autoApproveConditions significa que a política não segura o plano. Uma regra auto com autoApproveConditions segura o plano e só o aprova automaticamente quando todas as condições valem (maxSeverity é comparado com a severidade da Issue; uma severidade desconhecida não atende); caso contrário, um humano decide. Um plano com um restart e uma ação que nenhuma regra anterior lista também roda pela low-risk-auto.
defaultMode é informativo: o kubectl get ap o mostra, mas o operator não o aplica. Sem regra que case, a política não segura o plano, e é por isso que a última regra (match: {}) é um pega-tudo que segura todo o resto.
DrainNode faz cordon do nó e despeja os pods pela Eviction API policy/v1 com 30 segundos de grace period, então os PodDisruptionBudgets são respeitados. Despejos recusados com 429 ou erro de servidor são refeitos a cada 5 segundos até o param opcional timeout (padrão 2m, no máximo 10m); depois disso a ação falha, citando os pods que não conseguiu despejar. Pods de DaemonSet e mirror pods são pulados. Mesmo assim, deixe essa ação atrás de uma regra manual.
O gate falha fechado. Se a Issue, o AIInsight ou as ApprovalPolicies não puderem ser lidos, ou o decision engine der erro, o plano fica em Pending, um Event de Warning ApprovalGateUnavailable é registrado nele e ele é tentado de novo com backoff. Um plano cuja Issue pai sumiu falha (“Parent issue not found…”). Um AIInsight ausente conta como confiança 0, o que só deixa o gate mais rígido.

Aprove com uma anotação no ApprovalRequest (chamado approval-<plano>, no namespace do plano). Restrinja update/patch em approvalrequests com RBAC a quem pode aprovar, porque o nome de quem aprova é texto livre:

kubectl -n production get approvalrequests
kubectl -n production annotate approvalrequest approval-<plano> \
  platform.chatcli.io/approve="alice:rollback revisado"

O dashboard e o POST /api/v1/approvals/{name}/approve (ou /reject) registram uma decisão num pedido Pending, do mesmo jeito que a anotação. Quem aprovou fica gravado como <nome digitado> (api-key: <identidade da chave>), e o ApprovalReconciler avalia então o requiredApprovers e a janela de mudança. Pela REST, um quorum conta API keys distintas, então uma chave compartilhada não satisfaz requiredApprovers: 2; aprovadores por anotação são contados pelo nome, sem diferenciar maiúsculas. Qualquer rejeição rejeita o pedido. Um pedido que não está Pending, ou uma segunda decisão da mesma chave, responde 409.

A janela de mudança só controla quando uma decisão tem efeito: decisões são registradas a qualquer hora, e uma rejeição vale na hora. O relógio do timeout só corre com a janela aberta, e um pedido já aprovado que só espera a janela não expira; ele vira Approved quando a janela abre, com a condition ChangeWindow=False (reason OutsideChangeWindow) enquanto isso. Uma janela que nunca abre bloqueia a aprovação e expira pelo relógio de parede. Mais dois portões podem segurar um plano sem política nenhuma: o tier do cluster (chart clusterName, com o nome de um ClusterRegistration) e o decision engine (chart decisionEngine.enabled). Veja Fluxo de Aprovação e Decision Engine.

10. Prometheus

São duas integrações separadas: Coleta. O operator expõe /metrics na porta 8080 (chatcli_operator_*). Cada Instance expõe /metrics na porta de métricas (chatcli_grpc_*, chatcli_llm_*, chatcli_watcher_*, chatcli_server_*). As duas são HTTP puro sem autenticação, então restrinja quem alcança essas portas com NetworkPolicy (passos 1 e 3). O serviceMonitor.enabled do chart cobre o operator. Para a Instance:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: chatcli-prod
  namespace: chatcli
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: chatcli
      app.kubernetes.io/instance: chatcli-prod
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

deploy/grafana/dashboards-configmap.yaml traz só dois ServiceMonitors, não os dashboards. O ServiceMonitor do servidor dele seleciona app.kubernetes.io/name: chatcli e a porta metrics, que os Services das Instances (operator) e o Helm chart do servidor têm, em qualquer namespace; aplique-o, ou fique com o ServiceMonitor mais restrito da Instance acima.

Consultas durante a análise. Com prometheusUrl definido no chart do operator (variável PROMETHEUS_URL), o operator consulta o Prometheus no intervalo do incidente e junta o resultado à análise de IA: CPU, memória, restarts e rede por pod, taxas de requisição e de erro, percentis de latência e réplicas do HPA. Ele chama /api/v1/query_range sem autenticação, então a URL precisa chegar a uma API HTTP do Prometheus sem autenticação, normalmente o Service interno do cluster. As métricas de container vêm do cAdvisor e os restarts do kube-state-metrics. Sem essa URL a análise roda do mesmo jeito, só que sem essas métricas.

11. Dashboards do Grafana

O repositório traz quatro dashboards em deploy/grafana/. Os painéis referenciam o datasource ${DS_PROMETHEUS}, que a tela de importação do Grafana resolve, mas o provisionamento pelo sidecar não. Para o sidecar, troque antes pelo UID do seu datasource do Prometheus (prometheus no kube-prometheus-stack; confira em Connections → Data sources no Grafana):

git clone --depth 1 --branch v1.212.2 https://github.com/diillson/chatcli.git
mkdir -p chatcli-dashboards
for f in chatcli/deploy/grafana/*.json; do
  sed 's/\${DS_PROMETHEUS}/prometheus/g' "$f" > "chatcli-dashboards/$(basename "$f")"
done

kubectl -n monitoring create configmap chatcli-grafana-dashboards \
  --from-file=chatcli-dashboards/ --dry-run=client -o yaml | kubectl apply -f -
kubectl -n monitoring label configmap chatcli-grafana-dashboards grafana_dashboard=1 --overwrite

Ou importe cada JSON em Dashboards → New → Import e escolha o datasource ali. Todo painel consulta uma métrica que o operator ou o servidor exporta; veja em Web Dashboard o que cada dashboard mostra.

12. Validar com um drill de chaos

Um drill prova o ciclo de ponta a ponta: a falha é injetada, o watcher percebe, uma Issue é aberta e marcada como drill, e a carga se recupera.

Rode drills só em cargas com réplicas suficientes. Nada é protegido por padrão: todas as proteções abaixo são opcionais, e nenhum namespace é bloqueado a menos que você o liste.

apiVersion: platform.chatcli.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: api-gateway-pod-kill
  namespace: production               # o namespace do alvo
spec:
  experimentType: pod_kill
  target:
    kind: Deployment
    name: api-gateway
    namespace: production
  duration: "3m"                      # janela de observação depois da injeção única
  parameters:
    count: "1"
  dryRun: true                        # primeiro, só as verificações de segurança
  enabled: true
  safetyChecks:
    minHealthyPods: 2                 # verificado uma vez, antes da injeção
    maxConcurrentExperiments: 1
    abortOnIssueDetected: false       # true abortaria assim que o AIOps detectasse a falha que você injetou
    blockedNamespaces: ["kube-system", "chatcli-system", "chatcli"]
  postExperiment:
    verifyRecovery: true
    recoveryTimeout: "5m"

kubectl apply -f chaos.yaml
kubectl -n production get chaosexperiment api-gateway-pod-kill -w
kubectl -n production get chaosexperiment api-gateway-pod-kill -o jsonpath='{.status.result}{"\n"}'
# dry-run: would execute pod_kill on production/api-gateway for 3m

# Completed é final: editar o objeto não inicia outra execução.
# Apague, troque para dryRun: false no chaos.yaml e crie de novo.
kubectl -n production delete chaosexperiment api-gateway-pod-kill
kubectl apply -f chaos.yaml

O que observar:

# Issues abertas durante o drill levam o label de chaos e nunca escalam
kubectl -n production get issues -l platform.chatcli.io/source=chaos-experiment
kubectl -n production get chaosexperiment api-gateway-pod-kill \
  -o jsonpath='{.status.state} recovered={.status.recoveryVerified}{"\n"}'

Limitações para saber antes de planejar drills:

pod_kill e pod_failure funcionam com o RBAC que o chart instala. cpu_stress, memory_stress e disk_stress criam um pod de stress, que o RBAC do chart permite; o pod passa no Pod Security Standard restricted (UID/GID 65534, não-root, seccomp RuntimeDefault, sem escalada de privilégio, todas as capabilities removidas, root filesystem somente leitura com um emptyDir em /tmp, sem token de ServiceAccount). network_delay e network_loss não são suportados: o experimento falha em Pending com uma mensagem dizendo que nada foi injetado.
requireApproval: true cria um ApprovalRequest chaos-<experimento> (ação pedida Custom, timeout de 30 minutos). O experimento roda depois de aprovado; uma rejeição ou expiração faz o experimento falhar.
schedule não é suportado: um experimento que o define falha em Pending e nada roda. Crie um ChaosExperiment por execução.
recoveryTime é medido do fim da injeção até o primeiro health check que passa (os checks rodam a cada 5 segundos); recoveryVerified é o sinal de passou/falhou. As Issues do drill ficam fora do MTTD e do MTTR.

Veja Chaos Engineering para todos os tipos, parâmetros e estados.

13. Verificar a instalação

Operator e CRDs

kubectl -n chatcli-system get pods -l app.kubernetes.io/name=chatcli-operator
kubectl get crd -o name | grep -c platform.chatcli.io            # 17

Condições da Instance

kubectl -n chatcli get instance chatcli-prod
kubectl -n chatcli get instance chatcli-prod \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status} {.reason}{"\n"}{end}'

As cinco condições precisam estar True, como no passo 3.

A ponte de alertas está conectada

kubectl -n chatcli-system logs -l app.kubernetes.io/name=chatcli-operator --prefix --tail=-1 \
  | grep -E 'Connected to Instance|Alert stream open|no ready Instance'

Espere Connected to Instance seguido de Alert stream open no líder. Connected to Instance sozinho não prova nada, porque a conexão é aberta de forma preguiçosa. Erros de TLS e de credencial aparecem em ServerReachable e nos erros do stream que vêm depois.

gRPC de ponta a ponta, com TLS e o token

kubectl -n chatcli port-forward svc/chatcli-prod 50051:50051 &
kubectl -n chatcli get secret chatcli-prod-tls -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
TOKEN="$(kubectl -n chatcli get secret chatcli-prod-token -o jsonpath='{.data.token}' | base64 -d)"

chatcli connect --addr localhost:50051 --tls --ca-cert ca.crt --token "$TOKEN" -p "Responda com OK"

Isso depende do SAN localhost do passo 2.

API REST e dashboard

kubectl -n chatcli-system port-forward svc/chatcli-operator 8090:8090 &
curl -s http://localhost:8090/readyz                                   # {"status":"ready",...}
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8090/api/v1/incidents                        # 401
curl -s -o /dev/null -w '%{http_code}\n' -H "X-API-Key: $VIEWER_KEY" http://localhost:8090/api/v1/incidents  # 200

Métricas

No Prometheus, up{namespace="chatcli-system"} e up{namespace="chatcli"} estão em 1, e chatcli_operator_instance_ready e chatcli_server_info retornam séries.

As políticas foram carregadas

kubectl get notificationpolicies,escalationpolicies,incidentslas -A
kubectl -n production get approvalpolicies,servicelevelobjectives

O pipeline reage

Rode o drill do passo 12 e acompanhe uma Issue aparecer em production e no dashboard.

14. Troubleshooting

Sintoma	Causa	Correção
Nenhum Deployment; `AuthenticationConfigured=False` (`CredentialMissing`)	A Instance não tem credencial	Defina `spec.server.token` (ou JWT, ou uma CA de cliente)
Nenhum Deployment; `TLSConfigured=False` (`SecretNameMissing`)	`tls.enabled: true` sem `tls.secretName`	Defina o nome do Secret
Pods parados em `ContainerCreating`, evento `secret "..." not found`	O Secret de TLS não existe no namespace da Instance	Crie o Secret (passo 2)
O pod sai na inicialização	A recusa é a última linha do `kubectl logs --previous` (num pod o servidor escreve o log no stderr); quase sempre uma credencial ausente	Leia e corrija o que ela aponta
O log mostra `refusing to serve an unauthenticated API`	O Secret ou a chave do token não existe. As referências a Secret são opcionais, então a variável é descartada em silêncio	Confira o nome do Secret e a `key` em `spec.server.token`
`ServerReachable=False`, `x509: certificate is valid for ..., not chatcli-prod.chatcli.svc.cluster.local`	O certificado não tem o nome interno do cluster	Emita de novo com os SANs do passo 2
`ServerReachable=False`, `x509: certificate signed by unknown authority`	Sem `ca.crt` no Secret, e a CA não é pública	Acrescente o `ca.crt` (o cert-manager com issuer de CA grava sozinho)
`ServerReachable=False`, `server info (credential check)` e `Unauthenticated`	A credencial do operator é recusada	Confira `OperatorCredentialConfigured`; um servidor só com RS256 (`jwtPublicKeyRef`) precisa de `operatorTokenRef` ou `operatorClientCertSecretName`
`Unauthenticated: authentication failed` e o log do servidor mostra `auth failure rate limit exceeded`	Algo no host do operator falhou a autenticação mais de 5 vezes num minuto e esgotou a cota de falhas desse host (rajada de 5, depois uma a cada 12 segundos; só autenticações que falham contam, credenciais válidas nunca são limitadas)	Encontre o chamador com credencial errada ou expirada; a cota repõe sozinha
`ServerReachable=False` (`ProbeFailed`, `DeadlineExceeded` ou `connection refused`) logo depois de um rollout, com os pods Ready	A sondagem rodou enquanto os pods eram trocados	Passageiro: uma sondagem que falha é repetida em 30 segundos; veja Condições da Instance
`ServerReachable=Unknown` (`DeploymentNotReady`)	Nenhum pod está pronto	`kubectl -n chatcli describe pod`; confira as probes em `/healthz` (porta 9090)
Alguns pods em `ContainerCreating` com `Multi-Attach error`	PVC de sessões RWO com `replicas > 1`	Desligue a persistência ou use uma réplica (passo 3)
O operator loga `no ready Instance found`	Nenhuma Instance está `Ready` ainda	Corrija a Instance primeiro
O dashboard ou `/api/` devolve 401 `no API keys configured`	O Secret `chatcli-operator-secrets` não existe, ou está em outro namespace	Crie o Secret no namespace do operator (passo 8)
A API REST devolve 429	Rate limit: 30 por minuto por host sem chave válida	Envie um `X-API-Key` válido; cada chave tem 600 por minuto
A página do dashboard abre atrás de um ingress, mas todo painel dá erro	Servido num sub-path	Use um host próprio na raiz `/` (passo 8)
Nenhuma Issue para uma carga observada	O alvo está em outro namespace sem RBAC, ou há várias Instances prontas	Confira o ClusterRoleBinding `chatcli-chatcli-prod-watcher`; mantenha uma Instance por cluster
A sincronização do `SourceRepository` falha com `read-only file system` ou `no space left on device`	Um chart do operator sem o emptyDir `/tmp`, ou um clone maior que `tmpVolume.sizeLimit`	Atualize o chart do operator; aumente `tmpVolume.sizeLimit`
A sincronização SSH do `SourceRepository` falha com `has no "known_hosts" key` ou `Host key verification failed`	O Secret não tem `known_hosts`, ou a chave do host mudou	Acrescente a saída do `ssh-keyscan` como `known_hosts`, ou defina `spec.sshHostKeyPolicy: acceptNew`
Grafana: `Datasource ${DS_PROMETHEUS} was not found`	Provisionado pelo sidecar sem trocar o UID do datasource	Use o laço com `sed` do passo 11, ou importe pela interface
O experimento de chaos fica em `Pending`	`requireApproval: true`, ou `maxConcurrentExperiments` atingido	Tire o `requireApproval`; espere o experimento em execução terminar

Cookbook

AIOps: Setup Produção Completo

Pré-requisitos

Onde cada recurso fica

1. Instalar o operator

2. Criar os Secrets da Instance

Certificado TLS

3. Criar a Instance de produção

4. Vincular repositórios de código (opcional)

5. Notificações

6. Escalação

7. SLOs e SLAs

SLO

SLA

8. Dashboard e chaves da API REST

9. Aprovações

10. Prometheus

11. Dashboards do Grafana

12. Validar com um drill de chaos

13. Verificar a instalação

14. Troubleshooting

Checklist de produção

Próximos passos

Hardening de segurança

K8s Operator

Fluxo de Aprovação

API REST

​Pré-requisitos

​Onde cada recurso fica

​1. Instalar o operator

​2. Criar os Secrets da Instance

​Certificado TLS

​3. Criar a Instance de produção

​4. Vincular repositórios de código (opcional)

​5. Notificações

​6. Escalação

​7. SLOs e SLAs

​SLO

​SLA

​8. Dashboard e chaves da API REST

​9. Aprovações

​10. Prometheus

​11. Dashboards do Grafana

​12. Validar com um drill de chaos

​13. Verificar a instalação

​14. Troubleshooting

​Checklist de produção

​Próximos passos

Hardening de segurança

K8s Operator

Fluxo de Aprovação

API REST

Pré-requisitos

Onde cada recurso fica

1. Instalar o operator

2. Criar os Secrets da Instance

Certificado TLS

3. Criar a Instance de produção

4. Vincular repositórios de código (opcional)

5. Notificações

6. Escalação

7. SLOs e SLAs

SLO

SLA

8. Dashboard e chaves da API REST

9. Aprovações

10. Prometheus

11. Dashboards do Grafana

12. Validar com um drill de chaos

13. Verificar a instalação

14. Troubleshooting

Checklist de produção

Próximos passos