Некоторых зацепило конкретно. Пока идет восстановление быстрые уроки по горячим следам
1. Бекапы должны лежать вне основного провайдера (off-site backup). Таким образом вы делаете микро-DRP, которое позволит сохранить данные, даже если провайдер рухнет, что уже бывало с OVH и AWS
2. Бекапы должны лежать в максимально простом формате, который можно в случае необходимости посмотреть и положить куда надо руками. Это нужно для того, что бы при аварийном восстановлении во временное место у другого провайдера, можно было ими воспользоваться в ручном режиме, даже если инфраструктура восстановления недоступна.
Применение систем резервного копирования, сохраняющих данные в проприетарном формате, может резко увеличить время восстановления.
3. Если инструкция по восстановлению лежит внутри упавшего контура, толку от нее, как выясняется, немного!
4. Тестовые переключения и восстановления - возможность снизить стресс и сделать процесс восстановления предсказуемым по времени. Если у вас просто есть бекап инженерам нужно вспомнить где он лежит, понять что с ним делать, как и куда восстанавливать, как понять, все ли восстановилось и как это проверить. Регулярные (это важно) тренировки позволяют инженерам превратить форс-мажор в рутинный процесс.
5. Базу данных нужно бекапить в бинарном формате. SQL формат очень удобен что бы посмотреть несколько нужных записей, но резко увеличивает время восстановления. Если бинарную копию базы достаточно скопировать на сервер, то sql дамп нужно загружать таблица за таблицей, это может занять часы, во время которых прод будет лежать. Об этом говорили на встрече на прошлой неделе.
6. Бекап конфигурации приложений и git/gitlab/etc. Это не очевидные, но очень важные данные, которые нужны на втором шаге, когда какой-то временный вариант обслуживания пользователей появился и пришло время развертывания полноценной площадки. И тут выясняется, что git'а больше нет, а все что есть это локальные репо разработчиков.
7. Переход на новую площадку это всегда новые, интересные и удивительные открытия. Что бы быстрее пройти фазу стабилизации очень помогает мониторинг, в идеале конечно заранее поставленный, а в худшем случае быстро развернутый. У нас например есть сборка, которую можно развернуть за 15 минут и подключить туда хосты. Ничего гениального, но базовые метрики, позволяющие увидеть, если что-то идет не так очень помогают.
Итого, чеклист потери датацентра:
1. Бекапы лежат как минимум в одном месте за пределами площадок
2. Их можно развернуть при необходимости руками
3. Вне текущей площадки есть инструкция по запуску новой
4. По этой инструкции хотя бы раз за последние три месяца происходило восстановление из off-site бекапов баз и приложений.
5. Развертывание прода было успешно выполнено за удовлетворительное время.
Поделитесь этим постом с коллегами, которых зацепила ситуация с яндексом, для них это практически готовый постмортем.
Подробнее про организацию DRP постом выше.
Берегите себя и не роняйте продакшн!
@dowtime_bar #DRP
Post #431
989

- ❤ 1