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

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

И с емейлом ровно то же — шлешь емейл и даже не в курсе, дойдет ли он, будет ли он прочитан вовремя, будет ли прочитан вообще.
Разница только в том, что решение на хидерах позволяет автоматизировать весь цикл траблшутинга. А вот с емейлами такого хоть тресни, не будет. Емейлы хорошо работают только в идеальном мире.

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

Это именно что закон природы, т.к. в разных конторах ситуация примерно одна и та же.

P>>Это что, так трудно понять?
·>Мне трудно понять почему это у вас является проблемой, несмотря на то, что ты сам рассказал, что у вас уже есть все трейсы и даже доступ к чужим логам.

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

P>>Очень даже понятно — инструктаж, обучение, контроль, метрики типа "время обработки одного емейла". Например L1 суппорт, а твои диспетчеры это чтото навроде L1, именно так и работают.
·>Это не тестирование. Ну по крайней мере в общепринятом понимании этого термина. Но впрочем, надёжная возможность трейсить запросы, контролируемая QA, конечно, нужна. И ты заявлял, что она у вас уже есть тоже. Следовательно ничего нового к вашему решению с хедерами добавлять не приходится.

Именно, что ничего нового к решению с хидерами добавлять не нужно. А вот с твоей командой нужны особые приседания приседания
1. понанимать людей в разных таймзонах, сиречь в разных странах
2. понанимать запасных
3. обучить
4. приставить менеджера, который будет обслуживать эту команду

Все нормальные конторы стараются избавлятся от таких команд, заменяя их на автоматические решения. Может вам курьеров нанять, что бы почту носили, понадёжнее всё таки

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

Именно!

P>>А вот если они теперь попытаются передеплить, то с варнингами их ждет отлуп.
·>Зачем они что-то будут пытаться передеплоить?

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

P>>Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.
·>5 человек это по одному челу в каждой tz и пара прозапас на случай отпусков/етс.

И это только для того, что бы емейлы добирались до нужных людей

P>>Подробно расскажи, как обнаружить неполученное письмо, особенно, если ты не знаешь, а было ли оно послано.
·>Посмотреть ли был у емейла reply.

Похоже, ты вообще не читаешь Еще раз — у тебя inbox пустой. Как узнать, а он и должен быть пустым или там должны быть письма(те что потерялись)?

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

Это минимальное предположение — что люди будут следовать простым инструкциям. Т.е. предполагаем, что сотрудники добросовестные, а не саботёры.

С емейлами надо предположить наличие цельной команды в разных часовых поясах, запасных людей на бенче и менеджер-два которые обслуживают её.

P>>А как этот кейс будет выглядеть с емейлами? Полагаю "каждые полчаса узнавать у диспетчеров, а не пропустили ли они что нибудь важное?"
·>Поизучай как строятся надёжные процессы в message-driven системах.

То есть, тебе нечего сказать

P>>Голосом-емейлом такое не подтверждается. Подтверждают только логи и метрика "вызовы старого апи" == 0 за последние 3 месяца.
·> А потом они внезапно переключатся на DR-сайт, а там они забыли что-то проапдейтить.

Внезапно никто не переключается.

·>Нет уж, логи могут лишь поддтвердить, что "вызовы старого апи" == 0 за последние 3 месяца, что очень важно для какого-нибудь сервиса, который работает раз в квартал. И всё.
·>И для этого хедеры не нужны. Нужны только логи.

С чего ты взял, что раз в квартал? Снова с потолка?

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

Именно. А тротлинг включается при наличии хидера. Об этом тебе уже говорили.

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

Наоборот — хидеры позволяют автоматизировать чуть не всё, навесить дополнительные капабилити, типа того же тротлинга, мониторинга, логов и тд и тд и тд.
Соответсвенно, лампочка в мониторинге загорится сразу. А в твоём случае — может да, может нет. Может сейчас. А может когда менеджер той команды кому то пистон вставит.

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

Вы там похоже тем и заняты, что обрубаете тесты "а они только время тратят"

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

И после деплоя, и после изменений у 3rd-party, инфраструктуры, и даже в моменты пиковой нагрузки.

P>>1 Снова у тебя проблема с ассертами. Ассерты должны быть на стороне сервера апи. Они говорят о том, что клиент делает чтото непотребное.
·>404 это тоже сторона сервера.

Это неприемлемо для консумера.

P>>2 тесты прода на той стороне используют те же самые эндпойнты, конфиги и тд, будут разве что тестовые юзеры. Собственно тест прода — это тест сразу после деплоймента прода. Разница меньше некуда — только что какой нибудь тестовый юзерский аккаунт.
·>Whatever. Вот для тестовых юзеров и возвращайте 4xx.

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

·>Это потому что ты бессовестно спихнул проблему на вызывающую сторону.

А мне кажется, что ты своими емейлами делаешь именно это — используешь заведомо ненадежный канал.

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

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

И с емейлом ровно то же — шлешь емейл и даже не в курсе, дойдет ли он, будет ли он прочитан вовремя, будет ли прочитан вообще.
Разница только в том, что решение на хидерах позволяет автоматизировать весь цикл траблшутинга. А вот с емейлами такого хоть тресни, не будет. Емейлы хорошо работают только в идеальном мире.

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

Это именно что закон природы, т.к. в разных конторах ситуация примерно одна и та же.

Свежий пример — несколько не мог восстановить доступ к фейсбуку, т.е. их емейл до меня тупо недоходил. У них — фейсбук, у меня — gmail. Даже обращение в суппорт не помогало. Разрешилось чисто случайно — по прошествии N лет я вдруг начал получать спам от фейсбука. Попробовал ресетнуть пароль и сразу же увидел их письмо в инбоксе.
Вот так работает твой емейл. Кого винить — фейсбук, gmail, еще кого — без понятия.

P>>Это что, так трудно понять?
·>Мне трудно понять почему это у вас является проблемой, несмотря на то, что ты сам рассказал, что у вас уже есть все трейсы и даже доступ к чужим логам.

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

P>>Очень даже понятно — инструктаж, обучение, контроль, метрики типа "время обработки одного емейла". Например L1 суппорт, а твои диспетчеры это чтото навроде L1, именно так и работают.
·>Это не тестирование. Ну по крайней мере в общепринятом понимании этого термина. Но впрочем, надёжная возможность трейсить запросы, контролируемая QA, конечно, нужна. И ты заявлял, что она у вас уже есть тоже. Следовательно ничего нового к вашему решению с хедерами добавлять не приходится.

Именно, что ничего нового к решению с хидерами добавлять не нужно. А вот с твоей командой нужны особые приседания приседания
1. понанимать людей в разных таймзонах, сиречь в разных странах
2. понанимать запасных
3. обучить
4. приставить менеджера, который будет обслуживать эту команду

Все нормальные конторы стараются избавлятся от таких команд, заменяя их на автоматические решения. Может вам курьеров нанять, что бы почту носили, понадёжнее всё таки

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

Именно!

P>>А вот если они теперь попытаются передеплить, то с варнингами их ждет отлуп.
·>Зачем они что-то будут пытаться передеплоить?

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

P>>Ты путаешь команду разработки и команду эксплуатации. Эти диспетчеры есть часть команды эксплуатации, работают 24/7.
·>5 человек это по одному челу в каждой tz и пара прозапас на случай отпусков/етс.

И это только для того, что бы емейлы добирались до нужных людей

P>>Подробно расскажи, как обнаружить неполученное письмо, особенно, если ты не знаешь, а было ли оно послано.
·>Посмотреть ли был у емейла reply.

Похоже, ты вообще не читаешь Еще раз — у тебя inbox пустой. Как узнать, а он и должен быть пустым или там должны быть письма(те что потерялись)?

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

Это минимальное предположение — что люди будут следовать простым инструкциям. Т.е. предполагаем, что сотрудники добросовестные, а не саботёры.

С емейлами надо предположить наличие цельной команды в разных часовых поясах, запасных людей на бенче и менеджер-два которые обслуживают её.

P>>А как этот кейс будет выглядеть с емейлами? Полагаю "каждые полчаса узнавать у диспетчеров, а не пропустили ли они что нибудь важное?"
·>Поизучай как строятся надёжные процессы в message-driven системах.

То есть, тебе нечего сказать

P>>Голосом-емейлом такое не подтверждается. Подтверждают только логи и метрика "вызовы старого апи" == 0 за последние 3 месяца.
·> А потом они внезапно переключатся на DR-сайт, а там они забыли что-то проапдейтить.

Внезапно никто не переключается.

·>Нет уж, логи могут лишь поддтвердить, что "вызовы старого апи" == 0 за последние 3 месяца, что очень важно для какого-нибудь сервиса, который работает раз в квартал. И всё.
·>И для этого хедеры не нужны. Нужны только логи.

С чего ты взял, что раз в квартал? Снова с потолка?

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

Именно. А тротлинг включается при наличии хидера. Об этом тебе уже говорили.

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

Наоборот — хидеры позволяют автоматизировать чуть не всё, навесить дополнительные капабилити, типа того же тротлинга, мониторинга, логов и тд и тд и тд.
Соответсвенно, лампочка в мониторинге загорится сразу. А в твоём случае — может да, может нет. Может сейчас. А может когда менеджер той команды кому то пистон вставит.

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

Вы там похоже тем и заняты, что обрубаете тесты "а они только время тратят"

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

И после деплоя, и после изменений у 3rd-party, инфраструктуры, и даже в моменты пиковой нагрузки.

P>>1 Снова у тебя проблема с ассертами. Ассерты должны быть на стороне сервера апи. Они говорят о том, что клиент делает чтото непотребное.
·>404 это тоже сторона сервера.

Это неприемлемо для консумера. Если можно кидать ошибки направо-налево, оно конечно просто — консумер сам винова. Штука в том, что 60-70% приложений это старые приложения, деплоились вообще хрен знает когда. Ломать крайне нежелательно.

P>>2 тесты прода на той стороне используют те же самые эндпойнты, конфиги и тд, будут разве что тестовые юзеры. Собственно тест прода — это тест сразу после деплоймента прода. Разница меньше некуда — только что какой нибудь тестовый юзерский аккаунт.
·>Whatever. Вот для тестовых юзеров и возвращайте 4xx.

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

·>Это потому что ты бессовестно спихнул проблему на вызывающую сторону.

А мне кажется, что ты своими емейлами делаешь именно это — используешь заведомо ненадежный канал.