В 2008 г. сервис поставки видео в режиме онлайн в Netflix работал на неделимом J2EE-приложении[144], расположенном в одном из его дата-центров. Однако начиная с 2009 г. компания начала перестраивать архитектуру системы, адаптировав ее целиком под облачные технологии (cloud native): она была спроектирована так, чтобы работать в общедоступном облаке Amazon и быть достаточно гибкой, чтобы не падать при масштабных сбоях.
Одной из конкретных целей при планировании системы было условие, чтобы сервисы Netflix продолжали работать, даже если выйдет из строя вся зона доступности AWS, что и произошло с зоной US-EAST. Для этого архитектура системы должна была быть слабо связанной, а у каждого компонента должно было быть четкое время ожидания, чтобы из-за сбоя одного элемента не рухнула вся система. Вместо этого каждый элемент функциональности был спроектирован так, чтобы плавно деградировать производительность системы. Например, во время резкого увеличения трафика, создавшего повышенную нагрузку на CPU, персонализированная подборка рекомендуемых фильмов заменялась на статичное содержание — кэшированные или среднестатистические результаты, требующие гораздо меньших вычислений.
Кроме того, в посте блога рассказывалось, что, помимо внедрения новых архитектурных шаблонов, также построили и запустили неожиданный и дерзкий сервис Chaos Monkey, симулирующий сбои AWS, постоянно и в случайном порядке выводивший из строя серверы. Создатели хотели, чтобы все «команды инженеров привыкли к определенному количеству неполадок в облаке» и чтобы сервисы могли «автоматически восстанавливаться без вмешательства вручную».
Другими словами, с помощью Chaos Monkey и регулярных намеренных сбоев команда Netflix обрела уверенность, что цели адаптировать систему достигнуты.
Как можно было ожидать, во время первого запуска Chaos Monkey в эксплуатационном окружении сервисы выходили из строя так, как никто не мог предсказать и вообразить. Постоянно находя и устраняя эти проблемы во время обычных рабочих часов, инженеры Netflix быстро создали более устойчивый сервис и в то же время получили новый опыт (и это в рабочее время!), позволивший развить свои системы далеко за пределы того, что могли их конкуренты.
Chaos Monkey — далеко не единственный пример того, как обучение можно интегрировать в повседневную деятельность. Эта история также показывает, как ориентированные на обучение компании думают о неудачах, провалах и ошибках: здесь есть возможность научиться чему-то новому, а не найти, за что следует наказывать. В этой главе мы изучим, как создать ориентированную на обучение систему и развить культуру беспристрастности, а также как регулярно репетировать неполадки и намеренно создавать сбои, чтобы ускорить обучение.