Корпоративные подписки: сервис виртуальный, SLA реальный

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

Изображение: Maks_lab/Shutterstock.com

Приведем пять типовых разделов для разработки или корректировки SLA и три нетиповых.

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

Например, корпоративные подписные решения, построенные на базе сервисов Microsoft, сейчас не просто находятся в зоне риска, а скорее становятся самым настоящим риском для тех компаний, которые использующих данные продукты без явных альтернатив. И это только один пример. А если сервисы отраслевые, то и альтернатив не особо много.

Частные и государственные компании уже могли видеть первые тревожные сигналы еще в далеком 2014 году, когда часть сервисов и решений начали запрещать для эксплуатации в России. Но тогда этот процесс был скорее точечным и локальным. Сейчас масштабы изменились. И подход к работе с сервисами должен меняться. Неважно, локальный это подписной сервис или глобальный, но определенные «правила игры» нужно учитывать всегда. Далее приведу пять типовых разделов для разработки или корректировки SLA и три нетиповых.

Типовые разделы

  1. Структура и показатели услуг (сервисов). Конечно, это самый ключевой и даже базовый пункт для SLA. Но далеко не всегда он реализован оптимально. В данном пункте нужно тщательно учесть не только сами сервисы и основные показатели по ним, но и прописать структуру предоставления сервисов, структуру мониторинга, ответственных с обеих сторон и допуски в показателях, которые могут входить в норму. Лишь в таком формате сервисы будут по-настоящему прозрачно зафиксированы в документе и не вызовут спорных ситуаций (по крайней мере снизят неопределенность).

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

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

  4. Показатели временного решения при невозможности восстановления сервиса в регламентируемые сроки по SLA. Здесь важно прописывать детальную структуру формирования временного решения, в каких случаях оно применимо, как повлияет на предоставляемый сервис и как будет учитываться компенсация для заказчика. Был случай в практике, когда временное решение прописывалось в SLA так, что при любом минимальном отклонении по показателям сервис переходил в условно экстремальный режим. При этом потребность была только в 10% случаев, а деградация сервиса происходила каждый раз. 

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

Нетиповые разделы

А теперь о нетиповых пунктах. Я не настаиваю, что они обязательные, но учитывать такую возможность рекомендую.

  1. Альтернативные варианты предоставления сервисов, например, критически важных, а также показатели при условии, что для провайдера ситуация является форс-мажором. Например, какой-то софт для России принудительно закрыли, и в таком случае провайдер сервисов будет ссылаться на соответствующий пункт SLA, но не пытаться экстренно предоставить сервис. В рамках данного пункта учитываются и финансовые потери (конечно, только доказанные), но это важно зафиксировать. Например, в одном из подобных случаев в SLA мы прописывали процесс развертывания провайдером альтернативной инфраструктуры в течение согласованного времени и предоставления ключевого сервиса с определенными показателями. Разумеется, все в значительной степени зависит от масштабов потребляемого сервиса, возможностей провайдера и самого SLA.
  2. «Приоритетная линия». Мы называли именно так пункт в SLA, где фиксировали определенные номера телефонов ответственных руководителей со стороны провайдера и указывали конкретные показатели и случаи, при которых можно было воспользоваться этими контактами. Здесь также нужно прописывать, кто именно от заказчика может обращаться в рамках данного пункта. У нас был подобный согласованный пункт для прямой связи с одним из руководителей федеральной структуры в случае серьезной угрозы для ключевых процессов бизнеса, и только ИТ-директор мог использовать эту возможность. Иначе специалист, имеющий определенную зону ответственности, может злоупотребить данным пунктом SLA для ускорения, например, типовых процессов, которые еще не вышли из регламентных показателей.
  3. Кроме того, рекомендую учитывать то, что происходит в компании провайдера сервисов в части возможных процессов слияния и поглощения, изменений структуры и реорганизации. Любая коммерческая структура может достаточно быстро измениться и в сторону совершенствования, и в обратную сторону. И в идеале учесть и прописать какие-либо гарантии по предоставлению базы из сервиса, интеграции и переносу данных, документации и т. д. в случае, если сервисы вдруг полностью выведут из эксплуатации и поддержки. А также указать сроки оповещения об этом.

***

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

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

Опубликовано 28.03.2024

Похожие статьи