sla доставка что это

Что такое Соглашение об уровне услуг (SLA)?

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

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

Почему SLA так важны?

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

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

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

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

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

Кому нужно соглашение об уровне услуг?

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

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

Ключевые компоненты SLA

Ключевые компоненты соглашения об уровне услуг включают:

Существует 3 вида SLA

Существует три основных вида SLA: клиентские, внутренние и многоуровневые соглашения об уровне услуг.

Соглашение об уровне услуг клиентов заключается между поставщиком услуг и его внешними клиентами. Иногда это называется соглашением о внешнем обслуживании.

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

Соглашение об уровне услуг клиентов включает:

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

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

Например, отдел продаж компании ежемесячно осуществляет продажи на сумму около 800 000 рублей, при этом каждая продажа стоит 40 000 рублей. Если средний показатель закрытия сделок отдела продаж составляет 20%, то отдел продаж знает, что маркетинг должен предоставлять не менее 100 квалифицированных потенциальных клиентов каждый месяц.

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

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

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

Примеры SLA

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

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

Как проверить уровни SLA

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

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

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

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

SLA и положения о компенсации

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

Чтобы ограничить объем возмещений, поставщик услуг может:

Метрики производительности SLA

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

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

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

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

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

Что произойдет, если согласованные уровни услуг не будут соблюдены?

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

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

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

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

Штрафы

Штрафы SLA – это дисциплинарные меры, которые существуют для обеспечения соблюдения условий контракта. Эти штрафы различаются от контракта к контракту. Вот они:

Помимо сервисных кредитов, это могут быть:

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

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

Соображения по поводу показателей SLA

При выборе показателей производительности для включения в SLA компании следует учитывать следующие факторы.

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

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

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

Возврат средств

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

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

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

Когда пересматривать SLA

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

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

SLA следует пересмотреть:

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

Источник

Что такое Service Level Agreement

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

Как расшифровывается SLA

SLA (Service Level Agreement) дословно переводится как «Соглашение об уровне обслуживания (оказания услуги)», то есть это договор об уровне предоставляемого сервиса между компанией-провайдером и организацией-клиентом. Основное отличие SLA от обычного договора состоит в подробно прописанном уровне доступности сервиса и времени реакции на инциденты и раскрывает следующее:

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

Важно помнить, что использование SLA выгодно обеим сторонам:

Происхождение термина SLA

Термин SLA появился из методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), которая помогает IT-компаниям упорядочивать свои бизнес-процессы.

SLA подробнее всего описывается в стандартах ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»), используя которые компании-провайдеры регламентируют большинство своих процессов и выстраивают процедуры дальнейшего контроля выполнением этих процессов и взаимодействием с клиентами.

Для чего нужно SLA

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

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

Что включает в себя типовой SLA

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

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

При описании уровня качества сервиса, важно указать в SLA такие параметры, как:

Если речь идет об оплате сервиса, то указывается следующее:

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

Параметры, от которых зависит SLA

Параметры, из которых состоит SLA – это измеримые метрики, отвечающие за уровень качества предоставления услуги. Условно эти метрики можно называть «KPI» для SLA.

Такие метрики позволяют пользователям сервиса понимать, что именно и в каком объеме будет предоставляться. Главное условие соблюдения SLA — значения метрик должны быть известны всем заинтересованным сторонам, то есть находиться в открытом доступе, а описания метрик должны трактоваться однозначно.

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

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

Рекомендуется заранее определять критически важные сервисы, управление качеством которых будет осуществляться без каких-либо задержек, например:

Доступность услуги

Минимальное время, в течение которого услуга точно будет доступна, является метрикой доступности услуги. Доступность услуги обычно измеряется в абсолютных величинах (часах, минутах, секундах), например, за заданный промежуток времени (месяц, год) услуга будет точно доступна N часов, а время простоя составит X часов за тот же период. Доступность сервиса также может быть измерена в процентах и напрямую влияет на итоговую стоимость сервиса.

В качестве примера доступности услуги рассмотрим уровень надежности дата-центров Tier. Для каждого из четырех уровней дата-центров задана конкретная доступность в процентном эквиваленте.

Доступность сервиса невозможна на 100%. Значение доступности в процентах стремиться к 100% и выражается в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток», а доступность в 99,95% — может обозначаться как «три с половиной девятки».

Кстати, на примере доступности дата-центров учитывается только время простоя, в то время как значения остальных основных параметров заданы по умолчанию. При размещении сервера в Selectel, в стоимость входят:

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

Время реакции на инциденты

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

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

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

Оценка результата

Оценка результата управления инцидентами обычно определяется следующими метриками:

Время реакции на инциденты для оценки результата рекомендуется разделять на категории в зависимости от важности для работы всего сервиса в целом, например:

Чаще всего время реакции на инцидент в среднем составляет от 10 минут до 1 часа. Если при этом заранее были определены критически важные сервисы, то именно на сбои в их работе должна быть самая быстрая реакция.

SLI и SLO

SLI (Service Level Indicator) – это количественная оценка работы сервиса, которая является корреляцией между ожиданиями пользователей и действительной производительностью сервиса за указанный период времени (месяц, квартал, год).

SLI можно рассматривать в качестве индикатора пользовательского опыта, измеряя его в процентном эквиваленте, где:

Причем стоит помнить, что абсолютные минимум и максимум достижимы только в идеальных условиях, точно также, как и прописанные в SLA 100% доступности сервиса. При постановке целей рекомендуется реалистично смотреть на свой продукт и находить золотую середину.

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

SLO (Service Level Objectives) – это значение SLI, которого компания-провайдер хотела бы достичь. При установке SLO рекомендуется указывать реально достижимое значение для каждого конкретного SLI. SLO показывает, с каким качеством фактически работает сервис и/или приложение, в отличие от SLA, который используется для того, чтобы задать тот уровня доступности сервиса, на который смогут ориентироваться все пользователи.

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

Плюсы использования SLA для заказчиков и исполнителей

Вместо заключения

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

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

Источник

Как написать хороший SLA

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

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

Я буду оперировать названием SLA, Service Level Agreement, оно же Соглашение об уровне сервиса. Пришло оно из ITIL/ITSM и прижилось. Этот документ является краеугольным камнем в текущих подходах к осуществлению функций IT. Также он является одним из ключевых, если мы либо хотим нанять внешнего исполнителя для каких-нибудь услуг, либо хотим внутренние подразделения сделать максимально автономными, то есть по сути относиться к ним как к внутреннему аутсорсеру. И хотя подходы ITSM несколько более универсальны и применять их можно с некоторой выдумкой даже довольно далеко за рамками IT, в дальнейшем изложении я буду приводить в примеры ситуацию, когда у нас есть некоторая IT система и сервис — это её сопровождение. Ну просто потому что такая задача типична и встречается повсеместно. Аналогично можно написать SLA для любой другой деятельности, поменяются только список услуг да критерии оценки.

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

Вводная (определительная) часть SLA

В водной части SLA, и я не зря назвал её определительной, неплохо было бы определить, о чём вообще идёт речь.

Лучше всего начать SLA с глоссария, краткого описания системы и ролей участников процесса. Указываем название системы, на основе какого продукта от какого производителя она сделана, если в основе коробочный продукт, или на каких технологиях основана, если самопал. Обычные участники — пользователи, ключевые пользователи, сотрудники HelpDesk (первой линии поддержки), сотрудники второй, третьей (и так далее) линий поддержки, можно указать названия подразделений компании, вовлечённых в процесс, и перечислить какие роли выполняют сотрудники этих подразделений.

Далее необходимо определить границы действия SLA — территориальные, временные и функциональные. То есть где будет оказываться сервис (удалённо или на территории, адреса/явки), когда (с и по, график работ, в том числе в выходные и праздники). Раздел с функциональными рамками системы содержит мажорную версию системы (которая не поменяется от установки обновлений), список модулей системы (если система модульная), конфигурации (если есть разные базовые, типа как у 1С), интерфейсы с другими системами. Про интерфейсы лучше тут же и оговорить, какая их часть относится к SLA, а какая не относится. Если кроме продуктивного экземпляра системы SLA распространяется на тестовую зону или ещё какие-нибудь копии системы, это следует записать явно.

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

Подводя итог, общая часть SLA должна чётко определить сервис, который мы собираемся регулировать остальной частью документа. Общая часть должна дать понять, что в рамках данного SLA должно делаться, а что не должно. Если есть неопределённости, то дорабатываем описание. В идеале сторонний человек в теме (например, сотрудник профильной консалтинговой компании) должен после прочтения сказать «да, всё понятно!»

Где-то тут вводная часть начинает плавно переходить в существенную. Впрочем, я ещё предпочитаю тут же определить систему приоритетов, так как наш сервис скорее всего от приоритетов будет зависеть. Ещё не видел, чтобы не зависел. Ну и просто просится вставить сюда описание приоритетов (включая их использование/изменение) и процедуру эскалации.

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

Какой SLA является хорошим?

Начнём с вопроса «какой SLA мы будем считать хорошим». Очень достойный вопрос, очень мало кто может на него внятно ответить. Опустив три тонны размышлений и несколько сточенных языков, перейду сразу к самой сути.

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

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

Выбор метрик для SLA

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

Что тут важно. Не вдаваясь в подробности (это тема для отдельной статьи), метрики должны обладать следующим качествами:
(1) отражать качество предоставления сервиса,
(2) быть легко измеримыми,
(3) быть по возможности универсальными (чтобы использовать во всех своих SLA),
(4) их не должно быть много.

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

И, наконец, последнее по порядку (но не по важности):
(5) метрика должна зависеть только от работы исполнителя.

Если корреляция метрики с работой исполнителя будет слабая, то метрика не будет работать — контроль потерян, SLA не работает.

Приведу пример плохой метрики. Время доступности конкретной IT-системы 99,99% является плохой метрикой для работы HelpDesk. Потому что HelpDesk не влияет на время простоя систем от слова «никак». То есть, если система «упала», то HelpDesk может только максимально оперативно передать информацию тому администратору, кто может систему «поднять». А сколько это займёт времени (и будет ли там вообще кто-либо суетиться) от HelpDesk-а не зависит. Наказывать HelpDesk за чью-то неоперативную работу — это жестоко и бессмысленно. Единственное, чего этим можно будет добиться, что HelpDesk на подобный SLA положит с прибором.

Значения метрик

Теперь я хочу показать, как грамотно подойти к выбору значений метрик.

Типичная ошибка выглядит вот как. Описываю ситуацию. Пусть у нас есть довольно большая система (например, какая-нибудь ERP), и на её поддержке работают:

Если в Вашем случае эта система выглядит проще, не надо переживать. Я объясню принцип. А чем проще система, тем только легче её регулировать.

Мы пишем в SLA, что проблема критичного приоритета нашей системы должна решаться, скажем, за сутки. Аргументируем это тем, что пользователи хотят, чтобы за сутки проблема была решена. Мы их спрашивали, и они подтвердили. Это основная метрика в нашем SLA. Хорошо ли это или плохо? Рассмотрим с разных сторон.

HelpDesk в любом случае успеет сделать всё, что от него зависит даже не за сутки, а за час максимум. То есть в процессе телефонного разговора будет оформлен инцидент, заданы уточняющие вопросы, информация зафиксирована и отправлена на 2-й уровень. Час — это так, с запасом. Поэтому HelpDesk не обращает никакого внимания на метрики в SLA. Главное, чтобы всё, прилетевшее сегодня, сегодня же и улетело, и все SLA будут выполнены. Но они так всегда работают.

Теперь 2-й уровень получил инцидент (может напрямую, может из HelpDesk), и до конца дня есть время, чтобы с инцидентом разобраться. Не каждый инцидент может быть за такое время решён, но большая часть действительно за день решается, особенно критичного приоритета. Правда, если инцидент проболтался забытым до вечера в HelpDesk-е, то времени на его решение не осталось. При этом нарушит метрику 2-й уровень, а виноват-то на самом деле был HelpDesk.

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

Теперь 3-й уровень в лице разработчиков, если ещё не разошёлся по домам, имеет дилемму — поработать ударно в ночь или гарантированно нарушить SLA и заняться проблемой утром следующего рабочего дня. В случае ручного педалирования ситуации конечно первый вариант сработает, но штатной такую работу называть не хочется. Потому что с таким подходом срочное прилетает всегда к вечеру. Это итог ударной (и, что особенно важно, хорошей) работы коллег со 2-го уровня.

Разбор полётов. Что мы видим в результах в свете нашего SLA? Для HelpDesk-а и 3-го уровня SLA не работает, работает только для 2-го.

Что будет, если мы увеличим целевое время решения до недели? Теперь можно начать требовать исполнения такого SLA с 3-го уровня. Но зато для 2-го уровня такой SLA работать перестал — чего суетиться, завтра успеем. Или послезавтра. В результате на 3-й уровень проблемы станут попадать в последний день отведённой недели, 3-й уровень этим фактом возмутится и (если здравый смысл внезапно победит) неделя из SLA будет поделена на 2 дня работы 2-го уровня и 3 дня работы 3-го или ещё как-нибудь. Ну и 2-й уровень конечно расслабится, ведь времени, которое ему можно терять попусту, явно стало больше. Зато HelpDesk теперь на SLA не смотрит совсем, они такой SLA не могут нарушить даже если захотят. Им пользователи голову раньше открутят. И общее время решения проблем станет больше. Как-то не очень получается.

А что делать, чтобы SLA начал работать для HelpDesk? Наверное уменьшать время. До одного часа. Но тогда и 2-й и 3-й уровни перестанут попадать в SLA в принципе. И они перестанут в SLA смотреть совсем, потому что там с их точки зрения глупости написаны. И ещё постепенно все уволятся, потому что не могут выполнять свою работу хорошо, а этого на самом деле никто не любит.

Что же делать? Делать выводы. Если мы хотим контроль, то надо выделить целевое время работ на каждом уровне поддержки. И дать на работу HelpDesk-у час, 2-му уровню день, а 3-му три дня. За это время каждый должен выполнить свою задачу. А пока задачу решают другие, один счётчик тикать перестаёт, другой включается. Теперь у нас каждый следит за своим временем и не теряет его попусту. Полный контроль. При привлечении дополнительного уровня поддержки общее время должно увеличиваться, отражая глубину выявленной проблемы. Если надо кого-то интенсифицировать, то можно сделать это адресно. Например, если в самом деле надо вписаться в сутки на всё про всё, то делим их на 30 минут для 1-го уровня, 4 часа для второго и 19 с половиной для третьего. Это может оказаться излишне жёсткими требованиями в каком-то случае, но о вредных последствиях излишне жёстких требований я поясню чуть позже. Зато теперь у нас в SLA есть контроль и он работает, так как метрика позволяет легко выявить, кто не выполняет свою часть работы хорошо. Если пишете многоуровневый SLA, то всегда указывайте метрики отдельно для каждого уровня.

Отдельно отвечу на вопрос «но нам же пользователи сказали, что за один день», и что с этим делать. Пользователи IT-систем очень нечасто обладают компетенцией, достаточной для того, чтобы внедрить, настроить и далее развивать и поддерживать ту самую систему, пользователями которой они являются. Для решения подобных задач как раз существуют IT-подразделения, которые должны по роду своей деятельности понять и обеспечить именно то, что пользователям на самом деле нужно. Так что если Ваши пользователи назвали Вам время в сутки на решение критической задачи, то значит Вы их плохо спрашивали. Конечно же они хотели, чтобы критичные проблемы решались быстрее, скажем за час. А ещё лучше, чтобы сразу по мере возникновения. Некоторые, особо сообразительные могут даже потребовать превентивного решения проблем, и таки да, лучшие практики говорят как раз о проактивной работе. Но тогда, в случае полного успеха, работу IT-отдела не будет никому видно, и всех IT-шников уволят. Поэтому так круто заморачиваются только в тех случаях, когда без этого действительно никак (например, в системах по жизнеобеспечению). Так что не надо прикрываться некомпетентностью пользователей, а надо делать свою работу: объяснить пользователям, что простая проблема будет решена не за день, а даже быстрее. А сложная будет решаться дольше и от этого никуда не деться. И, кстати, в большинстве случаев тот же день на решение и получится.

Ещё одно интересное замечание. Если задачи довольно неоднородны по характеру и времени, необходимому на решение, и разделить их на разные услуги не получается, то имеет смысл не указывать в целевых метриках максимальное время на задачу, а перейти на статистические оценки. Например, 80% запросов будут решены за день. Альтернатива — дать возможность в задаче согласованно изменить срок.

Чем опасны излишние требования

Теперь о вреде излишней жестокости установленных метрик, да и любых других параметров услуг в SLA. Всё просто до банальности: ужесточение метрик увеличивает стоимость работ. Dixi. Поясню на примерах.

Пример №1. Предположим, что какой-то вид запросов на обслуживание в среднем решается часа за 4. Также нам известно, что исполнитель с высоким уровнем экспертизы может решать такие запросы за 2 часа. Что будет, если мы в SLA напишем 2 часа вместо 4? Это приведёт к тому, что исполнитель должен быть экспертом, значит станет более дорогим. Плюс проблемы с его мотивацией в будущем. Потому что с одной стороны эксперту будет скучно заниматься одним и тем же, а с другой стороны есть куча мест, куда его будут усиленно звать. По моим многочисленным наблюдениям цена услуги увеличивается в полтора-два раза.

Пример №2. Что будет, если в SLA в той же ситуации написать 1 час (или 1 минуту, что в данном контексте одно и то же), то есть сделать время нереалистичным? К предыдущему увеличению стоимости смело добавляйте величину предполагаемых штрафов за просрочку и умножайте результат на коэфициент риска, равный, скажем, 1,5-2. И, что самое плохое в данной ситуации, SLA перестаёт работать. Не надо так делать в здравом рассудке.

Пример №3. Хотим вместо режима 8х5 (8 часов по рабочим дням) получить режим 24х7. Ценник тут же увеличивается в два-три раза. И это только в том случае, если можно обойтись дежурной сменой, которая будет перекрывать ночь/выходные и вызванивать реальных исполнителей в случае чего. Если же нужна реальная постоянная работа в режиме 24х7, то ценник будет выше в пять раз, если не больше. Почему? Потому что три смены и выходные/праздники, да подмена на отпуска/больничные. А ещё квалифицированные кадры могут отказаться работать по нестандартному графику, и этот разрыв ожиданий придётся тоже лечить деньгами. Точно ли нужен 24х7?

Пример №4. Хотим постоянного присутствия исполнителя в офисе, чтобы было видно, как он работает и не работает ли — ах! — на сторону? Да, теперь он действительно не может больше помогать коллегам, участвовать параллельно в других проектах, а также не может быть сотрудником из регионального офиса. В конце концов исполнитель будет обязан соблюдать наш дресс-код и терять время на дорогу к нам. Итого раза в два будет дороже. Попутно мы перекрыли себе возможность использовать дополнительные ресурсы во время пиковых нагрузок и привлечение экспертов нужной квалификации по мере надобности, что происходило бы само собой в случае удалённой работы исполнителя. А может и не происходило бы, но теперь этого точно не будет.

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

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

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

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

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

Заключительные пожелания

Дополните SLA уместными ссылками на другие документы, описывающие процесс: политиками и регламентами. Не помешает указать, какие системы ведения запросов (обращений, инцидентов, проблем) используются, привести ссылки на регламенты работы с ними.

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

Что делать, если систем много. Писать свой SLA на каждую — получится совершенно запутанный зоопарк, нужно унифицировать. Полезно было бы сразу метрики из SLA и их значения сделать универсальными, чтобы не изобретать велосипед для каждой IT-системы в компании, да и в целом так проще отслеживать, что происходит вокруг, сравнивать ситуацию по разным системам. В больших компаниях различных IT-систем существуют десятки, если не сотни. Лучший мировой опыт говорит, что все системы нужно разбить на классы (Mission Critical, Business Critical и т.п.), и выписать метрики для классов. В отдельных случаях могут быть индивидуальные исключения, но большая часть систем может быть покрыта универсальным SLA именно так.

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

Приложение. Прототип SLA

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

Служебная информация
Владелец документа, лист согласования, история версий.

I. Вводная часть.

Система ХХХ на базе продукта УУУ версии 1.2.3.

Список компонент системы

Границы оказания услуг

Услуги оказываются с 09:00 по 18:00 МСК по рабочим дням с пн по пт, кроме выходных и праздников РФ.

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

II. Уровень сервиса

Приоритеты

Использование приоритетов, процедура эскалации (привлечений внимания)…

Ключевые показатели эффективности (КПЭ)

Пример для услуги №2 «Решение инцидентов»:

Целевые значения КПЭ

Алгоритм расчёта метрики

Целевое значение метрики (пример):
80% инцидентов должны решаться в целевое время.

Источник