Что и кто такое DevOps?

В жизни каждого приличного успешного проекта наступает момент, когда количество серверов начинает стремительно увеличиваться. Сервер с приложением перестаёт справляться с нагрузкой и приходится вводить в строй ещё несколько серверов и ставить перед ними балансировщик. База данных, прежде спокойно жившая на сервере с приложением, разрослась и нуждается не просто в отдельной машинке, но и ещё в одной для надёжности и бо́льшей скорости работы. Внутренняя команда теоретиков вдруг прослышала про микросервисы и теперь вместо проблемы одного монолита появляется много микропроблем.

Не успеешь и глазом моргнуть, как количество серверов ушло далеко за несколько десятков, каждый из которых нужно мониторить, с каждого нужно собирать логи, каждый нужно защищать от внутренних (“ой, я случайно дропнул базу”) и внешних угроз.

Зоопарк используемых технологий растёт после каждого совещания программистов, которые хотят поиграться с ElasticSearch, Elixir, Go, Lotus и бог знает с чем ещё.

Прогресс тоже не стоит на месте: редок месяц без важного обновления используемого софта и операционной системы. Ещё вчера ты жил спокойно с SysVinit, но теперь тебе говорят что нужно использовать systemd. И ведь правда нужно.

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

A system administrator, or sysadmin, is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers.

Все эти проблемы далеко не новы – умелые сисадмины вовремя подтянули знания программирования и автоматизировали всё по-максимуму, походу дела подарив миру такие инструменты, как, например, Chef и Puppet. Но возникла проблема: далеко не все сисадмины оказались достаточно умелыми, чтобы переквалифицироваться в настоящих инженеров сложных инфраструктур.

Более того, программисты, по-прежнему слабо представляющие, что происходит с их приложениями после деплоя, упорно продолжают считать сисадминов виновными в том, что новая версия софта съела весь CPU и открыла двери нараспашку всем хакерам мира. “Мой код идеален, это вы хреново сервера крутите”, – говорили они.

В такой непростой ситуации инженерам и сочувствующим пришлось заниматься просветительской деятельностью. А какая может быть просветительская деятельность без модного словечка? Так и появился DevOps – маркетинговый термин, вызывающий у людей совершенно разные ассоциации, от “культура внутри организации” до “мастер на все руки”.

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

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

Так же в сферу DevOps включают такие темы как Continuous Integration, Continuous Delivery и т. п. Мы уже однажды немножко рассказывали о CI в статье Непрерывная интеграция, Jenkins и Middleman.

Естественным путём DevOps из разряда “культуры” и “идеологии” переместился в разряд “профессии”. Рост вакансий с этим словом внутри стремительно растёт. Но что же ждут от DevOps-инженера рекрутёры и компании? Зачастую от него ждут смеси таких навыков как системное администрирование, программирование, использование облачных технологий и автоматизация крупной инфраструктуры.

Это означает, что нужно не только быть хорошим программистом, но так же идеально разбираться в том, как работают сети, операционные системы, виртуализация, как обеспечить безопасность и отказоустойчивость, а так же несколько десятков различных технологий, начиная от основных и проверенных временем вещей как iptables и SELinux и заканчивая более свежими и модными ранее упомянутыми технологиями как Chef, Puppet или даже Ansible.

Здесь внимательный читатель-программист скажет:

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

Другой внимательный читатель-сисадмин скажет:

Я отлично умею пересобирать ядро Linux и настраивать сеть, зачем мне учиться программировать, зачем мне ваши Chef, git и прочий странный зоопарк?

На это мы скажем: настоящий инженер должен уметь не Ruby, Go, Bash или “настраивать сеть”, а уметь строить сложные, красивые, автоматизированные и безопасные системы, и понимать как они работают от самого низкого уровня вплоть до генерации и отдачи HTML-страничек в браузер.

Конечно, мы частично согласны, что нельзя быть абсолютном профессионалом во всех сферах IT в каждый конкретный момент времени. Но ведь и DevOps – это не только о людях, умеющих всё делать хорошо. Это так же о максимальной ликвидации безграмотности по обе стороны баррикад (на самом деле являющихся одной командой), будь ты уставшим от ручной работы сисадмином или молящимся на AWS разработчиком.

В этой серии статей мы шаг за шагом будем знакомиться с основными инструментами и технологиями современного DevOps-инженера.

Разработчик, желающий чуть побольше узнать что происходит с его кодом после деплоя, ознакомится с необходимыми деталями и получит общее понимание всей экосистемы, тем самым перестав быть просто Ruby/Scala/Go-разработчиком с навыками Ansible.

Юные (и не юные) умы, желающие заняться DevOps, получат представление о том, как все работает и необходимые указания для дальнейшего изучения, а впоследствии научатся одной левой поддерживать сразу с два десятка организаций и заставлять дружить разработчиков и сисадминов.

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

Для работы тебе обязательно понадобится Linux. Мы очень сильно настаиваем на Red Hat дистрибутивах. Автор статьи сам в качестве основной системы использует Fedora 27 Workstation, а сервера mkdev крутятся на Centos 7.

В следующей статье мы ознакомимся с виртуализацией: узнаем зачем она нужна и как и при помощи чего ей пользоваться.