Регламент мониторинга сайтов клиентов для веб-студии

3 августа 2026 · 13 мин чтения

Регламент мониторинга — это не список URL и не обещание «следим за сайтом круглосуточно».

Это короткая договорённость о том, какие события считаются проблемой, кто получает сигнал, что должен проверить специалист, когда уведомлять клиента и каким результатом закрывается инцидент.

Без этих правил мониторинг быстро превращается в один из двух сценариев:

• система присылает десятки сообщений, команда перестаёт их читать;
• проверяется только главная страница, а сломанные заявки и заказы первым замечает клиент.

Ниже — практическая модель для российской веб-студии. Её можно применять к одному магазину или к портфелю из десятков проектов.

Коротко: из чего состоит рабочий регламент

1. Каталог сайтов и ответственных.
2. Критические пользовательские и бизнес-функции.
3. Уровни серьёзности и понятные примеры.
4. Проверки по внешнему и внутреннему контуру.
5. Правила подтверждения, группировки и подавления шума.
6. Каналы уведомлений и сроки эскалации.
7. Технические окна.
8. Критерии восстановления и закрытия.
9. Ежемесячный пересмотр покрытия.

Начните с цели, а не с инструментов

Фраза «контролировать работоспособность сайта» слишком расплывчата. У каждого типа проекта собственная работоспособность.

Для лендинга результат — доставленная заявка. Для магазина — созданный заказ и доступная оплата. Для личного кабинета — успешный вход. Для сайта с 1С — актуальные цены и остатки. Для корпоративного портала — доступность сотрудников из нужной сети.

Поэтому первая строка регламента должна отвечать на вопрос:

Какое пользовательское или бизнес-событие мы защищаем?

Пример:

Цель мониторинга интернет-магазина — обнаруживать недоступность сайта, нарушение оформления заказа, риск истечения домена и SSL, остановку обмена с 1С и критическое состояние сервера до массовых обращений покупателей.

Шаг 1. Создайте каталог наблюдаемых объектов

Для каждого клиента нужна одна карточка.

Поле	Пример
Клиент	ООО «Северный магазин»
Основной сайт	https://shop.example.ru
Назначение	Интернет-магазин
Владелец бизнеса	Коммерческий директор
Ответственный студии	Руководитель поддержки
Техническая эскалация	Дежурный разработчик
Рабочее время	09:00–19:00 МСК
Аварийный режим	24×7 для P1
Основные зависимости	Хостинг, DNS, 1С, оплата, доставка, почта
Статус-страница	status.example.ru / не настроена
Каналы	Telegram + email

Если объект не имеет владельца, его алерт не имеет адресата.

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

Шаг 2. Определите критические функции

Не ставьте одинаковое количество проверок на все страницы. Сначала перечислите функции, потеря которых влияет на деньги, обязательства или доверие.

Пример для интернет-магазина

1. Главная и каталог доступны.
2. Карточка товара показывает цену и остаток.
3. Товар добавляется в корзину.
4. Страница оформления загружается без серверной ошибки.
5. Заказ создаётся в CMS.
6. Боевой платёжный способ не находится в тестовом режиме.
7. Менеджер получает сведения о заказе.
8. Обмен с 1С завершается по расписанию.

Пример для сайта услуг

1. Основная посадочная страница доступна.
2. Телефон и контактные данные не изменились.
3. Форма принимает тестовую заявку.
4. Письмо или лид доходит до согласованного получателя.
5. Страница не закрыта от поисковых систем.
6. Посетителя не перенаправляет на неожиданный домен.

Сайт может отвечать 200 OK и одновременно не выполнять половину этого списка.

Шаг 3. Введите три уровня серьёзности

Для небольшой студии обычно достаточно трёх уровней. Чем сложнее классификация, тем чаще сотрудники спорят о номере вместо восстановления.

Уровень	Пользовательское влияние	Примеры	Реакция
P1 — критично	Критическая функция недоступна многим пользователям или есть активный риск безопасности	Сайт не открывается, checkout сломан, вредоносный редирект, боевой шлюз в тестовом режиме	Немедленное подтверждение, дежурный, клиент и статус-страница по регламенту
P2 — существенно	Часть функций нарушена, обходной путь существует, ущерб ограничен	Не работает одна форма, региональная проблема, высокая доля ошибок, повторяющийся сбой обмена	Реакция в согласованное время, назначение владельца, клиенту — по влиянию
P3 — предупреждение	Пользователи пока не затронуты, но есть срок или растущий риск	SSL через 21 день, домен через 30 дней, диск 80 %, устаревший модуль	Задача с владельцем и сроком, без аварийного вызова

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

