Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

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

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

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

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

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

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

Глава 19. Внедрите обучение в повседневную работу

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

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

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

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

Вслед за этим событием последовало множество домыслов о том, как Netflix смог удержать свои сервисы в рабочем состоянии. Популярная теория гласит, что, поскольку компания — один из крупнейших клиентов Amazon Web Services, у нее было привилегированное положение, что и позволило ей выстоять. Однако пост в блоге Netflix Engineering разъяснил, что причиной такой адаптивности компании оказались некоторые решения в планировании архитектуры, принятые еще в 2009 г.

В 2008 г. сервис поставки видео в режиме онлайн в Netflix работал на неделимом J2EE-приложении[144], расположенном в одном из его дата-центров. Однако начиная с 2009 г. компания начала перестраивать архитектуру системы, адаптировав ее целиком под облачные технологии (cloud native): она была спроектирована так, чтобы работать в общедоступном облаке Amazon и быть достаточно гибкой, чтобы не падать при масштабных сбоях.

Одной из конкретных целей при планировании системы было условие, чтобы сервисы Netflix продолжали работать, даже если выйдет из строя вся зона доступности AWS, что и произошло с зоной US-EAST. Для этого архитектура системы должна была быть слабо связанной, а у каждого компонента должно было быть четкое время ожидания, чтобы из-за сбоя одного элемента не рухнула вся система. Вместо этого каждый элемент функциональности был спроектирован так, чтобы плавно деградировать производительность системы. Например, во время резкого увеличения трафика, создавшего повышенную нагрузку на CPU, персонализированная подборка рекомендуемых фильмов заменялась на статичное содержание — кэшированные или среднестатистические результаты, требующие гораздо меньших вычислений.

Кроме того, в посте блога рассказывалось, что, помимо внедрения новых архитектурных шаблонов, также построили и запустили неожиданный и дерзкий сервис Chaos Monkey, симулирующий сбои AWS, постоянно и в случайном порядке выводивший из строя серверы. Создатели хотели, чтобы все «команды инженеров привыкли к определенному количеству неполадок в облаке» и чтобы сервисы могли «автоматически восстанавливаться без вмешательства вручную».