Тема 3.8 — Управление услугами и действующая эксплуатация

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

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

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

Здравоохранение и уход работают 24 часа в сутки, семь дней в неделю и не могут остановиться. Когда система оплаты в супермаркете отказывает, покупатели ждут; когда отказывает система ведения пациентов в больнице, скорые могут быть перенаправлены, а плановые списки отложены. Это придаёт действующей эксплуатации особый вес: простой — событие клинической безопасности, а план того, как вы обнаруживаете, эскалируете, сообщаете о нём и восстанавливаетесь, — часть вашей обязанности заботы. Атака программы-вымогателя WannaCry 2017 года, вынудившая отменить тысячи приёмов и операций NHS, — эталонный случай того, как операционный сбой становится кризисом безопасности пациентов и общественного доверия (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность).

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

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

Управление услугами и фаза «Live». Управление ИТ-услугами (ITSM) — набор практик проектирования, ведения, поддержки и улучшения ИТ-услуг на всём их протяжении. В модели фаз GOV.UK и NHS Live (эксплуатация) — фаза, где услуга работает в непрерывной эксплуатации, всё ещё итерируется, всё ещё финансируется, всё ещё имеет владельца, пока её не выведут из эксплуатации (см. тему 3.5 — Жизненные циклы поставки). Эксплуатация — не состояние покоя; это самая длинная и самая дорогая часть жизненного цикла.

ITIL 4. ITIL — наиболее широко используемая рамка ITSM. Её нынешняя редакция, ITIL 4, переформулирует более ранние версии, перегруженные процессами, вокруг «системы создания ценности услуг» и гибких практик и призвана работать рядом с Agile, DevOps и Lean, а не конкурировать с ними. Относитесь к ITIL как к словарю и контрольному списку практик, принимаемых соразмерно, а не как к бюрократии, которую нужно импортировать целиком.

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

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

Инженерия надёжности сайтов, SLI, SLO, SLA и бюджеты ошибок. Инженерия надёжности сайтов (SRE), возникшая в Google, применяет дисциплину программной инженерии к эксплуатации. Она измеряет надёжность индикатором уровня услуги (SLI), метрикой вроде доступности или задержки, относительно цели уровня услуги (SLO), внутреннего целевого значения этой метрики. Соглашение об уровне услуги (SLA) — внешнее, часто договорное обещание, обычно устанавливаемое мягче внутреннего SLO. Разрыв между 100% и вашим SLO — бюджет ошибок: объём ненадёжности, который можно потратить, прежде чем придётся прекратить поставку функций и стабилизироваться. В клинических системах SLO должны устанавливаться с клиницистами, потому что «приемлемый» простой — суждение о безопасности, а не только инженерное.

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

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

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

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

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

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

2. Избегайте антипаттерна «перебросить через стену операторам». Не позволяйте проектной команде создать услугу и передать её отдельной операционной команде, которая никогда не видела, как её делали. Применяйте «вы создаёте — вы эксплуатируете»: оставляйте команду, понимающую услугу, ответственной за её надёжность, или, как минимум, проводите сознательный, документированный переход услуги с общими дежурствами и гарантийным периодом. Стена между разработкой и эксплуатацией — место, где знания, владение и безопасность проваливаются.

3. Устанавливайте SLO с клиницистами и управляйте бюджетом ошибок. Определите, что значит «достаточно надёжно» для каждой услуги, как измеримые SLI и SLO и устанавливайте их совместно с клиницистами, несущими последствия: целевые значения доступности для системы отделения неотложной помощи — не чисто технический выбор. Используйте бюджет ошибок, чтобы арбитрировать вечное напряжение между поставкой функций и сохранением стабильности: когда надёжность потрачена, остановитесь и стабилизируйтесь. Держите внешние SLA мягче внутренних SLO, чтобы у вас было место действовать до нарушения обещания.

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

5. Ведите дисциплинированное управление инцидентами, проблемами и изменениями, соразмерно. Дайте инцидентам ясные уровни тяжести, целевые сроки реагирования, руководителя инцидента для крупных и единый источник истины во время реагирования. Подавайте серьёзные инциденты в пересмотры после инцидента без обвинений и процесс управления проблемами, устраняющий первопричины, а не раз за разом перезапускающий сервер. Контролируйте изменения процессом подходящего размера: лёгкие, стандартные, заранее одобренные изменения для рутинной низкорисковой работы; рассмотрение советом по изменениям только для действительно рискованных, чтобы управление защищало безопасность, не становясь узким местом, соблазняющим людей его обходить.

6. Репетируйте крупные инциденты и клинический простой, а не просто документируйте их. Пишите, тестируйте и регулярно отрабатывайте процедуры непрерывности бизнеса и клинического простоя: как уход продолжается на бумаге, как персоналу сообщают, что система не работает, как данные сверяются при восстановлении и кто объявляет и командует крупным инцидентом. Непроверенные планы проваливаются в день. Свяжите это явно с вашим управлением клиническими рисками и журналом опасностей (см. тему 1.6 — Клиническая безопасность и управление рисками), потому что простой — клиническая опасность со смягчением, которое можно отрепетировать.

7. Относитесь к обучению после инцидентов как к бесвинному и системному. После каждого значимого инцидента проводите пересмотр, спрашивающий, как система допустила сбой, а не кого винить, потому что обвинение загоняет сообщения в подполье и повторяет вред. Фиксируйте действия, назначайте владельцев и отслеживайте до закрытия; возвращайте закономерности в управление проблемами и проект. Культура обучения — контроль безопасности пациентов, зеркало «справедливой культуры» клинической регистрации инцидентов.

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

9. Сделайте дежурства устойчивыми, а поддержку человечной. Проектируйте графики дежурств, достаточно укомплектованные, справедливо оплачиваемые и гуманные, с ясной эскалацией и реалистичными ожиданиями: выгоревшие реагирующие принимают медленные, склонные к ошибкам решения именно в те моменты, которые важнее всего. Обеспечивайте службу поддержки ресурсами под реальный спрос круглосуточного клинического персонала и дайте персоналу переднего края быстрый, уважаемый путь сообщать о проблемах. Качество вашей поддержки — качество ухода, который персонал переживает от вашей услуги.

10. Планируйте вывод из эксплуатации как контролируемую операцию. Решите, пока услуга действует, как она в конце концов будет выведена: миграция или архивирование данных по закону о хранении записей, перенаправление пользователей, уведомление клиницистов и сохранение журнала опасностей и следа аудита. Незапланированный вывод бросает данные и пользователей и может нарушить законодательные обязанности по хранению. Запланированный — проверяемый операционный проект, а не суматоха, когда приходит замена.

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

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

2. Действительно ли мы финансируем и комплектуем «эксплуатацию» или мы отпраздновали запуск и тихо ушли? Большая часть стоимости и клинического риска услуги приходится на период после запуска, но модели финансирования вознаграждают создание нового и обескровливают ведение старого. Напряжение для обсуждения — структурное притяжение финансирования разработки против непривлекательной, существенной работы по мониторингу, обновлению, поддержке и итерации действующей услуги годами. Посмотрите честно на ваш действующий парк: у скольких услуг есть названный владелец, финансируемая команда, актуальные обновления безопасности и работающий мониторинг, а сколько осиротели, работают на неподдерживаемом ПО, и никто не отвечает? Подумайте о паттерне «перебросить через стену операторам» и о том, понимают ли люди, ведущие каждую услугу, как она была создана. Хороший ответ может указать на защищённые бюджеты эксплуатации, названных владельцев услуг на операционную жизнь и сознательный переход услуги, а не оставление, и может честно назвать осиротевшие услуги, чтобы их можно было принять, заменить или вывести, а не оставить рухнуть.

3. Как мы решаем, что значит «достаточно надёжно», и у кого есть право голоса? Надёжность не бесплатна, и погоня за дополнительной девяткой доступности может стоить больше вреда, который она предотвращает; но в клинических системах «приемлемый» простой — суждение о безопасности, которое инженеры не могут принять в одиночку. Этот вопрос спрашивает, есть ли у вас явные SLI и SLO, устанавливались ли они вместе с клиницистами и операционными руководителями, несущими последствия, и используете ли вы что-то вроде бюджета ошибок, чтобы уравновесить поставку улучшений и сохранение стабильности. Обсудите разницу между внутренней целью, по которой вы управляете, и внешним SLA, который обещаете, и измеряет ли ваш мониторинг то, что клиницисты переживают на самом деле, или только то, что сообщают серверы. Подумайте, есть ли у «мы стремимся к 99,9%» зубы: определённое измерение, последствие при нарушении, владелец, который действует. Хороший ответ связывает целевую надёжность с обоснованием клинической безопасности, показывает, что метрика измеряется и имеет владельца, и описывает, что команда делает иначе, когда бюджет потрачен, а не число на слайде, по которому никто не управляет.

