Тема 3.6 — DevOps и инженерное совершенство

Одним предложением: В клинических системах дисциплинированная инженерия (автоматизированные конвейеры, небольшие обратимые релизы, инфраструктура как код и наблюдаемость) делает изменения безопаснее, а не рискованнее, и отношение к тому, «как мы создаём и эксплуатируем программное обеспечение», как к вопросу безопасности, равенства и общественного доверия — признак зрелой организации цифрового здравоохранения.

Почему это важно в здравоохранении и уходе#

То, как вы проектируете и эксплуатируете программное обеспечение, — сама по себе мера клинической безопасности. Когда районная медсестра не видит изменения лекарства, когда электронное направление молча даёт сбой или когда простой блокирует доступ клиницистов к общей карте ухода, вред — не абстрактное неудобство, а отложенное лечение, пропущенная аллергия, пробел в защите. Инженерные практики этой темы определяют, достигнет ли нужное исправление производства за десять минут или десять недель и можно ли плохое изменение чисто откатить или клиницисты будут днями работать в обход сломанной системы.

В регулируемых областях живёт стойкий и опасный миф, что изменение — это риск, поэтому самая безопасная система — та, которой вы касаетесь меньше всего. Доказательства указывают в обратную сторону. Системы, которые редко меняют, накапливают необновлённые уязвимости, хрупкие ручные шаги развёртывания и недокументированное устное знание; когда изменение наконец становится неизбежным (патч безопасности, регуляторный срок, уход поставщика), оно приходит как крупный, рискованный, плохо понятый «большой взрыв». Организации, развёртывающие небольшие изменения часто, с автоматизацией и быстрым откатом, переживают меньше сбоев и восстанавливаются быстрее. В здравоохранении и уходе эта разница измеряется безопасностью пациентов.

Инженерное совершенство — также вопрос равенства и общественного доверия. Ненаблюдаемое ПО скрывает, что услуга работает хуже для пользователей на старых устройствах или в районах с плохой связью. Небезопасная цепочка поставок ПО подвергает риску конфиденциальную информацию о пациентах (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность). А поскольку это государственные деньги и государственные данные, сектор всё чаще ожидает, что код будет создаваться по открытым, проверяемым стандартам, порой буквально открыто. То, как вы работаете, поэтому не частное инженерное дело; оно подотчётно пациентам, клиницистам и общественности.

Ключевые понятия#

DevOps. DevOps — культура и набор практик, разрушающих традиционную стену между разработчиками, которые создают ПО, и операционным персоналом, который его эксплуатирует. Вместо «перебрасывания кода через стену» отдельной команде одни и те же люди разделяют владение услугой от проектирования до действующей эксплуатации, поддерживаемые автоматизацией и быстрой обратной связью. Это прежде всего способ работы (общая ответственность, обучение без обвинений, малые партии), обеспеченный инструментами, а не инструмент, который можно купить.

Непрерывная интеграция и непрерывная поставка (CI/CD). Непрерывная интеграция (CI) означает, что каждый разработчик часто вливает небольшие изменения в общую основную ветку, и каждое запускает автоматическую сборку и тестирование, так что проблемы всплывают за минуты. Непрерывная поставка (CD) расширяет это так, что ПО всегда находится в состоянии, пригодном для выпуска, и может быть развёрнуто в производство через автоматизированный, воспроизводимый конвейер. Непрерывное развёртывание (continuous deployment) идёт на шаг дальше, автоматически выпуская каждое изменение, прошедшее конвейер. Тестирование — суть ворот конвейера, подробно рассмотренное в теме 3.7 — Тестирование и обеспечение качества.

Разработка на основе основной ветки (trunk-based) и небольшие обратимые релизы. Trunk-based development держит всех работающими близко к единой основной линии в системе контроля версий, интегрируя много раз в день, а не выхаживая долгоживущие ветки, которые расходятся и болезненно сливаются. Парная дисциплина — выпускать небольшие, частые, независимо обратимые изменения. Небольшое изменение легко рассмотреть, легко протестировать и, что решающе важно в клинической системе, легко чисто откатить, если что-то пошло не так.

Инфраструктура как код (IaC). Вместо ручной настройки серверов вы определяете инфраструктуру в машиночитаемых файлах под контролем версий. Среда становится воспроизводимой, проверяемой и подотчётной: можно перестроить её идентично, увидеть, кто что и почему изменил, и доказать, что тест и производство совпадают. Это основа надёжных сред (см. тему 4.0 — Техническая архитектура, облако и унаследованные системы).

