Про одного CTO

Неделю назад наткнулся на канал одного CTO. Там он хвастается своим опытом: в одной из компаний за год работы техдиром результат - собрали команду в 100+ человек, поменяли процессы и переписали все на микросервисы. Читаю и понимаю, что что-то мне тут не нравится.

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

Во-первых

Ни о чем хорошем оно тоже, само по себе, не говорит. Потому что результаты - это про цель, а микросервисы, процессы и команда - это про путь. И если вы шли быстро, но не туда, то результата не будет, будет только путь, как у самурая. Короче, если уж вы CTO, то в результатах указывайте именно результаты работы, а не средства их достижения.

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

Во-вторых

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

1. Микросервисы.

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

То есть микросервисы должны позволить команде разрабатывать, тестировать и выкатывать доработки БЕЗ синхронизации с другими командами. Поэтому границы микросервисов = границы команды. То есть, в общем случае, на одну команду достаточно одного микросервиса.

Либо, если несколько доменов, то по количеству доменов. Просто потому что, если ничего общего нет, то непонятно, зачем оно должно быть в одном сервисе. Для примера: в приложении доставки еды сервис оформления заказов пользователем и сервис изменения меню рестораном - это разные поддомены и разные сервисы. Пример из жизни: сейчас наша команда считается помойкой доменов, куда можно скинуть все, что другим негоже. Поэтому у нас уже 5 доменов и, получается, 5 сервисов. И на подходе ещё 2.

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

Поэтому, в лучшем случае, в большинстве микросервисных архитектур требуется слепить часть микросервисов в сервисы побольше. В худшем: слепить всё и разлепить по-другому.

2. Процессы.

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

Цель внедрения процессов очевидна:
- Для прозрачности работы от исполнителей требуется отчётность и метрики. Например: задачки в жире, трекинг времени и статусов, обязательные артефакты в конфлюенс, обязательные оценки на полгода вперёд;
- Для снижения рисков устанавливаются дополнительные контрольные процедуры. Например, блокирующее ревью безопасником.
- Для снижения рисков сужаются полномочия. Например, отбираются доступы.
- Для равномерного распределения однообразной работы по специалистам и обмена компетенциями узкие специалисты собираются в команды. Например: команда девопс, команда тестирования, команда дба.
- Для согласованности действий подразделений планируются координационные мероприятия: рабочие группы, статусы и прочее.