Философия DevOps. Искусство управления IT

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

В январе 2013 года я попала на свою первую конференцию devopsdays (Нью-Йорк). Я впитывала как губка все разговоры и пыталась слушать как можно больше, даже если понимала, что вряд ли смогу что-либо добавить к сказанному. Я жила под воздействием хэштега #VelocityConf в Твиттере. В октябре того же года у меня было короткое выступление на второй конференции devopsdays (Нью-Йорк), на которой я встретилась с Майком Римбетси, одним из организаторов конференции. Он пригласил меня работать в Etsy, но я подумала, что он шутит, поскольку не считала себя профессионалом в этой области. Я следовала кодексу Code as Craft и придерживалась практики эксплуатационной группы Etsy в Интернете с тех пор, как открыла для себя devops-сообщества, но я не считала себя столь профессиональной, чтобы присоединиться к ним.

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

Имея опыт работы специалиста по вызову, доступного 24 часа в сутки и 7 дней в неделю большую часть года, и будучи знакомой с иными сценариями работы, далекими от идеального, я хочу поделиться с читателями книги приемами и методами, которые успешно применяются мной и членами моих групп. С помощью этих методик удалось снизить количество сотрудников, считающих себя «слабым звеном» в своей организации. В большой степени мотивация к написанию этой книги представляла собой возможность поделиться историями с читателями, историями, которые имели ко мне отношение или были рассказаны другими людьми. Это дает возможность делиться знаниями с другими пользователями, учиться и расти как сообщество. Именно devops-сообщество помогло мне занять мое нынешнее место, и эта книга представляет собой лишь один из способов возврата долга с моей стороны.

История Дженнифер

В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась «немного к разработке» и «немного к эксплуатации». Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа «ключ/значение» под названием Sherpa.

В качестве сервисного инженера в Yahoo я совершенствовала свои навыки в программировании, поддержке и в управлении проектами. Я работала вместе с группами по разработке и обеспечению качества Sherpa, координировала усилия с командами центров обработки данных, группами по поддержке сетей и хранилищ данных, а также группами обеспечения безопасности. В 2009 году, когда слухи о devops проникли в Yahoo, я знала реальную цену этой методики, поскольку фактически ею овладела!

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

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

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

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

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

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

Сбои – это ужасно, но они чему-то учат.

– Боб Саттон, инструктор из Stanford Management

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

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

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