Медіасервіс MEGOGO працював з перебоями в ніч на 26 вересня. У деяких користувачів сервісу при перегляді тріумфального бою Олександра Усика проти Джошуа це викликало хвилю обурення в Facebook.
Медіасервіс MEGOGO працював з перебоями в ніч на 26 вересня. У деяких користувачів сервісу при перегляді тріумфального бою Олександра Усика проти Джошуа це викликало хвилю обурення в Facebook.
У MEGOGO пояснили, що на одному з дата-центрів стався збій, через що у частини глядачів виникли складнощі з приєднанням до трансляції.
Редакція dev.ua попросила Бориса Данилова, CEO adaptech.biz, і ексдиректора oll.tv (конкурент MEGOGO) висловити свою думку щодо того, чому міг статися збій важливої відеотрансляції.
Далі — текст Бориса:
Щодо ситуації з проблемами при трансляції бою Усика в ніч з 25 на 26 вересня 2021 року на платформі Мегого, маю оцінювальну думку. При виході на новий рівень споживання немає інструменту, який зможе точно спрогнозувати поведінку всієї системи, але потрібно постаратися, щоб не допустити або мінімізувати втрати
А тепер здалеку…
Система надання ОТТ послуг (Over-the-Top, послуги в інтернеті — ред.) надзвичайно складна, тим більше в Україні, де ще немає такого рівня спеціалізації вендорів, а значить і стандартизації роботи різних ланок технологічного ланцюжка.
ОТТ у нас це — страшна комбінація самописних і куплених програмних рішень, поєднання різних платформ, інтеграцій з зовнішніми платформами, хмарні рішення, канали передачі даних, транскодинг, зберігання, криптування, коннект з рекламними серверами, платіжним процесингом тощо.
Все це працює в реальному режимі часу при одночасному відвантаженню відео, найбільш відповідному для цього інтернет-з'єднання і пристрою, відповідно до запитів користувача, виходячи з його тарифу, контексту, регіону.
Як відомо, будь-яке натискання кнопки на пульті «Смарт ТВ», дія на сайті або в додатку, оплата або замовлення, це — новий запит до системи, до баз даних.
Призначене для користувача навантаження в період «звичайного» перегляду ТБ в корені відрізняється від «спортивного» навантаження.
Якщо взяти глядачів звичайного ТБ, ми побачимо, що реєстрації, авторизації, навігація по меню, оплати «звичайних» глядачів, розтягнуті в часі. Дещо відрізняється навантаження у зв’язку з «платіжними днями», в залежності від тих чи інших ТБ-шоу, але незначно (видно навіть по ТБ- рейтингах). «Звичайне» навантаження повторюване, легко передбачуване.
Можна тримати надлишкову ємність для піків навантаження, але не істотну.
Не так поводяться глядачі спортивної події, які протягом декількох хвилин реагують зовсім інакше, ніж «звичайні» глядачі. Що відбувається, якщо у них виникає затримка? Правильно — користувачі починають «клацати» ще інтенсивніше.
Порівняти ці два типи навантаження — все одно, що порівнювати море до і під час удару цунамі, коли зайвий метр хвилі вже не має ніякого значення…
Можна порівняти з коллцентром — до і під час аварії, коли навантаження на лінії зростає удесятеро й кількість дзвінків, включаючи повторні, вже не має ніякого значення, коли потрібні інші сценарії: превентивні оповіщення, «заглушки», коллбекі тощо.
Технарі скажуть і матимуть рацію, що для цього є системи й процеси тестування навантажень, і ті, хто пише код для тестів, і що потрібно було спрогнозувати надлишкове навантаження й поставити додаткові сервери.
Ось тільки якщо ти ледь виходиш на новий рівень, з цим є проблема:
1. Обсяг робіт з підготовки навантажувального тестування не тільки вкрай великий, він НЕ дозволяє емулювати повне навантаження від комерційних користувачів в реальних умовах на всі системи, з варіаціями проблем. Це все одно, що повторити бій Усика і ті ж призначені для користувача умови, які об'єктивно створилися.
2. Усунення вже виявлених проблем не означає автоматичного їх вирішення — як пробка на дорозі, проблема часто переїжджає на наступне вузьке місце. Багато хто пам’ятає «кейси» OLL.TV, коли ані нові введені ємності, ані відновні процеси не допомагали, поки достатня кількість падінь не дозволила пройти всі точки відмови.
3. В Україні взагалі-то немає достатньої місткості підготовлених ресурсів, які під спортивне навантаження можна оперативно додати в роботу. Зайве говорити, що утримувати надлишкову місткість, яка у рази перевищує «звичайну», — нереально.
4. Деякі проблеми неможливо усунути, не змінюючи код цілком. Фактично, режим роботи у звичайному і спортивному мовленні так сильно відрізняються, що впору говорити про необхідність тримати дві різні системи, з різною архітектурою, процесами підготовки, реагування та… продажів.
Щось можна зробити?
Зазвичай максимально використовують той досвід, який дало «цунамі», не тільки для резервування ресурсів, але і для зміни підходів в тестуванні навантаження та його оптимізації. Швидше за все, ми більше не побачимо аналогічної проблеми.
Утім, добре б також мати домовленості з оперативного посилення ресурсами партнерських стрімінгових платформ, включно з конкуруючими, а іноді — безкоштовні і умовно безкоштовні (якщо ви розумієте, про що я…), аби усе ж таки задовольнити попит.
Адже трансляцію з події не можна відкласти, клієнти цього не прощають …
Нарешті, процедура по роботі з клієнтами для інцидентів може працювати й на випередження, й на вибачення — в Україні є кейси, коли правильна робота з фейлом компанії спрацювала краще будь-якої реклами.
MEGOGO — правильна компанія, яка знає, що робить, і все зробить правильно.
Побажаємо їм удачі, адже вони творять історію!
