Финансовый директор смотрит на облачный счет, берет прайс на сервер и делит одно на другое. Цифры часто оказываются не в пользу облака, отдел ИБ тоже может относиться к внешнему контуру осторожно, после чего идея создания собственной облачной платформы выглядит здраво. Больше контроля, меньше зависимости от поставщика, инфраструктура физически ближе к компании.
Я понимаю эту логику. Как CPO облачного вендора, я регулярно вижу ситуации, где собственный контур действительно оправдан: жесткая латентность, специализированное оборудование, предсказуемая нагрузка на годы вперед, требования к изоляции, КИИ, особые модели эксплуатации. Но я также вижу другую сторону. Часто бизнес-кейсы внутреннего облака строятся на неполной арифметике. Считают железо, но не считают сервис. Считают запуск, но не считают пятилетнюю эксплуатацию. Другими словами, считают «свое», но не считают организационную цену этого «своего». Давайте попробуем разобраться.
Вы строите инфраструктуру или сервисную организацию?
Типичный сценарий по созданию on-premise «самостоятельно» выглядит так. Бизнес запускает внутреннюю платформу с тезисом «готовые решения не учитывают нашу специфику». Через полгода появляется свой портал самообслуживания, своя модель квот, свой образ Linux, своя интеграция с учетными системами. Через год это уже не инфраструктурный проект, а внутренняя продуктовая разработка с добавлением каталога услуг, ролей, chargeback или showback, SLA, процессами изменений, поддержкой, документацией, и, конечно, эксплуатацией 24/7.
Это не есть плохо само по себе, вопрос в другом. Компания осознанно строит внутреннего провайдера или просто расширяет ИТ-отдел? Разница принципиальная. Внутренний провайдер должен иметь понятный продуктовый каталог, финансовую модель, владельца сервиса, измеримые уровни обслуживания и ответственность перед потребителями. Без этого «облако» быстро превращается в централизованную очередь инфраструктурных заявок.
Ведущие мировые исследователи в области стратегического IT-управления, Джеймс Д. Маккин и Хизер А. Смит, в своих работах четко объясняют: совместно используемый ИТ-сервис — это не просто централизация. Он должен работать как сервисная бизнес-единица с клиентской ориентацией, автономией, прозрачными затратами и качеством, сопоставимым с внешним рынком.
Для меня это важное уточнение. Говорить о внутреннем облаке организации имеет смысл не в плоскости «как поставить платформу». Вопрос действительно шире — сможет ли компания создать сервисную модель, которую внутренние клиенты будут выбирать не по принуждению, а по ценности.
Скорее всего, вы считаете не то
Прямое сравнение «сервер против виртуальной машины» редко дает хороший управленческий ответ. Сервер сам по себе бизнесу не нужен. Нужна его полезная работа: транзакция, тестовый контур, аналитический расчет, витрина данных, пользовательский час.
Метрика, с которой я предпочитаю начинать разговор про внедрение облаков:
cost-per-workload = все затраты на инфраструктуру за период / количество фактически выполненных рабочих нагрузок
В эту формулу должны попасть не только серверы. Туда входят СХД, сеть, лицензии, резервирование, электричество, охлаждение, мониторинг, ИБ, обновления, аварийные замены, запас мощности, закупочные циклы, дежурства, обучение, регламенты и стоимость капитала. То есть, все, что добавится с момента начала использования сервера.
Условный пример. Если контур куплен под пик в 1000 условных единиц, а средняя загрузка составляет 350, компания финансово оплачивает 1000, а полезную работу получает на 350. Это не аргумент против собственного контура. Это аргумент на подумать, как будет эффективнее. Иногда высокая утилизация действительно делает on-premise выгодным. Но если нагрузка переменная, проектная или сезонная, стоимость полезной работы быстро растет. Зрелая постановка задачи все-таки требует цифр.
Бесплатное ПО не означает бесплатный сервис
OpenStack, Kubernetes, Ceph, Prometheus, Terraform, Ansible — сильные инструменты. Их ценность трудно переоценить. Но open source не отменяет стоимость эксплуатации. Совместимость версий, тестовые стенды, регресс при обновлениях, патчи безопасности, интеграция с IAM, CMDB, SIEM, резервным копированием и каталогом услуг — все требует постоянство в работе, не разовую настройку.
Я называю это «налогом на open source» не в негативном смысле, а как напоминание для финансовой модели. Лицензия может быть нулевой, но инженерные часы — нет. Более того, чем глубже компания дорабатывает платформу под себя, тем выше будущая стоимость обновлений и тем сильнее зависимость от конкретных специалистов.
Здесь особенно важен кадровый фактор. Для внутреннего облака нужны не только системные администраторы. Нужны DevOps/SRE, сетевые инженеры, storage-инженеры, специалисты по виртуализации, Kubernetes, Ceph, ИБ, мониторингу, резервному копированию, FinOps и поддержке. В Москве и Санкт-Петербурге такие команды собрать сложно и дорого. В регионах — еще сложнее. Это не означает, что задача невозможна. Тем не менее, кадровый риск должен быть отдельной строкой в TCO.
Инженерный креатив полезен, но ему нужны границы
У сильных инженерных команд есть естественное желание сделать лучше, чем «просто готовое решение». В корпоративных ИТ это часто оправдано: специфика бизнеса, legacy, внутренние стандарты, регуляторные ограничения. Но без продуктовых границ инженерный креатив начинает подменять бизнес-результат.
Появляется свой портал, потом свой каталог, потом свой биллинг, потом своя система квот, потом отдельная команда интеграций. Каждый элемент сам по себе разумен. Однако с экономической точки зрения мы получаем продукт внутри компании, который должен конкурировать по качеству, срокам и цене с профессиональными провайдерами. Если у этой внутренней платформы нет внешнего бенчмарка, P&L, SLA и права бизнес-заказчика сравнивать альтернативы, экономическая мотивация размывается.
Я бы сформулировал это как вопрос к инвестиционному комитету: если мы строим внутреннего провайдера, кто его клиент, как измеряется ценность, кто отвечает за деградацию сервиса, как считается возврат инвестиций и при каких условиях проект будет остановлен?
Риски, которые часто остаются за пределами TCO
Есть несколько затрат, которые редко попадают в первую версию облачного бизнес-кейса.
- Первая — потеря фокуса. Если компания занимается ритейлом, промышленностью, логистикой или финансами, строительство платформы конкурирует за внимание с основным бизнесом. Это не всегда плохо: крупнейшие группы иногда действительно становятся «рынком сами для себя». Но тогда внутреннее облако должно рассматриваться как индустриальная платформа, а не как способ сэкономить на счетах провайдера.
- Вторая — зависимость от ключевых сотрудников. В сложных инфраструктурных платформах документация важна, но реальная экспертиза часто остается у нескольких архитекторов и инженеров. Их уход способен превратить нормальную эксплуатацию в дорогое восстановление контекста.
- Третья — SLA. Внешний SLA не идеален и не решает всех проблем. Но он фиксирует ответственность: сервис упал = клиент получил компенсацию. Внутри компании такого механизма нет. Единственный рычаг давления — депремирование, которое чаще заканчивается уходом сотрудника, чем разрешением ситуации.
- Четвертая — юридическая и регуляторная ответственность. При самостоятельном администрировании компания остается владельцем процессов доступа, журналирования, резервного копирования, реагирования на инциденты и расследования утечек. Передать железо в свой ЦОД — не то же самое, что закрыть риск.
Российский контекст: регуляторика
152-ФЗ, ИСПДн, требования к хранению персональных данных на территории РФ, реестр отечественного ПО и требования к КИИ действительно влияют на архитектурный выбор. Эти нормы нельзя игнорировать. Более того, в ряде отраслей они становятся главным ограничением при выборе публичного облака.
Но из регуляторики не следует автоматический вывод «строим все сами». На практике требования часто усложняют самостоятельное строительство: нужны модель угроз, сертифицированные и совместимые средства защиты, регламенты, аудит, аттестация, контроль изменений, журналирование, разделение ролей, процессы реагирования. Если все это недооценить, «свой контур» может оказаться не дешевле, а дороже совместимого внешнего решения.
К тому же, российский облачный рынок за последние годы адаптировался. Появились публичные, выделенные, гибридные и on-premise-модели поставки, рассчитанные на разные уровни ИБ и регуляторики. Если публичное облако не подходит, это еще не означает, что единственный путь — самостоятельный дата центр. Вариантом может быть выделенное облако у провайдера, в том числе Astra Cloud: изолированный контур, договорная ответственность, понятная зона эксплуатации и возможность проектировать архитектуру под требования заказчика. Конечно, это не универсальный ответ для всех компаний, но, как минимум, подумать в этом направлении стоит.
Когда свое все же необходимо
Собственный контур может быть рационален. Я вижу потребность в нем в следующих сценариях:
- нагрузка стабильная, прогнозируемая и утилизируется на высоком уровне;
- есть дешевая или уже амортизированная площадка;
- компания умеет эксплуатировать инфраструктуру как сервис, а не как набор серверов;
- есть специализированное железо, например FPGA или промышленное оборудование;
- требования к задержкам или изоляции нельзя закрыть внешней моделью;
- компания сама является крупным внутренним рынком для платформы;
- есть понятный горизонт загрузки на 5–7 лет.
Даже в этих случаях я бы начинал не с закупки оборудования, а с анализа модели спроса.
Не нужно изобретать провайдера там, где нужна управляемая модель потребления
Российский рынок IaaS, PaaS и SaaS уже сформировался. У компаний есть выбор между публичным облаком, выделенным облаком, гибридной моделью и on-premise поставкой. Архитектурная работа с компании при переходе на облачную инфраструктуру не снимается. Все равно нужны инвентаризация рабочих нагрузок, RPO/RTO, классификация данных, FinOps, квоты, владельцы ресурсов, план выхода и понимание сетевой модели.
Но это другая работа. Не строить облако как продукт, а выбрать модель, где стоимость полезной работы, скорость запуска и требования ИБ сходятся в приемлемую экономику.
Моя рабочая гипотеза такая: для большинства компаний покупка облачного сервиса или выделенного облачного контура выгоднее самостоятельного строительства по совокупности факторов — денег, сроков, кадров, SLA, регуляторики и управляемости рисков. Тезис «свое — значит безопаснее и дешевле» я считаю слишком упрощенным. Иногда он верен. Часто — нет.
Для более глубокого и объективного анализа этой проблемы я приглашаю экспертов и практиков из российских компаний принять участие в моем исследовании «Факторы влияния на создание внутреннего ИТ-инфраструктурного провайдера вместо использования off-premise cloud». Если вы сталкивались с описанными вызовами или имеете контраргументы — напишите мне на рабочую почту vkonoplev@astralinux.ru
Автор: Виктор Коноплев, директор по продукту Astra Cloud (входит в «Группу Астра»)
astracloud.ru
