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

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

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

Привет! Меня зовут Даша Боровик, я руковожу командой экспертов по клиентскому опыту в RUTUBE. База юзабилити-проблем сервиса — одно из детищ нашей команды. Как и многие в индустрии, мы сталкиваемся со сложностями в управлении CX-долгом и ищем свой подход. 

Если вы задумались над созданием или оптимизацией работы с бэклогом юзабилити-проблем — читайте эту статью. Я расскажу, как в RUTUBE управляют CX-долгом, зачем его вообще трогать и почему ну никак не получится махнуть на него рукой. А ещё честно предупрежу о сложностях, с которыми мы сталкиваемся — ведь наш процесс, хоть и рабочий, совсем не идеальный. И если у вас есть идеи и советы, поделитесь в комментариях.

Привет! Меня зовут Наташа, я ведущий исследователь в RUTUBE. Я изучаю поведение и потребности пользователей, чтобы помогать продуктовой команде улучшать опыт зрителей и авторов RUTUBE.

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

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

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

Существует много известных методологий оценки удобства использования веб-сайтов и приложений (UMUX, SUS и т.д.). Есть также комплексные метрики, где оценка внешнего вида является одним из измеряемых критериев (например, SUPR-Q). Но широко применимых методологий для оценивания именно визуальных характеристик интерфейса, которые подходили бы под наши задачи, нет.

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

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

В этой статье расскажем, как устроено файловое хранилище RUTUBE с точки зрения SRE, как мы пришли к именно такой конфигурации и как она работает на наших объемах — сейчас это порядка 400 Пбайт и 2 млрд объектов. 

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

Мы, Тимофей Соломенников и Руслан Мирзоев, разработчики онлайн-кинотеатра PREMIER, хотим поделиться своим опытом и на реальных примерах показать, что даёт правильное использование структур данных.

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

Создавать что-то новое — неважно, будь то продукт или команда — интересно и сложно. Зачастую по чужим готовым лекалам действовать не получается. А если это «новое» создаётся в большой компании, изменения надо стыковать со многими элементами действующей структуры. Короче, задачка получается со звёздочкой.

Меня зовут Даша Боровик. Сейчас я руководитель команды экспертов по клиентскому опыту и доступности в RUTUBE. А пару лет назад передо мной встала непростая задача — внедрить новую роль в компанию и собрать команду с нуля. Я искала материалы, которые бы подсказали мне, что и в какой последовательности делать — но, казалось, ни одна из найденных статей и заметок не подходила мне идеально. 

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

Да кто такой этот ваш 2D-скролл? Зачем он нужен, если ты не делаешь аналог excel? На самом деле, двунаправленная прокрутка нужна в огромном количестве сценариев использования мобильных приложений, в виде таблицы можно представить самые разные сущности — как, например, наш видеоредактор. 

Есть только одна маленькая проблема: видеоредактор Yappy кроссплатформенный, написан на Flutter, а до недавнего времени команда фреймворка предлагала только один способ реализовать 2D-скролл — очень не производительный. В статье рассказываю, в чём была была загвоздка, что есть во Flutter сейчас и каких впечатляющих результатов можно добиться собственной реализацией. 

Привет, Хабр! Меня зовут Дмитрий Иванов, я начальник отдела эксплуатации IT-инфраструктуры RUTUBE, что на наши деньги переводится как SRE-тимлид. В этой статье разберу задачу доставки контента и расскажу и решениях, которые помогают нам в RUTUBE. 

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

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

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

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

Как у нас в RUTUBE ИИ и служба клиентского сервиса работают сообща, вместе справляются ростом сервиса и мгновенно адаптируются к изменениям — рассказываем в этой статье. Делимся рецептом RAG-системы, которая за первые три месяца эксплуатации уже отвечает почти на 70% запросов пользователей и никогда не врёт про «космических зайцев». 

Привет! Меня зовут Костя, я Android-разработчик в онлайн-кинотеатре PREMIER. В процессе работы над проектом PREMIER для AndroidTV я столкнулся с тем, что в Jetpack Compose механизм фокусов — достаточно сложная и неочевидная тема. А информации в интернете об этом очень мало, особенно о специфичных сценариев вроде ТВ-приложений или устройств без сенсорного ввода.

Поэтому я решил разобрать тему фокусов в Compose максимально подробно, чтобы помочь разработчикам лучше понять этот механизм и избежать типичных ошибок. В первой статье на эту тему мы уже разобрали базовую структуру фокусировки в Compose. Теперь пришло время углубиться в технические детали: что именно происходит, когда вызывается requestFocus(), как Compose выбирает элемент для фокусировки и какие изменения были внесены в Compose 1.8, чтобы улучшить этот процесс.

Если вы работаете с приложениями под Android TV, кастомными компонентами или просто хотите лучше понимать, как работает система фокусов, эта статья для вас.

Привет! Меня зовут Костя, я Android-разработчик в онлайн-кинотеатре PREMIER. Среди прочего у нас есть приложение для Android TV. Работая над ним, я столкнулся с тем, что система фокусов в Jetpack Compose устроена сложнее, чем кажется на первый взгляд. Поскольку для ТВ-приложений и устройств без сенсорного управления работа с фокусом играет ключевую роль в навигации, мне понадобилось детально разобраться в теме. Результатами делюсь в статье.

Бизнес без устали тестирует разные гипотезы о том, как логично внедрять customer experience (CX) в производство своих продуктов. От команды к команде опыт подхода к этому «снаряду» отличается. Даже в рамках одной компании бывает, нет единого представления, как «сочетать несочетаемое»: ориентироваться на клиента и при этом зарабатывать деньги.

В RUTUBE мы нашли свой путь: пригласили в продуктовые стримы отдельных сотрудников. Их задача — погружать продуктовую команду в пользовательские запросы и потребности. А фоном — продвигать стратегию (и идеологию) классного клиентского опыта. Мы назвали себя Customer Journey Experts.

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

Simple Storage Service или S3 — сервис (и одновременно протокол) для хранения данных большого объёма. Для работы использует API поверх HTTP, который позволяет загружать или получать объекты из хранилища.

В проектах с приватной инфраструктурой часто возникает потребность в организации on-premise S3-хранилища. Популярное решение в таком случае это MinIO — удобная и довольно простая в использовании реализация сервиса S3.  Когда нам в RUTUBE потребовалось S3, мы не стали долго думать и взяли MinIO, потому что он стильный, модный, молодежный хорошо себя зарекомендовал на рынке, хорошо документирован и прост в первоначальной настройке и эксплуатации. 

В этой статье поделюсь своим опытом использования MinIO, сделав акцент на отказоустойчивости и сохранности данных в случае инцидентов разной степени — от выпадения диска до пожара в цоде.

За полгода с июля 2024 года большинство аудиторных и технических показателей RUTUBE выросло в разы: количество ежедневных пользователей выросло почти в 4 раза; количество видео, ежедневно загружаемых на видеохостинг — в 3 раза, с 330 тыс. до 1 млн единиц контента; CDN-трафик — в 4 раза и в пиковые часы превышает 7 Тбит/с. Как архитектура сервиса показала себя в условиях продолжительного «нагрузочного тестирования» и как команда переживала такой рост нагрузки, читайте в этой статье.