¿La filosofía DevOps “construir para fallar” es un riesgo para la seguridad?

Rompiendo la ley de los titulares de Betteridge , la respuesta corta es sí. Pero como ocurre con todas las cosas que hoy en día tienen que ver con la tecnología, la respuesta larga es un poco más compleja que eso.

Creo que DevOps se ha vuelto bastante omnipresente en todas las industrias. Si bien no todas las organizaciones adoptan todos los aspectos de este enfoque ni aplican el mismo ferviente apego a sus principios como, por ejemplo, Netflix, definitivamente es algo que está sucediendo.

Si bien no es una prueba directa, cuando preguntamos a más de 3000 encuestados cómo la transformación digital estaba afectando sus decisiones de aplicação para nuestro Estado de entrega de aplicação 2018, dos de las tres respuestas principales fueron "emplear automatización y orquestación en sistemas y procesos de TI" y "cambiar la forma en que desarrollamos aplicações (por ejemplo, pasando a ágil)". Para mí, ambas son reacciones inferidas a la adopción de al menos partes de un enfoque DevOps para desarrollar y entregar aplicações en arquitecturas modernas.

Entonces, si las organizaciones están adoptando algunas de las herramientas y técnicas relacionadas con DevOps, se podría suponer que también están adoptando otras. Una de ellas podría ser (con música dramática): construir para fracasar.

Ahora bien, esa frase es un tanto imprecisa, ya que nadie se sienta a diseñar sistemas que fracasen. Lo que sí hacen, sin embargo, es diseñar sistemas que sean resistentes a los fallos. Esto significa, por ejemplo, que si una instancia (servidor) falla, el sistema debería ser capaz de manejar automáticamente la situación eliminando la instancia muerta e iniciando una nueva para ocupar su lugar.

¡Listo! Construido para fallar.

Y si bien esta es ciertamente una reacción deseable, en particular cuando un sistema está sometido a una gran carga y demanda, existe un riesgo en el enfoque que debe considerarse y, se espera, abordarse posteriormente.

Pensemos en la vulnerabilidad de Cloudflare de principios de 2017 . Cloudflare, que ha sido admirablemente transparente en sus propios informes del problema, señala que, básicamente, el problema fue una pérdida de memoria (que resultó en una posible pérdida de datos) causada por un defecto en una extensión de un analizador HTTP. En pocas palabras, un error provocó una pérdida de memoria que provocó que las instancias fallaran. Esas instancias fueron eliminadas y reiniciadas porque fueron diseñadas para fallar.    

Para que quede constancia, esta no es una publicación para 'criticar a Cloudflare por un error'. Como desarrollador, me siento muy comprensivo con que mis defectos se expongan de forma tan pública. Soy menos comprensivo en situaciones en las que hay poca consideración por descubrir por qué algo falla, pierde memoria o simplemente falla por completo.

Y ese es el objetivo del post de hoy. Porque a veces la filosofía DevOps deja a sus seguidores con un enfoque de laissez-faire para la investigación posterior a un fallo.

Es perfectamente razonable reaccionar ante una falla de un servicio o aplicación cerrando y reiniciando el servicio para garantizar la disponibilidad, siempre y cuando luego investigues la falla para determinar qué la causó. Las aplicaciones no se bloquean sin motivo alguno. Si se cayó, algo lo empujó. Nueve de cada diez veces, es como un error no explotable. No hay nada sobre lo que escribir una entrada de blog. Pero la única vez que se trata de una vulnerabilidad grave esperando ser explotada hace que valga la pena el esfuerzo aparentemente desperdiciado en las otras nueve. Porque eso es algo sobre lo que se podría escribir una entrada de blog.

No es razonable ignorarlo.

El monitoreo y la alerta sobre fallas y otros problemas también es un componente clave de un programa DevOps integral. Esa es la “S” en los CAMS que conforman un enfoque holístico de DevOps: Cultura, automatización, medición y compartición. Damon y John (quienes acuñaron el acrónimo en 2010) no solo hablaban de pizza y cerveza (aunque esa es una buena manera de fomentar la “C” de Cultura de DevOps). También se trata de datos y del estado de los sistemas. Se trata de garantizar que quienes pueden beneficiarse del conocimiento, lo sepan. Y eso incluye un fallo en el sistema.

Un fallo, especialmente un accidente, no debe pasar desapercibido. Si falla un sistema en proceso de desarrollo, alguien debería saberlo y alguien debería comprobarlo. Ignorarlo es un riesgo de seguridad. Peor aún, es un riesgo evitable porque se trata de su entorno, de sus sistemas y de su código. Tienes el control total, por lo que no tienes excusa para ignorarlo.

Así que sí, en pocas palabras, “crear para fallar” puede exponer sus aplicaciones y su negocio a riesgos de seguridad. La buena noticia es que esos riesgos son completamente manejables, si nos aseguramos de que la filosofía no esté en el papel como "diseñada para fallar" pero en la práctica termine siendo "diseñada para ignorar un fracaso".

Preste atención a las cosas que fallan, incluso si las reinicia para mantener una alta disponibilidad. Puede salvarse usted mismo (y a su negocio) de ser tendencia en Twitter por las razones equivocadas.