4. Знаем ли мы на самом деле, что у нас работает, и могли бы мы ответить «что это изменение затронет?» посреди инцидента? Большинство крупных парков здравоохранения и ухода слабее всего именно там, где больнее всего: никто не держит точной, актуальной картины того, что работает, что от чего зависит, какие версии развёрнуты и кто владеет каждой услугой. Этот вопрос проверяет, ведёте ли вы запись конфигурации (CMDB или эквивалент) или это знание живёт в головах горстки людей и десятилетии недокументированных интеграций. Обсудите реальные последствия: изменение, тихо ломающее нижестоящую систему, обновление безопасности, которое нельзя применить, потому что никто не знает, что оно затронет, неподдерживаемый сервер, обнаруженный только когда он отказывает или его эксплуатируют. Напряжение в том, что управление конфигурацией непривлекательно, никогда не завершается и его легко отложить, но оно лежит в основе безопасных изменений, обновлений, лицензирования и киберустойчивости, то же слепое пятно, которое превратило WannaCry в кризис. Честный ответ описывает поддерживаемый перечень с владельцами и зависимостями, которому люди доверяют и которым пользуются во время инцидентов, и называет части парка, остающиеся тёмными, а не заявляет полноту, которой на самом деле нет ни у одной крупной организации.

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

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

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

Интегрированная система ухода (ICS) ведёт общую карту ухода, используемую больничными клиницистами, врачами общей практики, общественными командами и службами вне рабочего времени по всему региону. Она запущена два года назад; программа разработки закрыта, и теперь ей владеет постоянная продуктово-операционная команда. Эта команда выучила управление услугами трудным путём.

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

Затем они привели практики к подходящему размеру. Рутинные, низкорисковые обновления конфигурации стали стандартными заранее одобренными изменениями, выпускаемыми через автоматизированный конвейер с быстрым откатом; только действительно рискованные изменения идут на еженедельный пересмотр изменений с клиническим представительством. Гуманный график дежурств покрывает ночи и праздники, подкреплённый службой поддержки, обеспеченной ресурсами под реальный круглосуточный спрос. Решающе важно, что они написали и теперь дважды в год репетируют процедуру клинического простоя: кэшированная копия ключевых записей только для чтения, бумажный запасной вариант, каскад SMS, сообщающий клиницистам, что система деградировала, и шаг сверки при восстановлении. Когда прошлой весной отказ питания центра обработки данных отключил основную систему на сорок минут, уход продолжился на проверенном запасном варианте, руководитель инцидента провёл спокойное координированное реагирование, и ни один пациент не пострадал. Совет увидел отчёт о надёжности, привязанный к мерам клинической безопасности, а не расплывчатое заверение, а владение услугой до её возможного вывода названо и профинансировано.

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

Стартап#

У небольшой компании health-tech часто нет отдельной операционной функции, поэтому «вы создаёте — вы эксплуатируете» — значение по умолчанию, а не стремление: те же инженеры, что писали код, носят пейджер. Преимущество — быстрая обратная связь и отсутствие стены, через которую нужно перебрасывать работу; опасность — график дежурств из двух человек, ни устойчивый, ни безопасный, и мониторинг, останавливающийся на «работает ли сервер?». Стартапам следует принять SLO, базовую наблюдаемость, пересмотры после инцидентов без обвинений и письменную процедуру простоя с первого клиента NHS, потому что клинический сбой может закончить и контракт, и компанию. Даже без церемонии ITIL замысел (видеть услугу, быстро реагировать, учиться системно, сохранять пациентов в безопасности, когда она отказывает) не подлежит обсуждению в здравоохранении.

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

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

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

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

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

Национальный орган ведёт услуги, которые могут затрагивать миллионы, поэтому сбой — национальный инцидент с последствиями для парламента и общественного доверия, а целевые значения надёжности — предмет публичной подотчётности. Государственная поставка сочетает ITSM с ожиданием GOV.UK Service Manual, что действующие услуги надлежащим образом эксплуатируются, отслеживаются и итерируются, а не замораживаются при запуске, и с законодательными обязанностями по хранению записей и кибербезопасности (NCSC, DSPT). Контроль расходов и многолетние соглашения о финансировании формируют то, как выглядит финансирование «эксплуатации», а огромный масштаб повышает ставки непрерывности бизнеса, координированного реагирования на крупные инциденты и безопасного вывода унаследованных национальных систем с десятилетиями записей. Компромисс — гарантии и устойчивость против скорости и стоимости, разрешаемый открыто под контролем.

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

• Перебросить через стену операторам. Команда разработки передаёт услугу операционной команде, которая никогда не видела, как её делали; знание, владение и безопасность проваливаются в разрыв. Противоядие: «вы создаёте — вы эксплуатируете» или сознательный переход с гарантийным периодом и общим дежурством.
• Осиротевшая действующая услуга. Проект закрывается, команда распускается, финансирование эксплуатации испаряется; услуга гниёт, остаётся необновлённой и тихо накапливает клинический и киберриск. Противоядие: названный владелец услуги и защищённый бюджет эксплуатации на операционную жизнь.
• Мониторинг серверов, а не услуги. Всё «зелёное», пока клиницисты видят устаревшие или отсутствующие данные. Противоядие: SLI, отражающие опыт пользователя и клинициста, с оповещением о симптомах, имеющих значение.
• Непроверенные планы непрерывности. Процедура клинического простоя есть на бумаге, но никогда не репетировалась, поэтому проваливается в день. Противоядие: регулярно отрабатывать планы крупных инцидентов и простоя и исправлять то, что ломается.
• Пересмотры инцидентов с обвинениями. Поиск виновных загоняет сообщения в подполье и повторяет вред. Противоядие: бесвинное, системное обучение после инцидентов с отслеживаемыми действиями.
• Театр процесса изменений. Совет по изменениям настолько тяжёл, что команды его обходят, или настолько лёгок, что рискованные изменения выпускаются без проверки. Противоядие: подобрать размер: заранее одобрять стандартные изменения, резервировать рассмотрение для действительно рискованных.
• Нет записи конфигурации. Никто не может ответить «что затронет это изменение?» во время инцидента. Противоядие: вести CMDB или эквивалент с владельцами и зависимостями.

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

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

• У каждой действующей услуги есть названный владелец и защищённый бюджет эксплуатации на её операционную жизнь.
• Команда, ведущая каждую услугу, понимает, как она была создана (или существует задокументированный переход с гарантией и общим дежурством).
• SLI и SLO определены, а целевые значения клинических систем устанавливались с клиницистами; внешние SLA мягче внутренних SLO.
• Наблюдаемость (журналы, метрики, трассировки) и оповещение о симптомах отражают опыт клинициста и пользователя, а не только здоровье серверов.
• Управление инцидентами имеет уровни тяжести, целевые сроки реагирования, роль руководителя инцидента и единый источник истины во время реагирования.
• Управление проблемами устраняет первопричины; пересмотры после инцидентов бесвинны, а их действия отслеживаются до закрытия.
• Управление изменениями подобрано по размеру: стандартные изменения заранее одобрены и автоматизированы; рассматриваются только рискованные, с клиническим вкладом.
• Процедуры непрерывности бизнеса и клинического простоя написаны, связаны с журналом опасностей и репетируются не реже раза в год.
• Графики дежурств достаточно укомплектованы, гуманны и справедливо оплачиваются; служба поддержки обеспечена ресурсами под реальный круглосуточный спрос.
• Запись конфигурации (CMDB или эквивалент) перечисляет компоненты, зависимости, версии и владельцев и поддерживает обновления безопасности.
• План вывода из эксплуатации охватывает миграцию/архивирование данных по закону о хранении, перенаправление пользователей и сохранение записей безопасности и аудита.

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

• ITIL 4: система создания ценности услуг и практики управления (инциденты, проблемы, изменения, служба поддержки, управление уровнем услуг) — PeopleCert / AXELOS.
• Google — Site Reliability Engineering и The Site Reliability Workbook (SLI, SLO, бюджеты ошибок, дежурства, бесвинные пост-мортемы).
• GOV.UK Service Manual: эксплуатация и итерация действующей услуги; мониторинг статуса услуги; поддержка услуги после запуска.
• NHS England — стандарты управления клиническими рисками DCB0129/DCB0160 и отношение к простою системы как к клинической опасности (см. тему 1.6).
• NHS England / NCSC — операции кибербезопасности, Data Security and Protection Toolkit (DSPT) и уроки инцидента WannaCry 2017 года (см. тему 1.7).
• ISO/IEC 20000 (управление ИТ-услугами) и ISO 22301 (системы менеджмента непрерывности бизнеса).
• DevOps Research and Assessment (DORA): возможности, связывающие поставку и операционную результативность (мониторинг, изменения, надёжность).
• OKR и KPI для отчётности руководству об операционной деятельности и надёжности (см. тему 10.0 — Цели и ключевые результаты (OKR)).

Ссылки#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/