Мультиоблако для малого бизнеса: Timeweb + Hetzner + выделенный сервер

Года три назад мне позвонил один знакомый предприниматель — небольшая производственная компания, штук двадцать в штате, оборот приличный, но IT-инфраструктура в состоянии "как получилось". Он рассказал, что у них одновременно открыто три вкладки в браузере: панель управления Timeweb, панель Hetzner и какой-то самописный скрипт на скриншотах в Telegram, который присылает состояние выделенного сервера с 1С. Когда падает что-нибудь важное, его системный администратор (совмещающий эту роль с должностью "просто умный парень в компании") начинает судорожно переключаться между тремя этими вкладками, пытаясь понять, где именно горит и насколько сильно. Я тогда спросил: "А зачем вам вообще три разных провайдера?" И вот его ответ меня зацепил настолько, что я до сих пор его помню: "Потому что каждый из них делает что-то одно хорошо, и ни один не делает всё хорошо сразу."

Это, честно говоря, исчерпывающая характеристика современного рынка облачных услуг для малого и среднего бизнеса. Особенно в России, где ситуация дополнительно осложнена регуляторикой, курсом доллара и периодической нервозностью вокруг иностранных сервисов. В итоге большинство компаний приходят к одной и той же схеме не потому, что её кто-то спроектировал, а просто потому, что жизнь так сложилась: российский VPS для всего, что касается персональных данных и работы с клиентами, европейский сервер для тех сервисов, которым нужна скорость доступа из Европы или которые принципиально лучше работают там, и какой-нибудь физический или арендованный выделенный сервер для тяжёлых корпоративных систем — 1С, базы данных, архивы. Три мира. Три набора инструментов. Три точки отказа.

Я сам через это прошёл. И именно этот опыт в итоге привёл меня к тому, что я начал разрабатывать CosDevDirector — персональный дашборд для управления всем этим зоопарком через один интерфейс. Но прежде чем говорить про инструменты — давайте разберёмся, почему мультиоблачная схема для малого бизнеса это не баловство и не перегибание палки, а вполне рациональное решение. Просто обычно оно принимается хаотично, без архитектуры, и поэтому порождает столько боли.

Это не сразу происходит. Обычно всё начинается с одного VPS у одного провайдера — как правило, российского, потому что понятно, карты принимают, поддержка на русском, серверы в Москве, и вообще первый результат в Яндексе. Потом компания начинает расти, появляются задачи, которые плохо вписываются в исходную схему, и начинается дрейф.

Первый типичный сдвиг — это появление клиентов или партнёров за рубежом, либо просто понимание того, что какой-нибудь сервис (скажем, сервис рассылок, или аналитическая платформа, или корпоративный мессенджер) работает заметно быстрее, если хостится в Европе. Hetzner тут возникает почти неизбежно: немецкое качество, европейские датацентры, ценник при этом — один из самых низких на рынке. Dedicated-серверы от Hetzner при соотношении цена/мощность вообще практически вне конкуренции. И вот уже у тебя два провайдера.

Второй сдвиг — это 1С или любая другая тяжёлая ERP-система, которая в малом и среднем бизнесе почти всегда в какой-то момент появляется. 1С в облаке — это отдельная история, полная нюансов: лицензирование, производительность, особенности работы файловой базы в сети, требования к дискам. Многие компании в итоге приходят к тому, что держат 1С на физическом или виртуальном выделенном сервере у специализированного хостера, либо вообще на железе в офисе с удалённым доступом. И вот у тебя уже три точки.

Добавь сюда объект персональных данных — по российскому законодательству (152-ФЗ) персональные данные граждан РФ должны обрабатываться и храниться на серверах в России. Это значит, что CRM, база клиентов, любые формы с персоналкой — это Timeweb или другой российский провайдер, без вариантов. Европейский Hetzner для этого не подходит юридически, даже если технически всё работает. И вот архитектура окончательно оформляется: российский провайдер для compliance, европейский для скорости и технических сервисов, выделенный сервер для тяжёлых систем.

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

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

У него открыты три браузерные вкладки с панелями управления. Timeweb Cloud — там можно посмотреть метрики серверов, настроить бэкапы, зайти в Firewall. Hetzner Cloud Console — там свои сервера, свои IP-адреса, свой мониторинг. И SSH-клиент (PuTTY, iTerm, что угодно) открытый к выделенному серверу, потому что у него нет никакого API, только прямое подключение. Три разных набора учётных данных. Три разных интерфейса. Три разных способа получить информацию о том, что происходит.

