SLA хостинга 1С: что значат 99,9% и 99,99% простоя на практике

SLA с цифрой 99,9% выглядит солидно, но для сервера 1С это значит до девяти часов простоя в год — и провайдер обычно платит не за убытки, а возвращает часть абонентской платы. Для бухгалтерии важнее не процент аптайма, а время реакции на инцидент, срок восстановления базы из бэкапа и точное определение того, что вообще считается простоем.

что на самом деле означают 99%, 99,9% и 99,99% простоя

Провайдеры хостинга публикуют SLA в процентах, и на глаз 99% и 99,9% различаются едва заметно. В часах разница — в десять раз. При доступности 99% сервер вправе не отвечать почти четыре дня в году; для базы 1С, куда бухгалтерия заходит каждый рабочий день, это ощутимо. При 99,9% лимит падает до девяти часов в год, при 99,99% — меньше часа.

Важна не только цифра, но и точка измерения. Одни провайдеры считают аптайм сети и питания дата-центра, другие — доступность самой службы 1С на уровне приложения. Первое почти всегда даёт красивые 99,99%, потому что электричество действительно редко пропадает. Второе учитывает зависания службы 1С, переполнение диска логами и прочие сбои, которые реально останавливают работу бухгалтерии, — и там цифра обычно скромнее.

Ещё один нюанс — плановые технические работы. У многих провайдеров окно на обновление оборудования или миграцию попросту не входит в расчёт SLA: если в договоре есть фраза про «регламентные работы, о которых оповещают за сутки», эти часы можно смело вычитать из красивого процента. На бумаге доступность 99,9%, а по факту — ещё плюс несколько часов планового простоя в квартал, которые в статистику не попадают. И даже 99,99% в договоре не спасает, если авария случилась именно 1 числа месяца, когда база нужна всем сразу.

1 число, 9:07 утра: как выглядит простой на практике

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

IT-отдел эскалирует заявку, инженер провайдера подтверждает: идёт восстановление после сбоя дисковой подсистемы. Сервис поднимается к 12:40 — спустя три с половиной часа после первого симптома. В договоре указано время реакции — скажем, два часа. Формально провайдер укладывается: первый ответ пришёл через час пятьдесят. Но для бухгалтерии эти часы — не абстрактный пункт SLA, а прямая угроза сорвать срок сдачи отчёта, который отсчитывается не от момента ответа поддержки, а от полуночи.

Провайдер формально не нарушил SLA: простой уложился в квартальный лимит для 99,9%. Но бухгалтерии эта арифметика ничего не объясняет — половина документов, которые вводили с утра, потерялась из-за отката к последней ночной резервной копии: глубину потерь (RPO) в договоре просто не оговаривали. Компенсация, которую в итоге получила компания, — возврат части абонентской платы за сутки простоя. Час работы бухгалтера, потраченный вечером на пересчёт НДС вручную, стоит дороже. А штраф за просрочку декларации, случись он на самом деле, обошёлся бы ещё дороже.

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

четыре цифры в SLA, которые весят больше процента аптайма

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

• ✓время реакции — срок от заявки до первого ответа инженера; если в договоре написано «в кратчайшие сроки» вместо конкретного числа часов, это формулировка ни о чём, а не обязательство;
• ✓RTO — за сколько сервер поднимут после аварии из резервной копии: час это или шесть, зависит не от процента доступности, а от того, где физически хранится копия базы;
• ✓RPO — на какую глубину теряются данные при восстановлении: бэкап раз в сутки означает, что авария в 17:00 стоит бухгалтерии целого рабочего дня документов;
• ✓формула компенсации — обычно провайдер возвращает часть абонентской платы пропорционально часам простоя сверх лимита, а не всю сумму за месяц, и точно не покрывает упущенное время сотрудников.

RTO и RPO работают в паре: RTO отвечает на вопрос «когда снова будет доступ», RPO — «сколько данных потеряно к этому моменту». Договор, где прописан только один из двух показателей, описывает половину картины. Ни один из этих пунктов не сводится к проценту доступности — и поэтому их редко выносят на первую страницу презентации хостинга.

выделенный сервер, виртуальный или общий тариф — где SLA работает не только на бумаге

Формат аренды сервера напрямую определяет, какой RTO вообще физически достижим — вне зависимости от того, что написано в типовом SLA. На публичном общем хостинге доступность формально существует, но действует на уровне площадки в целом: если сосед по серверу утилизирует диск во время своего резервного копирования, база 1С тормозит, а простоя как такового нет — сервис отвечает, просто медленно.

Виртуальный сервер для 1С с выделенными ресурсами убирает эту зависимость: процессор и память закреплены только за вашей базой, и SLA считается по реальному ответу сервиса, а не по факту «сервер включён». Для баз с несколькими сотнями одновременных пользователей или под 1С:ERP смысл сразу смотреть на выделенный сервер в аренду: там RTO считается в минутах, потому что резервная копия хранится на отдельном оборудовании, а не в общем хранилище провайдера.

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

кто отвечает за регламентные операции

SLA держится не только на железе. Настройка сервера 1С — регламентные задания, расписание резервного копирования, обновление платформы — определяет, сработает ли восстановление за обещанные часы или растянется на сутки из-за забытого расписания бэкапов. Если в договоре аренды не прописано, кто именно следит за этими задачами, RTO из таблицы SLA остаётся цифрой без исполнителя.

пять вопросов, которые стоит задать до подписания SLA

Эти вопросы проясняют, сколько в SLA реального содержания, а сколько — маркетинга.

1. ✓что именно измеряется — доступность сети и питания или доступность самой службы 1С;
2. ✓входят ли плановые технические работы в расчёт простоя или идут отдельной строкой;
3. ✓сколько раз в сутки снимается резервная копия базы и где она физически хранится;
4. ✓какой RTO гарантирован письменно, а не «в разумные сроки»;
5. ✓как считается компенсация — по часам простоя сверх лимита или фиксированной суммой вне зависимости от масштаба сбоя.

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

как мы формулируем SLA для серверов 1С

Мы указываем в договоре конкретное время реакции на инцидент и RTO для восстановления из резервной копии, а не общую фразу про доступность. Аренда сервера 1С начинается от 1 100 ₽/мес за пользователя, сопровождение и работа системного администратора — 3 800 рублей в час, и это включает настройку регламентных заданий и расписания бэкапов, а не только реакцию на уже случившийся сбой.

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

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

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

Что провайдер считает простоем по SLA — весь сервер или конкретную базу 1С?

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

Что компания получит, если провайдер нарушит SLA?

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

Чем SLA виртуального сервера для 1С отличается от выделенного?

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

Как часто должны делать резервные копии базы 1С и что такое RPO?

RPO — это максимальный объём данных, который бизнес готов потерять при сбое, выраженный во времени. Бэкап раз в сутки даёт RPO до 24 часов: авария вечером стоит компании целого рабочего дня документов. Для 1С разумный ориентир — несколько копий в сутки.

Можно ли прописать индивидуальный SLA под 1С:ERP на несколько сотен пользователей?

Да, для нагруженных конфигураций вроде 1С:ERP SLA обычно составляют отдельно: время реакции короче, RTO считается в минутах, а сервер размещают на выделенном оборудовании без соседей по ресурсам. Такие условия обсуждают до заключения договора, а не берут из типового прайса.