Здравствуйте, Pauel, Вы писали:

P>>>Очевидно — никакие. Дальше что?
P>·>Дальше работаем.
P>Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
Я не увидел проблему.

P>·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
P>Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
Почему не могут? И на вопрос "зачем" ты так и не ответил.

P>>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
P>·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?
P>Добавить правило в мониторинг это дело секунд.
А толку? Правило в мониторинге полезно только тогда, когда оно работает, работает правильно и сообщает нужным людям нужную информацию. Этот аспект ты полностью умалчиваешь. Ведь по итогу все эти дашборды и мониторинги лишь для того, чтобы создать таску в джире и послать емейл.

>> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
P>О чем писать будешь, если тесты зелёные? Эй, ребята, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
У этих ребят должен быть свой мониторинг и процессы QA. Как ни странно.

P>·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.
P>Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
P>Варнинги появляются как обычно, это разновидность логирования, только рендерится и в респонс.
В чём преимущество рендерить в респонс-то? Рендери как обычно, в логи. Логи можно раздавать всем желающим, если хочется.

P>Итого — ты как решать будешь?
Чтобы что-то решать, я должен понять задачу. Какую задачу решает логгирование в респонз и не может решить логирование в логи?

P>·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.
P>Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
P>Как в твоем случае проблему обнаруживать будешь?
Вначале расскажи, какую проблему можно обнаружить по хедерам, но невозможно обнаружить по логам?

P>·>Не дольше, чем искать для какой комбинации нужен варнинг.
P> Ты похоже не понял, что такое 2 в степени 100. Тестами ты гарантировано ничего такого не найдешь, т.к. прогон тестов закончится вместе с электричеством.
P>А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.
Да ради бога. Для этого и придумали логи. Зачем в респонз-то?

Здравствуйте, ·, Вы писали:

P>>Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
·>Я не увидел проблему.

В том то и дело, что тесты её не показывают. Её можно увидеть только в рантайме, если есть. Ровно то же, что и трейсинг/логирование, только идет в обратную сторону.

P>>·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
P>>Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
·>Почему не могут? И на вопрос "зачем" ты так и не ответил.

Потому, что внутренних консумеров мы контролируем, для этого есть документация по каждой из капабилити. Например, мы требуем трейсинг, а это значит, что они берут готовый инструмент с нашими настройками, а не мастырят чтото своё на коленке "я просто пишу в сокет". Ровно так же с любой капабилити.

P>>Добавить правило в мониторинг это дело секунд.
·>А толку? Правило в мониторинге полезно только тогда, когда оно работает, работает правильно и сообщает нужным людям нужную информацию. Этот аспект ты полностью умалчиваешь.

Мониторинг уже протестировали. Остается кейс конкретного сервиса.

P>>О чем писать будешь, если тесты зелёные? Эй, ребята, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
·>У этих ребят должен быть свой мониторинг и процессы QA. Как ни странно.

У тех ребят точно так же 100% покрытия недостижимо. А раз у них есть и мониторинг, то проблема наполовину решена.

P>>Варнинги появляются как обычно, это разновидность логирования, только рендерится и в респонс.
·>В чём преимущество рендерить в респонс-то? Рендери как обычно, в логи. Логи можно раздавать всем желающим, если хочется.

Можно. Если ты точно знаешь, что у конечного сервиса есть все данные, что бы идентифицировать проблему, то можно и так. А если сервис не может этого сделать, надо бы делегировать обязанности тому, кто может, например, api gateway тот же.

P>>А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.
·>Да ради бога. Для этого и придумали логи. Зачем в респонз-то?

Тебе ж уже сказали — http://rsdn.org/forum/design/8377498.1

Автор: maxkar
Дата: 06.10.22

Здравствуйте, Pauel, Вы писали:

НС>>У меня текущий продукт ровно по такой схеме и построен. Только при чем тут заголовки с варнингами?
P>При том, что трафик после такого гатевея уже внутренний

Да. Я тебе больше скажу — у меня там целая пачка кастомных хидеров бегает. Но вот варнинги там точно не нужны.

P>, а раз так, то на него можно навешивать какие угодно капабилити.

Можно, но в хидерах не нужно. Это, по сути, статическая информация. Меняется при деплое, либо, в совсем уж экзотических случаях типа А/В, при изменении конфигурации. В условиях кубера такое обычно реализуют при помощи custom resource, из которого сервисы либо напрямую читают, либо их кормит этим специальный оператор. Так если для публичного апи какую то сомнительную пользу из обсуждаемого хидера еще и можно извлечь, то внутри кластера такие варнинги как собаке пятая нога.

P>Например, гатевей будет блокировать реквесты от конкретных юзеров, клиентов, если варнинги идут больше недели.

Такие вещи, как я уже сказал, обычно делаются при помощи CR и оператора (либо, если нужна супероперативность, с каким нибудь промежуточным хранилищем типа редиса или консула), а не засером всего внутреннего трафика дублирующейся информацией, которую придется как то обрабатывать всем сервисам (ну либо вешать на все сервисы специальные RP как в istio, что отдельная история).

P>1. сhangelog это в чистом виде человеческий фактор. например, девелопер не просмотрел, не учел последствия.

И это надо чинить. Потому что релизноты покрывают намного больше кейсов, чем предложенные заголовки.

P>2. И вот ты прочел changelog, проверил все что мог, тебя тесты зелёные. Твои действия? Что конкретно ты будешь предпринимать
P> в такой вот ситуации? Есть хороший пример, что бы не абстрактно рассуждать? ты то не надеешься на варнинги, как с проблемой будешь работать?

Вопрос непонятен. О какой проблеме речь?

НС>>Заголовки тут не спасут.
P>Зато это уже можно автоматизировать.

Можно. Но заголовки — лишняя сущность для этого.

P> А вот как автоматизировать обработку changelog депенденсов 2го уровня — не ясно.

Еще раз — 2 уровень заголовки тоже не отслеживают (если конечно ты не будешь эти заголовки пропогейтить по всей цепочке, что совсем уж дичь если сопоставить с исходной задачей).
Ты выкинь из головы все технические подробности и посмотри на проблему сверху. У тебя уже ровно в момент прихода реквеста непосредственно в сервис уже все известно и понятно. От того что ты потом эту информацию погонишь с респонсом обратно — ни новой информации, не улучшения доступности существующей не дает. Это абсолютно бессмысленное с точки зрения системы действо. Единственное что может быть полезно это если эти заголовки кто то в какой то момент увидит глазами (ну там всякие HATEOAS, да). Но в данном случае это ничего не даст, того же эффекта можно достичь убиранием заобсоличеных методов из OpenAPI definition, что обычно и так делается автоматом.

P>>>Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?
НС>>Заголовки тут не спасут.
P>Это смотря как ты ими пользоваться будешь.

Расскажи как.

Здравствуйте, Pauel, Вы писали:

P>>>Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
P>·>Я не увидел проблему.
P>В том то и дело, что тесты её не показывают. Её можно увидеть только в рантайме, если есть. Ровно то же, что и трейсинг/логирование, только идет в обратную сторону.
"Не увидел" в том смысле, что ты не обозначил какую задачу мы решаем.

P>>>Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
P>·>Почему не могут? И на вопрос "зачем" ты так и не ответил.
P>Потому, что внутренних консумеров мы контролируем, для этого есть документация по каждой из капабилити. Например, мы требуем трейсинг, а это значит, что они берут готовый инструмент с нашими настройками, а не мастырят чтото своё на коленке "я просто пишу в сокет". Ровно так же с любой капабилити.
Ну трейсинг. И что дальше-то? Крутится где-то там у них ваш навязанный мониторинг, и всем пофиг что там всё красным моргает, никто туда не смотрит, ибо свои дела есть. "устал, много варнингов, (не)загляну в понедельник".

P>>>Добавить правило в мониторинг это дело секунд.
P>·>А толку? Правило в мониторинге полезно только тогда, когда оно работает, работает правильно и сообщает нужным людям нужную информацию. Этот аспект ты полностью умалчиваешь.
P>Мониторинг уже протестировали. Остается кейс конкретного сервиса.
А кейс — по сути это конкретный сценарий, который надо задокументировать, имплементировать, протестировать и мейнтейнить. В чём автоматизация — неясно.

P>>>Варнинги появляются как обычно, это разновидность логирования, только рендерится и в респонс.
P>·>В чём преимущество рендерить в респонс-то? Рендери как обычно, в логи. Логи можно раздавать всем желающим, если хочется.
P>Можно. Если ты точно знаешь, что у конечного сервиса есть все данные, что бы идентифицировать проблему, то можно и так. А если сервис не может этого сделать, надо бы делегировать обязанности тому, кто может, например, api gateway тот же.
Неясно каким волшебным образом, как ты обещаешь автоматически, это появится благодаря хедерам.

P>·>Да ради бога. Для этого и придумали логи. Зачем в респонз-то?
P>Тебе ж уже сказали — http://rsdn.org/forum/design/8377498.1

Автор: maxkar
Дата: 06.10.22

Я не очень понял из этого ответа, почему это должно быть именно поле в респонзе, а не строчка в логе. Поясни. Я не очень понял что за системы у него упомянутые, но могу представить что в таких окружениях будет какая-нибудь kibana куда собираются все логи и настраиваются дашборды-алерты.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>При том, что трафик после такого гатевея уже внутренний

НС>Да. Я тебе больше скажу — у меня там целая пачка кастомных хидеров бегает. Но вот варнинги там точно не нужны.

А разве я говорю что надо всенепременно именно варнинг добавить? Если ты научился протаскивать капабилити с одним кастомным хидером, то какие проблемы будут с другой капабилити ?

P>>2. И вот ты прочел changelog, проверил все что мог, тебя тесты зелёные. Твои действия? Что конкретно ты будешь предпринимать
P>> в такой вот ситуации? Есть хороший пример, что бы не абстрактно рассуждать? ты то не надеешься на варнинги, как с проблемой будешь работать?

НС>Вопрос непонятен. О какой проблеме речь?

Вот так обычно и отвечают, когда указываешь, что changelog какая то хрень.

P>> А вот как автоматизировать обработку changelog депенденсов 2го уровня — не ясно.

НС>Еще раз — 2 уровень заголовки тоже не отслеживают (если конечно ты не будешь эти заголовки пропогейтить по всей цепочке, что совсем уж дичь если сопоставить с исходной задачей).

Зачем пропагейтить? Делегируешь процессинг другому компоненту, он от себя будет кидать, что бы ничего не пропагейтить.

НС>Ты выкинь из головы все технические подробности и посмотри на проблему сверху. У тебя уже ровно в момент прихода реквеста непосредственно в сервис уже все известно и понятно.

Теоретически. Когда ты всё контролируешь, и ничего никому не делегируешь, то можно и заранее дать ответ. Но таких случаев не так уж и много. Варнинг можно интерпретировать мониторингом как на этой стороне, так и на той. И это может быть дешевле чем мастырить архитектуру поверх всего.

P>>>>Далее, при деплое зависимости 2го уровня могут малёха поменяться, так, по мелочи. Кто будет курить changelog n*m таких зависимостей?
НС>>>Заголовки тут не спасут.
P>>Это смотря как ты ими пользоваться будешь.

НС>Расскажи как.

Я уже рассказал и тебе, и точке.

Здравствуйте, ·, Вы писали:

P>>В том то и дело, что тесты её не показывают. Её можно увидеть только в рантайме, если есть. Ровно то же, что и трейсинг/логирование, только идет в обратную сторону.
·>"Не увидел" в том смысле, что ты не обозначил какую задачу мы решаем.

Ага, ты не увидел, следовательно, это другие не поднесли тебе на блюдечке под нос Тут похоже твои "особенности" чтения.

·>Ну трейсинг. И что дальше-то? Крутится где-то там у них ваш навязанный мониторинг, и всем пофиг что там всё красным моргает, никто туда не смотрит, ибо свои дела есть. "устал, много варнингов, (не)загляну в понедельник".

Если люди могут игнорировать даже мониторинг, то changelog, емейлы, логи будут игнорировать с еще большей вероятностью.

P>>Мониторинг уже протестировали. Остается кейс конкретного сервиса.
·>А кейс — по сути это конкретный сценарий, который надо задокументировать, имплементировать, протестировать и мейнтейнить. В чём автоматизация — неясно.

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

P>>Можно. Если ты точно знаешь, что у конечного сервиса есть все данные, что бы идентифицировать проблему, то можно и так. А если сервис не может этого сделать, надо бы делегировать обязанности тому, кто может, например, api gateway тот же.
·>Неясно каким волшебным образом, как ты обещаешь автоматически, это появится благодаря хедерам.

Ты или забыл, что такое мониторинг, или забыл, про что речь.

P>>Тебе ж уже сказали — http://rsdn.org/forum/design/8377498.1

Автор: maxkar
Дата: 06.10.22

·>Я не очень понял из этого ответа

Так возьми там же и уточни, это разве трудно?

Здравствуйте, Pauel, Вы писали:

P>>>В том то и дело, что тесты её не показывают. Её можно увидеть только в рантайме, если есть. Ровно то же, что и трейсинг/логирование, только идет в обратную сторону.
P>·>"Не увидел" в том смысле, что ты не обозначил какую задачу мы решаем.
P>Ага, ты не увидел, следовательно, это другие не поднесли тебе на блюдечке под нос Тут похоже твои "особенности" чтения.
Телепатией не обладаю.

P>·>Ну трейсинг. И что дальше-то? Крутится где-то там у них ваш навязанный мониторинг, и всем пофиг что там всё красным моргает, никто туда не смотрит, ибо свои дела есть. "устал, много варнингов, (не)загляну в понедельник".
P>Если люди могут игнорировать даже мониторинг, то changelog, емейлы, логи будут игнорировать с еще большей вероятностью.
Ага. Ты стал приходить к пониманию, что это проблема административная. Важна реакция людей, а не хедеры.
Теперь последний шаг. В чём будет выражаться неигнорирование мониторинга? Ну допустим заметил какой-нибудь сисоп какой-то варнинг на дашбоарде. Дальше-то что?

P>>>Мониторинг уже протестировали. Остается кейс конкретного сервиса.
P>·>А кейс — по сути это конкретный сценарий, который надо задокументировать, имплементировать, протестировать и мейнтейнить. В чём автоматизация — неясно.
P>В случае с changlog ты вообще всю работу делаешь руками. А в данном случае ты просто добавил правило в мониторинг и всё.
Какую "всю"? Для справки, сhangelog — это лог сделанных изменений.

P>>>Можно. Если ты точно знаешь, что у конечного сервиса есть все данные, что бы идентифицировать проблему, то можно и так. А если сервис не может этого сделать, надо бы делегировать обязанности тому, кто может, например, api gateway тот же.
P>·>Неясно каким волшебным образом, как ты обещаешь автоматически, это появится благодаря хедерам.
P>Ты или забыл, что такое мониторинг, или забыл, про что речь.
Речь про хедеры. Мониторинг это лишь твой риторический приём перевести обсуждение на другую тему. Ты рассказываешь про мониторинг, но никак не можешь объяснить, почему нужно мониторить именно хедеры, а не логи, например.

P>>>Тебе ж уже сказали — http://rsdn.org/forum/design/8377498.1

Автор: maxkar
Дата: 06.10.22

Сказали, кстати, не мне.

P>·>Я не очень понял из этого ответа
P>Так возьми там же и уточни, это разве трудно?
Ок, maxkar, прошу уточнить. А то Pauel и сам не знает, просто как cargo cult повторяет.

Здравствуйте, ·, Вы писали:

·>Ага. Ты стал приходить к пониманию, что это проблема административная. Важна реакция людей, а не хедеры.

Да ты я вижу Шерлок Холмс — вывел меня на чистую воду. Особенно с учетом того, что было явно обозначено, что проблема — админстративная.

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

Ты не в курсе как работает мониторинг и опсы?

P>>В случае с changlog ты вообще всю работу делаешь руками. А в данном случае ты просто добавил правило в мониторинг и всё.
·>Какую "всю"? Для справки, сhangelog — это лог сделанных изменений.

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

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

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

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

А где я написал, что не надо мониторить логи? Нам надо сообщить вызывающей стороне. У них нет доступа к твоим логами. Жесткий вариант — кидануть ошибку. Мягкий вариант — ворнинг. Его можно послать разными способами — городить архитектуру вида "мой человек свяжется с твоим человеком" или воспользоваться возможностями транспорта. Это возможно, если вызывающая сторона пользуется твоим клиентом. Тогда в ихних логах, и ихнем мониторинге тоже появятся нужные строчки.
То есть, в этом случае у нас хидер x-варнинг есть часть АПИ

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Можно ждать, пока огранизация станет идеальной (не станет).

НС>Не надо ждать идеала. Надо решить конкретную проблему административным способом — это быстрее, дешевле и не создает оверхеда в работающей системе.

Ога. У девелопера полномочий нет решать такие проблемы. Все что он может — написать кому то письмо. А дальше придет ответ "придумай решение сейчас, а налаживать коммуникацю наймем специалиста"
Вот так и появляется хидер x-варанинг

Здравствуйте, Pauel, Вы писали:

P>·>Ага. Ты стал приходить к пониманию, что это проблема административная. Важна реакция людей, а не хедеры.
P>Да ты я вижу Шерлок Холмс — вывел меня на чистую воду. Особенно с учетом того, что было явно обозначено, что проблема — админстративная.
Так и решать её надо административно. Хедер не может административную проблему решить.

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

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>>>·>Неясно каким волшебным образом, как ты обещаешь автоматически, это появится благодаря хедерам.
P>>>Ты или забыл, что такое мониторинг, или забыл, про что речь.
P>·>Речь про хедеры. Мониторинг это лишь твой риторический приём перевести обсуждение на другую тему. Ты рассказываешь про мониторинг, но никак не можешь объяснить, почему нужно мониторить именно хедеры, а не логи, например.

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

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

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

P>Жесткий вариант — кидануть ошибку.
Правильный вариант в SIT-окружении, как минимум.

P>Мягкий вариант — ворнинг. Его можно послать разными способами — городить архитектуру вида "мой человек свяжется с твоим человеком" или воспользоваться возможностями транспорта. Это возможно, если вызывающая сторона пользуется твоим клиентом.
P>Тогда в ихних логах, и ихнем мониторинге тоже появятся нужные строчки.
Сами — не появятся. Даже если появятся, всё равно самое важное, чтобы на них кто-то обратил внимание и принял соответствующие действия. Хедер ничего этого не даёт, с таким же успехом можно посылать лучи ненависти (лучи даже лучше, трафик не отожрут).

Здравствуйте, Pauel, Вы писали:

P>Ога. У девелопера полномочий нет решать такие проблемы.

Девелопер — понятие растяжимое. Если ты имел в виду программера — так он и не должен эти проблемы решать.

P> Все что он может — написать кому то письмо. А дальше придет ответ "придумай решение сейчас, а налаживать коммуникацю наймем специалиста"

Или не придет.

P>Вот так и появляется хидер x-варанинг

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

Здравствуйте, Pauel, Вы писали:

P>А разве я говорю что надо всенепременно именно варнинг добавить?

В топике зашла речь именно про него.

P> Если ты научился протаскивать капабилити с одним кастомным хидером

Пошли по кругу.

НС>>Еще раз — 2 уровень заголовки тоже не отслеживают (если конечно ты не будешь эти заголовки пропогейтить по всей цепочке, что совсем уж дичь если сопоставить с исходной задачей).
P>Зачем пропагейтить? Делегируешь процессинг другому компоненту, он от себя будет кидать, что бы ничего не пропагейтить.

Ничего не понял.

НС>>Ты выкинь из головы все технические подробности и посмотри на проблему сверху. У тебя уже ровно в момент прихода реквеста непосредственно в сервис уже все известно и понятно.
P>Теоретически.

И практически тоже.

P>Когда ты всё контролируешь,

Не надо контролировать все, надо контролировать свой собственный сервис и свои собственные логи, даши и алерты.

P>Варнинг можно интерпретировать мониторингом как на этой стороне, так и на той.

Можно не означает нужно.

P> И это может быть дешевле чем мастырить архитектуру поверх всего.

Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>В топике зашла речь именно про него.

Это просто пример кастомного хидера. Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi

P>>Зачем пропагейтить? Делегируешь процессинг другому компоненту, он от себя будет кидать, что бы ничего не пропагейтить.

НС>Ничего не понял.

Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.

P>>Теоретически.

НС>И практически тоже.

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

P>>Когда ты всё контролируешь,

НС>Не надо контролировать все, надо контролировать свой собственный сервис и свои собственные логи, даши и алерты.

Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы?

P>>Варнинг можно интерпретировать мониторингом как на этой стороне, так и на той.

НС>Можно не означает нужно.

Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно.

P>> И это может быть дешевле чем мастырить архитектуру поверх всего.

НС>Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры.

Ты сам привел пример, забыл?

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>Ога. У девелопера полномочий нет решать такие проблемы.

НС>Девелопер — понятие растяжимое. Если ты имел в виду программера — так он и не должен эти проблемы решать.

Именно. Потому ждать решения административных проблем на стороне разработчика смысла мало. Так и вижу "ребята, закончу фичу через пять лет, когда топ-менеджмент решит вон те вопросы"

P>> Все что он может — написать кому то письмо. А дальше придет ответ "придумай решение сейчас, а налаживать коммуникацю наймем специалиста"

НС>Или не придет.

Именно. В том то и проблема — большой менеджмент не обязан перед тобой отчитываться.

P>>Вот так и появляется хидер x-варанинг

НС>Да заради бога, каждый кузнец своего счастья. Но советовать такое другим ...

А кто тебе это советует? Это был пример, а не совет. Товарищи в апи протащили не только ошибки, но и варнинги.

Хорошая вещь — например тротлинг сопровождаешь ворнингом. Когда L2 суппорт на той стороне будет искать причину просадки, обязательно заглянет в хидеры

Здравствуйте, ·, Вы писали:

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

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

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>> У них нет доступа к твоим логами.
·>Дай доступ.

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

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

Тебе уже сказали, что все это уже есть. Снова нечитатель?

Здравствуйте, ·, Вы писали:

·>Ок, maxkar, прошу уточнить. А то Pauel и сам не знает, просто как cargo cult повторяет.
Да без проблем. Только я прекрасно вижу, что Pauel знает и понимает, что и зачем я предлагаю. Давайте в лицах. Pauel сделал API и предусмотрел в нем заголовок для предупреждений. Я в процессе чтения документации увидел этого заголовок и решил, что да — в целом идея хорошая. Добавил метрику. Добавление метрики — это дешево. У меня в любом случае будут метрики вокруг вызова внешних сервисов (время ответа, процент ошибок, распределение кодов ответа), еще один параметр проблемой не будет. И добавлю один график Warnings across team на dashboard команды (аггрегированый по всем сервисам). В один прекрасный день я получаю письмо от Pauel. Там написано что-то вроде "Мы сделали замечательный API /api/v22 и решили прекращаем поддержку существующего /api/v21 через 3 месяца. Соответствующее предупреждение W092 будет вовзрващаться при всех вызовах API /api/v21 со следующего понедельника.". Я на это письмо посмотрю и сборошу в "для информации". Ключевой момнет для меня там — я все равно увижу это в мониторинге. Я далеко не всегда хочу идти в Jira и сразу заводить тикет. Например, я жду ответа от внешнего поставщика услуг по актуальному вопросу. И не хочу тратить лишнее время на то, что не относится к текущей проблеме. А еще для одного из моих сервисов в Jira уже есть тикет на миграцию с deprecated API(s). И вот для этого сервиса можно было бы обновить сразу два API. Но для этого мне надо знать, что есть зависимость. А у меня голова на данный момент забита другими проблемами. Если что, на дашборд я не забуду посмотреть. Я туда хожу регулярно. Там можно много интересного увидеть. Например, что у нас регулярно нагрузка на сервис достигает 85% от того, что мы гоняли на тестах быстродействия. Стоило бы перетестировать под большую нагрузку. У одного из провайдеров ночью вырастает время ответа уже третью неделю. Надо-бы спросить их, что происхоидт. И появился новый warning. Этим warning мы займемся через неделю, у нас тогда запланированы "внутренние" технические работы (которые не business value). Более того, dashboard — одна из первых вещей, которые я смотрю после выхода из отпуска. Еще до того, как начинаю разбирать тысячу писем, скопившихся за месяц (тысяча — не преувеличение).

Вопрос не в том, что это можно решить административно. Вопрос в том, как это решить удобно. Причем удобно для широкого класса разработчиков. Кто-то будет реагировать на письмо. Другие — на предупреждения. У меня нет цели сделать все единообразно. Пусть каждый выбирает то, что лучше всего работает для его команды. Для меня jira — это так, хотелки. Их можно деприоритизировать. А вот метрики — это объективная реальность и показатель здоровья системы. Плюс подобные метрики асинхронны — система не требует "незамедлительного" внимания, переключения контекста и т.п.

Для контекста. Я предпочитаю культуру с высокой автономией команд. Команды имеют "общую" высокоуровневую цель, но при этом могут выбирать средства достижения с учетом своей предметной области и других факторов. На уровне компании мы хотим быстро развиваться и экспериментировать. Команды у нас взрослые. Они ответственно подходят к работоспособности своей системы. В результате этих факторов, у нас получается сложнее применять глобальные решения. Они неизбежно будут кому-то неудобны. Так что курс идет на автономию. И отсюда же дополнительные "механизмы безопасности" на случай человеческого фактора. На дороге в светлое будущее у нас безопасно не потому, что очень детальные правила дорожного движения. А потому, что с текущими средствами безопасности можно ехать быстро и не бояться разбиться.

Ну и исходная задача (я ее уже в общих чертах приводил). Есть сервис A. Он предоставляет /servicea/api/v1. В один прекрасный день команда реализует новый API /service/api/v2 и решает удалить /servicea/api/v1 через три месяца. Кроме того, у нас есть два других сервиса (разрабатываемых другими командами). Сервис Б последний раз деплоился полгода назад и с тех пор не менялся. Сервис В деплоится сейчас два раза в неделю. К сожалению, его команда на ближайший месяц занята своими задачами — удовлетрворяют новые требования законодательства. Так что в течение следующего месяца они так и продолжат использовать /servicea/api/v1. Задача — сделать такие механизмы, чтобы обе команды (Б и В) не забыли перейти на /servicea/api/v2 вовремя. Задача со звездочкой — сделать так, чтобы механизм был удобен и воспринимался естественно в рамках целей компании а не как очередной навязанный процесс. Вот вы что-то про тесты писали. Я совсем не понимаю, как они приблизят нас к решению задачи. Когда/почему будут выполняться тесты для сервиса Б? Как будет выглядеть использование deprecated api в процессе тестирования? Что должна делать команда В, которая осознанно использует deprecated API в течение некоторого времени?

Здравствуйте, ·, Вы писали:

·>Дай доступ. ... Терабайты съэкономишь.
Ой! Какой ужас, терабайты! Давайте посчитаем, сколько они стоят. Например, aws ec2 transfer. Самый дорогой — это первые 10Тб, отправленные в интернет. Стоит это 0.09 USD/GB. Т.е. 90 USD/TB. Это где-то 1.5-2 человекочаса. Если вдруг терабайт заголовков позволяет сэкономить 2 часа (суммарно) на координации, переключениях контекста и прочем обслуживании, мы остаемся в плюсе! Данный доступ — это плохое решение. Вместо того, чтобы иметь одну систему мониторинга (для своих сервисов) команда теперь будет вынуждена ходить в несколько различных — свою и каждой зависимости. На ровном месте мы чуть-чуть экономим на заголовках и создаем проблемы администрирования и координации!

Кроме того. Есть еще один замечательный момент. Заголовок с содержимым выглядит примерно так: "X-API-Warnings: W084,W092,W103". Округляя, 100 байт. В килобайте — 10 заголовков. В терабайте 10^10. (мега, гига, тера — 3*3 порядка). Допустим, команда все три месяца ничего не делала и перешла на новый API в последний момент. Т.е. 10^10 ответов было отправлено за 3 месяца. Это дает 10^10 / 3 / 30 / 24 / 60 / 60 = 1286 сообщений в секунду. Что-то мне кажется не очень выгодным тратить время команды, поддерживающей такую нагрузку, на административные задачи и координацию. Я думаю, разработчики будут гораздо более полезны на технических задачах и задачах бизнеса.

Что еще. Если у нас терабайты дополнительных заголовков, то логи не работают. Потому что логов тоже терабайты. Ну ладно, по сети они передаются сжатыми. Но обработка и хранение? Я пока не встречал ни одного предложения по обработке логов, где 1ТБ стоил бы всего 90 USD. Так что остаются только метрики. Для этого нам нужно идентифицировать клиентов. Здравствуйте, заголовки. И я уже упоминал сценарий, где несколько deployment unit являются частью одного сервиса и используют одни и те же credentials. Коллега тут предложил использовать "User-Agent". Ну т.е. заголовок. В каждом запросе (API Warnings ходят только там, где есть предупреждения). И по размеру обычно гораздо больше, чем те же коды предупреждений. И кто из нас экономит траффик?

Ну и потом, гоняться по разным Jira и системам за командами — то еще удовольствие. Ведь нужно не только поставить тикет. Нужно, чтобы его заметили нужные люди (я себе настраиваю так, чтобы digest новых тикетов отправлялся на почту каждый день, но далеко не все так делают). Нужно, чтобы не забыли. Особенно если сейчас они заняты другим. А вот постоянно горящая лампочка check engine api usage — хорошая напоминалка. И если команда пользователей делает лампочку сама, с большой вероятностью она окажется на приборной панели (на виду) а не где-нибудь под капотом (там, куда никто из команды не заходит).

Здравствуйте, 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>Тебе уже сказали, что все это уже есть. Снова нечитатель?
В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер?

Здравствуйте, Shmj, Вы писали:

S>

S>PUT /v1/orders/786706b8-ed80-443a-80f6-ea1fa8cc1b51

S>{
S>  "id": "786706b8-ed80-443a-80f6-ea1fa8cc1b51",
S>  "from": "Москва, ул. Садовническая набережная 82с2",
S>  "to": "Аэропорт Внуково"
S>}
S>

S>Какие минусы в этом?
Вообще говоря, мне не нравится вообще слово idempotency_key. ИМХО более общее будет request_uuid — я обычно так делаю.
Я бы API сделал примерно так:

PUT /v1/orders&request_uuid=86706b8-ed80-443a-80f6-ea1fa8cc1b51
{
  "from": "Москва, ул. Садовническая набережная 82с2",
  "to": "Аэропорт Внуково"
}

И в результате бы возвращал на клиент id (возможно uuid) с которым существующая запись вставилась, возможно с еще какой вспомогательной информацией. Например может

Или действительно возможно генерил бы id.

Вообще, при проектировании API основными критериями я считаю краткость, удобство и универсальность. Нужно заботиться о клиенте чтоб ему твоим API было пользоваться максимально комфортно. Параметр request_uuid близок к необходимому, ибо обеспечение идемпотентности в современных условиях практически необходимо, альтернативные решения все хуже (альтернативными решениями было бы либо забить на идемпотентность),либо городить какой либо кабздец вида API с методами bеgin_transaction commit_transaction rollback_transaction, либо еще какой лисапед кривой придумывать, request_uuid же это решение по умолчанию для мутаций о котором я давно уже даже не задумываюсь.

К спорным моментом можно отнести генерить ли ключи на клиенте. Конечно можно переложить это на клиент, но при этом следует понимать, что далеко не факт что клиенту этот сгенерированный uuid реально как то нужен. И чтоб разгрузить клиент от излишней логики, как раз имеет смысл это не делать, а вернуть уже uuid списком или через SSE. Не хочет клиент уведомления получать — пусть не получает, пусть только коды возврата проверяет, а общий список получает через GET /orders.

А так, клиенту один хрен с большой долей вероятностью захочется подписываться на SSE которые генерят другие пользователи, соответственно у него будут обязательства отображать новые сущность с новыми uuid — так нахрена клиента еще нагружать генерацией? Пусть пишет как меньше кода, самый минимум который возможен, и будет всем счастье!

Здравствуйте, maxkar, Вы писали:

M>·>Ок, maxkar, прошу уточнить. А то Pauel и сам не знает, просто как cargo cult повторяет.
M>Да без проблем. Только я прекрасно вижу, что Pauel знает и понимает, что и зачем я предлагаю. Давайте в лицах. Pauel сделал API и предусмотрел в нем заголовок для предупреждений. Я в процессе чтения документации увидел этого заголовок и решил, что да — в целом идея хорошая. Добавил метрику. Добавление метрики — это дешево. У меня в любом случае будут метрики вокруг вызова внешних сервисов (время ответа, процент ошибок, распределение кодов ответа), еще один параметр проблемой не будет. И добавлю один график Warnings across team на dashboard команды (аггрегированый по всем сервисам). В один прекрасный день я получаю письмо от Pauel. Там написано что-то вроде "Мы сделали замечательный API /api/v22 и решили прекращаем поддержку существующего /api/v21 через 3 месяца. Соответствующее предупреждение W092 будет вовзрващаться при всех вызовах API /api/v21 со следующего понедельника.". Я на это письмо посмотрю и сборошу в "для информации". Ключевой момнет для меня там — я все равно увижу это в мониторинге. Я далеко не всегда хочу идти в Jira и сразу заводить тикет.
Офигеть. Добавить тикет в джире это примерно 10 сек времени. И там же можно прописать due date чтобы в планировщик работ попало куда надо.

M>Например, я жду ответа от внешнего поставщика услуг по актуальному вопросу.
Э, и? Как это мешает завести джиру?!

M>И не хочу тратить лишнее время на то, что не относится к текущей проблеме. А еще для одного из моих сервисов в Jira уже есть тикет на миграцию с deprecated API(s).
Добавь sub-task туда или тупо коммент (если, конечно, due date совпадают).

M> И вот для этого сервиса можно было бы обновить сразу два API. Но для этого мне надо знать, что есть зависимость. А у меня голова на данный момент забита другими проблемами.
Ну потом проанализируешь джиру и пропишешь связи между тасками.

M>Если что, на дашборд я не забуду посмотреть. Я туда хожу регулярно. Там можно много интересного увидеть. Например, что у нас регулярно нагрузка на сервис достигает 85% от того, что мы гоняли на тестах быстродействия. Стоило бы перетестировать под большую нагрузку. У одного из провайдеров ночью вырастает время ответа уже третью неделю. Надо-бы спросить их, что происхоидт.
Это просто мониторинг, и к обсуждаемому хедеру отношения не имеет. Наличие мониторинга не оправдывает добавление хедера.

M>И появился новый warning. Этим warning мы займемся через неделю, у нас тогда запланированы "внутренние" технические работы (которые не business value). Более того, dashboard — одна из первых вещей, которые я смотрю после выхода из отпуска. Еще до того, как начинаю разбирать тысячу писем, скопившихся за месяц (тысяча — не преувеличение).
Ну во-первых, эти емейлы должен читать не один человек, а команда.
Во-вторых, всё просто: пришел емейл, создал джиру, ответил на емейл, что мол, ясно, спасибо, джира создана, сообщим когда сделаем. Всё, будет на виду, в нужном фильтре тикетов с due date. Если емейл потеряется, то отправитель будет чейсить или ескалайтить.
В-третьих, следить за емейлами и джирой можно поручить более дешевому сотруднику. Ты вообще можешь этим не заниматься.
И не забывай, тебе придётся джиру создать в любом случае, вне зависимости есть у тебя хедер или нет. И чейсить и эскалайтить тоже надо будет, т.к. наличие хедера ни к чему обязать не может, и код сам не напишется.

Кстати, если команды работают близко, то они вообще друг-другу джиры могут создавать и видеть что в каком состоянии.

M>Вопрос не в том, что это можно решить административно. Вопрос в том, как это решить удобно. Причем удобно для широкого класса разработчиков. Кто-то будет реагировать на письмо. Другие — на предупреждения. У меня нет цели сделать все единообразно. Пусть каждый выбирает то, что лучше всего работает для его команды. Для меня jira — это так, хотелки. Их можно деприоритизировать. А вот метрики — это объективная реальность и показатель здоровья системы. Плюс подобные метрики асинхронны — система не требует "незамедлительного" внимания, переключения контекста и т.п.
В метрике, например, не будет информации о сроках. Что один API надо проапгрейдить обязательно через 3 месяца, а другой можно на следующий год отложить. И взаимосвязи работ нет. И вообще много чего нет, что может быть в банальном емейле.

M>Для контекста. Я предпочитаю культуру с высокой автономией команд. Команды имеют "общую" высокоуровневую цель, но при этом могут выбирать средства достижения с учетом своей предметной области и других факторов. На уровне компании мы хотим быстро развиваться и экспериментировать. Команды у нас взрослые. Они ответственно подходят к работоспособности своей системы. В результате этих факторов, у нас получается сложнее применять глобальные решения. Они неизбежно будут кому-то неудобны. Так что курс идет на автономию. И отсюда же дополнительные "механизмы безопасности" на случай человеческого фактора. На дороге в светлое будущее у нас безопасно не потому, что очень детальные правила дорожного движения. А потому, что с текущими средствами безопасности можно ехать быстро и не бояться разбиться.
Философия какая-то, неясно причём тут хедер.

M>Ну и исходная задача (я ее уже в общих чертах приводил). Есть сервис A. Он предоставляет /servicea/api/v1. В один прекрасный день команда реализует новый API /service/api/v2 и решает удалить /servicea/api/v1 через три месяца. Кроме того, у нас есть два других сервиса (разрабатываемых другими командами). Сервис Б последний раз деплоился полгода назад и с тех пор не менялся. Сервис В деплоится сейчас два раза в неделю. К сожалению, его команда на ближайший месяц занята своими задачами — удовлетрворяют новые требования законодательства. Так что в течение следующего месяца они так и продолжат использовать /servicea/api/v1. Задача — сделать такие механизмы, чтобы обе команды (Б и В) не забыли перейти на /servicea/api/v2 вовремя. Задача со звездочкой — сделать так, чтобы механизм был удобен и воспринимался естественно в рамках целей компании а не как очередной навязанный процесс.

Это чисто административная и организационная проблема. Хедер эту задачу не поможет решить. Абсолютно никак.

M>Вот вы что-то про тесты писали. Я совсем не понимаю, как они приблизят нас к решению задачи. Когда/почему будут выполняться тесты для сервиса Б? Как будет выглядеть использование deprecated api в процессе тестирования?
Про тесты писал Pauel, как обычная попытка подменить тему обсуждения.

M>Что должна делать команда В, которая осознанно использует deprecated API в течение некоторого времени?
Договориться с командой A о сроках вывода из эксплуатации.