Сайт Ростелеком под капотом

Пока свежи воспоминания, хочу рассказать о том как я участвовал в поддержке портала одной крупной телекоммуникационной компании России.

Пять лет назад кто-то в Москве озаботился состоянием телекоммуникационной отрасли в РФ. Обнаружилось, что на основе государственного имущества приближенныепредприниматели строят бизнес, но забывают делиться. Кроме того в стратегическую отрасль стала проникать офшоризация, а с ней и иностранные диверсантыинвесторы. Было принято решение вернуть все региональные компании под контроль и присоединить к Ростелеком.

До этого в стране работало 7 крупных региональных компаний телекоммуникационных услуг. У каждой компании был выстроен процесс работы с клиентами, подрядчиками. У каждой был свой сайт, биллинг, какой-то CRM и т.д. После объединения пришло понимание, что с этим нужно что-то делать. В качестве базы был взят опыт ОАО «Уралсвязьинформ», который на тот момент уже объединял 6 областных компаний, имел успешный опыт по интеграции разрозненных сервисов и развитую техническую службу.

Введение

Когда, два года назад, я пришел в проект, сайт работал уже несколько месяцев, а основные силы компании были брошены на создание личного кабинета клиента, объединение биллинга, баз клиентов, тарифов и т.д. По словам коллег сайт был перенесен на java с php за пару бессонных недель на таблетках и энергетиках. Эта легенда всячески поддерживается в коллективе. Она объясняет наличие непонятных мест в коде, нелепые ошибки, опечатки и т.п.

Портал состоял из нескольких приложений: сайт (представляет из себя CMS с поддержкой множества регионов, объединённых в макрорегионы), бэкофис для сайта, баннерокрутилка, бэкофис для нее, бэкофис публикации новостей и другие. По понятным причинам первые релизы были выполнены как MVP и просто работали.

Процесс разработки не был выстроен. Проект начинался как java web приложение, но затем был преобразован в maven проект. В компании использовался собственный трэкер, для maven был поднят локальный nexus репозитарий, код положили в svn. Все работали в транке и его же выкладывали на продакшен.

Публикация релиза была вообще кошмаром. На продакшен выкладывался распакованный war. Иногда выкладывали отдельные jsp. Попадание неотлаженного кода приводило к падению tomcat, недоступности сайта и повышению энтропии в офисе. Был случай, когда более получаса сайт лежал, пока не позвонили от заказчика! После чего пересобрали предыдущий релиз и выложили целиком проект. Потом нашли причину и покарали виновных, но «осадочек-то остался».

Еще была проблема с правами пользователей. Руководитель группы разработки состоял в группе root. После его обновлений другой пользователь не мог обновляться. На это попался сам, попытка изменить права уронила сайт и… беготня, повышенное давление, мокрая спина, знакомство с высоким начальством… во время испытательного срока.

Я, как и многие, ленивый человек. И повышение энтропии или только такая возможность меня угнетает. Поэтому составил себе небольшой план по наведению порядка, получил карт-бланш и принялся за дело.

Окружение проекта

Первым делом была изменена структура проекта. Проект стал многомодульными с иерархическим наследованием зависимостей. Тут же обнаружилось, что отдельные модули использовали разные версии одинаковых библиотек — поправили.

Затем был выработан цикл жизни кода. После получения задачи разработчик делал ветку транка со своей фамилией и номером задачи, работал в ней и сдавал в транк. По требованию транк выкладывался на тестовый сервер для проверки. После утверждения ветка разработчика мержилась с релизом, который по требованию выкладывался на продакшен.

Кто-то из разработчиков пользуется идеей, кто-то эклипсом, а они по разному «облегчают» жизнь разработчика. Выяснилось, что не всегда проект собирающийся в идее, собирается в эклипсе и наоборот. Кроме того, в плане был дженкинс для автоматизации рутинных задач. В maven проект были добавлены и настроены необходимые плагины и настройки локальной IDE перестали влиять на процесс сборки.
Сайт развивался, количество задач росло. Тестовый сервер разделил на два: тестовый для заказчика и тестовый для разработчиков. Процесс выкладки на тест и так отнимал много времени, а теперь их стало два. Позвали дженкинса. В pom проекта были добавлены необходимые цели, а в дженкинсе задачи. А потом еще и автозапуск этих задач по времени. На тест выкладывался два раза в день, на дев — два раза в неделю.

Для подключения к ЦХД использовался vpn, который нередко обрывался при передаче больших файлов. Исторически сложилось, что проект содержал немного статического содержимого в WEB-INF и результирующий размер war получался более 50Мб. Статика была обнаружена и выпилена, что сократило размер втрое и решило проблему выкладки.

Управление качеством кода

Код не читался. Форматирование привело к массовому коммиту и потере истории. Приняли стандарт форматирования, сдвинули версию и начали с чистого листа.

Во время выполнения задач всем рекомендовалось выполнять рефакторинг обнаруженных проблемных мест. И комментировать, комментировать, комментировать… Для контроля поставили сонар. Цели для него добавили в pom проекта, а в дженкинсе задачи и порядок их исполнения. Отчет показал, что работы непочатый край.

В проекте активно используются jsp. При старте томкат эти файлы компилируются в классы. Так как одна из целей — не допустить непроверенного кода на продакшен, была введена прекомпиляция jsp во время сборки. Также этот шаг устранил проблему частичного обновления и ускорил старт продакшена после обновления.

Сайт — это не только серверная часть, но и клиентские скрипты и их тоже нужно проверять. В нашем окружении хорошо показал себя аналог jslint от yahoo. В процесс сборки проекта добавлены шаги по синтаксической проверке css и js файлов, а позднее минификация, группировка и архивация.

Архитектура портала

Объем контента и количество посещений росли как снежный ком. Суточный бэкап сайта перевалил за 5Гб в архиве, а пиковые посещения 10кк. Пришло время оптимизировать работу серверной части сайта.

Содержимое сайта состоит из двух частей: статический контент (статьи) и связи. Контент создается в бэкофисе и хранится в виде дерева файлов. А связи лежат в БД. Из-за наличия регионов и макрорегионов эти связи очень непростые.

Файловая часть несет проблему. Уже сейчас бэкап занимает несколько часов и не всегда успевает закончиться в отведенное время. Иногда подводит процесс репликации статики между серверами. Огромное количество файлов и каталогов нагружают дисковую систему и сокращают время жизни. Оптимизация работы БД была проделана по типовому сценарию. Проверили наличие необходимых ключей. Провели работу по оптимизации запросов. Добавили кэш для частых запросов. Например, панель выбора региона, список тарифов или телепрограмма.

Поначалу контент раздавался с двух томкатов через энжинкс, затем количество томкатов увеличилось до четырех. Статика раздается напрямую энжинксом. Для уменьшения нагрузки на энжинкс изменены заголовки запросов кэширования в броузерах. Статика отдается без куков и лишних заголовков. Изучены и применены рекомендации yahoo и google.

Заключение

Конечно не все проблемы удалось решить. Но даже то немногое, что было сделано, значительно облегчило поддержку проекта. После внедрения автоматизации улучшилась культура производства и снизился порог вхождения в проект. Была устранена проблема попадания неисправного кода на продакшен.

С тех пор, спина потела только от игры в настольный футбол или теннис… в свободное время.

Кстати, к дженкинсу был привязан светофор. Но это уже совсем другая история…