Мы написали идеальный Design Doc. Все согласились и разошлись по задачам в своих зонах ответственности
Пошла
Проходит пару месяцев, ну ладно, полгода. Мы заглядываем в код и видим, что модуль domain почему-то напрямую лезет в Redis. Новый микросервис должен был быть независимым, но в коде намертво завязан на базу данных соседа. А если вечером в пятницу вечером все ебанет, то может пройти много времени до выяснения, в каком из пяти сервисов произошел сбой.
Что случилось? Случилась реальность
Чертеж - это не здание. Самая лучшая архитектура бесполезна, если она не воплощается в коде и не поддерживается со временем. Наша задача здесь не стоять над душой у каждого разработчика, а выстроить систему, которая будет сама следить за здоровьем архитектуры.
Что делаем:
1️⃣Архревью
Словосочетание «архитектурное ревью» может ассоциироваться с душной комнатой, где самые суровые эксперты унижают менее суровых. Нам по сути нужно превратить ревью из карательного органа в регулярный и совместный процесс поиска «слепых зон».
▫️Выделяем один час в неделю на "Design Review". Это открытая встреча, куда любой разработчик может принести свой Design Doc для обсуждения до написания основного объема кода.
▫️Цель - помочь улучшить решение. Не токсичим, а задаем правильные вопросы: "А что если этот сервис ляжет?", "Как мы будем это масштабировать через год?"
▫️Создаем коллективную ответственность. Если решение окажется топовым, то затащил не автор, а вся команда, которая его обсуждала. Также и наоборот, главное не пережестить, иначе будет страшно пробовать новые подходы.
Здесь ревью выполняет не только типичную свою функцию, но и способствует обучению и синхронизации команды - это дает возможность думать о системе в целом.
2️⃣Автотесты
Тут это еще до нас придумали наши деды. Делаем проверки в CI/CD-пайплайне - автоматизированные тесты, которые проверяют соблюдение наших архитектурных принципов:
▫️Проверка зависимостей - тест, который падает, если код из слоя domain пытается импортировать что-то из слоя infrastructure
▫️Проверка на утечки или ограничения - никто не ходит в базу данных напрямую, либо в коде нет чьих-то токенов или SECRET_KEY. Подробнее тут
▫️Проверка NFRs - нагрузочный тест, который падает, если p99 времени ответа ключевого эндпоинта превышает установленный нами SLO (например, 300 мс)
▫️Проверка контрактов - убедиться, что два микросервиса по-прежнему понимают API друг друга. Подробнее тут
Здесь мы за счет тестов убеждаемся в том, что абстрактные правила из Design Doc будут работать в коде.
3️⃣Мониторинг
Если в час ночи сервисы упали, то спокойный техлид спокойно открывает ноутбук, а чуть менее спокойный уже успевает поднять на ноги синьора. Проблема в том, что ни синьору, ни нам условные 50 дашбордов с графиками не помогут быстро локализовать проблему. Наблюдаемость (Observability) - это не фича, которую можно прикрутить потом, это фундаментальное свойство архитектуры.
Наша задача как техлида на каждом Design Review получить ответ на три момента:
▫️Список метрик. Как мы поймем, что этот сервис здоров и работает? Какие ключевые бизнес и технические метрики? Например, количество запросов, время ответа, процент ошибок
▫️Структура логов. Это чтобы понимать, почему происходят ошибки. Логи должны быть структурированными (например, в JSON), содержать айдишники для отслеживания запроса и иметь достаточно контекста для диагностики
▫️Трассировка запросов для микросервисов. Понять, где именно завис запрос, который проходит через три сервиса. Подробнее тут
Просто берем и настраиваем дашборды, алерты и трассировки сразу с выкаткой основной фичи.
Короче, на уровне техлида важно уже построение отказоустойчивой системы не только в коде, но и в процессах. Что делать дежурному, какие мероприятия проводить при алертах. Когда откатываться к прошлому релизу и от кого получить ОКи.
То есть создаем самодиагностирующую и саморегулирующую экосистему. Возможно, спать по ночам спокойнее не станет, но по крайней мере высыпаться можно ьудет чаще.
@teamleadosh
#career