Замтехдира «Одноклассников»: Из-за чего ОК не работали три дня в 2013 и как боролись с аварией

Развитие событий: ЦОДы на качелях: какие факторы влияют на бизнес дата-центров в России сейчас (21 сентября 2015)

Из официального заявления о причинах сбоя в работе проекта:

В результате технического сбоя во время выкладки конфигурационного файла на все сервера ОК произошли необратимые изменения. В течение 10 минут произошел рост использования ресурсов серверов до 100%. От нас потребовался принудительный рестарт и ручное переконфигурирование значительной части из более чем 5 000 серверов. Это повлекло за собой восстановление работы систем хранения данных и запуск сервисов с нуля.

4 апреля 2013 года произошла самая серьезная авария за всю историю Одноклассников — портал не работал более суток, а потом еще в течение двух дней был доступен в ограниченном режиме. У десятков миллионов пользователей пропала возможность писать сообщения своим друзьям и близким, слушать музыку, смотреть видео и играть в любимые игры на портале. Экспертами и людьми, не обладающими техническими знаниями, выдвигались всевозможные предположения: от взлома хакерами и потери всех данных, до «они поднимают свой MS SQL». Отношение к произошедшему тоже было разное: от пожеланий скорейшего решения проблем и добрых писем в отдел поддержки пользователей до злорадных комментариев и обвинения сотрудников ОК в некомпетентности.

ОК ЛИ

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

К примеру, Одноклассники на сегодня — это более 7000 серверов, которые в совокупности обслуживают около 150 различных подсистем.

В любом крупном проекте, разработчики принимают ряд мер для того, чтобы обезопасить себя от аварий, сбоев, отказов и пр. Типичный пример такой проблемы — выход из строя какого-то оборудования (от жесткого диска до аварии на интернет-магистрали, к которой подключен датацентр). Другой пример — ошибка в программном обеспечении. Это может быть неправильно работающий драйвер операционной системы сервера или даже простая ошибка программиста из конкретного подпроекта. Наши решения умеют моментально переключаться с одного оборудования на другое в случае, если автоматика распознает, что с текущим оборудованием что-то не так.

Как все было. Что-то пошло не так или «давай с твоей консоли поправим, будет быстрее, у меня уже закрыто»

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

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

ka-boom

Как чинили и какие были сложности

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

Бегите, глупцы

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

Что мешало

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

Что вдохновляло

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

Какие выводы мы сделали и что решили изменить

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

А также:

  • Поменяли процедуры изменений на production (сервера, находящиеся в промышленной эксплуатации, то есть непосредственно обрабатывающие запросы пользователей) и ввели review (обязательную проверку еще одним сотрудником) этих изменений
  • Поменяли процедуры тестирования служебных систем
  • Повысили надежность служебных систем и сети
  • Подготовили и постоянно тестируем план действий при аварии
  • Несмотря на произошедшее, команда была полностью сохранена. Мы никого не уволили, потому что понимали, что человеческий фактор всегда возможен

На деле любой (даже зарезервированный) компонент может отказать как в нашей инфраструктуре, так и неподконтрольный нам: электричество, системы охлаждения в датацентрах, линии связи и т. д. При этом, мы уже сейчас готовы пережить полное уничтожение любого из наших датацентров без потери данных и приближаемся к готовности обеспечить полностью работающий проект в такой ситуации. Заранее предусмотреть все сценарии аварии невозможно, но можно снизить ее вероятность и грамотно подготовиться на случай, если на ЦОД вдруг упадет крыша соседнего здания из-за урагана или вдруг в город ворвется Годзилла, что, конечно, менее вероятно.

Лучшие комментарии

  • Контекст комментария

    Andrey Guba Одноклассники, Mail.Ru Group

    Разница в операционных системах и текстовых редакторах, используемых сотрудниками. Один оставлял дополнительный символ перевода строки, другой нет.

