Глава 19. Внедрите обучение в повседневную работу
Когда мы работаем в сложной системе, предсказать все последствия наших действий невозможно. Часто это приводит к неожиданным и иногда катастрофическим последствиям, даже если мы пользуемся мерами предосторожности, например чек-листами или документацией, где фиксируем понимание системы на данный момент.
Для безопасной работы над сложными системами, организации должны совершенствовать процессы самодиагностики и внутренних улучшений, а также иметь развитые навыки обнаружения и устранения проблем. Это создает динамическую систему обучения, позволяющую понимать причины ошибок и переводить понимание в действия, предотвращающие повторение таких ошибок в будущем.
Такие организации доктор Стивен Спир называет эластичными. Они способны исцелять сами себя. «Для таких компаний реагирование на кризисы не есть нечто редкое и специфическое. Этим они занимаются все время. Таков источник их устойчивости».
Яркий пример отказоустойчивости, возникающей из следования этим принципам и методикам, продемонстрировал Netflix. 21 апреля 2011 г. вся зона доступности AWS US-EAST компании Amazon вышла из строя, захватив с собой всех зависящих от нее клиентов организации, включая Reddit и Quora. Netflix, однако, оказался неожиданным исключением: казалось, что масштабный сбой AWS его не затронул.
Вслед за этим событием последовало множество домыслов о том, как Netflix смог удержать свои сервисы в рабочем состоянии. Популярная теория гласит, что, поскольку компания — один из крупнейших клиентов Amazon Web Services, у нее было привилегированное положение, что и позволило ей выстоять. Однако пост в блоге Netflix Engineering разъяснил, что причиной такой адаптивности компании оказались некоторые решения в планировании архитектуры, принятые еще в 2009 г.
В 2008 г. сервис поставки видео в режиме онлайн в Netflix работал на неделимом J2EE-приложении, расположенном в одном из его дата-центров. Однако начиная с 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). Разбор ошибок без поиска виноватых (автор термина — Джон Оллспоу) помогает изучить «ошибки так, чтобы сфокусироваться на ситуационных аспектах механизма сбоя и на процессе принятия решений у человека, стоявшего ближе всех к сбою».
Для этого мы проводим совещание как можно быстрее после инцидента и до того, как связи между причинами и следствиями исчезнут из памяти или изменятся обстоятельства (конечно, мы ждем до того момента, когда проблема будет устранена, чтобы не отвлекать тех, кто над ней еще работает).
Во время совещания по разбору ошибок мы делаем следующее:
• воссоздаем хронологическую последовательность и собираем детали с разных точек зрения о том, как произошел сбой, проверяя, что мы при этом никак никого не наказываем;
• мотивируем всех инженеров улучшать безопасность, побуждая их давать подробные описания того, как их действия способствовали возникновению сбоя;
• поощряем людей, совершающих ошибки, становиться экспертами, показывающими остальным, как избежать этих ошибок в будущем;
• допускаем, что всегда есть ситуации, где люди могут действовать только по своему усмотрению, а оценить эти действия можно только в ретроспективе;
• предлагаем ответные меры, чтобы предотвратить похожие сбои в будущем, и проверяем, что для этих мер записана целевая дата и определен ответственный.
Чтобы лучше понять, что же на самом деле произошло, на совещании должны присутствовать следующие участники:
• принимавшие решения, имеющие отношение к проблеме;
• обнаружившие проблему;
• устранявшие проблему;
• диагностировавшие проблему;
• пострадавшие от проблемы;
• все остальные заинтересованные в разборе проблемы.
Первая задача во время совещания — восстановить цепочку событий, имевших отношение к сбою. Сюда включаются все наши действия и время их совершения (в идеале — подкрепленные логами чатов, например IRC или Slack), то, какие эффекты мы наблюдали (в идеале — в виде конкретной телеметрии, а не в виде субъективного изложения фактов), все рассмотренные нами пути исследования проблемы и предложенные способы решения.
Для такого анализа мы должны скрупулезно фиксировать детали и укреплять культуру, предполагающую возможность делиться информацией без страха наказания. Поэтому будет хорошо, особенно для первых совещаний, если встречи будет вести специально обученный посредник, никак не связанный с возникшей проблемой.
Во время совещания и последующего решения вопроса нужно запретить употребление фраз «мог бы» и «должен был», так как это контрфактуальные высказывания, возникающие из свойства человеческого мышления создавать альтернативные варианты уже происшедших событий.
Контрфактуальные утверждения, такие как «Я мог бы…» или «Если бы я знал об этом, я бы…», формулируют проблему в терминах воображаемой системы, а не в терминах системы, существующей на самом деле, которой мы и должны себя ограничивать (см. ).
Один из возможных неожиданных результатов таких встреч — сотрудники часто станут винить себя за то, что оставалось вне их контроля, или сомневаться в своих способностях. Йен Малпасс, инженер Etsy, замечает: «Когда мы делаем что-то такое, отчего весь сайт вдруг перестает работать, все внутри стынет, как от прыжка в ледяную воду. Наверное, первая мысль у всех — “Я неудачник, я понятия не имею, что делаю”. Надо это прекратить, такие мысли — путь к отчаянию, сумасшествию и ощущению себя обманщиком. Нельзя допускать, чтобы хорошие инженеры так о себе думали. Гораздо лучший вопрос: “Почему тогда это казалось мне правильным?”»
Во время совещаний мы должны выделить достаточно времени на мозговой штурм и на выбор ответных мер. Когда контрмеры определены, нужно определить их приоритет, составить план выполнения и выбрать ответственного за их воплощение в жизнь. Все это показывает, что мы ценим улучшение повседневной работы больше, чем ее саму.
Дэн Мильстейн, один из ведущих инженеров Hubspot, пишет, что он начинает совещания по разбору ошибок со слов: «Давайте попытаемся подготовиться к такому будущему, где мы такие же тупые, как сегодня». Другими словами, контрмера «быть осторожнее» или «быть не такими глупыми» — плохая, вместо этого мы должны разработать реальные контрмеры, чтобы подобные ошибки больше не повторялись.
Примерами контрмер могут быть автоматизированные тесты для обнаружения опасных состояний в цикле развертывания, добавление новой телеметрии, определение категорий изменений, подразумевающих дополнительное рецензирование коллегами, и проведение репетиций сбоев во время регулярных упражнений игровых дней.
Распространяйте информацию с разбора ошибок как можно шире
Проведя совещание по разбору ошибок, нужно сообщить всем о доступности записей со встречи и других документов (например, записей о восстановленном ходе событий, логов IRC-чата, внешних контактов). Эта информация в идеале должна находиться в централизованном месте, где все сотрудники компании могут получить к ней доступ и извлечь пользу и новые знания из произошедшего сбоя. Проведение совещаний с разбором ошибок настолько важно, что можно даже приостановить полное устранение инцидента до того, как будет завершен анализ сбоя.
Такой подход помогает распространять локальные улучшения и опыт по всей компании. Рэнди Шуп, бывший технический директор Google App Engine, описывает то, как документация совещаний по разбору ошибок может иметь огромную ценность для организации: «Как вы можете догадаться, в Google вся информация доступна. Все документы с разбора причин сбоев находятся в местах, где их могут видеть все сотрудники. И поверьте мне, когда у какой-то группы происходит авария, похожая на то, что уже когда-то было, эти документы читаются и изучаются в первую очередь».
Широкое распространение результатов анализа ошибок и поощрение знакомства с ними увеличивают суммарные знания компании. Кроме того, среди организаций, занимающихся онлайн-услугами, все более распространенными становятся публикации разборов инцидентов, повлиявших на клиентов. Это часто сильно увеличивает прозрачность работы компании для внутренних и внешних клиентов и, в свою очередь, повышает доверие к нам.
Стремление проводить как можно больше совещаний по разбору ошибок привело компанию Etsy к некоторым проблемам: за четыре года в базе организации накопилось огромное число заметок со встреч. Искать информацию, сохранять новые данные и работать с базой знаний стало очень трудно.
Чтобы справиться с проблемой, в компании придумали инструмент под названием Morgue, позволяющий легко фиксировать аспекты каждого сбоя, например его MTTR и степень серьезности, лучше работать с разными часовыми поясами (это стало важно, потому что многие сотрудники Etsy начали работать удаленно) и включать в отчеты другие данные, например текст в формате Markdown, изображения, теги и историю.
Приложение Morgue было разработано для того, чтобы команде было легко фиксировать:
• возникла ли проблема из-за запланированного или незапланированного инцидента;
• кто ответствен за разбор ошибок;
• важные логи IRC-чата (особенно важно для проблем, возникших в три часа ночи, когда точное фиксирование деталей может не произойти);
• важные тикеты JIRA для корректирующих действий и дедлайны по ним (эта информация особенно важна для менеджмента);
• ссылки на форумные посты клиентов (где клиенты жалуются на проблемы).
После разработки и использования Morgue число фиксируемых разборов в Etsy сильно увеличилось по сравнению с тем временем, когда они использовали страницы специальной вики, особенно для инцидентов P2, P3 и P4 (то есть инцидентов с низким уровнем серьезности). Этот результат подтвердил гипотезу, что если документировать разбор ошибок с помощью инструментов типа Morgue станет проще, то больше специалистов начнут записывать и детализировать результаты совещаний, и накопленный опыт организации увеличится.
Эми Эдмондсон, профессор управления и менеджмента Гарвардской школы бизнеса и соавтор книги Building the Future: Big Teaming for Audacious Innovation, пишет:
Путь решения проблемы, не обязательно требующий больших затрат времени и денег, — избавиться от предрассудков в отношении ошибок. Эли Лилли делает это еще с ранних 1990-х: она устраивает «вечеринки неудачников», чтобы отметить умные, высококачественные научные эксперименты, закончившиеся неудачей. Эти вечеринки обходятся недорого, а перераспределение ценных ресурсов — а именно ученых — на новые проекты раньше, чем обычно, может сэкономить сотни тысяч долларов, не говоря уже о возможных стимулах для новых открытий.
Уменьшите стандартные отклонения, чтобы улавливать слабые сигналы о возможных сбоях
Когда организации учатся эффективно диагностировать и решать проблемы, то, чтобы не останавливаться в развитии, они неизбежно расширяют понятие того, что считать проблемой. Для этого нужно научиться усиливать слабые сигналы о возможных неполадках. Например, как было описано в части IV, к тому моменту, когда компания Alcoa смогла существенно сократить количество несчастных случаев на производстве, Пол О’Нил, CEO Alcoa, начал получать отчеты не только о реально произошедших несчастных случаях, но и о потенциально аварийных ситуациях.
Доктор Стивен Спир резюмирует достижения О’Нила, отмечая: «Хотя все началось с проблем безопасности труда, в компании быстро обнаружили, что эти проблемы отражали общее невежество в отношении процессов производства, и эта невежественность проявлялась в других проблемах, связанных с качеством, своевременностью работы и количеством брака».
Когда мы работаем в сложных системах, необходимость усиливать слабые сигналы очень важна, чтобы избежать катастрофических последствий. Прекрасный пример — как NASA использовала сигналы о неполадках в эпоху космических шаттлов. В 2003 г., на шестнадцатый день полета космического шаттла Columbia, он взорвался при входе в атмосферу. Сейчас известно, что это произошло из-за того, что во время взлета от внешнего топливного бака оторвался кусок теплоизоляционной пены.
Незадолго до входа шаттла в атмосферу несколько инженеров NASA среднего звена сообщили об этом инциденте, но их не услышали. Во время послестартового анализа инженеры заметили на видеозаписи, что отпавший кусок теплоизоляции повредил теплоизоляцию на крыле, и оповестили об этом менеджеров NASA, но им ответили, что проблемы с теплоизоляцией бывают часто. Смещение изоляционной пены повреждало шаттлы и во время предыдущих запусков, но это никогда не приводило к авариям. Считалось, что это проблема технического обслуживания, не стоит из-за нее принимать специальных мер.
Майкл Роберто, Ричард Бомер и Эми Эдмондсон в статье 2006 г. для Harvard Business Review писали, что культура NASA стала одной из причин катастрофы. Они описывали две типичные структуры организаций: стандартизированная модель, где всем управляют установившиеся практики и системы и где жестко соблюдают сроки и бюджеты, и экспериментальная модель, где каждый день каждую задачу и каждую крупицу новой информации оценивают и обсуждают в атмосфере, напоминающей научно-исследовательскую и конструкторскую (R&D) лабораторию.
Они также отмечают: «Фирмы сами навлекают на себя неприятности, принимая неправильный образ мышления, диктующий, как реагировать на неоднозначные угрозы или, в терминах этой книги, на слабые сигналы о неполадках… К 1970 г. NASA создала культуру с жесткой стандартизацией, рекламируя Конгрессу шаттлы как дешевый и многоразовый космический корабль». Вместо экспериментальной модели, где каждый факт должен был оцениваться без предвзятости, в NASA предпочитали четкое следование процедурам. Отсутствие непрерывного обучения и экспериментирования привело к катастрофическим последствиям. Авторы резюмируют: важны именно культура и образ мыслей, а не просто «необходимость быть осторожным», «бдительность сама по себе не может помешать неоднозначным слабым сигналам о неполадках перерасти в дорогостоящие (а иногда и трагичные) ошибки».
Работа в технологическом потоке ценности, например связанном с космическими технологиями, должна восприниматься как принципиально экспериментальное занятие, и управляться она должна соответственно. Вся сделанная работа — это новая потенциально важная гипотеза и источник данных, а не рутинное воспроизведение и подтверждение прежних методов. Вместо того чтобы считать технологическую работу полностью стандартизованной, когда все стремятся к слепому следованию установленным процедурам, нужно постоянно выявлять все более слабые сигналы о возможных сбоях, чтобы лучше понять системы и управлять ими.
Переопределите понятие ошибки и поощряйте взвешенный риск
Руководители компаний, сознательно или нет, своими действиями укрепляют организационную культуру и ее ценности. Эксперты по аудиту, бухгалтерскому учету и этике давно заметили, что взгляды «верхушки» предопределяют вероятность мошенничества или других недобросовестных действий. Чтобы укрепить культуру обучения и взвешенных рисков, руководители должны постоянно следить, чтобы сотрудники не боялись ошибок, но в то же время чувствовали себя ответственными за их исправление и за получение нового опыта.
Говоря об ошибках, Рой Рапопорт из Netflix замечает: «Что доклад 2014 State of DevOps Report доказал мне, так это то, что высокоэффективные DevOps-организации совершают ошибки чаще. Это не только нормально, это как раз то, что компаниям и нужно! Если высокоэффективные компании работают в 30 раз быстрее и при этом уровень сбоев в два раза ниже, очевидно же, что общее число сбоев там выше».
Далее он продолжает: «Я как-то говорил с одним коллегой о недавнем масштабном сбое у нас в Netflix, он произошел, честно говоря, из-за глупейшей ошибки. На самом деле сбой случился из-за одного инженера, за последние 18 месяцев уже дважды полностью выводившего Netflix из строя. Но, конечно, мы его ни за что не уволили бы. За те же 18 месяцев этот инженер продвинул уровень наших эксплуатации и автоматизации вперед не на километры, а на световые годы. Его работа позволила нам безопасно делать развертывания каждый день, и он сам лично провел огромное число развертываний кода».
Рапопорт заключает: «В DevOps должно быть место для таких инноваций и для вытекающего из них риска ошибок. Да, в эксплуатации у вас будет больше сбоев. Но это хорошо, за это нельзя наказывать».
Устраивайте намеренные сбои, чтобы укрепить адаптивность и улучшить обучение
Как мы видели во введении к этой главе, намеренное создание неполадок в среде эксплуатации (например, с помощью Chaos Monkey) — один из способов укрепления адаптивности к сбоям. В этой части мы опишем процессы симуляции и введения сбоев в систему, чтобы удостовериться, что наши системы спроектированы и выстроены правильно, а неполадки контролируемы и происходят, как запланировано. Для этого мы регулярно (или даже непрерывно) будем проводить тесты, чтобы убедиться: системы выходят из строя плавно и предсказуемо.
Как пишет Майкл Нейгард, автор книги Release It! Design and Deploy Production-Ready Software, «Подобно тому как в машины встраивают зоны смятия, чтобы при аварии пассажиры оставались в безопасности, вы можете определить, какие элементы системы важнее всего, и спроектировать режимы отказа, способные держать трещины подальше от этих элементов. Если вы специально не определяете режимы отказа, то результат будет непредсказуемым — и, как правило, опасным».
Адаптивность требует, чтобы мы сначала продумали режимы отказа и затем протестировали, работают ли они так, как нам нужно. Один из способов проделать это — специально создавать сбои в эксплуатационной среде и репетировать масштабные аварии, чтобы убедиться, что мы можем быстро восстановиться после инцидентов, когда они на самом деле произойдут, в идеале — так, чтобы клиенты этого не заметили.
История Netflix и сбоя Amazon AWS-EAST в начале этой главы — не единственный пример. Еще более интересный пример адаптивности Netflix произошел во время «Великой перезагрузки Amazon 2014», когда почти 10 % всех серверов EC2 Amazon пришлось перезагрузить, чтобы срочно установить обновление для системы безопасности Xen. Кристос Каланцис, специалист по конструированию облачных баз данных в Netflix, вспоминает: «Когда мы узнали о срочной перезагрузке EC2, у нас отвисла челюсть. Когда мы получили список того, сколько серверов Cassandra будут затронуты этим, мне стало плохо». Каланцис продолжает: «Потом я вспомнил все тренировки с Chaos Monkey. Моя реакция была: “Ну же, давайте!”»
И опять результаты оказались поразительными. Из более чем 2700 узлов Cassandra, используемых в эксплуатации, 218 были перезагружены, а перезагрузка 22 закончилась неудачей. Каланцис и Брюс Вонг, занимающийся проектированием хаоса (Chaos Engineering), писали: «В те выходные Netflix был недоступен ровно ноль секунд. Регулярные и постоянные упражнения в устранении сбоев, даже на уровне баз данных, должны быть частью плана по развитию адаптивности каждой компании. Если бы Cassandra не участвовала в тренировках Chaos Monkey, эта история закончилась бы совсем по-другому».
Что еще более удивительно, в те выходные не только в Netflix никто не работал над устранением инцидентов из-за сбоев узлов Cassandra, никого вообще не было в офисе — все сотрудники были в Голливуде, где отмечали завершение очередного этапа работ. Это еще один пример того, как благодаря проактивному фокусированию на адаптивности то, что для одних компаний могло оказаться серьезным кризисом, для других — всего лишь еще один обычный рабочий день (cм. ).
Устраивайте Game Days, чтобы репетировать неполадки
В этой части мы опишем специальные тренировки восстановления после аварий. Они называются игровыми днями (Game Days). Этот термин придуман Джессом Роббинсом, одним из основателей сообщества Velocity Conference и сооснователем компании Chef, и стал популярен благодаря его работе в компании Amazon, где он отвечал за программы по обеспечению доступности сайтов и где его называли «мастером аварий». Идея игровых дней появилась из такого направления, как адаптивное проектирование (resilience engineering). Роббинс определяет адаптивное проектирование как «тренировку, направленную на увеличение адаптивности с помощью намеренных масштабных сбоев во всех критических системах».
Роббинс отмечает, что, «когда вы собираетесь спроектировать машстабируемую систему, лучшее, на что вы можете надеяться, — это надстроить надежную платформу над абсолютно ненадежными компонентами. Из-за этого вы оказываетесь в ситуации, где сложные сбои неизбежны и непредсказуемы».
Следовательно, мы должны обеспечить бесперебойную работу сервисов во время аварий, теоретически во всей системе, в идеале — без кризисного вмешательства (или вручную). Как шутит Роббинс, «сервис протестирован только тогда, когда мы ломаем его в эксплуатации».
Цель Game Days — помочь командам симулировать и репетировать сбои, чтобы у них была возможность практиковаться. Сначала мы планируем катастрофическое событие, например разрушение целого дата-центра. Потом мы даем командам время на подготовку, устранение всех возможных точек отказа и создание необходимых процедур наблюдения, перехода на другие ресурсы и так далее.
Команда Game Day определяет и проводит тестовые задания, например проверяет переключение баз данных (то есть симулирует отказ первичной базы данных и переключение на вторую базу) или отключает важное сетевое соединение, чтобы выявить проблемы в каком-либо из анализируемых процессов. Все обнаруженные проблемы и сложности анализируются, устраняются и снова тестируются.
В запланированный момент мы устраиваем сбой. Как это описывает Роббинс, в Amazon они «буквально отключали питание устройств — без предупреждения — и затем позволяли системам выходить из строя естественным образом, а сотрудникам — следить за этими процессами, независимо от того, как они бы стали развиваться».
Такой подход помогает нам выявлять скрытые дефекты наших систем. Они оказываются доступны для наблюдения только благодаря намеренному внесению сбоев в системы. Роббинс объясняет: «Вы можете обнаружить, что некоторые системы наблюдения или управления, нужные для процессов восстановления, не работают из-за той же симулированной вами аварии. Или вы можете найти новые точки отказа, о которых вы до этого и не подозревали». Такие тренировки постепенно становятся все более интенсивными и сложными с той целью, чтобы они воспринимались как обычная часть обычного рабочего дня.
С помощью игровых дней мы постепенно формируем более адаптивные сервисы, получаем уверенность в том, что мы можем восстановить работу после инцидентов, а также создаем новые знания и повышаем способность к адаптации нашей компании.
Отличный пример симулирования сбоев — программа восстановления после аварий компании Google (Disaster Recovery Program, DiRT). Крипа Кришнан, главный инженер программ Google, на момент написания этой книги руководит этой программой уже семь лет. За это время они симулировали землетрясение в Кремниевой долине, из-за которого комплекс зданий и офисов Google в городе Маунтин-Вью оказался отсоединен от остальной компании, полную потерю питания в крупнейших дата-центрах и даже нападение пришельцев на города, где жили инженеры организации.
По словам Кришнан, «тестировщики часто обходят стороной бизнес-процессы и коммуникации. Системы и процессы очень тесно переплетены, и разделять тестирование систем и тестирование бизнес-процессов — нереалистичный подход: отказ бизнес-системы скажется на бизнес-процессе, и наоборот, работающая система без нужного персонала не очень-то полезна».
Во время симулирования таких аварий было сделано несколько открытий:
• когда соединение было прервано, переход коммуникации на рабочие места инженеров не помог;
• инженеры не знали, как получить доступ к коммутатору телеконференции, или коммутатор мог соединять только пятьдесят человек, или им нужен был новый провайдер конференций, позволяющий выкидывать из беседы участников, не бравших трубку и вынуждающих всех остальных слушать мелодию ожидания ответа;
• когда у дата-центров закончилось топливо для запасных генераторов, никто не знал процедур для экстренных закупок у поставщика, из-за чего одному сотруднику пришлось использовать личную кредитную карту и закупить топлива на 50 000 долларов.
С помощью создания аварий в контролируемых условиях мы можем успешно тренироваться и придумывать нужные сценарии. Еще один важный результат Game Days — то, что работники знают, кому звонить и с кем разговаривать. Так они налаживают отношения с сотрудниками других отделов, чтобы можно было успешно работать вместе во время аварий, превращая сознательные действия в бессознательные шаблоны и привычки.
Заключение
Чтобы создать справедливую культуру, поощряющую обучение, нам нужно поменять отношение к так называемым ошибкам. При правильном подходе ошибки, неизбежные в сложных системах, создают динамическую учебную среду, где все сотрудники чувствуют себя защищенными и могут выдвигать новые идеи и замечания и где команды быстрее оправляются от неудачных проектов, работавших не так, как ожидалось.
Разбор ошибок без поиска виноватых и сознательное создание сбоев укрепляют культуру, где всем комфортно и где все чувствуют ответственность за получение новых знаний из ошибок. Кроме того, когда мы значительно сокращаем число инцидентов, мы уменьшаем порог чувствительности, чтобы не останавливаться в развитии. Как говорит Питер Сэндж, «единственное надежное конкурентное преимущество — это способность компании учиться быстрее, чем ее конкуренты».