Платформенная инженерия и опыт разработчика. Платформенная инженерия рассматривает внутренние инструменты, конвейеры и среды, от которых зависят команды поставки, как продукт, а команды — как его пользователей. Хорошо построенная внутренняя платформа даёт командам «мощёную дорогу» (безопасные значения по умолчанию, заранее одобренные паттерны, развёртывание в один щелчок), чтобы они могли двигаться быстро и безопасно, не изобретая каждый заново соответствие. Хороший опыт разработчика — не излишество; это способ сделать безопасный путь лёгким.

Метрики DORA. DevOps Research and Assessment (DORA) выделила четыре меры, отличающие высокоэффективные команды: частота развёртывания (как часто вы выпускаете), время выполнения изменений (сколько от коммита до производства), доля неудачных изменений (какая доля изменений вызывает проблему) и время восстановления услуги (как быстро вы восстанавливаетесь). Вместе они показывают, что скорость и стабильность растут вместе: команды, развёртывающие чаще всех, и терпят неудачи реже всех и восстанавливаются быстрее всех.

«Вы создаёте — вы эксплуатируете», SRE и наблюдаемость. Популяризованное в Amazon «you build it, you run it» означает, что команда, пишущая услугу, также эксплуатирует её, носит пейджер и чувствует её сбои, замыкая цикл обратной связи между инженерными выборами и операционной реальностью (см. тему 3.8 — Управление услугами и эксплуатация). Инженерия надёжности сайтов (SRE) — конкретная реализация, применяющая инженерию к эксплуатации, с явными целями надёжности и бюджетами ошибок. Наблюдаемость, способность понимать внутреннее состояние системы по её выходам (метрики, журналы, трассировки), — то, что позволяет обнаруживать и диагностировать проблемы до того, как их заметят пациенты и клиницисты.

Безопасная цепочка поставок ПО. Современное ПО собирается из множества сторонних компонентов и зависимостей. Атака на цепочку поставок использует доверенный компонент, чтобы скомпрометировать всё, что от него зависит. Управление зависимостями, сканирование на известные уязвимости и ведение перечня компонентов ПО (software bill of materials) — основная инженерная гигиена, а не необязательное дополнение по безопасности.

Код в открытом доступе и программное обеспечение с открытым исходным кодом. Политика британского правительства, выраженная в GDS Service Standard и NHS Service Standard, просит команды делать новый исходный код открытым по умолчанию и использовать открытые стандарты. Для публично финансируемого ПО здравоохранения это улучшает проверку, повторное использование и доверие при условии, что данные пациентов и настоящие секреты строго остаются вне публичных репозиториев.

Лучшие практики#

1. Постройте конвейер CI/CD до того, как строите услугу. Установите автоматизированную сборку, тестирование и развёртывание с первой недели, чтобы каждое изменение шло по одному воспроизводимому, проверяемому пути в производство. Конвейер — место, где ваши ворота клинической безопасности, безопасности и доступности живут как автоматические проверки, давая задокументированную, защищённую от подделки запись о том, что именно было развёрнуто и когда. В регулируемой системе этот след аудита — не накладные расходы, а доказательство для вашего обоснования клинической безопасности (см. тему 1.6 — Клиническая безопасность и управление рисками).

2. Развёртывайте небольшие, частые, обратимые изменения. Предпочитайте много небольших релизов нечастым крупным и проектируйте каждое изменение так, чтобы его можно было быстро откатить или отключить. Крошечное изменение, давшее сбой, легко понять и откатить; квартальный мегарелиз, давший сбой, — клинический инцидент со сотней подозреваемых. Приёмы вроде флагов функций (feature flags), канареечных релизов и сине-зелёного развёртывания позволяют выставлять изменение постепенно и мгновенно возвращать его, превращая развёртывание из пугающего события в рутинное, невозмутимое действие.

3. Сделайте быстрый, чистый откат первоклассной мерой безопасности. Репетируйте откат так, как репетируете пожарную тревогу, и измеряйте, сколько он на самом деле занимает. В клинической системе самая ценная операционная возможность — способность вернуться в заведомо рабочее состояние за минуты, когда изменение причиняет вред. Откат, который никогда не тестировали, — надежда, а не контроль; докажите, что он работает, и продолжайте доказывать.

4. Рассматривайте инфраструктуру и конфигурацию как код. Определяйте среды, сети и конфигурацию декларативно, под контролем версий, и поставляйте их автоматически. Это даёт воспроизводимые среды, изменения, рассмотренные коллегами, и возможность перестроиться после сбоя или катастрофы (см. тему 3.9 — Непрерывность бизнеса и аварийное восстановление). Ручные, настроенные вручную серверы-«снежинки» невоспроизводимы, недокументированы и обычная причина «в тесте работало, а в производстве нет».

5. Используйте метрики DORA для честных разговоров, а не для ранжирования людей. Отслеживайте частоту развёртывания, время выполнения, долю неудачных изменений и время восстановления как сигнал здоровья на уровне системы и следите, чтобы они двигались вместе к быстрее-и-безопаснее. Сопротивляйтесь превращению их в индивидуальные или командные турнирные таблицы: авторы DORA сами предостерегают от этого, потому что это порождает манипуляции и скрытый риск. Правильное использование диагностическое: растущая доля неудачных изменений говорит вам нечто о покрытии тестами или размере партии, что совет должен хотеть услышать.

6. Примите «вы создаёте — вы эксплуатируете», подкреплённое наблюдаемостью. Дайте командам поставки подлинное владение их услугами в производстве, включая ответственность за дежурства, чтобы люди, делающие проектные выборы, жили с операционными последствиями. Подкрепите это наблюдаемостью (метрики, структурированные журналы и трассировки, плюс осмысленное оповещение, привязанное к воздействию на пользователей), чтобы команды находили проблемы до того, как о них сообщат клиницисты. Это замыкает цикл обратной связи, который со временем улучшает инженерные выборы, и напрямую связано с управлением услугами (тема 3.8).

7. Непрерывно защищайте цепочку поставок ПО. Ведите перечень зависимостей, автоматически сканируйте на известные уязвимости, фиксируйте и проверяйте версии и храните перечень компонентов ПО, чтобы вы могли ответить «затронуты ли мы?» в течение часов после следующей широко разрекламированной уязвимости. Ограничивайте, кто и что может отправлять в производство, и строго защищайте секреты и учётные данные (см. тему 4.2 — Управление идентификацией и доступом). В здравоохранении и уходе скомпрометированная зависимость — путь к конфиденциальным данным пациентов, поэтому гигиена цепочки поставок — работа по безопасности пациентов и управлению информацией.

8. Устанавливайте и обеспечивайте инженерные стандарты и осознанно управляйте техническим долгом. Согласуйте стандарты кодирования, автоматизированный линтинг, рецензирование кода и ясное «определение готовности», чтобы качество закладывалось, а не проверялось позже. Отслеживайте технический долг явно и погашайте его как плановую работу, потому что неуправляемый долг в клинической системе тихо повышает цену и риск каждого будущего изменения. Стандарты делают код читаемым для следующего инженера, а также для аудиторов, специалистов по безопасности и рецензентов открытого кода, которым может понадобиться его читать.

9. Пишите код открыто там, где безопасно. Следуйте ожиданию GDS и NHS делать новый исходный код открытым по умолчанию и повторно использовать открытые стандарты, строго не пуская данные пациентов и секреты в публичные репозитории дисциплинированным управлением секретами. Открытый код приглашает проверку, улучшающую качество и безопасность, позволяет повторное использование в стеснённой в деньгах системе и создаёт общественное доверие, что программное обеспечение, на которое тратятся государственные деньги, делает то, что заявляет. Там, где код действительно нельзя открыть (например, некоторые компоненты, чувствительные для безопасности), документируйте причину, а не оставляйте закрытым по привычке.

Вопросы для обсуждения с командой#

1. Действительно ли мы верим, что более частые изменения наших клинических систем делают их безопаснее и соответствует ли наше поведение этому убеждению? Этот вопрос заставляет команду столкнуться с разрывом между доказательствами и инстинктом. Исследования DORA ясно показывают, что команды, часто развёртывающие небольшие изменения, имеют меньшую долю сбоев и быстрее восстанавливаются, но многие организации здравоохранения всё ещё сбивают изменения в редкие, тяжело закрытые воротами релизы во имя безопасности, непреднамеренно делая каждый крупнее и рискованнее. Обсудите, где ваши процессы совета по изменениям действительно снижают риск, а где просто добавляют задержку, толкающую команды к релизам «большим взрывом». Посмотрите честно на последние несколько инцидентов: были ли они вызваны частыми небольшими изменениями или редкими крупными и необновлённой запущенностью? Подумайте, реален ли и отрепетирован ли ваш откат, потому что довод в пользу частых изменений целиком опирается на способность быстро их отменить. Хороший ответ не идеологичен; он называет конкретные контроли (автоматизированное тестирование, канареечные релизы, проверенный откат), которые позволили бы увеличить частоту изменений и одновременно удовлетворить ваши обязательства по клинической безопасности и гарантиям.

2. Кто ведёт наши услуги в производстве в 2 часа ночи и что это говорит нам о наших инженерных выборах? «Вы создаёте — вы эксплуатируете» легко одобрить и трудно прожить. Этот вопрос выясняет, чувствуют ли люди, принимающие архитектурные решения и решения по поставке, операционные последствия, или боль сбрасывается на отдельную операционную команду или службу поддержки, не способную устранить первопричины. Изучите состояние вашей наблюдаемости: когда общая карта ухода замедляется, вы узнаёте об этом из дашбордов и оповещений или от рассерженного клинициста? Обсудите и человеческую цену: дежурства должны быть гуманными, финансируемыми и общими, иначе они становятся проблемой выгорания и удержания, что в стеснённой кадрами NHS серьёзный риск (см. тему 7.2 — Планирование кадров). Есть реальный компромисс между полным владением команды и реальностью, что некоторым небольшим организациям и поставщикам действительно нужна общая платформа или управляемая услуга, чтобы вести дела надёжно. Сильный ответ связывает операционную ответственность обратно с проектом: он определяет, где цикл обратной связи между созданием и эксплуатацией разорван, и что вы изменили бы, чтобы инженерные выборы информировались реальностью действующей эксплуатации.

3. Какая часть нашего кода и инженерной практики выдержала бы обнародование и что этот ответ раскрывает? Политика правительства и NHS просит команды писать код открыто по умолчанию, и этот вопрос использует эту линзу как диагностику даже там, где полная открытость пока невозможна. Если перспектива публикации ваших репозиториев вызывает тревогу, спросите точно почему: жёстко прописанные секреты, встроенные данные пациентов, отсутствие тестов, недокументированные решения или просто непривычность? Каждое из этого — реальная проблема инженерного качества или управления информацией, которую закрытость лишь скрывает, а не решает. Подискутируйте о подлинных ограничениях (некоторый чувствительный для безопасности код должен оставаться закрытым, а правильное управление секретами — предпосылка) против выгод проверки, повторного использования в стеснённой в деньгах системе и общественного доверия к тому, как используются расходы на ПО здравоохранения. Подумайте о репутационной и безопасностной ценности того, что внешние глаза найдут изъян раньше атакующего. Хороший, честный ответ отличает код, закрытый по защитимой, задокументированной причине, от кода, закрытого по привычке или смущению, и обязуется исправлять лежащие в основе проблемы качества и гигиены в любом случае.

4. Если бы завтра утром объявили широко известную уязвимость в распространённой зависимости, сколько времени нам потребовалось бы, чтобы ответить «затронуты ли мы и где?» Этот вопрос проверяет, реальная ли возможность гигиена цепочки поставок или стремление, используя тип событий по всему сектору (уязвимость в духе Log4j), превращающих абстрактный риск в чрезвычайную ситуацию того же дня. Честный ответ зависит от того, ведёте ли вы точный перечень зависимостей и перечень компонентов ПО или потратили бы дни на поиск по репозиториям и расспросы поставщиков, которые сами могут не знать. Изучите, какая часть вашего ПО собрана из сторонних и открытых компонентов и какую часть этой поверхности вы действительно отслеживаете автоматическим сканированием, а не эпизодическими ручными проверками. Обсудите и измерение третьих сторон и поставщиков, потому что в здравоохранении и уходе большая часть парка куплена, а не построена, и скомпрометированная зависимость в продукте поставщика — путь к конфиденциальным данным пациентов, которыми вы не управляете напрямую (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность). Подумайте, достаточно ли плотны ваши конвейеры и права отправки в производство, чтобы отравленный компонент не мог тихо проскочить. Сильный ответ называет реалистичное время ответа, измеряемое часами, указывает на конкретные инструменты и перечни, делающие это возможным, и откровенен в отношении частей парка (особенно предоставленных поставщиками), где видимость сейчас слаба.

5. Говорят ли нам наши инженерные метрики правду или они тихо превратились в целевой показатель, которым люди манипулируют вверх? Метрики DORA полезны только как честный сигнал на уровне системы, и этот вопрос проверяет, пережили ли ваши столкновение с организационными стимулами. Закон Гудхарта неумолим: в момент, когда частота развёртывания или доля неудачных изменений становится числом, по которому оценивают команду, люди оптимизируют число, а не лежащую в основе реальность: дробят развёртывания, чтобы раздуть частоту, или тихо переклассифицируют инциденты, чтобы они не считались сбоями. Обсудите, кто видит эти метрики и зачем и используются ли они диагностически, чтобы побудить инвестиции в покрытие тестами или размер партии, или как турнирная таблица, порождающая манипуляции и скрытый риск. Подумайте и об обратной стороне: команды, не измеряющие ничего и полагающиеся на анекдот, так что растущая доля сбоев невидима, пока не станет клиническим инцидентом. Есть реальное напряжение между законной потребностью совета в гарантиях и тем, что самые полезные метрики — те, о которых команды безопасно сообщают честно. Хороший ответ описывает, как измерение формулируется и управляется, чтобы выявлять неудобные истины рано, а не вознаграждать людей за их сокрытие.

6. Когда мы в последний раз осознанно гасили технический долг и как мы решаем, что означает «достаточно хорошая» инженерия в клинической системе? Технический долг в клинической системе — не вопрос аккуратности; он тихо повышает цену и риск каждого будущего изменения, так что исправление, которое должно занять день, занимает две недели и затрагивает код, который никто не осмеливается рефакторить. Этот вопрос заставляет команду увидеть, управляется ли долг как видимая, плановая работа или просто копится, пока что-то не сломается, и действительно ли обеспечиваются инженерные стандарты (рецензирование кода, линтинг, ясное определение готовности) или отменяются под давлением поставки. Изучите реальный компромисс между поставкой функции, нужной услуге сейчас, и поддержанием внутреннего качества, которое сохраняет систему безопасной для изменения позже, потому что в здравоохранении и уходе оба законны, а баланс — суждение, а не лозунг. Обсудите, как стандарты делают код читаемым не только для следующего инженера, но и для аудиторов, специалистов по клинической безопасности и рецензентов открытого кода, которым может понадобиться его читать. Подумайте, можете ли вы вообще видеть свой долг: назван ли он и отслеживается или это устное знание о том, какие модули пугающие? Честный ответ указывает на конкретное, финансируемое устранение, которое действительно произошло, и на общее, защитимое определение планки качества, которой требует регулируемая система.

На практике: пример из здравоохранения и ухода#

Интегрированная система ухода (ICS) ведёт общую услугу «единой точки доступа», маршрутизирующую срочные направления общественного ухода к нужной команде. В первые два года услуга развёртывалась вручную примерно раз в квартал: разработчик следовал странице вики с ручными шагами поздно вечером в пятницу, и каждый релиз был напряжённым мероприятием для всех. Когда всплыла ошибка маршрутизации направлений (иногда направляла направления со сложными потребностями не той команде), исправление шесть недель простояло в очереди в ожидании следующего окна релиза, а клиницисты справлялись с риском ручными обходными путями.

Новый руководитель инженерии переформулирует это как проблему клинической безопасности, а не просто эффективности. Команда вводит конвейер CI/CD: каждое изменение небольшое, рассмотрено коллегами и автоматически собирается и тестируется, с проверками доступности и безопасности и шагом согласования клинической безопасности, закодированными как ворота конвейера, дающие проверяемую запись для журнала опасностей. Инфраструктура переводится в код, так что тестовая и производственная среды наконец совпадают. Развёртывания переходят с квартальных на несколько раз в неделю, выпускаются сначала на одну территорию как канарейка, с проверенным откатом, возвращающим к последнему заведомо рабочему состоянию менее чем за пять минут.

