Серверы сайта и личного кабинета регионального оператора по обращению с отходами (Россия) настраивал Евгений Росляков. Сайт публичный, кабинет для юридических лиц, где они берут договоры и счета. Евгений занимается серверами и сайтами с 2016 года. Он самозанятый, заключает договор, а организациям выдаёт закрывающие документы. Живёт и принимает заказы в Москве, остальных ведёт удалённо.
Беда копилась в дни выставления счетов. Раз в месяц сотни организаций открывают кабинет за одним и тем же, и в эти дни он переставал отвечать. Публичный сайт тормозил следом, хотя посетителям оттуда нужны только контакты и тарифы.
Устройство было такое. Сайт работал на классическом LAMP: Linux, Apache, MySQL, PHP. Кабинет — приложение ASP.NET на Internet Information Services под Windows Server. Два сервера, две технологии, и настройки у обоих остались как после установки. Лимиты процессов, таймауты и кеш никто не трогал.
Серверами занимается один системный администратор. Linux и Windows он знает, но в дни выставления счетов было не до разбора: звонили клиенты, а он вручную перезапускал службы и ждал, пока всё оживёт.
Задача: пережить день выставления счетов без падений и развести кабинет и сайт так, чтобы тормоза одного не задевали другой. Приложения менять нельзя, поэтому всё решалось на уровне серверов.
Сначала искал, где ломается. Выгрузил логи за несколько дней выставления счетов и сложил с графиками загрузки. Apache запускал процессы по старой схеме и упирался в память, а кабинет страдал из-за пула приложений: он разрастался и не освобождал ресурсы.
Общим входом сделал Nginx на Linux. Он принимает запросы из интернета, хранит сертификаты, обслуживает соединения по второй версии протокола передачи страниц и сам отдаёт картинки, скрипты и стили. Страницы публичного сайта кеширует, поэтому до Apache доходит малая часть запросов. Для сайта и кабинета задал разные таймауты: кабинету, где собираются документы, нужно подождать дольше. Добавил ограничение частоты запросов и защиту от ботов, которые раньше перебирали страницы и грузили сайт.
Apache перевёл на mpm_event, PHP вынес в PHP-FPM, лимиты процессов подогнал под память сервера. Теперь нагрузка не раздувает его до отказа.
В Internet Information Services сделал отдельные пулы приложений и поставил ночную переработку по расписанию. Включил сжатие и фильтрацию запросов, настроил журналы так, чтобы по ним можно было разбираться.
Перед очередным днём выставления счетов провёл нагрузочную проверку: подал поток запросов, похожий на реальный, и правил лимиты по результатам. Поставил мониторинг ответов и ошибок. Написал регламент: что смотреть накануне, как выкатывать изменения, что делать при сбое.
Первый день выставления счетов после настройки прошёл без остановок. В самый пик кабинет отвечал медленнее обычного, но работал, а сайт нагрузки почти не почувствовал. Раньше такие дни заканчивались звонками и ручной рассылкой документов.
Сотрудники оператора перестали гадать, почему «что-то лежит». Мониторинг показывает, где растут ошибки или время ответа, и чаще всего это видно до жалоб. Регламент хранится у системного администратора. Он сам готовится к дням выставления счетов и подкручивает лимиты, не дожидаясь меня.
Есть и граница возможностей. Настройка серверов не лечит приложение. Если запрос в кабинете долгий из-за кода или базы, Nginx его не ускорит. Такие места я собрал в отдельный отчёт для разработчиков кабинета, пусть разбирают их своим порядком. Организаций будет становиться больше, и тогда придётся добавлять мощности и снова пересматривать лимиты. Это заложено в регламент как плановая проверка перед сезоном.
Следующим шагом клиент думает вынести кабинет на отдельный сервер с запасом и позже заняться самим приложением.
Если ваши сайт и кабинет живут на разных серверах и «ложатся» в одни и те же дни, пришлите мне сообщение на freelance.ru: на чём работает каждая часть и когда случаются провалы. Я подскажу, с чего начинать.
