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