09 Июля 2004 14:07 09 Июл 2004 14:07 |

Поделиться

Как правильно составить SLA в ИТ?

SLA — осознанная необходимость

На определенном этапе успешного развития любого ИТ-проекта перед теми, кто принимает решения, возникает дилемма. Как поддерживать работоспособность бизнеса?

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

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

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

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

С одной стороны, резкое увеличение аутсорсинга и более чем оптимистичные прогнозы на будущее. Кроме того, определенные сложности в управлении создает возникновение все новых и новых проектов в ИТ-сфере.

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

Как подойти к описанию требуемого уровня качества, чем руководствоваться? Подобная практика получила емкое и исчерпывающее название — Service Level Agreement (SLA). Содержание термина SLA довольно четко раскрыто в нем самом.

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

7 мифов об SLA

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

2. SLA просто описывает предоставляемые услуги.
Описание услуг — основной предмет SLA, что вполне естественно. Любая продуктивная совместная работа возможна при наличии общего языка. Именно при составлении SLA компании согласовывают общую терминологию.

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

3. В SLA не должны быть указаны бизнес-цели клиента.
Это не совсем так. Всеобъемлющее понимание основных приоритетов в бизнесе потребителя дает организации, предоставляющей услуги, четкие ориентиры — каким образом нужно действовать при возникновении проблем с обслуживанием «этого» клиента.

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

К примеру, американская компания Intira, специализирующаяся на веб-хостинге, указывает в своих SLA, что она компенсирует каждые 15 минут отсутствия доступа к ресурсам клиентов одним днем бесплатного обслуживания и так — вплоть до месяца бесплатного обслуживания в год.

5. Все провайдеры предоставляют стандартные SLA.
Это правда — некоторые даже уделяют место универсальности договорной базы в своей маркетинговой стратегии. Однако подавляющее большинство провайдеров все-таки идет навстречу пожеланиям пользователей, особенно корпоративных.

Здесь просто не может идти речи о шаблонном SLA. Так, вице-президент аутсорсинговой компании Nuclio Corp. Майк Коффилд (Mike Coffield) отмечает, что каждый SLA его компании строится вокруг бизнес-требований конкретного клиента. На разработку соглашения подчас уходит до трех недель. «Мы не навязываем SLA пользователю, — отмечает Коффилд. — Мы вносим туда все, что ему необходимо».

Гибридный ренессанс: как использовать растущий тренд на гибридную инфраструктуру

Облака

6. Качество предоставляемых услуг невозможно измерить.
Пожалуй, — это главное заблуждение относительно SLA. В зависимости от типа услуги, потребители могут измерить качество ее предоставления по одному из параметров: доступность; среднее количество сбоев за определенный период, их динамика; время, затрачиваемое на их устранение.

Вице-президент е-commerce-портала Commerce One Inc. (компания предоставляет услуги хостинга и co-location для сотен известных американских компаний) Сэм Пратер (Sam Prather) отмечает: «На третий день после оформления SLA с компанией Siterock наши технические специалисты не получили ни единого уведомления о сбое. Через месяц услуги Siterock, обходящиеся нашей компании в $15 тыс., сэкономили нам $1,5 млн., избавили нас от головной боли и сохранили нам ценных специалистов». В настоящее время целым рядом экспертных организаций по всему миру разрабатываются унифицированные системы материальной оценки качества услуг в сфере ИТ.

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

Типовая модель SLA

Как работает добровольная сертификация ИТ-решений для КИИ

Цифровизация

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

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

Второй немаловажный компонент любого SLA — регламент доступности сервиса, включая время, потраченное на тестирование, текущую поддержку и модернизацию. Неотделимо от этого и число конечных пользователей услуги — к примеру, 2 миллиона GSM-абонентов, 15 тысяч посетителей сайта, тысяча FTP-пользователей или триста сотрудников офиса. В любом случае должно оговариваться обслуживаемое или задействованное в обслуживании оборудование.

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

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

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

Шаг 1: Требуйте только то, что нужно именно вам.
Например, основным видом деятельности компании является веб-хостинг. Поддержка его функционирования осуществляется сторонними организациями. В этом случае затраты на стопроцентную доступность составляют на порядок большие суммы, чем средства, направленные на поддержание 98% или даже 99% от теоретической работоспособности. Но более тщательный анализ позволяет сделать вывод, что даже в веб-хостинге отдельные приложения не требуют такого пристального внимания. Даг Плоткин (Doug Plotkin), директор по развитию массачусетской компании Meta Group Consulting, советует своим клиентам сопоставлять качество услуг, предлагаемое сервис-провайдерами в SLA, в соответствии с реальными потребностями бизнеса. Быть может, услуг с меньшей стоимостью поддержки их качества будет вполне достаточно? Тогда не потребуется ассигновать в два-три раза большие средства на их «hi-end»-аналоги.

Шаг 2: Уделяйте внимание защите важных компонентов.
Допустим, аутсорсинговая компания обеспечивает поддержку доступа к 50 вашим серверам, но SLA предусматривает компенсацию лишь в случае падения среднего уровня доступности ниже оговоренного показателя (практика SLA, именуемая «агрегация»). Тем временем на деле стопроцентная работоспособность обеспечена 49 серверам из 50: всем, за исключением самого важного. «Агрегационный мониторинг хорош лишь в том случае, когда отсутствуют критические узлы, сбои которых не позволяют функционировать всей системе целиком, — отмечает Даг Плоткин. — Зачастую при наличии критических компонентов провайдеру дешевле выплатить мизерную компенсацию, нежели уделять отдельное внимание подобным ключевым участкам». Массачусетский консультант советует заранее дифференцировать уровень качества обслуживания первостепенных частей и всех остальных.

Шаг 3: Четко определите термины.
В любом SLA должен иметься список определений для понятий, относящихся к качеству сервиса. Наоми Картен, CEO Karten Associates, а также автор книги «Разработка SLA», делится опытом: «Когда провайдер гарантирует вам доступ на уровне 98%, имеет смысл лишний раз уточнить — 98% чего?». По его словам, краеугольным камнем является схема осуществления мониторинга: как будет отслеживаться качество услуг, как будет осуществляться переход на его новые уровни, как и в какой форме провайдер будет отчитываться.

Шаг 4: Учитывайте наилучшие и наихудшие сценарии развития событий.
Здесь показателен пример с аутсорсингом телефонной службы поддержки пользователей. SLA предполагает, что на 90% звонков будет дан ответ в течение 30 секунд. Это означает, что сотрудники help-desk смело могут заставить оставшиеся 10% пользователей ожидать помощи неопределенное время. Решением в подобных ситуациях станет видоизменение соответствующего пункта SLA. Проблема будут решена, если записать: «Провайдер гарантирует заказчику, что на 90% звонков, поступивших в службу поддержки, будет дан ответ в течение 30 секунд; на оставшиеся 10% — ответ будет дан не позднее 60 секунд».

Шаг 5: Компенсация должна быть адекватной.
Бизнес, уничтоженный низким качеством технологического обслуживания либо плохим обеспечением безопасности, уже не нуждается в лишнем годе бесплатного сервиса в качестве компенсации. Здесь потребуется прямое возмещение материальных убытков, а не удешевление и без того некачественных услуг. Компенсация должна соответствовать причиненному ущербу. Например, в соответствии с SLA, заключенным между почтовым порталом MiracleMail.com и упоминавшейся выше компанией Intira, в случае, когда портал остается недоступным 15 минут, на 16 минуте начинается автоматическое пополнение банковского счета MiracleMail.com.

Шаг 6: Обязательная модернизация.
Условия долгосрочных SLA должны периодически пересматриваться. Так, по словам того же Дага Плоткина, 5 лет назад максимальная гарантия доступности сайтов, декларированная хостинг-провайдерами, составляла 95%. В настоящее время минимальный уровень гарантируемого провайдерами uptime равен 97%.

В заключение хотелось бы остановиться еще на одном немаловажном аспекте. Суть SLA состоит в том, что подобные соглашения остаются творческим продуктом двух независимых сторон. Однако на практике же редко встречаются ситуации, когда обоюдная работа ведется на каждом этапе создания SLA. Тем не менее, удачное, работоспособное SLA — это соглашение, над которым плодотворно потрудились и компания, предоставляющая услуги, и потребитель этих услуг. Когда такой процесс действительно имел место, SLA, по большому счету, может смело храниться в архиве, поскольку на этой стадии люди уже прекрасно знают, как им сотрудничать друг с другом, на чем базировать и как развивать партнерские отношения. А это и есть основная цель SLA.

Антон Фойгт / CNews.ru

Поделиться

Подписаться на новости Короткая ссылка