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

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

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

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

Яркий пример отказоустойчивости, возникающей из следования этим принципам и методикам, продемонстрировал 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, постоянно и в случайном порядке выводивший из строя серверы. Создатели хотели, чтобы все «команды инженеров привыкли к определенному количеству неполадок в облаке» и чтобы сервисы могли «автоматически восстанавливаться без вмешательства вручную».

Другими словами, с помощью Chaos Monkey и регулярных намеренных сбоев команда Netflix обрела уверенность, что цели адаптировать систему достигнуты.

Как можно было ожидать, во время первого запуска Chaos Monkey в эксплуатационном окружении сервисы выходили из строя так, как никто не мог предсказать и вообразить. Постоянно находя и устраняя эти проблемы во время обычных рабочих часов, инженеры Netflix быстро создали более устойчивый сервис и в то же время получили новый опыт (и это в рабочее время!), позволивший развить свои системы далеко за пределы того, что могли их конкуренты.

Chaos Monkey — далеко не единственный пример того, как обучение можно интегрировать в повседневную деятельность. Эта история также показывает, как ориентированные на обучение компании думают о неудачах, провалах и ошибках: здесь есть возможность научиться чему-то новому, а не найти, за что следует наказывать. В этой главе мы изучим, как создать ориентированную на обучение систему и развить культуру беспристрастности, а также как регулярно репетировать неполадки и намеренно создавать сбои, чтобы ускорить обучение.