Годовой бюджет на инфраструктуру: статьи, которые забывают все

MAATRIX

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

Почему бюджет почти всегда оказывается заниженным

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

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

Время администрирования: труд, а не только железо

Самая недооценённая статья — это не деньги за инфраструктуру, а время людей, которые её обслуживают. Сервер сам себя не обновляет, не мониторит логи, не разбирает инциденты в три часа ночи и не читает changelog перед major-апгрейдом. Если это делает штатный инженер — его время всё равно стоит денег, просто эти деньги уже размазаны по зарплатному фонду и не попадают в строку «инфраструктура». Если это делает подрядчик или агентство — счёт хотя бы виден, но часто недооценён по объёму часов.

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

Отдельно стоит учитывать, что время администрирования растёт скачками, а не плавно: миграция на новую версию ОС, смена панели управления, внедрение нового мониторинга — это не рутинные часы, а проекты, которые съедают недели. Если в компании планируется хотя бы одна такая миграция в год, её стоит внести в бюджет отдельной строкой, а не растворять в «текущей поддержке».

Бэкапы, восстановление и учения disaster recovery

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

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

В-третьих — и это забывают почти всегда — стоимость плановых учений по восстановлению. Настроенный бэкап без проверки восстановления — это гипотеза, а не гарантия. Регулярная тренировка (выгрузить копию на тестовый сервер, поднять сервис, засечь время) стоит рабочих часов несколько раз в год, но именно она превращает «мы вроде бэкапим» в «мы точно умеем восстановиться». Разбор того, почему эти учения обходятся дешевле реальной аварии, — в статье «Стоимость учений по восстановлению: почему они дешевле одной аварии».

Домены, SSL и мониторинг сверх бесплатных лимитов

Домен и SSL-сертификат — это то, что легко один раз оплатить и забыть в буквальном смысле: продление домена приходит раз в год, а Let's Encrypt автопродляет сертификат каждые три месяца без участия человека. Пока автоматика работает — расходов почти не видно, и именно поэтому их выпускают из годовой сметы. Проблема начинается, когда доменов становится много (поддомены под тестовые окружения, отдельные зоны под разные продукты) или когда для части сервисов нужен не бесплатный сертификат, а платный wildcard или EV-сертификат под конкретные требования клиента. Это уже не разовая мелочь, а строка, которая растёт вместе с числом сервисов.

С мониторингом та же логика, но острее. Базовый мониторинг доступности — почти всегда бесплатный: несколько проверок, простой uptime-чек, минимальный набор алертов укладывается в лимиты бесплатных тарифов сервисов мониторинга. Как только нужно больше точек проверки, более частый интервал опроса, хранение метрик за длительный период или алерты в несколько каналов сразу — бесплатный лимит заканчивается, и появляется платная подписка, которую редко закладывают заранее именно потому, что «мониторинг же бесплатный». Разбор момента, когда за формально бесплатные SSL, CDN и мониторинг всё-таки начинают выставлять счёт, стоит держать в голове при планировании — рост числа сервисов и доменов почти гарантированно этот момент приближает.

Лицензии стороннего ПО и буфер на непредвиденный рост

Голый сервер стоит одних денег, но поверх него почти всегда стоит софт, у части которого лицензия не входит в аренду. Панель управления хостингом, коммерческая СУБД, специализированное ПО для бизнеса (учётные системы, CRM, специфичные модули), лицензии на форк с расширенной поддержкой — каждая такая позиция имеет свою модель оплаты: разовая, годовая подписка, оплата по числу пользователей или ядер. При планировании бюджета на инфраструктуру эти лицензии часто считают отдельно, «в софтовом бюджете», и в итоге инфраструктурная смета выглядит заниженной ровно на сумму лицензий, без которых сервер бесполезен. Классический пример — лицензирование Windows Server и клиентских лицензий CAL, где сумма до покупки часто больше, чем кажется на первый взгляд; логика переносится на любой другой лицензируемый софт с похожей моделью оплаты.

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

Обновление и замена оборудования по графику

Если инфраструктура — это собственное железо, а не только аренда, добавляется ещё одна статья, о которой вспоминают в момент отказа, а не в момент планирования: срок службы компонентов. Диски, блоки питания, память — всё это имеет ожидаемый ресурс, и его истечение не означает мгновенную поломку, но означает растущую вероятность отказа именно тогда, когда его меньше всего ждут. Бюджет, который не закладывает плановую замену, фактически финансирует внеплановую — а внеплановая замена почти всегда дороже: она включает не только сам компонент, но и срочность, простой и иногда экспресс-доставку.

Даже если инфраструктура полностью на аренде, вопрос обновления не исчезает — он просто переносится на другой уровень: рано или поздно текущий тариф перестаёт соответствовать задаче, и переход на следующий уровень (больше ядер, больше памяти, другой класс диска) — это тоже расход, который стоит предвидеть, а не открывать для себя в момент, когда сервис уже начал тормозить. Честный подход к сроку жизни железа и к моменту, когда пора закладывать замену, разобран в статье «Амортизация серверного железа: как считать срок жизни честно».

Ниже — сводная таблица статей, которые стоит явно внести в шаблон годового бюджета, если их там ещё нет.

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

Частые вопросы