Прогнозный мониторинг – ключ к успешному SLA

26 ноября 2014 г. | Цодиков Евгений | Категория: Обсуждаем статью

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

Многие SLA включают обещания клиенту всех возможных будущих благ, потому что легко обещать, если отсутствует система привлечения к ответственности за нарушения.

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

Прогнозный мониторинг

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

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

SLA должно обеспечить, чтобы прописанные в нем уровни сервисов были достижимы на деле. В соглашении нужно учесть, как все работало в прошлом, как работает сейчас и каков прогноз на будущее.

Прогнозный мониторинг – это ключ к успешному SLA. Например, какой-то параметр соглашения определяет приемлемую скорость отклика сервиса на запрос конечного пользователя. Документ фиксирует, что приемлемой величиной средней измеряемой скорости отклика является значение 500 миллисекунд, измеренных на протяжении часового периода.

Когда приложение запускается, скорость составляет 300 мс, и это ниже уровня, установленного соглашением в часовой период. Однако, время отклика увеличивается с течением времени в процессе использования приложения: 350 мс, затем 405 мс, потом 470 мс. Если вы отслеживаете только среднюю скорость, то вам кажется, что операции остаются в рамках параметров в часовом периоде, предусмотренных соглашением. Однако если вы применяете метод прогнозного мониторинга, то вы сможете понять, что время отклика может увеличиться и привести к нарушению соглашения еще до того, как этот параметр выйдет за установленные пределы.

Устранение проблемы

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

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

Учитывая развитие цифровых технологий и изменение рабочих нагрузок, провайдер должен объяснять клиенту, какие параметры реально поддерживать на уровне, предусмотренном в SLA, а какие будут нереалистичны. Например, если наплыв пользователей замедляет работу приложения, более мощная виртуальная машина могла бы устранить проблему, но это будет стоить дороже. Если IT-бюджет не позволяет использовать дополнительные ресурсы, следует обсудить соотношение стоимости и качества сервисов. Устроит ли клиента, если услуга будет дешевле, но при этом снизится и ее качество – с 500 мс, например, до 550 мс?

На месте все сложнее

Договориться об уровнях внутреннего SLA – задача еще более сложная. Разнородная среда собственных дата-центров в комбинации с колокейшн и облачными сервисами означает, что «главное» соглашение должно объединять параметры SLA с внутренним IT-департаментом и SLA с внешним провайдером. Придерживайтесь одинакового подхода к соглашениям со всеми подразделениями, при этом целью должно быть конструирование гибких отношений с провайдером для предотвращения отказа или других сюрпризов в эксплуатации, а также для того чтобы избежать непредусмотренных затрат. Не ставьте во главу угла штрафные санкции.

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

Поднимайте вопрос о штрафных санкциях только в том случае, если провайдер не справляется с выполнением условий соглашения - в этот момент отношения сторон и так портятся. Подготовьте коммерческий план Б: кто заменит персонал, допустивший нарушение? Можете ли вы себе позволить уволить сразу весь отдел IT? Это может быть лишь крайней мерой.

Клайв Лонгботтом

Quocirca

Теги: SLA