История Дженнифер
В 2007 году я связалась с руководством Yahoo по поводу позиции, которая относилась "немного к разработке" и "немного к эксплуатации". Речь шла о вакансии старшего сервисного инженера, ответственного за создание и обслуживание мультиарендованного, размещенного на хосте, распределенного и географически реплицированного хранилища данных типа "ключ/значение" под названием Sherpa.
В качестве сервисного инженера в Yahoo я совершенствовала свои навыки в программировании, поддержке и в управлении проектами. Я работала вместе с группами по разработке и обеспечению качества Sherpa, координировала усилия с командами центров обработки данных, группами по поддержке сетей и хранилищ данных, а также группами обеспечения безопасности. В 2009 году, когда слухи о devops проникли в Yahoo, я знала реальную цену этой методики, поскольку фактически ею овладела!
Летом 2011 года Джефф Парк принял на себя бразды правления моей группой. Он помог взрастить группу профессионалов, благодаря чему у нас появилось несколько сервисных инженеров в США и в Индии. Этого было недостаточно, и Джефф беспокоился о том, что мне приходилось работать в непрерывном режиме, практически в одиночестве оказывая сервисные услуги. Он также проявлял беспокойство по поводу бизнеса и хотел добавить больше отказоустойчивости в модель эксплуатации путем найма избыточного персонала. В декабре этого же года он посоветовал мне взять настоящий отпуск, не читать электронную почту и отключить мобильный телефон.
В ответ я заявила ему, что чувствую, как будто бы что-то происходит неправильно, что-то работает не так, как ожидалось. Он сказал, что просто уволит меня, если я не уйду в отпуск. При этом он заверил меня, что все будет хорошо. И вечером накануне отпуска я настроила простую визуализацию соответствующих метрик с помощью сценария JavaScript и Perl, управляемого с помощью cron. Я посчитала, что этого будет достаточно, поскольку в случае возникновения каких-либо проблем отображались соответствующие уведомления.
После возвращения из отпуска я столкнулась с полной деградацией сервиса. Множество мелких проблем, с которыми я встречалась ранее, вылились в неприятный результат. Причем отладка была в значительной степени затруднена именно по причине большого количества этих проблем. Я столкнулась с полным провалом, несмотря на то что наспех состряпанная визуализация позволяла выявлять и отслеживать возникающие проблемы.
Джефф отвел меня в сторонку и заявил о том, что знал о существовании высокого риска возникновения сбоев во время моего отпуска. Также имели место дополнительные риски, связанные с тем, что моя группа полностью полагалась на меня. Мой героизм на работе помогал маскировать сбои, присущие системе.
Он сказал, что иногда неудачи, имеющие место в краткосрочной перспективе, превращаются в достоинства (в долгосрочной перспективе), если делать верные выводы. Если что-то выходит из строя, это поможет установить приоритет критичности для процессов общего доступа, документирования и распространения знаний и опыта в бизнесе. В конечном счете это приведет к достижению большей стабильности и улучшению показателей как для организации в целом, так и для отдельных сотрудников.
Это событие сплотило эксплуатационную группу Sherpa, поскольку мы попытались скорректировать сервис и понять, что же произошло. Мы разделились на кросс-функциональные группы в целях устранения разных компонентов проблемы: обработчики сбоев, коммуникационная группа, инструментальная группа и группы по мониторингу и очистке. Также всегда были доступны ключевые менеджеры, готовые к принятию жестких решений. Эти решения помогут сократить время простоя.
Сбои – это ужасно, но они чему-то учат.
– Боб Саттон, инструктор из Stanford Management
Основной урок, вынесенный мной из этого события, заключался в признании ценности сбоя. Не нужно бояться потерпеть неудачу, просто следует извлекать уроки из провалов. Мы собирались на регулярные совещания для оперативного решения вопросов, вызванных неприятными событиями. Мы продолжали устранять проблемы как межотраслевая группа, а не как группа сервисного инжиниринга. Мы способствовали возникновению дискуссий между потребителями и поставщиками услуг, которые помогли бы в выявлении слабых мест в системе.
Потратив более десяти лет на создание рабочих практик, основанных на примитивной культуре эксплуатации, заключающейся в долгих часах ожидания, изоляции проблем и избегании сбоев системы, я так и не смогла добиться нужных изменений.
Я была готова к внедрению devops. Для меня ценность devops заключалась не в мантре "разрабатываем X и поддерживаем Y, либо разработка и поддержка", а в том, чтобы делиться историями, решать проблемы, возникающие в производстве, на основе принципов сотрудничества и укреплять ряды сообщества. Открытая среда для совместной работы превратилась в новую систему поддержки, которая укрепила основы устойчивых рабочих практик и способствовала развитию взаимоотношений между людьми.
Сотрудничество с Кэтрин при написании этой книги способствовало углублению моего понимания devops. Возможность делиться рабочими стратегиями и методиками со всего мира, которые полезны для создания и улучшения рабочих практик, превращается в захватывающее путешествие. И это путешествие не завершается после того, как прочитана последняя страница книги.
Мы все получаем опыт каждый день, поскольку имеем разные точки зрения на все, что происходит вокруг нас. Независимо от того, находитесь вы в начале карьеры, когда культурная трансформация только начинается, либо задумываетесь об изменении ролей и обязанностей, ваш опыт позволит делиться информацией и обучать других. И я с нетерпением ожидаю ваши истории, в которых я расставлю правильные акценты. Эта даст нам возможность расти как сообществу и вместе извлекать уроки из наших успехов и неудач.
Истории, иллюстрирующие devops-практики
Мы выбрали различные тематические исследования, чтобы проиллюстрировать разные способы проявления культуры эффективных devops-практик. Цель этих историй заключается не в предоставлении шаблонов, которым нужно точно следовать, слепо копируя структуру, используемую в другой организации, либо задействуя индивидуальные практики для всех обстоятельств и выбранных вариантов.
Рассматривайте эти истории как иллюстрации или руководства к действию. Мы надеемся, что в процессе чтения этих историй вы увидите отражение нашего опыта – возможно, нынешнего, а возможно, опыта, который будет иметь место в будущем. Мы включили истории из разных источников, как формальные тематические исследования, так и неформальные личные рассказы. Здесь вы найдете истории, относящиеся к хорошо известным организациям. Но вместе с тем мы намеренно включили истории из менее известных источников, чтобы продемонстрировать все разнообразие существующих devops-практик.
В процессе знакомства с результатами этих исследований не только учитывайте выбранные варианты и результаты этих выборов, но и принимайте во внимание возникшие обстоятельства и ситуации. Каково сходство между возникшими обстоятельствами и каковы ключевые отличия? Если вы сделали аналогичный выбор в вашей организации, какие факторы, уникальные для вашего рабочего места, могут повлиять на результат? Мы надеемся, что путем чтения и понимания этих историй вы сможете распознать лежащие в их основе темы и начать их применять в собственных devops-практиках.
Обучение не должно ограничиваться рассказанными историями. Экспериментируйте с новыми процессами, инструментами, методиками и идеями. Оцените ваш прогресс и, самое главное, поймите причины происходящего. Как только вы начнете понимать, что получается, а что нет, вы сможете перейти к более сложным экспериментам.
Глава 2. Определение devops
Devops – это культурное движение, изменяющее отношение людей к работе и к ее результатам. Благодаря внедрению devops в организации формируются интенциональные процессы, ускоряющие эффективность бизнеса. Это способствует скорейшему появлению результата от социальных и технических нововведений. Благодаря новым способам мышления и работы отдельные сотрудники и организации могут развивать и поддерживать устойчивые рабочие практики. Devops представляет собой культурный субстрат, ускоряющий формирование эмпатии между коллегами и облегчающий обмен опытом. В результате закладывается прочный фундамент, обеспечивающий эффективное приложение усилий в процессе работы со стороны отдельных сотрудников и команд.
Рецепт формирования культуры
Devops является необходимым условием для формирования культуры, но не достаточным. Ни одно культурное движение в мире не существует само по себе, поскольку культура неразрывно связана с социальной структурой. На культуру оказывают влияние много факторов. Это иерархические структуры, сформированные внутри организаций, связи между организациями и эффекты, вызванные глобализацией. Также на формирование культуры воздействуют ценности, нормы, убеждения и артефакты, связанные с упомянутыми выше факторами. Например, программное обеспечение варьируется в зависимости от того, кто его разрабатывает и использует. Благодаря devops появились способы адаптации и совершенствования социальной структуры, культуры и технологии, что, в свою очередь, способствует более эффективной работе.
Уравнение devops
Существует опасность, что движение, которое расценивает себя как новое, будет пытаться охватывать все, что не является старым.
– Ли Рой Бич и др., Naturalistic Decision Making and Related Research Lines
Не относитесь к этой книге как к сборнику рецептов, позволяющих реализовать единственно верный путь применения devops. Несмотря на то что мы будем упоминать часто используемые неверные представления и "антишаблоны", мы больше заинтересованы в описании внешних признаков и принципов внедрения успешной devops-культуры, а также способов применения этих принципов в разных организациях и средах.
Хотя термин devops образован на основе слов "development" (разработка) и "operations" (эксплуатация), принципы devops могут и должны применяться на всех стадиях рабочего процесса, реализуемого в организации. Устойчивый и успешный бизнес представляет собой нечто большее, чем совокупность, состоящую из команд разработчиков и эксплуатации. Если же вы будете ограничиваться исключительно этими командами, вы окажете бизнесу, налаженному в вашей организации, "медвежью услугу".
Использование "devops" в качестве народной модели
В наши дни термин "devops" стал общеупотребительным и приобрел статус народной модели. Это обстоятельство может привести к определенному недопониманию и вызвать недоразумения. В когнитивистике под народной моделью понимают некую абстракцию, на основе которой формируются более конкретные идеи. В силу своей простоты народная модель используется в качестве замены обсуждаемых концепций. В качестве примера подобной модели может служить ситуационная осведомленность, которая заменяет более конкретные понятия, такие как восприятие и кратковременная память. Но не используйте народную модель в качестве неадекватной замены исходного понятия. Как правило, эти модели становятся непригодными в тех случаях, когда применяются не по назначению.
Люди зачастую тратят много времени на споры о природе "devops". Они также обсуждают народные модели вместо того, чтобы сосредоточиться на идеях, представляющих собой реальную ценность. Порой для обхода проблем, вызываемых попытками точного определения devops, и стимулирования обсуждения соответствующих концепций и принципов преувеличивается значимость "плохого" поведения. Это делается для того, чтобы сконцентрироваться на "хорошем" поведении, которое подается в качестве "devops". Чтобы перейти к обсуждению эффективного сотрудничества в команде, можно воспользоваться примером фиктивной компании, в которой создана devops-команда. Эта команда выступает исключительно в качестве посредника между командами разработчиков и техподдержки (см. предисловие). Этот пример является в какой-то мере искусственным, но зато иллюстрирует более серьезные и практические концепции, чем обычные определения.
Прежний и новый взгляд
Если в компании складывается практика взаимных обвинений и преследований за совершенные ошибки, формируется атмосфера страха. В результате между сотрудниками компании появятся "стены", препятствующие общению. А теперь представьте себе идеальную среду, в которой все проблемы решаются сообща и расцениваются в качестве возможности для обучения как отдельных людей, так и организации в целом. Профессор Сидни Деккер в своей книге Field Guide to Understanding Human Error характеризует эти ситуации как "прежний взгляд" и "новый взгляд" на человеческие ошибки.
В первом случае "человеческие ошибки являются причиной появления проблем". "Прежний взгляд" описывается как способ мышления, в котором основной акцент делается на устранение человеческих ошибок. Ошибки вызываются "гнилыми яблоками", которые нужно выкинуть. Этот взгляд доминирует в культурах, основанных на взаимных обвинениях, поскольку предполагается, что ошибки часто порождаются злым умыслом или некомпетентностью. Люди, ответственные за ошибки, должны быть обвинены и пристыжены (либо просто уволены).
Во второй среде "человеческие ошибки рассматриваются в качестве симптома более глубоких системных проблем". Этот "новый взгляд" соответствует образу мышления, в котором человеческие ошибки рассматриваются как следствие проблем, имеющих структурный, а не личный характер. Люди делают выбор и выполняют действия на основе собственного понимания ситуации. Они не совершают ошибки в силу злых намерений или некомпетентности. Чтобы минимизировать последствия ошибок или ответить на возникшие вопросы, нужно применять системный подход на уровне организации.
"Новый взгляд" является ключом к пониманию движения devops. Этот взгляд поощряет нас делиться опытом, который представляет собой прекрасную возможность для обучения сотрудников.
Если вы поделитесь опытом применения devops, то это:
• приведет к увеличению степени прозрачности и доверия в группе;
• поможет вашим коллегам понять, как избежать ошибок, чреватых серьезными потерями;
• предоставит больше времени на решение новых задач, благодаря чему появятся дополнительные инновации.
Как только истории об опыте применения devops станут всеобщим достоянием, они окажут влияние на отрасль в целом. В результате появятся новые возможности и знания, а также станет возможным обмен знаниями.
Devops-пакт
Подлинный devops-пакт имеет место только тогда, когда люди не просто работают вместе в одной группе, а формируют единую команду. Если участники команды постоянно сообщают друг другу о своих намерениях и возникающих проблемах и постоянно подстраиваются с учетом общих целей организации, формируется так называемый devops-пакт.
Пример пакта
Чтобы представить себе критически важный пакт, рассмотрим общение между двумя скалолазами, которое заключается в обмене информацией, уточнении спорных моментов и формировании взаимного доверия. Суть скалолазания заключается в перемещении по скалам и искусственным сооружениям в разных направлениях. Скалолазу нужно достичь верхней или конечной точки маршрута и не сорваться при этом. Для достижения этой цели понадобится как физическая выносливость, требуемая для решения возникающих проблем, так и умственная активность, необходимая для понимания сути проблемы и подготовки к выполнению следующих действий.
Обычно в процессе скалолазания скалолаз, выполняющий восхождение (восходитель), использует трос и карабин для страховки от возможного падения. Напарник восходителя контролирует степень натяжения троса. Он должен натягивать его достаточно сильно во избежание падения, но в то же время давать слабину, необходимую для обеспечения свободы маневра.
Обеспечение правильной и безопасной страховки требует от страхующего напарника как понимания используемых инструментов и процессов, так и обеспечения постоянной связи со скалолазом, выполняющим восхождение. Восходитель должен надежно прикрепить страховочный трос к карабину. Страхующему напарнику нужно убедиться в том, что страховочное устройство надежно закреплено с помощью карабина. Между скалолазами устанавливаются доверительные отношения, но прежде чем приступать к восхождению, нужно еще раз все проверить.
При восхождении используется набор словесных ключей, позволяющих проверить готовность к процессу восхождения. Сначала восходитель спрашивает у напарника: "На страховке?" Напарник отвечает: "На страховке". Затем восходитель говорит: "Подъем!", сигнализируя о готовности к началу восхождения. И наконец, напарник подтверждает осведомленность о готовности восходителя, произнося слово "подъем".
Для обеспечения работоспособности этого пакта применяются следующие принципы:
• общие четко сформулированные цели;
• непрерывное общение;
• динамическая настройка и коррекция понимания.
Как будет показано в следующих разделах, соблюдение этих принципов необходимо как для внедрения devops на рабочем месте, так и для успешного восхождения на горную вершину.
Пример devops-пакта
Представьте себе, что два сотрудника компании Sparkle Corp работают в разных командах. Сотрудник по имени Дженераль является старшим разработчиком, обладает множеством рабочих навыков и работает в компании Sparkle Corp уже два года. Джордж работает в отделе техподдержки, обладает некоторыми рабочими навыками и является новичком в компании Sparkle Corp.
Команды, в которых работают эти два сотрудника, поддерживают глобальное сообщество людей, использующих сайт компании Sparkle Corp для реализации своих творческих начинаний. Общая цель, стоящая перед этими командами, заключается во внедрении нового средства, которое увеличивает ценность сайта компании для конечных пользователей, не оказывая на него негативного влияния.
Обладая большим опытом работы в компании, Дженераль дает четкие указания Джорджу об ожиданиях, ценностях и процессах, имеющих место в компании Sparkle Corp. В свою очередь Джордж может в любой момент обратиться к Дженераль с просьбой о помощи или в случае непонимания какого-либо производственного нюанса. Прежде чем перейти к следующему этапу производственного процесса, Дженераль и Джордж контролируют результаты работы друг друга. Подобная проверка является примером модели "доверяй, но проверяй", используемой при описании процесса скалолазания.