Раздел 5.6. DevOps культура: Pets vs Cattle (2010 — ...)

К 2015 году у нас было всё: бесконечное железо (AWS), контейнеры (Docker) и умные базы данных (NoSQL). Но оставалась одна гигантская проблема — человеческий фактор. Системные администраторы всё еще настраивали серверы вручную. Релизы выкатывали люди с красными от недосыпа глазами. Любая ручная работа — это ошибка. А в масштабах Google ошибка — это катастрофа.

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

Раздел 5.6. DevOps культура: Pets vs Cattle (2010 — наше время)

А. Infrastructure as Code (IaC): Убийство любимых питомцев

Старый мир: Эпоха Жрецов и «Гэндальфа»

До середины 2010-х системный администратор был похож на шамана в пещере с проводами. Он отвечал за конкретные физические серверы в стойке. Чтобы различать серверы, им давали имена. Обычно это были пантеоны: Зевс, Аполлон, Тор или персонажи: Гэндальф, Фродо, Бильбо.

Сюжет: В каждой компании был сервер «Гэндальф». Это был главный почтовый сервер.
Если «Гэндальф» начинал кашлять (тормозить), сисадмин Вася не спал ночами. Он заходил внутрь, чистил логи, менял планки памяти, нежно перезапускал процессы.
Вася знал характер «Гэндальфа»: «Не обновляйте на нем ядро Linux, там стоит особый патч, который я накатил в 2009-м, иначе всё рухнет».
Bus Factor: Если Вашу сбивал автобус, компания умирала, потому что никто больше не знал секретов «Гэндальфа».

Этот подход назывался Pets (Домашние питомцы). Вы даете им имена. Вы заботитесь о них. Когда они болеют, вы их лечите.

Проблема: Это не масштабируется. Нельзя давать имена и лечить 10 000 серверов. Вы просто сойдете с ума.

Новый мир: Скотобойня (Cattle)

С приходом облаков парадигма сменилась. Авторство метафоры приписывают Биллу Бейкеру (Microsoft) и Рэнди Биасу. Они сказали: «Серверы — это не питомцы. Это скот (Cattle)».

У серверов нет имен, только бирки с номерами (s-4821, s-4822).
Они все одинаковые, клонированные из одного образа.
Если сервер s-4821 начинает тормозить, вы не разбираетесь, почему. У вас нет времени на ветеринарию. Вы пристреливаете его (команда terminate) и мгновенно заказываете у облака новый, свежий сервер.

Митчелл Хашимото и Terraform: Швейцария в мире облаков

Чтобы управлять этим «стадом», нужен был пастух. Им стал Митчелл Хашимото. Будучи студентом Вашингтонского университета, Митчелл был одержим автоматизацией. Он ненавидел настраивать среду разработки вручную. Сначала он написал Vagrant (чтобы любой разработчик мог поднять копию продакшена на ноутбуке одной командой).

Позже он основал компанию HashiCorp. В 2014 году он представил Terraform. В то время у Amazon был свой инструмент автоматизации — CloudFormation. Но он был ужасен (сложный JSON) и работал только с Amazon. Митчелл понял боль рынка: компании не хотели зависеть только от одного облака.

Идея Terraform: Один язык для всего. Вы не заходите в консоль AWS и не кликаете мышкой «Создать сервер». Вы пишете код (HCL — HashiCorp Configuration Language):

Terraform

resource "aws_instance" "web" {
  count = 50
  type  = "t2.micro"
  region = "us-east-1"
}

Вы запускаете terraform apply. Программа идет в AWS, проверяет, что там есть, видит разницу с вашим кодом и создает 50 серверов.

Если вы исправите 50 на 100, он докупит еще 50.
Если вы удалите файл, он уничтожит весь дата-центр за секунду.

Влияние: Администрирование умерло. Родился DevOps. Теперь вся инфраструктура банка хранится в Git. Аудитор может прочитать код и увидеть, как настроена сеть. Вы можете сделать git revert, чтобы отменить изменения в архитектуре целого дата-центра. Завод стал программой.

Б. CI/CD: Конвейер Генри Форда в IT

Если Terraform строит завод (стены, станки, электричество), то кто поставляет на конвейер детали (код)? Раньше процесс релиза (выкладки новой версии сайта) был праздником со слезами на глазах.

«Ад интеграции» (Integration Hell):

Команда из 20 человек пишет код две недели. Каждый пишет свой кусок.
В пятницу все пытаются соединить (merge) свои куски в один файл.
Ничего не работает. Кусок Пети конфликтует с куском Маши.
Сисадмины в «Ночь релиза» вручную копируют файлы на сервер по FTP.
Сайт падает. Клиенты звонят. Директор кричит. Все выходные команда чинит баги.

Косуке Кавагути и Дворецкий

В начале 2000-х в Sun Microsystems работал инженер Косуке Кавагути. Он был отличным программистом, но часто «ломал билд» (писал код, который не компилировался), и коллеги ругали его. Косуке, будучи вежливым японцем, устал извиняться. Он решил написать программу, которая будет «ловить» его ошибки до того, как их увидят коллеги.

Он написал скрипт, который автоматически просыпался каждый раз, когда кто-то сохранял код, пытался его скомпилировать и прогнать тесты. Если была ошибка, программа тут же включала красную лампу. Он назвал проект Hudson.

Драма с Oracle: В 2010 году Oracle купила Sun Microsystems. Oracle, известная своей жесткой политикой, заявила права на торговую марку Hudson. Сообщество Open Source возмутилось. Разработчики (включая самого Кавагути) форкнули проект и переименовали его в Jenkins.

Логотип: Дворецкий. Потому что он делает грязную работу за вас.

Дворецкий изменил жизнь. Теперь разработчик нажимал «Сохранить», и через 5 минут знал: «Я сломал проект» или «Всё ок».

GitLab CI и Дмитрий Запорожец: Труба (Pipeline)

Jenkins был хорош, но он был «старым миром» — его самого нужно было настраивать и лечить как «Питомца». В 2011 году украинский разработчик Дмитрий Запорожец из Харькова захотел сэкономить. Ему нужен был аналог GitHub, но который можно поставить на свой сервер бесплатно. Он начал писать GitLab.

Дмитрий и его партнер из Нидерландов Сид Сибранджи сделали гениальную вещь: они встроили «Дворецкого» прямо в хранилище кода. Появился файл .gitlab-ci.yml. Это инструкция для робота, которая лежит прямо в папке с проектом.

Это называется Pipeline (Труба/Конвейер):

Stage: Build. Собери приложение из исходников.
Stage: Test. Запусти 10 000 автотестов.
Stage: Security. Проверь, нет ли в коде дыр.
Stage: Deploy. Если всё зеленое, закинь код на серверы, созданные Терраформом.

Это называется CI/CD (Continuous Integration / Continuous Delivery).

Эффект Форда и Бизнес-контекст

Генри Форд не изобрел автомобиль, он изобрел конвейер. Автомобили стали дешевыми и одинаковыми. CI/CD сделал то же самое с софтом.

Раньше: Релиз раз в полгода. Это событие. Маркетинг готовит кампанию. Шампанское. Стресс.
Сейчас: Amazon, Netflix, Facebook делают тысячи релизов в день. Каждые 11 секунд на Amazon.com обновляется код.
Canary Deployment: Новый код сначала выкатывается только на 1% пользователей (канарейка в шахте). Если ошибок нет — на 5%, потом на 100%.

Бизнес-вывод: Скорость доставки фич (Time to Market) стала главным оружием. Тот, у кого лучше настроен конвейер CI/CD, выигрывает рынок. Он может проверить гипотезу («А давайте кнопка будет синей?») утром, а вечером уже знать результат. Конкурент с «ручным приводом» будет проверять это месяц.

Итог раздела 5.6

Мы завершили построение современного IT-завода.

Terraform строит стены и станки (инфраструктуру) по чертежам. Мы относимся к серверам как к безликому скоту.
CI/CD — это конвейерная лента, которая непрерывно доставляет сырье (код) и превращает его в продукт (работающий сервис), отсеивая брак (баги) автоматически.

Человеческий фактор сведен к минимуму. Система стала самовоспроизводящейся машиной. Теперь, когда у нас есть идеальная машина для обработки данных, остался последний вопрос: «А может ли эта машина думать?». В финальном Модуле 6 мы перейдем границу между алгоритмом и интеллектом.