Service Level Agreement (SLA) — определяет взаимную ответственность провайдера ИТ-сервиса и пользователей этого сервиса. В соответствии с рекомендациями ITIL Information Technology Infrastructure Library, SLA – это основной документ, регламентирующий взаимоотношения ИТ и клиентов. Цель документа – дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и с точки зрения пользователя.
Содержание
Существенной частью SLA является каталог сервисов.
Service Level Agreement – SLA – это соглашение между заказчиком и исполнителем, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Соглашение SLA четко прописывает временные рамки для устранения проблем, определяет штрафные санкции, накладываемые на нашу компанию в том случае, если качество услуг оказалось ниже прописанного в договоре уровня. Это позволит минимизировать ваши убытки. Таким образом, заказчик получает удобный способ контролировать услуги, быть уверенным в их полноте и качестве. Уникальность услуги в том, что SLA дает понятный ответ на вопрос «Хорошо или плохо работает служба поддержки?».
Структура
Типовая модель SLA должно включать следующие разделы:
В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное для максимизации способности удовлетворять SLA.
Что обязательно стоит включить в SLA?
На что еще обратить внимание?
Для того, чтобы выстроить эффективное взаимодействие с подрядчиком, необходимо одинаково понимать важность бизнес-процессов, а также обеспечить прямую коммуникацию с бизнесом
От чего зависит стоимость и как не переплатить?
Как еще можно снизить стоимость?
Зачем нужны SLA
Из чего состоит SLA?
Наконец, SLA – это управление ожиданиями пользователей. Качественным может быть только такое обслуживание, когда каждый, кто подает заявку, всегда знает – когда эта заявка будет исполнена. То есть когда мы грамотно управляем ожиданиями наших пользователей.
Внедрение Service Desk, безусловно, тесно связано как с определением каталога сервисов, так и с разработкой SLA. Поскольку:
Ошибки
Отсутствие правил расставания
Невнимательность к санкциям
Нет механизма приостановления / возобновления работы
Как это сделать?
За каждой услугой / запросом пользователя стоят свои процессы, запускаемые в ИТ-службе. В этом плане SLA – это возможность построить ИТ-процессы и быть уверенным, что именно такая организация поможет работать эффективно с точки зрения пользователей. Введение четко регламентированного времени реакции/устранения инцидента/предоставления услуги является частью масштабного процесса SLM, однако это возможно только в том случае, если в ИТ-службе уже налажены более элементарные процессы. Как же в этом случае построить эффективный процесс управления уровнем сервиса?
Другими словами, чтобы указать в SLA реально выполнимые сроки, мы должны: а) знать, какие сроки мы в состоянии соблюдать сейчас; б) понимать, какой процесс стоит за соблюдением этих сроков.
Резюме: при разработке SLA необходимо учитывать несколько ключевых моментов
SLA, SLO и SLI: в чем разница?
Что общего у всех технологических компаний? Пользователи.
Работаете ли вы в поисковой системе Google, услугами которой бесплатно пользуется миллиард ежемесячных активных пользователей, или в системе Salesforce с 3,75 миллионами платных подписчиков — создание технологического продукта всегда связано с обслуживанием людей.
В современном мире постоянной доступности люди предъявляют высокие требования как к бесплатным, так и платным сервисам. Скорость. Время безотказной работы. Удобный интерфейс. Современные пользователи ожидают соответствия высоким стандартам.
Компания Looker выбрала Opsgenie с целью организации ежедневного сервиса для 200 000 пользователей.
Именно поэтому компаниям важно знать и соблюдать SLA, SLO и SLI — три аббревиатуры, которые представляют обещания, данные пользователям, внутренние цели, которые помогают выполнять обещания, и отслеживаемые показатели, позволяющие понять, как мы справляемся.
Цель этих трех компонентов — сформировать у всех (и поставщиков, и клиентов) общее представление о работе системы. Как часто будут доступны ваши системы? Как быстро отреагирует ваша команда на отказ системы? Какие обещания вы даете в отношении скорости и функциональных возможностей? Пользователи хотят это знать, поэтому вам нужны SLA, SLO и SLI.
SLA: соглашения об уровне обслуживания
Что такое SLA?
SLA (соглашение об уровне обслуживания) — это соглашение между поставщиком и клиентом об измеримых показателях, таких как время безотказной работы, время реагирования, а также мерах ответственности.
Эти соглашения обычно составляются новыми юридическими и бизнес-командами компании. В них включаются обещания, которые вы даете клиентам, а также последствия, которые повлечет за собой невыполнение этих обещаний. Как правило, последствия включают в себя штрафы, компенсации или продление лицензий.
Задача SLA
Как известно, SLA сложно измерить, представить в отчете и выполнить. Эти соглашения (обычно их пишут люди без детальных знаний о технологиях) часто содержат обещания, которые командам трудно измерить. Они не всегда соответствуют текущим и постоянно меняющимся бизнес-приоритетам и не учитывают всех тонкостей.
Например, соглашение SLA может содержать обещание, что команды решат проблемы с продуктом X в течение 24 часов. При этом в SLA не оговаривается, что произойдет, если клиенту потребуется 24 часа на отправку ответов или снимков экрана, необходимых команде для диагностики проблемы. Означает ли это, что 24 часа, отведенные команде, пропали из-за медлительности клиента? Или отсчет времени начинается после получения отклика от него? В SLA должны быть ответы на эти вопросы, но часто их нет. Поэтому многие менеджеры ИТ относятся к соглашениям неодобрительно.
По мнению многих экспертов, для решения этой задачи нужно прежде всего привлекать к созданию SLA технических специалистов. Чем более тесным будет сотрудничество команд ИТ и DevOps с юридическими и бизнес-командами при создании соглашений SLA, которые соответствуют реальным ситуациям, тем больше будут отражены в SLA реальные условия (например, задержка решения проблемы по вине клиента).
Кому нужны соглашения SLA?
SLA — это соглашение между поставщиком и клиентом, который оплачивает сервис. Компании, которые предоставляют бесплатные услуги, вряд ли нуждаются в SLA для своих пользователей.
SLO: цели уровня обслуживания
Что такое SLO?
SLO (цель уровня обслуживания) — это соглашение в рамках SLA о конкретном показателе, например о времени безотказной работы или времени реагирования. Таким образом, если соглашение SLA является формальным соглашением между вами и клиентом, то SLO — это отдельные обещания, которые вы даете клиенту. Соглашения SLO формируют ожидания клиентов и показывают командам ИТ и DevOps, каких целей они должны достичь и на какие показатели ориентироваться.
Задачи SLO
Соглашения SLO вызывают меньше неодобрения, чем SLA, но могут создать не меньше проблем, если будут расплывчатыми, излишне усложненными или не поддающимися измерению. По мнению инженеров, главная черта хороших соглашений SLO — простота и ясность. Претендовать на статус SLO могут только самые важные показатели. Цели должны быть изложены простым языком и, как и в случае SLA, должны всегда учитывать такие проблемы, как задержки на стороне клиента.
Кому нужны соглашения SLO?
Если соглашения SLA актуальны только для платных клиентов, соглашения SLO могут быть полезны как для платных, так и для бесплатных аккаунтов, а также для внутренних и внешних клиентов.
Внутренние системы, такие как CRM, репозитории клиентских данных и интранет, могут быть не менее важны, чем внешние системы. Соглашения SLO для этих внутренних систем — не только важное условие достижения бизнес-целей. Они позволяют внутренним командам достигать собственных целей, ориентированных на клиента.
SLI: индикатор уровня обслуживания
Что такое SLI?
Индикатор уровня обслуживания (SLI) измеряет соответствие цели уровня обслуживания (SLO). Например, если в SLA указано, что системы будут доступны 99,95 % времени, то в качестве SLO, вероятно, будет выбрано время безотказной работы 99,95 %, а в качестве SLI — фактическое измеренное время безотказной работы. Возможно, оно составит 99,96 %. Или 99,99 %. Чтобы удовлетворять требованиям SLA, индикатор SLI должен соответствовать обещаниям, зафиксированным в этом документе, или превосходить их.
Задачи SLI
Как и в случае SLO, задача состоит в том, чтобы индикаторы SLI были простыми, выбранные показатели можно было легко отслеживать, а работа ИТ-команд не усложнялась из-за отслеживания слишком большого числа показателей, которые на самом деле не важны для клиентов.
Создайте подробный план аварийного восстановления
Что вы будете делать, когда столкнетесь с простоем? Если вы еще не знаете ответ на этот вопрос, значит, ваш ответ — «Терять драгоценное время, пытаясь понять, что делать».
Чем лучше будет составлен план реагирования на инциденты, тем быстрее и эффективнее ваши команды будут справляться с ними. Вот почему первым делом в любой новой программе управления инцидентами нужно подготовить процесс и план.
Кому нужны индикаторы SLI?
Индикаторы SLI нужны любой компании для проведения измерений, результат которых можно сравнивать с SLO. На самом деле соглашения SLO бесполезны без SLI.
Рекомендации по SLA, SLO и SLI
Согласуйте SLA с ожиданиями клиентов
Каждая часть соглашения с клиентом должна создаваться с учетом того, что важно для клиента. Фактически инцидент может требовать рассмотрения 10 различных компонентов. Но клиенту важно только, чтобы система функционировала согласно его ожиданиям.
Соглашения SLA и SLO должны отражать эту ситуацию. Не усложняйте соглашения, углубляясь в детали и давая отдельные обещания по каждому из этих 10 компонентов. Ограничьтесь обещаниями в отношении функциональных возможностей верхнего уровня, ориентированных на пользователя. Это повысит удовлетворенность клиентов и не запутает их, а кроме того, облегчит работу ИТ-специалистам, ответственным за выполнение обещаний SLA.
Пишите SLA простым языком
Клиенты не всегда будут сами обращаться за разъяснениями. Поэтому если соглашение SLA написано слишком сложным языком, в будущем вас могут ожидать неприятные недоразумения. Чем проще язык, тем меньше вероятность конфликтов с клиентами в будущем.
Чем меньше SLO, тем лучше
Не все показатели важны для успеха клиента, поэтому не каждый показатель следует превращать в SLO. Используйте как можно меньше SLO. Сосредоточьтесь на тех целях, которые особенно важны для клиентов.
Не каждый отслеживаемый показатель должен стать SLI
Аналогичным образом, отслеживание работы системы по 10 компонентам для каждого из 10 соглашений SLO очень быстро станет неподъемной задачей. Вместо этого мыслите стратегически: выберите действительно важные показатели для основных соглашений SLO и направьте свою энергию на их эффективное отслеживание.
Учитывайте факторы, не зависящие от ИТ-команды
Что происходит, когда решение проблемы задерживается по вине клиента? Если эта ситуация четко не оговорена в SLA, команда будет стремиться к невыполнимому стандарту, пытаясь решить проблему без участия клиента.
Предусмотрите бюджет ошибок
Если предусмотреть возможность сбоев, это не только защитит компанию от нарушения SLA и тяжелых последствий, но и оставит пространство для маневра, чтобы команда могла быстро вносить изменения и имела время на опробование инновационных решений, которые могут оказаться неудачными.
Кстати, компания Google рекомендует использовать остаток бюджета ошибок на плановые простои. Это помогает выявлять непредвиденные проблемы (например, ненадлежащее использование серверов со стороны сервисов) и поддерживать соответствующие ожидания клиентов.
Не ставьте перед собой труднодостижимые цели
То, что команда, вероятно, сможет поддерживать безотказную работу в течение 99,99 % времени, не означает, что 99,99 % следует указать в качестве SLO. Всегда лучше обещать меньше, а делать больше. Особенно это касается agile-команд, которые стремятся запускать продукты рано и часто: им необходим бюджет ошибок для поддержания такого быстрого темпа.
Как это влияет на SRE?
SLA, SLO и SLI являются основой успеха для тех, кто следует модели Google и использует команды по техническому обеспечению надежности сайта (SRE) для преодоления разрыва между разработкой и эксплуатацией. Соглашения SLA помогают командам установить границы и определить размер бюджета ошибок. Соглашения SLO позволяют расставить приоритеты в работе. А индикаторы SLI указывают инженерам SRE, когда им следует приостановить все запуски, чтобы сэкономить бюджет ошибок, а когда можно расслабиться.
Изучайте информирование об инцидентах с помощью Statuspage
В этом руководстве мы покажем, как использовать шаблоны инцидентов, чтобы наладить эффективную коммуникацию во время разрешения инцидента. Применимо ко многим видам технических сбоев.
Важность процесса разбора инцидентов
Разбор инцидента, или анализ результатов реагирования на инцидент, — это лучший способ проработать произошедшее и зафиксировать полученный опыт.
Что такое 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.
Как управлять параметрами SLA через показатели KPI в сервисной компании (часть 1)
Что такое SLA – это согласованный уровень качества предоставления данной услуги. Параметры качества услуги должны быть измеримыми, то есть представимыми в виде числовых метрик в определённый период времени. Мы можем использовать оценку ключевых показателей эффективности (KPI) при работе с SLA, и таким образом, через введение KPI повысить прибыльность сервисной компании.
Мы предлагаем вам готовый инструмент, который позволит собственникам и руководителям упростить на всех этапах управление сервисной компанией, обеспечить постоянный контроль на всех участках работ и постоянную оптимизацию всех процессов. В цикле статей «Описание проекта ELMA KPI для сервисной компании» мы подробно объясним и наглядно продемонстрируем, как с помощью системы KPI повысить прибыльность сервисной компании и качество предоставляемых услуг. Давайте разберёмся, какие параметры входят в SLA сервисной компании и через какие ключевые показатели эффективности можно максимально оптимизировать участки работ.
Таким образом, с помощью введения KPI мы можем управлять оптимальными показателями SLA. Кроме того мы решаем ещё ряд проблем.
Оптимизация бизнес-процессов и снижение добавленной стоимости продукции на каждом участке цепочки. Можно выделить наиболее ресурсоемкие участки, на которых происходит рост добавленной стоимости продукта. Ввести целевые показатели эффективности для лица, ответственного за данный участок, и, таким образом, мотивировать его на оптимизацию и качественное выполнение своих обязанностей. При этом надо понимать, что снижение добавленной стоимости продукта может быть не прямым – где-то это сокращение времени выдачи изделия из ремонта, а где-то повышение квалификации сотрудника.
Внедрение системы KPI позволяет получить конкурентное преимущество за счет повышения качества и сокращения сроков предоставляемых услуг. Повышение качества обслуживания клиентов осуществляется за счет внесения показателей, основанных на элементах обратной связи. Это анализ повторных ремонтов, обзвон клиентов по завершению работ, заполнение анкет. Также это может быть анализ повторных ремонтов. Все это складывается в оценку качества работы как отдельных сотрудников, так и всего сервиса в целом. Поэтому анализируя обратную информацию, полученную от клиентов, мы можем повысить качество предоставляемых услуг и сделать компанию более конкурентоспособной.
Повышение квалификации персонала. Клиенты становятся всё более требовательными. На общую удовлетворённость качеством работы сервисного центра влияет много факторов. Даже самый быстрый и качественный ремонт может испортить низкая квалификация менеджера по приёму изделий. Система оценки квалификации персонала мотивирует его на обучение. Причём, как на прохождение общих курсов компании, так и на саморазвитие. При введении KPI сотрудник понимает, что для увеличения его показателей эффективности, а, соответственно – зарплаты, ему надо повышать свою квалификацию. Это касается всех сотрудников: от менеджеров по работе с клиентами и инженеров, до курьеров и работников склада.
Постоянный анализ и улучшение процессов. Система предоставляет отчёт о текущем состоянии дел в виде легко читаемых таблиц и графиков. Таким образом, мы можем оперативно отреагировать на изменения плановых показателей и во время принять правильное управленческое решение. Возможно, по ряду услуг не дополучаем деньги. Или наоборот. Система позволяет анализировать и постоянно улучшать все участки работ.
В следующей статье мы подробно опишем, как правильно прописать дерево показателей для ключевых должностей компании, настроить матрицу эффективности и связать её с целевым управлением компанией.
Хватит думать, что 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 вам, скорее всего, не поможет. А вот работа с собственником мощностей, а не перекупщиком — значительно ускорит решение возможных проблем.