Когда всё работает — это терпимо. Когда что-то падает — это кошмар. Потому что в момент инцидента ты должен одновременно проверять три источника информации, пытаясь понять, где именно проблема. Упал сайт? Это может быть сервер в Timeweb, может быть сервер в Hetzner, а может быть 1С на выделенном не отвечает и вся цепочка встала. И ты начинаешь методично переключаться между вкладками, при этом теряя время, которое в инциденте на вес золота.

Мне самому приходилось работать в такой конфигурации, и я отлично помню этот момент, когда ты уже понял, что что-то не так, но ещё не понял, что именно. Первые 3-5 минут инцидента — ты просто ориентируешься. Смотришь метрики CPU на одном сервере, переключаешься на другой, проверяешь логи, открываешь третье SSH-соединение. Это время потеряно не на решение проблемы, а на поиск проблемы. А ведь именно в этот момент клиенты не могут зайти на сайт, продавцы не могут открыть CRM, бухгалтерия не может выставить счёт.

Ещё один аспект, про который обычно не говорят, но который реально раздражает — это SSH-ключи. У каждого провайдера свои правила работы с ключами. В Timeweb один интерфейс для загрузки публичного ключа. В Hetzner другой. На выделенном сервере ты просто вручную правишь `authorized_keys`. И если у тебя несколько человек в команде (или ты сам работаешь с нескольких машин), контроль за тем, у кого какой доступ — это постоянная головная боль. Сколько раз я видел ситуацию, когда уволился человек, а его ключи ещё полгода висят на серверах — никто просто не помнит, где именно их убирать.

А теперь добавь к этому мониторинг. У Timeweb есть встроенные метрики — CPU, RAM, диск, сеть. Hetzner тоже показывает свои метрики. На выделенном сервере — Zabbix, Prometheus, Grafana, или просто регулярный `htop` по SSH. И где единый дашборд, где я вижу состояние всей инфраструктуры одним взглядом? Его нет. Нужно либо настраивать Grafana и тащить метрики из всех источников (а это отдельный проект на несколько недель), либо жить с разрозненными данными и надеяться, что всё будет хорошо.

Точка перелома у меня была конкретная. Мы запускали новый проект — и-нет смысла вдаваться в детали, важно то, что у нас была инфраструктура ровно такой конфигурации: Timeweb для production-окружения с персональными данными, Hetzner для CI/CD и staging-среды, выделенный сервер для базы данных и 1С. Стандартная схема.

В один прекрасный вечер у клиента перестала работать интеграция с CRM. Звонит менеджер, говорит — не синхронизируется. Я начинаю разбираться. Сначала проверяю Timeweb — серверы живые, приложение запущено, с виду всё нормально. Перехожу в Hetzner — там тоже всё зелёное. SSH на выделенный — 1С работает, базы доступны. Я трачу двадцать минут на то, чтобы методично проверить всё по кругу. И только через двадцать минут выясняю, что проблема была в Docker-контейнере на Hetzner — один из сервисов молча умер, логи в стандартном месте не были, healthcheck не был настроен. Всё выглядело зелёным, но работало неправильно.

Двадцать минут — это немного в абсолютных цифрах. Но в этот момент менеджер не мог работать. Клиент не получал данные. И всё это время я тыкал в три разных интерфейса, вместо того чтобы сразу увидеть: "Вот этот контейнер умер, вот его последние логи, вот когда это произошло."

Именно после этого случая я начал серьёзно думать про единый дашборд. Не "собрать Grafana", не "настроить Prometheus exporters на всех серверах" — это долго, сложно, и поддерживать это тоже нужно. Мне нужен был инструмент, который подключается к API Timeweb, к API Hetzner, к SSH на выделенный сервер — и показывает всё в одном месте. Метрики, Docker-контейнеры, логи, алерты. Единый интерфейс поверх разнородной инфраструктуры.

Вот в чём суть подхода CloudProvider абстракции, который я в итоге реализовал в CosDevDirector. Идея не новая, крупные компании используют её давно — но для малого бизнеса готовых инструментов такого уровня практически нет. Либо слишком просто (только мониторинг), либо слишком сложно (enterprise-решения с ценником в десятки тысяч долларов в год).

