Создание DevOps-команды

Брайан Генри

Building a DevOps Team by Brian Henerey for agilesysadmin.net

Original article: http://agilesysadmin.net/building-a-devops-team
Translated by Ivan Pesin, February 2012

Предыстория

С тех пор, как я начал работать в Sony в августе 2008-го, моя должность менялась 3 раза. Около года назад, я принял руководство командой, в которую я пришел с самого начала. И хотя это была, с любой точки зрения, разваливающаяся команда, я был очень доволен возможностью её изменить. Я знал, что оставшиеся люди были очень недовольны, и могли уйти в любую минуту, потому у меня было несколько неотложных задач:

  • Брать новых людей!
  • Удерживать тех, кто есть.
  • Брать новых людей!

Побочная история: я наткнулся на одну важную задачу, которую не перечислил. Делать заказчиков довольными. Совершенно не важно, насколько классной ваша команда может быть, если, по старой памяти, с вами никто не хочет работать. Я даже не представлял себе, до какой степени демотивированный сотрудник может испортить отношения с заказчиком, просто в силу отсутствия интереса. У меня ушли месяцы, чтобы восстановить доверие одного из заказчиков. Я где-то слышал историю о менеджере, который периодически предлагал £500 каждому своему сотруднику, который уволится. Думаю, у этого подхода есть свои слабые стороны, но идея такой отбраковки немотивированных людей соблазнительна.

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

Начало

Ещё год назад я никогда не слышал слова DevOps. Если вы в таком же положении, то есть много статей о том, что представляет собой DevOps:

И чего он не представляет:

Тем не менее, я подозреваю, что у некоторых возникнут проблемы с тем, чтобы найти действительно стоящие перлы, среди водянистой болтовни. Вот хорошее место, чтобы начать: Приступая к работе с подходом DevOps. Этот гигантский список ссылок на тему DevOps, собранный Патриком Дебуа (Patrick Debois), ясно продемонстрирует, почему не стоит пытаться прочесть всё о DevOps: devops-закладки.

Если же вы уже в курсе дела, DevOps вам нравиться и вы хотите построить команду вокруг этого принципа, то вот как это делал я.

Налаживание связей

Понимание, что же такое DevOps у меня оформилось только после того, как я начал об этом говорить с другими людьми. К счастью, в Лондоне есть очень активное сообщество DevOps, и поэтому у меня было достаточно возможностей разговаривать на эту тему. Неутомимый Гарет Рашгров (Gareth Rushgrove) проводит множество мероприятий, а The Guardian их часто принимает у себя. Я принимал участие в сессиях, где обсуждалась Continuous Integration, Deployments, Google App Engine, Load Balancers, Chef, CloudFoundry, и т. д. Я обнаружил, что люди удивительно открыто говорят о своих технологиях, процессах, культуре, трудностях и успехах.

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

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

Результат: я познакомился, а после и взял на работу, со Стивеном Нельсоном-Смиттом (Stephen Nelson-Smith) из Atalanta-Systems. (Он – автор блога agilesysadmin.net и пишет в твиттере под ником @Lordcope).

Рабочее определение DevOps

Если вы собираетесь нанимать людей, ориентированных на DevOps, неплохо иметь для себя его рабочее определение. Мне нравятся «столпы DevOps»  (Culture, Automation, Measurement, Sharing = CAMS) предложенные Джоном Уиллисом (Что означает DevOps для меня):

  • Культура
  • Автоматизация
  • Измерение
  • Обмен знаниями

Мне кажется, что SMAC был бы лучшим акронимом, но буду пользоваться устоявшимся CAMS.

Требования к DevOps-кандидатам

