Видео выступления Сергея Лукина «Документирование микросервисов на примере LeanlX» с ArchDays 2020
https://youtu.be/wIJpumyG8qQ

Видео выступления Филиппа Уварова «Краткая история Event Delivery в Spotify»
https://youtu.be/e0TC5Qef78E

​​Краткое сравнение SOA и микросервисов от infopulse

Видео выступления Ильи Волынкина «Как сделать SaaS для анализа переписки, который не страшно использовать?»
https://youtu.be/FPmCLxkc2AM

Видео выступления Максима Цепкова «Модели приложения для разных парадигм программирования»
Тот самый доклад про гномиков 🙂
https://youtu.be/AkUMSyapP6E

Сделал редирект на канал ArchDays в youtube c http://archdays.ru/youtube/
Теперь делится ссылкой на канал станет проще.

А странно в этой истории то, что все условия для того, чтобы сделать человеческий урл, вроде /archdays на самом youtube все условия уже год как выполнены, но google по неизвестной причине не дает возможность этого сделать, поддержка молчит. Если кто-то знает, как решить проблему (обложка есть, лого есть, подписчиков > 600) – напишите в комментариях, буду признателен за помощь.

Терминология istio

Архитектура istio

istio: data plane и control plane

Статейка вышла по итогам моего выступления на TechLeadConf про Event Storming и микросервисы: https://m.habr.com/ru/company/oleg-bunin/blog/537862/

Само видео тут: https://www.youtube.com/watch?v=cG9DVbcPc9M

Для микросервисной архитектуры жизненно-важным является наличие DevOps-культуры. При этом эту культуру пытаются как-то измерить, но чаще пытаются измерить производительность команд, нередко, чтобы сравнивать между собой (facepalm).
По мне так это странный способ и сами три пути DevOps и принципы CALMS дают ответ на то, что следует измерять, а в книге Accelerate так вообще все раскладывается по полочкам.
Посмотрим на измерение важных вещей в трех измерениях:
1. Outcomes на уровне компании
2. Здоровье команд
3. Компетенции

Почему именно эти срезы? В чем-то это моя любимая фрактальная структура. Outcome (так я не нашел достойного перевода этому термину для отделения от output и result, можете предложить вариант в коментариях), так вот, outcome на уровне компании — это результат работы команд, состоящих из людей, обладающий нужными компетенциями на необходимом уровне.

Далее по-порядку:

Метрики уровне компании, мой перевод из отчета State of DevOps 2019

Подробнее про эти метрики

Время внесения изменений (Lead Time)
Сколько времени требуется для поставки фичи, от начала и до конца. С этим могут быть сложности, иногда упрощают от pull request’а до клиента.

Частота развертываний (Deployment Frequency)
Количество поставок на прод в единицу времени. Для повышения частоты развертываний нередко все начинается с декомпозиции большой задачи на более мелкий, автономные, отвечающие критериям INVEST (https://www.agilealliance.org/glossary/invest/)

Процент отказов при изменениях (change-fail rate)
Процент поставок, приведших к падению сервиса от общего числа поставок.

Среднее время восстановления (Mean time to restore, MTTR)
За какое время в среднем восстанавливаем упавший сервис. Обычно выясняем в рамках post-mortem. Это интересная метрика, потому что монолитных системах нередко акцент идет на метрику MTBF (Mean time between failure - среднее время между сбоями). Это по-прежнему важная метрика, а для ряда классов систем прям вот сильна важная, но в распределенных системах, микросервисных, мы принимаем, что падать будет и будет падать часто, поэтому на MTBF смотреть можем, но важнее стремиться к сокращению MTTR. Быстро поднятое не считается упавшим 🙂

Лучшая метрика здоровья команды — это обратная связь от её членов и между её членами. Все в том же отчете State of DevOps 2019 приведены основные факторы, влияющие на производительность поставки и на продуктивность. И там и там есть такой фактор, как психологическая защищенность. Это убеждение, что никто не будет наказан или унижен за высказывание идей, вопросов, опасений или ошибок. В 2015-м году Google провел внутреннее исследование 180-и команд, пытаясь выяснить, что делает команды более или менее эффективными. Исследование показало, что психологическая безопасность — одна из пяти базовых основ высокоэффективных команд. При этом — самая важная. В такой культуре люди фидбечат свободно, принимают фидбек, меняют что-то и у них просто не остается поводов для конфликтов (гипотетически) и остается куча энергии и времени на решение крутых задач.

Например, вот что влияет на производительность поставки. Жирным выделены статистически самые важные аспекты.

Напоминаю, что для общения есть чат, в котором всегда помогут делом и словом :)

@microservices_ru

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

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

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

Что получаем: обоснование в необходимости развития тех или иных компетенций и текущий уровень несоответствия. Последним заполняем столбец «Действия» — как будем экпертизу получать.

Важно, чтобы по итогам заполнения «Действий» появились реальные Action Items — зарегистрироваться на курс, написать коллеге письмо, сходить в соседний проект в понедельник и так далее. И самое важное — завести регулярную встречу, на которое отслеживать прогресс (5-10 минут в неделю бывает достаточно).

Микросервисная среда — весьма динамична. Поэтому так важно выбрать полезные метрики и непрерывно разивать свои скилы, скилы команды, тем самым усиливая её. Это компас нашей производственной системы.

Матрица компетенций в CircleCI: https://docs.google.com/spreadsheets/d/131XZCEb8LoXqy79WWrhCX4sBnGhCM1nAIz4feFZJsEo/edit#gid=0

Микросервисы - это не только технологии, это еще и люди и команды их разрабатывающие. Завтра будет бесплатный митапчик по дизайну команд. Да, там не будет про технологии, но технологии у нас в сердцах и головах, а ведь немаловажно с кем мы плечом к плечу микросервисы пилим :)

Кому интересно, ссылочка: https://agilerussia.timepad.ru/event/1539341/