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-плана: измеряется не в технических метриках, а в количестве бессонных ночей у владельца бизнеса.