Наблюдаемость и эксплуатация живой телемед-платформы

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Когда на платформе появляются реальные пациенты, вопрос «работает ли она?» перестаёт быть инженерной мелочью и становится вопросом безопасности пациента и юридической обязанности. 152-ФЗ требует защищать персональные данные не только от утечки, но и от блокирования и уничтожения (ст. 19 ч. 1), а приказ Минздрава 193н отводит на экстренную телемедицинскую консультацию от 30 минут до 2 часов. В продакшене приходится решать две задачи сразу: поддерживать работу сервиса (наблюдаемость и дежурства) и доказывать, кто что делал с данными пациента (регистрация и учёт всех действий с ПДн – ст. 19 ч. 2 п. 8 152-ФЗ и меры РСБ приказа ФСТЭК № 21). Сложность в том, чтобы делать первое, не нарушая второго: внимательно следить за каждой консультацией, не пуская медданные в эксплуатационные логи, дашборды и сторонние инструменты, и держать всю телеметрию на серверах в России, потому что зарубежный SaaS-мониторинг с персональными данными упирается в запрет зарубежных баз (ст. 18 ч. 5). Ниже – практическое руководство для продакшена: сигналы, целевые показатели сервиса, дежурства, self-hosted стек в российском облаке и связь мониторинга с 24-часовым сроком уведомления Роскомнадзора.

Зачем это читать

Если потребительское видеоприложение обрывает звонок, человек просто перезванивает. Если звонок обрывает телемед-платформа, может прерваться консультация с человеком в кризисе, послеоперационный контроль или консилиум по пациенту с инсультом, где счёт идёт на минуты. Тому, кто отвечает за работу такой платформы, – основателю, ИТ-директору клиники, продакт-менеджеру, который впервые выстраивает эксплуатацию, – нужно знать, какие сигналы отслеживать, что считать чрезвычайной ситуацией и где через стек мониторинга проходит граница медданных. Статья переводит «запустить в продакшен» в конкретную практику эксплуатации с учётом 152-ФЗ и 323-ФЗ. Тогда худший день на платформе станет контролируемым инцидентом, который хорошо виден в мониторинге, а не тихим сбоем, о котором узнали, только когда позвонил врач.

«Работает» – теперь клиническое понятие

Начнём с правил: они меняют взгляд на всё остальное. Статья 19 152-ФЗ обязывает оператора защищать персональные данные «от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения». Медданные – сведения о здоровье конкретного человека – это специальная категория персональных данных (ст. 10), а факт обращения, диагноз и всё, что стало известно при лечении, – ещё и врачебная тайна (ст. 13 323-ФЗ). На видеоплатформе сюда входят сама консультация, запись, чат и даже факт, что конкретный пациент встретился с конкретным психиатром в определённый день.

Большинство команд читают «доступ» и «распространение» и на этом останавливаются. Но «блокирование» и «уничтожение» стоят в том же списке. Когда платформа лежит, данные пациента недоступны врачу, которому они нужны, и это вопрос мер защиты, а не только аптайма. Это подтверждает и состав мер: приказ ФСТЭК № 21 выделяет отдельные группы «обеспечение доступности персональных данных» (ОДТ, включая периодическое резервное копирование) и «обеспечение целостности» (ОЦЛ); сам 152-ФЗ требует восстанавливать данные, изменённые или уничтоженные при несанкционированном доступе (ст. 19 ч. 2 п. 7); а для электронных медицинских документов приказ Минздрава 209н требует резервного копирования и журналирования доступа.

Есть и чисто клиническая сторона. Приказ 193н задаёт сроки телемедицинских консультаций: в экстренной форме – от 30 минут до 2 часов, в неотложной – от 3 до 24 часов (п. 19), а по ОМС соблюдение сроков контролируют страховые медицинские организации. Простой в 40 минут может целиком съесть окно экстренной консультации.

Поэтому продакшен-мониторинг – не украшательство. Это доказательство того, что вы умеете обеспечивать конфиденциальность, целостность и доступность медданных. Как резервный генератор в больнице: никто не называет его роскошью, потому что все понимают, что «нет электричества» – клиническое событие. На телемед-платформе «сервис лежит» – событие того же рода.

Мониторинг решает две задачи сразу

На этой идее построена вся статья: на телемед-платформе инфраструктура логирования и мониторинга решает две разные задачи одновременно, и требования у них противоположные.

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

Вторая задача – комплаенс: доказывать, кто что сделал с данными пациента. Закон требует этого напрямую. Ст. 19 ч. 2 п. 8 152-ФЗ включает в меры безопасности установление правил доступа к персональным данным и «обеспечение регистрации и учёта всех действий, совершаемых с персональными данными» в информационной системе. Приказ ФСТЭК № 21 раскладывает это на группу мер «регистрация событий безопасности» (РСБ): сбор, запись, хранение и защита информации о событиях безопасности, а также её просмотр и анализ. Для электронных медицинских документов журналирование доступа требует 209н. Этот журнал обязан фиксировать доступ к медданным: кто открыл чью карту, когда и что сделал. Состав событий и сроки хранения подробно разобраны в статье о журналах аудита и контроле доступа.

Нажмите, чтобы увеличить

Главная сложность – в противоречии между ними. Дашборды эксплуатации должны быть очищены от медданных, чтобы их могли свободно смотреть инженеры и подрядчики. Журнал аудита устроен наоборот: он намеренно фиксирует доступ к медданным, находится внутри границы медданных, открыт узкому кругу и хранится годами. С самого начала стройте их как два раздельных конвейера. Если их смешать – отправить журнал аудита с идентификаторами пациентов в общий дашборд или выдать очищенный эксплуатационный лог за запись аудита, – значит одним решением провалить обе задачи.

Что наблюдать: три слоя сигнала

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

Слой 1 – инфраструктура и сервисы. Основа: работают ли серверы, базы, сигналинг и API, быстро ли они отвечают, нормальна ли доля ошибок. Здесь хорошо справляются стандартные инструменты, и этот слой необходим, но недостаточен. Платформа может быть «вся зелёная» на этом уровне, пока пациенты не могут завершить ни одного визита, потому что сбой происходит уровнем выше.

Слой 2 – реальное видео каждой консультации. Этот слой телемед-команды упускают чаще всего. WebRTC – браузерная технология, которая передаёт живое аудио и видео, – отдаёт богатый набор показателей качества через функцию getStats(), стандартизованную W3C. Для каждого звонка можно читать потери пакетов (долю аудио- и видеопакетов, которые не дошли), джиттер (насколько неравномерно приходят пакеты), круговую задержку (RTT – сколько миллисекунд пакет идёт туда и обратно), а также разрешение и частоту кадров. Именно эти цифры решают, разглядит ли врач рану и уловит ли эмоциональное состояние пациента.

Любой, кто эксплуатировал платформу реального времени, знает нюанс: каждое чтение getStats() – единичный снимок. Чтобы понять качество, показатели нужно снимать весь звонок, отправлять на бэкенд компактную сводку по консультации и агрегировать по звонкам. Серверный дашборд может показывать «SFU в порядке», пока у конкретного пациента в конкретной домашней сети звонок деградировал настолько, что клинически бесполезен. Точнее всего качество видно на стороне клиента, поэтому собирайте его там – по каждой консультации.

Слой 3 – клиническая воронка. Вопрос уровня бизнеса: происходят ли визиты на самом деле? Отслеживайте воронку: записан → вошёл (через ЕСИА) → встал в зал ожидания → соединился с врачом → консультация завершена → протокол подписан. Резкое падение между «встал в зал ожидания» и «соединился» – продакшен-инцидент, даже если все серверы зелёные и все метрики видео в норме: пациенты сидят в виртуальной приёмной, которая их так и не соединяет. Эта воронка ещё и самый ранний и чёткий сигнал, что у реальных пользователей что-то не так.

Нажмите, чтобы увеличить

Целевые показатели, которые важны врачам

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

SLI (Service Level Indicator, показатель уровня сервиса) – одна измеримая цифра, отражающая опыт пользователя, например «доля визитов, соединившихся за 10 секунд». SLO (Service Level Objective, целевой уровень) – целевое значение этой цифры, например «99,5% визитов соединяются за 10 секунд на скользящем окне в 30 дней». Бюджет ошибок – просто остаток: 100% минус SLO. Если SLO доступности 99,9%, бюджет ошибок – 0,1%, и его стоит перевести в минуты.

Посчитаем – результат многих удивляет. В месяце около 43 200 минут. Бюджет ошибок 0,1% – это:

43 200 минут × 0,001 = 43,2 минуты в месяц

То есть цель доступности 99,9% разрешает примерно 43 минуты простоя в месяц – больше, чем нижняя граница окна экстренной консультации по 193н. При 99,99% бюджет сжимается примерно до 4,3 минуты в месяц. Достичь этого трудно и дорого, и обычно это оправдано только для помощи, где критично время, например для экстренных консультаций «врач – врач». Бюджет ошибок – инструмент планирования: когда он израсходован, вы перестаёте выкатывать рискованные изменения и посвящаете следующий спринт надёжности.

Для телемед-платформы значимые для врачей SLO привязаны к визиту, а не к инфраструктуре. Разумный стартовый набор выглядит так.

Две оговорки. Первая: это стартовые значения, которые нужно калибровать под вашу клиническую практику, а не отраслевые гарантии. У дерматологии с отложенными консультациями и у телеинсульта планки разные; см. статью о клинической планке «достаточно хорошо». Вторая: не путайте SLO (внутреннюю цель) с SLA (Service Level Agreement – договорным обещанием клиенту, часто со штрафами). Месяцами отрабатывайте SLO внутри команды, прежде чем вписывать любую цифру в договор с клиникой или страховой компанией.

Алерты и дежурства для медицинского продукта

Алерт должен означать одно: на это нужно посмотреть прямо сейчас, потому что затронуты пациенты. Систему алертов чаще всего губят две ошибки, и обе встречаются постоянно.

Первая – алерты на причины вместо симптомов. Вызов дежурного по «CPU 85%» будит человека ради цифры, которая может ничего не значить. Вызов по «успешные соединения визитов упали ниже 98% за последние 5 минут» будит, потому что пациенты прямо сейчас не могут начать визиты. Настраивайте алерты на симптомы, заметные пациенту (то есть на SLI), а причину пусть ищет дежурный. То же советует документация Prometheus: алертить на симптомы, связанные с проблемами конечного пользователя, а не на каждую возможную причину. Вторая ошибка – усталость от алертов: когда звенит всё, не слышно ничего, и единственный важный алерт теряется в шуме. Жёстко настраивайте пороги, чтобы вызов был редким и всегда обоснованным.

Здравоохранение меняет модель дежурств в трёх отношениях. Первое: платформа работает не только в часы приёма. Консультации психологов и психотерапевтов идут вечерами и в выходные, экстренные консультации «врач – врач» – в любое время суток, а Россия – это 11 часовых поясов: ночь в Москве – утро во Владивостоке. Телемед-платформе обычно нужно полноценное покрытие 24/7 задолго до того, как оно понадобилось бы потребительскому приложению, потому что периодов, когда на связи нет ни одного пациента, почти не бывает. Второе: дистанционное наблюдение – это тоже алертинг. По 193н при дистанционном наблюдении лечащий врач задаёт пороговые значения показателей и обеспечивает экстренное реагирование (п. 43–46). Если конвейер данных с тонометров и глюкометров остановился, врач не увидит выхода за порог, поэтому задержка поступления данных наблюдения сама по себе заслуживает алерта высокой серьёзности. Третье: некоторые сценарии не должны отказывать молча. Если продукт работает с ментальным здоровьем, путь эскалации при кризисе – сценарий, который соединяет человека в опасности с 112, скорой (103) и телефонами доверия, – единственный компонент, чей отказ означает настоящую ЧС. Ему нужен свой монитор и свой алерт высшей серьёзности, отдельно от всего остального. (Как строить сам путь, разобрано в статье о телемедицине ментального здоровья; здесь мысль проще: мониторьте его так, будто от него зависит жизнь, – потому что так и может быть.)

Заведите простую шкалу серьёзности, чтобы реакция соответствовала риску. Отказ кризисного пути, потока данных наблюдения или полный простой – немедленный вызов, 24/7. Частичная деградация (один регион, рост обрывов) – вызов в часы покрытия. Медленный тренд (бюджет ошибок расходуется быстрее плана) – задача в трекере, а не звонок в 2 часа ночи. Запишите это до запуска, а не во время первого инцидента. И помните, что текст алерта – тоже телеметрия: в корпоративный мессенджер, SMS или звонок дежурному уходят идентификатор визита и симптом, но не ФИО и не диагноз.

«Типичная ошибка: зелёные дашборды, сломанные визиты. Самый частый провал эксплуатации телемедицины – доверять здоровью серверов, пока у пациентов на периферии сети всё ломается. Все метрики инфраструктуры зелёные, поэтому алерт не срабатывает, но конкретная группа пользователей (старые Android-смартфоны, один региональный мобильный оператор, неверно настроенный TURN-сервер) не может соединиться. Вы узнаёте об этом, только когда жалуется врач. Решение – настроить алерты на клиническую воронку и на качество видео по данным клиента, а не только на инфраструктуру. Если «завершённые визиты в час» упали, а дежурного никто не вызвал, в мониторинге дыра.»

Наблюдать всё, не логируя медданные

Эта часть специфична для здравоохранения, и именно в ней команды чаще всего ошибаются. Вам нужна глубокая видимость продакшена, и вы отправляете данные во множество инструментов: трекеры ошибок, агрегаторы логов, APM, аналитику. Каждый из них – место, куда могут утечь медданные, и каждая такая утечка – потенциальный инцидент с 24-часовым сроком уведомления.

Важно различать две вещи. Журнал аудита обязан содержать сведения о доступе к медданным: он фиксирует, что пользователь X открыл карту пациента Y в момент Z. Его требует ст. 19 ч. 2 п. 8, он хранится внутри границы медданных, его разбирают по графику, а срок хранения оператор определяет и фиксирует письменно (мера РСБ.1) – конкретной цифры ни 152-ФЗ, ни ПП 1119, ни приказ № 21 не называют. Журнал выполняет свою функцию именно потому, что фиксирует доступ.

С эксплуатационной телеметрией всё наоборот. Сообщения об ошибках, логи запросов, трейсы, метрики, краш-отчёты, продуктовая аналитика – ничто из этого не должно содержать медданных. Здесь действует принцип ст. 5 ч. 5 152-ФЗ: обрабатываемые персональные данные не должны быть избыточными по отношению к заявленным целям. Чтобы сообщить, что сервис работает плохо, мониторингу почти никогда не нужны ФИО или диагноз пациента. И помните про врачебную тайну: строка лога «пациент записан к психиатру» раскрывает факт обращения, даже если диагноза в ней нет.

На практике очищайте данные у источника. Идентифицируйте пользователей в логах непрозрачным внутренним ID, никогда – ФИО, телефоном, e-mail, номером полиса или СНИЛС. Не допускайте идентификаторы пациента и любые клинические детали в URL, тексты ошибок, тела исключений и события аналитики: краш-отчёт с ?patient=Ivanova+Anna&dx=F32 уже отправил медданные в ваш трекер ошибок. Маскируйте или отбрасывайте свободные текстовые поля – жалобы, чат, комментарии – до того, как они попадут в лог.

Где размещён стек. В России добавляется вопрос, который многие руководства пропускают: где физически хранится телеметрия. С 1 июля 2025 года 152-ФЗ прямо запрещает запись, систематизацию и хранение персональных данных граждан РФ в базах данных за рубежом (ст. 18 ч. 5; штраф для юрлица – до 6 млн ₽, повторно – до 18 млн ₽), а отправка данных зарубежному сервису – ещё и трансграничная передача, о которой нужно заранее уведомить Роскомнадзор (ст. 12). Лог, в который просочились телефон или e-mail пациента, содержит персональные данные, и зарубежный SaaS для мониторинга превращается в зарубежную базу с ПДн. Поэтому для медицинского продукта стандарт – self-hosted стек в российском облаке с аттестатом по 152-ФЗ, внутри границы медданных или рядом с ней:

• метрики – Prometheus и Alertmanager, дашборды – Grafana;
• логи – Loki или OpenSearch;
• трейсы – OpenTelemetry Collector с Jaeger или Tempo;
• ошибки и краши – Sentry в self-hosted-развёртывании на собственных серверах;
• сводки качества звонков из getStats() – собственное хранилище событий, например ClickHouse.

Держите собственное зеркало образов и пакетов: доступность зарубежных репозиториев из России не гарантирована. Встроенные сервисы мониторинга и логирования российских облаков тоже подходят, если они входят в аттестованный контур и с провайдером оформлены договорные условия. Любой подрядчик, который может увидеть медданные, даже в российском облаке, работает по поручению оператора (ст. 6 ч. 3 152-ФЗ): в договоре – перечень данных и действий, цели, конфиденциальность, требования ст. 19 и обязанность сообщать об инцидентах. Подробно – в статье о поручении обработки ПДн и договорах с подрядчиками. Лучшее решение снимает вопрос целиком: инструмент просто не видит медданных.

Нажмите, чтобы увеличить

Повторим предупреждение, которое проходит через весь курс: «зашифровано» не значит «законно». Лог, отправленный по TLS в зарубежный сервис, всё равно лежит в зарубежной базе; лог, отправленный подрядчику без поручения, всё равно передан без основания. Шифрование защищает данные при передаче, а законной обработку делают поручение, локализация и меры ст. 19.

Мониторинг запускает отсчёт сроков по утечке

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

По ст. 21 ч. 3.1 152-ФЗ, если установлен факт неправомерной или случайной передачи, предоставления, распространения или доступа к персональным данным, повлёкший нарушение прав пациентов, оператор обязан уведомить Роскомнадзор в течение 24 часов (что произошло, предполагаемые причины, вред, принятые меры, контактное лицо), а в течение 72 часов – сообщить результаты внутреннего расследования и, если они установлены, виновных. Самое тонкое и дорогое – с какого момента считать. Отсчёт идёт с момента выявления инцидента оператором, Роскомнадзором или иным заинтересованным лицом. Проще говоря, незнание отсчёт не останавливает: если утечку первым нашёл исследователь безопасности или регулятор, время уже идёт, а вы об этом ещё не знаете.

Параллельно работают ещё два канала. Об инцидентах, повлёкших неправомерную передачу ПДн, оператор информирует ГосСОПКА (ст. 19 ч. 12; приказ ФСБ № 77): напрямую в НКЦКИ в течение 24 часов, если есть соглашение о взаимодействии, или через Роскомнадзор. Кроме того, здравоохранение – сфера критической информационной инфраструктуры: распоряжение Правительства № 360-р от 26.02.2026 включило в перечень типовых отраслевых объектов информационные системы медорганизаций и иные системы, взаимодействующие с ЕГИСЗ. Является ли ваша система объектом КИИ, решает категорирование, но если она значимый объект, об инциденте нужно сообщить в НКЦКИ не позднее 3 часов с момента обнаружения (приказ ФСБ № 547). Цена ошибки конкретна: неуведомление Роскомнадзора стоит юрлицу 1–3 млн ₽ (ч. 11 ст. 13.11 КоАП), утечка данных о здоровье – 10–15 млн ₽ (ч. 16).

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

Нажмите, чтобы увеличить

Куда движется регулирование: 24 июля 2026 года ФСТЭК опубликовала проект приказа на замену № 21 (regulation.gov.ru, № 169583). На конец сентября 2026 года он не подписан, но направление ясно: показатель зрелости защиты; оценка защищённости до начала обработки, не реже раза в три года и после каждого инцидента; меры для ИИ, контейнеров и API; требования к обработчикам по поручению. Для государственных медорганизаций с 1 марта 2026 года действует приказ ФСТЭК № 117. Фактически это описанная здесь программа, закреплённая в нормах: готовьтесь к ней уже сейчас, а финальный текст сверяйте с юристом.

Где здесь Фора Софт

Фора Софт с 2005 года строит продукты с видео в реальном времени – видеоконференции, стриминг, e-learning, видеонаблюдение и телемедицину, – и описанная практика – то, как мы поддерживаем клинические видеопродукты после запуска. Мы собираем метрики видео по каждой консультации и клинической воронке, а не только по инфраструктуре; держим журнал аудита и эксплуатационную телеметрию в раздельных конвейерах и разворачиваем стек наблюдаемости в российском облаке, чтобы медданные не попадали в сторонние и зарубежные инструменты; кризисный путь и поток данных дистанционного наблюдения считаем компонентами высшей серьёзности. Сначала называем требование – защита от блокирования, регистрация действий с ПДн, 24-часовой срок, – затем строим мониторинг, который ему отвечает.

Главное

• 152-ФЗ защищает медданные и от блокирования и уничтожения, а 193н задаёт сроки консультаций: аптайм платформы стал обязанностью, а не пожеланием.
• Регистрацию и учёт всех действий с ПДн требуют ст. 19 ч. 2 п. 8 152-ФЗ и меры РСБ приказа ФСТЭК № 21, так что мониторинг – это ещё и юридический контроль.
• Собирайте сигналы с трёх слоёв: инфраструктуры, качества видео по консультации через getStats() и клинической воронки.
• Ставьте SLO на визит (соединение, обрывы, качество); 99,9% доступности ≈ 43 минуты простоя в месяц.
• Очищайте эксплуатационные логи от медданных и держите весь стек наблюдаемости в России (Prometheus, Grafana, Loki, self-hosted Sentry); подрядчику, который может увидеть медданные, нужно поручение.
• Мониторинг выявляет утечки, а с выявления начинается отсчёт: Роскомнадзор – 24 и 72 часа, значимый объект КИИ – 3 часа.

Что читать дальше

• Тестирование клинического видео: QA на надёжность и комплаенс
• Журналы аудита и контроль доступа для клинического видео
• Реагирование на инциденты и уведомление об утечках