Хотя я и видел вакансии на DevOps, я не считаю это должностью. В своей вакансии я только упоминал, что ищу «подкованных в DevOps», а потом изменил это на «DevOps-ориентированных» или что-то в этом роде. Объявление про вакансию истекло, и я собирался его выкинуть, но Р. И. Пинар (R.I.Pinearr) у себя в твиттере назвал его «идеальным описанием работы devops». Я очень люблю последовательно уточнять описание вакансии до тех пор, пока в требованиях не остается лишь то, что мне действительно требуется, и что можно чётко оценить в процессе собеседований. Но то, как составлять описание вакансии, выходит далеко за пределы этой статьи. Вкратце, я искал людей:

  • с хорошими навыками решения проблем
  • исполнительных и энергичных
  • хорошо вписывающихся в команду (очень трудно оценить)
  • с широким набором профессиональных навыков (LAMP, Java, C++, Ruby, Python, Oracle, Scaling/Capacity, High-Availability, и т.д., и т.п.)

Моя команда работает с огромным набором технологических стеков и они постоянно изменяются. Эта работа – настоящая мечта технаря, но самыми важными навыками для неё являются навыки межличностных отношений.

Рекрутеры

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

Отбор резюме

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

Первое собеседование – удалённое техническое тестирование

Вот здесь начинается самое интересное! Я не знаю, лондонская ли это специфика, но у меня было очень много кандидатов из других стран, которые хотели присоединиться к команде. Для тех, у кого было хорошее резюме, а рекрутер ручался за хороший английский, я разработал отличный скрининг-тест, который можно было проводить удалённо. Это позволяло экономить на поездке в Лондон и проживании, а также быстро закончить разговор, если дела шли не лучшим образом. Вот как это выглядело:

  • Я выслал кандидату или рекрутеру ссылку на инстанс ec2, который я запускал минут за 20 до собеседования.
  • В инстансе был запущен веб-сервер, который содержал инструкцию для теста. Она лишь информировала, что кандидату будет нужен терминальный клиент, например Putty, если используется Windows.
  • В оговоренное время я звонил кандидату. Я объяснял, что тест состоит из двух заданий. Первое задание ориентировано на системное администрирование, и на него выделяется 20 минут. Второе задание – на программирование, и на него можно использовать всё оставшееся время. Звонок закончится через час.
  • Объясняю правила: вся работа должна быть выполнена на инстансе ec2, у кандидата есть тестовая учетная запись с паролем и root-доступ через sudo. Для выполнения задания можно пользоваться любыми ресурсами. Использование google, man-страниц, библиотек не только разрешено, но и предполагается.
  • Объясняю, что я от них хочу: они должны разговаривать со мной, рассказывая, как и о чём они думают, демонстрируя мне свой процесс решения задачи. Мне гораздо важнее этот диалог, чем смогут ли они решить какую-либо из поставленных задач.
  • Добавляю, что мы будем использовать Screen и я буду видеть всё, что они вводят.
  • Подменяю файл index.html с полными инструкциями, отмечаю время и говорю кандидату начинать.

Задачи

1) На самом деле очень простая: установить WordPress и настроить его для корректной работы. Уловка в том, что mysql мы предварительно поставили и сломали, а теперь наблюдали, как кандидаты ломали себе голову над тем, что ж такое происходит. Для опытного администратора это детские игрушки.

Как правило, мне приходилось собеседовать людей, больше ориентированных на разработку, чем администрирование. И практически сразу было понятно, насколько хорошо человек разбирается в Linux-системах. Было интересно видеть, какие предположения делали люди о самой системе (я ни разу не упоминал, что за операционная система установлена в инстансе; некоторые просто решили, что это Ubuntu). Некоторые люди читали инструкции, а некоторые – нет. В них был указан пароль для mysqladmin, но тем не менее были такие, кто искал как сбросить утерянный пароль. Один парень потратил 10 минут, пытаясь зайти по ssh на http://ec2… . Я сделал ему скидку из-за нервного напряжения, но он продолжал в том же духе и я вскоре закончил собеседование. Он жаловался на языковой барьер (он из Восточной Европы) и сказал, что если бы я только яснее выражался… Если я не могу с ним нормально общаться, то, я думаю, это весьма серьезная проблема, в независимости о того, чья это вина.

