Соглашение об уровне сервиса (SLA, Service Level Agreement) для поддержки и сопровождения

Ключевые факты (ответ в первом абзаце)

• Это SLA описывает целевые показатели поддержки и сопровождения для инцидентов, дефектов и уязвимостей безопасности.
• Базовое покрытие: рабочие часы по CET/CEST. Поддержка вне рабочих часов / 24×7 дежурство (on-call) — в зависимости от плана поддержки.
• Основной канал приёма обращений — тикет-система. Обращения из чатов могут дублироваться в тикеты для учёта по SLA.
• Для критических инцидентов приоритет — восстановить работоспособность сервиса до углублённого анализа причин.
• Для установления реалистичных целевых показателей для сложных или унаследованных систем требуется онбординг (onboarding).

Что входит в SLA

Это SLA применяется к:

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

Что не входит в SLA (исключения)

Это SLA не покрывает проблемы, находящиеся вне операционного контроля, включая:

• Сбои дата-центра / инфраструктуры, не управляемой нашей командой.
• Сбои внешних сервисов или изменения API (примеры: провайдеры оплат, платформы email-маркетинга).
• Отказы микросервисов или подсистем, не разработанных и не эксплуатируемых нашей командой (мы можем помогать в диагностике и координации).
• Ситуации, когда необходимый доступ не предоставлен (действуют ограничения; см. «Требования к доступам» и «Онбординг»).

Что мы делаем, если первопричина вне нашего контроля

Если инцидент вызван внешними сервисами или зависимостями, мы можем:

• Определить и подтвердить характер отказа, связанного с зависимостью.
• Предоставить технический контекст и журналы (логи), если доступны.
• Помочь заказчику как технический посредник при общении с поддержкой поставщика в рамках оплачиваемого объёма поддержки.
• Зафиксировать выводы в тикете и предложить меры снижения влияния или обходные решения, когда это возможно.

Модель разделённой ответственности

Поддержка и сопровождение работают в рамках модели разделённой ответственности:

• Наша ответственность: код приложения и бизнес-логика, процессы развёртывания и релизов, конфигурация компонентов в нашем управлении, диагностика и координация инцидентов, мониторинг в согласованном объёме.
• Ответственность заказчика: инфраструктура и среда хостинга (серверы, сеть, DNS, балансировщики нагрузки), предоставление доступов и управление учётными данными, договоры со сторонними сервисами (платёжные провайдеры, почтовые сервисы, CDN), бизнес-решения по принятию мер восстановления и приоритизации изменений.
• Совместная / координируемая зона: управление CI/CD-пайплайном (в зависимости от доступов), администрирование баз данных (в зависимости от объёма), практики безопасности (прикладной vs. инфраструктурный уровень).

Точная граница определяется для каждого проекта в ходе онбординга и фиксируется в SOW.

Тикет

Тикет — основной объект для учёта, триажа, эскалации, реакции и отчётности. Учёт SLA ведётся по тикетам.

Инцидент (production incident)

Инцидент — отказ сервиса, влияющий на доступность или ключевую функциональность в продуктивной среде. Примеры:

• Сайт/сервис недоступен (полностью или частично).
• Повторяющиеся серверные ошибки (например, HTTP 500), блокирующие использование.
• Критический сбой развёртывания или инфраструктуры, влияющий на продуктивную среду.

Дефект (bug)

Дефект — некорректное поведение существующей функциональности. Примеры:

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

Запрос на изменение (Change Request)

Запрос на изменение — запрос на изменение или улучшение системы (новый интерфейс, новая функция, новая бизнес-логика). Такая работа ведётся как плановый поток поставки:

• Выполняется оценка.
• Планируется по загрузке и условиям договора.
• Не рассматривается как инцидент, если не блокирует работу в продуктивной среде.

Срочные изменения по внешним дедлайнам

Некоторые изменения срочные из-за внешних дедлайнов (закон/регуляторика, кампания, важное бизнес-событие). Такие задачи могут приоритизироваться как срочные, даже если это не инцидент. Приоритизация зависит от влияния на бизнес и плана поддержки.

Первая реакция (first response) — подтверждение + начало работ

Первая реакция означает:

• Тикет подтверждён.
• Команда подтверждает, что обращение получено и по нему начаты работы.
• При необходимости запускается эскалация (подключаются нужные роли).

Временное восстановление / меры снижения влияния (mitigation) и восстановление работоспособности

Временное восстановление означает как можно быстрее вернуть минимально достаточную работоспособность (даже если полное устранение причины требует дополнительного времени). Это подход по умолчанию для критических инцидентов.

Полное устранение (resolution)

Полное устранение означает полное исправление, устраняющее причину и восстанавливающее всю функциональность. В сложных случаях полное устранение может выполняться после восстановления работоспособности (особенно при инцидентах вне рабочих часов).

Стандартное покрытие: рабочие часы (CET/CEST)

Покрытие поддержки по умолчанию предоставляется в рабочие часы по CET/CEST.

Расширенное покрытие: вне рабочих часов и дежурство (on-call) — по плану

Расширенное покрытие может предоставляться для выбранных планов:

• Реакция вне рабочих часов на критические инциденты.
• Назначение дежурного инженера для пересечения по часовым поясам заказчика (включая часовые пояса США, если требуется по плану).
• Планирование критических развёртываний в удобные для заказчика окна (например, ночные/ранние утренние окна для снижения влияния на пользователей).

Праздники и нерабочие дни

Календари праздников могут согласовываться по месту исполнения работ и договорному контексту (примеры, используемые в операционной практике: Молдова, Германия, США). Применимый календарь может быть определён для конкретного плана поддержки / SOW.

Преимущество часовых поясов для заказчиков из США

Работа по CET/CEST создаёт структурное преимущество для заказчиков в часовых поясах США:

• Реакция в ночное время США: критичные инциденты, возникающие ночью по американскому времени, совпадают с нашими стандартными рабочими часами, что обеспечивает немедленное подключение инженера без дополнительной оплаты за дежурство.
• Окна для релизов: развёртывания и критичные обслуживания могут планироваться на ночное/раннее утреннее время по США для минимизации влияния на бизнес-операции.
• Покрытие для часовых поясов СНГ также может быть согласовано.

Поддерживаемые языки

• Русский и английский: полная поддержка для всей коммуникации, документации и отчётности.
• Немецкий: доступен для коммуникации с заказчиком и документации.
• Другие языки: могут быть согласованы.
• Перевод с помощью ИИ доступен как опция для снижения языковых барьеров в операционной коммуникации, с учётом политики заказчика по обработке данных.

Официальный канал поддержки (отсюда ведётся учёт SLA)

Официальный канал для учёта по SLA — тикет-система. Чаты (например, мессенджеры) могут использоваться для оперативной коммуникации, но обращения следует фиксировать в тикетах для единообразного учёта и отчётности.

Обязательная информация в обращении (минимальный состав)

Чтобы сократить время триажа и избежать повторных уточнений, обращение должно содержать:

• Что произошло (краткое описание).
• Когда произошло (временной интервал).
• Где проявилось (страница/маршрут/метод API/функция; среда, если известна).
• Влияние на бизнес (что блокируется; кто затронут).
• Предварительная оценка критичности (если заказчик может указать).
• По возможности: скриншоты, сообщения об ошибках, логи, идентификаторы трассировки (trace ID).

Требования к доступам и операционные ограничения

Эффективность поддержки зависит от доступов. Примеры:

• Без доступа к продуктивной среде поддержка может быть ограничена изменениями на уровне репозитория и консультациями.
• Инфраструктурные сбои (сломанный пайплайн развёртывания, проблемы среды выполнения) нельзя полностью устранить без доступа к соответствующему инфраструктурному слою. Требования к доступам фиксируются в ходе онбординга.

Уровни критичности и соответствие приоритетам

Используется модель критичности, совместимая со стандартной практикой enterprise:

• Уровни критичности S1–S4 (Severity) могут быть сопоставлены с уровнями приоритета P0–P4 (Priority).

Определения критичности (сначала влияние на бизнес)

S1 / P0 — Критический, блокирующий бизнес

• Полная или частичная недоступность сервиса.
• Заблокирован ключевой бизнес-сценарий (оплаты/заказы/доступ в личный кабинет).
• Критический сбой инфраструктуры/развёртывания, влияющий на продуктивную среду.
• Инцидент безопасности с риском утечки данных или значимого репутационного ущерба.

S2 / P1 — Высокое влияние, но не полный блок

• Существенная деградация или отказ важной функции, при этом бизнес может работать с ограничениями или обходными путями.
• Примеры: влияние на SEO/индексацию, поломка важных страниц, деградация вторичных, но бизнес-значимых сценариев.

S3 / P2 — Среднее влияние

• Дефекты с ограниченным влиянием или наличием обходных путей.
• Подходят для плановой очереди исправлений.

S4 / P3–P4 — Низкое влияние / бэклог

• Косметические проблемы, небольшие UX-изменения, несрочные улучшения.
• Планируются по загрузке и условиям договора.

Срочные изменения по внешним дедлайнам

• Могут рассматриваться как повышенный приоритет при наличии явного риска дедлайна для бизнеса (соответствие регуляторике, кампания, требования под событие). Обработка зависит от плана и влияния.

Целевые показатели зависят от плана поддержки

Целевые показатели сервиса зависят от выбранного плана поддержки (Базовый / Расширенный / Корпоративный). Точные значения могут быть зафиксированы в SOW / приложении к плану поддержки.

Целевые показатели первой реакции (операционная база)

• В рабочие часы для критических инцидентов целевой ориентир — начать работу быстро после получения тикета; типичный ориентир для критических случаев — около 20 минут (быстрее для более высоких планов при доступности ресурсов).
• Реакция вне рабочих часов предоставляется по плану; типичный ориентир вне рабочих часов может составлять в течение нескольких часов, учитывая получение оповещения и подключение дежурного.

Целевые показатели восстановления работоспособности (восстановление vs. полное устранение)

Подход «сначала восстановить» означает возврат минимально критичной функциональности в кратчайшие сроки, даже если полное устранение первопричины требует дополнительного времени. Ориентиры восстановления применяются, когда первопричина находится в нашей зоне ответственности (код приложения, конфигурация, развёртывание под нашим контролем).

Существенные оговорки:

• Финальные целевые показатели восстановления фиксируются в SOW для каждого проекта и зависят от: технологического стека, зрелости системы, уровня доступа, объёма контроля инфраструктуры и количества зависимостей от третьих сторон.
• Если первопричина вне нашего контроля (сбой дата-центра, сетевой отказ, проблема хостинг-провайдера), мы обеспечиваем координацию и техническое содействие, но не можем гарантировать срок восстановления инфраструктуры, которой не управляем.
• Восстановление означает возврат критичных бизнес-сценариев в работоспособное состояние. Это может включать работу в режиме ограниченной функциональности, пока продолжается полное восстановление.
• Анализ первопричин (RCA) выполняется после восстановления сервиса, а не вместо него.

Вехи коммуникации (обновления статуса)

Обновления по тикету предоставляются по вехам прогресса:

• Подтверждено / работа начата.
• Подтверждено направление диагностики.
• Восстановлена работоспособность (применены меры снижения влияния) — при необходимости.
• Развёрнуто исправление (полное устранение) — при необходимости.
• Итоговые комментарии и рекомендации.

Частота обновлений статуса зависит от плана поддержки (см. «Enterprise-условия и договорные приложения» → «Коммуникация во время инцидента: частота обновлений»). Минимальная частота обновлений для активного инцидента S1 — каждые 4 часа (Basic), с более высокой частотой для Extended и Enterprise.

Блокирующие факторы: доступы и данные со стороны заказчика

Если выполнение работ блокируется отсутствием доступа или данных:

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

Лестница эскалации (кто подключается)

Стандартный путь эскалации:

1. Дежурный / назначенный инженер (первый реагирующий)
2. Руководитель проекта / техлид
3. Старшие роли / роли с расширенными правами (CTO, архитектор) — для сложных или критических случаев

Когда происходит эскалация

Эскалация запускается:

• Немедленно, если у первого реагирующего нет доменного контекста или доступа (например, платежный модуль, инфраструктурный слой).
• После расследования, если инцидент уходит в подсистему без необходимых доступов или компетенций.

Триггеры подключения руководства

Подключение старших ролей может происходить, когда:

• У критичных заказчиков есть прямые финансовые потери (например, банковские/трейдинговые сценарии).
• Репутационный инцидент требует быстрого сдерживания (например, заметная компрометация/подмена содержимого).
• Критический инцидент безопасности требует координированной реакции.

Временные пороги эскалации (Enterprise)

Для корпоративного (Enterprise) плана матрица эскалации с временными порогами фиксируется в SOW (см. «Enterprise-условия и договорные приложения» → «Матрица эскалации с временными порогами»).

Операционный приоритет: сначала восстановить сервис

Для инцидентов уровня S1/S2 первоочередная задача — восстановить минимально достаточную работоспособность. Углублённое устранение первопричин выполняется после восстановления.

Набор мер снижения влияния (примеры из практики)

Меры зависят от типа инцидента и могут включать:

• Временное отключение или ограничение проблемной функции.
• Блокировку проблемного маршрута/эндпоинта для прекращения каскадных отказов.
• Экстренные меры для снижения влияния нагрузки при одновременной диагностике инфраструктуры или приложения.
• Выпуск точечного экстренного исправления (hotfix) при необходимости.

Подход к коммуникации во время инцидентов

Коммуникация строится по вехам:

• «Инцидент получен, работа начата».
• «Локализовали область отказа / подтвердили предполагаемую причину».
• «Восстановили критичную функцию / снизили влияние».
• «Работаем над полным исправлением и проверкой». Это обеспечивает информирование заказчика без издержек, которые замедляют восстановление.

Критерии закрытия инцидента

Инцидент считается закрытым, когда:

• Сервис восстановлен и работоспособен для критичных бизнес-сценариев.
• Основной режим отказа устранён/снижен так, чтобы он не блокировал бизнес. Полное восстановление всей функциональности или системные улучшения могут продолжаться как плановые работы после стабилизации.

Предварительное объяснение во время восстановления

В ходе устранения инцидента мы даём краткое операционное объяснение на основе наблюдаемых симптомов и первичной диагностики.

Итоговый RCA-разбор после устранения (для крупных инцидентов)

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

• Что произошло (высокоуровнево).
• Почему произошло (вероятная первопричина).
• Какие меры были приняты для устранения/снижения влияния.
• Какие меры рекомендуются для предотвращения повторения (действия и улучшения). Формат RCA ориентирован на практическую пользу и агрегированные выводы; чрезмерно детальные таймлайны по умолчанию не формируются, если это отдельно не требуется заказчику.

Мониторинг зависит от плана поддержки

Покрытие и глубина мониторинга зависят от плана поддержки. Типовые возможности:

Базовый мониторинг

• Синтетические проверки доступности критичных доменов/страниц с заданным интервалом.
• Оповещения при недоступности эндпоинтов или ошибочных ответах.

Мониторинг сроков и операционных рисков

• Контроль сроков действия сертификатов.
• Контроль сроков доменов и связанные оповещения.

Расширенный мониторинг (по плану)

• Проверки на уровне содержимого (HTML-маркеры / ожидаемые текстовые блоки) для выявления ситуаций «HTTP 200, но страница некорректна».
• Мониторинг инфраструктуры и ресурсов для выявления всплесков нагрузки или нехватки мощности.

Маршрутизация оповещений и реакция

• Оповещения могут направляться в инженерные группы, отвечающие за поддерживаемый сервис.
• Для планов с мониторингом 24×7 оповещения доступны круглосуточно и могут инициировать реакцию дежурного.

Проактивные уведомления заказчика

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

Классификация уязвимостей и маркировка тикетов

Проблемы безопасности оформляются как тикеты с явной классификацией (например, «уязвимость / инцидент безопасности») и высоким приоритетом.

Принципы реакции на проблемы безопасности

Для проблем безопасности операционный приоритет — сдерживание и снижение риска:

• Быстрое применение мер для сокращения окна уязвимости.
• Проверка, что уязвимость закрыта или контролируется.
• Подключение старших технических ролей при необходимости. Публично обработка безопасности определяется как максимально возможные усилия (best effort) с высоким приоритетом и план-зависимыми опциями эскалации и реакции.

Политика уведомления заказчика по безопасности

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

Модель по умолчанию: инфраструктура заказчика

• Данные обрабатываются и хранятся на инфраструктуре заказчика (хостинг, облако, собственные серверы).
• Доступ к системам заказчика осуществляется через согласованные защищённые каналы (VPN, SSH, промежуточные серверы), определённые при онбординге.

Тестовые среды и тестовые данные

• Для некритичных проектов тестовая среда может размещаться на стороне Webdelo для разработки и тестирования.
• При отсутствии доступа к продуктивным данным используются тестовые или анонимизированные наборы данных.
• Использование реальных продуктивных данных в тестовых средах требует явного согласия заказчика и дополнительных мер безопасности.

Обработка чувствительных данных

• Заказчик обязан уведомить нас о системах, обрабатывающих чувствительные данные (персональные данные, финансовая информация, медицинские данные, регулируемые данные).
• Для систем с чувствительными данными применяются дополнительные меры:
• Ограниченный контур доступа и состав сотрудников.
• При необходимости могут быть оформлены отдельные соглашения с участниками команды.
• Предпочтение работы исключительно на инфраструктуре заказчика без локальных копий данных.
• Определение «чувствительных данных», границы доступа и конкретные требования фиксируются в SOW.

Отключение доступов при завершении договора

• По завершении договора все предоставленные доступы отзываются в контролируемом порядке.
• Выполняется проверка отсутствия копий данных на системах Webdelo (если временное копирование допускалось в ходе работ).
• Чек-лист отключения доступов — часть процедуры завершения (см. «Непрерывность услуг и управление знаниями»).

Применяемые практики безопасности

Следующие практики являются частью стандартного процесса разработки и поддержки:

• Ревью кода: все изменения продуктивного кода проверяются перед развёртыванием.
• Управление зависимостями: регулярный мониторинг и обновление сторонних библиотек и фреймворков для устранения известных уязвимостей.
• Контроль доступов: ролевой доступ, принцип минимальных привилегий, отзыв доступов при изменениях в составе команды.
• Логирование и мониторинг: логирование на уровне приложения для диагностики и расследования инцидентов; мониторинг в согласованном объёме.
• Управление секретами: учётные данные, API-ключи и токены хранятся защищённо и не помещаются в репозитории.
• Обновления фреймворков и среды выполнения: согласуются с заказчиком; обновления для устранения уязвимостей могут выполняться приоритетно.

Глубина практик безопасности зависит от контекста

Глубина и строгость практик безопасности определяются балансом между требованиями проекта и бюджетом:

• Базовые практики (перечислены выше) применяются ко всем проектам.
• Усиленные меры (тестирование на проникновение, аудит безопасности, моделирование угроз, инструменты статического/динамического анализа) доступны по соглашению и фиксируются в SOW.
• Плановые работы по безопасности (аудиты, усиление защиты, ревью инфраструктуры) ведутся как отдельный поток работ, а не как устранение инцидента.

Статус сертификации

• Формальная сертификация (SOC 2, ISO 27001) на данный момент отсутствует.
• Движение к сертификации запланировано в горизонте 12–15 месяцев. Это заявленное намерение и план; заказчику рекомендуется уточнить актуальный статус перед подписанием договора.
• Опросник по безопасности с описанием применяемых мер контроля, практик обработки данных и организационных мер доступен по запросу.

Целевые показатели тестового покрытия (операционный ориентир)

• Стандартный ориентир: не менее 90% автоматизированного тестового покрытия кода приложения (юнит- и интеграционные тесты, в зависимости от технологического стека).
• Критичные бизнес-пути — 100% тестовое покрытие: все участки кода, связанные с платежами, обработкой данных клиентов, ключевой бизнес-логикой и аутентификацией, должны быть покрыты автоматизированными тестами без исключений.
• Типы и глубина тестов (юнит, интеграционные, сквозные) согласуются по проекту и фиксируются в SOW.

Ответственность заказчика за решения по бюджету на тесты

• Если заказчик принимает решение сократить или отказаться от тестового покрытия для оптимизации бюджета, это решение должно быть подтверждено явно в письменной форме (тикет, e-mail или дополнение к SOW).
• Подтверждая сокращение тестового покрытия, заказчик принимает на себя связанные риски: повышенную вероятность регрессий, увеличение времени диагностики и устранения инцидентов, рост стоимости будущих изменений.
• Webdelo фиксирует решение о сокращении покрытия и его потенциальные последствия в реестре рисков проекта.

Статический анализ и стандарты ревью кода

• Все изменения продуктивного кода проходят ревью перед развёртыванием.
• Инструменты статического анализа (линтеры, проверки стиля кода) — часть стандартного CI/CD-пайплайна, где применимо.
• Для проектов с повышенными требованиями к безопасности могут быть интегрированы инструменты SAST/DAST по согласованию (фиксируется в SOW).

Доступность отчётности (по запросу / по плану)

Отчётность может формироваться на основе данных тикетов. Режим по умолчанию:

• По запросу, чтобы не создавать избыточную нагрузку для низких планов. Для корпоративных планов может быть согласована периодическая отчётность.

Метрики, которые можно сформировать из истории тикетов

При ведении работ через тикеты можно извлекать метрики за выбранные периоды:

• Время до первой реакции.
• Время до восстановления работоспособности (если применимо).
• Количество инцидентов по критичности и категориям.
• Исторические списки инцидентов и сводки.

Использование отчётности для непрерывных улучшений

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

Формат и периодичность отчётности

• Basic: отчётность по запросу.
• Extended: ежемесячная отчётность доступна как опция; формат согласуется по проекту.
• Enterprise: периодическая отчётность (ежемесячно по умолчанию); формат согласуется в SOW (PDF-сводка, CSV-экспорт или доступ к дашборду).

Инструменты и интеграции

• Тикет-портал обязателен для всех планов.
• Extended и Enterprise: для управления тикетами по умолчанию используется Jira.
• Enterprise (по согласованию): возможна интеграция с существующей системой заказчика. Примеры систем, с которыми возможна координация: Jira Service Management, ServiceNow, PagerDuty, Zendesk.
• Каналы коммуникации: тикет-система (обязательно), Slack / Microsoft Teams (по согласованию для оперативной коммуникации).
• Смена или интеграция инструментов требует онбординга, корректировки процессов и может повлиять на стоимость — фиксируется в SOW.

Зависимости от внешних сервисов

Если влияние на бизнес вызвано внешними сервисами (платёжные провайдеры, email-сервисы, другие API):

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

Обязанности заказчика, влияющие на результат

Для достижения результата заказчик должен предоставить:

• Требуемые доступы (продуктивная среда, логи, при необходимости CI/CD).
• Своевременные ответы на запросы поддержки, когда требуется дополнительная информация.
• Подтверждение влияния на бизнес и согласование мер временного восстановления, если это необходимо.

Что считается изменением

• Развёртывание кода (новые функции, исправления, рефакторинг).
• Обновления зависимостей и фреймворков.
• Изменения конфигурации (переменные окружения, маршрутизация, правила доступа).
• Изменения инфраструктуры в нашей зоне управления (контейнеры, CI/CD-пайплайн и связанные настройки).

Процесс согласования

• Стандартные изменения: запрос через тикет, оценка, планирование и развёртывание после подтверждения заказчика.
• Enterprise / интегрированный процесс: координация через процесс заказчика (спринты, ревью изменений, согласующие этапы). Детали фиксируются в SOW.
• Уполномоченные контакты: заказчик назначает лиц, уполномоченных согласовывать изменения; список фиксируется в SOW или проектной документации.

Окна обслуживания

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

План отката

• План отката обязателен для критичных изменений (ключевые бизнес-сценарии, миграции баз данных, инфраструктурные модификации).
• Подход к откату документируется в тикете до развёртывания.
• Для некритичных изменений готовность к откату поддерживается как стандартная инженерная практика.

Экстренные изменения

• При полном отказе сервиса, связанном с недавним изменением, экстренный откат или hotfix может быть применён без предварительного согласования для восстановления работоспособности.
• Экстренные изменения восстанавливают предыдущее рабочее состояние или применяют точечное исправление и не меняют согласованные бизнес-требования.
• Заказчик уведомляется сразу после применения экстренного изменения с описанием выполненных действий.

Сравнение планов (возможности)

Дополнительные возможности по планам (Enterprise-условия фиксируются в SOW)

Целевые показатели доступности

Для систем, к которым у нас есть полный доступ на уровне приложения и процесса развёртывания, а инфраструктура стабильна и находится под надлежащим контролем, операционный целевой показатель доступности — 99,5%, с ориентиром на 99,8%. Это применимо к системам, разработанным или существенно сопровождаемым нашей командой, с ограниченным числом сложных зависимостей от третьих сторон.

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

• Стабильность инфраструктуры и SLA хостинг-провайдера.
• Надёжность сторонних сервисов (платёжные шлюзы, внешние API, CDN).
• Своевременность предоставления заказчиком доступов и согласований.
• Архитектурная зрелость системы и уровень технического долга.

Проектные показатели доступности фиксируются в SOW после онбординга и оценки системы. Мы берём обязательства за то, что контролируем; доступность на уровне инфраструктуры — ответственность хостинг-провайдера.

Почему цены не публикуются: факторы стоимости планов поддержки

Стоимость поддержки не фиксируется публично, поскольку стоимость выполнения надёжных SLA-обязательств зависит от множества проектных факторов:

• Сложность технологического стека (Go-микросервисы, Laravel, Symfony, унаследованные системы, смешанные среды).
• Количество интеграций и зависимостей от третьих сторон (платёжные системы, внешние API, провайдеры данных).
• Требуемый грейд инженеров (вовлечение senior/lead для критичных систем vs. стандартная поддержка для стабильных приложений).
• Требования к реакции и коммуникации (частота обновлений, доступность 24×7, количество каналов коммуникации).
• Требования к отчётности и инструментам (интеграция с системами заказчика — Jira, ServiceNow; доступ к дашборду; кастомная отчётность).
• Требования к процессам безопасности (глубина практик безопасной разработки, аудиты безопасности, тестирование на проникновение).
• Ограничения по обработке данных (запрет внешних ИИ-инструментов, развёртывание локальных моделей, работа в ограниченных контурах доступа).

Объём услуг и целевые показатели фиксируются в SOW. Состав команды и грейд инженеров зависят от критичности инцидентов и сложности системы. Требования к отчётности, глубине мониторинга и частоте коммуникации напрямую влияют на стоимость. Мы берём обязательства за то, что контролируем; проектные целевые показатели согласуются договорно.

Договорные обязательства, фиксируемые в SOW

Детализированные договорные обязательства (включая сервис-кредиты, временные пороги эскалации, RPO/RTO, сроки уведомлений о безопасности, периодичность сервис-ревью и показатели доступности) фиксируются в SOW / приложении к плану поддержки, а не на этой публичной странице.

Сервис-кредиты (Service Credits)

Для корпоративного (Enterprise) плана могут применяться финансовые компенсации (сервис-кредиты) за нарушение целевых показателей первой реакции/начала работ. Конкретные условия, расчёт и лимиты фиксируются в SOW/приложении к договору.

Принципы, закрепляемые в SOW:

• Основание: сервис-кредит начисляется, если по инциденту S1 Исполнитель не приступил к работам (не подтвердил принятие и фактическое начало работ) в пределах согласованного целевого времени первой реакции.
• Размер: от 2% от ежемесячного платежа за поддержку за каждый инцидент, подлежащий сервис-кредиту.
• Лимит: суммарно не более 30% от ежемесячного платежа за расчётный период (месяц).
• Форма компенсации: сервис-кредит (скидка) на следующий расчётный период.
• Сервис-кредиты применяются к времени первой реакции/начала работ, но не к срокам полного устранения, поскольку время устранения зависит от природы инцидента и не всегда предсказуемо.
• По запросу Заказчика условия (проценты, лимиты, метрики) могут быть изменены; при этом стоимость услуги пересчитывается в зависимости от уровня обязательств.

Матрица эскалации с временными порогами

Для корпоративного (Enterprise) плана матрица эскалации с временными порогами (когда подключаются руководящие роли) фиксируется в SOW/приложении к плану поддержки.

Принципы, закрепляемые в SOW:

• Роли: Дежурный инженер → Техлид проекта → CTO → CEO.
• Триггеры (S1):
• 4 часа без начала работ по S1 → уведомляется Техлид проекта.
• 8 часов без начала работ по S1 → уведомляется CTO.
• 12 часов без начала работ по S1 → уведомляется CEO.
• Каналы уведомления: тикет-система (обязательно) + дополнительные каналы по договору (см. «Каналы коммуникации»).

Коммуникация во время инцидента: частота обновлений

Частота обновлений статуса зависит от плана поддержки. Основной канал во всех планах — тикет-система.

• Enterprise: для S1 — каждые 30 минут; для S2 — каждые 4 часа (в согласованные часы поддержки).
• Extended (Pro): для S1 — каждые 2 часа; для S2 — ежедневно.
• Basic (Start): для S1 — каждые 4 часа; для S2 — по ключевым вехам (принято / устранено) либо по договору.

Дополнительные каналы для Enterprise (по договору): тикет + чат + e-mail и иные согласованные каналы.

Примечание: чем выше требования к частоте обновлений и количеству каналов, тем выше стоимость поддержки — условия фиксируются в договоре.

Disaster Recovery: RPO/RTO и бэкапы

Целевые показатели восстановления после аварий (RPO/RTO) фиксируются в SOW/DR-приложении только если бэкапы и аварийное восстановление входят в согласованный объём услуг. Значения RPO/RTO зависят от объёма данных и архитектуры и определяются после аудита.

Принципы, закрепляемые в SOW:

• RPO (Recovery Point Objective) и RTO (Recovery Time Objective) определяются по каждой системе после аудита и включают:
• состав данных и компонентов (БД, файловые хранилища, кэши, очереди и др.)
• метод бэкапов (полные / инкрементальные / дифференциальные)
• ретеншн (срок хранения)
• требования к консистентности (например, связка MySQL + Redis + MongoDB и пр.)
• порядок и периодичность тестового восстановления
• Если бэкапы выполняются стороной Заказчика:
• Исполнитель может настроить мониторинг/проверки факта выполнения бэкапов (по договору).
• Исполнитель может содействовать восстановлению во время инцидента (по договору).

Тестирование аварийного восстановления (Disaster Recovery Testing)

Мы рекомендуем регулярное тестирование процедур восстановления для подтверждения работоспособности бэкапов и корректности процесса восстановления. Бэкап, который ни разу не тестировался, не является надёжным бэкапом.

• Рекомендуемая частота: не реже 1 раза в месяц для продуктивных систем.
• Объём тестирования: тестирование восстановления должно охватывать как файловую систему, так и все базы данных (реляционные, NoSQL, кэши, очереди — по применимости).
• Стратегия тестовых данных: тестовые маркеры (конкретные записи или снимки данных) готовятся заранее и оставляются в системе на протяжении времени. Это позволяет проверить, что восстановление корректно работает как для старых данных, так и для недавних изменений — подтверждая отсутствие потерь данных в окне бэкапа.
• Среда тестирования: тесты восстановления проводятся на продуктивных бэкапах (восстановление в отдельную среду) для валидации реальных сценариев восстановления.
• Для критичных систем: интервал тестирования может быть сокращён (например, раз в 2 недели или еженедельно), если заказчик требует более высокого уровня уверенности и готов выделить бюджет на это.
• Частота и объём тестирования фиксируются в SOW / DR-приложении.

Уведомление об инцидентах безопасности (Security Breach Notification)

Для Enterprise-плана срок уведомления о подтверждённом инциденте безопасности фиксируется в договоре и по умолчанию составляет до 48 часов с момента подтверждения факта несанкционированного доступа или подтверждённой утечки данных.

Принципы, закрепляемые в SOW:

• Уведомление Заказчика: в течение 48 часов с момента подтверждения факта несанкционированного доступа или подтверждённой утечки данных.
• Более строгие сроки (например, 24 часа) могут быть согласованы отдельно с пересчётом стоимости.
• Канал уведомления: тикет-система + e-mail (и/или согласованный secure-канал).

Регулярные сервис-ревью (Service Review / QBR)

Для Enterprise-плана доступны регулярные сервис-ревью (QBR): анализ инцидентов, трендов, предложений по улучшению мониторинга и стабильности. Периодичность фиксируется в договоре.

Принципы, закрепляемые в SOW:

• Периодичность: ежеквартально (включено в Enterprise), ежемесячно (опционально, оплачивается отдельно).
• Входы: отчёт по тикетам, топ-инциденты, рекомендации и риски стабильности.
• Выходы: план действий, предложения по улучшению мониторинга, рекомендации по стабилизации/рефакторингу (как отдельный поток работ).

Онбординг требуется для надёжных целевых показателей поддержки

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

Чек-лист онбординга (минимум)

• Настройка доступов (продуктивная среда/логи/репозитории/CI/CD при необходимости).
• Обзор архитектуры и карта зависимостей (включая внешние сервисы).
• Определение критичных бизнес-сценариев и критичных страниц/эндпоинтов.
• Анализ истории инцидентов и известных слабых мест.
• Согласование объёма мониторинга и маршрутизации оповещений.

Глубина и длительность онбординга (диапазоны, не обещания)

• Небольшие типовые проекты (например, стандартные веб-приложения): первичная готовность может быть достигнута в течение первой недели.
• Сложные DevOps-окружения (контейнеры, Kubernetes, нетривиальный CI/CD): требуется больше времени и практическая проверка.
• Крупные корпоративные системы: онбординг и стабилизация могут занимать несколько месяцев. Полная ожидаемая работоспособность целевых показателей SLA достигается после выполнения предпосылок онбординга.

Ключевые принципы работы с legacy-системами

• Не является блокирующим фактором: унаследованный код — не причина отказываться от проекта. У нас есть опыт работы с унаследованными системами на различных технологических стеках и с разным уровнем технического долга.
• Честные ожидания: для унаследованных систем мы не можем обеспечить тот же уровень гарантий (время реакции, точность оценок, сроки восстановления), который обеспечиваем для систем собственной разработки. Разрыв зависит от: качества документации, тестового покрытия, ясности архитектуры, количества недокументированных зависимостей и доступа к знаниям оригинальной команды разработки.
• Онбординг критичен: для legacy-систем фаза онбординга длиннее и глубже. Она включает обследование архитектуры, картирование зависимостей, выявление недокументированного поведения и оценку рисков (см. «Онбординг для готовности поддержки»).
• Постепенное улучшение: мы рекомендуем и можем реализовать поэтапный подход к улучшению legacy-систем: сначала стабилизация (мониторинг, исправление критичных дефектов, тестовое покрытие ключевых сценариев), затем целевой рефакторинг и архитектурные улучшения как плановый поток работ.

Рекомендации заказчикам с legacy-системами

• Выделите бюджет на обследование: начальная фаза оценки необходима и не должна пропускаться. Она определяет реалистичные целевые показатели SLA и выявляет зоны наибольшего риска.
• Ожидайте скорректированных целевых показателей SLA: сроки восстановления и точность оценок для legacy-систем будут шире, чем для систем, которые мы контролируем от начала до конца. Скорректированные показатели фиксируются в SOW после онбординга.
• Инвестируйте в тестовое покрытие и документацию: самый быстрый способ вывести legacy-систему на более высокий уровень сервиса — увеличить автоматизированное тестовое покрытие критичных путей и создать операционную документацию.
• Рассмотрите план рефакторинга: мы предоставляем рекомендации по приоритетам рефакторинга на основе бизнес-влияния, рисков стабильности и стоимости. Рефакторинг ведётся как плановый поток работ, а не как устранение инцидента.

Документация архитектуры и база знаний

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

Снижение риска зависимости от ключевых лиц

• Для критичных проектов назначаются минимум два специалиста с пересекающимися областями знаний.
• Вовлечение техлида и/или CTO поддерживается для крупных проектов для обеспечения архитектурной непрерывности.
• Внутренний обмен знаниями — часть стандартного инженерного процесса (ревью кода, документация, совместная работа над сложными инцидентами).

Поддержка с использованием ИИ (опционально)

Инструменты анализа на базе ИИ могут использоваться для поддержки операций:

• Анализ кода, логов, интеграций, истории инцидентов.
• Все действия с использованием ИИ выполняются при участии специалиста (человек в контуре принятия решений).
• Влияние на скорость работы: в зависимости от типа проекта, сложности и критичности, использование ИИ-инструментов может ускорить рутинные инженерные задачи (анализ кода, ревью зависимостей, разбор логов, генерация документации, создание каркаса тестов) ориентировочно в 5–20 раз по сравнению с полностью ручным выполнением. Фактическое ускорение зависит от типа задачи и не является фиксированным гарантированным множителем; приводится как операционный ориентир на основе внутреннего опыта.

Использование ИИ — опционально и согласуется:

• Внешние ИИ-сервисы (облачные) используются только с явного согласия заказчика.
• Варианты: сервисы с размещением в ЕС/США, локальные модели на стороне заказчика или полный запрет использования ИИ.
• Полный запрет ИИ-инструментов возможен; это может повлиять на сроки и стоимость — фиксируется в SOW.

Онбординг нового члена команды (замена или расширение)

Время выхода нового специалиста на самостоятельную продуктивную работу зависит от ряда факторов:

• Сложность проекта: монолит vs. микросервисы, количество интеграций, глубина технологического стека.
• Срок работы с проектом: проекты, которые наша команда ведёт длительное время, имеют более качественную документацию и отлаженные процессы передачи знаний.
• Документация и тестовое покрытие: хорошо задокументированные проекты с высоким покрытием тестами позволяют быстрее вводить нового человека.
• Разрешение на ИИ-инструменты: если для проекта разрешены ИИ-инструменты анализа кода и документации, это ускоряет адаптацию.
• Размер и охват сервисов: количество сервисов, модулей и бизнес-доменов, с которыми инженеру предстоит работать.

Типичные сроки онбординга (операционный ориентир, не гарантия):

• Минимум: от 2 недель для хорошо задокументированных проектов с ограниченным объёмом.
• В среднем: около 3–4 недель для типичных проектов средней сложности.
• Сложные или унаследованные системы: может потребоваться больше времени, в зависимости от перечисленных факторов.

В период онбординга новый специалист работает под руководством техлида или старшего инженера для обеспечения качества и непрерывности.

Процедуры завершения сотрудничества

По завершении договора могут быть предоставлены по соглашению:

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

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