Технологии
Техническая поддержка сайтов: что входит в услугу, как определить SLA и зоны ответственности
Техническая поддержка сайта помогает обеспечить стабильную работу системы и заранее определить порядок действий при сбоях. Разбираем, что входит в услугу, как выбрать подходящий SLA и распределить зоны ответственности между заказчиком и подрядчиком.
После запуска сайта или веб-системы начинается эксплуатация: появляются обращения, обновления, изменения во внешних сервисах, иногда сбои. Пока всё работает штатно, формулировки вроде «исправляем ошибки», «реагируем на критичные обращения» или «поддерживаем интеграции» могут казаться однозначными.
При первом серьёзном сбое может выясниться, что заказчик и подрядчик по-разному представляют порядок действий: например, насколько быстро нужно подключиться к проблеме, кто должен искать её причину и что делать, если перестали работать внешние интеграции или недоступен весь сервис.
Поэтому условия технической поддержки необходимо определить заранее: что именно входит в услугу, какой уровень сервиса нужен и где проходят границы ответственности между заказчиком, подрядчиком и владельцами внешних систем.
Что входит в техническую поддержку сайта
Техническая поддержка сайта – услуга, которая помогает сохранять работоспособность проекта после запуска и решать возникающие в процессе эксплуатации технические задачи. Конкретный состав работ зависит от самого проекта и условий договора.
В рамках поддержки команда устраняет ошибки и разбирается со сбоями, связанными с внешними сервисами. Отдельно в договор могут входить мониторинг, обновления и небольшие технические изменения.
У простого корпоративного сайта задач обычно меньше. В сложной веб-системе отдельно приходится работать с серверной частью и базами данных. Также нужно учитывать интеграции и фоновые процессы.
При этом важно не смешивать поддержку и развитие системы. Если после обновления перестала работать форма, это инцидент, который нужно диагностировать и устранить. Если бизнес хочет изменить логику формы, добавить новые поля или перестроить маршрут заявки, речь уже идёт о развитии.
В техническое обслуживание сайта входят регулярные работы, которые выполняются до появления сбоев. Например, обновление компонентов, проверка сертификатов и резервных копий.
Техническое сопровождение сайта – более широкое понятие. В него может входить и поддержка текущей работы, и плановые изменения. Поэтому лучше сразу прописать в договоре, какие задачи относятся к поддержке, а какие – к развитию.
Чем гарантия на сайт отличается от технической поддержки
Гарантия и техническая поддержка – не одно и то же. В гарантийный срок подрядчик отвечает за качество уже выполненных работ в пределах условий договора. Техническая поддержка нужна для текущей работы сайта. Это могут быть новые технические задачи или сбои, которые не относятся к гарантии.
Например, после запуска обнаружилась ошибка в функции, которую сделал подрядчик. Если причина в недостатке выполненных работ и гарантийный срок действует, это гарантийный случай. А изменение API внешнего сервиса или новая логика работы системы к гарантии уже могут не относиться.
Условия технической поддержки лучше определить ещё до запуска сайта и начать её сразу после релиза. Ждать окончания гарантийного срока для этого не нужно: гарантия и поддержка решают разные задачи.
Если гарантию и поддержку ведут разные подрядчики, лучше заранее договориться о порядке действий. Например, кто разбирается в причине сбоя и как передаёт информацию второй команде.
Что такое SLA технической поддержки и что в нём фиксируют
SLA – это соглашение между заказчиком и исполнителем, в котором зафиксированы измеримые параметры сервиса. Для поддержки прежде всего определяют режим работы и время реакции. Отдельно договариваются, какие обращения считать критичными и как передавать проблему дальше, если для её решения нужно подключить другого специалиста или команду.
Если в SLA написано «реакция на критичный инцидент – 15 минут», но не определено, что считается критичным инцидентом, заказчик и подрядчик могут понимать условие по-разному.
Поэтому в SLA обычно фиксируют:
- что именно находится на поддержке;
- режим работы;
- уровни критичности и время реакции для каждого из них;
- каналы для обращений и порядок эскалации;
- случаи, когда отсчёт времени приостанавливается, например пока команда ждёт доступ или информацию от заказчика;
- зоны ответственности.
Если подрядчик отвечает ещё и за инфраструктуру или доступность конкретного сервиса, для них можно отдельно определить нужные показатели.
Как определить подходящий уровень SLA
Чтобы выбрать подходящий уровень SLA, сначала надо понять, какой простой бизнес может себе позволить. Что произойдёт, если сайт или конкретная функция не будут работать час? А если четыре часа?
Для корпоративного сайта с информацией об услугах отказ отдельной страницы и полная недоступность системы онлайн-бронирования – разные по последствиям ситуации. В первом случае основной процесс может продолжаться. Во втором пользователи вообще не смогут выполнить нужное действие.
Важно и то, когда используется система. Если через неё круглосуточно проходят заказы или платежи, поддержка может понадобиться ночью и в выходные. Для информационного сайта такой режим часто не нужен.
Чем быстрее должна реагировать поддержка, тем дороже обходится такой режим. Особенно если команда должна быть на связи ночью, в выходные и праздники. Поэтому самый быстрый SLA нужен не каждому проекту.
Как определить уровень критичности инцидента
Уровень критичности показывает, насколько сильно инцидент влияет на работу системы, пользователей и бизнес-процессы. При оценке важны последствия сбоя и возможность продолжить работу другим способом.
Критичность и приоритет – не одно и то же. Критичность показывает последствия технической проблемы. Приоритет определяет, насколько срочно конкретную задачу нужно взять в работу с учётом текущей ситуации в бизнесе.
Например, небольшая ошибка в тексте на главной странице почти не влияет на работоспособность системы. Но перед запуском крупной рекламной кампании её исправление может получить высокий приоритет.
Пример SLA для технической поддержки
| Уровень | Что произошло | Требование к реакции | Что происходит дальше |
|---|---|---|---|
| Критический | Система недоступна или остановлен ключевой процесс, обходного пути нет | Минимальный срок реакции по договору | Команда сразу начинает диагностику и восстановление |
| Высокий | Существенно нарушена важная функция | Сокращённый срок реакции | Команда определяет масштаб проблемы и ищет решение или обходной сценарий |
| Средний | Проблема есть, но работу можно продолжать | Стандартный срок реакции | Исправление планируется в обычном порядке |
| Низкий | Основные сценарии не нарушены | Плановый режим | Задача ставится в очередь |
Конкретные сроки зависят от проекта. Универсального SLA для корпоративного сайта, интернет-магазина и внутренней веб-системы нет.
Время реакции и время решения – не одно и то же
Если в соглашении указано время реакции 30 минут, это не означает, что через 30 минут система будет полностью восстановлена. Сначала команде нужно принять обращение в работу и найти причину сбоя.
Дальше процесс может выглядеть так:
обращение → реакция → диагностика → восстановление критичной функции или временный обходной сценарий → устранение причины.
Время реакции – срок, за который поддержка должна начать работу с обращением.
Время решения – срок до устранения проблемы или другого заранее согласованного результата.
Для типовой проблемы срок решения иногда понятен заранее. Со сложным сбоем иначе: сначала надо найти причину. Например, одна и та же ошибка может оказаться проблемой в коде, инфраструктуре или внешнем сервисе, и от этого уже зависит срок исправления.
Поэтому SLA по времени реакции зафиксировать проще, чем обещать одинаковое время полного устранения любой проблемы.
Как распределить зоны ответственности между заказчиком и подрядчиком
Даже простой сайт редко работает сам по себе. Есть инфраструктура, домен, внешние сервисы и интеграции. Поэтому заранее надо понять, за какую часть отвечает подрядчик, за какую – заказчик, а где подключается сторонний поставщик.
Пример карты ответственности
| Компонент | Что нужно определить |
|---|---|
| Код сайта или веб-системы | Кто вносит изменения и исправляет ошибки |
| Серверы и облачная инфраструктура | Кто администрирует и общается с провайдером |
| База данных | Кто отвечает за доступы и восстановление |
| Домен и DNS | У кого есть доступ к аккаунту регистратора и DNS-настройкам |
| SSL-сертификаты | Кто следит за выпуском и продлением |
| CRM, ERP, 1С | Где проходит граница между сайтом и внешней системой |
| Платёжные сервисы | Кто проверяет интеграцию и общается с провайдером |
| Внешние API | Кто отслеживает изменения API и реагирует на сбои внешнего сервиса |
| Резервные копии | Кто создаёт, хранит и проверяет копии |
| Доступы | Кто выдаёт и отзывает права |
Особенно важно договориться о стыках между несколькими командами. Иначе часть времени при сбое уйдёт на выяснение, кто должен разбираться дальше.
Если проблема возникла во внешней системе
Если пользователь не может провести оплату, проблема не обязательно в самом сайте. Сначала надо понять, где произошёл сбой: в интеграции или уже на стороне платёжного сервиса.
Если проблема находится у внешнего поставщика, подрядчик может проверить свою часть системы и передать ему данные для диагностики. Но устранить сбой в чужой инфраструктуре он не может. Поэтому ответственность за диагностику и ответственность за само исправление лучше разделять заранее.
Хорошая поддержка начинается до первого сбоя
При этом одного контроля доступности мало. Главная страница может открываться, а форма заявки – уже не работать. Поэтому для важных систем полезно следить именно за ключевыми пользовательскими сценариями.
Отдельно стоит следить за зависимостями. Библиотеки и фреймворки обновляются, отдельные версии перестают поддерживаться. Если такие изменения годами откладывать, очередная доработка может оказаться сложнее и дороже.
То же касается резервных копий. Важно не только создавать их, но и понимать, можно ли из них действительно восстановить систему.
Если одна и та же проблема регулярно возвращается, стоит искать её причину, а не каждый раз устранять последствия.
Поддержка сайта: стоимость и факторы, от которых она зависит
Стоимость поддержки сайта зависит от сложности системы и объёма работ. На неё влияют количество интеграций, состояние кода и документации, инфраструктура и нужный уровень SLA.
Имеет значение и роль самой системы в бизнесе. Корпоративный сайт с несколькими формами обратной связи и веб-система, через которую идут заказы или расчёты, по-разному переживут час простоя. Поэтому и условия поддержки у них будут разными.
Стоимость лучше оценивать после того, как понятны состав системы, критичные сценарии и зоны ответственности.
Архитектурная амнезия: почему компании помнят, что построили, но забывают зачем
Знать, из каких компонентов состоит система, недостаточно. Для безопасной поддержки и изменений важно понимать, почему команда когда-то выбрала именно такую архитектуру и какие ограничения учитывала.
Читать статью →
Что проверить перед передачей сайта на поддержку
Если поддержку принимает команда, которая не разрабатывала систему, одного архива с исходным кодом недостаточно. Даже документация не гарантирует, что новый подрядчик сможет сразу работать с проектом самостоятельно.
До старта надо понять, где находится инфраструктура и у кого есть доступы. Затем проверить, как выпускаются обновления и что происходит при неудачном релизе. Отдельно стоит разобраться с резервными копиями и внешними сервисами.
Документацию тоже нужно сверить с фактическим состоянием системы. Интеграции могли измениться, компоненты – обновиться, а часть решений могла вообще не попасть в описание.
Если проект ещё находится на гарантии у прежнего разработчика, надо отдельно договориться, как новая команда работает с такими случаями.
Проверка закончена не тогда, когда «все доступы получили», а когда команда может сама выпустить изменение, найти причину сбоя и восстановить систему.
Как сменить подрядчика и не остановить веб-систему
Разбираем, что нужно передать новой команде кроме исходного кода и документации и как проверить, что она действительно готова самостоятельно поддерживать систему.
Читать статью →
Когда технической поддержки уже недостаточно
Поддержка помогает сохранять работоспособность системы и решать текущие проблемы. Но она не должна бесконечно компенсировать ограничения архитектуры или устаревшего технологического стека.
Сам возраст проекта здесь мало о чём говорит. Система может работать много лет, получать обновления и нормально дорабатываться. В таком случае модернизация только из-за даты запуска не нужна.
Проблема начинается, когда почти каждая доработка требует обходных решений. Обновления становятся рискованными, новые интеграции приходится подстраивать под старые ограничения, а заметная часть бюджета уходит просто на сохранение текущей работоспособности.
Ещё один признак – одни и те же проблемы возвращаются снова. Тогда стоит оценивать уже не очередную заявку на поддержку, а состояние системы в целом.
Сколько стоит отложенная модернизация веб-системы
Разбираем, почему затраты на поддержку старой системы могут расти из года в год и как понять, когда точечных доработок уже недостаточно.
Читать статью →
Что зафиксировать до начала технической поддержки
Условия поддержки лучше определить ещё до запуска сайта, даже если после релиза действует гарантия. Тогда у заказчика и подрядчика не будет разных ожиданий по одним и тем же задачам.
Перед стартом стоит проверить:
Что именно находится на поддержке.
Какие работы входят в услугу, а какие оцениваются отдельно.
Когда начинается поддержка и как она работает параллельно с гарантией.
Какие функции и бизнес-сценарии считаются критичными.
Какие уровни критичности используются и какое время реакции установлено для каждого.
В какие дни и часы действует SLA.
Как создаются обращения и как происходит эскалация.
Где проходят зоны ответственности заказчика, подрядчика и внешних поставщиков.
Какие профилактические работы входят в поддержку.
Кто отвечает за резервное копирование и восстановление.
Как согласовываются задачи по развитию системы.
Как действуют команды, если гарантия и поддержка находятся у разных подрядчиков.
Чем меньше таких договорённостей остаётся «понятными по умолчанию», тем меньше времени придётся тратить на выяснение ответственности уже во время сбоя.
Техническая поддержка и развитие веб-систем в DIGITAL SECTOR
DIGITAL SECTOR занимается технической поддержкой и развитием веб-систем после запуска. Состав работ зависит от проекта и может включать сопровождение действующей системы, устранение инцидентов, плановые технические работы и дальнейшее развитие.
Если нужно подключить поддержку к уже работающей системе или заранее продумать её после запуска нового проекта, обсудим состав работ, подходящий SLA и зоны ответственности.
Согласен