Zehn Jahre seit der Rettung von HealthCare.gov
(pauladamsmith.com)- Am 18. Oktober 2013 begann ein kleines Technikteam im Weißen Haus mit der ersten Vor-Ort-Bestandsaufnahme, um das kurz nach dem Start zum Stillstand gekommene HealthCare.gov wiederzubeleben; diese Arbeit wurde später als „tech surge“ bekannt
- Die Website wurde am 1. Oktober 2013 veröffentlicht, funktionierte jedoch nicht richtig, und wegen des am selben Tag begonnenen Shutdowns der US-Bundesregierung konnte externe Unterstützung erst nach dem 17. Oktober eingesetzt werden
- Am ersten Tag fuhr das Team nacheinander zum Weißen Haus, zu HHS, CMS, dem Exchange Operations Center und in die CGI-Büros und identifizierte Engpässe in einem großen System, in dem Verträge, Komponenten, Geschäftsregeln und Deployment-Verfahren miteinander verflochten waren
- Vor Ort wurden manuelle Tests, lange nächtliche Deployments und Rollbacks, langsame Ressourcenbereitstellung, eine zentrale Datenschicht ohne Schema und das Fehlen von Echtzeit-Monitoring als Hauptrisiken sichtbar
- Nachdem in den CGI-Büros New Relic direkt auf einigen Servern installiert worden war, wurden erstmals Latenz, Fehlerrate und Anzahl der Requests sichtbar; in den folgenden rund zweieinhalb Monaten wurde die Rettungsaktion ausgeweitet und trug zur Verbesserung der Website bei
18. Oktober 2013: Der Beginn der Rettungsaktion
- Die Wiederherstellung von HealthCare.gov nahm am Freitag, dem 18. Oktober 2013, um 7:15 Uhr morgens mit einer kleinen Gruppe nahe dem Eingang des West Wing im Weißen Haus richtig Fahrt auf
- Zur ersten Gruppe gehörten Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman und Paul Smith; später an diesem Tag kam Mikey Dickerson über eine lange Lautsprecher-Telefonkonferenz hinzu
- Einige kamen von außerhalb der Regierung, andere arbeiteten damals bereits in der Regierung, doch alle waren Technikexperten mit Erfahrung in Startups oder großen Technologieorganisationen
- Todd Park, damals US-CTO, hatte sie ausgewählt, um die Regierungsmitarbeiter und Vertragsteams zu verstärken, die HealthCare.gov gebaut hatten
- Die Mission war kein „Sturmangriff der Kavallerie“, sondern eher eine zurückhaltende Unterstützung: leise in eine bereits stark belastete und gestresste Lage hineingehen, Informationen sammeln und die Situation bewerten
- Todd Park sagte, die nächsten 30 Tage seien entscheidend, und das Ziel sei, bis zum Ende des offenen Einschreibungszeitraums am 31. März 2014 sieben Millionen Menschen anzumelden
Das Vakuum durch Shutdown und misslungenen Start
- HealthCare.gov wurde am 1. Oktober 2013 gestartet, funktionierte aber nicht richtig, und am selben Tag begann der Shutdown der US-Bundesregierung
- Wegen des Shutdowns konnte niemand außerhalb des Kernteams von HealthCare.gov zur Unterstützung hinzukommen
- In der Zwischenzeit waren die Nachrichten vom Shutdown und dem schleppenden Startdesaster geprägt, und Informationslücken, Spekulationen und Sorgen nahmen zu
- Das Weiße Haus konnte nicht feststellen, was bei HealthCare.gov schiefgelaufen war, und wenn die Website scheiterte, konnte das zentrale Instrument zur Bereitstellung der Vorteile des Affordable Care Act für Hunderte Millionen Menschen ins Wanken geraten
- Der Shutdown endete am 17. Oktober, und erst dann konnte das externe Technikteam die tatsächliche Lage prüfen und mit der Arbeit beginnen
Das große Bild des Systems, das am ersten Vormittag sichtbar wurde
- Das Team frühstückte in der Navy Mess des Weißen Hauses und ging dann ins Büro des Chief of Staff, um Denis McDonough zu treffen
- Denis McDonough fragte direkt: „Könnt ihr es reparieren?“, und einige Teammitglieder antworteten angespannt mit „Ja“
- Danach ging es zum Hubert H. Humphrey Building, dem HHS-Hauptquartier, wo sie CMS-Leiterin Marilyn Tavenner und ihren Stab trafen
- Dort wurden die Struktur von HealthCare.gov, die wichtigsten funktionalen Komponenten sowie die Störungsstellen und übergeordneten Performance-Probleme besprochen, die der CMS-Führung bekannt waren
- Da die CMS-Führung aus Gesundheitspolitik-Experten und Verwaltungsleuten bestand, entsprachen die übermittelten Informationen vor allem Business-Metriken und Beschreibungen der Performance auf hohem Niveau
- Später am Vormittag fuhr das Team zum CMS-Hauptsitz in Woodlawn, Maryland, und traf dort auf die HealthCare.gov-Führung, darunter Michelle Snyder, Henry Chao und Dave Nelson
- Dort wurden nach und nach Informationen über Deployment-Probleme, Engpässe, Stellen, an denen Nutzer auf der Website „stecken blieben“, die MarkLogic-XML-Datenbank sowie die Deployment-Architektur und Servertypen sichtbar
Die betriebliche Realität im XOC
- Am Nachmittag ging es zum Exchange Operations Center in Columbia, Maryland, also zum XOC
- Das XOC war eine missionskontrollartige Zentrale für den Betrieb von HealthCare.gov, und dort hörte das Team den Technikern zu, die direkt mit der Website arbeiteten
- Die vor Ort bestätigten Probleme waren deutlich gravierender als zunächst erwartet
- Es gab mangelndes Vertrauen in Änderungen am Source Code
- Viele Teile der Website wurden durch komplexe Code-Generierungsverfahren erstellt, was eine sorgfältige Abstimmung zwischen den Teams erforderte
- Tests waren größtenteils manuelle Prozesse
- Releases und Deployments erforderten lange nächtliche Downtimes, und bei Fehlschlägen folgten lange Rollbacks
- Die zentrale Datenschicht hatte kein Schema
- Die Bereitstellung von Hosting-Ressourcen war langsam und nicht automatisiert
- Weder APM noch grundlegende Metriken wie CPU, Speicher, Festplatte oder Netzwerk lagen in einer Form vor, die die Teams einsehen konnten
- An diesem Punkt akzeptierte das Team, dass die Lage viel schlimmer war als ursprünglich angenommen, und Paul Smith notierte hastig das Gehörte in einem Moleskine-Notizbuch
Die Nacht, in der in den CGI-Büros New Relic angeschlossen wurde
- Am Abend ging es in die CGI-Büros in Herndon, Virginia
- CGI war der Hauptauftragnehmer für HealthCare.gov, und das Team traf dort Führungskräfte und Technikteams und stellte Fragen
- In diesem Treffen war es wichtig, dass das externe Technikteam das Vertrauen des CGI-Teams gewann
- Das CGI-Team stand unter Druck und war erschöpft
- Das Rettungsteam betonte, dass es nicht zum Beschuldigen, sondern zum Helfen gekommen war
- Es versuchte, auf Basis seiner Erfahrung mit Websites mit hohem Traffic technische Kompetenz zu zeigen
- Die Kernfrage lautete: „Was stimmt mit der Website nicht, und woher wisst ihr das?“, doch CMS und CGI konnten größtenteils nicht zeigen, an welchen konkreten Stellen im System einzelne Komponenten intern nicht wie erwartet funktionierten
- Das Team schlug vor, den vertrauten Monitoring-Dienst New Relic im Stil eines APM auf einigen Servern zu installieren
- Unter Umgehung des üblichen Release-Verfahrens installierten sie die Agenten direkt auf einigen ausgewählten Servern, nachdem ein CMS-Verantwortlicher bestätigt hatte, dass bereits eine New-Relic-Lizenz vorhanden war, und die Freigabe erteilt hatte
- Diejenigen, die bis nahe Mitternacht noch vor Ort waren, führten die Änderung durch, und auf dem New-Relic-Dashboard im Besprechungsraum begannen die ausgewählten „red shard“-Server bald, Metriken zu senden
- Zum ersten Mal wurden operative Echtzeit-Metriken wie plötzliche Spitzen bei der Request-Latenz, Fehlerraten und Requests pro Minute sichtbar, wodurch ein Systemzustand erkennbar wurde, der zuvor praktisch unsichtbar gewesen war
- Diese Metriken schufen die Grundlage dafür, Business-Metriken mit dem Systemzustand zu verknüpfen und Korrekturen und Maßnahmen zu priorisieren, die die größten Verbesserungen bringen konnten
Nach dem ersten 18-Stunden-Tag
- Nach dem Aufbruch aus Herndon hielt das Team gegen 2 Uhr morgens im stillen Roosevelt Room des Weißen Hauses eine kurze Nachbesprechung ab
- Zu diesem Zeitpunkt erkannte das Team, dass die Probleme nicht mit kurzfristiger Beratung zu lösen waren und dass es sich vorerst dieser Arbeit widmen musste, bis sich die Website erholt hatte
- Nach ein paar Stunden Schlaf fuhren sie am nächsten Morgen wieder nach Herndon
- Der erste Tag dauerte rund 18 Stunden, und ähnliche Marathons setzten sich auch danach fort
- Bis Ende Dezember wurde der tech surge über rund zweieinhalb Monate ausgeweitet, neue Teammitglieder kamen hinzu, und die Aktion half bei der Verbesserung von HealthCare.gov
- In diesem Jahr meldeten sich Millionen Menschen für Krankenversicherungsschutz an, für viele war das ein Novum
1 Kommentare
Meinungen auf Hacker News
Ursprünglich war beabsichtigt, dass jeder Bundesstaat seine eigene Börse betreibt und nur die Einwohner der Bundesstaaten, die das ablehnten, die Bundesbörse nutzen.
Anfangs richteten 36 Bundesstaaten keine eigene Börse ein 0, derzeit scheinen 20 Bundesstaaten einschließlich D.C. eigene Marketplaces zu betreiben 1.
Der Government Shutdown 2013, der verhinderte, dass externe Leute dem HealthCare.gov-Team des Bundes zu Hilfe kommen konnten, wurde von Senator Ted Cruz mit dem Ziel, den ACA zu behindern, vorangetrieben 2.
Ich habe das Gefühl, dass das amerikanische Prinzip „jeder Bundesstaat ist eigenständig“ manchmal zu weit geht.
Sie befürchteten, ein bundesweites Gesundheitssystem würde am Ende zu einer allgemeinen Krankenversicherung führen; nachdem sie den Kompromiss herausgeholt hatten, verweigerten sie die Umsetzung der Börsen in der Hoffnung, das Gesetz möge scheitern.
Aber das Gesetz scheiterte nicht, und sie sind bis heute unzufrieden damit.
Nachdem Bundesmittel als pauschale Zuschüsse an die Bundesstaaten weitergegeben wurden und die Bundesstaaten Programme wie TANF samt Anspruchsprüfung übernahmen 1, verschlechterten sich sowohl die Effizienz, mit der ein Dollar aus dem Bundeshaushalt tatsächlich als Unterstützung ankam, als auch Zahl und Höhe der Leistungen für die Empfänger deutlich.
Ich kenne die Begründung für die ACA-Marketplaces der Bundesstaaten nicht, aber historisch gesehen hat das Einbeziehen der Bundesstaaten die Möglichkeiten vergrößert, dass ein Mittelsmann ein Programm beschädigt und Geld anderswohin umleitet.
Texas hat zum Beispiel kostenlose Bundesmittel in Höhe von 5 bis 6 Milliarden Dollar pro Jahr abgelehnt, die die Bundesregierung für die Ausweitung von Medicaid bereitstellen wollte 2.
Es hieß wohl mehrfach, ein Versicherer habe wegen einiger weniger Patienten mit extrem hohen Behandlungskosten Verluste gemacht, und als diese Kosten so stark stiegen, dass die Preise erhöht wurden, wollte niemand mehr dieses Produkt kaufen.
Vor Kurzem habe ich versucht, diese Artikel wiederzufinden, konnte sie aber nicht mehr finden, sodass ich unsicher bin, ob ich mir das nur eingebildet habe.
Wenn man Geld hat und bereit ist, ein Geschäft abzuschließen, es aber nicht kann, dann ist dieses System gescheitert.
Ich erinnere mich daran, mit diesen Leuten zusammengearbeitet zu haben, als wir alle hineingezogen wurden, um das zu reparieren.
Gabe beim Coden in VIM zuzusehen war wie einem Meisterviolinisten zuzusehen, und bei der Arbeit mit Mikey habe ich die Macht von Metriken und SRE gesehen.
Aus einem Raum, in dem alle auf den jeweils nächsten Vendor zeigten, wurde eine Situation, in der tatsächlich Teile des Engpasses gefunden wurden.
Insgesamt fühlte es sich an, ein kaputtes System zu reparieren, ohne es für ein großes Refactoring offline nehmen zu können, als würde man einen Jogger operieren; es war eine wirklich raue Erfahrung.
Ein kleines Startup in D.C. war ungefähr der Subunternehmer des Subunternehmers des Subunternehmers für die Front-Landingpage, aber ich erinnere mich positiv daran, dass wir es immerhin geschafft haben, dass Leute auf healthcare.gov auf einer echten Seite landeten und nicht auf einer 500-Fehlerseite.
Wenn ich mich richtig erinnere, lag das an einem einzelnen Server mit Jekyll und einem Backup.
In heutiger Sprache war es „Static Page Generation“, weshalb sie auch auf kleiner Hardware gehostet werden konnte.
Damals galt das als ziemlich fortschrittliche Taktik, und vermutlich ist das gemeint.
Soweit ich weiß, wurde diese Site beim Start der Bundesbörse komplett ersetzt; die Landingpage selbst nahm keine personenbezogenen Daten entgegen und verarbeitete sie nicht, daher gab es bei der Bereitstellung keine großen Hürden.
Alles kam erst zum Stillstand, nachdem Nutzer tatsächlich nach Versicherungsprodukten zu suchen begannen.
Development Seed baute später auch ein anderes Projekt, von dem man vielleicht gehört hat: Mapbox; am Ende stellte sich das ganze Unternehmen darauf um.
Ich erinnere mich, in irgendeinem Podcast gehört zu haben, dass man „Backend-Timeout“-Fehler nicht mehr als Fehler anzeigte, sondern die Daten per E-Mail verschickte und den Nutzern sagte: „Alles klar, wir haben es erhalten. Kommen Sie später wieder und prüfen Sie es.“
Ich hielt das für sehr clever und merkte es mir als Ansatz, den man später in Notfällen verwenden kann.
Bei WebTV gab es etwas Ähnliches, als die Datenbank überlastet war: Man nahm alle Mail-Zustellserver der letzten Stufe herunter, die eine Datenbankverbindung brauchten, sodass die Mails auf den eingehenden SMTP-Servern in eine Queue gestellt wurden; später, als die Datenbanküberlastung vorbei war, wurden sie abgearbeitet.
Die Lehre lautet: Wenn man die Last eines Systems reduzieren will, das zwar für transaktionales Arbeiten entworfen wurde, aber gerade ausfällt, sollte man batchorientierte Verarbeitung aus einer Queue verwenden.
Die „Go Time“-Podcast-Folge zu diesem Thema war hervorragend und behandelte, wie Go eingesetzt wurde, um Teile der Website bereitzustellen.
Ich kann diese Folge und den Podcast sehr empfehlen.
https://changelog.com/gotime/154
Ich hatte darauf geklickt, weil ich eine interessante technische Diskussion erwartet hatte, aber Technik kam erst ziemlich spät zur Sprache.
Stattdessen waren die Blicke hinter die Kulissen des Prozesses unerwartet sehr interessant, und ich freue mich wirklich auf den nächsten Teil.
Es hat mir wirklich gefallen, diesen Artikel zu lesen.
Ich erinnere mich daran, wie vor zehn Jahren auf HN der GitHub-Quellcode der Website auseinandergenommen wurde: https://news.ycombinator.com/item?id=6540993
Was tatsächlich passiert ist, war nicht ideal, aber ich frage mich, ob es neben diesem Rückblick noch Material gibt, das genauer erklärt, was genau passiert ist und wie es behoben wurde.
Ich werde die nächsten Beiträge dieser Reihe weiter verfolgen.
Es fühlt sich ein bisschen wie Engineering-Kompetenz-Porn an, aber ich mag solche Geschichten.
Vor ein paar Jahren habe ich The Phoenix Project gelesen; es war fiktionalisiert und führte Agile und DevOps ziemlich unverblümt ein, aber für mich als Datenanalyst war es neu und gut, und wenn es ähnliche Empfehlungen gibt, würde ich sie gern lesen.
Um einen guten Auszug zu nennen: Dickerson brachte direkt außerhalb des Kontrollraums Regeln an der Wand an.
Regel 1: „Der War Room und die Meetings sind dazu da, Probleme zu lösen. Es gibt genug andere Orte, an denen man kreative Energie für Schuldzuweisungen aufwenden kann.“
Regel 2: „Die Person, die zu einem Thema sprechen sollte, ist nicht die ranghöchste Person, sondern die Person, die das Thema am besten kennt. Wenn jemand passiv dasitzt, während Manager und Führungskräfte mit weniger präzisen Informationen sprechen, sind wir vom Kurs abgekommen, und ich will das wissen.“ Dickerson erklärte später: „Wenn man die Manager aus dem Weg räumt, wollen die Engineers Probleme lösen.“
Regel 3: „Wir müssen uns auf die dringendsten Themen konzentrieren, die uns in den nächsten 24 bis 48 Stunden schaden werden.“
Die Lösung ist, solche Arbeiten nicht immer wieder denselben Firmen zu geben.
Es scheint offensichtlich, dass Firmen wie CGI und IBM nicht ausreichend kompetent sind; ich verstehe nicht, warum sie bei ähnlichen künftigen Verträgen nicht mit einem Bietverbot belegt werden.
Wenn man einen Vertrag vermasselt, sollte man für die nächsten zehn Jahre von allen Regierungsaufträgen ausgeschlossen werden.
Dann bekäme man tatsächlich funktionierende Technik, statt dass immer wieder derselbe Müll zirkuliert.
Dadurch wird es für kleinere Firmen schwierig, überhaupt teilzunehmen.
Oder man mischt die Teams einfach neu zusammen.
Bald wird niemand mehr übrig sein, der solche Arbeiten übernimmt.
„Bestimmte Technologien, darunter eine XML-Datenbank namens MarkLogic“ – eine XML-Datenbank für einen Kerndienst, den 300 Millionen Menschen nutzen?
Unheimlich.
Vermutlich lagen die Geschäftsregeln in XML vor und waren praktisch read-only, während die dynamischen Daten in einer relationalen Datenbank lagen.
Vielleicht ist das aber auch nur Wunschdenken.
Es könnte eine Konfigurationsdatenbank gewesen sein; da es aber so klingt, als seien die Probleme aus der Business-Logik gekommen, könnte selbst das problematisch gewesen sein.