Quienes han trabajado en TI durante mucho tiempo seguro han visto esto: la principal aplicación de misión crítica, creada especialmente para estar siempre disponible, deja de funcionar y no hay poder humano que la eche andar, aunque haya una gran cantidad de costosos respaldos y protecciones. Las razones por las que este tipo de falla “imposible” ocurre son amplias y variadas, pero al final se llega a dos factores importantes que por lo general van de la mano: la complejidad y el error humano.
La complejidad está en todas partes
La complejidad de incluso las redes más pequeñas de hoy hace palidecer a la de las empresas de ayer. Si bien nos llama la atención la virtualización de servidores, la migración de máquinas virtuales, la replicación, las redes convergentes y todas las tecnologías relativamente nuevas, implementarlas tiene un costo que muchos tienden a ignorar.
Antes, la funcionalidad de una sola aplicación dependía sólo de su hardware interno y de que la red funcionara adecuadamente. Hoy, esa dependencia incluye a un grupo de dispositivos de almacenamiento centralizado junto con su creciente base de código de software, un hipervisor de virtualización con toda su funcionalidad y una arquitectura de red más elaborada que lo soporta.
Deberíamos alegrarnos de todo eso: mantener decenas o centenas de servidores independientes cada uno con su propio software y hardware de almacenamiento era una gran pérdida de tiempo. La complejidad es sólo resultado del progreso, pero tiene un costo.
Cada vez que usted se pregunta “¿y ahora qué está pasando?”, básicamente está pagando ese costo. Las soluciones que implementamos son mucho más complicadas que ninguno de nosotros podemos realmente entenderlas completamente. Si usted ha pasado algunas horas escudriñando una pila de archivos de registro para averiguar por qué algo que debería funcionar no lo está haciendo, sabe exactamente a lo que me refiero.
Tal vez parcialmente como resultado de esa complejidad, pero también debido a la cada vez mayor dependencia de las empresas modernas de la tecnología para funcionar, mantener la alta disponibilidad se ha vuelto cada vez más crítico en los departamentos de TI de todos los tamaños. Hace quince años, muchas empresas veían a la falla de una aplicación importante durante 24 horas como algo incómodo, pero no desastroso. Cuando hoy ocurre una caída de esa magnitud, ruedan cabezas.
Tener todo funcionando a punto requiere mucha redundancia: clusters, replicación y sitios alternos, por mencionar algunas soluciones populares. Si bien estos sistemas normalmente cumplen con sus objetivos si son diseñados, implementados y mantenidos adecuadamente, lo que realmente significan es que: “Nuestros sistemas son demasiado complejos y podrían fallar, así que vamos a agregar otro nivel de complejidad para resolver eso”. Suena tonto dicho así, pero ese es exactamente lo que hacemos. Y funciona… la mayor parte del tiempo.
El elemento humano
Si se sometiera a cada falla importante de TI bajo el mismo escrutinio que aplica la NTSB (National Transportation Safety Board) a los accidentes aéreos, vería usted el error humano como el único factor o un factor decisivo en cada uno de ellos. Así como TI se trata de racks de equipo, cables, líneas de telecomunicaciones y software, se trata más de la gente que diseña, crea y opera todas esas cosas.
Diseño de productos. El desfile de errores humanos comienza antes de que su nuevo equipo entre por la puerta. Este no es un fenómeno nuevo. Todos probablemente han tenido que lidiar con equipo que se muere porque no fue ensamblado correctamente o incluía componentes defectuosos.
Aunque hoy la complejidad presente en los sistemas que usamos se deriva en tipos de fallas mucho más insidiosas. Por ejemplo, un proveedor de SAN bastante conocido liberó recientemente nuevo software para su principal producto de almacenamiento. El software soportaba varias funcionalidades avanzadas, y era una versión atractiva, hasta que comenzó a tirar los arrays y ocasionalmente dejar salir datos de los clientes.
Si bien no se sabe con exactitud cuál fue el problema, puede apostar a que probablemente no se hicieron las suficientes pruebas de regresión. Ya que las soluciones que estos proveedores son cada vez más complejas, los desafíos de probarlas en todos los escenarios en los que los clientes las usarán se vuelve cada vez más complicado. Eso no quiere decir que no tengan la culpa de la falla, pero se ha convertido en el status quo esperar que el nuevo software rompa algo. Eso es triste, pero es a lo que nos enfrentamos.
Antes, si usted tenía un dispositivo de almacenamiento centralizado hecho por una compañía confiable que fallaba, podría haber sido una tarjeta o una unidad frita, tenía a los técnicos de soporte bien equipados arreglándolo de inmediato. Hoy, el técnico de soporte que no se sorprende de su problema está al otro lado de la línea tratando de averiguar cuál de las deficiencias del software le ha provocado el problema.
Implementación. Finalmente, no importa qué tan bueno es el producto: si no se implementa correctamente, es probable que no funcione o que lo haga de forma muy deficiente. La complejidad eleva la probabilidad de que la implementación sea incorrecta. Por suerte, con las pruebas adecuadas, puede identificarse la mayoría de los errores de implementación antes de que los sistemas entren en producción. Si no se realiza la prueba de aceptación adecuada, surgirá el peor de estos problemas cuando los sistemas estén bajo carga.
Mantenimiento y pruebas. La falta de mantenimiento y las pruebas adecuadas son los dos factores más grandes que contribuyan a las caídas de todo tipo. Las razones de por qué esto es cierto deben ser obvias para todos los que trabajan en TI: a todos se nos está pidiendo hacer más con menos recursos.
Honestamente no puedo recordar la última vez que vi un departamento de TI donde un empleado no tuviera suficiente trabajo que hacer para justificar su empleo. Normalmente es lo opuesto: el negocio pide nueva funcionalidad más rápido de lo que TI puede ofrecerla, así que el mantenimiento regular y los niveles adecuados de prueba se dejan a un lado.
Qué se puede hacer
Si usted no tiene nada más qué hacer, realice pruebas. Pruebe todo tan frecuentemente como pueda. Pruebe los respaldos, los clusters, los switches redundantes; pruebe todo en lo que haya invertido mucho dinero para estar prevenido si algo falla. Asegúrese de hacer pruebas bajo circunstancias fuera de lo común – no se asegure de que todo esté trabajando correctamente antes de hacer las pruebas porque no tendrá ese lujo en una escenario real. No cierre las cosas limpiamente, desconecte el cable. Suponga que si usted no ha probado algo en los últimos tres meses o desde que se hicieron cambios importantes a la arquitectura, simplemente no funcionará como se supone que lo haría.
Si usted le pide a la administración de su empresa el tiempo necesario para hacer las pruebas y se lo niegan por cualquier razón, deje claro que no puede garantizar que los sistemas de failover funcionarán adecuadamente en caso de una falla. Esto no lo hará popular. Pero, créame, es mucho mejor a que le señalen la puerta porque el sistema de failover del que usted es responsable no funcionó.
