Ningún sistema, aplicación o infraestructura es infalible. Por muy robusta que tratemos de hacerla, por muy resiliente que queramos que sea y por muchas pruebas que hagamos siempre existe la posibilidad de que falle. Y eso de por si no es malo, lo que si es preocupante es no aprender de esos errores para tratar de evitarlos. Y no podemos aprender sin entender, por eso ante una incidencia siempre hay que analizar las causas y pensar en la forma de evitar que se vuelvan a producir. A esta investigación se la suele llamar post mortem y tan importante es realizarla como docuentarla para poder consultarla en el futuro. Ahí es dónde entran los RCA.
UN RCA es un documento en el que se plasma una serie de información referente a un incidente. Se pueden añadir todos los apartados que se quiera, pero por lo general cómo minimo debería aparecer lo siguiente:
- Descripción del problema
- Causa Raíz
- Solución y prevención
- Descripción del impacto
Con esta información, es fácil dejar plasmado que es lo que ha pasado, el motivo, la forma de solucionarlo, medidas que se van a tomar para prevenir que vuelva a suceder (si es posible) y como ha afectado al servicio (Si ha tenido impacto economico, reputacional, cómo ha afectado a los usuarios.. )
Pongamos un ejemplo, el disco duro en el que nuestra base de datos almacena la información se llena, la base de datos no puede escribir y deja de dar servicios. Todas las aplicaciones que usan esta base de datos dejan de funcionar. nuestro RCA podría tener la siguinte forma:
Descripción del problema
El pasado sábado día 26 de Mayo del 2024 el disco duro en el que la base de datos code_teca se qeudó sin espacio. Al no poder escribir en el disco, la base de datos dejo de dar servicio.
Causa Raiz
El disco duro en el que la base de datos persiste la información se quedó sin espacio.
Solución
Se sustituye el disco actual de 1Tb por uno de 5Tb, haciendo previamente un volcado completo de datos para no perder la inforamción existente antes del incidente.
Una vez sustituido el disco, se reinicia la instancia de la base de datos y se comprueba que vuelve a dar servicio con normalidad.
Prevención
Se configuran alertas de estado de FS, creando una alerta de tipo info al superar le 60% de la ocupación. una de tipo minor al llegar al 70%, una high al llegar al 80% y una critical al 90% de llenado del disco.
Las alertas high y critical se envían también al grupo de Slack de los SRE.
Impacto
Durante las 2 horas que se tardó en resolver el incidente hubo una perdida de servicio total para el registro de usuarios, compra online, recebir comentarios de los usuarios y subida de nuevos productos. Y una afectación parcial en el catálogo de productos.
Estas afectaciones tuvieron impacto para el negocio, tanto a nivel económico como a nivel de experiencia de los clientes.
Y ya estaría, esto sería basicamente todo. Hemos tratado todos los puntos importantes de la incidencia y podemos consultar de forma sencilla todo su ciclo de vida.
Esto se puede escribir en cualquier tipo de documento, aunque quizá lo más sencillo sea utilizar markdown, que permite escribir texto con formato y no requiere ningún programa especifico para poder ser leido o editado, a diferencia de lo que ocurre por ejemplo con Word.
Por ultimo quedaría darle un nombre al documento, generalmente no se le da un nombre cualquiera, sino que se usa la fecha para refenciarlo. Por ejemplo dado que nuestro incidente ocurrio el 26 de Mayo del 2024 lo normal sería llamar al fichero
260524A
La letra se usa por si en un mismo día ocurriese más de un incidente. En ese caso se irían usando de forma consecutiva las demás letras del alfabeto.
De esta forma tan sencilla podemos tener nuestra biblioteca de RCAs perfectamente ordenada y organizada.
