Для английской мультиязычной версии сайта «Игр будущего» мы сделали собственную систему управления: во время игр с сайтом работают сотни редакторов из разных стран, и интерфейс не даёт им испортить вёрстку и держит единый стиль. Сайт выдерживал около 140 000 живых посетителей в день — это 1,6 человека в секунду в среднем за сутки и, по нашей оценке, 10–12 новых посетителей в секунду в первый час после открытия.
Объясняем на пальцахСотни редакторов — как сотни продавцов за одной кассой. Дай каждому менять ценники как хочет — к вечеру магазин не узнать. Наша админка — касса, где товар пробить можно, а прайс переписать нельзя.
Как конструктор с готовыми деталями: собрать можно любую новость, но нельзя распилить деталь или покрасить её в свой цвет. Поэтому у всех редакторов получается в одном стиле.
Как общая тетрадь рецептов, куда пишет родня из разных городов: графы одинаковые — продукты, шаги, время. Каждый пишет своё, а тетрадь остаётся аккуратной.
Обычный корпоративный сайт живёт как дача зимой: раз в месяц кто-то заезжает поменять баннер. Сайт международного турнира живёт как вокзал перед праздниками. Сотни людей одновременно что-то публикуют, сотни тысяч одновременно что-то читают, и все — на разных языках. А времени чинить нет: финал не перенесут, пока вы ищете, кто удалил закрывающий тег.
Ниже — разбор того, как мы подходили к такой задаче на английской версии сайта «Игр будущего»: зачем понадобилась своя система управления, как устроен редакторский интерфейс для международной команды и сколько на самом деле «весят» 140 000 посетителей в день, если пересчитать их в секунды.
Что за проект и что в этой статье факт, а что расчёт
«Игры будущего» — международный турнир по фиджитал-спорту: это формат, где киберспорт и классический спорт объединены в одну дисциплину. Например, в фиджитал-футболе команды сначала играют в FIFA, а потом выходят на поле. Подробности проекта — в кейсе сайта «Игр будущего».
Чтобы не смешивать опыт и предположения, сразу разделим.
| Что | Статус |
|---|---|
| Для этой версии сайта мы сделали собственную систему управления (CMS) | факт проекта |
| Версий системы было много; сейчас она протестирована и работает | факт проекта |
| Во время игр с сайтом работают сотни редакторов из разных стран | факт проекта |
| Эта версия — английская и мультиязычная; сайт может работать сразу на нескольких языках | факт проекта |
| Сайт выдерживал около 140 000 живых посетителей в день | факт проекта |
| Основная масса пришла на открытие в 10:00, дальше — в течение рабочего дня | факт проекта |
| В системе много параметров безопасности | факт проекта |
| Нагрузка в секунду | наша оценка из дневной посещаемости, а не замер |
| Доля аудитории в первый час, длина визита, число запросов к серверу | наши допущения для расчёта, помечены в тексте |
| Чек-листы по архитектуре и безопасности | общая практика, а не перечень того, что стоит на этом сайте |
Система управления сайтом (CMS) — это «админка»: программа, через которую люди без программиста добавляют новости, фото и страницы. Посетитель её не видит, но от неё зависит, как сайт выглядит завтра.
Почему готовая CMS ломается, когда редакторов сотни
Популярные готовые системы — WordPress, «1С-Битрикс», конструкторы вроде Тильды — хорошо решают обычную задачу: сайт компании, два-три контент-менеджера, понятные права. Для такого сайта мы и сами чаще всего советуем готовое решение, а не разработку с нуля — сравнение есть в материале WordPress, Битрикс или Тильда.
Сайт крупного события устроен иначе. Когда редакторов сотни и они в разных странах, у готовой админки проявляются слабые места, которые на маленьком сайте не видны.
- Слишком много свободы в оформлении. Визуальный редактор позволяет менять шрифт, цвет, размер, вставлять текст из Word вместе с его стилями. Один человек так не навредит. Триста человек за неделю превратят сайт в стенгазету.
- Права «всё или ничего». Часто есть только «автор» и «администратор». Автору не хватает прав, администратору их слишком много, и в итоге администраторами делают всех.
- Одновременная правка. Два редактора открыли одну новость, оба сохранили — победил тот, кто нажал кнопку позже. Правки первого исчезли, и никто этого не заметил.
- Разные привычки в разных странах. Даты, имена, названия команд и дисциплин каждый пишет по-своему. Через месяц поиск по сайту находит одну команду под тремя написаниями.
- Нет времени учить. Сотни людей подключаются к работе прямо перед играми. Инструкцию на 40 страниц никто не прочитает: интерфейс должен объяснять себя сам.
- Каждый плагин — ещё одна дверь. Чем больше дополнений, тем больше мест, через которые можно что-то сломать или взломать.
Сценка, знакомая любому, кто вёл медийный проект:
— Новость про финал опубликована?
— Опубликовал.
— А почему она зелёная, курсивом и на пол-экрана?
— Так праздничнее.
Готовую систему можно «зажать» настройками и доработками. Но когда доработок становится больше, чем исходной системы, честнее сделать свою — под реальную работу редакции. Так мы и поступили.
Защищённый редакторский интерфейс: принципы
Защищённый редакторский интерфейс — это админка, в которой редактор может наполнять сайт, но не может испортить его дизайн и структуру. Задача, которую решала наша система, звучала просто: сотни редакторов из разных стран ничего не ломают и пишут в одном стиле.
Ниже — принципы, из которых складываются такие интерфейсы. Это подход, а не инструкция к конкретной системе: набор и глубина защиты подбираются под редакцию и тип материалов.
Блоки вместо свободного HTML
Редактор не рисует страницу, а собирает её из готовых блоков: заголовок, лид, абзац, цитата, фото с подписью, галерея, видео, таблица результатов. У каждого блока заранее заданный вид. Покрасить заголовок в зелёный нельзя — такой кнопки просто нет.
Это как конструктор с фиксированными деталями: собрать можно что угодно, распилить деталь — нельзя.
Поля с правилами
Вместо одного большого окна «пишите что хотите» — поля с ограничениями: заголовок до определённой длины, обязательный лид, обязательная подпись к фото, дата и время выбираются из календаря, а не вписываются руками. Фотографии система сама приводит к нужным размерам: редактор может загрузить снимок с телефона на 12 мегабайт, а на сайт уйдут лёгкие версии.
Стиль живёт в шаблоне, а не в голове редактора
Единый стиль невозможно обеспечить письмом «пишите, пожалуйста, единообразно». Его закладывают в шаблоны материалов: у новости, анонса, интервью и результата матча своя структура. Названия дисциплин, команд и стран выбираются из справочника, а не набираются вручную, — поэтому они везде написаны одинаково, из какой бы страны ни был редактор.
Лучшая инструкция для редактора — та, которую не нужно читать.
Роли, проверка и история
- Роли. Автор, редактор, выпускающий, переводчик, администратор — каждый видит и меняет только своё.
- Проверка перед публикацией. Материал можно отправить на просмотр, увидеть так, как его увидит посетитель, и только потом выпустить.
- История версий. Видно, кто, что и когда поменял; неудачную правку можно откатить за минуту.
- Защита от одновременной правки. Если материал открыт у коллеги, система предупредит, а не тихо перезапишет.
Сравнение на одной таблице
| Свободный визуальный редактор | Защищённый интерфейс | |
|---|---|---|
| Оформление | каждый оформляет как умеет | вид задан блоками, изменить нельзя |
| Структура материала | любая | по шаблону типа материала |
| Названия команд и дисциплин | вручную, кто как напишет | из справочника |
| Ошибка новичка | видна всем посетителям | ловится полем или проверкой |
| Обучение сотен людей | инструкции и созвоны | подсказки прямо в интерфейсе |
| Если что-то пошло не так | ищут виноватого | смотрят историю и откатывают |
Мультиязычность: одна модель контента, несколько языков сразу
Версия сайта, о которой мы говорим, — английская. При этом система мультиязычная: один и тот же сайт может работать сразу на нескольких языках. Для международного события это не украшение, а базовое требование: команда редакторов интернациональная, и аудитория тоже.
Вот принципы, на которых строится такая архитектура.
- Один материал — несколько языковых версий. Новость о финале — это одна сущность, у которой есть английская, русская или любая другая версия. Не три отдельных сайта, которые расходятся через неделю.
- Общие поля вводятся один раз. Дата, дисциплина, фото, счёт матча не зависят от языка. Их вносят один раз, а переводят только текст. Так счёт не может оказаться разным в разных версиях.
- Понятно, чего не хватает. Редактор видит, у каких материалов ещё нет перевода, и решает, показывать ли на этом языке заглушку или версию на английском.
- Отдельный адрес у каждой языковой версии. Так поисковые системы понимают, какую страницу показывать англоязычному пользователю, а какую — русскоязычному. Без этого мультиязычный сайт конкурирует сам с собой. Подробнее о типичных ошибках — в материале почему проекты на зарубежных рынках закрываются через полгода.
- Язык письма и шрифты. Если среди языков есть арабский, страница должна уметь читаться справа налево, а шрифты — содержать нужные символы. В нашей серии проектов есть, например, сайт турнира в Абу-Даби на английском и арабском.
- Часовые пояса. Матч в 10:00 по времени площадки — это другое время для зрителя в другой стране. Время лучше хранить в одном формате, а показывать с понятной подписью.
Если перевод хранится как копия страницы, языки рано или поздно разойдутся. Если перевод хранится как версия одного материала, общие данные синхронны всегда.
140 000 посетителей в день — это сколько в секунду
Цифра «140 000 в день» звучит внушительно, но для архитектуры сайта важна не она. Важно, сколько людей приходит в одну и ту же секунду: сервер не знает, что такое «сутки», он видит только очередь.
Посчитаем честно, с допущениями на виду. Факты проекта: около 140 000 живых посетителей в день, основная масса пришла на открытие в 10:00 и дальше — в течение рабочего дня. Всё остальное — допущения, которые стоит сверить с реальной статистикой.
Цифры в секунду ниже выведены из дневной посещаемости при указанных допущениях. Это оценка порядка величин, а не данные мониторинга сервера.
Допущения
| Что берём | Значение | Факт или допущение |
|---|---|---|
| Живых посетителей в сутки | около 140 000 | факт проекта |
| Когда приходит основная масса | открытие в 10:00 и рабочий день | факт проекта |
| Доля суточной аудитории в первый час после открытия | 25–30 % | допущение |
| Во сколько раз пиковая минута выше среднего за час | в 2–3 раза | допущение |
| Длительность визита | около 3 минут | допущение |
| Страниц за визит | 3 | допущение |
| HTTP-запросов за визит | около 30: страница, стили, скрипты, шрифты, картинки; при переходах часть файлов уже лежит в кэше браузера | допущение |
Расчёт: новые посетители в секунду
| Сценарий | Как считаем | Новых посетителей в секунду |
|---|---|---|
| Равномерно все 24 часа | 140 000 ÷ 86 400 с | ≈ 1,6 |
| Равномерно в рабочий день 10:00–19:00 | 140 000 ÷ 32 400 с | ≈ 4,3 |
| Первый час после открытия, 25 % дня | 35 000 ÷ 3 600 с | ≈ 9,7 |
| Первый час после открытия, 30 % дня | 42 000 ÷ 3 600 с | ≈ 11,7 |
| Пиковая минута открытия | 11,7 × 2…3 | ≈ 23–35 |
| Остаток рабочего дня, 70–75 % аудитории за 8 часов | 98 000–105 000 ÷ 28 800 с | ≈ 3,4–3,6 |
Среднее «1,6 человека в секунду» обманчиво спокойное. В момент открытия реальная нагрузка в 6–7 раз выше среднего за сутки, а в пиковую минуту — примерно в 15–20 раз. Сайт, рассчитанный «на среднее», ляжет ровно тогда, когда на него смотрят все.
Сколько человек на сайте одновременно
Есть простая формула из теории очередей: сколько людей одновременно на сайте = сколько приходят в секунду × сколько секунд они остаются. Как в магазине: если каждую минуту заходят 10 покупателей и каждый ходит 5 минут, внутри одновременно около 50 человек.
При визите около 3 минут (180 секунд):
- в первый час после открытия: 9,7–11,7 × 180 ≈ 1 750–2 100 человек одновременно;
- если пиковый темп держится хотя бы 3 минуты: 23–35 × 180 ≈ 4 100–6 300 человек одновременно;
- в обычный час рабочего дня: 3,5 × 180 ≈ 630 человек.
Сколько запросов прилетает на сервер
Один посетитель — это не один запрос. Браузер скачивает саму страницу, стили, скрипты, шрифты, каждую картинку и превью видео. По нашему допущению, это около 30 HTTP-запросов за визит, то есть запросов к серверу на порядок больше, чем посетителей. За сутки получается 140 000 × 30 ≈ 4,2 млн запросов.
| Момент | Посетителей в секунду | HTTP-запросов в секунду (× 30) | До сервера, если CDN и кэш отдают 90–95 % |
|---|---|---|---|
| Обычный час рабочего дня | ≈ 3,5 | ≈ 105 | ≈ 5–10 |
| Первый час после открытия | ≈ 10–12 | ≈ 300–360 | ≈ 15–36 |
| Пиковая минута | ≈ 23–35 | ≈ 700–1 050 | ≈ 35–105 |
Главный вывод из этой таблицы: разница между «сайт выдержал» и «сайт упал» — в том, сколько запросов вообще доходит до сервера. Сотни запросов в секунду, а в пиковые минуты около тысячи, — это много для одного сервера, который на каждый запрос собирает страницу из базы данных. И это немного, если 90–95 % из них отдаёт сеть доставки контента и кэш, а сервер видит десятки запросов в секунду.
Точную картину дают не допущения, а статистика: посещаемость по минутам в Яндекс Метрике и журналы сервера. Как читать журналы, разобрано в материале анализ логов сервера. Подставьте свою долю первого часа и длину визита в таблицу выше — и получите свою пиковую нагрузку.
Что эта математика значит для архитектуры
Ниже — практики, которые следуют из расчёта для любого сайта события. Это общая инженерная логика, а не перечень того, что стоит на конкретном сайте.
Статика — в сеть доставки контента
CDN (сеть доставки контента) — это множество серверов по миру, которые хранят копии картинок, видео, стилей и скриптов и отдают их посетителю из ближайшей точки. Для международной аудитории это вдвойне важно: зритель в другой стране получает файлы не через полмира, а из своего региона. Основной сервер при этом отвечает только за то, что действительно меняется.
Готовые страницы — из кэша
Новость о финале одинакова для всех читателей. Нет смысла собирать её заново тысячу раз в секунду: достаточно собрать один раз и раздавать копию. Даже очень короткий кэш творит чудеса. Если на главную приходит 30 запросов в секунду, а кэш живёт 5 секунд, то из 150 запросов только один доходит до сервера, остальные 149 получают готовую копию.
Сброс кэша — точечный
Вот где сотни редакторов встречаются с нагрузкой. Если каждая публикация сбрасывает кэш всего сайта, то при десятках публикаций в час сайт сам себе устраивает атаку: всё приходится пересобирать заново, причём в самые горячие минуты. Правильно — обновлять только то, что изменилось: саму страницу материала и списки, где он показан.
Читатели — отдельно от редакторов
Посетители читают, редакторы пишут. Если обе нагрузки бьют в одну базу данных и в одни и те же ресурсы, наплыв зрителей замедляет публикацию, а массовая публикация замедляет сайт. Публичную часть и админку разумно разделять.
Тяжёлое — заранее, а не в момент запроса
Уменьшение фото, превью видео, подготовка версий страниц — всё это лучше делать в момент загрузки, а не когда посетитель открыл страницу. Как это влияет на скорость и почему медленный сайт теряет посетителей, мы разбирали в материале про скорость сайта.
Нагрузочный тест — до игр, а не во время
Пиковую нагрузку стоит проверить заранее, с запасом в 2–3 раза от расчётной. Открытие — экзамен без пересдачи: репетировать нужно до него.
Безопасность сайта события: чек-лист
В нашей системе много параметров безопасности. Конкретные механизмы защиты отдельного сайта не принято раскрывать публично, поэтому ниже не перечень того, что стоит у «Игр будущего», а чек-лист, по которому стоит проверить любой сайт с большой редакцией и громким событием.
Громкое событие привлекает не только зрителей. Чем больше аудитория, тем интереснее сайт для тех, кто хочет его сломать, подменить новость или просто положить на время открытия.
- У каждого редактора личная учётная запись, общих логинов нет.
- Вход в админку — с двухфакторной проверкой: пароль плюс код.
- Права минимальные: каждый может ровно то, что нужно для его работы.
- После игр временные учётные записи отключаются, а не живут годами.
- Админка доступна не всему интернету, а по отдельному адресу или с ограничением доступа.
- Редакторы не могут вставить произвольный код в материал — только содержимое в готовые блоки.
- Загружаемые файлы проверяются по типу и размеру, исполняемые файлы не принимаются.
- Есть журнал действий: кто, что и когда изменил или опубликовал.
- Резервные копии делаются автоматически, а восстановление из них проверено на практике.
- Сайт работает только по защищённому соединению (HTTPS).
- Перед сервером стоит защита от атак на отказ и фильтрация подозрительных запросов.
- Обновления системы и библиотек ставятся регулярно и не за день до открытия.
- Включён мониторинг: если сайт замедлился или упал, дежурный узнаёт об этом раньше зрителей.
- Есть план Б: облегчённая страница или режим «только чтение» на случай аварии.
Самая популярная уязвимость в мире по-прежнему не в коде, а на стикере с паролем, приклеенном к монитору в пресс-центре. Поэтому личные учётные записи и вторая проверка входа дают больше, чем любая сложная защита.
Много версий CMS: почему это нормально
Нашу систему управления мы не сделали за один подход. Версий было много, и сейчас система протестирована и работает. Для продукта, которым одновременно пользуются сотни людей в разных странах, это не недостаток, а единственный честный путь.
Что из этого следует для любого подобного проекта:
- Начинать стоит со сценариев редакторов, а не с кнопок. Что публикуют чаще всего, кто проверяет, где люди ошибаются. Интерфейс вырастает из этих ответов.
- Каждая версия — ответ на реальную ошибку. Если редактор смог что-то сломать, это повод не ругать редактора, а убрать такую возможность из интерфейса.
- Тестировать нужно и людьми, и нагрузкой. Посадить за админку тех, кто будет работать на играх, и отдельно прогнать сайт под расчётным пиком.
- Перед событием изменения замораживают. Новые функции — после игр. Во время игр — только исправления.
- После события — разбор. Что мешало редакторам, где сайт был на грани, что поменять к следующему сезону.
Хорошая система управления не та, где много функций, а та, где мало способов ошибиться.
Если вам нужен сайт для крупного события: чек-лист
Перед тем как выбирать подрядчика или систему, ответьте себе на эти вопросы. Половина из них не про технологии, а про людей и время.
- Сколько редакторов будет работать с сайтом в пиковые дни и из каких они стран?
- Какие типы материалов публикуются: новости, результаты, расписание, интервью, фото, видео?
- Кто пишет, кто проверяет и кто нажимает «опубликовать»?
- Какие языки нужны на старте и какие могут добавиться позже?
- Когда пики: открытие, финалы, церемонии? Какая доля аудитории придёт в первый час?
- Сколько это в секунду по формуле из этой статьи и какой запас закладываем?
- Что отдаёт CDN и кэш, а что каждый раз собирается на сервере?
- Когда нагрузочный тест и обучение редакторов — за сколько недель до события?
- Как устроены права, вход в админку, журнал действий и резервные копии?
- Кто дежурит в день открытия и что делаем, если сайт замедлился?
- Что будет с сайтом после игр: архив, следующий сезон, новые турниры?
Если на половину вопросов ответа пока нет, это нормально: именно с них начинается проектирование. Стоит заранее проверить и технический фундамент — индексацию, дубли, скорость; что смотреть, разобрано в материале про технический аудит сайта.
Другие проекты серии «Игры будущего» и фиджитал-спорт
Сайт «Игр будущего» — часть серии наших проектов вокруг фиджитал-движения. В каждом своя задача: где-то турнир на нескольких языках, где-то сообщество, где-то федерация.
- Кейс сайта «Игр будущего» — собственная CMS для сотен редакторов, мультиязычная платформа, около 140 000 посетителей в день.
- Games of the Future Abu Dhabi 2025 — сайт турнира в Абу-Даби на английском и арабском.
- World Phygital Community — мультиязычный портал фиджитал-спорта с каталогом федераций.
- Phygital International — мультиязычная платформа турниров и федераций с личными кабинетами.
- Phynder — мультиязычный сервис поиска игроков, команд и турниров.
- ВФФС — сайт Всероссийской федерации фиджитал-спорта: регистрация участников и работа с регионами.
«Хорошая админка — та, в которой невозможно сделать некрасиво, даже если очень хочется.»
Частые вопросы
Сколько это в секунду — 140 000 посетителей в день?
В среднем за сутки около 1,6 человека в секунду, за 9-часовой рабочий день — около 4,3. Если на открытие в первый час приходит 25–30 % дневной аудитории, это 10–12 новых посетителей в секунду, а в пиковую минуту — 23–35.
Почему для сайта события не взять готовую CMS вроде WordPress или Битрикса?
Для сайта с несколькими редакторами готовая система — хороший выбор. Когда редакторов сотни и они из разных стран, нужны жёсткие шаблоны, роли, проверка и защита от одновременной правки — и доработок становится больше, чем самой системы.
Что такое защищённый редакторский интерфейс?
Это админка, в которой редактор собирает материал из готовых блоков и заполняет поля с правилами, но не может изменить дизайн и структуру сайта. Ошибку новичка ловит интерфейс, а не посетитель.
Можно ли сделать один сайт сразу на нескольких языках?
Да. Правильнее хранить один материал с несколькими языковыми версиями: общие данные — дата, фото, счёт — вводятся один раз, а переводится только текст. У каждой языковой версии должен быть свой адрес для поисковых систем.
Как подготовить сайт к пиковой нагрузке на открытии?
Посчитать пик в секунду по доле аудитории в первый час, отдать статику через CDN, раздавать готовые страницы из кэша, сбрасывать кэш точечно и провести нагрузочный тест с запасом в 2–3 раза до события.
Как это выглядит у клиентов
Опубликовано .
