Здравствуйте, 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 вовремя. Задача со звездочкой — сделать так, чтобы механизм был удобен и воспринимался естественно в рамках целей компании а не как очередной навязанный процесс. Вот вы что-то про тесты писали. Я совсем не понимаю, как они приблизят нас к решению задачи. Когда/почему будут выполняться тесты для сервиса Б? Как будет выглядеть использование deprecated api в процессе тестирования? Что должна делать команда В, которая осознанно использует deprecated API в течение некоторого времени?
Это чисто административная и организационная проблема. Хедер эту задачу не поможет решить. Абсолютно никак.

Здравствуйте, 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 о сроках вывода из эксплуатации.