Papéis e responsabilidades em operações

1) Por que formalizar os papéis

A distribuição clara dos papéis reduz o MTTA/MTTR, elimina «zonas cinzentas», agiliza os lançamentos e torna a conformidade SLO/Complance reproduível. Papéis = Responsabilidade + Autoridade + Interfaces (para quem escrevemos, para quem escalamos, para quais soluções estão autorizadas).

2) Modelo RACI básico

R (Resolvível) - executa o trabalho.
A (Accountable) - tem responsabilidade final e toma decisões.
C (Consulted) é um especialista consultado antes/durante.
I (Informed) - Informado por SLA.

3) Diretório de papéis (descrições e responsabilidades)

3. 1 Incident Commander (IC)

Objectivo: Gerencia a resposta para o incidente SEC-1/0.
Permissões: anunciar SEV, congelar lançamentos, mudar de tráfego, escalar.
As principais tarefas são timeline, tomada de decisões, retenção de foco, distribuição de tarefas, Go/No-Go.
Artefactos, cartão de ocorrência, updates SLA, AAR final.

3. 2 P1/P2 On-Call (Primary/Secondary)

Objetivo: resposta primária e ação técnica.
P1: triagem, lançamento de playbooks, ligação com IC.
P2: Bacap, mudanças complexas, retenção de contexto, tempestades - pega os botões.

3. 3 SRE / Platform Engineer

Alvo: confiabilidade de plataforma e corrimão (SLO, alert, GitOps, scale automático, DR.).
Tarefas: SLI/SLO, alert-higiene, lançamentos progressivos, infraestrutura como código, capacidade, observabilidade.
Durante o incidente, diagnóstico de raiz, retrações/folbacks, inclusão de degrade-UX.

3. 4 Service Owner / Product Owner

O objetivo é a qualidade do serviço no sentido empresarial.
Tarefas: definição de SLO/prioridades, negociação de lançamentos/janelas, participação em Go/No-Go.
Coms: decidir quando e o que dizer aos clientes com a Comms.

3. 5 Release Manager

O objetivo é entregar as alterações de forma segura.
Tarefas: Orquestra lançamentos, checkup gate, canário/azul-green, anotações de lançamentos, freeze em incidentes.

3. 6 CAB Chair / Change Manager

O objetivo é controlar o risco de mudança.
Tarefas: processo RFC, plano/backout, calendário de conflitos, aprovação high-risk.

3. 7 RCA Lead / Problem Manager

Alvo: análise pós-incidente, CAPA.
Tarefas: timeline, causalidade de prova, ação corrigir/prevenir, controle D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

O objectivo é a segurança e resposta aos incidentes de segurança.
Tarefas: triagem de eventos seguros, rotação de chaves, isolamento, forense, notificações regulatórias, auditoria WORM.

3. 9 DataOps / Analytics

Objetivo: confiabilidade de dados e pipas.
Tarefas: frescura/qualidade (DQ), contratos de dados, lineage, backfill, SLA BI/relatórios.

3. 10 FinOps

O objetivo é um custo controlado.
Tarefas: quotas/limites, relatórios $/unidade, gates de orçamento, otimização (volume de logs, egress, reserva).

3. 11 Compliance / Legal

O objetivo é adequar-se à regulação e aos contratos.
Tarefas: prazos de notificação, retoques/evidence imutável, negociação de textos públicos.

3. 12 Support / Comms

O objetivo é comunicar com clientes/steakholders internos.
Tarefas de status, layouts de update, frequência e clareza de mensagens, coleta de feedback.

3. 13 Vendor Manager / Provider Owner

Objetivo: relações com provedores externos (PSP/KYC/CDN etc.).
Tarefas: escalações, SLA/OLA, rotas de reserva, coordenação de janelas.

4) Papéis de mudança e escalação

Mudança: P1/P2 + IC-of-the-day (não combinar com P1).
Escalonamento de tempo: P1→P2 (5 min sem ack) → IC (10 min) → Duty Gerente (15 min).
Quiet Hours: P2/P3 não despertam; os sinais de segurança são sempre.

