Путь DevOops-героя

Soft skills крайне важны для DevOps-специалиста, потому что развитие DevOps в компании затрагивает не только используемые инструменты и технологии, но и взаимодействие сотрудников компании.

Антон Вайс, основатель Otomato Software, сравнил внедрение DevOps со строением мифов разных культур. Звучит фантастично, не правда ли? Но эта схема, как оказалось, отлично ложится на картину того, с чем сталкиваются многие DevOps-специалисты.

Далее текст будет вестись от лица Антона, а вы усаживайтесь удобнее, и добро пожаловать под кат.

Я начал свою карьеру в IT ровно 20 лет назад. Меня, молодого, неопытного, но подающего надежды программиста взяли писать на C в компанию, которая занималась разработкой поисковых механизмов.

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

Что делать? Замок было не открыть, на работе еще никого не знал, и звать на помощь было неудобно. Поэтому я тихонько скреб дверь, и меня услышал сисадмин (благо серверная находилась рядом с туалетом). Он попытался открыть дверь снаружи, но замок застрял изнутри. Тогда админ меня проинструктировал, как разобрать жалюзи, чтобы вылезти через окно. Я был спасен и получил первый урок, как работают вещи в IT: когда программист застревает в сортире, то админы помогают им выбраться.

Этот случай стал для меня отправной точкой. У всех нас есть подобная точка, ведь мы куда-то движемся, а движение инженеры привыкли описывать диаграммами, схемами и алгоритмами.

12 этапов путешествий DevOps-героя

Еще 70 лет назад американский исследователь мифологии Джозеф Кэмпбелл написал книгу «Герой с тысячью лицами» (к слову, она вдохновила Джорджа Лукаса на создание «Звездных войн»). Кэмпбелл, сравнив истории Будды, Иисуса, Мухаммеда, Гильгамеша и других божеств, пришел к выводу, что все эти мифы можно представить в виде истории судьбоносных путешествий архетипического героя, которые можно разложить на различные этапы. В первоначальной схеме было 18 этапов, затем голливудские сценаристы упростили схему до 12 этапов. Эти этапы настолько плотно впаяны в наш культурный код, что любую человеческую историю можно разложить на 12 этапов, в том числе DevOps-трансформацию.

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

Схема циклична, потому что конец каждого пути — это начало нового витка. Чтобы стать настоящим DevOps-героем, индивиду и организации необходимо провести изменения по всем четырем измерениям:

• люди;
• процессы;
• инструменты:
• связывающее всех информационное пространство.

Обычный мир

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

Но в этом королевстве что-то прогнило, и мы услышали зов приключений — «зов DevOps».

Зов DevOps

В книге «Руководство по DevOps» от Джена Кима, Патрика Дебуа и других этот зов называют «моментом ага» — моментом, когда мы понимаем, что в IT некоторые вещи работают достаточно плохо, и есть другой путь. Такой точкой может быть доклад на конференции, первый опыт работы в кроссфункциональной команде или попытка собрать пайплайн своими руками.

В основе «моментов ага» лежит стресс и нежелание страдать дальше. Боль может возникнуть от недооценки нашего труда, отсутствия понимания, невозможности реализовать задуманное или несоответствия потраченных усилий и полученных результатов. Именно эту боль DevOps и был призван решать, поэтому первый вид зова мы назовем «DevOps от боли».

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

В 2017 году я помогал одной компании с подобной DevOps-трансформацией. Ситуация была удручающая, и мы наметили первые шаги и промежуточные цели. Но главный начальник отвел меня в секретную комнату за закрытой дверью и спросил, каких результатов следует ожидать, если их компания выполнит все рекомендации. Я начал говорить о творческом подходе, мотивации, инновациях, сплоченных командах, стабильности системы и скоростных методах доставки, однако начальник меня перебил и сказал, что он должен сократить расходы и понять, сколько инженеров можно уволить после внедрения DevOps.

Схожую картину можно проследить и на личном уровне. В одном случае мы внедряем DevOps, чтобы работать лучше, а в другом случае мы хотим повысить свой рыночный рейтинг и оплату труда. Однако опыт показывает, что изменения, происходящие от боли сотрудников, а не начальников, имеют больше шансов на успех, потому что боль — это хороший компас.

Отказ от зова

Мы услышали зов, теперь надо приниматься за работу? Не тут-то было. В схеме Кэмпбелла следующий этап называется «Отказ от зова». Здесь герой встречает привратника, который отговаривает героя от путешествия. В нашей истории таким привратником может оказаться либо начальник, который не выделяет ресурсов для проведения изменений, либо сотрудники, которые устали от организационных инициатив, и они уже не верят в изменения к лучшему.

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

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

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

Встреча с наставником

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

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

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

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

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

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

Четвертый вариант хорошо сочетается со всеми остальными — книга, например «Руководство по DevOps» или «Проект „Феникс“». Когда я был начальником интеграции в компании AT&T, на моем столе всегда лежала книга «Непрерывное развертывание ПО» Хамбла и Фарли, и во всех сложных ситуациях я обращался к первоисточнику за советом.

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

Пересечение порога

Мы начинаем смотреть на обычный мир с обратной стороны, и приходит время строить DevOps. Мы горячо обсуждаем распил монолита на микросервисы, строим первые пайплайны, осваиваем Kubernetes, и кажется, что дороги назад уже нет. Но основные сложности новой дороги еще впереди.

Испытания, демоны и союзники

Герой сталкивается с первыми испытаниями, где его поджидают демоны:

• сомнения;
• страх ответственности;
• вложение большого количества денег;
• недостаток знаний;
• борьба за власть;
• нагромождение сложности;
• бюрократизм.

Поначалу мы говорим, что распилим монолит, построим конвейер от кода до прода или же добавим по ops-у в каждую команду dev-ов. Но в процессе возникают более сложные вопросы:

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

Ответы на них мы получаем неопределенные, ведь нужно подгонять их под конкретные задачи.

На этом этапе герой должен искать союзников, которые помогут победить демонов. И тут наставники — ядро команды и надежные советники в виде консультантов или книг — становятся незаменимыми.

Мы начинаем понимать, что DevOps касается не только отдельной организации, но и отрасли в целом, и мы ищем союзников уже в сообществе. Мы посещаем конференции (например, DevOops), митапы, вебинары и прочие тусовки, и приходим к мысли, что DevOps тесно связан с оперсорсом. Мы должны не только пользоваться наработками сообщества, но и возвращать ему фидбек и участвовать в попытке переосмысления отрасли: искать баги и писать код в инструменты, которыми пользуемся. Так мы приближаемся к «сокровенной пещере».

Приближение к «сокровенной пещере»

Заручившись помощью союзников и прочитав полезную литературу, мы готовимся отвечать на самые важные вопросы:

• языки программирования и фреймворки;
• CI-сервер;
• механизм деплоя;
• базы данных;
• очереди сообщений.

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

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

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

«Точка смерти»

Мы думали, что прошли все круги ада и ответили на все сложные вопросы, но наступает главное испытание по Кэмпбеллу, где проверяют, настоящий ли герой или нет. В этот момент герой либо погибает, либо побеждает и получает незаменимое доказательство, что он тот самый единственный славный герой.

В ситуации с DevOps-трансформацией все не столь драматично, но есть несколько околосмертных явлений, которые можно наблюдать.

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

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

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

Подарок силы

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

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

Когда мы получаем подарок силы, мы начинаем дорогу домой.

Дорога домой

После прохождения испытаний герой принимает решение сделать полученный опыт частью своей повседневной жизни. Будда становится учителем, Симба возвращается домой, чтобы стать царем зверей, а наша DevOps-организация встает на путь постоянных изменений. Теперь «зеленые пастбища» у нас, и другие неофилы стремятся перепрыгнуть уже на палубу нашего авианосца.

Сам Кэмпбелл в книге написал:

The trick in returning is to retain the wisdom gained on the quest, to integrate that wisdom into a human life, and then maybe figure out how to share the wisdom with the rest of the world.

Джозеф Кэмпбелл

Возрождение или Обретение мастерства

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

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

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

Возвращение с эликсиром (история силы)

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

В нашей DevOps-истории такой историей является вклад в open source, который показывает направление движения и действительно помогает людям в работе. Мы пишем блоги, в которых рассказываем, что и как мы сделали, как другим людям найти правильный подход к улучшению рабочих процессов и как проверить, почему не работает. Примерами таких историй являются SRE от Google, модель Spotify, Netflix OSS и другие.

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

Когда мы рассказываем свою историю, очень важно помнить, что она еще не закончена. Пройдя по пути героя, мы начинаем верить в свою правоту, и в этом кроется опасность — мы перестаем развиваться и начинаем разлагаться. Настоящий DevOps-герой никогда не почивает на лаврах и напоминает Эрнесто Че Гевара, который, совершив революцию на Кубе, отправился в джунгли Конго.

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

Как сказал Антон, помочь DevOps-специалисту пройти путь героя сможет наставник, которым может быть как человек, так и книга или доклад. А со 2 по 5 декабря 2020 года JUG Ru Group проводит онлайн-конференцию DevOops 2020 Piter, где вы сможете перенять опыт коллег и улучшить процессы вокруг себя. Там же Антон представит свой новый доклад «От стресса к прогрессу: Обзор непрерывной доставки на Кубер».