Философия DevOps. Искусство управления IT Дэвис Дженнифер
К тому же затраты на поддержание платформы AWS намного меньше, чем затраты на поддержку CDN (большие затраты связаны с большим объемом видеоданных, передаваемых каждый месяц) и зарплаты инженеров. Небольшая оптимизация расходов в случае перехода к другому провайдеру нивелируется резким ростом трудозатрат со стороны инженерного персонала.
При рассмотрении существующих технологий, используемых в процессах выбора инструментов, задайте себе следующие вопросы.
• Какие средства абсолютно необходимы, а какие – желательны?
• Какие решения доступны прямо сейчас, а какие могут стать доступными в ближайшее время?
• Каким образом затраты на внедрение необходимых вам средств соотносятся с затратами на внедрение доступных средств?
Непрерывное влияние новых технологий
По мере развития технологий и появления новых инструментов в экосистеме могут возникать затруднения в процессе принятия решений в пользу того или иного инструмента. В случае небольшой компании, выполняющей большие объемы незапланированных работ и имеющей постоянные технические долги, важно в первую очередь реализовывать наиболее важные проекты.
Гросс описал несколько проблем, с которыми столкнулась его команда в октябре 2013 года.
• Как правило, Django применялось для выполнения медленного неатомического развертывания со сложными сбоями. Приложение Django являлось одним из важнейших приложений пути запроса, которое имело серьезные требования к доступности и времени ожидания. Из-за использования клона git замедлялось развертывание, к тому же в процессе развертывания периодически случались сбои.
• Увеличение степени сложности развертывания. Новые приложения Go не могут быть развернуты при использовании существующих процессов. Для двоичных модулей и интерпретированного исходного кода имели место разные требования к поставке.
• Раздельное тестирование качества и процессов развертывания производства без каких-либо возможностей аудита.
• Различные среды разработки и непрерывной интеграции.
Гросс также описал дополнительные цели, которые преследовала его команда:
• переход от монолитного приложения к меньшим по размерам микросервисам;
• изоляция разных версий приложения на одном хосте в средах разработки и контроля качества.
Как говорит Гросс:
Эксплуатационная команда (состоящая из двух человек на то время) оценила несколько вариантов, основываясь на разных преимуществах, таких как подгонка процесса решения проблем, наш опыт работы с языком реализации, известные виды отказов и т. п. В результате был выбран Docker. Этот выбор был основан на перспективах использования обобщенного интерфейса развертывания, который позволил бы решить все проблемы.
Большой риск заключался в том, что в те времена Docker был весьма сырым проектом (в октябре 2013 года, версия 0.6). К тому же мы не развертывали в производственной среде проекты, не подготовленные к использованию в производстве. Мы знали, что в случае возникновения каких-либо проблем можем всегда вернуться к более зрелой базовой LXC-системе. Эту ситуацию мы изложили руководству команды разработчиков, чтобы получить «добро» на продолжение работы.
После выполнения испытаний в среде разработки/контроля качества мы развернули Docker для производства основного приложения Django. Только после завершения тестирования мы можем перейти к контейнеризации остальных приложений.
Как и в случае с любым другим внедрением технологии, возникают дополнительные проблемы, которые должны быть разрешены. Зачастую интеграция результатов работы в среде непрерывной интеграции (CI) осуществляется с помощью автоматизации. Каждое действие по интеграции верифицируется с помощью автоматизированного процесса, который создает и тестирует обязательный код. В результате ускоряется обнаружение ошибок. Как правило, это достигается путем развертывания среды и тестирования кода с последующим разрушением среды.
В среде CI часто возникали проблемы, связанные с дисками. Зачастую причина появления этих проблем заключалась в повышенной вибрации. Для устранения этой проблемы был заменен драйвер хранилища Docker (эта задача довольно сложная). Также возникали проблемы, связанные с масштабированием реестра Docker. Чтобы устранить технологические проблемы, связанные с реестром, выполнялось развертывание локального реестра хоста, при поддержке AWS S3 (вместо использования центрального сервера).
Третья проблемная область появилась после развертывания Docker в локальной среде разработки. По этому поводу Гросс сказал:
В случае выбора платформы AWS эксплуатация осуществлялась без особых проблем. Но мне не удалось найти хорошее решение, пригодное для выполнения Docker на локальной платформе. К тому же команда разработчиков была очень занята внедрением новых средств и не могла выделить время на изучение новой технологии. Когда мы развернули boot2docker в качестве варианта локальной среды разработки, у нас возникла серьезная «дыра» в обучении, которая сохранялась дольше, чем мы бы хотели, и привела к появлению серьезных внутренних трений. Это был хороший урок для нас, суть которого заключалась в том, что новые изменения должны вноситься в инфраструктуру при более непосредственном участии со стороны команды разработчиков.
Процесс тщательного отбора и оценки имеет значение как для новой, так и для существующей технологии. В случае новой технологии (новой вообще или новой для вашей организации) задайте себе следующие вопросы:
• Каковы известные риски новой технологии?
• С какими неизвестными моментами вы можете столкнуться?
• Какие проблемы невозможно решить в рамках существующей технологии?
Расширенное внедрение практик формирования близости
Безупречный постмортем (https://codeascraft.com/2012/05/22/blameless-postmortems/) с целью формирования культуры непрерывного улучшения.
– @0x74696d at @dramafever
Мне очень приятно, когда @0x74696d ссылается на @codeascraft в дискуссии, посвященной трактовке сбоев со стороны @dramafever. Спасибо за помощь в обучении, Etsy!
– Bridget Kromhout (@bridgetkromhout)
Эти твиты, написанные в феврале 2015 года, иллюстрируют нарастающую тенденцию формирования близости между компаниями, достигаемую посредством обмена знаниями. Кромхаут заявила, что DramaFever адаптировала безупречные постмортемы для использования техническими командами.
В DramaFever также поощряется самообучающаяся организация с помощью обзора кода. Помимо проверки кода Кромхаут описала культурные проблемы, вызванные быстрым ростом и необходимостью в коррекции понимания между командами. При этом используется метод «улучшенной координации за счет прояснения ожиданий о взаимодействии сервисов. Это позволяет небольшим группам разработчиков преследовать свои собственные идеи, сохраняя при этом стандарты организации на высоком уровне».
В DramaFever поощряется прозрачность. Как говорит Кромхаут, «прямо сейчас разработчики получают полный доступ к сервисам AWS в среде разработки. Мы также активизировали IAM-доступ в режиме чтения». Благодаря подобной прозрачности сотрудники могут учиться и наблюдать непосредственно из среды разработки, которая реплицирует производство и ответы на вопросы об использовании производства в реальном мире по мере их возникновения.
Поскольку DramaFever эксклюзивно использует технологию AWS, не требуется центр обработки данных. Также отсутствуют требования к сотрудникам по поводу явного присутствия в специфической среде. Команда DramaFever, насчитывающая примерно 120 человек, в основном находится в Филадельфии и в Нью-Йорке, а некоторые сотрудники трудятся в других местах. В процессе описания среды Кромхаут сказала следующее: «Наши сотрудники находятся поблизости, в Мэриленде, или очень далеко, в Сеуле, и все они должны без помех выполнять одну и ту же работу».
Чтобы еще больше облегчить работу удаленных сотрудников, в конференц-залах DramaFever установлены компактные компьютеры Chromebox. На основе такого компьютера реализуется бизнес-система организации видеоконференций. Используется операционная система Chrome OS, камера с высоким разрешением, внешние микрофоны и колонки. По умолчанию совещания проводятся в режиме виртуального присутствия, реализованного с помощью Google Hangouts, благодаря чему не требуется физическое присутствие в офисе.
Обратите внимание на то, каким образом инструменты и методы работы взаимодействуют между собой внутри вашей организации и команд.
• Каковы ценности, исповедуемые в вашей команде или организации?
• Помогают ли инструменты реализовать эти ценности на практике или только мешают этому процессу?
• Насколько прозрачно взаимодействуют между собой ценности и процессы?
Порядок выбора инструментов в DramaFever
Из-за бюджетных ограничений, имеющих место при работе в небольшой компании и дополнительных затрат, связанных с бюрократическим характером процесса, в DramaFever осторожно относятся к процессу выбора инструмента. Обычно выбираются инструменты с открытым исходным кодом.
Кромхаут описала процесс выбора инструмента, начиная с «предполагаемой функции или результата, с последующей оценкой потенциальных инструментов на основе степени удовлетворения текущих нужд. В первую очередь учитываются потребности человека, выбирающего и внедряющего инструмент, но также учитывается набор стандартов обслуживания, которым должен удовлетворять выбранный инструмент».
Беседа, проводимая при внедрении новой технологии, посвящена рассмотрению соответствующего определения. На основе этого определения можно судить, будут ли работать существующие решения, почему новая технология может оказаться более подходящей. Также нужно рассчитать дополнительную рабочую нагрузку на имеющийся персонал.
Согласно объяснению, приведенному Кромхаут,
при выборе между своим собственным сервисом и SaaS[49] оцениваются соответствующие расходы и преимущества, включая затраты, связанные с выполнением дополнительных работ (как затраты времени персонала, так и финансовые).
Например, при рассмотрении порядка обработки логов мы подсчитали текущий объем логов, учли желательный объем и сравнили стоимость поддержки логов с помощью ELK со стоимостью передачи логов независимым провайдерам услуг. Мы перечислили действия, выполняемые по отношению к логам. После получения квот и учета количества времени, выделенного на поддержку ELK, мы сделали выбор в пользу ELK.
Персонал DramaFever стремится к устранению времени простоя даже из процедуры регулярного технического обслуживания. Степень успеха в этом деле оценивается с помощью инкрементного процесса завершения работ, связанных с устранением времени простоя.
Как отмечает Кромхаут:
Создание рабочей инфраструктуры, определенной кодом, очень важно, поскольку мы стремимся все заменять в оперативном режиме, не отключая сайт на проведение профилактических работ. Рассматриваемый код может обрабатываться с помощью файла JSON, определяющего конфигурацию сервисов AWS, или «поваренных книг» Chef, или же с помощью Python (посредством Boto и Fabric). Мы отправляем запросы на включение подобного кода, который будет просмотрен и протестирован нашими коллегами перед выполнением слияния и развертывания. Критерий успеха в данном случае – создание рабочего кода. Это позволило нам отказаться от GitHub и наладить рабочий поток в стиле Канбан.
Важно осознать, какие формы принимает «успех» для вашей организации. Убедитесь в том, что вы знаете, какой инструмент может расцениваться как успешный. В процессе выбора успешного инструмента обращайте внимание на следующие моменты:
• Кто несет ответственность за принятие решений по выбору инструмента?
• Какие критерии используются для выбора инструмента, его оценки и опыта использования?
• Что является главным при выборе инструмента с точки зрения разработчика и заказчика?
Многие люди избегают пользоваться технологиями. Особенно это относится к новым технологиям, таким как Docker, которая имела статус новой во времена развертывания производственной инфраструктуры DramaFever. Также существует категория людей, для которых Docker вообще лишен всякого смысла. Цель этого примера заключается не в том, чтобы обсудить технологию Docker, а в том, чтобы выявить причины, в силу которых инженеры выбирают эту программу, изучить соображения, которыми они руководствуются, и компромиссы, а также познакомиться со способами принятия окончательных решений в пользу выбора того или иного инструмента.
Стек технологий Etsy является приложением PHP, включающим большое количество внутренних сервисов. Эти сервисы являются довольно сильно взаимозависимыми и сложными. С другой стороны, переход к популярным ныне микросервисам может и не привести к росту независимости. Сервисы применяются для выполнения таких операций, как покупки, продажи, поиск и вывод перечня элементов, а также обработка платежей при выполнении покупок. Несмотря на наличие нескольких крупных хорошо известных провайдеров платежей, услугами которых пользуются многие известные компании в мире, Etsy нуждается в большем контроле над процессом обработки платежей, поэтому реализует этот процесс самостоятельно. Подобные процессы должны быть совместимы с PCI, также должны учитываться другие соображения, связанные с организацией обработки платежей. Инфраструктура преимущественно носит локальный характер и основана на различных центрах обработки данных.
Явная и неявная культура
При создании желаемой специфической культуры в среде основное внимание уделяется явному определению набора культурных убеждений и ценностей. Изначально компания Etsy была основана на сообществе пользователей. Открыто сформулированные ценности компании Etsy приведены в следующем перечне.
• Мы представляем думающий, прозрачный и гуманный бизнес.
• Мы планируем и строим исходя из долгосрочной перспективы.
• Мы ценим профессионализм во всем, что мы делаем.
• Мы считаем, что все нужно делать с улыбкой.
• Мы никогда не отрываемся от реальности[50].
Эти ценности вдохновляют и объединяют сотрудников согласно данным отчета Etsy Progress Report[51] за 2013 год. Хотя в Etsy отсутствует devops-команда, devops-менеджер и devops-инженеры, явно и четко объявленные ценности отражены в ключевых практиках и руководствах по наблюдению за поведением и созданию вклада в devops-сообщество. Заранее обдуманные практики Etsy включают проявление сострадания, экспериментирование, повторное выполнение действий и поощрение обучающих организаций.
Культура сострадания
Чтобы быть по-настоящему гуманным, следует проявлять сострадание. Это чувство проявляется в стремлении сделать чью-то жизнь лучше, даже если это не приведет к улучшению вашей собственной жизни. Компания Etsy вложила значительные средства в создание гуманной рабочей среды для сотрудников. Эта среда характеризуется безупречностью и дружелюбием по отношению к удаленным сотрудникам.
В Etsy также поощряется благодарственная культура, в рамках которой регулярно и публично отмечаются достижения сотрудников. ИТ-работа снискала репутацию неблагодарной, поскольку не заметна, когда все идет хорошо, и подвергается валу критики в случае каких-либо проблем. Поскольку соответствующая рабочая среда не является гуманной, то помимо безупречности в случае каких-либо проблем в Etsy поощряются благодарности ИТ-сотрудникам, хорошо выполняющим свою работу.
ВАЖНОСТЬ БЛАГОДАРНОСТИ
Культура благодарности является важным компонентом формирования и улучшения отношений. Признание и оценка вклада других людей способствуют формированию сплоченного коллектива.
Согласно данным исследований, благодарность обеспечивает ряд преимуществ, в том числе[52]:
Улучшение состояния здоровья
Усиление иммунной системы и снижение кровяного давления.
Повышение устойчивости
Больший уровень сопротивляемости по отношению к невзгодам.
Повышенный уровень положительных эмоций
Более высокие уровни счастья, радости и довольства.
Уменьшение уровня негативных эмоций
Уменьшение остроты ощущения одиночества и изоляции.
Усиление стремления к сотрудничеству и взаимодействию
Более высокие уровни щедрости и сострадания.
Инструменты и культура могут оказывать влияние друг на друга на протяжении жизненного цикла организации. Если вы уделяете внимание этим взаимодействиям, то сможете улучшить уровень культуры в организации и сделать использование инструментов более эффективным. Ответьте на следующие вопросы.
• Какое поведение вы собираетесь поощрять среди сотрудников?
• Каким образом люди работают с помощью существующих инструментов и рабочих потоков?
• Как могут использоваться инструменты для поощрения определенного поведения или ценности?
Публичное общение поощряется не только в инженерных отделах, но и во всей компании. Как можно чаще отправляйте членам команды поощрительные сообщения по электронной почте и мгновенные сообщения. Поощряйте членов команд за устранение ошибок, добавление новых функций, вклад в хранилище программ с открытым кодом, оказание помощи другим сотрудникам и даже за обновление документации. Как говорит Джон Коуи, Staff Operations Engineer:
Один очень хороший пример культуры благодарности в действии – наличие соответствующей кнопки в каталоге персонала. Эта кнопка позволяет номинировать любого сотрудника на «премию Etsy». После щелчка на этой кнопке соответствующее сообщение отправляется номинанту и его менеджеру. В этом сообщении содержится оценка работы номинанта или благодарность за оказанную помощь.
Эта культура помогает укреплять эмпатию и повышать степень близости. В результате повышается эффективность совместного труда, уменьшается вероятность взаимных обвинений и создается более гуманная среда для всех сотрудников.
Культура безупречности
Как уже упоминалось в главе 4, безупречная среда формируется там, где сотрудники делятся между собой историями и несут ответственность за повышение степени безопасности. Джон Оллспоу, занимающий пост технического директора Etsy, в мае 2012 года написал статью Blameless PostMortems and a Just Culture» (https://codeascraft.com/2012/05/22/blameless-postmortems/). В этой статье описывается трансформация обработки неточностей и ошибок с применением безупречного подхода.
Человеку свойственно совершать ошибки. Принятие этого факта как неотъемлемой части бизнеса будет первым шагом на пути к разрядке эмоциональных ситуаций. В рамках традиционного подхода ответственность за совершенные ошибки возлагается на конкретного человека, предусматривается применение карательных санкций, создание барьеров на пути к деятельности отдельных людей и дополнительное обучение персонала. В Etsy применяется более системный подход. Этот подход подразумевает балансирование между безопасностью и подотчетностью, поощрение обмена историями, поддержку безупречности и постмортемов.
В постмортеме, созданном с помощью применяемого в Etsy инструмента Morgue (https://github.com/etsy/morgue), отдельным сотрудникам предлагается дать подробный отчет, включающий следующие пункты:
• график действий и событий;
• наблюдаемые эффекты;
• ожидания;
• допущения;
• результаты и решения.
Применяемая в Etsy практика не допускает наказания отдельных сотрудников, которые делятся своими историями, а также способствует выяснению всех обстоятельств происшедших событий. Когда люди не боятся делиться информацией, они становятся более ответственными за свои действия, и формируется более безопасная среда, предотвращающая повторение одних и тех же ошибок.
Дружелюбие по отношению к удаленным пользователям
Компания Etsy имеет международную аудиторию. Это означает, что приложения этой компании должны быть доступны круглосуточно. В целях создания более гуманной среды для людей, поддерживающих приложения, предусмотрено разбиение на несколько часовых поясов. В результате большее количество людей получает возможность работать исключительно в рабочее время. Дополнительное преимущество заключается в создании расширенного кадрового резерва, который может находиться практически в любой стране мира.
Чтобы внедрить подобный вид культуры, используются несколько инструментов, в том числе IRC (обмен мгновенными сообщениями или организация чата), электронная почта (обмен более длинными текстовыми сообщениями) и Vidyo (организация видеоконференций и сотрудничества). В Etsy практикуется идея общения в «удаленной по умолчанию» форме, когда даже те люди, которые работают в локальном офисе, будут использовать инструменты, предназначенные для удаленного общения.
Поскольку инструменты интегрированы в среду и рабочие процессы, использование средств, дружественных к удаленным пользователям, связано с небольшими накладными расходами. Благодаря использованию подобных инструментов удаленные сотрудники смогут быть в курсе принимаемых решений и участвовать во всех беседах.
Благодаря использованию подобных инструментов можно работать из любого удобного места. Исключение из этого правила составляют лишь техники из центров обработки данных, которые должны находиться недалеко от них. Сотрудники, находящиеся в комфортных условиях, будут более счастливы. Они также могут работать в режиме, который является наиболее эффективным для них, а также позволяет улучшить состояние здоровья и производительность.
Помимо удобств, предоставляемых для удаленной работы, в организациях могут использоваться инструменты для улучшения жизненных условий сотрудников и усовершенствования рабочего потока. При этом нужно учитывать следующие факторы.
• Каким образом инструменты улучшают или уменьшают степень комфорта пользователя?
• Насколько гибкими являются ваши инструменты? В какой степени они могут быть настроены?
• Каким образом воздействуют инструменты на ежедневный стиль общения между людьми?
Роль инструментов в укреплении практик
Инструменты играют огромную роль в укреплении и поощрении практик в Etsy. Культура, дружественная к удаленным пользователям Etsy, подразумевает формирование devops-пакта и устранение любых недоразумений, которые возникают при совместной работе людей. Дополнительная работа, направленная на совершенствование общения, позволяет сформировать гуманную среду. В подобной среде поддерживается круглосуточная ротация по вызову между часовыми поясами. Чтобы выработать одинаковое отношение к обучающим организациям и людям, были адаптированы стратегические процессы, связанные с общением.
При осуществлении поддержки удаленных сотрудников недоступны сеансы специального кодирования и неформальные беседы с глазу на глаз. В этом случае большая часть общения осуществляется в письменном формате. Люди обмениваются сообщениями электронной почты в случае принятия решений, внесения изменений, появления простоев, возникновения проблем либо при необходимости поделиться какими-либо инициативами. Чтобы уменьшить количество сообщений электронной почты, используются фильтры. Всю переписку целесообразно хранить в архиве с возможностью поиска. Ретранслируемый интернет-чат (Internet Relay Chat; IRC) критически важен для формирования культуры, дружественной к удаленным пользователям, которая взлелеяна в Etsy. Чат-боты обновляют каналы с помощью информации о развертываниях, предупреждениях и изменениях конфигурации. Чат-боты также поддерживают системное взаимодействие, например, для обмена тихими предостережениями Nagios, относящимися к предстоящему плановому техническому обслуживанию либо к обзору кода. Чат-боты могут применяться для продвижения культуры благодарности путем обмена «плюсиками» и одобрениями.
Большинство дискуссий происходят в общественных каналах. Эти каналы являются «прозрачными» и открытыми, обеспечивая людям возможность просмотра каналов, принадлежащих другим командам. Поскольку интересы людей не ограничиваются работой, доступны не только рабочие, но и другие каналы. Чаты, идущие в режиме реального времени, воспринимаются как навязчивые, поэтому неудивительно, что люди отключают оповещения, чтобы поработать.
Каждый сотрудник Etsy использует клиент Vidyo, а удаленные сотрудники применяют веб-камеру и гарнитуру. Для максимально комфортного проведения видеоконференций используется телевизор с большим экраном и оборудование Vidyo. Подобная «операционная пещера» исполняет роль канала, используемого большинством удаленных эксплуатационных команд. Благодаря перманентной настройке вызова Vidyo в рабочей области эксплуатационной команды удаленные сотрудники могут в любой момент подключаться к этому каналу, чтобы услышать происходящее в офисе или показать своих кошек. Благодаря возможности слышать окружающий шум и болтовню эти пользователи могут в любой момент времени принять участие в беседе, что позволит им ощутить сопричастность к команде и к культуре организации в целом.
Документация воспринимается в качестве способа выполнения каких-либо операций в Etsy. Как правило, wiki-страницы, созданные с помощью программы Atlassian Confluence, являются точными и актуальными. Настоятельно рекомендуется обновлять страницы с документацией (особенно с информацией о текущих задачах). В то время как некоторые компании ленятся создавать документацию, мотивируя свое поведение фактом ее быстрого устаревания, компания Etsy является сторонником принципа «обновление wiki-страниц – лучшее вложение трудозатрат».
Покупка или самостоятельная разработка
Компания Etsy уклоняется от практики использования новейших технологий только на основании того, что они являются новыми и интересными. Большинство инструментов, применяемых в компании, хорошо известны и имеют большой стаж использования. Дополнительная информация, обосновывающая эту философию, приводится в посте блога бывшего инженера компании Etsy Дэна Маккинли Choose Boring Technology («Выбор скучной технологии»). Эта статья доступна на сайте http://mcfunley.com/choose-boring-technology. Идея, заложенная в основу этой статьи, заключается в том, что сосредоточение на реализации новых и непроверенных технологий крадет время и энергию, которые могут потребоваться на инновации продукта, что является конечной целью компании.
В Etsy высоко ценится так называемое благородство духа, которое заключается в работе на благо сообщества. Эта отдача может принимать форму сообщений в блогах, выступлений на конференциях, наставничества других сотрудников либо создания вклада в проекты с открытым исходным кодом (свои собственные или посторонние).
Общий подход к выбору инструментов предусматривает получение ответов на следующие вопросы.
• Можем ли мы сделать это с помощью инструмента, который мы знаем и которым владеем? Существуют ли веские причины отказаться от такого решения?
• Существует ли инструмент, который отвечает нашим потребностям?
• Существует ли инструмент, который в целом отвечает нашим потребностям и может быть расширен или настроен? Создан ли этот инструмент на основе проекта с открытым исходным кодом?
• Имеются ли возможность, время и желание создать инструмент самостоятельно?
• Нужно ли решать возникшую проблему и достаточно ли только внутренних возможностей?
Компания Etsy вносит вклад в разработку множества инструментов, в том числе Nagios, Chef, Elasticsearch и Kibana. Если же инструменты перестают давать нужную отдачу, они подлежат замене. В Etsy контролируется сетевое оборудование и отслеживается поведение новых устройств. Одно время в Etsy использовался Cacti (www.cacti.net), но из-за сложности и необходимости ручной настройки этого инструмента был разработан и выпущен FITB (https://github.com/lozzd/FITB).
Пограничный протокол шлюза (Border Gateway Protocol; BGP) выполняет мониторинг, отслеживание сайта и синтетическое тестирование. Именно в этих областях Etsy выбирала внешние услуги или программы, исходя из природы проблемного пространства. Рассматривая BGP-мониторинг в качестве примера, можно сказать, что этот пример имел смысл только для Etsy, поскольку BGP-мониторинг включает мониторинг всех внешних потоков трафика. Эти потоки анализируются, чтобы понять их влияние и устранить проблемы, возникающие при маршрутизации в сетях. Лучше использовать время сетевых инженеров, чем воссоздавать сложную услугу мониторинга, которая применяется в других местах. В этом случае понятно, что лучше использовать существующий инструмент.
Рассмотрение автоматизации
На протяжении многих лет в Etsy была проделана большая работа по автоматизации различных рабочих потоков и процессов в областях, в которых засилье ручных процессов вызывало проблемы. Один из ключевых примеров был рассмотрен во введении – выполняемый вручную и чреватый ошибками процесс развертывания, который занимал много часов и был невероятно труден в откате. Этот процесс был заменен на более рациональный автоматический инструмент развертывания, Deployinator. Процесс замены был не одномоментным, а скорее итеративным, представлявшим большую часть автоматизации в Etsy.
В качестве другого примера рассмотрим процесс создания новых серверов. Поскольку Etsy использует собственные центры обработки данных, не обращаясь к облачным сервисам, процесс создания сервера является ручным, занимая часы или даже дни, начиная с момента установки сервера в стойку и завершая моментом запуска в эксплуатацию. Первый этап автоматизации заключался в создании коллекции скриптов, написанных на Ruby, которые предназначены для устранения некоторых наибольших «болевых точек», таких как настройка коммутаторов и виртуальных локальных сетей. На протяжении нескольких следующих лет были добавлены новые средства, устранены ошибки и автоматизированы дополнительные «болевые точки». В результате инструмент получил веб-интерфейс, с помощью которого любой инженер (помимо члена эксплуатационной команды) может выбрать профиль оборудования, роль Chef и получить новый сервер в свое распоряжение в течение нескольких минут.
Инженеры из компании Etsy не пытаются слепо автоматизировать все на свете ради самой автоматизации. Они осведомлены об остаточном принципе[53], согласно которому остаются неавтоматизированные задачи, выполняемые людьми-операторами. Эти задачи либо слишком сложны для автоматизации и редко автоматизируются, либо слишком просты и нерентабельны для автоматизации. В результате может появиться так называемая дисквалификация, когда из-за автоматизации задач люди забывают, как их выполнять. Это приводит к постепенной утрате навыков в соответствующих областях.
Автоматизация может обеспечивать большие преимущества во многих ситуациях, позволяя сэкономить время на выполнение ручных повторяющихся задач и исключить появление ошибок. Конечно, автоматизация не является панацеей. Если вы собираетесь внедрять автоматизацию, задайте себе следующие вопросы.
• Каковы ваши самые большие «болевые точки»?
• Что можно, а что нельзя автоматизировать?
• Должны ли полностью автоматизироваться некоторые аспекты рабочего процесса?
• Как вы поступите в случае появления сбоя при выполнении автоматизации?
Оценка успеха
Чтобы сознательно экспериментировать и поощрять обучение, в Etsy придают большое значение «прозрачности» и мониторингу. Эти принципы демонстрируются множеством инструментов и процессов. Начиная от мониторинга производительности на уровне системы и завершая показателями на бизнес-уровне, Etsy стремится собрать как можно больше данных. Эти данные являются «прозрачными» для сотрудников, поэтому даже те, кто не обладает глубоким пониманием операций, могут прийти к выводам о необходимости выполнения итеративных улучшений. Этот процесс требует определенного времени.
Майкл Римбетси присоединился к Etsy в 2008 году. Он и его команда начали просматривать посты на форумах пользователей Etsy. В результате этого просмотра обнаружились проблемы, которые оставались скрытыми из-за отсутствия реального мониторинга в организации. В результате анализа причин частых простоев и в процессе обратной связи с пользователями Римбетси и другие руководители обнаружили более устойчивые способы запуска и выполнения платформы. Вместо того чтобы пытаться запланировать внедрение полностью исчерпывающего решения, они начали с минимально жизнеспособного решения, с основных положений решения мониторинга, которые оказывают наиболее влияние на качество обслуживания клиентов.
Поскольку не существовало четких критериев выбора нужных инструментов, приходилось экспериментировать. При этом ставилась цель понять, что происходит с сайтом, приложениями и компонентами блокировки. Были выбраны Nagios, Cacti и Ganglia, поскольку руководители были знакомы с этими платформами. К тому же была достаточно высока результирующая скорость внедрения и низкие накладные расходы (эти платформы распространяются на бесплатной основе).
Со временем, благодаря частой итерации и эволюции, все подразделения Etsy были охвачены практикой «измерять все, что только можно». Помимо опережающего планирования объектов измерения любой пользователь мог легко получить нужные ему сведения в виде графика. Был разработан и выпущен StatsD, сетевой демон, выполняющийся на платформе Node.js. Этот демон может прослушивать статистику, отсылаемую через порты UDP и TCP, и агрегировать полученные данные с помощью подключаемых серверных служб, таких как Graphite. Поскольку каждые 10 секунд данные сбрасываются, обеспечивается создание коллекции данных практически в режиме реального времени.
Общая цель заключалась в создании и доставке программного обеспечения. Разные команды осуществляют мониторинг в соответствии со своими нуждами. Как правило, не назначаются отдельные люди, выполняющие мониторинг. Поощряется участие в процессах мониторинга каждого сотрудника, который может вносить свой посильный вклад в это дело. Что же касается мониторинга, рекомендуется следовать таким советам.
• Если у вас возникают вопросы, задайте их кому-либо.
• В случае, когда ваши проблемы относятся к категории производственных, эксплуатационная команда пообщается с вами на предмет устранения этих проблем.
В качестве примера devops-пакта в действии Дэниелс описала процесс эксплуатации, реализуемый при работе с совсем другой командой. В этом случае формируется команда, отвечающая за интерфейсную инфраструктуру, которая обрабатывает полученные предупреждения. После того как в полночь было получено предупреждение о размере дискового пространства на сервере (любимое предупреждение каждого сисадмина), она поняла, что причина этого предупреждения заключается в том, что логи были сохранены в разделе диска, размер которого намного меньше размера стандартного раздела диска, применяемого для хранения логов.
Мониторинг и оповещения являются ключевыми элементами каждой программной среды, а также областями, для которых эффективное использование инструментов обеспечивает огромные преимущества. Обязательно примите во внимание следующие вопросы.
• Каким образом ваши инструменты дифференцируются между мониторингом и обработкой оповещений?
• Каким образом ваши инструменты и процессы удовлетворяют потребности в мониторинге разных команд?
• Насколько гибки и настраиваемы решения мониторинга и обработки оповещений?
После осознания причины появления предупреждения Дэниелс обсудила вместе с командой лучшие операционные практики, применяемые для создания логов, обговорила соответствующую документацию, описала возникающие проблемы и предложила пару решений. Команда, отвечающая за интерфейсную инфраструктуру, выбрала и внедрила наиболее подходящее решение. Подобное сочетание безупречности и обмена информацией является основным условием создания и поддержки культуры понимания.
На основе двух рассмотренных ранее примеров стало очевидно, что решения по выбору инструментов, используемых изо дня в день, не следует принимать впопыхах. Корпоративные информационные бюллетени, ведущие средства массовой информации и конференц-киоски публикуют перечни и статьи, описывающие «лучшие» инструменты, предназначенные для devops-команд. И вряд ли вы заметите разницу между компанией, пытающейся продать решение, которое может быть эффективным в вашей среде, и компанией, пытающейся вписаться в devops-тренд.
Инструменты важны для выполнения работы, но они не являются единственным и необходимым условием для осуществления этого процесса. Не существует «devops-услуги», которую можно купить и использовать в качестве исчерпывающего решения всех ваших производственных проблем. Важно понимать, что хотя инструменты и воздействуют на культуру, они не способны заменить ее. Поэтому будьте осторожны, если кто-то пытается вам продать «devops-решение, сделанное на заказ». Подобные предложения звучат заманчиво, но вряд ли реальны.
Другие мотивации находятся вне сферы действия наших собственных целей и амбиций. Они выступают в виде наших межличностных отношений. Например, организация собирается сделать выбор в пользу поставщика X, поскольку он предложил провести спортивное мероприятие и организовать хороший обед. Либо у лица, принимающего решения, имеется друг в стартапе, который нужно поддержать.
В конце концов, на выбор инструментов может оказать влияние их хорошая репутация, которая проявляется в той или иной форме. Например, с высказыванием «никто и никогда не был уволен за покупку техники IBM» трудно спорить. Благодаря осознанию мотивов принятия решений в вашей среде вам будет проще принять решение по выбору способов улучшения процессов в вашей организации.
«Я действительно считаю, что наши демо-дни являются довольно интересными и познавательными, – заявил Джордж. – Я заметил, что вы используете виртуальную машину на ноутбуке и управляете ею отдельно от кода. Пытались ли вы использовать инструмент Test Kitchen для создания проекта по управлению виртуальной машиной? Эксплуатационная команда использует этот инструмент при тестировании новых реализаций сервисов. Таким образом мы можем воссоздать то, что делает каждый сотрудник или команда».
«Нет, я раньше никогда не слышала о Test Kitchen. Я хотела бы познакомиться с этим инструментом поближе, особенно в свете того, что он позволит облегчить создание пользовательской виртуальной системы», – сказала Элис.
«Фактически мы начинаем с ChefDK. Этот набор для разработки кода от Chef. Он уже установлен на всех ноутбуках, находящихся у сотрудников компании, – заметил Джордж. – Похоже, что мы должны координировать свои действия с ИТ-командой и обязаны позаботиться об обновлении документации, посвященной описанию локальной среды разработки для компании. Эти обязанности прописаны в моем новом контракте инженера по эксплуатации. И я не понимал, почему другие команды не выполняли эти действия».
Джордж проиллюстрировал простоту настройки быстрой «поваренной книги» Chef. При этом использовался заранее созданный шаблон Test Kitchen, включающий зеркальное отображение настроек, сделанных Элис, Джорди и Джози при установке MongoDB.
«Теперь я могу передать это обратно, в нашу централизованную среду Git, а любой из вас может получить проект и работать с ним дальше», – сказал Джордж.
Элис протестировала сказанное путем клонирования проекта и использования команд kitchen, как это делал Джордж. После того как образ ОС был синхронизирован, она быстро сформировала тестовую среду на своем ноутбуке.
«Эта работа также может быть сделана с помощью MySQL, и тогда мы сможем быстрее оценить преимущество выбранного решения на основе реальных показателей», – сказала Джози.
«А как насчет того, чтобы разделиться на две команды и в паре подключиться к нашему кластеру Jenkins? Это позволит нам протестировать процесс вытягивания программного проекта на каждую платформу с одновременным выполнением оценки», – сказал Джордж.
В конце концов все пришли к выводу, что использование MySQL имело смысл с точки зрения эксплуатационных расходов. Благодаря использованию визуализированных показателей соответствующие команды смогли оценить использование MySQL в среде. Благодаря использованию инструментов Chef, git и Jenkins каждый сотрудник может делиться своей работой, а не дублировать затраты времени и сил. В результате облегчается совместная работа людей из разных команд.
Благодаря использованию сотрудничества команда может в течение недели получить начальную демоверсию приложения, для которого составлены обзоры. В результате команда разработки вместе с командой обеспечения безопасности может выделять больше времени на планирование алгоритмов обнаружения опасных вторжений. Благодаря открытому и постоянному общению каждый сотрудник может ощутить, что его голос был услышан и учтен. В результате каждый член группы может принять участие в выработке групповых решений.
Убедитесь в том, что у вас имеется четко определенный набор ценностей для вашей организации. В компании Etsy имеется очень четкий, убедительный набор ценностей, который является своего рода руководством по принятию решений, связанных с инструментами и технологиями. Это руководство также определяет использование инструментов и технологий в ежедневной работе.
Фильтруйте используемые практики на основе текущих действий, выполняемых в вашей команде. Ниже перечислены практики, наблюдаемые в компаниях Etsy и DramaFever:
• безупречная среда;
• экспериментирование и итерация;
• последовательное улучшение;
• обучающие организации.
После того как вы идентифицировали ваши текущие действия и практики, вы будете в состоянии определить соответствие применяемых практик ценностям компании. Если, например, в список ваших ценностей входят программы с открытым исходным кодом, но вы чаще выбираете поставщика программ с закрытым исходным кодом либо не даете людям возможности вносить свой вклад в коллекцию программ с открытым исходным кодом, это может быть признаком несоответствия ценностей в теории и на практике.
При выборе инструментов руководствуйтесь вашей культурой, уровнем навыков и потребностями. С течением времени выбор инструментов может изменяться. Даже если ваши сотрудники и организации разделяют культурные особенности и ценности, они все равно испытывают разные технические и деловые потребности. Несмотря на то что в примерах было рассмотрено великое множество ценностей и практик, в конечном итоге в компании DramaFever появился другой набор инструментов, отличающийся от рассмотренных ранее средств. Ни одна компания не является всегда «правой» или «лучшей». Вы должны знать, что является правильным для вашей организации в момент принятия решений.
Поймите, что изменения в вашей культуре и в степени эффективности инструментов не происходят в одночасье. Компания Etsy работает над своими инициативами в области мониторинга начиная с 2008 года и будет продолжать последовательно оттачивать мастерство кодирования. Богатый набор инструментов, который появился в сообществе пользователей программ с открытым исходным кодом, не следует рассматривать в качестве готового решения, призванного решить все проблемы, хотя он может оказаться полезным. Для внедрения изменений понадобятся время и непрерывная практика.
Знайте, что оценка вашего прогресса критически важна для достижения успеха. Если вы находитесь в состоянии нулевого мониторинга, учтите, что это единственная область, которой стоит уделить время. Чтобы воспользоваться дополнительными преимуществами мониторинга, прочитайте книгу Джейсона Диксона (Jason Dixon) Monitoring with Graphite (O’Reilly). Эта книга, а также другие источники информации приведены в главе 20.
И наконец, имейте в виду, что инструменты не полностью отделены от трех других столпов эффективных devops-практик. В конечном счете инструменты используются людьми, чтобы помочь другим людям, для создания решений, предназначенных для людей. Эту «человеческую составляющую» невозможно отделить от инструментов. Инструменты могут влиять и подвергаться влиянию на работу и общение. Чтобы добиться существенных и длительных изменений, следует учитывать все эти факторы и взаимодействия.
Глава 13. Инструменты: заблуждения и устранение неполадок
В этой главе мы рассмотрим заблуждения и способы устранения проблем, которые могут возникать при выполнении различных сценариев, связанных с выбором и использованием инструментов в более широком смысле. Мы не будем касаться способов поиска и устранения проблем, связанных с использованием конкретных инструментов и технологий, поскольку эти вопросы выходят за рамки темы, рассматриваемой в этой книге. Мы остановимся на процессах принятия решений и различных проблемах, связанных с использованием инструментов в рабочем потоке.
Многие ошибочные представления, связанные с использованием инструментов в devops-процессах, сводятся к важности конкретных инструментов в devops-решениях.
Мы используем технологию X, тогда как другие используют технологию Y; мы должны любой ценой перейти к использованию технологии Y
Как упоминалось в части I, devops является культурным движением. Культура включает в себя набор технологий и крупномасштабных изменений. Все это, особенно в случае санкционирования со стороны менеджмента, ведет к замедлению развития организации в целом. Прежде чем отказаться от используемой технологии, нужно распознать в среде инструменты, являющиеся частью существующей культуры, узнать все об опыте взаимодействия людей с этими инструментами, о сходствах и различиях в использовании. В результате выполнения подобной проверки и оценки вы сможете определить, какие изменения должны быть выполнены и следует ли их выполнять прямо сейчас.
Единственное исключение из вышеописанной ситуации – обновления. Модернизация технологии необходима. Чем дольше вы будете откладывать обновление, тем больше вы будете накапливать «долгов», связанных с надежностью и тестированием совместимых способов обновления. В случае слишком раннего обновления может понадобиться внедрить систему контроля качества для продукта. Если же обновление выполняется слишком поздно, возможно, вам придется использовать «технологию вчерашнего дня».
Заимствование инструментов, используемых в успешных компаниях, не обязательно обернется успехом для вашей организации. Сосредоточьтесь на процессе, а не на результате. Если технология X успешно используется в вашей среде, не отказывайтесь от нее.
Наличие конкретного инструмента или технологии не означает, что вы не можете развернуть успешную инициативу devops. Использование каналов IRC вместо Slack или Hipchat, запуск и выполнение серверов на физическом сервере вместо «облака» либо использование монолита PHP вместо микросервисов Go не исключает использования идей devops. Суть движения devops заключается в культуре производства и в организации совместной работы, а не в применении самых современных инструментов. Качество общения не зависит от того, какую программу чата вы используете, – современную или двадцатилетней давности.
Использование технологии X эквивалентно внедрению devops
Существуют определенные группы или типы инструментов и технологий, которые могут существенно помочь с внедрением инициатив devops. В качестве основных примеров приводились система контроля версий и автоматизация инфраструктуры. Важно понять, почему эти примеры столь ценны и каким образом эта ценность влияет на человеческий фактор при создании программного обеспечения.
Например, автоматизация инфраструктуры позволяет сотрудникам вносить изменения более непосредственным и надежным способом, уменьшая риск и «трения», связанные с изменениями.
Без учета воздействия вышеописанных факторов на «человеческий аспект» воздействие технологий будет в значительной степени нивелировано. Если вы, например, начнете использовать автоматизацию инфраструктуры, но при этом продолжите поддерживать прежние процессы контроля изменений, которые являлись «болевыми точками» для разработчиков, вряд ли вы ощутите реальные преимущества от автоматизации инфраструктуры. Ни один инструмент сам по себе не способен исправить разрушенную культуру. Чтобы использовать инструменты более эффективно, нужно обратить внимание на то, как и почему люди используют инструменты, что они пытаются сделать и как инструменты могут помочь или помешать им в этом.
Простое добавление в среду Chef, Docker, Slack или любого другого инструмента, часто упоминаемого в связи с devops, вовсе не означает, что вы «сделали devops». На самом деле набор инструментов – это лишь одно из условий организации совместной работы. Не наличие или отсутствие инструмента приводит к формированию или разрушению инициативы devops. Инструменты могут лишь помогать или мешать формированию культуры, основанной на devops.
Мы должны убедиться в том, что не выбрали некорректный инструмент
Некоторые люди опасаются, что выбор «некорректного» инструмента будет иметь пагубные последствия как для проекта, так и для организации в целом. Эти опасения могут еще больше раздуваться поставщиками, утверждающими, что вы «должны» использовать именно их продукты и решения, чтобы внедрить devops. Естественно, сначала нужно убедиться в том, что ваши решения не приведут к серьезным негативным последствиям.
Не следует акцентировать внимание на особенностях отдельных инструментов. Лучше сосредоточьтесь на способах использования инструментов на всех уровнях организации, а также уроках, которые можно извлечь из позитивных и негативных аспектов, связанных с использованием этих инструментов. Выбор некорректного инструмента не так страшен, как неправильный метод выбора инструментов.
Например, когда идет речь об автоматизации инфраструктуры, выбор инструмента Chef вместо Puppet (или наоборот) вряд ли окажет существенное влияние на успех или неудачу этого проекта. Конечно, от используемого инструмента зависят детали реализации либо определенные варианты использования автоматизации инфраструктуры. Если же идет речь о влиянии на глобальном уровне, то более важно, как вы используете выбранный инструмент автоматизации инфраструктуры, чем какой вы выбрали инструмент.
Если вы понимаете принципы надлежащего использования инструментов, то можете сказать, когда выгодно использовать автоматизацию, знаете, как выбрать новые инструменты и внедрить их в организации, вы сможете принимать лучшие решения по выбору и внедрению инструментов. Более того, вы сможете учиться на собственном опыте.
В результате вы окажетесь способными адаптироваться к постоянно изменяющемуся ландшафту новых инструментов и технологий. И даже если вы выберете не оптимальный инструмент, вы не потратите слишком много сил и ресурсов и не будете обречены на вечное использование этого инструмента. Быть в состоянии рассуждать, учиться и изменять способ использования инструмента более важно, чем просто выбрать «лучший в мире» инструмент.
Можно купить devops «в упаковке» или devops в качестве услуги
Растущее влияние и популярность devops привели к быстрому росту поставщиков, которые включили связанные с devops словечки в свою маркетинговую политику, чтобы попытаться «быть в тренде». Порой бывает нелегко провести границу между маркетинговой шумихой и реальностью, особенно если эти идеи для вас новые либо вас просто «забросали» огромным количеством предложений по продаже devops.
Чтобы сформировать более сбалансированный взгляд, следует учитывать четыре столпа devops. Помимо инструментов нужно учитывать сотрудничество, близость и масштабирование. Возможно, неплохо иметь набор разных инструментов «в упаковке» либо в качестве услуги, но, как уже было сказано ранее, просто иметь нужный набор инструментов devops недостаточно. Чтобы преуспеть во внедрении devops, нужно научиться использовать инструменты эффективно.
Практики devops – это намного больше, чем просто инструменты. Ответьте на следующие вопросы. Каким образом вы продаете сотрудничество в качестве услуги? Что вы можете сказать об инструменте, помогающем устранить определенные проблемы, связанные с сотрудничеством или общением, и о фактической деятельности людей, работающих вместе? Как насчет того, чтобы члены разных команд сели рядом и обсудили разные цели, приоритеты и проблемы? Все это вы не сможете купить «в упаковке» или в качестве услуги. В конце концов сотрудники вашей организации должны выработать общее понимание, которое описывается как devops-компакт. В соответствии с этим пониманием должны быть выполнены внутренние изменения в вашей организации.
Существует множество великих инструментов и услуг. Многие компании предлагают решения, которые способствуют решению реальных проблем. Когда вы слышите слово «devops» в маркетинговых кампаниях, представляйте четыре столпа devops наравне с взаимодействиями и пересечениями. При этом спросите себя, реальны ли обещания, щедро раздаваемые маркетологами. Просто замените слово «devops» в рекламном слогане фразой «людям хорошо работается вместе» и подумайте, имеет ли смысл полученное предложение. Если оно звучит глупо или смешно, вряд ли следует доверять подобному рекламному слогану.
В конечном счете вам самостоятельно придется делать всю тяжелую работу, вместе со своими людьми и командами выяснять, что именно работает или не работает в вашей организации. Устойчивые изменения в культуре невозможно купить, их придется создавать самостоятельно.
Имейте в виду, что в процессе поиска и устранения проблем, связанных с использованием технологий, не следует относиться к инструментам как к игрушкам. Нужно выбирать инструменты, которые будут решать проблемы. Нет причин менять что-либо просто так, без оснований.
Мы пытаемся найти лучшие практики для технологии X
Иногда удобно искать наилучшую практику для конкретной поставленной задачи, но подобное мышление может заложить основу для проблем в будущем. В процессе выбора «наилучшего» решения, которое оказывается неработоспособным, возникает когнитивный диссонанс, за которым зачастую следует чувство вины. Прежде чем погрузиться в решение какой-либо проблемы, попробуйте применить несколько ключевых стратегий.
• Идентифицируйте состояние проблемы в настоящее время.
• Определите нужные вещи и полезные штучки.