За две недели марта офисы опустели, а сотрудники ушли по домам. Корпоративные порталы, VPN-шлюзы, системы документооборота и видеоконференции приняли нагрузку, к которой их не готовили. По нашим замерам в проектах клиентов из госсектора и крупного бизнеса трафик на внутренние сервисы вырос в три раза за считанные дни. Там, где раньше держали запас на пиковые часы, теперь пик стал постоянным состоянием. Ниже – что делать, когда система начинает захлёбываться, а отключить её нельзя.

Сначала найдите узкое место, а не докупайте железо

Утроившаяся нагрузка редко равномерна. Обычно упирается один компонент: пул соединений к базе, число лицензий VPN, однопоточный шлюз авторизации или диск под логами. Докупка серверов вслепую сжигает бюджет и не лечит причину.

Начните с измерений. Снимите метрики по CPU, памяти, дисковому вводу-выводу и сетевым соединениям на каждом узле в часы пиковой нагрузки. Посмотрите время отклика базы и длину очередей запросов. В девяти случаях из десяти виден один-два компонента, на которые приходится деградация. Их и масштабируйте в первую очередь.

Если у вас нет актуальной схемы того, как сервисы зависят друг от друга, восстановите её – это экономит часы при разборе инцидента. Здесь окупается дисциплина технической документации: без неё команда ищет причину сбоя вслепую.

Масштабируйте горизонтально и снимайте нагрузку с критичных узлов

Вертикальный путь – добавить ядра и память одному серверу – даёт быстрый, но конечный выигрыш. Горизонтальное масштабирование надёжнее под резко выросший трафик: ставьте несколько одинаковых узлов приложения за балансировщиком, выносите сессии в общее хранилище, а статику – на отдельный кэширующий слой или CDN.

Несколько приёмов, которые дают эффект за дни, а не недели:

  • Балансировка нагрузки. Распределите HTTP- и VPN-трафик между несколькими шлюзами. Это убирает единую точку отказа и сглаживает пики.
  • Кэширование. Вынесите часто запрашиваемые данные в Redis или Memcached. Чтение из кэша снимает с базы основную долю запросов.
  • Реплики базы. Направьте операции чтения на реплики, оставив запись на основной узел. Отчёты и выборки перестают конкурировать с транзакциями.
  • Очереди. Тяжёлые операции – генерацию отчётов, рассылки, обработку файлов – уводите в асинхронные очереди, чтобы они не блокировали интерактивные запросы.

Пропускная способность каналов и ёмкость VPN – отдельный фронт. Если шлюз удалённого доступа держал сотню сессий, а нужно пятьсот, кластеризуйте его и поднимите лимиты заранее. Мы разбирали этот сценарий подробно в материале про инфраструктуру для удалённой работы, а вопросы доступа без потери контроля – в заметке о защищённом удалённом доступе.

Заложите запас и автоматизируйте

Разовое расширение закроет сегодняшний пик, но нагрузка продолжит расти. Перейдите от ручного добавления ресурсов к управляемому процессу: шаблоны конфигураций, скрипты развёртывания новых узлов, мониторинг с порогами оповещений. Когда метрика приближается к лимиту, инженер узнаёт об этом до отказа, а не после звонка пользователей.

Закладывайте запас в полтора-два раза от текущего пика. В условиях, когда сроки возврата в офисы неясны, это не избыточность, а разумная страховка.

Вывод

Трёхкратный рост нагрузки – проверка зрелости инфраструктуры, а не повод для паники. Измерьте, найдите узкое место, масштабируйте горизонтально и оставьте запас. Если своих рук не хватает, разумно перейти на отказоустойчивую инфраструктуру под выросшую нагрузку – она держит пики без простоев для бизнеса.