Шаг 4. Постройте проверки слоями

Слой 1. Внешняя доступность

Показывает то, что видит посетитель без доступа к серверу:

• HTTP/HTTPS;
• ожидаемый код ответа;
• время ответа;
• содержимое или обязательный элемент страницы;
• редиректы и конечный домен;
• доступность из нескольких регионов;
• DNS;
• SSL и срок домена.

Внешняя проверка должна работать независимо от CMS и хостинга клиента. Иначе авария сервера отключит одновременно сайт и его наблюдение.

Слой 2. Бизнес-функции

Отвечает не «открылась ли страница», а «выполнена ли работа»:

• форма действительно доставила тестовое сообщение;
• страница оформления существует;
• серверный конвейер заказа не сломан;
• платёжный способ находится в правильном режиме;
• заказ появился в системе;
• обмен обновил данные;
• фоновая задача завершилась вовремя.

Не все пути можно безопасно проверять реальной покупкой. Используйте служебные сущности и учитывайте ограничения конкретной CMS и платёжной системы.

Слой 3. CMS и приложение изнутри

Может показывать:

• версии ядра и модулей;
• ошибки встроенной диагностики;
• состояние очередей;
• поток заказов;
• конфигурацию платёжных способов;
• результат отправки почты;
• известные уязвимости;
• состояние критических фоновых механизмов.

Этот слой дополняет внешнюю проверку, но не заменяет её. CMS может считать себя исправной, пока сайт недоступен снаружи.

Слой 4. Сервер

Нужен для ответа на вопрос, не исчерпаны ли ресурсы:

• процессор;
• память и своп;
• заполнение и нагрузка диска;
• общая нагрузка;
• контейнеры или службы, если это входит в архитектуру.

Серверные графики помогают направить расследование, но сами по себе не доказывают работоспособность заявки или заказа.

Слой 5. Фоновые задачи

Для бэкапов, обменов, импортов и очередей часто нет внешнего URL. Задача сама должна сообщать об успешном завершении, а мониторинг — считать событием отсутствие ожидаемого сигнала.

Контролируйте:

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

Подробнее эта модель разобрана в статье Pingvera о мониторинге cron и бэкапов.

Шаг 5. Подтверждайте сбой до эскалации

Один неудачный запрос может означать краткий сетевой сбой между точкой проверки и сайтом. Но слишком долгое подтверждение увеличивает ущерб реальной аварии.

Используйте комбинацию:

• повторной попытки через короткий интервал;
• второй региональной точки;
• нескольких последовательных ошибок;
• проверки ожидаемого содержимого;
• свежего соединения без старого кэша;
• сравнения внешнего и внутреннего сигнала.

Окно зависит от риска:

• checkout и заявка подтверждаются быстрее;
• краткое замедление некритичной страницы может ждать дольше;
• срок SSL не требует ночного звонка;
• неожиданный редирект на чужой домен требует срочной проверки.

Руководство Prometheus рекомендует оповещать о симптомах пользовательской проблемы и не вызывать человека по событию, с которым он не может ничего сделать. Этот принцип одинаково полезен для большой SRE-команды и студии из трёх человек.

Шаг 6. Группируйте зависимые события

Если упал общий сервер, одновременно могут перестать отвечать:

• главная;
• форма;
• административная панель;
• CMS-модуль;
• несколько клиентских сайтов.

Без группировки одна авария создаст десятки сообщений.

В каталоге укажите зависимости:

Сервер A
├── Сайт клиента 1
│   ├── Главная
│   └── Форма
├── Сайт клиента 2
│   └── Checkout
└── Агент серверных метрик

Когда подтверждён отказ родительского объекта, дочерние проверки сохраняют доказательства, но не должны каждая создавать отдельный ночной звонок.

Шаг 7. Разведите каналы по срочности

P1

• рабочий Telegram-канал инцидентов;
• push или телефон дежурного, если это входит в договор;
• резервный канал email;
• автоматическая эскалация, если никто не подтвердил получение.

P2

• очередь поддержки или отдельная тема Telegram;
• назначенный владелец;
• напоминание до согласованного срока.

P3

• панель рисков;
• задача в Helpdesk;
• еженедельный дайджест;
• клиентский отчёт.

