Un runbook ayuda a pasar de un síntoma específico a una decisión segura.
Un runbook ayuda a pasar de un síntoma específico a una decisión segura. No es una lista de todos los comandos disponibles. Escriba para alguien con las capacidades esperadas que puede estar cansado o conocer poco el componente.
Empezar por señal e impacto
Indique alerta, recorrido afectado y condiciones de aplicación. Enlace el panel y explique qué observación distingue causas similares. Añada responsable, fecha de revisión y escalado. El documento debe seguir accesible si la aplicación principal falla; su ubicación forma parte del diseño operativo.
Definir requisitos y límites
Explique permisos, selección del entorno y aprobaciones para acciones importantes. Establezca cuándo datos inexplicables, copia ausente o resultados contradictorios obligan a detener y escalar. No inserte secretos. Cada paso debe incluir propósito, resultado esperado y siguiente decisión, además de efecto sobre trabajo en curso.
Incluir comprobación y mantenimiento
Para reinicio, repetición o conmutación, explique duplicados y reversión. Verifique recorrido cliente y trabajo pendiente, registrando acciones y consecuencias. Otra persona debe probar la guía de forma segura. Actualícela tras cambios e incidentes relevantes. Una instrucción breve comprobada es más fiable que un documento largo abandonado.
Un ejemplo y su aceptación
Ante una cola creciente, distinga falta de workers, proveedor lento y tarea aislada que falla repetidamente. Un reinicio general puede ocultar la causa o producir más repeticiones. Indique qué observación confirma cada rama y cuál es la siguiente acción limitada. Otra persona debe elegir el camino correcto y verificar cola y resultado comercial. Registre salidas no comprendidas y permisos ausentes como mejoras del documento. La aceptación no consiste en ejecutar todos los comandos, sino en tomar una decisión segura a partir de evidencia suficiente.
- Servicio relacionado
- Guardias para startups sin equipo SRE dedicado
- Gravedad de incidentes: una matriz de escalado
Preguntas frecuentes
¿Debe incluir comandos?
Sí, revisados y con requisitos, alcance y resultados esperados.
¿Qué longitud conviene?
La necesaria para el recorrido concreto, sin información ajena que oculte acciones.
¿Quién debe probarlo?
Alguien distinto del autor con accesos y capacidades esperados.
¿Qué hacer si la realidad difiere?
Detenerse en el límite definido, preservar pruebas y escalar.
¿Cuándo actualizarlo?
Tras cambios, ejercicios e incidentes que modifiquen sus supuestos.
Convirtamos la idea en un alcance realizable
Comparta el recorrido del usuario, las integraciones y las condiciones del lanzamiento. Podemos preparar una estimación con supuestos y exclusiones.
Para seguir leyendo
Guardias para startups sin equipo SRE dedicado
Un equipo pequeño puede organizar guardias útiles si sus promesas encajan con sus recursos.
Gravedad de incidentes: una matriz de escalado
La gravedad describe impacto actual o creíble, no lo alarmante del texto de un log.
Rollback o hotfix durante un incidente de producción
Durante un incidente, elija la acción con mayor probabilidad de recuperar servicio con riesgo controlado.