Sla что это такое простыми словами

Что такое SLA в управлении?

Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT Infrastructure Library) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.
В SLA описываются условия предоставления услуг (сервисов), устанавливается перечень таких услуг, а также правила, по которым заказчик будет пользоваться этими сервисами. В то же время SLA — один из основных механизмов, позволяющих управлять качеством ИТ-услуг и управлять ожиданиями пользователей.

Что должно быть в SLA?

Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.

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

SLA: с чего начать

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

Ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется — Service Level Management, SLM.

Источник

Что это такое SLA

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

Что это такое SLA

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

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

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

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

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

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

Преимущества SLA для сторон соглашения

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

Исполнитель получает собственные преимущества:

Наиболее важные условия, которые необходимо прописать в SLA:

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

Вред излишних требований

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

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

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

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

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

Услуга поддержки по SLA

Услуга поддержки по SLA позволяет получить ожидаемый результат от сопровождения информационных систем по четко определенной цене и в конкретные сроки. Линия консультаций 24/7 позволяет нашим клиентам оперативно получать помощь квалифицированных специалистов.

Источник

Service Level Agreement (SLA) — определяет взаимную ответственность провайдера ИТ-сервиса и пользователей этого сервиса. В соответствии с рекомендациями ITIL Information Technology Infrastructure Library, SLA – это основной документ, регламентирующий взаимоотношения ИТ и клиентов. Цель документа – дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и с точки зрения пользователя.

Содержание

Существенной частью SLA является каталог сервисов.

Service Level Agreement – SLA – это соглашение между заказчиком и исполнителем, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Соглашение SLA четко прописывает временные рамки для устранения проблем, определяет штрафные санкции, накладываемые на нашу компанию в том случае, если качество услуг оказалось ниже прописанного в договоре уровня. Это позволит минимизировать ваши убытки. Таким образом, заказчик получает удобный способ контролировать услуги, быть уверенным в их полноте и качестве. Уникальность услуги в том, что SLA дает понятный ответ на вопрос «Хорошо или плохо работает служба поддержки?».

Структура

Типовая модель SLA должно включать следующие разделы:

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

Что обязательно стоит включить в SLA?

На что еще обратить внимание?

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

От чего зависит стоимость и как не переплатить?

Как еще можно снизить стоимость?

Зачем нужны SLA

Из чего состоит SLA?

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

Внедрение Service Desk, безусловно, тесно связано как с определением каталога сервисов, так и с разработкой SLA. Поскольку:

Ошибки

Отсутствие правил расставания

Невнимательность к санкциям

Нет механизма приостановления / возобновления работы

Как это сделать?

За каждой услугой / запросом пользователя стоят свои процессы, запускаемые в ИТ-службе. В этом плане SLA – это возможность построить ИТ-процессы и быть уверенным, что именно такая организация поможет работать эффективно с точки зрения пользователей. Введение четко регламентированного времени реакции/устранения инцидента/предоставления услуги является частью масштабного процесса SLM, однако это возможно только в том случае, если в ИТ-службе уже налажены более элементарные процессы. Как же в этом случае построить эффективный процесс управления уровнем сервиса?

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

Резюме: при разработке SLA необходимо учитывать несколько ключевых моментов

Источник

Хватит думать, что SLA вас спасет. Оно нужно, чтобы успокоить и создать ложное чувство безопасности

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

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

Что чаще всего пишут в публичной версии SLA хостеры, которую показывают публике? Ну, первой строкой идет такой термин, как «надежность» хостера — это обычно цифры от 98 до 99,999%. По сути, эти цифры — лишь красивая выдумка маркетологов. Когда-то, когда хостинг был молодым и дорогим, а облака только снились специалистам (как и широкополосный доступ для всех и каждого), показатель аптайма хостинга был крайне и крайне важен. Сейчас же, когда все поставщики используют плюс-минус одно и тоже оборудование, сидят на один и тех же магистральных сетях и предлагают одни и те же пакеты услуг, показатель аптайма абсолютно непоказателен.

Бывает ли вообще «правильный» SLA

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

Что должно быть в хорошем SLA? Если дать TLDR, то хороший SLA — это регулирующий отношения двух субъектов документ, который дает одной из сторон (заказчику) максимум контроля над процессом. То есть, как это работает в реальном мире: есть документ, который описывает глобальные процессы взаимодействия и регулирует взаимоотношения сторон. Он устанавливает границы, правила и сам по себе становится рычагом воздействия, которым могут пользоваться обе стороны в полной мере. Так, благодаря правильному SLA заказчик просто может заставить исполнителя работать так, как договаривались, а исполнителю — помогает отбиваться от необоснованных договором «хотелок» слишком уж активного клиента. Выглядит так: «У нас в SLA написано так и так, идите отсюда, мы все делаем как оговорено».

То есть «правильный SLA» = «адекватный договор на оказание услуг» и дает контроль над ситуацией. А возможно это только при работе «на равных».

То, что пишут на сайте и то, что ждет в реальности — разные вещи

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

Если взять популярных отечественных хостеров, то одно предложение краше другого: поддержка 25/8, аптайм серверов 99,9999999% времени, куча своих дата-центров минимум по России. Запомните, пожалуйста, момент про дата-центры, мы к нему вернемся чуть позже. А пока поговорим про идеальную статистику отказоустойчивости и с чем сталкивается человек, когда его сервер все же попадает в «0,0000001% падений».

При показателях от 98% и выше, любое падение — событие на грани статистической погрешности. Рабочее оборудование и коннект либо есть, либо их нет. Вы можете годами пользоваться хостером с показателем «надежности» в 50% (согласно его же SLA) без единой проблемы или «падать» раз в месяц на пару дней у ребят, где заявлено 99,99%.

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

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

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

«Множество дата-центров по всему миру» — повод для беспокойства

Ситуацию с большим количеством дата-центров у поставщика услуг мы вынесли в отдельную категорию, потому что кроме очевидных вышеописанных проблем с коммуникацией всплывают проблемы и неочевидные. Например, ваш поставщик услуг не имеет доступа к «своим» дата-центрам.

В нашей прошлой статье мы писали о видах партнерских программ и упомянули модель «White Label», суть которой заключается в перепродаже чужих мощностей под своей вывеской. Подавляющее большинство современных хостеров, которые заявляют о наличии «своих дата-центров» во множестве регионов, являются перекупщиками по модели White Label. То есть, физически они не имеют никакого отношения к условному дата-центру в Швейцарии, Германии или Нидерландах.

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

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

Почему мы не рассматриваем варианты, когда множество ДЦ на самом деле может принадлежать одной компании? Ну, таких компаний очень и очень немного. Один, два, три небольших дата-центра или один крупный — это реально. Но десяток ДЦ, половина из которых в РФ, а вторая на территории Европы — практически невозможно. А это значит, что компаний-перекупщиков намного больше, чем можно себе представить. Вот простой пример:

Оцените количество дата-центров сервиса Google Cloud. В Европе их всего шесть. В Лондоне, Амстердаме, Брюсселе, Хельсинки, Франкфурте и Цюрихе. То есть на всех основных магистральных точках. Потому что дата-центр — это дорого, сложно и очень большой проект. А теперь вспомните хостинговые компании откуда-то из Москвы с «десятком дата-центров по всей России и Европе».

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

Это еще раз напоминает нам, что SLA бесполезен, если вы не имеете понятия о структуре организации и мощностей поставщика.

Что в итоге

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

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

В первую очередь нужно выявить, является ли продавец услуг непосредственным владельцем мощностей/дата-центра. Очень многие перекупщики по модели White Label изо всех сил маскируют свой статус и в этом случае надо смотреть на какие-то косвенные признаки. Например, если «их европейские ДЦ» имеют какие-то специфические названия и логотипы, отличающиеся от названия компании-поставщика. Или если где-то мелькает слово «партнеры». Партнеры = White Label в 95% случаев.

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

Со многими дата-центрами можно договориться о личном визите в офис и мини-экскурсии в сам ДЦ. Там можно оценить степень порядка, возможно, удастся пообщаться с кем-нибудь из инженеров. Понятно, что никто не будет устраивать вам экскурс на производство, если вам нужен один сервер за 300 RUB/месяц, но если вам требуются серьезные мощности, то отдел продаж вполне может пойти вам на встречу. Мы, например, такие экскурсии проводим.

В любом случае следует руководствоваться здравым смыслом и потребностями бизнеса. Например, при необходимости распределенной инфраструктуры (часть серверов в РФ, вторая — в ЕС), проще и выгоднее будет воспользоваться услугами хостеров, имеющих партнерские отношения с европейскими ДЦ по модели White Label. Если же вся ваша инфраструктура будет сконцентрирована в одной точке, то есть в одном дата-центре, то стоит уделить вопросу поиска поставщика некоторое время.

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

Источник

Как написать хороший 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% инцидентов должны решаться в целевое время.

Источник