# SLA ## Зачем нужны SLA SLA (Service Level Agreement) – соглашение между поставщиком ИТ-услуг и заказчиком (по умолчанию – между ИТ-подразделением и основным бизнесом компании). В SLA описаны обязательства поставщика и условия предоставления услуг, а также обязанности и возможности заказчика по потреблению услуг. Заключая SLA с бизнес-структурой, ИТ-служба гарантирует предоставление услуги с уровнем качества не ниже согласованного. развивая сервисный подход на предприятии нелишне подумать: «А зачем SLA потребителям моих услуг? Поможет ли он повысить их удовлетворённость, решить их задачи»? ### Из чего состоит SLA? * Описание сервисов / услуг, предоставляемых в рамках SLA (часть или весь каталог сервисов, предоставляемых ИТ-службой ) * Описание условий предоставления сервисов / услуг (вплоть до порядка обработки запросов на определенные услуги) ### Типичные ошибки при составлении SLA Отсутствие правил расставания * Будет ли известно о расторжении заранее? * Хватит ли суммы компенсации? Невнимательность к санкциям * Как будет компенсировано нарушение? * Является ли ответственность соразмерной? Нет механизма приостановления / возобновления работы Неточность условий * Какие запросы я буду получать? * На какой результат я могу рассчитывать? ### Как запускать SLA чтобы указать в SLA реально выполнимые сроки и метрики, мы должны: * знать, какие сроки мы в состоянии соблюдать сейчас; * понимать, какой процесс стоит за соблюдением этих сроков. Начните измерять фактическое соблюдение параметров качества. Когда станет очевидно, что заявленные в SLA сроки работают не всегда и в 50% случаев нарушаются или бизнес ставит новые задачи, выделяя новые критические сервисы – начинайте детализировать услуги и корректировать условияSLA. Двигаться в сторону повышения health range и увеличения количества метрик стоит в зависимости от потребностей бизнеса, а не по собственной фантазии. ## Как у нас Заказчики: их нет. Мы сами определяем рамки и список услуг, чтобы выйти на "рынок" не с пустыми руками. Список услуг: мы сами должны определить какие услуги предоставляем и по каким услугам будем предоставлять метрики, т.к. нет заказчиков. Более того, у нас развивающийся продукт, то есть, мы фактически меняем список предоставляемых услуг, а значит должны менять и список метрики по услугам. Приоритеты и нормативное время решения проблем. Не описано явно - это проблема. Механизм изменения списка метрик и health range не описан, определяется не требованиям заказчика, а здравым смыслом, то есть, фактически у нас нет объективных причин что-то менять, кроме собственного желания. Мы не можем получать обратную связь от бизнес-экспертов по предоставляемым метрикам. Не понимаем как именно метрики влияют на конечных пользователей, то есть, это нам также не помогает определить health range метрик. ## Чего мы вообще хотим достичь на текущем этапе? Какая у нас цель? Построить процесс поддержки SLA? Наладить контакт с потребитебями наших услуг? Поддерживать метрики на текущем уровне? Растить метрики? Ссылки: * https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BE%D0%B1_%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5_%D1%83%D1%81%D0%BB%D1%83%D0%B3 * https://club.cnews.ru/blogs/entry/dal_slovo_ * https://itsource.com.ua/blog/dlya-chego-nugen-sla/ * https://realitsm.ru/2011/11/why_does_business_need_sla/ *