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

Романтика железа и суровая реальность

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

Реальность, на самом деле, выглядела более прозаично. Кондиционер легко мог сломаться в пятницу вечером, генератор — не завестись в грозу, а кабели под фальшполом превращались в змеиный клубок, к которому страшно было притронуться. 

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

Именно здесь появился первый шаг к изменению модели — колокация и аренда стоек в коммерческих дата-центрах. После появилась Data Center as a Service (DCaaS), где физическая инфраструктура и все её ресурсы теперь принадлежали провайдеру, а клиент получал их по запросу.

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

Модель оплаты по факту использования изменила и экономику ИТ. Вместо капитальных затрат на строительство собственных дата-центров бизнесы начали относить расходы на инфраструктуру к операционным, так как стали платить только за реально использованные вычисления, хранение и трафик.

В этот момент дата-центр перестал быть «местом». Он стал абстракцией — набором ресурсов, доступных по сети, которые существуют ровно тогда и там, где они нужны.

Инфраструктура по запросу

Переломный момент наступил тогда, когда ЦОД впервые перестал ассоциироваться с конкретным зданием. В середине 2000-х появились первые публичные сервисы: ресурсы можно было получить не после закупки оборудования и его монтажа, а по API-запросу (первым был Amazon). 

Несколько строк конфигурации заменяли месяцы работы снабженцев и монтажников. Так в оборот вошёл термин Infrastructure as a Service (IaaS) — инфраструктура как услуга.

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

Однако теперь часть контроля пришлось передать в руки провайдера, доверившись SLA и технической поддержке. В этой ситуации проблемы с доступностью серверов или с сетью приравниваются к простою, на который сисадмин уже не может повлиять напрямую.

При этом модель аутсорсинга позволила даже небольшим компаниям достигать масштабов, которые ещё недавно были по силам только крупным игрокам с собственными ЦОД. 

Скрипты вместо ручного труда

Следующий шаг — появилась концепция Infrastructure as Code (IaC). Она связана с тем, что инфраструктуру вовсе перестали собирать руками. Вместо панели управления и ручных настроек появился код. Теперь серверы, сети и балансировщики описываются в виде конфигурационных файлов, которые система исполняет по заранее заданным правилам.

Эта практика решила несколько проблем одновременно. Во-первых, появилась повторяемость. Один и тот же набор файлов даёт одинаковое окружение хоть в тесте, хоть в продакшене. Ошибки формата «здесь работает, а там нет» ушли вместе с ручными изменениями, которые ранее забывали документировать.

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

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

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

Баланс между прошлым и будущим

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

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

Несомненно, корпоративные ЦОД будут нужны и через 10–20 лет. Ниша для них останется — по требованиям безопасности, экономическим соображениям или для очень специфических нагрузок). Но для большинства случаев парадигма изменилась.

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

© 2025 ООО «МТ ФИНАНС»