Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

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

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

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

До этого в стране работало 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кк. Пришло время оптимизировать работу серверной части сайта.

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

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

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

Завершение

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

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

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

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB