Кратко

  • Процент доступности в заголовке SLA не определяет объём фактически переданного поставщику риска. Его определяют единица измерения, архитектурные предпосылки, база расчёта кредита, исключения, верхние пределы, сроки и доказательства.
  • Сервисный кредит обычно привязан не к потерям бизнеса, а к плате за конкретный затронутый облачный ресурс. Поэтому час простоя критической системы и час простоя дешёвого компонента могут иметь совершенно разный экономический разрыв между компенсацией и ущербом.
  • Архитектура нередко является частью права на более высокий SLA. У AWS региональные 99,99% для EC2 требуют одновременного размещения работающих инстансов минимум в двух Availability Zones; IBM прямо показывает ту же экономику через пример VPC: чтобы в полной мере воспользоваться SLO 99,999%, нужны три виртуальных сервера в трёх зонах и балансировщик. (Amazon Web Services, Inc.)

Сначала формула, потом процент

У Cloudflare полезно буквально читать множители. Affected Customer Ratio — это отношение уникальных посетителей, измеряемых по IP-адресам и затронутых незапланированным сбоем, ко всем уникальным посетителям. Сервисный кредит считается как произведение минут Outage Period, умноженных на пять, и затронутой доли, также умноженной на пять, делённое на Scheduled Availability. Базой самого кредита служат только ежемесячные регулярные платежи, относящиеся к покрытому Service.

Именно здесь рекламное число начинает распадаться на договорные переменные. Если час простоя затронул не 100%, а, скажем, гипотетические 20% посетителей, при тех же остальных допущениях расчёт становится ((60 × 5) × (0,2 × 5)) / 43 200, то есть около 0,69% соответствующей месячной платы. Реальный экономический эффект для конкретной компании при этом может быть как малым, так и огромным: формула не знает выручку клиента, штрафы перед его собственными заказчиками, стоимость аварийных работ, репутационный ущерб или цену потерянной транзакции.

Даже знаменатель не является просто «числом минут в месяце». В Cloudflare Scheduled Availability исключает запланированный клиентом простой и простой, относимый к форс-мажору. Те же категории не входят в Unscheduled Service Outage. Поэтому перед чтением результата нужно знать не только продолжительность видимого инцидента, но и то, какие минуты вообще попали в договорную систему координат. (Cloudflare)

Это хороший пример более общего правила: SLA — не статистический снимок всей надёжности приложения. Это тонкий договорный измеритель заранее определённой поверхности отказа.

Измерительная граница создаёт обязательство

У AWS EC2 граница устроена иначе. Региональный SLA 99,99% действует, когда все работающие EC2-инстансы одновременно размещены в двух или более Availability Zones одного региона; для отдельного инстанса существует отдельный SLA 99,5%. Если соответствующий порог нарушен, шкала кредита составляет 10%, 30% или 100% в зависимости от фактического уровня доступности. База — месячный счёт EC2 в затронутом регионе либо счёт соответствующего отдельного инстанса; разовые платежи, включая upfront-платежи за Reserved Instances, из расчёта исключены. Кредит обычно применяется к будущим платежам. (Amazon Web Services, Inc.)

Google Compute Engine ещё нагляднее показывает, что «доступность» не является одной универсальной величиной. Monthly Uptime Percentage и финансовый кредит определяются по календарному месяцу на уровне Project и Region либо, для Single Instance, по отдельному инстансу. Для Instances in Multiple Zones обязательство зависит также от Network Service Tier и региона. Период простоя должен длиться как минимум одну последовательную минуту: частичная минута или прерывистая недоступность продолжительностью менее минуты в Downtime Period не засчитывается. Уровни кредита — 10%, 25% и 100%. (Google Cloud)

Это не повод объявлять один подход «лучше» другого. Они измеряют разные объекты разными способами. Для покупателя важен другой вопрос: совпадает ли измеряемый объект с тем, что бизнес считает отказом?

Если пользователь не смог совершить платёж из-за цепочки из DNS, CDN, балансировщика, виртуальной машины, базы данных и стороннего API, сквозной отказ может быть очевиден операционно, но договорно распадаться на несколько отдельных поверхностей. Одни компоненты могли не нарушить собственный SLA. Другие могли нарушить его, но не пройти порог измерения. Третьи могли попасть под исключение. Результат для клиента один — транзакция не состоялась. Результат по контрактам может оказаться совсем другим.

Более высокий SLA часто надо сначала построить

Архитектура в этих договорах не просто техническая рекомендация. Она может быть условием, от которого зависит само обязательство.

У AWS переход от SLA отдельного EC2-инстанса к региональному SLA означает одновременное распределение работающих инстансов минимум по двум зонам. То есть покупатель не получает более высокую договорную цифру только потому, что выбрал известный облачный бренд: сначала он должен купить и эксплуатировать соответствующую топологию. (Amazon Web Services, Inc.)

IBM проводит различие особенно явно. SLO у компании — цель, а не договорная гарантия; SLA может давать право на сервисный кредит.

В руководстве по resiliency для IBM Cloud VPC приведён SLO 99,999%, однако, чтобы workload в полной мере использовал такую архитектурную цель, минимум составляют три virtual server instances — по одному в каждой из трёх зон multi-zone region — и load balancer. При двух серверах в двух зонах устойчивость ниже, при одном сервере без балансировщика — ещё ниже. IBM одновременно формулирует разделение ответственности: облачный провайдер отвечает за устойчивость и восстановление самого облака, клиент — за устойчивость и восстановление собственной нагрузки. (IBM Cloud)

В экономическом смысле это означает, что номинальная доступность имеет цену входа. Дополнительная зона — это дополнительные вычислительные ресурсы, сетевой трафик, репликация, балансировка, наблюдаемость, тесты failover и операционная сложность. Сравнивать два SLA по двум процентам без стоимости архитектуры, необходимой для получения этих процентов, — всё равно что сравнивать страховые полисы только по максимальной выплате, игнорируя страхуемый объект и условия покрытия.

Кредит считается от счёта, а не от убытка

Вторая принципиальная граница — денежный знаменатель.

Cloudflare применяет кредит только к monthly recurring fees соответствующего Service. AWS привязывает его к счёту EC2 в затронутом регионе или к отдельному инстансу. Google ограничивает максимальный совокупный месячный кредит суммой, причитающейся за соответствующий Covered Service в регионах, где SLO не был выполнен, и применяет кредит к будущему использованию. (Cloudflare)

Oracle формулирует тот же принцип ещё уже: сервисный кредит рассчитывается как процент чистых платежей за фактически использованное количество конкретного Non-Compliant Service в соответствующий Measured Period. Документ предусматривает различные модели использования кредита в зависимости от модели покупки; для ряда кредитных моделей важны сроки использования и истечения. Максимум при этом не может превышать плату за фактически использованное количество соответствующего Non-Compliant Service в измеряемом периоде. (Oracle)

Отсюда возникает фундаментальный разрыв. Пусть критическая система генерирует для компании миллионы выручки, но затронутый облачный компонент стоит несколько тысяч. SLA обычно начинает денежный расчёт со второй величины, а не с первой.

Это не дефект арифметики. Это и есть распределение риска. Провайдер заранее ограничивает объект денежной ответственности стоимостью определённой услуги, а покупатель сохраняет у себя остаточный риск всей бизнес-системы.

Право на кредит нужно ещё оформить

Сбой сам по себе обычно не создаёт автоматически реализованный денежный результат.

Cloudflare требует уведомить Customer Support об инциденте в течение пяти рабочих дней. Для претензии необходимо сообщить детали, включая продолжительность, traceroutes, затронутые URL и предпринятые попытки устранения. Достаточные доказательства должны поступить не позднее конца расчётного месяца, следующего за месяцем инцидента. Cloudflare затем использует разумно доступную информацию для проверки применимости SLA. (Cloudflare)

AWS требует открыть дело через Support Center до конца второго платёжного цикла после инцидента. Для региональной претензии нужны даты и время недоступности, регион, resource IDs и request logs; для instance-level claim — также соответствующая AZ и данные, необходимые для проверки. Непредоставление требуемой информации лишает права на кредит. (Amazon Web Services, Inc.)

Google даёт 60 дней с момента возникновения права на Financial Credit и требует лог-файлы с Downtime Periods, датой и временем. Невыполнение этих условий означает утрату права на кредит. (Google Cloud)

В текущем Oracle PaaS and IaaS Public Cloud Services Pillar Document претензия должна поступить в течение 60 календарных дней после события. Требуются, среди прочего, время и длительность, регион, tenancy, compartment и affected resource OCID, описание попыток устранения и подтверждающие документы или логи. (Oracle)

Из этого следует практический вывод: процедура SLA должна находиться внутри incident response, а не в конце квартала у закупок. Если логи имеют короткий retention, если traceroute не снимался во время отказа, если временная шкала восстановлена по памяти, экономическое право может исчезнуть раньше, чем организация успеет обсудить его с юристами.

