Здравствуйте, Pauel, Вы писали:
P>·>Так и решать её надо административно. Хедер не может административную проблему решить.
P>Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу?
Без хедера фича не работает?
P>>>·>Теперь последний шаг. В чём будет выражаться неигнорирование мониторинга? Ну допустим заметил какой-нибудь сисоп какой-то варнинг на дашбоарде. Дальше-то что?
P>>>Ты не в курсе как работает мониторинг и опсы? 
P>·>В курсе. Теперь ты на мой вопрос ответь.
P>Дальше в соответствии с инструкциями. Например, наши L2 после мониторинга обязаны локализовать проблему, связаться с разработчиками-менеджерами и предпринять кое какие шаги, если есть такая возможность, что бы купировать проблему.
Итак. Получается такая цепочка:
0. Ты обнаружил precondontion.
1. Код ворнинга
2. QA
3. Хедер
4. Система логгирования
5. Мониторинг
6. L2 замечает проблему
7. L2 расследует
8. разработчик-менеджер.
Вот теперь объясни зачем нужны шаги 1-7? Это затраты ресурсов и человеческих, и машинных, и на каждом шаге можно сломаться-потеряться и вся цепочка рухнет. Почему бы сразу не перейти к 8му шагу?
P>·>У тебя нет 2^100 комбинаций.
P>Есть. Типичный реквест содержит куда больше информации.
И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация.
>>В рассматриваемом случае у тебя есть ровно одна, ты же сам её написал. Вот она: Warning.assert(precondontion, 'unexpected input').
P>·>Если до тебя допёрло что можно написать именно этот Warning, значит ты с таким же успехом можешь создать джиру/послать емейл и добиться проверки|тестироваия|исправления этого данного precondontion.
P>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи.
Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно.
>> Заметать это под коврик хедеров, это лишь оттягивать удовольствие и вводить кучу никому не нужных слоёв, рискуя прод-инцидентами.
P>Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет?
И причём тут хедер?
P>>>Как и несколько месяцев назад, ты как то не в курсе, что те же ассерты и тесты покрывают немного разные классы задач. Одни дискретные, другие — непрерывные. Для тебя, похоже, это пустой звук.
P>·>Провал ассерта это проблема твоя, а не твоих консьюмеров. Тебя она и должна беспокоить. Зачем это слать кому-то в хедерах — расскажи.
P>>>assert(deprecated) сработает вне зависимости от того, сколько у нас данных, 2^10 или 2^10^10.
P>·>Верно. Но если этот assert бабахнет, это твоя проблема, ты и обязан фиксить. Поэтому это должно быть в твоих логах. С какого боку тут хедеры?
P>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты.
Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер.
P>Какой смысл продолжать?
Продолжать уводить разговор в сторону — никакого смысла, ясен пень, нет. Так что не продолжай, конечно.
P>>>А где я написал, что не надо мониторить логи?
P>·>Ты невнимательно читаешь вопрос. Я спрашиваю, почему именно хедеры надо? (а логи лишь _например_).
P>Мы рассматриваем конкретную фичу апи. Кроме того, l2 суппорт смотрит не только хидеры, а много чего еще.
Так почему именно хедер с ворнингом надо? Чем другие механизмы не устраивают-то?
P>·>Хедер — не единственный способ сообщить что-то кому-то. Объясни в чём уникальность хедера, что другие способы не могут работать?
P>Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне.
Зачем триггерить мониторинг на той стороне?
P>>> У них нет доступа к твоим логами.
P>·>Дай доступ.
P> у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать.
1. В логах не должно быть сенситив информации. По крайней мере не во всех. На крайний случай заведи лог специально для варнингов и расшарь.
2. Мы вроде о внутренних консьюмерах говорили. Иначе твои аргументы про мониторинг на той стороне идут лесом, т.к. сотню-тысячу консьюмеров ты банально не сможешь уговорить пользваться какими-то непонятными хедерами и мониторингами.
>>Настрой свой мониторинг и шли кому надо какие-нибудь сообщения в каком-либо виде — емейл, чаты, смски, джиры, етс, но не в хедерах каждого респонза. Терабайты съэкономишь.
P>Тебе уже сказали, что все это уже есть. Снова нечитатель?
В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер?