Через полгода метрики DORA рассказывают совету историю простыми словами: время исправления сократилось с шести недель до менее суток, частота развёртывания выросла в десять раз, а доля неудачных изменений упала, потому что изменения теперь небольшие и наблюдаемые. Когда тонкая ошибка маршрутизации повторяется, дашборды наблюдаемости помечают аномалию за минуты, команда откатывает до того, как хоть одно направление направлено неверно, выпускает исправление следующим утром и записывает пересмотр после инцидента без обвинений. Команда также публикует нечувствительный движок правил маршрутизации как открытый код по NHS Service Standard, и соседняя ICS использует его повторно. Более частое изменение системы сделало её наглядно безопаснее.

Отраслевые перспективы#

Стартап#

Стартап цифрового здравоохранения может принять современную инженерную практику с первого дня, без унаследованной операционной команды для согласования: разработка на основе основной ветки, CI/CD и инфраструктура как код — по сути бесплатные значения по умолчанию в небольшой команде с нуля, и это подлинное преимущество. Риск в том, что «двигаться быстро» тихо отбрасывает дисциплины, которых требует здравоохранение: автоматизированные тесты, проверенный откат, управление секретами и сканирование зависимостей ощущаются как трение, когда регулятор ещё не смотрит. Основатели должны признать, что обязательства клинической безопасности и цепочки поставок лежат на них независимо от размера компании и что один утёкший набор данных пациентов или неуправляемая зависимость могут закончить компанию. Прагматичный путь — опереться на управляемые облачные платформы и небольшую, обоснованную «мощёную дорогу», чтобы крошечная команда получила безопасность по умолчанию, не строя платформенную группу, которую пока не может себе позволить.

Малый бизнес#

Устоявшийся небольшой поставщик или производитель (практика врача общей практики, общественная аптека, дом престарелых, клиника в одном месте или небольшой поставщик health-tech, миновавший стадию без выручки) обычно имеет реальных пациентов и реальную деятельность, но не имеет выделенной инженерной или ИТ-функции для ведения конвейеров, наблюдаемости или дежурств. Для большинства таких организаций практическая форма инженерного совершенства — хорошо купить, а не строить: выбирать поставщиков и управляемые платформы, чью собственную дисциплину DevOps вы можете проверить, и делать автоматические обновления, проверенные резервные копии и обновление зависимостей договорными ожиданиями, а не надеждами. Там, где небольшой поставщик действительно пишет ПО, один хорошо настроенный конвейер CI/CD на управляемой облачной платформе, с автоматическим сканированием зависимостей и секретами вне репозитория, даёт большую часть выигрыша безопасности по цене, которую скромная команда может выдержать. Ловушка — предполагать, что малый размер снижает планку клинической безопасности, безопасности и управления информацией: это не так, а необновлённая зависимость или развёрнутое вручную изменение, пошедшее не так, вредят пациентам так же надёжно в практике из двух клиницистов, как и в национальном органе. Реалистичная цель — безопасность по умолчанию, унаследованная от хороших платформ и хороших поставщиков, при том, что ограниченное внимание практики уходит на проверку, что эти значения по умолчанию действительно включены.

Крупная организация#

У крупного траста NHS или крупного поставщика health-tech есть ресурсы, чтобы вести платформенную инженерию, наблюдаемость и «вы создаёте — вы эксплуатируете» как следует, но его сдерживают унаследованные системы, «силосные» команды разработки и эксплуатации и процессы совета по изменениям, построенные для более медленной эпохи. Характерный сбой — тяжеловесный совет по изменениям, который, пытаясь контролировать риск, вынуждает крупные пакетные релизы, более опасные, чем частые небольшие, которых он боится. Возможность — инвестировать во внутреннюю платформу разработчика, встраивающую соответствие, безопасность и ворота клинической безопасности в мощёную дорогу, чтобы десятки команд унаследовали хорошую практику, а не договаривались о ней каждая. Масштаб здесь — палка о двух концах: радиус поражения плохого развёртывания огромен, и именно поэтому автоматизация, канареечные релизы и проверенный откат существенны, а не необязательны.

Государство#

