Почему цифры доступности в облаке часто вводят в заблуждение
Эта тема вообще возникает не на пустом месте. К ней обычно приходят после первого или второго инцидента, когда сервис «формально был доступен», но клиенты почему-то не смогли им воспользоваться. До этого момента на цифры доступности смотрят бегло — как на что-то само собой разумеющееся. 99,9% выглядит достаточно хорошо, чтобы не вчитываться дальше.
Представим простую бытовую ситуацию. Вы заходите в магазин за шоколадкой. На ценнике крупно написано «шоколад», упаковка выглядит знакомо, цена вроде бы адекватная. Уже на кассе выясняется, что речь идёт не о целой плитке, а о небольшом кусочке — всё честно, просто это было написано мелким шрифтом сбоку. Формально вас не обманули. Фактически ожидания и результат не совпали.
С цифрами доступности в облаке происходит ровно то же самое. Процент бросается в глаза, а условия — нет. Большинство проблем начинаются не потому, что провайдер врёт, а потому что стороны по-разному понимают, что именно им пообещали.
Почему это происходит чаще, чем кажется:
- Цифры читаются быстро, а условия — долго;
- Проценты выглядят понятнее, чем формулировки в договорах;
- Доступность воспринимается как «сервис работает / не работает», без полутонов;
- На этапе выбора облака внимание сосредоточено на цене и функциональности, а не на деталях SLA.
Теперь перенесёмся в бизнес-контекст. Компания запускает онлайн-магазин и видит в договоре «99,9% доступности». В голове это превращается в «сайт почти всегда работает». Но в реальности доступность может считаться только для инфраструктуры провайдера, без учёта приложения, базы данных или платёжного сервиса. В результате в момент пика заказов всё формально «зелёное», а пользователи не могут оплатить покупку.
Именно здесь цифры начинают играть злую шутку. Они создают ощущение надёжности, но не отвечают на главный вопрос бизнеса: смог ли пользователь выполнить целевое действие. Для клиента недоступен не дата-центр и не балансировщик. Для него недоступна покупка, оплата или вход в аккаунт.
Поэтому разговор о доступности почти всегда начинается с процентов, но очень быстро упирается в реальность. В договоре всё может выглядеть корректно, а система — всё равно вести себя нестабильно с точки зрения пользователей. Чтобы понять, почему так происходит, нужно разобраться, что именно скрывается за цифрами и чем отличаются обещания провайдера от того, как доступность ощущается в живой системе.
Именно здесь на сцену выходят SLA, SLO и SLI — три похожих термина, которые часто путают между собой, хотя отвечают на совершенно разные вопросы. С них и стоит продолжить.
Чем отличаются SLA, SLO и SLI и что это вообще такое
SLA: что именно вам обещает провайдер
Когда в договоре фигурируют проценты доступности, почти всегда речь идёт о SLA — Service Level Agreement. Это формальное обещание провайдера, зафиксированное на бумаге, с чётко очерченной зоной ответственности и заранее описанными последствиями в случае нарушений.
Важно сразу убрать лишние ожидания. SLA — это не обещание, что сервис «всегда будет работать» в привычном для бизнеса смысле. Это договор, который регулирует уровень сервиса.
Если говорить проще, SLA прописывает, что именно провайдер берётся держать на нужном уровне и по каким правилам это считается. Причём речь не всегда только про «железо» и метрики: иногда туда попадают и вещи из поддержки — например, как быстро команда реагирует на тикеты и в какие сроки берёт инциденты в работу.
Но когда в договоре вы видите именно проценты (99,9% и подобное), почти всегда речь идёт об availability. То есть о доступности конкретного компонента — виртуальных машин, сети, managed-сервиса — и только в тех границах, которые провайдер считает своей зоной контроля.
Обычно SLA отвечает на довольно узкий набор вопросов. Что именно считается сервисом? Как измеряется недоступность? За какой период она считается? И что произойдёт, если заявленный уровень не будет достигнут? Всё остальное — уже за пределами обязательств.
Здесь и появляется первое расхождение с реальностью. В SLA почти никогда не говорится о пользовательском опыте. Провайдер может гарантировать работу виртуальных машин, сети или управляемого сервиса, но при этом не отвечать за то, как ведёт себя приложение, насколько корректно оно настроено и что происходит с внешними интеграциями.
Отдельная история — исключения. В большинстве договоров заранее перечислено, какие ситуации не считаются нарушением SLA. Плановые работы, ошибки конфигурации со стороны клиента, проблемы во внешних сервисах или действия команды заказчика обычно сразу выносятся за скобки. Формально это логично, но именно в этих зонах и происходит значительная часть реальных простоев.
Даже когда SLA всё-таки нарушен, последствия редко выглядят так, как ожидает бизнес. Вместо компенсации потерь чаще всего предлагаются service credits — скидки на будущие счета. Они могут быть полезны с точки зрения бюджета, но почти никогда не соразмерны упущенной выручке или репутационному ущербу. Лично я считаю, что это, конечно, приятно, но в большей степени бесполезно. Зачем мне скидка, если провайдер нарушает свой же SLA и из-за этого мой бизнес подвергается риску? Каждый даст сам ответы на этот вопрос, ну а мы идём дальше.
SLO и SLI: что на самом деле влияет на пользовательский опыт
Если посмотреть на SLA в отрыве от остальной системы, может сложиться ощущение, что вопрос доступности уже решён: цифры есть, условия прописаны, ответственность формально определена. Но именно здесь возникает разрыв между договором и тем, как сервис ощущается в реальности.
Далеко ходить не будем, возьмём повседневный будний день и наш прошлый пример с шоколадкой. Поговорим всё с самого начала. На ценнике написано «шоколад», продавец подтверждает, что товар есть в наличии, и вы его покупаете. Формально обещание выполнено — шоколадку вам продали. Это и есть аналог SLA: обязательство соблюдено, сделка состоялась.
Но дальше начинается то, что SLA не описывает. Вы разворачиваете покупку и обнаруживаете, что плитка отколота, вес меньше ожидаемого, а вкус сопоставим с пластилином. Магазин может быть абсолютно прав с точки зрения формальных условий, но ваше ожидание как покупателя не совпало с результатом. Здесь как раз и проявляется разница между тем, что «обещано», и тем, как это ощущается на практике.
В мире облаков эту разницу и описывают SLO и SLI.
SLO (Service Level Objective) — это внутренние целевые показатели, которые команда задаёт для сервиса: каким он должен быть “в норме”, чтобы пользователь был доволен.
SLI (Service Level Indicator) — конкретные измеримые метрики, по которым это оценивается в реальности: время ответа, доля успешных запросов, частота ошибок, задержки и другие признаки того, как сервис ведёт себя под нагрузкой.
Важно, что SLO почти всегда строже и приземлённее, чем SLA. Провайдер может гарантировать доступность на уровне инфраструктуры, но пользователь сталкивается не с виртуальными машинами и зонами доступности, а с конкретным сервисом. Если страница открывается медленно, запросы периодически падают или часть функциональности недоступна, формальное соблюдение SLA не спасает ситуацию.
Именно поэтому инженеры работают не с абстрактной «доступностью дата-центра», а с SLI конкретных пользовательских сценариев. Они измеряют не факт того, что сервис «жив», а то, насколько стабильно он выполняет свою задачу. А SLO становятся внутренним ориентиром, который помогает принимать решения: где можно рискнуть, а где нет; что считать деградацией, а что — допустимым отклонением.
Если возвращаться к примеру, SLA отвечает на вопрос «продали ли товар», а SLO и SLI — на вопрос «получил ли покупатель то, за чем пришёл». И для реального пользовательского опыта второй вопрос почти всегда важнее первого.
Где «теряется» доступность между договором и реальной системой
После разговора про SLA, SLO и SLI логично возникает вопрос: если провайдер формально выполняет свои обязательства, а инженеры видят деградации и недовольство пользователей, то где именно возникает этот разрыв? Почему на бумаге всё выглядит стабильно, а в реальности сервис «сыпется»?
Проблема в том, что между договором и конечным пользовательским опытом находится целый слой ответственности.
Даже понимая ограничения SLA, многие ожидают от него большего, чем он способен дать на практике. Договор фиксирует доступность отдельных элементов инфраструктуры, но пользователь сталкивается с результатом работы всей цепочки — от сети и балансировщиков до кода приложения и внешних зависимостей. Именно в этой связке и появляется первый разрыв между формальной доступностью и реальным опытом.
Здесь и появляется первая «потеря». Провайдер может честно выдерживать свои 99,9%, но часть системы, находящаяся уже под контролем заказчика, выходит за рамки SLA. Любая ошибка конфигурации, перегруженный компонент или неучтённая зависимость мгновенно превращает формальную доступность в пользовательскую недоступность.
Вторая зона разрыва — границы ответственности. В облаке они редко очевидны. Провайдер отвечает за инфраструктуру, заказчик — за архитектуру поверх неё. Но на практике многие проблемы возникают именно на стыке: сетевые задержки между сервисами, некорректные тайм-ауты, особенности managed-сервисов, которые работают «как есть» и не покрываются SLA в ожидаемом смысле.
И отдельно стоит сказать про человеческий фактор. Даже самая аккуратно спроектированная система может начать сбоить из-за неудачного деплоя, спешного фикса или решения, принятого в стрессовой ситуации во время инцидента. Такие вещи почти никогда не попадают в договоры и SLA, но именно они чаще всего ощущаются пользователями как «сервис упал».
В итоге доступность не пропадает в одной конкретной точке. Она размывается постепенно — по мере того, как абстрактные цифры из договора сталкиваются с реальной архитектурой, нагрузкой и поведением системы в нестандартных условиях. SLA задаёт нижнюю границу ответственности провайдера, но не отвечает на вопрос, как сервис поведёт себя при пике трафика, частичном отказе или цепочке мелких сбоев.
Отсюда и главный вывод: проблемы с доступностью редко возникают потому, что провайдер кого-то намеренно вводит в заблуждение. Чаще они появляются из-за ожиданий. SLA начинают воспринимать как гарантию пользовательского опыта, хотя по факту он описывает лишь один из уровней всей системы. Всё, что происходит выше этого уровня, остаётся зоной ответственности заказчика — даже если это не всегда очевидно на этапе выбора облака.
Как читать SLA-договоры без юридического образования
Ключевые пункты, на которые стоит смотреть в первую очередь
Если вдруг показалось, что речь выше шла «просто о договоре», стоит сделать небольшую паузу и уточнить: это не тот случай, когда вы ставите галочку под пользовательским соглашением в игре и идёте дальше. SLA — не аналог лицензионного соглашения в Warcraft или любой другой онлайн-игре, которое читают единицы и которое почти ни на что в повседневной игре не влияет.
Здесь ставки другие. SLA — это документ, который определяет, в каких условиях провайдер считает себя выполнившим обязательства, даже если сервис для вас фактически был недоступен. И если его читать так же бегло, как EULA в игре, разочарование почти гарантировано.
Хорошая новость в том, что для базового понимания не нужно юридическое образование. Плохая — ключевые моменты почти никогда не находятся там, где их ожидают увидеть. Поэтому при чтении договора полезно сразу сосредоточиться на нескольких конкретных вещах.
| На что смотреть | Почему это важно |
| Как считается downtime | Часто недоступность считается только при полном отказе сервиса. Медленная работа, ошибки части запросов или деградация функциональности могут вообще не попадать в расчёт. |
| Единица измерения доступности | Процент может считаться для региона, зоны или сервиса в целом. Это не то же самое, что доступность именно вашего приложения. |
| Минимальный период расчёта | Иногда SLA считается за месяц или даже за год. Один крупный инцидент может «раствориться» в общей статистике. |
| Условия получения компенсации | В большинстве случаев компенсация не начисляется автоматически. Её нужно запросить, соблюдая жёсткие сроки и формальные требования. |
| Форма компенсации | Почти всегда это не деньги, а скидка на будущие счета, которая никак не компенсирует простой бизнеса. |
| Исключения и оговорки | Плановые работы, сетевые проблемы, ошибки конфигурации и даже часть managed-сервисов могут быть выведены из зоны ответственности. |
Таблица выше показывает, что именно стоит проверять в SLA в первую очередь, даже если документ выглядит «стандартным».
Чтобы лучше почувствовать импакт и разницу в подходе, полезно сравнить SLA с тем, о чём мы говорили в самом начале— пользовательскими соглашениями в играх. Мы редко читаем их внимательно, потому что заранее понимаем: они написаны не для защиты игрока, а для защиты платформы.
| Пользовательское соглашение в играх | SLA в облаке |
| «Сервис предоставляется как есть» | «Доступность обеспечивается при соблюдении условий» |
| Лаги, вылеты и баги — не гарантийный случай | Частичная деградация и ошибки могут не считаться downtime |
| Потеря прогресса — ответственность игрока | Потери бизнеса не компенсируются напрямую |
| Пользователь принимает условия автоматически | Заказчик формально соглашается, часто не вникая |
В играх мы к этому относимся спокойно. Лаги неприятны, но редко критичны. В облаке же тот же подход начинает выглядеть иначе: простой сервиса, потерянные заказы или недоступность API напрямую отражаются на деньгах и репутации.
Дальше имеет смысл посмотреть на формулировки, которые выглядят нейтрально и привычно, но именно они чаще всего и маскируют реальные риски.
Типовые формулировки, которые маскируют риски
После того как вы посмотрели на ключевые параметры SLA, следующим шагом обычно становится чтение формулировок. И именно здесь чаще всего создаётся ощущение, что «вроде всё нормально». Текст выглядит аккуратным, юридически выверенным и даже обнадёживающим. Проблема в том, что многие из этих формулировок говорят не о том, что будет работать, а о том, в каких случаях провайдер не считает себя ответственным.
Одна из самых распространённых фраз — best effort. В буквальном смысле она означает, что провайдер «приложит разумные усилия» для поддержания сервиса. На практике это не гарантия результата, а обещание попытки. Если что-то пошло не так, сам факт сбоя ещё не означает нарушение обязательств — достаточно показать, что действия предпринимались.
Другая типичная конструкция — широкие исключения из зоны ответственности. Плановые работы, обновления, проблемы у подрядчиков, сетевые инциденты, ошибки конфигурации на стороне клиента — всё это часто вынесено за рамки расчёта доступности. В результате значительная часть реальных инцидентов формально не считается нарушением, даже если пользователи видят сервис недоступным.
Отдельного внимания заслуживает агрегированная доступность. Когда доступность считается не для конкретного сервиса или региона, а «в среднем по платформе», цифры почти всегда выглядят красиво. Один проблемный компонент легко теряется на фоне десятков стабильных. Для бизнеса же важен не средний показатель, а доступность именно того сервиса, который приносит деньги или обслуживает клиентов.
Есть и более тонкие моменты. Например, требования к уведомлениям об инцидентах. В договоре может быть указано, что провайдер обязан уведомить о сбое, но без чётких сроков или каналов. В результате уведомление приходит уже после того, как пользователи начали жаловаться, а команда — тушить пожар вслепую.
Все эти формулировки сами по себе не являются обманом. Они отражают реальную границу ответственности провайдера. Проблема возникает тогда, когда их читают как обещание пользовательского опыта, а не как юридическое описание условий оказания услуги.
Именно поэтому SLA стоит воспринимать не как гарантию бесперебойной работы, а как документ, который фиксирует минимальный уровень обязательств. Всё, что выходит за его рамки — доступность конкретных сценариев, реакция на деградацию, поведение системы под нагрузкой — остаётся задачей архитектуры и процессов на стороне заказчика.
Этот вывод напрямую подводит к следующему шагу: если договор не гарантирует реальную доступность, значит её нужно проектировать поверх облака осознанно, а не ожидать, что цифры в SLA сделают это за вас.
Проектирование доступности поверх облака
После всех разговоров о договорах и формулировках становится понятно одно: реальная доступность не появляется автоматически вместе с облаком. Она не «включается» галочкой и не обеспечивается самим фактом использования managed-сервисов. Это результат архитектурных решений, которые принимаются на стороне заказчика.
Первое, с чего стоит начать, — отказ от мышления «работает / не работает». В реальности большинство инцидентов — это не полный даунтайм, а деградация. Сервис может отвечать медленно, часть функциональности — не работать, отдельные пользователи — сталкиваться с ошибками. Если система спроектирована так, что любое отклонение превращается в сбой, доступность будет хрупкой независимо от облака.
Отсюда вытекает важный принцип: устойчивость строится через избыточность и деградацию, а не через попытку избежать ошибок. Компоненты должны уметь переживать частичные отказы. Если внешний сервис недоступен — система должна корректно ограничивать функциональность, а не падать целиком. Если один из узлов перегружен — трафик должен перераспределяться, а не упираться в узкое место.
Следующий слой — работа с отказоустойчивостью на уровне размещения. Использование нескольких зон доступности или регионов само по себе ещё ничего не гарантирует. Важно, чтобы компоненты действительно были независимы: разные точки отказа, отдельные очереди, отдельные хранилища метаданных. Иначе «мультизональность» превращается в иллюзию, которая рушится при первом серьёзном инциденте.
Отдельного внимания заслуживают процедуры восстановления. Бэкапы и реплики имеют смысл только тогда, когда команда регулярно проверяет, что из них действительно можно восстановиться. Реальная доступность — это не только про «не упасть», но и про «быстро вернуться в рабочее состояние», если сбой всё-таки произошёл. Без отработанных сценариев восстановления даже небольшая ошибка может превратиться в многочасовой простой.
Наконец, доступность всегда связана с деньгами и стратегией. Избыточность стоит ресурсов, резервирование — денег, а быстрые восстановления требуют времени на подготовку. Поэтому архитектурные решения здесь редко бывают универсальными. Где-то оправдано держать горячий резерв, где-то — принимать риск редкого простоя, компенсируя его быстрым восстановлением. Важно, чтобы этот выбор был осознанным, а не случайным следствием чужих ограничений.
Казалось бы, что вот и всё, поговорили о всём и вы теперь более подкованы, но нет. Есть ещё одна важная глава которая обязательна к рассмотрению.
Согласования ожиданий бизнеса и реальную доступность
После технической части обычно всплывает неудобный момент: инженеры могут построить очень устойчивую систему, но бизнес всё равно будет недоволен. И наоборот — бизнес может требовать «максимальную доступность», не понимая, что за этим стоят конкретные деньги, сроки и архитектурные ограничения. Поэтому вопрос здесь не столько про технологии, сколько про согласование ожиданий.
Самая частая ошибка — обсуждать доступность в вакууме. Когда говорят «нам нужно 99,9%», часто не уточняют, что именно должно быть доступно: главная страница, каталог, оплата, личный кабинет, API партнёров, административная панель? Для бизнеса это может быть «весь сервис», для инженеров — набор компонентов с разными профилями рисков. Пока вы не договорились о критичных пользовательских сценариях, цифры мало что значат.
Хороший способ приземлить разговор — перевести доступность на язык потерь и приоритетов. Не в стиле «будет плохо», а максимально конкретно: что происходит, если платёж не проходит 15 минут в прайм-тайм? Сколько заказов теряется? Какие последствия для поддержки? Где начинается репутационный ущерб? Такой разговор быстро показывает, что не все части системы одинаково важны.
Дальше появляется неизбежный компромисс: стоимость против уровня доступности. Высокая устойчивость требует избыточности, резервов и постоянной инженерной дисциплины. Это не «разовая настройка», а режим работы. Поэтому разумнее не гнаться за красивыми цифрами, а выбрать уровень доступности, который бизнес действительно готов оплачивать — и который инженеры реально смогут поддерживать.
В этом месте часто становится видно, почему «честные 99,5%» лучше, чем «99,9% на бумаге». Честные — это когда:
- Определены критичные сценарии и их приоритеты;
- Понятно, какие деградации допустимы, а какие нет;
- Есть план восстановления и реальная практика его выполнения;
- Цифра отражает поведение системы, а не только формальные расчёты.
И самое важное: договорённости по доступности не должны быть вечными. Продукт растёт, нагрузка меняется, появляются новые зависимости. То, что было приемлемо год назад, сегодня может быть недостаточно — и наоборот. Поэтому лучше воспринимать доступность как живую управленческую настройку, к которой регулярно возвращаются, а не как цифру, которую однажды выбрали и всё, можно забить.
В итоге согласование ожиданий — это про то, чтобы бизнес и инженеры одинаково понимали, что именно защищают, чем рискуют и сколько готовы за это платить.
Заключение
Если оглянуться на всё, о чём мы говорили, становится заметно одно: проблемы с доступностью почти никогда не начинаются с цифр. Они начинаются с ожиданий. С того, что одни и те же проценты читаются по-разному — бизнесом, инженерами и провайдером.
История с шоколадкой хорошо это иллюстрирует. Формально товар был продан, обещание выполнено. Но ощущение от покупки оказалось совсем не тем, на которое рассчитывали. В облаке происходит то же самое: договор может быть соблюдён, а сервис при этом воспринимается как нестабильный. И наоборот — система может работать предсказуемо и спокойно, даже если цифры выглядят неидеально.
Пример с играми тоже не случаен. Мы давно привыкли к пользовательским соглашениям, которые защищают платформу, а не игрока. В облаке договоры устроены похожим образом, просто цена ошибки выше. Там, где в игре это оборачивается лагом или вылетом, в бизнесе это превращается в простой, потери и недовольных пользователей.
Реальная доступность складывается из архитектуры, поведения системы под нагрузкой, готовности к сбоям и того, насколько честно внутри команды проговорены приоритеты. Проценты в договоре могут быть отправной точкой, но никогда не должны быть единственным ориентиром.
В итоге вопрос доступности — это не про то, как выбрать «правильный SLA», а про то, чтобы понимать, что именно вы защищаете, где готовы принимать риски и какие последствия для вас действительно критичны. Когда этот контекст ясен, цифры перестают вводить в заблуждение и начинают работать как инструмент, а не как иллюзия надёжности. Пожалуй, это самый надёжный способ не купить «99,9% на бумаге».
Спасибо за внимание!
