Комментарии 86
базой данных ElasticSearch
Вот в этот момент что-то пошло не так?
У нас были резервные копии большинства баз данных, кроме ElasticSearch.
Если уж назвали ее базой - будте добры делать бэкап.
эта база данных была моделью для чтения и по определению не являлась источником истины
Бэкап делают не (только) вещей, которые являются источником истины, но и вещей, которые долго восстанавливать. Как собственно и произошло.
Проблема сидит глубже. Полагаю, тут дело в недооценке реальной (а не теоретической) трудозатратности восстановления индекса.
Если бы его реально можно было восстановить за пару часов — таких проблем бы не было. Судя по всему, когда-то так и было, на более ранних этапах жизни проекта и текущая стратегия была обоснованной. Затем в какой-то момент объем данных вырос и за тем, что восстановление индекса может стать проблемой, не уследили. Особенно с учетом того, что подобных инцидентов ранее не было.
В реальных сложных системах при быстром росте трудно бывает уследить абсолютно за всем, даже если масштабированием занимаются опытные инженеры. Простого решения тут нет, к сожалению.
Проблема не в том что это сложно, а в том что это не запланировано. Да, нужен архитектор, который следит за процессами. Конечно, идеала нигде нет, и такие случаи - повод что-то исправить, но общие правила типа тренингов по восстановлению из бэкапа раз в N месяцев - вещи достаточно известные
Тренинги - это хорошо. Интересно было бы послушать про тренировочное развертывание чего-то действительно большого, типа банка или магазина уровня Озона.
Мне почему-то кажется, что это малореально. Вот у автора - восстановление заняло 6 дней. Через сколько часов бы руководство сказало "все, заканчиваем фигней страдать, работать надо, авось пронесет..."
Мне почему-то кажется, что руководство Озона хорошо понимает почему это необходимо
Скорее всего. Но вот руководство wb - точно нет.
Но мне интересно, как это выглядит. Бывшая сотрудница IT банка мне тут подсказывает, что у них это было в виде "под новый год мы берем свежую кассету и разворачиваем за пару часов". А что происходит когда "дата-центр не отзывается в виду попадания метеорита?". Одно дело архив тестом проверить, другое - когда выясняется, что даже пользователей надо создавать с нуля на системе, которую тоже надо срочно где-то достать.
Так вроде бы это называется Disaster Recovery Plan. Именно для случаев, когда система уничтожена физически (пусть не метеорит, но пожар в дата центре, например). Там и прописано, кто и как разворачивает физическое оборудование (звонит ли в другой дата центр, с которым заключено соглашение и забронировано какое-то кол-во мощностей или бежит на склад за стойками), как и какое ПО разворачивать и в какие сроки, настройки сети и ПО, накат бекапов, переключение на новые адреса смежные сервисы, кто кого и в каком порядке информирует, короче просто вот "перезапустить Озон".
И ещё регулярно проводят тесты этого плана, в идеале переключая каждый год primary на satndby, а в следующем наоборот. Прям на проде с приостановкой работы или параллельно - отдельная тема, ну и тут зависит от величины системы.
Ну и банк или озон не монолит же, вероятность что навернётся просто вот всё - ну, такое... (т.е. абсолютно вся компания хостилась в одном месте и бэкапы там же хранились) таких не жалко.
Насколько понимаю, регулярные симуляции восстановления системы (не только базы, разных сценариев) как раз и должны показать, насколько хорошо (надежно, быстро) работает план по восстановлению. И как его поправить.
Согласен, что в небольших фирмах это "забывают" делать.
Вообще странно было иметь настолько легкий доступ к действию с настолько деструктивными последствиями. Все равно что красную кнопку на столе хранить, как в том меме с карандашом.
Поддерживаю - все подобные ситуации решаются очень надо выдавать пользователя с правами по только на чтение. Это радикально снижает возможность ошибки
Даже если аккаунт админский. Для действия которое сносит целую базу хотелось бы иметь предохранитель. Например, гитхаб просит ввести имя репозитория, который пользователь хочет удалить. Необходимость не слишком частая, чтобы это сильно мешало, но зато теперь нечаянно это точно не сделаешь.
«Как мы потеряли 54 000 звёзд на GitHub»: https://habr.com/ru/amp/post/662155/
в том меме с карандашом
вы знаете правила )
Это не Пикабу. Или на Хабре тоже есть такое правило?
Я имел в виду вот это.
Если действие потенциально деструктивное, как вам идея с распределенными полномочиями на такого рода операции: это как бы первый админ запрашивает потенциально деструктивные действия , а второй админ подтверждает их. Да согласен, это несколько медленнее, но надежнее. Или, как вариант, помечать данные как "удаленные" без немедленного физического удаления из БД, а физически удалять после подтверждения вторым админом и/или по истечении заданного времени.
Кстати, а как правильно по-русски будет? Вроде раньше не переводили и всегда говорили что-нибудь типа "прод", или "продакшен", неужели теперь переводят как "продуктивная"?
Может не дословно, но по смыслу ближе всего "рабочий сервер". Еще иногда говорят "боевой". Для БД аналогично. Дословно будет "производственный", но я не слышал чтобы кто-то так говорил.
"промышленный".
промбаза - и так вполне говорят.
Промбаза вообще-то несколько другое :)
Работаю с SAP и всегда в компании называем исключительно продуктивной системой. Скорее зависит от слэнга организации. У нас федеральная, поэтому не юзаем такое и так же проще, как бизнес-аналитику, поддерживать общение в общем кругу клиентов и сотрудников.
Продакшен база звучит лучше, чем продуктовая, особенно если в ней храняться не продукты питания.
промышленная, промбаза, "на проме". почти не отличается от "на проде".
Ни от какой кривой кальки так не корёжит, как от "боевая база", "на бою" и тому подобных. Что угодно, только не это
В российских реалиях часто встречается "продуктивный контур", например. Почему нет.
Как вариант, "промышленная БД"
лучше уж SQL, где надо не мышкой, а умышленно нажать последовательность букв DELETE.
По итогу вы сделали восстановление из ранее использованных индексов. Повезло.
DELETE /items/idА потом хочешь посмотреть список, но ленишься открыть новую вкладку и исправляешь запрос, забыв поменять глагол на GET.
DELETE /items/К счастью, обычно такая операция не определена.
Поэтому я в Постмане стараюсь не лениться и не переиспользовать вкладки для разных операций. В таком случае тоже можно забыть поменять глагол, но по молчанию там GET, который в большинстве случаев безопасен.
Не далее как в пятницу наблюдал запуск запроса UPDATE без секции WHERE. В этом случае бекап был отдельно слит прямо перед операцией, но тем не менее. Из тех серверников, что я знаю, так или иначе почти каждый делал это в продакшне. И рекомендация писать сначала SELECT и смотреть что выбралось, а потом переписывать начало запроса на UPDATE или DELETE не меняя секцию WHERE не спроста появилась.
Я думаю и остальные бэкапы тоже никто не проверяет, если нет периодических процедур disaster recovery
Когда-то давно я умышленно нажал последовтельность букв "DELETE FROM table_name<ENTER>". На самом деле я хотел написать ещё WHERE, но дрогнула рука. Хорошо, что в мускуле тогда уже была защита от безусловных удалений. Это была mysql-консоль, на проде, на боевой базе, под админским, разумеется, аккаунтом.
Не ElasticSearch, а Elasticsearch. Брэнды надо уважать, иначе они кусаются.
Помню много лет назад презентацию ребрендинга флагманского продукта одной крупной софтверной компании, и основателю из зала задали вопрос "а как это правильно произносится", на что основатель ответил - "а как вам больше нравится? Можете произносить как вам нравится!"
Это было неожиданным, но очень "сильным" ответом. Не важно, как говорить: "хюндай", "хёндай" или "хёнде" - все варианты работают на бренд. Более того, многочисленные смешные и нелепые вариации, их обсуждения и даже споры пользователей только способствуют запоминаемости бренда.
Про юрлицо, насколько я знаю, есть какой-то закончик о транслитерации, который не даёт разгуляться в нейминге для зарубежных дочек.
Потому что Postgres - это была другая база. В том, что подросли школьники, которые этого не помнят, те люди, которые "выбирали написание", уж точно не виноваты.
Выбирали, кстати, в том числе Вадим Михеев из Красноярска, который тогда работал в соседнем здании (поэтому я прекрасно этот процесс помню) и написал половину тогдашнего постгреса (из-за чего он во многом и стал sql) и Джулиан Ассанж (да, тот самый).
Как зануда-школьник, читающий в данный момент официальную докментацию PostgreSQL, приведу цитату из пункта 2.3 предисловия.
Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.
Не знаю, кто там определяет правильность, но я буду называть так, как написано в доках.
Удивительные приключения разработчиков на проде! «Как вы можете нас не пускать в продуктовую базу, вы нам не доверяете? Вы плохой сисадмин, был бы хороший девопс, он бы строил эджацл, а не запрещал доступы.»
Если надо было просто запросы и фильтры потыкать там, где жалко что-то потерять, то нахера это было делать не под R/O учёткой, напрашивается вопрос.
Мы использовали старую версию ElasticSearch, которая обеспечивала лишь самую базовую аутентификацию пользователей, поэтому мы воспользовались тогда еще платной версией XPack. В более поздних версиях ElasticSearch XPack уже включен в бесплатную лицензию.
Я так понимаю, что там не было разделения на роли. Мне это тоже кажется ужасно странным. Но я не знаком с администрированием ElasticSearch, может это и правда так, или я что-то понял неправильно.
"Мы приняли решение ограничиться включением резервного копирования только в самые критические периоды работы бизнеса." Делать что-то только в самые критичные моменты... что может пойти не так (с)?
Только на прошлой неделе общался в крупным банком, все разработчики одного из DataLake которого работают сразу в проде - "но ведь нам для работы нужны prod данные". Ну да, ну да, а скопировать кусок в dev не позволяет религия, видимо...
я не из этого банка, но представляю себе, как это - на проде 100500 мильонов ГБ и мощность серверов достаточная, а на тесте и места фиг да маленько, и запросы бегают в 2-3-5 раз дольше. А когда еще данные нужны не из 3 таблиц, а из 28, ууу, вообще больно становится.
Нужен жестко регламентированный, желательно автоматический и постоянный/регулярный процесс, сопоставимые по параметрам контуры и удобные способы репликации, иначе разработчики, как ток, пойдут по пути наименьшего сопротивления. А такой процесс, контуры и способы репликации - это вопрос способности менеджеров настоять на их необходимости и выбить ресурсы из экономного начальства =) Такие менеджеры на вес золота идут и редко встречаются))
Все словоблудие можно уменьшить до фразы "У нас были резервные копии большинства баз данных, кроме ElasticSearch"
Вторым элементом катастрофы было отсутствие в эластике ролей. Третьим — особенность устройства API эластика в сочетании с особенностями Postman.
И мне кажется, это полезные знания. А не только то, что надо делать бэкапы. Которые они, кстати, так и не стали делать регулярно, даже проанализировав катастрофу.
И без ролей бэкап бы помог. Благо в эластике он прекрасно реализован (правда, могут быть технические трудности с обеспечением эластика shared storage'ем).
И в целом для управления эластиком мне нравится больше кибана devtools. Там как раз буквы писать нужно + история запросов всегда под рукой - у меня их штук 30 для управления кластером. Встал на нужную строчку, Ctrl-Enter - профит. Очень удобно. Если эластик (и кибана) вдруг полегли, обычно хватает CURLa. В постмане же гораздо проще ошибиться, действительно.
У меня тоже есть пара историй которые учат тому, что некоторые действия не должны быть легкими и простыми, иначе велик шанс их случайного совершения.
Давным давно, когда компьютеры были не у в всех, мой знакомый приходил ко мне поработать за компьютером, он любил использовать total commander и совершать все файловые операции через комбинации клавиш (для скорости и пущей эффектности), и в итоге простой комбинацией клавиш отформатировал мне диск C вместо дискетки, о бекапах я тогда еще не знал)
Однажды я работал на проекте где использовалась MongoDB и по просьбе отдела QA я написал простой скрипт который при исполнении удалял часть коллекций в базе, скрипт этот я просто положил в репозиторий. В один прекрасный день, мне нужно было подключиться к прод базе консольным клиентом, я запустил клиент из каталога где и лежал этот скрипт. Как оказалось, волей гения разработчиков Mongo консольный клиент в момент запуска находит все js файлы в текущем каталоге и запускает их, очень удобно. Помню то ощущение как от удара кнутом, когда я понял что произошло, но к счастью база была маленькая и мы восстановили ее за полчаса. Скрипт я конечно переписал так, чтобы случайная загрузка не приводила к исполнению.
Чему я научился после того как я случайно уничтожил продуктовую базу данных?
Проходить собеседования!
Автор бы ещё в графане хранил базу продуктов...
"To delete your base press OK"
Этот пост не похож на посты про "Смотрите как у меня хорошо получается". Плюс.
Я как-то когда работал "мальчиком при кампухтерах", так грохнул бухгалтерскую БД 1С. Времена тогда были.. сложные, и на фирме было две БД, одна для проверок, красивая, белая, вторая настоящая, и лежала она у главбуха на компе (паранойя, да, она самая), доступ к ней был только у директора, главбуха и ее помощницы. Но в один прекрасный момент, комп главбухши засбоил, винда перестала загружаться, а я по привычке, что-бы не париться долго решил просто залить на него образ винды, с предварительным форматированием - все компы были по сути тупыми клиентами, все данные лежали в расшаренных папках на сервере, 1С работала через терминал на этом-же сервере, поэтому проблемы с клиентскими компами так обычно мной и решались. О том что там лежит "секретная" БД, я вспомнил уже когда образ винды накатился и запустился. :)))
Ощущения были незабываемые. Повезло - отделался малой кровью - на сервере лежал бекап (который я делал тайком, скриптом по расписанию, на такой вот случай, он, конечно запароленный был, но я пароль, естественно знал), с него и восстановил базу, немного данных потерялось, но это бухгалтерия довольно быстро восстановила, там меньше чем за день потери были.
Ошибки к сожалению неизбежны. И подобный опыт, сын ошибок трудных, наверное есть у большинства. Но в результате возникли правильные вопросы по функционированию системы. И это автор может записать себе в актив.
Оглядываясь назад, можно сказать, что все это стало больше походить на монолит, чем на действительно распределенную архитектуру...
Т.н. распределённая архитектура имеет массу трудно решаемых проблем, её применение должно быть чем-то оправданно, если есть возможность её не использовать. то обычно получается вполне работоспособный вариант. IMHO
вместо GET было выбрано DELETE.
всегда удивляло, как в продуктах так легко можно использовать разные команды, которые могут иметь такие разные действия.
причем если запрос информации можно делать без лишних вопросов - почему удаление информации должно быть настолько-же просто, без дополнительных вопросов и параметров?
Просто RBAC для хипстеров - это сложно и муторно, проще всем выдать админские права и не париться.
1) там все по Http REST стандарту. А уж у постмана вообще нет понимания - зачем вы делаете запросы. Вам надо сделать запрос - он тут же выполняет :)
2) все штуки, которые спрашивают "вы точно хотите?", к которым вы привыкли - увы, но это визуальные надстройки, а не "протокол запрашивает подтверждение и т.д"
Чего, судя по всему, не было, так это специалиста отвечающего за безопасность. Потому, что случившееся это типовой случай диверсии, а уж умышленно она сделана или нет, с точки зрения безопасности не важно. Основной принцип - пользователь не должен иметь возможности совершить деструктивные действия.
Ее смысл состоит в том, что виноваты процессы, а не люди.
Парадокс в том, что эти процессы выстраивают как раз люди. И именно они порой бывают виноваты. Если же вы доведёте процесс до идеала, не позволяющего никаких ошибок, то, боюсь, люди будут в нём уже не люди а некое приложение процесса не имеющего ни свободы выбора, ни свободы воли.
Манипулировать рабочей БД через инструменты разработчика типа postman не очень хорошая идея. В инструментах администраторов обычно можно просто обозначить соединение как production, и тогда операции на запись или блокируются, или требуют дополнительных подтверждений.
"Чему мы научились после того, как я случайно уничтожил продуктивную базу данных" - пользоваться readonly доступами
Очень приятно читать адекватную позицию автора! Считаю, что не ошибается только тот, кто ничего не делает. А ответственность - это не про предотвращение собственных фобий (которые взялись часто на пустом месте благодаря слухам), а про предотвращение повторения факапа. Так, чтобы предотвратить повторение, надо сначала получить его в первый раз, и это нормально.
Пойду-ка настрою роли в эластике...
Чему мы научились после того, как я случайно уничтожил продуктивную базу данных