Национальный орган вроде NHS England или департамента здравоохранения децентрализованной администрации задаёт стандарты, которым следуют другие (стандарты услуг NHS и GDS, контроль расходов, ожидание писать код открыто), и подотчётен парламенту и общественности за то, как ПО создаётся и эксплуатируется. Его инженерные выборы расходятся волнами по системе: хорошо ведомая национальная платформа, опубликованные компоненты с открытым кодом и ясное руководство по цепочке поставок поднимают нижнюю планку для каждого траста и поставщика. Ограничения реальны: многолетнее финансирование, правила закупок и огромный масштаб и чувствительность национальных данных означают, что ритм развёртывания более взвешен, чем в стартапе. Государственная линза должна уравновешивать образцовую прозрачность и повторное использование с безопасностью национально критичных систем, сознательно решая, что открывается, а что защищается, и документируя рассуждение в любом случае.

Типичные способы сбоя#

• Паралич «изменение — это риск». Редкое развёртывание ради ощущения безопасности порождает крупные, опасные, плохо понятые релизы и необновлённую запущенность. Противоядие: небольшие, частые, обратимые изменения с проверенным откатом.
• Стена между разработкой и эксплуатацией. Разработчики «перебрасывают код через стену» отдельной операционной команде, не способной устранить первопричины; никто не владеет всем циклом. Противоядие: общее владение и «вы создаёте — вы эксплуатируете», поддерживаемое гуманно.
• Ручные развёртывания «снежинок». Релизы зависят от одного человека и страницы вики; среды дрейфуют, а «работает в тесте, ломается в производстве» — рутина. Противоядие: CI/CD плюс инфраструктура как код.
• Метрики как палка. Числа DORA используются для ранжирования команд, порождая манипуляции и скрытый риск. Противоядие: использовать их как диагностику на уровне системы, по руководству самой DORA.
• Эксплуатация, слепая к оповещениям. Нет наблюдаемости, поэтому пациенты и клиницисты узнают о сбоях первыми. Противоядие: метрики, журналы, трассировки и оповещение о воздействии на пользователей.
• Заброшенная цепочка поставок. Необновлённые зависимости и несканированные компоненты становятся нарушением. Противоядие: непрерывное сканирование, перечень компонентов ПО и защищённые конвейеры.
• Случайное раскрытие. Небрежно ведомый открытый код, утекающие секреты или данные пациентов. Противоядие: строгое управление секретами и сканирование перед публикацией, а не отступление к закрытому по умолчанию.

Модель зрелости#

Контрольный список#

• Конвейер CI/CD собирает, тестирует и развёртывает каждое изменение по одному проверяемому пути, с закодированными воротами безопасности/защиты/доступности.
• Изменения небольшие, частые и независимо обратимые (флаги функций, канареечные или сине-зелёные релизы).
• Откат к заведомо рабочему состоянию регулярно тестируется и завершается за задокументированное короткое время.
• Инфраструктура и конфигурация определены как код под контролем версий; тестовая и производственная среды совпадают.
• Четыре метрики DORA отслеживаются как сигнал на уровне системы, а не используются для ранжирования людей или команд.
• Команды поставки владеют своими услугами в производстве, с гуманными, финансируемыми дежурствами и осмысленной наблюдаемостью (метрики, журналы, трассировки, оповещение).
• Зависимости инвентаризируются и автоматически сканируются; существует перечень компонентов ПО, а секреты защищены.
• Инженерные стандарты, рецензирование кода и определение готовности согласованы; технический долг отслеживается и погашается как плановая работа.
• Новый исходный код открыт по умолчанию там, где безопасно, со строгими проверками, что данные пациентов и секреты не раскрыты.
• Инженерная практика задокументирована, чтобы новый инженер, аудитор или специалист по безопасности мог понять, что работает и почему (см. тему 10.3).

Ключевые источники#

• Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and Development and DevOps: исследование DORA и четыре ключевые метрики.
• DORA (DevOps Research and Assessment): ежегодные отчёты State of DevOps и каталог возможностей — dora.dev.
• Jez Humble & David Farley, Continuous Delivery: конвейер развёртывания и автоматизация релизов.
• Betsy Beyer et al. (eds.), Site Reliability Engineering: книга Google по SRE о ведении производственных систем.
• NHS England — NHS Service Standard и NHS Digital Service Manual (включая открытый код и открытые стандарты).
• GOV.UK Service Manual / Government Service Standard (GDS): «make new source code open», непрерывная поставка и эксплуатация услуги.
• National Cyber Security Centre (NCSC): руководство по безопасной разработке ПО и безопасности цепочки поставок.
• NHS England — стандарты управления клиническими рисками DCB0129 и DCB0160 (инженерные изменения как часть обоснования клинической безопасности).

Ссылки#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety