Принцип единственной ответственности.

Я люблю принцип единственной ответственности.

В архитектуре. В процессах. В задачах. В проектах. В жизни.

Agile — молодцы. Команда — отлично.

Но за конкретный кусок отвечает один человек. Один.

Это не про наказание.

Это про ожидания. Про прозрачность. Про ясность, кто приносит кофе, а кто чинит прод. Времена AI, а проблема осталась Казалось бы, с AI измерение доступности приложения — решённый вопрос.

Но нет. Везде доступность меряют по-разному. Одни — по аптайму серверов. Другие — по HTTP 200. Третьи — по звонкам в поддержку.

А в итоге — болото. Нельзя сравнить. Нельзя улучшить. Нельзя натянуть на KPI. Как мы выбрали мерить Мы выбрали по сценариям.

Сценарий — это точка входа и выход. По-простому: «пользователь зашёл и сделал дело».

Между ними — шаги. Каждый шаг — конкретный эндпоинт, сервис, действие.

Вход: кликнул «Заказать».

Выход: увидел «Заказ оформлен».

Внутри: 5 вызовов API, 3 микросервиса, 2 базы. Главное решение, которое изменило всё Мы приняли правило: За один сценарий отвечает одна конкретная команда. Один PO. Один тимлид. Не «все повязаны». Не «разберёмся по факту».

Один сценарий = одна команда = одна ответственность.

И вот тут началась магия. Что произошло дальше Команды начали вести себя иначе.

🧩 Стали понимать зависимости

Раньше: «Ой, там Петя что-то сломал, мы не виноваты».

Теперь: «Это наш сценарий. Если Петя нас тормозит — мы идём к Пете и договариваемся».

✂️ Начали сокращать зависимости через архитектуру

Лишний вызов к другому сервису? Убираем.

Можно закешировать? Кешируем.

Не нужна синхронная связка? Делаем асинхронную.

Потому что каждая зависимость — угроза доступности моего сценария.

🧻 Начали подкладывать соломку

Резервные сервисы. Таймауты. Circuit breakers.

Не потому что «так хорошая архитектура», а потому что иначе упадёт мой KPI.

📝 Заключать SLA между командами

«Петя, твой сервис должен отвечать за 100 мс в 99.9% случаев, иначе мой сценарий не успевает».

Раньше это было абстрактное нытьё. Теперь — конкретное обязательство.

Что было до (и это ад)

Когда ответственность размазана:

- За фронт отвечает Вася - За бэк — команда Пети - За базы — отдел Димы - За доступность — никто

Доступность посчитать можно. Честно. С цифрами.

Но сдвинуть команды на изменения — невозможно.

Особенно когда их больше 40.

40 команд. 40 мнений. 40 «это не наша проблема». Почему это работает Принцип единственной ответственности + прозрачный KPI = двигатель изменений.

Команда знает:

- за что отвечаю - как это измеряется - что будет, если провалю

И у команды появляется интерес:

- сокращать зависимости - договариваться с соседями - улучшать мониторинг - делать код надёжнее

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

Назначьте одну команду ответственной за каждый сценарий.

Сделайте KPI команды — доступность её сценариев.

И наблюдайте, как архитектура начнёт чиниться сама собой.