Три дня, которые потрясли нас в 2013

Большие сбои в онлайн-проектах происходят редко. А в больших проектах — ещё реже. Конечно, чем сложнее система, тем выше вероятность ошибки. Один час простоя крупных систем, особенно соцсетей, обходится недёшево, и потому в больших проектах прикладывается очень много усилий по предотвращению аварий и снижению негативного эффекта для пользователей. Но иногда то ли звёзды складываются в особенную комбинацию, то ли закон Мёрфи обретает реальную силу, и большие аварии всё же происходят. В истории Одноклассников крупнейший сбой произошёл 4 апреля 2013 года: в течение трёх дней проект был целиком или частично неработоспособен. О том, что же тогда произошло, по каким причинам и как мы с этим боролись, будет наш рассказ.

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

Вскоре посыпались сообщения о сбоях на разных серверах, их количество быстро росло. Дежурные сразу подняли лог и предположили, что всё дело в изменённом шаблоне конфигурации. Естественно, изменения сразу попытались откатить, вернув первоначальную версию шаблона на серверы. Однако к тому времени отказали уже все Linux-машины, составлявшие тогда бόльшую часть серверного парка Одноклассников. Так начались самые долгие три дня.

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

• На тот момент мы использовали старую версию openSUSE и, как следствие, старую версию bash «из коробки». Забэкпортить необходимые нам изменения выглядело проще, чем обновляться на новую ветку (сейчас bash обновлён до новой ветки, что потребовало фиксить синтаксис некоторых системных и наших скриптов). В процессе бэкпортирования была допущена ошибка, которая проявила себя только при очередном изменении шаблона конфигурации, распространённого по всем серверам.
• Разработчик, создававший и тестировавший шаблон, работал в текстовом редакторе, который не добавляет автоматически в конце файла символ переноса строки.
• Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла.
• Оказалось, что в нашей системе централизованного управления (CFEngine) присутствовал баг, из-за которого в редактируемый файл всегда добавляется символ переноса строки. В результате получились два символа переноса подряд — пустая строка в конце файла.
• В модифицированном нами коде bash оказался другой баг, из-за которого интерпретатор при обнаружении пустой строки в конце конфигурационного файла входил в бесконечный цикл и переставал отвечать на внешние команды.

К сожалению, нельзя было восстановить работоспособность системы просто перезапустив серверы. Связано это с особенностями архитектуры портала.

Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других. Если хаотично перезапускать серверы, то можно нарушить работу не только одной конкретной подсистемы, но и множества других связанных с ней.

Пример связей между подсистемами:

Чем-то напоминает классику:

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

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

Как вы помните, нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.

Изначально на некоторых серверах можно было «достучаться до bootstrap» — получить описание кластера и выяснить, где именно в нём хранятся те или иные данные. Пока серверы не были перезагружены, они очень медленно, но всё же отдавали конфигурацию, и можно было запустить какие–то сервисы. С ускорением процесса восстановления приходилось эти серверы перезагружать. Но для старта или нормальной работы каждой подсистеме нужно, чтобы были доступны другие связанные с ней подсистемы. Из-за перезагрузки терялся доступ к описанию некоторых кластеров и возможность запуска многих подсистем. Те, которые могли бы быть запущены, уже не запускались. А те, которые работали, переставали работать, и приходилось повторно их восстанавливать.

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

• Сконфигурированы ли ваши серверы для удалённого перезапуска?
• Насколько надежно организована ваша система бэкапов данных?

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

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

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

Системы мониторинга и статистики повсеместно используются в интернет-проектах, и такой большой проект, как Одноклассники, не является исключением. Постоянно отслеживается огромное количество параметров, касающихся как корректности работы оборудования и приложений, так и поведения пользователей. Во время устранения аварии из-за слишком большого количества сбоев информация собиралась медленно или вообще не собиралась — попытки связи мониторов со многими серверами заканчивались таймаутами. В результате мониторы отмечали давно починенные серверы как сбойные, и наоборот — нерабочие серверы считал работающими, так как до них просто не дошла ещё очередь на опрос монитором. Зачастую системы мониторинга вообще выходили из строя. Мы не могли получить актуальные данные о состоянии серверов и узнать, корректно ли работают приложения. Поэтому приходилось делать проверки вручную, что отнимало дополнительное время

