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