Re[53]: Идемпотентность POST - хорошая ли практика?
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.22 08:32
Оценка:
Здравствуйте, ·, Вы писали:

·>Так и решать её надо административно. Хедер не может административную проблему решить.


Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу?

P>>·>Теперь последний шаг. В чём будет выражаться неигнорирование мониторинга? Ну допустим заметил какой-нибудь сисоп какой-то варнинг на дашбоарде. Дальше-то что?

P>>Ты не в курсе как работает мониторинг и опсы?
·>В курсе. Теперь ты на мой вопрос ответь.

Дальше в соответствии с инструкциями. Например, наши L2 после мониторинга обязаны локализовать проблему, связаться с разработчиками-менеджерами и предпринять кое какие шаги, если есть такая возможность, что бы купировать проблему.

P>>>>В случае с changlog ты вообще всю работу делаешь руками. А в данном случае ты просто добавил правило в мониторинг и всё.

P>>·>Какую "всю"? Для справки, сhangelog — это лог сделанных изменений.
P>>Именно.
P>>1. надо прочитать, вникнуть в каждый тикет, посмотреть тамошние подробности
P>>2. каждую строку проверить на предмет того, а не цепляет ли это вас
P>>Повторить для всех n*m зависимостей
P>>Прогнать тесты
P>>Если они красные пофиксить
P>>А если зеленые — а хер его знает. Тут мы выяснили, что ты плохо понимаешь, что такое 2^100 комбинаций, простейший случай
·>У тебя нет 2^100 комбинаций.

Есть. Типичный реквест содержит куда больше информации.

>В рассматриваемом случае у тебя есть ровно одна, ты же сам её написал. Вот она: Warning.assert(precondontion, 'unexpected input').

·>Если до тебя допёрло что можно написать именно этот Warning, значит ты с таким же успехом можешь создать джиру/послать емейл и добиться проверки|тестироваия|исправления этого данного precondontion.

Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи.

> Заметать это под коврик хедеров, это лишь оттягивать удовольствие и вводить кучу никому не нужных слоёв, рискуя прод-инцидентами.


Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет?

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

·>Провал ассерта это проблема твоя, а не твоих консьюмеров. Тебя она и должна беспокоить. Зачем это слать кому-то в хедерах — расскажи.

P>>assert(deprecated) сработает вне зависимости от того, сколько у нас данных, 2^10 или 2^10^10.

·>Верно. Но если этот assert бабахнет, это твоя проблема, ты и обязан фиксить. Поэтому это должно быть в твоих логах. С какого боку тут хедеры?

И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты.

Какой смысл продолжать?

P>>А где я написал, что не надо мониторить логи?

·>Ты невнимательно читаешь вопрос. Я спрашиваю, почему именно хедеры надо? (а логи лишь _например_).

Мы рассматриваем конкретную фичу апи. Кроме того, l2 суппорт смотрит не только хидеры, а много чего еще.

·>Хедер — не единственный способ сообщить что-то кому-то. Объясни в чём уникальность хедера, что другие способы не могут работать?


Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне.

P>> У них нет доступа к твоим логами.

·>Дай доступ.

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

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


Тебе уже сказали, что все это уже есть. Снова нечитатель?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.