В этой статье не будет описываться, как можно быстро настроить icecast в различных Linux системах для разных задач. Нет. В этой статье хотелось бы осветить маленькую историю одного небольшого проекта по выводу эфирной радиостанции в глобальную сеть. С какими проблемами пришлось столкнуться и как мы их решали.
Итак. Маленькая предистория — есть радио-холдинг из нескольких эфирных музыкальных радиостанций с головным офисом в столице нашей родины Москве. Сами радиостанции вещают себе в FM диапазоне столицы, имеют свою аудиторию и вполне себе счастливы своим слушателем. Но вот незадача — на дворе 2012 год, а направление интернет вещания развивается не шатко не валко. Дальше будет много слов и маленьких историй в рамках одной основной, если заинтересовало, добро пожаловать под кат.
Постановка задачи давно назрела, как для генерального директора всего холдинга, так и для многих программных директоров самих радиостанций. Но была небольшая проблема — холдинг ни в каком виде не видел способов монетизации этого сервиса, а раз нет монетизации, нет и никаких бюджетов для того, что бы построить безумное решение. Почему задача назрела — существовавший сервис на тот момент (весна 2012 года) не удовлетворял никаким требованиям надёжности, качества и удобства. Как раз к весне 2012 года в холдинге произвели смену руководства технического департамента и IT службы. Мне судьба и мои коллеги «подарили» возможность руководить IT службой этой компании.
Итак.
Вещание в Интернет в компании обеспечивал небольшой комплекс серверов:
Далее сигнал в формате MP3 отправлялся не совсем прямо — для каждой из радиостанций, а их было 5, формировался поток в 256 kbit/s и публиковался на локальном icecast сервера энкодривания, после чего, основной сервер раздачи через NAT самостоятельно забирал эти потоки и транскодировал их в дополнительные (64, 96, 128, 320). Это по серверной части, по клиентской части всё было ещё хуже — никакого flash/html клиента не существовало в принципе, был написан небольшой FAQ выложенный на сайте радиостанций, как подключаться к потокам и на этом всё «облизывание» клиентов заканчивалось. Нужно добавить, что работала эта конструкция ни шатко не валко, практически ежедневно мы наблюдали «срывы» потоков основной радиостанции холдинга при достижении 3-3,5 тысяч слушателей, как правило «срывы» возникали в течении дня по несколько раз. Причины сбоев были различными, то transcoder встанет, то почему то сервер решит, что он не видит удалённую точку монтирования, то ещё что-то. Короче заняться было явно чем.
На мой логичный вопрос адресованный инженерам, которые осуществляли поддержку всего этого хозяйства — а что ж так «не логично» то всё выстроено? Последовал обычный ответ — ну так исторически сложилось. Нужно отметить, что «допиливанием» icecast занимался внешний аутсорсовый сотрудник из Новосибирска. Отличный парень, знает FreeBSD вдоль и поперёк, пишет на C or C++, но понимания в мультимедиа у него не такое большое, а как строить большие вещательные платформы в сети, да ещё и без единой точки сбоя он точно не знал. Да и не надо оно ему, ему деньги не за это платят. Плюс разница во времени, короче точка перелома была пройдена в тот момент, когда в наш кабинет с начальником технического департамента вошёл Генеральный и сказал — ребят, что-то у меня не играет с iPhone наша радиостанция в сети, давайте, что-нибудь уже сделайте. Отвечать ему было нечем — ну реально же не играет, потому, что опять, что-то там отвалилось и т.д.
Любой администратор скажет вам при виде icecast, что тут думать, тут «запиливать» надо. Но это не наш случай. Нам так уже «исторически» запилили, что нужно эти конюшни привести к какому-то нормальному уровню. Основные проблемы существовавшие на тот момент:
Короче копать куда есть, теперь как это всё привести к какому-то разумному виду.
Решение требовалось системное – что приходит на ум любому управленцу из IT когда он сталкивается с не совсем профильной задачей – правильно, а давайте отдадим на аутсорс за деньги. Некоторые, не особенно чистые на руку управленцы ещё и свой интерес в стоимость аутсорса успевают засунуть, но мы не об этом. Мы с моим начальником рассматривали сразу оба решения, т.е. или мы делаем это сами и как, или мы отдаём это на аутсорс, тогда возникает вопрос – а сколько это будет стоить? Так вот, вопрос аутсорса отпал сам собой, как только мы посчитали сколько будет стоить отдать вещание в сети третьей стороне и забыть об этой задаче навсегда. Компании которые предоставляют подобные услуги публично представляют такие цены на свои услуги, что крупные игроки радио рынка к ним не придут никогда, это факт. Доходность даже крупных радиостанций входящих в десятку в Москве конечно позволит им отдаться на этих условиях, но всё равно будет значимой статьёй расходов и это при отсутствии нормальной монетизации. Есть сервисы предлагающие сразу и вещание и монетизацию в виде размещения различных видов рекламы, но и у них цены на услуги достаточно высоки, а вопрос возврата инвестиций стоит очень остро, поэтому было сказано – НЕТ. На это мы пойти не можем, тем более, что нанимали нас с целью уменьшения операционных расходов максимально доступными способами, а тут всё будет с точностью наоборот. Короче, отказались мы от этой идеи.
Строим сами – как?
Почему так?
Попытки ставить какие-либо балансировки нагрузки перед icecast несущими большое количество потоков, на мой взгляд абсолютно бессмысленны. Если у вашего сервера есть гигабитный канал связи, при сравнительно слабеньком процессоре и небольшом количестве оперативной памяти Icecast его забьёт полностью, только подтаскивайте клиентов. Так что вы будете балансировать? Несколько гигабитных потоков, а что делать с единой точкой отказа? Какой выход – балансируем только на сетевом уровне средствами коммутаторов, если у вас есть port channel. При трёх гигабитных каналах вы сможете рассчитывать на 2,7 гигабита в секунду, при четырёх каналах на все 4, ну и так далее. Распределение нагрузки между серверами, дабы не перегружать точки монтирования может осуществлять сам icecast, его KH версия. На практике оказалось, что icecast не удерживает более 3200-3500 на одной точке монтирования 128 kbit/s MP3 – причина, насколько мы понял, в высокой нагрузке на ядра процессоров. Дело в том, что icecast по умолчанию обрабатывает одну точку монтирования на одном ядре. В случае если точек монтирования больше чем количество ядер в системе он начинает их разделять по ядрам, но опять же, не равномерно, а по точкам монтирования на одно ядро. Если процессоры у вас не очень скоростные, то больше 3000 одновременных на одну точку монтирования нагружать не стоит, можно воспользоваться хитростью – перебрасывать по достижению этой величины на скрытую точку монтирования на этом же сервере, но с другим именем. В обычном icecast эта «извращённая» логика отлично работает. KH версия требует, что-бы у другой точки монтирования был и другой источник.
Второе, я считаю, что создавать монструозный сервер для задач вещания означает абсолютно не учитывая возможности горизонтального роста платформы в целом, что не совсем верно, в дальнейшем всё равно аукнется и ещё как. Поэтому был выбран вариант именно с горизонтальным масштабированием.
Почему хотели кодировать проприетарным софтом – не хотели городить огород в виде отдельных компонентов FM обработки и энкодинга, ну и внедрение AXIA LiveWire было очень «вкусным» дополнением к решению этой задачи. Плюсом было ещё и то, что после тестирования нескольких энкодеров стало понятно, что AXIA отличается от бесплатных именно качеством сжатия, т.е. по сравнению с lame и т.д. она лучше звучит. Долго объяснять «почему?» не хотелось бы, лучше потом или в комментариях.
С чем столкнулись сразу – стало понятно, что нужно как-то измерять количество слушателей, причём и одновременных и накопленных за сутки, день, неделю и т.д. В процессе выяснения чётко стало понятно, что оставлять такое разнообразие потоков и многие из них крайне «толстые» (320 например), мы просто не можем. Вот это и было первым серьёзным камнем преткновения, причём убедить программных директоров и остальных топов оказалось сильно проще чем рядовых инженеров отвечавших за реализацию этой задачи в прошлом. «Аудиофильское» состояние души отказывалось понимать объективную реальность. Не мытьём так катаньем нам удалось это сделать, крови это стоило большой и душевных ран оставило немало. Но слава Богу никого не уволили и не испортили карму с подчинёнными. Начали приводить всё в порядок. Пришли к следующим стандартным потокам для каждой из 5 радиостанций – 128 & 64 kbit/s MP3, 56 & 48 kbit/s AACv2+.
Долгое время не трогали основной раздающий сервер, приводили в порядок внутреннюю инфраструктуру. Наконец в один из дней весной 2013 мы с моим подчинённым утром метнулись на M IX и устроили обрушение всего и вся с дальнейшим поднятием. Получилось неплохо. Сразу выяснились плюсы внедрения Linux в связке с icecast-kh – он реально начал слабее грузить процессоры при тех же нагрузках. Разница было до 20%. Это много. Плюс, сразу разнесли нагрузку на 4 сервера и в течении дня начали подключать их к единой DNS записи.
Из-за затруднений у отдела разработки с получением нормального плеера мы решили дополнить балансировку нагрузки ещё и механизмом Round&Robin в DNS. Он конечно не самый надёжный, но пока не об этом.
В ноябре месяце 2013 года моя трудовая деятельность в этой славной компании закончилась. Чем могу гордиться и что осталось не сделанным в рамках этой задачи.
Общий поток фермы из 4 серверов превысил 2,5 Gbit/s в пике днём и продолжал медленно повышаться от месяца к месяцу. До всех телодвижений, которые были произведены он не превышал 1,2-1,3. По факту компания обслуживала не всех кто хотел получить сервис, а только тех кто успевал первым.
По предварительной статистике мы смогли «пробить» показатель полмиллиона уников за неделю, эти цифры уже можно как-то продавать. Был обкатан механизм размещения intro файлов, которые проигрывают рекламный ролик каждому подключившемуся пользователю, пока без отслеживания кому уже проиграли, а кому нет, но это был первый опыт размещения.
Нагрузка начала более равномерно разноситься по серверам, и это сказалось на качестве сервиса. Перебои возникали только в результате реальных сбоев сети и других проблем, но уже не были вызваны некорректной настройкой самих сервисов или другими проблемами.
За счёт появления качественных потоков с низким битрейтом началось смещение количества клиентов с мобильных платформ в сторону их увеличения. Это радует меня как инженера – ведь это по сути будущая модель доставки в целом для радиостанций.
Внутренние icecast были отстрелены и создан единый внутренний icecast для раздачи по всем серверам дистрибуции + он же использовался некоторыми региональнами партнёрами, как резервный источник сигнала. Это не раз и не два нас спасало, да и региональщики сказали спасибо за надёжный сервис резерва.
Чем гордиться не могу.
Остались не реализованными планы по внедрению полноценного перехода на Omnia AX/E – полностью отказали в финансировании. Вынуждены были в итоге городить огород с аппаратными FM процессорами найденными на складе, древними как ммм, ну вы поняли. Осталась проблема мониторинга – отказ в финансировании, решили внедрять PRTG, на Nagios & more просто не было человеческих ресурсов, эта задача потянула за собой невозможность оперативной реакции на выход из строя любого из серверов и недопущению у большого количества клинетов многих минут тишины. Не получилось внедрить нормальную систему аналитики log файлов раздающих серверов – под нормальной понимается система способная посчитать кроме обычных параметров ещё и чисто медийные данные, аля AQH и другие. Единственная система из известных мне это Casterstat, все остальные заточены под обработку в первую очередь Web серверов и не совсем подходят. Так и не были до конца разработаны полноценные плеера для большинства мобильных платформ, смогли закончить только под iOS, но хоть так, тем более, что задача была не у нас.
Я не знаю как оценить в степени завершённости, но внедрить полноценную систему баллансировки на основе pls механизма плееров у нас не получилось в первую очередь из-за проблем со стороны отдела отвечавшего за разработку плеера. Но это не важно, винить нам их не в чем да и не за что.
Нужно понимать, что это далеко не единственная задача, которую решал технический департамент и IT служба за время моей работы в этой компании, поэтому не стоит удивляться такой длительности. Это я типа оправдываюсь.
Если кого-то заинтересовала тема IT в мультимедиа сфере, то могу продолжить рассказы на какие-то другие темы, благо опыт есть.
Итак. Маленькая предистория — есть радио-холдинг из нескольких эфирных музыкальных радиостанций с головным офисом в столице нашей родины Москве. Сами радиостанции вещают себе в FM диапазоне столицы, имеют свою аудиторию и вполне себе счастливы своим слушателем. Но вот незадача — на дворе 2012 год, а направление интернет вещания развивается не шатко не валко. Дальше будет много слов и маленьких историй в рамках одной основной, если заинтересовало, добро пожаловать под кат.
Постановка задачи давно назрела, как для генерального директора всего холдинга, так и для многих программных директоров самих радиостанций. Но была небольшая проблема — холдинг ни в каком виде не видел способов монетизации этого сервиса, а раз нет монетизации, нет и никаких бюджетов для того, что бы построить безумное решение. Почему задача назрела — существовавший сервис на тот момент (весна 2012 года) не удовлетворял никаким требованиям надёжности, качества и удобства. Как раз к весне 2012 года в холдинге произвели смену руководства технического департамента и IT службы. Мне судьба и мои коллеги «подарили» возможность руководить IT службой этой компании.
Итак.
Предварительная ситуация
Вещание в Интернет в компании обеспечивал небольшой комплекс серверов:
- 1 раздающий сервер (FreeBSD, допиленный icecast, thanscoder, 3 Gbit ethernet, M IX Бутлерова)
- 2 сервера энкодирования, установленных в студийном комплексе (он же головной офис) в Москве и кодирующих аналог/AES источники в MP3 потоки на основной раздающий сервер (Windows XP, icecast, edcast)
Далее сигнал в формате MP3 отправлялся не совсем прямо — для каждой из радиостанций, а их было 5, формировался поток в 256 kbit/s и публиковался на локальном icecast сервера энкодривания, после чего, основной сервер раздачи через NAT самостоятельно забирал эти потоки и транскодировал их в дополнительные (64, 96, 128, 320). Это по серверной части, по клиентской части всё было ещё хуже — никакого flash/html клиента не существовало в принципе, был написан небольшой FAQ выложенный на сайте радиостанций, как подключаться к потокам и на этом всё «облизывание» клиентов заканчивалось. Нужно добавить, что работала эта конструкция ни шатко не валко, практически ежедневно мы наблюдали «срывы» потоков основной радиостанции холдинга при достижении 3-3,5 тысяч слушателей, как правило «срывы» возникали в течении дня по несколько раз. Причины сбоев были различными, то transcoder встанет, то почему то сервер решит, что он не видит удалённую точку монтирования, то ещё что-то. Короче заняться было явно чем.
На мой логичный вопрос адресованный инженерам, которые осуществляли поддержку всего этого хозяйства — а что ж так «не логично» то всё выстроено? Последовал обычный ответ — ну так исторически сложилось. Нужно отметить, что «допиливанием» icecast занимался внешний аутсорсовый сотрудник из Новосибирска. Отличный парень, знает FreeBSD вдоль и поперёк, пишет на C or C++, но понимания в мультимедиа у него не такое большое, а как строить большие вещательные платформы в сети, да ещё и без единой точки сбоя он точно не знал. Да и не надо оно ему, ему деньги не за это платят. Плюс разница во времени, короче точка перелома была пройдена в тот момент, когда в наш кабинет с начальником технического департамента вошёл Генеральный и сказал — ребят, что-то у меня не играет с iPhone наша радиостанция в сети, давайте, что-нибудь уже сделайте. Отвечать ему было нечем — ну реально же не играет, потому, что опять, что-то там отвалилось и т.д.
Сначало нужно подумать
Любой администратор скажет вам при виде icecast, что тут думать, тут «запиливать» надо. Но это не наш случай. Нам так уже «исторически» запилили, что нужно эти конюшни привести к какому-то нормальному уровню. Основные проблемы существовавшие на тот момент:
- низкий уровень резервирования — по сути не резервирован был ни один компонент системы
- отсутствие системы хоть какой-то балансировки нагрузки – все потоки на один сервер, все клиенты на один сервер. А там посмотрим, удержит он их или нет.
- большое количество недиагносцируемых сбоев
- проведение диагностики затруднено в силу недостаточной документированности кастомизаций icecast and FreeBSD core + устаревший продукт (FreeBSD какой-то там лохматой версии) + проблемы с этим продуктом в виде не совсем «верно» реализованных частей стэка TCP/IP, которые вылезают, как раз при высоких нагрузках с большим количеством сессий
- полное отсутствие FM обработки сигнала — это считается очень непрофессиональным в радийной среде, если нужно пояснение в личку или комментарии
- отсутствие flash/html клинета для проигрывания прямо на сайте радиостанций
- отсутствие системы мониторинга
Короче копать куда есть, теперь как это всё привести к какому-то разумному виду.
Хватит думать – пора «запиливать»
Решение требовалось системное – что приходит на ум любому управленцу из IT когда он сталкивается с не совсем профильной задачей – правильно, а давайте отдадим на аутсорс за деньги. Некоторые, не особенно чистые на руку управленцы ещё и свой интерес в стоимость аутсорса успевают засунуть, но мы не об этом. Мы с моим начальником рассматривали сразу оба решения, т.е. или мы делаем это сами и как, или мы отдаём это на аутсорс, тогда возникает вопрос – а сколько это будет стоить? Так вот, вопрос аутсорса отпал сам собой, как только мы посчитали сколько будет стоить отдать вещание в сети третьей стороне и забыть об этой задаче навсегда. Компании которые предоставляют подобные услуги публично представляют такие цены на свои услуги, что крупные игроки радио рынка к ним не придут никогда, это факт. Доходность даже крупных радиостанций входящих в десятку в Москве конечно позволит им отдаться на этих условиях, но всё равно будет значимой статьёй расходов и это при отсутствии нормальной монетизации. Есть сервисы предлагающие сразу и вещание и монетизацию в виде размещения различных видов рекламы, но и у них цены на услуги достаточно высоки, а вопрос возврата инвестиций стоит очень остро, поэтому было сказано – НЕТ. На это мы пойти не можем, тем более, что нанимали нас с целью уменьшения операционных расходов максимально доступными способами, а тут всё будет с точностью наоборот. Короче, отказались мы от этой идеи.
Строим сами – как?
- Резервирование – увеличиваем количество раздающих серверов до 4 с встраиванием механизма балансировки на уровень icecast-kh. Выносим энкодирующий софт на платформу виртуализации. Вынимаем icecast первого уровня раздачи с энкодеров и ставим его на отдельную виртуальную машину. Резервируем каналы интернет в центральный офис
- Балансировка – балансируем нагрузку в зависимости от наполнения точек монтирования средствами icecast-kh
- В качестве энкодирующего софта предложено использовать Omnia AX/E, он позволяет закрыть, как потребности в энкодировании, так и FM обработке звука
- полный отказ от транскодирования на основных серверах раздачи, сервер должен получать уже полностью готовый поток и только его раздавать
- Полный отказ от FreeBSD на серверах и переход на какой-то из Linux (в итоге выбрали Ubuntu 12.04 LTS)
- написание силами соседнего департамента полноценного flash/html клиента для проигрывания на сайте, разработка клиентов для мобильных платформ iOS+Andriod
- предоставление клиентам не только MP3, но и AACv2+ потоков для прослушивания в сетях мобильных операторов
- установка системы активного мониторинга с возможностью изменения файлов по событию
Почему так?
Попытки ставить какие-либо балансировки нагрузки перед icecast несущими большое количество потоков, на мой взгляд абсолютно бессмысленны. Если у вашего сервера есть гигабитный канал связи, при сравнительно слабеньком процессоре и небольшом количестве оперативной памяти Icecast его забьёт полностью, только подтаскивайте клиентов. Так что вы будете балансировать? Несколько гигабитных потоков, а что делать с единой точкой отказа? Какой выход – балансируем только на сетевом уровне средствами коммутаторов, если у вас есть port channel. При трёх гигабитных каналах вы сможете рассчитывать на 2,7 гигабита в секунду, при четырёх каналах на все 4, ну и так далее. Распределение нагрузки между серверами, дабы не перегружать точки монтирования может осуществлять сам icecast, его KH версия. На практике оказалось, что icecast не удерживает более 3200-3500 на одной точке монтирования 128 kbit/s MP3 – причина, насколько мы понял, в высокой нагрузке на ядра процессоров. Дело в том, что icecast по умолчанию обрабатывает одну точку монтирования на одном ядре. В случае если точек монтирования больше чем количество ядер в системе он начинает их разделять по ядрам, но опять же, не равномерно, а по точкам монтирования на одно ядро. Если процессоры у вас не очень скоростные, то больше 3000 одновременных на одну точку монтирования нагружать не стоит, можно воспользоваться хитростью – перебрасывать по достижению этой величины на скрытую точку монтирования на этом же сервере, но с другим именем. В обычном icecast эта «извращённая» логика отлично работает. KH версия требует, что-бы у другой точки монтирования был и другой источник.
Второе, я считаю, что создавать монструозный сервер для задач вещания означает абсолютно не учитывая возможности горизонтального роста платформы в целом, что не совсем верно, в дальнейшем всё равно аукнется и ещё как. Поэтому был выбран вариант именно с горизонтальным масштабированием.
Почему хотели кодировать проприетарным софтом – не хотели городить огород в виде отдельных компонентов FM обработки и энкодинга, ну и внедрение AXIA LiveWire было очень «вкусным» дополнением к решению этой задачи. Плюсом было ещё и то, что после тестирования нескольких энкодеров стало понятно, что AXIA отличается от бесплатных именно качеством сжатия, т.е. по сравнению с lame и т.д. она лучше звучит. Долго объяснять «почему?» не хотелось бы, лучше потом или в комментариях.
Начинаем «мотылять»
С чем столкнулись сразу – стало понятно, что нужно как-то измерять количество слушателей, причём и одновременных и накопленных за сутки, день, неделю и т.д. В процессе выяснения чётко стало понятно, что оставлять такое разнообразие потоков и многие из них крайне «толстые» (320 например), мы просто не можем. Вот это и было первым серьёзным камнем преткновения, причём убедить программных директоров и остальных топов оказалось сильно проще чем рядовых инженеров отвечавших за реализацию этой задачи в прошлом. «Аудиофильское» состояние души отказывалось понимать объективную реальность. Не мытьём так катаньем нам удалось это сделать, крови это стоило большой и душевных ран оставило немало. Но слава Богу никого не уволили и не испортили карму с подчинёнными. Начали приводить всё в порядок. Пришли к следующим стандартным потокам для каждой из 5 радиостанций – 128 & 64 kbit/s MP3, 56 & 48 kbit/s AACv2+.
Долгое время не трогали основной раздающий сервер, приводили в порядок внутреннюю инфраструктуру. Наконец в один из дней весной 2013 мы с моим подчинённым утром метнулись на M IX и устроили обрушение всего и вся с дальнейшим поднятием. Получилось неплохо. Сразу выяснились плюсы внедрения Linux в связке с icecast-kh – он реально начал слабее грузить процессоры при тех же нагрузках. Разница было до 20%. Это много. Плюс, сразу разнесли нагрузку на 4 сервера и в течении дня начали подключать их к единой DNS записи.
Из-за затруднений у отдела разработки с получением нормального плеера мы решили дополнить балансировку нагрузки ещё и механизмом Round&Robin в DNS. Он конечно не самый надёжный, но пока не об этом.
Я ухожу оставляя горы окурков… Итоги
В ноябре месяце 2013 года моя трудовая деятельность в этой славной компании закончилась. Чем могу гордиться и что осталось не сделанным в рамках этой задачи.
Общий поток фермы из 4 серверов превысил 2,5 Gbit/s в пике днём и продолжал медленно повышаться от месяца к месяцу. До всех телодвижений, которые были произведены он не превышал 1,2-1,3. По факту компания обслуживала не всех кто хотел получить сервис, а только тех кто успевал первым.
По предварительной статистике мы смогли «пробить» показатель полмиллиона уников за неделю, эти цифры уже можно как-то продавать. Был обкатан механизм размещения intro файлов, которые проигрывают рекламный ролик каждому подключившемуся пользователю, пока без отслеживания кому уже проиграли, а кому нет, но это был первый опыт размещения.
Нагрузка начала более равномерно разноситься по серверам, и это сказалось на качестве сервиса. Перебои возникали только в результате реальных сбоев сети и других проблем, но уже не были вызваны некорректной настройкой самих сервисов или другими проблемами.
За счёт появления качественных потоков с низким битрейтом началось смещение количества клиентов с мобильных платформ в сторону их увеличения. Это радует меня как инженера – ведь это по сути будущая модель доставки в целом для радиостанций.
Внутренние icecast были отстрелены и создан единый внутренний icecast для раздачи по всем серверам дистрибуции + он же использовался некоторыми региональнами партнёрами, как резервный источник сигнала. Это не раз и не два нас спасало, да и региональщики сказали спасибо за надёжный сервис резерва.
Чем гордиться не могу.
Остались не реализованными планы по внедрению полноценного перехода на Omnia AX/E – полностью отказали в финансировании. Вынуждены были в итоге городить огород с аппаратными FM процессорами найденными на складе, древними как ммм, ну вы поняли. Осталась проблема мониторинга – отказ в финансировании, решили внедрять PRTG, на Nagios & more просто не было человеческих ресурсов, эта задача потянула за собой невозможность оперативной реакции на выход из строя любого из серверов и недопущению у большого количества клинетов многих минут тишины. Не получилось внедрить нормальную систему аналитики log файлов раздающих серверов – под нормальной понимается система способная посчитать кроме обычных параметров ещё и чисто медийные данные, аля AQH и другие. Единственная система из известных мне это Casterstat, все остальные заточены под обработку в первую очередь Web серверов и не совсем подходят. Так и не были до конца разработаны полноценные плеера для большинства мобильных платформ, смогли закончить только под iOS, но хоть так, тем более, что задача была не у нас.
Я не знаю как оценить в степени завершённости, но внедрить полноценную систему баллансировки на основе pls механизма плееров у нас не получилось в первую очередь из-за проблем со стороны отдела отвечавшего за разработку плеера. Но это не важно, винить нам их не в чем да и не за что.
Нужно понимать, что это далеко не единственная задача, которую решал технический департамент и IT служба за время моей работы в этой компании, поэтому не стоит удивляться такой длительности. Это я типа оправдываюсь.
Если кого-то заинтересовала тема IT в мультимедиа сфере, то могу продолжить рассказы на какие-то другие темы, благо опыт есть.
