¿Qué podemos aprender de la crisis de HealthCare.gov?

TIME - Code Red Una de las políticas estrellas del presidente Obama ha sido la llamada ‘Obamacare’, una reforma del sistema sanitario de los Estados Unidos orientada a facilitar el acceso a la sanidad de manera universal (a la americana). El primer día de Octubre del 2013 iniciaba su andadura el buque insignia del programa, el sitio web HealthCare.gov.

A través de esta web los ciudadanos deberían realizar sus gestiones para obtener la cobertura sanitaria que les correspondiera en cada caso, bien comparando las ofertas de las aseguradoras o bien, si tenían derecho a ello, acogiéndose a programas para personas con recursos limitados como el Medicaid. Desde el primer momento el sitio empezó a hacer aguas, y con los republicanos al acecho todo el plan Obamacare corría peligro de colapsar porque una web en la que se habían invertido más de 300 millones de dolares no respondía a las expectativas. ¿Qué podemos aprender de la crisis de HealthCare.gov?

El pasado Marzo Steven Brill publicaba en la revista TIME el interesante reportaje: “CODE RED_ Inside the nightmare launch of HealthCare.gov and the team that figured out how to fix it” en el que se narra el fracaso inicial del lanzamiento del sitio web, y como un grupo de elegidos acudió al rescate y consiguió reflotar el ‘titanic’.

La agencia gubernamental que fue la encargada de llevar a cabo el desarrollo de la web, dos semanas después del lanzamiento era incapaz de siquiera de saber qué estaba pasando. Según el reportaje, en las reuniones diarias que Obama tenía con los mandamases, éstos no eran capaces de decir si el sitio web funcionaba o no, y la única manera de comprobarlo era coger un portátil y probar, como un usuario más.

Llegados a este punto se trataba de decidir si la web se podía arreglar, o si era mejor empezar de nuevo desde cero. Visto que la gente de CMS no parecía capacitada, recurrieron a un viejo conocido: Gabriel Burt, quién se había encargado durante la campaña presidencial de las herramientas de Big Data que tan buen resultado habían dado.

En aquellas elecciones Burt y sus chicos de marketing se llevaron el reconocimiento público, pero en la sombra había un genio como Mickey Dickenson en cuyo haber consta el puesto de Site Reliability Engineer de Google, vamos, que era el encargado de que Google fuera ‘fino’. Durante la campaña electoral Dickenson fue el que hizo escalable el website de campaña de Obama, y el que diseño el software de reporting durante el propio día de las elecciones. Esta vez, acertadamente, volvieron a recurrir a él.

Al equipo de rescate inicial formado por Burt y Dickinson se unieron pronto otros valiosos reclutas que consiguieron con mucho esfuerzo, y no sin altibajos devolver la funcionalidad a una web que en sus inicios apenas era capaz de dar servicio a un centenar de usuarios sin venirse abajo, y sin que éstos se encontraran múltiples errores por el camino. Ríos de tinta han corrido sobre el asunto, y la mayoría se queda en la punta del iceberg. Este artículo arroja algo de luz sobre los entresijos (mientras alguno de los que estuvo en el fregado no publique un libro) y permite hacernos una idea grosso modo de los principales errores que se cometieron.

ERROR: Seguimiento inadecuado de la ejecución proyecto

Durante la ejecución del proyecto los políticos y los hombres de los trajes estaban más preocupados de que el proyecto político saliera adelante que de los medios que lo harían posible. Se dio por sentado que la tecnología respondería. Comprensible por otra parte dada la oposición que el proyecto suscitaba, sin embargo el no haber hecho un seguimiento mejor no permitió identificar los problemas hasta que fue demasiado tarde.

ERROR: Falta de liderazgo y coordinación

Una de las primeras cosas que el equipo de rescate constató es que habían tejido una maraña de contratistas, y no había un líder que ejerciera de coordinador y que estuviera al cargo del proyecto. Así las cosas, los contratistas se echaban las culpas de lo ocurrido unos a otros, y ninguno tomaba responsabilidades de sus actos. Esta falta de responsabilidad se tradujo, por ejemplo, en que nadie parecía tener prisa por arreglar el desaguisado. En cuanto a la falta de coordinación, había llevado a una situación en la que los sistemas desarrollados por empresas independientes eran incapaces de entenderse entre sí, no habían acordado los protocolos de comunicación, y acabaron con un montón de ‘sistemas autistas’.

ERROR: Lanzamiento megalítico

