Джин Ким - Руководство по DevOps

«Пока это предложение рассматривалось, я хотела понять, почему процесс TEAP-LARB занимает столько времени, и я использовала методику “пяти почему”… Она в конце концов привела меня к вопросу, зачем вообще нужен TEAP-LARB. Удивительно, но никто не мог на него ответить, кроме разве что расплывчатых соображений о том, что нам нужен какой-то контроль. Многие знали, что несколько лет назад произошла какая-то катастрофа и она ни за что не должна повториться снова. Но никто не мог точно вспомнить, что же это была за катастрофа».

Микман отмечает, что проходить через этот процесс ее группе было необязательно, если они соглашались быть ответственными за поддержание новой технологии. Она также добавляет: «Я дала всем знать, что все новые технологии, поддержанные моей командой, согласовывать с TEAP-LARB не нужно».

В результате систему управления базами данных Cassandra в Target успешно внедрили. Более того, процесс TEAP-LARB впоследствии был отменен. В благодарность за устранение барьеров для введения новых технологий команда Хизер Микман вручила ей награду за профессиональные достижения.

В этой главе мы обсудили, как вводить в работу новые методики, повышающие качество вносимых изменений, сокращающие риск неудачных развертываний и уменьшающие зависимость от процессов согласования и одобрения изменений. Примеры из практики компаний GitHub и Target показывают: эти методики не только улучшают наши результаты, но также значительно сокращают время на создание продуктов и увеличивают производительность разработчиков. Для всего этого требуется культура высокого доверия.

Вот история об одном младшем инженере, рассказанная Джоном Оллспоу. Этот инженер спросил, можно ли отправить в развертывание небольшую правку в HTML-коде, и Оллспоу ответил: «Я не знаю». Затем он спросил: «Кто-нибудь просмотрел твой код? Ты знаешь, кого лучше всего спрашивать об изменениях такого типа? Сделал ли ты все возможное, чтобы досконально убедиться, что эти изменения будут вести себя в эксплуатации именно так, как и планировалось? Если да, то не спрашивай меня — просто внеси правки, и все».

Таким ответом Оллспоу напомнил инженеру, что за качество изменений отвечает только он сам: если она сделал все, что мог, чтобы убедиться в том, что все работает правильно, тогда ему не нужно было просить одобрения, он мог просто внести свои правки.

Создание условий, когда авторы идей сами отвечают за их качество, — важная часть производительной культуры высокого доверия. Ее мы и хотим построить. Кроме того, такие условия позволяют создать более безопасную систему, где все помогают друг другу достичь целей, преодолевая любые препятствия.

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

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

В части III, мы обсудили то, как использовать методики создания быстрого течения в потоке ценности. В части IV «Второй путь: методики обратной связи» нашей целью было создать как можно больше обратной связи — раньше, быстрее, дешевле, — покрывающей как можно больше частей нашей системы.

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

В следующих главах мы введем ритуалы, усиливающие безопасность и поощряющие непрерывное обучение и введение улучшений с помощью таких шагов, как:

• установление беспристрастной культуры, чтобы сотрудники чувствовали себя в безопасности;

• намеренное создание сбоев, чтобы улучшить способности к восстановлению;

• трансформация локальных открытий в глобальные улучшения;

• выделение времени на создание улучшений и новых знаний на уровне всей компании.

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

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

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

Такие организации доктор Стивен Спир называет эластичными. Они способны исцелять сами себя. «Для таких компаний реагирование на кризисы не есть нечто редкое и специфическое. Этим они занимаются все время. Таков источник их устойчивости».

Яркий пример отказоустойчивости, возникающей из следования этим принципам и методикам, продемонстрировал Netflix. 21 апреля 2011 г. вся зона доступности AWS US-EAST компании Amazon вышла из строя, захватив с собой всех зависящих от нее клиентов организации, включая Reddit и Quora [143]. Netflix, однако, оказался неожиданным исключением: казалось, что масштабный сбой AWS его не затронул.