какое количество пользователей добавляется в трекер в рамках тарифа sla platinum

Дополнительная функциональность — Ограничение доступа по IP и SLA

В нашем сервисном центре можно быстро и просто приобрести дополнительный функционал для сервиса ЭДО Диадок — ограничение доступа по IP и SLA. Вы можете настроить доступ к системе с учетом правил внутренней безопасности и заключить соглашение о необходимом вам уровне сервиса. Сделайте документооборот в компании простым и быстрым и уже сейчас распределите время сотрудников на решение более важных бизнес-задач. По вопросам приобретения дополнительного функционала обращайтесь к менеджерам по телефону +7 (495) 795-40-10 или оформляйте заказ на сайте.

Ограничение доступа по IP

Чтобы повысить уровень безопасности при работе с электронными документами, вы можете разрешить доступ к сервису только с определенных IP-адресов. Если сотрудник попытается войти в ящик, например, из дома, система выдаст ошибку и запретит вход.

Список разрешенных IP-адресов указывает администратор ящика. Можно добавить адреса или диапазоны, максимум — 100 записей.

Ограничение прав доступа помогает сохранить внутреннюю информацию в контуре предприятия.

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

Уровень предоставляемого сервиса (SLA)

При заключении соглашения об уровне сервиса Service Level Agreement (SLA) Диадок берет на себя обязательства по обеспечению 99 % доступности сервиса в год. Также SLA гарантирует высокую скорость решения обращений, на письма и звонки отвечают высококвалифицированные эксперты.

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

Где купить лицензию для сервиса ЭДО Диадок — Ограничение доступа по IP и SLA?

г. Москва, Пресненская наб. 12, ММДЦ «Москва-Сити» башня «Федерация-Восток», этаж 25, офис B

МО, г. Щёлково, площадь Ленина д. 8, этаж 3, офис 92

График работы: Пн. — Пт.: 09:00 — 18:00

По телефону По электронной почте

Источник

Что такое 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 — обычно самый оторванный от реалий документ, который можно вообразить. Более бесполезен, наверное, только 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% инцидентов должны решаться в целевое время.

Источник