Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».
Если объяснять просто, «Портфель» — это раздел, где клиент смотрит свои активы: деньги, ценные бумаги, валюту, фонды, облигации, фьючерсы, финансовый результат и общую картину по инвестициям.
Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.
Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.
На стыке всего этого и появляется роль Service Owner.
Сразу оговорюсь: это не рассказ про новую должность в оргструктуре и не попытка придумать еще одного «главного». В больших продуктах проблема обычно в другом: клиент видит один сценарий, а внутри компании за него отвечают сразу несколько команд и систем.
Пока все работает, это почти не заметно. Но когда сценарий начинает тормозить, деградировать или давать непонятный результат, быстро возникает вопрос: кто собирает всю картину целиком и доводит проблему до решения?
В моем понимании Service Owner нужен именно для этого — держать в одной рамке клиентский результат, техническое состояние сервиса и договоренности между командами.
Чем Service Owner отличается от Product Owner
У нас в компании есть владельцы разных сервисов: «Портфель», «Авторизация», «Пополнение и вывод денежных средств», «Безбумажный офис», «Торговый функционал» и другие направления.
Снаружи это может быть похоже на Product Owner. Но на практике фокус другой.
Product Owner чаще смотрит на продуктовую ценность. Какие сценарии развивать, какие гипотезы проверять, какие фичи запускать, как это повлияет на клиента и бизнес.
Service Owner больше смотрит на то, как сервис живет каждый день.
Работает ли он стабильно
Понимает ли клиент данные на экране
Кто первым узнает о проблеме — команда или клиент
Куда попадет обращение
Кто возьмет проблему в работу
Как быстро мы восстановимся
И что сделать, чтобы такая история не повторялась
Для меня сервис — это не только экран и не только набор микросервисов. Это вся цепочка, через которую клиент получает результат.
В случае «Портфеля» результат простой: клиент открывает раздел и должен понять, что происходит с его активами. Если данные выглядят странно, экран долго грузится или расчет непонятен, для клиента сервис работает плохо. Даже если внутри у нас часть систем показывает, что работает хорошо.
Как мы для себя определяем Service Owner
Если сформулировать коротко, Service Owner в БКС — это человек, который отвечает за end‑to‑end качество сервиса. Не только за то, что есть задачи в бэклоге, а за то, чтобы сервис был понятным, стабильным, наблюдаемым и управляемым в реальной эксплуатации.
Это не каноническое определение из учебника. Скорее практическая модель, которая у нас сложилась на стыке продуктового управления, эксплуатации, поддержки и инженерной надежности.
У роли есть зона ответственности и есть зона влияния. Ответственность — видеть состояние сервиса, поднимать проблемы, собирать контур решения, следить за качеством и не отпускать повторяющиеся боли. Влияние — договариваться с командами, которые владеют отдельными частями цепочки.
Что мы в БКС называем сервисом
Для нас сервис — это не любой микросервис и не просто экран. Это значимая клиентская или бизнес‑функция, вокруг которой есть пользователи, ожидания по качеству, зависимости, обращения, инциденты и понятный результат для клиента.
Например, «Портфель» — это сервис, потому что клиент через него смотрит состояние активов и принимает решения. «Авторизация» — тоже сервис, потому что без нее клиент вообще не попадет в продукт. «Пополнение и вывод» — сервис, потому что от него зависит движение денег. «Безбумажный офис» и торговый функционал — такие же сквозные клиентские сценарии.
Граница сервиса не всегда совпадает с границей команды. И это нормально. В финтехе клиентский путь часто проходит через несколько контуров сразу: приложение, backend, интеграции, биржевые данные, банковские системы, инфраструктуру безопасности и поддержку.
Поэтому для Service Owner важен не вопрос «кому принадлежит конкретный компонент», а вопрос «получает ли клиент нормальный результат на всем пути».
Главный вызов: ответственность за весь клиентский опыт
Одна из ключевых особенностей роли Service Owner — это ответственность за целостный клиентский опыт при работе в условиях, когда не все звенья цепочки находятся в твоем управлении.
Например, клиент пишет: «Портфель долго открывается». Для него это одна проблема — просто раздел долго грузится.
А внутри компании причин может быть много:
backend отвечает быстро, но frontend долго отрисовывает экран
данные приходят из нескольких источников
часть запросов выполняется последовательно, а не параллельно
где‑то мешает сетевой слой или инфраструктура безопасности
клиент сидит на нестабильном мобильном интернете
на старом устройстве экран грузится иначе, чем на новом
смежная система отдает данные медленнее, чем ожидалось
Клиент этого не видит. Он не знает, где backend, где frontend, где кеш, где сетевой маршрут и где чья зона ответственности.
Он видит только одно: открыл приложение — страница долго грузится.
И тут нельзя просто сказать: «Это не наша зона». Формально, может быть, и не наша. Но если клиент пришел в «Портфель» и получил плохой опыт, Service Owner все равно должен собрать картину целиком.
Иногда для этого хватает задачи, иногда нужна встреча, иногда приходится несколько раз возвращаться к одной теме, потому что у каждой команды свой взгляд на проблему.
Одна команда говорит, что у нее все хорошо. Другая считает, что проблема не на ее стороне. Третья просит конкретный кейс.
Бизнес ждет сроки решения, служба поддержки уже получает обращения от клиентов и по сути, им не важно, где именно сломалась цепочка.
В такой работе быстро понимаешь: формальной власти часто мало. Нужны данные, нормальная аргументация и способность договариваться. И еще важно не дать проблеме раствориться между командами.
SLA: красивая цифра еще не значит хороший сервис
Один из самых спорных вопросов в управлении сервисом — SLA.
На бумаге все обычно выглядит просто. Например: «страница должна открываться не дольше одной секунды».
Звучит понятно. Но дальше начинаются вопросы.
Что именно мы считаем? Ответ backend‑сервиса? Первую отрисовку экрана? Полную загрузку страницы? Момент, когда клиент уже может пользоваться разделом?
И какую метрику берем? Среднее значение или 95-й перцентиль?
Это не попытка спорить с цифрой ради спора, от этого зависит, какую картину мы увидим.
Среднее значение показывает, что «в среднем все нормально». Но в то же время оно легко прячет проблемы: быстрые открытия страницы компенсируют медленные, и итоговая цифра получается лучше, чем опыт части клиентов.
95-й перцентиль жестче. Он показывает, что происходит у клиентов, которым повезло меньше.
Почему CSI нельзя просто взять и сделать SLA
Еще один частый спор — можно ли использовать CSI как SLA сервиса.
Идея понятная. Клиент поставил высокую оценку — значит, сервис хороший. Оценка упала — значит, сервис плохой.
Но с CSI так не работает.
CSI — это не чисто техническая метрика. Это оценка клиента. В нее может попасть скорость загрузки, непонятные данные, ожидания от продукта, раздражение после общения с поддержкой, неудобный сценарий, плохой интернет, ошибка в другом разделе приложения или просто эмоция из‑за финансового результата.
Например, клиент может поставить низкую оценку «Портфелю» не потому, что сервис был недоступен. И не потому, что там была техническая ошибка.
Он мог не понять, почему доходность считается именно так. Или почему один инструмент попал в одну категорию, а другой — в другую. Или почему цифры отличаются от того, что он ожидал увидеть.
Для клиента это все выглядит как одна проблема: «мне непонятно» или «мне неудобно».
Но внутри это разные вещи.
Есть техническая стабильность: доступность, скорость, ошибки, инциденты, MTTR.
А есть продуктовая и методологическая часть: логика расчетов, UX, тексты, ожидания клиента, обучение поддержки, объяснение сложных финансовых показателей.
Если все это сложить в один показатель и назвать SLA, получится не очень управляемая история.
Я бы не стал превращать CSI в прямую SLA‑метрику сервиса. Не потому, что CSI не важен. Он важен. Его нужно смотреть, читать комментарии, группировать причины, отделять технические проблемы от продуктовых и превращать повторяющиеся боли в задачи.
Но использовать CSI как жесткий SLA опасно. Команда может получить ответственность за показатель, на который влияет слишком много факторов вне ее прямого контроля.
Для себя я разделяю так.
CSI — это про восприятие клиента.
SLA — это про то, насколько стабильно и управляемо сервис предоставляет услугу.
Обе метрики нужны. Просто они отвечают на разные вопросы.
Если их смешать, можно получить красивый показатель для отчета, но слабый инструмент для управления качеством.
Какие метрики реально помогают
В сервисе легко начать мониторить все подряд. Но это не всегда помогает. Дашборд может быть большим, а ответа на простой вопрос все равно нет: клиент сейчас нормально проходит сценарий или нет?
Поэтому я бы делил метрики на несколько слоев.
Клиентский слой. Здесь важны p95 и p99 по ключевым действиям, доля успешного завершения сценария, повторные попытки, падения на конкретном шаге, рост однотипных обращений.
Технический слой. Здесь уже смотрим latency, traffic, errors, saturation, ошибки интеграций, состояние зависимых систем.
Операционный слой. Это количество инцидентов, их критичность, время обнаружения, время локализации, время восстановления и повторяемость похожих проблем.
Слой изменений. Отдельно важно понимать, как релизы влияют на стабильность: сколько изменений прошло без проблем, где потребовался откат, какие задачи после релиза ушли в инциденты или обращения.
В SRE‑подходах для этого есть удобные слова SLI и SLO. Я не вижу смысла использовать их ради модной терминологии, но сама логика полезная: сначала договориться, какой показатель действительно отражает качество сервиса, а потом определить, какое значение для нас считается нормой.
В случае «Портфеля» одним из таких показателей стала скорость загрузки страницы по p95. Не единственным, но важным. Потому что она ближе к реальному клиентскому опыту, чем просто среднее значение.
Что Service Owner делает на практике
Если убрать красивые формулировки, работа Service Owner довольно приземленная.
Нужно разбираться, что происходит с сервисом. Не просто смотреть на общий статус, а понимать, где техническая проблема, где продуктовая, где методологическая, где проблема коммуникации, а где клиент просто не получил нормального объяснения.
Данные приходится собирать из разных мест: мониторинги, логи, обращения, комментарии клиентов, аналитика, инциденты, релизы, задачи, обсуждения с командами.
Иногда картина быстро складывается. Иногда нет.
Бывает, что клиент пишет: «У меня все неправильно».
Для команды это еще не задача. Нужно понять, что именно неправильно. На каком инструменте. В какой версии приложения. В какой момент. По какой методологии. С какими входными данными. Можно ли это воспроизвести. Есть ли похожие обращения.
Бизнес может сказать: «Нужно просто сделать быстрее».
Но «быстрее» не всегда означает одну задачу на оптимизацию. Иногда это архитектурная переделка. Нужно изменить последовательность запросов, пересмотреть кеширование, убрать лишние зависимости, доработать frontend‑отрисовку или договориться со смежной системой.
Разработка может сказать: «У нас все работает отлично».
И тогда важно уточнить: отлично работает по компонентам или для клиента?
Это разные вещи.
В этом и состоит ежедневная работа. Не в том, чтобы самому чинить каждый инцидент. А в том, чтобы связать между собой людей, данные и решения.
Где‑то нужно принести цифры. Где‑то — конкретный клиентский кейс. Где‑то — зафиксировать договоренность. Где‑то — не дать проблеме уехать в долгий ящик.
Как это выглядит при инциденте
Инцидент — это момент, когда роль Service Owner становится особенно заметной. В спокойное время можно долго спорить о границах ответственности. Во время проблемы важнее другое: быстро понять масштаб, собрать нужных людей и не потерять связь с клиентским эффектом.
На практике контур выглядит примерно так.
Сначала появляется сигнал. Это может быть алерт из мониторинга, рост ошибок, обращение от поддержки, сообщение от контактного центра или кейс от конкретного клиента.
Потом нужно понять серьезность: это единичная проблема, деградация для части клиентов или массовый сбой. Здесь важны не только технические графики, но и бизнес‑контекст: какой сценарий затронут, сколько клиентов может пострадать, есть ли обходной путь.
Дальше собирается контур: разработка, сопровождение, смежные сервисы, иногда бизнес и контактный центр. Service Owner в такой ситуации не обязательно становится incident lead, но он должен держать сервисную картину: что сломалось для клиента, кто что проверяет, какой статус можно передать дальше и что считаем восстановлением.
После восстановления работа не заканчивается. Нужен разбор: что заметили поздно, где не хватило мониторинга, какая зависимость была неочевидной, почему проблема повторилась или могла повториться.
Хороший разбор инцидента — это не поиск виноватого. Это список конкретных действий: добавить алерт, поправить runbook, изменить деградационный сценарий, доработать тесты, вынести задачу в reliability backlog или договориться со смежной командой о новом SLA/SLO.
Какие артефакты помогают не держать все в голове
Когда сервис маленький, многое можно держать в голове. Когда сервис растет и вокруг него появляется несколько команд, так уже не работает.
Нам в такой модели полезны несколько простых артефактов.
Сервисный паспорт: что делает сервис, кто его пользователи, какие есть ключевые сценарии, зависимости, владельцы, контакты, метрики и каналы эскалации.
Карта зависимостей: какие системы участвуют в клиентском сценарии и где может возникнуть деградация.
Единый дашборд: не просто набор технических графиков, а картина по здоровью сервиса — скорость, ошибки, обращения, инциденты, ключевые зависимости.
Runbook: что делать при типовых проблемах, куда смотреть первым делом, кого подключать и какие временные меры возможны.
Журнал инцидентов и follow‑up задач: чтобы после восстановления проблемы не исчезали из поля зрения.
Это звучит довольно приземленно, но именно такие вещи часто решают, будет проблема закрыта системно или через месяц вернется в похожем виде.
Баланс между развитием и стабильностью
У сервиса всегда есть две силы.
Первая — развитие. Новые функции, новые сценарии, новые продуктовые задачи, новые ожидания бизнеса.
Вторая — стабильность. Скорость, доступность, корректность данных, качество поддержки, снижение инцидентов, мониторинги, технический долг.
Если заниматься только развитием, качество постепенно начнет проседать. Сервис будет обрастать функциональностью, но станет тяжелее, сложнее и менее предсказуемым.
Если заниматься только стабильностью, сервис перестанет двигаться вперед. Он будет аккуратным, но начнет отставать от клиентских ожиданий и бизнеса.
На практике баланс — это постоянный выбор.
Что берем в работу сейчас: новую фичу или техническое улучшение?
Что важнее в этом квартале: ускорить экран или добавить новый сценарий?
Где проблема уже влияет на клиента, а где это пока внутренний риск?
Что можно поправить быстро, а что требует архитектурной переделки?
Service Owner не всегда принимает эти решения один. Но он должен принести в обсуждение сервисную картину. Не только «что хочет бизнес», но и «что происходит с качеством».
Service Owner работает не только с разработкой
Если смотреть на роль только через разработку, картина будет неполной. Большая часть полезной информации о сервисе приходит не из одного места.
С разработкой разговор обычно про надежность, архитектурные ограничения, технический долг, наблюдаемость, релизы и риски изменений.
С тестированием — про регресс, критичные клиентские сценарии, проверки после релиза и случаи, когда сервис не падает полностью, но работает не так, как ожидает клиент.
С поддержкой и контактным центром — про реальную обратную связь клиентов. Иногда именно они первыми видят, что проблема набирает масштаб, хотя мониторинг еще не кричит.
С бизнесом — про приоритеты, клиентский эффект, допустимый уровень риска и честное объяснение, почему часть нефункциональных задач нельзя бесконечно откладывать ради новых фичей.
Со смежными владельцами сервисов — про границы, зависимости, эскалации и договоренности. Особенно когда проблема проявляется у клиента в одном месте, а причина лежит в другом.
Что оказалось сложным
Самая сложная часть — не придумать красивую схему роли. Сложно сделать так, чтобы она реально работала в ежедневной практике.
Во‑первых, не всегда легко провести границу сервиса. Клиентский путь может идти через несколько систем, и у каждой есть свой владелец, свой backlog и свои приоритеты.
Во‑вторых, у Service Owner не всегда есть прямое административное влияние на команды, которые нужны для решения проблемы. Поэтому приходится работать через факты, аргументацию и договоренности.
В‑третьих, метрики часто живут в разных системах. Где‑то мониторинг, где‑то обращения, где‑то аналитика, где‑то инциденты. Пока не соберешь это вместе, единая картина не сложится.
В‑четвертых, reliability‑задачи конкурируют с feature roadmap. Новая фича обычно понятнее и заметнее. А задача на наблюдаемость, устойчивость или снижение технического риска выглядит менее эффектно, пока что‑нибудь не сломается.
И важное ограничение: Service Owner не решает все магически. Он не заменяет инженерную культуру, нормальную архитектуру, качественную поддержку и зрелые процессы инцидентов. Эта роль только делает проблемы видимыми и помогает доводить их до системного решения.
Почему важно смотреть глазами клиента
Внутри компании легко начать мыслить системами, компонентами, задачами, релизами и зонами ответственности.
Клиент так не мыслит, клиент видит итог. Поэтому главный вопрос для Service Owner простой: результат работы полностью удовлетворяет требованиям клиента?
Если нет, работа не закончена. Даже если формально проблема где‑то на границе зон ответственности.
Почему роль Service Owner становится важнее
Чем больше компания, тем больше зависимостей между командами. И тем выше риск, что проблема будет переходить из одного контура в другой, но так и не получит владельца на уровне всего клиентского сценария. Service Owner нужен именно в таких местах: не вместо команд и не над командами, а как человек, который держит общую сервисную картину.
Это роль, которая смотрит на сервис целиком. Не только на продуктовую ценность. Не только на техническую стабильность. Не только на обращения в поддержку. А на всю цепочку предоставления услуги.
Что меняется, когда появляется такой контур
Главный эффект не в том, что у сервиса появляется еще один человек в списке ответственных. Эффект в том, что проблемы перестают так легко теряться между командами.
Становится понятнее, какие сигналы считаем важными. Быстрее видно, где деградация влияет именно на клиента. Проще объяснять бизнесу, почему нужна не только новая функция, но и техническое улучшение. Поддержка и контактный центр получают более понятный канал обратной связи. Разработка видит не абстрактную жалобу, а конкретный сценарий и данные.
Не всегда это работает идеально. Иногда все равно приходится долго договариваться. Но появляется рабочая рамка: сервис рассматривается не по границам команд, а по границам клиентского результата.
Каким должен быть хороший Service Owner
На мой взгляд, хороший Service Owner должен сочетать несколько компетенций.
Техническая экспертиза. Не обязательно быть самым сильным инженером в комнате. Но нужно понимать архитектуру, интеграции, мониторинги, логи, метрики, ограничения и технический долг. Иначе сложно отличить реальную проблему от красивого объяснения.
Продуктовый взгляд. Сервис существует не ради архитектуры и не ради отчетов. Он нужен, чтобы клиент получил понятный и полезный результат.
Управленческое влияние. Очень часто вопросы приходится двигать без прямой административной власти. Не приказом, а аргументами, фактами, договоренностями и настойчивостью.
Еще нужна эмоциональная стабильность. Инциденты будут. Спорные SLA будут. Клиентский негатив будет. Разные позиции команд тоже будут. Если каждый раз реагировать эмоционально, быстро перестанешь видеть суть.
Также важна настойчивость. Многие сервисные проблемы не решаются с первого обсуждения. Иногда нужно несколько раз вернуться к теме, собрать дополнительные данные, уточнить гипотезу, найти правильных людей и довести вопрос до результата.
Еще важное умение — быть «переводчиком» между разными участниками процесса.
Клиент говорит одно. Бизнес слышит другое. Разработка просит конкретику. Поддержка видит поток обращений. Мониторинг показывает цифры. И все это нужно собрать в понятную картину, из которой появляются конкретные действия.
Если этого не делать, сервис быстро превращается в набор разрозненных задач.
Итог
Видеть в Service Owner лишь новую позицию в оргструктуре — значит упускать главное. Это прежде всего способ сделать ответственность за сервис видимой и действенной: через конкретные метрики, работу с инцидентами, выстроенные процессы коммуникации и понятную обратную связь от клиентов.
Он не обязательно пишет код, не всегда сам проектирует интерфейс и не сам чинит каждый инцидент.
Но он должен понимать, где «болит», почему «болит», кто может помочь и что нужно сделать, чтобы в следующий раз болело меньше.
Эта роль не отменяет архитектурный долг и не снимает ответственность с команд. Но она хорошо показывает, где сервисом реально владеют, а где задачи просто ходят по кругу.