2) Мы давали немного почищенные журнальные файлы от Tomcat с реальным приложением, которое мы поддерживаем, и просили написать скрипт для разбора этого журнального файла на любом языке, который выберет кандидат. Нас интересовало, чтобы скрипт выводил вызовы методов, их число, частоту, среднее и 90-ю персентиль задержки. Предпочитаемым языком был Ruby, но кандидат был волен выбирать любой.

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

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

Результаты

Я провёл через этот процесс несколько кандидатов. Когда мы только начали формировать тест, кроме меня в разговоре принимало участие ещё несколько человек из моей команды, но это оказалось слишком затратным в плане времени и, кроме того, пугало некоторых кандидатов. Ограничение по времени первой задачи стало огромным шагом вперёд, а как только к нашей команде присоединился Стивен Нельсон-Смит, у меня появился человек, который мог оценить код на ruby лучше меня. Мы все считаем, что описанный процесс тестирования чрезвычайно хорошо демонстрирует навыки кандидатов, и я крайне его рекомендую.

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

Этап 2 – личное собеседование

Второй этап состоял из нескольких частей:

  • Неформальный разговор за кофе/обедом/ужином, длинной до часа. Я объяснял, что я ищу, кандидаты рассказывали про себя, и мы оценивали, на сколько подходим друг другу.
  • Упражнение на решение гипотетической проблемы у доски: вам звонит заказчик и говорит, что получает пустую страницу, когда заходит на http://yoursite.com. Ваши действия? Можно немного поимпровизировать с темой самой проблемы, но у неё должно быть две цели: показать подход человека к решению проблем и с архитектурами какой сложности он имел опыт работы.
  • Два часа парного программирования с любым человеком из моей команды. Обычно, это самая настоящая работа, которую нужно сделать. Это может быть cookbook для chef, или тест в cucumber, и т.п. Нам нужно выяснить, насколько комфортна тесная работа с этим человеком. Моя команда часто практикует парное программирование. Готовы ли мы работать с ним в паре день за днём?

Этап 3 – мой босс + любой член команды, которые ещё не встречался с кандидатом

  • Этот этап обычно очень свободный, хотя мой босс имеет своих собственные методы для оценки людей.

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

Отличный результат

Один из лучших людей, которых я нанял, знал не только C, Java и Linux, но и написал пример приложения на Ruby, потому что знал, что нам нужен был человек, умеющий писать на ruby. Его программа находила кратчайший маршрут между станциями лондонского метро, правда только по количеству остановок, а не времени в пути. Мне такая инициативность сказала о многом, и она полностью подтверждается с тех пор, как он присоединился к нашей команде. Жаждет новых знаний и хочет их применять. Любая проблема или задача для него «это просто». Единственная моя проблема с ним, это то, что он считает проблему решенной, как только придумает, как её решить. Это, конечно, немного шутка. На днях я ему сказал, что он объявляет задачу решённой, если твёрдо уверен, что ему потребуется ещё семь своих действий для её решения.

После найма

Что теперь? Ну, приём правильного человека – большое событие. Мы отмечали приход каждого человека, в противоположность типичным «прощальным столам», когда люди уходят. То, как я управляю командой, я ещё напишу (я надеюсь), но хочу сделать небольшой комментарий. Нанимая людей, в соответствии со своим видением, я должен буду отвечать перед ними. Всякий раз, когда я понимаю, что причиной моего решения стала «политика», я знаю, что это нужно менять.

Об авторе

Брайан Генри возглавляет Operations Engineering из Online Technology Group в Sony Computer Entertainment Europe. Его увлечения включают Devops, Tool-chains, Web Operations, Continuous Delivery и Lean thinking. Сейчас он занимается разработкой линий автоматизированных инфраструктур, с применением Ruby, Chef и AWS, запуская само-обслуживаемые, создаваемые по требованию, информационные окружения для разработки и тестирования в Sony’s Worldwide Studios.