Почему нельзя пускать программистов на сервера, или Почему девопсы еще не вымерли, хотя об этом много говорили

Привет, Хабр!

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

Мнение автора может не отражать позицию компании и других коллег.

Знакомьтесь — Александр Ефимов, Configuration manager/DevOps

Есть у меня знакомый, который, будучи первоклассным сисадмином, мечтает стать программистом. По его словам, хочет творить, а не использовать уже существующий… не очень хороший софт. В чем-то я его понимаю: «чистое» творчество — безусловно, круто. Но давайте разберемся, что и как происходит на самом деле.
Я уже достаточно долгое время работаю девопсом. Проекты, в которых я имел честь участвовать, неизбежно проходили примерно следующие фазы:

1. Анархия. Каждый разработчик делает и коммитит все, что хочет (во всяком случае, так это видится стороннему наблюдателю). В конце спринта «самый виноватый» собирает все наработки в некоего кадавра, работающего на его машине и (теоретически) на каком-то из серверов. Потом, проходя круги боли и ада, это внедряется на сервера и как-то там работает.
2. «На стейджинге работает». Наконец-то заказчик выделил деньги на один сервер стейджинга. Теперь ад со сборкой работающего прототипа повторяется еще и для стейджинга. Пикантность ситуации в том, что вся «обвязка» в виде БД, сервера очередей, кеш-сервера и прочего живет на localhost. Т. е. получаем ту же машину разработчика, только удаленно. Со всеми выводами типа хардкодинга части sensitive параметров соединений.
3. Нам нужен какой-нибудь админ. На этом этапе все, сотворенное ранее, уже стало неуправляемым, стейджингу плохо, продакшен не обновляется. Тут и приходит кто-то, кого назовут DevOps, и начинает разгребать бардак и раздавать именные пендели средства мотивации. Если вообще приходит.

Вот мы и подошли к самому главному — конфликту Development и Operations. Он уже со всех сторон рассмотрен и обмусолен и вкратце выглядит вот так:

Далее я попытаюсь объяснить, почему для меня решение этого конфликта вынесено в заголовок статьи.

Творчество vs. порядок

Разработка ПО — творческий процесс. Управление творческим процессом предполагает гибкость и умение не мешать. Собственно, методология Agile растет именно из этого: ее цель — управлять хаосом, минимально его упорядочивая. И это, по-моему, действительно хорошо: при правильно сделанном Agile получается неплохой продукт.

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

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

Пример из жизни. Допустим, по умолчанию log-файлы лежат в директории приложения. Разработчикам это удобно: всегда знаешь, куда смотреть. Разработчик разворачивает приложение на тестовом сервере. Через три дня диск сервера переполнен, сервер очередей упал, БД орет в свои логи о том, что писать некуда. Ничего не работает, demo через три часа, все в шоке. А причина проста: надо было переложить логи в специальный раздел и/или настроить ротацию. С этим даже начинающий админ/DevOps справился бы на автомате, не особо задумываясь, зачем это надо. Просто «для порядка».

Умение пользоваться существующими решениями

Когда я впервые начал работать в компании, разрабатывающей ПО (в той компании — для внутреннего использования), меня удивила их система мониторинга. Она была самописной и невероятно глючной. В 2009 году. Отделу инфраструктуры пришлось пройти через многое, чтобы убедить начальство, что надо внедрить Zabbix.

С подобными проблемами я сталкивался еще несколько раз в разных компаниях, и везде было одно и то же: «нам проще написать свое, чем разбираться в чужом». Уже позже я понял причину подобного образа мыслей: разработчикам действительно проще разрабатывать. Это админы привыкли копаться в конфигах, «снюхивая» несколько систем в единую. Иногда через параметры, иногда скриптами, иногда — и тем, и другим. А разработчику проще написать 100 строк кода, чем разбираться в документации и конфигах.

Вообще, здесь конфликт подходов очень остро заметен. Админ не полезет в код, пока не припечет, точно так же как девелопер не полезет в конфиги.

Разница компетенций

Отчасти это следует из вышесказанного, но факт остается фактом: сисадмин/DevOps и программист/девелопер имеют абсолютно разные компетенции.

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

Пример из жизни. На одном из предыдущих мест работы, в небольшой софтовой компании, я столкнулся с вопросом начальства «а зачем нам админы/DevOps?». И действительно, они в упор не понимали, что же делает системный администратор. IP-адресация в их локальной сети была из Internet-диапазона (благо, эта подсеть принадлежала какому-то из американских провайдеров домашнего интернет-доступа). Использовались коммутаторы-«мыльницы» и обычный «домашний» маршрутизатор для доступа в Internet. Эти люди разрабатывали весьма серьезную распределенную систему (не скажу чего), пытаясь сделать ее отказоустойчивой. Через примерно полгода разработки осознание, что надо, все же, нанять кого-то, разбирающегося в серверном оборудовании и ОС, победило.

Заключение и выводы

По-моему, разделение сфер влияния — это прекрасно. Можно быть сколь угодно универсальным «сферическим айтишником в вакууме», но всего не успеешь никак. Именно поэтому девелоперы разрабатывают ПО, а админы — создают и управляют инфраструктурой и этим же ПО.

Программистов нельзя пускать на сервера не потому, что они плохие, а потому, что это не их забота. Для этого есть девопс — «чужой среди своих», человек-админ в стане девелоперов, адаптировавшийся к хаосу и создавший в нем странный порядок, называемый кучей словосочетаний с Continuous (Continuous Integration/Deployment/Delivery/Operation).

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

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

Но на сервера их все равно не пускайте :).

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.