Una de mis grandes pasiones son las operaciones de infraestructura. Mis primeros trabajos fueron en ingeniería de redes, y más tarde, a medida que la nube se fue imponiendo, eso se convirtió en lo que ahora llamamos infraestructura u operaciones en la nube. Probablemente los momentos más estresantes fueron durante los cortes. A lo largo de las dos últimas décadas, he formado parte de muchos apagones, algunos peores que otros, pero llevo con orgullo mis cicatrices de batalla operativa. En este post, compartiré algunos aprendizajes y observaciones de estos incidentes.
Lo que me impulsó a escribir este post
Podría escribir muchos artículos sobre los incidentes “épicos” en los que he participado. Aunque son estresantes en el momento, después son buenas historias de guerra. En los últimos años, empresas como Facebook y Cloudflare han empezado a compartir públicamente sus retrospectivas de interrupciones (cronologías, causas fundamentales y lecciones aprendidas), que me gusta leer. ¡Es aprendizaje gratuito!
Hace unos días, Rogers publicó su resumen público de incidencias, que cubría los aspectos típicos de una retrospectiva de una interrupción. La interrupción en sí fue significativa. Rogers es el segundo ISP y operador de telefonía móvil de Canadá.
Lee: Apagón de Rogers: ¿Qué sabemos después de dos meses?
Hace dos años, sufrieron un apagón de 24 horas en todo el país que afectó a todos sus clientes de teléfono (incluido el 911) e Internet. Sí, ¡duro de pelar durante un día entero! Así que, naturalmente, como cliente de Rogers y entusiasta de las operaciones por Internet, cuando publicaron su informe (¡dos años después!), tuve que leerlo.
El apagón de Rogers
Aunque no es el tema principal de este artículo, repasemos brevemente la interrupción.
Durante un mantenimiento planificado, el personal de Rogers eliminó una política de enrutamiento de red, lo que provocó que las rutas (BGP u OSPF/ISIS) se inundaran internamente. Esto sobrecargaba el plano de control, causando todo tipo de problemas y, finalmente, provocando que se bloqueara o dejara inoperativos sus routers centrales.
El siguiente paso lógico sería intentar deshacer ese cambio, pero los propios routers ya no eran gestionables debido a los problemas del plano de control y, para empeorar las cosas, la red de gestión fuera de banda (OOB) también estaba caída.
Resulta que la red fuera de banda dependía de algún modo de la red de datos de producción, de modo que cuando ésta se caía, también lo hacía la red fuera de banda, lo que imposibilitaba la solución de problemas y la reparación.
Al final, hubo que enviar ingenieros para que accedieran manualmente a la consola.
Reflexiones sobre la interrupción de Rogers
Las interrupciones son un asco. Son superestresantes y, como demuestra el incidente de Rogers, pueden tener importantes repercusiones en el mundo real. Realizar estas retrospectivas a posteriori y llegar a la causa raíz, las lecciones aprendidas, etc., es obligatorio para cualquier organización que quiera mejorar continuamente.
Una cosa que me llamó la atención fue el artículo de CBC.ca (un importante medio de noticias de Canadá), cuyo titular era: “Un error humano provocó la interrupción masiva del servicio de Rogers en 2022, según un informe”. Si bien es cierto que el cambio desencadenó una secuencia de acontecimientos, declararlo como la causa principal es miope.
Muchas de estas interrupciones son como las investigaciones de accidentes aéreos, en las que múltiples factores contribuyen al fallo, a veces con años de antelación o mal diseñados para empezar.
Reflexionar sobre los cortes: ¿Podemos eliminarlos? ¿Deberíamos quererlo?
Siempre es fácil mojarse en un apagón desde la barrera, pero para que quede claro, esa no es mi intención. He aprendido de primera mano que ¡Mierda pasa! Así que, con la interrupción de Rogers en mente y a partir de la experiencia pasada, extraigamos algunas lecciones genéricas.
En primer lugar, eliminar por completo los cortes es probablemente demasiado ambicioso para la mayoría de nosotros. Sí, parte del proceso retrospectivo de una avería debe consistir en evitar que se produzca exactamente la misma avería en el futuro. Aun así, las arquitecturas evolucionan, las tecnologías cambian, e incluso un ligero cambio en los parámetros puede volver a provocar una interrupción similar.
Así que, aunque podemos limitar la posibilidad de cortes, no podrás eliminarlos al 100%. De hecho, dado el coste de la eliminación completa de la interrupción y dependiendo de tu sector (digamos Facebook frente a pilotar un avión de pasajeros), puede que no quieras aspirar necesariamente a eso. Hay costes financieros reales, costes de proceso, costes de agilidad o costes de tiempo de obtención de valor al intentar conseguir la eliminación total de las interrupciones.
Así pues, ¡aceptemos que se producirán cortes y utilicemos esa visión para centrarnos en limitar su daño e impacto! Este enfoque nos permite priorizar las estrategias eficaces, de las que hablaré a continuación.
Hora de Detectar – ¡también conocido como Sé el Primero en Saber!
Una supervisión suficiente ayuda a reducir el tiempo que se tarda en detectar y localizar las causas profundas. Suena obvio, ¿verdad? Sin embargo, casi todas las retrospectivas de averías tendrán un elemento de acción de mejora llamado “más supervisión”. Eso indica que siempre estamos olvidando alguna métrica y, por alguna razón, parece que nunca tenemos todas las comprobaciones y métricas. Por eso soy un gran partidario de la supervisión sintética de la disponibilidad.
Esta comprobación debe imitar una experiencia de usuario típica. Así, aunque cambies un componente básico, podrás ver el impacto sin añadir más métricas. Como no es fácil que se te escape algo, es la primera comprobación que debes añadir y, sobre todo, sobre la que debes alertar. Así que, tanto si se trata de un ping como de una simple prueba HTTP, esto te dará la seguridad instantánea de que tu servicio funciona. Yo lo llamo el principio de “ser el primero en enterarse”. No quieres que tus clientes te digan que tu servicio no funciona; tú eres el responsable y deberías ser el primero en saberlo.
Limitar radio de explosión
¿Podemos contener el impacto cuando algo se rompe? La interrupción de Rogers es un buen ejemplo del peor caso: un cambio rompió toda la red; la separación lógica, geográfica o funcional, podría haberlo evitado. Los proveedores modernos de la nube, como AWS, nos animan activamente a pensar en esto. Con AWS, siempre estás pensando en Multi-AZ o Multi-región. Algunos van más allá y van a la multi-nube (piensa en multi-proveedor en el terreno de las redes).
Sin embargo, la transición de una sola región a una multirregión o multi-nube puede resultar exponencialmente compleja y costosa. Lo mismo ocurre en el terreno de las redes, donde el camino de un proveedor único a un proveedor múltiple puede volverse bastante complejo rápidamente.
Algunos servicios son más fáciles de hacer multirregionales que otros (ni siquiera estoy pensando aún en la multi-nube). Por ejemplo, tu base de datos principal. Esto conlleva costes de complejidad real, y es comprensible que no siempre sea así.
Lo entiendo; los equipos de infraestructura suelen considerarse centros de costes. Aunque la alta disponibilidad y la fiabilidad se anuncian como prioridades, a menudo tienen prioridad las necesidades urgentes, el desarrollo de funciones y las presiones de costes. Sin embargo, ¡nunca dejes que un buen desastre se desperdicie! Tras una interrupción importante, los presupuestos y las prioridades suelen cambiar. Esta es tu oportunidad para defender las inversiones en resiliencia. La propuesta de valor es más fuerte inmediatamente después, así que aprovecha el momento.
Gestión Acceso
Las interrupciones que aún me persiguen y me provocan “estrés postraumático de operaciones” son aquellas en las que perdimos el acceso de gestión durante la interrupción. Esto es lo que le ocurrió a Rogers, y un incidente similar ocurrió con una de las mayores interrupciones de Facebook. Es una auténtica pesadilla: no puedes solucionar ni remediar el problema, ya que has perdido la capacidad de hacer nada en el dispositivo. A menudo, incluso la posibilidad de apagarlo o sacarlo de la rotación. Hasta que no restaures algún tipo de acceso de gestión al dispositivo, estarás atascado.
Este problema está más presente para la gente que ejecuta hardware físico que para los que lo hacen, por ejemplo, en AWS. Así que, si diriges tus propios centros de datos, nunca comprometas el acceso a la red fuera de banda sin pensar en el peor de los casos. Asegúrate de que tienes acceso OOB y de que está aislado de tu acceso a la red en banda. No siempre es fácil, pero si no lo tienes, tu tiempo de interrupción pasará de minutos a muchas horas (véase el ejemplo de Rogers y Facebook). La sensación de impotencia, aunque sepas cuál es el problema y sólo haga falta una orden para solucionarlo, es horrible.
Escenarios de retroceso
Otra valiosa herramienta de tu caja de herramientas para reducir el impacto de una interrupción es garantizar que su duración sea limitada. Hiciste el cambio, viste rápidamente que las cosas iban mal y simplemente deshiciste el cambio. Sin embargo, para que esto funcione, necesitas acceso de gestión (ver más arriba).
En los primeros tiempos con Cisco IOS, lo hacíamos así:
# reload in 5
# conf t
# < do your change >
# no reloadEsto significaba que el dispositivo se recargaría 5 minutos después de tu cambio, a menos que ejecutaras el último comando. Suponiendo que no perdieras el acceso, ejecutarías no recargar, lo que anularía la recarga al no ser necesaria. Juniper introdujo más tarde una solución más elegante con el “commit confirmado”, que hace retroceder automáticamente los cambios si no se confirman en un plazo determinado.
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
# < On-call blows Up! >
user@host# rollback 1
user@host# commitSi tu entorno es más bien un equipo de desarrollo de software, entonces considera la posibilidad de utilizar despliegues azul-verde. Sea cual sea tu elección a la hora de hacer cambios o desplegar nuevas versiones de tu software, es esencial tener la capacidad de retroceder rápidamente a la última versión de trabajo conocida. Saber que puedes retroceder rápidamente es muy bueno para la confianza. Obviamente, esto depende de nuestros temas anteriores: “sé el primero en saberlo” y el acceso a la gestión.
Cultura de equipo – No seas un héroe.
Por último, pero no por ello menos importante, tenemos que hablar de la cultura de equipo. Una de las cosas buenas de pasar del modelo tradicional de operaciones a DevOps (tú lo construyes, tú eres el propietario) es que ya no lanzas una nueva versión del software sobre la pared y pides a tu equipo de operaciones que la despliegue sin verlo.
Inevitablemente, en algún momento, distribuyes una versión defectuosa y el responsable de operaciones (yo) no tiene ni idea de lo que ha cambiado ni de cómo solucionarlo. Esto es extremadamente estresante y, francamente, injusto.
Hoy en día, la mayoría de los equipos de desarrollo son propietarios de sus propios cambios y los despliegan, y disponen de modernos pipelines de despliegue para realizarlos. Pero incluso entonces, el software es complejo, y no todos los miembros del equipo comprenden todos los componentes. Así, cuando haya una interrupción, traer al resto del equipo debería ser fácil. No tengas reparos en llamar a los miembros de tu equipo, incluso en mitad de la noche. En una organización sana, nadie debería querer despertarse a la mañana siguiente con la noticia de que ha habido un apagón de 4 horas y alguien de tu equipo ha intentado solucionar el fallo que tú introdujiste. Por tanto, ten un grupo de WhatsApp o cualquier herramienta que utilices sólo para tu equipo o tu propio canal fuera de banda para ayuda de emergencia.
Los cortes son abrumadores. Recibes muchas alertas que hay que reconocer, y recibes preguntas de los equipos de asistencia, de los clientes, de la alta dirección, etc. Y también se espera que resuelvas problemas. Ninguna persona puede hacerlo. Necesitas unas cuantas personas para solucionar los problemas, gestionar las alertas y coordinar todo el proceso, incluida la comunicación. Así que no te hagas el héroe. Llama a tus compañeros de equipo; juntos podéis hacer frente a esto. Recuerda: un equipo, un sueño.
Los cortes de suministro se producirán inevitablemente
Reconozcamos esta realidad y adoptemos medidas proactivas para limitar su impacto y duración.
Ten en cuenta la respuesta instintiva de la dirección: “¡Necesitamos más proceso de gestión del cambio!” A menos que seas una auténtica tienda YOLO, ésta no suele ser la respuesta.
En lugar de eso, utiliza el principio de “sé el primero en saberlo”, asegúrate de tener acceso a tu equipo en todo momento y ten herramientas preparadas para revertir rápidamente los cambios a un estado bueno conocido por última vez. Por último, aprovecha la oportunidad de aprender con tu equipo a través de las retrospectivas y sal aún más fortalecido. Con una dinámica de equipo sana, las interrupciones pueden convertirse sorprendentemente en valiosas experiencias de unión. Estando preparados y trabajando juntos, convertiréis los cortes en meros destellos en el radar.
Adaptado del post original que apareció por primera vez en toonk.io
Andree Toonk es una experimentada tecnóloga y empresaria apasionada por todos los aspectos de la infraestructura de Internet.