В январе 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, поскольку мы попытались скорректировать сервис и понять, что же произошло. Мы разделились на кросс-функциональные группы в целях устранения разных компонентов проблемы: обработчики сбоев, коммуникационная группа, инструментальная группа и группы по мониторингу и очистке. Также всегда были доступны ключевые менеджеры, готовые к принятию жестких решений. Эти решения помогут сократить время простоя.
Сбои – это ужасно, но они чему-то учат.
Основной урок, вынесенный мной из этого события, заключался в признании ценности сбоя. Не нужно бояться потерпеть неудачу, просто следует извлекать уроки из провалов. Мы собирались на регулярные совещания для оперативного решения вопросов, вызванных неприятными событиями. Мы продолжали устранять проблемы как межотраслевая группа, а не как группа сервисного инжиниринга. Мы способствовали возникновению дискуссий между потребителями и поставщиками услуг, которые помогли бы в выявлении слабых мест в системе.
Потратив более десяти лет на создание рабочих практик, основанных на примитивной культуре эксплуатации, заключающейся в долгих часах ожидания, изоляции проблем и избегании сбоев системы, я так и не смогла добиться нужных изменений.
Я была готова к внедрению devops. Для меня ценность devops заключалась не в мантре «разрабатываем X и поддерживаем Y, либо разработка и поддержка», а в том, чтобы делиться историями, решать проблемы, возникающие в производстве, на основе принципов сотрудничества и укреплять ряды сообщества. Открытая среда для совместной работы превратилась в новую систему поддержки, которая укрепила основы устойчивых рабочих практик и способствовала развитию взаимоотношений между людьми.
Сотрудничество с Кэтрин при написании этой книги способствовало углублению моего понимания devops. Возможность делиться рабочими стратегиями и методиками со всего мира, которые полезны для создания и улучшения рабочих практик, превращается в захватывающее путешествие. И это путешествие не завершается после того, как прочитана последняя страница книги.
Мы все получаем опыт каждый день, поскольку имеем разные точки зрения на все, что происходит вокруг нас. Независимо от того, находитесь вы в начале карьеры, когда культурная трансформация только начинается, либо задумываетесь об изменении ролей и обязанностей, ваш опыт позволит делиться информацией и обучать других. И я с нетерпением ожидаю ваши истории, в которых я расставлю правильные акценты. Эта даст нам возможность расти как сообществу и вместе извлекать уроки из наших успехов и неудач.
Мы выбрали различные тематические исследования, чтобы проиллюстрировать разные способы проявления культуры эффективных devops-практик. Цель этих историй заключается не в предоставлении шаблонов, которым нужно точно следовать, слепо копируя структуру, используемую в другой организации, либо задействуя индивидуальные практики для всех обстоятельств и выбранных вариантов.
Рассматривайте эти истории как иллюстрации или руководства к действию. Мы надеемся, что в процессе чтения этих историй вы увидите отражение нашего опыта – возможно, нынешнего, а возможно, опыта, который будет иметь место в будущем. Мы включили истории из разных источников, как формальные тематические исследования, так и неформальные личные рассказы. Здесь вы найдете истории, относящиеся к хорошо известным организациям. Но вместе с тем мы намеренно включили истории из менее известных источников, чтобы продемонстрировать все разнообразие существующих devops-практик.
В процессе знакомства с результатами этих исследований не только учитывайте выбранные варианты и результаты этих выборов, но и принимайте во внимание возникшие обстоятельства и ситуации. Каково сходство между возникшими обстоятельствами и каковы ключевые отличия? Если вы сделали аналогичный выбор в вашей организации, какие факторы, уникальные для вашего рабочего места, могут повлиять на результат? Мы надеемся, что путем чтения и понимания этих историй вы сможете распознать лежащие в их основе темы и начать их применять в собственных devops-практиках.
Обучение не должно ограничиваться рассказанными историями. Экспериментируйте с новыми процессами, инструментами, методиками и идеями. Оцените ваш прогресс и, самое главное, поймите причины происходящего. Как только вы начнете понимать, что получается, а что нет, вы сможете перейти к более сложным экспериментам.