1 of 74

Укрощение�зоопарка сервисов

Как системный подход одной команды повышает надёжность и скорость разработки

2 of 74

Обо мне

TechLead @ Bridge & Arch

Иван Нещадин

Улучшаю архитектуру

Повышаю надёжность

Люблю Go

Менторю

Москва 2025

3 of 74

Содержание

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

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

С какими проблемами сталкиваемся

1

2

3

4

Как строим процесс приоритизации

5

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

Москва 2025

4 of 74

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

Москва 2025

5 of 74

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

Сначала был он:

Монолит

Москва 2025

6 of 74

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

Затем, появилась команда

Antimonolith

Москва 2025

7 of 74

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

В 2023 монолит распилили

Antimonolith

SLA

Arch

Bridge

Москва 2025

Затем, в 2023 году, пришли к состоянию, когда монолит хоть и остался существовать, но работал уже полностью как микросервис. Т.е. в нём почти не осталось никакого трафика, он обслуживал менее 0.5% всего трафика Авито. В нём остались какие-то старые API методы, которые ещё где-то использовались, но было уже нецелесообразно держать целую команду для того, чтобы допиливать такие небольшие кусочки. И в итоге, Antimonolith был преобразован в три команды: SLA, Arch и Bridge.

8 of 74

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

Новая структура команды

ArchGovernance�(Unit)

SLA

Arch

Bridge

Москва 2025

9 of 74

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

Новая структура команды

Разрабатывает инструменты

для отслеживания надёжности

Разрабатывает качественные подходы к архитектуре и даёт инструменты оценки

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

SLA

Arch

Bridge

Москва 2025

По задумке, команды внутри юнита функционируют так: SLA разрабатывает инструменты для отслеживания глобальной надёжности у всех сервисов, команда Arch разрабатывает архитектурные подходы и даёт инструменты для оценки качетва архитектуры. А команда Bridge помогает продуктовым командам, у которых по какой-либо причине возникают сложности с улучшением надёжности или архитектуры исправлять их проблемы.��При этом, т.к. команда будет взаимодействовать непосредственно с другими сервисами, она будет работать как SWAT команда

10 of 74

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

Москва 2025

11 of 74

Знаете ли вы, что такое SWAT-команда?

Москва 2025

12 of 74

Что такое SWAT-команда?

Это команда, которая находит проблемные зоны внутри продуктов компании, приходит в них �и наносит «непоправимую пользу» — �т.е. исправляет все проблемы

Москва 2025

13 of 74

Системно боремся �с критическим тех. долгом и архитектурными рисками до того, как они станут инцидентами

Москва 2025

14 of 74

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

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

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

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

Москва 2025

15 of 74

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

Москва 2025

16 of 74

Мы — проектная команда

У нас нет своих сервисов, своей кодовой базы, �за которыми мы могли бы следить и развивать.

Мы всегда работаем с чужим кодом и контекстом

Москва 2025

И первая особенность - мы - **Проектная команда**. Вы могли подумать - ну и что такого?

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

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

17 of 74

Сложно ставить годовые цели для команды

У продуктовых команд есть свои зоны ответственности и сервисы, в которых�они понимают, что можно улучшить �и какие метрики заложить в цели.

Москва 2025

Ну и ещё одна проблема, которая связана с этой это то, что нам довольно проблематично ставить годовые цели. У других команд ставить цели значительно легче - они могут заложить увеличение конкретных метрик в своей зоне ответственности. Например, продуктовая команда вертикали товаров может заложить увеличение числа buyer на 5% за следующий год или рост объёма b2c сделок.

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

18 of 74

Постановка целей в Авито

В Авито цели ставятся по методологии OKR.

Objective (Цель) – конкретная вещь, которая должна быть достигнута. В формулировке обязательно используется глагол.

Key Result (Ключевой результат) – числовые метрики, достижение которых подтверждает выполнение цели.

Вставьте картинку сюда

Москва 2025

19 of 74

Сложности с discovery целей

Нет своих сервисов, нужно искать, кому помогать

Москва 2025

Для того, чтобы нам понимать, что нужно делать в рамках квартала, в течении всего предыдущего квартала приходится тратить дополнительное время на discovery проектов на будущее. Если другие команды могут уже заранее понимать, что им в своих сервисах улучшить, какие фичи внедрить, нам нужно бегать по всему функционалу, спрашивать у коллег из других команд - есть ли где-то проблемные зоны, для того, чтобы планировать работу в них.

И в результате, зачастую получается так, что мы понимаем, что нам нужно делать буквально перед началом следующего квартала, когда нужно ставить цели. А для того, чтобы грамотно поставить цели, нужен хотя бы примерный план и roadmap, чтобы понимать, хватит ли ресурсов команды для достижения цели или цель в принципе недостижима? В методологии OKR очень важно брать именно достижимые цели, поэтому по методологии считается, что хорошо, если команда выполнила 70% от поставленных целей. Это значит, что цели были достаточно амбициозные и ресурсы были оптимально загружены. Если бы цель была выполнена на 100% - значит, взяли слишком простые цели, а если менее 70% - недостижимые цели и это тоже плохо.

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

20 of 74

Сложности с discovery целей

Нет своих сервисов, нужно искать, кому помогать

Тратим много времени на research

Москва 2025

Для того, чтобы нам понимать, что нужно делать в рамках квартала, в течении всего предыдущего квартала приходится тратить дополнительное время на discovery проектов на будущее. Если другие команды могут уже заранее понимать, что им в своих сервисах улучшить, какие фичи внедрить, нам нужно бегать по всему функционалу, спрашивать у коллег из других команд - есть ли где-то проблемные зоны, для того, чтобы планировать работу в них.

И в результате, зачастую получается так, что мы понимаем, что нам нужно делать буквально перед началом следующего квартала, когда нужно ставить цели. А для того, чтобы грамотно поставить цели, нужен хотя бы примерный план и roadmap, чтобы понимать, хватит ли ресурсов команды для достижения цели или цель в принципе недостижима? В методологии OKR очень важно брать именно достижимые цели, поэтому по методологии считается, что хорошо, если команда выполнила 70% от поставленных целей. Это значит, что цели были достаточно амбициозные и ресурсы были оптимально загружены. Если бы цель была выполнена на 100% - значит, взяли слишком простые цели, а если менее 70% - недостижимые цели и это тоже плохо.

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

21 of 74

Сложности с discovery целей

Нет своих сервисов, нужно искать, кому помогать

Тратим много времени на research

Задачи часто приходят в конце квартала и мало времени на планирование

Москва 2025

Для того, чтобы нам понимать, что нужно делать в рамках квартала, в течении всего предыдущего квартала приходится тратить дополнительное время на discovery проектов на будущее. Если другие команды могут уже заранее понимать, что им в своих сервисах улучшить, какие фичи внедрить, нам нужно бегать по всему функционалу, спрашивать у коллег из других команд - есть ли где-то проблемные зоны, для того, чтобы планировать работу в них.

И в результате, зачастую получается так, что мы понимаем, что нам нужно делать буквально перед началом следующего квартала, когда нужно ставить цели. А для того, чтобы грамотно поставить цели, нужен хотя бы примерный план и roadmap, чтобы понимать, хватит ли ресурсов команды для достижения цели или цель в принципе недостижима? В методологии OKR очень важно брать именно достижимые цели, поэтому по методологии считается, что хорошо, если команда выполнила 70% от поставленных целей. Это значит, что цели были достаточно амбициозные и ресурсы были оптимально загружены. Если бы цель была выполнена на 100% - значит, взяли слишком простые цели, а если менее 70% - недостижимые цели и это тоже плохо.

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

22 of 74

Пример задач, которые решаем

Москва 2025

23 of 74

Стабилизация сценариев

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

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

Заказчик: получили информацию при очередном нагрузочном тестировании

Москва 2025

24 of 74

Стабилизация сценариев

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

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

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

Заказчик: получили информацию при очередном нагрузочном тестировании

Москва 2025

Приведу здесь один из реальных кейсов - к нам обратился один из директоров направления, нужно было интегрировать сервисы одного из направлений бизнеса, которые были изначально разработаны вне нашей платформы, на нашу общую платформу под названием PaaS. Всё что нам сказали про предметную область - то что сервисы написаны на C#, среди них всего пара микросервисов, остальное - это большой монолит, написанный на C#. Как и что там деплоится - непонятно, БД используется MySQL (вроде), хотя у нас в целом в Авито подход к БД стандартизирован и используется в основном PostgreSQL.

25 of 74

Стабилизация сценариев

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

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

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

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

Заказчик: получили информацию при очередном нагрузочном тестировании

Москва 2025

Приведу здесь один из реальных кейсов - к нам обратился один из директоров направления, нужно было интегрировать сервисы одного из направлений бизнеса, которые были изначально разработаны вне нашей платформы, на нашу общую платформу под названием PaaS. Всё что нам сказали про предметную область - то что сервисы написаны на C#, среди них всего пара микросервисов, остальное - это большой монолит, написанный на C#. Как и что там деплоится - непонятно, БД используется MySQL (вроде), хотя у нас в целом в Авито подход к БД стандартизирован и используется в основном PostgreSQL.

26 of 74

Стабилизация сценариев

Переключили трафик и решили проблему

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

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

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

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

Заказчик: получили информацию при очередном нагрузочном тестировании

Москва 2025

Приведу здесь один из реальных кейсов - к нам обратился один из директоров направления, нужно было интегрировать сервисы одного из направлений бизнеса, которые были изначально разработаны вне нашей платформы, на нашу общую платформу под названием PaaS. Всё что нам сказали про предметную область - то что сервисы написаны на C#, среди них всего пара микросервисов, остальное - это большой монолит, написанный на C#. Как и что там деплоится - непонятно, БД используется MySQL (вроде), хотя у нас в целом в Авито подход к БД стандартизирован и используется в основном PostgreSQL.

27 of 74

Пример сложного кейса

Москва 2025

28 of 74

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

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

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

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

Москва 2025

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

Приведу пример, когда мы не смогли договориться изначально о взаимодействии с другой командой. К нам пришла команда Messenger. Они попросили нас помочь им с решением им архитектурного долга. Их сервисы были написаны одними из первых, когда переход на микросервисы с огромного PHP монолита только начинался. При этом, всё это время платформа не стояла на месте и многие основные элементы, которые нужны для работы микросервисов у нас стандартизировались.

Например:

- Чётко описанный для всех сервисов формат взаимодействия со внешними пользователями. Для этого у нас принят стандарт OpenAPI (с некоторыми доработками) и JSON протокол, который формируется на основании OpenAPI описания. Публикация роутов наружу также происходит из OpenAPI описания.

- Формат взаимодействия между сервисами на нашем протоколе Brief (что-то похожее на protobuf по описанию, но не совсем оно).

- Способы автоматизированного деплоя БД в kubernetes при помощи команд

- Очереди

- databus события для межсервисного общения

- clickstream события

- и многое многое другое

Но Messenger не спешили переводить свои сервисы на актуальные рельсы платформы. В результате, у них накопилось большое количество тех. долга. Например - вместо json протокола с понятными методами, в которые ходили клиенты с фронта, у них всё взаимодействие строилось на Websocket, в котором по определённым форматам вызывались методы на бэкенде.

29 of 74

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

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

Сильно устаревший тех. стек

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

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

Москва 2025

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

Приведу пример, когда мы не смогли договориться изначально о взаимодействии с другой командой. К нам пришла команда Messenger. Они попросили нас помочь им с решением им архитектурного долга. Их сервисы были написаны одними из первых, когда переход на микросервисы с огромного PHP монолита только начинался. При этом, всё это время платформа не стояла на месте и многие основные элементы, которые нужны для работы микросервисов у нас стандартизировались.

Например:

- Чётко описанный для всех сервисов формат взаимодействия со внешними пользователями. Для этого у нас принят стандарт OpenAPI (с некоторыми доработками) и JSON протокол, который формируется на основании OpenAPI описания. Публикация роутов наружу также происходит из OpenAPI описания.

- Формат взаимодействия между сервисами на нашем протоколе Brief (что-то похожее на protobuf по описанию, но не совсем оно).

- Способы автоматизированного деплоя БД в kubernetes при помощи команд

- Очереди

- databus события для межсервисного общения

- clickstream события

- и многое многое другое

Но Messenger не спешили переводить свои сервисы на актуальные рельсы платформы. В результате, у них накопилось большое количество тех. долга. Например - вместо json протокола с понятными методами, в которые ходили клиенты с фронта, у них всё взаимодействие строилось на Websocket, в котором по определённым форматам вызывались методы на бэкенде.

30 of 74

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

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

Сильно устаревший тех. стек

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

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

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

Москва 2025

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

Приведу пример, когда мы не смогли договориться изначально о взаимодействии с другой командой. К нам пришла команда Messenger. Они попросили нас помочь им с решением им архитектурного долга. Их сервисы были написаны одними из первых, когда переход на микросервисы с огромного PHP монолита только начинался. При этом, всё это время платформа не стояла на месте и многие основные элементы, которые нужны для работы микросервисов у нас стандартизировались.

Например:

- Чётко описанный для всех сервисов формат взаимодействия со внешними пользователями. Для этого у нас принят стандарт OpenAPI (с некоторыми доработками) и JSON протокол, который формируется на основании OpenAPI описания. Публикация роутов наружу также происходит из OpenAPI описания.

- Формат взаимодействия между сервисами на нашем протоколе Brief (что-то похожее на protobuf по описанию, но не совсем оно).

- Способы автоматизированного деплоя БД в kubernetes при помощи команд

- Очереди

- databus события для межсервисного общения

- clickstream события

- и многое многое другое

Но Messenger не спешили переводить свои сервисы на актуальные рельсы платформы. В результате, у них накопилось большое количество тех. долга. Например - вместо json протокола с понятными методами, в которые ходили клиенты с фронта, у них всё взаимодействие строилось на Websocket, в котором по определённым форматам вызывались методы на бэкенде.

31 of 74

Какие были разногласия

Команда думала, что мы отдаём своего сотрудника как аутстафф и он подключается ко всем процессам

Москва 2025

32 of 74

Какие были разногласия

Команда думала, что мы отдаём своего сотрудника как аутстафф и он подключается ко всем процессам

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

Москва 2025

33 of 74

Какие были разногласия

Команда думала, что мы отдаём своего сотрудника как аутстафф и он подключается ко всем процессам

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

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

Москва 2025

34 of 74

Появилось соглашение по работе с другими командами

Москва 2025

35 of 74

Соглашение с другими командами

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

Москва 2025

36 of 74

Соглашение с другими командами

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

Мы уважаем совладение

Москва 2025

37 of 74

Соглашение с другими командами

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

Мы уважаем совладение

Мы работаем прозрачно

Москва 2025

38 of 74

Соглашение с другими командами

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

Мы уважаем совладение

Мы работаем прозрачно

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

Москва 2025

39 of 74

Соглашение с другими командами

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

Мы уважаем совладение

Мы работаем прозрачно

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

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

Москва 2025

40 of 74

Соглашение с другими командами

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

Мы уважаем совладение

Мы работаем прозрачно

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

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

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

Москва 2025

41 of 74

Как ищем и приоритизируем задачи

Москва 2025

42 of 74

Дашборд надёжности команды SLA

Москва 2025

43 of 74

Сценарии в Авито

Москва 2025

44 of 74

Вчера был доклад бывшего руководителя юнита ArchGovernance

Москва 2025

45 of 74

Мой доклад о поиске проблем в архитектуре в прошлом году

Москва 2025

46 of 74

Как происходил процесс�целеполагания

Team Lead собирал список проектов, �сам прикидывал по срокам, распределял приоритеты, наносил на Roadmap.

