Ben Franklin una vez dijo que nada es inevitable excepto la muerte y los impuestos. Hoy yo añadiría los incidentes de operaciones a esa lista.
En Geko hemos tenido la (mala) fortuna de pasar por nuestra buena cantidad de respuestas de incidentes de operaciones, sistemas y seguridad. Es algo que pasa de forma inevitable por unas razones que son omnipresentes (en las que entraremos más adelante), y como respuesta proactiva a esto hemos adoptado unas prácticas y hábitos que nos permiten detectar, localizar y resolver incidentes de todo tipo de manera eficiente. Se vuelve una práctica mucho más manejable una vez asumes que van a ocurrir y te preparas para ello. Nunca se puede ser demasiado cuidadoso cuando estás hablando de la infraestructura crítica que tu equipo y tú usáis para trabajar, o el producto al que acceden tus clientes. Es un escenario de “No podemos permitirnos un desastre” y debes estar preparado para ello.
Hay unas contramedidas y comprobaciones que necesitas introducir en tu infraestructura y ecosistema que hace este escenario mucho más fácil de gestionar:
- Una plataforma de monitorización robusta
- Un plan bien diseñado de alertas
- failover de servicios
- snapshots y backups de los datos importantes
- un plan de disaster recovery
Vayamos de uno en uno para definir qué son y por qué son imprescindibles.
¿Cómo sé cuándo falla algo?
El primer paso hacia saber que tu infraestructura está fallando, es saber cómo se ve cuando no está fallando. Necesitas construir un sistema que compruebe constantemente el estado de todas las partes críticas de tu infraestructura, así sabrás cual es su estado normal, y podrás ver cuando se desvía de este estado de funcionamiento correcto. El status drift, si no se vigila, será tu primer paso hacia un estado de fallo: todo funciona bien, luego va fallando poco a poco. Al final llega un día donde tu estado se habrá desviado tanto de su funcionamiento original que tendrás que reconstruirlo todo desde cero. No quieres acabar aquí. Así que para evitarlo, se debe monitorizar anomalías de estado. Si algo se mueve, necesita monitorización. Si algo no se mueve, necesita monitorización por si se mueve.
¿Siento a alguien a mirar métricas?
No sirve de mucho un stack de monitorización si éste no te grita cuando algo va mal. Por lo tanto, a medida que se configura la infraestructura de monitorización, se añaden al mismo tiempo las alertas. La forma de hacerlo depende de la urgencia de la tarea. ¿Es un servidor que tiene el 70% de su disco lleno? quizás vale con que envíe un mensaje de Slack sobre ello a su equipo de TI. ¿Producción no responde a los pings? Probablemente quieras que llame a alguien inmediatamente para que empiece a hacer debugging cuanto antes. Depende de la urgencia del sistema y de lo grande que sea el indicador del problema. Tu entorno, tus prioridades.
¿Pero eso no mantiene el servicio como tal, no?
¿Necesitas una forma de mantener el servicio incluso en caso de fallo? Mantén un sistema de conmutación por error. Tal vez puedas omitir la llamada sobre el servidor que falla, o puedes mover ese ticket de «cambiar el disco duro fallido» hacia abajo en la lista de prioridades porque de momento tienes otra en el RAID. Dos es uno, uno es ninguno. Implementa una conmutación por error en básicamente cualquier cosa importante, incluso si es un sistema de conmutación por error manual. Ten algo preparado para cambiar rápidamente y mantener el servicio.
¿Qué hago cuando me llega una alarma de fallo?
Pongámonos en un escenario de desastre por un momento. Supongamos que has ignorado la alerta S.M.A.R.T. un día más de lo que debías. Tu máquina principal ha caído, no puedes simplemente pulsar el botón de encender para que vuelva a funcionar y olvidarte de ella, y de alguna manera también tenías tu failover en esa misma máquina, por ejemplo un escenario en el que tu máquina proxmox pasa a conocer al creador. Enhorabuena, estás ante un incidente. Así que, para este caso, que sabías que podía ocurrir, has preparado copias de seguridad (espero) y puedes intercambiar esa unidad y restaurarla. Puede que pierdas un día de trabajo, pero no es nada comparado con perderlo todo y pasar cientos de horas reconstruyendo tu empresa desde cero. Es especialmente importante recordar la regla básica de las copias de seguridad, conocida generalmente como la regla 3-2-1:
- 3 copias de tus datos
- En al menos 2 dispositivos diferentes
- 1 de ellos en una localización remota
De este modo, incluso en caso de un incidente especialmente grave, como un incendio, puedes simplemente restaurar a partir de la copia de seguridad externa (aunque eso puede llevar bastante más tiempo dependiendo de tu solución). Además, comprueba que tus copias de seguridad funcionan. Por favor. Una copia de seguridad no es una copia de seguridad hasta que la pruebas.
Como extra, no te marques un Michael Scott con tu equipo.
¿No podemos prepararnos para todo, cierto?
Pueden ocurrir muchas cosas y, por desgracia, no se pueden predecir todas. Puede pasar cualquier cosa y cuanto más compleja sea la configuración de tu infraestructura, más puntos de fallo habrá en ella, así que tienes que prepararte todo lo posible. Tal vez no puedas tener todos los incidentes posibles previstos, pero cuantos más planifiques, mejor, de modo que si ocurre algo, tu personal de guardia pueda simplemente repasar un runbook en tu documentación y solucionar el problema sin mucho escalado. Este plan suele incluir ejemplos de escenarios que consideras posibles en función de la configuración de tu infraestructura, los elementos que se ven afectados y la forma de solucionar el problema.
Suena a que necesito uno de esos planes.
Si un elemento importante de su infraestructura falla, ¿recibirías una llamada, un correo electrónico o una notificación de Slack? ¿Está seguro de que sus copias de seguridad funcionan? ¿Cómo de resistente es tu plataforma a un fallo de disco? Si estos escenarios suenan como un problema en tu caso, tal vez te resulte útil ponerte en contacto con nosotros y hablaremos de cómo ponerlo todo en orden. Sólo tiene que tomar una decisión: ¿lo haces ahora o espera a que se produzca su próximo incidente? Recuerda las palabras de Picard sobre la gestión de incidentes:
