DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. Это культура, методика, если угодно. DevOps движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации. Разработчики считали, что если код запустился у них локально, то нет проблем — можно запускать в продакшн. Если все же проблемы возникали, то со стороны команды эксплуатации звучало: «Да это проблемы с кодом, пусть разработчики разбираются!». Из-за такого подхода релизы продуктов постоянно затягивались и зачастую страдало качество конечного продукта. Сильно накладывало отпечаток еще и то, что за один релиз выкатывалось очень много изменений и было очень трудно разобраться, что же породило проблемы на продакшене.
DevOps был призван решить эти проблемы. Он должен был стать связующим звеном между командой разработки и командой эксплуатации. Условно, в DevOps культуре можно выделить несколько ролей, которые очень хорошо соотносятся с профессиями:
- Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде — это все про него.
- Release Engineer — отвечает за доставку кода от разработки в продакшн. Какая ветка пойдет в тестирование, какой билд попадет на продакшн, релиз-инженер занимается именно этим.
- Automation Engineer — инженер по автоматизации. Автоматизирует все, что движется. А что не движется, двигает и тоже автоматизирует. Автоматическая сборка при пуше в гит, прогон тестов, деплой на staging, деплой в продакшн — это все его задачи. Ключевая роль в DevOps подходе.
В целом можно выделить еще несколько ролей. Например, Security Engineer, который будет отвечать за прогон security-тестов и изучение уязвимостей в используемых компонентах. В реальном мире все (или почти все) эти роли по отдельности обычно совмещает какой-нибудь другой человек. К примеру, роль билд-инженера можно отдать в руки разработчика. Да и автоматизация настройки серверов обычно отдается системным администраторам. А DevOps инженеру остается проработать и автоматизировать процесс сборки и доставки кода от разработчика в продакшн.
В "DevOps Cookbook" и "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win", описываются лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода "Три пути". Они описывают ценности и философию, которые являются основой процессов, процедур, практик, а также обязательных шагов.
Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела — это может быть как большое подразделение (например, разработка или ИТ отдел) так и отдельные люди (например, разработчик, системный администратор).
В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT. Другими словами, он начинается тогда, когда определяются основные требования (например, для бизнес или ИТ), они закончены в разработке, а затем перешли в ИТ-отдел, в которых ценность сервиса затем и доставляется заказчику в виде сервиса.
Результаты следования Первому Пути на практике состоят в том, что известные баги никогда не передаются на следующий этап работ, никогда не развивается локальная оптимизация, приводящая к созданию глобальной деградации, происходит непрерывное улучшение и стремление достичь глубокого понимания системы.
Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью практически любой инициативы по совершенствования процесса является сокращение и усиление обратной связь, чтобы необходимые поправки могли внедряться постоянно.
Итоги Второго Пути: понимание и реакция на всех клиентов, как внутренних так и внешних, сокращение и усиление всех петель обратной связи, и углубление знаний о среде там, где это нужно.
Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству.
Нам нужны оба этих принципа в равной мере. Эксперименты и принятие рисков, является тем, что гарантирует, что мы продолжим улучшения, даже если это означает, что мы можем зайти в слишком опасные дебри. И мы должны учиться навыками, которые могут помочь нам выйти из опасной зоны, когда мы зашли слишком далеко.
Итоги Третьего Пути включают выделение времени для улучшения повседневной работы, создание ритуалов, которые поощряют команду в принятии рисков и возможному созданию неисправностей в системе с целью повышения устойчивости в перспективе.
В книге "DevOps Cookbook", выделено 4 модели внедрения DevOps:
Модель 1. Углубление процессов разработки в поставку: это включает расширение непрерывной интеграции и выпуска на боевые сервера, интеграция тестирования и информзащиты в рабочие процессы, что дает готовый к поставке код, настроенные среды, и так далее.
Модель 2. Создание обратной связи от прода до разработки: включает создание полной хронологии событий в разработке и администрировании, с целью помощи в разрешении проблем, а так же предоставление доступа команде разработки к анализу проблем на проде, одновременно с созданием разработчиками сервисов самообслуживания, везде где это возможно, и создание информационных радиаторов, показывающих изменение в поведении системы при вносе изменений.
Модель 3. Объединение разработки и администрирования: состоит во включении команды разработки в цепочку разрешения проблем, назначение разработчиков на разрешение проблем на проде, а так же взаимные тренинги между разработчиками и администраторами, чтобы уменьшить количество эскалаций.
Модель 4. Включение ИТ команды в разработку: состоит во включении или тесной связью между IT и разработкой, создание многоэтапных пользовательских историй (включая развертывание, управление кодом в производстве и т.д.), и определение нефункциональных требования, которые могут быть использованы во всех проектах.
Вообще DevOps инженер — это больше про опыт, нежели про знание конкретного софта. Девопс-ребята постоянно учатся, изучают и тестируют новые проекты и технологии. Они должны постоянно задавать себе вопрос: улучшит ли эта технология наш проект? Что лучше выбрать в качестве языка: ruby, python, golang или написать на чистых плюсах? А как мы будем доставлять изменения в продакшн, чтобы не поломать работающие системы?
Главное, что надо понимать, — DevOps инженер обладает действительно хорошим кругозором. Чтобы его расширить необходимо постоянно заниматься самообучением. Ниже я привел примерные шаги, которые помогут вам вырасти из, например, системного администратора в DevOps инженера. Главное запомните — список всего лишь указывает направление, оттачивать навыки придется вам самим.
- Сразу напишем небольшое приложение. Язык выбираем абсолютно любой. Приложение будет отдавать информацию о пользователях через HTTP. По сути, простенькое API
- Теперь давайте добавим работу с базой: пусть наши пользователи хранятся в базе. Идеально структуру базы хранить рядом с кодом и научиться прогонять миграции при новых изменениях. Таким образом ваше приложение само синхронизирует базу до нужной структуры
- Регистрируемся на GitHub/BitBucket и закидываем весь исходный код нашего приложения туда
- На своей машине поднимаем Jenkins/TeamCity и настраиваем автоматическую сборку приложения из нашего репозитория по кнопке
- Усложняем задачу. Настроим webhooks на GitHub/BitBucket, которые будут автоматически запускать сборку на Jenkins/TeamCity
- Добавим тестов в Jenkins: как минимум можно прогонять lint по нашему коду или набросать unit тесты
- Переключимся на настройку dev окружения. Берем в руки Ansible/Chef/Puppet/Salt и настраиваем виртуалку с нуля: создаем пользователей, устанавливаем необходимые библиотеки и зависимости
- Подводим все это дело под Vagrant: виртуалка должна автоматически подниматься и настраиваться
- Подключаем Vagrant к Jenkins с помощью соответствующего плагина: при пуше в git наше приложение собирается, и поднимается виртуальное окружение с помощью Vagrant + configuration system management
- Ищем best practices по деплою приложений на языке, который вы выбрали. Можно заворачивать все в deb/rpm пакеты, можно деплоить ruby с помощью Capistrano. Главное — выбрать решение
- Выбор сделан, реализуем его и конфигурируем Jenkins, чтобы после пуша в репозиторий, Jenkins, помимо сборки приложения и развертывания окружения, выкладывал и запускал наш код
- Добавляем смоук тесты: после запуска Jenkins должен запросить список пользователей у нашего API и убедиться, что получает ответ
- Добавляем мониторинг нашего проекта: изучаем time series базы, настраиваем Prometheus, Grafana, автоматически подключаем новый инстанс нашего приложения к мониторингу
- Улучшаем мониторинг: интегрируемся со Slack и PagerDuty, чтобы получать нотификации
- Читаем про Docker, пишем Dockerfile и оборачиваем наше приложение.
- Изучаем увлекательные статьи про настройку систем оркестрации Swarm, Kubernetes, Cattle. Следуем рекомендациям и поднимаем кластер
- Меняем Jenkins: собираем Docker образ, прогоняем тесты, запускаем собранный докер на кластере Kubernetes, проводим smoke тесты, вводим наше приложение в балансировку