Простой или не простой, вот в чём вопрос… Звучит философски, но в жизни сисадмина философии мало — куда важнее чёткие показатели. Например, сколько минут (или секунд) сервис может быть недоступен, прежде чем начнутся убытки и паника. Ответ на этот вопрос обычно можно найти в SLA, в котором все хотят увидеть побольше заветных «девяток» аптайма. Но что именно стоит «99,99%», откуда вообще берутся эти «девятки» и зачем SLA нужно ИТ-отделу? Давайте разбираться.
Что такое SLA
SLA — это соглашение об уровне сервиса, формальный договор между поставщиком услуги и её потребителем о том, какого качества сервис обязуется предоставлять поставщик. Проще говоря, SLA — это как гарантийный талон на ИТ-услугу, в котором описываются:
параметры работы сервиса (например, доступность, время отклика, время восстановления),
методы их контроля,
обязанности сторон,
и, главное, целевые показатели качества, которые обещает обеспечить поставщик.
На этом этапе важно понять, кто кому и что обещает по SLA. Чаще всего SLA заключается между провайдером и клиентом. Например, хостинг-провайдер обещает клиенту не менее 99,9% аптайма сервера или регламентирует время реакции поддержки на инциденты. Но SLA применяется и внутри организаций — зачем, расскажу дальше.
В целом, соглашение нужно для того, чтобы устранить разрыв между ожиданиями и реальностью. Пользователи хотят, чтобы сервис просто работал, а инженеры — чтобы их труд оценивали с пониманием ограничений. SLA переводит размытые ожидания в конкретные договорённости, делая уровень сервиса прозрачным и управляемым.
Когда параметры обслуживания формализованы, легче отслеживать отклонения, планировать улучшения и в целом выстраивать доверие.
Откуда берутся «девятки»
Основной параметр, фигурирующий в SLA инфраструктурных сервисов, — это доступность, она же время бесперебойной работы (аптайм). Доступность обычно выражается в процентах от времени за определённый период (месяц или год).
Например, 99% означает, что сервис работал 99% времени, а оставшийся 1% времени был недоступен (даунтайм). Высокие проценты удобнее для восприятия, чем прямое указание простоя в часах, поэтому отрасль обрела свой жаргон.
Так вот, «девятками» называют количество цифр «9» в числе процентов: 90% аптайма именуют «одна девятка», 99% — «две девятки», 99.9% — «три девятки» и т. д. Каждая добавленная девятка означает, что допускается в десять раз меньше времени простоя.
Разница между доступностью 99,9% и 99,99% — это почти 7 часов дополнительного простоя в год. Неудивительно, что для критичных систем требования выражаются в пяти «девятках» и выше.
Как правило, значения SLA устанавливают или на основе возможностей инфраструктуры, или по договорённости сторон, исходя из допустимых рисков.
Например, телеком-операторы исторически стремятся к пяти «девяткам» (99,999% аптайма) в своих сетях. А для внутренних корпоративных сервисов, если простои не слишком критичны, зачастую достаточно и двух «девяток» (99%). За всеми этими процентами стоит расчёт допустимого простоя.
Сколько стоит каждая «девятка»
Каждая дополнительная «девятка» в SLA серьёзно снижает допустимое время простоя. Ниже приведены ориентировочные значения допустимого даунтайма для разных уровней доступности (в расчёте на месяц и на год, при условии 30-дневного месяца и непрерывной работы сервиса 24/7).
Доступность (SLA) | Простой в месяц | Простой в год |
99% | ~ 7 ч. 18 мин. | ~ 86 ч. 16 мин. (≈3.6 сут) |
99.9% | ~ 43 мин. 50 с. | ~8 ч. 46 мин. |
99.95% | ~ 21 мин. 55 с. | ~ 4 ч. 23 мин. |
99.99% | ~ 4 мин. 23 с. | ~ 52 мин. 36 с. |
99,999% | ~ 26 с. | ~ 5 мин. 16 с. |
Даже 90% доступности означают ~72 ч простоя в месяц (почти 3 дня) или ~876 ч в год (36.5 суток). То есть «всего лишь» одна девятка на деле равна почти целому месяцу простоя.
Каждый шаг от 99% к 99,9% и так до 99,999% сокращает допустимые «перерывы» работы сервиса или сервера. На основе этого то, что измерялось часами, превращается в минуты или секунды. И, как вы можете понимать, цена каждой девятки высока.
Более того, технически обеспечить такие показатели также значительно сложнее. Например, 99,95% доступности обычно требует как минимум кластер из двух узлов (active-passive), чтобы один мог подхватить работу при сбое второго. А чтобы достичь уровня 99,99% и выше, систему придётся распределить по нескольким дата-центрам — иначе говоря, построить архитектуру без единичной точки отказа.
Если переводить всё на деньги — каждая следующая честная девятка добавляет нолик к стоимости системы, потому что сокращает потери. Допустим, интернет-магазин зарабатывает 50 млн рублей в год. При равномерных продажах это ~5700 руб. в час (в году 8 760 часов). Если его система работает с доступностью 99% (до ~87 часов простоя в год), потенциально теряется около 500 тыс. руб. выручки на простоях. А при 99,99% (до ~52 минут простоя в год) потери сократятся до 5 тыс. рублей.
Однако SLA не гарантия надёжности
«Девятки», к сожалению, не равны реальной безотказности системы. Во-первых, цифры относятся к оговорённой зоне ответственности. Если в соглашении сказано про 99,9% доступности дата-центра, это значит, что провайдер гарантирует бесперебойную работу своей инфраструктуры (электричества, охлаждения, сети) на 99,9% времени. Но если ваш сервер упал из-за бага приложения или «кривого» обновления — это не считается нарушением SLA.
Во-вторых, SLA оговаривает компенсации, а не спасает от простоев. Если провайдер не выполнил условия (аптайм оказался ниже обещанного), вы получите возмещение — обычно в виде кредитов или скидки. Но бизнес-ущерб от простоя этими кредитами не компенсировать полностью.
В-третьих, дьявол кроется в деталях соглашения. Нужно понимать, что именно покрывает SLA, и какие есть исключения. Например, часто в контракте оговаривается, что плановое обслуживание (maintenance) не считается недоступностью. Провайдер может выполнять регламентные работы раз в месяц на протяжении часа — и эти часы не войдут в расчёт простоя по SLA.
В итоге на бумаге выходит 99,99%, а фактически сервис ежемесячно имеет час даунтайма на профилактику плюс, возможно, внеплановые сбои. Также важно уточнять период расчёта: 99,9% в месяц — это гораздо мягче, чем 99,9% в год.
Наконец, не все одинаково честны. Дешёвый хостинг с формальными 99,99% может оказаться менее надёжным, чем добросовестный провайдер, честно дающий 99,95%.
На основе описанного, SLA лучше воспринимать как базовый показатель или часть стратегии, но не стоит забывать о резервных копиях, мониторинге, тестировании отказоустойчивости и прочих практических мерах.
Зачем тогда оно нужно
SLA нужно не только провайдерам. Даже ИТ-отделу стоит считать и отслеживать уровень доступности своих сервисов. Итак, внутренний SLA:
Дисциплинирует. Когда вы измеряете аптайм, появляются конкретные цифры, которые можно улучшать. Команда видит: «В прошлом квартале у нас было 99,3% времени без сбоев, давайте постараемся довести до 99,5%». Появляется здоровый ориентир на надёжность.
Повышает прозрачность для соседних команд и руководства. Если ваш отдел поддерживает, скажем, внутреннюю CRM для отдела продаж, договорённость «мы обеспечиваем 99.5% доступности в рабочее время и восстановление за 1 час в случае сбоя» сразу снимает многие вопросы.
Помогает в ретроспективе инцидентов. Благодаря SLA можно точно фиксировать инциденты, минуты простоя, их причины и принятые меры. Эти данные ценны для планирования улучшений и для отчёта перед начальством.
Аптайм для SLA посчитать просто. В целом, это отношение времени бесперебойной работы к общему времени за период, в процентах. Например, за месяц сервис был недоступен суммарно 2 часа, значит, доступность:
(720 ч – 2 ч) / 720 ч × 100% ≈ 99.72%
Обычно внутри команды неформально договариваются, что считать инцидентом и как засекать время простоя (мониторинг вам в помощь). Также важно определить совокупную доступность системы, если она состоит из нескольких компонентов.
Например, ваше веб-приложение зависит от базы данных и API стороннего сервиса. Если у приложения 99.5% аптайма, у базы 99.9%, а у внешнего API — 99%, то общая надёжность будет ограничена самым слабым звеном: примерно 99% (может быть даже чуть меньше, если простои накладываются).
Кстати, зачастую внутренние метрики надёжности называют SLO — цель по уровню сервиса, на которую ориентируется команда. Это по сути то же самое, что и SLA, только без юридического веса. Вы можете оперировать тем термином, который больше нравится.
Инструмент, а не бюрократия
SLA часто воспринимают как нечто формальное, бюрократическую обязанность или маркетинговую уловку. Но, в сущности, правильно выстроенное SLA может стать очень полезным инструментом управления качеством ИТ-сервисов. Оно устанавливает прозрачные ожидания и стимулирует постоянное повышение надёжности.
Конечно, бумага «стерпит всё», и можно подписать соглашение хоть на 200% аптайма. Однако ценность SLA кроется не в самом факте наличия или крутизне цифр, а в том, что за ними стоит реальная работа.
Простой или не простой, вот в чём вопрос… А у вас в ИТ-отделе есть SLA или SLO?
© 2025 ООО «МТ ФИНАНС»