В конце – приносил в команду – я сделяль.

Москва 2025

47 of 74

Как происходит процесс �целеполагания теперь

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

Москва 2025

48 of 74

Как происходит процесс �целеполагания теперь

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

Москва 2025

49 of 74

Как происходит процесс �целеполагания теперь

Вся команда совместно собирает карточки с проектами на квартал
На встрече грумим карточки, делим на этапы
Для каждого этапа делаем примерную оценку в человеко-спринтах

Москва 2025

50 of 74

Как происходит процесс �целеполагания теперь

Вся команда совместно собирает карточки с проектами на квартал
На встрече грумим карточки, делим на этапы
Для каждого этапа делаем примерную оценку в человеко-спринтах
Рассчитываем приоритеты

Москва 2025

51 of 74

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

Разработали числовой подход к тому, как приоритизировать задачи. Выделили 3 наших зоны ответственности и для каждой из них выделили влияние на зоны и выделили числовой коэффициент

Москва 2025

52 of 74

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

Разработали числовой подход к тому, как приоритизировать задачи. Выделили 3 наших зоны ответственности и для каждой из них выделили влияние на зоны и выделили числовой коэффициент

Москва 2025

53 of 74

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

Разработали числовой подход к тому, как приоритизировать задачи. Выделили 3 наших зоны ответственности и для каждой из них выделили влияние на зоны и выделили числовой коэффициент

Москва 2025

54 of 74

Работа системы

Проект – повышение надёжности для сервиса

Москва 2025

55 of 74

Работа системы

Проект – повышение надёжности для сервиса

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

Москва 2025

56 of 74

Работа системы

Проект – повышение надёжности для сервиса

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

Москва 2025

57 of 74

Работа системы

Проект – повышение надёжности для сервиса

P0 – влияние на надёжность вертикалей +1
P0 – влияние на масштабируемость +1
P3 – влияние на тех. долг +0

Москва 2025

58 of 74

Работа системы

Проект – повышение надёжности для сервиса

P0 – влияние на надёжность вертикалей +1
P0 – влияние на масштабируемость +1
P3 – влияние на тех. долг +0
Важная годовая цель +1

Итого: приоритет 3

Москва 2025

59 of 74

Как делаем дальше

Берём список всех задач и сортируем �их по приоритетам

Москва 2025

60 of 74

Как делаем дальше

Берём список всех задач и сортируем �их по приоритетам
Наносим их по предварительной оценке на Roadmap

Москва 2025

61 of 74

Как делаем дальше

Берём список всех задач и сортируем �их по приоритетам
Наносим их по предварительной оценке на Roadmap
То что влезло - берём, что не влезло — откладываем на потом

Москва 2025

62 of 74

Как думаете, сколько времени занимает приоритизация?

Москва 2025

63 of 74

Как думаете, сколько времени занимает приоритизация?

Планирование Q3 заняло 4 встречи �на 1.5 часа на 4х человек.

24 человеко-часа при таком подходе

Москва 2025

64 of 74

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

Москва 2025

65 of 74

Собрали брейншторм сессию с несколькими командами и придумали список метрик и приоритетов

Москва 2025

66 of 74

Новый процесс целеполагания

Москва 2025

67 of 74

Новый процесс целеполагания

Москва 2025

68 of 74

Новый процесс целеполагания

Москва 2025

69 of 74

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

Москва 2025

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

70 of 74

Когда нужна такая команда

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

Москва 2025

71 of 74

Когда нужна такая команда

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

Есть возможность на метриках находить проблемы в ваших сервисах

Москва 2025

72 of 74

Когда нужна такая команда

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

Есть возможность на метриках находить проблемы в ваших сервисах

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

Москва 2025

73 of 74

Get in touch

Если хотите пообщаться ещё — приходите.

Консультирую �и менторю

Иван Нещадин

TechLead @ Bridge&Arch

tg @Exitialis

site: https://exitialis.dev

Вставьте картинку сюда

74 of 74

Оцените доклад