Условия 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 вам, скорее всего, не поможет. А вот работа с собственником мощностей, а не перекупщиком — значительно ускорит решение возможных проблем.

Источник

Service Level Agreement (SLA): все о соглашении об уровне сервиса

Время чтения : 12 минут

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

Что такое SLA-соглашение?

Грамотно составленное соглашение об уровне сервиса SLA уменьшает число формулировок с двояким толкованием. Заказчик и провайдер устанавливают ясные и понятные правила сотрудничества. Стороны четко знают свои обязанности и оперируют идентичными терминами.

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

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

SLA в информационных технологиях

В сфере ИТ SLA означает договор на оказание IT-услуг. В стандартном соглашении обычно оговариваются следующие моменты:

Зачем бизнесу SLA?

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

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

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

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

Примечание
>SLA направляет сотрудничество с провайдером в цивилизованное русло. Стороны соглашения имеют четкое представление о своих правах и обязанностях. Между ними реже возникают споры и недопонимание.

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

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

Как правильно написать SLA

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

Пример классификации приоритетов в SLA-соглашении

SLA-соглашение начинается с вводной или определительной части. В самом начале договора приводится глоссарий. В словаре коротко описывается информационная система (ИС) и перечисляются роли участников.

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

На следующем этапе определяются границы действия Service Level Agreement (SLA). Территориальные устанавливают, как и где оказывается сервис. Например, в удалённом режиме или офисе заказчика. Временные отвечают на вопрос, когда предоставляются услуги – круглосуточно/определённое время, будние/выходные/праздничные дни.

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

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

Хорошая практика – приводить примеры услуг и сразу оговаривать, что в них входит или, наоборот, не включается. Услуги описываются компактно и нумеруются. В нумерованных списках гораздо проще ориентироваться.

Готовая определительная часть должна вызывать минимум вопросов. Чем меньше малопонятных моментов, тем лучше. Идеальный вариант – заказчик или его представитель понимает написанное с первого раза.

Метрики для SLA

Правильный выбор метрик для соглашения об уровне сервиса напрямую зависит от знания и понимания предметной области. В контексте информационных систем чаще всего оперируют 2 понятиями – время реакции на инцидент и целевое время решения проблемы.

Существуют и другие метрики:

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

При указании времени поддержки оговаривается период, когда провайдер не имеет возможности поддерживать работоспособность сервиса. Многие организации работают с понедельника по пятницу и отвечают на запросы заказчиков с 9-10 утра до 18 вечера. Аналогичный график прописывается в договоре техподдержки SLA.

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

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

4 главных требования к метрикам SLA

Если в договоре техподдержки SLA или аналогичном документе указывается больше 1 метрики, один из параметров обозначается как основной. Иначе провайдеру придётся заниматься сопоставлением метрик, а не критически важными проблемами. Распространённой практикой считаются штрафы за отклонение от нормы именно главного параметра.

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

Как мы видим, облака все больше и больше входят в повседневную жизнь как обычных людей, так и целых компаний. Облачные вычисления сильно упрощают, и главное – ускоряют процесс создания новых сервисов, что в свою очередь положительно сказывается на общих результатах компаний. Это гибкий инструмент, функционал которого совершенствуется год от года, позволяя переложить часть непрофильных задач на плечи провайдеров и сфокусироваться на своем основном бизнесе. Важной частью успешной работы является правильно составленный договор SLA. Михаил Тутаев, Лидер продуктового направления PaaS SberCloud

Чек-лист: важные моменты SLA

Итак, мы получили общее представление, что такое SLA в IT. Пришла пора рассмотреть, на какие моменты стоить обратить внимание при подготовке SLA.

Группы пользователей. Когда система большая, не пытайтесь объять необъятное. Для начала возьмите несколько групп. Допустим, привилегированные и обычные пользователи. С парой категорий работать проще и эффективнее. Заодно получите мощный фундамент знаний для дальнейших действий.

Критические сервисы. Яркий тому пример – подключение к CRM. Если компания ведёт активную торговую деятельность, отсутствие связи с CRM рискует обернуться убытками. Работа менеджеров по продажам остановится или сильно замедлится.

Нормы качества. Принимайте в расчёт функционал сервиса и так называемые «целевые показатели».

Параметры и нормативы качества сервисов. Характеристики должны отвечать 2 требованиям. Во-первых, сопоставляться с бизнес-целями, которые преследует компания. Во-вторых, отражать потребности бизнес-пользователей системы. Примеры параметров – время устранения инцидентов и восстановления работы.

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

Информирование пользователей. Об SLA оповещаются все без исключения лица, которых касаются правила из соглашения.

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

Анализ и оптимизация. Постоянно предпринимайте эффективные действия для достижения целевых показателей. Сервис должен на 100% удовлетворять потребности конечных пользователей.

Примеры готовых договоров SLA на английском языке

Резюме

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

Источник

4 главных вопроса об SLA-соглашении

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

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

SLA (англ. Service Level Agreement – соглашение об уровне сервиса) – это соглашение между заказчиком и исполнителем о том, какие, когда и как будут предоставляться услуги. Также в него входят права и обязанности сторон. Используется SLA в IT и сфере телекоммуникаций.

Этот термин относится к методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), в которой описываются лучшие способы организации работы компаний, предоставляющих IT-услуги.

Для чего нужно SLA

Простыми словами, SLA – это договор, в котором подробно описаны предоставляемые услуги, их качество, время реагирования на заявку и ее исполнение.

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

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

И чтобы избежать таких моментов и сохранить хорошие отношения, аутсорсинговая компания может составить SLA, в котором:

И теперь клиенты будут знать, что если разом перестали работать 20 тонких клиентов из 30, то сотрудник сможет заняться этим через 15–30 минут, а на устранение уйдет от 1 до 5 часов. А если проблема с принтером, то отклик будет только через час, хотя решение проблемы займет всего 10 минут.

Как составить SLA

Существует типовая структура, которой следует придерживаться, чтобы составить договор аутсорсинга на оказание услуг:

Все эти пункты должны быть прописаны очень подробно. Так, например, описывая уровень качества, нужно учесть такие параметры, как:

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

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

Наиболее полную информацию о SLA можно встретить в описаниях стандартов ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»).

Источник

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 поломки из-за косных приложений или неправильной настройки ВМ не удастся.

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

Источник