avatar
Кучевые АйТи
@oblakoteka
09.09.2025 10:50
От звонка до лайка: опыт создания техподдержки. Часть 2

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

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

Сегодня наш директор техподдержки Ирина Курбатова рассказывает, к чему Облакотека пришла.

Как мы понимаем, что услуга доступна

Наши клиенты определили такие критерии:

Можно подключиться. Услуга отзывается с предусмотренными параметрами, это происходит с должной скоростью, и канал связи обеспечивает согласованную в SLA ширину полосы.
Производительность соответствует заявленным показателям. Например, для IaaS: производительность процессора, параметры дисков — скорость операций чтения/записи, задержка от запроса на операцию до ответа на нее, пропускная способность.
Можно самостоятельно управлять услугой. Остановить или возобновить работу, изменить параметры услуги — количество ресурсов, их тип, глубину бэкапа.
Удобно управлять дополнительными опциями. Речь про библиотеку образов, развертывание из шаблона, подключение инструментов безопасности и надежности и других функциях.

Как определяем гарантированный уровень доступности услуг

В Облакотеке почти везде этот показатель составляет 99,9%. Но все зависит от компонентов конкретной услуги. Например, гарантии могут быть ниже, если использовано прикладное ПО внешнего вендора или standalone-архитектура.

Мы все это описываем в приложении к типовому договору. А еще по запросу клиента подбираем решения с более высокой доступностью.

Почему проводим профилактические работы

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

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


Чтобы такие ситуации не влияли (или почти не влияли) на клиента, профилактические работы организовывают таким образом, чтобы:

время снижения производительности или недоступности не превышало 2 часов в месяц;
клиенты были предупреждены за 3 рабочих дня;
работы проводились по выходным, праздникам или в будни после 22.00 МСК.

Как рассчитываем фактическую доступность

Период расчета — календарный месяц. Берем промежуточные показатели:

А: количество минут в месяце, когда услуга была недоступна или ограниченно доступна. Этот показатель определяем по системам мониторинга и по обращениям клиентов.
В: сколько всего минут в месяце (зависит от количества дней).
С: доля времени недоступности услуги за период. То есть А разделить на В.

Доступность считаем по формуле: (1- С)*100%.

Если этот показатель оказывается менее гарантированного (обычно 99,9%), то превышение округляем до часов в большую сторону (в пользу клиента). За каждый час ​​недоступности возвращаем 1% стоимости услуги за месяц.

#Ирина_поддержи
8
7
❤‍🔥 5
1 1 617

Обсуждение 1

Обсуждение не доступно в веб-версии. Чтобы написать комментарий, перейдите в приложение Telegram.

Обсудить в Telegram