Для библиотеки вышло исправление безопасности
Проверяем на тестовом стенде и выпускаем плановым релизом
Проектируем и разрабатываем сайты, приложения и цифровые системы, которые помогают бизнесу расти.
Поддержка · Мониторинг · DevOps · с 2007 года
Стабильная работа сайта — это внимание к нюансам. Обновляем модули и зависимости, каждый день автотестами проверяем оплату, корзину и API, получаем ошибки в момент появления, мониторим систему, базу и сеть — и поднимаем разработчиков по тревоге.
Почему поддержка ↗
Хорошо сделанный сайт работает годами. Но он живёт не в вакууме: выходят новые версии библиотек, банки и сервисы обновляют API, растут база и нагрузка, продлеваются сертификаты. Каждый нюанс сам по себе мелкий — важно заметить его вовремя и закрыть в плановом режиме.
Проверяем на тестовом стенде и выпускаем плановым релизом
Адаптируем интеграцию до даты перехода
Автотест замечает расхождение — правим вёрстку или скрипт
Следим за местом и скоростью, настраиваем хранение и ротацию
Проверяем продление заранее и уведомляем ответственных
Настраиваем SPF, DKIM и DMARC, проверяем доставку писем о заказах
Примеры типичных нюансов, а не список проблем конкретного сайта.
Поддержка — это когда ошибки закрываются раньше, чем вы о них узнаете. Для этого вокруг проекта работают пять уровней сопровождения — от малого к общему.
Уровень 1 из 5 · Фундамент
Фреймворки и языки держим на поддерживаемых версиях — Django, Next.js, Python, Node.js. Ведём реестр компонентов проекта и сверяем его с базами уязвимостей. Обновляем небольшими шагами и сначала на тестовом стенде.
| Компонент | Сейчас | Доступно | Статус |
|---|---|---|---|
| Django | 4.2 LTS | 5.2 LTS | Плановое обновление |
| Next.js | 14.2 | 15.x | Проверено на staging |
| Python | 3.10 | 3.13 | Плановое обновление |
| Node.js | 18 | 22 LTS | Критические уязвимости |
| Пакеты Python / npm | 47 шт. | 3 уязвимости | Исправлено в релизе |
| Nginx · ОС · Docker-образы | — | — | Актуально |
Пакеты Python и npm, модули CMS, библиотеки интеграций. Проверка уязвимостей встроена в сборку и идёт по расписанию.
Плановый переход на поддерживаемые версии Django, Next.js, Python, Node.js. Предупреждаем о конце поддержки заранее.
Пакеты ОС, Docker-образы, Nginx, PostgreSQL, SSL-сертификаты. Доступы, ключи и секреты — под контролем.
Тестовый стенд, выпуск через CI/CD и план отката. Если обновление пошло не так — возвращаем предыдущую версию.
Уровень 2 из 5 · Автотесты
Платёжные шлюзы, системы оплаты, корзина, API и интеграции — автоматические сценарии проходят их каждый день и после каждого обновления. По каждому прогону — отчёт со скриншотом шага, на котором что-то пошло не так.
Добавление товара, пересчёт цен и скидок, доставка, обязательные поля, создание заказа.
Платёжная форма, ответы провайдера, callback/webhook, смена статуса: успех, отказ, отмена.
Обмен с CRM, 1С, службами доставки и внешними API; повторная отправка без дублей.
Заявки, вход, поиск и всё, что приносит обращения и деньги именно на вашем сайте.
Реальных списаний нет: платёжные сценарии прогоняем в тестовом контуре провайдера, а на рабочем сайте контролируем API, уведомления об оплате и статусы. Физический терминал и реальные платежи — по отдельно согласованному сценарию.
Тесты проверяют сценарии, которые мы предусмотрели. Ошибки реальных пользователей отслеживает следующий уровень.Уровень 03 · Ошибки на сайте →Уровень 3 из 5 · Анализ логов
Все логи подключённых систем собираются в Graylog и автоматически анализируются на ошибки. Исключения кода приходят в Sentry с версией и действием пользователя. По номеру заказа видна вся цепочка: что нажал клиент, что ответил банк, где оборвалось.
Сбой оплаты появляется в нашем дашборде через несколько секунд после получения события: ответ платёжного сервиса, код ошибки и связанные логи уже перед специалистом.
| 02:13:58 | INFO | nginx | GET /catalog/sneakers 200 · 84 ms |
| 02:14:01 | INFO | app | order.create #48213 · 12 490 ₽ |
| 02:14:02 | WARN | payment | callback timeout · retry 1/3 · req=a7f3e1 |
| 02:14:07 | ERROR | payment | status not updated · order=#48213 · req=a7f3e1 |
| 02:14:07 | ERROR | sentry | TypeError in PaymentWebhook.handle · release 2.14.1 |
| 02:14:09 | INFO | crm | push skipped: order not paid · #48213 |
| 02:14:12 | INFO | nginx | GET /cart 200 · 61 ms |
500-е ответы, сбои оплаты, таймауты интеграций, ошибки в браузере — то, что тесты не предусмотрели.
Лог, ошибка в коде и нагрузка на сервер связаны по времени и номеру заказа. Причину ищем минуты, а не часы.
Группируем однотипные ошибки, видим, какая выросла после релиза, и исправляем причину, а не симптом.
Ротация, сроки хранения, маскирование персональных данных и секретов. Логи не забивают диск.
Уровень 4 из 5 · Мониторинг систем и сети
Все подключённые системы регулярно опрашиваются: серверы, базы, очереди, контейнеры и сеть. Собираем метрики в Grafana и Prometheus. Для каждой метрики — свои пороги: предупреждение заранее и критическое состояние. На одном экране видно, где началось замедление и что его вызвало.
Загрузка CPU, нехватка RAM, swap, перезапуски из-за нехватки памяти.
Свободное место и скорость заполнения, задержки чтения и записи, доступные SMART/NVMe-показатели износа.
Доступность сайта снаружи, время ответа, трафик, ошибки соединений, DNS, срок SSL-сертификата.
Медленные запросы и блокировки PostgreSQL, Redis, фоновые задачи, состояние Docker-контейнеров.
Находим, что растёт — логи, загрузки, копии. Настраиваем ротацию, при необходимости расширяем хранилище.
Находим тяжёлый запрос или блокировку, исправляем запрос, индексы или лимиты подключений.
Ищем узкое место: код, кэш, ресурсы или сеть. Оптимизируем и проверяем под нагрузкой.
Проверяем свежесть резервной копии, готовим перенос и замену через провайдера. Метрики снижают риск, но не предсказывают каждый отказ.
Уровень 5 из 5 · Алерты и уведомления
Все сигналы — от тестов, логов и мониторинга — сходятся в одну систему уведомлений. Критические сразу уходят ответственным разработчикам с контекстом. Не подтвердили — уведомление повторяется и уходит следующему по цепочке.
иллюстрация, не SLA
Автотест оплаты не прошёл, в логах — ошибка обработчика банка.
С контекстом: шаг, ответ провайдера, заказ, ссылки на логи.
Обработчик callback откатили к предыдущей версии.
Оплата и передача в CRM снова работают.
Что случилось, что исправили и как не допустить повтора.
Критическое приходит сразу, предупреждения — по согласованному регламенту. Убираем дубли, чтобы важный сигнал не потерялся.
Подтверждение, повтор, эскалация. Сигнал не потеряется, даже если первый адресат спит.
Пропали метрики или остановилась проверка — это тоже тревога. Настройку подтверждаем тестовым инцидентом.
Фиксируем причину и исправление; при повторе меняем код или правило контроля.
24/7 Автоматический контроль работает круглосуточно. Время подключения инженера ночью и в выходные согласуем при подключении проекта.
Пять уровней по отдельности — набор инструментов. Вместе — готовая система сопровождения вашего проекта.Итог · Экосистема →Итог · Экосистема сопровождения
Мы не собираем мониторинг с нуля под каждого клиента. Архитектура уже работает на наших проектах: подключаем к ней ваш сайт, добавляем проверки под ваш бизнес. Пять уровней работают вместе.
Уровни 1–5 работают
не по очереди, а одновременно
и подстраховывают друг друга
↻ цикл повторяется на каждом изменении
Файлы и база по расписанию, хранение отдельно от рабочего сервера. Регулярно проверяем, что из копии действительно можно восстановиться.
Один процесс выпуска, история версий, откат. Любое изменение сначала проходит staging.
Отлаженные конфигурации метрик, логов и алертов адаптируем под стек и добавляем проверки именно ваших заказов и интеграций.
Доступы, репозиторий, дашборды, журнал инцидентов и документация: карта сервисов, инструкции выпуска, отката и восстановления.
Настраиваем резервное копирование PostgreSQL, пользовательских файлов и конфигурации. Для восстановления на момент времени при необходимости используем базовые копии и архивирование WAL. Контролируем возраст копии, ошибки задания и заполнение хранилища.
Проверяем восстановление в изолированном окружении. Согласуем допустимую потерю данных (RPO), целевое время восстановления (RTO) и фиксируем результаты теста. В Docker-образах и репозитории храним конфигурации; секреты отделяем от кода.
Обновление без простоя проектируем через blue-green или rolling deployment там, где позволяет архитектура. Проверяем готовность новой версии и совместимость миграций. Для изменений данных отдельно определяем порядок отката или восстановления.
Доработка ↗
В рамках сопровождения дорабатываем функциональность сайта и интернет-магазина. Каждая доработка проходит те же пять уровней — тест, выпуск, контроль.
Крупные модули оцениваем отдельным этапом.Стоимость ↗
ΣКонтроль бэкапов и тесты восстановления, выпуск через staging и CI/CD, отчёт о работах
Подключение проекта ↗
Инвентаризация серверов, доступов и версий. Проверяем, можно ли восстановить сайт из копии.
Первыми закрываем риски потери данных и недоступности.
Мониторинг, логи, автотесты, алерты. Проверка тестовым инцидентом.
Обновления, разбор инцидентов, развитие и ежемесячный отчёт.
Вопросы и ответы ↗
Расскажите о вашем проекте — уточним, какие проверки и работы нужны в первую очередь.
Обсудить поддержку ↗Да. У нас отработана архитектура сбора метрик и логов, автоматических проверок, уведомлений разработчикам, резервного копирования и выпуска обновлений. Подключаем к ней проект, сопоставляем его сервисы с готовыми проверками, добавляем специфичные сценарии и назначаем ответственных. Состав компонентов и размещение подбираем под инфраструктуру проекта.
Запускаем проверки корзины, оформления, платёжной интеграции, передачи заказа в CRM и уведомлений менеджерам. Дополнительно постоянно контролируем API, очереди, статусы и логи. Если реальная оплата завершилась ошибкой, через несколько секунд после получения события в нашем дашборде появляются ответ платёжного сервиса и связанный контекст. Специалисты получают сигнал и начинают диагностику до обращения клиента; результаты плановых проверок сохраняются в отчётах.
Основные платёжные сценарии проверяем в тестовом контуре провайдера. На рабочем сайте контролируем доступность интеграции, входящие события, статусы заказов и ошибки обмена. Проверку с реальным списанием, физическим терминалом или кассой включаем только в заранее согласованный сценарий: браузерный тест сам по себе не подтверждает работу оборудования.
Для централизованного сбора и анализа логов приложения, веб-сервера, контейнеров и интеграций. Настраиваем потоки, поля, поиск, сроки хранения и события для уведомлений. Graylog помогает связать ошибку с запросом или заказом и найти причину сбоя; нужные события поступают в общую систему реагирования.
Подключаем источники метрик и логов, собираем дашборды для серверов, приложения, базы и очередей. Настраиваем правила алертов, пороги, задержки срабатывания, каналы доставки и эскалацию. Проверяем уведомления тестовым инцидентом. Сбор метрик организуем через Prometheus и подходящие экспортёры; для централизованных логов подключаем Graylog, Loki или имеющуюся систему.
Да. Автоматические проверки работают круглосуточно, а критические сообщения поступают напрямую разработчикам в Telegram, почту или другой рабочий канал. Мы получаем контекст сбоя и начинаем реагировать по аварийному регламенту, не дожидаясь звонка клиента. Настраиваем подтверждение, повтор и эскалацию; время реакции и ночное дежурство фиксируем при подключении проекта.
Настраиваем предупреждения о заполнении диска и inode, ошибках и задержках I/O. Если доступны данные накопителя, отслеживаем SMART/NVMe-показатели состояния и износа. На VPS физический накопитель может быть недоступен для диагностики. Не каждый отказ имеет предварительные признаки, поэтому одновременно нужны отдельные копии и проверенный план восстановления.
Сопоставляем время ответа и ошибки сайта с нагрузкой на процессор, память, диск и сеть. Проверяем медленные запросы и блокировки в базе, очереди, логи приложения и внешние API. После определения причины меняем конкретный участок кода, запрос, настройку или ресурс и повторяем замеры.
Метрики показывают, когда и где изменились нагрузка, время ответа или число ошибок. Все поступающие логи подключённых компонентов автоматически анализируются: правила выявляют исключения, ошибки запросов и сбои интеграций. Записи связываются по времени, сервису и идентификатору запроса, чтобы специалист видел последовательность событий и мог установить причину. Задаём срок хранения и маскирование чувствительных данных.
Да, включаем тест восстановления в согласованный план. Разворачиваем базу и файлы в отдельном окружении, проверяем данные и запуск приложения, фиксируем длительность и результат. Алерты проверяют также ошибки задания, возраст последней копии и состояние хранилища.
Да, если приложение и инфраструктура поддерживают такую схему. Настраиваем проверку готовности новой версии и переключение трафика, согласуем обработку фоновых задач и совместимость миграций базы. Для изменений, требующих остановки или необратимого преобразования данных, заранее готовим отдельный план.
Сборка приложения или Docker-образа, автоматические тесты, проверки зависимостей, публикация на тестовый стенд, согласование выпуска и выкладка на production. После релиза проверяем ключевые сценарии и метрики. Фиксируем секреты, права выпуска и порядок отката; состав проверок подбираем под стек проекта.
Проверяем, затрагивает ли уязвимость используемую версию и конфигурацию. Определяем срочность, обновляем зависимости, образы или пакеты, тестируем и выпускаем исправление. При критическом риске используем согласованный аварийный порядок; результат и оставшиеся ограничения документируем.
Да. Изучаем код, серверы и способ развёртывания, проверяем доступы, копии и текущие ошибки. После диагностики предлагаем план подключения мониторинга, восстановления и релизов. Готовое ТЗ для первого разговора не требуется.
Регулярное сопровождение — от 12 000 ₽/мес. После диагностики согласуем системы, проверки, обновления, задачи и время команды. Первичное внедрение мониторинга, CI/CD, staging и схемы резервного копирования оцениваем по текущему состоянию инфраструктуры. Условия аварийного реагирования и расходы на серверы и хранилища фиксируем отдельно.
Да. Передаём конфигурации мониторинга и CI/CD, карту сервисов, инструкции выпуска, отката и восстановления. Репозитории и сервисные учётные записи оформляем с согласованным доступом заказчика. По выполненным работам показываем задачи, изменения и результаты проверок.
Обсудим вашу задачу ↗
Расскажите, что за проект и что беспокоит. Начнём с аудита: покажем, что устарело, где риски и какие уровни защиты нужны в первую очередь. Готового ТЗ не нужно — достаточно описать задачу своими словами.
Казанская улица, 7, офис 7
Подключаемся к проектам удалённо
Напишите напрямую — обсудим вашу задачу