Я работаю в небольшой компании-разработчике, к которой все чаще обращаются с просьбой составить официальные соглашения об уровне обслуживания (SLA) для наших продуктов на основе конкретных конфигураций.
С точки зрения разработки меня это устраивает, однако нет смысла говорить, что мы достигнем конкретных целей с точки зрения программного обеспечения, если они нереалистичны с точки зрения оборудования/платформы — клиентов волнует только общая доступность системы.
На что мне следует обратить внимание с точки зрения платформы? Какие метрики и уровни?
Кроме того, какие есть подводные камни (например, с точки зрения программного обеспечения я бы никогда не стал брать на себя обязательства по времени исправления — я понятия не имею, придется ли мне переписывать весь продукт, чтобы что-то исправить, поэтому говорить, что мы можем исправить это за 5 дней, потенциально невозможно — каких обязательств мне следует избегать с точки зрения оборудования/ОС/платформы)?
решение1
У меня большой опыт в этой сфере; я много работаю для нескольких компаний из списка Fortune 5, которые управляют своими центрами обработки данных так, как это делает интернет-провайдер для различных отделов компании, нуждающихся в услугах хостинга и поддержки.
Обычно у них есть две метрики, которые называются SLA (Соглашение об уровне обслуживания) и OLA (Соглашение об уровне эксплуатации).
SLA выполняются через тип используемого оборудования. Когда мы говорим об SLA, мы используем уровни для их описания. SLA-1 — это нулевое время простоя, SLA-2 — это что-то вроде до 1 часа простоя, SLA-3 — 8 часов и т. д. SLA выполняются через использование избыточного оборудования. В одной компании мы используем много Cisco для создания высокой доступности (Cisco CSM и оборудование GSS). Когда мы говорим об уровнях SLA, мы обычно говорим о HA (высокая доступность) и DR (аварийное восстановление). В ситуациях, когда у компании есть несколько центров обработки данных, компонент HA обычно является атрибутом для каждого центра обработки данных, в то время как DR является атрибутом для всего центра обработки данных; оба измеряются с точки зрения RPO (целевая точка восстановления) и RTO (целевое время восстановления), что означает уровень SLA.
OLA, в реальных базовых терминах, это то, как быстро кто-то (человек) реагирует на событие, требующее ручного вмешательства/корректирующего действия. OLA обычно измеряются также с точки зрения времени реагирования; они используют те же цели RTO/RPO. Одна компания, которую я консультирую, использует 6 уровней для своих показателей OLA. Первые 3 уровня здесь являются примером этого:
OLA-1: RTO 0 < 2 часов OLA-2: RTO >= 2 и <= 4 часа OLA-3: RTO >= 24 часа и <= 30 дней, если нет сбоя в центре обработки данных, если сбой в ЦОД > 30 дней.
То, что управляет показателями OLA и SLA, называется рейтингом CIA. CIA = Конфиденциальность, Целостность и Доступность. Данные для приложения должны быть классифицированы бизнес-подразделением, оплачивающим это приложение. CIA поможет определить, какими должны быть OLA и SLA. Каждой части уровня CIA присваивается номер от 1 до 3. Так, например, рейтинг CIA 1-1-1 будет означать «Высокая конфиденциальность», «Наивысший уровень целостности» и «Наивысший уровень доступности». Рейтинг CIA 3-3-3 — это самый низкий возможный уровень. Таким образом, рейтинг CIA 3-3-3 обычно соответствует уровню SLA и OLA 6, где SLA-6 и OLA-6 — это самый низкий (самое долгое время ответа) гарантированный уровень.
То, как вы получаете рейтинг CIA, обычно сводится к выяснению того, сколько денег потеряет бизнес, если данные будут украдены (Конфиденциальность), скомпрометированы (Целостность) или когда системы выйдут из строя (Доступность). Таким образом, компания, которая может потерять 10 миллионов долларов, если конфиденциальные данные будут украдены, может иметь рейтинг C 1 или, если эта потеря данных не является критической и обойдется компании всего, скажем, в 1000 долларов, то вместо этого у вас может быть рейтинг C 3.
Именно так обычно решают подобные вопросы крупные компании, которые я консультировал.
решение2
Я бы не спешила брать на себя обязательства по времени исправления проблем с оборудованием, как и с программным обеспечением. Никогда не знаешь, когда будешь ждать, пока поставщик исправит критическую ошибку в чем-то. Что касается уровней SLA, я обнаружила, что они, как правило, имеют форму «кто-то будет работать над вашей проблемой в течение X часов». X, конечно, зависит от того, сколько они платят, но где-то от 1 до 8 часов, по моему опыту, кажется нормальным.
решение3
Если вас просят предоставить SLA для восстановления проблем с оборудованием, где установлено ваше программное обеспечение, ответ — «нет». Вы можете взять на себя обязательство по времени ответа, но без контроля всего стека оборудования/ОС/ПО вы не можете взять на себя обязательство по времени разрешения.
Может быть, ваш клиент неловко говорит вам, что ему действительно нужно размещенное предложение для вашего продукта? Таким образом, он может избежать любых внутренних проблем, о которых он беспокоится, и просто выписать вам чек.
решение4
При заключении соглашения об уровне обслуживания (SLA) следует учитывать, что само по себе соглашение об уровне обслуживания (SLA) абсолютно ничего не значит и должно соблюдаться вместе со штрафными санкциями в случае его невыполнения.
Например, наш интернет-провайдер предоставляет нам 100% SLA на сеть, но максимальная сумма, которую мы можем получить обратно, равна нашему ежемесячному счету, который действительно невелик, поскольку в настоящее время пропускная способность дешева и даже близко не сопоставима с суммой, которую мы теряем при сбоях в работе сети.
Кроме того, в контрактах обычно прописывается, как быстро кто-то отреагирует на проблему, а не сколько времени на самом деле потребуется, чтобы ее исправить. Так что если они заставляют вас обещать короткие сроки реагирования, просто поставьте стажера в ночную смену, чтобы он перетасовывал для вас билеты, пока вы не проснетесь, и все.
По моему опыту, все эти SLA-соглашения на практике не имеют практически никакого значения, если вообще имеют.