Comments 129
один из админов GitLab.comYP (https://yorickpeterse.com) — software developer. Собственно это к вопросу о DevOPS, мне кажется что Системный Администратор с опытом такой ошибки не допустил бы.
Обычный человеческий фактор: усталость, чуточка спешки. Задача на которой не сработали типовые и рутинные решения что раздражает. Итого стечение кучи обстоятельств, «Секунда невнимательности» и оп.
UFO just landed and posted this here
Я бы ещё добавил аккуратность.
Пилоты самолетов, налетавшие десятки тысяч часов — и те совершают ошибки которые могут стоить жизни не только им самим но еще десяткам и сотням людей.
Человеческий фактор — это феномен безразличный к выслуге лет и квалификации. Конечно, у хорошего специалиста шансов выстрелить себе в ногу меньше, но утверждать что дело только в этом также совсем не верно.
А проблема гитлаба не только в одной консольной команде одного человека. Тут ситуация глубже значительно, потому что система бэкапов у них точно также не работала штатно и сомневаюсь что господин Петерс единолично все везде настраивал.
В этой ситуации мы с товарищами склонны видеть очень ценный жизненный урок и точку после которой в любом случае Gitlab значительно пересмотрит подход к работе с данными и вероятность повторения подобной ситуации должна уменьшиться в разы. Однако в любом случае какого крутого админа не возьми, человеческий фактор исключить полностью невозможно.
Человеческий фактор — это феномен безразличный к выслуге лет и квалификации. Конечно, у хорошего специалиста шансов выстрелить себе в ногу меньше, но утверждать что дело только в этом также совсем не верно.
А проблема гитлаба не только в одной консольной команде одного человека. Тут ситуация глубже значительно, потому что система бэкапов у них точно также не работала штатно и сомневаюсь что господин Петерс единолично все везде настраивал.
В этой ситуации мы с товарищами склонны видеть очень ценный жизненный урок и точку после которой в любом случае Gitlab значительно пересмотрит подход к работе с данными и вероятность повторения подобной ситуации должна уменьшиться в разы. Однако в любом случае какого крутого админа не возьми, человеческий фактор исключить полностью невозможно.
Там автоматика в самолетах. И даже, если она отключается, назойливый голов об этом говорит.
Ну так катастрофы обычно случаются на стыке действий человека и автоматики, или на неправильном ее использовании, да еще и при сочетании множества факторов (сложные условия полета, ошибка человека, неочевидная работа автоматики в ситуации которую создатели не предусмотрели и т.п.). Каждый пункт по отдельности вроде бы не страшен и каждое отдельное действие системы может быть логичным и ожидаемым, но в сумме все приводит к катастрофе.
Например как с Ту-204 во Внукове: слишком плавно приземлились с большим перелетом -> не обжались до конца стойки шасси -> автоматика посчитала что самолет еще летит и не дала включить реверс -> пилоты вовремя не прочухали в чем дело и дали полный газ (думая что включают реверс) -> самолет разогнался вместо того чтобы тормозиться -> выкатились с полосы.
Каждое отдельное действие бортовой системы управления правильное — нельзя давать включать реверс пока самолет еще летит (хотя вроде в советское время так делали для быстрого сброса скорости, но сейчас это запрещено), если дают полный газ на полосе — надо разгоняться и взлетать (возможно это уход на второй круг). Но в целом — катастрофа практически на ровном месте. Чтобы этого не допускать и нужны люди, но они бывает ошибаются и не справляются.
Например как с Ту-204 во Внукове: слишком плавно приземлились с большим перелетом -> не обжались до конца стойки шасси -> автоматика посчитала что самолет еще летит и не дала включить реверс -> пилоты вовремя не прочухали в чем дело и дали полный газ (думая что включают реверс) -> самолет разогнался вместо того чтобы тормозиться -> выкатились с полосы.
Каждое отдельное действие бортовой системы управления правильное — нельзя давать включать реверс пока самолет еще летит (хотя вроде в советское время так делали для быстрого сброса скорости, но сейчас это запрещено), если дают полный газ на полосе — надо разгоняться и взлетать (возможно это уход на второй круг). Но в целом — катастрофа практически на ровном месте. Чтобы этого не допускать и нужны люди, но они бывает ошибаются и не справляются.
В большинстве случаев не голос, а звук, который ещё надо распознать.
подавляющее большинство авиакатастроф происходит при взлете и посадке, где никакая «автоматика» не работает, это чисто ручной этап полета.
плюс стоит отметить, что до сих пор эксплуатируются самолеты, которые лишены этой автоматики (ту-154, ан-24 и пр.)
плюс стоит отметить, что до сих пор эксплуатируются самолеты, которые лишены этой автоматики (ту-154, ан-24 и пр.)
DevOps это хорошо, но получается, что на разработчиков начинает сваливаться все — и поддержка и доставка приложения и куча задач, которые раньше лежали на плечах сисадминов
вспоминаю формулировку вакансии на должность системного администратора на странице Павла Дурова несколько лет назад, где одно из качеств было: высокая стрессоустойчивость.
Почему вы обсуждаете админа?
Давайте попробуем предположить что бы было, если бы были бекапы всех пяти уровней?
Бинго! Ничего! Потеря данных за время меньше часа и все. Никто бы ничего не узнал — обычное дело, как отключение питания или сбой оборудования и прочее. Пожурили админа, сделали выводы.
Если вся команда налажала настолько, что не работает ни один из 5 бекапов — пытаться все свалить на одного человека — типичное российское поведение хренового управления. Нормальный управленец понимает, что проблема в организации резервирования, а не в хреновом админе просто потому, что при таком отношении к бэкапам такая ситуация возникла бы неминуемо рано или поздно, ибо человеский фактор не искоренить.
Давайте попробуем предположить что бы было, если бы были бекапы всех пяти уровней?
Бинго! Ничего! Потеря данных за время меньше часа и все. Никто бы ничего не узнал — обычное дело, как отключение питания или сбой оборудования и прочее. Пожурили админа, сделали выводы.
Если вся команда налажала настолько, что не работает ни один из 5 бекапов — пытаться все свалить на одного человека — типичное российское поведение хренового управления. Нормальный управленец понимает, что проблема в организации резервирования, а не в хреновом админе просто потому, что при таком отношении к бэкапам такая ситуация возникла бы неминуемо рано или поздно, ибо человеский фактор не искоренить.
Мое мнение что админ не сделал бы rm. Админ бы переименовал каталог. Просто на всякий случай. Из за той самой паранойи.
UFO just landed and posted this here
переименовывают удаленную папку
А удаленную мамку или бабку?
В серверных системах есть директории(directory), а мамки с папками остались в запускалке игр.
В серверных системах есть директории(directory), а мамки с папками остались в запускалке игр.
Ой, не любишь ты ностальгию, так нельзя
UFO just landed and posted this here
Забавно, что из английского оно заимствовано во второй раз с новым смыслом; в первый раз, как структура власти — латинизм (в начале 20 века).
Чем заимствование из греческого лучше чем заимствование из английского? Просто более ранней датой? :)
Вот когда будете создавать православную и домотканную ПравОС для православных досчатых компьютеров на единичной логике, тогда можете хоть каталогами называть, хоть поповским домиком. А пока есть директории и ничего с этим не поделаешь.
Разработчик с рутовым доступом к боевому серверу, который по ночам чинит репликацию постгреса — действительно странно…
Может быть, это не DevOps, а просто раздолбайство?
Может быть, это не DevOps, а просто раздолбайство?
от @Бобук
На волне всеобщего увлечения devops'изацией, в куче компаний решили что админы не нужны, и управлением серверами могут заниматься сами разработчики. Могут, но неплохо бы думать научиться, чтобы небыло как с GitLab: один разработчик случайно удаляет продакшн базу данных, перепутав сервера. И тут выясняется, что бэкапы есть, но восстановить из них ничего нельзя. В общем поучительная история.
Они думали что devops'изация избавит от раздолбайства.
А DevOps не подразумевает наличие DevOps-инженеров, которые те же самые опытные админы, но нацелены на всеобщее единение и лучше разбираются в разработке софта?
Не всегда.
Возможно я не до конца понимаю суть DevOps, но мне кажется что это явление вообще не подразумевает существование людей с подобными должностями. Как по мне, DevOps — это нечто вроде религии, взаимоотношения между Dev и Ops. А в случае ребят из GitLab — у них похоже роль Ops возложена на Dev
Не в ту консоль вбить команду, совершил бы кто угодно.
А вот не проверять «5 разных видов бекапов» до такой степени что ни один из них как оказалось бекапом не был, вот это да.
А вот не проверять «5 разных видов бекапов» до такой степени что ни один из них как оказалось бекапом не был, вот это да.
Я, когда за этой историей следил, точно так же и подумал. Мне только кажется самая большая ошибка это не то что developer удалил базу не на том сервере, а то что компания с USD 20 mln инвестиций не потрудилась обеспечить отказоустойчивость сервиса и не проработали детальный Disaster Recovery план с соответствующими RTO и RPO и обязательным тестированием процесса восстановления.
Disaster Recovery план? Не, не слышали)
- Регулярные бэкапы, похоже, также делались только раз в сутки...
- SH: Похоже, что pg_dump работает неправильно, поскольку...
- Снимки дисков в Azure включены для NFS-сервера, для серверов баз данных — нет.
- Процедура репликации оказалось очень хрупкой...
- SH: Мы позже выяснили, что...
- Наши S3-бэкапы также не работают: папка пуста.
- У нас нет надежной системы оповещений о неудачных попытках создания бэкапов...
Глазам не верю — это точно GitLab? Не VasilyPupkinMegaBestCloudHosting Ltd. с полутора серверами?
Серьезная компания мирового уровня, да, вне всяких сомнений.
Вся статья проникнута сочуствием и уважением «к открытости», и это по-человечески понятно, но давайте называть вещи своими именами — это полный бардак, запредельный. И если бы не эта «роковая случайность», оно могло бы стрельнуть позже с куда более крутыми последствиями. Повезло везунчикам.
P.S. Ниже в комментах говорят об увеличении лояльности к компании по причине их той самой открытости. Чудеса. Вы собираетесь им свои данные доверять или их няшные портреты на стенку вешать? Вроде как первое, а что до портретов, то можно найти и по-няшнее. Просто осмыслите факт — люди работали годами без бэкапов и зашевелились на эту тему только сейчас, когда выстрелили себе в ногу. Просто представьте себе образ мышления этих людей. Представили? Нравится? Няшно? Жесть.
Поясню пару моментов от лица ГитЛаба.
Чтобы вы понимали, для ГитЛаба GitLab.com с точки зрения бизнеса — совсем не основное направление. Деньги компания зарабатывает на продаже Enterprise-лицензий.
Приятно слышать что вы считаете GitLab компанией мирового уровня, но не стоит забывать что это очень молодая компания, и за год компании пришлось вырасти с 25 человек до 160.
Да, слишком поздно обратили внимание на то с какой скоростью растет бесплатный GitLab.com, из-за этого и проблемы со скоростью сервиса, и вот это.
Открытость в данном случае — это не оправдание, а гарантия что проблема будет преодолена и такой фигни больше не случится.
Ну, зато индексы перестроились, теперь всё будет работать побыстрее :)
По поводу перевода небольшое замечание: «frustration» в данном контексте корректнее переводить как «досада» или «раздражение». Т.е. на него не печаль накатила, и он пошёл чистить базу на диске на манер суицида, а просто слегка психанул.
Ламерский вопрос:
Что за ссылки на gitlab.slack.com? Предполагается, что к данной группе есть доступ(гостевой) у всех? Или только у тех, кто настраивал интеграцию Slack<->Gitlab?
Что за ссылки на gitlab.slack.com? Предполагается, что к данной группе есть доступ(гостевой) у всех? Или только у тех, кто настраивал интеграцию Slack<->Gitlab?
Твит от YP
Манера изложения навевает тревожность, чем напоминает передачу
Кстати мысль: начал бы кто снимать аналогичную, но с IT спецификой. Для начала можно выкладывать и на youtube. На декорации тратиться не надо — подойдёт любой офис. Главное хороших актёров найти.
Я бы посмотрел.
Секунды до катастрофы
Кстати мысль: начал бы кто снимать аналогичную, но с IT спецификой. Для начала можно выкладывать и на youtube. На декорации тратиться не надо — подойдёт любой офис. Главное хороших актёров найти.
Я бы посмотрел.
Передача, в которой происходящее будет понимать только узкий круг специалистов? Мне вот, некоторые вещи из статьи гуглить понадобилось. Как вы это в передачу засунете?
Если всё разжёвывать и объяснять — то спецам в области, в которой произошёл инцидент будет скучновато; если не объяснять ничего — то происходящие поймут единицы. Останавливать видео каждые 14 секунд и гуглить — тоже не вариант.
Если всё разжёвывать и объяснять — то спецам в области, в которой произошёл инцидент будет скучновато; если не объяснять ничего — то происходящие поймут единицы. Останавливать видео каждые 14 секунд и гуглить — тоже не вариант.
Рекомендую почитать Артура Хейли. Как ни странно, ему это удалось… А специфики в авиации не меньше…
Сэм (админ): У нас упал интернет, я позвонил Дереку уточнить детали
Дерек (провайдер): Мне только что звонил Сэм, говорят у них упал интернет. С этим срочно нужно что то делать, каждая секунда на счету
Том (клиент): Сэм сказал что у них не работает интернет. Наша работа стоит. Я надеюсь это скоро исправят
Что то типа этого? )
Дерек (провайдер): Мне только что звонил Сэм, говорят у них упал интернет. С этим срочно нужно что то делать, каждая секунда на счету
Том (клиент): Сэм сказал что у них не работает интернет. Наша работа стоит. Я надеюсь это скоро исправят
Что то типа этого? )
Скорее что-то вроде этого.
Что-то подобное есть кстати
Читал с замиранием и просто физически ощущал напряжение и выбор метода сначала настройки репликации, а потом «лечения» нарастающих проблем.
На словах " YP начинает чувствовать безысходность" захотелось по советам Шелдона Капера предложить ему горячий напиток.
На словах " YP начинает чувствовать безысходность" захотелось по советам Шелдона Капера предложить ему горячий напиток.
> Шелдона Капера
рукалицо.bmp
рукалицо.bmp
упс… говорила мне мама: перечитывай, сынок, после того, как набрал что-то на клавиатуре, не глядя :)
уровень потерь совершенно разный.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
Вот так наберешь однажды rm -rf…
UFO just landed and posted this here
Помнить, что даже самое тяжелое поражение можно превратить в победу.Я не понимаю, где тут победа? Они сейчас потеряли лояльность клиентов. Представьте например, на месте GitLab — Сбербанк и потерю данных за 3 часа? Я думаю мы бы речи о победе не вели.
Кто то перестанет им верить, мне лично импонирует их открытость, признание проблем и юмор над самим собой.
Пожалуй они получили больше моей лояльности.
Пожалуй они получили больше моей лояльности.
Поддерживаю! Их, ИМХО, в такой ситуации нельзя сравнивать с тем же Сбербанком. Они не держат у себя денег других людей/компаний в отличии от Сбербанка.
И да! Они абсолютные красавцы и молодцы в такой ситуации только за то, что подошли к этому инциденту с определенной долей юмора и решили преподнести этот фэйл не только как свой косяк, но и показали как выйти из такой ситуации. Показали слабые места.
Короче говоря: эти ребята молодчики!
И да! Они абсолютные красавцы и молодцы в такой ситуации только за то, что подошли к этому инциденту с определенной долей юмора и решили преподнести этот фэйл не только как свой косяк, но и показали как выйти из такой ситуации. Показали слабые места.
Короче говоря: эти ребята молодчики!
Потому что Сбербанк бы всё засекретил и хрен бы что рассказал на публику, а не потому, что потерял бы данные. А тут всё правильно сделали. Не ошибается тот, кто ничего не делает.
Да ладно. Link
Возможно, я что-то упускаю, но сообщение в СМИ типа "Произошёл сбой в работе базы данных" никак не может являться примером публичности, а как раз подтверждает мою точку зрения "хрен бы что рассказали".
Выложили данные для анализа, привлекли помощь сообщества и рассказали технические подробности. Да процесс восстановления не стримили и внутренние документы не выкладывали.
По вашей ссылке не нашёл данных для анализа и технических подробностей. Из поста лишь ссылка на СМИ, не более того.
История, судя по их пресс-релизам:
6 июля 2012г сбой в работе:
В связи с техническим сбоем не осуществляется обслуживание карт Сбербанка. ИТ-служба Сбербанка предпринимает все возможные меры для скорейшего устранения возникшей проблемы. Сбербанк приносит извинения своим клиентам за доставленные неудобства.
6 июля, чуть позже:
Сбербанк России сообщает о восстановлении обслуживания банковских карт.
Обслуживание банковских карт Сбербанка было не доступно с 17:10 МСК в связи со сбоем в работе базы данных процессинга на платформе ORACLE. Перевод системы на резервный комплекс не дал ожидаемых результатов. В связи с этим было принято решение о начале процедуры Recovery (восстановления) базы данных. Из-за большого объема данных эта процедура занимает продолжительное время, однако гарантирует восстановление абсолютно всех клиентских данных и транзакций. Система была полностью восстановлена в 20:10 МСК.
Сбербанк приносит клиентам свои искренние извинения за доставленные неудобства.
13 (!) июля:
Сбербанк создал краудсорсинговый ресурс для выявления причин технического сбоя в обслуживании банковских карт
(видимо, тогда и выложили "данные для анализа"; сложно сказать, т.к. этот ресурс сейчас недоступен)
То есть, неделя тишины, а потом (видимо, не выяснив самостоятельно?) они просят помощи у сообщества.
Ну ок.
И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.
— Ну, давай уже технические подробности!
— Журнал повторного выполнения Oracle реализован в виде кольцевого буфера. В «голову» процесс LGWR пишет новые изменения в БД, а «хвост» подчищается процессом CKPT по мере того, как изменения, записанные в «хвосте» будут записаны процессами DBWn в файлы данных. «Голова» — это текущий (current) файл журнала, хвост — активные (active) файлы. Подчистка хвоста заключается в том, что журналы помечаются как пригодные к повторному использованию (inactive). Проблема состояла в том, что «подчистка» прекратилась, т.е. все файлы оперативного журнала стали активными, и экземпляру БД стало некуда записывать новые изменения.
И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.
Я думаю у GitLab — это тоже не единственный сбой, но по остальных они документы не выкладывают.
Да как-то нет. Зная масштаб конторки и предлагаемые ими условия, все взаимодействие с ними строится на основе того факта, что рано или поздно все это навернется. А основная клиентура у них на самом деле корпоративная, которая отваливает за standalone версию, то есть их эта кутерьма если и затронула, то опосредованно.
Читал как хронику «чернобыля», только со счастливым концом.
UFO just landed and posted this here
отличный пример для того, чтобы учиться на чужих ошибках и уже делать бэкапы (и проверять восстановление)
Все я фанат Ёрика, пойду базу грохну… поддержу так сказать )
Они скорее всего просто хлопнули коньячку, и решили сыграть в админскую рулетку ;)
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo «Alive!»
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo «Alive!»
UFO just landed and posted this here
Логика подсказывает, что любой дополнительный уровень абстракции должен замедлять работу. Но умные люди в Интернете пишут, что в случае LVM это влияние пренебрежительно мало, и лишь в некоторых особых случаях может оказаться заметным. Согласен с Вами, похоже, что в статье о накладных расходах при использовании LVM не нужно было упоминать.
UFO just landed and posted this here
У нас имена серверов отличаются по буквам, serveru1, serverp2 — uat/prod.
+ цветовая индикация. Прод сервер красного цвета, юат синего. Правда не на всех серверах есть цветовая индикация. Тем не менее 7 раз проверь, один раз удали должен работать на уровне рефлексов, я считаю.
Думаю второй раз YP этой ошибки не совершит :)
+ цветовая индикация. Прод сервер красного цвета, юат синего. Правда не на всех серверах есть цветовая индикация. Тем не менее 7 раз проверь, один раз удали должен работать на уровне рефлексов, я считаю.
Думаю второй раз YP этой ошибки не совершит :)
Должный уровень паранойи. Вот чего многим не хватает.
У меня вот ее через край, от чего тормозятся иногда даже банальные вещи, которые в принципе всегда non-disruptive.
У меня вот ее через край, от чего тормозятся иногда даже банальные вещи, которые в принципе всегда non-disruptive.
Можете объяснить, с какой целью вы уродуете ссылки на источники, вставляя в них www.google.com, отчего мой браузер постоянно варнится на редиректы?
По идее можно было бы восстановить и проекты и ишью и комменты из production.log. Погрепать по POST и взять params, и с них уже восстановить все, что было потеряно.
Думаю, будет не лишним сделать скрипт, который бы отображал администратору имя сервера (крсаненьким, мигающим) и запрос уверен ли он выполнить rm -rf. ну и намутить alias, чтобы по rm вызывался этот самый скрипт.
Глупость. Во-первых, это поломает скрипты. Во-вторых, любой "красненький, мигающий" запрос после пятого-десятого раза проходится автоматически, без участия мозга.
Не сломает. bash -c «alias» не вызывает интерактивный шелл, а при запуске неинтерактивного шелла .bashrc и иже с ним игнорятся. К тому же, во многих системах, по-умолчанию для rm заведен алиас rm='rm -i'. Мигающая надпись добавит шансов, что администратор остановится.
Да, согласен, не сломает. Забыл как алиасы работают.
Но мигающая надпись все равно будет админом обходиться без участия мозга, это уже проверено поколениями чайников, сломавших себе винду самыми странными способами.
Так вроде бы разница между чайником и админом еще и в том, что последний сначала читает, что написано, а потом делает, а не наоборот. И не надо допускать чайников к администрированию важных серверов
Увы, но механизмы обучаемости и возникновения условных рефлексов — одни и те же. Вылезло окно — нажми "ОК" не читая. Загорелась мигающая надпись — нажми "y"...
rm -rf — это не та команда, которую администратор выполняет по несколько раз на дню.
Для борьбы с этим можно применять простой способ — подтверждение требует ввода слова, а само слово указано в тексте сообщения. Причем для разных серверов слово может быть разным. Что может спасти в ситуации "перепутал сервер".
По-моему, такая открытость — это просто популистская попытка прикрыть собственную безалаберность (я про компанию).
Похоже, что открытость у них в крови. Вполне возможно, что там даже не было обсуждения уровня освещения инцидента и какого-то процесса принятия решения о том, чтобы отрабатывать это событие в открытую. Они просто всегда так работают.
Вот их ценности, в число которых входит "Transparency".
Там написано следующее: "everything at GitLab is public by default", т. е. они публичны по умолчанию.
Sign up to leave a comment.
sudo rm -rf, или Хроника инцидента с базой данных GitLab.com от 2017/01/31