HealthCare.gov Kurtarma Operasyonunun 10. Yılı

• 18 Ekim 2013’te, kullanıma açıldıktan hemen sonra duran HealthCare.gov’u yeniden işler hâle getirmek için küçük bir teknik ekip Beyaz Saray’da ilk saha incelemesine başladı; bu çalışma daha sonra “tech surge” olarak anıldı
• Site 1 Ekim 2013’te açılmıştı ancak düzgün çalışmıyordu; aynı gün başlayan federal hükümet kapanması nedeniyle dış destek ancak 17 Ekim’den sonra devreye alınabildi
• İlk gün ekip Beyaz Saray, HHS, CMS, Exchange Operations Center ve CGI ofislerini sırayla dolaşarak sözleşmelerin, bileşenlerin, iş kurallarının ve dağıtım süreçlerinin iç içe geçtiği büyük ölçekli sistemdeki darboğazları belirledi
• Sahada manuel testler, uzun gece dağıtımları ve geri almalar, yavaş kaynak sağlama, şemasız çekirdek veri katmanı ve gerçek zamanlı izleme eksikliği başlıca riskler olarak ortaya çıktı
• CGI ofisinde bazı sunuculara New Relic doğrudan kurulduktan sonra gecikme süreleri, hata oranları ve istek sayıları ilk kez görünür hâle geldi; sonraki yaklaşık iki buçuk ay boyunca kurtarma çalışmaları genişleyerek sitenin iyileştirilmesine katkı sağladı

---

18 Ekim 2013: Kurtarma çalışmasının başlangıcı

• HealthCare.gov kurtarma çalışması, 18 Ekim 2013 Cuma sabahı saat 07.15’te Beyaz Saray’ın West Wing girişinin yakınında toplanan küçük bir grupla fiilen başladı
• İlk grupta Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman ve Paul Smith vardı; Mikey Dickerson ise o gün ilerleyen saatlerde uzun bir hoparlörlü telefon görüşmesiyle ekibe katıldı
• Bazıları hükümet dışından gelmişti, bazıları ise o dönemde hükümette çalışıyordu; ancak hepsi startup ya da büyük teknoloji organizasyonu deneyimine sahip teknoloji uzmanlarıydı
• O dönemin ABD CTO’su Todd Park, HealthCare.gov’u inşa eden devlet çalışanları ve yüklenici ekipleri desteklemek için bu kişileri seçmişti
• Görev, “süvari gibi hücum etmek” değil; zaten baskı ve stresin yüksek olduğu sahaya sessizce girip bilgi toplayan ve değerlendirme yapan düşük profilli bir destek niteliğindeydi
• Todd Park, sonraki 30 günün kritik olduğunu söyledi; hedef, açık kayıt döneminin sona ereceği 31 Mart 2014’e kadar 7 milyon kişiyi kaydetmekti

Kapanma ve başarısız lansmanın yarattığı boşluk

• HealthCare.gov 1 Ekim 2013’te kullanıma açıldı ancak düzgün çalışmadı; aynı gün federal hükümet kapanması başladı
• Kapanma nedeniyle HealthCare.gov çekirdek ekibi dışındaki personel yardım için içeri giremedi
• Bu sırada haberler, kapanma ve yavaş ilerleyen lansman felaketiyle doldu; bilgi boşluğu, spekülasyonlar ve kaygılar büyüdü
• Beyaz Saray, HealthCare.gov’da neyin yanlış gittiğini anlayamıyordu; site başarısız olursa Affordable Care Act kapsamındaki faydaları milyonlarca kişiye ulaştırmanın temel aracı sarsılabilirdi
• Kapanma 17 Ekim’de sona erdi ve dış teknik ekip ancak o zaman gerçek durumu görüp çalışmaya başlayabildi

İlk günün sabahında görülen sistemin büyük resmi

• Ekip, Beyaz Saray Navy Mess’te kahvaltı ettikten sonra Chief of Staff ofisine çıkarak Denis McDonough ile görüştü
• Denis McDonough doğrudan “Bunu düzeltebilir misiniz?” diye sordu; ekip üyelerinden bazıları gergin bir hâlde “evet” yanıtını verdi
• Ardından HHS merkezi olan Hubert H. Humphrey Building’e giderek CMS yöneticisi Marilyn Tavenner ve ekibiyle görüştüler
• Bu toplantıda HealthCare.gov’un yapısı, başlıca işlevsel bileşenleri, CMS liderliğinin bildiği arıza noktaları ve üst düzey performans sorunları paylaşıldı
• CMS liderliği sağlık politikası uzmanları ve yöneticilerden oluştuğu için aktarılan bilgiler daha çok sitenin iş metrikleri ve üst düzey performans açıklamaları niteliğindeydi
• Sabahın ilerleyen saatlerinde Maryland, Woodlawn’daki CMS merkezine giderek Michelle Snyder, Henry Chao, Dave Nelson ve diğer HealthCare.gov liderleriyle görüştüler
• Burada dağıtım sorunları, darboğazlar, kullanıcıların sitede “takıldığı” noktalar, MarkLogic XML veritabanı, dağıtım mimarisi ve sunucu türleri hakkında bilgiler parça parça ortaya çıktı

XOC’de ortaya çıkan operasyon gerçeği

• Öğleden sonra Columbia, Maryland’deki Exchange Operations Center’a, yani XOC’ye gidildi
• XOC, HealthCare.gov operasyonları için bir görev kontrol merkezi gibiydi; ekip burada siteyle doğrudan ilgilenen teknisyenlerin anlattıklarını dinledi
• Sahada görülen sorunlar ilk tahminlerden çok daha ciddiydi
  • Kaynak kod değişikliklerine yönelik güven eksikliği vardı
  • Sitenin birçok bölümü karmaşık kod üretme süreçleriyle oluşturuluyor ve ekipler arasında hassas koordinasyon gerektiriyordu
  • Testler büyük ölçüde manuel süreçlerle yapılıyordu
  • Sürümler ve dağıtımlar uzun gece kesintileri gerektiriyor; başarısız olursa uzun geri alma süreçleri izliyordu
  • Çekirdek veri katmanında şema yoktu
  • Barındırma kaynaklarının sağlanması yavaştı ve otomatikleştirilmemişti
  • APM bir yana, CPU, bellek, disk ve ağ gibi temel metrikler bile ekibin görebileceği biçimde hazır değildi
• Bu noktada ekip, durumun ilk beklediklerinden çok daha kötü olduğunu kabul etti; Paul Smith duyduklarını aceleyle Moleskine defterine not etti

CGI ofisinde New Relic’in bağlandığı gece

• Akşam Virginia, Herndon’daki CGI ofisine gidildi
• CGI, HealthCare.gov’un ana yüklenicisiydi; ekip, liderlik ve teknik ekiplerle görüşerek sorular yöneltti
• Bu görüşmede dış teknik ekibin CGI ekibinin güvenini kazanması önemliydi
  • CGI ekibi baskı altındaydı ve yorgundu
  • Kurtarma ekibi suçlamaya değil, yardım etmeye geldiğini vurguladı
  • Yüksek trafikli web sitesi deneyimine dayanarak mühendislik yetkinliğini göstermeye çalıştı
• Temel soru “Sitede ne yanlış ve bunu nasıl biliyorsunuz?” idi; ancak CMS ve CGI, sistem içinde belirli bileşenlerin beklendiği gibi çalışmadığı noktaları çoğunlukla gösteremiyordu
• Ekip, aşina oldukları APM tarzı izleme hizmeti New Relic’in bazı sunuculara kurulmasını önerdi
• Normal sürüm süreci atlanarak seçilen bazı sunuculara agent doğrudan kuruldu; bir CMS lideri hâlihazırda New Relic lisansı bulunduğunu doğruladıktan sonra onay verdi
• Gece yarısına yakın saatlere kadar kalan kişiler değişikliği uyguladı; toplantı odasındaki ekranda görünen New Relic yönetici arayüzünde seçilmiş “red shard” sunucuları kısa süre içinde metrik göndermeye başladı
• İlk kez istek gecikmesindeki sıçramalar, hata oranları ve dakika başına istek sayısı gibi gerçek zamanlı operasyon metrikleri görünür oldu; o zamana kadar fiilen görünmeyen sistem durumu ortaya çıktı
• Bu metrikler sayesinde iş metrikleriyle sistem durumunu ilişkilendirmek ve en büyük iyileştirmeyi sağlayacak düzeltme ve aksiyonları önceliklendirmek için bir temel oluştu

18 saatlik ilk günün ardından

• Herndon’dan ayrıldıktan sonra ekip, sabaha karşı 02.00 civarında sessiz Beyaz Saray Roosevelt Room’da kısa bir değerlendirme yaptı
• Bu noktada ekip, sorunun kısa vadeli tavsiyelerle kapanacak ölçekte olmadığını ve site toparlanana kadar bir süre bu işe odaklanmaları gerektiğini kabul etti
• Birkaç saat uyuduktan sonra ertesi sabah yeniden Herndon’a gittiler
• İlk günün programı yaklaşık 18 saatti; sonrasında da benzer maratonlar devam etti
• Aralık sonuna kadar yaklaşık iki buçuk ay boyunca tech surge genişledi, yeni ekip üyeleri katıldı ve HealthCare.gov’un iyileştirilmesine yardımcı oldu
• O yıl milyonlarca kişi sağlık sigortası kapsamına kaydoldu; pek çoğu için bu bir ilkti

[GN⁺]

Hacker News yorumları

• Asıl niyet, her eyaletin kendi borsasını işletmesi ve yalnızca bunu reddeden eyaletlerin sakinlerinin federal borsayı kullanmasıydı.
  Başta 36 eyalet kendi borsasını kurmamıştı 0; şu anda ise D.C. dahil 20 eyaletin kendi pazar yerini işlettiği görülüyor 1.
  HealthCare.gov eyalet ekibi dışındaki kişilerin yardıma gelmesini engelleyen 2013 hükümet kapanması, Senatör Ted Cruz’un ACA’yı baltalama amacıyla öncülük ettiği bir işti 2.

  • Bir eyalet kurumunu yönetiyor olsaydım, federal hükümet kendi sistemini kullanmamı söylediğinde eyalet bütçesi harcamak yerine muhtemelen federal sistemi seçerdim.
    ABD’deki “eyaletler birbirinden bağımsızdır” ilkesinin bazen fazla ileri gittiğini düşünüyorum.
  • Eyaletlerin işlettiği borsa fikri zaten Cumhuriyetçilerle sınırda duran Demokratlar, özellikle de Arlen Specter için bir uzlaşma idi.
    Bunlar federal sağlık sisteminin sonunda evrensel sağlık sigortasına dönüşmesinden kaygılanıyordu; uzlaşmayı elde ettikten sonra ise yasanın ölmesini umarak borsaları uygulamayı reddettiler.
    Ama yasa ölmedi ve bundan hâlâ hoşnut değiller.
  • Eyaletlerin pazar yeri işletmesi meselesi, bana Clinton dönemindeki başarısız refah “reformunu” hatırlatıyor.
    Federal fonların eyalet bazlı blok hibelere aktarılması, TANF gibi programların ve uygunluk değerlendirmelerinin eyaletlere bırakılması sonucunda 1, federal bütçedeki 1 doların fiili yardıma dönüşme verimi de, yardım alan kişi sayısı ve miktarı da ciddi biçimde kötüleşti.
    ACA’daki eyalet pazar yerlerinin gerekçesini bilmiyorum, ama tarihsel olarak eyaletleri araya sokmak, aracıların programı bozması ve parayı başka yerlere yönlendirmesi için daha fazla alan açtı.
    Örneğin Texas, Medicaid genişlemesi için federal hükümetin vermek istediği yılda 5–6 milyar dolarlık bedava parayı reddetti 2.
  • Bu iş başladıktan yaklaşık 1–2 yıl sonra, bireysel eyalet pazar yerlerinden sigorta şirketlerinin çekildiğine dair haberlerin bir süre çok çıktığını net biçimde hatırlıyorum.
    Sanırım birkaç kez, bir sigorta şirketinin tedavi masrafları çok yüksek olan az sayıda hasta yüzünden zarar ettiği, bu maliyetler aşırı yükselince fiyatları artırdığı ve ardından kimsenin o ürünü satın almak istemediği anlatılıyordu.
    Yakın zamanda o yazıları aradım ama artık bulamadım; bu yüzden bunları hayal mi ettim diye kafam karışıyor.
  • Nevada borsası kullanılamaz düzeyde; geçen yıl kayıt olmayı başarmış olmama rağmen şimdi sigortasız durumdayım.
    Param da var, işlem yapma isteğim de var ama yapamıyorum; bu sistem başarısız.

• Bunu düzeltmek için herkes işin içine çekildiğinde bu insanlarla çalıştığımı hatırlıyorum.
  Gabe’in VIM ile kod yazışı usta bir kemancı gibiydi; Mikey ile çalışırken metriklerin ve SRE’nin gücünü gördüm.
  Odadaki herkesin bir sonraki tedarikçiyi suçladığı durumdan, darboğazların bir kısmını gerçekten bulmaya doğru geçildi.
  Genel olarak, bozuk bir sistemi büyük bir refaktör için çevrimdışı bile alamadan onarmak, koşu yapan birine ameliyat yapmak gibiydi; gerçekten sert bir deneyimdi.

  • 2014 civarında Velocity konferansında Mikey’nin bu hikâyeyi anlattığını gördüm; süreci nasıl açıkladığını dinlemek gerçekten çok ilginçti.

• D.C.’deki küçük bir startup, ön açılış sayfasını üstlenen taşeronun taşeronunun taşeronu gibi bir konumdaydı; yine de insanların healthcare.gov’da 500 hata sayfası yerine gerçek bir sayfaya ulaşmasını sağlayabilmiş olmamızı iyi hatırlıyorum.
  Yanlış hatırlamıyorsam bu, Jekyll kullanan tek bir sunucu ve bir yedek sayesinde olmuştu.

  • Şu anda devlet teknolojisi tarafında yüklenici olarak çalışan biri olarak, daha fazla Amerikalının şunu bilmesi gerektiğini düşünüyorum: tedarik kuralları yüzünden federal kurumlar kendi yazılımlarını geliştirmeyi neredeyse hiç yapamaz hale geliyor ve işlerin çoğu kelimenin tam anlamıyla çok katmanlı taşeronluğa gidiyor.
  • Borsa açılmadan önceki erken dönem healthcare.gov, D.C.’deki küçük web geliştirme şirketi Development Seed’in yaptığı bilgilendirici küçük bir siteydi.
    Bugünkü ifadeyle “statik sayfa üretimi” yöntemiydi; bu yüzden küçük donanımlarda bile barındırılabiliyordu.
    O dönemde oldukça ileri bir taktik sayılıyordu; muhtemelen hatırlanan şey de bu.
    Bildiğim kadarıyla federal borsa açılınca o site tamamen değiştirildi; açılış sayfasının kendisi kişisel bilgi almadığı veya işlemediği için sunulmasında büyük bir engel yoktu.
    Her şeyin durduğu nokta, kullanıcılar gerçekten sigorta ürünleri aramaya başladıktan sonraydı.
    Development Seed daha sonra duymuş olabileceğiniz bir başka projeyi, Mapbox’ı da yaptı ve sonunda şirketin tamamı o tarafa dönüştü.

• Bir podcast’te, “arka uç zaman aşımı” hatasını hata olarak göstermek yerine verileri e-postayla gönderip kullanıcıya “Tamam, aldık. Daha sonra gelip kontrol edin” dediklerinden bahsedildiğini hatırlıyorum.
  Bunun çok zekice olduğunu düşündüm ve ileride acil durumda kullanılabilecek bir yöntem olarak aklımda tuttum.
  WebTV’de veritabanı aşırı yüklendiğinde de benzer bir şey olmuştu: veritabanı bağlantısı gerektiren son aşama posta teslim sunucularının hepsi kapatıldı, böylece postalar gelen SMTP sunucularında kuyruğa alındı; daha sonra veritabanı yükü normale dönünce kuyruk boşaltıldı.
  Ders şu: işlem mantığıyla çalışacak şekilde tasarlanmış ama arıza yaşayan bir sistemin yükünü azaltmak istiyorsanız, kuyruktan işlenen toplu işlem odaklı işleme kullanın.

  • Evet, hatırladığım kadarıyla Go ile sunucudaki düz metin dosyalarına yazıyorlardı ve bu dosya ilgili süreç için bir kuyruk gibi çalışıyordu.
  • Başka bir yerde bahsedilen Changelog podcast’inin 36:16 noktasında açıklanıyor.

• Bu konuyla ilgili çıkan “Go Time” podcast bölümü harikaydı; sitenin bazı bölümlerini sunmak için Go’yu nasıl kullandıklarını ele alıyor
  Bu bölümü ve podcast’i şiddetle tavsiye ederim
  https://changelog.com/gotime/154

• İlginç bir teknik tartışma sanıp tıkladım ama teknik kısma epey sonradan gelindi
  Buna karşılık sürecin sahne arkası beklenmedik derecede ilginçti; sonraki bölümü gerçekten merak ediyorum

• Bu yazıyı okumak gerçekten çok hoşuma gitti
  10 yıl önce HN’de web sitesinin GitHub kaynak kodunu didik didik ettiğimiz günleri hatırlıyorum: https://news.ycombinator.com/item?id=6540993

• Gerçekte yaşananlar ideal değildi ama bu retrospektif dışında tam olarak ne olduğu ve nasıl çözüldüğünü daha ayrıntılı anlatan kaynaklar var mı merak ediyorum
  Bu serinin sonraki yazılarını da takip etmeyi düşünüyorum
  Biraz mühendislik yeterlilik pornosu gibi hissettiriyor ama böyle hikâyeleri seviyorum
  Birkaç yıl önce The Phoenix Project’i okumuştum; romanlaştırılmıştı ve Agile ile DevOps’u epey açık biçimde tanıtıyordu, ama bir veri analisti olarak benim için yeniydi ve hoşuma gitmişti; benzer öneriler varsa okumak isterim

  • Time, evet o Time Magazine, bu konuyu oldukça iyi işlemişti: https://time.com/10228/obamas-trauma-team/
    Güzel bir alıntı vermek gerekirse, Dickerson kontrol odasının hemen dışındaki duvara kuralları asmıştı
    Kural 1: “Savaş odası ve toplantılar sorunları çözmek içindir. Sorumluluk atmaya yaratıcı enerji harcanacak yerler zaten bolca var.”
    Kural 2: “Bir konu hakkında konuşması gereken kişi, rütbesi en yüksek olan değil, o konuyu en iyi bilen kişidir. Yöneticiler ve üst düzey yöneticiler daha az doğru bilgilerle konuşurken biri pasifçe oturuyorsa raydan çıkmışız demektir ve bunu bilmek isterim.” Dickerson daha sonra şöyle açıklamıştı: “Yöneticileri aradan çıkarınca mühendisler sorunları çözmek ister.”
    Kural 3: “Önümüzdeki 24 ila 48 saat içinde bize zarar verecek en acil konulara odaklanmalıyız.”

• Çözüm, bu tür işleri aynı şirketlere vermeye devam etmemek
  CGI, IBM gibi şirketlerin yeterince yetkin olmadığı açık görünüyor; neden benzer gelecekteki sözleşmelerde ihaleye girme yasağı almadıklarını anlamıyorum
  Bir sözleşmeyi batırırsan önümüzdeki 10 yıl boyunca tüm kamu sözleşmelerinden men edilirsin
  O zaman çöp gibi çıktılar döngüye sokulmaya devam etmek yerine gerçekten çalışan teknolojiye sahip oluruz

  • Avrupa kamu sektöründeki çeşitli sektörlerde IT danışmanlığı yapmış biri olarak, sözleşme rekabete açıldığında aynı sektörde büyük ölçekli proje deneyimine sahip olmak puan kazandırıyor, hatta bazen zorunlu şart oluyor
    Bu yüzden küçük şirketlerin rekabete katılması zorlaşıyor
  • “Tüm kamu sözleşmelerinden men” desen bile şirketin adını değiştirirsin, olur biter
    Ya da ekipleri birbirine karıştırırsın
  • Devlet çoğu zaman saçma sapan gereksinimlerle başarısızlığı garanti ediyor
    Yakında işi üstlenecek kimse kalmayacak

• “MarkLogic adlı bir XML veritabanı da dahil olmak üzere belirli teknolojiler” mi; 300 milyon kişinin kullandığı kritik bir hizmette XML veritabanı mı?
  Ürkütücü

  • O dönem NoSQL’in zirve zamanlarına yakındı ama bunun kelimenin tam anlamıyla böyle olduğuna pek ihtimal vermiyorum
    Muhtemelen iş kuralları XML’deydi ve fiilen salt okunurdu; dinamik veriler ise ilişkisel veritabanındaydı diye düşünüyorum
    Belki de bu sadece umut dolu bir tahmindir
  • Bunun ana veri deposu olduğunu sanmıyorum
    Bir yapılandırma veritabanı olmuş olabilir; ama sorun iş mantığından kaynaklanmış gibi duyulduğuna göre bu tek başına bile sorun yaratmış olabilir