HealthCare.gov बचाव के 10 साल

 (pauladamsmith.com)
1 पॉइंट द्वारा GN⁺ 2023-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 18 अक्टूबर 2013 को, लॉन्च के तुरंत बाद ठप पड़ गए HealthCare.gov को फिर से खड़ा करने के लिए एक छोटी टेक टीम ने White House में पहली ऑन-साइट जांच शुरू की, और इस काम को बाद में “tech surge” कहा गया
  • साइट 1 अक्टूबर 2013 को सार्वजनिक हुई थी, लेकिन ठीक से काम नहीं कर रही थी, और उसी दिन शुरू हुए federal government shutdown के कारण बाहरी मदद 17 अक्टूबर के बाद ही लगाई जा सकी
  • पहले दिन टीम ने White House, HHS, CMS, Exchange Operations Center और CGI दफ्तरों का क्रम से दौरा करते हुए contracts, components, business rules और deployment प्रक्रियाओं में उलझे बड़े सिस्टम की bottlenecks पहचानीं
  • मौके पर manual testing, लंबी रात की deployments और rollbacks, धीमी resource provisioning, schema-रहित core data layer और real-time monitoring की अनुपस्थिति बड़े risks के रूप में सामने आए
  • CGI दफ्तर में कुछ servers पर New Relic सीधे install करने के बाद latency, error rate और request count पहली बार दिखने लगे, और इसके बाद करीब ढाई महीनों तक बचाव कार्य बढ़ता गया तथा साइट सुधारने में योगदान देता रहा

18 अक्टूबर 2013, बचाव कार्य की शुरुआत

  • HealthCare.gov recovery का काम शुक्रवार, 18 अक्टूबर 2013 को सुबह 7:15 बजे White House West Wing के प्रवेश द्वार के पास इकट्ठे हुए एक छोटे समूह से सचमुच शुरू हुआ
  • शुरुआती समूह में Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman और Paul Smith थे, और उसी दिन बाद में Mikey Dickerson लंबे speakerphone call के जरिए शामिल हुए
  • कुछ लोग सरकार के बाहर से आए थे और कुछ उस समय सरकार में काम कर रहे थे, लेकिन सभी startup या बड़े tech organizations का अनुभव रखने वाले तकनीकी विशेषज्ञ थे
  • उस समय America के CTO Todd Park ने इन्हें HealthCare.gov बनाने वाले सरकारी कर्मचारियों और contractors की team को मजबूत करने के लिए चुना था
  • मिशन “घुड़सवार सेना की तरह धावा बोलने” वाला नहीं था, बल्कि पहले से दबाव और तनाव में चल रहे现场 में चुपचाप जाकर जानकारी जुटाने और आकलन करने वाली low-profile support जैसा था
  • Todd Park ने कहा कि अगले 30 दिन अहम हैं, और लक्ष्य open enrollment period खत्म होने की तारीख 31 मार्च 2014 तक 70 लाख लोगों का enrollment कराना था

Shutdown और launch failure से बना खालीपन

  • HealthCare.gov 1 अक्टूबर 2013 को launch हुआ, लेकिन ठीक से काम नहीं कर रहा था, और उसी दिन federal government shutdown शुरू हो गया
  • Shutdown की वजह से HealthCare.gov core team के बाहर के लोग मदद करने के लिए अंदर नहीं आ सके
  • इस बीच खबरें shutdown और धीरे-धीरे बढ़ती launch disaster से भरी रहीं, और information gap, अटकलें और चिंताएं बढ़ती गईं
  • White House यह समझ नहीं पा रहा था कि HealthCare.gov में क्या गड़बड़ है, और अगर साइट fail होती तो Affordable Care Act के benefits लाखों लोगों तक पहुंचाने का मुख्य माध्यम डगमगा सकता था
  • Shutdown 17 अक्टूबर को खत्म हुआ, और बाहरी tech team तभी वास्तविक स्थिति देख पाई और काम शुरू कर सकी

पहले दिन सुबह समझ आई सिस्टम की बड़ी तस्वीर

  • टीम ने White House Navy Mess में breakfast के बाद Chief of Staff office में जाकर Denis McDonough से मुलाकात की
  • Denis McDonough ने सीधे पूछा, “क्या आप इसे ठीक कर सकते हैं,” और team के कुछ सदस्यों ने तनाव में “हां” जवाब दिया
  • इसके बाद वे HHS headquarters, Hubert H. Humphrey Building गए और CMS प्रमुख Marilyn Tavenner तथा उनके staff से मिले
  • इस बैठक में HealthCare.gov की architecture, मुख्य functional components, CMS leadership को ज्ञात failure points और high-level performance problems साझा किए गए
  • CMS leadership में health policy experts और administrators थे, इसलिए दी गई जानकारी मुख्यतः साइट के business metrics और high-level performance explanations जैसी थी
  • सुबह के बाद के हिस्से में वे Maryland के Woodlawn स्थित CMS headquarters गए और Michelle Snyder, Henry Chao, Dave Nelson समेत HealthCare.gov leadership से मिले
  • यहां deployment issues, bottlenecks, वे points जहां users साइट पर “अटक” रहे थे, MarkLogic XML database, deployment architecture और server types की जानकारी धीरे-धीरे सामने आई

XOC में सामने आई operational reality

  • दोपहर में वे Columbia, Maryland के Exchange Operations Center, यानी XOC गए
  • XOC HealthCare.gov operations के लिए mission-control-style hub था, और टीम ने वहां साइट को सीधे संभालने वाले technologists की बातें सुनीं
  • मौके पर दिखी समस्याएं शुरुआती अनुमान से कहीं ज्यादा गंभीर थीं
    • source code changes को लेकर trust की कमी थी
    • साइट के कई हिस्से जटिल code generation procedures से बने थे, और teams के बीच बहुत सावधानी से coordination की जरूरत थी
    • testing ज्यादातर manual process थी
    • releases और deployments के लिए रात में लंबे downtime की जरूरत होती थी, और failure होने पर लंबा rollback करना पड़ता था
    • core data layer में schema नहीं था
    • hosting resource provisioning धीमी थी और automated नहीं थी
    • APM तो दूर, CPU, memory, disk और network जैसे basic metrics भी team को दिख सकें, इस रूप में मौजूद नहीं थे
  • इस समय तक team ने स्वीकार कर लिया कि स्थिति शुरुआती अनुमान से बहुत खराब है, और Paul Smith ने Moleskine notebook में सुनी हुई बातें जल्दी-जल्दी लिख लीं

CGI office में New Relic जोड़ने वाली रात

  • शाम को वे Virginia के Herndon स्थित CGI office गए
  • CGI HealthCare.gov का prime contractor था, और team ने leadership तथा tech team से मिलकर सवाल पूछे
  • इस मुलाकात में बाहरी tech team के लिए CGI team का trust हासिल करना अहम था
    • CGI team दबाव में थी और थक चुकी थी
    • rescue team ने जोर देकर कहा कि वे दोष देने नहीं, मदद करने आए हैं
    • उन्होंने high-traffic websites के अनुभव के आधार पर अपनी engineering क्षमता दिखाने की कोशिश की
  • मुख्य सवाल था, “साइट में क्या गड़बड़ है, और आपको यह कैसे पता है,” लेकिन CMS और CGI ज्यादातर यह नहीं दिखा पाए कि system के अंदर कौन-से specific components अपेक्षा के अनुसार काम नहीं कर रहे थे
  • टीम ने सुझाव दिया कि परिचित APM-style monitoring service New Relic को कुछ servers पर install करके देखा जाए
  • सामान्य release procedure को bypass करके चुने गए कुछ servers पर agent सीधे install किया गया, और CMS leader ने यह पुष्टि करने के बाद approval दिया कि New Relic license पहले से मौजूद है
  • आधी रात के करीब तक रुके लोगों ने changes लागू किए, और conference room screen पर New Relic admin screen में चुने गए “red shard” servers जल्द ही metrics भेजने लगे
  • पहली बार request latency spikes, error rate और requests per minute जैसे real-time operational metrics दिखे, और system की वह स्थिति सामने आई जो पहले लगभग अदृश्य थी
  • इन metrics की वजह से business metrics और system state को जोड़कर देखने, और सबसे बड़ा सुधार लाने वाले fixes और actions को prioritize करने का आधार मिला

