Les 10 ans du sauvetage de HealthCare.gov
(pauladamsmith.com)- Le 18 octobre 2013, une petite équipe technique a entamé sa première inspection sur le terrain à la Maison-Blanche pour remettre sur pied HealthCare.gov, à l’arrêt juste après son lancement ; cette intervention sera plus tard appelée le « tech surge »
- Le site a été mis en ligne le 1er octobre 2013, mais ne fonctionnait pas correctement, et à cause du shutdown du gouvernement fédéral qui a commencé le même jour, un renfort extérieur n’a pu être déployé qu’après le 17 octobre
- Lors de la première journée, l’équipe a enchaîné les passages à la Maison-Blanche, au HHS, au CMS, à l’Exchange Operations Center et dans les bureaux de CGI afin d’identifier les goulots d’étranglement d’un système de grande ampleur où s’entremêlaient contrats, composants, règles métier et procédures de déploiement
- Sur place, les principaux risques identifiés étaient des tests manuels, de longs déploiements nocturnes suivis de rollbacks, un provisionnement lent des ressources, une couche centrale de données sans schéma et l’absence de monitoring en temps réel
- Après avoir installé directement New Relic sur certains serveurs dans les bureaux de CGI, la latence, le taux d’erreur et le nombre de requêtes sont devenus visibles pour la première fois ; le sauvetage s’est ensuite étendu sur environ deux mois et demi et a contribué à l’amélioration du site
18 octobre 2013, début des opérations de sauvetage
- Le travail de remise en état de HealthCare.gov a réellement commencé le vendredi 18 octobre 2013 à 7 h 15, avec un petit groupe réuni près de l’entrée de la West Wing de la Maison-Blanche
- Le groupe initial comprenait Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman et Paul Smith ; plus tard dans la journée, Mikey Dickerson les a rejoints au cours d’un long appel sur haut-parleur
- Certains venaient de l’extérieur du gouvernement, d’autres y travaillaient déjà, mais tous étaient des experts techniques ayant une expérience en startup ou dans de grandes organisations technologiques
- Todd Park, alors CTO des États-Unis, les avait sélectionnés pour renforcer les fonctionnaires et les équipes de prestataires qui avaient construit HealthCare.gov
- La mission ne consistait pas à « charger comme la cavalerie », mais relevait plutôt d’un soutien discret : entrer sans bruit dans un environnement déjà sous forte pression et stress, puis recueillir des informations et évaluer la situation
- Todd Park a expliqué que les 30 jours suivants seraient décisifs, avec pour objectif d’inscrire 7 millions de personnes d’ici au 31 mars 2014, date de fin de la période d’inscription ouverte
Le vide créé par le shutdown et l’échec du lancement
- HealthCare.gov a été lancé le 1er octobre 2013, mais ne fonctionnait pas correctement, et le shutdown du gouvernement fédéral a commencé le même jour
- À cause de ce shutdown, personne en dehors de l’équipe centrale de HealthCare.gov ne pouvait venir apporter son aide
- Pendant ce temps, l’actualité était dominée par le shutdown et par un lancement désastreux qui avançait au ralenti, alimentant le vide informationnel, les spéculations et les inquiétudes
- La Maison-Blanche ne parvenait pas à comprendre ce qui n’allait pas avec HealthCare.gov, et si le site échouait, c’est le principal canal de distribution des bénéfices de l’Affordable Care Act à des millions de personnes qui risquait d’être compromis
- Le shutdown a pris fin le 17 octobre, et ce n’est qu’alors que l’équipe technique externe a pu constater la situation réelle et commencer à travailler
La vue d’ensemble du système comprise dans la matinée du premier jour
- Après avoir pris leur petit-déjeuner au Navy Mess de la Maison-Blanche, l’équipe est montée au bureau du Chief of Staff pour rencontrer Denis McDonough
- Denis McDonough a demandé directement : « Est-ce que vous pouvez réparer ça ? », et certains membres de l’équipe, tendus, ont répondu que oui
- Ils se sont ensuite rendus au Hubert H. Humphrey Building, siège du HHS, pour rencontrer Marilyn Tavenner, responsable du CMS, ainsi que son équipe
- À cette occasion, l’architecture de HealthCare.gov, ses principaux composants fonctionnels, les points de défaillance connus de la direction du CMS et les problèmes de performance à haut niveau ont été présentés
- Comme la direction du CMS était composée d’experts des politiques de santé et d’administrateurs, les informations transmises relevaient surtout des indicateurs métier du site et d’explications de haut niveau sur ses performances
- En fin de matinée, l’équipe s’est rendue au siège du CMS à Woodlawn, dans le Maryland, pour rencontrer Michelle Snyder, Henry Chao, Dave Nelson et d’autres responsables de HealthCare.gov
- C’est là que des informations ont commencé à émerger, petit à petit, sur les problèmes de déploiement, les goulots d’étranglement, les points où les utilisateurs se retrouvaient « bloqués » sur le site, la base de données XML MarkLogic, l’architecture de déploiement et les types de serveurs
La réalité opérationnelle révélée au XOC
- L’après-midi, l’équipe s’est rendue à l’Exchange Operations Center, ou XOC, à Columbia, dans le Maryland
- Le XOC était une sorte de centre de contrôle de mission pour l’exploitation de HealthCare.gov, et l’équipe y a écouté les techniciens qui manipulaient directement le site
- Les problèmes constatés sur place étaient bien plus graves que prévu au départ
- Il y avait un manque de confiance dans les changements apportés au code source
- Une grande partie du site était produite via des procédures complexes de génération de code, nécessitant une coordination minutieuse entre équipes
- Les tests étaient pour l’essentiel manuels
- Les releases et les déploiements exigeaient de longues interruptions nocturnes, suivies de longs rollbacks en cas d’échec
- La couche centrale de données n’avait pas de schéma
- Le provisionnement des ressources d’hébergement était lent et non automatisé
- Ni APM, ni même des métriques de base comme le CPU, la mémoire, le disque ou le réseau n’étaient disponibles sous une forme exploitable par les équipes
- À ce moment-là, l’équipe a pris la mesure du fait que la situation était bien pire qu’elle ne l’avait imaginé au départ, et Paul Smith a noté en hâte ce qu’il entendait dans son carnet Moleskine
La nuit où New Relic a été branché dans les bureaux de CGI
- En soirée, l’équipe s’est rendue dans les bureaux de CGI à Herndon, en Virginie
- CGI était le principal prestataire de HealthCare.gov, et l’équipe y a rencontré les responsables et les équipes techniques pour leur poser des questions
- Lors de cette rencontre, il était essentiel que l’équipe technique externe gagne la confiance des équipes de CGI
- Les équipes de CGI étaient sous pression et épuisées
- L’équipe de sauvetage a insisté sur le fait qu’elle n’était pas venue pour accuser, mais pour aider
- Elle a cherché à démontrer sa crédibilité en ingénierie à partir de son expérience des sites web à fort trafic
- La question centrale était : « Qu’est-ce qui ne va pas sur le site, et comment le savez-vous ? », mais ni le CMS ni CGI ne parvenaient vraiment à montrer à quels endroits précis certains composants internes du système ne fonctionnaient pas comme attendu
- L’équipe a proposé d’installer sur certains serveurs New Relic, un service de monitoring de type APM qu’elle connaissait bien
- En contournant la procédure normale de release, des agents ont été installés directement sur certains serveurs sélectionnés, après validation par un responsable du CMS qui a confirmé qu’une licence New Relic existait déjà
- Les personnes encore présentes presque à minuit ont effectué les changements, et sur l’écran de la salle de réunion, la console d’administration de New Relic a rapidement commencé à recevoir les métriques des serveurs sélectionnés du « red shard »
- Pour la première fois, des métriques opérationnelles en temps réel comme les pics de latence des requêtes, le taux d’erreur et le nombre de requêtes par minute sont apparues, révélant un état du système jusqu’alors pratiquement invisible
- Grâce à ces métriques, il est devenu possible de relier les indicateurs métier à l’état du système et d’établir des priorités pour les correctifs et les actions capables d’apporter les plus fortes améliorations
Après une première journée de 18 heures
- Après avoir quitté Herndon, l’équipe a brièvement fait un retour à froid vers 2 heures du matin dans une Roosevelt Room silencieuse à la Maison-Blanche
- À ce stade, l’équipe a compris que les problèmes dépassaient largement le cadre de simples conseils de court terme et qu’il faudrait s’investir dans ce travail pendant un certain temps, jusqu’au rétablissement du site
- Après quelques heures de sommeil, elle est repartie vers Herndon le lendemain matin
- Cette première journée a duré environ 18 heures, et des marathons comparables ont suivi
- Jusqu’à la fin décembre, sur environ deux mois et demi, le tech surge s’est élargi, de nouveaux membres ont rejoint l’effort et ont contribué à l’amélioration de HealthCare.gov
- Cette année-là, des millions de personnes se sont inscrites à une couverture santé, souvent pour la première fois
1 commentaires
Avis sur Hacker News
L’intention initiale était que chaque État gère sa propre bourse d’échange, et que seuls les habitants des États qui refusaient utilisent la bourse fédérale.
Au début, 36 États n’avaient pas créé leur propre bourse 0, et aujourd’hui il semble que 20 États, D.C. inclus, exploitent leur propre marketplace 1.
Le shutdown du gouvernement de 2013, qui a empêché des personnes extérieures à l’équipe de l’État de HealthCare.gov de venir aider, a été mené par le sénateur Ted Cruz dans le but de faire obstacle à l’ACA 2.
J’ai parfois l’impression que le principe américain selon lequel « les États sont chacun indépendants » va trop loin.
Ils craignaient qu’un système de santé fédéral finisse par mener à une couverture santé universelle et, après avoir obtenu ce compromis, ils ont refusé de mettre en œuvre les bourses en espérant que la loi meure.
Mais la loi n’est pas morte, et cela leur déplaît encore.
Le fait de transférer les fonds fédéraux aux États sous forme de dotations globales, puis de confier aux États des programmes comme TANF et l’examen de l’éligibilité 1, a fortement dégradé à la fois l’efficacité avec laquelle chaque dollar du budget fédéral se transformait en aide réelle, ainsi que le nombre de bénéficiaires et les montants versés.
Je ne connais pas la justification des marketplaces d’État dans l’ACA, mais historiquement, dès qu’on fait intervenir les États, on augmente la marge de manœuvre pour qu’un intermédiaire abîme le programme et détourne l’argent ailleurs.
Par exemple, le Texas a refusé les 5 à 6 milliards de dollars annuels d’argent gratuit que le gouvernement fédéral voulait lui donner pour l’extension de Medicaid 2.
Il me semble avoir lu plusieurs fois qu’un assureur avait perdu de l’argent à cause d’un petit nombre de patients aux soins très coûteux, et que les coûts étaient devenus si élevés qu’après avoir augmenté les prix, plus personne ne voulait acheter ce produit.
J’ai essayé récemment de retrouver ces articles, mais je n’y arrive plus, donc je me demande si je n’ai pas imaginé tout ça.
J’ai l’argent et la volonté de conclure une transaction, mais je ne peux pas ; ce système est donc un échec.
Je garde le souvenir d’avoir travaillé avec ces personnes quand tout le monde a été embarqué pour réparer ça.
Gabe codait dans VIM avec l’allure d’un grand violoniste, et en travaillant avec Mikey, j’ai vu la puissance des métriques et du SRE.
Dans une salle où tout le monde pointait du doigt le fournisseur suivant, on est passé à l’identification réelle d’une partie des goulots d’étranglement.
Réparer un système largement cassé sans pouvoir le mettre hors ligne pour une grosse refactorisation, c’était comme opérer quelqu’un en train de faire son jogging ; une expérience vraiment rude.
Une petite startup de D.C. était à peu près le sous-traitant du sous-traitant du sous-traitant chargé de la page d’accueil front-end, mais je garde un bon souvenir du fait d’avoir quand même permis aux gens d’arriver sur une vraie page de healthcare.gov plutôt que sur une page d’erreur 500.
Si ma mémoire est bonne, c’était grâce à un seul serveur utilisant Jekyll, plus un serveur de secours.
Avec les termes d’aujourd’hui, c’était de la « génération de pages statiques », ce qui permettait de l’héberger sur du matériel modeste.
À l’époque, c’était considéré comme une tactique assez avancée, et c’est probablement ce à quoi tu penses.
À ma connaissance, ce site a été entièrement remplacé à l’ouverture de la bourse fédérale, et comme la page d’accueil elle-même ne recevait ni ne traitait de données personnelles, sa fourniture ne posait pas de difficulté majeure.
Tout s’est arrêté quand les utilisateurs ont commencé à essayer réellement de chercher des offres d’assurance.
Development Seed a aussi créé un autre projet dont vous avez peut-être entendu parler plus tard, Mapbox, et l’entreprise entière a fini par basculer dans cette direction.
Je me souviens avoir entendu dans un podcast qu’au lieu d’afficher les échecs de type « timeout du backend » comme des erreurs, ils avaient changé le système pour envoyer les données par e-mail et dire à l’utilisateur : « Très bien, nous les avons reçues. Revenez vérifier plus tard. »
J’avais trouvé ça très malin, et je l’ai gardé en tête comme une approche réutilisable en cas d’urgence.
Quelque chose de similaire s’est produit chez WebTV lors d’une surcharge de la base de données : ils ont arrêté tous les serveurs de livraison de courrier de dernière étape qui nécessitaient une connexion à la base, afin que les e-mails soient mis en file d’attente sur les serveurs SMTP entrants, puis les ont vidés une fois la surcharge de la base de données résorbée.
La leçon est que, pour réduire la charge d’un système conçu pour fonctionner de manière transactionnelle mais en train d’échouer, il faut utiliser un traitement orienté batch alimenté par une file.
L’épisode du podcast « Go Time » consacré à ce sujet était excellent, et expliquait comment Go a été utilisé pour servir une partie du site
Je recommande vivement cet épisode et ce podcast
https://changelog.com/gotime/154
J’ai cliqué en pensant trouver une discussion technique intéressante, mais la partie technique n’est arrivée qu’assez tard
En revanche, les coulisses du processus se sont révélées étonnamment passionnantes, et j’attends vraiment la suite avec impatience
J’ai vraiment apprécié la lecture de cet article
Je me souviens qu’il y a 10 ans, sur HN, on décortiquait le code source GitHub du site web : https://news.ycombinator.com/item?id=6540993
Ce qui s’est réellement passé n’était pas idéal, mais je me demande s’il existe, en dehors de cette rétrospective, des ressources qui expliquent plus en détail ce qui s’est exactement passé et comment cela a été résolu
Je compte continuer à suivre les prochains articles de cette série
Ça a un petit côté porno de compétence en ingénierie, mais j’aime ce genre d’histoires
J’ai lu The Phoenix Project il y a quelques années ; c’était romancé et le livre introduisait Agile et DevOps de façon assez explicite, mais comme je suis analyste de données, c’était nouveau pour moi et j’ai apprécié. S’il existe des recommandations similaires, j’aimerais les lire
Pour citer un bon extrait, Dickerson avait affiché des règles sur le mur juste à l’extérieur de la salle de contrôle
Règle 1 : « La war room et les réunions servent à résoudre les problèmes. Il existe plein d’autres endroits où dépenser son énergie créative à rejeter la faute sur les autres. »
Règle 2 : « La personne qui doit parler d’un sujet n’est pas celle qui a le plus haut rang, mais celle qui connaît le mieux ce sujet. Si quelqu’un reste assis passivement pendant que des managers et des dirigeants parlent avec des informations moins exactes, alors nous avons déraillé, et je veux le savoir. » Dickerson a expliqué plus tard que « quand on écarte les managers, les ingénieurs veulent résoudre les problèmes »
Règle 3 : « Nous devons nous concentrer sur les sujets les plus urgents qui risquent de nous causer du tort dans les 24 à 48 prochaines heures. »
La solution, c’est de ne pas continuer à confier ce genre de choses aux mêmes entreprises
Il semble évident que des sociétés comme CGI ou IBM ne sont pas suffisamment compétentes, et je ne comprends pas pourquoi elles ne sont pas interdites de soumissionner pour de futurs contrats similaires
Si vous ratez un contrat, vous devriez être exclu de tous les marchés publics pendant les 10 années suivantes
Comme ça, au lieu de recycler sans cesse des livrables médiocres, on finirait par avoir une technologie qui fonctionne vraiment
Cela rend la participation difficile pour les petites entreprises
Ou alors de mélanger les équipes
Bientôt, il ne restera plus personne pour accepter le travail
« Certaines technologies, dont une base de données XML appelée MarkLogic » : une base de données XML pour un service critique utilisé par 300 millions de personnes ?
Ça fait froid dans le dos
Les règles métier étaient probablement en XML et plus ou moins en lecture seule, tandis que les données dynamiques se trouvaient dans une base relationnelle
C’est peut-être juste un vœu pieux de ma part
Cela pouvait être une base de données de configuration, mais comme le problème semble venir de la logique métier, cela aurait déjà pu poser problème en soi