¿Supone un riesgo para la seguridad la filosofía de DevOps de «crear para fallar»?

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Contraviniendo la ley de los titulares de Betteridge, la respuesta corta es sí. Pero, como ocurre hoy en día con todo lo relacionado con la tecnología, la respuesta larga es algo más compleja.

Creo que DevOps se ha generalizado bastante en todos los sectores. Aunque no todas las organizaciones adoptan todos los aspectos de este enfoque ni se adhieren a sus principios con el mismo fervor que, por ejemplo, Netflix, no cabe duda de que es una tendencia real.

Aunque no constituye una prueba directa, cuando preguntamos a los más de 3000 encuestados cómo estaba influyendo la transformación digital en sus decisiones sobre las aplicaciones para nuestro informe State of Application Delivery 2018, dos de las tres respuestas principales fueron «aplicar la automatización y la orquestación a los sistemas y procesos de TI» y «cambiar la forma en que desarrollamos aplicaciones (por ejemplo, adoptando metodologías ágiles)». En mi opinión, ambas son reacciones implícitas a la adopción de, al menos, algunos aspectos de un enfoque DevOps para desarrollar y entregar aplicaciones en arquitecturas modernas.

Así pues, si las organizaciones están adoptando algunas de las herramientas y técnicas relacionadas con DevOps, cabe suponer que también están adoptando otras. Una de ellas podría ser incluso (suena música dramática): diseñar para el fallo.

Ahora bien, esa expresión es un tanto imprecisa, ya que nadie se dedica a diseñar sistemas para que fallen. Sin embargo, lo que sí se hace es diseñar sistemas que sean resilientes ante los fallos. Esto significa, por ejemplo, que si una instancia (servidor) deja de funcionar, el sistema debería poder gestionar automáticamente la situación eliminando la instancia inactiva e iniciando otra nueva que la sustituya.

¡Voilà! Diseñado para fallar.

Y aunque esta es sin duda una reacción deseable —especialmente cuando un sistema está sometido a una carga y una demanda elevadas—, este enfoque conlleva un riesgo que debe tenerse en cuenta y, cabe esperar, abordarse posteriormente.

Pensemos en la vulnerabilidad de Cloudflare de principios de 2017. Cloudflare —que ha sido admirablemente transparente al informar sobre el problema— señala que, en esencia, se trató de una fuga de memoria (que podía provocar una posible filtración de datos) causada por un defecto en una extensión de un analizador HTTP. En pocas palabras, el error provocó una fuga de memoria que hizo que las instancias fallaran. Esas instancias se cerraron y reiniciaron porque estaban diseñadas para fallar.

Que conste que esta publicación no pretende «arremeter contra Cloudflare por un error». Como desarrollador, comprendo perfectamente lo que supone que los fallos de uno queden expuestos de forma tan pública. Soy menos comprensivo cuando apenas hay interés por averiguar por qué algo se bloquea, tiene fugas de memoria o, sencillamente, falla por completo.

Y ese es precisamente el tema de la publicación de hoy. Porque, a veces, la filosofía DevOps lleva a sus adeptos a adoptar una actitud de laissez-faire ante la investigación posterior a un fallo.

Es perfectamente razonable reaccionar ante el fallo de un servicio o una aplicación deteniéndolo y reiniciándolo para garantizar su disponibilidad, siempre y cuando después se investigue el fallo para determinar qué lo causó. Las aplicaciones no fallan sin motivo. Si una se cae, es porque algo la ha hecho caer. Nueve de cada diez veces se trata de un error que no se puede aprovechar. Nada sobre lo que escribir una entrada de blog. Pero esa única vez en que se trata de una vulnerabilidad grave a la espera de ser explotada hace que merezca la pena el esfuerzo aparentemente desperdiciado en las otras nueve. Porque eso sí da para escribir una entrada de blog.

No es razonable ignorarlo.

La supervisión y las alertas sobre fallos y otros problemas también son un componente clave de un programa de DevOps completo. Esa es la «S» de CAMS, los pilares de un enfoque integral de DevOps: cultura, automatización, medición e intercambio de conocimientos. Damon y John (quienes acuñaron el acrónimo en 2010) no se referían únicamente a la pizza y la cerveza (aunque son una buena forma de fomentar la «C» de cultura de DevOps). También se trata de los datos y del estado de los sistemas. Se trata de garantizar que quienes puedan beneficiarse de la información estén al tanto. Y eso incluye los fallos del sistema.

Un fallo —especialmente un bloqueo— no debe pasar inadvertido. Si un sistema de la canalización se bloquea, alguien debe saberlo y encargarse de investigarlo. Ignorarlo supone un riesgo para la seguridad. Y lo que es peor, es un riesgo evitable porque se trata de tu entorno, tus sistemas y tu código. Tienes el control absoluto y, por tanto, no hay excusa para ignorarlo.

Así que sí, en pocas palabras, «diseñar para fallar» puede exponer tus aplicaciones —y tu empresa— a riesgos de seguridad. La buena noticia es que esos riesgos son totalmente gestionables, siempre que te asegures de que esa filosofía no figure sobre el papel como «diseñado para fallar», pero en la práctica acabe siendo «diseñado para ignorar los fallos».

Presta atención a los elementos que fallan, aunque los reinicies para mantener una alta disponibilidad. Puede que así evites que tú (y tu empresa) seáis tendencia en Twitter por los motivos equivocados.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie