12-шаговый план подготовки медклиники к изоляции рунета: что мы внедрили заранее

Однажды к нам заглянул главврач частной медклиники «25 РМ». Сразу, без обиняков, он задал вопрос, который его очень волновал: «Что будет с моим бизнесом, если завтра вдруг отрубят зарубежный интернет?» Это был не какой-то подвох, а самое что ни на есть реальное беспокойство. Ведь его клиника работает с зарубежными лабораториями, все анализы считает в Excel-облаке, да и с пациентами общается через Telegram. Мы взялись за дело и всего за 14 рабочих дней смогли разработать и внедрить для него 12-шаговый план. Сейчас я вам пошагово всё расскажу.

Контекст: почему именно медклиника заволновалась

Наш главврач — это не только владелец клиники в Свиблово, но и практикующий гинеколог-эндокринолог. У него в штате 25 рабочих мест: 8 врачей, 4 администратора, 6 медсестёр, 3 сотрудника в бухгалтерии, 2 в маркетинге, плюс ещё директор и два администратора-кассира. Клиника работает по ДМС-полисам страховых компаний, принимает пациентов по добровольному обращению, а также активно сотрудничает с зарубежными лабораториями. Например, анализы на гормоны они отправляют в Германию через DHL.

Это беспокойство возникло у главврача после очередной порции новостей о «суверенном рунете» и грядущих блокировках. Он прочитал две статьи на Хабре, посвящённые сценарию полной изоляции, и, прикинув риски, насчитал целых 14 зависимостей клиники от зарубежных или централизованных сервисов. Поэтому он решил действовать заранее. Его аргумент был простым и понятным: «Если завтра у нас неделю не работает Telegram-бот регистрации, мы теряем 30% записей. Я хочу спать спокойно».

Мой первый ответ на его опасения был довольно сдержанным. Знаете, я сам не верю в полную изоляцию рунета — это было бы технически очень сложно, да и экономически разрушительно для нашего государства. Но я вполне согласен, что частичные блокировки могут стать нашей новой реальностью. Взять, к примеру, 2024 год: внезапно отрубили Discord и Notion у всех российских операторов. А в 2025 году то же самое случилось с частью CDN Cloudflare. Так что бизнесу важно быть готовым не к какому-то апокалипсису, а скорее к серии «средних» событий.

Аудит зависимостей: 14 критичных сервисов

Мы не стали терять время и за 2 дня прошлись по всем сервисам, которыми пользуется клиника. Каждый сотрудник мне написал список инструментов, без которых он не представляет свою работу. Я потом всё это соединил, отфильтровал и получил довольно ясную картину.

Вот что оказалось критичным и завязано на зарубежных серверах: Telegram (через бота идёт регистрация пациентов), WhatsApp (общение с пациентами), Gmail (для внешней переписки с DHL и лабораториями), Zoom (для телемедицины), Google Maps (там хранятся адреса лабораторий) и GitHub (туда мы заливаем код Telegram-бота).

А вот критичные сервисы, которые работают на крупных российских облаках: Яндекс360 (это внутренняя почта, диск, документы), 1С:Медицина (она на серверах 1С), Битрикс24 (наша CRM для пациентов), СБИС (для отчётности), Сбер-Бизнес (это наш банк-клиент) и РТЛабс (электронная отчётность).

Были и прочие сервисы: Notion (там хранится внутренняя база знаний для врачей) и DigitalOcean (это резервный сервер с регистрационным ботом). Они тоже зарубежные, но, честно говоря, менее критичные — клиника вполне может без них работать какое-то время.

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

Шаги 1-3: инфраструктура DNS и зеркала пакетов

Мы начали с самого главного — DNS. Если завтра Google DNS (тот самый 8.8.8.8) вдруг перестанет резолвить запросы из РФ или его заблокирует ТСПУ, то, считайте, 90% сервисов клиники просто перестанут работать. Именно поэтому наш первый шаг — запуск локального рекурсивного DNS на офисном сервере.

Итак, Шаг 1: мы установили unbound на офисный сервер, который представляет собой Dell PowerEdge T440 с Ubuntu 22.04. Его конфигурация — это рекурсивный резолвер с собственным кэшем. Для большинства записей мы поставили 60 секунд TTL, для редких — 24 часа. Если вдруг внешний DNS падает, unbound спокойно отдаёт данные из своего кэша, используя последние известные значения.

# /etc/unbound/unbound.conf.d/clinic.conf
server:
    interface: 0.0.0.0
    access-control: 192.168.10.0/24 allow
    cache-min-ttl: 60
    cache-max-ttl: 86400
    serve-expired: yes
    serve-expired-ttl: 86400
    serve-expired-reply-ttl: 30
    prefetch: yes
    do-ip6: no

    # форвардеры в порядке приоритета
    forward-zone:
        name: "."
        forward-tls-upstream: yes
        forward-addr: 77.88.8.8@853#dns.yandex.ru
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
        forward-addr: 8.8.8.8@853#dns.google

Конфигурация делает три вещи: резолвит через DNS-over-TLS (защита от подмены DNS на провайдере), хранит ответы 24 часа в expired-кэше (если форвардеры умерли, отдаёт последний известный ответ), приоритизирует Yandex DNS как российский. На всех 25 рабочих местах через GPO прописали этот сервер как primary DNS.

Шаг 2: мы настроили зеркало npm и PyPI прямо на офисном сервере. У клиники есть свой разработчик (это один человек, который поддерживает Telegram-бота на Python и веб-сайт на React). Если завтра npm.org или pypi.org окажутся недоступны, он просто не сможет деплоить обновления. Поэтому мы поставили Verdaccio для npm и devpi для PyPI — они оба зеркалируют все скачанные пакеты на диск.

# Verdaccio для npm
docker run -d --name verdaccio -p 4873:4873 \
    -v /srv/verdaccio/storage:/verdaccio/storage \
    -v /srv/verdaccio/conf:/verdaccio/conf \
    verdaccio/verdaccio:5

# в .npmrc клиента-разработчика:
registry=http://npm.clinic.local:4873/

# devpi для PyPI
pip install -U devpi-server devpi-web
devpi-init --serverdir /srv/devpi
devpi-server --host 0.0.0.0 --port 3141 --serverdir /srv/devpi &

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

Шаг 3: мы организовали зеркало для CRAN и Maven через Sonatype Nexus OSS. CRAN нужен для R, которым пользуется бухгалтер для статистики по пациентам. Maven пригодится, если кто-то в офисе вдруг начнёт работать с Java/Kotlin – пока таких нет, но это задел на будущее. Кстати, Nexus умеет проксировать оба этих репозитория, плюс Docker-репозиторий и Helm-чарты.

Контр-нарратив: «не парьтесь, всё ставите через VPN»

Я часто слышу от админов такое: «Зачем заморачиваться с зеркалами? Всё же можно качать через корпоративный VPN». И это правда, так можно. Но это не даёт стопроцентной страховки. VPN ведь ходит через интернет-канал клиники, который тоже может вырубиться в тот самый «час Х». А вот локальное зеркало будет работать даже тогда, когда вся внешняя связь мертва. Это значит, что разработчик сможет продолжать деплоить обновления, а инженер — обновлять локальный софт.

Шаги 4-6: почта, CRM, резервный домен

Шаг 4: мы внедрили Mailcow on-premise, который стал параллельным почтовым доменом. Основной домен клиники, @clinic.ru, сейчас работает на Яндекс360. Мы развернули Mailcow на офисном сервере под доменом @mc.clinic.ru, настроив для него собственные MX-записи. Внутренняя переписка между сотрудниками уже идёт через локальный сервер — так мы тестируем нагрузку в боевом режиме. Внешняя почта пока по-прежнему через Яндекс, но если что, MX-запись @clinic.ru можно будет за 4 часа переключить на наш on-premise.

Mailcow, к слову, занимает 6 ГБ RAM при 25 активных почтовых ящиках. Хранилище у него — 200 ГБ на NVMe, а бэкап делается на отдельный диск раз в сутки. Внутри используются Postfix, Dovecot, Rspamd, а для веб-клиента — SOGo. Внешний доступ организован через 443/TCP с сертификатом Let's Encrypt, выданным на домен mail.mc.clinic.ru.

Шаг 5: мы развернули on-premise Bitrix24 (self-hosted) для CRM пациентов. Облачный Битрикс24, который является РФ-разработкой с серверами в Москве, пока работает стабильно. Но клиент решил перестраховаться и поднять параллельный self-hosted вариант на офисном сервере. Он работает в полу-active режиме: каждую ночь данные из облака синхронизируются в self-hosted через API. Если облако вдруг «ляжет», наш self-hosted будет готов принять нагрузку всего за 30 минут.

Мы поднимали его через BitrixVM на CentOS Stream 9. Лицензию на self-hosted клиент приобрёл отдельно, это стоило порядка 110 тысяч в год. Синхронизацию данных выполняет наш Python-скрипт, запущенный по CRON каждый час. Он забирает CRM-сделки через REST API облачного Битрикса и записывает их в self-hosted через тот же API. Это, конечно, не полноценный кластер, но зато база пациентов всегда остаётся в актуальном состоянии.

# /opt/bitrix-sync/sync.py
import requests, json, datetime

CLOUD = "https://clinic.bitrix24.ru/rest/1/{webhook}"
ONPREM = "http://b24.clinic.local/rest/1/{webhook}"

# забираем сделки за последние 25 часов (overlap)
since = (datetime.datetime.now() - datetime.timedelta(hours=25)).isoformat()
r = requests.get(f"{CLOUD}/crm.deal.list.json",
                 params={"filter[>DATE_MODIFY]": since, "select[]": "*"})
deals = r.json()["result"]

# пишем в on-premise
for d in deals:
    r2 = requests.post(f"{ONPREM}/crm.deal.add.json", json={"fields": d})
print(f"synced {len(deals)} deals at {datetime.datetime.now().isoformat()}")

Шаг 6: резервный домен в зоне .рф. Основной сайт клиники — clinic.ru. Купили клиника.рф как резерв на случай, если основная зона по каким-то причинам станет недоступна (внезапная блокировка регистратора, проблемы с DNS-провайдером в .ru-зоне). Резервный домен ведёт на тот же сервер, контент дублируется. Пациенты в случае проблем смогут найти клинику по альтернативному адресу.

Шаги 7-9: карты, печать, риск-карта

Шаг 7: мы внедрили офлайн-карты Yandex с полноценной поддержкой адресов. Регистраторы клиники ведь постоянно помогают пациентам найти филиалы лабораторий, выписывают адреса для DHL при отправке анализов. Если Google Maps и Yandex Maps API в браузере вдруг откажут, эта функция просто перестанет работать. Мы скачали через Yandex Maps API набор тайлов Москвы и МО, это заняло 15 ГБ, и поставили их в локальный nginx для офлайн-просмотра. А для регистраторов сделали самописное веб-приложение: там можно искать по адресу с автодополнением из локальной базы 4ГИС.

Шаг 8: мы настроили print-сервер на Windows Server 2022 с резервом через LPT. В клинике есть принтер-этикетировщик Zebra ZD420 (для этикеток на пробирки с биоматериалом), три Kyocera M2540dn (для общих документов) и фотопринтер Canon Selphy (для мелких диагностических снимков пациентам). Все принтеры подключены к Windows-серверу через USB или LPT, доступ к ним идёт через SMB-шару \\printserver\zebra. GPO раскатывает настройки принтеров на все 25 рабочих мест. Так что, если интернет полностью исчезнет, печать продолжит работать без проблем.

Кстати, история с LPT-переходником — это отдельная тема. У Zebra ZD420 есть и USB, и Ethernet. Но вот Ethernet в офисе идёт через MikroTik, и если MikroTik вдруг перезагрузится, принтер сбрасывается. USB-подключение напрямую к серверу оказалось самым надёжным вариантом. Один из админов клиники, конечно, просил сделать «современно, через сеть». Но я его отговорил — старая школа в кризис всегда надёжнее.

Шаг 9: мы разработали документ — риск-карту для всех 14 зависимостей. По каждому сервису мы подробно прописали: что его заменяет, сколько времени потребуется на переключение, какой бюджет нужен и кто за это отвечает. Это был один из самых полезных шагов! Теперь у руководства клиники есть чёткий документ, где они видят «что у нас по интернету, что нет», без необходимости глубоко вникать в технические детали.

Что вошло в риск-карту по каждому сервису

Вот, например, что мы прописали по Telegram-боту регистрации: альтернатива — обычный телефонный обзвон администраторов плюс СМС-рассылка через российский шлюз СМС-Аэро. Время переключения — 2 часа (нужно будет перенастроить call-центр). Бюджет переходного периода — 18 000 ₽/мес за СМС-Аэро. Ответственный — главврач (он же, кстати, владеет администрированием СМС-Аэро).

А по Notion ситуация такая: альтернатива — Wiki.js on-premise на офисном сервере. Время на переключение — 1 неделя (потребуется миграция всего контента). Бюджет — 0 ₽, потому что Wiki.js бесплатен. Ответственный — старший врач.

Шаги 10-12: резервные каналы и регламенты

Шаг 10: мы организовали резервный канал интернета через LTE с тремя SIM-картами. Изначально у клиники был один оптический канал от Ростелекома на 100/50 Мбит. Мы установили на MikroTik модем LTE18-mini с тремя SIM-картами от разных операторов — МТС, МегаФон и Билайн. В случае необходимости между ними работает mwan3 balanc. Если основной канал падает, LTE подхватывает связь всего за 15 секунд. Если же падает один из операторов LTE, система автоматически переключается на следующий. Это даёт целых 4 уровня резервирования внешней связи, что очень надёжно.

Шаг 11: мы позаботились о «облачных» деньгах, распределив их по двум банкам. У клиники был счёт в Сбер-Бизнесе. Мы открыли резервный счёт в ВТБ-Бизнес как своего рода страховку от возможных проблем с одним банком. Сейчас около 10% оборотных средств хранится в ВТБ, а отчётность синхронизирована. Это, конечно, не совсем технический шаг, скорее финансовый, но мы как IT-аутсорс инициировали этот разговор. Главврач, кстати, был очень благодарен.

Шаг 12: мы разработали регламент DR-тестирования, которое проводится раз в полгода. Каждые 6 месяцев мы устраиваем у клиента 36-часовое учение под названием «отключился внешний интернет». На сутки мы физически отрубаем оптику Ростелекома и остаёмся работать только на LTE-резерве. Мы тщательно проверяем, что почта работает, CRM функционирует, регистрация идёт, печать работает. Первый такой тест прошёл в апреле, и мы выявили 3 мелких косяка, которые тут же починили.

Что нашли при первом DR-тестировании

На 4-м часу теста, например, выяснилось, что СБИС-Сдача отчётности никак не работает через LTE МТС. Оказалось, оператор режет SBIS-трафик, считая его «P2P». Решение нашлось: мы прописали СБИС в исключения mangle на MikroTik, чтобы он шёл по специальному маршруту через VPN. К 8-му часу мы обнаружили, что веб-почта Yandex360 заметно тормозит — латентность LTE оказалась слишком чувствительной для веб-приложения с авторизацией. Для критичных пользователей мы решили эту проблему, переключив их на десктопный почтовый клиент Mozilla Thunderbird с IMAP. А на 24-м часу выяснилось, что один из принтеров Kyocera потерял настройки SNMP-мониторинга. Оказалось, что Windows-сервер при перезагрузке подцепил его как новое устройство. Всё исправили простым рестартом службы.

Экономика проекта и итоги после 3 месяцев

Полное внедрение нашего 12-шагового плана заняло у инженера 14 рабочих дней, что распределилось на 4 недели. Общая стоимость составила 480 000 ₽. Из этой суммы: 180 тысяч ушло на лицензии (годовая self-hosted Bitrix24, Nexus OSS и Mailcow бесплатные, домен .рф — 6 тысяч в год, LTE-модем — 18 тысяч за железо). Ещё 240 тысяч — это наша работа, работа инженеров ITfresh. И 60 тысяч — это обучение персонала клиники: главврача, администратора и бухгалтера.

Дополнительные расходы клиники после внедрения: 28 000 ₽/мес — наше сопровождение (мониторинг состояния зеркал, обновление on-premise сервисов, поддержка резервных каналов). LTE — 4 800 ₽/мес за три SIM-пакета. Электричество и место в серверной — копейки. Итого operational cost около 35 000 ₽/мес.

Что же главврач сказал нам через 3 месяца? Его слова дорогого стоят: «Я перестал нервничать. Если завтра отрубят Telegram — у меня есть чёткий план на 2 часа. Если отрубят Яндекс — у меня есть Mailcow. Это как ОСАГО — надеешься, что не пригодится, но платишь и спишь спокойно».

