Pull to refresh

Comments 5

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

Полный регламент:

1) Автоматический провиз сервера/виртуалки/контейнера
2) Подъём СУБД с нуля
3) Загрузка резервной копии
4) Комплект SQL тестов (для postgres — pgtap), проверяющих, что данные в SQL «похожи» на свежие и правильные (число клиентов, данные «за вчера», наличие ключевых таблиц, какие-то domain specific queries).
5) Всё это под таймером, гарантирующим, что восстановление происходит за время из SLA.

P.S. Это всё должно делаться роботами и каждый день (каждый интервал времени после бэкапа).
В целом, согласен. Но, это когда резервное копирование делается «с любовью» и под себя. Для массовой услуги такое будет проблематично.
Опять же, не всякую базу можно сдампить за конечное время. У нас база биллинга пару сотен гигабайт занимает. На её дамп невесть сколько времени уйдет. Про восстановление я вообще молчу.
В общем, тут много но. В этом направлении написана вторая часть данного рассказа…
Если у вас данные после восстановления (или время восстановления) не соответствуют ожиданиям бизнеса, у вас плохой IT-процесс.

Что делать? Шардинг, большие мощности, смена типа БД, etc. Проблема решаема в любом случае. Если денег ни на что нет, то остаётся expectation management.

Если вы не можете себе позволить на стейджинге поднять копию продакшена (минус вопросы всяких PCI DSS), то ваш бизнес зависит от того, сколько выпил А Гуй Вам в ночь перед тем, как паял провод 12 В в БП рядом с проводом 5В.
Sign up to leave a comment.