Сопровождение после запуска: SLA, релизы и развитие сайта

1. Запуск — это начало эксплуатации

Многие компании воспринимают запуск как момент, когда подрядчик "сдал сайт" и работа закончилась. На практике именно после запуска начинается самый ответственный этап. Появляются реальные сценарии, которых не было в тестах: пользователь заполняет форму с нестандартным телефоном, CRM меняет обязательное поле, платежный шлюз присылает повторный вебхук, контент-менеджер загружает слишком тяжелое изображение, поисковик индексирует старый URL, а маркетинг запускает рекламу на страницу, где неожиданно выросло время ответа.

Сопровождение — это не только "исправлять баги". Это операционная система вокруг продукта: мониторинг доступности, контроль ошибок, обновления безопасности, плановые релизы, работа с backlog, аналитика, регламент коммуникации и регулярный пересмотр roadmap. Чем сложнее сайт — личный кабинет, интеграции, платежи, роли, документы — тем сильнее сопровождение влияет на бизнес-результат.

Хорошая приемка проекта должна включать не только список реализованных функций, но и готовность к эксплуатации: доступы, мониторинг, регламенты, backup, SLA и план первых релизов.

2. Мониторинг: что нужно видеть каждый день

Минимальный мониторинг сайта начинается с доступности и скорости, но не заканчивается ими. Нужны external uptime checks, health endpoints, server metrics, application errors, frontend errors, логирование интеграций, контроль очередей, домены и SSL-сертификаты, бэкапы, cron-задачи, web vitals и бизнес-события. Если сайт принимает заявки, важно видеть не только HTTP 200, но и количество успешных отправок форм, ошибки валидации, доставку в CRM и время ответа менеджера.

Для порталов и ecommerce добавляются платежи, статусы заказов, синхронизация с 1С, ошибки авторизации, очереди вебхуков, отправка писем и доступность документов. Мониторинг должен отвечать на вопрос "что сломалось и кого это затронуло", а не просто показывать красную лампочку. Поэтому логи и метрики связываются через correlation_id, user_id, order_id, payment_id и integration_name.

• Availability: uptime, response time, DNS, SSL, CDN and hosting health.
• Application: backend errors, frontend exceptions, failed jobs, queue age, memory and CPU.
• Business: leads, payments, CRM delivery, 1C sync, conversion events and abandoned flows.
• Security: suspicious auth attempts, dependency alerts, unexpected admin activity and WAF events.

3. Инциденты P1-P3: общий язык для бизнеса и команды

SLA становится полезным, когда команда и бизнес одинаково понимают приоритеты. Не каждая ошибка является пожаром, но некоторые проблемы требуют немедленной реакции. Мы обычно используем P1, P2 и P3. P1 — полный простой или критичный бизнес-ущерб: сайт недоступен, оплаты не проходят, личный кабинет не открывается, есть подозрение на утечку данных. P2 — существенная деградация: часть пользователей не может завершить сценарий, CRM-синхронизация задерживается, но есть workaround. P3 — некритичные дефекты и улучшения: визуальные баги, неудобства админки, не срочные правки контента.

Важно разделять response time и resolution time. Время реакции — когда команда приняла инцидент в работу и начала диагностику. Время восстановления — когда сервис вернулся к приемлемому состоянию. Для сложных интеграций не всегда можно гарантировать полное исправление за один час, но можно гарантировать быструю реакцию, понятный статус, временное решение и регулярные обновления.

• P1: недоступность production, массовый сбой оплаты, риск утечки, критичный security incident.
• P2: сломан важный сценарий для части пользователей, задержка интеграции, рост ошибок без полного простоя.
• P3: локальный баг, правка верстки, улучшение админки, не срочная задача развития.

Если приоритеты не описаны до инцидента, они будут обсуждаться в самый плохой момент — когда сервис уже деградирует, а эмоции мешают принимать решения.

4. Incident management: от алерта до postmortem

Процесс инцидента должен быть коротким и понятным. Сначала alert или обращение попадает в agreed channel. Ответственный подтверждает прием, классифицирует приоритет, собирает факты, назначает исполнителя и сообщает первый статус. Дальше команда локализует проблему, применяет workaround или rollback, восстанавливает сервис, фиксирует причину и создает задачи на предотвращение повтора.

Postmortem нужен не для поиска виноватого. Его смысл — улучшить систему: добавить мониторинг, переписать хрупкий участок, уточнить runbook, изменить релизный чек-лист, усилить тесты, перенести секреты, разделить права доступа. Для P1 postmortem обязателен; для P2 полезен, если проблема повторяется или затронула выручку.

5. Релизный ритм: скорость без хаоса

После запуска изменения продолжаются: новые страницы, A/B-гипотезы, правки форм, интеграции, SEO-задачи, юридические тексты, доработки личного кабинета. Если выпускать их хаотично, production превращается в полигон. Поэтому нужен релизный ритм: например, плановый релиз раз в неделю или раз в две недели, срочные hotfix отдельно, крупные изменения через feature flags и staging.

Каждый релиз должен иметь состав, owner, дату, checklist, план отката и критерии успешности. Для сайта с интеграциями в checklist входят smoke-тесты: формы, авторизация, платежи, CRM, 1С, письма, sitemap, robots, ключевые страницы и Core Web Vitals. После выката команда смотрит error rate, скорость, события аналитики и обращения поддержки.

• Плановые релизы лучше объединять в понятные пакеты, а не выкатывать каждую мелочь отдельно.
• Hotfix должен быть исключением для production incidents, а не обычным способом работы.
• Feature flags помогают включать рискованные функции постепенно и быстро отключать их без rollback всего релиза.

Релизный процесс защищает не от изменений, а от случайности. Бизнес получает скорость, когда команда понимает, что, когда и как выходит в production.

6. Security patches: безопасность как регулярная работа

Сайт после запуска живет в меняющейся среде. Выходят CVE в библиотеках, обновляются браузеры, меняются требования платежных провайдеров, появляются новые атаки на популярные CMS и фреймворки, истекают сертификаты, устаревают Docker-образы. Если security patches не включены в сопровождение, проект постепенно накапливает технический долг, который всплывает в самый неудобный момент.

Регулярная security-работа включает dependency monitoring, обновление пакетов, проверку breaking changes, обновление серверных компонентов, ротацию секретов, контроль прав доступа, backup restore tests, проверку security headers и периодический аудит. Для проектов с персональными данными, платежами и личными кабинетами это не "дополнительная опция", а нормальная эксплуатационная обязанность.

• Поддерживайте список зависимостей и владельцев компонентов.
• Не обновляйте production вслепую: сначала staging, smoke-тесты и rollback-план.
• Проверяйте восстановление backup, иначе backup может оказаться только "галочкой".

7. Backlog после запуска: как выбирать задачи

После релиза backlog быстро наполняется: маркетинг просит новые посадочные страницы, продажи хотят дополнительные поля в CRM, поддержка просит фильтр в админке, SEO-специалист предлагает структуру разделов, пользователи жалуются на сложную форму, бухгалтерия просит изменить документы. Если все задачи считать одинаковыми, команда захлебнется. Нужен механизм приоритизации.

Мы рекомендуем оценивать задачи по четырем осям: бизнес-эффект, риск, срочность и стоимость задержки. Исправление потери заявок выше визуальной полировки. Security patch выше новой анимации. Улучшение формы, которое влияет на conversion rate, может быть важнее крупного, но слабо подтвержденного раздела. Хороший backlog прозрачен: видно, почему задача в работе сейчас, а другая ждет.

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

Backlog поддержки — это не список просьб. Это инструмент управления развитием, где каждая задача конкурирует за ограниченное внимание команды.

8. SLA-метрики: что измерять в договоре и отчетах

SLA должен быть измеримым. Формулировка "оперативно реагируем" не защищает ни заказчика, ни команду. В договоре и регламенте фиксируют часы поддержки, каналы обращения, приоритеты, response time, target recovery time, окна плановых работ, исключения, формат отчетности и порядок эскалации. Для некоторых проектов добавляют SLO по uptime, времени обработки очередей, доставке лидов и максимальной давности синхронизации.

Отчетность не должна превращаться в бюрократию. Нужен короткий ежемесячный отчет: сколько обращений пришло, сколько закрыто, какие были P1/P2, среднее время реакции, невыполненные SLA, причины, выполненные релизы, security updates, состояние backlog и предложения по roadmap. Такой отчет помогает руководителю видеть, что поддержка не "съедает бюджет", а удерживает качество и развивает продукт.

• Response time: время до подтверждения и начала работы.
• Recovery time: время до восстановления приемлемого состояния.
• Uptime/SLO: доступность за период с учетом исключений.
• Backlog health: возраст задач, доля срочных, выполненные релизы.
• Security posture: обновления, уязвимости, доступы, backup tests.

9. In-house или outsource: когда какую модель выбирать

Вопрос "нанять своих или оставить подрядчика" не имеет универсального ответа. In-house оправдан, когда сайт или портал стал ядром бизнеса, изменения идут ежедневно, нужна глубокая доменная экспертиза внутри компании, а продуктовый roadmap большой и долгосрочный. Собственная команда быстрее погружается в бизнес, но требует найма, управления, процессов, дежурств, DevOps-компетенций и бюджета на удержание специалистов.

Outsource-поддержка подходит, когда нужен предсказуемый уровень сервиса без постоянной загрузки полной команды: корпоративный сайт, B2B-портал на этапе роста, регулярные релизы, интеграции, SEO и security updates. Хороший подрядчик уже имеет процессы, инженеров разных специализаций и опыт похожих инцидентов. Часто оптимальна гибридная модель: внутри остается product owner и контент/маркетинг, а разработка, DevOps, аудит и сопровождение — у внешней команды.

• Выбирайте in-house, если продукт требует ежедневной разработки и является конкурентным ядром.
• Выбирайте outsource, если нужна надежная эксплуатация, регулярные улучшения и доступ к разным компетенциям.
• Выбирайте гибрид, если бизнес-экспертиза должна быть внутри, а инженерная мощность нужна гибко.

Главный критерий — не "свои или чужие", а наличие владельца продукта, понятного SLA и команды, которая реально несет ответственность за production.

10. Roadmap развития: сайт должен взрослеть

Хорошее сопровождение не ограничивается реакцией на ошибки. Через 1-3 месяца после запуска уже видны данные: какие страницы приводят заявки, где пользователи бросают форму, какие интеграции чаще падают, какие вопросы задает поддержка, какие разделы индексируются, какие сценарии требуют автоматизации. Эти данные превращаются в roadmap развития.

Roadmap обычно делится на горизонты. Ближайший месяц — исправление слабых мест после запуска и стабилизация. 3 месяца — улучшение конверсий, SEO-структуры, админки, интеграций и скорости. 6-12 месяцев — новые продуктовые сценарии: личный кабинет, биллинг, документы, сегментация, контентная платформа, self-service для клиентов. Такой подход делает сайт не разовой витриной, а развивающимся цифровым активом.

• 30 дней: стабилизация, мониторинг, быстрые UX-правки, обработка обратной связи.
• 90 дней: SEO, conversion rate, performance, интеграции, админские инструменты.
• 180+ дней: новые сценарии, автоматизация, личный кабинет, аналитика и self-service.

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