Standard Operating Procedures

1) O que é o SOP e o que é necessário

O SOP (Standard Operating Procedure) é uma sequência de passos formalizados e aprovados para operações repetitivas com entradas/saídas, papéis e critérios de qualidade.

• Redução da variabilidade de execução e riscos.
• Redução de MTTA/MTTR por meio de ações prontas.
• Complacência e auditoria: reprodução, rastreabilidade.
• Acelera o aprendizado e «shadow → solo».

SOP playbook: playbook - árvore de soluções de bifurcação, SOP - regulamento linear para um cenário específico (ou ramo de playbook).

2) Princípios «bom» SOP

Outcome-Driven: foco em resultados (SLO/Critérios de Negócios), não apenas em passos.
Inequívocos: comandos, parâmetros, efeitos esperados e pontos de controle.
A segurança padrão é gate, limite, backout/rollback.
Mínimo de contexto: Notas curtas + links de runbook detalhado/diagnóstico.
Relevância: data de revezamento, proprietário, versão, data de validade.
Execução: Acessibilidade de JIT/JEA, verificações de pré-palavras, modelos de artefatos.

3) Estrutura SOP padrão (esqueleto)

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4) Catálogo SOP e posse

Repositório único (Docs-as-Code) com marcas de formatação: 'domain/ops',' service/checkout ',' risk/high ',' provider/psp-a '.
O cartão do proprietário, a equipa, os contactos, o dono da reserva.
SLA relevante (por exemplo, revisão a cada ≤90 dias ou após o incidente/lançamento).
Linter/Validador SOP (CI): verificação de estrutura, links, proprietários, prazos.

5) Ciclo de vida SOP

1. Iniciar (após incidente/exercício/novo processo).
2. Rascunho (autor = dono do serviço/processo).
3. Revezamento (SRE/Segurança/Legal/Comms - domínio).
4. Piloto (tabletop/game day): medimos o tempo, as descobertas → as alterações.
5. Publicação (versão, data, número, modelos no CMDB/diretório do serviço).
6. Aplicações operacionais (anotações em tíquetes/bate-papos, coleta de evidence).
7. Atualização (RCA/CAPA, tempo de revezamento, mudanças na arquitetura).
8. Arquivamento/depredação (substituído por um novo SOP/playbook).

6) Ligações com artefatos vizinhos

Playbooks: SOP - «ramo de linha» dentro do playbook; referência de passos.
Runbook 'e: pormenores técnicos/script foram trazidos no runbook, SOP se refere.
Políticas (Policy-as-Code): gates de tolerância, reticência, RBAC - links obrigatórios.
SLO/SLI: critérios de sucesso e garde-rails.
Matriz de escalações: rol/timing quando a SOP falha.
Janelas de serviço: requisitos de slot/comms para high-risk SOP.

7) Métricas de eficiência SOP

Time-to-Execute (mediana/p95) - Quanto tempo o procedimento leva.
Sucess Rate - Proporção de resultados bem sucedidos sem escalar/reverter.
O Evidence Completeness é um artefato cheio.
SLO Impact - se há degradação durante/depois do passo (burn-minuto).
Defect Density - Observações em 10 SOP.
Freshness - porção SOP com ciúmes de ≤90 dias.
Adopção - Quantas alertas/ocas estão realmente ligadas ao SOP.

8) Folha de cheque do autor do SOP

• O objetivo e os limites da aplicação estão definidos.
• Papéis, acessíveis e janelas - descritas.
• Gates de qualidade e SLO - medíveis, há fontes de sinal.
• Os passos são executáveis: comandos/script, resultados esperados, verificação.
• Backout/rollback e critérios de lançamento são claros.
• Modelos comm anexados.
• A lista de evidence está estruturada.
• A versão/data/dono/revezamento estão especificados.

9) Folha de cheque do executor SOP

• Pré-palavras confirmadas e acessíveis JIT/JEA.
• Tíquete/war-room aberto e anotações ativadas.
• Observabilidade: os dashboards/alertas desejados estão abertos.
• Cumpro as etapas de ordem; depois de cada um, uma verificação.
• Em caso de violação de gardrelas - backout imediato e escalação.
• A evidência está preenchida; teste final SLO/Business SLI.
• O tíquete está fechado e o status da página/coms foi atualizado.

10) Exemplos de SOP (fatias)

10. 1 SOP: ReL-ROLLBACK-01

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10. 2 SOP: Upgrade BD (MW-DB-UPGRADE-02)

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10. 3 SOP: Mudar de provedor PSP (PROV-PSP-SWITCH-01)

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10. 4 SOP: Verificação de Recuperação de Bacape (DATA-BACKUP-RESTORE-CHECK-03)

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11) Automação em torno de SOP

Modelo SOP: geração de esqueleto com RACI/gates/KOM.
Executivo de bot: passos com cheque-boxes, temporizadores, lembretes de cadence, reunião automática de evidence.
Integração com CMDB/diretório: o serviço tem uma lista de SOP relevantes.
Anotações de telemetria: «SOP-RUN: <ID> step N» → análise rápida.
Políticas de tolerância: pod/janela só começam com gates verde SOP.

12) Anti-pattern

SOP sem dono/data de revezamento - documento «morto».
Instruções inchadas sem critérios de sucesso e backout.
Comandos/chaves incoerentes - risco de erros e fugas.
Versões diferentes no wiki e no repositório - divergência de fontes da verdade.
Sem evidence - não há como confirmar qualidade/complacência.
«Um SOP para todos os casos» - perde-se a execução.

13) Mapa de trânsito de implementação (4-6 semanas)

1. Ned. 1: Aprovar o modelo SOP, o linter e o diretório; escolher o top 10 do cenário.
2. Ned. 2: escrever SOP para lançamentos/reversão/provedor/bacapes; pilotos tabletop.
3. Ned. 3: ligar o ChatOps-bot e anotações de telemetria; ligar as alertas ao SOP.
4. Ned. 4: Gráfica trimestral de revo; digitar as métricas Freshness/Sucess Rate.
5. Ned. 5-6 - cobrir 90% das operações críticas; DR/Security-SOP; automatizar a coleta de evidence.

14) Total

A SOP torna as operações previsíveis e verificáveis, como gates de qualidade unificada, passos detalhados, papéis claros e reversibilidade. Associado a playbooks, políticas, SLO e automação, isso transforma a operação em uma linha de produção confiável - reações rápidas, risco mínimo e responsabilidade compreensível.