CrowdStrike lanzó un parche relativamente menor el viernes y, de alguna manera, causó estragos en grandes sectores del mundo de las TI que utilizan Microsoft Windows, provocando la caída de aeropuertos, centros de salud y centros de llamadas al 911. Si bien sabemos que una actualización defectuosa causó el problema, no sabemos cómo se lanzó en primer lugar. Es muy probable que una empresa como CrowdStrike tenga un sofisticado sistema de desarrollo y operaciones con políticas de lanzamiento establecidas, pero incluso con eso, el código defectuoso se coló de alguna manera. En este caso, tal vez fue la madre de todos los códigos defectuosos. La empresa ha sufrido un fuerte golpe a su reputación y el precio de las acciones se desplomó de $ 345,10 el jueves por la noche a $ 263,10 el lunes por la tarde. Desde entonces se ha recuperado ligeramente. En una declaración del viernes, la empresa reconoció las consecuencias de la actualización defectuosa: «Todos en CrowdStrike comprenden la gravedad y el impacto de la situación. Identificamos rápidamente el problema e implementamos una solución, lo que nos permitió concentrarnos diligentemente en restaurar los sistemas de los clientes como nuestra máxima prioridad». Además, explicó la causa raíz de la interrupción, aunque no cómo sucedió. Ese es un proceso post mortem que probablemente continuará dentro de la empresa durante algún tiempo, ya que busca evitar que algo así vuelva a suceder. Dan Rogers, director ejecutivo de LaunchDarkly, una empresa que utiliza un concepto llamado indicadores de características para implementar software de una manera altamente controlada, no pudo hablar directamente sobre el problema de implementación de CrowdStrike, pero sí pudo hablar sobre los problemas de implementación de software de manera más amplia. «Los errores de software ocurren, pero la mayoría de los problemas de experiencia de software que alguien experimentaría en realidad no se deben a problemas de infraestructura», dijo a TechCrunch. «Se deben a que alguien implementó un software que no funciona, y esos en general son muy controlables». Con los indicadores de características, puede controlar la velocidad de implementación de nuevas características y desactivar una característica, si las cosas van mal para evitar que el problema se propague ampliamente. Sin embargo, es importante señalar que, en este caso, el problema estaba en el nivel del núcleo del sistema operativo, y una vez que se descontrola, es más difícil de solucionar que, por ejemplo, una aplicación web. Sin embargo, una implementación más lenta podría haber alertado a la empresa del problema mucho antes. Lo que sucedió en CrowdStrike podría sucederle potencialmente a cualquier empresa de software, incluso a una que tenga buenas prácticas de lanzamiento de software, dijo Jyoti Bansal, fundador y CEO de Harness Labs, un fabricante de herramientas para desarrolladores de canalización DevOps. Si bien tampoco pudo decir con precisión qué sucedió en CrowdStrike, habló en general sobre cómo el código con errores puede pasar desapercibido. Por lo general, existe un proceso en el que el código se prueba exhaustivamente antes de implementarlo, pero a veces un equipo de ingeniería, especialmente en un grupo de ingeniería grande, puede tomar atajos. «Es posible que algo así suceda cuando se omite la canalización de pruebas DevOps, lo que es bastante común con actualizaciones menores», dijo Bansal a TechCrunch. Dice que esto suele suceder en organizaciones más grandes donde no hay un enfoque único para los lanzamientos de software. «Digamos que tienes 5000 ingenieros, que probablemente se dividirán en 100 equipos de aproximadamente 50 desarrolladores diferentes. Estos equipos adoptan diferentes prácticas», dijo. Y sin estandarización, es más fácil que el código malo se escape. Cómo evitar que se cuelen errores Ambos directores ejecutivos reconocen que a veces se cuelan errores, pero hay formas de minimizar el riesgo, incluida quizás la más obvia: practicar la higiene estándar de lanzamiento de software. Eso implica probar antes de implementar y luego implementar de manera controlada. Rogers señala el software de su empresa y señala que las implementaciones progresivas son el lugar para comenzar. En lugar de entregar el cambio a todos los usuarios a la vez, lo lanza a un pequeño subconjunto y ve qué sucede antes de expandir la implementación. En la misma línea, si tiene implementaciones controladas y algo sale mal, puede volver atrás. «Esta idea de gestión de características o control de características le permite revertir características que no funcionan y hacer que la gente vuelva a la versión anterior si las cosas no funcionan». Bansal, cuya empresa acaba de comprar la startup de bandera de características Split.io en mayo, también recomienda lo que llama «implementaciones canarias», que son pequeñas implementaciones de prueba controladas. Se llaman así porque recuerdan a los canarios que se enviaban a las minas de carbón para comprobar si había fugas de monóxido de carbono. Una vez que se demuestra que la prueba parece buena, se puede pasar a la implementación progresiva a la que aludió Rogers. Como dice Bansal, puede parecer bien en las pruebas, pero una prueba de laboratorio no siempre detecta todo, y es por eso que hay que combinar buenas pruebas de DevOps con una implementación controlada para detectar cosas que las pruebas de laboratorio pasan por alto. Rogers sugiere que, al realizar un análisis de su régimen de pruebas de software, se observen tres áreas clave: plataforma, personas y procesos, y que todas ellas trabajan juntas en su opinión. «No basta con tener una gran plataforma de software. No basta con tener desarrolladores altamente capacitados. Tampoco basta con tener flujos de trabajo y gobernanza predefinidos. Los tres tienen que ir juntos», dijo. Una forma de evitar que los ingenieros o equipos individuales eludan el proceso es exigir el mismo enfoque para todos, pero de una manera que no ralentice a los equipos. “Si creas un flujo de trabajo que ralentiza a los desarrolladores, en algún momento encontrarán formas de hacer su trabajo fuera de él porque pensarán que el proceso va a sumar otras dos semanas o un mes antes de que podamos enviar el código que escribimos”, dijo Bansal. Rogers está de acuerdo en que es importante no implementar sistemas rígidos en respuesta a un incidente malo. “Lo que no quieres que suceda ahora es que estés tan preocupado por hacer cambios de software que tengas un ciclo de prueba muy largo y prolongado y termines sofocando la innovación de software”, dijo. Bansal dice que un enfoque automatizado bien pensado puede ser realmente útil, especialmente con grupos de ingeniería más grandes. Pero siempre habrá cierta tensión entre la seguridad y la gobernanza y la necesidad de velocidad de lanzamiento, y es difícil encontrar el equilibrio adecuado. Puede que no sepamos qué sucedió en CrowdStrike durante algún tiempo, pero sí sabemos que ciertos enfoques ayudan a minimizar los riesgos en torno a la implementación de software. El código incorrecto se va a filtrar de vez en cuando, pero si sigues las mejores prácticas, probablemente no será tan catastrófico como lo que sucedió la semana pasada.