Иногда легаси нельзя постепенно улучшить: его приходится разбирать, переосмысливать и заменять, пока основной продукт продолжает работать. Именно в такой ситуации оказались мы в Okko. Нам нужно было отделить воспроизведение от монолита, переписать транскодинг, заменить единовременно старую CMS и сохранить непрерывную работу онлайн‑кинотеатра. В результате мы получили единую Видеоплатформу с документированными API, собственным кодированием 4K и HDR, управляемой аналитикой и возможностью разворачивать отдельные инсталляции для внешних партнёров.

Привет! Меня зовут Юлия, я представляю компанию Okko — один из крупнейших и старейших онлайн‑кинотеатров России. Сервис появился в 2011 году и за это время вырос в сложный технологический продукт, ежедневно работающий с большими объемами видеоконтента и высокой нагрузкой.

В Okko я руковожу отделом discovery продуктов и сервисом «Видеоплатформа», и именно о нем пойдет речь в этой статье. Я расскажу, почему мы решили создать сервис, какие задачи перед собой поставили, с какими техническими и организационными вызовами столкнулись и как внедрили новую платформу без даунтайма основного продукта.

Почему мы решили строить Видеоплатформу с нуля

Несколько лет назад, только придя в Okko, мне предложили применить предыдущий опыт работы с видео и заняться обновлением внутренних инструментов. На первый взгляд задача звучала просто: «У нас уже почти всё готово. Нужно только собрать существующие решения, объединить их в единый процесс и быстро внедрить».

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

Сервис обработки видео — транскодер — работал на устаревшем оборудовании. Его возможности масштабирования были ограничены как доступными вычислительными мощностями, так и архитектурой самого решения. Увеличивать объемы обработки контента становилось все сложнее, а простое добавление серверов уже не решало проблему.

Редакторы и контент‑менеджеры, которые отвечают за наполнение витрины крупного онлайн‑кинотеатра, работали в CMS, созданной около 15 лет назад на C#. У системы не было отдельного бэкенда: клиентское приложение напрямую обращалось к базе данных. Это осложняло развитие продукта, повышало риски и практически исключало возможность гибко масштабировать отдельные компоненты и добавлять интеграции, чтобы ускорить работу.

Можно было сказать: «Система работает — и хорошо. Не стоит трогать то, что пока не ломается». В ее устройстве даже чувствовалась легкая винтажность, а винтаж, как известно, снова в моде. Однако компанию, которая хочет развивать сильный бренд, расширять огромную библиотеку контента, показывать крупные премьеры и лучшие спортивные лиги, такой подход не устраивал.

К тому моменту накопились проблемы, которые невозможно было игнорировать.

Разработка новых функций занимала слишком много времени. Команды постоянно сталкивались с ограничениями легаси‑кода, внутренней CMS и клиентского монолита. Даже небольшое изменение могло потребовать доработок сразу в нескольких тесно связанных компонентах.

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

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

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

Три цели новой Видеоплатформы

Обсудив с менеджментом ключевые показатели основного продукта и планы развития Okko, мы сформулировали три цели, которых хотели достичь при обновлении инструментов и сервисов для работы с контентом.

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

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

2. Не менее важная, а для менеджмента, пожалуй, основная: внедрить новую платформу без остановки онлайн‑кинотеатра. Okko не мог поставить работу продукта на паузу, отключить воспроизведение или временно отказаться от публикации нового контента ради миграции.

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

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

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

Так у проекта появились три уровня задач.

Метрики, по которым мы оценивали успех

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

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

Вторая метрика касалась обработки контента. Контент‑менеджеры не могли точно управлять временем выхода премьер, потому что никто не знал, сколько займет обработка конкретного файла. Для бизнеса это означало постоянную неопределенность: материал уже получен, дата публикации приближается, а назвать точное время готовности невозможно.

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

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

На тот момент у нас также не было собственного кодирования видео в 4K и HDR. Большое обновление платформы стало хорошим поводом не просто перенести существующие возможности, а добавить новые форматы непосредственно в сервис транскодирования.

Отдельной и принципиальной метрикой оставалось отсутствие простоя: внедрение новой платформы без даунтайма было ключевым требованием менеджмента и обязательным условием проекта.

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

Мы хотели видеть не только факт запуска видео, но и всю картину воспроизведения: скорость старта, количество ошибок, зависания, переключения качества и другие показатели, влияющие на пользовательский опыт. Эти данные должны были помочь нам проводить эксперименты с параметрами кодирования и способами доставки контента, а также быстро отвечать на главный вопрос: всё ли прямо сейчас хорошо у пользователя с просмотром?

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

Нам нужен план

На этом этапе случился классический мем: «Нам нужен план».

Мы разделили будущую видеоплатформу на несколько самостоятельных частей, каждая из которых отвечала за свой участок работы с видео. Таких направлений было три: плеер, транскодинг и интерфейс для загрузки и управления материалами — проще говоря, новая CMS.

Работу над ними мы разделили на два основных потока: разработку и интеграцию.

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

Плеер: всё уже придумали до нас. Или нет

На первый взгляд с плеером все должно было быть просто. Есть Google и Apple, готовые библиотеки для разных платформ, описанные протоколы и стандартные инструменты воспроизведения. Кажется, остается взять готовое решение, подключить его к приложению и перейти к следующей задаче.

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

Самой сложной и разнообразной платформой оказались ТВ‑поверхности. Там одновременно существовали легаси‑код, первые версии операционных систем популярных производителей и устройства, которые работали с устаревшими или редко используемыми протоколами доставки видео.

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

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

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

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

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

Поэтому нужно было не написать еще один плеер, а унифицировать подходы, определить зоны ответственности, выстроить единые правила развития продукта и собрать общую аналитику по всем платформам.

Как мы унифицировали плееры

Решать накопившиеся проблемы мы начали с довольно очевидных шагов. Сначала собрали отдельную команду, постепенно нанимая специалистов под каждую платформу. Затем зафиксировали требования и попытались разобраться, какую задачу изначально решала каждая из функций. Иными словами, выясняли, «что хотел сказать автор» — в нашем случае продакт, который когда‑то поставил задачу на разработку.

После этого проверили контракт взаимодействия с бэкендом и составили единый перечень аналитических событий. Он должен был помочь нам оценить результат интеграции и выполнить одну из ключевых метрик видеоплатформы — получить подробную и сопоставимую аналитику воспроизведения на всех устройствах.

Отдельной задачей стал выбор технологической основы. Мы изучили доступные открытые библиотеки для каждой платформы, выбрали решения, подходящие под наши требования, и на их основе сформировали собственные комплекты средств разработки — SDK. Они инкапсулировали основную логику воспроизведения и упрощали внедрение плеера в приложения Okko.

Интеграцию мы разделили по платформам. Начали с веб‑версии. С одной стороны, она казалась наиболее простой для первого запуска. С другой — была достаточно разнообразной по сценариям, чтобы полученный опыт можно было позднее перенести на мобильные устройства и телевизоры.

Саму веб‑интеграцию дополнительно разбили на несколько направлений: фильмы и сериалы, спортивный контент и детский раздел. У каждого были свои особенности. Для кино и сериалов важны переходы между эпизодами, продолжение просмотра и работа с субтитрами. Для спорта — минимальная задержка, стабильность прямого эфира и быстрое переключение между трансляциями. В детском разделе действовали отдельные требования к интерфейсу и пользовательским сценариям.

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

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

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

Модернизация транскодинга

Следующим этапом стала перестройка транскодинга — системы, которая принимает исходные видеофайлы и готовит из них версии для воспроизведения на разных устройствах.

Исходная ситуация была сложной. Сервис работал на устаревшем коде и старой версии библиотеки FFmpeg. Видео в 4K и HDR мы кодировали на стороне подрядчиков, из‑за чего тратили больше времени, денег и внутренних ресурсов. Вся система была развернута на физических серверах в одном дата‑центре.

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

К моменту, когда мы решили превратить наши внутренние технологии в самостоятельный продукт, команда модернизации транскодинга уже была сформирована. Это немного облегчило задачу: мне не пришлось начинать с найма и поиска базовой экспертизы. Я присоединилась к уже запущенному процессу, помогла синхронизировать технические решения с требованиями бизнеса и встроить транскодинг в общую концепцию видеоплатформы.

Нам предстояло решить несколько задач одновременно: обновить технологический стек, отказаться от критической зависимости от одного дата‑центра, научиться масштабировать обработку под фактический объем контента и перенести кодирование 4K и HDR внутрь компании.

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

Кодирование 4K и HDR мы перенесли внутрь Okko. Это позволило сократить зависимость от подрядчиков, лучше контролировать сроки обработки и быстрее вносить изменения в профили кодирования.

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

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

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

Что получилось после модернизации транскодинга

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

Одновременно мы расширили функциональность сервиса. Внутри компании появилось собственное кодирование видео в 4K и HDR, которое раньше приходилось отдавать подрядчикам. За счет этого мы сократили сроки обработки, получили полный контроль над процессом и сэкономили компании десятки тысяч долларов.

Дополнительный эффект получили после внедрения нового кодека в раздачу. За счет более эффективного сжатия объем передаваемых данных сократился примерно на 10%. Для онлайн‑кинотеатра с большой аудиторией даже такая доля означает заметное снижение расходов на доставку видео.

Как мы внедряли новый транскодер

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

Пользователей сервиса мы переводили в зависимости от того, какие выходные материалы им требовались. Отдельными потоками мигрировали обработку трейлеров, полнометражных фильмов и записей спортивных событий.

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

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

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

Самая любимая часть — CMS

На тот момент системе было около 15 лет. Почему ее так долго не обновляли? Причина стандартная для быстро растущего бизнеса: ресурсы в первую очередь направляются на внешние функции, которые видит B2C‑пользователь. Внутренние инструменты почти всегда отходят на второй план.

Логика понятная: внутри как‑нибудь справимся, наймем людей, придумаем обходной путь, еще немного потерпим. Однако постепенно внутренний инструмент становится узким местом. Он начинает сбоить, замедляет работу, требует все больше ручных операций, а накопленный техдолг делает его обновление почти невозможным. Именно в такой ситуации находились мы. 

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

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

Задача выглядела одновременно тривиальной и сложной. Тривиальной — потому что общий план был очевиден: собрать требования, описать пользовательские сценарии, найти все интеграции, выяснить зависимости и перенести систему на новый стек. Сложной — потому что почти ничего из этого не было задокументировано.

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

За годы существования CMS в ней накопилось множество функций, причины появления которых уже никто не помнил. Часть использовалась по привычке, часть дублировала другие процессы, а некоторые сохранялись только потому, что все боялись их удалить.

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

Ночная миграция и два месяца усиленной поддержки

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

Ситуацию осложняло то, что мы не могли остановить развитие основного продукта. Пока мы собирали требования и создавали новую систему, бизнес продолжал запускать проекты, добавлять контент и развивать пользовательские сценарии. Старая CMS обрастала новыми функциями, а мы пытались ее догнать. Получалась гонка: мы переписывали систему, которая продолжала меняться прямо во время переписывания.

В какой‑то момент стало ясно: без фиксации требований мы не закончим никогда. Тогда договорились с бизнесом объявить мораторий на изменения в старой CMS. Новые функции временно перестали добавлять, а мы получили возможность стабилизировать новую систему, завершить тестирование и подготовиться к переключению.

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

А затем одной весенней ночью мы переключили онлайн‑кинотеатр на новую CMS. Осознание того, что все действительно получилось, пришло не сразу. После миграции мы еще около двух месяцев находились в режиме усиленной поддержки — hypercare. Команда внимательно следила за системой, разбирала ошибки, помогала пользователям осваивать новые процессы и исправляла сценарии, которые невозможно было обнаружить заранее.

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

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

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

Что в итоге мы построили

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

Раньше плееры, транскодинг и CMS существовали как отдельные элементы большой системы, каждый со своими правилами, зависимостями и зонами ответственности. Мы объединили их в единый механизм, который отвечает за весь путь видеоконтента — от загрузки и обработки до воспроизведения на устройствах многомиллионной аудитории Okko.

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

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

Так внутри компании появились команды и экспертиза по разработке кроссплатформенных плееров, транскодированию, адаптивному стримингу, аналитике воспроизведения, работе с кодеками и оптимизации видеотрафика. Кроме того, мы приобрели компетенцию, которой раньше в Okko практически не было, — научились создавать внутренние CMS и полноценные B2B‑системы.

Исторически онлайн‑кинотеатр был сосредоточен на взаимодействии с конечным зрителем. Основные продуктовые и инженерные ресурсы направлялись на B2C‑сценарии: витрину, рекомендации, просмотр и пользовательский опыт. В ходе этого проекта нам пришлось научиться проектировать продукт для другой аудитории — редакторов, контент‑менеджеров, технических специалистов и внешних команд.

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

К этому моменту все три части Видеоплатформы уже прошли проверку реальной эксплуатацией. Они работали под нагрузкой крупного онлайн‑кинотеатра, обрабатывали премьеры и спортивный контент, поддерживали разные устройства и ежедневно использовались внутренними командами.

Тогда перед нами возник логичный вопрос: если компетенции уже сформированы, технологии проверены практикой, а система выдерживает требования Okko, почему бы не вывести эту экспертизу на внешний рынок? Можно сказать, что сама вселенная подводила нас к третьей цели — превращению внутренней видеоплатформы в самостоятельный B2B‑продукт.

Как внутренняя платформа стала B2B‑продуктом

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

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

Поскольку платформу можно разворачивать в облачной инфраструктуре, мы получили возможность гибко управлять вычислительными ресурсами. Если объем контента или нагрузка растут, мощности можно увеличить. Если потребность снижается — сократить. Клиент при этом оплачивает фактически используемые ресурсы, а не постоянно зарезервированную инфраструктуру с большим запасом.

В B2B‑версию мы включили ключевые сервисы и функции, которыми сами ежедневно пользуемся внутри Okko: загрузку и управление контентом, транскодирование, подготовку видео к раздаче, плееры и аналитику воспроизведения.

При этом основной акцент сделали на двух направлениях:

1. Наша экспертиза в обработке и кодировании видео. Платформа поддерживает разные разрешения, профили качества, адаптивный битрейт, 4K и HDR, а также позволяет оптимизировать объем трафика и стоимость доставки контента.

2. Возможность бесшовно встроить платформу в уже существующий продукт партнера. Для этого предоставляем документированный B2B API.

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

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

Так внутреннее решение Okko постепенно превратилось в самостоятельный B2B‑сервис.

Первый внешний пилот и дальнейшее развитие продукта

Первый пилот не заставил себя ждать. Уже больше года мы предоставляем нашу технологию компании «Звук», которая использует ее для показа видеоклипов на разных пользовательских поверхностях.

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

Развивать внешний продукт мы планируем по тому же принципу, который уже показал свою эффективность: сначала тестируем новую технологию внутри Okko, проверяем ее под реальной нагрузкой, дорабатываем на собственных сценариях и только после этого добавляем в B2B‑версию платформы.

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

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

Такие инструменты могут упростить разметку видео, ускорить подготовку метаданных, помочь находить нужные фрагменты и сократить объем ручной работы для редакторов и контент‑менеджеров. При этом мы придерживаемся того же подхода: сначала проверяем технологию на внутренних процессах Okko, оцениваем ее точность и реальную пользу, а затем предлагаем внешним клиентам.

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

Какие уроки мы вынесли из проекта

Возможно, некоторые из них покажутся очевидными, но на практике именно простые принципы чаще всего теряются за архитектурными схемами, сроками и техническими ограничениями.

Не выбрасывать легаси целиком только потому, что оно старое.

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

Декомпозируйте, разделяйте и еще раз разделяйте.

Разбиение большой системы на самостоятельные продукты, этапы и сценарии сделало наш проект управляемым. Мы могли отдельно развивать плееры, транскодинг и CMS, формулировать для каждого направления собственные метрики и выбирать подходящую стратегию внедрения.

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

Всегда думайте о пользователях, но не додумывайте за них.

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

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

Именно в такие моменты обнаруживаются неочевидные зависимости, пропущенные функции и действия, которые команда разработки считала несущественными.

Иногда стоит всерьёз подумать, не проще ли отдать задачу внешнему исполнителю.

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

Мы были готовы пройти этот путь и в итоге превратили внутреннюю технологию Okko в самостоятельный продукт. Однако перед началом подобного проекта стоит честно ответить на вопрос: готова ли ваша команда к такому масштабу изменений и действительно ли компании необходимо создавать всю видеотехнологию самостоятельно? Говорят, что нужно учиться на ошибках. Я бы добавила: лучше учиться на чужих ошибках, чем повторять весь путь самостоятельно.

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

Спасибо, что прошли этот путь вместе со мной.

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