SOP:

Estandarización de procedimientos operativos

1) Por qué es necesario

SOP es el «sistema operativo» de la compañía. La estandarización elimina el caos y los «estilos individuales», reduce el MTTR, el ruido de alertas y los riesgos de incidentes, acelera el onboarding y hace que los resultados sean reproducibles.

• Reducir la variabilidad de las acciones en incidentes y rutinas.
• Acelerar el aprendizaje y mejorar la calidad de los hendovers.
• Hacer verificables los procesos: auditoría, métricas, mejoras en los datos.
• Garantizar el cumplimiento de los requisitos regulatorios e internos.

2) Principios de normalización

1. Formato y terminología uniformes. Una notación, una definición (SLO, ETA, Owner).
2. Actionable, no enciclopedia. Sólo pasos verificables, criterios de éxito y reversión.
3. Ramificación mínima. Decisiones claras «si/entonces» en lugar de una declaración libre.
4. Versificación y posesión. Cada SOP tiene un propietario, versión y fecha de revisión.
5. Integración con herramientas. Referencias a dashboards, tickets, fichflags, comandos CLI.
6. Disponibilidad en on-call. Buscar rápidamente, leer, ejecutar un enlace.
7. Mejora continua. Los postmortemas → tareas para actualizar SOP.

3) Marco SOP (plantilla)

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 en release-tool (enlace)
• 2) Comprobar los paneles «Cambiar seguridad» y «API p99»
• 3) Crear ticket REG- , especificar baseline/ventana
• DoD: p99 ≤ 1. 1 × baseline 15m, errores
• Rollback: desactivación total de la bandera, post mortem ≤72ch

SOP: PSP Provider Feilover

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

• 1) Habilitar el routing PSP-Y (configuración/botón)
• 2) Comprobar la conversión de depósitos y p95 PSP-Y
• 3) Anotaciones en gráficos, apdate en # incident-channel
• DoD: success_rate ≥ 99. 5%, p95 ≤ 300ms 10m
• Rollback: retorno parcial del tráfico del 20% cuando se estabiliza el PSP-X

12) Hojas de cheques

Lista de comprobación de preparación SOP:
[] El objetivo y los desencadenantes son claros y medibles.
[] Hay acciones paso a paso con comandos/enlaces.
[] DoD/Rollback se formulan.
[] Las escaladas y los contactos son relevantes.
[] Los metadatos están llenos (owner, version, last_review).
[] El comprobador de link y el validador de CI pasan.

Lista de verificación de aplicación SOP (en caso de incidente):
[] El SOP está abierto desde el Administrador de incidencias/referencia en el panel.
[] Se completaron los pasos y se confirmaron los resultados.
[] DoD alcanzado/no - marcado.
[] Las acciones/inconsistencias se registran en el ticket.
[] Las actualizaciones/mejoras de SOP son creadas por tareas (si es necesario).

13) Formación y onboarding

Mini cursos de SOP clave (Pagos/Apuestas/Juegos/KYC).
Shadow-service con la aplicación obligatoria de SOP en los entrenamientos.
«Clínicas SOP» semanales: 30 minutos de desmontes/mejoras.
Simulaciones (game-days): práctica de DR- e incidentes SOP.

14) Gestión de cambios SOP

RFC vía PR, etiquetas 'menor/mayor/breaking'.
Cambios de breaking - con formación obligatoria y anuncio.
Notificaciones automáticas a los propietarios de dominios y al coll.
Notas independientes de «SOP-Release Notes» al final de cada semana.

15) Anti-patrones

Forma libre «cómo va a funcionar» y diferentes plantillas por equipos.
SOP sin propietario/versión/fecha de revisión.
Textos «enciclopédicos» en lugar de acciones paso a paso.
No hay Rollback/DoD - nada para probar el éxito.
Enlaces rotos, comandos «manualmente fuera del chat», pasos privados «secretos».
Cambios invisibles de SOP sin escritura ni entrenamiento.

16) 30/60/90 - Plan de implementación

30 días:
Aprobar la plantilla SOP y los estándares mínimos.
Crear un repositorio de 'ops-sop/' (docs-as-code), habilitar CI-linters.
Digitalizar 10-15 SOPs críticos (incidentes/lanzamientos/proveedores).
Conectar el Gestor de incidencias y los paneles de observación a los enlaces SOP.

60 días:
Alcanzar Coverage ≥ 70% en escenarios críticos.
Poner en marcha las «clínicas SOP» semanales y las sesiones de formación on-call.
Agregar búsqueda AI (RAG) por SOP y TL; Tarjetas DR.
Introduzca Review SLA (180 días) y los informes de SOP caducados.

90 días:
Cobertura ≥ 90%, Tasa de uso ≥ 70% de los incidentes.
Incrustar DoD/Rollback en todos los SOP, cerrar enlaces rotos (0).
Vincular los KPI SOP a los comandos OKR (MTTR, Change Failure Rate).
Llevar a cabo un retro y registrar las mejoras del próximo trimestre.

17) FAQ

P: ¿En qué se diferencia el SOP del runbook?
R: SOP es un procedimiento estandarizado (reglamento «como correcto»). Runbook - instrucciones detalladas para un caso/servicio específico. A menudo, SOP hace referencia a uno o más runbooks.

P: ¿Cuántas piezas debe haber en SOP?
R: Exactamente tanto como para que el operador pueda realizar acciones sin «llegar al fondo» en el chat. Todo lo que no afecta a la acción está en los materiales de ayuda individuales.

P: ¿Cómo mantener la relevancia?
R: Revisiones SLA (≤180 días), recordatorios automáticos, linternas CI y métricas Usage/DoD. Cualquier incidente de desviación → una tarea para actualizar el SOP.