Observabilidad, fiabilidad y validación

Se centra en las evidencias de auditoría, los objetivos de servicio, los datos de capacidad y los controles de validación, y define cómo demostrar la fiabilidad del sistema antes de pasar a producción.

12. Observabilidad y auditoría

12.1 Centro de observabilidad y auditoría

El centro de observabilidad y auditoría solo recibe eventos con un origen explícito: eventos de ejecución y decisión del plano de datos, cambios ordinarios del plano de control y auditoría dentro de la transacción, y copias de auditoría local break-glass. Es responsable de eliminación de datos sensibles, correlación y salida de evidencia; no inicia otra cadena de escritura de auditoría del plano de control.

La cobertura de auditoría se basa en transacciones de escritura de configuración; las alertas y consultas de cumplimiento se basan en el resultado correlacionado del centro de observabilidad. Ambos comparten request_id, versión de configuración e identificador de recurso, pero sus responsabilidades no se duplican.

12.2 Métricas principales

• Volumen de solicitudes: por región, plataforma, ruta, comerciante y resultado.
• Latencia: latencia total de gateway, latencia de autorización y latencia de backend, cada una con P50, P95 y P99.
• Tasa de error: por 401, 403, 404, 429, 502, 503, 504 y reason code interno.
• Autorización: Key desconocida, fallo de resumen, IP no coincidente, Scope insuficiente, Key vencida y Key revocada.
• Configuración: versión más reciente del plano de control, versión aplicada en cada región, retraso de propagación, acumulación de consumo y diferencias de conciliación.
• Enrutamiento: número de instancias saludables del backend, estado de disyuntor, número de reintentos y número de conmutaciones por fallo.
• Seguridad: características de enumeración de Key, cambios anómalos de IP, aumento brusco de la tasa de denegación y operaciones administrativas de alto riesgo.

12.3 Campos de registro y trazado

Los registros estructurados del plano de datos incluyen al menos: timestamp, request_id, trace_id, region, environment, route_name, platform, merchant_id, Key ID oculto, IP de origen normalizada, resultado de autorización, reason code interno, epoch de configuración, sequence de configuración, estado HTTP, duración de solicitud, duración de backend y dominio de fallo.

Los registros de auditoría administrativa incluyen al menos: identidad del actor, identidad del aprobador, recurso, operación, motivo, resumen antes y después del cambio, identificador de solicitud, sistema de origen y tiempo.

12.4 Alertas

Los siguientes eventos deben activar alertas en tiempo real:

1. La tasa de denegación de autorización de cualquier región aumenta de forma significativa frente a la línea base de los últimos 30 minutos.
2. La versión de configuración regional queda más de 30 segundos por detrás del plano de control.
3. La propagación de un cambio de seguridad supera 10 segundos.
4. Cualquier plataforma no tiene backend saludable o activa conmutación por fallo interregional.
5. La latencia P99 del gateway o la proporción de 5xx supera el SLO.
6. Una sola Key falla consecutivamente la autenticación desde varias IP no vinculadas.
7. Una operación administrativa de alto riesgo no completa aprobación de dos personas o falla la escritura de auditoría.

13. SLO recomendados y principios de capacidad

Los siguientes indicadores son recomendaciones de diseño y no compromisos confirmados en la reunión:

El denominador del SLI de disponibilidad del gateway son las solicitudes que superan la validación básica de protocolo y llegan a la entrada regional; los 4xx provocados por el cliente y los 5xx ya marcados como dominio de fallo de backend no se cuentan como fallos de gateway, pero se debe establecer un SLI de disponibilidad de extremo a extremo independiente. Un 503 producido por el fallo cerrado del servicio de validación de API Key es un fallo del gateway y consume presupuesto de error.

En 30 días, 99.99% permite solo unos 4.32 minutos de indisponibilidad. La entrada perimetral, el gateway y el servicio de validación de API Key pueden usar como máximo un tercio del presupuesto de error cada uno, por lo que la disponibilidad mensual de cada componente no puede ser inferior a 99.997%. Redis no debe convertirse en una dependencia fuertemente síncrona de cada solicitud; la instantánea de configuración en proceso se usa para aislar su fallo. Este presupuesto debe recalcularse con el grafo real de dependencias tras la selección tecnológica; no se puede declarar cumplimiento multiplicando simplemente los SLO de componentes.

Una región saludable se define como una región que informó continuamente en los últimos 30 segundos el estado de salud del plano de datos, la versión de configuración y el estado de sincronización de reloj. El SLI de propagación solo excluye regiones retiradas formalmente por el punto de ejecución de entrada del centro de política de enrutamiento de tráfico; no se puede marcar temporalmente una región como no saludable por retraso de propagación para evadir la medición.

Los materiales de reunión no proporcionan QPS máximo, cuerpo medio de solicitud, cuerpo de respuesta, duración de conexión, número de comerciantes, número de API Key ni lista de regiones; por ello no es posible dar un dimensionamiento de instancias y hardware creíble en este momento.

Antes del dimensionamiento se deben recopilar, para cada plataforma, los últimos 30 días de QPS máximo, cuerpos de solicitud P95 y P99, duración de backend P95 y P99, tasa de reutilización de conexiones, número de comerciantes, número de Key por comerciante y número de vinculaciones IP. Las pruebas de carga deben validar el SLO al 70% de la capacidad objetivo y conservar al menos 30% de margen de ráfaga regional y capacidad residual después del fallo de una zona de disponibilidad.

