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

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

Отличный пример симулирования сбоев — программа восстановления после аварий компании Google (Disaster Recovery Program, DiRT). Крипа Кришнан, главный инженер программ Google, на момент написания этой книги руководит этой программой уже семь лет. За это время они симулировали землетрясение в Кремниевой долине, из-за которого комплекс зданий и офисов Google в городе Маунтин-Вью [151]оказался отсоединен от остальной компании, полную потерю питания в крупнейших дата-центрах и даже нападение пришельцев на города, где жили инженеры организации.

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

Во время симулирования таких аварий было сделано несколько открытий:

• когда соединение было прервано, переход коммуникации на рабочие места инженеров не помог;

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

• когда у дата-центров закончилось топливо для запасных генераторов, никто не знал процедур для экстренных закупок у поставщика, из-за чего одному сотруднику пришлось использовать личную кредитную карту и закупить топлива на 50 000 долларов.

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

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

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

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

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

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

Эта методика впервые была опробована в GitHub, где она стала известна под названием ChatOps. Главной целью было использовать автоматизированные инструменты прямо в разговорах чатов, создавая прозрачность и документируя текущую работу. Как пишет Джесс Ньюлэнд, системный инженер GitHub, «Даже если вы новичок, вы можете посмотреть на логи чатов и увидеть, как все было сделано. Вы как будто все время занимались парным программированием со всей командой».

Они создали Hubot, приложение, взаимодействовавшее с командой эксплуатации в их чатах, где можно было выполнять действия с помощью команд прямо из беседы (например, @hubot deploy owl to production [152]). Результаты выполнения также отображались в чате.

У автоматического выполнения команд из чата (в противоположность запуску автоматизированных скриптов из командной строки) было много преимуществ, в том числе:

• все видят всё, что происходит;

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

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

• новые знания внутри компании накапливались гораздо быстрее.

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

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

Это также очень эффективный способ распространения знаний по компании. В GitHub все сотрудники, занимавшиеся эксплуатацией, работали удаленно. Более того, все инженеры эксплуатации жили в разных городах. Как вспоминает Марк Имбриако, бывший директор по эксплуатации GitHub, «в GitHub не было материального кулера. Кулером был чат» [153].

Через Hubot можно было запускать разные инструменты автоматизации, используемые в Github, такие как Puppet, Capistrano, Jenkins, resque (библиотека на основе Redis для создания фоновых процессов) и graphme (инструмент для создания графиков в Graphite).

С помощью Hubot можно было проверять работоспособность сервисов, развертывать код в производственную среду и блокировать оповещения, когда сервисы переходили в профилактический режим. Повторяющиеся действия, например smoke-test при сбое развертывания, выведение серверов эксплуатации из работы, возврат к исходной ветке для front-end-сервисов или извинения инженерам, вызванным в нерабочее время, тоже стали возможными действиями в Hubot [154].