Зміст
Джерело: Максим Ємельянов / Dreamstime.com
Винос:
Washington Post назвав HealthCare.gov "однією з найскладніших програм програмного забезпечення, що коли-небудь написана для федерального уряду". З точки зору ІТ, саме тому сайт не працював.
По-перше, не нашкодь! Цей едикт - перефразований з присяги Гіппократа - пронизує професійну охорону здоров'я, як це було ще з світанку західної медицини близько 2500 років тому. Будь-хто може оцінити простоту та значення цієї мантри. Якщо ви, як медик, нічого іншого не робите, принаймні не шкодите своєму пацієнту.Написаний у нижній частині цієї фрази, ви можете знайти безперечну смиренність. Насправді, для всіх різних та різноманітних напрямків науки існує критична аксіома: завжди будьте готові ставити під сумнів свої припущення. Ми знаємо лише те, що знаємо, і впевнені, що ще нічого не знаємо, і ніколи не будемо. Нехай ця мудрість служить обережністю для ваших найсильніших рецептів.
Тоді є виконуюча частина. У будь-яких життєвих починаннях людина сподівається дізнатись про щось важливе, а потім вжити відповідних заходів. Обережно так само, як і дбайливе ставлення, а при догляді за життям інших людей необхідна серйозність. З огляду на наше полотно та розуміння інформаційних технологій (ІТ) під нашими поясами, давайте подивимося на розробку HealthCare.gov, часто характерного флагмана Закону про доступну допомогу, який називається "Obamacare".
Життєзабезпечення
Якою я тупою можу бути? HealthCare.gov був мертвий після прибуття. Тепер колективна прозорість говорить про те, що всі шість людей підписалися в перший день, 1 жовтня. Шість. Тільки 32,994 не вистачає цілі 33000 щоденно. І хоча питання "пропускної спроможності" розглядалися як відсторонене визнання попиту, кожен, хто має знання веб-динаміки, знав краще."Це не є невирішеною проблемою", - зазначає доктор Робін Блор, науковець із даних та співзасновник The Bloor Group. "У Голландії такий обмін".
Насправді голландці випереджають гру вже два десятиліття, отримавши багато уроків. Швейцарці також мають певний досвід, і, звичайно, Массачусетс має MAHealthConnector.org, так званий «RomneyCare».
Блер говорив, що 40 років досвіду роботи з ІТ довели, що великі проекти завжди несуть великий ризик.
"Робіть великий проект, з високим ризиком високий ризик невдачі. Мати три з половиною роки звучить так, як в сучасний день, цього було б достатньо, але ось проект високого ризику, і все це вийшло погано, - сказала Блор.
Він був найщирішим щодо способу тестування інтеграції для HealthCare.gov.
"Заключна річ, яка мене зробила, майже не засміявшись, - це інтеграційне тестування до двох тижнів, перш ніж ви будете жити - і це просто так, як ви могли це зробити з чимось подібним? Як ви могли?" - сказала Блор.
Поділяючи цю перспективу федеральний підрядник і науковий співробітник, доктор Джеффрі Малафський з Phasic Systems Inc. Малафський нещодавно запропонував погодинну детальну оцінку розгортання HeathCare.govs і прокоментував прийняті стратегічні та тактичні рішення. . Перш за все, він вказує пальцем на протокол придбання федерального уряду.
"Один з найважливіших моментів невдач, що переймається особливо державними ІТ-проектами, - це спадщина, архаїчність, застаріле уявлення про те, що ви можете сформулювати всю необхідну бізнес-логіку за допомогою деяких лінійних вимог. Це принципово не працює з великими ІТ-системами", - сказав він.
Його сенс полягає в тому, що великі ІТ-системи підроблять навіть найрозумніших планувальників. Ви просто ніколи не знаєте, звідки з’являться проблеми, де вам потрібно буде надати додаткову підтримку або яким чином вирішити проблеми, з якими ви опинитеся. Отже, погана ідея обмежувати процес проектування, змушуючи інженерів проекту передбачати все вони знадобляться вперед.
Ускладнює питання, зазначає Малафський, той факт, що чиновники закупівель у федеральному уряді стали настільки потужними - завдяки величезній кількості грошей, які вони контролюють, - що вони по суті контролюють те, як просуваються великі ІТ-проекти. Це ставить посадових осіб відомства в роль заявника та вкладає елемент ризику у вирішальну процедуру в центрі будь-якої значної ІТ-ініціативи: вибору правильних інструментів, технологій та підрядників.
"Люди, які найголосніше не погоджуються з цим твердженням, називаються професіоналами з придбання, і я закликаю їх з'явитися в мене вдома, і ми будемо сидіти навколо цього і обговорювати це, тому що у мене є багато емпіричних доказів, щоб підтвердити це", - сказав Малафський сказав.
Стратегія сайту
Одним з важливих запитань є те, чому уряд прийняв таку комплексну архітектуру для цього веб-сайту."Якщо загальна урядова програма створена таким чином, що страхові компанії фактично володіють клієнтом після того, як вони взяли на себе зобов'язання, то чому б не просто відсунути трафік на існуючий канал взаємодії з клієнтами, який мають страхові компанії? Так, вони можуть необхідно розширити свої власні, але це було б вагомою причиною для бізнесу, оскільки вони зараз збираються залучати нових клієнтів ", - сказав Малафський.
Всесвітньо відомий (і на сьогодні дещо сумнозвісний) піонер із безпеки програмного забезпечення Джон Макфей також нещодавно прокоментував цю стратегію, зробивши кілька спірних зауважень щодо "Шоу Ніла Кавуто" в Fox News:
"О, це серйозно погано", - сказав Макфей. "Хтось допустив серйозну помилку не в розробці програми, а в простому впровадженні її веб-аспекту. Я маю на увазі, наприклад, будь-хто може створити веб-сторінку і претендувати на роль брокера для цієї системи ... будь-який хакер може поставити веб-сайт, щоб він виглядав надзвичайно конкурентоспроможним, і через характер системи - а це все-таки охорона здоров’я - вони можуть задати вам найінтимніші питання, і ви вільно збираєтесь відповісти на них ".
Що стосується самої веб-архітектури, Малафський вказує на очевидне - що Інтернет не був побудований для запуску складних програм. Це було завданням мейнфрейму ще в часи, коли Інтернет був у зародковому стані. Швидше, дизайнерським пунктом для Інтернету був простий обмін інформацією через окремі сторінки, що поширюються в широкій мережі комп’ютерів. При проектуванні систем мета - побудувати щось, що працює. Включення складності заради себе є непродуманим, відвертим, богомільним і майже завжди є рецептом катастрофи.
Під час власного глибокого занурення щодо того, що пішло не так з HealthCare.gov, The Washington Post опублікував відому на сьогодні графіку, яка зображала різні проблеми, з якими стикався сайт. Мова, яку використовує документ для опису сайту, насправді є досить показовою, особливо якщо врахувати, що це створена газета Washington, D.C., епіцентр федерального уряду США:
HealthCare.gov, побудований 55 підрядниками, є одним із найскладніших програм програмного забезпечення, створених для федерального уряду. Він спілкується в режимі реального часу з принаймні 112 різними комп'ютерними системами по всій країні. За перші 10 днів він отримав 14,6 мільйона унікальних візитів, за даними адміністрації Обами.
Джерело: The Washington Post
Можливо, за визначенням, щоб хтось стверджував, що у них є програмне забезпечення, повинно бути так, що програмне забезпечення насправді працює. Інакше у вас є компіляція коду, яка ще не є програмним забезпеченням. Окрім примх, відзначте перелічені номери, особливо частину про спілкування в режимі реального часу зі 112 різними комп'ютерними системами по всій країні. Це прекрасний приклад прославляти складність заради себе.
"Ми знаємо, що ще одна можливість - створити просту, дуже просту систему веб-посередників, що все це робиться за допомогою дуже простого коду сервера додатків і ще більш простого клієнтського Javascript, створює дуже приємний інтерфейс, який виробляє згорнуті дані для людей ", - сказав Малафський. "Ось, що ви можете зробити: перейдіть через це; перейдіть через це. Тоді будь-які дії, які відбудуться, можна зробити в точці відбору та відправити комусь, хто насправді має власність на програму." Звичайно, що "хтось" відноситься до страхових компаній, які все одно матимуть поліси.
Графічна графіка
Дизайнери систем у всьому світі, мабуть, почали бачити цю графіку. Давайте розглянемо різні окреслені кроки, зокрема, серйозні проблеми, які виникають при такій амбітній архітектурі. Перш за все, ми розглянемо кількість можливих транзакцій, які не вдалися до цього часу, більшість із них через програмні тайм-аути - випадки, коли одна частина процесу трансакції не отримує необхідних даних протягом прийнятного періоду часу.
"У кожного програмного забезпечення цієї графіки були свої тайм-аути, і навіть не один тайм-аут. Це може бути більше", - сказала Малафсі. "Закінчення терміну дії будь-якого з них знищить всю транзакцію. Деякі з них легко налаштувати та контролювати, як файли журналів. Це такі, як тайм-аути на веб-сервері та сервері додатків. Деякі більш непрозорі. У вас є бази даних з одночасністю та тригерами, але вони мають багато взаємодію. Якщо ви дійсно глибоко занурюєтесь у те, як працюють бази даних, це не дуже приємне видовище ". (Вивчіть основи роботи баз даних у нашому Посібнику з баз даних.)
"Сервери баз даних люблять говорити. Ми тримаємо все в порядку". Насправді, - сказав Малафський. Єдиний спосіб, коли вони можуть підвищити продуктивність та справді керувати ним, - це те, що існує серія файлів із штампованою часом, які створюються на сховищі, постійному сховищі, і вони не згортаються в один всебічний точний набір даних, доступних для будь-кого у будь-який час, тому що це забирає занадто багато часу. Це призведе до вбивства затримки транзакцій. Ви повинні переглянути ці деталі, а потім згорнуті через інтерфейс управління - і це дуже добре такі назви, як тригери та паралельність - але це, в основному, означає, що потрібно отримати багато часу, щоб отримати дані, оновити дані, і якщо я не можу це зробити до появи іншого запиту, я просто збираюся сказати вам, забудьте. Я закритий для бізнесу."
- "Передні двері"
Графіка Washington Post містить дуже цікаву інформацію прямо у самому типі в її першому розділі "Проблема", де йдеться про те, що "адміністрація Обами вирішила в кінці вересня виключити функцію, яка дозволила б людям робити покупки плани охорони здоров’я без попереднього створення онлайн-рахунку ".
Ого. По-перше, це справді "особливість", яку було виключено? Ми говоримо про фундаментальний потік сайтів. Спочатку план полягав у тому, щоб дозволити людям робити покупки, а потім у відповідний час розглянути можливість реєстрації облікового запису.
Деякі критики припускають, що ця зміна в останню хвилину (сама по собі неймовірно ризикований крок з таким великим проектом) показує, що адміністрація знала, що сайт не працював добре протягом останніх кількох тижнів, що привели до запуску 1 жовтня. . Натомість виникла ідея зібрати всю інформацію тих, хто потребує страхування, таким чином, щоб маркетингові зусилля могли бути докладені до них десь за лінією, коли сайт запрацював.
З точки зору зручності використання та потенціалу, цей останній хід поставив величезне навантаження на будь-яку основу бази даних, на якій розміщувався сайт. Це пояснює всі анекдоти людей, які не можуть зареєструватися або змушені змінювати свої паролі. І будьмо тут чесними. Чи є якась проблема більш ретельно вирішена в усьому світі, ніж процес створення облікового запису користувача? Yahoo, Google, Microsoft, YouTube, LinkedIn - навіть клас в'язання вашої бабусі - має власну динамічну форму реєстрації в наші дні, з підпискою на підписку, перемотування та інші основні функції.
- Реєстрація
Коли прийшов час зареєструватися на HealthCare.gov, підрядники кажуть: "Зв'язок між деякими з цих систем не працював належним чином, це означає, що багато користувачів не змогли успішно створити обліковий запис".
Що? Які системи? Ми говоримо про базу даних клієнтів! Тоді "системи" були б веб-клієнтом та базою даних клієнтів. Які ще системи брали участь? Це особливе "пояснення" не має сенсу.
- Доказ ідентичності
Далі - підтвердження особи. Для цього кроку не вказано жодних проблем, що також цікаво. Experian вказаний як сторонній агент, який "перевірить" чиюсь особу. Без сумніву, вирішення ідентичності є серйозною проблемою, яку потрібно вирішити. Більшість страхових компаній використовують ваш номер соціального страхування, а також сторонніх постачальників, таких як Experian. Чи справді немає проблем з цим кроком?
Напевно ми знаємо з численних анекдотів, підтверджених представленою документацією, що HealthCare.gov, безумовно, зазнав безлічі конфіденційної інформації. Малафський зазначає, що питання якості даних є набагато серйознішими, ніж питання щодо потенціалу. (І Блор зазначає, що якщо проблеми з потенціалом справді були проблемами, їх слід було б вирішити за дні, а не тижні. Ви можете додати апаратне забезпечення, віртуалізуватись, робити будь-яку кількість речей для вирішення проблем з потенціалом.)
Ні, питання якості даних - справді небезпечні. І найбільш тривожним аспектом є всі виниклі проблеми щодо якості даних. Існують історії, коли люди підписуються, а потім отримують конфіденційні документи про приналежність, що належать іншим реєстрантам! Це присмаки абсолютно жахливого дизайну під ковдрами. Чи вони не використовують якийсь універсальний ідентифікаційний код для кожної людини?
"Розумним кроком було б створити універсальний унікальний ідентифікатор (UUID), зберігати зашифровані значення - відмітити множину - того, що може бути унікальною інформацією (SSN, DOB, вік, біометричні показники), а потім оцінити їх за доказами унікальної особистості". - сказав Малафський.
Те, що хтось міг отримати конфіденційні документи іншої людини, невимовно погано, і це свідчить про деякі дуже серйозні проблеми з картографуванням глибоко в животі звіра.
- Придатність
Гаразд, люди. Ось де життя стає цікавим! Якщо ваша транзакція до цього часу не вичерпана, вона майже напевно зробила цей крок. Згідно з графікою The Washington Posts, "система повинна визначити право на отримання фінансової допомоги, передавши особисту інформацію споживача в Центр даних, який укладає десятки федеральних і державних агентств".
Спроба здійснити транзакцію в трьох або чотирьох ключових системах - справжнє завдання. Спроба потрапити на "десятки" державних та федеральних відомств "в режимі реального часу" - поза графіком, і зовсім непотрібна. Малафський взяв лише один пункт взаємодії, щоб зробити свою справу:
"Одним із очевидних тут є отримання фінансових даних на людину, щоб визначити, чи заслуговує вона на субсидію, або якою буде їх ціна, тому ми переходимо до IRS. Зараз ми маємо деяке посилання на це місце, але це посилання живе Це означає, що користувач сидить там і чекає на екрані свого комп'ютера, що повинен перейти на систему IRS. У ідеальному світі це посилання трапляється, комп'ютери розмовляють, я отримую результат, і я повертаюся назад.
"А як у реальному світі? Що робити, коли системи IRS перевантажені? А як тоді, коли вони працюють, що робити? А як тоді, коли, можливо, вони займаються технічним обслуговуванням? Що про мережу між мережевим операційним центром веб-сторінки початкового рівня що клієнт звертається до центру IRS? Можливо, там є якісь проблеми. Можливо, там є вірус. Можливо, там троянський кінь біжить навколо, а телекомунікації закрили речі, щоб вирішити цю проблему. Це вб'є транзакцію з точки зору користувача. Це лише один із багатьох таких моментів у цій архітектурі ", - сказав Малафський.
Його справа в тому, що кожна з цих систем - як ця веб-архітектура була розроблена для HealthCare.gov - кожна з них є потенційною ахіллесовою п'ятою. Це не виграшна ситуація. І знову ж таки, це не потрібно з точки зору робочого процесу. Існує будь-яка кількість точок, на яких робочий процес може бути доповнений потоками даних майже в реальному часі, правильними часовими даними, навіть втручанням людини для вирішення основних точок відмов автоматизації.
Тому велика стратегічна помилка намагалася досягти такого неймовірно складного сайту.
- Покупки для плану
Пам'ятайте: це повинен був бути початковий потік сайту. Веб-серфери спочатку купують план страхування. Потім, знайшовши щось цікаве, вони могли зареєструватися на рахунок, перевірити наявність субсидій, якщо вони бажають і в кінцевому рахунку придбати план.
Згідно з графікою, "деяким людям з низьким рівнем доходу кажуть, що вони не мають права на субсидії або не мають права на Medicaid, хоча і повинні". Тут виникає питання: Чому ця проблема перерахована під Крок 5 замість кроку 4? Це проблема, пов’язана з тим, що попередній крок не був обчислений належним чином і, таким чином, не був правильно врахований на Крок 5.
- Страховий переклад
У нашому світі цю частину ми називаємо ETL. Це так само вирішено проблему, як і реєстрація сайту.
- Зарахування на страхування
Святий Грааль! Але зачекайте, за словами підрядників HealthCare.govs є останній "збій": "Звіти, відомі як 834, іноді заплутані та повторювані, що ускладнює страховим компаніям знати, хто насправді є їхніми новими клієнтами".
Давайте хвилину мовчання, щоб оцінити цю ...
Так, так, насправді страхова компанія повинна знати, кого вона справді страхує. Це досить критична складова. Те ж саме стосується працівника швидкої допомоги, який знає, кого лікувати, або лікаря, який знає, у чиї груди слід пересадити серце. У медіа-бізнесі ми можемо охарактеризувати цю маленьку принаду як випадок, коли наші федеральні підрядники досить успішно поховали залог.
- Покриття
І останнє, але не менш важливе, на графіці зазначається, що "чиновники адміністрації заявляють, що покупці подали понад 700 000 заяв на медичне страхування. Деякі з них надійшли через HealthCare.gov, а інші - на державні ринки. Але чиновники відмовляються сказати, скільки людей записалися на план ».
Ручне перевизначення
Мабуть, найгострішим кривим кулею, який був нещодавно кинутий у суміш, був хід просування паперових додатків через проблеми з функціональністю сайту. На жаль, навіть паперові форми повинні бути подані на непрацюючий сайт. За визначенням, це не ручне перевизначення. За визначенням, ручне переопрацювання повинно дозволяти комусь або чомусь вручну переосмислювати автоматизовану систему.І тепер, під час публікації цієї статті, ми чуємо, що для відновлення HealthCare.gov адміністрація більше покладається на страхові компанії для вирішення проблем. Здогадайтеся, що це означає - я покладу на вас, що ви пончики в доларах (так, раніше було навпаки), що те, що зараз відбувається, є випадком широко розповсюдженого видобутку та заміни. Зокрема, програмісти та інженери, ймовірно, вирвали багато з "зв’язків у режимі реального часу" та інших надзвичайно дорогих проміжних програм, які так схвилювали редакторів Washington Post. Заміняючи весь цей складний код набагато простішими, більш високими затримками з'єднань, які подаються за допомогою ряду даних, пов'язаних за допомогою більшої кількості пакетного середовища з різними державними та федеральними системами.
Іншими словами, рішення, яке пропонують Малафський, Блор та Макафі - це те, куди ми йдемо. І весь той фантазійний код спагетті, який ці федеральні підрядники витратили на будівництво півмільярда доларів за останні три з половиною роки? У контейнер для гострих.