18 घंटे के पहले दिन के बाद

  • Herndon से निकलने के बाद team ने सुबह करीब 2 बजे शांत White House Roosevelt Room में संक्षिप्त retrospective किया
  • इस समय तक team ने मान लिया कि समस्या ऐसी नहीं है जो थोड़े समय की सलाह से खत्म हो जाएगी, और साइट के recover होने तक कुछ समय तक उन्हें इसी काम में लगे रहना होगा
  • कुछ घंटे सोने के बाद वे अगली सुबह फिर Herndon के लिए रवाना हुए
  • पहले दिन का schedule करीब 18 घंटे का था, और इसके बाद भी ऐसे ही marathon sessions जारी रहे
  • December के अंत तक करीब ढाई महीनों में tech surge बढ़ा, नए team members जुड़े, और इसने HealthCare.gov सुधारने में मदद की
  • उस साल लाखों लोगों ने health insurance coverage में enrollment कराया, और कई लोगों के लिए यह पहली बार था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-21
Hacker News की रायें

  • मूल इरादा यह था कि हर राज्य अपना खुद का exchange चलाए, और जिन राज्यों ने मना किया उनके निवासी ही federal exchange का इस्तेमाल करें
    शुरुआत में 36 राज्यों ने अपना exchange नहीं बनाया था 0, और अभी लगता है कि D.C. समेत 20 राज्य अपना marketplace चला रहे हैं 1
    2013 का government shutdown, जिसने HealthCare.gov की state team के बाहर के लोगों को मदद के लिए अंदर आने से रोक दिया था, Senator Ted Cruz ने ACA में बाधा डालने के उद्देश्य से lead किया था 2

    • अगर मैं state government agency चला रहा होता, तो जब federal government कहती कि बस हमारा system इस्तेमाल कर लो, मैं state budget खर्च करने के बजाय federal system ही चुनता
      मुझे लगता है कि अमेरिका का “हर राज्य अपने-आप में स्वतंत्र है” वाला सिद्धांत कभी-कभी बहुत आगे चला जाता है
    • state-run exchange खुद Republican और सीमा पर खड़े Democrat, खासकर Arlen Specter, के लिए एक समझौता था
      उन्हें चिंता थी कि federal healthcare system आखिरकार universal healthcare की ओर ले जाएगा, और समझौता हासिल करने के बाद उन्होंने कानून के मर जाने की उम्मीद में exchange implementation से इनकार कर दिया
      लेकिन कानून मरा नहीं, और वे अब भी इससे नाखुश हैं
    • राज्यों द्वारा marketplace चलाने की बात सुनकर Clinton दौर की असफल welfare “reform” याद आती है
      federal funds को state-level block grants के रूप में सौंपने, और TANF जैसे programs तथा eligibility screening को राज्यों के जिम्मे करने के परिणामस्वरूप 1, federal budget के हर $1 का वास्तविक सहायता में बदलने की efficiency, साथ ही सहायता पाने वाले लोगों की संख्या और राशि, काफी खराब हो गई
      ACA के state marketplace का आधार मुझे नहीं पता, लेकिन इतिहास में जब राज्यों को बीच में लाया गया है, तो middleman के लिए program बिगाड़ने और पैसा कहीं और मोड़ने की गुंजाइश बढ़ी है
      उदाहरण के लिए Texas ने Medicaid expansion के लिए federal government से मिलने वाले सालाना $5–6 billion के free money को ठुकरा दिया था 2
    • मुझे साफ याद है कि यह शुरू होने के करीब 1–2 साल बाद कुछ समय तक individual state marketplaces से insurers के बाहर निकलने की बहुत सी खबरें आई थीं
      कई बार ऐसी खबरें आई थीं कि किसी insurer को इलाज पर बहुत ज्यादा खर्च करने वाले थोड़े-से patients की वजह से नुकसान हुआ, और जब वह लागत इतनी बढ़ गई कि कीमतें बढ़ानी पड़ीं, तो कोई भी वह product खरीदना नहीं चाहता था
      हाल ही में मैंने वे articles ढूंढे, लेकिन अब नहीं मिले, इसलिए उलझन है कि कहीं यह सब मेरी कल्पना तो नहीं था
    • Nevada exchange इस्तेमाल करने लायक नहीं है, इसलिए पिछले साल enroll करने में सफल होने के बावजूद अभी मैं uninsured हूं
      मेरे पास पैसे भी हैं और transaction करने की इच्छा भी, लेकिन कर नहीं सकता, इसलिए यह system failure है

  • जब इसको ठीक करने के लिए सबको खींचकर लाया गया था, तब इन लोगों के साथ काम करने की यादें अब भी हैं
    Gabe को VIM में code करते देखना किसी महान violinist जैसा था, और Mikey के साथ काम करते हुए metrics और SRE की ताकत दिखी
    कमरे में मौजूद हर कोई अगले vendor पर उंगली उठा रहा था, वहां से बात बदलकर bottleneck के कुछ हिस्सों को सचमुच ढूंढ निकालने तक पहुंची
    कुल मिलाकर, एक टूटे हुए system को बड़े refactoring के लिए offline तक न कर पाने की हालत में ठीक करना किसी jogging करते व्यक्ति की surgery करने जैसा था, और यह सच में बेहद rough experience था

    • 2014 के आसपास Velocity conference में Mikey को इस कहानी पर talk देते देखा था, और उसकी process को समझाते हुए सुनना वाकई दिलचस्प था

  • D.C. का एक छोटा startup front landing page संभालने वाले subcontractor के subcontractor के subcontractor जैसा था, फिर भी यह अच्छी याद है कि हम लोगों को healthcare.gov पर 500 error page के बजाय असली page तक पहुंचा पाए
    अगर मेरी याद सही है, तो यह Jekyll इस्तेमाल करने वाले एक single server और एक backup की वजह से था

    • अभी government tech में contractor के तौर पर काम करते हुए, मुझे लगता है कि ज्यादा Americans को पता होना चाहिए कि procurement rules की वजह से federal agencies अपना software development लगभग कर ही नहीं पातीं, और ज्यादातर काम literally multi-level subcontracting में चला जाता है
    • exchange launch से पहले का शुरुआती healthcare.gov, D.C. की छोटी web development firm Development Seed ने बनाया हुआ एक छोटा informational site था
      आज की भाषा में यह “static page generation” तरीका था, इसलिए इसे छोटे hardware पर भी host किया जा सकता था
      उस समय इसे काफी advanced tactic माना जाता था, और शायद आप इसी को याद कर रहे हैं
      मेरी जानकारी में federal exchange खुलते ही वह site पूरी तरह replace हो गई थी, और landing page खुद personal information लेता या process नहीं करता था, इसलिए उसे serve करने में कोई बड़ी मुश्किल नहीं थी
      सब कुछ तब रुका जब users ने सच में insurance products खोजने की कोशिश शुरू की
      Development Seed ने बाद में एक और project भी बनाया जिसे आपने शायद सुना होगा, Mapbox, और आखिर में पूरी company उसी दिशा में shift हो गई

  • मुझे याद है कि किसी podcast में सुना था कि “backend timeout” failure को error की तरह दिखाने के बजाय, उन्होंने data को email से भेजने और user को “ठीक है, हमें मिल गया। बाद में आकर check करें” बताने का तरीका अपनाया
    मुझे यह बहुत smart लगा, और बाद में emergency में इस्तेमाल करने लायक pattern के रूप में याद रख लिया
    WebTV में database overload होने पर भी कुछ ऐसा ही हुआ था: database connection की जरूरत वाले अंतिम चरण के mail delivery servers सब बंद कर दिए गए ताकि mail inbound SMTP servers पर queue हो जाए, और बाद में database overload हटने पर उसे flush किया गया
    सबक यह है कि transactional तरीके से काम करने के लिए design किए गए लेकिन fail हो रहे system का load घटाने के लिए, queue से process होने वाली batch-oriented processing इस्तेमाल करें

    • हां, मेरी याद में वे Go से server की plain text file में लिख रहे थे, और वह file उस process की queue की तरह काम कर रही थी
    • कहीं और mention किए गए Changelog podcast के 36:16 mark पर इसकी explanation है

  • इस विषय पर आया “Go Time” podcast episode शानदार था, और इसमें बताया गया कि साइट के कुछ हिस्सों को serve करने के लिए Go का इस्तेमाल कैसे किया गया
    इस episode और podcast की जोरदार सिफारिश करता/करती हूं
    https://changelog.com/gotime/154

  • मैंने सोचा था कि कोई दिलचस्प technical चर्चा होगी, इसलिए click किया, लेकिन tech की बात काफी बाद में आई
    इसके बजाय process की behind-the-scenes झलक उम्मीद से कहीं ज्यादा दिलचस्प निकली, और अगले हिस्से का सच में इंतजार है

  • यह लेख पढ़ना सच में अच्छा लगा
    10 साल पहले HN पर वेबसाइट के GitHub source code को बारीकी से खंगालने की बात याद आ गई: https://news.ycombinator.com/item?id=6540993

  • असल में जो हुआ वह आदर्श नहीं था, लेकिन इस retrospective के अलावा क्या कोई ऐसा material है जो ज्यादा detail में बताता हो कि ठीक-ठीक क्या हुआ और उसे कैसे ठीक किया गया?
    इस series के अगले लेख भी मैं देखते रहने वाला/वाली हूं
    थोड़ा engineering competence porn जैसा लगता है, लेकिन मुझे ऐसी कहानियां पसंद हैं
    कुछ साल पहले मैंने The Phoenix Project पढ़ी थी; वह novelized थी और Agile और DevOps को काफी साफ तौर पर introduce करती थी, लेकिन एक data analyst के रूप में मेरे लिए वह नई और अच्छी थी, और अगर ऐसी ही कोई recommendations हों तो पढ़ना चाहूंगा/चाहूंगी

    • Time, हां वही Time Magazine, ने इस मामले को काफी अच्छे से cover किया था: https://time.com/10228/obamas-trauma-team/
      एक अच्छा अंश यह है कि Dickerson ने control room के ठीक बाहर दीवार पर rules लगा दिए थे
      नियम 1: “war room और meetings समस्याएं हल करने की जगह हैं। दोष मढ़ने में creative energy खर्च करने के लिए और भी बहुत-सी जगहें हैं।”
      नियम 2: “किसी issue पर बोलने वाला व्यक्ति सबसे senior पद वाला नहीं, बल्कि वह होना चाहिए जो उस issue को सबसे अच्छी तरह जानता हो। अगर management और executives कम accurate जानकारी के आधार पर बोल रहे हों और कोई चुपचाप बैठा रहे, तो हम track से भटक गए हैं, और मैं यह जानना चाहता हूं।” Dickerson ने बाद में समझाया, “managers को रास्ते से हटा दें, तो engineers समस्या हल करना चाहते हैं”
      नियम 3: “हमें उन सबसे urgent issues पर focus करना चाहिए जो अगले 24–48 घंटों में हमें नुकसान पहुंचाएंगे।”

  • हल यह है कि ऐसे काम बार-बार उन्हीं कंपनियों को न दिए जाएं
    CGI, IBM जैसी कंपनियां पर्याप्त competent नहीं हैं, यह साफ लगता है; समझ नहीं आता कि ऐसे future contracts में उन्हें bidding ban क्यों नहीं किया जाता
    अगर कोई contract बिगाड़ता है, तो उसे अगले 10 साल तक सभी government contracts से बाहर कर दीजिए
    तब घटिया output बार-बार घूमता रहने के बजाय हमारे पास सच में काम करने वाली technology होगी

    • यूरोप के public sector की कई industries में IT consulting करने के अनुभव से कहूं तो, जब contract competition खोला जाता है, तो उसी industry के large-scale project experience के लिए points मिलते हैं, या कभी-कभी वह mandatory requirement भी होता है
      इसलिए छोटी कंपनियों के लिए competition में हिस्सा लेना मुश्किल हो जाता है
    • “सभी government contracts से ban” कहने पर भी company बस नाम बदल सकती है
      या फिर teams को mix कर सकती है
    • सरकार अक्सर बेहूदा requirements के साथ failure को guaranteed बना देती है
      जल्द ही काम लेने वाला कोई बचेगा ही नहीं

  • “MarkLogic नाम के XML database सहित कुछ specific technologies” — 30 करोड़ लोगों द्वारा इस्तेमाल की जाने वाली core service में XML database?
    डरावना है

    • वह समय NoSQL के peak के आसपास जरूर था, लेकिन मुझे नहीं लगता कि बात सचमुच वैसी रही होगी
      शायद business rules XML में थे और लगभग read-only थे, जबकि dynamic data relational database में रहा होगा
      शायद यह सिर्फ मेरी hopeful guess हो
    • मुझे नहीं लगता कि वह primary data store रहा होगा
      वह configuration database हो सकता था, लेकिन problem business logic से आई लगती है, तो अपने-आप में वह भी समस्या हो सकती थी