Простой или не простой, вот в чём вопрос… Звучит философски, но в жизни сисадмина философии мало — куда важнее чёткие показатели. Например, сколько минут (или секунд) сервис может быть недоступен, прежде чем начнутся убытки и паника. Ответ на этот вопрос обычно можно найти в 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).

Даже 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 ООО «МТ ФИНАНС»