Pull to refresh

Service Level Agreement: пишем SLA для… других, или заключение SLA с Оператором связи

Reading time4 min
Views5.1K
Уверен, что многие хабражители хоть раз в жизни занимались вопросом обеспечения услугами связи для какой нибудь конторы или компании (собственное жилище тоже считается), все мы когда-то, увы не всегда вдумчиво, «подмахивали» договор на услуги связи, надеясь, что все будет хорошо/качественно/стабильно.

В половине случаев качество предоставляемых услуг связи приемлемо, но есть и ситуации когда такие услуги надо регулировать и заключать с Операторами СУО (SLA). Операторы идут на это неохотно, утверждая, что таких процедур у них нет, это отклонение от стандартных условий и «да что вы переживаете — у нас никто не жалуется».

В таких случаях приходится брать инициативу в свои руки и писать процедуру SLA за Оператора, а потом мучительно согласовывать ее и выбивать нужные условия. Тем, кому приходилось, или ещё придется заниматься данным видом литературного рабства — welcome, тема скучноватая, но деваться от этого некуда…

КДПВ

Ах как было бы прекрасно, если бы Операторы работали исключительно ответственно, техника никогда бы не ломалась, а если и ломалась — то регенерировала самостоятельно в кратчайшие сроки. Увы, чтобы все это именно так и работало нужен SLA c Оператором… Про SLA на Хабре есть удачные статьи, а есть менее удачные (IMHO), но часто они обращены на внутренние процессы компании, или описаны общими словами, а нам же дело иметь с Оператором связи, что он нам по этому вопросу предложит? Давайте сегодня говорим про фиксированную связь…

А предлагает он нам «стандартные условия договора», раздел «ответственность оператора», содержащий обычно пару абзацев. Эти пару абзацев и правда довольно стандартны, у всех почти одинаковые, и всех их объединяет понятие «1/720».

Т. об. если Оператор предоставляет вам услуги фиксированной связи за определенную абон. плату, и, внезапно, данные услуги перестанут быть доступны, то с щедрой подачи Оператора, за каждый час простоя из месячной абон.платы будет вычитаться ее 1/720. На первый взгляд — круто. Но быстро приходит понимание, что грубо — в месяце всего 720 часов, и в реальности, если Оператор не предоставляет услуги — он просто не берет с вас абон.плату, что, согласитесь, очевидно… и немного обидно. :)

Нас такой сервис не устраивает, мы хотим крови мотивировать Оператора работать без простоев, а простои сокращать до минимумов, поэтому мы садимся писать SLA.

Начать традиционно надо с воды...
1. Процедура взаимодействия Оператора и Компании
Очень кратко описываем показатели качества предоставляемых услуг, контакты ответственного человека/группы со стороны Оператора.
2. Регламент приема, регистрации и отработки заявки от Компании.
Рассказываем, что есть понятие заявки или Trouble Ticket`а, как вам удобнее. Описываем, что указывается в этой заявке. Описываем, что подаем ее например электронно, мылом, с конкретного адреса. Указываем, что будет подтверждением регистрации заявки

… а продолжить определением приоритетов срочности проблемы. Это важно, это мы будем использовать. Автор SLA сам должен придумать количество приоритетов, но если грубо, их будет не менее трех.

Давайте разберем на примере, мы используем услугу доступа в Интернет и тут:

  1. Доступ в Интернет полностью отсутствует — это «нулевой» (самый важный) приоритет — такую проблему мы будем решать в срочном порядке…
  2. Доступ есть, но деградирует качество… Или скорости существенно недодают или половина узлов недоступно. Называем это — «проблема на сети Оператора приводит к снижению качества предоставления услуг» — этот приоритет будет «первым».
  3. Есть прочие вопросы… такой приоритет проблемы тоже должен быть. Пусть он будет «второй». Это счета, доп соглашения, акты сверок, уточнялки всякие. Все это тоже должно решаться в определенные сроки.

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

Например, попробуем так:

  • Нулевой приоритет — время решения не более 4 часов;
  • Первый приоритет — время решения не более 8 часов;
  • Второй приоритет — время решения не более 24 часов.

Все это мы придумали, что бы мы наказывали имели мотивирующее воздействие на Оператора в разделе «Ответственность сторон».

Здесь мы опишем, что коэффициент доступности услуги в месяц составляет 99,5%, т.об. простой услуги не может превышать 4-х часов в месяц. Дадим Оператору какое то время на работы плановые и мелкие аварии.

Но! Если эти условия не выполняются, то теперь уже мы пишем, что за каждый час простоя свыше 4-х часов в месяц, Оператор будет вычитать, например, 1/100 (припомните Оператору 1/720) из месячной абон.платы. Это 1% в час — это очень стимулирует Оператора.

Мы рассмотрели просто пример, бумага все стерпит, можете придумывать любые вариации. Например, коэффициент доступности 99,00% и 8 часов бесплатного простоя. Другие приоритеты описываем аналогично.

Что ещё можно/нужно добавить в SLA
3. Регламент информирования Компании о решении ТТ
Описываем как часто и какими путями Оператор извещает о решении проблемы и сроках ее устранения
4. Листы эскалации
Если ваш менеджер у Оператора заболел/недоступен/ведет себя плохо? Кому пожаловаться? Документом закрепляем ФИО и контакты менеджера, его заместителей и руководства. Указываем критичные сроки, когда мы начинаем жаловаться Руководству Оператора на действия (или бездействие) менеджера. Кстати, Оператор попросит аналогичный лист эскалации, чтобы жаловаться вашему Руководству :)
5. Контактные координаты для связи
Здесь подробно описываем все контакты, понимая, что возможно придется связываться экстренно… ночью… когда почту никто не читает
6. Зоны ответственности
В чьей зоне ответственности электропитание оборудования Оператора, расположенного в вашей серверной? Правильно — Ваша. Именно с наличия питания на оборудовании начнет беседу оператор по «нулевому» приоритету. Описываем кто и за что отвечает и где граница ответственности.
7. Схема организации услуг связи
Это удобно иметь схему под рукой.
8. Порядок проведения Оператором плановых работ
О всех плановых работах, причем с обеих сторон, Клиент и Оператор должны извещать друг друга во избежании лишних инцидентов.

А теперь, весь этот «труд» надо согласовать с Оператором, который в свою очередь будет биться за каждый процент и час. Все компромисы регулируются стоимостью контракта.

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

Articles

Change theme settings