HealthCare.gov: сайтът не беше спасен само с още хора

Реален и публичен случай. Hábil не е участвал в HealthCare.gov. Анализираме го въз основа на докладите на правителството на Съединените щати и на пресата; източниците са в края.

Полунощ е на 1 октомври 2013 г. Наетият персонал, който оперира системата за акаунти и идентичност на HealthCare.gov, гледа как сайтът тръгва. Току-що е отворил и през него милиони хора трябва да сравнят и да сключат здравна застраховка. Един от тях щеше да го разкаже така пред одиторите: «Седяхме в офиса в полунощ, когато започна да работи, и не изглеждаше добре. Всичко на екраните ни ставаше червено» (собствен превод) [1].

Този ден на сайта влязоха едновременно 250 000 потребители, многократно повече от планираното. Сривовете започнаха два часа след отварянето. В края на деня, според доклада на Генералния инспектор на Министерството на здравеопазването на Съединените щати, само шест души успяха да подадат заявление и да изберат план [1].

Шест. В сайта, който трябваше да обслужи милиони хора в 36 щата [1].

Това е историята как този сайт се възстанови за около два месеца. Не я разказвам заради политиката, нито заради здравното осигуряване. Разказвам я, защото всеки директор по технологиите е бил, в по-малък мащаб, в същата зала: система, която не може да се провали, дата, която не мърда, и някой на масата, който казва «да добавим още хора». Интересното в случая е, че това вече е било опитано и само по себе си не е стигнало. Сайтът се възстанови, когато, освен че се добавиха хора, се промени и начинът на работа: малко ядро от опитни инженери, интегрирано на една маса с агенцията и изпълнителите, метрики за цялата система и безмилостно орязани приоритети. Одиторите посочват няколко причини, не една [1].

Седемдесет и два часа преди старта

Проблемът не започна на 1 октомври. Правителствените одитори го проследяват години назад. Генералният инспектор (OIG, службата, която одитира Министерството на здравеопазването) интервюира 86 служители и изпълнители и прегледа хиляди документи. Основният му извод се побира в един ред: най-сериозното беше липсата на ясно ръководство, която забави решенията, остави задачите лошо дефинирани и попречи да се види размерът на проблема, докато той растеше [1].

Последните дни преди старта изглеждат написани за филм.

На 24 септември отговорничката за информационната сигурност на агенцията, която изграждаше сайта (CMS, Центровете за услуги по Medicare и Medicaid), предупреди, че един централен компонент не отговаря в разумна степен на изискванията за сигурност. На 27-и, вместо обичайно разрешение, Администраторката на CMS подписа временно разрешение за работа за шест месеца [1].

На 26 септември, по-малко от пет дни преди старта, техници на CMS направиха тестове за натоварване и откриха, че сайтът издържа много по-малко едновременни потребители от планираното. Отидоха с кола направо до офисите на доставчика на инфраструктура и му поискаха да удвои целия капацитет за 72 часа. Един мениджър на доставчика го разказа така: «Искането беше да удвоим всичко 72 часа преди старта. […] Наемахме самолети, за да докараме хардуер, който беше предназначен за други клиенти» (собствен превод) [1].

На 29 септември системата за акаунти и идентичност, вратата, през която трябваше да мине всеки потребител, претърпя сривове. Същия ден Администраторката на CMS писа на главния технологичен директор на Съединените щати, че сайтът ще бъде готов на 1 октомври [1].

Има една подробност, която докладът подчертава и която важи за всяка компания: мнозина в екипа вярваха, че датата на сайта е записана в закона. Не беше. Законът изискваше покритието да започне най-късно на 1 януари 2014 г. и оставяше на Министерството на здравеопазването да определи периода за записване, който по силата на подзаконова уредба започна на 1 октомври 2013 г. [1]. Отгоре тежеше и политиката: Белият дом публично се беше ангажирал с тази дата, а в Министерството се опасяваха, че едно забавяне ще даде аргументи на онези, които искаха да отменят закона в Конгреса [1]. Датата, която никой не смееше да помръдне, не идваше от закона, а от подзаконова уредба и от политиката. И никой в ръководството на CMS не обсъди официално преместването ѝ [1].

И още една: нямаше пълни тестове от край до край. Един изпълнител го обобщи пред одиторите: «Тестовете от край до край са критични. Да не ги направиш е самоубийство» (собствен превод) [1].

Добавянето на хора вече беше опитано

Ето фактът, който почти никой не разказва за този случай.

През август 2013 г., два месеца преди старта, CMS видя, че проектът сериозно изостава, и реагира така, както би реагирала почти всяка организация: временно разпредели още 60 души от други звена към 51-те, които вече работеха по сайта. Увеличение със 117 % [1].

