Что такое sla простыми словами

Что такое SLA в управлении?

Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT Infrastructure Library) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.
В SLA описываются условия предоставления услуг (сервисов), устанавливается перечень таких услуг, а также правила, по которым заказчик будет пользоваться этими сервисами. В то же время SLA — один из основных механизмов, позволяющих управлять качеством ИТ-услуг и управлять ожиданиями пользователей.

Что должно быть в SLA?

Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.

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

SLA: с чего начать

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

Ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется — Service Level Management, SLM.

Источник

Что такое SLA

Service Level Agreement или SLA (соглашение об уровне сервиса) — три слова, определяющие подходы компании к организации ИТ-процессов. Согласно ITIL (IT InfrastructureLibrary) SLA — это мини-договор, устанавливающий параметры качества предоставляемых бизнесу ИТ-услуг.

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

Что должно быть в SLA

Говоря иными словами, для ИТ-подразделения SLA — это набор параметров ключевых ИТ-процессов, а соблюдение SLA — основной ключевой показатель эффективности (KPI) ИТ-отдела.

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

SLA: с чего начать

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

Начните с 2-3 групп, например, VIP- пользователи и Обычные пользователи

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

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

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

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

И, как бы всем участникам процесса не хотелось, чтобы все заявки по какому-то сервису закрывались за 5 минут, если традиционно они закрываются по 10 дней — значит от 10 дней и надо начинать плясать.

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

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

Постоянно ищите способы оптимизации процессов, чтобы постепенно приближать, например, сроки в SLA к тем, которые нужны бизнесу. Этот процесс называется «Service Level Management», SLM.

Источник

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 – «Задачи управления для информационных и смежных технологий»).

Источник

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

Источник