Книга: Руководство по DevOps

Создайте ритуалы для погашения технического долга

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

Помимо таких терминов бережливого производства, как kaizen-blitz и блиц-обучение, методика ритуалов по улучшению работы также называется весенней или осенней генеральной уборкой (spring или fall cleaning) или неделями инверсии очереди задач (ticket queue inversion weeks). Иногда используются и другие термины, например хакатон (hack day, hackaton) или 20 % времени на инновации (20 % innovation time). К сожалению, конкретные ритуалы часто предназначены для совершенствования готовых продуктов и создания прототипов новых продуктов, а не для улучшения повседневной работы и, что еще хуже, методики используют только разработчики, что очень далеко от целей блиц-обучения[159].

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

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

Сила блиц-обучений в том, что они вдохновляют непрерывно выявлять и решать проблемы без посторонних стимулов. Представьте, что наша сложная система — это паутина, переплетающиеся в ней нити постоянно ослабевают и рвутся. Если порвется определенная комбинация отдельных нитей, то всей паутине придет конец. Нет управления сверху, чтобы указывать рабочим, какие нити и в каком порядке нужно чинить. Вместо этого нужно создать организационную культуру и нормы, побуждающие сотрудников самим находить и исправлять слабые места системы в процессе ежедневной работы. Как отмечает Спир, «неудивительно, что пауки заделывают разрывы в паутине, как только они появляются, а не ждут, когда их станет слишком много».

Хороший пример успешного воплощения блиц-обучений описан Марком Цукербергом, генеральным директором Facebook. В интервью Джессике Стиллман, размещенном на сайте Inc.com, он рассказывает: «Каждые несколько месяцев мы проводим хакатон, где все желающие создают прототипы для новых идей. В конце мероприятия вся команда собирается вместе и смотрит, что получилось. Многие из наших самых успешных продуктов появились именно во время хакатонов, в том числе Timeline, чат, видео, среда разработки для мобильных приложений и некоторые компоненты инфраструктуры, например компилятор HipHop».

Компилятор PHP HipHop особенно интересен. В 2008 г. у Facebook появились серьезные проблемы с работоспособностью: число активных пользователей превысило отметку в 100 миллионов и продолжало расти, из-за чего у технических служб были большие проблемы. Во время хакатона Хайпин Жао, старший инженер по работе с серверами в Facebook, начал экспериментировать с конвертацией кода на PHP в компилируемый код на C++, надеясь увеличить работоспособность их инфраструктуры. За следующие два года небольшая команда создала то, что потом будем названо компилятором HipHop, и перевела все сервисы Facebook с интерпретируемого PHP-кода в компилируемые двоичные файлы на C++. Новый компилятор позволил платформе Facebook выдерживать в шесть раз большие нагрузки, чем раньше.

В интервью с Кейдом Метцем, журналистом издания Wired, Дрю Пароски, один из инженеров, работавших над проектом, отметил: «Был такой момент, когда, если бы не HipHop, мы оказались бы в очень сложной ситуации. Чтобы обслуживать сайт, нам понадобилось бы больше машин, чем имелось на тот момент. Это был отчаянный шаг, но он сработал».

Позже Пароски и его коллеги Кейт Адамс и Джейсон Эванс решили, что могут улучшить производительность компилятора HipHop и убрать некоторые ограничения, снижавшие производительность разработчиков. В результате появился проект виртуальной машины HipHop (HHVM), использовавшей принцип динамической компиляции. К 2012 г. HHVM полностью заменила HipHop в эксплуатации. В разработке проекта приняло участие около 20 инженеров.

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

Оглавление книги