Comments 29
… Но вы получите аналогичный эффект, если затронете своими изменениями уникальный ключ, на который ссылается внешний ключ из других таблиц....
ИМХО: обычно сочетание «уникальный ключ» и «внешний ключ другой таблицы» говорят о том, что это хороший кандидат на первичный ключ. И если приходится делать update первичного ключа, то это сигнал о проблеме в архитектуре БД.
Но первая глобальная проблема для любого более-менее серьёзного проекта — то, что у вас нет доступа к серверным логам вследствие политики безопасности. Иногда вообще нет никакого доступа. А иногда можно попросить участок, но надо ждать. Иногда это 30 минут, иногда день.
Мне кажется, на более-менее серьезных проектах такие проблемы недопустимы. У вас может не быть непосредственного доступа на сервер, но доступ к логам быть обязан. Для этого можно агрегировать логи в ELK стек. Или как-то еще централизованно хранить. Но ситуации, при которой логов нужно ждать ДЕНЬ(!) возникать в работе не должно. А если такая ситуация возникает с пугающей регулярностью, надо все бросать и немедленно принимать меры.
Логи могут содержать конфиденциальную информацию, поэтому слово «обязан» не всегда осуществимо. День приходится ждать почти никогда, но при наслоении проблем отдел, который имеет доступ к оным, будет обслуживать заявки на логи в последнюю очередь.
Но ведь ее можно удалить из логов перед отправкой, верно?
А почему такая важная информация вообще в логах?
Email пользователя например. У вас упал Update на обновление контактных данных и он может быть засвечен.
Я сразу хочу оговориться, у нас нет в логах ничего важного кроме ников игроков. Просто описанный способ подходит если:
1. Такая информация у вас есть.
2. Сделать джобу на периодическую отправку логов сложно, из-за бюрократических процедур.
3. Вам нужны очень понятные логи, оторажающие всё что вообще происходило в этот момент.
Вот мы руководствовались третьим соображением и немного вторым.
1. Такая информация у вас есть.
2. Сделать джобу на периодическую отправку логов сложно, из-за бюрократических процедур.
3. Вам нужны очень понятные логи, оторажающие всё что вообще происходило в этот момент.
Вот мы руководствовались третьим соображением и немного вторым.
Проблема с доступом к логам, как правило, не техническая, а организационно-административная.
Есть ли в логах чувствительная к разглашению информация? Кто к ней должен иметь доступ? Система в скоупе PCI DSS? И т.д.
Есть ли в логах чувствительная к разглашению информация? Кто к ней должен иметь доступ? Система в скоупе PCI DSS? И т.д.
первая глобальная проблема для любого более-менее серьёзного проекта — то, что у вас нет доступа к серверным логам вследствие политики безопасности. Иногда вообще нет никакого доступа. А иногда можно попросить участок, но надо ждать. Иногда это 30 минут, иногда день.
Если права и доступы четко разграничены, значит скорее всего у вас также разграничены зоны ответственности.
Админы, девупсы, разработчики, архитекторы и т.д. Также используется система непрерывного развертывания, гит и т.д. и т.п. Не суть на самом деле.
Проблема с логами решается на уровне админов/девупсов, которые заводят в jenkins таску, выгружающаю с прода нужный кусок лога или весь лог за какой-то день. Доступ к этой джобу в jenkins дается разработчикам, чтобы они могли в кратчайшие сроки выгрузить то, что им нужно.
Еще можно прикрутить Zabbix и мониторить любые ошибки базы, в случае появления которых запускать джобу и получать все логи на почту еще до того как о проблеме будет известно широкому кругу заинтересованных лиц.
Да, согласен, ну а мы поступили описанным способом и имеем гораздо более подробную информацию о происходящем и в гораздо более описательном виде.
Уж поверьте, не в Варгейминге. Там разработчики от продакшена огорожены так, что никто из них не имеет туда доступа и не знает где что лежит. МОжет быть за редким исключением. Девопсы, в свою очередь, ничего не знают про приложение, а админы — конфигурят железо.
При этом все боятся и не доверяют никому в компании.
При этом все боятся и не доверяют никому в компании.
Не буду утверждать так голословно за всю компанию, но в моём отделе всё описанное вами не соответствует действительности.
Ну так доступов то у вас нет, даже для того, чтобы собрать всю необходимую диагностическую информацию и ждать приходится по несколько часов. Опять же, без пинка редко кто возьмёт тикет в разработку. Хорошо, если это меняется и команды теперь знают о продакшене больше, чем ничего.
У тимлидов обычно есть доступ, но они бывают на совещаниях часто. Кроме того незачем их отвлекать лишний раз, если можно самим себе всё устроить, например описанным способом.
Без пинка редко кто возьмёт тикет в работу — это справедливо и наоборот. Если вам приходит тикет из соседнего отдела, то нужно чтобы вас пнули, ибо у вас своей работы тоже хватает.
Без пинка редко кто возьмёт тикет в работу — это справедливо и наоборот. Если вам приходит тикет из соседнего отдела, то нужно чтобы вас пнули, ибо у вас своей работы тоже хватает.
Привет! Наши разработчики постоянно работают с продакшеном, и базами в том числе. Деплой и разработка все вместе контролируют и обмениваются статистикой. Также нет проблем и с админами. Наверное, бывают разные случаи, но в целом все работает именно так.
У нас есть специально обученные люди), занимающиеся разбором происшествий на проде.
Они не занимаются кодингом, но имеют доступ к исходникам или части кода, который был изменен в тои или иной таске, например. Также имеют доступ к продовским БД, но тоже с ограничениями. Для чтения, не ко всем таблицам или столбцам порой к реплике продовской базы. Также могут быстро получать логи нужных систем через таски в jenkins.
Понятно, что у них в нужный момент может не оказаться всего, что нужно для разбора инцидента, но много что есть. и если чего-то нет, быстрый доступ может появиться. Но также как у вас, через день, 2)
Это своеобразный саппорт IT отдела (именно отделка не клиентский саппорт).
Т.е. у них есть доступ, но изменить они ничего не могут, персональные данные тоже прикрыты, весь код унести также не получится.
Они не занимаются кодингом, но имеют доступ к исходникам или части кода, который был изменен в тои или иной таске, например. Также имеют доступ к продовским БД, но тоже с ограничениями. Для чтения, не ко всем таблицам или столбцам порой к реплике продовской базы. Также могут быстро получать логи нужных систем через таски в jenkins.
Понятно, что у них в нужный момент может не оказаться всего, что нужно для разбора инцидента, но много что есть. и если чего-то нет, быстрый доступ может появиться. Но также как у вас, через день, 2)
Это своеобразный саппорт IT отдела (именно отделка не клиентский саппорт).
Т.е. у них есть доступ, но изменить они ничего не могут, персональные данные тоже прикрыты, весь код унести также не получится.
Всё это неизбежно приводит к дедлокам
Неправильная архитектура.
Если код из примера реальный, то это жесть…
Неправильный выбор инструмента для решения вашей задачи.
Девелоперы — не очень.
Но админы молодцы, интересно.
А если есть несколько ЦОДов. У каждого есть мастер. В оба мастера приходят запрос баланса и списания суммы, если баланса достаточно. Как синхронизировать мастера, чтобы не было двойного списания и в итоге в минус на счету не ушли?
Sign up to leave a comment.
Как мы ловим Deadlock`и на PostgreSQL и чиним их