Он пьянел медленно, но все-таки опьянел, как-то сразу, скачком; и когда в минуту просветления увидел перед собой разрубленный дубовый стол в совершенно незнакомой комнате, обнаженный меч в своей руке и рукоплещущих безденежных донов вокруг, то подумал было, что пора идти домой. Но было поздно.
Аркадий и Борис Стругацкие
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 — следите за тем, как мы обсуждаем и решаем проблему!
- Понесенные потери
- Хронология (время указано в UTC)
- Восстановление — 2017/01/31 23:00 (бэкап от примерно 17:20 UTC)
- Возникшие проблемы
- Помощь со стороны
- HugOps (добавляйте здесь посты из twitter и откуда-либо еще, в которых люди по-доброму реагировали на случившееся)
- Stephen Frost
- Sam McLeod
Понесенные потери
- Потеряны данные примерно за 6 часов.
- Потеряно 4613 обычных проектов, 74 форка и 350 импортов (грубо); всего 5037. Поскольку Git-репозитории НЕ потеряны, мы сможем воссоздать те проекты, пользователи/группы которых существовали до потери данных, но не сможем восстановить задачи (issues) этих проектов.
- Потеряно около 4979 (можно сказать, около 5000) комментариев.
- Потенциально потеряно 707 пользователей (сложно сказать точнее по логам Kibana).
- Веб-хуки, созданные до 31 января 17:20, восстановлены, созданные после — потеряны.
Хронология (время указано в UTC)
- 2017/01/31 16:00/17:00 — 21:00
- YP работает над настройкой pgpool и репликацией в staging, создает LVM-снимок, чтобы загрузить боевые данные в staging, а также в надежде на то, что сможет использовать эти данные для ускорения загрузки базы на другие реплики. Это происходит примерно за 6 часов до потери данных.
- Настройка репликации оказывается проблематичной и очень долгой (оценочно ~20 часов только на начальную синхронизацию pg_basebackup). LVM-снимок YP использовать не смог. Работа на этом этапе была прервана (так как YP была нужна помощь другого коллеги, который в тот день не работал, а также из-за спама/высокой нагрузки на GitLab.com).
- 2017/01/31 21:00 — Всплеск нагрузки на сайт из-за спамеров — Twitter | Slack
- Блокирование пользователей по их IP-адресам.
- Удаление пользователя за использование репозитория в качестве CDN, в результате чего 47 000 айпишников залогинились под тем же аккаунтом (вызвав высокую нагрузку на БД). Информация была передана командам технической поддержки и инфраструктуры.
- Удаление пользователей за спам (с помощью создания сниппетов) — Slack
- Нагрузка на БД вернулась к норме, вручную запущен vacuum нескольких таблиц PostgreSQL, чтобы почистить большое количество оставшихся пустых строк.
- 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 по местному времени), но остался на месте по причине неожиданно возникших проблем с репликацией.
- 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)
- Предложенные способы восстановления:
- Смигрировать db1.staging.gitlab.com на GitLab.com (отставание около 6 часов).
- CW: Проблема с веб-хуками, которые были удалены во время синхронизации.
- Восстановить LVM-снимок (отстает на 6 часов).
- 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. Хорошие новости заключаются в том, что данные вплоть до этого момента выглядят нетронутыми, поэтому мы, возможно, сможем восстановить веб-хуки.
- Смигрировать db1.staging.gitlab.com на GitLab.com (отставание около 6 часов).
- Предпринятые действия:
- 2017/02/01 23:00 — 00:00: Принято решение восстанавливать данные с db1.staging.gitlab.com на db1.cluster.gitlab.com (production). Несмотря на то, что они отстают на 6 часов и не содержат веб-хуков, это единственный доступный снимок. YP говорит, что ему сегодня лучше больше не запускать никаких команд, начинающихся с sudo, и передает управление JN.
- 2017/02/01 00:36 — JN: Делаю бэкап данных db1.staging.gitlab.com.
- 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/.
- 2017/02/01 01:05 — JN: nfs-share01 сервер выделен в качестве временного хранилища в /var/opt/gitlab/db-meltdown.
- 2017/02/01 01:18 — JN: Копирую оставшиеся production-данные, включая запакованный pg_xlog: ‘20170131-db-meltodwn-backup.tar.gz’.
- 2017/02/01 01:58 — JN: Начинаю синхронизацию из stage в production.
- 2017/02/01 02:00 — CW: Для объяснения ситуации обновлена страничка развертывания (deploy page). Link.
- 2017/02/01 03:00 — AR: rsync выполнился примерно на 50% (по количеству файлов).
- 017/02/01 04:00 — JN: rsync выполнился примерно на 56.4% (по количеству файлов). Передача данных идет медленно по следующим причинам: пропускная способность сети между us-east и us-east-2, а также ограничение производительности диска на staging-сервере (60 Mb/s).
- 2017/02/01 07:00 — JN: Нашел копию нетронутых данных на db1 staging в /var/opt/gitlab_replicator/postgresql. Запустил виртуальную машину db-crutch VM на us-east, чтобы сделать бэкап этих данных на другую машину. К сожалению, она ограничена 120 GB RAM и не потянет рабочую нагрузку. Эта копия будет использована для проверки состояния базы данных и выгрузки данных веб-хуков.
- 2017/02/01 08:07 — JN: Передача данных идет медленно: по объему данных передано 42%.
- 2017/02/02 16:28 — JN: Передача данных закончилась.
- 2017/02/02 16:45 — Ниже приведена процедура восстановления.
- Процедура восстановления
- [x] — Сделать снимок сервера DB1 — или 2 или 3 — сделано в 16:36 UTC.
- [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).
- [x] — Запустить DB — 16:53 UTC
- Мониторить запуск и убедиться, что все прошло нормально.
- Сделать бэкап.
- [x] — Обновить Sentry DSN, чтобы ошибки не попали в staging.
- [x] — Увеличить идентификаторы во всех таблицах на 10k, чтобы избежать проблем при создании новых проектов/замечаний. Выполнено с помощью https://gist.github.com/anonymous/23e3c0d41e2beac018c4099d45ec88f5, который читает текстовый файл, содержащий все последовательности (по одной на строку).
- [x] — Очистить кеш Rails/Redis.
- [x] — Попытаться по возможности восстановить веб-хуки.
- [x] Запустить staging, используя снимок, сделанный до удаления веб-хуков.
- [x] Убедиться, что веб-хуки на месте.
- [x] Создать SQL-дамп (только данные) таблицы “web_hooks” (если там есть данные).
- [x] Скопировать SQL-дамп на production-сервер.
- [x] Импортировать SQL-дамп в рабочую базу.
- [x] — Проверить через Rails Console, могут ли подключаться рабочие процессы (workers).
- [x] — Постепенно запустить рабочие процессы.
- [x] — Отключить страницу развертывания.
- [x] — Затвитить с @gitlabstatus.
- [x] — Создать связанные со сбоем задачи, описывающие дальнейшие планы/действия Скрытый текст
- https://gitlab.com/gitlab-com/infrastructure/issues/1094
- https://gitlab.com/gitlab-com/infrastructure/issues/1095
- https://gitlab.com/gitlab-com/infrastructure/issues/1096
- https://gitlab.com/gitlab-com/infrastructure/issues/1097
- https://gitlab.com/gitlab-com/infrastructure/issues/1098
- https://gitlab.com/gitlab-com/infrastructure/issues/1099
- https://gitlab.com/gitlab-com/infrastructure/issues/1100
- https://gitlab.com/gitlab-com/infrastructure/issues/1101
- https://gitlab.com/gitlab-com/infrastructure/issues/1102
- https://gitlab.com/gitlab-com/infrastructure/issues/1103
- https://gitlab.com/gitlab-com/infrastructure/issues/1104
- https://gitlab.com/gitlab-com/infrastructure/issues/1105
[ ] — Создать новые записи Project Git-репозиториев, у которых нет записей Project, в случаях, когда пространство имен соответствует существующему пользователю/группе.
- PC —
Я создаю список этих репозиториев, чтобы мы могли проверить в базе данных, существуют ли они.
[ ] — Удалить репозитории с неизвестными (потерянными) пространствами имен.
- AR — работаю над скриптом, основанным на данных с предыдущей точки.
[x] — Еще раз удалить спам-пользователей (чтобы они снова не создали проблем).
- [x] CDN-пользователь с 47 000 IP-адресами.
- Сделать после восстановления данных:
- Создать задачу на изменение в терминалах PS1-формата/цветов, чтобы было сразу понятно, какая среда используется: production или staging (production — красный, staging — желтый). Для всех пользователей по умолчанию в приглашении bash показывать полное имя хоста (например, “db1.staging.gitlab.com” вместо “db1”): https://gitlab.com/gitlab-com/infrastructure/issues/1094
- Как-нибудь запретить rm -rf для директории data PostgreSQL? Не уверен, что это выполнимо или необходимо (в том случае, если есть нормальные бэкапы).
- Добавить оповещения для бэкапов: проверка хранилища S3 и т. д. Добавить график, показывающий изменения размеров бэкапов, выдавать предупреждение, когда размер уменьшается более чем на 10%: https://gitlab.com/gitlab-com/infrastructure/issues/1095.
Рассмотреть добавление времени последнего успешного бэкапа в БД, чтобы админы могли легко увидеть эту информацию(предложено клиентом в https://gitlab.zendesk.com/agent/tickets/58274).- Разобраться, почему у PostgreSQL внезапно возникли проблемы с max_connections, установленным в 8000, несмотря на то, что это работало с 2016-05-13. Неожиданное появление этой проблемы во многом ответственно за навалившиеся отчаяние и безысходность: https://gitlab.com/gitlab-com/infrastructure/issues/1096.
- Посмотреть на увеличение порогов репликации через архивацию WAL / PITR — также будет полезно после неудачных обновлений: https://gitlab.com/gitlab-com/infrastructure/issues/1097.
- Создать для пользователей руководство по решению проблем, которые могут возникнуть после запуска сервиса.
- Поэкспериментировать с перемещением данных из одного дата-центра в другой с помощью AzCopy: Microsoft говорит, что это должно работать быстрее rsync:
- Похоже, это Windows-специфичная вещь, а у нас нет экспертов по Windows (или кого-то хотя бы отдаленно, но в достаточной степени знакомого с вопросом, чтобы грамотно это протестировать).
Возникшие проблемы
- LVM-снимки по умолчанию делаются лишь один раз в 24 часа. По счастливой случайности YP за 6 часов до сбоя сделал один вручную.
- Регулярные бэкапы, похоже, также делались только раз в сутки, хотя YP еще не выяснил, где они хранятся. Согласно JN они не работают: создаются файлы размером в несколько байт.
- SH: Похоже, что pg_dump работает неправильно, поскольку выполняются бинарники от PostgreSQL 9.2 вместо 9.6. Это происходит из-за того, что omnibus использует только Pg 9.6, если data/PG_VERSION установлено в 9.6, но на рабочих узлах этого файла нет. В результате по умолчанию запускается 9.2 и тихо завершается, ничего не сделав. В итоге SQL-дампы не создаются. Fog-гем, возможно, вычистил старые бэкапы.
- Снимки дисков в Azure включены для NFS-сервера, для серверов баз данных — нет.
- Процесс синхронизации удаляет веб-хуки после того, как он синхронизировал данные на staging. Если мы не сможем вытащить их из обычного бэкапа, сделанного в течение 24 часов, они будут потеряны.
- Процедура репликации оказалось очень хрупкой, склонной к ошибкам, зависящей от случайных shell-скриптов и плохо документированной.
- SH: Мы позже выяснили, что обновление базы данных staging работает путем создания снимка директории gitlab_replicator, удаления конфигурации репликации и запуска отдельного PostgreSQL-сервера.
- Наши S3-бэкапы также не работают: папка пуста.
- У нас нет надежной системы оповещений о неудачных попытках создания бэкапов, мы теперь видим такие же проблемы и на dev-хосте.
Другими словами, из 5 используемых способов бэкапа/репликации ни один не работает. => сейчас мы восстанавливаем рабочий бэкап, сделанный 6 часов назад.
http://monitor.gitlab.net/dashboard/db/postgres-stats?panelId=10&fullscreen&from=now-24h&to=now
Помощь со стороны
Hugops (добавляйте здесь посты из twitter или откуда-то еще, в которых люди по-доброму реагировали на случившееся)- A Twitter Moment for all the kind tweets: https://twitter.com/i/moments/826818668948549632
- Jan Lehnardt https://twitter.com/janl/status/826717066984116229
- Buddy CI https://twitter.com/BuddyGit/status/826704250499633152
- Kent https://twitter.com/kentchenery/status/826594322870996992
- Lead off https://twitter.com/LeadOffTeam/status/826599794659450881
- Mozair https://news.ycombinator.com/item?id=13539779
- Applicant https://news.ycombinator.com/item?id=13539729
- Scott Hanselman https://twitter.com/shanselman/status/826753118868275200
- Dave Long https://twitter.com/davejlong/status/826817435470815233
- Simon Slater https://twitter.com/skslater/status/826812158184980482
- Zaim M Ramlan https://twitter.com/zaimramlan/status/826803347764043777
- Aaron Suggs https://twitter.com/ktheory/status/826802484467396610
- danedevalcourt https://twitter.com/danedevalcourt/status/826791663943241728
- Karl https://twitter.com/irutsun/status/826786850186608640
- Zac Clay https://twitter.com/mebezac/status/826781796318707712
- Tim Roberts https://twitter.com/cirsca/status/826781142581927936
- Frans Bouma https://twitter.com/FransBouma/status/826766417332727809
- Roshan Chhetri https://twitter.com/sai_roshan/status/826764344637616128
- Samuel Boswell https://twitter.com/sboswell/status/826760159758262273
- Matt Brunt https://twitter.com/Brunty/status/826755797933756416
- Isham Mohamed https://twitter.com/Isham_M_Iqbal/status/826755614013485056
- Adria Galin https://twitter.com/adriagalin/status/826754540955377665
- Jonathan Burke https://twitter.com/imprecision/status/826749556566134784
- Christo https://twitter.com/xho/status/826748578240544768
- Linux Australia https://twitter.com/linuxaustralia/status/826741475731976192
- Emma Jane https://twitter.com/emmajanehw/status/826737286725455872
- Rafael Dohms https://twitter.com/rdohms/status/826719718539194368
- Mike San Roman https://twitter.com/msanromanv/status/826710492169269248
- Jono Walker https://twitter.com/WalkerJono/status/826705353265983488
- Tom Penrose https://twitter.com/TomPenrose/status/826704616402333697
- Jon Wincus https://twitter.com/jonwincus/status/826683164676521985
- Bill Weiss https://twitter.com/BillWeiss/status/826673719460274176
- Alberto Grespan https://twitter.com/albertogg/status/826662465400340481
- Wicket https://twitter.com/matthewtrask/status/826650119042957312
- Jesse Dearing https://twitter.com/JesseDearing/status/826647439587188736
- Franco Gilio https://twitter.com/fgili0/status/826642668994326528
- Adam DeConinck https://twitter.com/ajdecon/status/826633522735505408
- Luciano Facchinelli https://twitter.com/sys0wned/status/826628970150035456
- Miguel Di Ciurcio F. https://twitter.com/mciurcio/status/826628765820321792
- ceej https://twitter.com/ceejbot/status/826617667884769280
Stephen Frost
- https://twitter.com/net_snow/status/826622954964393984 @gitlabstatus Привет, я разработчик PG, и мне нравится то, что вы делаете. Сообщите, если я могу чем-то помочь, я был бы рад оказаться полезен.
Sam McLeod
- Привет, Сид, очень жаль, что у вас проблемы с базой данных / LVM, это чертовски неприятно. У нас работает несколько кластеров PostgreSQL (master/slave), и я обратил внимание на несколько вещей в вашем отчете:
- Вы используете Slony, а это еще тот кусок сами знаете чего, и это совсем не преувеличение, тут вот даже смеются над ним http://howfuckedismydatabase.com, при этом встроенный бинарник PostgreSQL, отвечающий за потоковую репликацию, очень надежен и быстр, предлагаю переключиться на него.
- Не упоминается использование пулов соединений, зато говорится о тысячах соединений в postgresql.conf — это очень плохо и неэффективно с точки зрения производительности, предлагаю использовать pg_bouncer и не выставлять max_connection в PostgreSQL выше 512-1024; практически, если у вас больше 256 активных соединений, надо масшабироваться горизонтально, а не вертикально.
- В отчете говорится, насколько ненадежны ваши процессы отработки отказа и резервного копирования, мы написали и задокументировали простой скрипт для postgresql failover — если хотите, я его вам перешлю. Что касается бэкапов, то для инкрементных резервных копий в течение дня мы используем pgbarman, а также делаем полные бэкапы дважды в день с помощью barman и pg_dump, важно с точки зрения производительности и надежности хранить ваши бэкапы и директорию с данными postgresql на разных дисках.
- Вы все еще в 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/, а пользователи Хабра вспомнили чудесную тематическую картинку:
Какие можно сделать выводы?
- Нужно проверять бэкапы.
- Необходимо учитывать дополнительные трудности при восстановлении файлов в облаке (по крайней мере, в Azure).
- LVM — это не так уж и плохо, и его используют для размещения БД даже такие заметные компании, как GitLab.com, несмотря на потери в производительности.
- Не давать dev/stage/prod-серверам похожие названия.
- Делать интерфейсы dev/stage/prod-серверов отличающимися друг от друга по цвету/формату.
- Не бояться рассказать всему свету о своей ошибке — добрых людей больше, и они помогут.
- Помнить, что даже самое тяжелое поражение можно превратить в победу.
Ссылки по теме:
- Оригинал документа: GitLab.com Database Incident — 2017/01/31: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
- Сообщение в блоге GitLab.com: https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
- Первая статья на Хабре: https://habrahabr.ru/post/320988/
Комментарии (121)
ksenobayt
03.02.2017 10:45+2По поводу перевода небольшое замечание: «frustration» в данном контексте корректнее переводить как «досада» или «раздражение». Т.е. на него не печаль накатила, и он пошёл чистить базу на диске на манер суицида, а просто слегка психанул.
lightman
03.02.2017 11:23+12Можно ввести новый мед. термин «пост-постгрессовое стрессовое расстройство»
arandomic
03.02.2017 10:55Ламерский вопрос:
Что за ссылки на gitlab.slack.com? Предполагается, что к данной группе есть доступ(гостевой) у всех? Или только у тех, кто настраивал интеграцию Slack<->Gitlab?
gekk0
03.02.2017 11:19Думаю, туда доступ есть только у сотрудников GitLab. Они в открытую вели работу над инцидентом, но в опубликованный для всех документ добавляли ссылки и на закрытие ресурсы, чтобы им самим было удобно с ним работать.
yjurfdw
03.02.2017 10:58+22lightman
03.02.2017 11:02+4Манера изложения навевает тревожность, чем напоминает передачу
Секунды до катастрофы
Shultc
03.02.2017 13:21Передача, в которой происходящее будет понимать только узкий круг специалистов? Мне вот, некоторые вещи из статьи гуглить понадобилось. Как вы это в передачу засунете?
Если всё разжёвывать и объяснять — то спецам в области, в которой произошёл инцидент будет скучновато; если не объяснять ничего — то происходящие поймут единицы. Останавливать видео каждые 14 секунд и гуглить — тоже не вариант.
Jef239
03.02.2017 14:31-2Рекомендую почитать Артура Хейли. Как ни странно, ему это удалось… А специфики в авиации не меньше…
Shultc
03.02.2017 14:35Он писал книги о том, как чинился самолёт, и это было интересно читать как обычным людям, так и авио-механникам?
Delphinum
03.02.2017 13:49+3Сэм (админ): У нас упал интернет, я позвонил Дереку уточнить детали
Дерек (провайдер): Мне только что звонил Сэм, говорят у них упал интернет. С этим срочно нужно что то делать, каждая секунда на счету
Том (клиент): Сэм сказал что у них не работает интернет. Наша работа стоит. Я надеюсь это скоро исправят
Что то типа этого? )
tentakle
03.02.2017 18:17+3Что-то подобное есть кстати
boloto
03.02.2017 11:05Читал с замиранием и просто физически ощущал напряжение и выбор метода сначала настройки репликации, а потом «лечения» нарастающих проблем.
На словах " YP начинает чувствовать безысходность" захотелось по советам Шелдона Капера предложить ему горячий напиток.ksenobayt
03.02.2017 11:06+4> Шелдона Капера
рукалицо.bmpboloto
03.02.2017 11:20упс… говорила мне мама: перечитывай, сынок, после того, как набрал что-то на клавиатуре, не глядя :)
rekby
03.02.2017 11:39+1уровень потерь совершенно разный.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.ksenobayt
03.02.2017 11:54+1Идея в том, что Гитлаб пытается продавать себя как сервис в том числе.
И здесь уже качество его работы с точки зрения стабильности тоже начинает играть роль.
caban
03.02.2017 11:29+1Помнить, что даже самое тяжелое поражение можно превратить в победу.
Я не понимаю, где тут победа? Они сейчас потеряли лояльность клиентов. Представьте например, на месте GitLab — Сбербанк и потерю данных за 3 часа? Я думаю мы бы речи о победе не вели.
Sergey-S-Kovalev
03.02.2017 11:39+7Кто то перестанет им верить, мне лично импонирует их открытость, признание проблем и юмор над самим собой.
Пожалуй они получили больше моей лояльности.
JTProg
03.02.2017 12:48Поддерживаю! Их, ИМХО, в такой ситуации нельзя сравнивать с тем же Сбербанком. Они не держат у себя денег других людей/компаний в отличии от Сбербанка.
И да! Они абсолютные красавцы и молодцы в такой ситуации только за то, что подошли к этому инциденту с определенной долей юмора и решили преподнести этот фэйл не только как свой косяк, но и показали как выйти из такой ситуации. Показали слабые места.
Короче говоря: эти ребята молодчики!
norlin
03.02.2017 12:04+5Потому что Сбербанк бы всё засекретил и хрен бы что рассказал на публику, а не потому, что потерял бы данные. А тут всё правильно сделали. Не ошибается тот, кто ничего не делает.
caban
03.02.2017 12:12+1Да ладно. Link
norlin
03.02.2017 12:20Возможно, я что-то упускаю, но сообщение в СМИ типа "Произошёл сбой в работе базы данных" никак не может являться примером публичности, а как раз подтверждает мою точку зрения "хрен бы что рассказали".
caban
03.02.2017 12:23Выложили данные для анализа, привлекли помощь сообщества и рассказали технические подробности. Да процесс восстановления не стримили и внутренние документы не выкладывали.
norlin
03.02.2017 12:46+1По вашей ссылке не нашёл данных для анализа и технических подробностей. Из поста лишь ссылка на СМИ, не более того.
История, судя по их пресс-релизам:
6 июля 2012г сбой в работе:
В связи с техническим сбоем не осуществляется обслуживание карт Сбербанка. ИТ-служба Сбербанка предпринимает все возможные меры для скорейшего устранения возникшей проблемы. Сбербанк приносит извинения своим клиентам за доставленные неудобства.
6 июля, чуть позже:
Сбербанк России сообщает о восстановлении обслуживания банковских карт.
Обслуживание банковских карт Сбербанка было не доступно с 17:10 МСК в связи со сбоем в работе базы данных процессинга на платформе ORACLE. Перевод системы на резервный комплекс не дал ожидаемых результатов. В связи с этим было принято решение о начале процедуры Recovery (восстановления) базы данных. Из-за большого объема данных эта процедура занимает продолжительное время, однако гарантирует восстановление абсолютно всех клиентских данных и транзакций. Система была полностью восстановлена в 20:10 МСК.
Сбербанк приносит клиентам свои искренние извинения за доставленные неудобства.13 (!) июля:
Сбербанк создал краудсорсинговый ресурс для выявления причин технического сбоя в обслуживании банковских карт
(видимо, тогда и выложили "данные для анализа"; сложно сказать, т.к. этот ресурс сейчас недоступен)
То есть, неделя тишины, а потом (видимо, не выяснив самостоятельно?) они просят помощи у сообщества.
Ну ок.
И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.
caban
03.02.2017 13:10-4— Ну, давай уже технические подробности!
— Журнал повторного выполнения Oracle реализован в виде кольцевого буфера. В «голову» процесс LGWR пишет новые изменения в БД, а «хвост» подчищается процессом CKPT по мере того, как изменения, записанные в «хвосте» будут записаны процессами DBWn в файлы данных. «Голова» — это текущий (current) файл журнала, хвост — активные (active) файлы. Подчистка хвоста заключается в том, что журналы помечаются как пригодные к повторному использованию (inactive). Проблема состояла в том, что «подчистка» прекратилась, т.е. все файлы оперативного журнала стали активными, и экземпляру БД стало некуда записывать новые изменения.
И это при том, что данный сбой был далеко не единственным у Сбера, однако по другим случаям – вообще тишина.
Я думаю у GitLab — это тоже не единственный сбой, но по остальных они документы не выкладывают.
lpwaterhouse
03.02.2017 21:40Да как-то нет. Зная масштаб конторки и предлагаемые ими условия, все взаимодействие с ними строится на основе того факта, что рано или поздно все это навернется. А основная клиентура у них на самом деле корпоративная, которая отваливает за standalone версию, то есть их эта кутерьма если и затронула, то опосредованно.
le1ic
03.02.2017 12:48+3К сожалению, она ограничена 120 GB RAM и не потянет рабочую нагрузку.
По-моему у них проблема не только с бэкапами
breakoffbrain
03.02.2017 13:32отличный пример для того, чтобы учиться на чужих ошибках и уже делать бэкапы (и проверять восстановление)
vladadm
03.02.2017 14:04+1Они скорее всего просто хлопнули коньячку, и решили сыграть в админскую рулетку ;)
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo «Alive!»srbgd
03.02.2017 15:18Без sudo не так интересно.
Erelecano
03.02.2017 23:01-1Не сработает же.
--no-preserve-root забыли, без него никак.ghostinushanka
06.02.2017 00:45+2Никто ничего не забыл и очень даже сработает, обратите внимание на то что там не "/" а "/*" (globbing)
Scorry
03.02.2017 15:03> LVM — это не так уж и плохо, и его используют для размещения БД даже такие заметные компании, как GitLab.com, несмотря на потери в производительности.
О какой потере производительности идёт речь?gekk0
03.02.2017 16:16Логика подсказывает, что любой дополнительный уровень абстракции должен замедлять работу. Но умные люди в Интернете пишут, что в случае LVM это влияние пренебрежительно мало, и лишь в некоторых особых случаях может оказаться заметным. Согласен с Вами, похоже, что в статье о накладных расходах при использовании LVM не нужно было упоминать.
Scorry
03.02.2017 16:55Именно так. Я бы также уточнил, что замедление работы файловых операций поверху LVM возникает при создании снапшотов, особенно при неподходящем chunk size, но при обычной работе оверхед от LVM пренебрежимо мал, чтобы о нём вообще упоминать. В контексте новости упоминалось о снапшоте, но никто не говорил, как его использовали (я не читал тщательно первоисточник). Возможно, его использовали как суточный бэкап для отката — гадать не буду.
Timur_n
03.02.2017 15:24+2Человеческий фактор, друзья мои, это девайс который работает в «обе» стороны. поэтому, как написал автор — «5.Делать интерфейсы dev/stage/prod-серверов отличающимися друг от друга по цвету/формату.» пукт 5 хорошо освоили в МЧС. IT-шники пятый пункт часто недооценивают.
DJ-Glock
03.02.2017 17:15У нас имена серверов отличаются по буквам, serveru1, serverp2 — uat/prod.
+ цветовая индикация. Прод сервер красного цвета, юат синего. Правда не на всех серверах есть цветовая индикация. Тем не менее 7 раз проверь, один раз удали должен работать на уровне рефлексов, я считаю.
Думаю второй раз YP этой ошибки не совершит :)
mikkisse
03.02.2017 16:02+1Должный уровень паранойи. Вот чего многим не хватает.
У меня вот ее через край, от чего тормозятся иногда даже банальные вещи, которые в принципе всегда non-disruptive.
KriMs
03.02.2017 18:35-2По идее можно было бы восстановить и проекты и ишью и комменты из production.log. Погрепать по POST и взять params, и с них уже восстановить все, что было потеряно.
c3po
06.02.2017 11:49-1Думаю, будет не лишним сделать скрипт, который бы отображал администратору имя сервера (крсаненьким, мигающим) и запрос уверен ли он выполнить rm -rf. ну и намутить alias, чтобы по rm вызывался этот самый скрипт.
mayorovp
06.02.2017 12:45-1Глупость. Во-первых, это поломает скрипты. Во-вторых, любой "красненький, мигающий" запрос после пятого-десятого раза проходится автоматически, без участия мозга.
c3po
06.02.2017 13:14Не сломает. bash -c «alias» не вызывает интерактивный шелл, а при запуске неинтерактивного шелла .bashrc и иже с ним игнорятся. К тому же, во многих системах, по-умолчанию для rm заведен алиас rm='rm -i'. Мигающая надпись добавит шансов, что администратор остановится.
mayorovp
06.02.2017 13:23Да, согласен, не сломает. Забыл как алиасы работают.
Но мигающая надпись все равно будет админом обходиться без участия мозга, это уже проверено поколениями чайников, сломавших себе винду самыми странными способами.
Azoh
06.02.2017 13:32Так вроде бы разница между чайником и админом еще и в том, что последний сначала читает, что написано, а потом делает, а не наоборот. И не надо допускать чайников к администрированию важных серверов
mayorovp
06.02.2017 13:37Увы, но механизмы обучаемости и возникновения условных рефлексов — одни и те же. Вылезло окно — нажми "ОК" не читая. Загорелась мигающая надпись — нажми "y"...
c3po
06.02.2017 14:41rm -rf — это не та команда, которую администратор выполняет по несколько раз на дню.
Azoh
06.02.2017 14:46+1Для борьбы с этим можно применять простой способ — подтверждение требует ввода слова, а само слово указано в тексте сообщения. Причем для разных серверов слово может быть разным. Что может спасти в ситуации "перепутал сервер".
c3po
06.02.2017 15:42поддержу, кстати. Эти словом может быть имя сервера, например.
Erelecano
06.02.2017 18:31Ну да. Например для того, что бы случайно не ребутнуть не тот сервер есть molly-guard, который подменяет собой команды reboot и shutdown и спрашивает имя хоста при попытке сделать их по ssh. Очень хорошо помогает в качестве защиты от случайного ребута.
prostovovan
06.02.2017 23:04+1По-моему, такая открытость — это просто популистская попытка прикрыть собственную безалаберность (я про компанию).
caban
Sergey-S-Kovalev
Обычный человеческий фактор: усталость, чуточка спешки. Задача на которой не сработали типовые и рутинные решения что раздражает. Итого стечение кучи обстоятельств, «Секунда невнимательности» и оп.
Laney1
В том-то и дело. Хорошего админа от простого разработчика отличают не компетенции, а в первую очередь уровень паранойи при работе с продакшном.
Регулярно делать бэкапы и проверять их работоспособность, не использовать похожие названия, не делать ничего наугад, когда система начинает показывать неожиданное поведение ("PostgreSQL ругается на то, что открыто слишком много семафоров, и не стартует, при том что до этого нормально работал почти целый год"), да даже банально не работать в 11 вечера — это же все прописные истины, о которых расскажет любой новичок.
caban
Я бы ещё добавил аккуратность.
phoenixweiss
Пилоты самолетов, налетавшие десятки тысяч часов — и те совершают ошибки которые могут стоить жизни не только им самим но еще десяткам и сотням людей.
Человеческий фактор — это феномен безразличный к выслуге лет и квалификации. Конечно, у хорошего специалиста шансов выстрелить себе в ногу меньше, но утверждать что дело только в этом также совсем не верно.
А проблема гитлаба не только в одной консольной команде одного человека. Тут ситуация глубже значительно, потому что система бэкапов у них точно также не работала штатно и сомневаюсь что господин Петерс единолично все везде настраивал.
В этой ситуации мы с товарищами склонны видеть очень ценный жизненный урок и точку после которой в любом случае Gitlab значительно пересмотрит подход к работе с данными и вероятность повторения подобной ситуации должна уменьшиться в разы. Однако в любом случае какого крутого админа не возьми, человеческий фактор исключить полностью невозможно.
nikitasius
Там автоматика в самолетах. И даже, если она отключается, назойливый голов об этом говорит.
JediPhilosopher
Ну так катастрофы обычно случаются на стыке действий человека и автоматики, или на неправильном ее использовании, да еще и при сочетании множества факторов (сложные условия полета, ошибка человека, неочевидная работа автоматики в ситуации которую создатели не предусмотрели и т.п.). Каждый пункт по отдельности вроде бы не страшен и каждое отдельное действие системы может быть логичным и ожидаемым, но в сумме все приводит к катастрофе.
Например как с Ту-204 во Внукове: слишком плавно приземлились с большим перелетом -> не обжались до конца стойки шасси -> автоматика посчитала что самолет еще летит и не дала включить реверс -> пилоты вовремя не прочухали в чем дело и дали полный газ (думая что включают реверс) -> самолет разогнался вместо того чтобы тормозиться -> выкатились с полосы.
Каждое отдельное действие бортовой системы управления правильное — нельзя давать включать реверс пока самолет еще летит (хотя вроде в советское время так делали для быстрого сброса скорости, но сейчас это запрещено), если дают полный газ на полосе — надо разгоняться и взлетать (возможно это уход на второй круг). Но в целом — катастрофа практически на ровном месте. Чтобы этого не допускать и нужны люди, но они бывает ошибаются и не справляются.
nikitasius
И каждый раз автоматика (для своего уровня) пытается сообщить об этом. Все помнят полет «bad angle»? Когда бортовая система госолила, что, мол, вы самолет чрезмерно довернули, так они еще добавили. На ютубе можно найти видео с модуляцией.
lubezniy
В большинстве случаев не голос, а звук, который ещё надо распознать.
nikitasius
погуглите тему
lubezniy
Что погуглите? На тытрубах на том же 737 при отключении автопилота раздаётся характерный звук. Но при серьёзной запаре до него ли?
darkslave
подавляющее большинство авиакатастроф происходит при взлете и посадке, где никакая «автоматика» не работает, это чисто ручной этап полета.
плюс стоит отметить, что до сих пор эксплуатируются самолеты, которые лишены этой автоматики (ту-154, ан-24 и пр.)
breakoffbrain
DevOps это хорошо, но получается, что на разработчиков начинает сваливаться все — и поддержка и доставка приложения и куча задач, которые раньше лежали на плечах сисадминов
s-kozlov
Дык правильный девопс — это когда разработчики и админы тесно сотрудничают, а не когда разрабы выполняют работу админов.
funcbook
вспоминаю формулировку вакансии на должность системного администратора на странице Павла Дурова несколько лет назад, где одно из качеств было: высокая стрессоустойчивость.
NINeOneone
Почему вы обсуждаете админа?
Давайте попробуем предположить что бы было, если бы были бекапы всех пяти уровней?
Бинго! Ничего! Потеря данных за время меньше часа и все. Никто бы ничего не узнал — обычное дело, как отключение питания или сбой оборудования и прочее. Пожурили админа, сделали выводы.
Если вся команда налажала настолько, что не работает ни один из 5 бекапов — пытаться все свалить на одного человека — типичное российское поведение хренового управления. Нормальный управленец понимает, что проблема в организации резервирования, а не в хреновом админе просто потому, что при таком отношении к бэкапам такая ситуация возникла бы неминуемо рано или поздно, ибо человеский фактор не искоренить.
lubezniy
Насчёт того, что никто бы ничего не узнал, не соглашусь. На посещаемых сервисах народу много, данные обновляются часто.
А оргвыводы наверняка тоже сделаны, но внутри команды. И бэкапы теперь наверняка они будут проверять.
9660
Мое мнение что админ не сделал бы rm. Админ бы переименовал каталог. Просто на всякий случай. Из за той самой паранойи.
Scorry
Есть админы, которые удаляют, и админы, которые уже переименовывают.
webasyster
переименовывают удаленную папку
Erelecano
А удаленную мамку или бабку?
В серверных системах есть директории(directory), а мамки с папками остались в запускалке игр.
webasyster
Ой, не любишь ты ностальгию, так нельзя
Erelecano
У меня не может быть ностальгии по запускалке игр, я со Спектрума пересел сразу на первый Пень с FreeBSD.
gekk0
Разработчик с рутовым доступом к боевому серверу, который по ночам чинит репликацию постгреса — действительно странно…
Может быть, это не DevOps, а просто раздолбайство?
caban
Они думали что devops'изация избавит от раздолбайства.
gekk0
А DevOps не подразумевает наличие DevOps-инженеров, которые те же самые опытные админы, но нацелены на всеобщее единение и лучше разбираются в разработке софта?
caban
Не всегда.
ybalt
Верно, вон вверху висит вакансия от компании-автора блога, там предлагают 55 тыс руб. за DevOps админа.
Учитывая, что DevOps это админ с сильным dev бэкграундом или дев с хорошим админ. бэкграундом, мне кажется, что пока нет понимания, что такой специалист редок и стоит дорого, а за 55 тыс. можно разве что «удалителя данных» нанять.
o_serega
DevOps — это парадигма разработки программного обеспечения, при чем тут админ с дев бэграундом или наоборот, это, в первую очередь, тесное взаимодействие между командами, организация процессов. софт скилы, в конце концов! Откуда взялся весь этот бред…
ybalt
Это точно не парадигма разработки ПО. DevOps не рассказывает, как делать ПО и уж точно не организует межкомандное взаимодействие, скорее, это подход к управлению этим ПО — от взаимодействия разных частей и компонентов до средств доставки и развертывания. Грубо говоря, это сплав девелопера и админа, о чем я и говорил в предыдущем сообщении. ДевОпс должен одинаково хорошо понимать как девелоперские задачи уровня архитектуры и связности, так и администрирования, типа развертывания инфрастуктуры и процесса эксплуатации этой инфраструктуры.
Это лично мое мнение, как человека, более двух лет занимающегося именно DevOps — от создания IaaC и стека мониторинг\логгирование до небольших служебных программ, обеспечивающих связность компонент или облегчающих работу разработчиков.
o_serega
Вот именно — это сугубо Ваше личное мнение. Да DevOps и не должен рассказывать как «делать» ПО, он рассказывает как строить процессы. Ну тогда у Вас есть одна проблема, Вы совсем забыли про QA.
Давайте хоть в википедию заглянем https://ru.wikipedia.org/wiki/DevOps.
Не нравится википедия, окей https://www.youtube.com/watch?v=HpZBnc07q9o возьмем блог достаточно большой и уважаемой компании.
Совсем забыл, прочтите книгу проект феникс, в конце концов
ybalt
Не согласен. Строить процессы это не работа DevOps. Это работа менеджеров.
И никакой проблемы я не вижу, на самом деле, я опустил QA потому, что тестирование это часть разработки ПО.
А вот создание системы, включающей как автоматическую сборку-тестирование-доставку-постдоставочное тестирование — это как раз задача DevOps. Упрощенно говоря, задача DevOps заключается в том числе и в создании системы, где разработчики сфокусированы именно на разработке, тестеры на тестировании, а админы — на администрировании сетей и железа.
Чтобы девелопер мог нажать кнопочку и его приложение собралось, отттестировалось, развернулось, прошло интеграционные тесты, включилось в мониторинг и начало работать, а если где-то ошибка, то произошел автоматический откат к рабочей версии с общением кому надо.
o_serega
Я ссылки выше привел, но никто не запрещает Вам жить в своих заблуждениях)
А вот создание системы, включающей как автоматическую сборку-тестирование-доставку-постдоставочное тестирование… Уж простите — это все было до появления девопс. Тогда встает вопрос, чем Вы занимались все время до последних двух лет.
ybalt
Ссылки ссылками, но, как выяснилось, каждый понимает это по-своему. Кто-то считает, что девопс это менеджер, огранизовывающий межкомандное взаимодействие. Кто-то — что это мегапрограммер, говорящий как писать ПО.
Различия в дефинициях — это нормально, идет процесс понимания вообще сути девопс.
Вот даже ваша ссылка на вики говорит:
«Методология фокусируется на стандартизации окружений разработки с целью способствования быстрому выпуску релизов. В идеале, системы автоматизации сборки и выпуска должны быть доступны всем разработчикам в любом окружении, и у разработчиков должен быть контроль над окружением, а информационно-технологическая инфраструктура должна становиться более сфокусированной на приложении».
Это все как раз то, о чем я говорил. ДевОпс ближе к архитектору, чем к админу или девелоперу, но, имхо, должен иметь сильную компетенцию как в деве, так и в администрировании, потому что видит систему в целом, а не отдельные ее компоненты.
И да, процесс описанный выше существовал и раньше, но был разбит на куски и эти куски делались разными людьми или отделами и большая часть времени уходила как раз на то, чтобы выяснить, почему на тест-окружении все OK, а на продакшене не OK. Раньше деплоем занимался разработчик, запуском тестов — тестер, а изменением маршрутов к задеплоеному — админ. Сейчас все делается автоматически и ошибок на порядок меньше из-за автоматизации, унификации окружения и нет паники типа «о боже, у нас полетели два боевых сервера, это два дня на настройку у вечно занятого админа». Теперь развертывание инфрастуктуры и всех приложений с нуля занимает порядка двух часов, может быть проведена как разработчиком, так и админом и сама инфрастуктура перестает быть ценностью — работа сфокусирована именно на ПО.
Если интересно — могу рассказать, что за задачи пришлось решать в рамках работы DevOps, если нет и вы настаиваете на книжном-вики-крутаякомпания варианте — можете смело ставить минус и забыть о моем сообщении )
o_serega
В нормальных компаниях — это все было и до девопс: и нормальная автоматизация (которая не спасает от ошибок сама по себе), и межкомандное взаимодействие, и админы, которые понимали в вопросах разработки, и разработчики, для которых прод — это не просто страшное слово. Потом появился ДевОпс — как квинтэссенция всего вышеописанного. Еще раз повторюсь — девопс — это, в первую очередь, построение тех самых процессов, коммуникация. Автоматизация и ci/cd — это вообще один из способов построения процессов и, тем самым, ДевОпс.
А то что Вы описали — это извращенное видение наших галер и как можно на хайпе заработать побольше бабок, продав заказчику не нормально построенный процесс разработки, а супер пупер мега дорого ухо-горло-сон в мире айти. И эти бредом забит весь интернет.
ybalt
Угу, вот как раз, наверное, в статье и описана «нормальная компания», где человек вручную базы удаляет.
Я вот в упор не вижу различий между вашим описанием видения девопс и моим, ну кроме «построения процессов и коммуникаций» потому что это ну точно не девопс, а менеджмент. И не везде есть автоматизация, не везде ci/cd и не везде все это грамотно интегрировано в инфраструктуру, а задача девопса как раз решать такие задачи по интеграции. И это таки требует серьезных знаний в админ части и в дев части, но никак не менеджмента команд. И девопс как раз создает нормально построенный процесс не столько разработки, сколько эксплуатации ПО и средств его доставки и мониторинга.
Имхо, это выходит за рамки компетенции как девелоперов так и админов, и ничего плохого в том, что такие специалисты стоят дороже рядовых админов или девов нет. Время покажет, просто это модное слово и хайп скоро стихнет, или это процесс эволюции ИТ профессий.
o_serega
В построении процессов участвуют не только менеджеры, а вся команда.
ДевОпс — это построение процессов для организации эффективной разработки, тестирования, эксплуатации, построения каналов связи на всех этапах, как в сторону выкладки, так и фидбэк уже после того, как код копал на прод. Это все ДевОпс, тут работают все, и менеджеры, и тех персонал.
На сим закончим, ибо каждый остается при своем мнении.
ybalt
Честно говоря, не представлю себе девопса, строящего коммуникации между командами или организовывающего разработку ПО, поэтому да — у каждого свое мнение и это даже хорошо.
Спасибо за продуктивный диалог )
o_serega
Я отталкиваюсь от того, что девопс — это парадигма разработки программного обеспечения. Как это было принято изначально в мире, когда появился данный термин. Вы отталкиваетесь от того, что у вас девопс — это какой-то отдельно взятый инженер. В этом вся разница.
ybalt
Я отталкиваюсь от того, что девопс это человек-интегратор (если речь идет о позиции), использующий определенные подходы и практики для существенного облегчения и унификации задач на стыке админ и девелопер. В принципе, между нашими вариантами не так много различий, единственное, что меня смутило — «парадигма разработки программного обеспечения», честно говоря, слабо представляю себе девопса, командующего девелоперами и говорящего им как делать ПО. Сам процесс разработки ПО может быть отвратительным, а девопс решения — грамотными и эти сущности слабо пересекаются. Имхо, опять же.
s-kozlov
Вот откуда взялось, что девопс — это человек?
ybalt
Извините, пропущено слово «инженер». Для краткости.
nike38rus
Возможно я не до конца понимаю суть DevOps, но мне кажется что это явление вообще не подразумевает существование людей с подобными должностями. Как по мне, DevOps — это нечто вроде религии, взаимоотношения между Dev и Ops. А в случае ребят из GitLab — у них похоже роль Ops возложена на Dev
D1abloRUS
вот именно, википедия отлично описывает данный процесс, https://ru.wikipedia.org/wiki/DevOps. А то уже устал читать, что это чудо человек, сочитающий в себе и разработчика и админа и бога, что уж таить.
s-kozlov
Вот и доигрались. История человечества учит, что специализация — это круто, но некоторые предпочитают учиться на своих ошибках.
Noa69
Не в ту консоль вбить команду, совершил бы кто угодно.
А вот не проверять «5 разных видов бекапов» до такой степени что ни один из них как оказалось бекапом не был, вот это да.
akamensky
Я, когда за этой историей следил, точно так же и подумал. Мне только кажется самая большая ошибка это не то что developer удалил базу не на том сервере, а то что компания с USD 20 mln инвестиций не потрудилась обеспечить отказоустойчивость сервиса и не проработали детальный Disaster Recovery план с соответствующими RTO и RPO и обязательным тестированием процесса восстановления.
ziap
Disaster Recovery план? Не, не слышали)
mkll
Глазам не верю — это точно GitLab? Не VasilyPupkinMegaBestCloudHosting Ltd. с полутора серверами?
Серьезная компания мирового уровня, да, вне всяких сомнений.
Вся статья проникнута сочуствием и уважением «к открытости», и это по-человечески понятно, но давайте называть вещи своими именами — это полный бардак, запредельный. И если бы не эта «роковая случайность», оно могло бы стрельнуть позже с куда более крутыми последствиями. Повезло везунчикам.
P.S. Ниже в комментах говорят об увеличении лояльности к компании по причине их той самой открытости. Чудеса. Вы собираетесь им свои данные доверять или их няшные портреты на стенку вешать? Вроде как первое, а что до портретов, то можно найти и по-няшнее. Просто осмыслите факт — люди работали годами без бэкапов и зашевелились на эту тему только сейчас, когда выстрелили себе в ногу. Просто представьте себе образ мышления этих людей. Представили? Нравится? Няшно? Жесть.
nem
Поясню пару моментов от лица ГитЛаба.
Чтобы вы понимали, для ГитЛаба GitLab.com с точки зрения бизнеса — совсем не основное направление. Деньги компания зарабатывает на продаже Enterprise-лицензий.
Приятно слышать что вы считаете GitLab компанией мирового уровня, но не стоит забывать что это очень молодая компания, и за год компании пришлось вырасти с 25 человек до 160.
Да, слишком поздно обратили внимание на то с какой скоростью растет бесплатный GitLab.com, из-за этого и проблемы со скоростью сервиса, и вот это.
Открытость в данном случае — это не оправдание, а гарантия что проблема будет преодолена и такой фигни больше не случится.
mkll
Спасибо за пояснения. Но каждый, наверное, уже сделал свои выводы. Из этих 160-ти человек должен был найтись хотя бы один, который бы сказал: «Эй, ребята, а что у нас с Disaster Recovery Plan? Он есть? Он работает?» — но не сказал. Или сказал, но его не услышали.