SOP:

Normalização de procedimentos operacionais

1) Por que é necessário

O SOP é o «sistema operacional» da empresa. A normalização remove o caos e os «estilos individuais», reduz o MTTR, o barulho de alertas e os riscos de incidentes, acelera o processo e torna os resultados reproduzíveis.

• Reduzir a variabilidade em incidentes e rotinas.
• Acelerar o treinamento e melhorar a qualidade dos hendowers.
• Tornar os processos verificáveis, auditoria, métricas, melhorias de dados.
• Assegurar que os requisitos regulatórios e internos estejam em conformidade.

2) Princípios de normalização

1. Formato e terminologia unificados. Uma notação, uma definição (SLO, ETA, Owner).
2. Actionable, não é uma enciclopédia. Apenas etapas verificáveis, critérios de sucesso e reversão.
3. Ramificação mínima. Soluções claras «se/se» em vez de falar livremente.
4. Versionização e posse. Cada SOP tem dono, versão e data de revisão.
5. Integração com ferramentas. Referências a dashboards, tíquetes, fichiflags, comandos CLI.
6. Disponibilidade no hole. Procure rapidamente, leia, faça um link.
7. Melhoria contínua. Postmortems → tarefas para atualização SOP.

3) Esqueleto SOP (modelo)

4) SOP classification

Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.

5) RACI: Ownership and Responsibility

Process    R (performer)    A (responsible)    C (consultant)    I (notify)
------------------------      ---------------      -----------------      ---------------      -------------
Create/Update SOP     Domain Owner       Head of Ops         SRE/Compliance      Teams
SLA Revision     Ops Enablement      Head of Ops        Domain leads     All
Use in an incident     On-call          Incident Manager      Domain Owner       Stakeholders

6) SOP lifecycle

1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.

7) Documentation as code (minimum standard)

We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.

8) SOP integrations

Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.

9) SOP quality check (KPI and review)

KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).

Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.

10) Containment standards

Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).

11) SOP examples (fragments)

SOP: Canary pause in SLO degradation

Triggers: error_budget_burn > 4x 10m, api_p99 > 1. 3×baseline 10m

• 1) Pause canary em release-tool (referência)
• 2) Verificar painéis «Mudança Safety» e «API p99»
• 3) Criar tíquete REG- , especificar baseline/janela
• DoD: p99 ≤ 1. 1 x baseline 15m, erros
• Rollback: Desligamento total da bandeira, depois da morte ≤72ch

SOP: PSP Provider Feilover

Triggers: quota_usage>0. 9 OR outbound_error_rate>2×baseline 5m

• 1) Incluir routing PSP-Y (config/botão)
• 2) Verificar conversão de depósitos e p95 PSP-Y
• 3) Anotações em gráficos, update em # invident-channel
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: retoma parcial de tráfego de 20% com estabilização PSP-X

12) Folhas de cheque

Folha de cheque pronto SOP:
[] O alvo e os desencadeadores são compreensíveis e mensuráveis.
[] Há passos a passo com comandos/links.
[] DoD/Rollback formulados.
[] Escaladas e contatos são relevantes.
[] Os metadados estão cheios (owner, version, last _ review).
[] O cheque Link e o validador CI passam.

Folha de cheque de aplicação da SOP (no incidente):
[] O SOP está aberto a partir do Invident Gerente/links de painel.
[] Os passos foram cumpridos e os resultados foram registrados.
[] DoD alcançado/não - marcado.
[] As ações/inconsistências estão escritas no tíquete.
[] Atualizações/melhorias do SOP foram criadas por tarefas (se necessário).

13) Treinamento e onboarding

Mini-cursos de SOP (Payments/Bets/Games/KYC).
Serviço Shadow com aplicação obrigatória de SOP no treino.
Clínicas «SOP» semanais: 30 minutos de análises/melhorias.
Simulações (game-days): processamento de SOP de DRs e incidentes.

14) Gerenciamento de alterações SOP

RFC via PR, tags 'menor/major/breaking'.
Mudanças Breaking - com treinamento e anúncio obrigatórios.
Notificações automáticas para os donos dos domínios e para a cola.
Uma «Nota SOP-Release» separada no final de cada semana.

15) Anti-pattern

Um formulário livre e diferentes modelos por comandos.
SOP sem dono/versão/data de revisão.
Texto «enciclopédico» em vez de passo a passo.
Não há nada para verificar o sucesso.
Referências batidas, comandos manualmente de bate-papo, etapas privadas «secretas».
Alterações de SOP invisíveis sem gravação ou treinamento.

16) 30/60/90 - plano de implementação

30 dias:
Aprovar modelo SOP e padrões mínimos.
Criar um repositório de 'ops-sop/' (docs-as-código) e incluir linteres CI.
Digitalizar 10-15 SOP críticos (incidentes/lançamentos/provedores).
Conectar o Invident Gerente e painéis de observabilidade a links SOP.

60 dias:
Atingir Coverage ≥ 70% em cenários críticos.
Iniciar as clínicas «SOP» e treinamentos semanais.
Adicionar pesquisa AI (RAP) por SOP e TL; Dr. Cartões.
Digite o Review SLA (180 dias) e os relatórios de SOP vencidos.

90 dias:
Coverage ≥ 90%, Usage Rate ≥ 70% incidentes.
Incorporar DoD/Rollback em todas as SOPs e fechar links batidos (0).
Vincular KPI SOP a comandos OKR (MTTR, Mudança Failure Rate).
Fazer retrô e registrar melhorias no próximo trimestre.

17) FAQ

Q: Em que o SOP é diferente do runbook?
A: SOP - Procedimento normalizado (regulamento «como certo»). Runbook - instruções detalhadas para uma mala/serviço específico. Muitas vezes, o SOP faz referência a um ou mais runbook.

Q: Quantas peças devem estar no SOP?
A: Exactamente o suficiente para que o operador possa executar as ações sem «terminar» no bate-papo. Tudo o que não afeta a ação está em referências individuais.

Como manter a relevância?
A: Revisões SLA ( dias), lembretes automáticos, linteres CI e métrica. Qualquer incidente de desvio → uma tarefa para atualizar o SOP.