Как определить, на чём сфокусироваться, если в компании множество вызовов: техдолг, неоптимальная архитектура и проблемы надёжности?

Привет, Хабр! Я — Иван Нещадин, работаю тимлидом в компании Авито. Сейчас я руковожу двумя командами Arch и Bridge. В этой статье по мотивам доклада для TeamLeadConf я расскажу, как в Авито мы создали SWAT-команду, которая быстро решает самые проблемные задачи и живёт между миров платформы и продукта. Также подробно опишу, как снижаем хаос в архитектуре и улучшаем надёжность.

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

В этой статье

• История создания команды 

• Концепция SWAT-команды 

• Как мы ставим цели в Авито

• Задачи, которые решает команда

• Принципы и порядок взаимодействия команды

• Как мы определяем приоритет задач

• Про постановку целей конкретно в нашей команде 

• Кому нужна такая команда?

История создания команды

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

Таким образом в 2019 году появилась команда Antimonolith, и спустя пару месяцев в эту команду пришёл я. А в 2023 году монолит уже распилили.

Сейчас осталось сколько-то сотых процента всего трафика, которые приходили на остатки монолита. Полностью монолит, к сожалению, не удалили: там остались какие-то старые deprecated api-методы, поэтому команду Antimonolith решили переформировать и создали три новые: SLA, Arch и Bridge.

• SLA разрабатывает инструменты для отслеживания надёжности;

• Arch разрабатывает качественные подходы к архитектуре и даёт инструменты для её оценки;

• Bridge улучшает надёжность и архитектуру в продукте. 

Для того, чтобы находить проблемы в архитектуре и надёжности, команда Bridge использует инструменты, которые ей предоставляют команды SLA и Arch.

Концепция SWAT-команды 

В Авито SWAT-команда — это команда, которая находит самые проблемные зоны внутри продуктов компании и наносит «непоправимую пользу», исправляет все имеющиеся проблемы.

Цель SWAT-команды — системная борьба с критическим техдолгом и архитектурными рисками до того, как они станут инцидентами. 

Из миссии видно, что мы за системный подход и за то, чтобы инциденты в принципе не происходили. 

Зоны ответственности SWAT-команды:

• Надёжность сервисов (SLI/SLO);

• Архитектурный долг (критичный!);

• Технический долг (критичный!).

Здесь очень важно остановиться на том, что мы отслеживаем именно самые критичные части для того, чтобы не превратиться в команду на побегушках, к которой продуктовые команды приходят и говорят: «Мы что-то накодили, перепишите нормально». Чтобы такого не было, мы разработали свой подход к приоритизации и берёмся только за самое критичное.

При этом у SWAT-команды есть свои особенности, которые не присущи обычным командам разработки ни в продуктовых командах, ни в платформенных.

Особенности SWAT-команды:

• Мы — проектная команда. У всех команд есть свои сервисы, но у нас их нет, как  нет и своей кодовой базы, за которой мы могли бы следить и развивать. Мы всегда работаем с чужим кодом и контекстом — с чужими зонами ответственности, c которыми мы часто не знакомы. 

• Сложно ставить годовые цели для команды. У продуктовых команд есть свои зоны ответственности и сервисы, они заранее понимают, что в них можно улучшить и какие метрики заложить в цели. А у нас нет прямых бизнес метрик, на которые мы могли бы непосредственно влиять. Но мы работаем над тем, чтобы они появились. 

  

Небольшое отступление, как мы вообще в Авито работаем с целями

У нас есть сложности с discovery целей:

• Мы всегда вынуждены искать, кому помогать. Нам важно понимать, что именно сейчас самое критичное, чтобы не было такой ситуации, когда  мы сходили по командам, узнали, у кого есть проблемы, собрали задачи и пошли делать, а потом оказалось, что были другие критичные места, которые мы пропустили и в них ничего не поправили, потому, что нам просто про них никто не рассказал.

• Тратим много времени на research. Мы приходим к команде, смотрим их код, разбираемся в том, как у них всё работает, и с их бизнес-контекстом для того, чтобы иметь понимание, какие изменения вносить и каким образом.

• Задачи часто приходят в конце квартала и остаётся мало времени на планирование. У нас квартальное планирование. Буквально за неделю до конца квартала могут принести проект, в котором мы ни в зуб ногой: видим сервис впервые в жизни, а нас просят оценить, сколько времени уйдёт на улучшение.

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

Задачи, которые решает команда

