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

Вслед за этим событием последовало множество домыслов о том, как 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 — далеко не единственный пример того, как обучение можно интегрировать в повседневную деятельность. Эта история также показывает, как ориентированные на обучение компании думают о неудачах, провалах и ошибках: здесь есть возможность научиться чему-то новому, а не найти, за что следует наказывать. В этой главе мы изучим, как создать ориентированную на обучение систему и развить культуру беспристрастности, а также как регулярно репетировать неполадки и намеренно создавать сбои, чтобы ускорить обучение.

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

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

Деккер называет желание избавиться от ошибок, избавившись от людей, совершивших эти ошибки, теорией плохого яблока . Он утверждает, что это неверный подход, потому что «человеческие ошибки — не причина наших проблем, а следствие проектирования инструментов, которые мы дали людям».

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

Превращая информацию в знание и встраивая результаты обучения в наши системы, мы строим культуру беспристрастности, уравновешивая потребность в безопасности и ответственность. Как утверждает Джон Оллспоу, главный технический директор компании Etsy, «наша цель в Etsy — смотреть на ошибки, промахи, неудачи, провалы и тому подобное с точки зрения обучения».

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

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

Чтобы развить в организации культуру беспристрастности, после аварий и значительных инцидентов (например, после неудачного развертывания или проблемы в эксплуатации, повлиявшей на клиентов), когда последствия сбоя уже устранены, нужно провести «послеаварийную ретроспективу» (blameless post-mortem) [145]. Разбор ошибок без поиска виноватых (автор термина — Джон Оллспоу) помогает изучить «ошибки так, чтобы сфокусироваться на ситуационных аспектах механизма сбоя и на процессе принятия решений у человека, стоявшего ближе всех к сбою».