Мы с самого начала составили план восстановления, наметив очерёдность работ. Все процедуры, выполнявшиеся в ходе восстановления, документировались. Работа людей координировалась, и когда кто-то завершал очередное задание, ему выдавалось следующее. Распределение заданий осуществлялось на основании текущей ситуации и оперативного плана. То есть процесс был управляемым, но лишь отчасти. Приходилось много импровизировать.

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

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

В Одноклассниках, как и во многих других проектах, применяется инцидент-менеджмент. То есть все нештатные ситуации фиксируются и делятся по категориям:

• баг в нашем коде,
• ошибки конфигурации,
• сбой аппаратуры,
• ошибочные действия сотрудников,
• сбои на стороне наших партнёров: платёжных агрегаторов, операторов связи, дата-центров и т.д.

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

Серьёзные аварии бывали и ранее. Например, в 2012 году Одноклассники не работали в течение нескольких часов из-за недоступности одного из дата-центов в связи с пожаром в коллекторе связи. После этого мы поставили себе глобальную цель: наш портал должен быть полностью работоспособен при потере любого из дата-центров. Этой цели мы скоро достигнем.

• при отказе нескольких серверов?
• одной или нескольких подсистем?
• одного из дата-центров?
• Как у вас построена работа с инцидентами?

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

• сколько времени заняло,
• какие возникали сложности и почему,
• как они решались,
• почему были приняты те или иные решения.

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

• Завершили процесс замены ненадежных систем хранения данных (далее СХД) на основе Berkeley DB. С самого основания Одноклассников подобные системы использовались для хранения больших бинарных данных и key value для различных бизнес-сущностей небольшого размера. Этим СХД было свойственно много недостатков. Например, из-за особенностей архитектуры репликации Single Master периодически терялись изменения при отказе мастера, а иногда и при отказе его реплики. Также в ходе аварии выяснилось, что процедура восстановления из бэкапов очень медленная и ненадёжная. На данный момент завершён переход на системы на базе Cassandra и Voldemort.
• Внедрили автономную систему централизованного управления серверами через IPMI. Теперь для управления серверами достаточно, чтобы у них было питание и сетевой доступ к IPMI.
• Повысили надежность и точность систем мониторинга. После аварии мы по пунктам разобрали работу всех систем мониторинга и сделали следующее: — полностью переписали скрипты для повышения стабильности работы, — уменьшили таймауты проверок, — ввели зависимости проверок приложений от доступности серверов по сети, — обновили программное обеспечение, — поменяли активные проверки на пассивные и внесли множество других изменений.
• Внедрили защиту от изменения конфигурации на всех серверах. Теперь изменения могут автоматически применяться только в одном из дата-центров и только в рабочее время.

• Как давно вы восстанавливали данные из бэкапа и сколько времени это заняло?
• Имеете ли вы возможность дистанционно управлять всеми серверами?
• Способна ли ваша система мониторинга корректно функционировать в случае полномасштабной аварии?
• Есть ли физическая возможность одним изменением конфигурации нарушить работу всех серверов за короткий период времени?

• Изменили процедуру внесения изменений в конфигурацию на production. Ввели принудительную проверку всех изменений ещё одним сотрудником. Тестирование любых изменений теперь проходит через бόльшее количество окружений: — unstable (виртуалки, где можно «вытёсывать топором»), — testing (с полным набором служебных систем, но не в production), — stable (специально выделенная группа сотни production-серверов различных типов) — и затем в production, отдельно по дата-центрам.
• Определили обязательные типы тестов, которым подвергаются новые служебные системы или измененные служебные компоненты (нагрузочные, интеграционные, отказоустойчивости и т.д.), и дополнили их примерами.
• Переделали служебные системы и сеть с учётом дополнительных аварийных сценариев.
• Снизили зависимость от инфраструктуры, добавили дублирование, организовали аварийный доступ.
• Исправили мешающие запуску приложений зависимости и внедрили тестирование отказов сервисов. Теперь на постоянной основе проверяется работа функциональности при полном отказе подсистем. Также внедрили «рубильники», позволяющие принудительно отключать сервисы.

• Как у вас построена процедура проверки и тестирования вносимых в production изменений?
• Насколько ваши служебные сервисы и рабочие инструменты подвержены сбоям в инфраструктуре?

Одной из основных проблем для нас было отсутствие плана действий при столь масштабной аварии. Мы разработали его на основании результатов анализа проведённых работ по восстановлению. Что входит в план: