Una lista para preparar la redacción ante el próximo pico de tráfico

La preparación de un sitio de noticias ante picos de tráfico debe probarse entre redacción e ingeniería. No basta con que los lectores abran un artículo. Los editores deben poder publicar, corregir errores y saber quién puede desactivar una función averiada sin perder la información periodística.

Este simulacro parte de una infraestructura existente. Comprueba si la redacción puede operarla bajo presión, en vez de proponer otra arquitectura de alojamiento.

Ensaye el recorrido completo de publicación

Elija una nota representativa con imagen, cobertura relacionada y algún elemento insertado habitual. Publíquela en un entorno autorizado mientras ingeniería ejecuta una simulación de tráfico acordada. No incluya pruebas de carga en producción salvo que operaciones haya aprobado límites y condiciones para detenerlas.

Pida a un editor actualizar el titular y corregir un párrafo. Verifique los cambios como lector anónimo, no solo en una vista previa autenticada. Revise portada, sección, artículo y los canales de distribución incluidos en el proceso editorial. Guardar correctamente en el CMS no demuestra que el público recibió la corrección.

La guía de caché HTTP de MDN distingue cachés privados y compartidos. Aquí importa esa diferencia: una vista previa correcta no demuestra que la respuesta pública compartida esté al día. Mida la propagación observada en vez de suponer que todas las capas se actualizaron.

Asigne nombres a las responsabilidades

Designe responsables editorial, técnico y de comunicación para el incidente. En una redacción pequeña, una persona puede cubrir varias funciones, pero las responsabilidades necesitan nombres y suplentes.

Prepare una lista que pueda utilizarse durante la presión:

• Confirmar URLs y tareas afectadas.
• Registrar si se puede guardar y publicar.
• Revisar la corrección más reciente como lector anónimo.
• Identificar la función averiada y su responsable.
• Acordar hora y canal de la siguiente actualización.
• Registrar quién activa y revierte la alternativa temporal.

La guía de procedimientos operativos de AWS recomienda que otra persona pruebe las instrucciones documentadas. Pida al editor suplente seguir la lista sin que su autor tenga que explicar cada paso.

Ejemplo hipotético de una falla en cobertura en vivo

Supongamos que la redacción cubre una interrupción del transporte. Es un ejercicio hipotético. El artículo principal abre, pero un módulo externo de actualizaciones se atasca e impide llegar de forma confiable al contenido inferior. El CMS sigue disponible.

La persona responsable editorial autoriza sustituir el módulo por actualizaciones con hora dentro de la nota. El responsable técnico utiliza un control preparado y verifica tanto el artículo como su versión pública en caché. Comunicación indica dónde deben agregar información los editores mientras el módulo permanece desactivado.

La alternativa solo funciona si la página sigue siendo comprensible y las correcciones se ven. Ocultar el módulo junto con información esencial no constituye una recuperación aceptable.

Decida de antemano qué puede degradarse

Clasifique módulos opcionales, recomendaciones, buscadores e integraciones analíticas según puedan desactivarse temporalmente. Preserve la información esencial, correcciones y controles necesarios de seguridad o acceso. No improvise vaciados generales de caché ni retire protecciones sin comprender su efecto.

Al terminar, registre las demoras de decisión además de las fallas técnicas. No saber quién aprueba una medida puede consumir más tiempo que ejecutarla. Repita la parte fallida tras corregirla, con los mismos criterios de aceptación.

Programe una prueba de propagación de correcciones con quien atendería la próxima noticia importante. Si el obstáculo es la responsabilidad operativa o la implementación de alternativas, lleve la evidencia a una revisión de soporte y mantenimiento con 5e Labs.