company_banner

sudo rm -rf, или Хроника инцидента с базой данных GitLab.com от 2017/01/31

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
  • Перевод

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

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.


Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...


По причине важности и во многих смыслах поучительности этого случая мы решили целиком перевести на русский язык его журнал-отчет, сделанный сотрудниками GitLab.com в процессе работы над инцидентом. Результат вы можете найти под катом.


Итак, давайте узнаем во всех подробностях, как это было.


Инцидент с базой данных GitLab.com от 31/01/2017


Замечание: этот инцидент затронул базу данных (включая задачи (issues) и запросы на слияние (merge requests)); git-репозитории и wiki-страницы не пострадали.


Прямая трансляция на YouTube — следите за тем, как мы обсуждаем и решаем проблему!


  1. Понесенные потери
  2. Хронология (время указано в UTC)
  3. Восстановление — 2017/01/31 23:00 (бэкап от примерно 17:20 UTC)
  4. Возникшие проблемы
  5. Помощь со стороны
    • HugOps (добавляйте здесь посты из twitter и откуда-либо еще, в которых люди по-доброму реагировали на случившееся)
    • Stephen Frost
    • Sam McLeod

Понесенные потери


  1. Потеряны данные примерно за 6 часов.
  2. Потеряно 4613 обычных проектов, 74 форка и 350 импортов (грубо); всего 5037. Поскольку Git-репозитории НЕ потеряны, мы сможем воссоздать те проекты, пользователи/группы которых существовали до потери данных, но не сможем восстановить задачи (issues) этих проектов.
  3. Потеряно около 4979 (можно сказать, около 5000) комментариев.
  4. Потенциально потеряно 707 пользователей (сложно сказать точнее по логам Kibana).
  5. Веб-хуки, созданные до 31 января 17:20, восстановлены, созданные после — потеряны.

Хронология (время указано в UTC)


  1. 2017/01/31 16:00/17:00 — 21:00
    • YP работает над настройкой pgpool и репликацией в staging, создает LVM-снимок, чтобы загрузить боевые данные в staging, а также в надежде на то, что сможет использовать эти данные для ускорения загрузки базы на другие реплики. Это происходит примерно за 6 часов до потери данных.
    • Настройка репликации оказывается проблематичной и очень долгой (оценочно ~20 часов только на начальную синхронизацию pg_basebackup). LVM-снимок YP использовать не смог. Работа на этом этапе была прервана (так как YP была нужна помощь другого коллеги, который в тот день не работал, а также из-за спама/высокой нагрузки на GitLab.com).
  2. 2017/01/31 21:00Всплеск нагрузки на сайт из-за спамеровTwitter | Slack
    • Блокирование пользователей по их IP-адресам.
    • Удаление пользователя за использование репозитория в качестве CDN, в результате чего 47 000 айпишников залогинились под тем же аккаунтом (вызвав высокую нагрузку на БД). Информация была передана командам технической поддержки и инфраструктуры.
    • Удаление пользователей за спам (с помощью создания сниппетов) — Slack
    • Нагрузка на БД вернулась к норме, вручную запущен vacuum нескольких таблиц PostgreSQL, чтобы почистить большое количество оставшихся пустых строк.
  3. 2017/01/31 22:00Получено предупреждение об отставании репликацииSlack
    • Попытки починить db2, отставание на этом этапе 4 GB.
    • db2.cluster отказывается реплицироваться, каталог /var/opt/gitlab/postgresql/data вычищен, чтобы обеспечить чистую репликацию.
    • db2.cluster отказывается подключаться к db1, ругаясь на слишком низкое значение max_wal_senders. Эта настройка используется для ограничения количества клиентов WAL (репликации).
    • YP увеличивает max_wal_senders до 32 на db1, перезапускает PostgreSQL.
    • PostgreSQL ругается на то, что открыто слишком много семафоров, и не стартует.
    • YP уменьшает max_connections с 8000 до 2000, PostgreSQL стартует (при том, что он нормально работал с 8000 почти целый год).
    • db2.cluster все еще отказывается реплицироваться, но на соединения больше не жалуется, а вместо это просто висит и ничего не делает.
    • В это время YP начинает чувствовать безысходность. Раньше в этот день он сообщил, что собирается заканчивать работу, так как было поздно (около 23:00 по местному времени), но остался на месте по причине неожиданно возникших проблем с репликацией.
  4. 2017/01/31 около 23:00
    • YP думает, что, возможно, pg_basebackup чересчур педантично относится к чистоте директории для данных, и решает ее удалить. Спустя пару секунд он замечает, что запустил команду на db1.cluster.gitlab.com вместо db2.cluster.gitlab.com.
    • 2017/01/31 23:27: YP отменяет удаление, но уже слишком поздно. Из примерно 310 Гб осталось только 4.5 — Slack.

Восстановление — 2017/01/31 23:00 (бэкап от ~17:20 UTC)


  1. Предложенные способы восстановления:
    1. Смигрировать db1.staging.gitlab.com на GitLab.com (отставание около 6 часов).
      • CW: Проблема с веб-хуками, которые были удалены во время синхронизации.
    2. Восстановить LVM-снимок (отстает на 6 часов).
    3. Sid: попробовать восстановить файлы?
      • CW: Невозможно! rm -Rvf Sid: OK.
      • JEJ: Наверное, уже слишком поздно, но может ли помочь, если достаточно быстро перевести диск в режим read-only? Также нельзя ли получить дескриптор файла, если он используется работающим процессом (согласно http://unix.stackexchange.com/a/101247/213510).
      • YP: PostgreSQL не держит все свои файлы постоянно открытыми, так что это не сработает. Также похоже, что Azure очень быстро удаляет данные, а вот пересылает их на другие реплики уже не так шустро. Другими словами, данные с самого диска восстановить не получится.
      • SH: Похоже, что на db1 staging-сервере отдельный PostgreSQL-процесс льет поток production-данных с db2 в каталог gitlab_replicator. Согласно отставанию репликации db2 был погашен в 2016-01-31 05:53, что привело к остановке gitlab_replicator. Хорошие новости заключаются в том, что данные вплоть до этого момента выглядят нетронутыми, поэтому мы, возможно, сможем восстановить веб-хуки.
  2. Предпринятые действия:
    1. 2017/02/01 23:00 — 00:00: Принято решение восстанавливать данные с db1.staging.gitlab.com на db1.cluster.gitlab.com (production). Несмотря на то, что они отстают на 6 часов и не содержат веб-хуков, это единственный доступный снимок. YP говорит, что ему сегодня лучше больше не запускать никаких команд, начинающихся с sudo, и передает управление JN.
    2. 2017/02/01 00:36 — JN: Делаю бэкап данных db1.staging.gitlab.com.
    3. 2017/02/01 00:55 — JN: Монтирую db1.staging.gitlab.com на db1.cluster.gitlab.com.
      • Копирую данные со staging /var/opt/gitlab/postgresql/data/ в production /var/opt/gitlab/postgresql/data/.
    4. 2017/02/01 01:05 — JN: nfs-share01 сервер выделен в качестве временного хранилища в /var/opt/gitlab/db-meltdown.
    5. 2017/02/01 01:18 — JN: Копирую оставшиеся production-данные, включая запакованный pg_xlog: ‘20170131-db-meltodwn-backup.tar.gz’.
    6. 2017/02/01 01:58 — JN: Начинаю синхронизацию из stage в production.
    7. 2017/02/01 02:00 — CW: Для объяснения ситуации обновлена страничка развертывания (deploy page). Link.
    8. 2017/02/01 03:00 — AR: rsync выполнился примерно на 50% (по количеству файлов).
    9. 017/02/01 04:00 — JN: rsync выполнился примерно на 56.4% (по количеству файлов). Передача данных идет медленно по следующим причинам: пропускная способность сети между us-east и us-east-2, а также ограничение производительности диска на staging-сервере (60 Mb/s).
    10. 2017/02/01 07:00 — JN: Нашел копию нетронутых данных на db1 staging в /var/opt/gitlab_replicator/postgresql. Запустил виртуальную машину db-crutch VM на us-east, чтобы сделать бэкап этих данных на другую машину. К сожалению, она ограничена 120 GB RAM и не потянет рабочую нагрузку. Эта копия будет использована для проверки состояния базы данных и выгрузки данных веб-хуков.
    11. 2017/02/01 08:07 — JN: Передача данных идет медленно: по объему данных передано 42%.
    12. 2017/02/02 16:28 — JN: Передача данных закончилась.
    13. 2017/02/02 16:45 — Ниже приведена процедура восстановления.
  3. Процедура восстановления
    1. [x] — Сделать снимок сервера DB1 — или 2 или 3 — сделано в 16:36 UTC.
    2. [x] — Обновить db1.cluster.gitlab.com до PostgreSQL 9.6.1, на нем по-прежнему 9.6.0, а staging использует 9.6.1 (в противном случае PostgreSQL может не запуститься).
      • Установить 8.16.3-EE.1.
      • Переместить chef-noop в chef-client (было отключено вручную).
      • Запустить chef-client на хосте (сделано в 16:45).
    3. [x] — Запустить DB — 16:53 UTC
      • Мониторить запуск и убедиться, что все прошло нормально.
      • Сделать бэкап.
    4. [x] — Обновить Sentry DSN, чтобы ошибки не попали в staging.
    5. [x] — Увеличить идентификаторы во всех таблицах на 10k, чтобы избежать проблем при создании новых проектов/замечаний. Выполнено с помощью https://gist.github.com/anonymous/23e3c0d41e2beac018c4099d45ec88f5, который читает текстовый файл, содержащий все последовательности (по одной на строку).
    6. [x] — Очистить кеш Rails/Redis.
    7. [x] — Попытаться по возможности восстановить веб-хуки.
      • [x] Запустить staging, используя снимок, сделанный до удаления веб-хуков.
      • [x] Убедиться, что веб-хуки на месте.
      • [x] Создать SQL-дамп (только данные) таблицы “web_hooks” (если там есть данные).
      • [x] Скопировать SQL-дамп на production-сервер.
      • [x] Импортировать SQL-дамп в рабочую базу.
    8. [x] — Проверить через Rails Console, могут ли подключаться рабочие процессы (workers).
    9. [x] — Постепенно запустить рабочие процессы.
    10. [x] — Отключить страницу развертывания.
    11. [x] — Затвитить с @gitlabstatus.
    12. [x] — Создать связанные со сбоем задачи, описывающие дальнейшие планы/действия
      Скрытый текст

      [ ] — Создать новые записи Project Git-репозиториев, у которых нет записей Project, в случаях, когда пространство имен соответствует существующему пользователю/группе.
      • PC — Я создаю список этих репозиториев, чтобы мы могли проверить в базе данных, существуют ли они.

      [ ] — Удалить репозитории с неизвестными (потерянными) пространствами имен.
      • AR — работаю над скриптом, основанным на данных с предыдущей точки.

      [x] — Еще раз удалить спам-пользователей (чтобы они снова не создали проблем).
      • [x] CDN-пользователь с 47 000 IP-адресами.

    13. Сделать после восстановления данных:
      1. Создать задачу на изменение в терминалах PS1-формата/цветов, чтобы было сразу понятно, какая среда используется: production или staging (production — красный, staging — желтый). Для всех пользователей по умолчанию в приглашении bash показывать полное имя хоста (например, “db1.staging.gitlab.com” вместо “db1”): https://gitlab.com/gitlab-com/infrastructure/issues/1094
      2. Как-нибудь запретить rm -rf для директории data PostgreSQL? Не уверен, что это выполнимо или необходимо (в том случае, если есть нормальные бэкапы).
      3. Добавить оповещения для бэкапов: проверка хранилища S3 и т. д. Добавить график, показывающий изменения размеров бэкапов, выдавать предупреждение, когда размер уменьшается более чем на 10%: https://gitlab.com/gitlab-com/infrastructure/issues/1095.
      4. Рассмотреть добавление времени последнего успешного бэкапа в БД, чтобы админы могли легко увидеть эту информацию (предложено клиентом в https://gitlab.zendesk.com/agent/tickets/58274).
      5. Разобраться, почему у PostgreSQL внезапно возникли проблемы с max_connections, установленным в 8000, несмотря на то, что это работало с 2016-05-13. Неожиданное появление этой проблемы во многом ответственно за навалившиеся отчаяние и безысходность: https://gitlab.com/gitlab-com/infrastructure/issues/1096.
      6. Посмотреть на увеличение порогов репликации через архивацию WAL / PITR — также будет полезно после неудачных обновлений: https://gitlab.com/gitlab-com/infrastructure/issues/1097.
      7. Создать для пользователей руководство по решению проблем, которые могут возникнуть после запуска сервиса.
      8. Поэкспериментировать с перемещением данных из одного дата-центра в другой с помощью AzCopy: Microsoft говорит, что это должно работать быстрее rsync:
        • Похоже, это Windows-специфичная вещь, а у нас нет экспертов по Windows (или кого-то хотя бы отдаленно, но в достаточной степени знакомого с вопросом, чтобы грамотно это протестировать).

    Возникшие проблемы


    1. LVM-снимки по умолчанию делаются лишь один раз в 24 часа. По счастливой случайности YP за 6 часов до сбоя сделал один вручную.
    2. Регулярные бэкапы, похоже, также делались только раз в сутки, хотя YP еще не выяснил, где они хранятся. Согласно JN они не работают: создаются файлы размером в несколько байт.
      • SH: Похоже, что pg_dump работает неправильно, поскольку выполняются бинарники от PostgreSQL 9.2 вместо 9.6. Это происходит из-за того, что omnibus использует только Pg 9.6, если data/PG_VERSION установлено в 9.6, но на рабочих узлах этого файла нет. В результате по умолчанию запускается 9.2 и тихо завершается, ничего не сделав. В итоге SQL-дампы не создаются. Fog-гем, возможно, вычистил старые бэкапы.
    3. Снимки дисков в Azure включены для NFS-сервера, для серверов баз данных — нет.
    4. Процесс синхронизации удаляет веб-хуки после того, как он синхронизировал данные на staging. Если мы не сможем вытащить их из обычного бэкапа, сделанного в течение 24 часов, они будут потеряны.
    5. Процедура репликации оказалось очень хрупкой, склонной к ошибкам, зависящей от случайных shell-скриптов и плохо документированной.
      • SH: Мы позже выяснили, что обновление базы данных staging работает путем создания снимка директории gitlab_replicator, удаления конфигурации репликации и запуска отдельного PostgreSQL-сервера.
    6. Наши S3-бэкапы также не работают: папка пуста.
    7. У нас нет надежной системы оповещений о неудачных попытках создания бэкапов, мы теперь видим такие же проблемы и на dev-хосте.

    Другими словами, из 5 используемых способов бэкапа/репликации ни один не работает. => сейчас мы восстанавливаем рабочий бэкап, сделанный 6 часов назад.



    http://monitor.gitlab.net/dashboard/db/postgres-stats?panelId=10&fullscreen&from=now-24h&to=now


    Помощь со стороны


    Hugops (добавляйте здесь посты из twitter или откуда-то еще, в которых люди по-доброму реагировали на случившееся)

    Stephen Frost


    • https://twitter.com/net_snow/status/826622954964393984 @gitlabstatus Привет, я разработчик PG, и мне нравится то, что вы делаете. Сообщите, если я могу чем-то помочь, я был бы рад оказаться полезен.

    Sam McLeod


    • Привет, Сид, очень жаль, что у вас проблемы с базой данных / LVM, это чертовски неприятно. У нас работает несколько кластеров PostgreSQL (master/slave), и я обратил внимание на несколько вещей в вашем отчете:
      1. Вы используете Slony, а это еще тот кусок сами знаете чего, и это совсем не преувеличение, тут вот даже смеются над ним http://howfuckedismydatabase.com, при этом встроенный бинарник PostgreSQL, отвечающий за потоковую репликацию, очень надежен и быстр, предлагаю переключиться на него.
      2. Не упоминается использование пулов соединений, зато говорится о тысячах соединений в postgresql.conf — это очень плохо и неэффективно с точки зрения производительности, предлагаю использовать pg_bouncer и не выставлять max_connection в PostgreSQL выше 512-1024; практически, если у вас больше 256 активных соединений, надо масшабироваться горизонтально, а не вертикально.
      3. В отчете говорится, насколько ненадежны ваши процессы отработки отказа и резервного копирования, мы написали и задокументировали простой скрипт для postgresql failover ­­— если хотите, я его вам перешлю. Что касается бэкапов, то для инкрементных резервных копий в течение дня мы используем pgbarman, а также делаем полные бэкапы дважды в день с помощью barman и pg_dump, важно с точки зрения производительности и надежности хранить ваши бэкапы и директорию с данными postgresql на разных дисках.
      4. Вы все еще в Azure?!?! Я бы предложил оттуда как можно быстрее съехать, так как там немало странных проблем с внутренним DNS, NTP, маршрутизацией и хранилищами, также я слышал несколько пугающих историй о том, как там все устроено внутри.

    Длинная переписка Сида и Сэма с упором в настройку PostgreSQL
    • Сообщите, если вам нужна помощь по настройке PostgreSQL, у меня в этом вопросе приличный опыт.
    • Capt. McLeod: еще вопрос: сколько места на диске занимает ваша база (базы)? Речь идет о терабайтах или это все еще гигабайты?
    • Capt. McLeod: выложил свой скрипт отработки отказа / репликации:
    • Я также вижу, что вы смотрите на pgpool ­— я бы предложил pgbouncer взамен
    • Capt. McLeod: У pgpool предостаточно проблем, мы его хорошенько протестировали и выкинули.
    • Capt. McLeod: Также дайте мне знать, если я могу сказать что-то публично через твиттер или как-то еще в поддержку GitLab и вашей прозрачности в работе над этой проблемой, я знаю, как это тяжело; когда я только начинал, у нас был split-brain на уровне SAN в infoxchange, и меня в буквальном смысле рвало — настолько сильно я нервничал!
    • Sid Sijbrandij: Привет, Сэм, спасибо за помощь. Ты не против, если я скопирую это в публичный документ, чтобы это могли остальные члены команды?
    • Capt. McLeod: Скрипт отработки отказа?
    • Sid Sijbrandij: Все, что ты написал.
    • Конечно, в любом случае это публичный репозиторий, но он не идеален, очень далек от этого, но хорошо делает свою работу, я постоянно путаю хосты безо всяких последствий, но у вас все может быть по-другому.
    • Да, конечно, ты можешь переслать и мои рекомендации.
    • Если ты сможешь прислать мне информацию о своей VM, на которой запущен PostgreSQL и свой PostgreSQL.conf, я дам рекомендации по его улучшению.


    • Sid: мы использовали Slony только для обновления с 9.2 до 9.6, в остальных случаях у нас работает потоковая репликация.
      Комментарий: ОК, это хорошо, для информации: в рамках мажорных версий PostgreSQL для выполнения обновлений можно использовать встроенную репликацию.


    • Rails уже создает пулы соединений (25 на процесс). При 20 процессах на 20 хостах получается где-то 10 000 соединений, при этом будет около 400 активных (поскольку Unicorn — это однопоточное приложение).
      Комментарий: Каждое PostgreSQL-соединение использует память, держать сразу много открытых соединений неэффективно; здесь может помочь pg_bouncer — фантастически простой и быстрый инструмент по созданию пулов соединений. Он делает только одну вещь, но делает ее хорошо, тогда как pgpool все усложняет. Он может переписывать запросы, некоторые из которых начинают работать не так, как ожидалось. Pgpool не создан для использования совместно с ORM/db-фреймворками.

    Стоит почитать: https://wiki.postgresql.org/wiki/Number_Of_Database_Connections


    • Для балансировки нагрузки, создания пулов соединений, качественной отработки отказов и т. д. мы смотрим на pgpool + потоковая репликация с синхронными коммитами (для согласованности данных). Pgbouncer, насколько мы знаем, не балансирует нагрузку (по крайней мере, из коробки). Вот это https://github.com/awslabs/pgbouncer-rr-patch стоит рассмотреть в качестве одного из вариантов.

    Вопрос: Используете ли вы в настоящее время несколько active/active PostgreSQL-нод, и если нет, то как выполняете балансировку нагрузки?


    Вопрос: Какова ежедневная нагрузка на сайт? Сколько загрузок страниц и запросов в секунду?


    * По всей вероятности, секция с вопросами от Сэма, ответами команды GitLab.com и итоговыми рекомендациями будет еще некоторое время пополняться и к самому инциденту прямого отношения уже не имеет. Мы пока не стали включать ее в перевод, так как оригинал еще не стабилизировался.


    Заключение


    Что показательно, ребята из GitLab сумели превратить свою грубейшую ошибку в поучительную историю и, думаю, не только не потерять, но и завоевать уважение многих айтишников. Также за счет открытости, написав о проблеме в Twitter и выложив лог в Google Docs, они очень быстро получили квалифицированную помощь со стороны, причем, похоже, совершенно безвозмездно.


    Как всегда, радуют люди с хорошим чувством юмора: главный виновник инцидента теперь называет себя "Database (removal) specialist" (Специалист по [удалению] баз данных), какие-то шутники предложили 1 февраля сделать днем проверки бэкапов http://checkyourbackups.work/, а пользователи Хабра вспомнили чудесную тематическую картинку:



    Источник


    Какие можно сделать выводы?


    1. Нужно проверять бэкапы.
    2. Необходимо учитывать дополнительные трудности при восстановлении файлов в облаке (по крайней мере, в Azure).
    3. LVM ­— это не так уж и плохо, и его используют для размещения БД даже такие заметные компании, как GitLab.com, несмотря на потери в производительности.
    4. Не давать dev/stage/prod-серверам похожие названия.
    5. Делать интерфейсы dev/stage/prod-серверов отличающимися друг от друга по цвету/формату.
    6. Не бояться рассказать всему свету о своей ошибке — добрых людей больше, и они помогут.
    7. Помнить, что даже самое тяжелое поражение можно превратить в победу.

    Ссылки по теме:


Southbridge 131,98
Обеспечиваем стабильную работу серверов
Поделиться публикацией
Похожие публикации
Комментарии 129
  • –9
    один из админов GitLab.com
    YP (https://yorickpeterse.com) — software developer. Собственно это к вопросу о DevOPS, мне кажется что Системный Администратор с опытом такой ошибки не допустил бы.
    • +24
      Обычный человеческий фактор: усталость, чуточка спешки. Задача на которой не сработали типовые и рутинные решения что раздражает. Итого стечение кучи обстоятельств, «Секунда невнимательности» и оп.
      • +23

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


        Регулярно делать бэкапы и проверять их работоспособность, не использовать похожие названия, не делать ничего наугад, когда система начинает показывать неожиданное поведение ("PostgreSQL ругается на то, что открыто слишком много семафоров, и не стартует, при том что до этого нормально работал почти целый год"), да даже банально не работать в 11 вечера — это же все прописные истины, о которых расскажет любой новичок.

        • +1
          Я бы ещё добавил аккуратность.
          • +28
            Пилоты самолетов, налетавшие десятки тысяч часов — и те совершают ошибки которые могут стоить жизни не только им самим но еще десяткам и сотням людей.

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

            А проблема гитлаба не только в одной консольной команде одного человека. Тут ситуация глубже значительно, потому что система бэкапов у них точно также не работала штатно и сомневаюсь что господин Петерс единолично все везде настраивал.

            В этой ситуации мы с товарищами склонны видеть очень ценный жизненный урок и точку после которой в любом случае Gitlab значительно пересмотрит подход к работе с данными и вероятность повторения подобной ситуации должна уменьшиться в разы. Однако в любом случае какого крутого админа не возьми, человеческий фактор исключить полностью невозможно.
            • –8
              Там автоматика в самолетах. И даже, если она отключается, назойливый голов об этом говорит.
              • +7
                Ну так катастрофы обычно случаются на стыке действий человека и автоматики, или на неправильном ее использовании, да еще и при сочетании множества факторов (сложные условия полета, ошибка человека, неочевидная работа автоматики в ситуации которую создатели не предусмотрели и т.п.). Каждый пункт по отдельности вроде бы не страшен и каждое отдельное действие системы может быть логичным и ожидаемым, но в сумме все приводит к катастрофе.

                Например как с Ту-204 во Внукове: слишком плавно приземлились с большим перелетом -> не обжались до конца стойки шасси -> автоматика посчитала что самолет еще летит и не дала включить реверс -> пилоты вовремя не прочухали в чем дело и дали полный газ (думая что включают реверс) -> самолет разогнался вместо того чтобы тормозиться -> выкатились с полосы.
                Каждое отдельное действие бортовой системы управления правильное — нельзя давать включать реверс пока самолет еще летит (хотя вроде в советское время так делали для быстрого сброса скорости, но сейчас это запрещено), если дают полный газ на полосе — надо разгоняться и взлетать (возможно это уход на второй круг). Но в целом — катастрофа практически на ровном месте. Чтобы этого не допускать и нужны люди, но они бывает ошибаются и не справляются.
                • 0
                  И каждый раз автоматика (для своего уровня) пытается сообщить об этом. Все помнят полет «bad angle»? Когда бортовая система госолила, что, мол, вы самолет чрезмерно довернули, так они еще добавили. На ютубе можно найти видео с модуляцией.
                • 0
                  В большинстве случаев не голос, а звук, который ещё надо распознать.
                  • 0
                    погуглите тему
                    • 0
                      Что погуглите? На тытрубах на том же 737 при отключении автопилота раздаётся характерный звук. Но при серьёзной запаре до него ли?
                  • 0
                    подавляющее большинство авиакатастроф происходит при взлете и посадке, где никакая «автоматика» не работает, это чисто ручной этап полета.
                    плюс стоит отметить, что до сих пор эксплуатируются самолеты, которые лишены этой автоматики (ту-154, ан-24 и пр.)
                • +1
                  DevOps это хорошо, но получается, что на разработчиков начинает сваливаться все — и поддержка и доставка приложения и куча задач, которые раньше лежали на плечах сисадминов
                  • 0
                    Дык правильный девопс — это когда разработчики и админы тесно сотрудничают, а не когда разрабы выполняют работу админов.
                  • +1
                    вспоминаю формулировку вакансии на должность системного администратора на странице Павла Дурова несколько лет назад, где одно из качеств было: высокая стрессоустойчивость.
                    • +14
                      Почему вы обсуждаете админа?
                      Давайте попробуем предположить что бы было, если бы были бекапы всех пяти уровней?
                      Бинго! Ничего! Потеря данных за время меньше часа и все. Никто бы ничего не узнал — обычное дело, как отключение питания или сбой оборудования и прочее. Пожурили админа, сделали выводы.

                      Если вся команда налажала настолько, что не работает ни один из 5 бекапов — пытаться все свалить на одного человека — типичное российское поведение хренового управления. Нормальный управленец понимает, что проблема в организации резервирования, а не в хреновом админе просто потому, что при таком отношении к бэкапам такая ситуация возникла бы неминуемо рано или поздно, ибо человеский фактор не искоренить.
                      • 0
                        Насчёт того, что никто бы ничего не узнал, не соглашусь. На посещаемых сервисах народу много, данные обновляются часто.
                        А оргвыводы наверняка тоже сделаны, но внутри команды. И бэкапы теперь наверняка они будут проверять.
                      • +1
                        Мое мнение что админ не сделал бы rm. Админ бы переименовал каталог. Просто на всякий случай. Из за той самой паранойи.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            переименовывают удаленную папку
                            • 0
                              А удаленную мамку или бабку?
                              В серверных системах есть директории(directory), а мамки с папками остались в запускалке игр.
                              • 0
                                Ой, не любишь ты ностальгию, так нельзя
                                • 0
                                  У меня не может быть ностальгии по запускалке игр, я со Спектрума пересел сразу на первый Пень с FreeBSD.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0

                                    Забавно, что из английского оно заимствовано во второй раз с новым смыслом; в первый раз, как структура власти — латинизм (в начале 20 века).

                                    • НЛО прилетело и опубликовало эту надпись здесь
                                    • 0

                                      Чем заимствование из греческого лучше чем заимствование из английского? Просто более ранней датой? :)

                                      • 0

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


                                        Вспомнилась шутка про языковой барьер в современном рунете:
                                        — Превед!
                                        — Дратути!.

                                        • НЛО прилетело и опубликовало эту надпись здесь
                                        • –4
                                          Вот когда будете создавать православную и домотканную ПравОС для православных досчатых компьютеров на единичной логике, тогда можете хоть каталогами называть, хоть поповским домиком. А пока есть директории и ничего с этим не поделаешь.
                            • +14
                              Разработчик с рутовым доступом к боевому серверу, который по ночам чинит репликацию постгреса — действительно странно…

                              Может быть, это не DevOps, а просто раздолбайство?
                              • +9
                                от @Бобук
                                На волне всеобщего увлечения devops'изацией, в куче компаний решили что админы не нужны, и управлением серверами могут заниматься сами разработчики. Могут, но неплохо бы думать научиться, чтобы небыло как с GitLab: один разработчик случайно удаляет продакшн базу данных, перепутав сервера. И тут выясняется, что бэкапы есть, но восстановить из них ничего нельзя. В общем поучительная история.

                                Они думали что devops'изация избавит от раздолбайства.
                                • +7
                                  А DevOps не подразумевает наличие DevOps-инженеров, которые те же самые опытные админы, но нацелены на всеобщее единение и лучше разбираются в разработке софта?
                                  • 0
                                    Не всегда.
                                    • +9
                                      Верно, вон вверху висит вакансия от компании-автора блога, там предлагают 55 тыс руб. за DevOps админа.
                                      Учитывая, что DevOps это админ с сильным dev бэкграундом или дев с хорошим админ. бэкграундом, мне кажется, что пока нет понимания, что такой специалист редок и стоит дорого, а за 55 тыс. можно разве что «удалителя данных» нанять.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        • –1
                                          Это точно не парадигма разработки ПО. DevOps не рассказывает, как делать ПО и уж точно не организует межкомандное взаимодействие, скорее, это подход к управлению этим ПО — от взаимодействия разных частей и компонентов до средств доставки и развертывания. Грубо говоря, это сплав девелопера и админа, о чем я и говорил в предыдущем сообщении. ДевОпс должен одинаково хорошо понимать как девелоперские задачи уровня архитектуры и связности, так и администрирования, типа развертывания инфрастуктуры и процесса эксплуатации этой инфраструктуры.
                                          Это лично мое мнение, как человека, более двух лет занимающегося именно DevOps — от создания IaaC и стека мониторинг\логгирование до небольших служебных программ, обеспечивающих связность компонент или облегчающих работу разработчиков.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • +1
                                              Не согласен. Строить процессы это не работа DevOps. Это работа менеджеров.
                                              И никакой проблемы я не вижу, на самом деле, я опустил QA потому, что тестирование это часть разработки ПО.

                                              А вот создание системы, включающей как автоматическую сборку-тестирование-доставку-постдоставочное тестирование — это как раз задача DevOps. Упрощенно говоря, задача DevOps заключается в том числе и в создании системы, где разработчики сфокусированы именно на разработке, тестеры на тестировании, а админы — на администрировании сетей и железа.
                                              Чтобы девелопер мог нажать кнопочку и его приложение собралось, отттестировалось, развернулось, прошло интеграционные тесты, включилось в мониторинг и начало работать, а если где-то ошибка, то произошел автоматический откат к рабочей версии с общением кому надо.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                • 0
                                                  Ссылки ссылками, но, как выяснилось, каждый понимает это по-своему. Кто-то считает, что девопс это менеджер, огранизовывающий межкомандное взаимодействие. Кто-то — что это мегапрограммер, говорящий как писать ПО.

                                                  Различия в дефинициях — это нормально, идет процесс понимания вообще сути девопс.

                                                  Вот даже ваша ссылка на вики говорит:

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

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

                                                  И да, процесс описанный выше существовал и раньше, но был разбит на куски и эти куски делались разными людьми или отделами и большая часть времени уходила как раз на то, чтобы выяснить, почему на тест-окружении все OK, а на продакшене не OK. Раньше деплоем занимался разработчик, запуском тестов — тестер, а изменением маршрутов к задеплоеному — админ. Сейчас все делается автоматически и ошибок на порядок меньше из-за автоматизации, унификации окружения и нет паники типа «о боже, у нас полетели два боевых сервера, это два дня на настройку у вечно занятого админа». Теперь развертывание инфрастуктуры и всех приложений с нуля занимает порядка двух часов, может быть проведена как разработчиком, так и админом и сама инфрастуктура перестает быть ценностью — работа сфокусирована именно на ПО.

                                                  Если интересно — могу рассказать, что за задачи пришлось решать в рамках работы DevOps, если нет и вы настаиваете на книжном-вики-крутаякомпания варианте — можете смело ставить минус и забыть о моем сообщении )

                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                    • +1
                                                      Угу, вот как раз, наверное, в статье и описана «нормальная компания», где человек вручную базы удаляет.

                                                      Я вот в упор не вижу различий между вашим описанием видения девопс и моим, ну кроме «построения процессов и коммуникаций» потому что это ну точно не девопс, а менеджмент. И не везде есть автоматизация, не везде ci/cd и не везде все это грамотно интегрировано в инфраструктуру, а задача девопса как раз решать такие задачи по интеграции. И это таки требует серьезных знаний в админ части и в дев части, но никак не менеджмента команд. И девопс как раз создает нормально построенный процесс не столько разработки, сколько эксплуатации ПО и средств его доставки и мониторинга.

                                                      Имхо, это выходит за рамки компетенции как девелоперов так и админов, и ничего плохого в том, что такие специалисты стоят дороже рядовых админов или девов нет. Время покажет, просто это модное слово и хайп скоро стихнет, или это процесс эволюции ИТ профессий.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • +1
                                                          Честно говоря, не представлю себе девопса, строящего коммуникации между командами или организовывающего разработку ПО, поэтому да — у каждого свое мнение и это даже хорошо.

                                                          Спасибо за продуктивный диалог )
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • +1
                                                              Я отталкиваюсь от того, что девопс это человек-интегратор (если речь идет о позиции), использующий определенные подходы и практики для существенного облегчения и унификации задач на стыке админ и девелопер. В принципе, между нашими вариантами не так много различий, единственное, что меня смутило — «парадигма разработки программного обеспечения», честно говоря, слабо представляю себе девопса, командующего девелоперами и говорящего им как делать ПО. Сам процесс разработки ПО может быть отвратительным, а девопс решения — грамотными и эти сущности слабо пересекаются. Имхо, опять же.
                                            • +3
                                              Грубо говоря, это сплав девелопера и админа, о чем я и говорил в предыдущем сообщении. ДевОпс должен одинаково хорошо понимать как девелоперские задачи уровня архитектуры и связности, так и администрирования, типа развертывания инфрастуктуры и процесса эксплуатации этой инфраструктуры.


                                              Вот откуда взялось, что девопс — это человек?
                                              • 0
                                                Извините, пропущено слово «инженер». Для краткости.
                                      • +5
                                        Возможно я не до конца понимаю суть DevOps, но мне кажется что это явление вообще не подразумевает существование людей с подобными должностями. Как по мне, DevOps — это нечто вроде религии, взаимоотношения между Dev и Ops. А в случае ребят из GitLab — у них похоже роль Ops возложена на Dev
                                        • +2
                                          вот именно, википедия отлично описывает данный процесс, https://ru.wikipedia.org/wiki/DevOps. А то уже устал читать, что это чудо человек, сочитающий в себе и разработчика и админа и бога, что уж таить.
                                          • 0
                                            А в случае ребят из GitLab — у них похоже роль Ops возложена на Dev


                                            Вот и доигрались. История человечества учит, что специализация — это круто, но некоторые предпочитают учиться на своих ошибках.
                                    • +9
                                      Не в ту консоль вбить команду, совершил бы кто угодно.
                                      А вот не проверять «5 разных видов бекапов» до такой степени что ни один из них как оказалось бекапом не был, вот это да.
                                      • +2
                                        Я, когда за этой историей следил, точно так же и подумал. Мне только кажется самая большая ошибка это не то что developer удалил базу не на том сервере, а то что компания с USD 20 mln инвестиций не потрудилась обеспечить отказоустойчивость сервиса и не проработали детальный Disaster Recovery план с соответствующими RTO и RPO и обязательным тестированием процесса восстановления.
                                        • 0
                                          Disaster Recovery план? Не, не слышали)
                                          • +7
                                            • Регулярные бэкапы, похоже, также делались только раз в сутки...
                                            • SH: Похоже, что pg_dump работает неправильно, поскольку...
                                            • Снимки дисков в Azure включены для NFS-сервера, для серверов баз данных — нет.
                                            • Процедура репликации оказалось очень хрупкой...
                                            • SH: Мы позже выяснили, что...
                                            • Наши S3-бэкапы также не работают: папка пуста.
                                            • У нас нет надежной системы оповещений о неудачных попытках создания бэкапов...


                                            Глазам не верю — это точно GitLab? Не VasilyPupkinMegaBestCloudHosting Ltd. с полутора серверами?
                                            Серьезная компания мирового уровня, да, вне всяких сомнений.

                                            Вся статья проникнута сочуствием и уважением «к открытости», и это по-человечески понятно, но давайте называть вещи своими именами — это полный бардак, запредельный. И если бы не эта «роковая случайность», оно могло бы стрельнуть позже с куда более крутыми последствиями. Повезло везунчикам.

                                            P.S. Ниже в комментах говорят об увеличении лояльности к компании по причине их той самой открытости. Чудеса. Вы собираетесь им свои данные доверять или их няшные портреты на стенку вешать? Вроде как первое, а что до портретов, то можно найти и по-няшнее. Просто осмыслите факт — люди работали годами без бэкапов и зашевелились на эту тему только сейчас, когда выстрелили себе в ногу. Просто представьте себе образ мышления этих людей. Представили? Нравится? Няшно? Жесть.
                                            • 0

                                              Поясню пару моментов от лица ГитЛаба.


                                              Чтобы вы понимали, для ГитЛаба GitLab.com с точки зрения бизнеса — совсем не основное направление. Деньги компания зарабатывает на продаже Enterprise-лицензий.


                                              Приятно слышать что вы считаете GitLab компанией мирового уровня, но не стоит забывать что это очень молодая компания, и за год компании пришлось вырасти с 25 человек до 160.


                                              Да, слишком поздно обратили внимание на то с какой скоростью растет бесплатный GitLab.com, из-за этого и проблемы со скоростью сервиса, и вот это.


                                              Открытость в данном случае — это не оправдание, а гарантия что проблема будет преодолена и такой фигни больше не случится.

                                              • +2
                                                Спасибо за пояснения. Но каждый, наверное, уже сделал свои выводы. Из этих 160-ти человек должен был найтись хотя бы один, который бы сказал: «Эй, ребята, а что у нас с Disaster Recovery Plan? Он есть? Он работает?» — но не сказал. Или сказал, но его не услышали.
                                        • +4
                                          Ну, зато индексы перестроились, теперь всё будет работать побыстрее :)
                                          • +2
                                            По поводу перевода небольшое замечание: «frustration» в данном контексте корректнее переводить как «досада» или «раздражение». Т.е. на него не печаль накатила, и он пошёл чистить базу на диске на манер суицида, а просто слегка психанул.
                                            • 0
                                              Согласен, спасибо за замечание!
                                              • +12
                                                Можно ввести новый мед. термин «пост-постгрессовое стрессовое расстройство»
                                              • 0
                                                Ламерский вопрос:
                                                Что за ссылки на gitlab.slack.com? Предполагается, что к данной группе есть доступ(гостевой) у всех? Или только у тех, кто настраивал интеграцию Slack<->Gitlab?
                                                • 0
                                                  Думаю, туда доступ есть только у сотрудников GitLab. Они в открытую вели работу над инцидентом, но в опубликованный для всех документ добавляли ссылки и на закрытие ресурсы, чтобы им самим было удобно с ним работать.
                                                • +22
                                                  Твит от YP
                                                • +4
                                                  Манера изложения навевает тревожность, чем напоминает передачу
                                                  Секунды до катастрофы


                                                  Кстати мысль: начал бы кто снимать аналогичную, но с IT спецификой. Для начала можно выкладывать и на youtube. На декорации тратиться не надо — подойдёт любой офис. Главное хороших актёров найти.
                                                  Я бы посмотрел.
                                                  • 0
                                                    Передача, в которой происходящее будет понимать только узкий круг специалистов? Мне вот, некоторые вещи из статьи гуглить понадобилось. Как вы это в передачу засунете?

                                                    Если всё разжёвывать и объяснять — то спецам в области, в которой произошёл инцидент будет скучновато; если не объяснять ничего — то происходящие поймут единицы. Останавливать видео каждые 14 секунд и гуглить — тоже не вариант.
                                                    • –2
                                                      Рекомендую почитать Артура Хейли. Как ни странно, ему это удалось… А специфики в авиации не меньше…
                                                      • 0
                                                        Он писал книги о том, как чинился самолёт, и это было интересно читать как обычным людям, так и авио-механникам?
                                                    • +3
                                                      Сэм (админ): У нас упал интернет, я позвонил Дереку уточнить детали
                                                      Дерек (провайдер): Мне только что звонил Сэм, говорят у них упал интернет. С этим срочно нужно что то делать, каждая секунда на счету
                                                      Том (клиент): Сэм сказал что у них не работает интернет. Наша работа стоит. Я надеюсь это скоро исправят

                                                      Что то типа этого? )
                                                    • +3
                                                      Что-то подобное есть кстати

                                                    • 0
                                                      Читал с замиранием и просто физически ощущал напряжение и выбор метода сначала настройки репликации, а потом «лечения» нарастающих проблем.
                                                      На словах " YP начинает чувствовать безысходность" захотелось по советам Шелдона Капера предложить ему горячий напиток.
                                                      • +4
                                                        > Шелдона Капера
                                                        рукалицо.bmp
                                                        • 0
                                                          упс… говорила мне мама: перечитывай, сынок, после того, как набрал что-то на клавиатуре, не глядя :)
                                                          • +1
                                                            уровень потерь совершенно разный.

                                                            Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.

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

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

                                                            и с этим учетом 6 часов данных не очень большая потеря.

                                                            к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
                                                            • +1
                                                              Идея в том, что Гитлаб пытается продавать себя как сервис в том числе.
                                                              И здесь уже качество его работы с точки зрения стабильности тоже начинает играть роль.
                                                            • 0
                                                              Вот так наберешь однажды rm -rf
                                                            • +2
                                                              >рукалицо.bmp
                                                              рукалицо.jpeg
                                                              • +1
                                                                >рукалицо.jpeg
                                                                рукалицо.svg
                                                                • +8

                                                                  рукалицо.рукалицо ))

                                                                  • 0
                                                                    >рукалицо.svg
                                                                    рукалицо.3ds
                                                            • +1
                                                              Помнить, что даже самое тяжелое поражение можно превратить в победу.
                                                              Я не понимаю, где тут победа? Они сейчас потеряли лояльность клиентов. Представьте например, на месте GitLab — Сбербанк и потерю данных за 3 часа? Я думаю мы бы речи о победе не вели.
                                                              • +7
                                                                Кто то перестанет им верить, мне лично импонирует их открытость, признание проблем и юмор над самим собой.
                                                                Пожалуй они получили больше моей лояльности.
                                                                • 0
                                                                  Поддерживаю! Их, ИМХО, в такой ситуации нельзя сравнивать с тем же Сбербанком. Они не держат у себя денег других людей/компаний в отличии от Сбербанка.

                                                                  И да! Они абсолютные красавцы и молодцы в такой ситуации только за то, что подошли к этому инциденту с определенной долей юмора и решили преподнести этот фэйл не только как свой косяк, но и показали как выйти из такой ситуации. Показали слабые места.

                                                                  Короче говоря: эти ребята молодчики!
                                                                • +5

                                                                  Потому что Сбербанк бы всё засекретил и хрен бы что рассказал на публику, а не потому, что потерял бы данные. А тут всё правильно сделали. Не ошибается тот, кто ничего не делает.

                                                                  • +1
                                                                    Да ладно. Link
                                                                    • 0

                                                                      Возможно, я что-то упускаю, но сообщение в СМИ типа "Произошёл сбой в работе базы данных" никак не может являться примером публичности, а как раз подтверждает мою точку зрения "хрен бы что рассказали".

                                                                      • 0
                                                                        Выложили данные для анализа, привлекли помощь сообщества и рассказали технические подробности. Да процесс восстановления не стримили и внутренние документы не выкладывали.
                                                                        • +1

                                                                          По вашей ссылке не нашёл данных для анализа и технических подробностей. Из поста лишь ссылка на СМИ, не более того.


                                                                          История, судя по их пресс-релизам:


                                                                          6 июля 2012г сбой в работе:


                                                                          В связи с техническим сбоем не осуществляется обслуживание карт Сбербанка. ИТ-служба Сбербанка предпринимает все возможные меры для скорейшего устранения возникшей проблемы. Сбербанк приносит извинения своим клиентам за доставленные неудобства.

                                                                          6 июля, чуть позже:


                                                                          Сбербанк России сообщает о восстановлении обслуживания банковских карт.

                                                                          Обслуживание банковских карт Сбербанка было не доступно с 17:10 МСК в связи со сбоем в работе базы данных процессинга на платформе ORACLE. Перевод системы на резервный комплекс не дал ожидаемых результатов. В связи с этим было принято решение о начале процедуры Recovery (восстановления) базы данных. Из-за большого объема данных эта процедура занимает продолжительное время, однако гарантирует восстановление абсолютно всех клиентских данных и транзакций. Система была полностью восстановлена в 20:10 МСК.

                                                                          Сбербанк приносит клиентам свои искренние извинения за доставленные неудобства.

                                                                          13 (!) июля:


                                                                          Сбербанк создал краудсорсинговый ресурс для выявления причин технического сбоя в обслуживании банковских карт

                                                                          (видимо, тогда и выложили "данные для анализа"; сложно сказать, т.к. этот ресурс сейчас недоступен)


                                                                          То есть, неделя тишины, а потом (видимо, не выяснив самостоятельно?) они просят помощи у сообщества.


                                                                          Ну ок.


                                                                          И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.

                                                                          • –4
                                                                            — Ну, давай уже технические подробности!
                                                                            — Журнал повторного выполнения Oracle реализован в виде кольцевого буфера. В «голову» процесс LGWR пишет новые изменения в БД, а «хвост» подчищается процессом CKPT по мере того, как изменения, записанные в «хвосте» будут записаны процессами DBWn в файлы данных. «Голова» — это текущий (current) файл журнала, хвост — активные (active) файлы. Подчистка хвоста заключается в том, что журналы помечаются как пригодные к повторному использованию (inactive). Проблема состояла в том, что «подчистка» прекратилась, т.е. все файлы оперативного журнала стали активными, и экземпляру БД стало некуда записывать новые изменения.


                                                                            И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.

                                                                            Я думаю у GitLab — это тоже не единственный сбой, но по остальных они документы не выкладывают.
                                                                  • 0
                                                                    Да как-то нет. Зная масштаб конторки и предлагаемые ими условия, все взаимодействие с ними строится на основе того факта, что рано или поздно все это навернется. А основная клиентура у них на самом деле корпоративная, которая отваливает за standalone версию, то есть их эта кутерьма если и затронула, то опосредованно.
                                                                  • 0
                                                                    Читал как хронику «чернобыля», только со счастливым концом.
                                                                    • +3
                                                                      К сожалению, она ограничена 120 GB RAM и не потянет рабочую нагрузку.

                                                                      По-моему у них проблема не только с бэкапами
                                                                      • 0
                                                                        отличный пример для того, чтобы учиться на чужих ошибках и уже делать бэкапы (и проверять восстановление)
                                                                        • 0
                                                                          Все я фанат Ёрика, пойду базу грохну… поддержу так сказать )
                                                                          • 0
                                                                            Суровый админский флешмоб?
                                                                          • +1
                                                                            Они скорее всего просто хлопнули коньячку, и решили сыграть в админскую рулетку ;)

                                                                            [ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo «Alive!»
                                                                            • 0
                                                                              Без sudo не так интересно.
                                                                              • +1
                                                                                Админская рулетка играется под root'ом.
                                                                                • 0
                                                                                  Зашел с root'а — игра началась?
                                                                                  • +1
                                                                                    Ага, сразу в .bashrc прописывайте строку и игра будет начинаться при каждом заходе :)
                                                                                    • 0
                                                                                      Тогда строку надо дополнить таким вызовом:
                                                                                      echo "Я хочу сыграть с тобой в одну игру"
                                                                                      
                                                                              • –1
                                                                                Не сработает же.
                                                                                --no-preserve-root забыли, без него никак.
                                                                                • +2
                                                                                  Никто ничего не забыл и очень даже сработает, обратите внимание на то что там не "/" а "/*" (globbing)
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • 0
                                                                                  Логика подсказывает, что любой дополнительный уровень абстракции должен замедлять работу. Но умные люди в Интернете пишут, что в случае LVM это влияние пренебрежительно мало, и лишь в некоторых особых случаях может оказаться заметным. Согласен с Вами, похоже, что в статье о накладных расходах при использовании LVM не нужно было упоминать.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • +2
                                                                                  Человеческий фактор, друзья мои, это девайс который работает в «обе» стороны. поэтому, как написал автор — «5.Делать интерфейсы dev/stage/prod-серверов отличающимися друг от друга по цвету/формату.» пукт 5 хорошо освоили в МЧС. IT-шники пятый пункт часто недооценивают.
                                                                                  • 0
                                                                                    У нас имена серверов отличаются по буквам, serveru1, serverp2 — uat/prod.
                                                                                    + цветовая индикация. Прод сервер красного цвета, юат синего. Правда не на всех серверах есть цветовая индикация. Тем не менее 7 раз проверь, один раз удали должен работать на уровне рефлексов, я считаю.

                                                                                    Думаю второй раз YP этой ошибки не совершит :)
                                                                                  • +1
                                                                                    Должный уровень паранойи. Вот чего многим не хватает.
                                                                                    У меня вот ее через край, от чего тормозятся иногда даже банальные вещи, которые в принципе всегда non-disruptive.
                                                                                    • +1
                                                                                      Можете объяснить, с какой целью вы уродуете ссылки на источники, вставляя в них www.google.com, отчего мой браузер постоянно варнится на редиректы?
                                                                                      • 0
                                                                                        Оригинал статьи в docs.google.com, отсюда и редиректы
                                                                                        • 0
                                                                                          Google Docs, похоже, зачем-то вставляет во все ссылки редиректы. Спасибо за сообщение. Поправим.
                                                                                          • 0
                                                                                            Исправили.
                                                                                          • –2
                                                                                            По идее можно было бы восстановить и проекты и ишью и комменты из production.log. Погрепать по POST и взять params, и с них уже восстановить все, что было потеряно.
                                                                                            • –1
                                                                                              Думаю, будет не лишним сделать скрипт, который бы отображал администратору имя сервера (крсаненьким, мигающим) и запрос уверен ли он выполнить rm -rf. ну и намутить alias, чтобы по rm вызывался этот самый скрипт.
                                                                                              • –1

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

                                                                                                • 0
                                                                                                  Не сломает. bash -c «alias» не вызывает интерактивный шелл, а при запуске неинтерактивного шелла .bashrc и иже с ним игнорятся. К тому же, во многих системах, по-умолчанию для rm заведен алиас rm='rm -i'. Мигающая надпись добавит шансов, что администратор остановится.
                                                                                                  • 0

                                                                                                    Да, согласен, не сломает. Забыл как алиасы работают.


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

                                                                                                    • 0

                                                                                                      Так вроде бы разница между чайником и админом еще и в том, что последний сначала читает, что написано, а потом делает, а не наоборот. И не надо допускать чайников к администрированию важных серверов

                                                                                                      • 0

                                                                                                        Увы, но механизмы обучаемости и возникновения условных рефлексов — одни и те же. Вылезло окно — нажми "ОК" не читая. Загорелась мигающая надпись — нажми "y"...

                                                                                                        • 0
                                                                                                          rm -rf — это не та команда, которую администратор выполняет по несколько раз на дню.
                                                                                                          • +1

                                                                                                            Для борьбы с этим можно применять простой способ — подтверждение требует ввода слова, а само слово указано в тексте сообщения. Причем для разных серверов слово может быть разным. Что может спасти в ситуации "перепутал сервер".

                                                                                                            • 0
                                                                                                              поддержу, кстати. Эти словом может быть имя сервера, например.
                                                                                                              • 0
                                                                                                                Ну да. Например для того, что бы случайно не ребутнуть не тот сервер есть molly-guard, который подменяет собой команды reboot и shutdown и спрашивает имя хоста при попытке сделать их по ssh. Очень хорошо помогает в качестве защиты от случайного ребута.
                                                                                                • +1
                                                                                                  По-моему, такая открытость — это просто популистская попытка прикрыть собственную безалаберность (я про компанию).
                                                                                                  • 0

                                                                                                    Похоже, что открытость у них в крови. Вполне возможно, что там даже не было обсуждения уровня освещения инцидента и какого-то процесса принятия решения о том, чтобы отрабатывать это событие в открытую. Они просто всегда так работают.


                                                                                                    Вот их ценности, в число которых входит "Transparency".


                                                                                                    Там написано следующее: "everything at GitLab is public by default", т. е. они публичны по умолчанию.

                                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                  Самое читаемое