Cuando se oye la palabra “caída,” se puede pensar que estamos hablando del colapso total de un servicio, que todas las partes de la cadena de prestación de servicios han dejado de estar disponibles de repente. Sin embargo, cuando se profundiza en la anatomía de la mayoría de las caídas, es raro (aunque no imposible) descubrir un colapso total.
Recientemente, hemos observado un repunte de lo que llamamos fallos “funcionales,” en los que tal vez solo ha fallado una parte de un servicio, pero con efectos que interrumpen toda la cadena de suministro; puede que sea un fallo de una puerta de enlace o un problema con un proceso de autenticación de usuarios. Estos componentes suelen ser suministrados por terceros y escapan al control del proveedor de servicios; sin embargo, pueden tener un impacto devastador en la prestación de servicios.
Solo examinando la anatomía de estas caídas se puede empezar a mitigarlas, tanto desde el punto de vista del proveedor de servicios como del cliente. A continuación, exploraremos cómo una comprensión más profunda de cómo se producen las caídas puede ayudar a reducir los riesgos de fallo a largo plazo.
El auge de los fallos funcionales
Si escuchas habitualmente el podcast The Internet Report, nos habrás oído hablar cada vez más de los fallos funcionales de algunos de los mayores servicios de Internet del mundo en los últimos meses. Estos fallos suelen aparecer ante el usuario como que el servicio está “caído”. No obstante, cuando nos adentramos en la superficie de estas caídas, descubrimos que a menudo es solo una pequeña parte de la aplicación la que ha fallado, como un plugin de terceros, una puerta de enlace de pago o el proveedor de autenticación.
Estamos en la era de la arquitectura distribuida, en la que los servicios están formados por muchos componentes diferentes que deben trabajar en armonía. Esta configuración tiene muchas ventajas, como la optimización del servicio y la reducción de la latencia. Si tu empresa vende a través de Internet, por ejemplo, probablemente no querrás gestionar tu propia puerta de enlace de pago. ¿Por qué? No es tu especialidad, es un campo de minas para la seguridad y casi siempre es más barato recurrir a un tercero que no tenga costes de desarrollo ni de mantenimiento. Incluso las mayores empresas tecnológicas del mundo confían en componentes de terceros para partes de sus aplicaciones. No se trata de tecnología por tecnología, sino de una forma de aumentar el rendimiento y reducir los gastos generales.
Sin embargo, existe un elemento de riesgo: estos componentes pueden convertirse en un único punto de fallo. Si un usuario no puede autenticarse en una red social, por ejemplo, no importa si el elemento de mensajería del servicio sigue funcionando perfectamente; no podrán entrar por la puerta principal.
De forma similar, hemos visto caídas en las que la autenticación está bien y todo lo relacionado con la aplicación parece funcionar con normalidad. Pero el fallo funcional de un servicio backend significa que cuando un usuario intenta realmente realizar una acción, como enviar un mensaje o comprar un artículo, el servicio falla.
Aunque la mayoría de los proveedores de servicios incorporan un elemento de redundancia en sus servicios, a veces la relación riesgo/beneficio hace que un sistema de conmutación por falla sea difícil de justificar. Por ejemplo, desplegar una puerta de enlace de pago de copia de seguridad es una solución cara y técnicamente compleja de la que muchos proveedores de servicios deciden prescindir. Del mismo modo, los consumidores rara vez compran dos servicios del mismo tipo por si uno falla.
Todo ello no significa que no haya más remedio que encogerse de hombros y aceptar las caídas ocasionales, ya sea por parte del proveedor de servicios o del usuario final.
Entender una caída
¿Qué se puede hacer en estas situaciones? En primer lugar, hay que comprender la anatomía de una caída.
Hay que empezar por identificar el dominio del fallo (es decir, dónde se ha producido realmente el problema y quién es el responsable de resolverlo). Por ejemplo, ¿fue un servicio de terceros o el centro de datos que aloja ese servicio el que falló?
Sin embargo, no estamos aquí únicamente para repartir culpas. Se trata de entender el impacto de ese fallo y los efectos secundarios que podría crear en el futuro, en caso de que se repita. ¿Ha habido una pérdida total del servicio o solo ha afectado al rendimiento? ¿Cuáles fueron las consecuencias del aumento de latencia en una parte concreta de la cadena de servicios? Solo cuando se conozcan todas las consecuencias de una caída se podrá empezar a pensar en cómo evitarla (o reducir su impacto) en el futuro.
Como empresa, tendrás que decidir dónde y cuándo tiene sentido la redundancia. Como hemos dicho antes, es muy poco probable que cuentes con dos puertas de enlace de pago porque no suele ser viable desde el punto de vista financiero. Sin embargo, quizá decidas tener dos proveedores CDN o dividirlos por regiones. Eso tendrá un coste informático, pero formará parte de la evaluación del riesgo.
Los clientes de estos servicios también deben evaluar los riesgos. ¿Cuánto cuesta un fallo de este tipo y cuánto costaría remediarlo? Como cliente de un proveedor de servicios en la nube, por ejemplo, puede que tengas que decidir si invertir en dos zonas de disponibilidad individuales, lo que requiere un análisis de costes: ¿cuál es el coste informático adicional? ¿Cómo se van a mantener los datos sincronizados entre las dos? ¿Se necesitan varias CDN? ¿Tiene más sentido desde el punto de vista financiero recurrir a un proveedor de nube de segundo nivel?
Todo esto se reduce a tener un conocimiento completo de toda la cadena de prestación de servicios. Hay que saber por qué se ha producido una caída, qué probabilidades hay de que se produzca en el futuro, cuál es el nivel de riesgo y si se quieren tomar medidas para evitar que vuelva a ocurrir.
Conviene evitar la mentalidad de “encontrar el fallo, arreglar el fallo” y situarse en una posición de mejora continua, en la que se puedan anticipar posibles problemas y mitigarlos antes de que se produzcan.
Ver el episodio del podcast "The Anatomy of an Outage" para saber más sobre la anatomía de una caída y estudiar algunos casos reales.
Identificar la información clave
Se trata de salir de este estado reactivo y pasar a un modo preventivo en el que la compañía busque continuamente formas de mejorar el rendimiento en toda la red. Para ello, hay que asegurarse de centrarse en los datos correctos.
Es fácil caer en la trampa de intentar estar al tanto de absolutamente todo, tirando de todas y cada una de las métricas que caen en tus manos, lo que no solo lleva mucho tiempo, sino que puede resultar muy caro. E incluso si puedes permitirte recopilar todos esos datos, pronto te encontrarás buscando la aguja en el pajar.
La clave está en identificar la información relevante que marcará la diferencia en tu empresa y que tee permitirá optimizar las operaciones de cara al futuro porque comprendes plenamente los riesgos y los costes/beneficios de abordar cualquier posible problema o posible solución.
En el pasado, trabajé con una empresa muy conocida en el sector del juego. La compañía había decidido trasladar sus operaciones desde su propio centro de datos a la nube, un “lift and shift” de su infraestructura, como se suele decir. A la empresa le dijeron que simplemente replicando su configuración actual en una arquitectura en la nube reduciría costes y mejoraría el rendimiento.
Sin embargo, una vez completada la migración, la organización se sorprendió al descubrir que el rendimiento había disminuido, a pesar de haberse trasladado a un hardware más moderno, porque no habían adaptado la arquitectura a los requisitos de la nueva infraestructura en la nube. Cualquier tipo de retraso en el rendimiento de la aplicación es fundamental en el sector del juego, porque los clientes apuestan en directo y quieren reaccionar al instante a los cambios. Pero en la nueva infraestructura se tardaba el doble en hacer apuestas que en la antigua, lo que podía ahuyentar a los clientes.
Para agravar el problema, los costes informáticos de la empresa estaban aumentando porque habían migrado una compilación en las instalaciones a la nube sin optimizar el backend para la infraestructura de nube.
Para solucionar el problema, tuvieron que dar un paso atrás y examinar de nuevo la situación. Rediseñaron el código basado en la plataforma de nube para reducir los costes, pero no a expensas del rendimiento. De hecho, necesitaban mejorar la eficiencia. Para ello, tuvieron que dividir el servicio y acercar geográficamente la infraestructura de nube a la base de usuarios, de modo que no hubiera tanto retraso cuando fueran a hacer apuestas.
Identificar los puntos de inflexión
Esta experiencia remite a nuestro punto sobre la búsqueda proactiva de mejoras. Lo más importante que puede hacer una organización es identificar los puntos débiles de su entorno. ¿Dónde están los posibles cuellos de botella?
No se trata necesariamente de identificar todos y cada uno de los puntos de fallo; se trata de encontrar dónde es más probable que se produzca una degradación del rendimiento. Si se logra identificar, será también la parte de la cadena que más posibilidades tiene de romperse, porque en cualquier caída, el principal indicador es la pérdida. Es entonces cuando se produce la degradación y la retransmisión, el aumento de la latencia y todos los principales indicadores de un fallo.
Si consigues identificar estos cuellos de botella antes de que algo se rompa, tendrás un objetivo para la optimización: ese será el lugar donde probablemente obtendrás el mayor beneficio en términos de gasto en TI. Y es un día menos que pasarás mirando las métricas y preguntándote qué salió mal.