The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Инцидент с СУБД проекта GitLab, opennews (??), 01-Фев-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


89. "Инцидент с СУБД проекта GitLab"  +1 +/
Сообщение от Аноним (-), 02-Фев-17, 17:44 
> Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемся

вы заблуждаетесь...в смысле - надежных платных тоже не бывает.
> Гарантия восстановления данных - 100% (да-да, это бывает)

не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая, чем потери бизнеса.

> Ну и главное не чем бэкапить, а какая policy. Если policy правильная,

главное - что бэкапать. У вас очень мало данных и много лишних денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?).

> У нас полиси такая:
> - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных

"отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется, я уже слегка спойлерю)

> типа СУБД - раз в час

у вас _очень_ мало данных.

> НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным.
> Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода
> команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами

и когда коммитилка и аппрувилка навернулись - мы делаем - что?

> Ну и помимо всякого - все действия логируются, по каждому инциденту заводится

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

> В общем - главное архитектура :-)

главное - забиться в норку, где хорошо платят, вкусно кормят и можно развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага.
А быть админом гитлаба, как видим, действительно плохо.

гитхабу, думаю, не легче.

Ответить | Правка | Наверх | Cообщить модератору

113. "Инцидент с СУБД проекта GitLab"  –2 +/
Сообщение от Андрейка (ok), 06-Фев-17, 14:35 
> вы заблуждаетесь...в смысле - надежных платных тоже не бывает.
> не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая,
> чем потери бизнеса.

Вы из какого-то 20 века что ли? Гарантия восстановления данных заключается не в том, что вам кто-то что-то заплатит. Нет. А в том, что технически решение:
а) проверяет готовый бэкап
б) реплицируется, в том числе в write only storage (т.е. без возможности "случайно" удалить реплику, если мастер грохнулся)

> главное - что бэкапать. У вас очень мало данных и много лишних
> денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?).

Ну "мало" или "много" понятия относительные. 15-20Тб в СУБД (postgres), ну и так, по мелочи еще 50Тб наберется менее критических данных


> "отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так
> много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши
> действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется,
> я уже слегка спойлерю)

30-50Тб это мало, что Вы :-)
200Тб - это еще куда ни шло. И это только одна полка, а их само собой несколько. failover, катастрофоустойчивость и т.д.

А про "нет денег", так это Вы, наверное, к русскому бизнесу привыкли, да? Сочувствую
Если на бэкап бизнес-критических данных нет денег, то такой бизнес лучше вообще не начинать, ну а Вам в такой компании работать не рекомендую

> у вас _очень_ мало данных.

Сколько для Вас - много данных? Ну, с какого числа оно хотя бы перестает быть "мало данных". Это понятия относительные

>> команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами
> и когда коммитилка и аппрувилка навернулись - мы делаем - что?

Коммитилка/Апрувилка - это Jenkins, который хранит свой конфиг в git, а образ виртуалки бэкапится. Если оно вдруг сломалось, то поднимается за 15 минут двумя-тремя командами, одна из которых apt-get install jenkins на чистой виртуалке

> Есть время тыцать мышью в неторопливый интерфейс жиры (на что обычно уходит
> куда больше времени, чем на саму работу).

Ага. Agile слышали. Или вы до сих пор по email инциденты трекаете? Вы точно из 20 века

> Поверьте, вы не гитлаб.

Мы - больше чем gitlab. По многим показателям

> главное - забиться в норку, где хорошо платят, вкусно кормят и можно
> развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага.
> А быть админом гитлаба, как видим, действительно плохо.

Завидуйте молча. Зависть вообще - смертный грех. Уверен на 99.9% вы даже не на уровне админа гитлаба

Ответить | Правка | Наверх | Cообщить модератору

114. "Инцидент с СУБД проекта GitLab"  +1 +/
Сообщение от QuAzI (ok), 07-Фев-17, 00:28 
Гонору у вас конечно много, с этим не поспоришь, но ~где пруфы~ дайте ссылку что почитать конкретнее же?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру