Недавно я прочитал книжку “Философия DevOps. Искусство управления IT” от Дженнифер Дэвис и Кэтрин Дэниелс. Как оказалось, эта книга одна из немногих, в которых не затрагиваются технические темы. В ней нет советов как лучше сконфигурировать высоконагруженный сайт или автоматизировать тестирование, вместо этого большое внимание уделено культуре DevOps. Причём эта культура разбирается по частям и с примерами. Так что такое культура DevOps?

Статьи и доклады на тему DevOps чаще всего приводят пример работу между командой разработки(Dev) и командой эксплуатации(Ops). Первым нужно чаще выпускать изменения в продукте, чтобы быстрее адаптироваться к изменениям и исправлять ошибки в работе. Вторым - нужна стабильность, соответственно, чем реже что-либо меняется, тем стабильнее работает продукт. Именно с этого вопроса и начало развиваться движение DevOps.

Правда количество участников не ограничивается этими двумя группами. Сюда можно смело включить команду тестирования(QA), инженеров по безопасности, бизнес и других прямых или косвенных создателей продукта. Для того, чтобы все участники процесса хорошо взаимодействовали, нужны не только налаженные процессы, но и культура между всеми командами. Иначе у нас получиться забюрократизированная система, где любое действие должно быть одобрено тремя уровнями менеджмента и любая задача перекидывается от команды к команде. Наладить общение и работу между людьми в команде, между командами в организации и между разными организациями - именно это ставится как философия DevOps.

Самое первое, что говорит нам книга, какие действия точно не приведут к появлению ДевОпс культуры:

Сейчас многие фирмы ищут себе DevOps инженеров, SRE и всякие другие красивые названия профессии. Я сам успел поработать в роли Build Engineer, System Owner, System Engineer и даже DevOps Engineer. Интересно то, что обычно под этим понимается Operations Engineer(Ops или инженер эксплуатации), который работает в команде с разработчиками и сам что-нибудь автоматизирует.

Толкование профессии «devops-инженер» является неоднозначным. Некоторые из толкований приведены в следующем списке:

• системный администратор, который знает, как писать программный код;

• разработчик ПО, владеющий навыками системного администрирования;

• мифический десятикратный инженер (производительность этого сотрудника в 10 раз выше производительности других сотрудников, хотя это скорее образное выражение), который может за одну зарплату выполнять обязанности системного администратора и разработчика ПО с наивысшим качеством работы.

Бывают и интересные случаи, которые встречались на рынке вакансий. И эта тема тоже затрагивается в книге:

С процессом найма devops-инженеров связано распространенное заблуждение. Суть этого заблуждения заключается в том, что можно взять на работу одного человека, который будет в состоянии исполнять две различные роли –разработчика и инженера по эксплуатации, работающих полный рабочий день, но при этом ему будут платить лишь одну ставку. На практике такая ситуация вряд ли возможна, а если даже возможна, то может привести к удручающим результатам. Попытка заставить одного человека работать за двоих может привести к ухудшению качества работы и выгоранию в долгосрочной перспективе. Также подобная ситуация будет способствовать формированию негативной репутации вашей организации, в которой плохо относятся к людям.

С этим я согласен только от части. Если проект достаточно большой, и на нём работает много людей, то обязанности по автоматизации развёртывания лучше поручить отдельному человеку. Бывают и небольшие проекты, где работает 1-2 программиста, тогда отдельному человеку, отвечающему за автоматизацию будет нечего делать, когда всё настроено.

Ещё одна цитата, ярко иллюстрирующая эту книгу:

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

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

Больше интересных цитат

Про сертификацию DevOps

Поскольку devops-методики в большой степени связаны с культурой, сертификация в этом случае вряд ли применима. Невозможно провести 60-минутный экзамен и по его результатам сертифицировать эффективность общения с другими людьми, оценить степень налаженности командной работы в вашей организации и сделать выводы о порядке обучения в организации. Сертификацию имеет смысл применять по отношению к высоким технологиям, использование которых потребует серьезного уровня знаний о таких вещах, как специфическое программное обеспечение или оборудование. Благодаря подобной сертификации компании могут получить представление о знаниях отдельных сотрудников в данной области.

Про open- space

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

Про смену работы

Согласно результатам недавно проведенных исследований, сотрудники с опытом работы в компании более 2 лет за 10 лет получат на 50 % меньше, чем если бы они уволились раньше(ссылка). Бытует мнение, особенно распространенное среди линейных сотрудников, что лучший способ получить существенную прибавку к жалованью –поменять работу. Естественно, нужно договориться о более высокой стартовой зарплате на новом месте. Сотрудники, которые длительное время работают в компании, ежегодно получают прибавку к жалованью, равную 3 % (в среднем). Но если учесть ежегодную инфляцию, равную 2 % (естественно, в США), то реальный ежегодный рост зарплаты составляет всего лишь 1 %. В случае же перехода в новую компанию можно рассчитывать на рост зарплаты от 10 до 30 %. Даже если вы очень любите свою родную компанию, вряд ли стоит игнорировать эти цифры.

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

Про развлечения на рабочем месте

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

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

Заключение

Мне книга понравилась, её можно поставить в один ряд с:

• Проект “Феникс”. Роман о том, как DevOps меняет бизнес к лучшему
• The DevOps Handbook – How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Видно, что авторы не понаслышке знакомы работой DevOps. Книга читается достаточно легко и понятно. Все процессы расписываются достаточно подробно, чтобы мог понять человек, далёкий от процесса разработки или даже информационных технологий. Я бы порекомендовал как новичкам, опытным профессионалам, так и менеджерам в области IT. Она есть как на английском языке, так и на русском.

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

Оценка: 9/10 - узнал много нового, хотя работаю не первый год. Плюс очень легко читается, так что можно скоротать за ней несколько вечеров.