Pull to refresh

Хронология отключения электричества в датацентре Google App Engine

Reading time 4 min
Views 1.6K
Если электричество отключится у вас дома, то скорее всего ничего серьёзного с вашим компьютером не произойдёт. Может конечно сгореть блок питания или накрыться диск — для вас это неприятно, но не смертельно. А вот что произойдёт, если электричество отключится в большом датацентре, обслуживающем сотни тысяч пользователей?



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

Раннее утро.

7:48. Графики мониторинга начинают показывать что в основном датацентре какие-то проблемы и что число ошибок неуклонно растёт. Примерно в это же время в списке рассылки появляются сообщения от пользователей о проблемах с доступом к App Engine.

7:53. Инженеры эксплуатационной надёжности (Site Reliability Engineers) посылают большому количеству дежурных инженеров сообщение о том, что в основном датацентре отключилось электричество. В датацентрах для такого случая есть резервные генераторы, но в этом случае примерно 25% машин в датацентре не получили резервного питания вовремя и упали. В это время наш дежурный инженер получил сигнал на пейджер.

8:01. К этому времени дежурный инженер определил объём сбоя и установил что App Engine не работает. Согласно процедуре, он по тревоге уведомил менеджеров продуктов и инженерных руководителей о необходимости информировать пользователей о сбое. Несколькими минутами позже в списке рассылки появляется первое сообщение от команды App Engine («We are investigating this issue.»).

8:22. После анализа мы устанавливаем, что хотя электроснабжение датацентра восстановлено, много машин не пережило отключения и обслуживать трафик они не способны. В частности, установлено что GFS и Bigtable кластеры из-за потери большого числа машин находятся в неисправном состоянии и следовательно хранилище данных (Datastore) в основном датацентре использовать нельзя. Команда дежурных инженеров обсуждает аварийное перемещение в альтернативный датацентр. Принимается решение о проведении аварийных работ по процедуре внезапного отключения электричества.

8:36. Команда App Engine посылает дополнительные сообщения о перебое в работе в группу appengine-downtime-notify и на сайт статуса App Engine.

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

8:44. В то время как все пытаются выяснить, какая же из аварийных процедур правильная, дежурный инженер пытается перевести трафик в режиме «только чтение» в альтернативный датацентр. Трафик переведён, но из-за неожиданной конфигурационной проблемы в этой процедуре, работает некорректно.

9:08. Разные инженеры занимаются диагностикой проблем с read-only трафиком в альтернативном датацентре. Однако тем временем, основной дежурный инженер получает данные, которые приводят его к мысли о том, что основной датацентр восстановился и может продолжать работу. У инженера, однако, не было чётких инструкций по принятию этого решения, которые могли бы подсказать ему что восстановление к этому моменту времени маловероятно. В попытке восстановить обслуживание, трафик переводится обратно в основной датацентр, в то время как остальные инженеры продолжают исследовать проблему read-only трафика в альтернативном датацентре.

9:18. Основной дежурный инженер устанавливает, что основной датацентр не восстановился и обслуживать трафик не может. К этому моменту дежурным инженерам ясно, что сигнал был ложным, основной датацентр по-прежнему неработоспособен и что нужно сосредоточиться на альтернативном и на аварийной процедуре.

9:35. Установлен контакт с инженером, знакомым с аварийной процедурой и он начинает руководить процессом. Трафик переносят в альтернативный ДЦ, сначала в режиме «только чтение»

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

9:53. После консультации, теперь уже в online режиме, с соответствующим инженером, правильная документация аварийной процедуры выяснена и подтверждёна и готова к использованию дежурным инженером. Начинается собственно процедура аварийного переноса чтения и записи.

10:09. Аварийная процедура завершается безо всяких проблем. Обслуживание трафика восстанавливается в нормальном режиме, для чтения и записи. В этот момент App Engine считается работающим.

10:19. В список appengine-downtime-notify посылается сообщение о том, что AppEngine работает в нормальном режиме.

Можно выдыхать.

Как завещал великий Джоэл, хватит болтать о бекапах, давайте поговорим о восстановлениях. Когда случается неприятность, нужно чтобы слаженно сработало много шестерёнок. Во-первых, ваша система мониторинга (Что? Вы не знаете что такое система мониторинга? Тогда наверное можете не задумываться об оставшихся шестерёнках) должна вас оповестить через несколько минут после начала неприятностей, а не через две недели в виде удивлённых писем от пользователей. Во-вторых, у вас должны быть резервные мощности. В-третьих, вы должны точно знать или иметь точные инструкции о том, как этими резервными мощностями воспользоваться. Если бы у команды App Engine был один (правильный) комплект документации, то outage продлился бы всего 20 минут вместо двух часов.

Впрочем, на мой взгляд App Engine справился с проблемой неплохо. Представьте себя на месте инженера, у которого ни свет ни заря на пейджере появляется сообщение «Доброе утро, друг! Прямо сейчас твоя компания теряет сотни долларов деньгами и бог весть сколько репутацией. И знаешь, это твоя проблема. Удачи!»
Tags:
Hubs:
+76
Comments 42
Comments Comments 42

Articles