14. Verificación y aceptación

14.1 Pruebas de matriz de autorización

Se deben cubrir las siguientes pruebas automatizadas:

1. Una Key válida, IP vinculada, entorno correcto y posesión del required scope permite el acceso.
2. Una Key válida combinada con otra IP no vinculada del mismo comerciante devuelve 401.
3. Otra Key del mismo comerciante sin vinculación a la IP actual devuelve 401.
4. Cuando Key e IP están vinculadas pero falta el required scope, devuelve 404 y la respuesta es idéntica a una ruta realmente inexistente.
5. Una Key desconocida, Secret incorrecto o formato de credencial incorrecto devuelve uniformemente 401.
6. Una Key en estado pending, suspended, revoked o expired se rechaza.
7. Durante la ventana de rotación se pueden usar Secret nuevo y anterior; al finalizar la ventana solo puede usarse el nuevo Secret.
8. La falsificación por el cliente de X-Forwarded-For no puede cambiar la IP de origen usada para autorización.
9. Una ruta que no declara required scope no puede publicarse.
10. Una Key de producción no puede acceder a un entorno que no es de producción y una Key que no es de producción no puede acceder a producción.
11. Una solicitud no autenticada devuelve el mismo 401 para una ruta existente y para una inexistente, sin permitir enumerar rutas.
12. Después de actualizar Pepper, un Secret que referencia una versión Pepper anterior y aún está dentro de vigencia sigue siendo verificable, y un Secret nuevo utiliza la versión Pepper nueva.
13. Se rechaza una vinculación IPv4 menor que /29 o IPv6 menor que /64, y no se pueden escribir redes solapadas.
14. Se rechaza una solicitud de escritura de pagos si la marca de tiempo de firma está fuera de 5 minutos, el Nonce se repite en 10 minutos, el resumen del cuerpo no coincide o la firma es incorrecta.

14.2 Pruebas multirregionales y de fallo

1. Detener una instancia de gateway; la solicitud cambia sin interrupción perceptible y no hay omisión de autorización.
2. Detener una zona de disponibilidad; la capacidad regional restante aún satisface el SLO.
3. Detener Redis de una región; las solicitudes conocidas se procesan según la estrategia de instantánea acotada y las Key desconocidas se rechazan.
4. Detener el bus de mensajes; la configuración se marca como pendiente de publicación y, después de recuperarlo, los eventos no se pierden y convergen en orden de versión.
5. Revocar una Key y comprobar que todas las regiones saludables la rechazan dentro del objetivo de 10 segundos.
6. Simular que una región completa no está disponible y realizar conmutación por fallo solo para lecturas o escrituras idempotentes que satisfacen la política.
7. Simular que la base de datos de negocio de la región de reserva está retrasada y confirmar que el gateway no realiza escritura interregional ciega.
8. Recuperar la región original, ejecutar una reversión controlada y validar la versión de configuración y el estado de datos del backend.
9. Antes de promover el plano de control de reserva, validar que la escritura del primario anterior fue vallada; el nuevo plano de control usa un epoch mayor y todas las regiones rechazan eventos del epoch anterior.
10. Cuando el plano de control y PostgreSQL no están disponibles a la vez, bloquear una Key de prueba mediante break-glass en todas las regiones saludables y, tras recuperar, archivarla como registro formal de revocación.
11. Después de un fallo de Redis, validar que la suma de cuotas del cubo de tokens local no supera la cuota global y que la recuperación no amplifica de forma súbita el tráfico.
12. Cuando la última instantánea de autorización supera 15 minutos, se rechazan solicitudes de escritura de alto riesgo y las solicitudes de lectura siguen la política de riesgo aprobada.
13. Cuando la señal de estado de réplica de la región de reserva vence o el retraso supera el umbral de ruta, las solicitudes de lectura no pueden conmutar automáticamente por fallo.
14. Se rechaza que una versión de configuración anterior sobrescriba otra nueva, las semánticas de 429 y 409 de backend se mantienen estables, y no existe un estado en que sea visible un conjunto parcial durante el reemplazo atómico de vinculaciones IP.

14.3 Puerta de publicación

La primera versión de producción debe cumplir simultáneamente:

1. La tasa de aprobación de pruebas automatizadas de matriz de autorización es 100%.
2. La propagación de cambios de seguridad, la latencia de gateway y la disponibilidad alcanzan los objetivos de la sección 13.
3. El escaneo de registros de gateway, WAF, APM y auditoría no encuentra Secret en texto claro.
4. Se completan un ejercicio de fallo de una zona de disponibilidad, un ejercicio real de asunción del plano de control, un ejercicio real de bloqueo break-glass y un ejercicio de mesa del plano de datos a nivel regional.
5. Los responsables de cada plataforma inicial firman ruta, required scope, idempotencia y política de conmutación por fallo.
6. El equipo de seguridad completa el modelo de amenazas y cierra los hallazgos de alto riesgo de pruebas de penetración.
7. El equipo de operaciones confirma que paneles, alertas, manual de guardia y proceso de reversión están disponibles.