5) Interfaces de interação (quem com quem e como)

IC ↔ Release Gerente: soluções freeze/rollback.
IC ↔ Comms: texto de update e frequência.
SRE ↔ DataOps: Negócio SLI (sucesso de pagamentos, frescor de dados) em guardrelas SLO.
Segurança ↔ Legal: relatos de incidentes de segurança, datas de notificação.
Vendor Owner ↔ IC: status do provedor, switchover/folback.

6) KPI por papéis (orientações)

IC: Time-to-Declare, cumprimento do Comms SLA, MTTR por SEC-1/0.
P1/P2: MTTA, Time-to-First-Action,% de seguimento para playbooks.
SRE/Platformm: SLO coverage, Alert Hygiene,% de reembolsos automáticos são bem sucedidos.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Sucess Rate Backphils.
Comms: Status Accuracy, Complaint Rating/Incidente.
FinOps: $/unidade,% de economia de QoQ, cumprimento de quotas.

7) Modelos de cartões de papel

7. 1 Cartão IC

Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)

7. 2 Cartões P1/P2

Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries

7. 3 Cartões Release Gerente

Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after

8) Processos e participações de papéis (resumo)

A — Accountable, R — Responsible, C — Consulted, I — Informed.

9) Folhas de cheque

9. 1 Atribuição de papéis

• Cada rol tem um dono, um vice e uma área de cobertura.
• As atribuições são descritas (quais decisões podem ser tomadas).
• Os playbooks e os canais de comunicação estão amarrados.
• SLA publicado por reação/coms.
• O papel está disponível no diretório (CMDB) de cada serviço.

9. 2 Mudança e handover

• O cartão de mudança foi atualizado (incidentes ativos, riscos, janelas).
• Os JIT/JEA disponíveis foram verificados.
• Mensagem de eco para o canal: «mudança aceita/entregue».

9. 3 Pós-incidente

• AAR realizado, RCA atribuído.
• CAPA com proprietários/prazos, D + 14/D + 30 controle.
• Playbooks/alertas/políticas foram atualizados.

10) Anti-pattern

O incerto «quem decide» → atrasos e esforços.
IC combinado com P1 - perda de liderança.
Coms públicos sem acordo com Legal/Comms.
Lançamento sem Release Gerente e gates → crescimento do CFR.
Nenhuma reserva de papel (doença/férias).
«Heróico» em vez de processo: Salvamos manualmente, mas não registramos corrimãos.
Os papéis não constam do CMDB/diretório do serviço → escalas perdidas.

11) Incorporar a ferramentas

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Catálogo/CMDB: O serviço tem dono, on-call, SLO, dashboard, playbooks, janelas.
Alert-as-Code: Cada Page tem um owner e um playbook padrão.
GitOps: As soluções IC/Release são refletidas em anotações de lançamentos e tíquetes.

12) Métricas de maturidade de distribuição de papéis

Coverage papéis em diretórios: ≥ 100% de serviços críticos.
On-call SLA: Ack p95 ≤ 5 min; O Page Storm p95 está controlado.
Postmortem SLA: rascunho ≤ 72h; CAPA completion ≥ 85%.
Mudança governance:% high-risk alterações com RFC/FAB ≥ 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) Mini-modelos

13. 1 RACI para o serviço (arquivo em repo)

yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident:  {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases:  {A: release-manager, R: dev,platform, C: security, I: support}
changes:  {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}

13. 2 Perfil do papel (Markdown)

Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations

14) Total

As operações são sustentáveis quando os papéis são transparentes, autorizados e incorporados às ferramentas. O catálogo de papéis, o RACI, as interfaces claras e as métricas de cada rol transformam incidentes, lançamentos e mudanças em processos gerenciáveis: as decisões são tomadas rapidamente, os riscos são controlados e os usuários veem um serviço estável.