Книга: Site Reliability Engineering. Надежность и безотказность как в Google
Назад: В. Пример документа о происшествиях
Дальше: Д. Список действий для координации запуска

Г. Пример постмортема

Shakespeare Sonnet++ Постмортем (сбой #465)

Дата: 2015-10-21.

Авторы: jennifer, martym, agoogler.

Статус: завершен, предпринимаются меры.

Краткая информация: поисковая система Shakespeare была недоступна на протяжении 66 минут в период очень высокого интереса к Shakespeare по причине открытия нового сонета.

Последствия: по предварительным подсчетам, потеряно 1,21 миллиарда запросов, доход не упал.

Исходные причины: каскадный отказ по причине сочетания исключительно высокой нагрузки и утечки ресурсов, когда поисковые запросы не обслуживались из-за отсутствия в текстовой базе данных Shakespeare. Новооткрытый сонет использовал слово, которое никогда не появлялось в работах Shakespeare и которое по совпадению оказалось поисковым запросом пользователей. В нормальных условиях доля отказа задач из-за утечки ресурсов является достаточно низкой, чтобы остаться незамеченной.

Запускающее событие: скрытая ошибка, активизированная внезапным притоком трафика.

Решение: перенаправление трафика в неприоритетный кластер и добавление десятикратной производительности, чтобы устранить каскадное отключение. Развернут обновленный индекс, разрешая проблему взаимодействия со скрытой ошибкой. Поддержание дополнительной производительности, пока приток пользовательского интереса к новому сонету не иссякнет. Утечка ресурсов определена, проблема решена.

Обнаружение: Borgmon обнаружил высокий уровень HTTP 500s и сообщил дежурным.

Перечень мер

Мера

Тип

Ответственное лицо

Ошибка

Добавить в план инструкции для реагирования на каскадное отключение

Минимизация

jennifer

Н/д ГОТОВО

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

Предотвращение

martym

Ошибка 5554823 ПЛАН

Запланировать тест на каскадное отключение во время следующего процесса DiRT

Процесс

docbrown

Н/д ПЛАН

Непрерывно исследовать переменный указатель MR/fusion

Предотвращение

jennifer

Ошибка 5554824 ПЛАН

Устранить утечку из дескриптора файлов в поисковой подсистеме ранжирования

Предотвращение

agoogler

Ошибка 5554825 ГОТОВО

Добавить функционал сегментации нагрузки в поисковую систему Shakespeare

Предотвращение

agoogler

Ошибка 5554826 ПЛАН

Создать регрессионные тестирования для подтверждения нормального реагирования серверов на мертвые запросы

Предотвращение

clarac

Ошибка 5554827 ПЛАН

Добавить к продукту обновленную поисковую систему ранжирования

Предотвращение

jennifer

Ошибка н/д ГОТОВО

Остановить работы до 2015-11-20 из-за исчерпания бюджета ошибок или считать исключение возникшим ввиду гротескных, невероятных, странных и беспрецедентных обстоятельств

Другое

docbrown

Н/д ПЛАН

Полученные уроки

Что прошло хорошо

Система контроля быстро оповестила нас о высокой доле (достигавшей 100 %) HTTP 500s.

• Быстрое обновление текстовой базы данных Shakespeare во всех кластерах.

Что прошло плохо

У нас нет практики реагирования на каскадные отключения.

• Мы превысили разрешенный бюджет ошибок (на несколько порядков) из-за исключительного притока трафика, который в результате привел к отказам.

В чем нам повезло

В списке рассылки приверженцев Shakespeare оказалась доступная копия нового сонета.

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

• Мертвые запросы были устранены в результате загрузки нового индекса, содержащего популярный поисковой запрос.

Хронология

2015-10-21 (время везде указано в формате UTC)

14:51 Появляются сообщения о том, что новый сонет Шекспира был обнаружен у Delorean.

• 14:53 Трафик по запросам о Шекспире возрастает в 88 раз после того, как пост в /r/shakespeare указывает на поисковую систему Shakespeare как место поиска нового сонета (вот только нового сонета у нас на тот момент не было).

• 14:54 НАЧИНАЕТСЯ ОТКЛЮЧЕНИЕ — поисковые серверы перегружаются.

• 14:55 docbrown получает шквал оповещений, ManyHttp500s из всех кластеров.

• 14:57 Сбой всего трафика по поисковому запросу Shakespeare: см. .

• 14:58 docbrown начинает расследование, обнаруживает очень высокую долю отказов сервера.

• 15:01 НАЧАЛО ИНЦИДЕНТА — docbrown объявляет инцидент #465 по причине каскадного отключения, координация действий в #shakespeare, jennifer назначается управляющей инцидентом.

• 15:02 По совпадению кто-то отправляет письмо в shakespeare-discuss@ с обнаруженным сонетом, который оказывается вверху списка входящих сообщений martym.

• 15:03 jennifer оповещает список рассылки shakespeare-incidents@ об инциденте.

• 15:04 martym находит текст нового сонета и ищет документацию по обновлению текстовой базы данных.

• 15:06 docbrown обнаруживает, что симптомы отказа идентичны для всех задач во всех кластерах, начинает искать причину в журналах приложений.

• 15:07 martym находит документацию, начинает подготовительные работы по обновлению текстовой базы данных.

• 15:10 martym добавляет сонет к известным произведениям Шекспира, начинает работу по индексации.

• 15:12 docbrown связывается с clarac и agoogler (из команды разработчиков Shakespeare) и просит помощи с изучением базы исходного кода в поисках возможных причин.

• 15:18 clarac обнаруживает в журналах явный след, указывающий на опустошение дескриптора файлов, подтверждает, что утечка существует, так как поиск в текстовой базе данных не выполняется.

• 15::20 martym завершает работу с индексом MapReduce.

• 15:21 jennifer и docbrown решают увеличить количество экземпляров до показателя, при котором они будут способны работать под нагрузкой на приемлемом уровне до того, как их отключат и перезагрузят.

• 15:23 docbrown выравнивает нагрузку трафика в кластере USA-2, позволяя увеличить количество экземпляров в других кластерах без немедленного отключения сервиса.

• 15:25 martym начинает распространять новый индекс на все кластеры.

• 15:28 docbrown начинает увеличивать количество экземпляров в два раза.

• 15:32 jennifer меняет баланс нагрузки для увеличения трафика в приоритетных кластерах.

• 15:33 Начало отказа задач в приоритетных кластерах, симптомы остаются прежними.

• 15:34 В вычислениях обнаружено порядковое возрастание количества ошибок при увеличении числа экземпляров.

• 15:36 jennifer возвращает исходные показатели балансировки нагрузки для повторного использования неприоритетного кластера USA-2 в подготовке к дополнительному глобальному увеличению количества экземпляров в пять раз (в общей сумме в десятикратном размере от исходной производительности).

• 15:36 ОТКЛЮЧЕНИЕ УМЕНЬШЕНО, обновленный индекс распространен на все кластеры.

• 15:39 docbrown начинает второй этап увеличения количества экземпляров до десятикратного размера от начальной производительности.

• 15:41 jennifer восстанавливает балансировку нагрузки по всем кластерам для 1 % трафика.

• 15:43 Доли ошибки HTTP 500 в приоритетных кластерах не превышают допустимых пределов, случайные отказы задач — на низком уровне.

• 15:45 jennifer распределяет 10 % трафика по приоритетным кластерам.

• 15:47 Доля HTTP 500 в приоритетных кластерах остается в пределах SLO, отказов задач не наблюдается.

• 15:50 30 % трафика распределено по приоритетным кластерам.

• 15:55 50 % трафика распределено по приоритетным кластерам.

• 16:00 ОТКЛЮЧЕНИЕ ЗАКОНЧЕНО, весь трафик распределен по всем кластерам.

• 16:30 ИНЦИДЕНТ ЗАКОНЧЕН, достигнут выходной критерий 30 минут номинальной производительности.

Вспомогательная информация

Панель мониторинга, .

Под последствиями понимается воздействие на пользователей, изменение дохода и т.д.

Пояснение обстоятельств, при которых произошел данный инцидент. Полезно использовать такие техники, как «Пять почему» [Ohno, 1988] для понимания сопутствующих факторов.

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

Этот раздел посвящен происшествиям без последствий.

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

Назад: В. Пример документа о происшествиях
Дальше: Д. Список действий для координации запуска