После запуска сайта у бизнеса часто появляется опасная иллюзия: «сайт готов, теперь он просто работает». На практике коммерческий сайт больше похож не на буклет, а на производственную систему. Он принимает заявки, обрабатывает формы, собирает аналитику, участвует в рекламе, ранжируется в поиске, хранит данные, интегрируется с CRM, платежами, телефонией, рассылками и сервисами аналитики. У такой системы есть не только дизайн и контент, но и операционная жизнь: обновления, сбои, уязвимости, нагрузка, человеческие ошибки, изменения API и регулярные мелкие доработки.
Именно здесь начинается зона технической поддержки сайта. Но поддержка бывает двух типов. Первый тип — реактивный: «напишите, если что-то сломается». Второй — управляемый: есть мониторинг, регламент реакции, приоритеты, журнал задач, ответственные, бэкапы, обновления, контроль безопасности, отчетность и понятные границы ответственности. Второй тип и называется нормальным SLA: service level agreement, соглашение об уровне сервиса.[2]
Проблема в том, что слово SLA часто используют как декоративную фразу в коммерческом предложении. В договоре написано «техническая поддержка сайта», но не указано, что считается аварией, в какие часы идет реакция, как быстро устраняется критичная проблема, кто принимает решение о временном отключении модуля, где лежит резервная копия, кто следит за security advisories, входит ли обновление CMS, что происходит при взломе и как бизнес получает отчет. Такой SLA не управляет риском. Он только создает ощущение порядка.
Почему SLA — это не бюрократия, а защита выручки
Нормальный SLA нужен не для того, чтобы «юридически наказать подрядчика». Его главная функция — убрать неопределенность в момент, когда сайт перестает работать как бизнес-инструмент. В спокойном режиме все согласны, что формы важны, безопасность важна, скорость важна, обновления нужны, резервные копии должны быть. Но когда в 10:20 утра перестали приходить заявки из рекламы, начинается хаос: менеджер пишет в чат, маркетолог обвиняет сайт, разработчик просит доступы, владелец хочет «починить срочно», а никто не знает, кто именно должен принимать решение и что считать успешным восстановлением.
SLA превращает такой хаос в заранее согласованный процесс. В нем должно быть написано, какие сервисы поддерживаются, какие метрики считаются критичными, как классифицируется инцидент, за сколько исполнитель подтверждает обращение, какие сроки восстановления применяются к разным приоритетам, как часто отправляются обновления, какие каналы связи считаются официальными и что происходит после устранения проблемы. Atlassian в своем объяснении SLA подчеркивает именно эту роль: соглашение задает ожидания, время реакции/решения и способ измерения качества сервиса.[2]
Для коммерческого сайта это напрямую связано с выручкой. Если сайт лежит, реклама продолжает списывать бюджет, SEO-трафик упирается в ошибку, менеджеры не получают лиды, а пользователь уходит к конкуренту. Если сайт работает, но медленно, ломается форма, не передается UTM-метка или не отправляется письмо, ущерб менее заметен, но часто больше: проблема может жить неделями, потому что «ничего же не упало». Поэтому SLA должен закрывать не только полный простой, но и деградацию ключевых сценариев: заявки, корзина, оплата, регистрация, поиск по сайту, страницы услуг, аналитика, индексация и скорость загрузки.
Главная мысль
SLA по поддержке сайта должен отвечать не на вопрос «когда разработчик свободен?», а на вопрос «какой бизнес-риск мы закрываем и как быстро возвращаем критичный сценарий в рабочее состояние?»
Хорошая поддержка всегда работает на стыке разработки, администрирования, безопасности, аналитики и бизнес-процессов. Если подрядчик видит только код, он может починить ошибку, но не заметить, что заявки неделю не попадают в CRM. Если видит только хостинг, он может восстановить сервер, но не понять, что после обновления сломалась микроразметка или исчезли важные SEO-страницы. Если видит только дизайн, он может «поправить кнопку», но не проверить, что цель в аналитике больше не срабатывает. SLA должен связать эти зоны в одну операционную систему.
SLA, SLO, SLI: что это значит простыми словами
В профессиональной поддержке часто используют три близких термина: SLA, SLO и SLI. Их важно разделять, потому что без этого договор превращается в набор красивых обещаний. Google SRE описывает эту логику как систему измерений: сначала нужно понять, какие свойства сервиса важны пользователю, затем определить показатели, целевые значения и последствия, если сервис не соответствует ожиданиям.[1]
SLI
метрика
SLO
цель
SLA
соглашение
Runbook
процесс
Для владельца сайта эти термины можно перевести совсем просто. SLI — что измеряем. SLO — какого значения хотим. SLA — что обещаем клиенту и как действуем, если обещание не выполнено. Если в поддержке нет SLI и SLO, SLA невозможно проверить. Если есть SLI и SLO, но нет SLA, бизнес не понимает, что ему гарантируют. Если есть SLA без процесса, он не работает в реальном инциденте.
Критичность P1–P4: как делить обращения
Самая частая ошибка в поддержке — все обращения считаются одинаковыми. «Не работает сайт», «поменять телефон в футере», «посмотреть, почему упала конверсия», «добавить баннер», «ошибка 500 после релиза», «не приходит заявка из формы» — все это летит в один чат. В результате срочные задачи спорят с несрочными, бизнес не понимает очередность, а исполнитель защищается фразой «мы работаем по порядку поступления».
Нормальный SLA должен разделять обращения по критичности. Ниже — не универсальный стандарт для всех проектов, а рабочая модель, которую адаптируют под конкретный сайт, часы работы бизнеса, рекламную активность, сезонность, стоимость простоя и доступный бюджет поддержки.
Пример матрицы приоритетов для коммерческого сайта
P1
Критичная авария
Сайт недоступен, массовые 5xx, не работает отправка заявок, сломан платеж, активный взлом, критичный security incident. Пример реакции: до 15 минут, обновления статуса каждые 30–60 минут, цель — быстрое восстановление критичного сценария.
P2
Высокий риск
Часть сайта работает неправильно: сбой CRM-интеграции, ошибки в корзине у части пользователей, важное security advisory, резкое падение скорости, проблема после релиза. Пример реакции: до 1 часа в рабочее время или по расширенному окну.
P3
Плановая ошибка
Некритичный баг, визуальная проблема, ошибка в контентном блоке, мелкая проблема на одной странице, не влияющая на заявки и оплату. Пример реакции: 4–8 рабочих часов, исправление по согласованному плану.
P4
Запрос на изменение
Новая функция, консультация, изменение структуры, баннер, посадочная, отчет, улучшение UX. Это не инцидент, а backlog. Пример реакции: следующий рабочий день, оценка и планирование в отдельный слот.
Такая классификация полезна только при одном условии: критерии должны быть понятны до инцидента. Если P1 определяется эмоционально — «нам очень срочно» — SLA ломается. Если P1 определяется через бизнес-сценарий — «заявки не отправляются на всех формах», «оплата невозможна», «сайт отдает 500 на главной и ключевых посадочных», — поддержка может действовать быстро и без споров.
Важно для договора
Для каждого приоритета нужно отдельно зафиксировать: время первой реакции, время начала работ, целевое время workaround, целевое время полного решения, канал связи, календарь учета времени и обязанности клиента по предоставлению доступов/подтверждений.
Что должно входить в нормальный SLA
Если SLA по технической поддержке сайта написан правильно, он описывает не только скорость ответа, но и состав поддерживаемой системы. Для сайта это особенно важно: проблема может быть не в коде, а в DNS, SSL, сервере, базе данных, модуле CMS, стороннем API, CRM, почтовой доставке, аналитике, контентной операции или рекламной посадочной странице. Поэтому нормальный SLA должен явно перечислять, что входит в зону ответственности, а что требует отдельной договоренности.
Минимальный рабочий состав SLA для коммерческого сайта выглядит так:
Периметр поддержки
Домены, хостинг/VPS, CMS, тема, модули, интеграции, формы, почта, аналитика, Search Console, рекламные посадочные, бэкапы и доступы. Без периметра невозможно понять, где заканчивается ответственность подрядчика.
Каналы и календарь
Где создаются обращения: helpdesk, email, CRM, Telegram как уведомление, но не как единственный журнал. В какие часы идет поддержка: 5×8, 5×12, 7×12, 24×7 для P1 или отдельный on-call.
Приоритеты и таймеры
P1–P4, response time, start time, workaround time, resolution target. Atlassian описывает SLA именно как набор time-based targets и правил для обработки обращений.[2]
Мониторинг доступности
Проверка uptime, HTTP-статусов, SSL, домена, диска, CPU/RAM, ошибок 5xx, очередей, cron, успешности отправки форм и базовых пользовательских сценариев. Мониторинг должен обнаруживать часть проблем раньше клиента.
Резервное копирование
Частота бэкапов, что именно сохраняется, где хранятся копии, срок хранения, шифрование, контроль успешности, регулярный тест восстановления. Бэкап без проверки восстановления — это надежда, а не процесс.
Обновления и патчи
Регламент обновлений CMS, модулей, библиотек и сервера. NIST рассматривает patch management как preventive maintenance: регулярный процесс идентификации, приоритизации, установки и проверки обновлений.[4]
Безопасность
Контроль уязвимостей, security advisories, права пользователей, 2FA, журналы, WAF/фаервол, антивирусные проверки, реакция на компрометацию. OWASP Top 10 отдельно выделяет уязвимые и устаревшие компоненты как ключевой риск веб-приложений.[6]
Отчетность и улучшения
Ежемесячный отчет: обращения, инциденты, время реакции, обновления, бэкапы, uptime, риски, рекомендации, план работ. Без отчета поддержка превращается в невидимую статью расходов.
Для Drupal-сайтов отдельным пунктом нужно прописывать работу с security advisories. На Drupal.org есть официальный раздел security advisories, где публикуются уведомления по ядру, contrib-модулям и публичные объявления безопасности.[7] Если сайт сделан на Drupal, WordPress, Laravel, Symfony или другой распространенной системе, SLA должен отвечать на практический вопрос: кто отслеживает эти уведомления, как быстро оценивает применимость, как тестирует обновление и как выпускает его в production.
Также в SLA стоит отдельно зафиксировать процесс релизов. Даже маленькое изменение на сайте может сломать форму, кеш, микроразметку, стили мобильной версии, интеграцию с CRM или tracking. Поэтому нормальная поддержка не выкатывает изменения «прямо на продакшен из админки», если сайт является источником лидов. Должны быть staging-среда, резервная копия перед релизом, проверка критичных сценариев, понятный rollback plan и журнал изменений.
Что техподдержка не должна обещать
Парадоксально, но слишком красивые обещания в SLA часто опаснее скромных. Если подрядчик обещает «мгновенную реакцию», «100% uptime», «исправление любых ошибок за 1 час» и «полную защиту от взлома», это не профессионализм, а отсутствие инженерной честности. В поддержке сайта есть зоны, которые исполнитель контролирует полностью, частично или не контролирует вообще.
Плохой SLA
Обещает невозможное
«Сайт всегда работает», «любой инцидент исправляем за час», «взлом невозможен», «все обновления без риска», «мы отвечаем в любом канале», «клиенту ничего не нужно делать». Такие формулировки создают конфликт сразу после первой серьезной аварии.
Нормальный SLA
Описывает управляемый процесс
«Мониторинг каждые N минут», «P1 — реакция до 15 минут», «workaround приоритетнее идеального исправления», «критичные обновления проходят staging», «статус каждые 30–60 минут», «после major incident — post-incident review».
Например, подрядчик может отвечать за обновления CMS, но не может гарантировать, что сторонний модуль никогда не получит уязвимость. Может отвечать за мониторинг uptime, но не может отвечать за сбой у регистратора домена, если домен зарегистрирован на клиента и доступы не переданы. Может восстановить сайт из бэкапа, но не может восстановить заявки, которые не были сохранены из-за выключенной CRM на стороне клиента. Может поддерживать Core Web Vitals, но не может гарантировать зеленую зону после того, как маркетинг самостоятельно вставил пять тяжелых сторонних скриптов.
Поэтому хороший SLA должен включать исключения. Не мелким шрифтом «исполнитель ни за что не отвечает», а нормальным операционным языком: плановые работы, форс-мажор, сбои сторонних сервисов, отсутствие доступов, просроченные согласования, самостоятельные изменения клиента, устаревшее ПО, отказ от рекомендованных обновлений, неоплаченный хостинг, проблемы на стороне рекламных/CRM/почтовых платформ. Это не попытка снять ответственность, а способ сделать ответственность точной.
Красный флаг
Если в SLA есть только «время реакции», но нет мониторинга, бэкапов, security process, приоритетов, исключений и отчетности, это не SLA технической поддержки сайта. Это тариф на переписку.
Response time и resolution time — не одно и то же
В договорах поддержки часто путают два принципиально разных времени: response time и resolution time. Response time — это когда поддержка подтвердила обращение, квалифицировала его и начала процесс. Resolution time — когда проблема полностью устранена. Между ними может быть workaround: временное решение, которое возвращает бизнес-сценарий в работу, но не устраняет первопричину.
Например, после обновления перестала работать отправка заявки из формы. Response time — специалист ответил, проверил проблему, подтвердил P1/P2 и начал диагностику. Workaround — временно переключил форму на резервную отправку через email или отключил проблемную интеграцию, чтобы заявки снова попадали менеджеру. Resolution — исправил интеграцию, протестировал CRM, восстановил нормальный маршрут заявки, обновил документацию и закрыл инцидент. Для бизнеса важны все три стадии, но особенно важно понимать, что «нам ответили» не равно «проблема решена».
| Параметр | Что означает | Как должно быть в SLA |
|---|---|---|
| Response time | Время до подтверждения обращения и первичной квалификации. | Фиксируется по P1–P4, с календарем учета времени и официальным каналом обращения. |
| Start time | Когда специалист реально начал диагностику или работы. | Для P1/P2 полезно отделять от обычного ответа, чтобы «мы приняли» не заменяло работу. |
| Workaround time | Срок до временного восстановления бизнес-сценария. | Особенно важно для заявок, оплаты, телефонии, CRM и рекламных посадочных. |
| Resolution target | Целевое время полного устранения причины. | Не всегда можно гарантировать жестко: зависит от сторонних сервисов, глубины дефекта, доступов и согласований. |
| Status update | Как часто клиент получает понятное обновление. | Для P1 — каждые 30–60 минут или после значимого изменения статуса. |
| Post-incident review | Разбор после крупного инцидента. | Фиксируются причина, действия, время, предотвращающие меры и владелец улучшений. Atlassian относит PIR к важным практикам incident lifecycle.[3] |
Для серьезного сайта лучше использовать не один общий срок «реакция 24 часа», а несколько целей. P1 требует быстрого ответа и начала работ. P4 может ждать планирования. Security update может быть срочным даже без видимого сбоя. Запрос на новый блок не должен вытеснять аварийное восстановление заявок. Такой подход делает поддержку честной: бизнес понимает, за что платит, а команда не тратит аварийный ресурс на косметические изменения.
Поддержка «по запросу» против SLA
Поддержка «по запросу» не всегда плохая. Она может быть нормальной для сайта-визитки, лендинга без рекламы, проекта без регулярных изменений или бизнеса, где простой сайта не критичен. Проблема начинается, когда такой формат используют для сайта, который уже зависит от трафика, SEO, рекламных кампаний, CRM-интеграций, заявок, платежей и сезонных продаж.
| Критерий | Поддержка по запросу | Нормальный SLA |
|---|---|---|
| Обнаружение проблем | Клиент сам замечает сбой или узнает от пользователей. | Мониторинг uptime, ошибок, SSL, диска, cron, форм и ключевых сценариев. |
| Приоритеты | Все задачи идут в общий чат и конкурируют эмоционально. | Есть P1–P4, критерии, таймеры, эскалация и правила остановки плановых работ. |
| Бэкапы | «Хостинг вроде делает», никто регулярно не проверяет восстановление. | Частота, хранение, контроль успешности, тест restore и план восстановления прописаны. |
| Обновления CMS | Ставятся нерегулярно, часто только после проблемы. | Есть план patch management, приоритизация security updates и тестирование перед production.[4] |
| Безопасность | Реакция начинается после взлома или жалобы. | Права, обновления, advisories, логи, контроль уязвимостей и incident response. |
| Релизы | Изменения часто делаются сразу на рабочем сайте. | Staging, резервная копия, чек-лист, окно релиза, rollback. |
| Скорость сайта | Оптимизация «когда станет совсем медленно». | Периодический контроль Core Web Vitals: LCP, INP, CLS и ключевых шаблонов.[9] |
| Аналитика заявок | Отсутствие лидов замечают менеджеры постфактум. | Проверяются формы, цели, события, CRM-цепочка, email-доставка и UTM-передача. |
| Коммуникация | Переписка в разных чатах, нет единого журнала. | Helpdesk или трекер, статусы, ответственные, история решений. |
| Отчетность | Непонятно, что сделано за месяц и какие риски остаются. | Отчет по инцидентам, обновлениям, uptime, задачам, рискам и рекомендациям. |
| Ответственность клиента | Не прописана: доступы, согласования, контент, сторонние сервисы. | Есть список обязанностей клиента и исключения из SLA. |
| Итог | Дешевле в спокойные месяцы, дороже в аварии. | Дороже как процесс, но снижает простой, хаос, security risk и потерю заявок. |
Если сайт уже участвует в маркетинге, поддержка по запросу обычно оказывается ложной экономией. Деньги экономятся только до первого серьезного инцидента. Потом выясняется, что доступы устарели, бэкап неполный, разработчик занят другим проектом, логов не хватает, обновление нельзя поставить без теста, а восстановление заняло не час, а день.
Экономика SLA: сколько стоит простой сайта
SLA кажется расходом, пока бизнес не считает цену простоя. Правильнее сравнивать стоимость поддержки не с нулем, а со стоимостью потерянных заявок, рекламного бюджета, времени команды, срочных работ, репутационных потерь и риска компрометации. Uptime Institute в отчете по outage 2024 отдельно подчеркивает высокую стоимость серьезных сбоев и то, что значительная часть инцидентов могла быть предотвращена лучшими процессами, управлением и конфигурацией.[8]
Пример. Сайт получает 8 000 посещений в месяц, в рабочие часы и во время рекламы — около 20 посетителей в час. Конверсия в заявку — 2,5%, конверсия заявки в продажу — 25%, маржа одной продажи — 1 200 BYN. Шестичасовой сбой во время активной кампании дает 120 потерянных посещений, примерно 3 потерянные заявки и 0,75 условной продажи. Это уже около 900 BYN маржи, не считая списанного рекламного бюджета, времени менеджеров, повторной настройки кампаний и доверия пользователей. Для B2B с высоким средним чеком одна потерянная заявка может стоить больше, чем несколько месяцев поддержки.
Но самая дорогая проблема — не полный outage, а тихая деградация. Форма работает только в части браузеров. CRM принимает заявки без UTM. Email попадает в спам. Страница грузится 6 секунд на мобильном. Core Web Vitals уходят в красную зону. Google Search Central рекомендует владельцам сайтов добиваться хороших Core Web Vitals для успеха в поиске и пользовательского опыта: LCP до 2,5 с, INP меньше 200 мс, CLS меньше 0,1.[9] В рекламе качество посадочной тоже не нейтрально: Google Ads включает Landing page experience в компоненты Quality Score, поэтому техподдержка должна отслеживать не только uptime, но и состояние страниц, на которые ведут кампании.[10]
Как считать честно
Оцените не только цену поддержки, но и цену отсутствия поддержки: сколько стоит 1 час простоя, 1 день сломанной формы, 1 неделя без обновлений безопасности, 1 месяц без контроля скорости и 1 инцидент без бэкапа.
8 модулей зрелой поддержки сайта
Чтобы SLA был не бумажным, а рабочим, его удобно собирать из модулей. Это помогает бизнесу выбрать подходящий уровень поддержки: базовый для информационного сайта, расширенный для leadgen-проекта, усиленный для e-commerce или B2B-системы с интеграциями. Ниже — восемь модулей, которые стоит рассматривать как нормальную основу.
1. Аварийная поддержка
P1/P2, on-call, каналы эскалации, порядок коммуникации, временное восстановление, post-incident review. NIST SP 800-61r3 рассматривает incident response как часть управления киберрисками: нужно быть готовыми обнаруживать, реагировать и восстанавливаться.[5]
2. Мониторинг и алерты
Uptime, SSL, DNS, диск, CPU/RAM, ошибки 5xx, лог ошибок CMS, cron, очередь писем, тестовые отправки форм, sitemap/robots, индексируемость ключевых страниц.
3. CMS и безопасность
Обновления ядра, модулей и библиотек, проверка security advisories, права пользователей, 2FA, ревизия администраторов, контроль устаревших компонентов и конфигураций.
4. Хостинг и инфраструктура
Контроль версии PHP, базы данных, веб-сервера, кешей, очередей, сертификатов, cron, логов, ресурсов VPS, резервного места, ограничений тарифа и даты продления услуг.
5. Резервные копии и restore
Отдельные копии файлов и базы, хранение вне сервера, retention policy, проверка восстановления, инструкция по rollback после неудачного релиза или взлома.
6. Релизы и доработки
Оценка задач, staging, код-ревью, проверка форм, адаптива, кешей, SEO-тегов, микроразметки, аналитики и интеграций перед выкладкой на production.
7. Производительность
Периодический контроль PageSpeed/Core Web Vitals, веса страниц, тяжелых скриптов, изображений, кеширования, TTFB, LCP, INP, CLS и влияния новых виджетов на скорость.
8. Отчет и план развития
Ежемесячный отчет по SLA, список инцидентов, выполненные обновления, риски, рекомендации, технический долг, план работ на следующий месяц и отдельная оценка задач развития.
Такой набор не означает, что каждый сайт обязан покупать максимальный пакет. Но каждый владелец должен понимать, от каких рисков он сознательно отказывается. Если нет мониторинга — вы узнаете о проблеме позже. Если нет staging — растет риск сломать production. Если нет security updates — растет риск компрометации. Если нет тестов восстановления — бэкап может оказаться непригодным в момент аварии. Если нет отчета — бизнес не видит, что поддержка делает и какие риски накопились.
Как ONTOP обычно выстраивает поддержку сайта
Для ONTOP техническая поддержка сайта — это продолжение разработки и продвижения, а не отдельная «мелкая услуга после запуска». Если сайт создается как инвестиция в бизнес, он должен поддерживаться как актив: с контролем доступности, скорости, безопасности, заявок, SEO-рисков и изменений. Мы уже подробно разбирали, почему профессиональный сайт — это инвестиция, почему быстрый хостинг и скорость загрузки влияют на заявки и почему выбор между VPS и shared hosting должен зависеть от нагрузки, безопасности и требований проекта.
В нормальной модели поддержка начинается с аудита текущего состояния: CMS, модулей, хостинга, бэкапов, доступа к домену, SSL, аналитики, форм, CRM-интеграций, Search Console, логов, скорости и прав пользователей. Затем составляется карта рисков: что может остановить заявки, что может ударить по SEO, что может привести к взлому, что может сломаться при обновлении, какие зоны сейчас не мониторятся. После этого уже можно писать SLA: не абстрактный, а привязанный к реальному сайту и реальной экономике бизнеса.
Особенно важно связывать поддержку с маркетингом. Если на сайте идут рекламные кампании, проблема формы — это не «технический баг», а слив бюджета. Если планируется SEO-миграция на новую CMS, поддержка должна заранее контролировать редиректы, индексацию и Search Console. Если бизнес думает о редизайне сайта, SLA помогает отделить аварийные проблемы от накопленного технического долга. Если падает конверсия, нужно проверять не только рекламу, но и ошибки форм заявки и обратного звонка.
Если сайт уже приносит заявки, но поддержка держится на чате, случайных правках и надежде, что «ничего не случится», стоит начать с SLA-аудита: периметр, риски, бэкапы, обновления, мониторинг, скорость, формы и порядок аварийной реакции.
Чек-лист перед подписанием договора
Перед тем как подписывать договор технической поддержки сайта, стоит пройти короткий практический чек-лист. Он быстро показывает, перед вами рабочий SLA или просто абонентский тариф с красивым названием.
Что проверить в SLA по поддержке сайта
- Периметр: перечислены сайт, CMS, хостинг, домен, SSL, модули, интеграции, формы, CRM, аналитика, Search Console, почта и сторонние сервисы, которые входят в поддержку.
- Приоритеты: есть P1–P4 с понятными критериями, а не размытая формулировка «срочные обращения выполняются в первую очередь».
- Таймеры: отдельно прописаны response time, start time, workaround, целевое resolution time и частота статус-обновлений.
- Календарь: понятно, когда действует SLA: рабочие часы, выходные, праздники, 24×7 только для P1 или отдельный аварийный режим.
- Мониторинг: указано, какие проверки автоматизированы: uptime, SSL, домен, ошибки, формы, дисковое место, cron, бэкапы, производительность.
- Обновления: есть регламент patch management: как отслеживаются security advisories, как оценивается риск, где тестируются обновления и как выкатываются.
- Бэкапы: зафиксированы частота, состав, место хранения, срок хранения, контроль успешности и тест восстановления.
- Релизы: есть staging, чек-лист перед выкладкой, резервная копия, rollback plan и правила экстренных изменений.
- Отчетность: клиент получает регулярный отчет по обращениям, инцидентам, обновлениям, uptime, рискам и рекомендациям.
- Исключения: прописаны сторонние сервисы, отсутствие доступов, самостоятельные изменения клиента, плановые работы, форс-мажор и отказ от рекомендованных обновлений.
Если подрядчик не может ответить на эти пункты, это не всегда означает, что он плохой. Возможно, он просто продает не SLA, а почасовую помощь. Это разные услуги. Почасовая помощь подходит, когда сайт не критичен. SLA нужен, когда сайт уже является частью продаж, рекламы, SEO и операционной стабильности бизнеса.
FAQ: частые вопросы по SLA
Короткие ответы на вопросы, которые чаще всего возникают перед договором поддержки
Чем SLA отличается от обычной технической поддержки сайта?
Обычная поддержка часто означает «пишите, когда нужна помощь». SLA означает заранее согласованные правила: что поддерживается, какие есть приоритеты, сроки реакции, процесс аварии, мониторинг, бэкапы, обновления, отчетность и ответственность сторон. SLA измерим, обычная поддержка часто держится на договоренностях в переписке.
Нужен ли SLA маленькому сайту?
Если сайт почти не влияет на продажи, можно ограничиться базовой поддержкой. Но если через сайт идут заявки, реклама, SEO-трафик, запись, оплата или важная репутационная коммуникация, минимальный SLA нужен даже небольшому проекту. Он может быть простым, но должен закрывать мониторинг, бэкапы, обновления и критичные инциденты.
Можно ли гарантировать 100% uptime?
Практически нет. 100% uptime как договорное обещание обычно нереалистичен: есть плановые работы, сбои дата-центров, DNS, сторонних сервисов, сетей, платежей, человеческие ошибки и уязвимости. Профессиональнее фиксировать целевой uptime, метод измерения, исключения, мониторинг и процесс восстановления.
Что важнее: время реакции или время решения?
Важны оба показателя, но они решают разные задачи. Время реакции показывает, как быстро команда включилась. Время решения показывает, когда проблема устранена. Для коммерческого сайта между ними нужен еще workaround: временное восстановление заявок, оплаты или доступности, чтобы бизнес не стоял в ожидании идеального исправления.
Как часто нужно обновлять CMS и модули?
Нет одной частоты для всех сайтов. Критичные security updates нужно оценивать и ставить быстро, плановые обновления — по регулярному графику с тестированием. NIST описывает patch management как процесс идентификации, приоритизации, установки и проверки обновлений, а не как разовую техническую операцию.[4]
Что должно быть в аварийном плане?
Список ответственных, каналы связи, критерии P1, доступы, runbook диагностики, места логов, порядок отключения проблемного модуля, восстановление из бэкапа, коммуникация со стейкхолдерами, rollback, фиксация таймлайна и post-incident review. Без этого авария каждый раз решается вручную и медленнее, чем могла бы.
Можно ли включить SEO и скорость сайта в SLA?
Да, но корректно. SLA не должен обещать позиции в поиске, потому что они зависят от конкурентов, контента, ссылок, спроса и алгоритмов. Но можно включить технические SLI/SLO: отсутствие 5xx на ключевых страницах, контроль sitemap/robots, редиректов, индексации, Core Web Vitals, скорости шаблонов и ошибок Search Console. Google отдельно рекомендует добиваться хороших Core Web Vitals для поисковой эффективности и UX.[9]
Вывод: нормальный SLA защищает не сайт, а бизнес-процесс
Техническая поддержка сайта ценна не сама по себе. Бизнесу не нужен «разработчик на абонентке» ради ощущения безопасности. Бизнесу нужно, чтобы сайт стабильно принимал заявки, быстро открывался, не терял SEO-трафик, не сливал рекламный бюджет, не превращался в security risk, не ломался после обновлений и не зависел от памяти одного человека.
Нормальный SLA как раз про это. Он переводит поддержку из режима «пожарные работы по факту» в режим управляемой эксплуатации: мониторинг, приоритеты, регламент аварий, бэкапы, обновления, security process, релизы, отчетность и постоянное улучшение. Чем больше сайт влияет на выручку, тем менее допустима поддержка в формате «если что — напишите в чат».
Хороший SLA не обязан быть огромным юридическим документом. Он должен быть ясным, измеримым и практичным. Если после прочтения договора понятно, что происходит при падении сайта, кто отвечает за бэкапы, как ставятся security updates, как проверяются формы, где фиксируются задачи, как быстро реагируют на P1 и что получает бизнес в отчете, — это уже рабочая основа. Если непонятно, SLA нужно переписывать до старта поддержки, а не после первой аварии.
Источники
- Google SRE Book — Service Level Objectives — глава из книги Google Site Reliability Engineering о Service Level Indicators, Objectives и Agreements: как выбирать метрики, целевые уровни надежности и управлять сервисом на основе того, что действительно важно пользователям.
- Atlassian — What is an SLA? Service level agreement explained — практическое объяснение SLA как соглашения об уровне сервиса: время реакции и решения, ожидания клиента, измерение качества поддержки и роль SLA в управлении IT-сервисами.
- Atlassian — How incident management works in Jira Service Management — материал по incident management: классификация инцидентов, escalation, communication, resolution, recovery, post-incident review и связь процесса инцидентов с SLA-метриками.
- NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning — официальный документ NIST о patch management как preventive maintenance: идентификация, приоритизация, установка и проверка обновлений для снижения риска компрометации и операционных сбоев.
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations — актуальная публикация NIST по incident response в рамках Cybersecurity Framework 2.0: подготовка, обнаружение, реагирование, восстановление и улучшение после инцидентов.
- OWASP Top Ten Web Application Security Risks — официальный проект OWASP Top 10 с актуальной версией и описанием наиболее критичных рисков веб-приложений, включая устаревшие компоненты, ошибки конфигурации, контроль доступа и логирование.
- Drupal.org — Security advisories — официальный раздел Drupal Security Advisories по ядру Drupal, contributed-проектам и PSA; источник для понимания, почему CMS-поддержка должна включать регулярный мониторинг security-обновлений.
- Uptime Institute — Annual outage analysis 2024 — аналитический отчет о причинах, стоимости и последствиях outage: рост роли cyber-related incidents, высокая цена серьезных простоев и влияние процессов управления на предотвращение сбоев.
- Google Search Central — Understanding Core Web Vitals and Google search results — официальная документация Google по Core Web Vitals: LCP, INP, CLS, их целевые пороги и значение для пользовательского опыта и эффективности сайта в поиске.
- Google Ads Help — About Quality Score for Search campaigns — справка Google Ads о Quality Score и его компонентах, включая Landing page experience; используется как подтверждение того, что качество посадочной страницы влияет не только на UX, но и на диагностику рекламной эффективности.
