Llegamos a ustedes gracias a:



Columnas de opinión

Lecciones de fracasos de TI de alto perfil

Por: Jonathan Hassell, director de 82 Ventures

[03/10/2016] No han sido buenos meses para la salud y la consistencia de las TI aérea. Dos enormes cortes, con un par de semanas de diferencia -causados por fallas de componentes simples- dieron como resultado interrupciones masivas de pasajeros y millones de dólares en ingresos perdidos y compensación a los clientes de las aerolíneas.

Estos eventos, que de hecho fueron más dolorosos para quienes los experimentaron, presentan un buen número de oportunidades para el aprendizaje y la mejora de nuestros propios procesos, y eso es lo que me gustaría explorar en este artículo.

En primer lugar, un poco de historia. Lo que terminó siendo un router defectuoso hizo caer todas las operaciones de Southwest Airlines por un día el 21 de julio, y causó efectos ondulantes durante varios días después de la interrupción inicial. (Un hecho que podría sorprender es que Southwest es por un amplio margen el mayor proveedor de servicios nacional de pasajeros en los Estados Unidos.) The Dallas Morning News informó de las consecuencias.

"El corte se produjo a principios de la tarde del miércoles después que un router de red fallara y que los sistemas de copia de seguridad no hicieran su trabajo", informó el periódico. "A pesar de que el corte se reparó aproximadamente 12 horas más tarde, la magnitud de la perturbación causó estragos en las operaciones de Southwest para los próximos días, a medida que la aerolínea con sede en Dallas trabajó para saber dónde se suponía que estaban los aviones, tripulaciones y pasajeros". En total, la aerolínea dijo que canceló cerca de 2.300 vuelos, o alrededor del 11% del total que habría operado en ese tiempo.

(La línea de "sistemas de copia de seguridad falló en ejecutarse", sonará familiar a los clientes de Amazon Web Servers, ya que un fracaso similar de los sistemas de copia de seguridad se produjo en gran parte de la nube de alojamiento de operaciones de Amazon en el 2011 y realmente impulsó el proceso de utilización de las zonas de disponibilidad de Amazon y otras características de tolerancia a fallas entre los clientes de la nube).

Luego, un par de semanas más tarde, el 8 de agosto, fue el turno de Delta Air Lines en la rueda de las interrupciones de TI, con cientos de vuelos cancelados y retrasados durante la mitad de su exigente temporada de viajes de verano [septentrional], debido a una falla de los componentes eléctricos. El Wall Street Journal reportó la historia así: "Un problema eléctrico en su sede de Atlanta se produjo a las 2:30 am ET y la aerolínea se vio obligado a contener cientos de aviones en tierra partir de las 5 de la mañana, de acuerdo con Ed Bastian, el gerente general, quien se disculpó con los clientes en un video. los problemas técnicos probablemente tendrán un costo de millones de dólares en ingresos perdidos, y dañará su reputación bien ganada como la más confiable de los principales operadores internacionales con sede en los Estados Unidos, después de haber cancelado solo un puñado de vuelos en el último trimestre".

Al parecer, el problema de tecnología subyacente en el corte de Delta fue una caja de distribución -esencialmente una caja de fusibles gigante que potencia las rutas de entrada y salida de una instalación- que falló en la sede de Delta, de acuerdo con Georgia Power, la utilidad pública que suministra electricidad al lugar en cuestión. Lo que no está claro es por qué un corte que se produjo a las 2:30 de la mañana no fue capaz de resolverse a tiempo para vuelos que comienzan a ser despachados a las 5:00 de la mañana, ni por qué los retrasos y cancelaciones en cascada desde las 5:00 am no fueron menos graves, o por qué no pudieron ser rectificados con mayor rapidez.

¿Qué significa todo esto?

Los cortes de Delta y Southwest muestran cómo una sola falla de TI en el lugar y momento equivocados -aún incluso después de todos estos años de planificación y de hablar de la importancia de la recuperación de desastres- puede costar millones de forma rápida, incluso en el transcurso de pocas horas.

Hemos tenido décadas de opciones de alta disponibilidad: Diferentes metodologías, ya sea escalar con hardware redundante más robusto o con cajas de materias primas más baratas, y opciones de conmutación por error para Windows y Linux que mueven las operaciones a través de geografías en cuestión de milisegundos, y ahora incluso la infraestructura como posibilidades de servicio en el que solo se ejecutan las operaciones de copia de seguridad en algún otro centro de datos cuando es necesario.

Todas estas opciones han reducido en el costo también. En donde solía necesitar asignaciones presupuestarias de millones para construir cualquier tipo de capacidad de conmutación por error, ahora puede ser tan simple como la compra de servicios por valor de tiempo de ejecución de unas horas con una tarjeta de crédito. (Eso es ciertamente demasiado simplista para una línea aérea de mil millones de dólares, pero la mayoría de nosotros no ejecutamos operaciones millonarias como las de las aerolíneas).

Un principio importante que creo que muchas personas pierden cuando comienzan la planificación para la continuidad del negocio y su infraestructura: Si su negocio depende de TI en cualquier sentido para su funcionamiento normal, entonces debe hacer una planificación de alta disponibilidad (e idealmente continua). Mucha gente piensa que la recuperación de desastres y la alta disponibilidad son la misma cosa, son objetivos comunes, y tienen el mismo valor para las organizaciones. Creo que hoy en día es una impresión equivocada.

La recuperación de desastres es el modo en el que se entra cuando el funcionamiento de la tecnología ha bajado de alguna manera, ya sea una falla técnica o de la madre naturaleza que afecte su centro de datos. Describe los procesos y procedimientos (y la infraestructura necesaria) que necesitaría para reconstruir las cosas y volver a un funcionamiento normal. Durante todo el tiempo que su plan de recuperación de desastres se está llevando a cabo, sus activos de TI no están en línea, lo que significa que su negocio no está sirviendo a los clientes y no está avanzando.

La alta disponibilidad, por el contrario, prevé un tiempo de inactividad mediante la adición de hardware y software que compensen para estar siempre en línea, listos para estar "recuperados". Aunque quizás la carga completa de su sistema no se pueda llevar adelante, las operaciones esenciales para su negocio de hecho pueden seguir circulando, debido a que su tecnología está disponible -quizás degradada, tal vez no, pero por lo menos, disponible.

Esto no quiere decir que no tenga sentido hacer planes para la recuperación de desastres. Después de todo, hay algunas situaciones que, a pesar de toda su planificación, anticipación y una cuidadosa reflexión, no será capaz de prever. Pero creo que lo mejor es tratar de eliminar el tiempo de inactividad, no planear cómo volver de ello.

Consejos útiles para conseguir alta disponibilidad

¿Por qué la alta disponibilidad es el objetivo más importante? Casi siempre hay menos interrupciones en su operación sobre una base reducida, que tener su tecnología totalmente fuera de línea. Tal vez no pueda servir a cada cliente de forma normal durante el corte, pero al menos, al tener la capacidad de tener funciones críticas ejecutándose completamente, puede permitirle activar los procesos manuales o alternos para mover el negocio de forma global.

En el caso de Delta Air Lines, esta última interrupción impedía que algunos planes de vuelo sean presentados ante la FAA, que esencialmente significaba que los aviones no podían salir, incluso si todos los demás procesos hubieran funcionado de forma automática o manual. Si el software de envío de plan de vuelo hubiera estado disponible, incluso a una capacidad reducida, entonces, los vuelos críticos con la mayor cantidad de pasajeros o los vuelos que hubieran alcanzado los lugares adecuados podrían haber sido enviados, y muchos menos clientes se habrían visto afectados negativamente por el corte.

Para tener en cuenta: Averigüe qué problemas de "compuerta" tiene -puntos críticos en el proceso que deben repararse o caería todo- y asegúrese de tener copias de seguridad secundarias y terciarias de esos puntos, así como un plan para ponerlos en línea en el caso de que falle el principal.

Al planificar la alta disponibilidad, la redundancia geográfica es también una preocupación. La única conclusión que podemos sacar de forma segura desde el corte de Delta, es que toda la infraestructura crítica de la línea aérea dependía de alguna pieza de hardware o software que se ejecutaba en el interior del edificio de la sede de Delta en Atlanta, que fue afectada por el corte. Incluso, si el sistema de servicio de pasajeros o las operaciones de software de Delta hubieran estado alojados en otros lugares, según lo han señalado algunos informes noticiosos, es evidente que alguna aplicación que se ejecuta en un armario de servidor o alguna pieza de hardware en el centro de datos de ese edificio fue en realidad el único punto de falla en la aerolínea.

Una de las lecciones más básicas de la planificación de disponibilidad es que cualquiera de los puntos críticos de falla necesita duplicar copias o versiones disponibles, preferentemente en un lugar lejos del otro nodo operativo, por lo que las fallas locales como problemas de electricidad o perturbaciones meteorológicas no afectan la operación del nodo de copia de seguridad.

Tenga en cuenta: Aunque la planificación de desastres ha avanzado mucho, todavía no puede ignorar el hecho de que debe tener sistemas de copia de seguridad en un lugar lejos de sus sistemas primarios.

Por último, es crítico hacerles pruebas a sus protocolos de conmutación por error, ya que no siempre funcionan cuando se quiere que trabajen. Los cortes de Delta y Southwest comparten algo en común: Las copias de seguridad y el respaldo ante las fallas no se encendieron cuando se les necesitó.

El New York Times informó: "En el caso de Southwest, un sistema de copia de seguridad estaba en su lugar, pero la aerolínea dijo que el sistema no se activó como debería cuando el router falló. Y Delta dijo que estaba investigando por qué algunas de sus propias operaciones críticas no activaron los sistemas de copia de seguridad". Toda la inversión en la recuperación de desastres y alta disponibilidad en el mundo no le ayudará si esas inversiones no se activan cuando es necesario.

Tenga en cuenta: Pruebe su conmutación por error de forma rigurosa y coherente. Elija las horas pico para la mayoría de las pruebas, pero también realice pruebas de esfuerzo de su plan durante un día lento, pero normal, y tenga en cuenta que las fallas que se producen para su posterior investigación y remediación.

¿La nube habría ayudado?

Los fanáticos de la nube han salido de la nada después de estos cortes. "Vea lo que sucede cuando deja las cosas en las instalaciones de la empresa" dicen. "Esto nunca habría sucedido si estuvieran usando Amazon Web Services o Microsoft Azure", señala. Pero ¿es este el caso?

Sí y no. La nube es un concepto de múltiples capas. ¿Cuándo se dice nube, se habla de máquinas virtuales que se ejecutan en otros lugares? ¿De una aplicación web completamente gestionada que recibe la tolerancia a fallas y la disponibilidad, ya que la plataforma se encarga de todo eso? ¿Se está hablando de una conmutación por error a un centro de datos en la nube que es esencialmente una nube privada alojada en otro lugar? Uno tiene que ser específico acerca de lo que significa "nube" en cualquier escenario dado.

Pero tomemos un vistazo más cercano. ¿Podría portar, por ejemplo, el sistema de reservas Sabre a AWS? No. ¿Podría ejecutar programas de ejecución de vuelos como una aplicación web en Azure? Tal vez, sí. ¿Puede ejecutar toda una línea aérea desde la nube de Google? Sin lugar a dudas no. ¿Pero las piezas fundamentales -los "puntos de compuerta" de los que hablamos anteriormente- se encuentran en la nube? Pienso que sí.

Es indiscutible el hecho de que las compañías aéreas tienen operaciones muy complejas, lo cual puede hacer un argumento creíble de que no hay ninguna operación que dependa más de las piezas y partes que llegan justo a tiempo en los lugares adecuados, por lo que incluso las fallas más leves debido a una tormenta eléctrica en un aeropuerto determinado, pueden tener enormes consecuencias para los clientes. Y en este artículo no estoy de ninguna manera tratando de decir que tengo mejores conocimientos que los directores técnicos de las aerolíneas, o que conozco sobre si esta línea aérea está invirtiendo o no en las tecnologías de nube. No tengo ningún conocimiento especial o privilegiado sobre las inversiones de TI en las aerolíneas, y tampoco son mis clientes.

Lo que estoy diciendo, sin embargo, es que el resto de nosotros puede aprender de la observación de las causas y efectos de estos cortes. Y parece que, en estos dos casos, ambas aerolíneas podrían haber puesto los aviones en el aire y movilizar a los clientes si hubieran tenido sistemas alternativos -que podría muy bien estar en la nube- de una manera oportuna. No, esto no habría resuelto el problema técnico subyacente, y no, no habría sido una solución fluida o ideal. Pero tampoco es lo que realmente ocurrió -miles de clientes varados, vacaciones en ruinas y una espiral de costos del pago de las reclamaciones por daños al cliente.

Jonathan Hassell es el director de 82 Ventures, una firma de consultoría con sede en Charlotte, Carolina del Norte.