Navegar por las interrupciones de las infraestructuras: Cicatrices de batalla y lecciones aprendidas

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 operaciones de infraestructura o en la nube. Probablemente, los momentos más estresantes fueron durante las interrupciones del servicio. 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.

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 raíz y lecciones aprendidas), que disfruto leyendo. ¡Es aprendizaje gratuito!

Hace unos días, Rogers publicó su resumen público de incidentes, que cubría los aspectos típicos de una retrospectiva de un apagón. La interrupción en sí fue significativa. Rogers es el segundo proveedor de servicios de Internet y de telefonía móvil de Canadá.

Leer: 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í, ¡se cayeron durante un día entero! Así que, naturalmente, como cliente de Rogers y entusiasta de las operaciones en Internet, cuando publicaron su informe (¡dos años después!), tuve que leerlo.

Aunque no es el tema principal de este artículo, repasemos brevemente el apagó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 sobrecargó el plano de control, causando todo tipo de desafíos, provocando finalmente que se bloqueara o dejara inoperativos sus routers centrales.

Un siguiente paso lógico sería intentar deshacer ese cambio, sin embargo, 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 remediación.

Al final, hubo que enviar ingenieros para conseguir manualmente el acceso a la consola.

Los apagones apestan. Son súper estresantes y, como demuestra el incidente de Rogers, pueden tener importantes repercusiones en el mundo real. Realizar estas retrospectivas después del hecho 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 desencadenó 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.

Muchos de estos apagones son como las investigaciones de accidentes aéreos, en los que múltiples factores contribuyen al fallo, a veces comenzando años antes o estando mal diseñados para empezar.

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 ¡la mierda pasa! Así que, con el apagón de Rogers en mente y a partir de la experiencia pasada, extraigamos algunas lecciones genéricas.

En primer lugar, eliminar los cortes de suministro por completo es probablemente demasiado ambicioso para la mayoría de nosotros. Sí, parte de un proceso retrospectivo de interrupciones debería consistir en evitar que se produzca exactamente la misma interrupción 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 podamos limitar la posibilidad de que se produzcan cortes, no podrá eliminarlos al 100%. De hecho, dado el coste de la eliminación completa de interrupciones y dependiendo de su sector (digamos Facebook frente a pilotar un avión de pasajeros), no necesariamente querrá aspirar a ello. Existen costes financieros reales, costes de proceso, costes de agilidad o costes de tiempo de obtención de valor al intentar lograr la eliminación completa de los cortes de suministro.

Así pues, ¡aceptemos que las interrupciones se producirán y utilicemos esa perspectiva para centrarnos en limitar su daño e impacto! Este enfoque nos permite priorizar estrategias eficaces, de las que hablaré a continuación.

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 es un indicio de 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 fan de la monitorización sintética de la disponibilidad.

Esta comprobación debería imitar una experiencia de usuario típica. Así, aunque cambie un componente básico, podrá ver el impacto sin necesidad de añadir más métricas. Dado que no es fácil que se le escape algo, es la primera comprobación que debe añadir y, lo que es más importante, sobre la que debe alertar. Así que, ya sea un ping o una simple prueba HTTP, esto le dará una confianza instantánea de que su servicio está funcionando. Yo llamo a esto el principio de "ser el primero en saberlo". No querrá que sus clientes le digan que su servicio no funciona; usted es el responsable y debería ser el primero en saberlo.

¿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 de nube modernos como AWS nos animan activamente a pensar en esto. Con AWS, siempre se está pensando en Multi-AZ o Multi-región. Algunos van más allá yendo a la multi-nube (piense en multi-proveedor en la tierra de la red).

Sin embargo, la transición de una sola región a una multiregión o multi-nube puede volverse exponencialmente compleja y costosa. Lo mismo ocurre en el terreno de las redes, donde el paso de un proveedor único a un proveedor múltiple puede volverse bastante complejo rápidamente.

Algunos servicios son más fáciles de convertir en multirregión que otros (ni siquiera estoy pensando aún en la multi-nube). Por ejemplo, su base de datos central. Esto conlleva unos costes de complejidad reales, y es comprensible que no siempre sea así.

Lo entiendo; los equipos de infraestructura se consideran a menudo centros de costes. Aunque la alta disponibilidad y la fiabilidad se pregonan como prioridades, las necesidades urgentes, el desarrollo de funciones y las presiones de costes suelen tener prioridad. Sin embargo, ¡nunca hay que desaprovechar un buen desastre! Tras una interrupción importante, los presupuestos y las prioridades suelen cambiar. Esta es su oportunidad para abogar por las inversiones en capacidad de recuperación. La propuesta de valor es más fuerte inmediatamente después, así que aproveche el momento.

Los apagones que aún me persiguen y me provocan "estrés postraumático de operaciones" son aquellos en los que perdimos el acceso de gestión durante el apagón. Esto es lo que le ocurrió a Rogers, y un incidente similar ocurrió con una de las mayores interrupciones de Facebook. Es un verdadero escenario de pesadilla: no se puede solucionar o remediar el problema ya que se ha perdido la capacidad de hacer cualquier cosa en el dispositivo. A menudo, incluso la capacidad de simplemente apagarlo o sacarlo de la rotación. Hasta que no restablezca algún tipo de acceso de gestión al dispositivo, estará 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 ejecuta sus propios centros de datos, nunca comprometa el acceso a la red fuera de banda sin pensar en el peor de los casos. Asegúrese de que dispone de acceso OOB y de que está aislado de su acceso a la red dentro de banda. No siempre es fácil, pero si no dispone de esto, su tiempo de interrupción pasará de minutos a muchas horas (véase el ejemplo de Rogers y Facebook). La sensación de impotencia, aunque sepa cuál es el problema y sólo haga falta un comando para solucionarlo, es horrible.

Otra valiosa herramienta de su caja de herramientas para reducir el impacto de una interrupción es asegurarse de que su duración es limitada. Usted hizo el cambio, vio rápidamente que las cosas iban mal y simplemente lo deshizo. Sin embargo, para que esto funcione, necesita acceso de gestión (véase más arriba).

En los primeros tiempos con Cisco IOS, lo hacíamos así:

Esto significaba que el dispositivo se recargaría 5 minutos después de su cambio a menos que ejecutara el último comando. Suponiendo que no perdiera el acceso, ejecutaría "no reload", que cancelaría la recarga al no ser necesaria. Juniper introdujo más tarde una solución más elegante con "commit confirmed", que anula automáticamente los cambios si no se confirman en un plazo de tiempo determinado.

Si su entorno es más propio de un equipo de desarrollo de software, entonces considere la posibilidad de utilizar despliegues azul-verde. Sea cual sea su elección a la hora de realizar cambios o desplegar nuevas versiones de su software, es esencial tener la capacidad de revertir rápidamente a la última versión de trabajo conocida. Saber que se puede volver atrás rápidamente es muy bueno para la confianza. Obviamente, esto depende de nuestros temas anteriores: "ser el primero en saberlo" y el acceso de gestión.

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 (usted lo construye, usted es el propietario) es que ya no lanza una nueva versión del software por la pared y pide a su equipo de operaciones que lo despliegue sin verlo.

Inevitablemente, en algún momento, envías una versión estropeada y tu persona de operaciones (este era yo) no tiene ni idea de qué ha cambiado o 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 modernas canalizaciones de despliegue para realizarlos. Pero incluso entonces, el software es complejo y no todos en el equipo entienden todos los componentes. Por eso, cuando se produce una interrupción, llamar al resto del equipo debería ser fácil. No sea tímido a la hora de llamar a los miembros de su 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 su equipo ha intentado solucionar el fallo que usted introdujo. Por lo tanto, tenga un grupo de WhatsApp o cualquier otra herramienta que utilice sólo para su equipo o su propio canal fuera de banda para ayuda de emergencia.

Las interrupciones del servicio son abrumadoras. Usted recibe muchas alertas que todas necesitan ser reconocidas, y recibe preguntas de los equipos de soporte, de los clientes, de la alta dirección, etc. Y también se espera de usted que resuelva los problemas. Una sola persona no puede hacerlo. Necesita a varias personas para solucionar los problemas, gestionar las alertas y coordinar todo el proceso, incluida la comunicación. Así que no se haga el héroe. Llame a sus compañeros de equipo; juntos, pueden hacer frente a esto. Recuerde: un equipo, un sueño.

Reconozcamos esta realidad y tomemos medidas proactivas para limitar su impacto y duración.

Sea consciente de la respuesta instintiva de la dirección: "¡Necesitamos más proceso de gestión del cambio!" A menos que sea una verdadera tienda YOLO, ésta no suele ser la respuesta.

En su lugar, utilice el principio de "ser el primero en saberlo", garantice el acceso a su equipo en todo momento y tenga herramientas preparadas para revertir rápidamente los cambios a un último estado bueno conocido. Por último, aproveche la oportunidad de aprender con su equipo mediante retrospectivas y salga aún más fortalecido. Con una dinámica de equipo sana, las interrupciones pueden convertirse sorprendentemente en valiosas experiencias para estrechar lazos. Estando preparados y trabajando juntos, convertirán las interrupciones 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.

Las opiniones expresadas por los autores de este blog son suyas y no reflejan necesariamente los puntos de vista de la Internet Society.