En otra entrada de este log ya escribí sobre una brecha de backups en esta plataforma que todavía no está completamente cerrada: un riesgo real y actualmente abierto, no un problema resuelto que esté narrando a posteriori como si ya estuviera atendido. Esta entrada es la otra mitad de esa honestidad: lo que existe porque la historia de los backups no está terminada. Un flujo de triaje ensayado y una documentación tratada como fuente de verdad real no sustituyen a los backups (nada sustituye a los backups), pero son el control compensatorio que hace que la brecha sea sobrevivible mientras se cierra, en lugar de ser simplemente un riesgo sin atender que permanece en silencio hasta que deja de estarlo.
Para dejar claro qué no es esta entrada: no es el relato de una caída concreta. Nada de lo que se describe aquí narra un incidente que ya haya ocurrido en esta plataforma. Es la disciplina general (el flujo que se usa si y cuando algo se rompe) puesta por escrito ahora, deliberadamente, en lugar de improvisada por primera vez bajo presión.
Runbooks y guías son documentos distintos
Es fácil meter toda la documentación operativa en un mismo montón indiferenciado llamado «docs», pero dos de las categorías de ese montón cumplen funciones genuinamente distintas, y confundirlas produce documentación mala en ambos frentes.
Un runbook responde a «qué hago cuando X se rompe», y se gana ese nombre por ser repetible: los mismos pasos, en el mismo orden, produciendo el mismo resultado, sin importar quién lo ejecute ni lo tranquila que esté esa persona a las tres de la madrugada. Un buen runbook se lee casi como un guion: comprueba esto, si es cierto haz aquello, si no lo es haz esto otro. No necesita explicar por qué existe cada paso, porque quien lo sigue durante un incidente real no tiene atención de sobra para el razonamiento; necesita que el procedimiento simplemente funcione.
Una guía responde a una pregunta distinta: «cómo razono sobre hacer X por primera vez». Es el documento que se lee antes de que exista un runbook para algo, o cuando el runbook no cubre la forma concreta en que se está manifestando este fallo en particular. Una guía explica el modelo mental: así es como funciona realmente este subsistema, así es como se ve lo normal, así se distingue entre tres modos de fallo que a primera vista se parecen. Se lee más despacio y se actúa sobre ella más despacio, y eso está bien, porque el trabajo de una guía es construir la comprensión que un runbook podrá comprimir más adelante en un procedimiento rápido.
El error es escribir guías cuando lo que hace falta son runbooks (nadie quiere razonar desde primeros principios mientras un servicio está caído) o escribir runbooks cuando lo que hace falta son guías (un procedimiento rígido para un modo de fallo nuevo simplemente falla en silencio en cuanto la realidad no coincide con el guion). Saber cuál de los dos exige una situación dada es, en sí mismo, parte de la disciplina, y a menudo la respuesta honesta, la primera vez que aparece un tipo concreto de fallo, es que todavía solo existe una guía, y el runbook se escribe después, con lo que realmente reveló el razonamiento a nivel de guía.
Un flujo general de triaje
Por debajo de los runbooks concretos para sistemas concretos, hay una forma que sigue la mayor parte del triaje de fallos en esta plataforma, más o menos en este orden:
1. Identificar el alcance real de lo que está roto. No lo que se reporta como roto, sino lo que realmente está roto. Un síntoma visible para el usuario («el sitio está caído») es con frecuencia un efecto secundario de algo completamente distinto, y saltar directamente a arreglar el síntoma visible sin acotar el fallo real desperdicia tiempo y a veces hace más difícil ver el problema de verdad. Acotar significa averiguar en qué capa está realmente el fallo antes de tocar nada.
2. Comprobar el estado del cluster y de la red. Antes de dar por hecho un fallo a nivel de aplicación, descartar (o confirmar) que la infraestructura subyacente está sana: si la red es alcanzable de extremo a extremo, si la capa de cluster o de host subyacente reporta estar sana, si esto es en realidad un problema de aplicación o un problema de infraestructura disfrazado de síntoma de aplicación. Saltarse este paso es cómo la gente acaba pasando veinte minutos depurando código de aplicación para un problema que en realidad era una partición de red una capa más abajo.
3. Reconstruir tratando la documentación como la fuente de verdad real. Este es el paso que más importa para el argumento de esta entrada. Cuando algo necesita reconstruirse (un servicio que hay que volver a desplegar, una pieza de infraestructura que hay que recrear), la reconstrucción sigue lo que está escrito, no lo que alguien recuerda haber hecho la última vez. La memoria colectiva y la memoria muscular son exactamente lo que falla bajo las dos condiciones que hacen difícil la recuperación ante desastres: hace tiempo que nadie sigue este procedimiento, o la persona que suele hacerlo no está disponible. Una reconstrucción guiada por la documentación es reproducible sin importar quién la haga ni cuánto tiempo haya pasado. Una reconstrucción guiada por la memoria es apostar a que el recuerdo de una persona concreta sea preciso bajo estrés, y es una mala apuesta de la que depender estructuralmente.
4. Validar que la reconstrucción realmente ha funcionado. Reconstruir algo y confirmar que tiene buena pinta no son el mismo paso, y saltarse el segundo es cómo un esfuerzo de recuperación deja tranquilamente un sistema en un estado que parece correcto y no lo es. Validar significa comprobar las cosas concretas que importan para ese sistema, no solo «¿responde?», sino «¿responde correctamente, con los datos y la configuración que se supone que debe tener?».
5. Registrar en la documentación lo aprendido. El bucle se cierra aquí o no se cierra en absoluto. Si la reconstrucción reveló que un paso del runbook estaba mal, faltaba o se basaba en una suposición que resultó no ser cierta, eso vuelve a la documentación de inmediato, no como una tarea para algún día, sino como parte de terminar la recuperación. Un esfuerzo de recuperación ante desastres que no actualiza después sus propias instrucciones garantiza que la siguiente persona se tope exactamente con la misma brecha, en el peor momento posible para descubrirla por primera vez.
Por qué esto es un control compensatorio, no un sustituto
Nada de esto hace que los backups sean opcionales. Un flujo de triaje ensayado y una documentación fiable reducen el daño de una clase de fallos (aquellos en los que hay que recrear, reconfigurar o depurar infraestructura desde un estado degradado), pero no hacen nada frente al modo de fallo que existen los backups para cubrir: datos que realmente han desaparecido. Si los datos subyacentes de un sistema se pierden y no hay ningún backup desde el que restaurarlos, el mejor flujo de triaje del mundo reconstruye la cáscara vacía del sistema que solía contener esos datos. La documentación te dice cómo recrear la infraestructura fielmente. No puede recrear datos que ya no existen en ninguna parte.
Ese es el límite honesto de lo que compra esta disciplina, y merece la pena hacerlo explícito en lugar de dejar que «tenemos buenos runbooks» ocupe en silencio el lugar de «tenemos backups», porque son frases distintas y aquí, ahora mismo, solo una de las dos es completamente cierta. Lo que el flujo de triaje y la práctica de documentación-como-fuente-de-verdad realmente hacen, mientras se cierra la brecha de backups, es reducir el conjunto de fallos que se convierten en caídas prolongadas o repetidas (una configuración se corrompe, un host hay que reconstruirlo desde cero, un servicio necesita volver a desplegarse tras un cambio erróneo) a algo aburrido y procedimental, en lugar de algo que depende de que alguien recuerde la secuencia correcta de comandos bajo presión. Eso es valor real. Simplemente no es el mismo valor que restaura un backup que funciona, y fingir lo contrario sería exactamente el tipo de exageración cómoda que este log ha intentado evitar.
La documentación se gana el título de «fuente de verdad» usándose
Hay una trampa específica del tercer paso del flujo de triaje que merece mencionarse aparte: la documentación solo funciona como fuente de verdad si es realmente precisa, y la única forma de saber que lo es consiste en haberla seguido lo bastante recientemente como para notar dónde se ha ido desviando de la realidad. Un runbook que era correcto cuando se escribió y no se ha tocado desde entonces es un runbook que ha ido acumulando en silencio pequeñas imprecisiones cada vez que el sistema subyacente cambió sin que la documentación se actualizara para reflejarlo: una clave de configuración renombrada, un paso que antes era manual y ahora está automatizado, una dependencia que se sustituyó por otra. Ninguno de esos cambios, por separado, parece merecer una actualización de la documentación en el momento en que ocurre. En conjunto, son lo que convierte «sigue los pasos documentados» de un procedimiento fiable en un procedimiento que te lleva el 90% del camino y luego te deja tirado justo en el paso que dejó de ser cierto sin que nadie se diera cuenta.
La única defensa real frente a esa deriva es tratar cualquier reconstrucción (no solo la forzada por un fallo real) como una prueba implícita de la propia documentación, y eso es exactamente lo que cierra el bucle en el paso cinco. Una reconstrucción rutinaria y planificada (levantar un host de repuesto, volver a desplegar un servicio como parte del mantenimiento ordinario en lugar de como respuesta a un incidente) es una oportunidad de bajo riesgo para descubrir la misma deriva que expondría un desastre real, sin la presión de tiempo de una caída real asociada al descubrimiento. Usar deliberadamente el trabajo de mantenimiento ordinario de esta forma (seguir el procedimiento documentado incluso cuando la memoria muscular sería más rápida en el momento) es lo que mantiene la documentación lo bastante fiable como para apoyarse en ella más adelante, cuando ni siquiera existe el lujo de que la memoria muscular sea una opción, porque la persona que suele encargarse de esto no es la que se está ocupando en ese momento.
El modo de fallo que existe toda esta disciplina para prevenir
Merece la pena ser preciso sobre qué es lo que realmente falla cuando falta esta disciplina, porque «sin backups» y «sin un proceso de recuperación ensayado» fallan de formas distintas y concretas, en lugar de difuminarse en una descripción genérica de «mala operación». La falta de backups falla como pérdida de datos: algo que existía ahora ha desaparecido, de forma permanente, y ningún procedimiento lo recupera. Un proceso de recuperación ausente o poco fiable falla como duración e inconsistencia: la caída dura más de lo necesario, o se resuelve de forma distinta según quién estuviera de guardia, porque no hay nada escrito lo bastante fiable como para seguirlo, y la persona que se ocupa está reconstruyendo el procedimiento a partir de la memoria y de decisiones sobre la marcha, en lugar de ejecutar algo ya verificado que funciona. Ambos modos de fallo son riesgos reales. Simplemente no son el mismo riesgo, y cerrar uno no afecta al otro, que es precisamente por lo que esta plataforma está trabajando en ambos en paralelo en lugar de tratar a uno como sustituto del otro.