Добавить 28 комментариев

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    Столько лет прошло, можно, все-таки, узнать, что за разности в окружении?

    (а как устраняли живые истории про разборы полетов слышал, да. «Первая ошибка это…, вторая ошибка это …, третья ошибка это ….». Повторить, повторить, повторить.)

  • Ответить

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

  • Ответить

    Добрый день!
    А можно уточнить, почему не работает способ вида: перезагрузить все сервера в условную загрузку по сети, распространить правильную конфигурацию, перезагрузить назад?
    Просто, чтобы понимать.

  • Ответить

    «произошел рост использования ресурсов серверов до 100% … повлекло за собой восстановление работы систем хранения данных и запуск сервисов с нуля»

    — почитал список мер, не увидел решения о предотвращении 100% нагрузки — задавать лимиты на ресурсы (в т. ч. ЦПУ) и ограничивать количество запросов умели еще в прошлом веке. Короче администрирование не на высоте, а если вспомнить что ОК активно используют Unsafe, который Oracle грозится исключить из будущих версий JVM, то и архитектура не блещет.

  • Ответить

    В этой ветке мы ещё не раз прочитаем язвительные комменты про некомпетентность сотрудников и всё такое. Ведь каждая кухарка способна руководить государством =) Надеюсь, когда-нибудь, эти кухарки смогут хотя бы представить масштаб подобных проектов. Например, один коллега более получаса вынужден был висеть на телефоне, объясняя как исправить критическую неполадку в сервисе. Всё бы ничего, но из-за него задерживали рейс на взлётной полосе Шереметьево, потому что он наотрез отказывался отключать телефон — пять миллионов пользователей онлайн, против сотни на борту.

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

    Удачи вам, и не ошибается только тот, кто ничего не делает!

  • Ответить

    > Например, один коллега более получаса вынужден был висеть на телефоне, объясняя как исправить критическую неполадку в сервисе. Всё бы ничего, но из-за него задерживали рейс на взлётной полосе Шереметьево, потому что он наотрез отказывался отключать телефон — пять миллионов пользователей онлайн, против сотни на борту.

    /r/thathappened

  • Ответить
    Andrey Guba Одноклассники, Mail.Ru Group

    Лимитировать нагрузку и ограничивать количество запросов мы умеем. Правда, без раскрытия технических подробностей сложно обьяснить, почему это нам в данном случае не помогло. Что касается Unsafe, его использует большое количество известных всем проектов, таких как (и не ограничиваясь): Cassandra, Hadoop/HBase, Scala, Akka, Netty и даже Spring и Hibernate (более подробно можно почитать, например, в документе международной рабочей группы https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit?usp=sharing)
    Мы в курсе проблемы и решим ее своевременно.

  • Ответить

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

    Сперва забудь о том что приложения не должны работать от привилегированного пользователя и что 100% загрузка ЦПУ это не нормальный режим работы сервера, потом дождись когда эта загрузка случится и сервер уйдет в даун, потом героически перезапусти тысячи серверов, попутно расчистив тот бардак что накопился за годы (очень по нашему — сначала халатность и наплевательство, потом героическое преодоление трудностей)

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

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

  • Ответить

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

    «большое количество известных всем проектов» — Вам от этого будет легче? или надеетесь что они продавят Oracle, а вы на прицепе отхалявите? Что характерно в этой проблеме — то что она была предсказуема.

    P. S. кстати насчет «не уволили» — очень напомнило недавнюю статью про чувака из Гугл который тоже что-то напартачил, тестировщики не проверили, гугл потерял большие бабки, но его «не уволили» потому что Гугл ценит своих сотрудников (такая была мораль) и за одного битого двух не битых дают.

  • Ответить

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

  • Ответить

    Нехватка \n в конфиге syslogd, раскатанном централизованно по всем машинам, может? (Мы на это наступали, уж больно по симптомам напоминает.) Пролейте свет.

  • Ответить

    Судя по намекам — тоже сначала казалось де криво выложили некий «главный» скрипт сервера, который перестал запускаться из-за перевода строки — есть такая проблема: символM bash воспринимает как часть пути и не находит исполняемый файл с этим символом.
    Ну если сломали bash — то тут уже почти все перестанет запускаться и действительно, такое починить сложновато, судя по описанию архитектуры — виртуализации нету.

    Однако, не понимаю, зачем вспоминать эту историю сейчас?

  • Ответить

    «Ваши предположения» — о чем Вы? Единственное предположение которое я высказал — проблемы были предсказуемы. Если конечно понимать под проблемой организационную и архитектурную не продуманность, а не какой-то там перевод строки и кривой Linux на который все списали.

  • Ответить

    Если сломали bash везде, то очень вероятно команде из 50−70 человек пришлось лично посетить «с дискеткой» каждый из 2400 серверов и вернуть нормальный bash на место.
    2400/70 = 48 серверов на человека, за 2−3 дня можно управиться.
    Вот такая обратная сторона масштабирования сервиса с акцентом на покупку железа.

  • Ответить

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

  • Ответить

    «Выводы сделаны, работы продолжаются. » — я конечно не «замтехдира», но … осмелюсь процитировать «Foundations of IT Service Management/Jan van Bon»:

    «Управление проблемами включает в себя проактивные (упреждающие) и реактивные виды деятельности. Проактивное Управление Проблемами помогает предотвратить повторное возникновение инцидентов путем определения слабых мест в инфраструктуре и подготовки предложений по ее усовершенствованию. Задачей реактивных составляющих Процесса Управления проблемами является выяснение корневой причины прошлых инцидентов и подготовка предложений по ее ликвидации.»

    Вы в статье продемонстрировали «реактивную» деятельность — это уровень нормального админа (есть проблема, устрани и прими меры чтобы она больше не возникла). Уровень управленца, это не только реактивная деятельность, но и деятельность упреждающая, которая позволяет принять меры до того как проблема произошла. Вот этого в статье увидеть не удалось.

    Извините что приходится озвучивать азбучные истины, но не я опубликовал статью породившую дискуссию и не я настаиваю на том, что сначала подумать было никак нельзя (хотя фраза «полностью избавились от ненадежных систем хранения данных» намекает, что это можно было сделать и раньше, ДО инцидента).

  • Ответить

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

  • Ответить

    > Важно понимать, что современные интернет-проекты с миллионами пользователей в онлайне — это очень сложные системы

    orly?

    это НАМ важно понимать, или все-таки ВАМ стоило бы понять?

    > Если мы говорим про социальные сети, то эти системы могут насчитывать десятки и сотни тысяч серверов

    > К примеру, Одноклассники на сегодня — это более 7000 серверов

    Социальные сети могут и сотни тысяч серверов занимать, а одноклассники — всего семь. Увольняйте писаря!

    > которые в совокупности обслуживают около 150 различных подсистем.

    Это роем или КП? Для кого эти отмазы и абслютно ничего не говорящие обороты о «150 различных подсистем»? Почему ни слова о миллионах файлов и миллиардах системных записей?

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

  • Ответить

    > Всё бы ничего, но из-за него задерживали рейс на взлётной полосе Шереметьево, потому что он наотрез отказывался отключать телефон — пять миллионов пользователей онлайн, против сотни на борту.

    Хуже этого может быть только пьяный чиновник на борту. Культура, меж тем, неразрывно связана с уровнем образования!

    > не ошибается только тот, кто ничего не делает!

    Ошибку в доказательстве теоремы Ферма можно понять и простить, а за некоторые принято премию Дарвина давать. Смекаешь?

  • Ответить

    Кстати — зашел недавно на ОК (давно там не был), а мне пишут:

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

    ну и предложение указать номер телефона

    — это последствия аварии или ОК тупо нужен мой телефон?