#резервное копирование

страница 2 из 2
пост №959Разработка и инженерия

Поведение при факапе - отдельное искусство.

Сильно упрощая: хостер Digitalocean заблокировал аккаунт клиента и потушил продакшен-серверы стартапа без предупреждения, не дал даже данные выгрузить (автоматический антифрод, да).

Твит про это капитально бомбанул, на ситуацию обратил внимание основатель компании и вот Digitalocean публикует образцовый постмортем.

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

5/5

P.S. Ещё одно напоминание об опасности держать все яйца в одной корзине. Как минимум бэкапы должны быть у второго провайдера.

пост №922Разработка и инженерия

Ходят слухи (пикабу, хабр), что Яндекс вчера случайно удалил виртуальные серверы клиентов в своем облаке (человеческий фактор).

Это отличное напоминание настроить бекапы (если вдруг их нет) и проверить, как работают процедуры восстановления.

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

Внушают опасение слухи, что клиентам написали письма о проблеме только через несколько часов и никакой публичной реакции Яндекса на ситуацию до сих пор нет.

Интересно, там было затронуто так мало машин, что они не видят видят причин официально комментировать? Классическое «это затронуло 0.004% клиентов и вот что мы сделали, чтобы такого больше не случилось» — тоже часть работы.

пост №752Продукты и дизайн

Планируя домашние бэкапы, обнаружил, что стоимость терабайта практически не зависит от объема диcка (раньше, крупные винчестеры стоили дороже).

А ещё убедился, что Numbers эстетически на голову выше Excel и Google Sheets. В нем можно составить цельную историю с множеством таблиц, текстом, картинками. Кайф.

пост №562Разработка и инженерия

У движка «Валли» сложная судьба.

Три года назад Ярослав Кравченко (он тогда отвечал за фронтенд монитора, админки Медузы) за несколько дней запрограммировал «игру». В ней нужно было угадывать положение точки на картинке (обычно используется географическая карта). Это была одна из первых игр Медузы.

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

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

Сейчас произошло второе рождение этого движка. Модный react, наша стандартная админка игр на бутстрапе, postgres-база с горячим резервом, даже тепловая карта кликов читателей — всё дышит 2018 годом.

В ролях: Витя Ходак — дизайн, Гоша Девяткин — программирование, Лёша Прилепский — менеджмент, Илья Красильщик и Саша Поливанов — редакционная поддержка.

https://meduza.io/games/gde-samaya-deshevaya-kvartira-v-rossii-a-samyy-vysokiy-dom

пост №377Разработка и инженерия

Обрыв двух независимых 20kV линии питания и всей оптики до основных площадок обмена трафиком в Европе — не очень частая ситуация. Тем более хороший повод повторить основные правила.

Идеальная схема — когда запросы идут параллельно на две площадки у двух не-аффилированных провайдеров (не два ДЦ у одного и того же провайдера, а прямо разные компании). Админ в Букмейте был из старой гвардии Яндекса и поддерживал такое. В таком сетапе падение одного провайдера проходит незаметно для читателей. Это обычно сложно технически и стоит денег по ресурсам.

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

Уровень пониже – иметь систему, позволяющую быстро развернуть сетап у другого провайдера. Договор или аккаунт с нормальными лимитами, система управления конфигами типа ansible и тд и тп. Ну и свежие бэкапы, конечно же. В этом случае ожидаемый простой — часы.

В противном случае – молимся, постимся и слушаем радио Радонеж при каждом падении.

пост №84Разработка и инженерия

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

So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.

Guys, don't be too hard on yourself. Все мы там были. Несколько месяцев назад аналогичная история произошла в медузе - монга двухлетней давности оказалась без бэкапов. Обнаружили мы это после того, как случайно удалили не тот сервер в админке хостера.

Единственный способ быть уверенным, что все в порядке - попробовать поднять реплику продакшена без продакшена, тестировать не бэкапы, а recovery plan.

Наслаждайтесь: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

пост №18Интернет и платформы

Гугл в очередной раз заблокировал аккаунты и разблокировал только когда поднялась буча в соцсетях. На этот раз речь не о gmail-почте, а о google cloud platform, довольно хорошем конкуренте Amazon AWS. Как всегда у гугла, до поддержки не достучаться, а алгоритмы не такие хорошие, как хотели бы умники из Пало-Альто. :(
Имейте в виду и держите запасной вариант и бэкапы.
http://www.fredtrotter.com/2016/08/22/google-intrusion-detection-problems/