Большинство компаний уверены, что знают, сколько платят за ИТ-инфраструктуру. Но если посчитать не только «железо» и облака, а людей, ручные операции, простои и управленческий «налог на ожидание», итоговая сумма может оказаться выше на 20% и более. В тексте IT-World — честный разбор реального TCO, скрытых расходов и главный вопрос: когда выгоднее свое, когда облако, а когда — гибрид.
Рано или поздно каждый ИТ-директор оказывается в одной и той же ситуации: нагрузки растут, сопровождение дорожает, требования по надежности увеличиваются, а бизнесу нужно масштабироваться дальше. И в какой-то момент возникает вопрос: что делать с инфраструктурой?
Меня зовут Эдгар Сипки, и я много лет работал как с облаками, так и внутри облаков, думаю, что пришло время поделиться интересным опытом.
Поговорив с ребятами из индустрии, я выяснил интересную деталь: многие компании систематически недооценивают свою инфраструктуру и иногда могут промахиваться на 20% бюджета.
Суть вот в чем. Есть такой термин, позже популяризированный самой AWS, — undifferentiated heavy lifting (недифференцированная тяжелая работа) — когда команда разработки продукта тратит до половины бюджета на работу ради возможности работать, а именно на заботу обо всей инфраструктуре, как бы абсурдно это ни звучало.
Давайте попробуем разобраться, куда реально утекают деньги и как сделать так, чтобы тратить осознанно, а не как получится. И самое важное, как понять, что вам выгоднее: облако или же своя инфраструктура?
Из чего реально складывается TCO
Когда обсуждают инфраструктурные расходы, часто учитывают только серверы, облака, лицензии, но это далеко не все, что нужно реально учитывать. Правда, остальное прячется там, куда не все заглядывают.
Начнем с того, что считают все. «Железо» (серверы, СХД, сеть) — 10–20% TCO. Облачные сервисы еще 10–20%. Лицензии 15–25%. Телеком 5–10%. Безопасность 5–8%.
Но суть в том, что это далеко не все. Это все равно что посчитать стоимость автомобиля, забыв про бензин, страховку, ТО, штрафы и остальное.
И вот тут начинается самое интересное. Возьмем, к примеру, ИТ-отдел. Ключевой нюанс в том, что нас интересует не весь ИТ-персонал, а конкретно инфраструктурная команда — SRE, DevOps, сисадмины, DBA, сетевики. По отраслевым данным, расходы на эту команду составляют около 80% (!!) стоимости управления инфраструктурой. Само «железо» или облако — лишь 20%.
Давайте просто посчитаем в рублях.
Медианная зарплата DevOps-инженера в России составляет около 240 000 руб./мес. на руки (Dream Job и Хабр Карьера дают цифры 241–242 тыс., РИА Новости — 234 тыс.). Senior — 300 000–380 000 руб. по стране (в Москве и у топовых работодателей — до 450 000 руб.). SRE — порядка 260 000 руб.
Но зарплата на руки — это не стоимость для компании. С учетом НДФЛ, страховых, оборудования, лицензий на рабочие инструменты и обучение fully-loaded-стоимость одного инженера выходит 400 000–600 000 руб./мес. Команда из пяти человек — 25–35 млн руб./год, и это без единого сервера, просто люди. А теперь самое болезненное. То, что почти никто не считает, — ручной деплой.
Provisioning через тикет, «заведите заявку, через три дня сделаем», ручной рестарт упавших сервисов, ручная ротация сертификатов — все это называется красивым словом toil («ручная рутина»).
Google SRE рекомендует держать toil ниже 50% времени инженера — это прямо написано в пятой главе легендарной книги Google SRE. На практике у Google средний показатель 33%, но это Google. В обычных компаниях я видел 60–80%.
Давайте посчитаем. Если инженер стоит компании 500 000 руб./мес. и тратит 70% времени на ручную работу — то в итоге 350 000 руб./мес. стоит то, что вы не автоматизировали. На пятерых человек — 21 млн руб./год. Двадцать один миллион на то, чтобы руками делать то, что должен делать скрипт.
Другой срез, еще больнее: если 50 разработчиков ждут инфраструктуру по 10 минут, 5 раз в день — это 10 000 человеко-часов в год. При средней стоимости часа разработчика 2500 руб. получается 25 млн руб. просто на ожидание. Ticket-driven provisioning — это не процесс, это буквально налог на бизнес.
Вендоры и простои
Поддержка вендоров ежегодно составляет 18–22% от стоимости оборудования и ПО. Это стандартная ставка, подтвержденная практикой (SAP, например, берет ровно 22% за enterprise support). Купили серверов и ПО на 50 млн руб. — готовьте 9–11 млн руб./год за право позвонить вендору, когда что-то сломается.
Простои. По данным ИТИC, более чем для 91% предприятий час простоя обходится дороже $300 000. И это не абстракция, ведь когда ваш главный сервис лежит — это репутация, отток клиентов, штрафы по SLA и часто чья-то карьера.
Когда собираешь все вместе, картина получается вполне себе отрезвляющей. TCO систематически недооценивается на 20%, в итоге половина бюджета уходит на работу ради возможности работать.
Свое vs облако
Вот тут начинается самое интересное: если мы возьмем стоимость сервера и сравним с месячным облачным счетом или наоборот, то может показаться, что выйдет вдвое дороже. Но это примерно как сравнивать стоимость покупки квартиры с арендой, забыв про ипотечные проценты, ремонт и коммуналку. Так что давайте честно посчитаем оба варианта. Возьмем типичный кейс — 20 серверов.
Сценарий «все свое»
Разовые затраты (CapEx): серверы 30–60 млн руб. (и да, параллельный импорт добавляет 30–50% к цене, это наша реальность). СХД 5–20 млн руб. Сеть 3–8 млн руб. Итого: 40–90 млн руб. только за «железо». Это еще даже не включено.
Ежегодные (OpEx): Colocation (размещение оборудования в стороннем ЦОДе) в московском Tier III ЦОД — 135 000–150 000 руб./мес. за стойку 42U, на 5 стоек это 8–9 млн руб./год. Электричество сверх тарифа 1–2 млн руб./год. Каналы с резервированием 1,2–2,4 млн руб./год. Персонал (два-три инженера минимум, потому что один человек не может быть on-call 24×7 без выгорания) — 12–18 млн руб./год. Вендорская поддержка 9–11 млн руб./год. Лицензии ПО 5–15 млн руб./год. Итого на три года: 145–255 млн руб. И это без refresh cycle (обновление «железа» каждые 3–5 лет), без стоимости инцидентов, без техдолга, без того чувства экзистенциального ужаса, когда в 3 часа ночи падает продакшн.
Сценарий «все в облаке»
Те же 20 серверов, сопоставимые характеристики.
Compute (16 vCPU/64 GB RAM) в российском облаке 25 000–45 000 руб./мес. за VM. 20 штук — 6–10,8 млн руб./год по on-demand ценам. Storage 2,4–6 млн руб./год. Сеть и трафик 1,2–3,6 млн руб./год. Managed-сервисы от 2,4 млн руб./год.
И персонал. Да, если вы в облаке, вам тоже нужны люди, но не в таком колличестве: cloud-архитектор, DevOps, SRE. Минимум два-три человека — 12–18 млн руб./год.
Итого на три года: on-demand — 90–150 млн руб., с годовым commИТment — 70–120 млн руб.
Так когда что выбирать? Я не буду делать вид, что считаю, что облако гарантированно лучше (даже с учетом финансовой составляющей).
On-prem выигрывает, когда нагрузка стабильная и предсказуемая (утилизация 60–70%+), горизонт планирования 3–5 лет, есть своя инфраструктурная команда, регуляторные требования к локализации данных жесткие, а также есть серьезные требования к сохранности своих данных, особенно если придется резко выключать серверы.
Облако выигрывает, когда нагрузка нестабильная (сезонность, пики, быстрый рост), нужно быстро запуститься (месяцы, а не кварталы), нет своей инфраструктурной команды (и нет желания ее строить), много экспериментов, dev/test-сред, R&D, и самое важное — они не всегда могут быть дешевле, но всегда гарантированно проще.
Гибрид — когда все сложнее. И это, кстати, самый частый случай. Стабильная база — на своем, пики и эксперименты — в облаке, sensИТive данные — на своем, dev/test — в облаке. Экономия гибрида 15–20% по сравнению с чистым on-prem.
Самая частая ошибка, которую я вижу снова и снова, — когда компании принимают решение на основе инерции. К примеру, «все идут в облако — и мы пойдем»” или « нас всегда было свое «железо» — зачем менять». Но в реальности правильный подход — измерить текущую загрузку, посчитать TCO для каждого варианта на горизонте 3–5 лет, учесть не только «железо»/облако, но и людей, и ручные операции, и только потом решать.
И вот еще что: если не знаете свою реальную загрузку, начните с облака. Облако прощает ошибки планирования — можно масштабировать в обе стороны. On-prem не прощает. Купили 20 серверов, а нужно 10 — деньги уже потрачены, серверы стоят в стойке и грустно мигают светодиодами.
Стандартизация
У каждой команды свои образы, свои конфиги, свои скрипты деплоя. Это часто видно, когда компании либо очень быстро растут, когда инфраструктурный отдел не поспевает за изменениями в процессах разработки, либо в ситуации, когда не хватает экспертизы в стандартизации.
Но основная суть в том, что каждая команда так и хочет иметь «свою версию Python» или «свои особенности развертки» и т. д. Но в масштабе компании каждое уникальное решение увеличивает стоимость поддержки экспоненциально, ведь каждый вариант — это отдельная документация, отдельные скрипты и, самое важное, ребята, — это отдельные головы, которые могут в любой момент уволиться. Вместе со всей документацией, которая у них в голове.
Golden images решают именно эту проблему. Golden images («золотой» образ — стандартный и полностью готовый образ для виртуальных машин) — это преднастроенные образы с hardening, мониторингом, агентами безопасности. И вы создаете 2–3 эталонных образа вместо «каждая команда собирает свое». Новая VM за минуты, а не за дни. Compliance-аудит — в разы проще, и это буквально первый шаг к стандартизации для работы с инфраструктурой, а значит, удешевления уже сейчас, шаблоны вроде «веб-приложение на три инстанса с балансировщиком», «кластер PostgreSQL с репликой». Разработчик выбирает шаблон, заполняет параметры — и через 10 минут среда готова. Не через тикет и три дня ожидания. Помните про налог на ожидание в 25 млн руб./год? Вот тут он исчезает.
Внутренняя платформа для разработчиков
IDP (внутренняя платформа для разработчиков) — это когда все предыдущие идеи и технологии собраны в единый продукт для разработчиков. Яркий пример: Spotify и их Backstage. До платформы запуск нового сервиса (создание репозитория, GCP-проекта, настройка CI/CD-пайплайна) занимал 14 дней. После — 5 минут. Не деплой кода, а именно создание всего окружения для нового проекта с нуля. Но 14 дней против 5 минут впечатляет.
Впрочем, тут важная оговорка. DORA Report 2024 (Google Cloud, октябрь 2024) обнаружил парадокс: команды, использующие IDP, показали 8%-ное снижение throughput и 14%-ное снижение стабильности изменений при одновременном росте индивидуальной продуктивности на 8% и командной эффективности на 10%. DORA не говорит «если внедрить неправильно» — это именно общий наблюдаемый трейдоф, который может объясняться J-кривой: борющиеся команды внедряют платформу, производительность проседает, а потом растет.
Главный принцип: стандартизация — это не ограничения, а снижение когнитивной нагрузки. Разработчик не должен знать, как настроить сеть. Он должен нажать кнопку и получить результат. Платформа должна быть добровольной — заслужить пользователей тем, что она самый простой путь, а не единственный.
Почему облако может выйти дороже?
Lift-and-shift («перенесли без изменений») без перепроектирования. Перенесли on-prem-архитектуру один в один — затраты выросли в 2,7 раза. Почему? Потому что on-prem проектировали под пиковую нагрузку (утилизация 40–50%), в облаке воспроизвели ту же модель. Только теперь за простаивающие ресурсы платят каждый час, но суть в том, что средняя загрузка CPU клиентских VM в облаке 10–15%. Не 90%, не 50%, а 10–15% (Cast AI's 2024 Kubernetes report показывает 13% в среднем по AWS, Azure и GCP).
Без бюджетных лимитов и алертов один эксперимент за выходные может стоить как месячный бюджет. Историю, когда джуниор случайно запустил 200 GPU-инстансов в пятницу вечером, слышали все. Настройте алерты на 50, 80, 100% бюджета — во всех российских облаках это есть. Если каждый разработчик может создавать любые ресурсы — вы получите зоопарк. Я видел компании, где в облаке жили ресурсы, о существовании которых не знал никто, включая тех, кто их создал. Разделение прав по средам, квоты, запрет на создание без тегов— это не бюрократия, это и есть облачная гигиена.
Что реально снижает расходы?
Экономия 30–72% в зависимости от провайдера и срока. Первое, что нужно внедрить после стабилизации нагрузки. Но не раньше - покупайте как минимум после 12 месяцев наблюдений. CommИТment на нестабильную нагрузку — это как годовой абонемент в зал 2 января.
Rightsizing (подбор правильного размера ресурсов). Анализ p95-метрик за 14–30 дней и подбор правильного размера. Экономия 25–35%. Помните про средние 10–15% загрузки CPU? Вот rightsizing — это лекарство.
Автовыключение non-prod. Dev/staging/test только в рабочие часы. Экономия 20–70%. И серьезный вопрос: кто использует тестовое окружение в 3 часа ночи? Если кто-то скажет «я» — поговорите с этим человеком, у него проблема, и не с инфраструктурой.
Zombie cleanup. 5–15% бюджета съедают забытые ресурсы. В 2012 году McKesson провела «охоту на зомби» в рамках инициативы Uptime InstИТute Server Roundup и списала 586 серверов, сэкономив почти $735 тысяч и снизив энергопотребление на 930 кВт. И это одна компания. Представьте масштаб проблемы по индустрии.
K8s-оптимизация. Автоскейлинг, rightsizing подов, namespace-квоты. Экономия 30–50% на кластерах. Kubernetes без FinOps — это как спорткар без спидометра: быстро, мощно и очень дорого.
Нужны ли бэкапы?
Короткий раздел, потому что мысль простая. Когда-то в начале карьеры мой CTO cказал мне прекрасную фразу: «Люди делятся на тех, кто просто делает бекапы, и тех, кто их проверят».
Бэкап, который вы не проверяете, как подушка безопасности, которую никогда не тестировали — теоретически она есть, практически — кто знает, как сработает :) На бумаге RPO 15–30 минут. В реальности большинство могут восстановить только 24–48 часов данных. Менее 30% регулярно проверяют RTO. Это как система пожаротушения, которую не тестировали со дня установки. Просто для примера: 16 мая 2019 года произошел крупный провал у Yandex Cloud. В результате инцидента было безвозвратно удалено 0,77% всех виртуальных машин и boot-дисков в одной из зон доступности. У части пользователей полностью были потеряны продакшн-серверы. У некоторых, конечно же, были бекапы, но даже они не покрывали всю утраченную информацию — не содержали последних дней либо оказались «битыми».
Что делать
Регулярные тесты восстановления — не реже раза в квартал. Tiered storage — разница между горячим и архивным хранилищем доходит до 23× (AWS S3 Standard vs Glacier Deep Archive — это почти точно 23,2×), но учитывайте стоимость retrieval и минимальные сроки хранения. Дедупликация бэкапов — типичное соотношение 10:1–30:1, в теории можно достичь и 40:1+, но это сильно зависит от типа данных и политик ретенции.
Экономить на бэкапах как экономить на тормозах. Экономия заметна только до первого использования.
Так в итоге, облако дешевле или свое дешевле?
Если вы дочитали до этого момента и ждете финальный вердикт в духе «облако дешевле» или «свое дешевле» — у меня не очень хорошие новости.
Если честно, точного ответа в реальности нет, и любой, кто вам его дает, либо что-то продает, либо не считал. Именно поэтому, чтобы принять решение, я рекомендую обращаться не к облакам за оценкой, а к профильным консультантам. Компания с грамотным FinOps выжимает 30–50% экономии из облака за счет rightsizing и reserved instances. Та же компания на своем «железе» сэкономит еще 20–40% сверху, но только при наличии профессиональной команды, отлаженных процессов и культуры эффективности.
А если облако — то какое?
Тут важно понимать одну вещь: масштабирование вашего бизнеса упирается в возможности масштабирования вашей инфраструктуры.
Большинство российских провайдеров построены на OpenStack. Это рабочая технология, но с потолком, причем не очень высоким. На рынке есть несколько игроков, которые пошли другим путем и написали платформу с нуля:
- Yandex Cloud — самая зрелая экосистема в РФ. Контроль всего стека от гипервизора до API, лучший managed K8s на рынке, глубокая интеграция AI/ML.
- h3llo Cloud — молодой, но с интересным подходом: современное «железо» (Xeon 5, DDR5), никакого shared CPU — каждая VM получает выделенные ядра. Плюс managed MariaDB вместо MySQL — полностью обратно совместимая, но стабильно быстрее на чтении и высокой конкурентности.
Из тех, кто на OpenStack, но делает это хорошо: Selectel — сильный вариант для гибрида bare metal + облако, прозрачные цены и долгая история на рынке. K2 Cloud — крепкий середнячок с хорошим балансом функционала.
Но провайдер — это второй вопрос. Первый вопрос — все-таки посчитать.
Прежде чем выбирать между облаком и своим «железом», посчитайте честно. Не стоимость серверов, а полную стоимость владения — с людьми, с toil, с простоями, с тем самым тикетом «заведите заявку, через три дня сделаем».
А если не знаете свою реальную загрузку — начните с облака, оно прощает ошибки планирования, а on-prem — нет.