A 10 años del rescate de HealthCare.gov
(pauladamsmith.com)- El 18 de octubre de 2013, poco después del lanzamiento, un pequeño equipo técnico inició en la Casa Blanca la primera revisión en terreno para revivir HealthCare.gov, que había quedado detenido; ese trabajo luego se conocería como “tech surge”
- El sitio se lanzó el 1 de octubre de 2013, pero no funcionaba correctamente y, debido al cierre del gobierno federal que comenzó ese mismo día, el apoyo externo solo pudo incorporarse después del 17 de octubre
- El primer día, el equipo recorrió sucesivamente la Casa Blanca, HHS, CMS, el Exchange Operations Center y las oficinas de CGI, identificando cuellos de botella en un gran sistema donde se entrelazaban contratos, componentes, reglas de negocio y procedimientos de despliegue
- En terreno, los principales riesgos que salieron a la luz fueron las pruebas manuales, los largos despliegues nocturnos y rollbacks, el aprovisionamiento lento de recursos, una capa central de datos sin esquema y la ausencia de monitoreo en tiempo real
- Tras instalar directamente New Relic en algunos servidores en las oficinas de CGI, por primera vez empezaron a verse la latencia, la tasa de errores y la cantidad de solicitudes; luego, durante unos dos meses y medio, el trabajo de rescate se amplió y contribuyó a mejorar el sitio
18 de octubre de 2013: el inicio del rescate
- La recuperación de HealthCare.gov comenzó en serio el viernes 18 de octubre de 2013 a las 7:15 a. m., con un pequeño grupo reunido cerca de la entrada del West Wing de la Casa Blanca
- El grupo inicial incluía a Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman y Paul Smith; más tarde ese día se sumó Mikey Dickerson mediante una larga llamada por altavoz
- Algunos venían de fuera del gobierno y otros trabajaban entonces en el gobierno, pero todos eran expertos técnicos con experiencia en startups o grandes organizaciones tecnológicas
- Todd Park, entonces CTO de Estados Unidos, los seleccionó para reforzar a los empleados gubernamentales y a los equipos contratistas que habían construido HealthCare.gov
- La misión no era “lanzarse como la caballería”, sino más bien entrar discretamente a un entorno ya sometido a mucha presión y estrés para recopilar información y evaluarla, como un apoyo de bajo perfil
- Todd Park dijo que los siguientes 30 días eran cruciales, y el objetivo era inscribir a 7 millones de personas antes de que terminara el período de inscripción abierta, el 31 de marzo de 2014
El vacío creado por el cierre del gobierno y el fracaso del lanzamiento
- HealthCare.gov se lanzó el 1 de octubre de 2013, pero no funcionó correctamente, y ese mismo día comenzó el cierre del gobierno federal
- Debido al cierre, personal externo al equipo central de HealthCare.gov no podía entrar a ayudar
- Mientras tanto, las noticias se llenaban del cierre del gobierno y de un desastre de lanzamiento que avanzaba lentamente, y crecían el vacío de información, las especulaciones y las preocupaciones
- La Casa Blanca no lograba identificar qué estaba mal en HealthCare.gov, y si el sitio fracasaba, podía tambalear el principal medio para entregar los beneficios de la Affordable Care Act a millones de personas
- El cierre del gobierno terminó el 17 de octubre, y solo entonces el equipo técnico externo pudo verificar la situación real y empezar a trabajar
La visión general del sistema identificada durante la primera mañana
- El equipo desayunó en el Navy Mess de la Casa Blanca y luego subió a la oficina del Chief of Staff para reunirse con Denis McDonough
- Denis McDonough preguntó directamente “¿pueden arreglarlo?”, y algunos miembros del equipo, nerviosos, respondieron que sí
- Después se trasladaron al Hubert H. Humphrey Building, sede del HHS, para reunirse con Marilyn Tavenner, responsable de CMS, y su equipo
- En esa reunión se compartieron la arquitectura de HealthCare.gov, sus principales componentes funcionales, los puntos de falla que conocía el liderazgo de CMS y los problemas de rendimiento a alto nivel
- Como el liderazgo de CMS estaba compuesto por expertos en política de salud y administradores, la información transmitida se parecía principalmente a métricas de negocio del sitio y descripciones de rendimiento a alto nivel
- Hacia el final de la mañana se trasladaron a la sede de CMS en Woodlawn, Maryland, para reunirse con Michelle Snyder, Henry Chao, Dave Nelson y otros líderes de HealthCare.gov
- Allí empezaron a emerger, poco a poco, detalles sobre problemas de despliegue, cuellos de botella, puntos donde los usuarios quedaban “atascados” en el sitio, la base de datos XML MarkLogic, la arquitectura de despliegue y los tipos de servidores
La realidad operativa revelada en el XOC
- Por la tarde se trasladaron al Exchange Operations Center, o XOC, en Columbia, Maryland
- El XOC era un centro tipo control de misión para la operación de HealthCare.gov, y allí el equipo escuchó a los técnicos que trabajaban directamente con el sitio
- Los problemas detectados en terreno eran mucho más graves de lo previsto inicialmente
- Había falta de confianza en los cambios al código fuente
- Muchas partes del sitio se generaban mediante procedimientos complejos de generación de código, que requerían una coordinación cuidadosa entre equipos
- Las pruebas eran, en general, un proceso manual
- Los releases y despliegues requerían largos períodos de downtime nocturno y, si fallaban, les seguían largos rollbacks
- La capa central de datos no tenía esquema
- El aprovisionamiento de recursos de hosting era lento y no estaba automatizado
- No había APM ni siquiera métricas básicas como CPU, memoria, disco y red disponibles de una forma que el equipo pudiera ver
- Para entonces, el equipo aceptó que la situación era mucho peor de lo que habían imaginado al principio, y Paul Smith anotó rápidamente lo que escuchaba en una libreta Moleskine
La noche en que conectaron New Relic en las oficinas de CGI
- Por la noche se trasladaron a las oficinas de CGI en Herndon, Virginia
- CGI era el contratista principal de HealthCare.gov, y el equipo se reunió con su liderazgo y sus equipos técnicos para hacer preguntas
- En esa reunión era importante que el equipo técnico externo se ganara la confianza del equipo de CGI
- El equipo de CGI estaba bajo presión y agotado
- El equipo de rescate enfatizó que no venía a culpar, sino a ayudar
- Intentaron demostrar capacidad de ingeniería basándose en su experiencia con sitios web de alto tráfico
- La pregunta central era “qué está mal con el sitio y cómo lo saben”, pero CMS y CGI en gran medida no podían mostrar en qué puntos específicos, dentro del sistema, ciertos componentes no se estaban comportando como se esperaba
- El equipo propuso instalar New Relic, un servicio de monitoreo de estilo APM con el que estaban familiarizados, en algunos servidores
- Saltándose el procedimiento normal de release, instalaron directamente agentes en algunos servidores seleccionados; después de que un líder de CMS confirmara que ya tenían una licencia de New Relic, se aprobó el cambio
- Las personas que se quedaron hasta cerca de la medianoche realizaron la modificación, y en la pantalla de la sala de reuniones, la consola de administración de New Relic pronto empezó a recibir métricas de los servidores seleccionados del “red shard”
- Por primera vez se vieron métricas operativas en tiempo real como picos de latencia de solicitudes, tasa de errores y solicitudes por minuto, revelando el estado del sistema que hasta entonces era prácticamente invisible
- Gracias a esas métricas, se pudo vincular las métricas de negocio con el estado del sistema y crear una base para priorizar los cambios y acciones que producirían las mayores mejoras
Después del primer día de 18 horas
- Después de salir de Herndon, el equipo hizo una breve retrospectiva alrededor de las 2 a. m. en el silencioso Roosevelt Room de la Casa Blanca
- En ese momento, el equipo aceptó que el problema no era de una escala que pudiera resolverse con consejos de corto plazo, y que tendría que dedicarse a este trabajo por un tiempo, hasta que el sitio se recuperara
- Tras dormir unas pocas horas, a la mañana siguiente volvieron a Herndon
- La primera jornada duró unas 18 horas, y luego continuaron maratones similares
- Hasta fines de diciembre, durante aproximadamente dos meses y medio, el tech surge se amplió, se sumaron nuevos integrantes al equipo y ayudó a mejorar HealthCare.gov
- Ese año, millones de personas se inscribieron en una cobertura de salud, y para muchas fue la primera vez
1 comentarios
Opiniones en Hacker News
La intención original era que cada estado operara su propio exchange, y que solo los residentes de los estados que se negaran usaran el exchange federal.
Al principio, 36 estados no crearon su propio exchange 0, y actualmente parece que 20 estados, incluido D.C., operan su propio marketplace 1.
El cierre del gobierno de 2013, que impidió que personal externo al equipo estatal de HealthCare.gov entrara a ayudar, fue impulsado por el senador Ted Cruz con el propósito de obstaculizar la ACA 2
A veces siento que el principio estadounidense de que “cada estado es independiente” se lleva demasiado lejos.
A ellos les preocupaba que un sistema federal de salud terminara llevando a un seguro médico universal y, después de obtener el compromiso, se negaron a implementar los exchanges esperando que la ley muriera.
Pero la ley no murió, y todavía les molesta.
Al transferir fondos federales a subvenciones globales por estado y dejar que los estados se encargaran de programas como TANF y de la evaluación de elegibilidad 1, empeoraron mucho tanto la eficiencia con la que cada dólar del presupuesto federal se convertía en apoyo real, como la cantidad de personas atendidas y los montos recibidos.
No conozco la justificación de los marketplaces estatales de la ACA, pero históricamente, al meter a los estados, se abrió más espacio para que un intermediario arruinara el programa y desviara el dinero a otra parte.
Por ejemplo, Texas rechazó entre 5 y 6 mil millones de dólares anuales de dinero gratis que el gobierno federal quería darle para ampliar Medicaid 2
Creo que varias veces se contaba que alguna aseguradora había perdido dinero por un pequeño grupo de pacientes con costos de tratamiento muy altos y que, cuando subió los precios porque esos costos se volvieron demasiado grandes, nadie quería comprar ese producto.
Hace poco busqué esos artículos y ya no pude encontrarlos, así que no sé si fue algo que imaginé.
Tengo el dinero y la voluntad de hacer la transacción, pero no puedo; así que este sistema es un fracaso.
Recuerdo haber trabajado con estas personas cuando todos fuimos arrastrados a arreglar esto.
Gabe programando en VIM era como ver a un violinista virtuoso, y trabajando con Mikey vi el poder de las métricas y SRE.
Pasamos de tener a todos en la sala señalando al siguiente proveedor a realmente identificar parte del cuello de botella.
En general, arreglar un sistema roto sin poder bajarlo para hacer una gran refactorización era como operar a alguien que está trotando; fue una experiencia realmente intensa.
Una pequeña startup de D.C. era algo así como el subcontratista del subcontratista del subcontratista encargado de la landing page frontal, y aun así recuerdo con agrado haber logrado que la gente llegara a una página real en healthcare.gov y no a una página de error 500.
Si no recuerdo mal, fue gracias a un solo servidor con Jekyll y un respaldo.
En términos actuales, usaba “generación de páginas estáticas”, así que podía alojarse incluso en hardware pequeño.
En ese momento se consideraba una táctica bastante avanzada, y probablemente sea eso lo que recuerdas.
Según tengo entendido, ese sitio fue reemplazado por completo cuando abrió el exchange federal, y como la landing page en sí no recibía ni procesaba datos personales, no había grandes obstáculos para servirla.
Todo se detuvo después de que los usuarios empezaron a intentar buscar planes de seguro de verdad.
Development Seed también creó otro proyecto del que quizá hayas oído hablar después, Mapbox, y al final toda la empresa giró hacia eso.
Recuerdo haber oído en algún podcast que, en vez de mostrar como error las fallas de “timeout del backend”, cambiaron el flujo para enviar los datos por email y decirle al usuario: “Listo, lo recibimos. Vuelve más tarde para revisarlo”.
Me pareció muy ingenioso, y lo guardé en la memoria como una estrategia que podría usar en una emergencia.
En WebTV pasó algo parecido cuando la base de datos se sobrecargó: bajaron todos los servidores finales de entrega de correo que necesitaban conexión a la base de datos, haciendo que el correo quedara en cola en los servidores SMTP de entrada, y luego la vaciaron cuando se alivió la sobrecarga de la base de datos.
La lección es que, para reducir la carga de un sistema diseñado para operar transaccionalmente pero que está fallando, hay que usar procesamiento orientado a lotes manejado desde una cola.
El episodio del podcast “Go Time” sobre este tema estuvo excelente y trata cómo se usó Go para servir partes del sitio.
Recomiendo mucho tanto ese episodio como el podcast.
https://changelog.com/gotime/154
Hice clic pensando que sería una discusión técnica interesante, pero la parte técnica apareció bastante más adelante.
En cambio, la mirada detrás de escena del proceso resultó inesperadamente muy interesante, y de verdad espero con ganas la siguiente entrega.
Disfruté mucho leer este artículo.
Recuerdo que hace 10 años en HN revisábamos a fondo el código fuente del sitio web en GitHub: https://news.ycombinator.com/item?id=6540993
Lo que realmente ocurrió no fue ideal, pero me pregunto si, además de esta retrospectiva, hay algún material que explique con más detalle qué pasó exactamente y cómo se resolvió.
Pienso seguir buscando las próximas entradas de esta serie.
Se siente un poco como porno de competencia en ingeniería, pero me gustan estas historias.
Hace algunos años leí The Phoenix Project; aunque está novelado y presenta Agile y DevOps de forma bastante explícita, para mí, como analista de datos, fue algo nuevo y me gustó. Si tienen recomendaciones similares, me gustaría leerlas.
Para citar un buen fragmento: Dickerson pegó las reglas en la pared justo afuera de la sala de control.
Regla 1: “La war room y las reuniones son para resolver problemas. Hay muchos otros lugares para gastar energía creativa echando culpas.”
Regla 2: “Quien debe hablar sobre un tema no es la persona de mayor rango, sino la que más sabe de ese tema. Si alguien está sentado pasivamente mientras los gerentes y ejecutivos hablan con información menos precisa, entonces estamos fuera de rumbo, y quiero saberlo.” Dickerson explicó más tarde: “si quitas de en medio a los gerentes, los ingenieros quieren resolver problemas”.
Regla 3: “Debemos concentrarnos en los asuntos más urgentes que nos van a perjudicar en las próximas 24 a 48 horas.”
La solución es no seguir entregándoles este tipo de trabajos a las mismas empresas.
Parece claro que empresas como CGI e IBM no son lo suficientemente competentes, y no entiendo por qué no se les prohíbe licitar en contratos futuros similares.
Si arruinas un contrato, deberías quedar excluido de todos los contratos gubernamentales durante los próximos 10 años.
Entonces tendríamos tecnología que realmente funciona, en vez de seguir reciclando resultados basura.
Por eso a las empresas pequeñas se les hace difícil participar en la competencia.
O mezclar los equipos.
Pronto no quedará nadie que quiera encargarse del trabajo.
“Ciertas tecnologías, incluida una base de datos XML llamada MarkLogic”; ¿una base de datos XML para un servicio crítico usado por 300 millones de personas?
Da escalofríos.
Supongo que las reglas de negocio estaban en XML y eran básicamente de solo lectura, mientras que los datos dinámicos estaban en una base de datos relacional.
Aunque quizá sea solo una conjetura optimista.
Podría haber sido una base de datos de configuración, pero como el problema parece haber venido de la lógica de negocio, eso por sí solo también pudo haber sido un problema.