Выступление Игоря Таранцева, руководителя отдела программных разработок компании Softlab-NSK, с докладом «Предложения Softlab-NSK для развития современного ТВ» на Online круглом столе «Broadcasting 2021. Облачные сервисы ТТЦ “Останкино”» 25 мая 2021 года. Опубликовано в ТКТ № 06 (734) 2021.
Павел Агейкин, главный технолог телецентра «Останкино»: Хочу представить следующего нашего докладчика. Это Игорь Таранцев, руководитель отдела программных разработок компании Softlab-NSK. Тема доклада «Предложения Softlab-NSK для развития современного ТВ».
Игорь Таранцев: Я представляю компанию Softlab-NSK из Академгородка. Работу в облаке мы начали еще в 2017 году. Сейчас продвигаем на выставке первые наши решения, предлагающие компаниям резервировать в облаке.
В настоящий момент у нас уже десятки индивидуальных клиентов. Есть пара очень интересных больших компаний с офисом в Лондоне (на самом деле это прибалтийские ребята, которые предоставляют в чистом виде сервис на базе нашего облачного решения). Другой проект в Индии, в Мумбае. Там 50 каналов вещания в интернет, больше миллиона зрителей. Наше декорирование метками SCTE позволяет учитывать просмотр каждого ролика каждым зрителем, все это подсчитывается, работает и приносит копеечку. Понятно, что мы свои решения в облаке постоянно подстраиваем так же, как и обычные стандартные решения, не облачные, то есть с поддержкой телетекста, субтитров и пр. Из последних проектов, близких к облачным, это проект на 30 городов в Татарстане. В Казани местное локальное облако, то есть компьютеры под собственным контролем, и из 30 городов люди заходят, загружают расписание, выгружают ролики, готовят разные титровальные события. Каждый меняет сайт, как ему надо, и это все уходит в эфир автоматически. Это понятное, традиционное, давно работающее решение по вещанию, целиком включающее в себя телеканал. Есть телеканал в коробке, а это телеканал в облаке.
Но сегодня я обратил бы внимание на существующие там проблемы. Одна из проблем – это резервирование не самого облачного решения, а резервирование системы защиты. Понятно, что в облаке не может быть какой-нибудь «железной» защиты, там стоит виртуальный ключ. Этот ключ помогает зайти на лицензионный сервер и проверить, что он работает. Если сервер лицензии «упал», то каналы ни у кого не работают. У нас стоит тройное резервирование площадки на разных континентах, один сервер в России. Если вдруг отключат сервер в России, то наши каналы все равно будут работать. Кроме стандартного, есть дополнительный мониторинг, через секунду позволяющий понимать, что произошла поломка. Есть свое устройство резервирования, когда идет один канал резерва IP-out, второй канал резерва IP-out и коммутатор отхода, который переключает выход.
Все входы аналогично будут резервироваться, причем как однотипные входы UDP/RTP/SRT, так и разнотипные. Канал может декодироваться с одного источника, например, SRT, и с другого, например, HLS. Оба эти сигнала внутри резервируется очень прозрачно, человеку напрягаться вообще не надо.
Следующий очень важный вопрос – это вопрос генлока. Люди в аппаратной привыкли работать с нормальным генлокированным сигналом. Отсутствие генлока создает очень много проблем, а наличие генлока сильно упрощает работу. Вы включили запись на пять минут или на восемь часов, у вас файлы записаны на разных магнитофонах и дают вам одинаковую длительность и синхронность с точностью до кадра. У нас генлок позволяет в виртуальных платах виртуальной машины синхронизовать кадр точнее. Мы работаем с разными кодеками и, если есть вопросы, можно поговорить о том, что можно в реальном облаке использовать, а что использовать очень проблематично. Я не зря спрашивал про Nvidia, 4K,H-EVC. Но я бы сегодня сделал акцент не на стандартном использовании решения с кодированием, перекодированием и так далее, а на сплайсинге. Сейчас первый мультиплекс полностью перешел на работу с SCTE-35, и цифровой сплайсинг там прекрасно работает. У нас есть свое решение для сплайсинга. которое прекрасно работает в облаке, позволяет делать не только врезку рекламы (для чего он исходно и создавался), но и врезку живых новостей. Часовые блоки местных новостей в прямом эфире – никаких проблем. Этот же сплайсинг может делать перехват для МЧС тоже без проблем: подвели маленький канал со звуком, звук идет и делается перехват, как положено. Самое главное здесь, на мой взгляд, что ресурсы для выполнения сплайсинга очень маленькие. Кодер требует много ресурсов CPU, виртуальная машина стоит дорого в аренде в облаке, а для работы сплайсера нужно на два порядка меньше ресурсов.
Я предлагаю как раз в развитии современного ТВ посмотреть на технологию сплайсинга для решения довольно широкого круга задач. Сейчас мы, например, работаем с Fashion-TV–это онлайн-канал, которому нужно в России локализовано вещать несколько часов с русским языком контента. Сплайсинг – прекрасная технология для этого дела. У нас есть решения не только для того, чтобы врезать сплайсинг, но и для того, чтобы готовить материалы, если нужно, их транс-кодировать, интегрировать в вашу сеть с вашей системой подготовки расписания и т. д.
Теперь про Softlab в целом. У нас много интерактивного производства, начиная с виртуальных студий, микшеров, спортивных титров и т. д. Все это мы пока в интернет не выносили. Честно говоря, я слабо себе представляю, зачем на стадионе компании делают интернет, но те не менее есть парочка проектов, которые сделаны именно в сторону облачных технологий.
Forward 4 Skipe – это трансляция для общения в студии через скайп. Есть интересное решение, похожее на выступление первого докладчика. Например, пульт компании «Гурамекс», включающий клавиатуру и микшер, работает следующим образом. Режиссер нажимает кнопки на пульте, смотрит картинку в превью, когда видит нужную картинку, жмет кнопку – микшер переключается и поехали. Когда пытаются вынести кодер наружу в период коронавируса или просто для экономии ресурсов, то ставят статические камеры, которые не так дорого стоят, и вещают в сеть. Передача таких сигналов через сеть – это весьма дорогостоящее удовольствие. Мы предлагаем другое решение. У нас на стадион увозится микшер, в задачу которого входит задержать все сигналы на фиксированное время, например, на полсекунды. А незадержанный сигнал мы отдаем в превью, он по вкладкам улетает, кодируется и просматривается режиссером. Мы даем очень небольшую задержку по SRT, чтобы туда и обратно за полсекунды сигнал пришел. Режиссер смотрит на картинку, эта картинка проштампована временем, жмет кнопку, кнопка с этим временем вылетает сюда и здесь ровно через полсекунды командуется микшеру, и микшер исполняет команду. В итоге мы получаем решение, которое по функциональности целиком аналогично локальному производству, режиссеру комфортно, он работает, как привык, программа всегда идеальная. Даже если у вас проблемы в сети, режиссер не заметит какого-то события и не вовремя выйдет в эфир, если уж совсем большая проблема вещания в сети. Если там пропало несколько кадров, то он, может быть, даже этого и не заметит.
Поскольку мы активно занимаемся наукой, работаем со студентами и они нам спокойно жить не дают, мы постоянно держим руку на пульсе. Когда мы работаем с какими-то компаниями, решаем какие-то задачи, всегда стараемся найти нетривиальное решение, нетрадиционное, хитрое, чтобы решить задачу максимально эффективно по деньгам.
Другой проект, который тоже хочу сегодня озвучить, – проект для большой компании ОТР. У них есть 85 точек вещания, куда нужно врезать локальный контент. В рамках этого проекта мы принимаем через наземные каналы связи сигнал SRT, который резервируется, принимается, восстанавливается. Все это работает из единого центра управления. Стандартное решение – это когда на спутник подняли конкретный поиск, опустили, подали в RTRS, из телекомпании подали SDI-сигнал, переключили и полетели. Сейчас запущено решение с наземным каналом, и он оказался дешевле, чем спутниковый, и быстрее. Мы сейчас внутри нашего свитчера делаем задержку сигнала для того, чтобы синхронизоваться с SDI. Наш сервер автоматически синхронизирует сигналы для того, чтобы при переключении не было никаких проблем. Если с утра региональные компании не пришли и не нажали кнопку Play, то мы пошлем команду и пойдет вещание. Мы качаем отсюда плейлисты и полное расписание с титрами, шаблонами, и локально храним. Если почему-то утром региональная телекомпания не доступна в принципе и сигнал SRT не идет, то мы играем с локального хранилища. То есть тут маленький простой свитчер, который выполняет довольно навороченный функционал. Понятно, что это было нужно конкретному заказчику и не нужно никакому другому заказчику, но это явление, которое работает.
Я бы хотел сказать, что делают решения Softlab-NSK для развития современного ТВ. Сейчас появляется много разных возможностей. Облачные технологии, удаленные технологии – это одно из решений. Я считаю, что не совсем корректно, когда мы как разработчики вам как пользователям предлагаем какие-то решения, то есть мы идем впереди вас и предлагаем то, что вам, может быть, вообще не нужно. Я предлагаю идти немного по-другому. У нас богатый опыт работы в ТВ, мы понимаем ваши задачи, мы говорим с вами на одном языке. Когда у вас возникает задача, вам что-то нужно решить, то у нас есть богатый опыт именно по решению нетрадиционных, нетривиальных и интересных задач, мы можем сделать весьма эффективное экономически решение. Я не говорю, что другие этого сделать не могут, но пока опыт показывает, что наши решения гораздо эффективнее, чем у наших конкурентов. На этом у меня все.
Павел Агейкин, главный технолог ФГУП ТТЦ «Останкино»: Игорь, спасибо большое. Я считаю, вы абсолютно правы по поводу роадмапа, дорожной карты, которую вы выставили по взаимоотношению разработчиков и заказчиков. Такой подход должен быть по всему рынку. Спасибо большое организаторам нашего сегодняшнего круглого стола, в том числе нашим партнерам и спонсорам: компании Grass Valley, компании NetInsight, компании Softlab-NSK и компании StreamLabs. Благодаря такому круглому столу мы можем вырабатывать взаимоотношения между разработчиками и заказчиками. Предлагаю перейти к вопросам к Игорю. У меня есть вопрос. Вы сказали, что у вас есть виртуальные титры, виртуальный микшер. Вы планируете их виртуализировать?
Игорь Таранцев: Виртуализировать – это вынести в облако в чистом виде?
Павел Агейкин: Да.
Игорь Таранцев: Честно говоря, я здесь не вижу правильного кейса для этого дела. Стоимость доставки сигнала в облако без потери – это нормально, это хорошо. Ситуации разные. Может быть шоу один раз. Если вы делаете шоу каждое утро, вещаете по три часа в день, то посчитайте аренду, сколько каналов задействовано. Так вот стоимость процессорных ресурсов в облаке сейчас гораздо дешевле, чем стоимость трафика. То есть послать десять потоков стоит дороже, чем арендовать седьмой.
Павел Агейкин: Я вас понял. Второй вопрос, может быть, сейчас сбалансирует ваше высказывание. Вы показали удаленный продакшн. Вся идея удаленного продакшна в том, что вы на удаленный сайт отправляете видеомикшер и осуществляете доставку за счет компрессии сигнала, переконвертирования в IP, тем самым мы компенсируем задержки и прочее. Но виртуальный продакшн не ограничивается лишь выносом удаленного микшера, соответственно, необходимо обеспечить синхронизацию камер. Предположим, она отправляется на микшер. Но микшер тоже надо синхронизировать с остальной аппаратной, которая тоже работает. Помимо этого, нужно обеспечить на камере ретерн, связь, операторов. Там тоже накапливается достаточно много сопутствующих сигналов, которые тоже необходимо обеспечивать какими-то дополнительными каналами. Аппаратное решение тоже по количеству каналов будет не такое маленькое, достаточно сопоставимое именно с виртуализированным решением. Это мое мнение.
Игорь Таранцев: У меня есть четкое мнение по этому поводу. Вопрос в количестве камер. Если у вас две камеры, то вообще не проблема их передать, если у вас четыре камеры – вопрос интересный, когда у вас 16 камер, то это очень тяжело и сложно. Если у вас много камер, то, на мой взгляд, гораздо дешевле использовать титровалку, то есть систему генерации графики унести туда же на стадион. Мы такую задачу делали для индусов. У них шло вещание крикета, он реально стоит дорого. Возить его из города в город очень тяжело и накладно. Им гораздо дешевле поставить те самые камеры, блоки микшеров в разных городах и их никогда не возить. Они стоят там постоянно, стационарно, это стоит не так дорого. Режиссер уже натренирован, он один. Соответственно, как сделать графику? Есть российский опыт с КХЛ. Мы в Москве титруем сигнал, он приходит потом и титруется задержанным. Там нет проблемы с тем, что он титруется не своевременно. Можно сделать графику, которая принимает информацию напрямую с табло. У нас есть система автоматизации, которая связывается с судейскими системами на стадионе, получает всю нужную графику, и показ интерактивной графики (гол, счет и прочее) делается автоматически. Вещать два канала – один без графики, другой с графикой – в облако можно без проблем.
Если взять интернет-вещание биатлона, то у нас там кучка автоматизированных каналов, отсечки вещаются по ПТС канала, зритель выбирает, что он хочет смотреть. На этой отсечке стоит титровальщик, который всех, подходящих сейчас, подтитровывает. То есть система автоматизации для таких спортивных систем оказывается более простая и удобная. А уже наложить графику про состав команд или подписей игроков можно спокойно потом, понятно, что не в постпродакшне, но именно в облаке. Как раз я из стадиона поднял сигнал в облако. У меня там время реакции – секунды. Я могу спокойно увидеть сейчас выступающего и через три секунды подать титр. Там нет необходимости передавать его через 0,1 секунду.
Павел Агейкин: Спасибо большое. Если больше нет вопросов, я предлагаю немного подискутировать. Судя по сегодняшним докладам, практически все разработчики сами начинают додумывать то, что нужно заказчику. Для этого нам надо чаще встречаться в таких форматах и общаться. С моей стороны по продуктам, в принципе, все ясно. Это абсолютно работоспособные интересные продукты, где-то что-то новое появляется, где-то это виртуализация привычных нам сервисов. Но мы, как люди, которые начинают реализовывать и смотреть не только со стороны владельцев сервисов, которые предоставляют их заказчикам, но и с принимающей стороны… как нам распределять эти сервисы? Как нам управлять этими сервисами? Как нам правильно выставить менеджмент этих сервисов для заказчиков и какой уровень доступа возможно правильно предоставлять нашим заказчикам? Под это все необходимо обеспечивать какой-то Work-flow, если речь идет не об одном-двух сервисах, которые мы хотим взять для нашего съемочного процесса, а если мы начинаем обрастать большим количеством сервисов и начинаем целую технологическую единицу, такую как ASB, полностью заменять на виртуализированные сервисы. Начинается симбиоз аппаратного существующего железа, SDI и виртуализированной среды, которая по большей части будет работать на оптической инфраструктуре совместно с ST-2110, предположим. Есть ли у кого-то какие-то пожелания к нашим разработчикам по поводу организации такого Work-flow для нас как заказчиков этих сервисов? Что бы хотелось видеть в ближайшем будущем коллегам именно как принимающей стороне? Как бы вы хотели видеть свои сервисы, агрегацию, управление этих сервисов и их доставку для себя как для конечного пользователя?
Григорий Арзамасцев, пресейл-инженер московского подразделения Grass Valley: Вопрос, скорее, к потребителям этих сервисов, нежели к нам как разработчикам. У меня есть встречный вопрос, может быть, он скорректирует вопрос Павла. Сейчас нами разработана программная платформа, которая предоставляет сервисы для конечных потребителей, которая включает полный комплект управления каналом, в том числе персоналом, финансами, ресурсами, проектами и т. д. Платформа готова к интеграции решений, которые сегодня наши коллеги представляли. Собственно, я очень рад за российских коллег, и они для нас в приоритете по интеграции их решений. Мы сейчас начали переговоры с «Ростелекомом» и рядом других российских облачных платформ для развертывания платформы и подготовки SAAS-решения, которое будет включать в том числе и высокоскоростные каналы для создания виртуальной сети, распределенных дата-центров и объединения в одну сеть для предоставления комплекса услуг телеканалам, чтобы они меньше тратили денег, а занимались творчеством. Вопрос вот в чем. «Ростелеком» не готов такие услуги предоставлять в полном объеме. То есть то, что сегодня поднял Павел, такие комплексы как сопровождение, настройка точных сервисов под каждого клиента, и для этого требуются такие специализированные структуры, допустим, как «Останкино». «Останкино» может на себя такой функционал забрать, стать одним окном, или нет? Для меня это существенно, потому что мы тогда вас включим в этот процесс.
Павел Агейкин: Вопрос достаточно сложный. В первую очередь, технологически, наверно, это было бы справедливо. Мы сейчас помимо девелоперства своих собственных сервисов занимаемся еще и настройкой этого организма предоставления сервисов. На данном этапе мы понимаем, что это не только технологический вопрос, но и вопрос именно человеческого ресурса, и выстраивание совместной технологии менеджмента и технологий этого слияния. Его надо прощупать, грамотно настроить, чтоб была возможность дальнейшего масштабирования. Тогда, наверно, можно будет поговорить о роли телецентра, глобальной в плане предоставления именно услуг и агрегации сервисов.
Григорий Арзамасцев: Да, потому что мы столкнулись с тем, что «Ростелеком» замечательно может предоставить дата-центры, сетевое окружение, каналы связи, обеспечив основу. Мы можем предоставить платформу, которая обеспечивает сами программные сервисы. Коллеги, которые здесь присутствуют, могут спокойно развернуть свои решения в этих же дата-центрах, на вашем центре для того, чтобы обеспечить продакшн, эфиры и полное техническое сопровождение, которое есть. Но задача в том, чтобы телеканалы получали не только эти сервисы как услугу, но и аппаратное обеспечение при необходимости вплоть до рабочих мест, чтобы все перевести из капитальных затрат в операционные затраты. Поэтому просто напрашиваются такие провайдеры. Если, допустим, платформенное решение мы осуществим путем открытия в том же Нижнем Новгороде нашего филиала совместно с государственными структурами Российской Федерации, который будет обеспечивать сопровождение этих сервисов, коллеги по своей части, я думаю, тоже могут закрыть эти вопросы, тем более что для них исчезнут продажи как таковые, они получат поток финансов за счет предоставления этих услуг. Я надеюсь это тоже будет интересно как изменение и корректировка бизнес-модели, которая сейчас есть. Соответственно, телецентрам нужно тоже изменить бизнес-модель телецентрам, добавив такое сопровождение. Предлагаю подумать над этим предложением и обсудить либо в рамках другого круглого стола, либо в каком-то другом формате.
Павел Агейкин: Спасибо, Георгий, отличное предложение. Я думаю, нужно будет обязательно связаться на эту тему и даже, наверно, можно будет встретиться. Я хочу сделать ремарку. Вообще, правильно сказано, что у нас виртуализированные сервисы в первую очередь дают преференцию продюсерам и финансистам, которые уходят от капексов в опексы, которые абсолютно прозрачны, размазываются на каждый месяц, уменьшаются риски, потеря денег и т. д. Это все достигается за счет быстрого масштабирования виртуализированных сервисов, за счет быстрого предоставления, развертывания этих сервисов и их перераспределения. Мы переходим на формат SHAREit-ресурс, то есть мы можем спокойно сегодня для одной программы предоставить 2ME-линейку и простую графику, а завтра 4ME-линейку на микшер и сложную графику плюс еще несколько сервером инжеста и доставку сигнала в другую страну. За счет этого перераспределения мы как раз и достигаем оперативности, масштабируемости и прочее. От этого, я считаю, как раз зависит игра с капексами и опексами. В первую очередь, мне кажется, надо каким-то опытным путем доказать эту масштабируемость и быструю оперативность этих сервисов. На данный момент выстраивание этих сервисов – это достаточно долгий и рутинный процесс, как показал наш опыт, но, слава богу, мы справились с этим, большое спасибо нашим коллегам, нашим интеграторам, тем, кто сегодня присутствует. Мы справились с этой задачей, но следующий вопрос будет стоять именно по оперативному добавлению сервисов для желания заказчиков. Продумать на перспективу, какие сервисы будут востребованы, и сидеть только с таким набором этих сервисов, наверно, было бы не совсем правильно для такого быстро изменяющегося рынка. Наверно, все-таки нужно иметь какую-то гибкую инфраструктуру, которая бы “кушала” эти сервисы.
Григорий Арзамасцев: Именно об этом и идет речь. Создать гибкую структуру, чтоб у клиента была всегда актуальная среда, которая соответствует изменяющимся бизнес-процессам в изменяющейся рыночной ситуации, чтобы они могли легко добавлять сервисы либо удалять ненужные вплоть до служебной связи (видео-конференц-связи, передачи чатов, почты и т. д.). Еще она должна быть изолированной и защищенной.
Павел Агейкин: Абсолютно верно. К сожалению, я на данный момент вижу подводные камни. В этом вопросе предоставления сервисов завязаны не только технологии, но и сам технологический менеджмент, и это прерогатива каждой компании, как она пытается это сделать, какие именно у нее планы на предоставления этого менеджмента. Есть много компаний, у которых технологически сервисы примерно одинаковые, но подход к клиенту разный. Тут тоже много моментов, которые тоже нужно будет обсуждать. Я бы хотел поднять еще одну тему, достаточно серьезную, может быть, она звучит как-то футуристично – это применение искусственного интеллекта и создание облачно-цифровых двойников таких экосистем. Мне кажется, в какой-то мере вопрос, который сейчас подняли: история, связанная с машинным обучением, с нейросетями и, соответственно, с созданием цифрового двойника, – может решить вопросы именно на технологическом уровне общего управления экосистем. Сейчас мы работаем на SDI и потихонечку мигрируем в IP. В IP у нас уже полностью мигрировал транспорт, мы сейчас работаем на 2022-6 и на 2022-7. Мы контролируем IP-потоки, смотрим, вкладываем, выкладываем их – это транспорт. Когда дело касается аппаратного студийного блока, в котором начинают появляться устройства, которые в конечном образе работают уже с IP-интерфейсом (там есть камеры, микшеры, мультивьюверы и тому подобное), то если таких аппаратных студийных блоков несколько и основное преимущество виртуализации заключается в том, что мы можем достаточно быстро и оперативно разворачивать эти сервисы, разворачивать виртуальные машины, добавлять лицензии, гасить эти виртуальные машины, когда нам надо, и перераспределять за счет собственной готовой инфраструктуры между этими объектами, то возникает вопрос, в первую очередь, управления всем этим хаосом. Во-вторых, это реальный контроль именно технического саппорта. Например, сейчас моя служба занимается конкретно технологическими решениями, которые контролируют весь процесс производства телецентра. Если что-то непонятно, специалист ножками идет в аппаратную, смотрит: SDI-интерфейс, кабель, порт такой-то, в другом девайсе порт такой-то, на терминальной панели порт такой-то. Это посмотрел, это посмотрел, это с этим скоммутировал, описал, процесс пошел. Соответственно, если мы будем переходить в инфраструктуру IP, то такие специалисты будут приходить, смотреть на гермозону, в которой будет обильное количество свитчей и жестких коммутаций 40G, 100Gи 10G и ничего руками потрогать нельзя, а контролировать это все, менять архитектуру на горячую все равно придется. Возникает вопрос: как это делать?
Григорий Арзамасцев: Я немного пофантазирую, потому что это задачи, которые стоят, и мы решаем эти задачи не только в области броадкаста, но и вообще государственного управления. Для того, чтобы говорить про модули аналитики, модули автоматизации, нейросети и искусственный интеллект, для того чтобы это заработало, нужно иметь единую платформу. Поэтому мы в своей отрасли рассматриваем в том числе решения, которые могут быть интегрированы. Там, где есть IP, мы накрываем это платформой. Для чего? Потому что, создавая эту распределенную виртуальную сеть, объединяя все вычислительные мощности: компьютеры, сервера, виртуальные машины, – в единую сеть, управляемую одной платформой, мы получаем единое вычислительное пространство и распределенную сеть вычислений. В данном случае, управляя данными потоками, которые в одной платформе генерируются в базы данных, и мы это контролируем, мы можем выстраивать математические модули контроля, автоматизации и самообучения. Мы можем вычислять, если идет сбой в бизнес-процессе, это ошибка бизнес-процесса или человеческий фактор, то есть звено, которое отвечает за какой-то процесс, и мы можем это отслеживать. Но для этого нужно создать единую сеть, иначе получится просто сборная солянка. Какие-то модули будут локально выполнять какой-то конкретный функционал, но общей среды управления не будет. Занимаясь платформой, мы в том числе создаем и среду профессионального мониторинга самой сети: каждый канал мониторит свою подсеть, дата-центр то же самое делает, но создается общая виртуальная сеть.
Максим Веремеев, руководитель проекта StreamLabs: Я бы немного поспорил. Вы говорите, в рамках платформы конфигурации нужно соединять вместе. Вообще это должны быть отдельные сети, потому что мониторинг – это отдельная часть, а конфигурирование – отдельная часть. Понятно, что они должны быть как-то связаны между собой, но это должны быть совершенно раздельные системы, иначе получается, что мы сами работаем и сами себя контролируем. Это совсем нехорошая идея.
Григорий Арзамасцев: Вопрос администрирования и мониторинга – естественно, это другая подсеть. Я имел в виду, что, создавая общую платформу управления и сервисов, создается и система, которая контролирует каждую подсеть. Естественно, это разные сети и разные системы.
Максим Веремеев: Я именно в плане сетей виртуальных систем, потому что там мониторинг и эксплуатация – это одна штука, а обычно эксплуатацией занимаются совсем другие люди, нежели те, которые конфигурируют сеть и вообще систему.
Григорий Арзамасцев: Я имел в виду, что общая платформа, общая сеть дает возможность создания искусственного интеллекта и модулей аналитики, и прогнозов на будущее. По нашему глубокому убеждению, кроме продакшна есть еще и управление организацией, которое включает в себя управление ресурсами, понимание, где находится съемочная техника, кто занят, что в планах в студиях кроме основного продакшна, кому какую зарплату нужно платить, какие финансы, работа с агентами контрагентами и так далее – это вся среда управления. CRM, ERP – это тоже часть управления организацией, и это тоже должно быть, иначе как планировать будущие периоды? Если мы говорим об управлении не продакшном, а об управлении организацией вообще.
Павел Агейкин: Я согласен, что уже само собой подразумевается, что бигдата привязывается ко всем процессам и все управление как раз основывается на работе с бигдата. Может быть, вы видели достаточно интересный кейс, который компания Nvidia сделала совместно с компанией BMW. Месяц назад был Keynote, упор сделали на визуализацию этого решения. В виртуальной среде это, может быть, уже чересчур, но в виде каких-то НОДов, в виде определённых блю-принтов, мне кажется, оно должно существовать. Сейчас очень много компаний, и мы тоже являемся юзерами такой системы, когда мы управляем нашей системой за счет НОДов. Но мне кажется, что все процессы в виде НОДов должны быть привязаны к технологической базе данных бигдата, которая будет, как Георгий правильно сказал, мониторить не только все технологические процессы, но и системно-менеджментские процессы предприятия, которые по большей части бывают блокирующим фактором для проведения какого-то мероприятия. То есть отсутствие оборудование, отсутствие персонала, невозможность организации правильной логистики и так далее.
Григорий Арзамасцев: Должно быть полностью комплексное решение, иначе все это бессмысленно. Это не работает не только в области броадкаста, такая же проблема вообще с цифровизацией как таковой в любой другой области народного хозяйства. Просто мы на передовой, потому что основной поток идет в броадкасте, потому что медиа нагружает сети, и те, кто работают с медиа, понимают, как работать с данными.
Павел Агейкин: Я знаю несколько компаний, до пандемии они уже занимались на уровне агрегации информации, создания баз данных и работы с базами данных с визуальным интерфейсом. Как раз дело касалось таких процессов менеджмента, о которых мы говорим, и взаимосвязки технологии и других нетехнологических процессов. Эти компании предоставляли статистику, что после внедрения их технологий экономия средств предприятия в процентном соотношении не особо большая, но она считается колоссальной: сколько они затратили на эту экосистему и какой профит получило предприятие по итогу после полугода использования этой системы.
Григорий Арзамасцев: Пока пилот не попробуем, не получится. Я думаю, что коллеги уже столкнулись с этим. Мы много обсуждаем и виртуализацию, и облачные технологии, но борьба идет даже не с технологиями, а со стереотипами. Мы привыкли, что лучше купить себе, зачем брать в аренду, хотя все пользуются тем же айфоном и все платят за айклауд, не понимая, что они уже давно на это перешли.
Павел Агейкин: Коллеги, я предлагаю уже заканчивать. Я считаю, что сегодняшний наш круглый стол поднял достаточно интересные темы. Хотелось бы эти темы в дальнейшем в личных встречах обсудить вместе с разработчиками и конечными заказчиками. Я считаю нам надо плотнее работать совместно, как технарям и творцам-режиссерам. Большое спасибо, коллеги, большое спасибо нашим партнерам-спонсорам. Я предлагаю при возможности встречаться и в онлайне, и в офлайне. Я обязательно поговорю с организатором нашей встречи Эдуардом. Большое ему спасибо за предоставленную возможность всем выступить, рассказать, обменяться опытом. Становится понятно, что у всех есть какие-то стратегические вопросы и их надо решать совестными встречами. Очень приятно пообщаться с коллегами, тем более все заинтересованы в развитии нашей доблестной телевизионной индустрии в России.
https://tkt1957.com/ru/soft-lab-for-modern-tv/
