Соглашение об уровне сервиса — это единственный документ, который отвечает на вопрос «за что мы платим каждый месяц, когда все работает». Плохо составленный, он не гарантирует ничего и при этом выглядит солидно.
Разберем по пунктам, что в нем должно быть, какие формулировки бесполезны и где обычно закапывается несогласие сторон. Все примеры ниже проверяются на любом предложении за полчаса чтения.
Реакция и восстановление: разные вещи
Главная подмена, на которой строится большинство красивых обещаний. Время реакции — это срок, за который подрядчик подтвердил, что принял заявку и начал работать. Время восстановления — срок, за который сервис снова работает.
Обещать пятнадцать минут реакции легко и почти ничего не стоит. Обещать четыре часа восстановления — обязательство, которое требует дежурства, мониторинга, документации и запасных решений.
Хороший договор содержит оба параметра, и разговор о цене идет именно вокруг второго. Если в предложении указана только реакция, вы покупаете вежливость. Работоспособность систем в такой договор не входит.
Отдельно проговаривается, откуда считается время: с момента регистрации заявки в системе, с момента звонка, с момента срабатывания мониторинга. Разница в трактовке дает часы спора при разборе инцидента, поэтому источник отсчета фиксируется прямо в тексте приложения.
Классы инцидентов: как договориться заранее
Без классификации любой спор сводится к «для нас это критично» против «это рядовая задача». Классы должны определяться по наблюдаемым признакам, эмоции заявителя тут плохой критерий.
| Класс | Признак | Пример | Реакция и восстановление |
|---|---|---|---|
| Критический | Бизнес-процесс полностью остановлен | Учетная система недоступна, отгрузки встали | Реакция минуты, восстановление часы |
| Высокий | Процесс работает частично, есть обходной путь | Не печатаются документы одного вида | Реакция час, восстановление рабочий день |
| Обычный | Неудобство без остановки работы | Медленно открывается отчет | Реакция рабочий день, восстановление несколько дней |
| Плановая задача | Изменение по запросу | Завести пользователя, настроить доступ | По согласованному графику |
Важная деталь: класс присваивается по влиянию на бизнес, а определяет его заявитель при регистрации. Подрядчик может оспорить класс, но обязан начать работать по заявленному. Обратный порядок превращает регистрацию заявки в переговоры, а это последнее, чем стоит заниматься в момент остановки отгрузок.
Что не входит: главный признак честного договора
Список исключений выглядит как попытка подрядчика уйти от ответственности, а на деле показывает, что человек понимает, о чем говорит.
Из-под гарантий обычно выводятся: сбои по вине поставщика связи и хостинга, последствия действий сотрудников заказчика с административными правами, аварии на оборудовании, которое подрядчик не обслуживает, форс-мажор, работы, которые заказчик запретил делать, проблемы систем вне периметра договора.
Отдельно стоит проговорить ситуацию, когда авария вызвана рекомендацией, которую подрядчик дал, а заказчик отклонил. Такие случаи стоит фиксировать письменно в момент отказа: постфактум доказать ничего не выйдет.
Если в предложенном договоре исключений нет вообще, это не щедрость. Это означает, что при первой же аварии начнется спор, и позиция будет определяться не документом, а настойчивостью сторон.
Окна работ и кто их согласует
Обновления, перезагрузки, миграции требуют технологических окон. Без их описания вы получите либо остановку в разгар рабочего дня, либо систему, которая годами не обновляется, потому что удобного момента нет никогда. Второй вариант встречается чаще и заканчивается тем, что обновление делается в авральном режиме после инцидента.
В договоре фиксируется: типовое окно для плановых работ, срок предупреждения, порядок согласования внепланового окна и правило для критичных обновлений безопасности, которые ждать не могут.
Практичная схема для большинства компаний — окно раз в месяц в выходной день с предупреждением за неделю. Плюс отдельная процедура для срочных случаев с согласованием по телефону и последующим письменным подтверждением.
Эскалация: что происходит, когда все идет плохо
Инциденты, которые не решаются за отведенное время, случаются у всех. Вопрос в том, описан ли порядок действий.
Нормальная схема эскалации содержит три уровня. Первый — инженер, который работает с заявкой. Второй — руководитель направления, подключается при превышении времени восстановления. Третий — руководитель подрядчика и ваш ответственный, включается при критическом инциденте длиннее нескольких часов.
У каждого уровня должны быть имя, телефон и понятный триггер подключения. Без этого эскалация выглядит как звонок кому попало в надежде, что кто-то ответит.
Отдельно опишите порядок коммуникации при затяжной аварии: как часто подрядчик обязан сообщать статус, даже если новостей нет. Пятнадцать минут молчания во время простоя ощущаются как час. Разумная норма — обновление статуса каждые тридцать минут при критическом инциденте, даже если единственная новость в том, что причина еще не найдена.
Доступность: как ее считают
Цифры доступности любят указывать в процентах, но без описания метода расчета они бессмысленны.
Договориться надо о трех вещах. Первое: что именно считается недоступностью — полный отказ или деградация, при которой работать невозможно. Второе: в каком окне считается — только рабочее время или круглосуточно. Третье: что исключается из расчета — плановые окна, сбои по вине третьих сторон, простои по вине заказчика.
Практический совет: для большинства компаний полезнее договориться о максимальной длительности одного простоя и о числе инцидентов за период, а процент доступности оставить в стороне. Эти параметры понятны, проверяемы и напрямую отражают то, что чувствует бизнес.
Отчетность: как проверить, что работа велась
Подписка отличается от разовых работ тем, что большую часть времени результат невидим. Отчет — единственный способ увидеть, что происходило.
В нормальном ежемесячном отчете есть: перечень инцидентов с классами, временем реакции и восстановления; выполненные плановые работы; результаты тестовых восстановлений из копий; замечания и риски, которые видит подрядчик; план на следующий период.
Последние два пункта важнее остальных. Подрядчик, который каждый месяц пишет «все стабильно», либо не смотрит, либо не хочет поднимать неудобные темы. Инфраструктура — живой организм, в ней всегда есть что улучшить.
Отчет должен приходить сам и в согласованный срок, обычно до десятого числа следующего месяца. Если за ним надо напоминать, это отдельный сигнал о состоянии отношений.
Почему круглосуточно только после трех месяцев
Мы принципиально не даем круглосуточный режим сразу, и это стоит объяснить, потому что звучит как отказ от денег.
Ночной инцидент требует не готовности отвечать на звонки, а способности починить систему быстро. Для этого нужны документация по вашему контуру, настроенный мониторинг с понятными сигналами, отработанные сценарии типовых аварий и понимание, что критично, а что подождет до утра.
Всего этого не существует в первый месяц работы. Дежурный, разбуженный в три часа ночи и впервые открывающий вашу инфраструктуру, сделает хуже, чем спокойное восстановление утром.
За три месяца обычной эксплуатации собирается все необходимое, и тогда круглосуточный режим становится обязательством, которое можно выполнять. Компании, обещающие его с первого дня, либо имеют готовый шаблон вашей инфраструктуры, либо продают вам ощущение защищенности.
Как считается загрузка и что такое «включено»
Вторая после времени восстановления причина взаимного недовольства: заказчик считает, что оплатил безлимитную помощь, подрядчик — что оплачено конкретное обслуживание.
Есть три подхода. Первый: подписка покрывает эксплуатацию, а изменения по запросу считаются отдельно по ставке. Второй: в подписку входит пакет часов на изменения, сверх пакета — по ставке. Третий: безлимит, который на практике существует только у мелких контуров, потому что иначе подрядчик разоряется или начинает саботировать заявки.
Работающая формулировка выглядит так: эксплуатация, мониторинг, инциденты и плановые работы входят в подписку без ограничения по количеству; развитие, внедрение новых систем и проекты считаются отдельно. Граница между инцидентом и развитием проводится по признаку «восстановить как было» против «сделать по-новому».
Эта граница спорная по природе, и в договоре стоит указать, кто разрешает спор: обычно это ответственные с обеих сторон на ежемесячной встрече. Практика показывает, что при нормальных отношениях таких споров единицы, а при плохих никакая формулировка не спасет.
Что заказчик обязан со своей стороны
Соглашение работает в обе стороны, и обязательства заказчика в нем тоже должны быть, иначе подрядчик физически не сможет выполнить свои.
Нужен доступ: постоянный и заранее выданный, а не запрашиваемый в момент аварии. Нужен ответственный, который принимает решения по вопросам, требующим согласования. Нужна возможность проводить работы в согласованные окна. Нужна информация об изменениях, которые заказчик делает сам: новый сотрудник с административными правами, купленное оборудование, установленная программа.
Отдельный пункт — административные права у сотрудников заказчика. Если они есть у нескольких человек, гарантировать состояние систем невозможно, и это надо либо ограничить, либо честно вынести в исключения.
Границы периметра
Пункт, из-за которого чаще всего возникают конфликты между несколькими подрядчиками.
В договоре перечисляется, какие системы обслуживаются: конкретные серверы, базы, сервисы, оборудование. Все, чего в списке нет, за периметром. Отдельно фиксируется, кто отвечает за стыки: например, учетную систему обслуживаем мы, а методологию учета ведет франчайзи, и вопрос неверной проводки идет к нему.
Наш периметр по подписке на инфраструктуру: серверы и виртуализация, базы данных, резервное копирование, мониторинг, сеть внутри контура, эксплуатация прикладных систем. Вне периметра: рабочие места пользователей, принтеры, выезды, лицензируемая защита информации, методология учета.
Тарифы зависят от объема контура: 60 000 ₽ в месяц для небольшой инфраструктуры, 120 000 ₽ для средней, 300 000 ₽ для распределенной с несколькими площадками. Вход — аудит от 90 000 ₽, по результатам которого периметр и уровни фиксируются в приложении.
Как выглядит первый месяц по договору
Полезно понимать, что происходит сразу после подписания, потому что ожидания здесь часто расходятся.
Первая неделя уходит на прием инфраструктуры: доступы, инвентаризация, проверка резервных копий, установка мониторинга. Никакого «мы сразу все починим» — сначала надо увидеть, что вообще есть. Как устроена такая приемка подробно, разобрано в материале про прием сервиса на поддержку.
Вторая и третья недели — закрытие критичных находок: то, что может упасть завтра. Обычно это копии, которые не проверялись, отсутствие мониторинга, просроченные сертификаты, диски на пределе, забытые учетные записи уволенных сотрудников.
Четвертая неделя — первый отчет и план на следующий период. К этому моменту становится понятен реальный объем работ, и иногда именно здесь корректируется тариф: если контур оказался вдвое больше заявленного, честнее пересмотреть условия сразу, чем экономить на качестве весь год.
Пункты, которых быть не должно
Формулировки, при виде которых стоит задать вопросы.
«Подрядчик прилагает разумные усилия». Юридически это означает отсутствие обязательства. Разумность каждый понимает по-своему.
«Время восстановления определяется сложностью инцидента». То же самое другими словами: срок не назван.
«Все работы по системам заказчика». Без перечня периметра это одновременно обещание всего и ничего.
Отсутствие пункта о передаче дел. В договоре должен быть описан порядок возврата доступов, документации и знаний при расторжении, с конкретным сроком. Как выглядит нормальная передача, разобрано в статье про приемку сервиса.
Штрафы: работают ли они
Вопрос, который задают почти всегда: можно ли прописать неустойку за нарушение сроков восстановления. Можно, и иногда это уместно, но эффект обычно переоценивают.
Штраф в размере части месячной подписки не компенсирует простой производства: цена часа простоя у среднего предприятия выше, чем весь месячный платеж. То есть неустойка работает как сигнал о серьезности намерений, а компенсацией ущерба она не является.
Второй эффект штрафов менее приятный: подрядчик начинает защищаться. Растет доля времени на переписку и обоснования, инциденты классифицируются консервативно, любая просьба вне договора встречает отказ. Отношения из рабочих превращаются в юридические.
Разумный компромисс, который мы используем: вместо штрафов — прозрачная отчетность и право заказчика расторгнуть договор без объяснения причин с коротким уведомлением. Это дисциплинирует сильнее неустойки и не портит работу.
Если бизнес критичен настолько, что простой действительно недопустим, правильный ответ лежит в архитектуре: резервирование, запасные контуры, отработанные сценарии переключения. Договорными формулировками эту задачу не закрыть. Это стоит заметных денег и обсуждается отдельно от подписки, зато дает результат, которого не даст ни один пункт про неустойку. Технические участки, с которых начинается такая работа, разобраны в статье про резервное копирование.
Шаблон приложения: минимальный состав
- Перечень обслуживаемых систем с указанием ответственных с обеих сторон.
- Классы инцидентов с признаками и примерами.
- Время реакции и время восстановления по каждому классу.
- График обслуживания: рабочее время, дежурства, праздничные дни.
- Технологические окна и порядок их согласования.
- Схема эскалации с именами и телефонами.
- Список исключений.
- Состав и срок ежемесячного отчета.
- Порядок изменения объема услуг и пересмотра стоимости.
- Порядок передачи дел при расторжении и срок.
Десять пунктов помещаются на две страницы и снимают девять из десяти будущих споров. Полезно перечитать это приложение через полгода работы: практика всегда вносит поправки, и документ, который живет вместе с отношениями, работает лучше идеального, но забытого. Что входит в наш периметр и как устроен вход — на странице аутсорсинга ИТ-инфраструктуры, а сравнение схем обслуживания по деньгам — в разборе стоимости года.