Часть 1
Вернемся к аналогии с мидлами и джунами - мы получили задачу и сразу в голове можем накидать примерный алгоритм решения этой проблемы? Тут либка, тут новый класс, асинхронную джобу можно отдать стажеру, пусть покайфует.
Будучи техлидом, мы открываем таск трекер, а там что-то типа "Сделать с нуля систему рекомендаций для корзины". Ну и типа все. Когда-то добавили эту задачку в бэклог, забыли, и вот по сути этот эпик добрался до проектов в Q3 (как раз сейчас конец сентября). Ничего дополнительного, никаких подсказок. Очевидно, что бизнес чего-то ожидает, и скорей всего, что система будет "быстрой, надежной и масштабируемой". Ну типа как и всегда должно быть.
Что на этом моменте зависит от нас? Мы старте принимаем архитектурное решение, последствия которого могут повлиять на масштабы предполагаемого труда в виде обычных тасок и фантомного сейчас, но материального в будущем техдолга. Будет ли команда его разгребать месяцами, если не годами - на все это мы можем повлиять в этой самой точке.
Простого решения через чтение блогов от пацанов с Netflix'а уже недостаточно. Наша задача здесь превратить неопределенность в обсуждаемый и верифицируемый план (по сути определение неопределенности, или другими словами стратегия). Это и есть наш архитектурный фундамент. Давайте его зальем.
1️⃣Нефункциональные требования
Идем и собираем от своих продактов и заказчиков их неокторые абстрактные пожелания. Далее все эти хотелки мы переводим в
То есть первостепенно нам нужно перевести бизнес-требования на язык измеряемых инженерных метрик. Это называется формализацией нефункциональных требований (Non-Functional Requirements). Без них любое архитектурное решение может быть субъективно (однозначно) и оторвано от метрик.
Какие могут быть типичные примеры
▫️"Система должна быть быстрой" → "99-й перцентиль (p99) времени ответа для эндпоинта /api/v0.1/recommendations должен быть не более 300 мс"
▫️"Система должна быть надежной" → "Доступность сервиса (Availability) должна составлять 99.99% (это допустимые ~52.6 минуты простоя в год). Время восстановления после сбоя (MTTR) - не более 5 минут"
▫️"Система должна выдерживать нагрузку в пик спроса" → "Система должна обрабатывать до 5000 RPS (requests per second) без деградации времени ответа"
Тут же задаем вопросы:
▫️Как мы поймем, что достигли успеха?
▫️Что произойдет, если ответ будет идти 1 секунду вместо 100 мс?
Эти цифры (SLO — Service Level Objectives) станут нашим главным критерием при выборе между Kafka и RabbitMQ, монолитом и микросервисами, SQL и NoSQL.
2️⃣Дизайн-док
"Помните, 2 года назад мы решили использовать FastApi, потому что REST был слишком медленным?» - рассказывает синьор на встрече. В ответ - тишина. Никто не помнит, скорее никого еще в компании на тот момент не было. Решение на словах, дальше рифму не знаю, но вы поняли.
Внедряем культуру RFC (Request for Comments) или Architecture Design Document. Делаем вид, что это не бюрократия, но в реале это нам потом поможет, и не раз. Ведь архитектура - это по сути одни компромиссы.
Предполагаемая структура:
✏️Проблема - что мы решаем и для кого? Какие NFRs мы должны удовлетворить?
✏️Альтернативы - другие 2-3 реалистичных подхода. Например, рекомендации популярного, алгоритм на factorization matrix, ARGUS
✏️Решение - детальное описание выбранного варианта. Вот прям схемы, диаграммы последовательности, API контракты
✏️Трейдоффы - почему предлагаемое решение лучше других в нашем контексте? Какие у него минусы?
Мы собираем коллективно этот документ. Одновременно даем автору глубоко продумать все аспекты, и с командой одновременно челленджим через асинхронный фидбек. При необходимости можем восстановить ход мыслей через пару лет, не отвлекая синьоров на встречах.
@teamleadosh
#career