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

Как-то к нам в офис заглянул главврач одной частной медклиники — «25 РМ». Знаете, он сразу, без всяких там прелюдий, выложил свою главную головную боль: "А что, если завтра зарубежный интернет просто отключится? Мой бизнес выживет?" Это, поверьте, не просто так было сказано. Реальное беспокойство! Ведь его клиника, представьте, работает с иностранными лабораториями, все анализы считает в облачном Excel, да и общение с пациентами у них через Telegram. Что делать? Мы, конечно, взялись за эту задачу. И всего за 14 рабочих дней не просто разработали, но и внедрили для него полноценный 12-шаговый план. Давайте-ка я вам теперь в деталях про это расскажу.

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

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

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

Мой первый ответ на эти опасения? Признаюсь, был довольно сдержанным. Я, честно говоря, сам не особо верю, что Рунет вот так возьмёт и полностью изолируется. Это же не только адски сложно технически, но и просто экономически самоубийственно для нашей страны. Но вот с чем я абсолютно согласен, так это с тем, что частичные блокировки — это уже наша реальность. Вспомните 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 прямо на офисном сервере.

Итак, давайте к делу. Что мы сделали на первом шаге? Мы взяли офисный сервер — это Dell PowerEdge T440 с Ubuntu 22.04, если вам интересны детали — и установили на него unbound. Что это такое? Проще говоря, это такой рекурсивный резолвер с собственным кэшем. Для большинства DNS-записей мы выставили TTL в 60 секунд, а для совсем редких — целых 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

Наша конфигурация unbound выполняет сразу три важные задачи. Во-первых, она резолвит запросы через DNS-over-TLS, а это, между прочим, надёжная защита от подмены DNS-записей на уровне провайдера. Во-вторых, ответы хранятся целые сутки в expired-кэше — то есть, даже если все форвардеры «умерли», unbound выдаст последний известный ответ. И в-третьих, мы специально приоритизировали Яндекс.DNS как российский. И самое главное: на всех 25 рабочих местах этот сервер был прописан как основной (primary) DNS через GPO. Ни один не забыли!

Теперь к Шагу 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 можно будет перекинуть на наш on-premise всего за 4 часа. Вот такая подстраховка!

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

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

Развертывали мы Битрикс через 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. Но что, если вдруг эта .ru-зона станет недоступна? Всякое бывает: внезапная блокировка регистратора или проблемы у DNS-провайдера. На такой случай мы купили адрес клиника.рф. Он ведёт на тот же самый сервер, контент полностью дублируется. Теперь, если что-то случится с основным, пациенты без проблем найдут клинику по альтернативному адресу. Удобно!

Шаги 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 для маленьких диагностических снимков пациентам. Все эти устройства мы подключили к серверу по USB или LPT. Доступ к ним простой — через SMB-шару \\printserver\zebra. А настройки принтеров для всех 25 рабочих мест раскатывает GPO. Главное, если вдруг весь интернет пропадёт, печать продолжит работать как ни в чём не бывало.

Ох, а история с LPT-переходником — это вообще отдельная песня! Да, у Zebra ZD420 есть и USB, и Ethernet, всё по-взрослому. Но вот в чём загвоздка: офисный Ethernet проложен через MikroTik. И если этот MikroTik вдруг перезагрузится, принтер, как назло, сбрасывается. После всех тестов мы поняли: самое надёжное решение — это USB-подключение напрямую к серверу. Один из админов, конечно, настаивал: «Давайте по-современному, через сеть!» Мы его, конечно, отговорили. В кризис, как показывает наша практика, старая добрая школа всегда надёжнее. Не так ли?

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

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

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

Что касается Notion, там расклад такой. Если что, его заменит Wiki.js, развёрнутый on-premise на офисном сервере. Время на переключение чуть дольше — целая неделя, ведь придётся мигрировать весь контент. Зато бюджет? Ноль рублей! Wiki.js абсолютно бесплатен. А ответственный за этот процесс — старший врач. Всё чётко.

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

Шаг 10: мы по-настоящему укрепили интернет-связь! Организовали резервный канал через LTE, да не просто так, а с тремя SIM-картами. До этого у клиники был всего один оптический канал от Ростелекома на 100/50 Мбит. Что мы сделали? Установили на MikroTik модем LTE18-mini, а в него — три симки: от МТС, МегаФона и Билайна, чтобы уж наверняка! Между ними, конечно, работает 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 тысяч рублей — это лицензии. Приятно, что часть ПО, как Bitrix24 self-hosted (годовая подписка), Nexus OSS и Mailcow, у нас бесплатные. А вот домен .рф обходится в 6 тысяч в год, плюс LTE-модем — 18 тысяч за само оборудование. Ещё 240 тысяч — это оплата нашей работы, наших инженеров ITfresh. И последние 60 тысяч мы потратили на обучение персонала клиники: главврача, администратора и бухгалтера. Ведь без них никуда!

Какие же дополнительные расходы ждут клинику после внедрения? Каждый месяц это 28 000 ₽ — за наше сопровождение. Сюда входят мониторинг состояния зеркал, обновление всех on-premise сервисов и, конечно, поддержка резервных каналов. Ещё 4 800 ₽ в месяц уходит на LTE — это за три SIM-пакета. Электричество? Место в серверной? Ну, это сущие копейки. Итого, общие операционные расходы, так называемый operational cost, составляют около 35 000 ₽ в месяц.

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

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

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

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

Давайте будем реалистами: полная изоляция Рунета, как сценарий, всё же довольно маловероятна. Большинство аналитиков дают ей лишь 5-10% шанса в ближайшие три года. А вот частичная изоляция — это уже совсем другая история. Отключение 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 ₽. Плюс к этому, ежемесячно клиника платит 28 000 ₽ за наше сопровождение — это и мониторинг зеркал, и обновление всех on-premise сервисов. Дороговато, скажете вы? Но давайте сравним: один день простоя такой клиники — это 180-220 тысяч рублей недополученной выручки. В этом контексте, согласитесь, наша 'страховка' выглядит очень разумной. Кстати, есть вариант идти поэтапно: например, распределить внедрение на полгода, укладываясь в комфортные 80 тысяч в месяц.

Итог

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