Привет, Хабр! Меня зовут Александр Дружков, сейчас я работаю заместителем технического директора 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. Но есть у компании и другие вакансии. Бонусом к интересной работе идет новый офис.