Кейс 1: стабилизация сценариев

При росте пользовательской нагрузки на определённый сервис выявлено, что этот сервис с ней не справляется. Если дальше пойдёт рост пользователей, сервис начнёт падать. 

Заказчик: одна из команд получила данные при очередном нагрузочном тестировании и пришла к нам.

Задача: увеличение читающей/пишущей нагрузки на сервис не влияет на стабильность сценариев. 

Что мы сделали: 

1. Разобрались с причинами просадки производительности

Мы пришли в сервис, разобрались с тем, как он работает, провели research. Выяснили, что проблема на стороне базы. Несмотря на то, что там и шарды есть, и всё, что только можно, уже оптимизировано, база не вывозит такое количество запросов на запись. Заскейлить легко тоже не получалось, поэтому нужно было что-то кардинально менять. 

2. Перенесли часть таблиц с данными в новый сервис

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

3. Перенесли api-методы, cron-задачи и остальной функционал

Мы перенесли в отдельный сервис часть самых нагруженных по записи таблиц, все api-методы, cron-задачи и всё прочее, что связано с этими табличками.

4. Переключили трафик на этот новый сервис

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

Кейс 2: исправить архитектуру сервиса 

Заказчик: запрос пришёл от команды-владельца сервиса.

Задача: обновить старый сервис, который был вынесен из монолита в самом начале пути распила и сейчас не использует актуальных платформенных стандартов.

Ребята из команды сказали: «Мы на микросервисы выносили ещё в „бородатые“ годы (буквально 5 лет назад). Там уже всё надо переписывать». 

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

С какими сложностями в этом проекте мы столкнулись:

1. Задача пришла почти в конце квартала со своими сроками 

Не шучу, их тимлид за неделю до конца квартала прислал мне Google-табличку, в которой я ничего не понял. Мы взяли их сервис, поставили в последний спринт задачу на research, чтобы понять, что от нас вообще нужно и в чём там проблема. Но, как вы понимаете, надёжно за 1 спринт разобраться не смогли и поэтому взяли те расчеты по проекту, которые провела команда-владелец и взяли их оценку на веру. 

2. Мисскоммуникация по договорённостям

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

3. Их команда оценивала задачи так, что их будут делать сразу и наш разработчик, и все разработчики из их команды

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

4. Возникли проблемы с приёмкой кода

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

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

Принципы и порядок взаимодействия команды

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

Основные тезисы соглашения:

1. Мы не аутстаф 

У нас есть свои процессы, цели и метрики. Мы не просто предоставляем разработчиков, потому что тогда получится странная команда, которую, наверно, надо называть горячим пулом разработчиков, а не SWAT-командой. 

2. Уважаем совладение 

Если мы приходим к вам в сервис для того, чтобы улучшить надёжность, исправить архитектуру, то ни в коем случае не делаем всё по-своему. Мы обязательно с вами согласуем все изменения, вы смотрите все PR, которые мы приносим, и без ревью мы ничего не мержим и не выкатываем.

3. Работаем прозрачно

Мы обговариваем, как будем коммуницировать и синхронизироваться в ходе работ, даём все планы, схемы, RoadMaps — всё обязательно обсуждаем. 

4. Согласуем взаимодействие

Мы договариваемся, как будем взаимодействовать, например, созвоны раз в спринт или раз в неделю, коммуникации в чатах. Главное, чтобы все заранее понимали, как будем синхронизироваться.

5. Тестирование силами владельцев 

У нас нет своих QA, которые тестируют код руками, так как им достаточно сложно каждый раз вникать в новую бизнес-область и понимать, какие именно тест-кейсы нужно проверять. Естественно, мы обязательно пишем автотесты на весь код, который делаем, поэтому всегда договариваемся о том, чтобы заказчик выделил QA, которые финально проверяют наши изменения.

6. Ретроспектива после окончания проекта

По окончанию работы над проектом  мы обязательно проводим ретроспективу и обсуждаем все нюансы, которые могли возникнуть. Если во время ретроспективы выяснилось, что заказчик чем-то недовольнен, мы обязательно закладываем себе это в бэклог и доделываем. 

Также в рамках встречи мы находим, как можно улучшить процессы для того, чтобы в следующие кварталы с другими командами всё проходило более гладко. 

Как даём приоритеты задачам

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

Дашборд надёжности

Первый инструмент — это дашборд надёжности, который сделала команда SLA (на скриншотах пришлось обрезать часть информации).

Что этот дашборд показывает: Команда SLA разработала универсальный подход, как считаются метрики надёжности. Для каждого сервиса у нас есть свои специальные конфиги, мы описываем их в nfr.toml. Далее, на стороне сервиса, при помощи middleware автоматически собираются метрики надёжности и отправляются в хранилище метрик. 

NFR мы считаем так:

Error Budget (бюджет на ошибки):

Пример: при SLO=99.99% и 1 млн запросов/день — допустимо 100 плохих запросов в сутки.
Также, мы составили сценарии. Сценарии — это набор API методов, которые выполняются совместно для выполнения какого-то целевого действия пользователя. У нас есть разделение сценариев по уровню критичности:

1. Crit — самые важные сценарии. Если они сломаются, то ляжет вообще всё Авито.
   Например: авторизация и регистрация;

2. High — чуть менее критичные сценарии, которые могут вызываться из crit сценариев, но при этом закрыты GD;

3. Medium — сценарии, которые могут повлиять на работу high и crit, но закрыты GD;

4. No Impact — внутренние сценарии, которые никак на пользователей не влияют.

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

На момент, когда я готовил этот материал, у нас было описано 1382 сценария. На картинке наш UI, где видно, какие у нас есть пользовательские сценарии, какие шаги в них входят, какие эндпоинты используются. Для каждого из них проставлен уровень критичности в зависимости от влияния на бизнес, считаются метрики стабильности, uptime. На основе них также настраиваются автоматически алерты, которые приходят в мониторинг. Даже если у самого сервиса алерты настроены неправильно, то уведомление о просадке какого-то сценария обязательно придёт.

Как мы понимаем, какие сценарии связаны друг с другом? Для этого мы используем сервис ArchRater. До этого на HighLoad++ я рассказывал о том, как мы в зоне архитектуры отслеживаем качество нашей архитектуры в целом.

Если вкратце, то у нас есть сервис ArchRater, в котором мы собираем все трейсы. На их основании строим граф взаимодействия между сервисами, сохраняем его в графовую базу Neo4j, а потом при помощи разных запросов строим эвристики и считаем, насколько наша архитектура приемлема. Например, находим циклические зависимости, смотрим цепочки с очень большой вложенностью. Так, чтобы отдать страницу пользователю, иногда нам нужно сходить в глубину в 100 сервисов. Естественно, это не очень хорошо, такие места нужно рефачить. Подробнее — по ссылке выше. 

Как в команде выбираем цели

Мы увидели, какие у нас есть инструменты для сбора метрик. Теперь посмотрим, как мы при помощи метрик выбираем конкретные места для изменений.

Как происходил процесс выбора целей раньше:

1. Тимлид, то есть я, собирал список проектов, прикидывал по срокам, распределял приоритеты и наносил на Roadmap. 

2. Потом приносил проекты в команду.

Я сам всё это собирал, агрегировал в таблички, а потом сидел и прикидывал сроки: если мы будем это фиксить, сколько на это нужно времени? Допустим, три человеко-спринта нам здесь хватит. Затем я это приоритизировал, приносил в команду, а команда говорит: «Прикольно, конечно, что ты сам оцениваешь проекты, но мы хотим участвовать в выборе, чтобы заранее понимать, что нам вообще делать». Честно, они так и сказали, я никого не заставлял. 

Как происходит процесс выбора целей сейчас:

1. Вся команда совместно собирает карточки с проектами на квартал 

Теперь у нас есть регулярные встречи, которые проходят раз в спринт. Мы заранее собираем карточки с идеями, чем будем заниматься. Идеи берём из метрик, показанных выше, запросов от других команд. Пока ребята работают с другими командами, они тоже тоже находят какие-то проблемы, когда смотрят на чужой на другой код, и собирают всё в карточки на общую доску.

2. На встрече грумим карточки, делим на этапы

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

3. Для каждого этапа делаем примерную оценку в человеко-спринтах 

4. Рассчитываем приоритеты

К последнему пункту у меня есть особый подход. 

Приоритизация проектов

У нас разработана числовая оценка приоритетов. Мы выделили три зоны ответственности:

• надёжность;

• масштабирование;

• актуальность стека.

Для каждой зоны выделили влияние и вывели числовой коэффициент. Есть три уровня влияния:

P0 — влияние на всё Авито: страдает один сервис — страдают все остальные сервисы

