Большинство знакомится с DevOps как со списком инструментов: Linux, Docker, Kubernetes, Terraform, пайплайн в GitHub Actions. Выучить команды, пройти собеседование — и готово. А потом в два часа ночи случается первый настоящий инцидент, и выясняется, что инструменты никогда не были сложной частью. Сложная часть — знать, что на самом деле делает ваша система, когда умирает нода, когда деплой завершён наполовину или когда сертификат на ingress истекает и никто не замечает этого сорок минут.
DevOps и облачная инфраструктура — это не должность и не набор инструментов. Это дисциплина, которая делает изменение инфраструктуры воспроизводимым, наблюдаемым и обратимым. Это определение звучит абстрактно, пока не увидишь счёт за ручное изменение, сделанное под давлением.
Ниже — как на самом деле выглядит работа: один конкретный разбор, места, где сам стандартный подход даёт сбой, и честная карта того, как этому учиться.
Что это за дисциплина, механически
Любая инфраструктурная система — это цикл из четырёх вещей: объявленное состояние, применённое состояние, наблюдаемое состояние и разрыв между ними. Инфраструктура как код (IaC) объявляет. CI/CD применяет. Мониторинг наблюдает. Реагирование на инциденты закрывает разрыв.
Ценность этой области проистекает из одного свойства: объявленное состояние версионируется в git. До этого сервер был снежинкой — кто-то зашёл по SSH и изменил конфиг полгода назад, и никто не знает, какую строку. После этого сервер — это текстовый файл с историей коммитов.
Именно это изменение делает облачную инфраструктуру экономически отличной от дата-центра. Виртуальная машина, которую можно воссоздать из кода за девяносто секунд, — расходник. Виртуальная машина, которую три дня собирали вручную, — это питомец, которого нельзя уволить.
Одна задача, разобранная как следует
Возьмём задачу, с которой сталкивается каждая команда: выкатить небольшой API на Node.js в облако, с базой данных, и пережить плохой деплой. Вот как практик на самом деле выстраивает последовательность и что ломается на каждом шаге.
Шаг 1 — Определите единицу деплоя до написания кода
Два варианта:
- Образ контейнера, отправленный в реестр и развёрнутый в управляемом контейнерном сервисе. Вы получаете переносимость и предсказуемую среду выполнения. Платите временем сборки образа и хранилищем реестра.
- Серверлесс-функция. Вы получаете почти нулевую стоимость простоя. Платите холодными стартами, контрактом среды выполнения, который вы не контролируете, и гораздо более слабой локальной воспроизводимостью.
Распространённая ошибка новичка — выбрать Kubernetes для одного API с 200 пользователями в день. Теперь вы поддерживаете control plane, ingress-контроллер, менеджер сертификатов и CNI — для трафика, который обслужила бы одна небольшая виртуальная машина. Компромисс реален, и обычно его делают задом наперёд.
Шаг 2 — Соберите образ так, чтобы он был воспроизводимым
Закрепляйте базовый образ по дайджесту, а не по тегу. node:20 — движущаяся цель; node:20@sha256:... — нет. Сначала скопируйте package.json и package-lock.json, выполните npm ci, затем скопируйте исходники. Такой порядок означает, что слой зависимостей кэшируется, пока не изменится lock-файл, сокращая время сборки с минут до секунд при повторных сборках.
Запускайте от имени непривилегированного пользователя. Это стоит одной строки USER и устраняет целый класс последствий побега из контейнера.
Шаг 3 — Объявляйте инфраструктуру, не кликайте её
Terraform, OpenTofu или Pulumi — выбор меньше значит, чем дисциплина. Два правила, которые экономят месяцы:
- Удалённое состояние с блокировкой. Локальный
terraform.tfstateна ноутбуке означает, что два инженера могут молча перезаписать друг друга. Используйте бакет объектного хранилища плюс таблицу блокировок или нативную блокировку провайдера. - План перед применением, всегда, в CI, а не локально. План, сгенерированный на чьей-то машине, отражает их учётные данные и их устаревшее состояние.
Шаг 4 — Пайплайн
Минимальный честный пайплайн — четыре стадии: сборка, тестирование, план, деплой. Две детали отличают работающий пайплайн от демонстрационного:
- Тег образа — это SHA коммита git, а не
latest.latestделает откат невозможным, потому что вы не можете назвать, к чему откатываетесь. - Шаг деплоя идемпотентен. Запуск дважды должен давать тот же результат, потому что он запустится дважды.
Шаг 5 — Мониторинг, который отвечает на вопрос
Не начинайте с дашбордов. Начните с двух вопросов: сервис работает? и он достаточно быстрый? Это одна синтетическая проверка, бьющая по /healthz каждые 30 секунд, и одна метрика задержки с порогом оповещения. Всё остальное — украшение, пока эти две не работают.
Что ломается, если сделать иначе
Если пропустить тег SHA, плохой деплой не даёт вам ничего для отката — вы пересобираете из main, который уже ушёл вперёд, и снова выкатываете баг. Если пропустить блокировку удалённого состояния, два применения перемешиваются, и вы получаете балансировщик, указывающий на целевую группу, которой больше нет. Если пропустить проверку работоспособности, оркестратор направляет трафик в контейнер, который ещё загружается, и доля ошибок подскакивает на время холодного старта.
Где даёт сбой сама схема
Это не ошибки новичков. Это режимы отказа модели, и они бьют и по опытным командам.
1. Состояние IaC расходится с реальностью. Кто-то в 3 часа ночи хотфиксит security group в консоли. Terraform об этом не знает. Следующее применение молча откатывает фикс — или, что хуже, планирует уничтожение. Ранний сигнал: terraform plan никогда не пуст на чистой ветке. Если уже слишком поздно: импортируйте ресурс обратно в состояние через terraform import или обновите и согласуйте осознанно, вместо того чтобы применять вслепую.
2. Пайплайн зелёный, но деплой не произошёл. CI сообщает об успехе, потому что последняя команда завершилась с кодом 0. Ранний сигнал: длительность деплоя резко падает. Исправление: заставьте пайплайн проверять работающую версию — запрашивать у сервиса его SHA коммита и падать при несовпадении.
3. Путь отката никогда не тестировался. Все предполагают, что откат работает. Он не работает, когда новый релиз включал миграцию базы данных, удалившую столбец. Миграции — единственное, что нельзя откатить повторным деплоем. Правило: миграции должны быть обратно совместимыми на один релиз — добавьте столбец, разверните, заполните, удалите старый позже.
4. Стоимость становится инцидентом. Автомасштабирование по неправильно настроенной метрике запускает инстансы, которые никогда не уменьшаются. Никто не замечает, пока не придёт счёт. Ранний сигнал: количество инстансов только растёт. Исправление: оповещения о бюджете на 50% и 80% ожидаемых месячных расходов плюс жёсткий лимит на максимальное количество нод.
Как люди на самом деле этому учатся
Три пути, честно сравненные.
| Путь | Время до первой работающей установки | Стоимость | Что получаете | Что упускаете |
|---|---|---|---|---|
| Самообучение по документации и туториалам | Недели-месяцы | Почти ноль денег, много времени | Широкий охват, реальный траблшутинг | Нет обратной связи о здравости дизайна; дорогие ошибки на реальных облаках |
| Домашняя лаборатория и бесплатные тарифы | Недели | Небольшие облачные счета | Практическая мышечная память | Бесплатные тарифы скрывают сложные части — квоты, IAM, стоимость |
| Структурированный курс с проверенными упражнениями | Недели | Стоимость курса | Порядок, обратная связь по решениям, с кем сравнить | Всё равно нужна собственная практика после |
Ловушка самообучения конкретна: туториалы всегда работают. Их писали на чистом аккаунте, с разрешениями автора, на версии, которая с тех пор изменилась. В вашем аккаунте есть забытый VPC, квота сервиса от прошлого эксперимента и роль IAM, у которой нет разрешения, которое предполагает туториал. Вы тратите два вечера на ошибку разрешений, которая ничему не учит вас о DevOps.
Структурированный путь закрывает этот разрыв, помещая упражнение в известное состояние и давая обратную связь по решению, а не только по команде. В этом вся разница — команды можно найти поиском, проектные решения — нет.
Программа DevOps и облачная инфраструктура построена вокруг этого: сначала Linux и сети, затем контейнеры, оркестрация, пайплайны, IaC, облачные платформы, мониторинг и реагирование на инциденты, с работающей установкой в конце каждого блока. Если вы сравниваете её с самообучением, честное сравнение — время до компетентности против денег, и курс — это сторона с меньшим временем и большей стоимостью.
Кому подходит, а кому нет
Подходит людям, которые уже пишут код или что-то администрируют и хотят владеть путём от коммита до продакшена. Подходит разработчикам, уставшим перебрасывать деплои через стену, и сисадминам, переходящим от ручного управления серверами к объявленной инфраструктуре.
Не подходит тому, кто хочет избежать командной строки. Linux — не модуль, который сдал и забыл, это субстрат. Также не подходит никому, кто ожидает обход скучных частей: DNS, подсети, IAM и цепочки сертификатов — там живёт большинство реальных инцидентов, и никакой путь их не пропускает.
Если хотите сначала попробовать, поднимите одну небольшую виртуальную машину, разверните один контейнер за обратным прокси, опишите всё это как файл Terraform и уничтожьте. Если это упражнение приносит удовлетворение, а не скуку, эта область для вас.
Начните с одной работающей установки
Эта область вознаграждает тех, кто что-то сломал и починил своими руками. Вам не нужен большой облачный бюджет — нужен цикл, который можно повторять: объявить, применить, наблюдать, откатить. Курс DevOps и облачная инфраструктура проходит именно этот цикл на работающих установках, от основ Linux через контейнеры, CI/CD, IaC и мониторинг, с обратной связью по решениям, а не только по командам. Если такая структура соответствует тому, как вы учитесь, начните там — а если нет, упражнение с одной виртуальной машиной выше — вполне хороший первый шаг.