10 Tahun Operasi Penyelamatan HealthCare.gov
(pauladamsmith.com)- Pada 18 Oktober 2013, untuk menghidupkan kembali HealthCare.gov yang macet sesaat setelah peluncuran, tim teknis kecil memulai pemeriksaan lapangan pertama di Gedung Putih; upaya ini kemudian dikenal sebagai “tech surge”
- Situs ini diluncurkan pada 1 Oktober 2013 tetapi tidak berfungsi dengan baik, dan karena shutdown pemerintah federal yang juga dimulai pada hari yang sama, dukungan eksternal baru bisa dikerahkan setelah 17 Oktober
- Pada hari pertama, tim berkeliling dari Gedung Putih, HHS, CMS, Exchange Operations Center, hingga kantor CGI untuk mengidentifikasi bottleneck dalam sistem besar yang melibatkan kontrak, komponen, aturan bisnis, dan prosedur deployment
- Di lapangan, risiko utama yang terungkap meliputi pengujian manual, deployment malam yang panjang beserta rollback, provisioning resource yang lambat, lapisan data inti tanpa skema, dan tidak adanya pemantauan real-time
- Setelah memasang New Relic secara langsung di sebagian server di kantor CGI, latency, error rate, dan jumlah request mulai terlihat untuk pertama kalinya; sesudah itu, operasi penyelamatan diperluas selama sekitar dua setengah bulan dan membantu memperbaiki situs
18 Oktober 2013, awal operasi penyelamatan
- Upaya pemulihan HealthCare.gov mulai berjalan sungguh-sungguh pada Jumat, 18 Oktober 2013 pukul 07.15 pagi, dari sekelompok kecil orang yang berkumpul di dekat pintu masuk West Wing Gedung Putih
- Kelompok awal mencakup Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman, dan Paul Smith, lalu di hari yang sama Mikey Dickerson bergabung lewat panggilan speakerphone yang panjang
- Sebagian datang dari luar pemerintahan dan sebagian bekerja di pemerintahan saat itu, tetapi semuanya adalah pakar teknis dengan pengalaman di startup atau organisasi teknologi besar
- Todd Park, yang saat itu menjabat sebagai CTO AS, memilih mereka untuk memperkuat pegawai pemerintah dan tim kontraktor yang membangun HealthCare.gov
- Misinya bukan “menyerbu seperti pasukan kavaleri”, melainkan lebih berupa dukungan rendah hati: masuk dengan tenang ke lapangan yang sudah penuh tekanan dan stres untuk mengumpulkan informasi serta melakukan penilaian
- Todd Park mengatakan 30 hari berikutnya akan sangat penting, dan targetnya adalah mendaftarkan 7 juta orang sebelum periode pendaftaran terbuka berakhir pada 31 Maret 2014
Kekosongan yang tercipta akibat shutdown dan kegagalan peluncuran
- HealthCare.gov diluncurkan pada 1 Oktober 2013, tetapi tidak berfungsi dengan benar, dan pada hari yang sama shutdown pemerintah federal dimulai
- Karena shutdown tersebut, orang-orang di luar tim inti HealthCare.gov tidak bisa masuk untuk membantu
- Sementara itu, berita dipenuhi oleh shutdown dan bencana peluncuran yang berjalan buruk, sehingga kekosongan informasi, spekulasi, dan kekhawatiran makin membesar
- Gedung Putih tidak dapat mengetahui apa yang salah dengan HealthCare.gov, dan jika situs itu gagal, sarana utama untuk menyalurkan manfaat Affordable Care Act kepada jutaan orang bisa terguncang
- Shutdown berakhir pada 17 Oktober, dan barulah setelah itu tim teknis eksternal dapat memeriksa situasi sebenarnya dan mulai bekerja
Gambaran besar sistem yang dipahami pada pagi hari pertama
- Tim sarapan di Navy Mess Gedung Putih lalu naik ke kantor Chief of Staff untuk bertemu Denis McDonough
- Denis McDonough langsung bertanya, “Apakah ini bisa diperbaiki?”, dan beberapa anggota tim yang tegang menjawab, “Bisa.”
- Setelah itu mereka berpindah ke Hubert H. Humphrey Building, kantor pusat HHS, untuk bertemu Marilyn Tavenner selaku pimpinan CMS beserta stafnya
- Di sana dibagikan informasi tentang struktur HealthCare.gov, komponen fungsional utama, titik gangguan yang diketahui pimpinan CMS, dan masalah performa tingkat tinggi
- Karena pimpinan CMS adalah pakar kebijakan kesehatan dan administrator, informasi yang disampaikan lebih dekat ke metrik bisnis situs dan penjelasan performa tingkat tinggi
- Menjelang siang mereka bergerak ke kantor pusat CMS di Woodlawn, Maryland, dan bertemu pimpinan HealthCare.gov seperti Michelle Snyder, Henry Chao, dan Dave Nelson
- Di sana mulai terungkap sedikit demi sedikit informasi tentang masalah deployment, bottleneck, titik tempat pengguna “tersangkut” di situs, database XML MarkLogic, serta arsitektur deployment dan jenis server
Realitas operasional yang terlihat di XOC
- Pada sore hari mereka berpindah ke Exchange Operations Center, atau XOC, di Columbia, Maryland
- XOC adalah hub bergaya mission control untuk operasional HealthCare.gov, dan di sana tim mendengar langsung kisah para teknisi yang menangani situs tersebut
- Masalah yang terkonfirmasi di lapangan jauh lebih serius daripada perkiraan awal
- Ada kurangnya kepercayaan terhadap perubahan source code
- Banyak bagian situs dibuat melalui prosedur code generation yang kompleks dan membutuhkan koordinasi cermat antartim
- Pengujian sebagian besar merupakan proses manual
- Release dan deployment membutuhkan downtime malam yang panjang, dan jika gagal akan diikuti rollback yang juga panjang
- Lapisan data inti tidak memiliki skema
- Provisioning resource hosting lambat dan tidak otomatis
- Bukan hanya APM, bahkan metrik dasar seperti CPU, memori, disk, dan jaringan pun tidak tersedia dalam bentuk yang dapat dilihat tim
- Pada titik ini tim menerima kenyataan bahwa situasinya jauh lebih buruk daripada perkiraan semula, dan Paul Smith buru-buru mencatat apa yang didengarnya di buku catatan Moleskine
Malam saat New Relic dipasang di kantor CGI
- Pada malam hari mereka berpindah ke kantor CGI di Herndon, Virginia
- CGI adalah kontraktor utama HealthCare.gov, dan tim bertemu pimpinan serta tim teknisnya untuk mengajukan pertanyaan
- Dalam pertemuan ini, penting bagi tim teknis eksternal untuk mendapatkan kepercayaan dari tim CGI
- Tim CGI berada di bawah tekanan dan kelelahan
- Tim penyelamat menekankan bahwa mereka datang bukan untuk menyalahkan, melainkan untuk membantu
- Mereka berusaha menunjukkan kapabilitas engineering berdasarkan pengalaman dengan situs web bertraffic tinggi
- Pertanyaan intinya adalah, “Apa yang salah dengan situs ini, dan bagaimana Anda mengetahuinya?”, tetapi CMS dan CGI sebagian besar tidak dapat menunjukkan bagian dalam sistem tempat komponen tertentu tidak bekerja seperti yang diharapkan
- Tim mengusulkan untuk mencoba memasang New Relic, layanan pemantauan bergaya APM yang sudah mereka kenal, pada sebagian server
- Mereka melewati prosedur rilis biasa dan memasang agent secara langsung pada beberapa server terpilih, lalu mendapatkan persetujuan setelah pimpinan CMS memastikan bahwa lisensi New Relic memang sudah ada
- Orang-orang yang masih bertahan hingga mendekati tengah malam melakukan perubahan itu, dan pada layar ruang rapat, dashboard admin New Relic segera mulai menerima metrik dari server “red shard” yang dipilih
- Untuk pertama kalinya, metrik operasional real-time seperti lonjakan request latency, error rate, dan jumlah request per menit terlihat, sehingga kondisi sistem yang sebelumnya nyaris tak tampak mulai terungkap
- Berkat metrik ini, menjadi mungkin untuk menghubungkan metrik bisnis dengan kondisi sistem, serta memiliki dasar untuk memprioritaskan perbaikan dan tindakan yang akan memberi dampak terbesar
Setelah hari pertama yang berlangsung 18 jam
- Setelah meninggalkan Herndon, sekitar pukul 2 pagi tim melakukan refleksi singkat di Roosevelt Room Gedung Putih yang sudah sunyi
- Pada titik ini, tim menerima bahwa masalahnya bukan sesuatu yang bisa selesai hanya dengan saran jangka pendek, dan bahwa mereka perlu mencurahkan waktu ke pekerjaan ini sampai situs pulih
- Setelah tidur beberapa jam, keesokan paginya mereka kembali menuju Herndon
- Jadwal hari pertama berlangsung sekitar 18 jam, dan setelah itu maraton serupa terus berlanjut
- Hingga akhir Desember, selama sekitar dua setengah bulan, tech surge diperluas dan anggota tim baru bergabung, yang membantu perbaikan HealthCare.gov
- Pada tahun itu, jutaan orang mendaftar untuk mendapatkan perlindungan asuransi kesehatan, dan bagi banyak di antaranya itu adalah pengalaman pertama
1 komentar
Komentar Hacker News
Niat awalnya adalah setiap negara bagian menjalankan bursanya sendiri, dan hanya penduduk negara bagian yang menolak yang memakai bursa federal.
Pada awalnya, 36 negara bagian tidak membuat bursa sendiri 0, dan sekarang tampaknya 20 negara bagian, termasuk D.C., menjalankan marketplace sendiri 1.
Shutdown pemerintah tahun 2013, yang membuat orang dari luar tim negara bagian HealthCare.gov tidak bisa masuk membantu, dipimpin oleh Senator Ted Cruz dengan tujuan mengganggu ACA 2
Saya merasa prinsip Amerika bahwa “setiap negara bagian itu independen” kadang berjalan terlalu jauh.
Mereka khawatir sistem layanan kesehatan federal pada akhirnya akan mengarah ke asuransi kesehatan universal, dan setelah mendapatkan kompromi itu, mereka menolak mengimplementasikan bursa sambil berharap undang-undangnya mati.
Namun undang-undangnya tidak mati, dan mereka masih tidak senang soal itu.
Akibat dana federal dialihkan menjadi block grant per negara bagian, lalu program seperti TANF dan pemeriksaan kelayakan diserahkan ke negara bagian 1, efisiensi setiap 1 dolar anggaran federal menjadi bantuan nyata, serta jumlah orang yang menerima bantuan dan besaran bantuannya, memburuk drastis.
Saya tidak tahu dasar marketplace negara bagian dalam ACA, tetapi secara historis, memasukkan negara bagian memperbesar ruang bagi perantara untuk merusak program dan mengalihkan uang ke tempat lain.
Misalnya, Texas menolak uang gratis 5–6 miliar dolar per tahun yang hendak diberikan pemerintah federal untuk perluasan Medicaid 2
Seingat saya, beberapa kali ada cerita bahwa sebuah perusahaan asuransi merugi karena sejumlah kecil pasien dengan biaya pengobatan sangat mahal, lalu ketika biaya itu membengkak dan harga dinaikkan, tidak ada yang mau membeli produk tersebut.
Belakangan saya mencoba mencari artikel-artikel itu, tetapi tidak bisa menemukannya lagi, jadi saya bingung apakah itu hanya imajinasi saya.
Saya punya uang dan mau bertransaksi, tetapi tidak bisa, jadi sistem ini gagal.
Saya masih ingat bekerja dengan orang-orang ini ketika semua orang ditarik masuk untuk memperbaikinya.
Gabe saat coding dengan VIM terlihat seperti pemain biola virtuoso, dan saat bekerja dengan Mikey saya melihat kekuatan metrik dan SRE.
Situasinya berubah dari semua orang di ruangan saling menunjuk vendor berikutnya menjadi benar-benar menemukan sebagian bottleneck.
Secara umum, memperbaiki sistem yang rusak tanpa bisa mematikannya untuk refactor besar terasa seperti mengoperasi orang yang sedang joging, dan itu pengalaman yang benar-benar keras.
Sebuah startup kecil di D.C. berada kira-kira sebagai subkontraktor dari subkontraktor dari subkontraktor yang menangani landing page depan, tetapi saya mengenang baik bahwa kami tetap bisa membuat orang yang datang ke healthcare.gov mendarat di halaman sungguhan, bukan halaman error 500.
Kalau ingatan saya benar, itu berkat satu server tunggal yang memakai Jekyll dan satu backup.
Dalam istilah sekarang, itu memakai pendekatan “static page generation”, sehingga bisa di-host bahkan di hardware kecil.
Pada saat itu, ini dianggap taktik yang cukup maju, dan mungkin inilah yang Anda ingat.
Setahu saya, situs itu sepenuhnya diganti ketika bursa federal dibuka, dan karena landing page itu sendiri tidak menerima atau memproses informasi pribadi, tidak ada rintangan besar dalam penyediaannya.
Semuanya berhenti ketika pengguna mulai benar-benar mencoba mencari produk asuransi.
Development Seed juga membuat proyek lain yang mungkin pernah Anda dengar kemudian, yaitu Mapbox, dan akhirnya seluruh perusahaan beralih ke sana.
Saya ingat pernah mendengar di sebuah podcast bahwa alih-alih menampilkan kegagalan “backend timeout” sebagai error, mereka mengubahnya menjadi mengirim data lewat email dan memberi tahu pengguna, “Baik, kami sudah menerimanya. Silakan kembali nanti untuk memeriksa.”
Saya pikir itu sangat cerdas, dan saya menyimpannya dalam ingatan sebagai pola yang bisa dipakai saat darurat nanti.
Hal serupa pernah terjadi di WebTV ketika database overload: semua server pengiriman email tahap akhir yang membutuhkan koneksi database dimatikan, sehingga email mengantre di server SMTP inbound, lalu dikosongkan setelah overload database mereda.
Pelajarannya adalah, untuk mengurangi beban pada sistem yang dirancang bekerja secara transaksional tetapi sedang gagal, gunakan pemrosesan berorientasi batch yang diproses dari queue.
Episode podcast “Go Time” tentang topik ini sangat bagus, dan membahas bagaimana Go digunakan untuk melayani sebagian situs
Saya sangat merekomendasikan episode dan podcast ini
https://changelog.com/gotime/154
Saya mengeklik karena mengira ini akan jadi diskusi teknis yang menarik, tetapi pembahasan teknisnya baru muncul cukup jauh di belakang
Sebagai gantinya, gambaran di balik layar dari prosesnya ternyata sangat menarik di luar dugaan, dan saya benar-benar menantikan bagian berikutnya
Saya sangat senang membaca tulisan ini
Saya jadi ingat 10 tahun lalu di HN saat orang-orang membedah habis kode sumber GitHub situs web itu: https://news.ycombinator.com/item?id=6540993
Apa yang sebenarnya terjadi memang tidak ideal, tetapi selain retrospektif ini saya penasaran apakah ada materi yang menjelaskan lebih rinci apa tepatnya yang terjadi dan bagaimana itu diperbaiki
Saya akan terus mencari tulisan-tulisan berikutnya dalam seri ini
Rasanya agak seperti pornografi kompetensi rekayasa, tapi saya suka cerita semacam ini
Beberapa tahun lalu saya membaca The Phoenix Project; buku itu dinovelkan dan cukup terang-terangan memperkenalkan Agile dan DevOps, tetapi bagi saya sebagai analis data isinya terasa baru dan bagus, jadi kalau ada rekomendasi serupa saya ingin membacanya
Salah satu kutipan bagusnya: Dickerson menempelkan aturan di dinding tepat di luar ruang kendali
Aturan 1: “War room dan rapat adalah tempat untuk memecahkan masalah. Ada banyak tempat lain untuk menghabiskan energi kreatif menyalahkan pihak lain.”
Aturan 2: “Orang yang harus berbicara tentang suatu isu bukanlah orang dengan jabatan tertinggi, melainkan orang yang paling memahami isu tersebut. Jika seseorang duduk pasif sementara para manajer dan eksekutif berbicara dengan informasi yang kurang akurat, berarti kita sudah keluar jalur, dan saya ingin mengetahuinya.” Dickerson kemudian menjelaskan, “Jika para manajer disingkirkan, para engineer ingin menyelesaikan masalah.”
Aturan 3: “Kita harus fokus pada isu paling mendesak yang akan merugikan kita dalam 24–48 jam ke depan.”
Solusinya adalah berhenti menyerahkan pekerjaan semacam ini terus-menerus kepada perusahaan yang sama
Jelas terlihat perusahaan seperti CGI dan IBM tidak cukup kompeten, jadi saya tidak mengerti mengapa mereka tidak dilarang ikut tender untuk kontrak serupa di masa depan
Jika mereka merusak kontrak, keluarkan saja dari semua kontrak pemerintah selama 10 tahun berikutnya
Dengan begitu kita akan mendapatkan teknologi yang benar-benar berfungsi, bukan hasil sampah yang terus berputar
Karena itu perusahaan kecil sulit ikut bersaing
Atau tinggal mencampur ulang timnya
Tidak lama lagi tidak akan ada siapa pun yang mau mengambil pekerjaan itu
“Teknologi tertentu termasuk database XML bernama MarkLogic”—database XML untuk layanan inti yang dipakai 300 juta orang?
Menyeramkan
Mungkin aturan bisnisnya ada di XML dan pada dasarnya hanya-baca, sementara data dinamisnya ada di database relasional
Mungkin ini hanya dugaan yang terlalu optimistis
Bisa saja itu database konfigurasi, tetapi karena masalahnya terdengar berasal dari logika bisnis, itu sendiri pun bisa menjadi masalah