Planteamiento y contexto
Descubre que un runbook de incidentes de uso frecuente contiene pasos para un servicio eliminado y podría empeorar una interrupción del servicio. Explique cómo proteger al equipo de guardia sin interrumpir la cobertura actual, validar un reemplazo, retirar o reescribir el runbook y demostrar que se adoptó la mejora.
Qué evalúa el entrevistador
- Reducir el riesgo de acciones inseguras antes de debatir a quién le pertenece la documentación.
- Convertir "el documento está desactualizado" en un plan de migración reproducible y verificable.
- Usar STAR para explicar el impacto, la colaboración, las compensaciones (trade-offs) y las métricas de seguimiento.
Preguntas para aclarar primero
- ¿Qué pasos son inválidos y podrían eliminar datos, ampliar el tráfico o bloquear la recuperación?
- ¿Dónde abren realmente el runbook los ingenieros de guardia, incluidos enlaces en caché y bots?
- ¿Quién es el propietario del reemplazo, qué sandbox existe y cómo funcionaría un rollback de emergencia?
Una respuesta de 30 segundos
Marcaría el riesgo en la parte superior del runbook, notificaría al personal de guardia y al responsable del incidente, y proporcionaría una ruta temporal verificada para que nadie repita el paso inválido. Probaría el reemplazo en un sandbox, actualizaría enlaces, permisos y guías de rollback con el propietario del servicio, y luego publicaría y marcaría como obsoleta (deprecate) la versión anterior. La adopción se mediría a través del acceso a enlaces, el éxito en simulacros, las acciones erróneas y las tareas de seguimiento completadas, no solo por un cambio de documentación fusionado (merged).
Análisis detallado paso a paso
1. Aislar los pasos peligrosos
Identifique comandos o decisiones con impacto irreversible. Agregue una advertencia visible, deshabilite enlaces automatizados o mueva la versión antigua a un archivo explícito mientras preserva una ruta temporal aprobada por el responsable de guardia.
2. Reconstruir la ruta de acceso real
Inspeccione índices de guardia, resultados de búsqueda, mensajes de bots, permisos y marcadores en caché para encontrar la versión que los ingenieros realmente utilizan. Editar únicamente el repositorio de origen deja enlaces copiados en circulación.
3. Validar el reemplazo
Ejecute los nuevos pasos en un sandbox o en una ventana de bajo riesgo y registre los requisitos previos, señales, condiciones de parada y rollback. GitLab describe los runbooks como herramientas para la identificación inicial y el manejo rutinario, con playbooks o rutas de escalamiento para casos más complejos; el límite del documento debe coincidir con la responsabilidad real.
4. Reescribir con los equipos propietarios
Pida al propietario del servicio, a un representante de guardia y a revisores de seguridad o cumplimiento que verifiquen el cambio. Separe hechos, suposiciones y verificaciones pendientes en lugar de reescribir comandos críticos de memoria. Cada paso establece el alcance y el punto de entrada de escalamiento cuando falla.
5. Planificar la publicación y el retiro
Publique la nueva versión como candidata y asigne a la antigua una fecha de obsolescencia y un enlace de reemplazo. Si la ruta anterior puede causar daños graves, elimine el permiso de ejecución o configúrela como de solo lectura antes de seguir el proceso de cambios. Mantenga el rollback alineado con los permisos de despliegue y la versión utilizable más reciente.
6. Probar la adopción con un simulacro
Haga que alguien que no haya redactado el runbook complete un simulacro. Observe si encuentra el punto de entrada, reconoce los requisitos previos y escala ante la condición de parada. Registre el tiempo, los pasos incorrectos y las preguntas en lugar de sustituir el uso real por la autoevaluación del autor.
7. Agregar activadores de mantenimiento
Establezca un propietario, una fecha de revisión y activadores como cambios de topología, nombre de alertas o permisos. La documentación desactualizada puede indicar que la revisión de cambios carece de una verificación de documentación; agréguela a las listas de verificación de lanzamientos y a las acciones de revisión de incidentes.
Respuesta modelo
Confirmaría el riesgo del paso inválido, agregaría una advertencia, notificaría al personal de guardia y al responsable del incidente, y proporcionaría una ruta temporal confirmada. Inspeccionaría los enlaces que la gente realmente usa, probaría el reemplazo en un sandbox con requisitos previos, condiciones de parada y rollback, y lo revisaría con el propietario del servicio y el representante de guardia. Luego publicaría la nueva versión, marcaría como obsoleta la anterior y realizaría un simulacro con alguien que no la haya redactado. Las métricas de aceptación incluirían encontrar la entrada, las acciones erróneas, los tiempos de escalamiento y la finalización de la migración, con activadores de mantenimiento en el proceso de cambios.
Errores comunes
- Eliminar el runbook antiguo sin una ruta de reemplazo segura.
- Editar el repositorio ignorando enlaces en caché, bots y marcadores.
- Declarar el éxito después de que solo el autor complete un simulacro.
- Colocar todos los procedimientos de fallo en un runbook sin delimitar playbooks o escalamientos.
- Contar fusiones (merges) de documentación en lugar de acciones erróneas y resultados de simulacros.
Preguntas de seguimiento y respuestas
¿Qué pasa si ya hay un incidente activo?
Haga que el líder del incidente confirme la ruta temporal y el riesgo, detenga la propagación del paso inválido y agregue la corrección de la documentación a la lista de acciones del incidente. No realice una reescritura grande no probada durante el combate del incidente en tiempo real.
¿Qué pasa si el propietario del servicio niega que el runbook esté desactualizado?
Presente el paso exacto, el cambio reciente y evidencia reproducible del fallo, y luego proponga un pequeño simulacro. Enfoque la discusión en el riesgo para el usuario y la propiedad del mantenimiento, no en la persona.
¿Qué pasa si muchos equipos externos usan el runbook antiguo?
Mantenga una redirección estable o una nota de compatibilidad, notifique a los consumidores y establezca una fecha límite de migración. Restrinja primero los permisos de comandos de alto riesgo y luego confirme la migración equipo por equipo.
¿Cuándo se debe eliminar la versión antigua por completo?
Solo después de que el reemplazo haya superado un simulacro, tenga un propietario asignado, todos los puntos de entrada críticos se hayan migrado y el rollback esté disponible. Siga reglas de retención más estrictas cuando la seguridad o el cumplimiento lo requieran.
¿Qué pasa si el reemplazo falla en el simulacro?
Detenga la publicación, registre los requisitos previos y señales que fallaron, corrija el procedimiento y vuelva a ejecutar el simulacro. El fallo es evidencia de que no se cumple el criterio de pase a producción, no una razón para justificarlo con excusas.
¿Cómo contaría esta historia con STAR?
Describa el riesgo y la tarea concretos, luego las notificaciones, validación, colaboración y pasos de publicación. Finalice con la reducción de acciones erróneas, la tasa de aprobación en simulacros o la finalización de la migración, más el mecanismo de mantenimiento que agregó.