2020 оказался годом удаленки. Уже в марте прошлого года я был вынужден перевести всю команду на полностью дистанционный формат работы и все процессы пришлось настраивать заново. Отдельной болью для нас стали видеозвонки. И началось: «Ой, а давайте в Скайпе, Дискорде, Телеграме, Зуме». А потом то девайсы программное обеспечение криво поддерживают, то технические сбои, то аккаунты вне доступа, то обновление софта и еще вагон проблем. Уходила куча времени, чтобы просто связаться и провести совещание. В общем, уже через месяц подобных экзекуций мы психанули и стали разрабатывать свою собственную систему видеосвязи. С какими трудностями столкнулись, как решали задачу и что из этого получилось — читайте в статье. Буквально за несколько месяцев после начала карантина количество пользователей Zoom увеличилось в 30 раз. В декабре 2019 года ежедневно сервисом пользовались 10 млн людей, а в апреле 2020 — уже 300 млн. Поначалу мы тоже использовали Zoom для общих видеоконференций. Были небольшие проблемы со стабильностью сервиса — сервера не выдерживали нагрузок и иногда звонки жутко тормозили — неприятно, но ничего критичного. Во всяком случае, мы так думали. А потом мы узнали о массивной утечке данных. В апреле 2020 хакеры взломали базы данных Zoom и в сеть утекли данные свыше 500 000 аккаунтов. Логины, пароли, email, URL личных чатов, коды администраторов для управления конференциями. Более того, уязвимости Zoom можно было использовать для получения удаленного доступа к компьютеру и защищенным файлам. Топовый сервис для видеоконференций оказался не просто ненадежным, а даже опасным. Вопрос безопасности встал очень остро. С зумбомбингом мы хоть не встречались, но были наслышаны и о нем. Насчет удобства использования сторонних сервисов, все также было не очень гладко. При обсуждении рабочих вопросов один на один или малыми группами чаще всего использовали Skype или Facebook Messenger. Для встреч по отделам и общих конференций — Zoom. И самым проблемным оказалось отсутствие единой базы записей видеозвонков. Попытка пересмотреть обсуждение какого-нибудь вопроса превращалась в квест.  Со стабильностью все было тоже не очень гладко. В марте у нас была ситуация, когда из-за обновления софта три участника важного видеозвонка просто не смогли подключиться. Танцы с бубном не помогали — фактического контроля над внешними зарубежными приложениями нет никакого и нет никакой возможности понять, что не так. В результате через полчаса пришлось переносить встречу на другой день. Время и нервы потрачены, результат нулевой. Да и в целом организационные моменты подталкивали на разработку своего софта для видеозвонков. С той лишь разницей, что мы видели его не как отдельное решение, а встроенный в нашу CRM видеочат для обсуждения рабочих задач и проектов, уже заведенных в систему. Тем более, что идеи уже были. Нам нужно было добиться  стабильной работы на всех ОС и мобильных платформах. Получить доступ к API и сделать существующие решения удобнее конкретно для нас — тоже не вариант. Разработчики либо вообще не давали доступ к API, либо это стоило космические деньги. В общем, в апреле 2020 года мы серьезно нацелились на разработку многофункциональной платформы видеосвязи, которая покроет не только наши хотелки, но и решит проблемы наших клиентов. Впервые идея создать собственную платформу видеосвязи появилась у нас в 2015 году.  Мы даже выделили немного времени и разработали тестовую версию сервиса видеосвязи на Flash. Прописали буквально только базовый функционал, так что даже до демо-версии она не дотягивала.  В результате аналитики решили, что допиливать софт до релиза нецелесообразно. В разработку нужно было огромное количество денег, а рентабельность идеи была очень сомнительной. Мы не собирались превращаться в конкурента Skype, а в качестве дополнительной функции нашего продукта вложения в видеосвязь были неоправданно высокими. Тем более, что тогда еще не было адекватных технологий, с помощью которых можно было все это организовать. Первоначальный вариант на Flash нам не понравился — его было невозможно масштабировать, было много вопросов с технической точки зрения, да еще за сервер нужно было платить неплохие деньги. И хорошо, что мы тогда не стали искать выходы. Было бы печально вложить кучу денег во второстепенную функцию, а через 5 лет узнать, что все нужно делать заново, потому что Flash отключают. *** Весной 2020 года мы вернулись к идее собственной платформы видеосвязи. Потому что проблемы с организацией рабочего процесса, с которым столкнулись мы — не были уникальными. У многих наших клиентов были такие же, а у нас были технические и профессиональные возможности их решить.  Разработка первоначальной версии велась буквально на коленке. Сначала выбрали OpenVidu, который нас максимально устраивал и был доступен в плане лицензии. А затем буквально в течение нескольких недель собрали MVP и попытались интегрировать его в свой CRM-продукт. Опенсоурсная версия получилась рабочей, но у нее было несколько серьезных проблем: Продукт получился очень требователен к мощности сервера. Если для внутреннего использования это еще не критично, то для релиза нужны были отдельные серверы для видеосвязи. Коммерческая лицензия позволяла сделать продукт масштабируемым, но тогда все упиралось в стоимость серверов — оплата была не за использование фактических возможностей, а за время аренды серверов. Даже если сервер простаивает, за него нужно платить. Вылез целый ряд багов и проблем, решение которых мы в процессе первичной разработки не нашли. Среди них: a. Отсутствие записи трансляции. Наши специалисты не смогли придумать, как реализовать запись без слишком больших переделок или без использования сторонних утилит. b. У технологии не было мультиплексирования, поэтому использование видеосвязи слишко быстро сажало аккумуляторы смартфонов. Для ее решения нужны были специализированные хардварные решения, к которым мы были не готовы. c. В мобильной версии в целом было много багов, для фикса которых нужно было много времени. Самым проблемным оказалось то, что приложение во время звонка вылезает на передний план и свернуть его никак нельзя. Работать со смартфоном во время конференции становилось попросту невозможно. Мы были привязаны к технической поддержке с третьей стороны. Работа даже над простыми багами могла затягиваться на неопределенно долгое время. Стоимость использования OpenVidu считается за одно серверное ядро в минуту. Для небольших решений она приемлема, но это крайне затрудняет масштабирование сервиса — все упирается в деньги, много денег.  Количество минусов перекрывало все перспективы использования технологии. Поэтому мы решили от нее отказаться. Для передачи видеоданных мы используем стандартный протокол WebRTC. Стабильная платформа для видеосвязи, на которой можно реализовать все хотели и свистелки, которые нам нужны. Но обычного p2p соединения нам недостаточно, ведь нужно было реализовать возможность записи трансляции на сервер. Поэтому решили использовать ретранслятор Janus Gateway.  В целом выбирали между тремя платформами: OpenVidu, которую оставили как контрольный образец, Jitsi и Janus. В результате чтения аналитики выяснили, что OpenVidu сильно проседает по качеству картинки трансляции (как будто и так вопросов было мало), а у Jitsi во время нагрузки качество плавает. Не то, чтобы мы планировали делать конференции из 200-300 пользователей, но стабильность работы видеосвязи для нас — ключевой момент. Janus же наиболее стабилен. Он выдает стабильный битрейт, рационально используя ресурсы процессора. В целом Jitsi и Janus показывают хорошие результаты, но у Jitsi есть порог производительности, выше которого он просто падает. Как поведет себя система с кучей дополнительных фишек и на полной нагрузке, было неясно. У Janus есть куча полезных фич, которые не реализованы или платные в OpenVidu. К примеру, контроль качества связи и автоматическое выставление битрейта в зависимости от него. Или же поддержка кодеков VP9 и режима симулькаста.   Janus имеет ничтожное влияние на процессор и память сервера. Всё упирается только в пропускную способность сети. Поэтому можно брать не самые мощные сервера, а много маленьких и пару больших для декодирования и склейки записанных видеозвонков. Мы не стали прибегать к сторонним решениям, вроде Janus cloud, где узким местом и точкой входа всё равно является janus-proxy, а сделали балансировку на уровне продукта. С Janus все также получилось не слишком гладко. Для реализации WebRTC используется библиотека React Native WebRTC. Чтобы устранить проблемы совместимости протокола с софтом сервера, ушло довольно много времени. Для мобильной версии также пришлось полностью перерисовывать интерфейс. Стандартный вариант не подходил для маленьких экранов — когда количество участников конференции было больше пяти, видео просто не помещались на экран, что вело за собой ошибки отображения трансляции в целом.  Пришлось сильно заморочиться с решением проблемы, разделив потоки на отдельные экраны и оптимизировав рендер и отрисовку видео участников в реальном времени. Вообще с реализацией мобильных версий на iOS и Android было неожиданно много проблем. Разница на платформах между управлением динамиками и микрофоном, разные принципы переключения на громкую связь и наушники. Пришлось создавать универсальный код, который одинаково работал бы на обеих ОС.  Самой главной головной болью для нас стала «проблема пятого человека». Пять человек стабильно могли участвовать в конференции, но как только присоединялся шестой — одного выбрасывало из трансляции. С ней тоже удалось справиться. Альфа-версия видеосвязи нас удовлетворила, поэтому мы выкатили бету. И практически сразу же получили ряд хотелок и рекомендаций непосредственно от клиентов. Сохранять записи звонков. Эту фичу мы планировали, но она пока в стадии реализации и тестирования.  Нужно предоставить возможность скачать запись только участнику с наибольшими правами в конференции, чтобы она не ушла «на сторону». Проигрывание записи через встроенный плеер тоже будет актуальным, чтобы клиент не использовал сторонний софт. Скорее всего, придется ограничить время существования записи. Ведь в противном случае нам придется закупать отдельные серверы для хранения видеоконтента. Но доступ к записи на протяжении 24 часов убирает проблему — через сутки запись трансляции автоматически удаляется с сервера. Добавить вебинарную комнату — самый популярный запрос. Чтобы можно было, к примеру, проводить отчетные мероприятия. То есть, клиенты хотят не просто совершать звонки, а получить универсальный инструмент для организации рабочего процесса. Им его не хватает. Правда, с вебинарной комнатой у нас немного затык. Нужно добавить инструмент работы со слайдами без демонстрации экрана и вайтборд для рисования маркерами.  Если у вас есть идеи, как это сделать в рамках Janus с минимальным количеством вытекающих проблем — с радостью послушаем.  Плюс клиенты просят добавить другие мелкие фичи, которые они увидели в сторонних проектах. Вроде размытия фона, добавления фильтров или склейку. Это не в приоритете, но в дальнейшем мы собираемся реализовать и эти фичи. В целом разработка видеосвязи получилась неожиданной. Из инструмента, предназначенного для внутреннего использования, она стала частью нашего продукта и уже крепко вошла в инфраструктуру сервиса. Да, еще остается целая куча проблем с совместимостью, но результат уже рабочий и наши клиенты им активно пользуются.  Генеральный директор компании Мегаплан