Создание 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.

Избыточность

Мэт Симмонз

Day 13 – Redundancy by Matt Simmons

Original article: http://sysadvent.blogspot.com/2009/12/day-13-redundancy.html
Translated by Ivan Pesin, January 2012

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

Но постойте-ка, обычно так не бывает. Что, в общем-то, забавно, потому что двигатели у самолетов отказывает постоянно. Серьезно, это случается так часто, что Федеральное авиационное агентство даже не ведет статистику отказов. Вот тут пилоты прикидывают, что отказы авиадвигателей происходят с частотой от одного раза на каждую тысячу летных часов, до одного раза на каждые десять тысяч часов. Вроде как нечасто. Но так кажется до тех пор, пока вы не примете во внимание, что в любой день, в воздухе над США выполняется около 30 000 коммерческих рейсов. Тем не менее, каждый день, вы просыпаетесь, ходите на работу, читаете новости и не слышите страшных историй про падающие с небес самолеты, хотя есть все шансы, что где-то в этот день у самолета отказал двигатель. Мало того, если вы много летаете, то вполне возможно, что такое случалось и с самолетом на котором вы летели. Только вы про это не узнаете, никто не обязан вам о таком рассказывать.

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

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

Если бы двигатели переставали работать раз в сто полетов (цифра с потолка и сильно завышенная) и на самолете был только один двигатель, то, понятно, один раз из ста полетов он бы отказывал. К сожалению, этот полет был бы очень захватывающим, не в лучшем значении этого слова, для пассажиров. А вот уже при двух установленных двигателях, хотя отказы двигателей происходили бы каждые 50 полетов, в среднем только один из 10 000 полетов, заканчивался бы трагически. Именно поэтому, большие и тяжелые самолеты, которым для полета требуются два работающих двигателя, имеют целых четыре. Это еще больше уменьшает вероятность возникновения настоящих проблем. Но, как я уже говорил, рейсов-то очень много и, в конце-концов, статистика берет свое. Если вы посмотрите эту ссылку, то узнаете, что в одном из рейсов над Индийским океаном произошло целых пять отказов двигателей. И тем не менее, этот рейс успешно приземлился, благодаря разным бортовым системам безопасности.

Мы, в IT, можем многому поучится у авиационной отрасли. Это одна из немногих областей, где требования к безотказной работе выше, чем у нас. Кроме того, они в деле-то подольше нашего будут. За время своего существования, они кое-чему научились, в том числе тому, что у вас должен быть порядочный запас прочности (читай: избыточность), если вы хотите, чтобы ваш сервис имел действительно высокую доступность.

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

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

Сами дата-центры предоставляют питание от двух отдельных электросистем, каждая со своими аккумуляторными батареями и генераторами. Высококачественные дата-центры для обеспечения надежности используют схемы N+1 и N+2. Это означает, что на каждые N единиц оборудования, необходимого для нормальной работы, у них есть одна (или две) запасная. Самолеты с 2-мя двигателями используют схему N+1, с 4-мя двигателями — N+2.

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

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

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

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

Подключение серверов в локальной сети одним кабелем очень рискованно. Всегда есть риск зацепить и выдернуть провода. Сетевые карты сбоят, а порты на свичах умирают. Сервер станет недоступен в любом из таких случаев. Чтобы избежать возникновения подобных проблем, современные сервера выпускаются с двумя встроенными сетевыми картами. Раньше я не понимал зачем, но потом узнал об объединении интерфейсов (interface bonding).

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

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

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

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

Но даже кластер серверов не поможет в случае катастрофического происшествия.

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

К счастью, обезопасить себя от этого можно. К несчастью, это непросто и недешево.

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

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

Дополнительное чтение:

Сисадминская притча: официантка и стакан воды

Том Лимончелли

A SYSTEM ADMINISTRATION PARABLE: THE WAITRESS AND THE WATER GLASS
by Tom Limoncelli

Original article: http://www.usenix.org/publications/login/2010-10/openpdfs/limoncelli.pdf
Translated by Ivan Pesin, December 2011

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

Стояло лето 2008 года, точнее июль. Так случилось, что три вечера подряд я ужинал в трех разных ресторанах. В каждом из них по-разному решали вопрос с пополнением моего стакана воды и это привлекло мое внимание.

Режим «по прерыванию»
Пакетный режим с прерываниями
Режим делегирования
Организация работы
Задавайте вопросы
Аварийные ситуации
Варианты пакетных режимов
Делегирование и специализация
Автоматизация
О чем стоит подумать
Ссылки

Режим «по прерыванию»

Во вторник вечером я ужинал в Friendly’s. Если вы не знаете, Friendly’s — это сеть ресторанов средней категории, нацеленная на семьи с детьми. Три таких ресторана находятся недалеко от места, где я живу в Нью-Джерси. Обычно, там работают ученики старших классов и, скорее всего, это их первая работа.

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

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

Результат:

  • Лучший вариант: официантка была доступна немедленно и мы быстро получали воду.
  • Худший вариант: мы ждали 5–10 минут, пока она к нам подойдет, после чего получали воду быстро. Но пока она наполняла наши стаканы, мы были без воды, которая еще в них оставалась.
  • В общем: так себе.

Пакетный режим с прерываниями

В среду я ужинал в модном ресторанчике, который находится в Нью-Йоркском районе Адская кухня. Название района отражает дурную славу, которую он имел до конца 80-х годов прошлого века. Позднее он был облагорожен и сейчас там располагается множество отличных ресторанов. Культура работы официантов в Нью-Йорке имеет очень высокие стандарты. Эти люди усердно работают, мало получают и живут в местах, где стоимость жизни очень высока. Чаевые в этом городе начинаются с 20% совсем неспроста. С тех пор как я начал работать в Нью-Йоркском офисе Гугл, я нашел тут много отличных ресторанов.

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

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

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

Результат:

  • Лучший вариант: вода доливалась без просьбы.
  • Худший вариант: также, как и в Friendly’s, но стаканы всегда были у нас на столе и меньше нужно было мыть посуды.
  • В общем: иногда мы ждали, но обычно все было без задержек и напоминаний. В целом, очень хорошо.

Режим делегирования

Вечер четверга я провел за ужином в Skylight Diner, расположенном в Нью-Йоркском районе Клинтон. Skylight — это греческая закусочная. Есть несколько вещей, которые нужно знать о греческих закусочных, типичных для Нью-Йорка и Нью-Джерси. Во-первых, они называются «греческими» не потому, что там подается греческая кухня, а потому, что их владельцы обычно греческого происхождения. Нью-Йорк — это город иммигрантов и это одна из тех особенностей, которые делают его таким замечательным. Во-вторых, меню в этих заведениях огромные: страница за страницей следуют блюда от гамбургеров и пасты до морепродуктов и соте. В некоторых даже есть греческие блюда. В-третьих, блюда обычно отличные, а порции — поразительно большие. Наконец, если вы слышите «закусочная» и представляете страшненький фастфуд, вы ошибаетесь на 100%. Чтобы искупить свою ошибку, сходите в такую закусочную, когда голодны. Очень голодны.

Официантки в Skylight никогда не пополняли наши стаканы с водой, это была обязанность их помощников — басбоев. Они постоянно обходили столы, забирая пустые тарелки и наполняя наши стаканы водой. Если стакан с водой у кого-то все-таки пустел и он обращался к официантке, то она подзывала ближайшего басбоя и говорила: «Más agua aquí».

Это сила делегирования или, можно сказать, автоматизации.

Результат:

  • Лучший вариант: вода доливалась без просьбы.
  • Худший вариант: вода доливалась, сразу после просьбы.
  • В общем: практически всегда был лучший вариант.

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

Результат:

  • Лучший вариант: вода доливалась по необходимости.
  • Худший вариант: ждать, пока нальют новый графин с водой.
  • В общем: обычно как в лучшем варианте.

Организация работы

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

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

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

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

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

Когда нас отрывают с какой-то новой задачей, то вместо того, чтобы сразу хвататься за нее, надо взвесить имеющиеся варианты. Выслушайте запрос. Пауза. А теперь подумайте, что лучше с ним сделать: записать, делегировать или сделать?

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

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

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

Задавайте вопросы

Раньше я считал, что все запросы срочные. Теперь я всегда спрашиваю «когда вам это нужно будет?». Удивительно, как много запросов, которые звучат неотложными, оказываются не такими и срочными, если только об этом спросить. «Да я на днях лечу в Бостон, сможешь это сделать до моего возвращения?» или «Он выходит на работу 18-го октября, нужно сделать до этого момента».

Поразительно, как часто мы забываем задать этот вопрос.

Возможность записывать задачи зависит от наличия места, где их можно записать. Один из способов — это список задач в ежедневнике (мои рекомендации приведены в [1]). Однако, в дополнение, очень важно иметь систему отслеживания запросов, которая позволяет пользователям ставить задачи не отрывая вас от текущих задач. Существует множество типов таких систем автоматизации службы поддержки или отслеживания запросов. Они бывают как с открытым исходным кодом, такие как Request Tracker [2] и OTRS [3], так и платные.

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

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

Аварийные ситуации

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

Любой шеф-повар должен иметь в своем распоряжении инструменты для своей работы: плиту, кастрюли и сковородки. Так же и системный администратор должен иметь свои инструменты — систему учета запросов и утвержденное определение аварийной ситуации.

Варианты пакетных режимов

Свою работу в пакетном режиме можно организовывать по-разному.

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

Можно собирать пакет задач по местонахождению: отобрать все запросы, требующего физического посещения здания №47 и сделать из все за один визит.

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

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

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

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

Делегирование и специализация

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

Специализация становится возможной только с ростом компании. Как правило, отдел ИТ в маленькой фирме начинается с одного человека, отвечающего за всё.

Спустя некоторое время нанимается другой специалист и, теперь, они вдвоем несут на себе всю тяжесть ИТ. Переместимся на несколько лет вперед и мы обнаружим ИТ-отдел из 10 человек, которые пытаются отвечать за всё. Когда же они должны начать специализироваться? Вероятно, после второго или третьего человека принятого в команду. Это сильно зависит от организации, поскольку в разных организациях требуется разная специализация. Обычно люди специализируются в областях, где нужны специфические знания. Если есть потребность в большом, постоянно растущем хранилище данных, некоторые люди могут специализироваться на хранилищах. Даже в маленьких командах есть человек, который лучше всех разбирается в сетях и отвечает за Интернет-шлюз с фаерволом.

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

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

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

Автоматизация

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

Сперва можно автоматизировать процесс так, чтобы системный администратор мог легко активировать или дезактивировать доступ для одного пользователя. Такой инструмент освободит время администратора для других задач. Следующим шагом должно стать создание функции самообслуживания: веб-страница, где пользователь может запросить доступ одним кликом. Этот запрос должен быть одобрен ответственным администратором, после чего система сама автоматически выполнит необходимые действия по активации доступа. Некоторые люди могут быть предварительно одобрены, например, пользователи в LDAP-группе «Engineers». Или же только люди из LDAP-группы «Visitors» требуют ручного одобрения администратором. Теперь у вас есть инструмент, который не только освобождает ваше время, но и позволяет пользователям самим решить свою задачу.

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

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

Какие из них используете вы?

О чем стоит подумать

  1. В каком режиме вы работали последнюю неделю: по прерыванию, пакетном, делегирования, автоматизации или писали системы самообслуживания?
  2. Какие три задачи на работе вы можете выполнять в пакетном режиме?
  3. Когда кто-то делает запрос, как вы определяете насколько он срочен?
  4. Какие есть специализации в вашей команде? Являются ли они официально признанными?
  5. Как бы вы реорганизовали то, как делаете свою работу? Какое влияние это окажет на вас? На ваших пользователей?
  6. Как бы вы реорганизовали работу своей команды или ИТ-отдела? Что в результате станет лучше, а что хуже для вас и ваших пользователей?
  7. Отвечая на вопросы 5 и 6 вы предложили много изменений. Какие из них будут иметь наибольшее влияние? А какие сулят наиболее быстрый результат?

Ссылки

[1] Thomas A. Limoncelli, Time Management for System Administrators (O’Reilly Media, 2005).
[2] RT: Request Tracker: http://www.bestpractical.com
[3] OTRS: http://www.otrs.org