Смысл абстракции в следующем. Для системы управления инфраструктурой неважно, у какого провайдера находится сервер. Важны унифицированные операции: получить список серверов, получить метрики, получить список Docker-контейнеров, получить логи, выполнить команду. Если каждый провайдер реализует этот интерфейс по-своему — это проблема провайдера, не моя. Моя задача — написать адаптер для каждого провайдера, который переводит их API в единый язык.

Timeweb имеет REST API — там можно получить список серверов, метрики CPU/RAM/диска, управлять бэкапами, настраивать firewall. Hetzner Cloud тоже имеет хорошо задокументированный API — серверы, снимки, сети, плавающие IP. Выделенный сервер API не имеет по определению — там только SSH. Но SSH тоже можно унифицировать: подключился, выполнил команду, получил результат, закрыл соединение. Метрики с Linux-сервера — это `cat /proc/stat`, `free -m`, `df -h`. Docker-контейнеры — `docker ps --format json`. Логи — `journalctl` или `docker logs`. Всё это доступно через SSH.

В результате в дашборде ты видишь единый список серверов. Не "серверы Timeweb" отдельно и "серверы Hetzner" отдельно, а просто серверы — с иконкой провайдера, но в единой таблице. Кликаешь на любой — видишь одинаковый интерфейс: CPU-график, RAM-график, диски, сетевой трафик. Для Docker-серверов — список контейнеров с состоянием, метрики каждого, кнопка "посмотреть логи". Всё это работает одинаково независимо от того, Timeweb это, Hetzner или выделенный сервер, доступный только по SSH.

Алерты — тоже унифицированы. Ты настраиваешь правило один раз: "Если CPU любого сервера больше 80% — уведомить в Telegram". Не три отдельных правила для трёх провайдеров, а одно правило для всей инфраструктуры. Система сама опрашивает все источники через свои адаптеры и применяет общую логику алертинга.

Важный момент про выделенный сервер с 1С. Там есть специфика, которую нельзя игнорировать: Windows Server + 1С — это SSH-доступ через специальные инструменты, плюс 1С имеет OData API для получения данных (документы, заказы, выручка). В моей реализации это отдельный адаптер, который работает через SSH-очередь — потому что параллельные SSH-соединения к Windows-серверу могут заблокировать учётную запись. Каждый провайдер имеет свои особенности, и абстракция должна их учитывать, а не скрывать до момента, когда они проявятся в виде инцидента.

Про бэкапы тоже стоит сказать отдельно. В мультиоблачной схеме бэкапы — это отдельная головная боль. У Timeweb есть автоматические бэкапы серверов. У Hetzner тоже есть свои snapshots. На выделенном сервере — своя система, чаще всего самописная. И хранятся они в разных местах. Унифицированное управление бэкапами — это когда ты видишь в одном месте: все сервера, у каждого последний бэкап, когда он был, насколько свежий, и куда он сохранился. Если бэкап старше 48 часов — сразу алерт, без того, чтобы я вручную заходил и проверял.

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

Когда твои серверы у одного провайдера — трафик между ними идёт по внутренней сети. Timeweb внутренняя сеть, Hetzner внутренняя сеть — это быстро, дёшево (часто вообще бесплатно), задержки минимальные. Но когда сервер в Timeweb должен обращаться к сервису на Hetzner — трафик идёт через интернет. И это меняет всю картину.

Задержка между датацентрами Timeweb в Москве и Hetzner в Амстердаме — примерно 40-60 миллисекунд в одну сторону. Для HTTP-запроса, который и так занимает 200-300 мс — это заметно, но терпимо. Но если у тебя есть цепочка микросервисов, которые синхронно вызывают друг друга, и часть из них в Москве, а часть в Амстердаме — вот тут начинаются проблемы. Каждый cross-datacenter вызов добавляет 80-120 мс к общему времени ответа. Десять таких вызовов в цепочке — и запрос занимает лишнюю секунду только на сетевые задержки.

Я наблюдал именно такую ситуацию. Компания разнесла разные части своей системы по провайдерам не по логике, а по принципу "этот сервис настраивал Вася и он привык к Hetzner, а тот настраивал Коля и он зарегистрировался в Timeweb". В результате получилась архитектура, где каждый пользовательский запрос тащил за собой несколько межпровайдерных вызовов, и приложение работало субъективно медленно. Не критично медленно, но ощутимо. И никто долго не понимал почему — все серверы по отдельности были быстрые, нагрузка низкая, а пользователи жаловались.

Правило, которое я для себя выработал: сервисы, которые синхронно и часто общаются между собой — должны жить у одного провайдера. Разные провайдеры — это про логическое разделение по назначению, а не про случайное распределение. CRM, которая в каждом запросе дёргает бэкенд-сервис — они должны быть рядом. Аналитика, которая раз в час выгружает данные из CRM для построения отчётов — это уже асинхронная связь, и она может жить где угодно.

Есть ещё вопрос безопасности межпровайдерного трафика. Когда данные идут по публичному интернету — это другой уровень риска, чем данные по внутренней сети провайдера. Минимум — HTTPS везде, без исключений. Желательно — VPN-туннель между сегментами инфраструктуры. У меня в рабочей конфигурации WireGuard поднят на всех серверах всех провайдеров, и межпровайдерный трафик ходит через него — это и шифрование, и фиксированные IP для firewall-правил, и удобная инфраструктурная сеть поверх интернета. Настраивается один раз, работает прозрачно.

Отдельная история — исходящий трафик. У Timeweb и Hetzner разные условия по трафику: у одних он включён в тариф, у других считается сверх. Когда твои серверы в разных провайдерах активно гоняют данные между собой, это может неожиданно вылезти в счёт. Я видел ситуацию, когда компания ежемесячно платила несколько тысяч рублей за трафик, который мог бы быть бесплатным, если бы сервисы жили у одного провайдера или если бы данные между провайдерами передавались батчами раз в час, а не в реальном времени.

Вот тут я хочу сказать кое-что, с чем часто не соглашаются, но я убеждён, что это так. Мультиоблачная стратегия — это не просто про удобство управления. Это про стратегическую свободу.

Когда ты завязан на одного провайдера, ты заложник его ценовой политики, его availability, его технических ограничений. Timeweb поднял цены? Ты злишься, но никуда не денешься — мигрировать больно и дорого. Hetzner ввёл новые ограничения для российских пользователей? Технически можешь переехать, но куда — непонятно, потому что вся инфраструктура заточена под их конкретный API. Выделенный провайдер закрылся? Это вообще катастрофа.

Когда у тебя есть нормальная абстракция поверх провайдеров, ситуация меняется. Ты переезжаешь с Timeweb на Selectel — в системе управления добавляешь нового провайдера, переносишь серверы, убираешь старого. Дашборд продолжает работать. Мониторинг продолжает работать. Алерты продолжают работать. Никакой переконфигурации логики, только смена источника данных.

Это звучит как теория, но на практике я видел несколько ситуаций, где именно эта гибкость спасла. Один знакомый в 2022 году довольно быстро переехал часть инфраструктуры с зарубежных провайдеров на российские — именно потому, что у него была гибкая архитектура, которая не зависела от конкретного провайдера. Те, у кого всё было намертво заточено под AWS или DigitalOcean, потратили на переезд в несколько раз больше времени и нервов.

Ещё один аспект vendor lock-in, про который редко говорят — это данные. Если ты используешь специфические managed-сервисы провайдера (например, Timeweb Cloud Databases или Hetzner Managed Kubernetes), ты дополнительно зависишь от их конкретной реализации. Это не всегда плохо — managed-сервисы экономят время. Но нужно понимать, что за удобство платишь зависимостью. Я для себя выработал правило: core infrastructure (серверы, сети) — провайдеронезависимо, managed-сервисы — только там, где это даёт реальную экономию времени и данные некритичны для переезда.

Юрисдикционный вопрос тоже работает в обе стороны. Да, данные российских клиентов должны храниться в России — это закон, и это нужно соблюдать. Но некоторые данные, наоборот, по бизнес-логике лучше хранить вне России. Например, если ты работаешь с европейскими партнёрами и им нужен быстрый доступ к каким-то данным. Или если ты хочешь иметь бэкап важных данных в другой юрисдикции — не потому что нарушаешь закон, а потому что это дополнительная страховка от катастрофических сценариев. Мультиоблачная схема позволяет это разграничить архитектурно, без костылей.

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

Для компании из 30 человек с нормальной IT-инфраструктурой типичная конфигурация выглядит так. Timeweb: три VPS — для CRM, для сайта, для почты. Скажем, конфигурации medium: 4 vCPU, 8GB RAM, 80GB SSD каждый. По текущим ценам Timeweb — это примерно 2500-3500 рублей за сервер в месяц, итого 7500-10500 рублей на российской стороне. Hetzner: один-два сервера, CX31 или CX41 — 2-4 vCPU, 8-16GB RAM. Hetzner в евро, по текущему курсу CPX31 (4 ядра, 8GB) обходится примерно в 1200-1500 рублей. Выделенный сервер — от 5000 до 15000 рублей в зависимости от конфигурации и провайдера (aruba, selectel, ihor или любой другой). Итого всё вместе — 15000-25000 рублей в месяц.

Альтернатива — всё у одного российского провайдера, скажем, Timeweb или Selectel. Чтобы получить аналогичную совокупную мощность — понадобится больше серверов или серверы более мощные конфигурации. При этом выделенный сервер для 1С у российских провайдеров стоит сопоставимо или дороже, чем у специализированных. И производительности Hetzner за те деньги на российском рынке просто нет. В итоге чисто по железу мультиоблако часто дешевле или сопоставимо с "всё у одного".

Но это только прямые расходы. Есть ещё TCO — совокупная стоимость владения. Я однажды попытался честно посчитать, сколько времени в месяц уходило на обслуживание разрозненной инфраструктуры без единого дашборда — мониторинг вручную, ответы на инциденты с ориентацией по нескольким интерфейсам, периодические аудиты SSH-ключей, проверка бэкапов на каждой платформе отдельно. Вышло около 10-12 часов в месяц на одного человека. При стоимости часа хорошего системного администратора в 2000-3000 рублей — это 20000-36000 рублей в месяц скрытых затрат. Которые никто не считает, потому что это "просто работа".

После внедрения единого дашборда это время сократилось примерно втрое — до 3-4 часов. Большую часть рутинных проверок делает система автоматически: метрики собираются, алерты срабатывают, инциденты логируются. Человек включается только когда что-то реально требует внимания. Экономия — 15000-20000 рублей в месяц только на административном времени. Которое, замечу, высвобождается не в вакуум, а на продуктивные задачи.

Ещё один скрытый стоимостной фактор — стоимость инцидентов. Каждый инцидент, когда что-то лежит и бизнес не работает, стоит денег. Потери зависят от того, что именно не работает: если CRM недоступна час и несколько менеджеров не могут работать — это прямые потери. Если 1С не работает и бухгалтерия не может выставить счета — это тоже деньги. Сократить среднее время устранения инцидента с 20-30 минут до 5-10 минут — это реальная финансовая экономия, которая при нескольких инцидентах в месяц легко перекрывает любые затраты на инструменты управления.

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

Чтобы не быть голословным — давайте конкретно. Типичная конфигурация для компании из 20-50 человек, которая занимается оптовой торговлей или производством и имеет более-менее нормальную IT-инфраструктуру.

На Timeweb — три-четыре сервера. Один для CRM (Bitrix24 коробочная или AmoCRM self-hosted, если такие используют), один для корпоративного сайта и лендингов, один для почты или внутренних сервисов. Всё это в российском дата-центре, compliance соблюдён, данные клиентов не покидают РФ. Цены у Timeweb в рублях, понятные, карточка российская — никаких проблем с оплатой.

На Hetzner — один-два сервера. Там живёт CI/CD (Drone CI или GitLab Runner), staging-окружение, возможно, VPN для доступа к внутренним ресурсам, аналитические сервисы, которые не работают с персональными данными. Hetzner даёт очень хорошее соотношение цена/мощность, особенно для серверов с большим объёмом RAM или дисков. У меня был сервер — 64GB RAM, 2TB NVMe, 8 ядер — за сумму, за которую Timeweb предложил бы что-то несравнимо скромнее.

Выделенный сервер — там 1С, база данных PostgreSQL с исторической аналитикой (которую не хочется тащить в облако из-за объёмов), и возможно файловый сервер для обмена документами с партнёрами. Физический сервер имеет смысл, когда у тебя постоянно высокая нагрузка — аренда VPS с аналогичными характеристиками обходится дороже, чем аренда или покупка железа.

Теперь посмотрим, что происходит с мониторингом в CosDevDirector для такой конфигурации. В дашборде — семь серверов в едином списке. Рядом с каждым — иконка провайдера (Timeweb, Hetzner, или custom для выделенного), цветовой индикатор состояния, ключевые метрики (CPU, RAM, uptime). Страница каждого сервера — одинакова для всех: графики метрик, список Docker-контейнеров (если есть), последние записи из логов, SSH-консоль прямо в браузере.

Алерты настроены один раз — и работают для всей инфраструктуры. CPU больше 85% — уведомление. Диск больше 90% — уведомление. Сайт не отвечает больше 2 минут — инцидент. 1С база недоступна — инцидент с высоким приоритетом. Бэкап 1С не создавался больше 24 часов — предупреждение. Всё это настраивается один раз, видится в одном месте, уведомления приходят в Telegram.

Когда что-то падает, сценарий выглядит иначе, чем тот кошмар с тремя вкладками, который я описывал. Приходит уведомление: "Контейнер bitrix-app на сервере timeweb-crm перезапустился 3 раза за последние 10 минут". Открываю дашборд, нахожу сервер, нахожу контейнер, смотрю логи прямо здесь же. Всё в одном месте, никаких переключений контекста. Время от уведомления до понимания проблемы — минуты, а не двадцать минут, как у меня было раньше.

Отдельно стоит сказать про интеграцию с бизнес-системами — 1С и Bitrix24. Это не просто мониторинг серверов. Это интеграция с данными, которые на этих серверах работают. Дашборд показывает не только "1С-сервер жив", но и "в 1С сейчас 5 активных сессий, 2 заблокированных объекта, последняя плановая задача выполнена успешно". Bitrix24 — "API отвечает за 230мс, SIP-телефония активна, баланс на телефонии 4200 рублей". Это инфраструктурный мониторинг, встроенный в бизнес-контекст. Когда я вижу, что 1С работает медленно и одновременно вижу, что на сервере выполняется тяжёлый отчёт — я сразу понимаю связь.

Был бы нечестным, если бы не сказал про ошибки и вещи, которые я понял с опозданием.

Первая ошибка — я слишком долго терпел разрозненную инфраструктуру, потому что казалось, что "настроить всё нормально" — это большой проект на несколько недель. На самом деле минимально работающий единый дашборд — это несколько дней, если правильно расставить приоритеты. Перфекционизм здесь враг: лучше иметь что-то, что показывает 70% нужной информации, но сразу — чем ждать идеального решения и жить с тремя вкладками. Я застрял в этой ловушке примерно на год — постоянно откладывал, потому что "сейчас срочные задачи", "потом разберёмся", "когда будет время". Времени не появилось само по себе. Я просто в какой-то момент сел и сделал.

Вторая ошибка — недооценка стоимости разрозненности. Я считал, что проблема терпима. Не считал время, которое тратится на переключение между интерфейсами, на ориентацию во время инцидентов, на объяснение нескольким людям, где что находится. Это не разовые потери — это постоянный drain, который суммируется в часы каждую неделю. Только когда я честно посчитал и увидел цифру — 10 часов в месяц на чистую административную рутину — мне стало некомфортно. 10 часов — это четверть рабочей недели. Выброшенная на то, что можно автоматизировать.

Третья история — про аварийный доступ. Когда что-то падает, иногда падает и панель управления провайдера. Hetzner пару раз был недоступен в момент, когда нужно было срочно посмотреть метрики. Timeweb API бывает возвращает ошибки в пиковые часы. SSH-подключение к серверам при этом работает — потому что это прямое соединение, не зависящее от API провайдера. Поэтому в нормальной архитектуре всегда должен быть fallback: если API провайдера недоступен, метрики берутся напрямую с сервера по SSH. Это важно заложить с самого начала, а не добавлять потом как костыль.

Ещё момент про выделенный сервер — обновления операционной системы и программного обеспечения. В облаке провайдер берёт на себя часть этой работы. На выделенном сервере ты сам. И если нет нормального процесса обновлений, очень легко оказаться в ситуации, когда сервер работает на ядре трёхлетней давности с известными уязвимостями. Автоматизированный аудит — раз в неделю проверять версии ключевых компонентов, смотреть CVE для установленных пакетов — это минимум, который нужно иметь в любой схеме с выделенными серверами. Я несколько раз находил серверы клиентов с критическими уязвимостями просто потому, что никто не следил за обновлениями — каждый думал, что кто-то другой за этим смотрит.

