Нарушено 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: советы по составлению для ServiceDesk и Helpdesk
Соглашение об уровне обслуживания (Service Level Agreement, или SLA ) — договор между поставщиком ИТ-услуги и заказчиком. Появившись когда-то в ITIL как одна из рекомендаций, SLA стал незаменимым практическим инструментом. Сейчас именно на основе SLA в большинстве случаев выстраивается взаимодействие поставщика и заказчика.
Каждая компания составляет собственное соглашение с учетом требований заказчика. Тем не менее, есть стандартизованная структура SLA, которая включает около десятка разделов. Этой структуры, в большей или меньшей степени, придерживаются все:
Основной канал, через который поставщик и клиент взаимодействуют в рамках предоставления ИТ-услуги, — служба поддержки. Отсюда и ключевая роль Help Desk, или Service Desk, в SLA. Важно составлять подробное и грамотное SLA, чтобы оно учитывало все нюансы процесса оказания услуги.
Мы подготовили несколько советов, которые помогут составить SLA с измеримыми метриками и достижимыми целевыми показателями.
Периодически проверяйте и корректируйте SLA
ITIL рекомендует пересматривать и обновлять SLA всегда, когда в ИТ-сервис вносятся изменения. Так у поставщика и у клиента будет уверенность в том, что целевые показатели актуальны, а изменения не принесли вреда. В особенности это касается критичных метрик, таких как время работоспособности и время поддержки услуги.
Вы сервис-провайдер, который взял на поддержку виртуальную инфраструктуру клиента. Одна из ключевых метрик вашего SLA — параметр производительности системы хранения на HDD-дисках. Допустим, производительность СХД по SLA составляет 2000 IOPS.
В какой-то момент клиент переходит на новую ресурсоемкую СУБД. После чего в вашу службу поддержки начинает поступать всё больше запросов, связанных с медленной работой СХД. Выясняется, что клиента больше не удовлетворяет действующая метрика производительности, и он, не вникая в особенности технологии, просит пересмотреть SLA.
Анализируя отчеты Service Desk, вы можете действовать на опережение — пообщаться с клиентом и выяснить причины проблемы. Как вариант, можно перевести клиентскую базу данных на SSD-хранилище с производительностью 10 000 IOPS и предложить клиенту SLA с новыми метриками. Так, своевременный апгрейд инфраструктуры и пересмотр метрик поможет избежать конфликтной ситуации.
Однако даже если ваш ИТ-сервис не изменялся, «для профилактики» раз в год желательно проводить совместную ревизию SLA. Возможно, в бизнес-процессах клиента произошли изменения, которые повлияли на сервис, но не были учтены.
Добавьте ограничения и исключения
Нередко проблемы с выполнением целевых показателей не зависят напрямую от качества работы техподдержки. Желательно учесть в SLA все возможные исключения, которые могут быть вызваны объективными или форс-мажорными обстоятельствами.
Время реакции. Если у вас проводится регулярное плановое техобслуживание систем мониторинга, когда вы не можете оперативно ответить на запрос, укажите это в SLA в качестве ограничения. Например: «Гарантированное время реакции на запрос — до 1,5 часов, кроме каждой второй среды месяца в период с 1.00 до 4.00». Добавьте детальное объяснение причины.
Периоды простоя. Отметьте ситуации, когда простой сервиса не зависит от вас и время неработоспособности сервиса может возрасти. Например:
Время поддержки. Учтите период, в который вы не сможете поддерживать сервис, — к примеру, в нерабочее время и в выходные. Тогда согласованное время поддержи можно указать так: «8×5 (10:00-18:00, Пн-Пт)».
Задержка со стороны клиента. Иногда, чтобы правильно обработать запрос, от клиента требуется дополнительная информация. Если клиент по какой-либо причине не предоставляет эту информацию, временные метрики могут быть нарушены. В этом случае отклонения от целевых показателей — в первую очередь, времени решения — можно квалифицировать как допустимые.
Сделайте SLA измеримыми
Метрики, на которые ориентируется служба поддержки и которые предоставляются клиенту, должны недвусмысленно показывать, было ли достигнуто SLA. Это возможно при соблюдении нескольких условий.
Сделайте отдельные метрики для каждого уровня поддержки
Help Desk и Service Desk обычно многоуровневые службы. У каждого уровня определенные специфика, сложность задач и KPI. Это нужно учитывать при согласовании в SLA времени реакции и времени решения проблем.
Возьмем для примера техподдержку ITSM-системы. Help Desk такой системы чаще всего включает три линии обслуживания.
Первая линия обрабатывает запросы пользователей и решает простые проблемы — ей на это требуется в среднем один-два часа.
Вторая решает более сложные проблемы — от нескольких часов до суток.
Третья линия, например разработчики, может отрабатывать тикеты до нескольких дней, а то и недель.
Рассчитывайте временные метрики в SLA индивидуально для каждой линии техподдержки. Метрики должны быть реалистичными: если проблема требует сложных работ с привлечением третьей линии поддержки, ее невозможно решить за сутки.
Объясните клиенту, почему у разного типа инцидентов и запросов на обслуживание разные сроки решения, и от чего они зависят.
Учитывайте ожидания клиента
В SLA указываются не просто цифры, а достоверные показатели, которые отражают фактические желаемые результаты для клиента. Важно, чтобы клиент понимал каждый целевой показатель и ограничения поставщика.
Если уровень гарантированной доступности сервиса 99,9%, ему позволено «лежать» суммарно 43 минуты в месяц. Сценарии могут быть разными. Например — четыре некритичных инцидента ночью с простоем по 10 минут каждый. Либо 40 минут днем, в час пиковой нагрузки, когда простой сервиса приведет к многомиллионным убыткам. Формально поставщик не нарушит SLA, но вряд ли клиент будет удовлетворен качеством услуги.
Согласуйте свои возможности и ожидания клиента. Если для клиента критичен простой даже в 10 минут, можно организовать бесперебойную работу сервиса — например, за счет резервирования канала связи. И вам, и клиенту такой уровень доступности будет стоить дороже, но зато SLA будет реалистичным.
Избегайте общего SLA для клиентов с географически распределенной структурой
Бывают заказчики с филиалами в разных городах. При этом у одного и того же запроса на обслуживание сроки решения могут отличаться в зависимости от филиала.
Вы обслуживаете офисную компьютерную технику компании с несколькими филиалами. Заказчик просит, чтобы сломавшийся ноутбук заменяли не позднее, чем до обеда следующего за обращением рабочего дня. Для головного офиса, который находится в крупном городе, это реалистичные сроки. В филиале, который расположен в удаленном райцентре, — чаще всего нереалистичные. Потому что время решения зависит от скорости работы службы доставки и, возможно, от других факторов. В таком случае единый SLA работать не будет.
Составляйте SLA для каждого удаленного подразделения клиента, где срочность, приоритеты и время решения будут рассчитываться с учетом локальных особенностей.
Для чего нужен SLA и что кроется под заветными процентами
Что такое SLA
Service Level Agreement (SLA) часто встречается в описании преимуществ облачных провайдеров. Его можно назвать гарантией качества услуги. Термин появился благодаря руководству ITIL, самому распространённому документу по управлению ИТ-услугами. С его помощью компании во всём мире упорядочивают свои бизнес-процессы. Встречается SLA и в стандарте COBIT, регламентирующем большинство процессов облачных провайдеров, контроль их выполнения и взаимодействие с клиентами.
SLA — это полноценный документ, в котором фиксируются параметры оказываемой провайдером услуги. От традиционного договора SLA отличается детально прописанным уровнем доступности сервиса и скорости реакции на проблемы, которые могут возникнуть у клиента провайдера.
SLA определяет гарантированный уровень качества предоставляемой провайдером услуги. То есть ниже, чем зафиксировано в договоре, сервис быть не может. На разные сервисы могут прописываться разные Соглашения об уровне обслуживания. Условия тоже могут отличаться. Например, SLA на виртуальную инфраструктуру распространяется строго до ОС клиентской виртуальной машины. То, что внутри ВМ — касается только клиента и его ИТ-службы. Соответственно при каком-либо сбое начинать проверку надо с собственной системы. Потому что поломку инфраструктуры провайдер увидит раньше вас с помощью систем мониторинга.
Кому выгоден SLA и в чём его особенности
Наличие SLA — это норма для любого облачного провайдера. Клиенты часто уточняют цифры на этапе знакомства с компанией, а провайдеры гордо указывают заветные девятки в своих промо-материалах. При этом не всегда понятно, чем может быть полезен документ и в каких случаях нужно срочно обращаться к провайдеру, а в каких — разбираться самостоятельно.
Как мы уже сказали, клиентские ВМ — это своеобразная закрытая зона для провайдера. Но при этом большинство сбоев происходит именно там. Переполнение дисков, блокировка учётных записей, сбои из-за глючного обновления или неправильной настройки приложений — эти проблемы не подпадают под SLA. Их решают силами клиента. Нередко — с привлечением сотрудников провайдера, но уже в рамках отдельных договорённостей.
Соглашение об уровне обслуживания фиксирует следующие требования:
Соглашение об уровне обслуживания имеет ещё одну важную особенность: измеряемость. Все критерии, прописанные в Соглашении, имеют цифровые значения. Так, допустимое время простоя сервисов и сроки устранения проблем указываются в минутах.
Получается, что SLA выгоден обеим сторонам. Облачный провайдер защищён от необоснованных требований, а клиент получает гарантии, что возникший инцидент будет решён в конкретные временные рамки.
Время реакции на инциденты и другие цифры
Раз уж мы заговорили про контроль сроков и время реакции на инциденты, давайте рассмотрим этот вопрос детальнее.
Время реакции на инциденты в SLA — это числовая метрика, которая охватывает период времени с момента поступления или регистрации тикета об инциденте до момента его закрытия. Она не равна времени простоя, так как является составляющей её длительности. Математически всё это выглядит так:
Время инцидента = Время реакции на произошедшее + Время решения инцидента
Если реакция на инцидент или общее время простоя выше зафиксированного в SLA, это может грозить провайдеру выплатой неустойки. Поэтому облачные провайдеры строго следят за соблюдением сроков и внедряют новые технологические решения, позволяющие добиться нужного уровня доступности.
Кстати, инциденты бывают разные. Условно говоря, критические, важные и типовые. Все запросы и инциденты разделяются по приоритетам, что позволяет провайдеру быстрее реагировать на действительно важные обращения и вовремя устранять неисправности. Все заявки обрабатываются в круглосуточном режиме, но время на исполнение у всех разное.
Доступность — это те самые девятки, которые показываются как SLA. И в них кроется особая магия. Посмотрите:
Время простоя за месяц
Время простоя за год
7 час. 18 мин. 17,5 сек.
3 дня 15 час. 39 мин. 29.5 сек.
8 час. 45 мин. 57 сек.
4 часа 22 мин. 58,5 сек.
1 час 34 мин. 40,3 сек.
Вы заметили, как с ростом процентной точности снижается время простоя? 99% — это почти 4 дня простоя в год, а заявленные Cloud4Y 99,982% — всего полтора часа. Разница по времени колоссальная, хотя по цифрам — меньше 1 процента.
И тут встречается хитрость со стороны провайдера, когда в договоре он указывает время простоя не за год, а за месяц. Обязательно уточняйте этот момент, чтобы потом не получить неприятный сюрприз.
От чего зависят проценты? От организации инфраструктуры провайдера. Определённый уровень отказоустойчивости сервиса напрямую зависит от того, как построена виртуальная инфраструктура. Уровень доступности в 99,95% требует от провайдера наличия как минимум одного кластера active-passive. Показатель 99,982% дают распределённые системы с использованием нескольких ЦОДов Tier III. У Cloud4Y для обеспечения такого уровня доступности используется Hi-End оборудование корпоративного уровня, каждый элемент нашей инфраструктуры многократно дублируется, а информация передаётся по защищённым каналам и хранится в современных дата-центрах, расположенных в России и за рубежом.
Подчеркнём, что 99,99% и тем более 99,999% не должны быть самоцелью. Во-первых, такой уровень доступности будет стоить сильно дороже. Во-вторых, он не всегда нужен. Да, Cloud4Y может предложить некоторые сервисы с таким уровнем доступности. Но подавляющему большинству клиентов достаточно базового 99,982%.
Ещё один интересный нюанс — совокупная доступность. Она считается по наименьшему показателю. Если, к примеру, ваше приложение имеет доступность 99,95%, а дата-центр и облако, в котором оно развёрнуто — 99,982%, то общая доступность всё равно будет 99,95%. Всё определяется самым слабым звеном, не забывайте об этом. Нестабильное, часто сбоящее приложение не спасёт даже самое надёжное геораспределённое решение.
Чтобы снять все вопросы, приведём заявленный уровень доступности дата-центров разного уровня:
Уровень надежности ЦОД
Время простоя, часов в год
Что ещё может учитываться в SLA
Несомненно, доступность является самым важным параметром облачных ИТ-сервисов. Но виртуальные машины могут здорово потрепать нервы и при 100% доступности. Сетевые задержки, недостаточное количество IOPS, медленная СХД — эти и другие проблемы тоже нужно предусмотреть. Какие метрики нужно прописать в SLA?
Вместо заключения
SLA — это важный инструмент, удобный как для поставщика облачных услуг, так и для потребителя этих самых услуг. Если разобраться в деталях и понять, например, что означают сотые доли процента в метрике доступности, то у вас не будет завышенных ожиданий, но и уровень предоставляемого сервиса вы тоже сможете быстро оценить. В целом, можно перечислить следующие преимущества использования SLA для компании-клиента: