Lo que la arquitectura puede enseñarnos sobre los sistemas de autorreparación

Reeditado por Platón

seguidores: 0

Los equipos de DevOps y los ingenieros de confiabilidad del sitio (SRE) se ocupan del código a diario. Hacerlo les enseña a escudriñar su mundo, hacer observaciones astutas y establecer conexiones inesperadas. Después de todo, aunque de naturaleza altamente lógica y matemática, el desarrollo de software es, al menos en parte, una forma de arte.

¿No te convence esa afirmación? Considere los paralelismos entre las hazañas arquitectónicas más notables de la historia y la ingeniería de software moderna. Es una comparación adecuada: al igual que la ingeniería de software, la arquitectura emplea cálculos matemáticos complejos para crear algo hermoso. Y en ambas disciplinas, un ligero error de cálculo puede tener importantes consecuencias. Curiosamente, muchos errores arquitectónicos famosos son análogos a los problemas que encontramos en el código.

Recuerda, la inspiración está en todas partes, siempre y cuando sepas dónde buscar. Aquí hay algunas lecciones que los ingenieros de software pueden aprender de las epifanías arquitectónicas a lo largo de los siglos, especialmente con respecto al futuro de los sistemas de autorreparación.

Lección 1: Los casos extremos siempre aprovecharán las vulnerabilidades del sistema

Citicorp Tower, ahora llamada 601 Lexington, terminó su construcción en la ciudad de Nueva York en 1977, momento en el que era el séptimo edificio más alto del mundo. El diseño de vanguardia del rascacielos incluía tres pilotes de más de 100 pies. Fue una maravilla al terminar. Sin embargo, un estudiante universitario pronto descubrió algo discordante: fuertes vientos podría poner en peligro la integridad del edificio. Específicamente, si fuertes vientos acuartelados golpeaban las esquinas de Citicorp Tower, la estructura estaba sujeta a colapso, un literal caso de borde.

La torre tenía una posibilidad entre 16 de colapsar cada año. Estas probabilidades pueden atraer a alguien sentado en una mesa de juego, pero el panorama era sombrío para los arquitectos e ingenieros estructurales detrás de Citicorp Tower. Afortunadamente, los técnicos pudieron reforzar las uniones atornilladas del edificio. Se evitó el desastre.

Los ingenieros estructurales sabían que Citicorp Tower eventualmente enfrentaría un viento lo suficientemente fuerte como para comprometer sus rodamientos. Del mismo modo, los ingenieros de software experimentados saben que la supervisión sólida del rendimiento de las aplicaciones (APM) y la gestión de eventos no son suficientes para proteger un sistema de los casos extremos inevitables. Esto se debe a que los sistemas estáticos sin aprendizaje automático (ML) las capacidades no pueden manejar nuevas situaciones inesperadas y no planificadas, como vientos fuertes. Cuando se confía únicamente en las herramientas de monitoreo, un administrador humano debe descifrar los errores y escalar el proceso de gestión de incidentes.

Para reducir el tiempo medio de recuperación (MTTR)/tiempo medio de detección (MTTD), los equipos de DevOps deben aceptar la alta probabilidad de casos extremos y trabajar para implementar soluciones de autoaprendizaje de forma preventiva. Esta lección es muy útil, ya que la previsión es fundamental en la ingeniería.

Lección 2: "Construir el avión mientras vuela" crea un ciclo interminable

Acontecimientos trágicos han dejado varios de las lecciones más importantes de la historia de la aviación. Cuando un avión sufrió una inmensa descompresión en pleno vuelo y se estrelló en 1954, los ingenieros determinaron que las ventanas cuadradas de los pasajeros eran un punto de estrés innecesario. De ahora en adelante, los aviones estaban equipados con ventanas redondeadas. Los incendios a bordo llevaron a nuevos arreglos de asientos que priorizaron la facilidad de evacuación. Estos cambios han salvado innumerables vidas.

En muchas industrias, incluida la aviación, no hay forma de realizar una prueba de estrés exhaustiva de un producto. Como se mencionó anteriormente, los casos extremos son inevitables. La conclusión más importante aquí es que los ingenieros de software deben prestar atención a las vulnerabilidades de su sistema cuando se presentan. A partir de ahí, deben abordarlos de manera expedita. Hacer eso requiere dos cosas: (1) identificar y rastrear los indicadores clave de rendimiento (KPI) correctos y (2) invertir tiempo y recursos para mejorar los sistemas basados en métricas relevantes.

El equipo de ingeniería promedio invierte en 16 a 40 herramientas de monitoreo, pero a menudo pierden la marca sobre qué métricas demuestran el éxito. Menos del 15 % de los equipos rastrean el MTTD, por lo que pierden el 66 % del ciclo de vida del incidente. Y una cuarta parte de los equipos informan Faltan sus acuerdos de nivel de servicio (SLA) a pesar de la inversión significativa en el seguimiento de la disponibilidad. Esto nos dice que la recopilación de datos necesita un análisis minucioso y sistemático para cortarlo: las soluciones puntuales ya no son suficientes.

Los ingenieros de software, los equipos de DevOps y los SRE deben priorizar los procesos y las herramientas que extraen valor de cantidades abrumadoras de información sobre disponibilidad. En lugar de simplemente observar un error crítico, deben tomar una página del libro de un ingeniero de aviación y tomar decisiones críticas rápidamente. El secreto para hacerlo radica en la IA.

Lección 3: La IA es un componente fundamental para los sistemas de autorreparación

Un sistema de autorreparación completamente autónomo y perfectamente funcional es ideal para cualquier ingeniero de software. Los sistemas que se parchean solos son buenos para la satisfacción del cliente, ya que eliminan el costoso tiempo de inactividad que enfrentan los consumidores. Además, son increíblemente beneficiosos para las funciones de gestión de servicios de TI (ITSM), ya que reducen significativamente la necesidad de la tediosa gestión de tickets. La construcción de un sistema de este tipo requiere varios componentes, muchos de los cuales están actualmente fuera de alcance. Pero estamos más cerca de una realidad de autocuración de lo que algunos pueden darse cuenta.

La falta de adopción generalizada de IA sigue siendo el mayor obstáculo al que se enfrentan los sistemas de recuperación automática en la actualidad. Aunque muchas empresas han adoptado herramientas rudimentarias basadas en IA o ML, la integridad de estas herramientas es cuestionable. Es decir, muchos ingenieros se ocupan de inteligencia artificial para operaciones de TI (AIOps) tecnologías que siguen una lógica de automatización basada en reglas en lugar de algoritmos de IA autónomos. La distinción puede parecer diminuta, pero en la práctica, es la diferencia entre horas de productividad perdida y millones en posibles pérdidas.

La cuestión es que las herramientas AIOps basadas en reglas analizan las interacciones entre soluciones puntuales dispares y probablemente pueden identificar errores de datos comunes. Pero los sistemas basados en la automatización no pueden procesar la evolución de errores completamente nuevos a lo largo del tiempo, ni pueden predecir fallas novedosas en los datos. Esto se debe a que los administradores humanos que codifican estas funciones le piden al sistema que siga un si esto, entonces aquello patrón lógico. Las herramientas AIOps genuinamente eficientes mitigan los errores que surgen en los cuatro puntos de telemetría clásicos, desde la detección hasta la resolución, al clasificar patrones nuevos y problemáticos antes de que los técnicos humanos se den cuenta de su existencia.

Mientras esperamos la Tercera ola inminente de IA, esta versión de AIOps es lo más cercano que tenemos a los sistemas de recuperación automática. Será interesante hacer un seguimiento de cómo las aplicaciones AIOps actuales se introducen en el futuro de la IA, que incluirá la automatización completamente realizada y las posibilidades de pensamiento independiente. Tal vez entonces los ingenieros estructurales también obtengan las recompensas de un sistema de autorreparación basado en IA.