Трагедия в трех актах

Спринт 0

- Коллеги, добрый день! Как вы уже знаете, в рамках проекта "Человек" наша команда будет заниматься разработкой системы потребления питательных веществ. Это новый для нас челледж, но работаем стандартно: аджайл, двухнедельные спринты, оценка в попугаях, отдельной квоты на техдолг пока нет, но это не значит, что его не нужно делать. Считаю, что все понятно, можем приступать.

- А что делать-то? В смысле, задачу уже кто-то проработал? Есть бизнес-требования?

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

Команда мощно провела серию митингов по грумингу, брейнштормингу, коддингу, токингу и чилингу. Проработала системную и техническую архитектуру под хайлоад. Подготовила статьи в конфлюенсе и забукала время на архмитинге (+100500 человек на встрече) для презентации решения.

- Мы подготовили схему архитектуры Nutrients Consuming Service, прошу высказываться.

- Куда планируете разворачиваться?
- В кубер. Сервис легко масштабируется как в рамках одного, так и в рамках нескольких ЦОДов.
- Понятно, спасибо.

- Какой протокол для API планируется?
- У нас хайлоад сервис, и мы за экономию трафика, поэтому gRPC.
- Понятно, спасибо.

- Ну, если больше вопросов нет, будем считать, что решение принято...
- А можно коротенько уточнить по процессу, а то не совсем понятно для чего этот сервис?
- Да, конечно. Это сервис потребления питательных вещество в рамках проекта "Человек". На вход подаются растворенные питательные вещества, асинхронно передаются в компоненту обработки, которая сохраняет их в БД. Для внешних потребителей предоставляется апи.
- Если правильно помню... но это не точно... питательные вещества могут быть не только растворенными, это как-то учитывается в текущем решении или в следующих версиях? Может уточнить этот момент?
- На текущий момент подобных бизнес-требований не было. К тому же сервис нужен асап хотя бы в формате эмвипи. Да и квартал подходит к концу, оценка на носу, мы уже не успеем внести существенных изменений, либо придется переносить задачу на следующий квартал. Но спасибо за вопрос, мы это уточним, зафиксируем в техдолг.

Спринт 1

- Коллеги, приветствую! Все молодцы, хорошо сработали. Сервис запущен в прод, сроки соблюдены, ттм на должном уровне, параллельные команды уже работают над интеграциями с нашим сервисом. Появились уточнения от бизнес-аналитиков, которые упустили при релизации эмвипи: питательные вещества могут быть не только растворенные. Поэтому в рамках текущего спринта работаем в данном направлении.

Очередной пример командной работы: груминг, брейншторминг, коддинг, токинг, чилинг. Обновлена документация, забукан архмитинг.

- Согласно новым бизнес-требованиям доработали архитектуру сервиса потребления питательных веществ: теперь наш сервис умеет не только в растворенные, но и в не растворенные питательные вещества. Это позволило значительно расширить функциональные возможности, что в свою очередь позитивно скажется на бизнесе. Обновленная схема:

- На данной схеме брокер сообщений подразумевается на разных кластерах или это будут разные топики на одном кластере?
- Пока мы ориентируемся на разные кластера, т.к. это позволит более оперативно управлять нагрузкой.
- Понятно, спасибо.

- Команда разработки сервиса предварительной обработки питательных веществ задизайнила единый интерфейс для растворенных и не растворенных питательных веществ, а на вашей схеме это разные компоненты. Надо с ними синкнуться по этому поводу.
- Мы исходили из того, что проектируем микросервисную архитектуру, поэтому такое разделение. Обсудим с ними, чтобы они добавили компоненту распределения. Спасибо за комментарий, очень важно.
- Боюсь, что у них ресурса на ближайшие пару спринтов нет. У них комментарии от ИБ по поводу какой-то имунной системы. Там еще непонятно будут они сами писать или интегрировать внешнее решение.
- Ну что же, все как обычно... придется пока своими силами закрыть вопрос, добавим на схему.

- Может стоит реализовать единый слой хранения и апи?
- Не нужно раньше времени идти в оптимизацию. Это разные потоки: растворенные и не растворенные питательные вещества, используются они скорее всего по-разному. Ну и управление нагрузкой опять же в данном варианте более гибкое.
- Понятно, спасибо.

Спринт 2

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

Груминг, брейншторминг, коддинг, токинг, чилинг, документация, архмитинг.
- В целях минимизации негативных рисков мы добавили на схему компоненту утилизации питательных веществ. Это позволит потенциально сэкономить бизнесу приличные деньги за счет уменьшения сроков хранения. Отразили на схеме: 

- А что такое Morbo?
- Это компонента утилизации. Наш тимлид вспомнил, что в футураме так звали одного уничтожителя, поэтому так и назвали.
- Может стоит назвать что-то вроде Disposal Component?
- Уже в документации везде указали Morbo, архвижену соответствует, все привыкли… запишем как техдолг на обсуждение, но явно пока не приоритетно.
- Окей.

- По информации от операционного департамента сроки и процессы использования растворенных и не растворенных питательных веществ отличаются. Может быть следует реализовать разные компоненты утилизации?
- Думаю, что это усложнит дальнейшую поддержку, т.к. количество компонент такими темпами будет расти просто неконтролируемо. Мы давно обсуждали подобные вопросы, но видимо эволюционным путем добрались до этапа добавления статусной модели в наш сервис. Конечно, мы еще обсудим это с бизнес-оунерами, но предварительно статусная модель будет очень простая, главное не усложнять: новый, в работе, потреблен, на удаление. Это позволит управлять разными питательными веществами с помощью единых механик.
- Очень элегантное решение, спасибо.
- Благодарю Вас, коллеги, за очень ценные комментарии, которые способствуют дальнейшему улучшению нашего сервиса.