Traducido en román paladino como “el que mucho abarca, poco aprieta”, se había cometido uno de los errores elementales consistente en lanzar todo de golpe y para todo el mundo a la vez. Hoy en día ningún sitio web comercial que se precie sigue este patrón, más bien se dedican a hacer lanzamientos pequeños incrementando la funcionalidad poco a poco; y en algunos casos incluso eligiendo un grupo reducido de prueba, para ir calibrando poco a poco.

En los párrafos anteriores se han señalado algunos de los errores más gordos desde el punto de vista de la gestión del proyecto, pero, no se vayan todavía, que aun hay más; desde el punto de vista más técnico tampoco se salvan.

ERROR: Falta de monitorización

El primer día que el grupo de rescate llega a las oficinas centrales del CMS se encuentran con una situación sorprendente. Las excusas del mal funcionamiento se achacaban a que el número de usuarios había superado las previsiones iniciales, pero lo cierto es que ¡No sabían cuántos usuarios tenían!

Se quedaron sorprendidos al comprobar que no había manera de medir qué estaba pasando el el website: no sabían los usuarios que lo estaban usando, no sabían cuáles eran los tiempos de respuesta a los click de los usuarios, no sabían en qué punto tenían más tráfico o en qué puntos tenían cuellos de botella de rendimiento…

De hecho, lo primero que hicieron nada más llegar fue implementar un sistema de monitorización, un ‘dashboard’, para poder saber qué estaba pasando. ¿Cómo vas a arreglar algo si no sabes qué tienes que arreglar? Claro, así normal que no supieran que tenían un problema 🙂

ERROR: Falta de Cachés

Una de las primeras cosas que les permitió ‘ver’ el dashboard es que tenían un problema en el acceso a los datos. Como no usaban cachés, la capa de acceso a datos no daba a basto con todas las peticiones. Tras añadir una capa de caché consiguieron una mejora sustancial, y lo que es más importante desde el punto de vista anímico, esa mejora les hizo creer que el proyecto era salvable sin necesidad de empezar de cero.

ERROR: Falta de optimización en componentes críticos

Tal como estaba diseñada la web resultó que tenían un motor de generación de tokens que servía para generar claves que los distintos sistemas pudieran usar en sus comunicaciones, y como no, éste era demasiado lento. Así que vista la importancia de este componente decidieron priorizar su mejora. Cuando se tiene un componente crítico como en este caso, toda atención que se le preste es poca. Los ingenieros originales no lo vieron así, y con una solución poco optimizada acabaron afectando a todo el sistema.

ERROR: El ratio de errores era muy elevado

El número de veces que un usuario se encontraba un error durante la navegación era muy elevado, en la mayoría de los casos en poco más de una decena de clicks el usuario obtenía un error. Esto no solo es un problema de funcionalidad y de usabilidad, es que además la gestión de los errores conlleva generalmente peores rendimientos, por ejemplo en el caso de los timeouts. Arreglar esto requirió muchos más tiempo al tener que ir viendo cada caso concreto por separado. Pero también en este caso al cabo de unas semanas de bugfix consiguieron rebajar el ratio de errores a menos del 0.5%

ERROR: La arquitectura no era escalable

Cuándo se revisó la arquitectura del sistema se comprobó que no había sido diseñada pensando en que tenía que poder escalarse según las necesidades. Resultaba que un elemento mal dimensionado provocaba lentitud en el resto del sistema. Los aurigas más rápidos llegaban tarde porque tenían que esperar por el carro más lento, y por encima no era factible añadir más caballos para que corriera más. Así que en este aspecto hubo cosas que no tuvieron más remedio que cambiar de raíz.

ERROR: El Hardware no era adecuado

Esta no es una solución que quede muy ‘elegante’ – resolver problemas de optimización por la vía de añadir más harware es, además de ineficaz en muchos casos, una solución bastante zafia-, pero en algunos casos también tuvieron que reemplazar el hardware que no era el adecuado. Y en otros casos, además, resultaba que los recursos eran más bien escasos y no quedaba más alternativa que ampliarlos.

Ciertamente es más fácil decirlo que hacerlo, y si gente muy preparada y con mucho dinero ha metido la pata, quién es el que está libre de pecado. Pero este post no pretende ser un “vaya burros que son, seguro que yo lo haría mejor”, más bien se trata de ver dónde se han equivocado otros, y con suerte podremos no caer en los mismos errores. Aunque ya se sabe que el hombre tiende a tropezar varias veces con la misma piedra.