Как стать автором
Обновить

Per Aspera Ad Astra: как развивался сервис на 50 миллионов зрителей

Время на прочтение 10 мин
Количество просмотров 18K
Привет, Хабр! Меня зовут Александр Дружков, сейчас я работаю заместителем технического директора ivi. Помню наш сервис маленьким сайтом, который бесплатно показывал интересные фильмы в промежутках между рекламой. Я расскажу, как нам удалось проделать путь до сервиса на 50 миллионов пользователей, какие технологии и решения нам помогли, с какими трудностями сталкивалась наша команда и как менялись наши задачи.

Как все начиналось
Давным-давно в одной далекой-далекой галактике появился доступный широкополосный интернет. Ночные посиделки в чатах и скачивание по одному файлу ушли в прошлое, а заодно появилась возможность смотреть видео прямо в сети. Правда, за простой идеей трансляции контента скрывалось множество сложных технических вопросов: от стыковки маршрутизаторов разных производителей и собственной CDN до поддержки IPv6 и многократного ежедневного деплоя релизов на прод. Здесь sci-fi заканчивается и наступает саспенс.
В начале пути перед нами стояли стандартные для таких сервисов вызовы, которые и легли в фундамент будущей цитадели. Основная задача любого OTT-сервиса — нести контент в одну сторону, а прибыль — в другую. Звучит легко, но если углубляться в детали дальше, то появляются серьезные требования к сетевой инфраструктуре, гибкому распределению рекламных роликов, рекомендательным сервисам, а главное — взаимодействию между разработчиками.
В этот период можно выделить две большие задачи, которые вывели нас на новый уровень. Во-первых, интеграция с платежными системами: до этого момента основная монетизация шла за счет показа рекламы пользователям, а затем к ней добавили платную модель доставки контента. Вторым важным этапом стало внедрение авторизации через социальные сети. Этот шаг сделал контент еще доступнее для пользователей.
Был забавный момент, когда на форуме техподдержки одной из соцсетей наш разработчик отвечал, как именно нужно использовать их API, пока поддержка хранила гордое молчание.
В 2010 году, после того, как новость про ivi прошла на федеральных каналах, сайт упал на несколько минут. А уже летом следующего года рунет распробовал бесплатное кино, и рост нагрузки некоторое время обгонял рост мощностей. Весь трафик проходил через каналы единственного провайдера из единственного московского дата-центра и легко мог попасть к конечному пользователю через Амстердам.
Долго так длиться не могло, и мы решились создать собственную CDN (сеть доставки контента — Content Delivery Network). Уже тогда на центральной площадке архитектура серверов разделялась на пограничные (edge) и исходные (origin) серверы. Оказалось, что edge-серверы удобно выносить на внешние площадки. В итоге к 2014 году компания ivi самостоятельно развернула узлы в 20 городах России и в странах СНГ и начала сама балансировать нагрузку между узлами.
Думаю, если бы мы сейчас увидели старые спецификации, это бы вызвало лишь улыбку на фоне того, какие теперь у нас запросы.
Сейчас узлов CDN более 30, а московский трафик распределяется между тремя точками присутствия, соединенных кольцом. Если один ЦОД откажет (падение метеорита, нашествие марсиан и прочие ЧП, которых нет в ГОСТах), обслуживание продолжится на оставшихся, а пользователь даже не заметит изменений. В регионах узлы значительно проще: они содержат от одного до восьми серверов плюс коммутатор. Их задача — держать контент близко к пользователям и не гонять трафик по магистральным линиям.
В самом начале предпочтение отдавалось оборудованию Cisco, но с ростом мы стали толерантнее: сейчас у нас оборудование от Cisco и Huawei до D-Link и Ubiquity. Основные требования предъявляются к итоговой стоимости эксплуатации и надежности оборудования, которая определяется собственной методикой тестирования. Перед тем как ввести новые модели в работу, мы усиленно гоняем их на стендах, проверяем работу под нагрузкой, смотрим за удобством эксплуатации и качеством технической поддержки от производителя. Наша основная цель — удостовериться, что оборудование справится с поставленной задачей, отработает свои деньги и не отправится в Вальхаллу раньше времени.
Сетевики — такие ребята, которые легким движением руки могут уронить весь сервис. Естественный отбор в нашей среде особенно суров. Поэтому у нас любая более-менее значимая работа включает планирование и подготовку на случай, если что-то пойдет не так.
Сейчас сетевая команда ivi занимается переходом на IPv6. Уже есть выделенный диапазон адресов, увеличивается число присоединенных операторов связи. Пока IPv6 применяется для технических целей: межсерверного общения и связи площадок между собой. Основной профит от перехода придет чуть позже, о чем до конца года будет отдельная статья.
Как кораблю разработки пройти через бутылочное горлышко взаимодействия
На старте ivi собственными силами развивал все направления системы: сетевую инфраструктуру, API приложений, разработку клиентских приложений. Но некоторые из них все же разрабатывались сторонними подрядчиками. И только завернув всю клиентскую разработку на себя, мы избавились от бутылочных горлышек во взаимодействии.
Менеджер работал с огромным количеством технической информации. Естественно, подобная схема не могла выдержать роста аудитории, поэтому мы разделили функции продуктового и проектного менеджера и сосредоточили разработку внутри компании. Проблем меньше не стало, но появилась возможность решать их скопом, вместе с проблемами роста и масштабирования.
Существует множество технологий, без которых сегодняшний рынок сложно представить. Трудно выделить что-то одно, однако я бы остановился на nginx, так как это ключевая технология, которая используется для стриминга.
Постепенно разработка усложнилась настолько, что изобретение собственных велосипедов (как это было с CDN) превратилось в искусство. Задач много: ребята пробуют новые форматы (HDR, HDR10+, Dolby Vision), кодеки, протоколы, технологии защиты контента.
В результате мы первыми в России добавили видео в формате Dolby Vision. В нем используются динамические метаданные, телевизор калибруется для каждого кадра, благодаря чему цветовая палитра и диапазон яркости становятся шире.
Еще одним нашим достижением стала автоматизация контроля качества нашего каталога. Контент, который к нам приходит, может содержать различные артефакты. Например, отсутствуют одни кадры и дублируются другие, из-за чего видео дергается. Или проблемы с объемным звуком в формате 5.1, когда один из каналов тише, чем другие. Артефакты возникали из-за неправильного перекодирования или ошибок в оригинальном файле. Вначале все это отслеживалось вручную. Да, была должность, на которой люди только сидели и смотрели фильмы. Они часто пропускали ошибки, очень быстро «выгорали», начинали ненавидеть кино и переставали пользоваться ivi. Наши R&D взяли дело в свои руки, автоматизировали процесс и спасли этих ребят.
Для R&D очень важно иметь максимально широкую компетенцию и уметь решать со вкусом любую проблему на любом устройстве, вплоть до воспроизведения 4K-контента на первых Apple Watch. И в этом только доля шутки, как вы понимаете.
С ростом аудитории увеличивалось количество поддерживаемых платформ. Важным шагом стала ориентация сервиса на работу со Smart TV. Легальные OTT-сервисы стали популярными во многом благодаря распространению SmartTV. Сейчас разработка в ivi ведется под шесть основных платформ: iOS, Android, Web, Smart TV, Windows + Xbox, PS4. Из-за таких «джунглей» перед разработчиками встало несколько сложных задач: необходимо выпускать продуктовые фичи на всех платформах одновременно и следить за тем, чтобы ничего не сломалось в старых приложениях.
Самой сложной платформой является SmartTV. Десяток вендоров, и каждый изобретает велосипед в вопросе операционной системы. В итоге нужно быть готовым к особенностям их работы еще на стадии придумывания фичи. Не все взлетает сразу, но надо работать.
У производителей SmartTV может отличаться аппаратное и программное обеспечение, а старые модели могут не обновляться. Еще одна беда — контент на платформах потребляют по-разному, каждой требуются свои фичи. В результате сложилась ситуация, когда у одного и того же приложения были свои функции и бизнес-логика для каждой платформы. Пользователей это раздражало, а разработчиков — злило.
Как сейчас работает команда разработки
Чтобы избавиться от накопившихся проблем, мы провели agile-трансформацию, добавили гибкости в вопросах взаимодействия продукта и технологий. Ввели практику ежедневных релизов там, где это возможно, и раз в две недели там, где это ограничено платформой (iOS, Android). А в 2017 году стали очень активно применять процессный фреймворк scrum, а также стали нанимать и воспитывать scrum master'ов, которые делали работу эффективнее, настраивая процессы в командах. Такая гибкость потянула за собой серьезные изменения в системе тестирования. Система пережила несколько реинкарнаций как с точки зрения управления, так и с точки зрения технических инструментов.
Мы требуем от наших тестировщиков высокого уровня технических скилов и самостоятельности, но при этом предоставляем свободу действий.
У ivi был период, когда все тестировщики относились к командам разработки, однако несколько лет назад тестирование выделилось в самостоятельный отдел, который обеспечивает качество продукта на всех этапах. Система тестирования backend и некоторых клиентских приложений подстроена под ежедневный релизный цикл, однако у нас также остались более долгие релизные циклы, требующие серьезных регрессионных проверок. Сейчас мы как раз активно работаем над автоматизацией регрессионного тестирования, тут у нас большая точка роста.
Тестировщики принимают участие в процессе создания фичи (от возникновения идеи до проверки ее на пользователях) и самостоятельно определяют сроки тестирования. Даже джун может выдать в релиз фичу, если ее одобрит тимлид тестирования платформы. А это сложно, так как тимлиды занимаются черной магией, а если находят баг — приносят неудачливого джуна в жертву богам Хаоса.
Нет технологической проблемы в разработке сервиса, так как это сложный, но вполне сходящийся интеграл, если говорить математическим языком. А вот выстроить продуктивный и работающий процесс взаимодействия десятков разработчиков, тестеров, продуктологов и дизайнеров — это уже несколько другой уровень катастрофы.
Так как джунов на все темные ритуалы не хватает, ivi приходится готовить кадры самим. Как ни удивительно, глобальные требования к новым сотрудникам не меняются. Кандидат должен быть профессионалом в своей области: знать профильный язык программирования, набор инструментов для работы с тест-кейсами и автотестами, механизмы деплоя кода и управления конфигурациями.
Из-за перехода на гибкую методологию разработки повысились требования к умению договариваться с коллегами и совместно приходить к решениям, выгодным для всей команды.
Что ждет новичков в ivi
Интеграция разработчика в проект, над которым он будет работать хотя бы на базовом уровне, занимает минимум 3 месяца. А на полное погружение в проект — решение задач любого уровня сложности, оперативный разбор инцидентов, предложения оптимизации — уходит до года.
Для нас важно, чтобы сотрудники были хорошими командными игроками. Это не значит, что мы берем на работу только гуру коммуникаций: мы всегда помогаем наладить взаимодействие между сотрудниками или прокачать коммуникационные навыки. Однако базовые навыки общения все же должны быть.
Кроме того, HR-отдел собрал следующие грабли:
    • Обучение новичков проводилось хаотично, по принципам «выплывет — не выплывет» и «расскажу, что вспомню», отнимало у тимлида много времени.
    • Новички терялись в обширной документации и упускали много важной информации.
    • Новички долго осваивались в проекте, не видели системы в целом и иногда так оптимизировали одну часть, что ломали другую.
    • Новички не всегда получали обратную связь. В итоге получалась странная ситуация: тимлид злился, что новичок работает плохо, а новичок думал, что все отлично.
    • После испытательного срока не всегда было очевидно, оставлять сотрудника или нет. В результате и новый сотрудник, и команда мучились друг с другом еще полгода-год.
    Был грустный случай. Около 5 лет назад я начал всем новым сотрудникам читать вступительную лекцию об устройстве нашего сервиса. На очередную лекцию пришел новый продуктовый менеджер, уже проработавший месяц, но пропустивший лекцию. В конце занятия он выглядел ужасно расстроенным. Когда я поинтересовался, что же его так расстроило, он поднял на меня полный боли взгляд и сказал: «Я целый месяц все это вытаскивал по крупицам из чертового количества людей! Почему ты не позвал меня раньше?!»
    Дальше это терпеть было нельзя, поэтому в ivi разработали новую систему онбординга для всех новых сотрудников. Она включает в себя:
      • Дорожную карту — понедельный план всех задач сотрудника на испытательный срок. От настройки почты, получения пропуска и подписания документов у HR до изучения проекта и активного участия в процессах команды.
      • Quick Start — справочник по каждому из проектов технического департамента. Набор всех необходимых ссылок с информацией о продукте ivi, основных процессах компании, структуре технического департамента.
      • Индивидуальные встречи с тимлидом, где можно обсудить текущие сложности, получить ответы на вопросы и дать отзыв о системе обучения.
      • Performance Review через 2 месяца — сбор обратной связи от коллег, с которыми работает сотрудник. На его основании подводятся итоги испытательного срока.
      Среди задач, стоящих перед техническими подразделениями ivi, можно выделить несколько особо важных:
        • полное обновление технологического стека сайта;
        • внедрение новой системы мониторинга и контроля качества работы сервисов;
        • разработка новой версии системы рассылки push и email уведомлений;
        • изменение системы оркестрации.
        Если вдруг стало интересно, не пугает возможность попасть к «силам зла», ivi ищет себе frontend-разработчика приложения для Smart TV и руководителя группы тестирования backend. Но есть у компании и другие вакансии. Бонусом к интересной работе идет новый офис.
        Теги:
        Хабы:
        +25
        Комментарии 6
        Комментарии Комментарии 6