Разработчики платформы для организации совместной разработки 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
Хипстеры...DROP PgSQL бэкапы не нужны ага,,,
Доверяйте облакам, говорили они. Держите все свои важные данные в облаках.
Они отказоустойчивые и регулярно бекапятся, говорили они.
Ну вот и посмотрим.
> Доверяйте облакам, говорили они. Держите все свои важные данные в облаках.
> Они отказоустойчивые и регулярно бекапятся, говорили они.
> Ну вот и посмотрим.просто ещё не реализовали облаков для облаков.
Вот тогда-то заживём!
> просто ещё не реализовали облаков для облаков.реализовали - они ж написали, "мы регулярно бэкпались в azure".
> Вот тогда-то заживём!
Но что-то пошло не так...
нашли в чём бэкапится
Ну так раз в 6 часов - это разве не регулярно? Если хочешь чаще - то бесплатного гектара на Дальнем Востоке тебе ненадолго хватит, чтобы складывать физические носители.
Да это просто жесть! Как-так! это все школьники организовали и забыли про бекапы?
они не забыли:
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 затраханный в рот и в зад админ ошибается окошком.
Кстати, кто виноват, совершенно точно известно, его и уволить.
> костыликов (отсюда и пять кривых бэкапов вместо одного работающего), то в
> 23:00 затраханный в рот и в зад админ ошибается окошком.кстати, это был хороший админ, поскольку догадался сделать _нештатный_ бэкап до начала работы, не надеясь на автоматику (или хорошо зная, что она нерабочая).
> Кстати, кто виноват, совершенно точно известно, его и уволить.вот его и уволят, будьте уверены.
кого уволить? кто нанял недостаточно админов?
> кого уволить? кто нанял недостаточно админов?как это его уволить? Это ж человек, тяжким трудом сэкономивший фирме N*(admin_salary) денег! А вот тот, который окошком ошибся - нанес ущерба на 10*N (плюс 1000*N упущенная прибыль)!
Не, ну может, конечно, на первый раз пожурят и заставят отрабатывать два дежурства за раз - он вон уже написал как он героично принимает меры для исключения повторения проблемы в будущем (не работать после 18 и спать вовремя в списке, заметим, отсутствуют).
> они не забыли:Да де-лы не знающие, что "бэкапы которые успешно не развернули хоть раз - не бэкапы" должны страдать!
Все очень сильно зависит от размера этого самого бекапа. Знаю одну контору у которой дамп БД делается в течении ~30 часов и следом начинается следующий дамп. Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачивать ибо это бессмысленно, и они нужны только на совсем крайний случай когда умерли все реплики и реплики отстающие на 6, 12 и 24 часа от мастера. И да, вариант что из дампа ничего не развернётся совершенно не нулевой.
А развернуть тестовую базу раз в полгода никому в голову не приходило?
> А развернуть тестовую базу раз в полгода никому в голову не приходило?Уверенность в одном из 146 (*) бэкапов это Важно.
(*)Никакой связи с Чуровым, совпадение: 365.24/2*24/30 = 146.096.
> Хочеш предложить им вариант как проверять эти бекапы методом "развернуть хотя бы раз"? Естественно никто даже не пробовал их разворачиватьПредлагаю вариант: развернуть хотя бы раз.
бывает, что не на чем.
например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300 и оракловая база, которая бэкапится отдельно.
да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще одной такой системы нет.
в /dev/null?
> бывает, что не на чем.
> например: кластер из 11 хостов c vmware (~60VM), тома на массиве vnx5300
> и оракловая база, которая бэкапится отдельно.
> да, бэкапы регулярно делаются, но развернуть их для теста просто некуда: еще
> одной такой системы нет.а потом "ORA 0600"(или как там правильно, давно не видал) и мы идем искать новую работу? ;-)
[нет, я понимаю, что там кластер, массив с избыточностью, кроссчек и все такое, но оракл такой изобретательный ;-) ]все ж таки 60vm это еще не фатально, можно биться с начальством за тестовую ферму.
Ну лучше чем в 0.
Что за детский сад? Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть неделю. Главное автоматически.
> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант для разработчиковВсе "отдельные сервера" заняли вэб-макаки под свои "докеры с нодами".
> Отдельный сервер, которые стягивает свежайший бэкап, разворачивает его, делает вариант
> для разработчиков (обрезаный, опционально). Какая разница сколько это занимает, хоть
> неделю.разница существенная - во втором случае, ты заметишь проблему только через неделю (или не заметишь вовсе, потому что развернуть-то оно развернуло, а внутри лажа). Соответственно, будь тамошний админ таки же как ты - и не постели соломку лично - им бы пришлось откатиться на бэкап недельной, а не шестичасовой, тухлости. Или двухнедельной. Или вообще никакого.
А цена этого "отдельного сервера", который, частенько, не отдельный сервер вовсе, а отдельный кластер на пяток стоек - очень и очень немаленькая. А инвестор жадный.
Ну и учти, что если бэкап восстанавливать неделю - то ты потеряешь половину пользователей.
То есть в какой-то момент становится понятным, что ну...вообще-то...ну хорошо бы в принципе иметь бэкап хотя бы вот для запуска тестового инстанса при мега-апгрейде инфраструктуры, но пользы от него не так много, как хотелось бы.> Главное автоматически.
наоборот - главное, хоть иногда человеческим глазом смотреть. Иначе, как и в этом случае, может оказатьтся, что гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор.
А для этого опять же надо чтобы у админов на это было время и вдохновение. А не 23:00, а таск все еще не закрыт.
>>Какая разница сколько это занимает, хоть неделю.
>тухлости. Или двухнедельной. Или вообще никакого.
> очень немаленькая. А инвестор жадный.
>восстанавливать неделю - то ты потеряешь половину пользователей.
>> Главное автоматически.
>гуглобайты данных качаются туда-сюда совершенно впустую, в них мусор."Нет пути."ТМ
> А для этого опять же надо чтобы у админов на это было
> время и вдохновение. А не 23:00, а таск все еще не
> закрыт."Усё пропалоушеф."Ц
+++Люто плюсую, пиши ещё - завтра пятница.
> Естественно никто даже не пробовал их разворачивать ибо это бессмысленноНужно хотя бы раз развернуть бекап, чтобы проверить, что там есть все, что нужно.
Для примера - у mysql есть хранимые процедуры и функции (stored routines (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. А если не указать, не сохраняет. Если они активно использовались, но дамп делался без них...
Есть шанс узнать что-то новое для себя в самый неподходящий для этого момент.
Дело в том, что если про эту опцию не знать, можно потратить много времени на поиск причины. С виду то как - дамп вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время на вытаскивание этих хранимок из кода или девелоперской среды.
> Для примера - у mysql есть хранимые процедуры и функции (stored routines
> (procedures and functions)). Утилита mysqldump их сохраняет, если указать -R. Аух ты, давно я не брал в руки шашек. В смысле, что они, оказывается, для этого ключик сделали (правда, судя по ману - кривой, портит даты, не от того юзера заводит).
вообще-то сохраняет, но если mysqldump --all ;-) Приятные последствия при мерже на другой кластер - побочный эффект ;-)А их использование по прежнему разваливает репликацию, или это я тоже уже от жизни на пять лет отстал?
> вернули, а ошибки сыпятся. А потом ещё придется потратить некоторое время
> на вытаскивание этих хранимок из кода или девелоперской среды.а они там - опа, не той версии и "той" вообще нигде нет ;-)
P.S. чего только не узнаешь странного, тролля на опеннете
> Естественно никто даже не пробовал их разворачиватьПопадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл. Т.е. с виду всё хорошо. И только когда возникла необходимость его распаковать чел понял, что исходный каталог он уже не получит.
> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файлХм. Что-то тут не так в этом комментарии.
gzip на каталог, если с флагом -r, даст вам на выходе каталог с .gz-шниками. А без флага -r вообще откажется работать.
Какой же там файл получился на выходе? К тому же через прогнозируемое время. И в довесок прогнозируемого объёма.
>> Попадался мне на LORе один чел, который запаковал каталог gzip'ом без tar'а. Утилита отработала прогнозируемое время, на выходе получился прогнозируемого объёма файл
> Хм. Что-то тут не так в этом комментарии.
> gzip на каталог, если с флагом -r, даст вам на выходе каталог
> с .gz-шниками. А без флага -r вообще откажется работать.
> Какой же там файл получился на выходе? К тому же через прогнозируемое
> время. И в довесок прогнозируемого объёма.С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout. Но челу нужен был файлик и он перенаправил stdout в файлик: https://www.linux.org.ru/forum/general/11356750 Речь не о том, что даже стандартными утилитами в неумелых руках можно выстрелить себе в коленку, а о том, что его при этом ничего не смутило -- файл то большой, значит все данные в нём есть, значит проверять ничего не нужно.
> С ключом -cr гзип рекурсивно всё сжал и вывалил в stdout.Понял. Весьма удивлён изобретательности человека. Так отстрелить себе ногу -- это ещё додуматься надо. :)
Чувак на самом деле не сильно виноват, а виноват тот кто не настроил процесс тестирования бекапов.
> Чувак на самом деле не сильно виноват, а виноват тот кто не
> настроил процесс тестирования бекапов.а это тот чувак и был (в числе прочих). Но никакого дополнительного времени на это у него никогда не было, а ddos - вот он, уже пришел, и кластер (который в штатном режиме сам себе бэкап) развалился. Подождите с вашим ддосом недельку, я тут хоть бэкапы настрою и протестирую, можно?
ребята, вы явно не работали никогда в подобных конторах. У вас очень спокойная жизнь.
Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1.
p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не в той команду вводим :)
> Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1.
> p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не
> в той команду вводим :)Раскраска подсказок, пауза перед нажатием энтера (вплоть до посидеть на руках, подумать) -- ну и не работать в уставшем виде... нажито непосильным трудом по разгребанию последствий такого в своих собственных масштабах.
> Раскраска подсказокДавно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от hostname/username. (Только никто не спрашивайте как, этот костыль из cut/od/sed/expr показывать стыдно, наверняка можно сделать лучше и проще).
Ручками задавать цвета лениво и на это бы быстро забил, а так оно шамо.
Да ладно, покажи, чоуж.
> Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от
> hostname/username. (Только никто не спрашивайте как, этот костыль из cut/od/sed/expr
> показывать стыдно, наверняка можно сделать лучше и проще).А покажите, действительно.
Не работать уставшим, посидеть подумать, угу. Особенно когда стоят над душой и нудят:- Вот вы здесь сидите, а там все стоит.
- Что стоит ?
- Все стоит
> Не работать уставшим, посидеть подумать, угу.
> Особенно когда стоят над душой и нудят:
> - Вот вы здесь сидите, а там все стоит.
> - Что стоит ?
> - Все стоит"если я нечаянно доломаю -- ты правда починишь? нет? тогда не мешай делать, что ещё могу"
Особо упорным можно напомнить, что ясновельможный пан Качиньский с первого раза (когда КВС его не послушал и сделал как надо над Грузией) не допёр, в итоге ладно бы сам угробился под Смоленском, так ещё других угробил и дров наломал. И спросить, сядут ли за руль автобуса, засыпая.
Можно ещё предложить поумножать или хотя бы поскладывать многозначные числа в уме, при этом подёргивая другими вопросами -- чтоб хоть немножко дошло, почём прерывания.
> Не работать уставшим, посидеть подумать, угу. Особенно когда стоят над душой и нудят:я тебе страшный девопский тайна открою (ее даже Шигорин не знает, потому что альтовские сервера нафиг никому не уперлись): когда у тебя высоконагруженный проект, да еще пусть под слабой даже атакой и в нем половина мощности внезапно ложится - у тебя "над душой" стоит даже не эффективный менеджер (его уже самого к тому моменту в интересных позах имеет инвестор) а система мониторинга, заходящаяся воем, что сейчас вообще ВСЕ пойдет по женскому органу.
То есть тупит база- начинают тормозить прокси - начинают тупить фронты - юзвери злобно жмакают релоад, увеличивая и без того большую нагрузку - и, скорее рано чем поздно, ты получаешь на ВСЕХ хостах LA500 - и сделать с этим уже ничего нельзя, отключай нахрен входящий канал и перезагружай хосты ресетом, это ж линукс, оно уже не очухается. Это все здорово напоминает управление чернобыльским реактором - за пять минут до взрыва.
Ничем, кроме найма большего числа админов, чтобы не лечить неизлечимо больного, а планомерно убирать узкие места, те же бэкапы проверять и переделывать в порядке текущей работы, покупки больше серверов, чтобы было что вводить в качестве резервов (почему, собственно, реплик только две, при том что одна не держит?), в общем - денег, денег и еще раз денег, сравнимо с тем что уже вгрохано в этот сервис, а не еще 5%, это не лечится.
А денег в маргинальных проектах мало и их жмут, особенно когда оно уже как-то завелось и вроде бы работает - "какие ЕЩЕ бэкапы, мы вам azure оплатили, пользуйтесь!". Проще назначить крайних, потерять пол-дня данных и день на восстановление, ну и процентов десять юзербазы, на первый разок.
> я тебе страшный девопский тайна открою (ее даже Шигорин не знает,
> потому что альтовские сервера нафиг никому не уперлись)...то-то у нас zabbix допиливали ;-)
> Это уже было несколько лет назад с каким-то крупным проектом, сценарий 1в1.
> p.s. Открыты 2 консоли локальная и удалённая, и тут жмах и не
> в той команду вводим :)Это еще хорошо, если только 2!.. :)
А если их 42 на 3-х мониторах и там еще закладок немеряно?!.. а среди них куча screen'ов и кластерных терминальных сессий (1-to-many).
И если к тому же миграция ночью после многих часов работы, то можно запросто ошибиться. И хорошо, что все же был нормальный архив... а админам сочувствую и понимаю...
> забыли про бекапы?Когда в голове дэдлайны, а над головой ПиЭмы, про бэкапы не думают.
Не было, и вот опять.
Надежность выбора технологий уровня GitLab,GiHub профинансировал ZFS OnLinux и использует его на Bare Metal серверах в это время под git-хранилища.
ZFS головного мозга дeтектед.
> Надежность выбора технологий уровня GitLab,уровня линyпс.
(тут и постгрез, с его невменяемой неработающей без ручного пинания репликацией, и снапшоты насквозь гнилого lvm, выполняющиеся полтора дня, так что очень не хочется их делать лишний раз, и сам lvm - а потом они удивляются, чавойта постгрез так тормозит, ага)
Напомню, что гугль (когда последний раз делился этой информацией, а это было давно) как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала. Не пытайтесь проделать это дома.> GiHub профинансировал ZFS OnLinux и использует его на Bare Metal серверах в
ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе нессыкотно этим пользоваться. Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная, но, возможно, у гитхаба есть возможность шевелить толстым бревном в дупе разработчиков всякий раз, как там что-то ломают.
У гитлаба, очевидно, такой возможности нет - они выбрали те инструменты, какие могли.
> постгрез, с его невменяемой неработающей без ручного пинания репликациейПоднял один раз, ни разу не пинал, все работает. ЧЯДНТ?
один разДаже фраза есть такая: "один раз не ***".
да я и много раз поднимал, всё чудесно работает.для тех кто руками не умеет даже pgbarman придумали
> уровня линyпс.
> постгрезНу да, был бы оракл, или mssql, то этого бы никогда не случилось. Гарантирую.
> Напомню, что гугль (когда последний раз делился этой информацией, а это было давно) как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала. Не пытайтесь проделать это дома.
Без журнала, ибо люстры.
Ты сам себе и объяснил, только немножко не то. У экстентных ФС одна облать применения, а у снапшотных - другая.
> ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе нессыкотно этим пользоваться.
О, так он оказывается платный? Или стаёт стабильнее только у финансирующих?
> Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная,
Дооо, чтение там забанили. Но не волнуйся, тебе не придбется там держать вообще ничего
> ибо очень уж эта поделка странная
А для кого-то - привычная. Твоя некомпетентность не является показателем.
> шевелить толстым бревном
А что ты делаешь на опеннете?
>> уровня линyпс.
>> постгрез
> Ну да, был бы оракл, или mssql, то этого бы никогда не_этого_ - ручного стирания каталогов под репликацию - да, никогда не случилось бы.
Другие грабли возможны, но не такие тупые.>> Напомню, что гугль (когда последний раз делился этой информацией, а это было давно)
>> как раз мигрировал свои люстры с ext2 (!) на ext4-без-журнала.
> Без журнала, ибо люстры.ибо тормоз. А люстры - просто удобный способ обойти проблему почти бесплатно (надо думать, в случае чего ее просто автоматически пересетапят на соседнюю картонку).
Но ext2 - это ж не просто без журнала, там еще вагон и маленькая тележка проблем. А прообнимались они с ней ПЯТЬ лет после того как все на нее забили, и ext4 была уже давным-давно объявлена совершенно стабильной и работающей. Делать им нечего, думаешь? ;-)>> ну, возможно, если ты имеешь дохрена денег и финансируешь zfs onlinux - тебе
>> нессыкотно этим пользоваться.
> О, так он оказывается платный? Или стаёт стабильнее только у финансирующих?естественно второе - "держи кнут, он твой!" То есть именно проблемы финансирующих и будут решать в первую (а так же вторую и третью) очередь. А не ответят что это "нетиповая конфигурация", "особенность линукс-сборки, см правильную в нашем иллюмосе", "у нас не воспроизводится" и т д. А пользующие "бесплатно" могут лично сидеть над дампами, тоже бесплатно, и сутками.
>> Я бы там ничего кроме writeonly-данных не держал, ибо очень уж эта поделка странная,
> Дооо, чтение там забанили. Но не волнуйся, тебе не придбется там держатьчтение, может, внезапно, не прочитать, ага. Причем ты об этом узнаешь, когда уже будет поздно. Или начать читать так, что лучше б сразу не прочитало (высоконагруженный проект, да) - кстати, совсем недавно в этом месте выскочили здоровенные грабли, судя по патчам - не специфичные для платформы.
>> ибо очень уж эта поделка странная
> А для кого-то - привычная. Твоя некомпетентность не является показателем."привыкнуть" и не замечать странностей - это и есть некомпетентность (совсем другое - понимать, чего ради, что возможно вместо, и чем грозит). А уж в этом случае, когда речь о целой отдельной науке, тамагоченьи zfs (и ее отдельном разделе, тамагоченьи zfs не на bsd-основе) - устрашающая. Ты, надеюсь, не сотрудник гитхаба? У меня там есть ценные игрушки, не хотелось бы их потерять. Вставший раком _без_ очевидных внешних причин zfs-пул обычных, не гитхабовых, размеров - нифига не является редкостью необычайной. И далеко не всегда легко и просто удается это починить, и тем более - понять, что вызвало проблему. Упомянутая история с неправильным размещением блоков - исключение, там нашли. Но пока разработчики что-то ищут, ты сидишь, глядя на индикаторы io/la ползущие к краю красной зоны, и совершенно ничего не можешь сделать.
>> шевелить толстым бревном
> А что ты делаешь на опеннете?издеваюсь над некомпетентными самоуверенными админами локалхоста, что ж еще
> Реагируя на обрушившуюся на проект DoS-атаку администраторы попытались разнести нагрузку на СУБД PostgreSQL на два сервера, организовав репликацию данныхТо есть, раньше реплики БД у них не было. Хипстота...
Была, но из-за атаки вторая БД начала лагать и репликация отвалилась.В попытке поднятия репликации на второй БД было решено очистить каталог постгреса, но случайно промахнулись окном.
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCx...
Это выглядит как желание прибить муху которая сидит на кнопке запуска ядерных ракет.
> Это выглядит как желание прибить муху которая сидит на кнопке запуска ядерных
> ракет.Удаление содержимого директории data на сервере куда будет производиться репликация - необходимый шаг.
Алгоритм настройки репликации примерно такой: удаляем data на slave, ставим checkpoint на master, переносим целеком содержимое директории data с master на slave, запускаем slave, убираем checkpoint.
PS. Много раз случалось не в той консоли что-то запускать.
>Удаление содержимого директории data на сервере куда будет производиться репликация - необходимый шаг.mv data old-data
mkdir data
> mv data old-data
> mkdir dataнадо б на досуге посмотреть результат этого действа на живом постгрезе - полагаю, будет весьма феерично, хотя до бэкапа может дело и не дойдет.
Ну и если поторопиться сделать после этого rm -r old-data - можно остаться ровно у того же разбитого корыта (а если не поторопиться - места на две копии не хватит, скорее всего)
https://www.youtube.com/watch?v=nc0hPGerSd4 Live Stream восстановления.
а может ради этого всё и задумывалось?
Куда донаты кидать?
Прикольно. Одного из них Ёрик зовут)) "Бедный Ёрик"(С)
Еще и спец по СУБД. Точно бедный.))
Нормальное дело.Можно подумать, никто из вас "reboot" не в том окошке мультиплексора терминалов не запускал...
Набрать ребут не в том окне - нормально. Не нормально иметь единственный сервер, ребут или полный выход которого из строя (в данном случае путем удаления файлов БД) приведет к отказу в обслуживании.
Первый раз - невнимательность. Регулярно - СДВ (СДВГ). Лечится.Симптомы СДВ:
1. неспособен удерживать внимание на деталях: из-за небрежности, легкомыслия допускает ошибки
2. с трудом сохраняет внимание при выполнении заданий
3. часто складывается впечатление, что больной не слушает обращённую к нему речь и поступает по своему
4. оказывается не в состоянии придерживаться предлагаемых инструкций и справиться до конца с выполнением заданий
5. испытывает сложности при самостоятельном выполнении заданий
6. избегает заданий, которые требуют длительного сохранения умственного напряжения 7. часто теряет необходимые вещи и файлы
8. легко отвлекается на посторонние стимулы (напр. форумы)
9. проявляет забывчивость
10. ломает всё подряд (в то же время делает вид, что не он это делал)Знакомо?
В России СДВ не считается заболеванием и больные им д---илы продолжают портить другим людям жизнь.
> Знакомо?
> В России СДВ не считается заболеванием и больные им д---илы продолжают портить
> другим людям жизнь.Зато в мериканнии детишек с этим "заболеванием" лечат [медицинским] кокаином. Человецищи! >/<
Признавайся, где ты спер мою биографию?
> Признавайся, где ты спер мою биографию?тыщи вас!
> Можно подумать, никто из вас "reboot" не в том окошке мультиплексора терминалов
> не запускал...clear config гораздо интереснее. И бесплатного резерва в 50% мощности обычно нет ;-)
А-ха-ха ... до боли знакомая ситуация. Сам так делал не раз.
http://checkyourbackups.work/
http://www.worldbackupday.com/ru/
Только зануды делают резервные копии: настоящие мужчины просто закачивают все важное на ftp, позволяя остальным отзеркалировать это.Линус Торвальдс
http://russianfedora.pro/posts/kernelorg-otkazyvaetsia-ot-ft.../
> http://russianfedora.pro/posts/kernelorg-otkazyvaetsia-ot-ft.../
>> на ftpна != по ;-)
>просто закачивают все важное на
> ftp,Просто. На. В. Git. Же.
> Линус Торвальдс
#гитлабживи
у них все на Azurenuff said
Вот, что бывает с ручным devops. NixOS - наше всё!
И что, там возможно настроить репликацию в PostgreSQL одной опцией? А если в этих ваших nix-файлах писатель ошибку допустил? Автоматика, товарищ, не отменяет головы. Автоматика даже гораздо опаснее рук, потому что с автоматикой можно сделать больше и быстрее. Читай - наломать дров больше и быстрее. Руками ты один сервер уронишь, а автоматикой - целый кластер.
Можно. Фишка с Nixos в воспроизводимости: проверил в vbox, задеплоил.https://github.com/zalora/nixsap/blob/092d712689eec989003ec2...
в любой системе управления конфигурациями так можно. да даже и с шелл-скриптами. man vagrant
> И что, там возможно настроить репликацию в PostgreSQL одной опцией? А если
> в этих ваших nix-файлах писатель ошибку допустил? Автоматика, товарищ, не отменяет
> головы. Автоматика даже гораздо опаснее рук, потому что с автоматикой можно
> сделать больше и быстрее. Читай - наломать дров больше и быстрее.
> Руками ты один сервер уронишь, а автоматикой - целый кластер.Все можно сделать "одной опцией", даже с puppet или скриптом bash. Только nix/nixos позволяют это делать безболезненно и естественно.
И безотносительно nixos, надо правильно мыслить. Не репликацию постгрес, а сервер с репликой. Даже с Puppet должен быть соответствующий шаблон. Нужна ещё одна реплика? Ок, вот новая нода класса postgres-repl. А не как эти Африки.
> И безотносительно nixos, надо правильно мыслить. Не репликацию постгрес, а сервер с
> репликой. Даже с Puppet должен быть соответствующий шаблон. Нужна ещё одна
> реплика? Ок, вот новая нода класса postgres-repl.и в датацентре сами собой воздвигаются новые стойки, из воздуха в них запрыгивают полки с дисками и головы с lvm'ами... эх, программисты... когда ж до вас дойдет, что у девопсов немного другой мир, совсем не такой как в вашей тестовой виртуалочке?
Ну и вот образовался у тебя "cервер с репликой", а реплики-то в нем и нет. Данные еще перелить надо, не перегрузив сеть, дисковый io уцелевшей полки и постгрезовую голову. А нагрузка растет, а часики тикают... А ты такой - "опа, заметил что надо руками стирать data, у самого постгреза что-то медленно получается - не, никаких консолей, быстренько создаем новый шаблон, быстренько тестим его на виртуалочке, и быстренько деплоим". Как раз к этому времени либо и так все устаканится, либо, что вероятнее, гораздо раньше все ляжет.
Все злорадные такие. То ли себя безгрешными считают, то ли GitLab не любят. Я, в общем-то, тоже не люблю - такое тяжёлое для установки приложение, которое написано на Ruby, но почему-то тянет с собой Python, ещё поискать нужно. Но людям сочувствую. В жизни ситуации разные бывают - может быть у админа родственник болеет, вот он просидел всю ночь у кровати больного и приехал на работу не выспавшимся, например. Может быть шеф зудел - давай сделаем, быстрей придумай что-нибудь ("ты же админ") чтобы под DoS'ом жилось не так тяжко.
Да ерунда же, просто ребята настолько легкомысленные, что 5 вариантов бекапа сделали и не протестировали. Главный по инфраструктуре не ввел в практику тестирование бекапов, но да, и мы все не без греха.
Я так понимаю DoS-атака в итоге оказалась успешной?
> Я так понимаю DoS-атака в итоге оказалась успешной?Да, в некотором смысле это новый(?) класс -- можно назвать SDoS, self denial of service... если бы был множественный -- тогда MSDoS, видимо.
> Я так понимаю DoS-атака в итоге оказалась успешной?Атака второго порядка: целью и жертвой оказался тот, кто чинил тот первый "просто" DoS.
мда, такие вот нынче специалисты
> мда, такие вот нынче специалистыЛюди такие всегда.
минусуют видимо те, кто тоже на работе так лажает.
а што все возбудились-то так, как будто на деньги кто-то попал?хипсторская контора предоставляет хипсторский сервис хипсторам. она вообще может раз в две недели все пользовательские данные обнулять - хипсторы сами обратно приползут и нагрузят еще, и спасибо скажут.
а как жэ иначэ, это жэ вэбдваноль, и инфраструктура как сэрвис. вы только не обращайте внимания на цифру 6 мегабайт в секунду на восстановлении, мы стараемся как можем, на сорок с лишним инвесторских лямов быстрее не получается. непрерывность бизноса? какого бизноса?
У гитлаба бизнес - в продаже gitlab ee, а gitlab.com - это так... демостенд, там и платных-то функций нет.
> У гитлаба бизнес - в продаже gitlab ee, а gitlab.com - это
> так... демостенд, там и платных-то функций нет.ну так вот инвестор на деньги и попал - он не с платных функций живет, а с цены акций, а они от таких подарков, собаки, падают.
На волне хайпа с гитлабом хотелось бы узнать, а чем и как в вашей организации организуются бекапы? А то что-то всё плохо с хорошим инструментом для бекапов, куда ни глянь - разваливающиеся на бегу костыльные велосипеды
Бесплатных не бывает. Есть платный (относительно дешевый) 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 не будет устранена, покрыта тестами и мониторингом и автоматизирована
В общем - главное архитектура :-)
> Бесплатных не бывает. Есть платный (относительно дешевый) enterprise, которым пользуемсявы заблуждаетесь...в смысле - надежных платных тоже не бывает.
> Гарантия восстановления данных - 100% (да-да, это бывает)не бывает. Бывает гарантия выплаты $nnn если "нишмагла". Обычно, увы, куда меньшая, чем потери бизнеса.
> Ну и главное не чем бэкапить, а какая policy. Если policy правильная,
главное - что бэкапать. У вас очень мало данных и много лишних денег, отсюда и наивная вера в полиси (мелкий банчок, чтoле?).
> У нас полиси такая:
> - Бэкап на отдельный сервер, инкрементально, поблочно каждую ФС. Для критичных данных"отдельный сервер" должен вмещать в себя полку в 30-50 терабайт (не так много на сегодняшний день, все любят всякую бигдату). Инкрементально, ага. Ваши действия? (нет, денег на отдельный бэкапный FC-свитч не дадут... уп-с, кажется, я уже слегка спойлерю)
> типа СУБД - раз в час
у вас _очень_ мало данных.
> НИКТО - это важно, даже СамыйГлавныйАдмин не имеет ручного доступа к данным.
> Т.е. rm -rf /var/lib/postgresql просто не выполнится в консоли. Такого рода
> команды работают только через коммит CICD джобы и аппрув 2+ тиммейтамии когда коммитилка и аппрувилка навернулись - мы делаем - что?
> Ну и помимо всякого - все действия логируются, по каждому инциденту заводится
у вас не только очень мало данных, но и очень мало настоящей работы (ну да, потому что данных мало).
Есть время тыцать мышью в неторопливый интерфейс жиры (на что обычно уходит куда больше времени, чем на саму работу).
Поверьте, вы не гитлаб.> В общем - главное архитектура :-)
главное - забиться в норку, где хорошо платят, вкусно кормят и можно развлекаться KPI и прочей ерундой, считая себя великим архитектором, ага.
А быть админом гитлаба, как видим, действительно плохо.гитхабу, думаю, не легче.
> вы заблуждаетесь...в смысле - надежных платных тоже не бывает.
> не бывает. Бывает гарантия выплаты $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% вы даже не на уровне админа гитлаба
Гонору у вас конечно много, с этим не поспоришь, но ~где пруфы~ дайте ссылку что почитать конкретнее же?
Андрейка, а иметь всю эту архитектуру, полиси, и т.д
действительно дешевле чем раз в 6 лет потерять последние 6 часов данных
и сутки простоя?Или у вас это не считали?
> Давно засунул себе в bashrc автораскраску PS1 в зависимости от md5sum от hostname/username.и как это помогает, когда у вас 50+ серверов?