Войти в систему
Войти с помощью соц. сетей:
Автор — Кори Адам Бэй
Под редакцией Дайаны Бэйтс
Жизнь так устроена, что все когда-нибудь ломается.
Как бы ни были высоки ставки и как бы ни была велика организация, важная характеристика, от которой зависит, как долго проживет организация и что выделяет ее среди других, — это то, как ее сотрудники реагируют на критические ситуации. Лишь некоторые из нас от природы хорошо ориентируются в таких ситуациях. Поэтому правильный подход состоит в заблаговременной подготовке к ним и периодических тренировках. Налаживание и поддержание системы тренировок и контроля требует, помимо добросовестного отношения со стороны персонала, также и соответствующего управления. Все эти составляющие важны для создания благоприятной атмосферы, в которой команды смогут вкладывать свою энергию, деньги и, возможно, сверхурочное время работы, чтобы быть уверенными в том, что в критической ситуации системы, процессы и люди будут вести себя эффективно.
Заметьте, что особенности составления отчетов, которые позволяют почерпнуть новые знания из инцидентов, потребовавших экстренного реагирования, обсуждаются в главе 15. Эта же глава более конкретно рассматривает сами такие инциденты.
Прежде всего — не паникуйте! Вы не одни, и небо не падает вам на голову. Вы профессионал и тренировались для таких ситуаций. Обычно никому не грозит прямая опасность, на грани смерти только несчастные электроны. В худшем случае не будет работать половина Интернета. Так что сделайте глубокий вдох… и продолжайте.
Если вам кажется, что вы не справитесь, привлекайте к решению больше людей. Иногда может потребоваться привлечь целую компанию. Если в вашей компании есть установленные процедуры реагирования на инциденты (см. главу 14), удостоверьтесь, что вы знакомы с ними, и действуйте согласно инструкции.
В Google взяли на вооружение упреждающий подход к тестированию поведения в аварийных и иных критических ситуациях (см. [Krishan, 2012]). SR-инженеры «ломают» наши системы, наблюдают их крах и вносят необходимые изменения для повышения устойчивости и предотвращения подобных отказов в будущем. Большинство таких «управляемых аварий» проходят в соответствии с планом, и системы демонстрируют поведение более или менее в рамках ожидаемого. Мы находим какие-то слабые места или неявные зависимости и документируем действия, необходимые для исправления выявленных недостатков. Однако иногда реальность расходится с нашими ожиданиями. Рассмотрим один пример теста, который вскрыл несколько неожиданных зависимостей.
Нам необходимо было удалить скрытые зависимости от тестовой базы данных в одной из наших крупных распределенных баз данных, реализованной на MySQL. Планировалось заблокировать любой доступ всего к одной базе из сотни. Того, что из этого получилось, не мог предположить никто.
Через пару минут после начала теста многие зависимые сервисы сообщили, что как внешние, так и внутренние пользователи не могут получить доступ к ключевым системам. Некоторые системы были доступны частично или с перебоями.
Придя к выводу, что в этом виноват тест, SR-инженеры немедленно прервали его. Мы попытались откатить изменения, но не добились успеха. Не поддаваясь панике, мы немедленно приступили к поиску возможности восстановить нормальный доступ. Мы пошли проверенным путем: переключили доступ на копии и резервные ресурсы. Одновременно мы связались с ключевыми разработчиками, чтобы те устранили дефекты в библиотеке, обеспечивающей взаимодействие приложений с БД.
Доступ был полностью восстановлен в течение часа, и все сервисы смогли опять подключиться. Столь масштабные последствия теста мотивировали нас как на быструю и полную корректировку всех библиотек, так и на включение в планы периодического повторного тестирования, чтобы предотвратить повторение подобной ситуации.
Что оказалось хорошо. Зависимые сервисы, которые были затронуты этим инцидентом, мгновенно распространили проблему в масштабах всей компании. Мы правильно предположили, что наш эксперимент вышел из-под контроля, и немедленно его прекратили. Всего за час мы полностью восстановили доступ. Некоторые команды избрали другой путь и перенастроили свои системы, исключив использование тестовой базы. Эти параллельные усилия помогли восстановить сервис так быстро, как это было возможно. Затем мы удостоверились в том, что система функционирует нормально, и решили периодически проводить подобные тесты, чтобы гарантировать, что ситуация больше не повторится.
Чему это нас научило. Хотя тест был предварительно полностью рассмотрен и изучен, реальность показала, что нам не хватило знаний того, как зависимые системы взаимодействуют между собой в такой ситуации.
Мы не смогли следовать процессу реагирования на инциденты, который создали всего несколько недель назад и который не был окончательно внедрен. Этот процесс гарантировал бы, что все сервисы и все пользователи будут предупреждены о перебоях в работе. Чтобы избежать подобного развития событий в будущем, команда SRE постоянно совершенствует и тестирует наши инструменты и процессы, ответственные за реагирование на инциденты, вдобавок удостоверяясь в том, что эти нововведения понятны всем заинтересованным сторонам.
Поскольку процедуры отката не были протестированы в тестовой среде, они оказались неработоспособны, из-за чего восстановление затянулось. Теперь мы каждый раз тестируем системы отката перед началом крупномасштабного тестирования.
Как вы уже можете себе представить, системы Google имеют множество конфигураций, причем сложных конфигураций, которые мы постоянно изменяем и дорабатываем. Для предотвращения поломки наших систем мы проводим множество тестов на этих конфигурациях, чтобы удостовериться в том, что они не приведут к неожиданным и нежелательным результатам. Однако масштаб и сложность инфраструктуры Google практически не позволяет предвидеть каждую зависимость или каждое взаимодействие. Иногда изменения в конфигурациях не идут по плану. И вот пример такого случая.
В пятницу было выполнено глобальное изменение конфигурации внутренней подсистемы, защищающей наши сервисы от перегрузки и некорректных обращений. Она взаимодействует со всеми нашими внешними системами, в которых изменение вызвало повторяющиеся отказы, и весь парк систем был парализован практически одновременно. Поскольку внутренняя инфраструктура Google зависит от собственных сервисов, множество внутренних приложений тоже стали недоступны.
Через несколько секунд начали поступать сообщения мониторинга, указывающие, что многие сайты перестали работать. Некоторые дежурные инженеры независимо друг от друга восприняли это как отказ корпоративной сети и перешли в специальные защищенные комнаты («комнаты паники») с резервным доступом к системам, находящимся в «промышленной» эксплуатации. К ним присоединились и другие инженеры, безуспешно пытавшиеся получить доступ к своим системам.
Через пять минут после обновления конфигурации ответственный за него инженер был оповещен о перебоях внутрикорпоративного доступа, но еще не знал о глобальном характере проблемы, и запустил повторное изменение, отменяющее предыдущее. С этого момента сервисы начали восстанавливаться.
Через десять минут после первого обновления дежурные инженеры объявили об инциденте и продолжили действовать согласно процедурам реагирования. Они начали уведомлять остальную компанию о возникшей ситуации. Инженер, который обновил конфигурацию, информировал дежурных о том, что проблема, скорее всего, была в обновлении, которое он откатил назад. Тем не менее, у некоторых сервисов сбои и нарушения конфигурации, спровоцированные первоначальным изменением и не позволяющие полностью восстановить работоспособность, продолжались до часа.
Что оказалось хорошо. В данном случае сработало несколько факторов, которые предотвратили усугубление ситуации до долговременного отключения множества внутренних систем Google.
Начнем с того, что в процессе мониторинга проблема была почти моментально обнаружена и система уведомила нас о ней. Однако стоит заметить, что в этом случае наша система мониторинга не была идеальной: уведомления «вылетали» многократно, непрерывно заваливая дежурных инженеров и забивая обычные и экстренные каналы связи.
Как только проблема была найдена, процедура разрешения инцидента прошла в целом как полагается и оповещение обо всех предпринимаемых действиях и событиях были регулярными и качественными. Наши средства коммуникаций держали всех на связи, даже когда более сложное программное обеспечение отказало. Этот опыт напомнил нам о том, зачем служба SRE продолжает использовать высоконадежные, не перегруженные функционалом резервные средства коммуникаций, к которым они регулярно прибегают.
В дополнение у Google есть инструменты, доступные из командной строки, и средства резервного доступа, которые позволили выполнять обновления и откатывать изменения, даже когда другие интерфейсы оказались недоступны. Они отлично сработали в критический момент, напоминая, что инженеры должны лучше знать и чаще тестировать инструменты, с которыми они работают.
В инфраструктуре Google был добавлен еще один уровень защиты: в системах, затрагиваемых изменениями, ограничивается быстрота доставки полных обновлений для очередных клиентов. Такое поведение могло бы остановить цепную реакцию отказов и предотвратить полное отключение, позволяя обрабатывать хотя бы несколько запросов между отказами. Наконец, не стоит сбрасывать со счетов элемент удачи в быстром разрешении этого инцидента: так случилось, что инженер, занимавшийся обновлением, был на связи в реальном времени — высокий уровень ответственности, чего обычно не бывает во время подобных изменений. Инженер заметил большое количество жалоб об отказах в доступе сразу же после того, как выполнил обновление, и практически сразу же откатил изменения. Если бы процесс отката задержался, кто знает, сколько бы продлились перебои и насколько бы усложнилась ликвидация их последствий.
Чему это нас научило. Предыдущие обновления, уже прошедшие тщательную проверку, не приводили к такой проблеме, так как в них не было комбинации одной редкой и специфичной опции конфигурации и нового функционала. Поэтому то изменение, которое вызвало аварию, не рассматривалось как рискованное и, следовательно, проходило менее строгий процесс проверки. Когда изменение применили ко всей системе, оно задействовало непротестированную связку опции конфигурации и функционала, что и спровоцировало отказ.
По иронии судьбы, усовершенствование средств проверки и автоматизации этого процесса планировалось как первоочередная задача на следующий квартал. Случившееся немедленно повысило ее приоритет и укрепило инженеров в решении о необходимости полного тестирования независимо от ожидаемой степени рискованности обновления.
Как и можно было ожидать, оповещения во время инцидента были голосовыми, потому что за пару минут практически все ушло в офлайн. Это нарушило работу дежурных инженеров и усложнило общение между ними, тем самым усложнив ситуацию.
Google полагается на свои инструменты. Но большинство инструментов, которые обычно используются в таких ситуациях, оказались подвержены цепной реакции отказов. Если бы перебой в работе сервисов затянулся, отладка стала бы намного сложнее.
Мы вложили немало времени и сил в автоматизацию управления нашим парком машин. Просто невероятно, сколько задач можно запускать, останавливать или перенастраивать на всех машинах с минимальными усилиями! Но если что-нибудь идет не по плану, такая эффективность автоматизации может обернуться угрозой.
В следующем примере быстрота исполнения показала себя не с лучшей стороны.
В ходе рутинного тестирования средств автоматизации на сервер, готовящийся к выводу из эксплуатации, были отправлены два последовательных запроса на отключение. На втором из них коварная ошибка в процедурах автоматизации отправила все машины аналогичных серверов по всему миру в очередь на выполнение Diskerase (полная очистка жестких дисков: см. врезку «Автоматизация: появление сбоев при масштабировании» в конце главы 7).
Сразу после запуска второго запроса на отключение дежурные инженеры получили оповещение об отключении небольшого сервера — того, который и планировалось отключить. Исследование показало, что машины поставлены в очередь Diskerase, поэтому, следуя обычной процедуре, дежурные инженеры убрали весь трафик данной площадки. Это было сделано для того, чтобы избежать отказов в обслуживании, поскольку у этих машин содержимое дисков было удалено и они не могли обрабатывать запросы. Трафик был перенаправлен на площадки, которые могли должным образом обрабатывать запросы.
Но вскоре стали поступать сообщения от аналогичных серверов по всему миру. Предотвращая дальнейшие разрушения, инженеры отключили автоматизацию во всех командах. Вскоре также были прекращены или приостановлены дополнительная автоматизация и процедуры обслуживания серверов промышленной эксплуатации.
В течение часа весь трафик был разведен по другим площадкам. И хотя пользователи могли сталкиваться с увеличившимися задержками, их запросы выполнялись. Сбой был официально устранен.
Теперь началось самое сложное — восстановление. По части ссылок наблюдались заторы запросов, и сетевые инженеры предпринимали меры по снижению нагрузки в выявляемых узких местах. На одной из таких площадок был выбран сервер, которому первым из многих предстояло восстать из пепла. Через три часа после сбоя благодаря упорству нескольких инженеров система была пересобрана и смогла вернуться в строй, радостно принимая запросы пользователей.
Американские команды передали эстафету своим коллегам из Европы, и службы SRE набросали порядок восстановления с использованием «конвейерной» ручной переустановки. Команда была разделена на три части, каждая из которых отвечала за один свой конкретный этап. Через три дня большая часть серверов была запущена, но восстановление некоторых затянулось на месяц или два.
Что оказалось хорошо. Управление обратными прокси-серверами в больших и в малых системах организовано по-разному, поэтому более крупные системы не пострадали. Дежурные инженеры смогли быстро перенаправить трафик от маленьких серверов к большим, которые спроектированы так, что могут без проблем выдерживать полную нагрузку. Однако некоторые узлы были перегружены, что потребовало от сетевых инженеров искать пути обхода. Для того чтобы уменьшить негативный эффект для пользователей, дежурные инженеры выделили перегруженные сети как свою самую приоритетную задачу.
Процесс отключения для небольших систем работал правильно и эффективно. Менее чем за час было отключено и надежно «зачищено» множество таких систем.
Хотя отключение средств автоматизации остановило также и мониторинг этих небольших систем, дежурные инженеры смогли возобновить его из командной строки. Это помогло им оценить масштабы нанесенного ущерба.
Инженеры оперативно следовали протоколу реагирования на инциденты, который к тому моменту был намного яснее, чем во времена первого сбоя, описанного в текущей главе. Взаимодействие и сотрудничество между командами и во всей компании в целом было превосходным — реальное свидетельство того, насколько эффективными были тренинги и вся программа по управлению в критических ситуациях. Никто не оставался в стороне, внося вклад в общее дело.
Чему это нас научило. В основе возникшей проблемы лежало то, что ответственный за отключение систем сервер автоматизации недостаточно проверял отправляемые команды на «стерильность». Попытавшись выполнить процедуру повторно после неудавшегося первого отключения, он получил пустой ответ от серверной стойки. Вместо того чтобы отфильтровать этот ответ, он передал в базу данных серверов запрос на удаление содержимого дисков с пустым фильтром, то есть всех машин, содержащихся в базе. Да, иногда «ничего» означает «все». База данных скомпилировала запрос, и процесс разрушения закрутился на всех серверах так быстро, как это было возможно.
Переустановка была медленной и ненадежной. Это по большей части было вызвано использованием протокола передачи файлов TFTP (Trivial File Transfer Protocol) с низшим показателем качества обслуживания (QoS) для удаленных площадок. BIOS этих машин не могла адекватно справиться с ошибками передачи. В зависимости от установленных сетевых карт, BIOS или приостанавливала работу, или уходила в бесконечный цикл перезагрузок. Раз за разом передача загрузочных файлов обрывалась, и это все сильнее нагружало установщики. Дежурные инженеры смогли решить проблему, слегка подняв приоритет для трафика перезагрузки систем и используя автоматизацию для перезапуска зависших машин.
Инфраструктура переустановки машин не смогла справиться с одновременной инсталляцией тысяч машин. Отчасти это вызвано тем, что процедуры восстановления позволяли запустить с одного рабочего места не более двух установок одновременно. Кроме того, в ходе восстановлении использовались неверные параметры QoS для передачи файлов и плохо настроенные тайм-ауты. Это вынудило переустанавливать ядро системы даже там, где очистка еще не была выполнена и ядро оставалось работоспособно. В попытке исправить эту ситуацию дежурные инженеры связались с командами, которые были ответственны за эту инфраструктуру и могли бы быстро перенастроить ее на поддержку такой необычной нагрузки.
Время и опыт показывают, что системы могут не просто ломаться — они могут ломаться так, как никто и представить себе не мог. Один из самых важных выученных нами уроков — это то, что решение есть всегда, даже если оно неочевидно, особенно для человека, у которого пейджер разрывается от вызовов. Если вы не можете придумать решение, забросьте свою сеть дальше. Подключите больше коллег, ищите помощи, делайте то, что должны, но делайте это быстро. Главное — быстро взять проблему под контроль. Зачастую больше всего знает о ситуации тот, кто как-то причастен к ее возникновению. Обратитесь к этому человеку.
Как только проблема будет решена, очень важно не забыть выделить время для наведения порядка, описания инцидента и…
Нет лучшего способа научиться, чем задокументировать то, что ранее ломалось. Это позволяет учиться на ошибках других. Будьте внимательны и честны, но самое главное — задавайте сложные вопросы. Ищите новые способы предотвратить повторный сбой не только тактически, но и стратегически. Убеждайтесь в том, что все члены команды могут узнать из отчетов все то, что узнали вы.
Оставляйте указания по действиям в такой ситуации для себя и других ответственных лиц. Это предотвратит будущие перебои, которые будут схожи с вашим случаем и будут вызваны теми же причинами, что и задокументированный. Наличие достаточно полного списка уже изученных сбоев позволит увидеть, что можно сделать, чтобы предотвратить такие случаи в будущем.
Нет лучшей проверки, чем реальность. Задавайте себе сложные, не имеющие готового ответа вопросы.
А что если в здании пропадет электропитание? Что если стойка с сетевым оборудованием окажется в двух футах под водой? А что если главный дата-центр внезапно выключится? А что если кто-то атакует ваш веб-сервер? Что тогда делать? Кому звонить? Кто за это заплатит? У вас есть план действий? Знаете ли вы, что делать? Знаете ли вы, как отреагируют системы? Сможете ли вы минимизировать ущерб, если это произойдет сейчас? Смогут ли другие люди, сидящие рядом, сделать то же самое?
Когда дело дошло до аварии, теория и практика — это две большие разницы. Пока ваша система не сломается по-настоящему, вы до конца не узнаете, как поведут себя эта система, зависящие от нее системы и пользователи.
Не надейтесь на то, что вы предполагаете, или на то, что не смогли или не стали тестировать. Какое окончание недели вы предпочтете — ошибку в два часа ночи в субботу, когда большая часть компании еще не вернулась с тимбилдинга в Шварцвальде (горный массив в Германии. — Примеч. пер.), или наблюдение за безукоризненным выполнением заключительных тестов, которые они тщательно гоняли всю эту неделю?
Мы рассмотрели три разных случая, когда компоненты нашей системы выходили из строя. Несмотря на то что причины всех трех происшествий были различны — упреждающее тестирование, изменение конфигурации, отказ оборудования, — дальнейшее развитие событий имело много общего. Ответственные не запаниковали. Они запросили помощь, когда посчитали это необходимым. Они были научены опытом предыдущих инцидентов. Впоследствии они построили свои системы для лучшего реагирования на такие виды инцидентов. Каждый раз новые найденные проблемы были задокументированы. Потом эти сведения помогали другим командам научиться устранять неполадки и защищать свои системы от схожих сбоев. Выполнялось упреждающее тестирование систем, которое гарантировало, что внесенные изменения решают проблемы, и показывало новые узкие места, до того как они станут проблемой.
Циклы эволюции наших систем продолжаются — с каждым сбоем или новым результатом тестирования постепенно улучшаются и процессы, и система в целом. И хотя рассматриваемые в этой главе примеры относятся к Google, те же подходы к разрешению критических ситуаций могут быть применены в любых организациях любого масштаба.
BIOS (Basic Input/Output System) — базовая система ввода/вывода. Встроенное программное обеспечение компьютера, управляющее им на низком уровне и обеспечивающее ввод/вывод до того, как запустится операционная система.
Войти с помощью соц. сетей: