Completar un plan de respuesta a incidentes para un equipo pequeño

Un plan de respuesta a incidentes debe ayudar a su equipo a gestionar de forma ordenada el trabajo interrumpido. Elija un flujo importante de su software y describa cómo se reconoce su fallo, quién decide y qué comprobación se necesita para reanudar la actividad.

Identificar el flujo afectado

En este ejemplo ficticio, el incidente I-72 afecta a un portal de clientes. La página de inicio responde, pero las nuevas solicitudes no pueden guardarse por completo con un archivo adjunto. La solicitud A-72 y el archivo F-72 son solo ejemplos de prueba. No se trata de una caída operativa observada aquí.

En este caso, la mera disponibilidad de la página de inicio no es el criterio de cierre. El plan identifica el flujo completo de la solicitud, incluidos almacenamiento del archivo, comprobación de roles y trabajo posterior. También registra qué cambios se permiten durante la respuesta.

Completar una ficha de respuesta con los roles

Google SRE describe roles claros, un registro de trabajo actualizado y traspasos confirmados. En equipos pequeños, una persona puede asumir varios roles. Aun así, debe quedar claro quién coordina, quién modifica el sistema y quién comunica la información.

La tabla describe pasos previstos, no una recuperación ejecutada. Defina un suplente y un contacto de escalado localizable. El documento de trabajo debe estar disponible incluso si el portal falla.

Planificar la comunicación como tarea propia

Designe quién informa a las personas afectadas y a los servicios implicados. Una actualización de estado indica el impacto conocido, el progreso de la respuesta y el próximo punto de información acordado. Una causa supuesta se identifica como hipótesis; una estimación de recuperación sin fundamento no se transmite como promesa.

Si cambia la persona responsable durante el incidente, se traspasa el estado actual y se confirma la aceptación. El traspaso incluye las medidas fallidas y las comprobaciones pendientes. Un mensaje enviado, por sí solo, no garantiza que la nueva coordinación haya asumido la tarea.

Distinguir la reanudación del trabajo posterior

Antes de reanudar, el equipo comprueba el flujo afectado en un entorno adecuado con los casos de prueba acordados. La posibilidad de volver a un estado anterior también depende de los datos modificados entretanto; un reinicio por sí solo no demuestra la recuperación.

Registre quién autoriza la reanudación y qué tareas pendientes siguen bajo observación. El posterior análisis de causas puede mejorar el plan, sin equipararse a la primera estabilización. Practique con la ficha en un escenario aprobado y corrija contactos, accesos o pasos de comprobación que falten.

Fuentes

• Google SRE: Managing Incidents