форумы  помощь  поиск  регистрация  вход/выход  слежка

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

"Инцидент с СУБД проекта GitLab"	+/–
Сообщение от opennews (??) on 01-Фев-17, 14:23
Разработчики платформы для организации совместной разработки GitLab сообщили (https://twitter.com/gitlabstatus) о частичной (https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCx...) утере содержимого СУБД, обслуживающей инфраструктуру проекта. До окончания разбирательства сайт GitLab.com временно выведен из строя. В процессе внесения оптимизаций, в ответ на  обрушившуюся на проект DoS-атаку, администраторы случайно удалили актуальное содержимое СУБД. Утверждается, что непосредственно git-репозитории с кодом и wiki не пострадали, проблема затронула только сопутствующие данные, такие как  merge-запросы, учётные записи разработчиков и обсуждения проблем. В настоящее время производится попытка восстановления данных из резервной копии, об актуальности которой не сообщается. URL: https://news.ycombinator.com/item?id=13537052 Новость: https://www.opennet.ru/opennews/art.shtml?num=45957
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

2. "Инцидент с СУБД проекта GitLab"	–3 +/–
Сообщение от Аноним (??) on 01-Фев-17, 14:25
Хипстеры... DROP PgSQL бэкапы не нужны ага,,,
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Инцидент с СУБД проекта GitLab"	+36 +/–
Сообщение от Аноним (??) on 01-Фев-17, 14:27
Доверяйте облакам, говорили они. Держите все свои важные данные в облаках. Они отказоустойчивые и регулярно бекапятся, говорили они. Ну вот и посмотрим.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Инцидент с СУБД проекта GitLab"	+14 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 14:54
	> Доверяйте облакам, говорили они. Держите все свои важные данные в облаках. > Они отказоустойчивые и регулярно бекапятся, говорили они. > Ну вот и посмотрим. просто ещё не реализовали облаков для облаков. Вот тогда-то заживём!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	18. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . on 01-Фев-17, 15:15
	> просто ещё не реализовали облаков для облаков. реализовали - они ж написали, "мы регулярно бэкпались в azure". > Вот тогда-то заживём! Но что-то пошло не так...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	101. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от алекс (??) on 02-Фев-17, 20:09
	нашли в чём бэкапится
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	61. "Инцидент с СУБД проекта GitLab"	+4 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 21:51
	Ну так раз в 6 часов - это разве не регулярно? Если хочешь чаще - то бесплатного гектара на Дальнем Востоке тебе ненадолго хватит, чтобы складывать физические носители.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Инцидент с СУБД проекта GitLab"	–3 +/–
Сообщение от Аноним (??) on 01-Фев-17, 14:36
Да это просто жесть! Как-так! это все школьники организовали и забыли про бекапы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Инцидент с СУБД проекта GitLab"	+16 +/–
	Сообщение от . on 01-Фев-17, 15:03
	они не забыли: So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place. => we're now restoring a backup from 6 hours ago that worked как обычно - если денег никому не платить, инфраструктуру держать на последнем издыхании, времени разбираться в том что до тебя кто-то настраивал ни у кого не остается, все заняты срочным возведением новых подпорочек и костыликов (отсюда и пять кривых бэкапов вместо одного работающего), то в 23:00 затраханный в рот и в зад админ ошибается окошком. Кстати, кто виноват, совершенно точно известно, его и уволить.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "Инцидент с СУБД проекта GitLab"	+9 +/–
	Сообщение от . on 01-Фев-17, 15:14
	> костыликов (отсюда и пять кривых бэкапов вместо одного работающего), то в > 23:00 затраханный в рот и в зад админ ошибается окошком. кстати, это был хороший админ, поскольку догадался сделать _нештатный_ бэкап до начала работы, не надеясь на автоматику (или хорошо зная, что она нерабочая). > Кстати, кто виноват, совершенно точно известно, его и уволить. вот его и уволят, будьте уверены.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	34. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от поледанныхотсутств on 01-Фев-17, 16:26
	кого уволить? кто нанял недостаточно админов?
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	95. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . on 02-Фев-17, 18:17
	> кого уволить? кто нанял недостаточно админов? как это его уволить? Это ж человек, тяжким трудом сэкономивший фирме N*(admin_salary) денег! А вот тот, который окошком ошибся - нанес ущерба на 10*N (плюс 1000*N упущенная прибыль)! Не, ну может, конечно, на первый раз пожурят и заставят отрабатывать два дежурства за раз - он вон уже написал как он героично принимает меры для исключения повторения проблемы в будущем (не работать после 18 и спать вовремя в списке, заметим, отсутствуют).
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	22. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от IB on 01-Фев-17, 15:20
	> они не забыли: Да де-лы не знающие, что "бэкапы которые успешно не развернули хоть раз - не бэкапы" должны страдать!
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	26. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Pavel (??) on 01-Фев-17, 15:36
	Все очень сильно зависит от размера этого самого бекапа. Знаю одну контору у которой дамп БД делается в течении ~30 часов и следом начинается следующий дамп. Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачивать ибо это бессмысленно, и они нужны только на совсем крайний случай когда умерли все реплики и реплики отстающие на 6, 12 и 24 часа от мастера. И да, вариант что из дампа ничего не развернётся совершенно не нулевой.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	33. "Инцидент с СУБД проекта GitLab"	+7 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:23
	А развернуть тестовую базу раз в полгода никому в голову не приходило?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	36. "Инцидент с СУБД проекта GitLab"	+4 +/–
	Сообщение от Andrey Mitrofanov on 01-Фев-17, 16:30
	> А развернуть тестовую базу раз в полгода никому в голову не приходило? Уверенность в одном из 146 (*) бэкапов это Важно. (*)Никакой связи с Чуровым, совпадение: 365.24/2*24/30 = 146.096.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	39. "Инцидент с СУБД проекта GitLab"	+5 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:40
	> Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачивать Предлагаю вариант: развернуть хотя бы раз.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	82. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от anonymous (??) on 02-Фев-17, 13:23
	бывает, что не на чем. например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300 и оракловая база, которая бэкапится отдельно. да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще одной такой системы нет.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	92. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от tacitusdef (??) on 02-Фев-17, 18:06
	в /dev/null?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	94. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . on 02-Фев-17, 18:12
	> бывает, что не на чем. > например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300 > и оракловая база, которая бэкапится отдельно. > да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще > одной такой системы нет. а потом "ORA 0600"(или как там правильно, давно не видал) и мы идем искать новую работу? ;-) [нет, я понимаю, что там кластер, массив с избыточностью, кроссчек и все такое, но оракл такой изобретательный ;-) ] все ж таки 60vm это еще не фатально, можно биться с начальством за тестовую ферму.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	81. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от vitalif (ok) on 02-Фев-17, 12:09
	Ну лучше чем в 0.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	60. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 20:00
	Что за детский сад? Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть неделю. Главное автоматически.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	68. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Led (ok) on 02-Фев-17, 00:09
	> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиков Все "отдельные сервера" заняли вэб-макаки под свои "докеры с нодами".
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	87. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 17:05
	> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант > для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть > неделю. разница существенная - во втором случае, ты заметишь проблему только через неделю (или не заметишь вовсе, потому что развернуть-то оно развернуло, а внутри лажа). Соответственно, будь тамошний админ таки же как ты - и не постели соломку лично - им бы пришлось откатиться на бэкап недельной, а  не шестичасовой, тухлости. Или двухнедельной. Или вообще никакого. А цена этого "отдельного сервера", который, частенько, не отдельный сервер вовсе, а отдельный кластер на пяток стоек - очень и очень немаленькая. А инвестор жадный. Ну и учти, что если бэкап восстанавливать неделю - то ты потеряешь половину пользователей. То есть в какой-то момент становится понятным, что ну...вообще-то...ну хорошо бы в принципе иметь бэкап хотя бы вот для запуска тестового инстанса при мега-апгрейде инфраструктуры, но пользы от него не так много, как хотелось бы. > Главное автоматически. наоборот - главное, хоть иногда человеческим глазом смотреть. Иначе, как и в этом случае, может оказатьтся, что гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор. А для этого опять же надо чтобы у админов на это было время и вдохновение. А не 23:00, а таск все еще не закрыт.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	99. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Andrey Mitrofanov on 02-Фев-17, 19:03
	>>Какая разница сколько это занимает, хоть неделю. >тухлости. Или двухнедельной. Или вообще никакого. > очень немаленькая. А инвестор жадный. >восстанавливать неделю - то ты потеряешь половину пользователей. >> Главное автоматически. >гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор. "Нет пути."ТМ > А для этого опять же надо чтобы у админов на это было > время и вдохновение. А не 23:00, а таск все еще не > закрыт. "Усё пропалоушеф."Ц +++Люто плюсую, пиши ещё - завтра пятница.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	66. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от XoRe (ok) on 01-Фев-17, 23:33
	> Естественно никто даже не пробовал их разворачивать ибо это бессмысленно Нужно хотя бы раз развернуть бекап, чтобы проверить, что там есть все, что нужно. Для примера - у mysql есть хранимые процедуры и функции (stored routines (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. А если не указать, не сохраняет. Если они активно использовались, но дамп делался без них... Есть шанс узнать что-то новое для себя в самый неподходящий для этого момент. Дело в том, что если про эту опцию не знать, можно потратить много времени на поиск причины. С виду то как - дамп вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время на вытаскивание этих хранимок из кода или девелоперской среды.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	93. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от . on 02-Фев-17, 18:08
	> Для примера - у mysql есть хранимые процедуры и функции (stored routines > (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. А ух ты, давно я не брал в руки шашек. В смысле, что они, оказывается, для этого ключик сделали (правда, судя по ману - кривой, портит даты, не от того юзера заводит). вообще-то сохраняет, но если mysqldump --all ;-) Приятные последствия при мерже на другой кластер - побочный эффект ;-) А их использование по прежнему разваливает репликацию, или это я тоже уже от жизни на пять лет отстал? > вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время > на вытаскивание этих хранимок из кода или девелоперской среды. а они там - опа, не той версии и "той" вообще нигде нет ;-) P.S. чего только не узнаешь странного, тролля на опеннете
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	80. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от ivn86 (ok) on 02-Фев-17, 11:30
	> Естественно никто даже не пробовал их разворачивать Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл. Т.е. с виду всё хорошо. И только когда возникла необходимость его распаковать чел понял, что исходный каталог он уже не получит.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	104. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от freehck (ok) on 03-Фев-17, 03:04
	> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл Хм. Что-то тут не так в этом комментарии. gzip на каталог, если с флагом -r, даст вам на выходе каталог с .gz-шниками. А без флага -r вообще откажется работать. Какой же там файл получился на выходе? К тому же через прогнозируемое время. И в довесок прогнозируемого объёма.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	105. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от ivn86 (ok) on 03-Фев-17, 07:35
	>> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл > Хм. Что-то тут не так в этом комментарии. > gzip на каталог, если с флагом -r, даст вам на выходе каталог > с .gz-шниками. А без флага -r вообще откажется работать. > Какой же там файл получился на выходе? К тому же через прогнозируемое > время. И в довесок прогнозируемого объёма. С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout. Но челу нужен был файлик и он перенаправил stdout в файлик: https://www.linux.org.ru/forum/general/11356750 Речь не о том, что даже стандартными утилитами в неумелых руках можно выстрелить себе в коленку, а о том, что его при этом ничего не смутило -- файл то большой, значит все данные в нём есть, значит проверять ничего не нужно.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	107. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от freehck (ok) on 03-Фев-17, 09:52
	> С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout. Понял. Весьма удивлён изобретательности человека. Так отстрелить себе ногу -- это ещё додуматься надо. :)
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	56. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 19:17
	Чувак на самом деле не сильно виноват, а виноват тот кто не настроил процесс тестирования бекапов.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	91. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от . on 02-Фев-17, 18:01
	> Чувак на самом деле не сильно виноват, а виноват тот кто не > настроил процесс тестирования бекапов. а это тот чувак и был (в числе прочих). Но никакого дополнительного времени на это у него никогда не было, а ddos - вот он, уже пришел, и кластер (который в штатном режиме сам себе бэкап) развалился. Подождите с вашим ддосом недельку, я тут хоть бэкапы настрою и протестирую, можно? ребята, вы явно не работали никогда в подобных конторах. У вас очень спокойная жизнь.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	44. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 17:02
	Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1. p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не в той команду вводим :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	64. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Фев-17, 22:59
	> Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1. > p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не > в той команду вводим :) Раскраска подсказок, пауза перед нажатием энтера (вплоть до посидеть на руках, подумать) -- ну и не работать в уставшем виде... нажито непосильным трудом по разгребанию последствий такого в своих собственных масштабах.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	71. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от KonstantinB (ok) on 02-Фев-17, 02:48
	> Раскраска подсказок Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от hostname/username. (Только никто не спрашивайте как, этот костыль из cut/od/sed/expr показывать стыдно, наверняка можно сделать лучше и проще). Ручками задавать цвета лениво и на это бы быстро забил, а так оно шамо.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	74. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 05:37
	Да ладно, покажи, чоуж.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	86. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Фев-17, 15:40
	> Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от > hostname/username. (Только никто не спрашивайте как, этот костыль из cut/od/sed/expr > показывать стыдно, наверняка можно сделать лучше и проще). А покажите, действительно.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	77. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 10:14
	Не работать уставшим, посидеть подумать, угу. Особенно когда стоят над душой и нудят: - Вот вы здесь сидите, а там все стоит. - Что стоит ? - Все стоит
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	85. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Фев-17, 15:38
	> Не работать уставшим, посидеть подумать, угу. > Особенно когда стоят над душой и нудят: > - Вот вы здесь сидите, а там все стоит. > - Что стоит ? > - Все стоит "если я нечаянно доломаю -- ты правда починишь?  нет?  тогда не мешай делать, что ещё могу" Особо упорным можно напомнить, что ясновельможный пан Качиньский с первого раза (когда КВС его не послушал и сделал как надо над Грузией) не допёр, в итоге ладно бы сам угробился под Смоленском, так ещё других угробил и дров наломал.  И спросить, сядут ли за руль автобуса, засыпая. Можно ещё предложить поумножать или хотя бы поскладывать многозначные числа в уме, при этом подёргивая другими вопросами -- чтоб хоть немножко дошло, почём прерывания.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	102. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от . on 03-Фев-17, 00:14
	> Не работать уставшим, посидеть подумать, угу. Особенно когда стоят над душой и нудят: я тебе страшный девопский тайна открою (ее даже Шигорин не знает, потому что альтовские сервера нафиг никому не уперлись): когда у тебя высоконагруженный проект, да еще пусть под слабой даже атакой и в нем половина мощности внезапно ложится - у тебя "над душой" стоит даже не эффективный менеджер (его уже самого к тому моменту в интересных позах имеет инвестор) а система мониторинга, заходящаяся воем, что сейчас вообще ВСЕ пойдет по женскому органу. То есть тупит база- начинают тормозить прокси - начинают тупить фронты - юзвери злобно жмакают релоад, увеличивая и без того большую нагрузку - и, скорее рано чем поздно, ты получаешь на ВСЕХ хостах LA500 - и сделать с этим уже ничего нельзя, отключай нахрен входящий канал и перезагружай хосты ресетом, это ж линукс, оно уже не очухается. Это все здорово напоминает управление чернобыльским реактором - за пять минут до взрыва. Ничем, кроме найма большего числа админов, чтобы не лечить неизлечимо больного, а планомерно убирать узкие места, те же бэкапы проверять и переделывать в порядке текущей работы, покупки больше серверов, чтобы было что вводить в качестве резервов (почему, собственно, реплик только две, при том что одна не держит?), в общем - денег, денег и еще раз денег, сравнимо с тем что уже вгрохано в этот сервис, а не еще 5%, это не лечится. А денег в маргинальных проектах мало и их жмут, особенно когда оно уже как-то завелось и вроде бы работает - "какие ЕЩЕ бэкапы, мы вам azure оплатили, пользуйтесь!". Проще назначить крайних, потерять пол-дня данных и день на восстановление, ну и процентов десять юзербазы, на первый разок.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	103. "Инцидент с СУБД проекта GitLab"	–2 +/–
	Сообщение от Michael Shigorin (ok) on 03-Фев-17, 00:19
	> я тебе страшный девопский тайна открою (ее даже Шигорин не знает, > потому что альтовские сервера нафиг никому не уперлись) ...то-то у нас zabbix допиливали ;-) https://support.zabbix.com/browse/ZBXNEXT-2253
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	79. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от SysA on 02-Фев-17, 11:07
	> Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1. > p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не > в той команду вводим :) Это еще хорошо, если только 2!.. :) А если их 42 на 3-х мониторах и там еще закладок немеряно?!.. а среди них куча screen'ов и кластерных терминальных сессий (1-to-many). И если к тому же миграция ночью после многих часов работы, то можно запросто ошибиться. И хорошо, что все же был нормальный архив... а админам сочувствую и понимаю...
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	67. "Инцидент с СУБД проекта GitLab"	+4 +/–
	Сообщение от Led (ok) on 02-Фев-17, 00:07
	> забыли про бекапы? Когда в голове дэдлайны, а над головой ПиЭмы, про бэкапы не думают.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Инцидент с СУБД проекта GitLab"	+3 +/–
