Глава 20. Преобразуйте локальные открытия в глобальные улучшения
В предыдущей главе мы обсудили, как с помощью разбора ошибок без поиска виноватых побуждать исполнителей говорить о своих ошибках и тем самым создавать безопасную и ориентированную на обучение культуру. Мы также изучили то, как находить слабые сигналы о возможных сбоях, а также побуждать сотрудников экспериментировать и рисковать. Кроме того, с помощью проактивного планирования и тестирования возможных аварий, а также поиска и исправления скрытых дефектов мы сделали наши системы более адаптивными и безопасными.
В этой главе мы создадим механизмы, помогающие распространить новые знания и улучшения по всей организации, тем самым многократно увеличивая эффект новых открытий. Благодаря этому все сотрудники смогут извлечь пользу из накопленного опыта компании, и мы выведем практические достижения нашей организации на новый уровень.
Используйте чаты и чат-ботов, чтобы автоматизировать и сохранять знания компании
Во многих организациях есть чаты, упрощающие быстрое общение между командами. Однако чаты также используются и для автоматизации.
Эта методика впервые была опробована в GitHub, где она стала известна под названием ChatOps. Главной целью было использовать автоматизированные инструменты прямо в разговорах чатов, создавая прозрачность и документируя текущую работу. Как пишет Джесс Ньюлэнд, системный инженер GitHub, «Даже если вы новичок, вы можете посмотреть на логи чатов и увидеть, как все было сделано. Вы как будто все время занимались парным программированием со всей командой».
Они создали Hubot, приложение, взаимодействовавшее с командой эксплуатации в их чатах, где можно было выполнять действия с помощью команд прямо из беседы (например, @hubot deploy owl to production). Результаты выполнения также отображались в чате.
У автоматического выполнения команд из чата (в противоположность запуску автоматизированных скриптов из командной строки) было много преимуществ, в том числе:
• все видят всё, что происходит;
• новые инженеры в первый же рабочий день могли видеть, как выглядит повседневная работа и как ее выполняют другие;
• сотрудники чаще просили о помощи, когда видели, что остальные помогают друг другу;
• новые знания внутри компании накапливались гораздо быстрее.
Кроме того, помимо этих преимуществ, чаты записывают все разговоры и делают обсуждения общедоступными. Электронная почта же обычно личная, информацию оттуда узнать или распространить по компании нелегко.
Автоматизация в чатах помогает документировать и делиться нашими наблюдениями и способами решения проблем прямо в процессе работы. Это укрепляет культуру прозрачности и сотрудничества в нашей повседневной деятельности.
Это также очень эффективный способ распространения знаний по компании. В GitHub все сотрудники, занимавшиеся эксплуатацией, работали удаленно. Более того, все инженеры эксплуатации жили в разных городах. Как вспоминает Марк Имбриако, бывший директор по эксплуатации GitHub, «в GitHub не было материального кулера. Кулером был чат».
Через Hubot можно было запускать разные инструменты автоматизации, используемые в Github, такие как Puppet, Capistrano, Jenkins, resque (библиотека на основе Redis для создания фоновых процессов) и graphme (инструмент для создания графиков в Graphite).
С помощью Hubot можно было проверять работоспособность сервисов, развертывать код в производственную среду и блокировать оповещения, когда сервисы переходили в профилактический режим. Повторяющиеся действия, например smoke-test при сбое развертывания, выведение серверов эксплуатации из работы, возврат к исходной ветке для front-end-сервисов или извинения инженерам, вызванным в нерабочее время, тоже стали возможными действиями в Hubot.
Результаты внедрения изменений в репозиторий исходного кода и команды, запускавшие процесс разветрывания, появлялись в чате. Кроме того, когда внесенные изменения продвигались по конвейеру развертывания, их статус также отображался в чате.
Типичный разговор в чате мог выглядеть так:
«@sr: @jnewland, как получить список больших репозиториев? что-то вроде disk_hogs?»
«@jnewland:/disk_hogs»
Ньюлэнд отмечает: некоторые вопросы, которые раньше часто задавали во время работы над проектом, теперь звучат очень редко. Например, инженеры могут спрашивать друг у друга: «Как там развертывание?», или «Ты проведешь развертывание или я?», или «В каком состоянии загрузка?»
Среди всех преимуществ — в их числе быстрая адаптация новых сотрудников и повышение производительности — Ньюлэнд особо выделяет то, что работа стала более человечной, инженеры теперь могли быстро и без усилий находить проблемы и помогать друг другу в их решении.
GitHub создал среду для совместного поиска новых знаний, которые могут быть трансформированы в статус организационных. Делиться знаниями с коллегами стало очень легко. Далее в этой главе мы рассмотрим способы того, как создавать пути и ускорять распространение нового опыта.
Автоматизируйте типовые процессы в ПО для многократного использования
Мы слишком часто закрепляем стандарты и процессы проектирования архитектуры, тестирования, развертывания и управления инфраструктурой в документах Word. Затем они пылятся в дальнем углу какого-нибудь сервера. Проблема в том, что инженеры, разрабатывающие новые приложения или среды, не всегда знают, что эти документы существуют, или у них нет времени реализовывать требования стандартов. В результате они создают свои инструменты и процессы с ожидаемым исходом: хрупкие, неподдерживаемые и ненадежные приложения, а также среды, которые сложно использовать, поддерживать и развивать.
Вместо того чтобы записывать опыт в файлы Word, мы должны так преобразовать эти стандарты и процессы, содержащие накопленный опыт компании, чтобы их было легко использовать. Один из лучших способов сделать эти знания полезными — поместить их в централизованный репозиторий и сделать его доступным для всех сотрудников.
Джастин Арбакл, будучи главным архитектором компании GE Capital, рассказывал: «Нам нужно было создать механизм, позволяющий командам легко соблюдать требования: государственные, региональные, отраслевые, описанные в десятках нормативных баз, распространяющиеся на тысячи приложений, работающих на десятках тысяч серверов в десятках дата-центров».
Созданный механизм получил название ArchOps. Этот механизм «позволял нашим инженерам быть строителями, а не каменщиками. Когда мы перевели стандарты проектирования в автоматизированные шаблоны, простые в использовании даже для новичка, консистентность оказалась побочным продуктом нашей работы».
Трансформируя процессы, осуществляемые вручную, в автоматизированный выполняемый код, мы делаем их доступными и полезными для всех, кто их использует. Арбакл заключает: «Уровень соблюдения требований в компании прямо пропорционален степени того, насколько эти требования переведены в код».
Если автоматизированный процесс — самый удобный способ достичь цели, то его будут использовать чаще и чаще, и можно даже подумать о том, чтобы сделать его общекорпоративным стандартом.
Создайте единый общедоступный репозиторий для всей организации
Общедоступный репозиторий исходного кода для всей компании — один из самых мощных механизмов распространения опыта по организации. Когда мы обновляем что-либо в таком репозитории (например, библиотеку общего пользования), изменения быстро и автоматически распространяются на все сервисы, использующие эту библиотеку.
Компания Google — один из самых ярких примеров использования репозитория, доступного всей организации. К 2015 г. в нем хранилось более миллиарда файлов и свыше двух миллиардов строк кода. Это хранилище кода используется каждым из 25 000 инженеров компании и покрывает все ее сервисы, включая Google Search, Google Maps, Google Docs, Google+, Google Calendar, Gmail и YouTube.
Один из ценных результатов такого подхода — то, что инженеры могут использовать разнообразный опыт всех сотрудников компании. Рэйчел Потвин, технический руководитель, возглавляющий группу по организации инфраструктуры для разработчиков, в интервью для журнала Wired рассказала, что у каждого инженера Google есть доступ к огромному объёму библиотек, где «практически все уже давно сделано до них».
Кроме того, как поясняет Эран Мессери, инженер команды по организации инфраструктуры для разработчиков в Google (Google Developer Infrastructure group), одно из преимуществ использования единого хранилища в том, что все пользователи имеют доступ к самой последней версии кода и ничего не нужно координировать.
Помимо исходного кода в едином репозитории можно хранить и другие вещи, фиксирующие знания и опыт компании, например:
• конфигурационные стандарты для библиотек, инфраструктуры и сред (рецепты Chef, декларации Puppet и так далее);
• инструменты развертывания;
• стандарты и инструменты тестирования, включая стандарты безопасности;
• инструменты конвейера развертывания;
• инструменты мониторинга и анализа;
• руководства и стандарты.
Сохранение опыта и создание общего доступа через такое хранилище — один из самых мощных механизмов распространения знаний. Как пишет Рэнди Шуп, «самый мощный механизм для предотвращения сбоев в Google — это единый репозиторий. Когда кто-то отправляет туда свой код, новая сборка всегда будет использовать последние версии всего. Все собирается напрямую из исходников вместо того, чтобы динамически подключать во время выполнения необходимые компоненты. В каждый момент времени существует лишь одна версия библиотеки, она и подключается во время сборки приложения».
Том Лимончелли — соавтор книги The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems и бывший инженер SRE Google. В своей книге он утверждает, что ценность единого репозитория настолько высока, что это сложно выразить словами.
«Вы можете написать какой-нибудь инструмент всего один раз, и он будет использоваться во всех проектах. У вас есть стопроцентно точное знание о том, кто зависит от этой библиотеки; поэтому вы можете провести рефакторинг и быть полностью уверенным в том, кого затронут изменения и кому нужно провести дополнительные тесты. Наверное, я мог бы привести еще сотню примеров. Я не могу выразить словами, насколько это важное конкурентное преимущество для Google».
В Google у каждой библиотеки (например, libc, OpenSSL, а также библиотеки, разработанные самой компанией, например для поддержания многопоточности в Java) есть свой хранитель, ответственный за то, чтобы она не только компилировалась, но и успешно проходила тесты для всех зависящих от нее проектов, совсем как настоящий библиотекарь. Хранитель также отвечает за перевод каждого проекта со старой версии на новую.
Представьте реальную организацию, пользующуюся 81 версией библиотеки Java Struts. Всех версии, кроме одной, серьезно уязвимы. Поддержка всех этих вариантов — у каждого свои особенности — создает огромную операционную нагрузку. Кроме того, такое большое количество делает обновление версий рискованным и опасным, из-за чего разработчики не горят желанием эти обновления проводить. Порочный круг.
Единое хранилище исходного кода решает большинство этих проблем, и к тому же можно создать автоматизированные тесты, позволяющие командам переходить на новые версии уверенно и безопасно.
Если мы не можем собирать все приложения с единого дерева исходного кода, нужно найти другой способ поддержки хороших версий библиотек и их зависимостей. Например, можно завести единое хранилище, такое как Nexus, Artifactory или репозиторий Debian или RPM. Это хранилище затем необходимо регулярно обновлять, если в репозиториях или в производственных системах будут выявлены уязвимые места.
Распространяйте знания, используя автоматизированные тесты как документацию и механизм обмена опытом
После того как мы создали общие для всей организации библиотеки, стоит заняться быстрым распространением профессиональных компетенций и улучшений. Включение в библиотеки большого количества автоматизированных тестов сделает их самодокументирующимися, и другим инженерам будет легко понять, как они работают.
Если мы внедрили методологию разработки через тестирование (TDD), где тесты пишутся до кода, то такое преимущество мы получим практически без лишних действий. Такой подход превращает наши наборы тестов в актуальную спецификацию системы. Любой сотрудник, желающий понять, как работать с какой-либо системой, может просто взглянуть на набор тестов и увидеть работающие примеры того, как пользоваться API-системой.
В идеале у каждой библиотеки должен быть свой хранитель или своя команда. Они становятся источником знаний о данной библиотеке. Кроме того, в эксплуатации должна использоваться только одна, наилучшая версия библиотеки (в идеальном случае), отражающая накопленные знания и опыт организации.
В этой модели инженер, ответственный за библиотеку, также отвечает и за перевод всех групп, пользующихся его репозиторием, с устаревшей версии на новую. Это, в свою очередь, требует быстрого обнаружения ошибок перехода между версиями библиотеки. Помочь могут исчерпывающее автоматизированное тестирование и непрерывная интеграция для всех систем, использующих ту или иную библиотеку.
Чтобы быстрее распространять знания, можно также создать группы обсуждений или чаты для каждой библиотеки и сервиса. Благодаря этому любой сотрудник, имеющий вопросы, может получить ответ от других пользователей, часто отвечающих быстрее, чем разработчики.
С помощью такого инструмента коммуникации мы облегчаем обмен знаниями и опытом, а сотрудники получают возможность помогать друг другу с проблемами и новыми подходами к разработке.
Определите четкие нефункциональные требования, чтобы при проектировании учитывались пожелания эксплуатации
Когда разработчики следят за судьбой своего продукта после того, как закончили его создание, и участвуют в ликвидации сбоев в производственной среде, сопровождать приложение становится гораздо проще и безопаснее. Кроме того, когда приложения и код сознательно пишутся с расчетом на высокую скорость потока и быстрые развертывания, то появляется возможность сформулировать набор нефункциональных требований, заслуживающих интеграции во все сервисы компании.
Благодаря таким нефункциональным требованиям наши сервисы будет легко развертывать и поддерживать, замечать и решать проблемы будет проще, а при отказе неисправных компонентов система не будет полностью выходить из строя. Примерами нефункциональных требований могут быть:
• достаточный объем производственной телеметрии в приложениях и средах;
• способность четко отслеживать зависимости;
• адаптивные сервисы, способные поддерживать минимум функциональности даже при масштабных сбоях;
• прямая и обратная совместимость между версиями;
• способность архивировать данные для управления размером набора данных в эксплуатации;
• легкий поиск и интерпретация логов всех сервисов;
• способность отслеживать запросы пользователей через большое количество сервисов;
• простая централизованная конфигурация вычислительной среды с флажками элементов функциональности и так далее.
При определении таких типов нефункциональных требований использовать накопленный опыт компании в новых и уже существующих сервисах становится гораздо проще. Ответственность за это лежит на команде, разрабатывающей тот или иной сервис.
Встройте пожелания команд эксплуатации в процесс разработки
Если в эксплуатацию введена работа, не поддающаяся полной автоматизации или неспособная перейти в режим самообслуживания, то ее надо сделать настолько шаблонной и воспроизводимой, насколько возможно. Для этого необходимо стандартизировать эту работу, максимально автоматизировать и тщательно задокументировать весь процесс, чтобы другим командам было проще планировать и выполнять такие действия.
Вместо того чтобы собирать серверы вручную и только потом вводить их в производственную среду в соответствии с чек-листами, нужно автоматизировать эту работу, насколько возможно. Если некоторые действия все равно требуют вмешательства вручную (например, установка и подключение серверов, проводимые другой командой), то нужно четко определить момент перехода задачи к другой группе, чтобы сократить время простоя и уменьшить число ошибок. Все это также поможет планировать такие шаги в будущем. Например, для автоматизации и организации рабочего процесса можно использовать инструменты Rundeck или системы тикетов вроде JIRA или ServiceNow.
В идеале для всех повторяющихся действий в эксплуатации мы должны знать следующее: какое действие нужно произвести, кто для этого нужен, какие шаги требуются для его выполнения и так далее. К примеру, «мы знаем, что релиз стабильной окончательной версии происходит в четырнадцать этапов, требует привлечения четырех команд и последние пять раз в среднем на это требовалось три дня».
Точно так же, как мы реализуем требования заказчиков в разработке, мы можем создать четко определенные «требования инженеров эксплуатации». В них отражаются действия, повторяющиеся во всех проектах (например, развертывание, вопросы безопасности и производительности и так далее). С помощью таких требований мы согласовываем работу отделов разработки и эксплуатации и упрощаем планирование, а также получаем на выходе более стабильные результаты.
Используйте технологии, работающие на достижение целей компании
Когда одна из наших целей — максимизировать продуктивность разработчиков, а архитектура у нас — сервис-ориентированная, то небольшие команды могут писать свои приложения на наиболее подходящем для них языке и в оптимальной среде разработки. В некоторых случаях такой подход лучше всего согласуется с целями компании.
Однако есть ситуации, где происходит обратное, например когда поддержка важного сервиса лежит на одной команде и только она может устранять неполадки и вносить изменения. В результате в системе появляется узкое место. Другими словами, продуктивность команды оптимизирована, но при этом оказалась в противоречии с целями компании.
Такое часто происходит, когда за все аспекты поддержки сервиса отвечает только одна функционально ориентированная группа по эксплуатации. В такой ситуации нужно сделать так, чтобы отдел эксплуатации мог влиять на то, какие компоненты используются в производственной среде, или же снять с них ответственность за неподдерживаемые платформы.
Если у нас нет готового списка поддерживаемых в эксплуатации технологий, составленного при участии отделов разработки и эксплуатации, нужно пройтись по инфраструктуре производственной среды и задействованным в ней сервисам, а также по их текущим зависимостям, чтобы найти компоненты, создающие непропорционально большой риск сбоев или незапланированных работ. Наша цель — определить технологии, которые:
• замедляют или мешают рабочему процессу;
• являются причиной большого количества незапланированной работы;
• являются причиной большого количества запросов на поддержку;
• плохо соответствуют целям в плане характеристик архитектуры (например, производительность, стабильность, безопасность, надежность, бесперебойность работы).
Выводя проблемную инфраструктуру и платформы из сферы ответственности отдела эксплуатации, мы позволяем ему сосредоточиться на технологиях, способствующих достижению целей компании.
Как пишет Том Лимончелли, «когда я работал в Google, у нас был один официальный компилируемый язык, один официальный язык сценариев и один официальный язык пользовательского интерфейса. Да, другие языки тоже так или иначе поддерживались, но, если вы работали с “большой тройкой”, вам было гораздо проще найти нужные библиотеки, инструменты и желающих работать с вами коллег». Эти стандарты укреплялись правилами рецензирования кода, а также тем, какие языки поддерживались внутренними платформами.
Ральф Лура, директор по информационным технологиям компании Hewlett-Packard, в презентации на конференции 2015 DevOps Enterprise Summer, подготовленной совместно с Оливье Жаком и Рафаэлем Гарсиа, отмечал:
«Между собой мы описывали нашу цель как создание “буйков, а не границ”. Вместо того чтобы проводить жесткие границы, за которые никто не должен заступать, с помощью буйков мы обозначаем глубокие места канала, где вы в безопасности и где вас поддержат. Вы можете выплыть за буйки в том случае, если вы продолжаете следовать принципам организации. В конце концов, как мы создадим новую инновацию, помогающую достичь успеха, если мы не исследуем неизвестное и не работаем на самой границе? Как лидеры мы должны размечать фарватер, способствовать судоходству и позволять “матросам” исследовать то, что лежит за пределами обитаемых земель».
Практический пример
Стандартизация нового стека технологий в Etsy (2010 г.)
Во многих компаниях, переходящих на DevOps, разработчики часто рассказывают, что «инженеры эксплуатации не предоставляли нам того, что мы просили, поэтому нужные нам системы мы создали и поддерживали сами». Однако в компании Etsy на ранних стадиях трансформации руководство поступило наоборот, сильно сократив число технологий, поддерживаемых в эксплуатации.
В 2010 г., после провальных результатов пиковой нагрузки, приходящейся на рождественские праздники, команда Etsy решила значительно уменьшить количество технологий, использовавшихся в эксплуатации, выбрав те, которые могли поддерживаться во всей организации, и избавившись от всех остальных.
Их целью было стандартизировать и сознательно уменьшить инфраструктуру и число конфигураций. Одним из первых было принято решение перевести всю среду Etsy на PHP и MySQL. Это было скорее философское решение, чем технологическое — в компании хотели, чтобы и в разработке, и в эксплуатации разбирались во всем стеке технологий, чтобы все могли работать в одной среде, а также читать, переписывать и исправлять чужой код. За несколько лет, как вспоминает Майкл Рембетси, тогдашний директор по эксплуатации, «мы отправили на пенсию несколько отличных технологий, полностью выведя их из эксплуатации», в том числе lighttp, Postgres, MongoDB, Scala, CoffeeScript, Python и многие другие.
Дэн Маккинли, разработчик, первым начавший использовать MongoDB в Etsy, пишет в своем блоге, что все преимущества бессхемной базы данных перечеркивались проблемами ее эксплуатации. Здесь были и проблемы логирования, составления графиков, мониторинга, производственной телеметрии, создания резервных копий данных и их восстановления, а также многие другие проблемы, о которых разработчики обычно не должны думать. В итоге от MongoDB в компании полностью отказались и все новые сервисы создавались на основе поддерживаемой инфраструктуры баз данных MySQL.
Заключение
Методики, описанные в этой главе, позволяют включить любой новый опыт в коллективное хранилище знаний организации, приумножая его положительный эффект. Это достигается благодаря активному и широкому распространению новых знаний, например с помощью чатов, подхода к архитектуре как к коду, общих репозиториев, стандартизации технологий и так далее. Благодаря такому подходу мы улучшаем практические достижения не только в разработке и в эксплуатации, но и во всей компании, потому что теперь у всех сотрудников есть доступ ко всему накопленному опыту организации.
