Standard Operating Procedures

1) Qué es SOP y por qué lo necesita

SOP (Standard Operating Procedure) es una secuencia de pasos formalizada y aprobada para operaciones repetibles con entradas/salidas comprensibles, roles y criterios de calidad.

• Reducción de la variabilidad de la ejecución y los riesgos.
• Reducción de MTTA/MTTR mediante acciones preparadas.
• Cumplimiento y auditoría: reproducibilidad, rastreabilidad.
• Onboarding: aceleración del aprendizaje y «shadow → solo».

SOP ≠ playbook: playbook es un árbol de soluciones con bifurcaciones, SOP es un reglamento lineal para un escenario específico (o rama de playbook).

2) Principios del SOP «bueno»

Outcome-Driven: enfoque en el resultado (criterios SLO/Business), no sólo en los pasos.
Inequívoco: comandos, parámetros, efectos esperados y puntos de control.
Seguridad predeterminada: gates, límites, backout/rollback prescritos.
Mínimo contexto: notas cortas + enlaces a runbook/diagnósticos detallados.
Relevancia: fecha de rugido, propietario, versión, fecha de caducidad.
Ejecutabilidad: accesos JIT/JEA, comprobaciones de precondiciones, plantillas de artefactos.

3) Estructura estándar SOP (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 y propiedad

Repositorio único (Docs-as-Code) con las etiquetas: 'domain/ops',' service/checkout ',' risk/high ',' provider/psp-a '.
Tarjeta del propietario: equipo, contactos de turno, propietario de reserva.
SLA de relevancia (por ejemplo, revisión cada ≤90 días o después de un incidente/lanzamiento).
Linter/validador SOP (CI): verificación de la estructura, referencias, propietarios, período de rugido.

5) Ciclo de vida SOP

1. Iniciación (después del incidente/simulacro/nuevo proceso).
2. Borrador (autor = propietario del servicio/proceso).
3. Revue (SRE/Security/Legal/Comms - por dominio).
4. Piloto (día de tabletop/game): medimos el tiempo, los hallazgos → la edición.
5. Publicación (versión, fecha, número, plantillas en el directorio CMDB/servicio).
6. Aplicación operativa (anotaciones en tickets/chats, recopilación de evidence).
7. Actualización (por RCA/CAPA, por tiempo de rugido, por cambios de arquitectura).
8. Archivado/depreciación (reemplazado por un nuevo SOP/playbook).

6) Conexiones con artefactos vecinos

Playbucks: SOP es una «rama lineal» dentro del playbook; una referencia de los pasos.
Runbook 'y: detalles técnicos/scripts publicados en el runbook, SOP se refiere.
Políticas (Policy-as-Code): puertas de acceso, retenciones, RBAC - referencias obligatorias.
SLO/SLI: criterios de éxito y garde-rails.
Matriz de escalamiento: funciones/tiempos de espera cuando falla la ejecución de SOP.
Ventanas de servicio: requisitos de ranura/comm para SOP de alto riesgo.

7) Métricas de eficacia SOP

Tiempo de ejecución (mediana/p95) - Cuánto tarda el procedimiento.
Tasa de éxito: proporción de ejecuciones exitosas sin escalar/revertir.
Evidence Completeness - llenado de artefactos.
SLO Impact - Si hay degradación durante/después del paso (burn-minute).
Defect Density - Comentarios al rugir/enseñar en 10 SOP.
Freshness - fracción de SOP con rugido ≤90 días.
Adoption - cuántas alertas/ventanas están realmente enlazadas a SOP.

8) Lista de verificación del autor SOP

• El objetivo y los límites de aplicación están definidos.
• Roles, accesos y ventanas - descritos.
• Gates de calidad y SLO son medibles, hay fuentes de señal.
• Pasos ejecutables: comandos/scripts, resultados esperados, verificación.
• Backout/rollback y criterios de lanzamiento - claramente.
• Se han aplicado plantillas comm.
• La lista de eventos está estructurada.
• Se especifica la versión/fecha/propietario/rugido.

9) Lista de verificación del artista SOP

• Se confirmaron las precondiciones y accesos de JIT/JEA.
• Ticket/war-room abierto y anotaciones habilitadas.
• Observabilidad: los dashboards/alertas necesarios están abiertos.
• Estoy siguiendo los pasos en orden; después de cada uno - verificación.
• Cuando se violan los gardrailes, se produce un retroceso inmediato y una escalada.
• Evidence está lleno; comprobación final de SLO/SLI empresarial.
• El ticket está cerrado, la página de estado/las comunicaciones están actualizadas.

10) Ejemplos SOP (fragmentos)

10. 1 SOP: Retroceso canario del lanzamiento (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: Actualización planificada del DB (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: Conmutación del proveedor 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: Comprobación de recuperación de backup (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) Automatización alrededor de SOP

Patrón SOP: Generación de esqueleto con bloque RACI/gates/comm.
Bot performer: pasos con cajas de cheques, temporizadores, recordatorios de cadencia, seguimiento automático.
Integración con CMDB/directorio: el servicio tiene una lista de SOP relevantes.
Anotaciones de telemetría: "SOP-RUN: <ID> step N' → análisis rápido.
Directivas de tolerancia: El deploy/ventana sólo comienza con las getas verdes SOP.

12) Anti-patrones

SOP sin propietario/fecha de rugido - documento «muerto».
Instrucciones infladas sin criterios de éxito y backout.
Comandos/claves inconsistentes: riesgo de errores y fugas.
Las diferentes versiones en el wiki y en el repositorio son una divergencia de fuentes de verdad.
Sin evidence - nada para confirmar la calidad/cumplimiento.
«Un SOP para todos los casos» - se pierde la ejecutabilidad.

13) Hoja de ruta para la implementación (4-6 semanas)

1. Ned. 1: aprobar la plantilla SOP, el linter y el directorio; seleccionar los 10 escenarios principales.
2. Ned. 2: escribir SOP para relizov/otkata/provaydera/bekapov; pilotos de tabletop.
3. Ned. 3: conectar el ChatOps-bot y las anotaciones de telemetría; asociar alertas con SOP.
4. Ned. 4: horario trimestral de rugido; introduzca las métricas Freshness/Success Rate.
5. Ned. 5-6: cubrir el 90% de las operaciones críticas; DR/Security-SOP; automatizar la recolección de evidence.

14) Resultado

El SOP hace que las operaciones sean predecibles y verificables: gates de calidad única, pasos detallados, roles explícitos y reversibilidad. En combinación con playbooks, políticas, SLO y automatización, convierte la operación en una línea de producción confiable: reacciones rápidas, riesgo mínimo y responsabilidad comprensible.