Крутая штука, да еще и свежак.
Atomic Microservices Transactions with MongoDB Transactional Outbox
Диспетчер цепляется к change stream монги и слушает инсерты в outbox. Это позволяет слать в брокер события из outbox в режиме реального времени 😍
Правда, придется вендорлокнуться на монгу, так как change stream фича монги. Есть еще пара минусов, они в статье.
https://blog.insiderattack.net/atomic-microservices-transactions-with-mongodb-transactional-outbox-1c96e0522e7c
Atomic Microservices Transactions with MongoDB Transactional Outbox
Диспетчер цепляется к change stream монги и слушает инсерты в outbox. Это позволяет слать в брокер события из outbox в режиме реального времени 😍
Правда, придется вендорлокнуться на монгу, так как change stream фича монги. Есть еще пара минусов, они в статье.
https://blog.insiderattack.net/atomic-microservices-transactions-with-mongodb-transactional-outbox-1c96e0522e7c
Medium
Atomic Microservices Transactions with MongoDB Transactional Outbox
Atomic Transactions with Polled Outbox
Вот есть действительно сложная система. Сложный домен. Банковский, ритейл, логистика, телеком. Действительно сложные системы состоят из большого количества интегрированных компонентов.
Одни компоненты критичны для бизнеса, другие являются поддерживающими.
Если границы компонентов - технологические, то как вы определите, какие из компонентов являются бизнес-критическими?
Неявным маркером того, что границы технические, является существование компонентных команд. Выглядит это примерно так: у того, кто отвечает за развитие продукта появляется стратегическая инициатива, он садится с кем-нибудь (аналитик/архитектор) и смотрит, в какой десяток-другой систем нужно внести изменения. Немного логики в интеграционной шине, немного логики в одной процедуре в базе, немного логики в другой процедуре в базе, а вот изменение способа коммуникации с клиентом, ага, нужно изменить компонент отправки уведомлений, 4 компонента в CRM….
Остановимся на уведомлениях.
Есть такой закон, 161-П, статья 9.3, банк обязан уведомлять клиента о движении денежных средств. В какой-то момент статья изменилась, теперь банк обязан уведомлять в соответствии с договором… но суть не в этом.
Технологичный, универсальный компонент отправки уведомлений. Если он отправляет 500 различных уведомлений (с днем рождения, с 8 марта, спасибо за покупку) по 5 каналам (смс, пуши, почта, звонок …) и среди этих уведомлений есть одно обязательное, критичное для бизнеса, то компонент автомагически становится бизнес-критическим, хотя бизнес-критичного в нем три копейки. Но вот у него уже совсем иной SLA, статус… ну вы поняли, он стал «золотым» в развитии, тестировании и поддержке.
То же самое происходит, когда вы вносите в интеграционную шину бизнес-логику. Команда шины развивает техническую интеграцию, появление в ней бизнес-логики означает, что теперь есть бизнес-логика, за которую особо никто не отвечает, даже если она бизнес-критичная, но наличие бизнес-критичной логики в паре методов возводит саму шину в сан бизнес-критичных.
Ну и самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:
1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/технологически/как пришлось
3. От критичного бизнес-компонента (логическая абстракция) в каждом техническом компоненте по 20% логики
4. Все 100% всех пяти компонентов становятся бизнес-критичными
В микросервисах решение этой проблемы лежит буквально в основе самого подхода, но нельзя забывать о том, что унаследованные, монолитные системы ведь тоже живут в этом же домене, в этой же предметной области и они точно так же поддаются проектированию с учетом предметной области.
Основной тезис в том, что даже если вы пошли в модульный монолит (внутренняя модульность), не забывайте о границах самого монолита, в масштабах крупной и сложной системы корректировка этих границ даст больший эффект для всей организации.
Одни компоненты критичны для бизнеса, другие являются поддерживающими.
Если границы компонентов - технологические, то как вы определите, какие из компонентов являются бизнес-критическими?
Неявным маркером того, что границы технические, является существование компонентных команд. Выглядит это примерно так: у того, кто отвечает за развитие продукта появляется стратегическая инициатива, он садится с кем-нибудь (аналитик/архитектор) и смотрит, в какой десяток-другой систем нужно внести изменения. Немного логики в интеграционной шине, немного логики в одной процедуре в базе, немного логики в другой процедуре в базе, а вот изменение способа коммуникации с клиентом, ага, нужно изменить компонент отправки уведомлений, 4 компонента в CRM….
Остановимся на уведомлениях.
Есть такой закон, 161-П, статья 9.3, банк обязан уведомлять клиента о движении денежных средств. В какой-то момент статья изменилась, теперь банк обязан уведомлять в соответствии с договором… но суть не в этом.
Технологичный, универсальный компонент отправки уведомлений. Если он отправляет 500 различных уведомлений (с днем рождения, с 8 марта, спасибо за покупку) по 5 каналам (смс, пуши, почта, звонок …) и среди этих уведомлений есть одно обязательное, критичное для бизнеса, то компонент автомагически становится бизнес-критическим, хотя бизнес-критичного в нем три копейки. Но вот у него уже совсем иной SLA, статус… ну вы поняли, он стал «золотым» в развитии, тестировании и поддержке.
То же самое происходит, когда вы вносите в интеграционную шину бизнес-логику. Команда шины развивает техническую интеграцию, появление в ней бизнес-логики означает, что теперь есть бизнес-логика, за которую особо никто не отвечает, даже если она бизнес-критичная, но наличие бизнес-критичной логики в паре методов возводит саму шину в сан бизнес-критичных.
Ну и самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:
1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/технологически/как пришлось
3. От критичного бизнес-компонента (логическая абстракция) в каждом техническом компоненте по 20% логики
4. Все 100% всех пяти компонентов становятся бизнес-критичными
В микросервисах решение этой проблемы лежит буквально в основе самого подхода, но нельзя забывать о том, что унаследованные, монолитные системы ведь тоже живут в этом же домене, в этой же предметной области и они точно так же поддаются проектированию с учетом предметной области.
Основной тезис в том, что даже если вы пошли в модульный монолит (внутренняя модульность), не забывайте о границах самого монолита, в масштабах крупной и сложной системы корректировка этих границ даст больший эффект для всей организации.
Микросервисы / распределенные системы
Крутая штука, да еще и свежак. Atomic Microservices Transactions with MongoDB Transactional Outbox Диспетчер цепляется к change stream монги и слушает инсерты в outbox. Это позволяет слать в брокер события из outbox в режиме реального времени 😍 Правда,…
Вдогонку реализация tx outbox для azure cosmos db
https://docs.microsoft.com/en-us/azure/architecture/best-practices/transactional-outbox-cosmos
За ссылку спасибо @dpr_dev
https://docs.microsoft.com/en-us/azure/architecture/best-practices/transactional-outbox-cosmos
За ссылку спасибо @dpr_dev
Наткнулся. Оффтопик, но пожалуй оно стоит того, чтобы запостить сюда :)
— Гендальф! – перекрикивая рев орков позвал Арагорн, – Остановись, планерка!
– Что? – удивился волшебник сбавляя темп бега.
– Планерка!
– Вы с ума сошли?! За нами гонятся орки! Давайте потом…
– Планерка проводится каждое утро! – менторским тоном перебил догнавший их мужчина.
Едва он успел договорить, как в него врезался Гимли, пачка хоббитов и Боромир. Только Леголас сумел затормозить перед неожиданно возникшим препятствием.
– Мы стоим на мосту посреди пропасти и за нами гонятся все орки Мории! Нет времени на планерку! – возмутился Гендальф.
– Я Энеджер, сын Менеджера, брат Инвестора, владыка Канбана! – стряхнув с себя хоббитов и приняв властную позу заявил мужчина, – Властью данной мне Эмбиеем объявляю планерку! И должен сразу отметить, Гендальф, что для планерки время есть всегда! Итак, первый вопрос для обсуждения. За нами гонятся орки, как мы пришли к такому, очевидно не устраивающему нас результату? Я не устану напоминать, что необходимо регулярно проводить мониторинг и корректировать наши действия соответственно полученным результатам.
Все молчали, нервно переглядываясь и прислушиваясь к реву, отражающемуся от сводов подземелья.
– Тук уронил ведро в колодец, нашумел, это услышали орки и подняли тревогу… – стал нетерпеливо объяснять Арагорн, но его прервал Энеджер.
– Не так токсично! Легко сваливать ответственность на другого! Лучше скажи как ты лично связан с этим результатом! Мы команда и каждый внес свой вклад в то, чтобы возникла такая ситуация. Ответственность и планирование!
– Я… Ну…
– Если мы будем тут стоять, то нас прибьют орки! – воззвал к голосу разума Гендальф.
– Самое простое – это лихорадочно бегать! – возразил Энеджер, – И я понимаю, почему инвесторы прислали меня чтобы усилить вашу команду. Очевидно раньше вы вообще не занимались планированием! Очевидно, что сейчас проект идет не совсем так, как было задумано.
– Да нет же!
– То есть забеги по подземельям с орками – это часть проекта? Можно посмотреть документацию?
– Нет, просто такое случается иногда! – заорал Арагорн.
– У меня нет. – возразил Энеджер, – Итак, очевидно нам надо немного подкорректировать проект в соответствии с нынешней ситуацией. Я изучил все данные, произвел расчеты и стало очевидно, что вы поставили перед собой слишком амбициозную задачу.
– И что? – хором спросили все.
– Нужно представить инвесторам новый план. Опять таки, я все посчитал. Мы уже потратили больше ресурсов чем планировали. А в график не укладываемся. Предлагаю отказаться от нереализуемых пунктов плана и сделать только то, что реально. Но четко к сроку.
Все непонимающе переглянулись. Леголас задумчиво пристрелил подбегающего к ним орка.
– И что конкретно мы должны сделать? – поинтересовался Гендальф.
– Я все посчитал. До Мордора мы не успеем добраться, а вот до Лориена вполне.
– Но нам же надо отнести его в Мордор! — возразил Арагорн.
– Слишком большие риски, да и все уже идет не по плану! Нужно смотреть на вещи реально! – возразил Энеджер.
– Но кольцо можно уничтожить только в Мордоре! У нас нет выбора!
– Не берите на себя слишком большую ответственность. – успокоил всех Энеджер, – Просто делайте свое дело. Решено, мы дойдем до Лориэна. И отчитаемся о проделанной работе. Как минимум 50% проекта мы реализуем. Это лучше, чем завалить все, не так ли? Управление рисками.
– И что дальше? – не понял Гендальф.
– Ну, нужно будет провести стратсессию, составить дорожную карту, привлечь консультантов и понять как отнести кольцо в Мордор. Да и нужно ли вообще нести.
– Что значит нужно ли? – нахмурился Гендальф.
– Вин-вин, всегда есть место сотрудничеству, понимаете?
Гендальф посмотрел на Арагорна. Тот кивнул.
– Ну что же, думаю можем продолжать двигаться. Объявляю планерку завершенной. Давайте побыстрее перейдем этот мост. А то как бы нас орки не догнали. Да и хлипковато выглядит эта конструкция, если честно.
Братство кольца с облегчением рвануло по мосту. Все кроме Гендальфа. Он придержал за локоть Энеджера, подождал пока все остальные удалятся и заглянув ему в глаза сказал.
– Ты не пройдешь.
— Гендальф! – перекрикивая рев орков позвал Арагорн, – Остановись, планерка!
– Что? – удивился волшебник сбавляя темп бега.
– Планерка!
– Вы с ума сошли?! За нами гонятся орки! Давайте потом…
– Планерка проводится каждое утро! – менторским тоном перебил догнавший их мужчина.
Едва он успел договорить, как в него врезался Гимли, пачка хоббитов и Боромир. Только Леголас сумел затормозить перед неожиданно возникшим препятствием.
– Мы стоим на мосту посреди пропасти и за нами гонятся все орки Мории! Нет времени на планерку! – возмутился Гендальф.
– Я Энеджер, сын Менеджера, брат Инвестора, владыка Канбана! – стряхнув с себя хоббитов и приняв властную позу заявил мужчина, – Властью данной мне Эмбиеем объявляю планерку! И должен сразу отметить, Гендальф, что для планерки время есть всегда! Итак, первый вопрос для обсуждения. За нами гонятся орки, как мы пришли к такому, очевидно не устраивающему нас результату? Я не устану напоминать, что необходимо регулярно проводить мониторинг и корректировать наши действия соответственно полученным результатам.
Все молчали, нервно переглядываясь и прислушиваясь к реву, отражающемуся от сводов подземелья.
– Тук уронил ведро в колодец, нашумел, это услышали орки и подняли тревогу… – стал нетерпеливо объяснять Арагорн, но его прервал Энеджер.
– Не так токсично! Легко сваливать ответственность на другого! Лучше скажи как ты лично связан с этим результатом! Мы команда и каждый внес свой вклад в то, чтобы возникла такая ситуация. Ответственность и планирование!
– Я… Ну…
– Если мы будем тут стоять, то нас прибьют орки! – воззвал к голосу разума Гендальф.
– Самое простое – это лихорадочно бегать! – возразил Энеджер, – И я понимаю, почему инвесторы прислали меня чтобы усилить вашу команду. Очевидно раньше вы вообще не занимались планированием! Очевидно, что сейчас проект идет не совсем так, как было задумано.
– Да нет же!
– То есть забеги по подземельям с орками – это часть проекта? Можно посмотреть документацию?
– Нет, просто такое случается иногда! – заорал Арагорн.
– У меня нет. – возразил Энеджер, – Итак, очевидно нам надо немного подкорректировать проект в соответствии с нынешней ситуацией. Я изучил все данные, произвел расчеты и стало очевидно, что вы поставили перед собой слишком амбициозную задачу.
– И что? – хором спросили все.
– Нужно представить инвесторам новый план. Опять таки, я все посчитал. Мы уже потратили больше ресурсов чем планировали. А в график не укладываемся. Предлагаю отказаться от нереализуемых пунктов плана и сделать только то, что реально. Но четко к сроку.
Все непонимающе переглянулись. Леголас задумчиво пристрелил подбегающего к ним орка.
– И что конкретно мы должны сделать? – поинтересовался Гендальф.
– Я все посчитал. До Мордора мы не успеем добраться, а вот до Лориена вполне.
– Но нам же надо отнести его в Мордор! — возразил Арагорн.
– Слишком большие риски, да и все уже идет не по плану! Нужно смотреть на вещи реально! – возразил Энеджер.
– Но кольцо можно уничтожить только в Мордоре! У нас нет выбора!
– Не берите на себя слишком большую ответственность. – успокоил всех Энеджер, – Просто делайте свое дело. Решено, мы дойдем до Лориэна. И отчитаемся о проделанной работе. Как минимум 50% проекта мы реализуем. Это лучше, чем завалить все, не так ли? Управление рисками.
– И что дальше? – не понял Гендальф.
– Ну, нужно будет провести стратсессию, составить дорожную карту, привлечь консультантов и понять как отнести кольцо в Мордор. Да и нужно ли вообще нести.
– Что значит нужно ли? – нахмурился Гендальф.
– Вин-вин, всегда есть место сотрудничеству, понимаете?
Гендальф посмотрел на Арагорна. Тот кивнул.
– Ну что же, думаю можем продолжать двигаться. Объявляю планерку завершенной. Давайте побыстрее перейдем этот мост. А то как бы нас орки не догнали. Да и хлипковато выглядит эта конструкция, если честно.
Братство кольца с облегчением рвануло по мосту. Все кроме Гендальфа. Он придержал за локоть Энеджера, подождал пока все остальные удалятся и заглянув ему в глаза сказал.
– Ты не пройдешь.
В техническом компоненте у вас будет time2prod environment
В бизнес-компоненте к нему прибавится time2market (потому что дорога к рынку - это еще и маретологи, реклама, контент, позиционирование)
В бизнесе как таковом, явно или неявно, интересен time2value.
По сути это синоним LeadTime из Lean.
И как же сильно его не хотят замерять :)
Ну а что, вот у нас три команды, сервисы пилят, очень понятный у них output - написать код и в отправить в прод.
А как мы «требование» придумываем, анализируем, подтверждаем, выделяем, убеждаем - «вы не понимаете, это другое».
А это не другое :)
В этом процессе отношение времени разработки ко всему остальному в пределе может стремиться к нулю, и если это так, то разработка - не то, с чего имеет смысл начинать.
Был кейс с запросом на переход на микросервисы. Тайм2маркет сократить. Провел предварительный аудит-исследование. Баги пролетали от своего появления в джире до прода за пару дней, максимум 3-4 дня. А вот то, что действительно важно, что позволяет зарабатывать больше и у чего максимальный потенциал - от задумки до прода 2-3 месяца. Из них разработка - около 2-х недель (спринт). Разработка - около 15% времени. Решать проблему хотели переходом на микросервисы, оставим мотивацию за скобками.
Правда, тут один нюанс. Посмотрите внимательно на описанный кейс. Без изменения процесса (от идеи до получения клиентом ценности) с переходом на микросервисную(или любую другую) архитектуру, изменится ли time2value?
В бизнес-компоненте к нему прибавится time2market (потому что дорога к рынку - это еще и маретологи, реклама, контент, позиционирование)
В бизнесе как таковом, явно или неявно, интересен time2value.
По сути это синоним LeadTime из Lean.
И как же сильно его не хотят замерять :)
Ну а что, вот у нас три команды, сервисы пилят, очень понятный у них output - написать код и в отправить в прод.
А как мы «требование» придумываем, анализируем, подтверждаем, выделяем, убеждаем - «вы не понимаете, это другое».
А это не другое :)
В этом процессе отношение времени разработки ко всему остальному в пределе может стремиться к нулю, и если это так, то разработка - не то, с чего имеет смысл начинать.
Был кейс с запросом на переход на микросервисы. Тайм2маркет сократить. Провел предварительный аудит-исследование. Баги пролетали от своего появления в джире до прода за пару дней, максимум 3-4 дня. А вот то, что действительно важно, что позволяет зарабатывать больше и у чего максимальный потенциал - от задумки до прода 2-3 месяца. Из них разработка - около 2-х недель (спринт). Разработка - около 15% времени. Решать проблему хотели переходом на микросервисы, оставим мотивацию за скобками.
Правда, тут один нюанс. Посмотрите внимательно на описанный кейс. Без изменения процесса (от идеи до получения клиентом ценности) с переходом на микросервисную(или любую другую) архитектуру, изменится ли time2value?
Технические зависимости (на уровне данных и интерфейсов) сложно разорвать в том числе из-за отсутствия бизнес-семантики. На основе технической зависимости мы может только сделать вывод о ее наличии, но не можем определить, должна она присутствовать по бизнес-контексту или нет.
Материалы с Service-Oriented Computing 19th International Conference, ICSOC 2021 🧐
https://link.springer.com/content/pdf/10.1007%2F978-3-030-91431-8.pdf
https://link.springer.com/content/pdf/10.1007%2F978-3-030-91431-8.pdf
Всех девушек поздравляю с 8 марта! 🌹
Счастья, добра, любви, мира, крепких связей и надежных людей рядом! 🌟🌻☀️
Счастья, добра, любви, мира, крепких связей и надежных людей рядом! 🌟🌻☀️
vuca&bani.pdf
62.2 KB
Пару лет назад составил себе шпаргалку по VUCA и BANI.
VUCA - модель описания происходящего для принятия решений (sense-making framework), появившаяся в 1987.
Несколько лет назад была предложена новая модель описания – BANI. Она описывает ситуации, в которых условия не просто нестабильны, – они хаотичны. В которых результаты не просто трудно предвидеть, они совершенно непредсказуемы. Или, если использовать язык этих фреймворков, ситуации, когда то, что происходит, не просто двусмысленно (не определено; ambiguous), оно непостижимо.
Делюсь заметками. Считаю, что VUCA актуальна, а BANI рассматриваю как гипотезу.
Все свойства прекрасно перекладываются на архитектуру, особенно на распределенную. В жизни же возможность разложить ситуации по свойствам модельки – это та самая работа с атрибутами качества и стратегиями их достижения, фундамент работы архитектора.
VUCA - модель описания происходящего для принятия решений (sense-making framework), появившаяся в 1987.
Несколько лет назад была предложена новая модель описания – BANI. Она описывает ситуации, в которых условия не просто нестабильны, – они хаотичны. В которых результаты не просто трудно предвидеть, они совершенно непредсказуемы. Или, если использовать язык этих фреймворков, ситуации, когда то, что происходит, не просто двусмысленно (не определено; ambiguous), оно непостижимо.
Делюсь заметками. Считаю, что VUCA актуальна, а BANI рассматриваю как гипотезу.
Все свойства прекрасно перекладываются на архитектуру, особенно на распределенную. В жизни же возможность разложить ситуации по свойствам модельки – это та самая работа с атрибутами качества и стратегиями их достижения, фундамент работы архитектора.
Микросервисы / распределенные системы
vuca&bani.pdf
Вообще, Крис Ричардсон назвал VUCA одним из трендов, которые привели к появлению микросервисов: https://chrisrichardson.net/post/microservices/2020/02/18/why-microservices-part-1.html
Компании сегодня должны быть гораздо более гибкими и внедрять инновации гораздо быстрее. А поскольку инновационные продукты и услуги основаны на программном обеспечении, IT должны выпускать ПО гораздо быстрее, чаще и надежнее.
Одна из причин, по которой производительность IT коррелирует с производительностью бизнеса, заключается в том, что чем меньше время внесения изменений и чем выше частота развертываний, тем больше и чаще проходят эксперименты, направленные на поиск функциональности, увеличивающей доход.
Микросервисы+DevOps нам все это дают.
Компании сегодня должны быть гораздо более гибкими и внедрять инновации гораздо быстрее. А поскольку инновационные продукты и услуги основаны на программном обеспечении, IT должны выпускать ПО гораздо быстрее, чаще и надежнее.
Одна из причин, по которой производительность IT коррелирует с производительностью бизнеса, заключается в том, что чем меньше время внесения изменений и чем выше частота развертываний, тем больше и чаще проходят эксперименты, направленные на поиск функциональности, увеличивающей доход.
Микросервисы+DevOps нам все это дают.
Подробно про дебаг ошибок, связанныз с SSL-сертификатами.
https://www.netmeister.org/blog/debugging-certificate-errors.html
https://www.netmeister.org/blog/debugging-certificate-errors.html
В open source решениях находят все больше политической малвари. По ссылке – пополняемый список.
Рекомендуется отключить обновления apt, rpm, brew, npm и так далее для latest версий.
https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview
Рекомендуется отключить обновления apt, rpm, brew, npm и так далее для latest версий.
https://docs.google.com/spreadsheets/d/1H3xPB4PgWeFcHjZ7NOPtrcya_Ua4jUolWm-7z9-jSpQ/htmlview
ECommerce Microservices is a fictional eCommerce, based on different software architecture and technologies like Microservices Architecture, Vertical Slice Architecture, CQRS pattern, Domain Driven Design, Event Driven Architecture, Inbox and Outbox Pattern and using Postgres for write side and MongoDb for read side and etc.
https://github.com/mehdihadeli/e-commerce-microservices
https://github.com/mehdihadeli/e-commerce-microservices
Гипотезу Данбара про 150 контактов опровергли.
https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
Опровержение научное, наборы данных общедоступны. Опровергнуть удалось за счет использования современных вычислительных мощностей, которые были недоступны во время, когда Данбар формулировал свою гипотезу.
Почему это важно?
В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.
В итоге выяснилось, что одним числом показатели выразить невозможно, даже границы (от и до) кол-ва приятельских отношений (те самые 150) определить статистически не удалось, там от нуля и до неизвестно скольки сверху.
В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
https://royalsocietypublishing.org/doi/10.1098/rsbl.2021.0158
Опровержение научное, наборы данных общедоступны. Опровергнуть удалось за счет использования современных вычислительных мощностей, которые были недоступны во время, когда Данбар формулировал свою гипотезу.
Почему это важно?
В последние годы один из популярных подходов для проектирования продуктовой структуры под решение на микросервисах — Team Topologies, в основе которого как раз лежит гипотеза Данбара о том, что мы можем поддерживать не более пяти глубоких (интимных) дружеских отношений, примерно 150 приятельских контактов, но можем знать имена до 1500 человек.
В итоге выяснилось, что одним числом показатели выразить невозможно, даже границы (от и до) кол-ва приятельских отношений (те самые 150) определить статистически не удалось, там от нуля и до неизвестно скольки сверху.
В общем, эти выводы ставят под сомнение опирающиеся на число Данбара структуры в Team Topologies и Agile Release Train в Scaled Agile. Это не означает, что они неверные или не эффективные, это лишь означает, что одна из гипотез, лежащих в основе формирования структур опровергнута, что открывает для нас простор для экспериментов и улучшений.
Про метрики
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDANCE_20220301.PDF
906.6 KB
Свеженький гайд по безе подъехал