Сообщение от Аноним (??) on 01-Фев-17, 14:40
Не было, и вот опять.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Инцидент с СУБД проекта GitLab"	+1 +/–
Сообщение от Аноним (??) on 01-Фев-17, 14:45
Надежность выбора технологий уровня GitLab, GiHub профинансировал ZFS OnLinux и использует его на Bare Metal серверах в это  время под git-хранилища.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 15:01
	ZFS головного мозга дeтектед.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Инцидент с СУБД проекта GitLab"	–8 +/–
	Сообщение от . on 01-Фев-17, 15:10
	> Надежность выбора технологий уровня GitLab, уровня линyпс. (тут и постгрез, с его невменяемой неработающей без ручного пинания репликацией, и снапшоты насквозь гнилого lvm, выполняющиеся полтора дня, так что очень не хочется их делать лишний раз, и сам lvm - а потом они удивляются, чавойта постгрез так тормозит, ага) Напомню, что гугль (когда последний раз делился этой информацией, а это было давно) как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала. Не пытайтесь проделать это дома. > GiHub профинансировал ZFS OnLinux и использует его на Bare Metal серверах в ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе нессыкотно этим пользоваться. Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная, но, возможно, у гитхаба есть возможность шевелить толстым бревном в дупе разработчиков всякий раз, как там что-то ломают. У гитлаба, очевидно, такой возможности нет - они выбрали те инструменты, какие могли.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	24. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от KonstantinB (ok) on 01-Фев-17, 15:30
	> постгрез, с его невменяемой неработающей без ручного пинания репликацией Поднял один раз, ни разу не пинал, все работает. ЧЯДНТ?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	38. "Инцидент с СУБД проекта GitLab"	–3 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:39
	один раз Даже фраза есть такая: "один раз не ***".
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	45. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от эцсамое (ok) on 01-Фев-17, 17:07
	да я и много раз поднимал, всё чудесно работает. для тех кто руками не умеет даже pgbarman придумали
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	65. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 23:18
	> уровня линyпс. > постгрез Ну да, был бы оракл, или mssql, то этого бы никогда не случилось. Гарантирую. > Напомню, что гугль (когда последний раз делился этой информацией, а это было давно) как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала. Не пытайтесь проделать это дома. Без журнала, ибо люстры. Ты сам себе и объяснил, только немножко не то. У экстентных ФС одна облать применения, а у снапшотных - другая. > ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе нессыкотно этим пользоваться. О, так он оказывается платный? Или стаёт стабильнее только у финансирующих? > Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная, Дооо, чтение там забанили. Но не волнуйся, тебе не придбется там держать вообще ничего > ибо очень уж эта поделка странная А для кого-то - привычная. Твоя некомпетентность не является показателем. > шевелить толстым бревном А что ты делаешь на опеннете?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	88. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 17:27
	>> уровня линyпс. >> постгрез > Ну да, был бы оракл, или mssql, то этого бы никогда не _этого_ - ручного стирания каталогов под репликацию - да, никогда не случилось бы. Другие грабли возможны, но не такие тупые. >> Напомню, что гугль (когда последний раз делился этой информацией, а это было давно) >> как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала. > Без журнала, ибо люстры. ибо тормоз. А люстры - просто удобный способ обойти проблему почти бесплатно (надо думать, в случае чего ее просто автоматически пересетапят на соседнюю картонку). Но ext2 - это ж не просто без журнала, там еще вагон и маленькая тележка проблем. А прообнимались они с ней ПЯТЬ лет после того как все на нее забили, и ext4 была уже давным-давно объявлена совершенно стабильной и работающей. Делать им нечего, думаешь? ;-) >> ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе >> нессыкотно этим пользоваться. > О, так он оказывается платный? Или стаёт стабильнее только у финансирующих? естественно второе - "держи кнут, он твой!" То есть именно проблемы финансирующих и будут решать в первую (а так же вторую и третью) очередь. А не ответят что это "нетиповая конфигурация", "особенность линукс-сборки, см правильную в нашем иллюмосе", "у нас не воспроизводится" и т д. А пользующие "бесплатно" могут лично сидеть над дампами, тоже бесплатно, и сутками. >> Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная, > Дооо, чтение там забанили. Но не волнуйся, тебе не придбется там держать чтение, может, внезапно, не прочитать, ага. Причем ты об этом узнаешь, когда уже будет поздно. Или начать читать так, что лучше б сразу не прочитало (высоконагруженный проект, да) - кстати, совсем недавно в этом месте выскочили здоровенные грабли, судя по патчам - не специфичные для платформы. >> ибо очень уж эта поделка странная > А для кого-то - привычная. Твоя некомпетентность не является показателем. "привыкнуть" и не замечать странностей - это и есть некомпетентность (совсем другое - понимать, чего ради, что возможно вместо, и чем грозит). А уж в этом случае, когда речь о целой отдельной науке, тамагоченьи zfs (и ее отдельном разделе, тамагоченьи zfs не на bsd-основе) - устрашающая. Ты, надеюсь, не сотрудник гитхаба? У меня там есть ценные игрушки, не хотелось бы их потерять. Вставший раком _без_ очевидных внешних причин zfs-пул обычных, не гитхабовых, размеров - нифига не является редкостью необычайной. И далеко не всегда легко и просто удается это починить, и тем более - понять, что вызвало проблему. Упомянутая история с неправильным размещением блоков - исключение, там нашли. Но пока разработчики что-то ищут, ты сидишь, глядя на индикаторы io/la ползущие к краю красной зоны, и совершенно ничего не можешь сделать. >> шевелить толстым бревном > А что ты делаешь на опеннете? издеваюсь над некомпетентными самоуверенными админами локалхоста, что ж еще
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

14. "Инцидент с СУБД проекта GitLab"	+1 +/–
Сообщение от Аноним (??) on 01-Фев-17, 15:06
> Реагируя на обрушившуюся на проект DoS-атаку администраторы попытались разнести нагрузку на СУБД PostgreSQL на два сервера, организовав репликацию данных То есть, раньше реплики БД у них не было. Хипстота...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 19:08
	Была, но из-за атаки вторая БД начала лагать и репликация отвалилась. В попытке поднятия репликации на второй БД было решено очистить каталог постгреса, но случайно промахнулись окном. https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCx...
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	57. "Инцидент с СУБД проекта GitLab"	+4 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 19:21
	Это выглядит как желание прибить муху которая сидит на кнопке запуска ядерных ракет.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	75. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 08:59
	> Это выглядит как желание прибить муху которая сидит на кнопке запуска ядерных > ракет. Удаление содержимого директории data на сервере куда будет производиться репликация - необходимый шаг. Алгоритм настройки репликации примерно такой: удаляем data на slave, ставим checkpoint на master, переносим целеком содержимое директории data с master на slave, запускаем slave, убираем checkpoint. PS. Много раз случалось не в той консоли что-то запускать.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	106. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от qqq (??) on 03-Фев-17, 08:53
	>Удаление содержимого директории data на сервере куда будет производиться репликация - необходимый шаг. mv data old-data mkdir data
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	108. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от пох on 03-Фев-17, 17:19
	> mv data old-data > mkdir data надо б на досуге посмотреть результат этого действа на живом постгрезе - полагаю, будет весьма феерично, хотя до бэкапа может дело и не дойдет. Ну и если поторопиться сделать после этого rm -r old-data - можно остаться ровно у того же разбитого корыта (а если не поторопиться - места на две копии не хватит, скорее всего)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

16. "Инцидент с СУБД проекта GitLab"	+5 +/–
Сообщение от burik666 (ok) on 01-Фев-17, 15:14
https://www.youtube.com/watch?v=nc0hPGerSd4 Live Stream восстановления.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:06
	а может ради этого всё и задумывалось?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	40. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:41
	Куда донаты кидать?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	46. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 17:42
	Прикольно. Одного из них Ёрик зовут)) "Бедный Ёрик"(С)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	47. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 17:51
	Еще и спец по СУБД. Точно бедный.))
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

20. "Инцидент с СУБД проекта GitLab"	+12 +/–
Сообщение от aNoN on 01-Фев-17, 15:17
Нормальное дело. Можно подумать, никто из вас "reboot" не в том окошке мультиплексора терминалов не запускал...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Инцидент с СУБД проекта GitLab"	+2 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 15:20
	Набрать ребут не в том окне - нормально. Не нормально иметь единственный сервер, ребут или полный выход которого из строя (в данном случае путем удаления файлов БД) приведет к отказу в обслуживании.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	35. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 16:29
	Первый раз - невнимательность. Регулярно - СДВ (СДВГ). Лечится. Симптомы СДВ: 1. неспособен удерживать внимание на деталях: из-за небрежности, легкомыслия допускает ошибки 2. с трудом сохраняет внимание при выполнении заданий 3. часто складывается впечатление, что больной не слушает обращённую к нему речь и поступает по своему 4. оказывается не в состоянии придерживаться предлагаемых инструкций и справиться до конца с выполнением заданий 5. испытывает сложности при самостоятельном выполнении заданий 6. избегает заданий, которые требуют длительного сохранения умственного напряжения 7. часто теряет необходимые вещи и файлы 8. легко отвлекается на посторонние стимулы (напр. форумы) 9. проявляет забывчивость 10. ломает всё подряд (в то же время делает вид, что не он это делал) Знакомо? В России СДВ не считается заболеванием и больные им д---илы продолжают портить другим людям жизнь.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	41. "Инцидент с СУБД проекта GitLab"	–3 +/–
	Сообщение от Andrey Mitrofanov on 01-Фев-17, 16:45
	> Знакомо? > В России СДВ не считается заболеванием и больные им д---илы продолжают портить > другим людям жизнь. Зато в мериканнии детишек с этим "заболеванием" лечат [медицинским] кокаином. Человецищи! >/<
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	48. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 17:52
	Признавайся, где ты спер мою биографию?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	96. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 02-Фев-17, 18:23
	> Признавайся, где ты спер мою биографию? тыщи вас!
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	90. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 17:51
	> Можно подумать, никто из вас "reboot" не в том окошке мультиплексора терминалов > не запускал... clear config гораздо интереснее. И бесплатного резерва в 50% мощности обычно нет ;-)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "Инцидент с СУБД проекта GitLab"	+1 +/–
Сообщение от Аноним (??) on 01-Фев-17, 15:20
А-ха-ха ... до боли знакомая ситуация. Сам так делал не раз.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Инцидент с СУБД проекта GitLab"	+2 +/–
Сообщение от Shamil on 01-Фев-17, 15:31
http://checkyourbackups.work/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Инцидент с СУБД проекта GitLab"	+3 +/–
	Сообщение от user (??) on 01-Фев-17, 15:55
	http://www.worldbackupday.com/ru/
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Инцидент с СУБД проекта GitLab"	+2 +/–
Сообщение от Аноним (??) on 01-Фев-17, 15:40
Только зануды делают резервные копии: настоящие мужчины просто закачивают все важное на ftp, позволяя остальным отзеркалировать это. Линус Торвальдс
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Инцидент с СУБД проекта GitLab"	+5 +/–
	Сообщение от Neptus on 01-Фев-17, 15:47
	http://russianfedora.pro/posts/kernelorg-otkazyvaetsia-ot-ft.../
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	97. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Фев-17, 18:40
	> http://russianfedora.pro/posts/kernelorg-otkazyvaetsia-ot-ft.../ >> на ftp на != по ;-)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	37. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Andrey Mitrofanov on 01-Фев-17, 16:33
	>просто закачивают все важное на > ftp, Просто. На. В. Git. Же. > Линус Торвальдс
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Инцидент с СУБД проекта GitLab"	+7 +/–
Сообщение от Аноним (??) on 01-Фев-17, 15:55
#гитлабживи
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Инцидент с СУБД проекта GitLab"	+4 +/–
Сообщение от omnomnin on 01-Фев-17, 16:06
у них все на Azure nuff said
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Инцидент с СУБД проекта GitLab"	–5 +/–
Сообщение от Аноним (??) on 01-Фев-17, 16:49
Вот, что бывает с ручным devops. NixOS - наше всё!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	49. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от www2 (ok) on 01-Фев-17, 18:40
	И что, там возможно настроить репликацию в PostgreSQL одной опцией? А если в этих ваших nix-файлах писатель ошибку допустил? Автоматика, товарищ, не отменяет головы. Автоматика даже гораздо опаснее рук, потому что с автоматикой можно сделать больше и быстрее. Читай - наломать дров больше и быстрее. Руками ты один сервер уронишь, а автоматикой - целый кластер.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	51. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 18:50
	Можно. Фишка с Nixos в воспроизводимости: проверил в vbox, задеплоил. https://github.com/zalora/nixsap/blob/092d712689eec989003ec2...
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	70. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от й on 02-Фев-17, 00:44
	в любой системе управления конфигурациями так можно. да даже и с шелл-скриптами. man vagrant
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	53. "Инцидент с СУБД проекта GitLab"	–2 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 18:54
	> И что, там возможно настроить репликацию в PostgreSQL одной опцией? А если > в этих ваших nix-файлах писатель ошибку допустил? Автоматика, товарищ, не отменяет > головы. Автоматика даже гораздо опаснее рук, потому что с автоматикой можно > сделать больше и быстрее. Читай - наломать дров больше и быстрее. > Руками ты один сервер уронишь, а автоматикой - целый кластер. Все можно сделать "одной опцией", даже с puppet или скриптом bash. Только nix/nixos позволяют это делать безболезненно и естественно.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	54. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 01-Фев-17, 19:02
	И безотносительно nixos, надо правильно мыслить. Не репликацию постгрес, а сервер с репликой. Даже с Puppet должен быть соответствующий шаблон. Нужна ещё одна реплика? Ок, вот новая нода класса postgres-repl. А не как эти Африки.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	109. "Инцидент с СУБД проекта GitLab"	–1 +/–
	Сообщение от пох on 03-Фев-17, 17:28
	> И безотносительно nixos, надо правильно мыслить. Не репликацию постгрес, а сервер с > репликой. Даже с Puppet должен быть соответствующий шаблон. Нужна ещё одна > реплика? Ок, вот новая нода класса postgres-repl. и в датацентре сами собой воздвигаются новые стойки, из воздуха в них запрыгивают полки с дисками и головы с lvm'ами... эх, программисты... когда ж до вас дойдет, что у девопсов немного другой мир, совсем не такой как в вашей тестовой виртуалочке? Ну и вот образовался у тебя "cервер с репликой", а реплики-то в нем и нет. Данные еще перелить надо, не перегрузив сеть, дисковый io уцелевшей полки и постгрезовую голову. А нагрузка растет, а часики тикают... А ты такой - "опа, заметил что надо руками стирать data, у самого постгреза что-то медленно получается - не, никаких консолей, быстренько создаем новый шаблон, быстренько тестим его на виртуалочке, и быстренько деплоим". Как раз к этому времени либо и так все устаканится, либо, что вероятнее, гораздо раньше все ляжет.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

50. "Инцидент с СУБД проекта GitLab"	+7 +/–
Сообщение от www2 (ok) on 01-Фев-17, 18:47
Все злорадные такие. То ли себя безгрешными считают, то ли GitLab не любят. Я, в общем-то, тоже не люблю - такое тяжёлое для установки приложение, которое написано на Ruby, но почему-то тянет с собой Python, ещё поискать нужно. Но людям сочувствую. В жизни ситуации разные бывают - может быть у админа родственник болеет, вот он просидел всю ночь у кровати больного и приехал на работу не выспавшимся, например. Может быть шеф зудел - давай сделаем, быстрей придумай что-нибудь ("ты же админ") чтобы под DoS'ом жилось не так тяжко.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-17, 19:27
	Да ерунда же, просто ребята настолько легкомысленные, что 5 вариантов бекапа сделали и не протестировали. Главный по инфраструктуре не ввел в практику тестирование бекапов, но да, и мы все не без греха.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

59. "Инцидент с СУБД проекта GitLab"	+6 +/–
Сообщение от Гентушник (ok) on 01-Фев-17, 19:30
Я так понимаю DoS-атака в итоге оказалась успешной?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	98. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Фев-17, 18:42
	> Я так понимаю DoS-атака в итоге оказалась успешной? Да, в некотором смысле это новый(?) класс -- можно назвать SDoS, self denial of service... если бы был множественный -- тогда MSDoS, видимо.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	100. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Andrey Mitrofanov on 02-Фев-17, 19:09
	> Я так понимаю DoS-атака в итоге оказалась успешной? Атака второго порядка: целью и жертвой оказался тот, кто чинил тот первый "просто" DoS.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

62. "Инцидент с СУБД проекта GitLab"	–5 +/–
Сообщение от Аноним (??) on 01-Фев-17, 22:14
мда, такие вот нынче специалисты
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	76. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Andrey Mitrofanov on 02-Фев-17, 09:35
	> мда, такие вот нынче специалисты Люди такие всегда.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	112. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Junker on 05-Фев-17, 01:47
	минусуют видимо те, кто тоже на работе так лажает.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

69. "Инцидент с СУБД проекта GitLab"	–2 +/–
Сообщение от Михрютка (ok) on 02-Фев-17, 00:12
а што все возбудились-то так, как будто на деньги кто-то попал? хипсторская контора предоставляет хипсторский сервис хипсторам. она вообще может раз в две недели все пользовательские данные обнулять - хипсторы сами обратно приползут и нагрузят еще, и спасибо скажут. а как жэ иначэ, это жэ вэбдваноль, и инфраструктура как сэрвис. вы только не обращайте внимания на цифру 6 мегабайт в секунду на восстановлении, мы стараемся как можем, на сорок с лишним инвесторских лямов быстрее не получается. непрерывность бизноса? какого бизноса?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	72. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 03:08
	У гитлаба бизнес - в продаже gitlab ee, а gitlab.com - это так... демостенд, там и платных-то функций нет.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	110. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от пох on 03-Фев-17, 17:30
	> У гитлаба бизнес - в продаже gitlab ee, а gitlab.com - это > так... демостенд, там и платных-то функций нет. ну так вот инвестор на деньги и попал - он не с платных функций живет, а с цены акций, а они от таких подарков, собаки, падают.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

78. "Инцидент с СУБД проекта GitLab"	–1 +/–
Сообщение от QuAzI (ok) on 02-Фев-17, 10:26
На волне хайпа с гитлабом хотелось бы узнать, а чем и как в вашей организации организуются бекапы? А то что-то всё плохо с хорошим инструментом для бекапов, куда ни глянь - разваливающиеся на бегу костыльные велосипеды
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	83. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Андрейка (ok) on 02-Фев-17, 13:53
	Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемся Гарантия восстановления данных - 100% (да-да, это бывает), скорость восстановления == скорость записи на диск по сети, т.е. зависит от железки куда рестор делаешь Если по сути - бэкапим диск на блочном уровне (для того же postgresql этого достаточно), для всяких mysql/mssql есть плагины (работает как mysqlproxy, отслеживая изменение состояния снапшота во время бэкапа) Ну и главное не чем бэкапить, а какая policy. Если policy правильная, то все будет хорошо У нас полиси такая: - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных типа СУБД - раз в час - Успешный бэкап сжимается и реплицируется на другой континент раз в 4 часа - Реплика бэкапа раз в сутки сливается в облако S3, а оттуда в долговременное хранилище - Раз в сутки бэкап разворачивается на stage-сервер и по нему гоняются автоматические тесты, которые в том числе позволяют установить точность восстановления на 95% - DWH собирает для основной базы KPI отчеты и stage-сервер сравнивает развернутый бэкап создавая аналогичные отчеты час-в-час, кроме последнего (текущего) часа - его еще нет в бэкапе Все делается автоматически, на CICD сервере При миграции данных (программисты выпускают новую версию), перед деплоем делается обязательный бэкап НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным. Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами (code/change review) Ну и помимо всякого - все действия логируются, по каждому инциденту заводится тикет в джире и не закрывается, пока root cause не будет устранена, покрыта тестами и мониторингом и автоматизирована В общем - главное архитектура :-)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	89. "Инцидент с СУБД проекта GitLab"	+1 +/–
	Сообщение от Аноним (??) on 02-Фев-17, 17:44
	> Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемся вы заблуждаетесь...в смысле - надежных платных тоже не бывает. > Гарантия восстановления данных - 100% (да-да, это бывает) не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая, чем потери бизнеса. > Ну и главное не чем бэкапить, а какая policy. Если policy правильная, главное - что бэкапать. У вас очень мало данных и много лишних денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?). > У нас полиси такая: > - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных "отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется, я уже слегка спойлерю) > типа СУБД - раз в час у вас _очень_ мало данных. > НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным. > Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода > команды работают только через коммит CICD джобы и аппрув 2+ тиммейтами и когда коммитилка и аппрувилка навернулись - мы делаем - что? > Ну и помимо всякого - все действия логируются, по каждому инциденту заводится у вас не только очень мало данных, но и очень мало настоящей работы (ну да, потому что данных мало). Есть время тыцать мышью в неторопливый интерфейс жиры (на что обычно уходит куда больше времени, чем на саму работу). Поверьте, вы не гитлаб. > В общем - главное архитектура :-) главное - забиться в норку, где хорошо платят, вкусно кормят и можно развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага. А быть админом гитлаба, как видим, действительно плохо. гитхабу, думаю, не легче.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	113. "Инцидент с СУБД проекта GitLab"	–2 +/–
	Сообщение от Андрейка (ok) on 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% вы даже не на уровне админа гитлаба
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

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

	115. "Инцидент с СУБД проекта GitLab"	+/–
	Сообщение от Аноним (??) on 13-Фев-17, 10:40
	Андрейка, а иметь всю эту архитектуру, полиси, и т.д действительно дешевле чем раз в 6 лет потерять последние 6 часов данных и сутки простоя? Или у вас это не считали?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

111. "Инцидент с СУБД проекта GitLab"	+/–
Сообщение от ALex_hha (ok) on 04-Фев-17, 19:29
> Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от hostname/username. и как это помогает, когда у вас 50+ серверов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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