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

P>>Между административной и технической нет четкой границы. Конторы решают эти вопросы так, как могут, насколько позволяет бюджет, и тд и тд.
P>>Административные вопросы большей частью автоматизируются, что есть решение техническими способами.
·>Верно. Но ты почему-то настаиваешь, что именно одно конкретное техническое решение позволяет решить административную проблему, а остальные, почему-то не позволяют.

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

> Важен способ как применено техническое решение, а не решение само по себе. Если мониторинг есть, но за ним не следят или игнорируют — такая же беда, как и игнорирование емейлов|джиры|whatever.

Мониторинг так устроен, что за ним легче следить, чем за потоком емейлов. И емейлы могут перестать ходить по чисто человеческим причинам, что регулярно бывает.

P>>Именно. И это наименьшее предположение, которое можно сделать. А вот ожидать, что диспетчеры емейлов будут реагировать оперативно 24/7 — это чудовищно большое предположение.
·>У тебя эти же диспечеры сидят на шаге 7-8.

Твои диспетчеры нужны только для того, что бы найти ту самую L2 команду. И дальше они форвардят емейл L2 команде. В моем случае 6 и 8 это l2 команда, а фунукции диспетчеризации автоматизированы.
Это что, так трудно понять?

P>>Ты предложил диспетчеризацию емейлов переложить на некую команду. Вот её и надо тестировать. А если ты решишь автоматизировать такую деятельность, то внезапно окажется так, что автоматизировать емейлы окажется неффективным, т.к. и так слишком много рисков.
·>Не очень ясно что такое "тестировать команду". Как вы тестируете свой L2 или девелоперов-менеджеров?

Очень даже понятно — инструктаж, обучение, контроль, метрики типа "время обработки одного емейла". Например L1 суппорт, а твои диспетчеры это чтото навроде L1, именно так и работают.

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

И это проблема. Клиент, у которого нет планов на передеплоймент, нет бюджета, нет команды, вдруг получил емейл. И что ему делать?
Через полгода это появилось. Им что, шерстить емейлы за полгода на предмет "а не было ли чего нибудь важного" от N вендоров API?

А вот если они теперь попытаются передеплить, то с варнингами их ждет отлуп.

P>>во вторых, команда из 5 человек в пересчете на зп, налоги и прочие издержки, типа запасные игроки, и тд, съест намного бОльшее количество денег, чем добавление правила в мониторинг и покрытие интеграционными тестами
·>Если в твоём приложении 1000 зависимостей, то значит у тебя уже довольно сложная система и там только девов будет десятки-сотни. +5 человек это будут доли процента от бюджета.

Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.

P>>·>Ты почему-то предполагаешь, что на каждый response с варнингом надо посылать емейл. Нет, надо один емейл на каждый случай изменения функционирования в сервисе. Т.е. кол-во емейлов в худшем случае пропорционально кол-ву релизов сервиса.
P>>Во первых, один емейл спокойно может затеряться по целому ряду причин — вся твоя цепочка зависит от человеческого фактора.
·>chase&escalate.

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

P>>В третьих, в твоем варианте нет возомжности
P>>1 запретить передеплоймент, например, старого клиента — только вручную "эй, не надо деплоить вон те версии, смотрите еще один список версий в другой рассылке полгода назад"
·>404. Т.к. мы уже подтвердили голосом-емейлом, что чуваки окончательно зарелизились и избавились от старого клиента.

Голосом-емейлом такое не подтверждается. Подтверждают только логи и метрика "вызовы старого апи" == 0 за последние 3 месяца.

P>>2 ограничить трафик от старых клиентов — вообще никак
·>А как хедеры ограничат трафик от старых клиентов?

Тебе уже рассказывали, но ты или не понимаешь, или не читаешь. Элементарно — есть хидер, делаем тротлинг.

P>>И хидеры точно так же не уронят прод. Это нормальная фича в хттп апи, response headers, и мониторинг, логирование, итд умеют с этим справляться.
·>Надеюсь. Впрочем, я говорил о риске, а не о свершившемся событии. Емейлы не уронят прод, т.к. в принципе уронить прод не могут. А хедеры у вас не роняют прод, т.к. вы делаете всё без багов и хедеры ваши все баги гарантировано находят.

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

P>>Более того, именно вызывающая сторона должна решать, что ей делать со странной ситуацией.
·>Хедер, как механизм спихнуть проблемы на клиента — вещь замечательная, но почему-то мне кажется, что это не самое правильное отношение к клиентам.

Наоборот — именно клиент знает, как быть в случае той или иной ситуации. А обрубать внезапно, рубильником, только что 200, через секунду — 404 это далеко не самая лучшая стратегия.

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

У нас кейс — не дать задеплоить приложение, которое использует депрекейтед апи. Ты читать то собираешься начать?

·>Я не очень понял зачем гонять тесты в проде, но это не важно. Ты сам утвержал, что тесты в проде используют специальные аккаунты-настройки-етс. Следовательно можно просто отдавать 400 вместо варнинга для тестов и не полагаться на корректность ассертов на стороне консьюмеров; это гораздо надёжнее и проще.

1 Снова у тебя проблема с ассертами. Ассерты должны быть на стороне сервера апи. Они говорят о том, что клиент делает чтото непотребное.
2 тесты прода на той стороне используют те же самые эндпойнты, конфиги и тд, будут разве что тестовые юзеры. Собственно тест прода — это тест сразу после деплоймента прода. Разница меньше некуда — только что какой нибудь тестовый юзерский аккаунт.

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

Алё — проблемы у вызывающей стороны, которую ты не контролируешь. С твоим продом всё в порядке.

P>>В твоем случае был один емейл полгода назад. И что? Я вот вижу, что игнор емейлов существует чуть ли не во всех крупных конторах.
·>chase&escalate.

Общие слова. Что сейчас делать, писать всем диспетчерам "эй, ребята, а не было ли у вас важного письма для нас за последние полгода?"