Не стигна. Самият доклад записва какво са изпитвали някои от участниците: че вече е късно да се включват други заради стръмната крива на обучение и че им е било неудобно «да вкарат други в една бъркотия» (собствен превод) [1].

През 1975 г. Frederick P. Brooks Jr., който беше ръководил разработката на операционната система OS/360 в IBM, написа в The Mythical Man-Month фраза, известна днес като закона на Brooks: «Добавянето на хора към закъснял софтуерен проект го забавя още повече» (собствен превод) [5]. Разсъжденията му: работата не се разделя на независими парчета, всеки нов човек има нужда някой да му обясни, а каналите за комуникация растат по-бързо от екипа.

Нека бъдем точни. Докладът на OIG не цитира Brooks и не може да се твърди, че тези 60 души са забавили сайта. Онова, което той документира, е, че добавянето им късно, без ясно ръководство и върху един безпорядъчен проект, не предотврати развръзката. Връзката с Brooks е моя и я предлагам като прочит, не като констатация на одиторите.

Две седмици на сляпо

След 1 октомври първата реакция отново беше да се изпратят още хора. След няколко дни персонал на CMS и на основния изпълнител се настани в командния център на изпълнителя в Херндън, Вирджиния, а постепенно се присъединиха и други изпълнители [1].

Но имаше дълбок проблем: никой не виждаше системата като цяло. Всеки изпълнител наблюдаваше собствената си част и не можеше да вижда останалите, макар че всички работеха заедно. Имаше няколко «командни центъра» на различни места, един в Херндън и друг в Кълъмбия, Мериленд, всеки със своите инструменти, и нито един ръководител или екип с поглед върху цялата система и с правомощия да действа. Никой не изпълняваше официално ролята на системен интегратор [1].

Един от инженерите, които щяха да дойдат по-късно, го каза на конференция през 2014 г.: «Нямаше къде да се провери дали сайтът работи днес или не, освен CNN, от който буквално научавахме за проблемите през голяма част от времето в началото» (собствен превод) [1].

За да стане още по-сложно, сутринта на старта федералното правителство спря работа поради липса на бюджет. Спирането продължи 16 дни, а персоналът на ключовите звена на проекта се сви до около една трета [1].

Междувременно сайтът почти не записваше хора. Според TIME през целия октомври чрез федералния пазар са се записали 26 794 души [4]. А реалният капацитет, според член на екипа, който по-късно го оправи, бил «може би няколко хиляди потребители» (собствен превод), докато официалната цифра говореше за 50 000 [4].

17 октомври: да се кърпи или да се изхвърли?

На 17 октомври, според реконструкцията на журналиста Steven Brill в TIME, в Белия дом се обсъждало дали си струва сайтът да се поправя, или да се изхвърли и да се започне от нулата [4]. Същия ден Todd Park, тогава технологичен директор на Белия дом, смени работата си, без да сменя кабинета си: «На 17 октомври преминах от технологичен директор на Белия дом към човек, който на пълно работно време поправя HealthCare.gov» (собствен превод) [4].

Park събра група инженери, които не бяха участвали в изграждането. OIG ги описва като «няколко ръководители и инженери от водещите технологични компании» (собствен превод) [1]. Сред тях беше Mikey Dickerson, инженер по надеждност на сайтовете в Google, тоест човек, чиято ежедневна работа беше един огромен сайт да не пада [4]. Една подробност от доклада казва много за това как са дошли: до голяма степен са дарили времето си, макар че, заради правилата на правителството за възлагане, им е било плащано на час чрез един от изпълнителите [1].

Първото, което направиха, не беше да програмират поправки. Беше да измерват. В нощта на петък, 18 октомври, според TIME, Gabriel Burt, технологичен директор на компания за анализ на данни, и други прекарали около пет часа в изграждане на табло, защото сайтът нямал бърз начин да се разбере какво се случва [4]. С това табло откриха една от първите бързи поправки: в нощта на 22 октомври времето за зареждане на една страница падна от осем секунди на две [4].

Същия ден, 22 октомври, министърката на здравеопазването публично обяви онова, което нарече «tech surge», технологична вълна: Jeff Zients, администратор с опит в управлението на компании, се присъединяваше като съветник по управлението, заедно с «експерти и специалисти» от правителството, от изпълнителите и от индустрията, «включително ветерани от водещите компании в Силициевата долина», и «шепа» членове на програмата Presidential Innovation Fellows на Белия дом (собствен превод) [3].

Първото важно решение, взето с тази група: да се рефакторира съществуващият код, а не да се изгражда отначало. Да се започне наново щеше да струва време, каквото нямаше, а персоналът на агенцията и на изпълнителите беше готов да работи с новодошлите [1].

Стаята в Кълъмбия

В края на октомври командният център се премести в зала от около 370 квадратни метра (4000 квадратни фута), която един от изпълнителите наемаше в офис парк в Кълъмбия, Мериленд [4]. С времето тя щеше да се превърне в официалния оперативен център на сайта [1].

Dickerson свика първата среща на крак на 24 октомври. Оттам нататък, всеки ден, включително през уикендите, през октомври и ноември: в 10:00 и в 18:30, по около 45 минути всяка, с телефонна линия, отворена 24 часа, за да може който работеше на друго място да говори с останалите веднага щом възникне нещо [4].

Правилата той закачи на стената, пред контролната зала. TIME ги възпроизвежда [4]:

1. «Залата и срещите са за решаване на проблеми. Има много други места, където хората посвещават творческата си енергия на прехвърлянето на вината».
2. «Тези, които трябва да говорят, са хората, които знаят най-много по даден въпрос, а не най-високопоставените».
3. «Трябва да се съсредоточим върху най-спешното, като нещата, които ще ни навредят през следващите 24 до 48 часа».

(Трите правила: собствен превод.)

Докладът на OIG описва същата промяна с други думи. Възприета е култура «без значка и без длъжност» (собствен превод): задачите се разпределяли според умението и наличността, независимо дали човекът е служител на правителството, или на някой изпълнител [1]. За първи път техническият екип и екипът по политиките на програмата работеха заедно. Един от инженерите го описа така: «Хората по политиките разгадаваха съобщенията за грешка. Какво правеше или не правеше кодът? Какво трябваше да се случи?» (собствен превод) [1]. А агенцията нае технически системен интегратор, някой, чиято работа беше всички части да си говорят. Според доклада това подобрило координацията «по общо мнение» (собствен превод) [1].

Има една фраза на служител на CMS, записана от одиторите, която обобщава случая по-добре от всеки анализ: «На CMS не ѝ трябваше технологична вълна; трябваше ни организационна вълна» (собствен превод) [1].

А натискът да се добавят още хора? Той продължаваше. Brill го разказва така: Zients имал «карт бланш да добавя ресурси», но да сложиш десет души на поправка, която на един програмист би отнела десет дни, не я превръща в проект за един ден. «Програмирането не работи така» (собствен превод) [4].

Часовникът на ноември

На 25 октомври Zients публично постави цел: сайтът щеше да работи добре за огромното мнозинство потребители до края на ноември [1]. Техническите ръководители в залата казаха по-късно на одиторите, че не са били консултирани за тази дата [1].

Пътят към тази цел беше тежък. В края на октомври две повреди в оборудването на доставчика на инфраструктура оставиха сайта неработещ за 24 и 36 часа [1]. Някои спаха в близки хотели и работеха на смени по 24 часа [1]. «Това бяха мрачни дни» (собствен превод), каза един служител [1].

Но цифрите започнаха да се движат. Според доклада на CMS от 1 декември, който OIG цитира, времето, през което сайтът работеше, се повиши от 42 % в началото на ноември до над 90 % в края на ноември [1]. (TIME съобщи 43 % и 95 % [4]; използвам цифрата от официалния доклад.) Към 1 декември сайтът издържаше над 35 000 едновременни потребители, без да пада, според OIG; TIME говореше за най-малко 50 000 [1][4]. Вече имаше табла за производителността на цялата система и, когато натоварването преливаше, «чакалня», която молеше потребителя да изчака или да остави имейла си [1].

Срокът за покритие от 1 януари беше удължен от 15 на 24 декември. В последния ден сайтът прие 49 156 едновременни потребители, според OIG [1]; TIME съобщи по-висок пик, от 83 000, на 23 декември [4]. Към 28 декември около 1,2 милиона души бяха избрали план чрез HealthCare.gov [1]. При закриването на първия период на записване 5,4 милиона души бяха избрали план на федералния пазар [1].

От шест души в първия ден до повече от милион през декември.

Колко струваше

Спасяването не изтри сметката. OIG съобщава, че шест ключови договора първоначално са били оценени на 464 милиона долара, а в началото на 2014 г. вече се изчислявали на 824 милиона; този за централната система нарасна от 58 на 207 милиона [1]. Сметната палата на правителството (GAO) установи, че сайтът е пуснат, без да е проверено дали отговаря на изискванията си за производителност, и че задълженията по договора за централната система са нараснали от 56 на над 209 милиона между септември 2011 г. и февруари 2014 г. [2].