P1 — влияние на конкретную вертикаль: в Авито есть пять вертикалей, если из-за того, что страдает сервис, страдают метрики всех сервисов в вертикали — это влияние P1.

P2 — влияние на небольшую микро-категорию: если сломался какой-то сервис, начинаются проблемы с соответствующей микро-категорией.

Цифры во втором столбце — это числовые коэффициенты, в которые мы транслируем оценку. Затем мы собираем сумму всех этих коэффициентов и рассчитываем приоритет для конкретного проекта. В случае актуальности техстека эти коэффициенты чуть ниже, потому что здесь речь идёт про техдолг, который на метрики ещё не влияет, но потенциально потом может повлиять, если его не исправлять, но мы всё равно считаем его менее приоритетным, чем архитектурные проблемы или проблемы с надёжностью.

Далее расскажу, как мы оцениваем приоритет для проекта на конкретном примере.

Допустим, у нас есть проект повышения надёжности для сервиса. Предположим, что надёжность сервиса N снизилась до уровня 99,5 и держится на нём более квартала. Этот сервис влияет на несколько других продуктовых сервисов, из-за чего страдает надёжность сразу трёх вертикалей (A, B и C). У команды-владельца сервиса не хватает экспертизы, чтобы разобраться с проблемой. При этом у них есть свой продуктовый бэклог с жёсткими дедлайнами, ввиду чего задача по оптимизации out of scope.  Нужно помочь им поднять надёжность этого сервиса.

Для начала оценим влияние на надёжность. Здесь у нас говорится сразу про три вертикали. Можно считать, что это импакт практически на всё Авито, ведь всего у нас 5 вертикалей. Соответственно, приоритет ставим P0, добавляем единичку. 

• P0 – влияние на надёжность вертикалей +1 

Далее смотрим, есть ли здесь влияние на масштабируемость: влияют ли проблемы, которые есть у этого сервиса, на то, что он не может масштабироваться. Если углубиться, становится понятно, что сервис нельзя просто так взять и заскейлить — это тоже часть проблемы. Так как это влияет сразу на всё Авито, то здесь тоже приоритет P0, ещё единичку добавляем.

• P0 – влияние на масштабируемость +1 

Следующий вопрос: есть ли здесь какой-то техдолг? Здесь стоит вопрос именно о критичном техдолге. Мы оценили, что его нет. У них сервис написан на актуальном стеке, использует актуальные платформенные подходы, поэтому здесь приоритет P3,  добавляем ноль.

• P3 – влияние на техдолг +0 

Поскольку это важная годовая цель, добавляем ещё единичку

• Важная годовая цель +1 

Получаем итоговый приоритет 3 и вносим его на карточку.

Что делаем дальше?

1. Берём все карточки, которые мы составили, и сортируем их в порядке убывания приоритета.

2. Наносим их на RoadMap с учётом всех наших праздников, выходных, отпускных и всего прочего, закладываем запас времени на техдолг и получаем RoadMap, в котором всё учтено. 

3. Задачи, которые на этот RoadMap нанести не удалось (они не влезли) откладываем на следующие кварталы. Что влезло, берём и делаем. 

И этот подход у нас работает хорошо: мы действительно берём всё самое важное и критичное.

Сколько времени занимает приоритизация?

В прошлом квартале у нас было четыре встречи по 1,5 часа на четверых, то есть 24 человека-часа. Не мало, но мы сразу максимально правильно понимаем, какие задачи будем делать. Но остался ещё один не рассмотренный вопрос.

Как решали проблему с поиском задач и приоритетами?

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

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

Зона ответственности — надёжность

Зона ответственности — архитектурный долг

Зона ответственности — технический долг

Нужна ли вам такая команда?

На этот вопрос просто не ответить, но могу дать несколько тезисов «за», когда такая команда нужна:

• Когда компания доросла до большой архитектуры и её качество overall сложно контролировать;

• Разработчики конкретного сервиса могут сами придумать какую-то архитектуру, внедрить её, и отслеживать это довольно сложно;

• Есть возможность на метриках находить проблемы в ваших сервисах.По метрикам видно, что качество/надёжность со временем ухудшаются, это происходит систематически и проблемы накапливаются.

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

А если вам интересно, когда я успеваю готовить так много классного материала — так это потому, что у меня клавиатура эргономичная и я быстро печатаю!
Заходите на огонёк в мой tg канальчик, я там пишу много интересного. Последнее время публикую много материалов по запуску локальных LLM моделей.