Defina la preparación en torno a un resultado del cliente
Comience con resultados, no con etiquetas de infraestructura. Una página de inicio accesible no es suficiente si un visitante no puede completar la tarea que importa. Para cada recorrido crítico, indique quién intenta hacer qué, qué significa el éxito y qué resultado es inaceptable. Empiece con unos pocos recorridos para que el equipo pueda tomar decisiones reales.
Clasifique cada paso como esencial, importante o aplazable. Esencial significa que el recorrido no puede concluir sin él; importante puede permitir una solución temporal por tiempo limitado; aplazable puede omitirse, retrasarse o simplificarse. Esta es una decisión de producto informada por ingeniería, no una clasificación técnica universal.
Registre un resultado utilizable, por ejemplo: un pedido es aceptado y se guarda la confirmación, en lugar de solo un objetivo de respuesta de página.
Mapee dependencias y decida qué puede degradarse
Para cada recorrido crítico, mapee el alojamiento o entrega, DNS, servicios de aplicación, bases de datos, autenticación, correo electrónico, pagos, búsqueda, etiquetas, herramientas de consentimiento y APIs externas. Registre el responsable, la vía de soporte, el límite relevante y el efecto en el usuario si cada elemento no está disponible. OWASP recomienda visibilidad en las dependencias de software; la misma disciplina de propiedad ayuda con las dependencias operacionales.
Una dependencia dura detiene la tarea cuando falla. Una dependencia blanda puede estar ausente o desactualizada mientras la función central sigue funcionando. AWS describe la degradación controlada (graceful degradation) como mantener la función central disponible cuando las dependencias están poco saludables. Defina una elección específica de producto: ocultar un widget no esencial, diferir un informe o presentar una alternativa honesta. No invente inventario, precios, estados de pedido o resultados de pago.
Capture propósito, responsable, límite conocido, fallback, contacto para cambios y fecha de la última prueba para cada elemento.
Convierta un pronóstico de tráfico en un experimento de capacidad
Use un escenario, no un solo número de tráfico. Indique el evento, el patrón de llegada, la mezcla de solicitudes, la proporción de usuarios autenticados, la geografía, la actividad concurrente de checkout o escrituras y el periodo pico. Incluya un caso alto y las suposiciones. Google señala que las solicitudes pueden tener costos de recursos muy diferentes, por lo que las solicitudes por segundo pueden ser un modelo de capacidad pobre por sí solo.
Pruebe tráfico sostenido, representativo y de extremo a extremo contra una configuración cercana a producción, con aprobación y salvaguardas. AWS advierte contra probar solo componentes, usar un subconjunto de solicitudes no representativo o detenerse en un pequeño margen por encima de la carga esperada. Documente la primera restricción o desaceleración. Las pruebas en producción en vivo pueden afectar a los clientes; use un entorno controlado a menos que corresponda un ejercicio planificado y con personal.
Conserve el escenario, la configuración, la mezcla de solicitudes, la duración, la restricción observada, el cambio de capacidad y el responsable de seguimiento.
Prepare opciones de cambio, retroceso y recuperación
Antes de un cambio de alto riesgo, identifique el artefacto o la configuración a restaurar, la aprobación necesaria, la persona autorizada y el método de validación. Mantenga un runbook corto para pausar un lanzamiento, revertir un despliegue, desactivar una feature flag, reducir una integración no crítica o restaurar datos usando un procedimiento aprobado. Pruebe la mecánica antes del evento; una copia de seguridad o plan de rollback no ejercitado es una asunción.
Establezca objetivos de recuperación a partir del impacto comercial. Recovery Time Objective, o RTO, es el retraso máximo aceptable antes de que el servicio se restaure. Recovery Point Objective, o RPO, es la pérdida máxima de datos aceptable medida desde el último punto de recuperación. AWS advierte contra objetivos arbitrarios o poco realistas y señala que los objetivos de dependencias afectan lo que es alcanzable. Trate los objetivos como metas de planificación, no como promesas al cliente.
Verifique un rollback o restauración limitada y segura y registre qué se comprobó, por quién y cualquier brecha encontrada.
Asigne propiedad antes de que las decisiones sean urgentes
Una lista de contactos por sí sola no es propiedad. Para cada recorrido crítico, asigne un propietario de negocio para el resultado aceptable, un propietario técnico para la implementación y un responsable de decisiones autorizado para realizar un cambio protector. Nombre suplentes y aclare cuándo un proveedor, agencia, procesador de pagos o equipo interno posee la siguiente acción.
Haga una breve revisión de preparación antes de que llegue el tráfico. Repase una falla de dependencia: qué queda disponible, qué palanca es segura, quién la aprueba y cómo se verifica el éxito. Esto es un ensayo proactivo, no un informe de estado en vivo. Registre acciones fechadas, propietarios y fechas de vencimiento.
Preautorice acciones estrechas y seguras cuando proceda para que la protección no espere una cadena de aprobaciones poco clara.
Trate las rutas sensibles a pagos y seguridad con especial cuidado
La preparación del checkout debe preservar la corrección además de la disponibilidad. No omita autorizaciones, debilite controles de acceso, exponga credenciales ni altere a la ligera los scripts de la página de pago. La PCI SSC ofrece orientación sobre autorización, integridad y detección de manipulación para scripts de páginas de pago y cabeceras HTTP con impacto en seguridad. Si el sitio acepta tarjetas o usa un frame de pago embebido, haga que el comerciante, el procesador, el adquirente y asesores cualificados en seguridad o cumplimiento revisen los cambios materiales.
Mantenga un inventario de scripts de producción, integraciones, versiones y propiedad de cuentas, y restrinja quién puede cambiarlos. OWASP señala que los inventarios de dependencias y el fijado de versiones pueden reducir la incertidumbre sobre lo que entra en una compilación, mientras que hallazgos automatizados aún requieren verificación manual. Estas prácticas apoyan la preparación pero no establecen el cumplimiento PCI ni sustituyen una evaluación de seguridad.
Use solo un flujo alternativo aprobado y revisado por el procesador; nunca recopile datos de tarjeta por canales informales.