Ежегодная сверка договора и SLA с хостером: что изменилось за год

MAATRIX

Договор и SLA с хостером обычно читают один раз — в день, когда подписывают, — и потом больше не открывают, пока не случится авария. За это время провайдер вполне мог обновить публичную оферту, изменить формулировки про гарантии доступности или добавить новые ограничения в политику использования, а письмо с уведомлением об этом ушло на «личный кабинет» и утонуло среди остальной почты. Ежегодная сверка — не про подпись под новым документом, а про то, чтобы один раз в год потратить полчаса и убедиться, что вы всё ещё точно знаете, на каких условиях работаете.

Зачем перечитывать документ, который вы уже читали

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

Три типа изменений, которые проходят мимо внимания чаще всего:

• Изменилась политика провайдера, которую вы никогда специально не искали — новые правила по резервному копированию (кто отвечает за бэкапы: вы или провайдер), обновлённые условия по хранению данных после расторжения, изменения в политике допустимого использования (Acceptable Use Policy), которые раньше не касались вашего сценария использования, а теперь касаются.
• Изменились гарантии доступности — процент в SLA мог остаться тем же на бумаге, а вот методика его расчёта или список исключений (плановые работы, форс-мажор, действия третьих сторон) — расшириться незаметно.
• Появились новые ограничения, которых не было год назад — лимиты на исходящий трафик, ограничения на типы нагрузки, изменившиеся условия по количеству одновременных подключений или ресурсоёмких процессов, которые раньше нигде не были прописаны явно.

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

Если вы ни разу не проводили даже первичный разбор договора — прежде чем переходить к ежегодной сверке, стоит один раз пройтись по базовому чеклисту: на что смотреть в договоре с хостером до подписания описывает семь пунктов, которые формируют тот самый список «что вообще нужно проверять» — ежегодная сверка дальше работает с этим списком, а не изобретает его заново.

Что могло измениться за год — конкретный список

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

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

Практический подход: перечитать, сравнить, зафиксировать разницу

Сама процедура сверки строится на трёх шагах, и ни один из них не требует юридического образования — речь идёт о внимательном чтении, а не о правовом анализе.

Шаг первый — найти актуальную версию документа. Не ту, что вы сохранили год назад в PDF, а текущую, опубликованную прямо сейчас. У большинства провайдеров это страница вида /legal/terms-of-service, /legal/sla или раздел «Договор» / «Публичная оферта» в личном кабинете. Если провайдер публикует историю изменений или changelog документа — это значительно ускоряет сверку, потому что можно сразу посмотреть на список правок, а не сравнивать весь текст целиком.

Проверьте эти разделы сайта провайдера в первую очередь:
- /legal/terms  или  /legal/tos  или  /oferta
- /legal/sla    или  /sla        или  раздел SLA в договоре
- /legal/aup    или  /legal/acceptable-use
- /legal/privacy (если работаете с персональными данными клиентов)

Шаг второй — сравнить с тем, что вы помните с прошлого раза. Здесь ключевое слово — «помните», и именно поэтому важен третий шаг ниже: человеческая память ненадёжна, особенно если с прошлой сверки прошёл год и произошло много других событий. Если по итогам прошлогодней сверки не осталось никаких записей — заметок, скриншотов, сохранённой версии документа, — сравнивать физически не с чем, и вся сверка сводится к первому прочтению документа с нуля. Именно поэтому свою версию для сравнения нужно сохранять сразу после каждой сверки, а не пытаться её реконструировать по памяти через год.

Практический способ сравнения, если старой версии нет под рукой, а провайдер не публикует историю изменений: воспользоваться веб-архивом.

# Проверить, есть ли в архиве снимок страницы годовой давности
https://web.archive.org/web/20250801000000*/example-hoster.com/legal/sla

# Если снимок есть — открыть и сравнить текст построчно
# с текущей версией страницы вручную

Метод не идеальный — не все страницы попадают в архив вовремя, а некоторые провайдеры закрывают юридические страницы от индексации, — но как аварийный вариант он работает.

Шаг третий — зафиксировать различия отдельным списком. Не обязательно юридически точным языком — достаточно простой заметки формата «было / стало» по каждому найденному изменению:

Сверка договора и SLA — [дата]

- SLA: было 99.9%, стало 99.95% — улучшение, проверить методику расчёта
- Компенсация: раньше max 100% от месячной платы, теперь max 50% —
  ухудшение, требует внимания
- AUP: добавлен явный запрет на майнинг криптовалют на VPS-тарифах —
  не относится к нам, но зафиксировать
- Процедура claim: раньше через тикет, теперь только через отдельную
  форму на сайте — обновить внутренний регламент реагирования на инцидент

Такой список занимает пять минут на составление и экономит часы в следующем году — сравнивать придётся уже не «документ против смутной памяти», а «текущий документ против прошлогоднего списка изменений».

Пункты о компенсациях — где стоит быть особенно внимательным

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

Что именно проверять в этом разделе:

• Изменилась ли формула расчёта компенсации. Обычно это процент от ежемесячной платы, пропорциональный превышению допустимого простоя — но сам порог допустимого простоя, шкала процентов и потолок максимальной выплаты у разных версий документа могут отличаться заметно.
• Изменилась ли форма выплаты. Деньги на счёт и скидка на следующий период обслуживания — принципиально разные вещи, особенно если вы планируете уходить от провайдера: скидкой, которой вы не успеете воспользоваться, компенсация фактически не является. Подробный разбор того, почему даже честно рассчитанная компенсация по SLA обычно не покрывает реальные потери бизнеса от простоя, — в статье компенсация по SLA против реальных убытков.
• Не сузился ли список случаев, за которые компенсация вообще положена. Провайдеры регулярно добавляют новые исключения — плановые работы, проблемы у аплинков, форс-мажорные обстоятельства в расширенном толковании. Каждое новое исключение — потенциально ваш следующий инцидент, который просто не попадёт под действие SLA.
• Не изменилась ли методика измерения простоя. Кто и чьим мониторингом фиксирует факт простоя — принципиальный вопрос, разобранный подробно в статье SLA в договоре: как читать проценты и компенсации. Если год назад простой засчитывался по вашему обращению в поддержку, а теперь — исключительно по внутреннему мониторингу провайдера, это существенно меняет реальные шансы получить компенсацию.

Отдельно стоит свериться с самим процентом гарантии доступности буквально — не полагаясь на память о том, что «там вроде было 99.9», а посмотрев цифру в текущем документе построчно, потому что 99.9% и 99.95% на слух звучат почти одинаково, а по допустимому простою в месяц отличаются примерно в два раза.

Процедура получения компенсации: то, что чаще всего меняют незаметно

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

На что смотреть конкретно:

• Канал обращения. Раньше можно было написать в общий тикет поддержки — теперь требуется отдельная форма claim на сайте или обращение через специальный адрес, отличный от обычной техподдержки.
• Срок подачи заявки. Это один из самых критичных пунктов — если провайдер отводит на подачу заявки о нарушении SLA, скажем, 30 дней с момента инцидента, а вы узнали об этом сроке уже после того, как он прошёл, компенсация не будет выплачена по формальному основанию, даже если инцидент был бесспорным.
• Требуемые доказательства. Раньше могло быть достаточно факта обращения в поддержку с фиксацией времени — теперь может требоваться экспорт логов вашего независимого мониторинга с точными таймстампами. Если такого мониторинга нет, самое время его завести.
• Кто инициирует процесс. У части провайдеров компенсация начисляется автоматически по итогам месяца на основании их мониторинга, у других — только по вашему явному заявлению в установленный срок. Молчаливо ожидать автоматической компенсации там, где требуется заявление, — верный способ её не получить.

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

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

Ценность ежегодной сверки резко падает, если результат просто держится в голове до следующего раза — ровно то же самое ненадёжное «помню приблизительно», с которого начинался этот годовой цикл. Итог сверки стоит оформить так, чтобы через год открыть его и сразу увидеть, с чем сравнивать.

Минимальный набор, который стоит сохранить после каждой сверки:

/docs/hosting-compliance/
├── 2025-08-sla-dogovor-sverka.md   — список изменений и текущее состояние
├── 2025-08-dogovor-snapshot.pdf    — сохранённый снимок документа (печать в PDF)
├── 2025-08-sla-snapshot.pdf
└── 2026-08-sla-dogovor-sverka.md   — следующая сверка через год

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

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

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

Частые вопросы