Кто контролирует доказательства

Cloudflare прямо говорит, что комплексный мониторинг Customer Content лежит на клиенте; компания рассматривает данные о заявленном Outage Period, полученные коммерчески разумной независимой системой измерения клиента. Для вычисления Affected Customer Ratio Cloudflare использует всю разумно доступную информацию, включая Service Data перед инцидентом. (Cloudflare)

Эта конструкция важна не только юридически. Она показывает, где находится доказательственная поверхность. Клиент лучше видит пользовательский путь и собственную систему; провайдер лучше видит внутреннее состояние своей инфраструктуры. Ни одна сторона сама по себе не обязательно обладает всей трассой отказа.

Поэтому зрелая система контроля хранит не «ещё один красивый uptime dashboard», а минимальный воспроизводимый набор фактов: точное время, затронутые ресурсы, регион и зону, результат внешних проверок, request IDs, логи, сетевые трассы, конфигурацию размещения и версию договора. Измерение должно быть достаточно тонким, чтобы его можно было повторить и объяснить, но не настолько сложным, чтобы после каждого серьёзного сбоя стороны спорили уже о методе вычисления.

Исключения и запрет на сложение меняют экономику

Следующий слой — то, что нельзя суммировать.

AWS не разрешает одновременно требовать Region-Level и Instance-Level кредит для одного и того же Single EC2 Instance. (Amazon Web Services, Inc.)

Google аналогично разрешает учитывать downtime конкретной VM либо как Single Instance, либо в составе Instances in Multiple Zones, но не обоими способами. (Google Cloud)

Oracle предусматривает несколько типов SLA для некоторых сервисов — availability, manageability и performance, — но если один инцидент создаёт право на несколько кредитов для одного Cloud Service, применяется тот вариант, который даёт наибольший кредит, без их сложения. Кредит не может превышать плату за соответствующий фактически использованный Non-Compliant Service. Сам сервисный кредит назван исключительным средством и всей ответственностью Oracle по соответствующему обязательству. (Oracle)

У Cloudflare сервисные кредиты также являются исключительным средством по SLA, а совокупный годовой объём ограничен эквивалентом шести месяцев совокупных ежемесячных service fees. (Cloudflare)

Такое non-stacking правило не говорит ничего о вероятности отказа. Оно говорит о том, сколько договорных последствий может породить один физический инцидент. Если один сбой одновременно ударил по доступности, управляемости и производительности, операционный ущерб способен сложиться; договорный кредит — нет.

Версия договора — ещё одна переменная

SLA живёт во времени. У Cloudflare условия фиксируются на Initial Term, но при продлении начинает действовать версия SLA, актуальная на начало renewal term. (Cloudflare)

Страница Google Compute Engine указывает последнее изменение 4 марта 2025 года и сохраняет ссылки на предыдущие версии. (Google Cloud)

У Oracle особенно показателен сам контроль версии: PDF по указанному публичному адресу сейчас маркирован как July 2026, поэтому для реальной закупки нельзя полагаться на дату из старого внутреннего обзора или сохранённого пересказа — нужно сопоставлять применимый документ с конкретным заказом и сроком договора.

Это редко попадает на архитектурную диаграмму, хотя экономически версия SLA — такой же dependency, как зона или сетевой уровень. Если контракт обновился при продлении, старая таблица кредитов в wiki компании не создаёт старых прав.

SLA не является рейтингом надёжности

У рассмотренных поставщиков различаются измерительные единицы, пороги, архитектурные предпосылки, сроки, денежные базы и правила зачёта. Из этого нельзя честно вывести рейтинг «самого надёжного облака». Публичный SLA сообщает, как определённая часть риска переводится в договорное обязательство и какое средство получает клиент при выполнении условий.

Число вроде 99,99% отвечает только на вопрос внутри своей модели. Для покупателя важнее серия более скучных вопросов: что именно измеряется; какую архитектуру нужно купить; чей мониторинг считается доказательством; сколько времени есть на претензию; какая строка счёта становится базой; что исключено; какие кредиты нельзя сложить; и что остаётся на балансе клиента после максимальной выплаты.

Именно последний остаток определяет сквозной риск workload. Если сервисный кредит покрывает несколько процентов платы за компонент, а остановка приложения стоит на порядки больше, разницу нельзя устранить более внимательным чтением процента. Её приходится закрывать архитектурой, закупочными условиями, резервами, страхованием, планом восстановления и, там где это экономически оправдано, возможностью выхода.

Источники