Как мы модернизировали портал yota.ru
Некоторое время назад мы полностью переделали портал www.yota.ru. Несмотря на некую преемственность по отношению к предыдущей версии, сайт был переделан практически полностью — и front-end, и back-end. Потребность в этой масштабной модернизации окончательно назрела, как только Yota начала предоставлять услуги в качестве мобильного оператора. Ниже мы хотим рассказать, зачем понадобилось переделывать сайт, какие задачи мы решали, с какими сложностями столкнулись и чего достигли на данный момент.Причины для модернизации сайта и последовавшие решения можно разделить на две группы: связанные с front-end (дизайн, карта сайта, структура страниц) и back-end. Рассмотрим каждую из них отдельно.
Front-end: дизайн и структураДо августа 2014 года Yota предоставляла услуги в сфере беспроводного 4G-интернета, и функционал и возможности портала удовлетворяли запросам наших пользователей. Но с переходом Yota в статус мобильного оператора к сайту стали предъявляться новые требования.Стоит сказать, что предложение Yota отличается от того, что сегодня представлено на рынке мобильной связи. И поскольку наш портал — не просто информационный ресурс, а важный инструмент взаимодействия с пользователями, предназначенный для самостоятельного управления всеми услугами, он прежде всего должен был отразить произошедшие с Yota перемены. Причём менять предстояло не только дизайн.
С расширением спектра услуг навигация по сайту затруднилась. По итогам проведённого нами usability-тестирования выяснилось, что для получения нужной информации пользователям приходилось совершать довольно много лишних движений. Элементы и блоки были расположены недостаточно очевидно и логично, так что на пути к цели посетитель сайта совершал больше кликов — например, чтобы выбрать свой город и посмотреть карту покрытия.
Второй важной причиной переделки front-end стало отсутствие резервов масштабируемости внутренней структуры. С появлением новых услуг и расширением географии присутствия мы столкнулись с тем, что без переделки самой структуры сайта расширять его наполнение становится крайне затруднительно. Да и выглядело это не слишком удачно.
Перед началом работ над новым дизайном мы провели исследование целевой аудитории. Очевидно, что при разработке дизайна нового сайта мы были ограничены определёнными требованиями по стилю: необходимо было использовать существующие корпоративные цвета и гарнитуры. Кроме того, дизайн сайта должен был нести совершенно ясные послания: мы не похожи на других операторов и нашими услугами очень легко пользоваться.
С точки зрения структуры сайта нужно было решить следующую задачу. Через главную страницу на портал попадают до 70% пользователей. И нам было важно сделать так, чтобы они либо могли прямо здесь найти нужную информацию, либо в один клик перейти к интересующему разделу. Например, один из главных вопросов перед покупкой беспроводного модема: «А есть ли у меня дома / в офисе покрытие сети?» Поэтому мы дали возможность узнать об этом по одному клику на главной странице.
С главной страницей предыдущей версии портала был связан ещё один важный момент. Около 25% пользователей из тех, кто зашёл на главную, потом просто уходили с сайта. Мы долгое время не могли выявить причину такого поведения. Проведённое в ходе разработки UX-тестирование показало, что часть пользователей просто не хочет ходить по меню сайта. Необходимость разбираться, искать нужную ссылку, нажимать на неё воспринимались как излишняя сложность сайта. Стоило нам разместить на главной странице модуль заказа модемов и SIM-карт, как количество «отказников» резко снизилось.
Во время UX-тестирования мы также проверяли эффективность разных управляющих элементов на странице. Помимо многих интересных моментов выяснилось, что пользователи стали в два раза чаще кликать на кнопки, когда мы увеличили их в 1,5 раза по сравнению с предыдущей версией портала.
Back-end: платформа сайта Разработка нового портала повлекла за собой и смену платформы, на которой базировался сайт. Использовавшаяся на тот момент CMS Bitrix уже не удовлетворяла всем нашим требованиям, поскольку: Система имела некластиризованную конфигурацию, то есть вся нагрузка по сайту ложилась на один PHP-сервер. Его ресурсы производительности были почти исчерпаны, отмечались случаи перегрузки и недоступности сайта. А переход на версию Bitrix, поддерживавшую кластеризацию, означал существенную переработку кода. Все обновления контента производились сразу на рабочем сервере, и в случае появления каких-то ошибок это отражалось и на работоспособности сайта. То есть необходимо было снизить его аварийность, тем самым улучшив качество обслуживания наших пользователей. В системе не использовались возможности CMS Bitrix по самостоятельному редактированию контента сотрудниками бизнес-подразделений компании. Все изменения необходимо было осуществлять с помощью ручной правки определённых файлов, и эта ответственность лежала на программистах, поддерживающих Bitrix, и сотрудниках департамента IT. Это означало дополнительные затраты ресурсов, отвлечение IT-специалистов от задач по поддержке и сопровождению инфраструктуры и т.д. К моменту передачи управления сайтом департаменту IT такой способ управления уже полностью исчерпал себя. Пришла пора избавить технических специалистов от обязанности наполнять и обновлять контент на сайте. Необходимо было спроектировать и внедрить такое решение, которое бы максимально использовало возможности CMS для сокращения затрат и сроков редактирования контента, обеспечивало высокие показатели готовности и производительности при минимальных затратах на сопровождение. Был проведён анализ возможности дальнейшего развития Bitrix с учётом всех наших потребностей. Этот путь был признан нецелесообразным, поскольку миграция была бы существенно затруднена: для кластеризации необходимо было делать апгрейд версии Bitrix, докупать модули, перерабатывать существенную часть кода. В конечном счёте получили бы не так много возможностей по контент-менеджменту, как нам хотелось. То есть техническим специалистам всё равно пришлось бы выполнять немало непрофильных работ, которые в случае с другими системами могут быть переложены на соответствующие бизнес-подразделения компании. И вопросы доступности, связанные с архитектурой и обеспечением техподдержки.Итак, оказавшись перед выбором — пытаться довести до ума Bitrix или внедрить новую CMS, — мы выбрали новую. Дело оставалось за малым: определиться с конкретной системой. Рассматривались различные предложения, начиная от проприетарных закрытых продуктов, с последующей полной зависимостью от поставщиков решений, до написания системы на Ruby с нуля, со всеми сопутствующими рисками, неизвестной работоспособностью, функционалом и неудовлетворительным сопровождением.
В результате выбор был сделан в пользу системы Liferay. Эта платформа предлагает достаточно богатый и гибкий функционал, о чём будет сказано чуть позже. Одним из существенных преимуществ стала открытость системы: наша компания в большинстве случаев делает ставку на open source-технологии, поскольку это даёт возможность не только контролировать работу и функциональность продуктов, но и самостоятельно осуществлять гибкую настройку под свои нужды. Нельзя не отметить и такие плюсы Liferay, как однородность с другими нашими системами и технологиями (в основном у нас используется технология JEE) и простота обслуживания. В том числе и за счет того, что при развертывании Liferay мы смогли максимально задействовать существующую инфраструктуру — операционные системы, сервер приложений, база данных, — внедрение Liferay не выдвигало никаких специфических требований к окружению.
Для новой конфигурации, способной к безболезненному масштабированию в будущем, была принята следующая схема: два сервера в режиме активного кластера (то есть активны оба устройства) обслуживают сам сайт и запросы к нему. На отдельный сервер возложена задача контент-менеджмента. То есть осуществляется активное резервирование серверов самого сайта, а сервер, с которым работают сотрудники разных подразделений Yota, интегрированный с нашей системой аутентификации, скрыт в нашей корпоративной подсети.Для повышения производительности мы воспользовались известным решением для высокопроизводительных приложений: реализовали модель CDN (content delivery network), установив ряд серверов Nginx, содержащих используемые на сайте графические файлы, текстовые, CSS-файлы и т.д. Тем самым мы полностью сняли нагрузку по отдаче статического контента с серверов сайта. Также это решение упрощает последующее масштабирование, поскольку количество Nginx-серверов можно увеличивать многократно по мере роста нагрузки.
Сервер контент-менеджера выполняет своего рода роль буфера, инструмента премодерации. Например, если сотрудник какого-либо отдела хочет опубликовать на сайте новость или иную информацию, то данные отправляются на сервер контент-менеджера, где они должны быть одобрены руководителем этого сотрудника. Все эти рабочие процессы, workflow, могут быть гибко настроены с помощью встроенного редактора BPMN — Activiti. После утверждения контента он публикуется на сайте. Эта процедура может осуществляться как вручную администратором, так и автоматически, в том числе по расписанию. Например, ночью, когда посещаемость минимальна. Такая схема работы — staging, то есть разбивка на этапы, — позволила управлять изменениями контента и предотвращать аварии. Теперь можно протестировать все вносимые изменения без выгрузки на сайт.
Ещё одним преимуществом Liferay с точки зрения редактирования контента является идеология WYSIWYG (what you see is what you get). То есть все изменения вносятся не в программный код, а с помощью удобного графического интерфейса. Сотрудник с правами администратора открывает в браузере на CMS-сервере копию сайта, мышью перемещает и добавляет нужные элементы, напрямую вносит изменения в текст, после чего подтверждает изменения и сразу может видеть, как будет выглядеть сайт для пользователей. Это позволяет избежать опечаток и ошибок в вёрстке в рабочей версии сайта.
Отдельной задачей стояла организация сквозного процесса разработки и модификаций нашего сайта от дизайнеров до запуска изменений на сайте. Сайт Yota (как и сама компания) развивается очень динамично — мы постоянно занимаемся его улучшениями, — и тут было очень важно сделать процесс реализации новых идей максимально быстрым. Нам удалось так наладить работу нескольких команд, что путь от «идеи» до сайта начал занимать минимальное время. В основе этого лежит: постоянная сборка над ветками для разработки / тестирования / поставки (Git, Grunt, набор пре-процессоров), а также стандарт реализации вёрстки, в котором отражены например такие правила как: один общий для сайта минифицированный CSS и специализированные CSS, запрет смешения функциональных стилей; запрет iFrame, помещение хэштегов в контейнеры и др.
Многие разработчики под Liferay сталкиваются с проблемой интеграции JavaScript в портлеты. Перед нами она также возникла, и мы нашли следующее решение, отразив в стандарте разработки: запрет глобальных переменных, использовать backbone.js для управления зависимостями между модулями, system.js, для подключения модулей; все параметры модуля JS задаются через конструктор (в т.ч. локализованные текстовые ресурсы, селекторы элементов DOM, параметры запросов к REST API бэк-энда), которые инициализирует портал при отрисовке портлета; также конструктор предусматривает параметры вызовов по умолчанию; взаимодействие JavaScript компонент через jQuery.
На этом мы, пожалуй, вынырнем из технических глубин и попробуем подвести итог.
Результаты Для конечного пользователя самым заметным результатом проделанной нами работы стала смена дизайна и структуры страницы. Быстродействие front-end выросло, не в последнюю очередь благодаря выносу статики на отдельные серверы. В то же время кластеризация и внедрение серверов статики позволили исключить возможность аварий в часы высоких нагрузок. Даже в условиях высокой посещаемости сайт никак не снижает свою производительность.С точки зрения сотрудников Yota, вносящих изменения на сайте, эта процедура радикально упростилась, появились:
WYSIWYG-редактор, позволяющий менять структуру сайта без участия программистов; доступ к контенту для сотрудников любых департаментов; внедрение процесса утверждения вносимых изменений; полностью контролируемый процесс публикации на сайте. На текущий момент мы используем не более 20–30% возможностей Liferay как по функционалу, так и по производительности. Поэтому проведённую модернизацию back-end нельзя рассматривать как решение лишь сиюминутных потребностей. Это был стратегический шаг, который в будущем позволит быстрее и эффективнее решать новые задачи как для новых функций сайта, так и для расширения возможностей самообслуживания клиентов.
