sla отчет что это

Как создавать соглашения SLA, измерять показатели и составлять отчеты

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

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

Для поставщика услуг соглашение об уровне обслуживания — это изложенное простым и доступным языком соглашение между ним и клиентом (внутренним или внешним). В таком соглашении определяются предоставляемые услуги, ожидаемая скорость реагирования и способ измерения эффективности.

Соглашение SLA определяет согласованные условия предоставления услуг, включая время безотказной работы и оперативность поддержки. Такое соглашение может включать обещание клиентам безотказной работы в течение 99,9 % времени или отклик службы поддержки в течение 24 часов. Помимо формализации ожиданий от обслуживания, соглашение SLA определяет условия возмещения ущерба при нарушении требований.

Важность соглашений SLA

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

Различия между SLA и KPI

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

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

Проблемы соглашений SLA

В теории все просто, не правда ли? Однако на практике ИТ-команды часто сталкиваются с одной или несколькими серьезными проблемами.

Как создавать соглашения SLA и измерять эффективность

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

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

Рекомендации по соглашениям SLA

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

Укажите в соглашении SLA, что отсчет времени до решения проблемы приостанавливается, пока не будет получен ответ клиента

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

Помните о взаимодействии с агентами

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

Разбивайте большие и сложные соглашения SLA на части

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

Устанавливайте разные целевые показатели эффективности в зависимости от приоритета заявок

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

SLA на облако: как читать и на что обратить внимание

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

Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.

Если мы не администрируем клиентские виртуальные машины, то и приложения внутри для нас – черный ящик. При этом самые частые отказы находятся как раз на стороне приложения. Может случиться что угодно: переполнятся диски, учетные записи заблокируются, DNS откажет, компоненты приложения перестанут взаимодействовать из-за неправильных настроек. А может оказаться, что системное время выставлено неверно или установилось ненужное обновление. Такие проблемы не являются нарушением SLA и решаются на стороне клиента. Так когда же он действует?

SLA – что это такое и для чего

SLA – это своего рода гарантийный талон на услугу. Но это не просто пункт с девятками в основном договоре. Это развернутое приложение, в котором фиксируются все параметры оказываемой услуги. Правильно составленное приложение страхует и клиента, и сервис-провайдера.

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

В хорошем SLA на виртуальную инфраструктуру должны быть:

Доступность

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

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

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

Девятки и инфраструктура. Если вам необходим определенный уровень отказоустойчивости сервиса, то и виртуальная инфраструктура должна быть построена таким образом, чтобы эту доступность обеспечивать. Так, для достижения уровня доступности 99,95% вам, как минимум, понадобится кластер active-passive. Если вы хотите перешагнуть за 99,982% (уровень доступности в дата-центрах Tier III), вам нужно строить систему, распределенную по нескольким ЦОД.

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

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

Совокупная доступность. Если ваше приложение имеет доступность 99,5%, облако имеет доступность 99,95%, а дата-центр, где оно развернуто, – 99,982%, то на выходе вы будете иметь доступность не выше 99,5%. Так как доступность всего сервиса не может быть выше доступности самого слабого его звена. Помните об этом при выборе сервиса и не пытайтесь лечить перелом подорожником. Защищенный геораспределенный кластер не спасет падающее через день приложение.

Не доступностью единой

Доступность для ИТ-сервисов – главный параметр. Но и при стопроцентном аптайме виртуальная машина может жестко тупить из-за сетевых задержек, недостаточного количества IOPS, высокой latency СХД и прочих проблем. Поэтому в правильном SLA должны быть все качественные метрики по инфраструктуре. На что смотреть и к чему стремиться?

секунды. Поэтому норма для этого параметра – в пределах от 0 до 1%. Как и в случае с сетевой задержкой, уточните у провайдера, где заканчивается его ответственность.

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

Запросы, инциденты и технические работы

Сначала разведем понятия запрос и инцидент. Запрос – это заявки на штатные работы. Инцидент – когда что-то сломалось и не работает, например: машина сильно тупит или не пингуется. Если что-то сломалось у провайдера, то уведомление об инциденте приходит из системы мониторинга. Все запросы и инциденты разделяются по приоритетам. Это позволяет быстро реагировать на вопросы жизни и смерти и чинить все вовремя. Важно определить статус заявки на этапе ее регистрации. Как это устроено у нас, мы рассказывали в статье о службе поддержки.

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

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

Пример инцидентов первого приоритета.

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

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

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

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

Мы делим запросы на три типа, которые отличаются по характеру работ и времени исполнения:

Проведение регламентных работ и уведомление. Инфраструктура – это живой организм. Ее нужно обслуживать: апгрейдить, накатывать критические обновления, проводить плановые работы (например, обновлять прошивку на серверах). Не все работы можно сделать без остановки сервиса. Поэтому в SLA фиксируется порядок уведомления о таких работах, время проведения работ и возможное время перерыва в сервисе. Проверяйте, чтобы срок уведомления о плановых работах был достаточным и было зафиксировано максимальное время остановки сервиса.

У нас это выглядит так:

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

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

Если есть вопросы, традиционно жду в комментариях. Здорового вам облака!

Источник