SLI, SLA, SLO — в чем разница?

Разница в третьей букве — конец. Штука :) Но шутка эта здесь не ради вайба (хотя и ради этого тоже), а ради того, чтобы сразу сделать акцент: объяснение разницы будет предметным.

Потому что простое толкование без конкретных (ну или хотя бы абстрактных) примеров из жизни даст читателю, не знакомому с терминами, понимание сабжа именно что на уровне «третьей буквы». А метрики важные, метрики нужные. Для многих бизнесов — фундаментальные. Посему рассказываем про разницу SLI, SLA и SLO на пальцах. Но сначала база.

Пока вы аху изумляетесь с того, что кто-то путает SLI, SLA и SLO — кто-то путает SLA и NDA

Что такое SLI

С этой метрикой, всего скорее, из личного опыта знакома большая часть наших читателей. Менеджеры уж точно, ведь в любая уважающая себя партнерка SLI использует для оценки скорости ответа менеджера. Никто же не хочет ждать «срочно нужной» инфы по 2–3 дня? Вот компании это понимают и внедряют метрику скорости ответа, называя ее SLI. У клиентского сервиса DatsTeam, например, время реакции на первое обращение не более 15 секунд. Однако это не SLI, а SLO — о нем позже.

SLI же — это фактическая метрика работоспособности системы (Service Level Indicator). Любой системы — хоть состоящей из людей (команда партнерки), хоть состоящей из проводов и железяк (серверы партнерки), хоть смешанной (партнерка). И в отличие от распространенного в сфере заблуждения, якобы SLI — скорость ответа, на самом деле SLI — это измеряемые метрики качества работы системы. То есть «не более 1 сбоя в месяц» — это тоже SLI. И еще SLI — это всегда про реальное положение дел.

Что такое SLA

А вот про нереальное — это SLA и SLO. Точнее, про условно нереальное. В особенности если речь про SLA. Ведь если SLI и SLA будут сильно отличаться, это подорвет траст к системе, и ей попросту перестанут пользоваться. И неважно, о чем речь — о партнерке или сервере CS:GO. Почему SLI и SLA не должны сильно отличаться? Потому что SLA (Service Level Agreement) — это обещание. Это то, какое качество работы системы «поставщик» обещает клиенту.

Безусловно, «поставщики» и клиенты не лучшая формулировка для мира партнерского партнерства. Но зато суть ясна. Если вы обещаете, что менеджер ответит в течение часа, а он отвечает через неделю, и это носит системный характер — значит, с вашим SLA что-то не так. Значит, нужно перестать пиздеть привести SLA-обещание в соответствие со SLI-реальностью. Впрочем, это работает лишь тогда, когда разница не в пользу клиента. Если SLA 1 час, а SLI 5 минут — все ок (но все ситуативно).

Что такое SLO

А вот SLO — это те самые внутренние 15 секунд на первую реакцию. Ну или не 15, если речь про другую компанию. Или не секунд, если мы измеряем не скорость ответа менеджера. Ключевое здесь — внутренние. А точнее, целевые. Но целевые уж слишком отдают постановкой задач, KPI и отетим всем. Поэтому во избежание путаницы скажем «внутренние». Ну или желаемые — так ближе по смыслу. И с учетом этого 15 секунд уже не кажутся чем-то нереальным — это кажется базой.

Проще говоря, SLO (Service Level Objective) — это то, что компания требует от своих сотрудников. И если по уму, это всегда делается для обеспечения соответствия SLA и SLI. И здесь тоже речь может идти о чем угодно: как о скорости ответа менеджера (если речь про партнерку), так и, например, о бесперебойном аптайме (если речь про сервер). И да, SLO практически всегда выглядит как что-то на грани адекватности. Почему? Да потому что только так оно и работает.

В чем различие между SLI, SLA и SLO простыми словами

Весь смысл SLO в том, чтобы быть «жестче» SLA. Который, как мы помним, должен быть «проще» SLO. Проще говоря, если мы обещаем (SLA) скорость ответа 15 минут, то от сотрудников (SLO) мы требуем ответа в течение 5 минут. И тогда есть шанс, что реальный ответ (SLI) будет где-то в районе 10 минут. Что с учетом обещания ответа в течение 15 приемлемо. Почему бы просто не нанять «ответственных» людей и не морочить голову 3 разными метриками?

Потому что речь не про «ответственность», а про реальность — в жизни, в отличие от абстрактных моделей бизнеса, существует бесконечное количество переменных («Зачем мне математика?», привет! :D) и учесть каждую из них попросту нереально. Куда проще заранее заложить «запас прочности» и не париться. Дает ли это 100% гарантию? Конечно же нет — форс-мажоры неизбежны. Но если 99,9% времени SLI не противоречит SLA — значит, SLO подобран правильно.

Саммари

SLI, SLA и SLO — это три точки зрения на одно и то же. И каждая из этих точек зрения важна и нужна. Но самое главное — это не только скорость ответа. Это что угодно, что можно измерить, и что так или иначе иллюстрирует работоспособность системы. И тут вжух — SLI превращается из скорости ответа менеджера в штуку, которой можно «измерять» эффективность, собственно, жизни. Главное — правильно подобрать SLA и SLO, а как это делать, вы уже знаете.