През януари 2014 г. CMS смени основния си изпълнител. Напускащият изпълнител, казва OIG, научил от Washington Post няколко дни преди да дойде новият [1].

Какво учи този случай

1. Добавянето на хора не стига, а понякога пречи

Имаше две вълни от хора. Тази от август 2013 г., 60 души повече върху проект без ясно ръководство, не предотврати катастрофата [1]. Тази от октомври, която също добави персонал от агенцията, от изпълнителите и от частния сектор, по-голямата част за три седмици [1], стана част от възстановяването, защото дойде заедно с ръководство, метрики, интеграция и ясни приоритети [1]. Случаят не позволява резултатът да се припише на един-единствен фактор.

Нека бъдем честни с данните: спасяването не беше направено с по-малко хора. Беше направено с други хора, организирани по друг начин. Разликата не беше в броя, а в това кои дойдоха, как се интегрираха и с какви инструменти работиха. Brooks беше прав в предупреждението си, но случаят не казва «никога не добавяйте хора». Казва: не очаквайте броят да оправи онова, което организацията не решава.

2. Малко, опитно и интегрирано ядро

Ядрото, което дойде в средата на октомври, беше малко: «няколко» инженери, според OIG; «шепа» членове на тази програма на Белия дом, според официалното съобщение [1][3]. Не дойдоха да вършат работата на всички. Дойдоха с опит в сайтове, които не падат, седнаха с инженерите на изпълнителите, които вече познаваха кода, и ги ръководеха. TIME говори за «десетки» инженери, готови и дори въодушевени, които това ядро координираше [4].

Това ядро беше една част, а не цялото обяснение. Сред ключовите фактори за възстановяването OIG откроява това, че целият персонал на CMS и на изпълнителите работеше като един екип, без значки, и една «безмилостна приоритизация» (собствен превод), която съгласува работата с най-важните и постижими цели [1].

Ключовата дума е интегрирано. Без значка и без длъжност: който знае, говори; който може, поема задачата. Външен инженер, който идва да «одитира» отвън, добавя още един слой. Такъв, който сяда в същата зала, със същите правила, маха един.

3. Измерване преди поправяне

Първото беше табло, сглобено за една нощ [4]. Преди това най-добрият източник, за да се разбере дали сайтът работи, беше телевизията [1]. Без метрики всеки нов човек има мнение; с метрики всеки нов човек атакува онова, което таблото посочва.

4. Една маса, с правила

Не още една ежедневна среща, а срещата: една-единствена стая, два среза на ден, 45 минути, постоянно отворена линия и три правила на стената [4]. Обсъжда се онова, което боли през следващите 24 до 48 часа, говори този, който знае, и не се търсят виновни. Това е обратното на няколко командни центъра, които не се виждат един друг [1].

5. Някой, който отговаря всичко да си говори

Преди старта никой не изпълняваше ролята на системен интегратор и всеки изпълнител гледаше своята част [1]. По време на спасяването агенцията нае такъв [1]. Когато една система е изградена от много части и много доставчици, някой трябва да отговаря за съединенията. Ако никой не отговаря, проблемът живее точно там.

6. Датата, която никой не мърда, заслужава въпрос

Датата 1 октомври не беше определена от закона: тя идваше от подзаконова уредба, крепеше я политически ангажимент и никой не обсъди официално преместването ѝ [1]. Преди да добавите хора, за да стигнете до дадена дата, си струва да попитате кой я е определил, какво става, ако се премести, и какво е минимумът, който трябва да работи в този ден.

Приложение: двама ключови инженери по-малко преди Buen Fin

Сценарий (илюстративен, без клиент и без реален случай). Прилагам поуките от HealthCare.gov към ситуация, която много директори в Мексико ще разпознаят.

Септември е. Вашата електронна търговия се подготвя за Buen Fin, уикенда през ноември, в който се съсредоточава голяма част от продажбите за годината. В рамките на едни и същи две седмици напускат двамата инженери, които най-добре познават интеграцията между магазина, наличностите и плащанията. Остават седем седмици.

Естествената реакция е тази от август 2013 г.: «да наемем петима». Поуките от случая подсказват друг ред:

1. Първо, измерете. Преди да си тръгнат, поискайте им една сесия, в която да направят видимо онова, което само те виждаха: какви аларми преглеждаха, какви табла, какви процеси рестартираха на ръка. Ако няма табло за целия поток на покупката (от магазина до плащането и наличностите), това е първата доставка, не последната.
2. После добавете малко хора, и то опитни. Не петима общи профили, които трябва да се обучават седем седмици преди върховия сезон. Един или двама инженери, които вече са работили по сходни интеграции и в сезони с голям обем и които екипът ви може да интервюира, преди да започнат.
3. Интегрирайте ги, не ги разпределяйте. Нека влязат с акаунтите на вашата компания, във вашите хранилища, във вашето работно време и на вашите срещи. Без «екип на доставчика» и «екип на компанията»: една маса.
4. Кратка среща, с правила. Два среза на ден в седмиците преди събитието, съсредоточени върху онова, което може да срине продажбите през следващите 48 часа.
5. Режете безмилостно. Каквото не е незаменимо, за да се продава, събира плащане и доставя през този уикенд, се отлага.
6. Преразгледайте датата на всяка промяна, а не тази на Buen Fin. Тя не мърда. Но датата на новия дизайн на количката, тази на новия платежен портал или тази на миграцията на каталога може би да.

Поставен така, Buen Fin не се печели с повече хора. Печели се с правилните хора, навреме и седнали на една маса.

Пет въпроса за следващия ви комитет

1. Ако утре си тръгнат двамата инженери, които знаят най-много за интеграциите ни, какво спира да работи и знае ли някой друг как работи?
2. Имаме ли табло за целия поток, който е важен за бизнеса, или всяко звено наблюдава само своята част?
3. Кой отговаря за съединенията между нашите системи и нашите доставчици?
4. Когато добавяме хора към закъснял проект, след колко време стават полезни и кой ги интегрира?
5. Датите, които «не могат да се преместят», записани ли са в договор, в закон или в презентация?

Ако при два или повече от тях отговорът е «не знам», там може да е следващият ви октомври.

Какво прави Hábil, когато липсва критично знание

Hábil е мексиканска инженерна консултантска компания, основана през 2006 г., която добавя старши инженери към екипите на компании в Мексико и Съединените щати. Не изпращаме «още хора»: представяме профили с опит в интеграцията, облака и регулираните системи, които вие интервюирате и одобрявате, преди да започнат, и които работят в рамките на вашите контроли: с идентичността на вашата компания, във вашите хранилища и в дневен прозорец от работно време, споделен с екипа ви.

Можете да започнете с един или двама инженери, които се интегрират в екипа ви, с клетка, която ние координираме, или с проект със затворен обхват. Вижте страницата Добавете инженери към екипа си.

Поискайте първия си разговор, безплатно. Той тръгва от това какво трябва да поддържате или да изградите, какъв профил подхожда и в каква форма на работа. Пишете ни в WhatsApp.

Често задавани въпроси

Какво беше «tech surge» на HealthCare.gov?

Това беше името, което Министерството на здравеопазването на Съединените щати даде на 22 октомври 2013 г. на подкреплението за поправката на сайта: съветник по управлението, Jeff Zients, и експерти от правителството, от изпълнителите и от технологични компании [3]. Техническото ядро беше набрано от Белия дом с инженери, които не бяха изграждали сайта [1].

Колко продължи спасяването?

OIG заключава, че CMS възстанови сайта за интензивно ползване за около два месеца: целта за подобрение беше изпълнена на 1 декември 2013 г. [1].

Какво казва законът на Brooks?

В свободен превод: «Добавянето на хора към закъснял софтуерен проект го забавя още повече». Идва от книгата The Mythical Man-Month на Frederick P. Brooks Jr., публикувана през 1975 г. [5]. Това е предупреждение, не забрана: цената е във времето, необходимо за интегрирането на всеки човек, и в комуникацията, която се умножава.

Значи никога не си струва да се добавят инженери към закъснял проект?

Случаят не казва това. През октомври 2013 г. бяха добавени хора и сайтът се възстанови, но тези хора дойдоха с опит, интегрираха се на една маса без разлика на работодател и работиха с метрики и орязани приоритети [1][4]. Случаят не позволява резултатът да се припише на един-единствен фактор. Онова, което не стигна, беше да се добавят хора без ръководство и без видимост [1].

Участвала ли е Hábil в случая HealthCare.gov?

Не. Това е публичен случай, документиран от правителството на Съединените щати и от пресата. Използваме го, защото поуките му важат за всеки екип, който поддържа система, която не може да се провали.

Колко време отнема един инженер на Hábil да се интегрира в екипа ми?

Зависи от три неща: профила, който ви трябва, интервютата, с които екипът ви го одобрява, и времето, което отнема на компанията ви да му даде акаунти и достъп до хранилищата си. В първия разговор определяме профила и ви казваме колко скоро може да започне във вашия контекст.

Цитатите са преведени от английски (собствен превод). Цифрите са тези, които съобщава всеки източник; когато два източника не съвпадат, текстът го казва и използва официалния.