How a Seemingly Well-Planned Server Move Crashed, Burned, and Rose from the Ashes | Rob Walling

Как, казалось бы, хорошо спланированный перенос сервера рухнул, сгорел и восстал из пепла

Фото: hisperati

Около 8 месяцев назад я приобрёл небольшой стартап под названием HitTail. Подробнее об этом приобретении можно прочитать здесь.

Когда сделка закрылась, приложение было в плачевном состоянии. В течение 3 недель мне пришлось перенести всю инфраструктуру, включая большую базу данных, на новые серверы. Это потребовало моей первой за долгое время бессонной ночи. Вот отрывок из письма, которое я отправил другу утром 16 сентября 2011 года в 6:47:

Тема: Моя первая за годы бессонная ночь

Ого, как же я устал. Хуже всего то, что мои дети проснутся в ближайшие полчаса. Будет больно 🙂

Но HitTail теперь на новом сервере и, похоже, работает действительно хорошо. Здорово, что всё под моим контролем. На старом сервере ещё осталась пара компонентов, но они менее важны, и я перенесу их в течение недели.

Напишу снова через несколько часов и расскажу всю историю целиком. Просто безумие, сколько всего пошло не так.

А далее — рассказ о той долгой ночи...

Подготовка

Я приобрёл HitTail в конце августа, и он был в плачевном состоянии. У меня было 3 приоритета, по которым я хотел ударить сильно и быстро, в следующем порядке:

Стабильность — до того как я его приобрёл, сайт падал каждые несколько месяцев, иногда на несколько дней подряд. Чтобы стабилизировать его, мне нужно было перенести всё на новые серверы, исправить несколько серьёзных багов и перенести 250 ГБ данных (1,2 млрд строк).Заткнуть воронку — показатели конверсии были ужасными; мне нужно было рассмотреть каждый шаг процесса и понять, как повысить долю людей, доходящих до следующего шага.Рассказать о нём — заняться маркетингом.

Первоочередной задачей был переезд на новые серверы, что включало отправку курьером 250 ГБ данных на USB-накопителе в новый дата-центр, восстановление из резервной копии, настройку репликации базы данных до синхронизации баз, перевод всего в офлайн на 2-3 часа для объединения двух серверов в один, тестирование всего и переключение.

Если бы только всё было так просто.

Четверг, 10 утра: несвоевременный сбой

Мы планировали отключить старые серверы в 22:00 по тихоокеанскому времени в четверг, но около 10 утра один из них упал. Сам сервер работал, но жёсткий диск отказывал, и он не мог обслуживать веб-запросы.

Я получил несколько писем от клиентов, спрашивавших, почему сервер недоступен, и смог объяснить, что это должен быть последний простой на многие месяцы. Все отнеслись с пониманием и поддержкой. Но я провёл почти весь день, пытаясь продержать сервер живым ещё 12 часов, — безуспешно. Половина пользователей не имела к нему доступа в последние 12 часов на старых серверах.

Четверг, 14:00: где данные?

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

Репликация молча упала примерно за 48 часов до этого, и ни я, ни мой администратор баз данных (DBA) этого не заметили. Так что в 14:00 мы осознали, что буквально на гигабайты отстаём в синхронизации. Имея всего 8 часов до начала окна миграции, мы заархивировали эти гигабайты и начали копировать их с сервера на сервер. Диалог сообщил, что это займёт 5,5 часов — не проблема! У нас был запас в 2,5 часа.

Четверг, ночь, 20:00: копировать и вставить

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

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

Пятница, 1 час ночи: начинается паника

Примерно в это время я начал паниковать. Обработать данные имеющимся кодом было невозможно — алгоритм написан на смеси JavaScript и Classic ASP, которые нельзя было выполнить так же, как они выполняются, когда приложение работает в обычных условиях. И он не отработал бы достаточно быстро, чтобы обработать миллионы строк, которым это требовалось, в сколько-нибудь реалистичные сроки.

Поэтому я сделал одну из самых безумных вещей за долгое время. Я потратил 4 часа, примерно с 23:00 до 3:00, на написание приложения Windows Forms, которое объединяло JavaScript и Classic ASP в одну сборку — причём JavaScript компилировался напрямую в .NET DLL, на которую я ссылался из кода на C#. Затем я перевёл Classic ASP (VBScript) на C# и молился, чтобы это сработало.

И после 2 часов кодирования и 2 часов выполнения это сработало.

Пятница, 3 часа ночи: становится хуже...

В это время DBA пытался объединить две базы данных — копируя 75 миллионов строк данных из одной БД в другую. Это должно было занять 3-5 часов, судя по тестам, которые провёл DBA.

Но это занимало в 20 раз дольше. Диски были безумно медленными, потому что мы работали во время их окна резервного копирования, а часть данных была на общем SAN. К 3 часам ночи, когда мы должны были уже завершать весь процесс, мы были готовы лишь на 10% из 75 миллионов строк.

К 6 утра нам нужно было принять решение. На Восточном побережье было уже 9 утра, и клиенты наверняка вот-вот залогинятся, если ещё не сделали этого. Я был измотан и на пределе из-за количества непредвиденных сбоев, и спросил своего DBA, какие у нас варианты.

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

К счастью для нас, никто ничего не заметил. А приложение, работающее на новом железе, было в 2-3 раза отзывчивее, чем на старой конфигурации.

Пятница, 6:45 утра: победа

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

Создание стартапа — это не только то веселье, о котором вы читаете на Hacker News и TechCrunch... иногда оно даже лучше.