По моему личному мнению, 12-шаговый план — это, возможно, перебор для большинства наших клиентов. Но для такой медклиники, где простой стоит 200 тысяч в день и напрямую связан со здоровьем пациентов, это абсолютно разумная инвестиция. Если у вас тоже есть критичные для бизнеса облачные зависимости, я бы посоветовал начать хотя бы с шагов 1-4. Это локальный DNS, зеркала пакетов, on-premise почта и резервный домен. Это займёт 30% от общего бюджета, но при этом обеспечит 60% страховки.

FAQ: что чаще всего спрашивают клиенты

Изоляция рунета — это реально или просто страх?

Полная изоляция, как сценарий, всё же маловероятна. Большинство аналитиков оценивают её шанс в 5-10% в горизонте 3 лет. Но вот частичная изоляция — отключение DNS Google, блокировка крупных CDN (CloudFlare, Amazon CloudFront), запрет иностранных SaaS — это уже происходит выборочно и вполне реально. Бизнесу важно быть готовым не к самому страшному сценарию, а к серии «средних» событий. К тому, что внезапно окажутся недоступны Slack, Discord, GitHub, Notion. Такое уже случается у отдельных операторов и в разное время.

С чего начать подготовку бизнесу до 50 РМ?

Начинать нужно, кстати, не с технических решений, а с тщательного аудита зависимостей. Просто выпишите все облачные сервисы, которыми пользуется ваша компания: почта, мессенджер, CRM, бухгалтерия, склад, ВКС, СБИС, банк-клиент. Рядом с каждым укажите, где находятся серверы (РФ, Европа, США), есть ли on-premise аналог и что будет, если сервис завтра окажется недоступен. Это упражнение займёт всего 2-3 часа, но зато даст вам очень ясную картину рисков. У клиента-медклиники мы, например, обнаружили 14 критичных зависимостей.

Зачем медклинике печать через LPT — это же 90-е?

В медклинике есть принтеры-этикетировщики Zebra и старые лазерники Kyocera, которые работают исключительно через драйверы Windows + USB или LPT. Современные интернет-сервисы печати (Google Cloud Print, любые SaaS-печатные шлюзы) — лишние посредники, которые упадут первыми. Print-сервер на Windows Server 2022 + DFS-репликация настроек — самодостаточный сетап, который работает без внешнего интернета. Часть оборудования клиники подключена через LPT->USB переходник, и это норма.

Что делать с почтой — Gmail/Яндекс или свой сервер?

Мы, кстати, развернули для клиента-медклиники Mailcow on-premise прямо на их офисном сервере. Он работает как параллельный почтовый домен @mc.clinic.ru. Внешняя почта пока что остаётся на Яндекс360 (у них бизнес-тариф). Но в случае любых проблем с Яндексом можно будет всего за 4 часа переключить MX-записи у регистратора на наш on-premise Mailcow. А внутренняя переписка между сотрудниками клиники уже сейчас идёт через локальный сервер — так что практический бэкап работает каждый день.

Сколько стоит план подготовки для клиники до 30 РМ?

Полная реализация 12-шагового плана для медклиники «25 РМ» обошлась в 14 рабочих дней инженера и 480 000 ₽ единовременно. Плюс к этому, ежемесячная подписка на сопровождение (куда входит мониторинг зеркал, обновление on-premise сервисов) — 28 000 ₽/мес. Дороговато, скажете вы? Но если сравнить это со стоимостью простоя клиники в день (а это 180-220 тысяч недополученной выручки), то это очень разумная страховка. Кстати, можно делать это и поэтапно — например, за полгода, укладываясь в бюджет 80 тысяч в месяц.

Итог

Подготовка бизнеса к изоляции рунета — это совсем не про панику и не про то, чтобы срочно переезжать в подвал. Это, скорее, про то, чтобы снизить зависимость от единых точек отказа. Для медклиники «25 РМ» из Свиблово мы развернули 12 параллельных слоёв страховки за 480 тысяч единовременно и 35 тысяч ежемесячно. Теперь главврач спит спокойнее, и я, честно говоря, тоже. И это, наверное, единственный по-настоящему честный итог любого DR-плана: он измеряется не в каких-то там технических метриках, а в количестве бессонных ночей у владельца бизнеса.