SLA IT-подрядчика клиники: как отличить поддержку от обещания «посмотрим»

• Опубликовано: 20 сентября 2026 г.

Фраза «мы всегда на связи» звучит как гарантия — до первой пятницы, когда в 18:40 перестаёт открываться МИС. Подрядчик отвечает в мессенджере через две минуты: «Смотрим». Регистратура видит очередь, врач не понимает, можно ли продолжать приём, руководитель ждёт прогноз. Через час выясняется, что быстрый ответ был не началом решения, а вежливым подтверждением сообщения.

SLA нужен не для того, чтобы измерить скорость слова «принято» и потом выставить штраф. Его ценность в предсказуемом маршруте: что клиника считает инцидентом, кто определяет влияние, когда подключается нужный специалист, как часто приходит обновление, какой резервный сценарий действует и по какому признаку работу действительно можно закрыть.

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

SLA начинается не со времени, а с результата клиники

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

Опишите критичные результаты:

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

Только после этого назначайте уровни приоритета. Иначе приоритет будет зависеть от громкости звонящего.

Реакция, диагностика, восстановление и решение — четыре разных часа

В договоре часто пишут «реакция — 15 минут». Заказчик читает это как «через 15 минут всё заработает», подрядчик — как «через 15 минут мы зарегистрируем заявку». Оба формально могут быть правы, но клинике от этого не легче.

Разделите этапы:

Для некоторых инцидентов восстановление возможно быстро, а корневая причина требует дней. SLA должен позволять честно разделять эти состояния.

Приоритет определяет влияние, а не название оборудования

Поломка дорогого сервера не автоматически важнее сбоя единственного сканера на стойке, если сервер резервирован, а сканер остановил поток пациентов. Матрица приоритета учитывает масштаб, критичность процесса, наличие обхода и срочность.

Пример логики, которую клиника должна адаптировать:

Таблица не является отраслевым нормативом. Она нужна, чтобы две стороны одинаково классифицировали конкретное влияние.

Кто имеет право повысить или понизить приоритет

Если подрядчик может самостоятельно понизить заявку, потому что «сервер отвечает», клиника рискует остаться с неработающим процессом. Если любой сотрудник может объявить максимальный приоритет, красный уровень быстро потеряет смысл.

Зафиксируйте:

• кто со стороны клиники подтверждает влияние;
• кто со стороны подрядчика классифицирует технический симптом;
• как разрешается спор;
• когда приоритет автоматически повышается;
• как учитывается появление обхода;
• кто уведомляется при критическом уровне.

Решение должно опираться на проверяемые признаки. «Очень срочно» — не признак. «Два филиала не могут открыть расписание, утверждённого обхода нет» — признак.

«Поддержка 24/7» нужно разобрать по ролям

Круглосуточный приём заявки не равен круглосуточной работе инженера нужной квалификации. Дежурный может зарегистрировать инцидент, но специалист по МИС, сетям или медицинскому оборудованию подключится только в своё окно.

Уточните в SLA:

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

Иногда честный режим 8×5 с хорошо подготовленным резервом полезнее формального 24×7, где ночью отвечает только автоответчик.

Тикет — это часть доказательства, а не бюрократия

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

Минимальная карточка обращения:

• время;
• заявитель и его роль;
• затронутый результат;
• масштаб;
• ожидаемое и фактическое поведение;
• безопасный технический ID;
• недавние изменения;
• приоритет и основание;
• назначенный исполнитель;
• следующее контрольное время;
• выполненные действия;
• критерий закрытия.

Не вставляйте в тикет медицинский документ, пароль, токен, raw SIP, запись разговора или дамп базы, если для диагностики достаточно идентификатора и контролируемой выгрузки.

Составной сценарий: подрядчик отвечал мгновенно, а клиника ждала часами

Это учебная реконструкция, а не кейс конкретной организации.

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

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

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

SLA не заменяет резервный сценарий клиники

Даже лучший подрядчик не телепортируется в кабинет и не принимает медицинское решение. Пока идёт диагностика, клиника должна знать, что делает регистратура, врач и руководитель процесса.

Для критичных сервисов согласуйте:

• допустимость временной работы;
• источник истины;
• место контролируемой очереди;
• способ связи с пациентом;
• запрет опасных ручных действий;
• возврат данных после восстановления;
• проверку дублей.

Материал о первых 60 минутах недоступности ЕГИСЗ показывает, почему подрядчик и клиника должны действовать параллельно: один диагностирует технологию, другая удерживает процесс.

Окно плановых работ должно иметь вход и выход

Фраза «работы ночью» не описывает риск. В окне должны быть:

• точный объект;
• причина;
• перечень изменений;
• проверка исходного состояния;
• резерв конфигурации;
• владелец приёмки;
• критерий успеха;
• стоп-условие;
• решение об откате;
• наблюдение после завершения;
• коммуникация пользователям.

Если подрядчик заканчивает в 03:00, а врач обнаруживает проблему в 08:05, кто считается завершившим приёмку? Нужен утренний функциональный тест, а не только сообщение инженера «всё поднялось».

Плановые работы и инцидент — разные режимы

Плановая задача известна заранее, может быть согласована и имеет окно. Инцидент требует восстановления нарушенного результата. Запрос на изменение добавляет новую функцию. Если всё учитывать как «заявки поддержки», отчёт теряет смысл.

Разделяйте минимум:

• инциденты;
• сервисные запросы;
• изменения;
• проблемы с повторяющейся причиной;
• профилактические работы;
• проекты.

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

Граница ответственности должна быть технической и операционной

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

Создайте матрицу:

Строка без владельца — будущая пауза в инциденте. Два владельца без правила координации — будущий спор.

Доступ подрядчика не должен быть вечным ключом

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

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

Проверьте:

• какие RMM/VPN-инструменты установлены;
• кто может подключаться;
• есть ли MFA;
• откуда разрешён вход;
• как согласуется сессия;
• что журналируется;
• как доступ прекращается после договора;
• существует ли аварийный отзыв.

Подробнее процесс временных ролей разобран в статье о контроле доступов подрядчика. А материал о сегментации гостевой, рабочей и медицинской сети показывает, почему сам факт подключения «внутрь» не должен давать инженеру доступ ко всей инфраструктуре.

Мониторинг: кто должен заметить проблему первым

Если клиника всегда узнаёт о сбое от пациента, SLA начинается слишком поздно. Для критичных сервисов согласуйте наблюдаемые признаки:

• доступность пользовательского маршрута;
• глубина очереди;
• возраст последнего успешного события;
• ошибки резервного копирования;
• срок действия сертификата;
• заполнение диска;
• пропущенные звонки;
• недоставка заявок;
• состояние интеграции.

Мониторинг не должен собирать лишние медицинские данные. Он проверяет технические и операционные признаки. Алерт без владельца и действия превращается в шум.

Целевое время решения не всегда можно обещать жёстко

Причина может находиться у третьей стороны, требовать поставку детали или согласование производителя. Это не повод отказаться от обязательств полностью. Разделите:

• срок реакции;
• срок первичной диагностики;
• срок включения доступного обхода;
• частоту обновлений;
• целевое время восстановления;
• исключения и зависимости;
• обязательство вести эскалацию до закрытия.

Фраза «срок зависит от сложности» ничего не даёт. Даже когда время решения неизвестно, время следующего статуса должно быть известно.

Приостановка SLA должна быть прозрачной

Таймер может ожидать ответа клиники, доступ, окно работ или решение третьей стороны. Но «ожидает клиента» иногда используется как удобный способ остановить обязательство.

Зафиксируйте:

• какие события приостанавливают время;
• какое доказательство требуется;
• кому отправляется запрос;
• сколько времени есть на ответ;
• продолжает ли подрядчик параллельные действия;
• когда таймер возобновляется;
• как учитывается нерабочее время.

Запрос «пришлите больше информации» без списка конкретных данных не должен бесконечно замораживать критический инцидент.

Зависимость от третьих сторон не снимает координацию

МИС, провайдер, облако, телефония и медоборудование могут обслуживаться разными компаниями. Клиника не должна становиться курьером между ними во время каждой аварии.

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

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

Закрытие заявки должен подтверждать пользовательский тест

Сервис running, порт открыт и процесс в диспетчере — это технические признаки, но не всегда конечный результат. Закрытие критичного инцидента подтверждает владелец процесса по заранее определённому тесту.

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

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

Ежемесячный отчёт должен отвечать на пять вопросов

1. Какие процессы останавливались или замедлялись?
2. Какие причины повторились?
3. Где нарушены сроки реакции, статуса или восстановления?
4. Какие временные обходы стали постоянными?
5. Какое одно изменение снизит риск в следующем месяце?

Красивые диаграммы количества тикетов вторичны. Если десять обращений о заполненном диске закрывались очисткой, отчёт должен приводить к настройке ёмкости и мониторинга, а не к похвале быстрой поддержки.

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

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

Полезный набор:

• время регистрации;
• время назначения исполнителя;
• время первого содержательного ответа;
• время до обхода;
• время до восстановления;
• соблюдение интервалов обновления;
• число повторных открытий;
• доля инцидентов с установленной причиной;
• число повторяющихся причин;
• число просроченных профилактических действий.

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

Штрафы — последняя часть, а не фундамент

Штраф может дисциплинировать, но не создаёт резерв, компетенцию и наблюдаемость. Если критерии размыты, стороны будут спорить о расчёте. Если размер санкции несопоставим с реальной услугой, подрядчик заложит риск в цену или исключения.

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

Что проверить в цене поддержки

Низкая ежемесячная цена может не включать:

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

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

Красные флаги SLA

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

Чек-лист приложения к договору

• [ ] Каталог поддерживаемых сервисов и границы.
• [ ] Владелец каждого компонента.
• [ ] Критичные пользовательские результаты.
• [ ] Матрица приоритетов по влиянию.
• [ ] Каналы регистрации и единый номер тикета.
• [ ] Определения реакции, диагностики, обхода и решения.
• [ ] Интервалы обновления статуса.
• [ ] Режимы 8×5, 24×7 и роли дежурства.
• [ ] Плановые окна, приёмка и откат.
• [ ] Порядок доступа подрядчика.
• [ ] Мониторинг и владельцы алертов.
• [ ] Эскалация третьим сторонам.
• [ ] Правила приостановки таймера.
• [ ] Критерии закрытия пользовательским тестом.
• [ ] Пост-инцидентный разбор.
• [ ] Ежемесячная отчётность.
• [ ] Передача документации и доступов при завершении договора.
• [ ] Правила работы с данными и журналами.
• [ ] Юридически согласованная ответственность.

Проверка SLA настольным учением

Не ждите настоящей аварии. Выберите три сценария:

1. В начале приёма недоступна МИС.
2. Телефония принимает не все звонки.
3. Резервное копирование две ночи завершалось ошибкой.

Для каждого отправьте синтетическую заявку и измерьте:

• правильно ли выбран приоритет;
• появился ли исполнитель;
• пришёл ли содержательный ответ;
• запустился ли резервный сценарий;
• знает ли регистратура статус;
• есть ли следующий контрольный момент;
• закрывается ли заявка после пользовательского теста.

NIST в руководстве по планированию непрерывности подчёркивает важность планов, процедур, восстановления и проверки готовности. Это методический источник, а не обязательная норма российского договора, но идея практична: документ, который никто не проигрывал, остаётся гипотезой.

FAQ

Обязательно ли включать штрафы в SLA?

Не универсально. Сначала опишите измеримые этапы, источники данных, исключения и критерии закрытия. Ответственность и санкции определяются сторонами с юристом применительно к договору.

Чем время реакции отличается от времени решения?

Реакция подтверждает, что обращение принято ответственным. Решение означает восстановление согласованного результата или полное устранение причины — в зависимости от определения. Между ними должны быть диагностика и регулярные статусы.

Как выбрать приоритет?

По влиянию на пациента и работу, масштабу, наличию обхода и срочности. Стоимость оборудования и должность заявителя сами по себе не определяют критичность.

Нужна ли поддержка 24/7?

Только если критичные процессы клиники действительно работают круглосуточно и риск оправдывает цену. Важно уточнить, какие специалисты доступны ночью, а не покупать красивую надпись.

Что делать, если подрядчик — один человек?

Зафиксировать резервный контакт, границы доступности, хранение документации и доступов у клиники, порядок передачи и сценарий длительной недоступности специалиста. Риск зависимости нельзя закрыть личным обещанием.

Как проверить, что SLA работает?

Провести настольные и безопасные синтетические сценарии, проверить тикеты, эскалацию, коммуникацию, резервный маршрут и закрытие по пользовательскому результату.

Источники и честные ограничения

NIST SP 800‑34 Rev. 1 использован как методическая основа для планирования непрерывности и восстановления. CISA #StopRansomware Guide поддерживает практику инвентаризации и контроля средств удалённого управления, журналирования и сегментации.

Эти документы не заменяют российские требования и договор клиники. Конкретные сроки, ответственность, обработка данных, допустимые резервные процедуры и стоимость определяются сторонами с профильными специалистами. Примеры матриц и сценарий в статье — редакционные модели, а не сведения о реальном заказчике.

Что сделать завтра

Возьмите последние десять обращений к IT и закройте названия систем. Оставьте только влияние: «пациент не получил звонок», «врач не открыл результат», «регистратура не оформила визит», «копия не прошла проверку».

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

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