Про команду и онбординг — отдельная тема, которую хочу затронуть, потому что это очень реальная боль. Когда к тебе приходит новый разработчик или системный администратор и нужно ввести его в курс дела — сколько времени на это уходит? Если инфраструктура разрозненная и живёт только в головах двух-трёх людей, онбординг занимает несколько дней живого общения. Причём половина информации всё равно теряется, потому что люди забывают рассказать очевидные для них, но неочевидные для нового человека вещи. У нас пароль от Hetzner вот здесь, а от Timeweb вот тут, а к выделенному серверу подключаться только через VPN, который настроен вот так, а у 1С другой пароль и вообще туда лучше без нужды не лезть. Это никуда не записано, это просто "знают нужные люди".

Единый дашборд с нормальной документацией меняет это радикально. Новый человек открывает один интерфейс и видит всю инфраструктуру. Какие серверы существуют, у каких провайдеров, что на них запущено, каковы их текущее состояние и исторические метрики. Это не заменяет живое знание и опыт, но даёт базовую ориентацию за час вместо нескольких дней. А в момент кризиса, когда важен каждый человек, который может помочь, это особенно ценно.

И последнее — документация. Мультиоблачная инфраструктура без актуальной документации — это бомба замедленного действия. Когда что-то сломается серьёзно (а это произойдёт), и тебе нужно будет быстро восстановить с нуля, или объяснить новому человеку, что и где — ты хочешь иметь эту информацию не в голове единственного "умного парня", а в системе. Автогенерируемая документация инфраструктуры — один из первых модулей, который я реализовал. Нажать кнопку и получить актуальный обзор: какие серверы, где, что на них запущено, как всё связано — это экономит время не только в кризис, но и при онбординге.

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

Мультиоблако начинает себя оправдывать, когда появляются реальные требования, которые один провайдер не закрывает одинаково хорошо. Требования compliance — персональные данные в РФ — это не вопрос предпочтений, это закон. Требования производительности — тяжёлые вычисления или большие объёмы данных, которым нужен выделенный сервер. Требования географии — если часть пользователей в Европе и для них важна скорость доступа. Требования отказоустойчивости — когда нельзя зависеть от одного провайдера, потому что риски слишком высоки.

А что если добавить к этому ещё один критерий, про который обычно не думают на этапе выбора — требования по развитию? Малый бизнес имеет свойство расти и меняться. Сегодня вам достаточно одного VPS, через год — нужна другая конфигурация, и вы начинаете смотреть на рынок по-новому. Компания, которая изначально заложила гибкую архитектуру и привыкла работать с несколькими провайдерами, эволюционирует значительно легче. Она умеет добавлять новые серверы, менять провайдеров, перераспределять нагрузку — потому что у неё есть инфраструктура для управления этим. Компания, которая всё держала у одного провайдера и никогда не думала про абстракции, при необходимости масштабирования или смены провайдера оказывается в ситуации переезда с нуля.

Я видел оба сценария. Первый — болезненный, долгий, дорогой. Второй — плавный, управляемый, с предсказуемым результатом. Разница не в технологиях и не в бюджете. Разница в том, думал ли кто-то об архитектуре управления заранее.

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

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

И вот что я заметил: как только у тебя появляется единый взгляд на всю инфраструктуру, начинаешь принимать лучшие решения. Видишь, что выделенный сервер простаивает ночью на 10% нагрузки — может, стоит перенести туда часть задач с облака и сэкономить. Видишь, что один из серверов в Timeweb постоянно упирается в диск — значит, пора поднимать или оптимизировать. Видишь паттерн в логах — аномалия, которая пока не стала инцидентом, но станет. Управление инфраструктурой превращается из реактивного "тушим пожары" в проактивное "видим проблему до того, как она стала пожаром". А это уже другой уровень работы.

Но, пожалуй, самое важное — это изменение в отношении к инфраструктуре в целом. Когда она разрозненная и непрозрачная, она воспринимается как источник тревоги. Что-то там работает, непонятно как, и в любой момент может что-то упасть, и ты не знаешь, что именно и насколько быстро сможешь это починить. Это фоновый стресс, который присутствует постоянно у всех, кто отвечает за такие системы. Единый дашборд снимает большую часть этой тревоги — не потому что делает инфраструктуру надёжнее сам по себе, а потому что делает её видимой и понятной. Ты знаешь, что происходит. Ты знаешь, что если что-то пойдёт не так — ты узнаешь об этом быстро и сможешь быстро разобраться. Это уже другое качество работы, другое ощущение контроля. И вот это, по моему опыту, ценнее любых метрик и автоматических алертов — просто спокойно спать ночью, зная что инфраструктура под контролем.

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