Не полагайтесь на один канал. Telegram, почта и мобильная сеть отказывают по разным причинам. При этом доставка сообщения не доказывает, что человек его прочитал — для критических событий нужен механизм подтверждения или повторной эскалации.

Шаг 8. Установите порядок эскалации

Пример для небольшой студии:

Время после подтверждения	Действие
0 минут	Событие получает дежурный
5 минут без подтверждения	Уведомляется резервный специалист
10 минут	Подключается руководитель поддержки
15 минут для P1	Клиент получает первое фактическое сообщение
По согласованному интервалу	Обновляется статус и следующая контрольная точка

Это не универсальный SLA. Для каждого договора укажите рабочее время, ночной режим, выходные и исключения.

Отдельно различайте:

• время обнаружения — когда система впервые увидела симптом;
• время подтверждения — когда сбой прошёл проверку;
• время реакции — когда ответственный принял событие;
• время восстановления — когда функция снова заработала;
• время подтверждения восстановления — когда контрольные проверки прошли.

Шаг 9. Планируйте технические окна

Плановая работа не должна создавать ложный публичный инцидент.

У технического окна должны быть:

• список сайтов и проверок;
• начало и обязательный конец;
• ответственный;
• причина;
• ожидаемое пользовательское влияние;
• уведомление клиента;
• контроль после завершения.

Окно должно подавлять уведомления, но не стирать данные. Если после окончания сайт остаётся недоступен, мониторинг обязан открыть событие.

Бессрочная кнопка «поставить на паузу» опасна: так проверки забывают выключенными на месяцы.

Шаг 10. Определите критерии закрытия

Инцидент не закрывается в момент, когда разработчик нажал Enter или перезапустил службу.

Минимальные критерии:

1. исходный пользовательский симптом исчез;
2. повторная проверка прошла из нужных точек;
3. критическая бизнес-функция подтверждена;
4. связанные проверки не показывают новый отказ;
5. клиент получил итоговое сообщение, если был уведомлён об открытии;
6. усиленное наблюдение назначено, если риск повторения остаётся.

Для магазина «страница снова открывается» недостаточно. Нужно убедиться, что checkout, создание заказа и необходимые интеграции действительно восстановились.

Шаг 11. Пересматривайте систему раз в месяц

Ежемесячный обзор должен отвечать:

• какие алерты были полезны;
• какие оказались ложными или не требовали действия;
• какие проблемы первым сообщил клиент;
• у каких проверок нет владельца;
• какие сайты изменились без обновления мониторинга;
• какие технические окна остались открыты;
• где заканчивается SSL или домен;
• какие бизнес-функции пока не проверяются;
• какие повторяющиеся события требуют системного исправления.

Итог обзора — не только график uptime, а изменение правил: добавить проверку, убрать шум, назначить владельца или пересмотреть порог.

Копируемый шаблон регламента

# Регламент мониторинга сайта [название]

Версия: [номер]
Дата: [дата]
Владелец документа: [роль]

## 1. Цель

Обнаруживать [перечень пользовательских и бизнес-проблем] до массовых обращений пользователей и обеспечивать понятную эскалацию.

## 2. Объекты

- Основной сайт: [URL]
- Критические страницы: [список]
- Бизнес-функции: [форма / заказ / оплата / вход]
- Интеграции: [1С / CRM / почта / доставка]
- Инфраструктура: [сервер / DNS / домен / SSL]

## 3. Ответственные

- Владелец со стороны клиента: [роль и контакт]
- Ответственный студии: [роль и контакт]
- Дежурный: [график]
- Резервная эскалация: [роль]

## 4. Уровни

- P1: [критерии и примеры]
- P2: [критерии и примеры]
- P3: [критерии и примеры]

## 5. Правила подтверждения

- Число повторов: [значение]
- Региональное подтверждение: [да / нет]
- Допустимая задержка: [по типам проверки]
- Группировка зависимостей: [правила]

## 6. Каналы и эскалация

- P1: [канал, подтверждение, резерв]
- P2: [канал и срок]
- P3: [очередь / отчёт]
- Нет подтверждения за [N] минут: [следующее действие]

## 7. Коммуникация с клиентом

- Первое сообщение: [условие и срок]
- Основной источник статуса: [URL / канал]
- Частота обновлений: [интервал]
- Ответственный за текст: [роль]

## 8. Технические окна

- Кто создаёт: [роль]
- Максимальная длительность: [значение]
- Проверка после завершения: [список]

## 9. Закрытие

Событие закрывается после [пользовательская проверка], [региональное подтверждение] и [сообщение клиенту].

## 10. Пересмотр

Регламент проверяется [раз в месяц / квартал] и после каждого P1.

Пример: магазин на 1С-Битрикс

P1

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

P2

• обмен с 1С не завершился после установленного допуска;
• резко выросла доля неоплаченных заказов;
• сайт недоступен только в одном важном регионе;
• почтовые уведомления о заказах не подтверждаются.

P3

• домен заканчивается через 30 дней;
• SSL заканчивается через 21 день;
• диск устойчиво приближается к порогу;
• встроенная диагностика показывает некритичное предупреждение.

Критерий восстановления P1 checkout

• страница оформления открывается;
• тестовый служебный заказ создаётся по согласованной процедуре;
• сумма и доставка рассчитываются;
• заказ виден менеджеру;
• внешняя и внутренняя проверки возвращаются в норму;
• продолжается усиленное наблюдение.

Типичные ошибки

Проверять только главную

Главная обычно самая закэшированная и самая простая страница. Она может работать, пока оформление, форма или личный кабинет сломаны.

Отправлять всё в один чат

Критический сбой смешивается с предупреждением об SSL и информацией о завершённом обслуживании. Через месяц команда перестаёт замечать важное.

Публиковать каждый единичный сбой

Неподтверждённый сетевой чих не должен автоматически становиться публичной аварией. Сначала определите правила подтверждения.

Использовать одинаковые пороги для всех клиентов

Пятиминутная недоступность checkout во время рекламной кампании и пятиминутная недоступность архивного сайта имеют разное влияние.

Считать изменение исправлением

Изменение конфигурации — действие. Исправление подтверждается только восстановленной пользовательской функцией.

Как реализовать регламент в Pingvera

Pingvera может закрыть техническую часть процесса:

• внешние проверки и региональное подтверждение;
• контроль SSL, домена, редиректов и поисковых ограничений;
• проверку форм и внутренних сигналов CMS;
• heartbeat фоновых задач;
• серверные метрики;
• единые события и каналы Telegram, email, MAX, webhook;
• статус-страницу;
• зафиксированный клиентский отчёт.

Серьёзность, владельцы, сроки реакции и порядок общения остаются управленческим решением студии.

Не начинайте со ста проверок. Выберите пять функций, потеря которых действительно ударит по клиенту, назначьте владельцев и настройте для них понятную эскалацию. Создать проверки в Pingvera.

Часто задаваемые вопросы

Нужно ли подписывать регламент с каждым клиентом?

Внутренний регламент студии можно использовать как основу. Условия, влияющие на обязательства сторон — покрытие, рабочее время, сроки реакции и исключения — лучше закрепить в договоре или приложении. Формулировки должен проверить юрист.

Какой интервал проверки выбрать?

Интервал зависит от возможного ущерба. Критические функции проверяют чаще, административные сроки — реже. Учитывайте также стоимость проверки, ограничения интеграции и риск создания побочных данных.

Нужно ли уведомлять клиента о каждом P2?

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

Можно ли считать Telegram единственным аварийным каналом?

Для некритичных проектов — если это осознанно согласовано. Для P1 лучше иметь независимый резерв и механизм эскалации, потому что доставка сообщения не гарантирует его прочтение.

Что делать с сайтом, для которого нельзя проверить заказ автоматически?

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

Главное

Хороший регламент мониторинга связывает технический сигнал с действием человека.

Он заранее отвечает: что защищаем, как подтверждаем, кого зовём, когда сообщаем клиенту и чем доказываем восстановление. Тогда мониторинг перестаёт быть стеной зелёных и красных точек и становится частью услуги поддержки.

Когда число проектов растёт, единичный регламент превращается в профили по классам, реестр исключений и формальное дежурство. Эта модель разобрана в руководстве о поддержке 10, 50 и 100 клиентских сайтов.

Источники и дополнительное чтение

• Prometheus: рекомендации по проектированию алертов
• Atlassian Incident Management Handbook
• Atlassian: лучшие практики реагирования на инциденты
• Pingvera: мониторинг фоновых задач
• Pingvera: мониторинг магазина изнутри
• Pingvera: статус-страница и доверие

Следующий материал: «Регламент действий веб-студии при падении сайта».

Читайте также: Перехватывают клиентов с сайта: как узнать и что делать · Что делать, если сайт клиента упал: регламент · Blameless postmortem для веб-студии: шаблон · API управления мониторингом: заводим сайты клиентов без рук в дашборде · Бесплатно проверить сайт.