- Кратко про SLA и Uptime
- Важность для клиента и поставщика
- Когда хорошо — это тоже плохо
- SLA для обычных людей
Все встречали в своей жизни такую штуку как SLA (Service level agreement). Необязательно даже знать, что это такое — оно везде.
Если вкратце, то это набор каких-то условий, которые кто-то обязуется исполнять, согласованный с клиентом. Неважно кто должен их исполнять — почтовый сервер, интернет провайдер или магазин с пивом. Условия эти зависят от области, но есть и такие, которые более популярны.
Условие, которое встречается чаще остальных — значение показателя Uptime. Uptime — это процент времени, который какая-то штука работает.
Пример:
Магазин работает с 8 утра по 8 вечера 7 дней в неделю круглый год. Получается 12 часов в день. Всего часов 24. Выходит, что uptime этого конкретного магазина 50%.
Плохо это или нет?
А кто его знает, зависит от клиентов этого магазина и его владельцев. Все ок пока все довольны, главное чтобы ожидания совпадали с реальностью.
Иногда 50% uptime это объективно мало. Представьте, что это uptime почты Gmail. По сути это означает, что в половине случаев почта не работает — так себе идея.
Возьмем показатель 99% — вроде отлично. Да, есть вероятность 1%, что сервис не работает, но не страшно, можно и страницу перезагрузить.
Все вроде логично, но по факту 99% uptime означает, что сервис может не работать 3 дня 15 часов и 39 с половиной минут (кто не верит, можно посчитать сколько это один процент от года или поиграться с числами на https://uptime.is). То есть, если Gmail нормально работал целый год, то в последние три дня разработчики могут выключать все сервисы и ехать отмечать новый год, KPI выполнен.
То же самое и с магазином: сегодня он решил, что он круглосуточный, а завтра не работает вообще. 50% uptime же.
Чтобы предотвратить такие ситуации, uptime никогда не используют в отрыве от других показателей, а особенно — как замена понятия SLA (точней используют, и очень часто, но это неправильно)
Что обычно стоит рядом с uptime?
Да все что угодно, если это позволит лучше понять, как должна работать система и обезопасить как клиента, так и поставщика услуг.
С клиентом, кажется, все понятно. Допустим, у меня есть контракт с интернет-провайдером и он гарантирует мне какой-то уровень надежности. Не получается — возвращает деньги.
С поставщиком услуг все интересней.
Помечтаем немного и представим, что я владелец платежной системы Мастеркард. Интернет магазины, банки, и много кто еще используют Мастеркард в своем бизнесе — ошибки очень критичны. Если завтра у меня все сломается, эти люди потеряют кучу денег и пойдут в суд, все описано в контракте.
Как себя обезопасить? Можно заложить какое-то количество ошибок на будущее. Сказать, что Мастеркард гарантирует работу только в 80% случаев. Но это звучит как какой-то сюрреализм — из 100 переводов в среднем 20 не дойдут до получателя, никто не будет пользоваться такой платежной системой. Поэтому обычно никто чрезмерно не перестраховывается и все пишут значение близкое к реальности.
Хорошо, допустим мы гарантируем 99.999% uptime — не более 5 минут простоя в год.
— Получается, что если Мастеркард по какой-то причине упал и не работал больше, чем 5 минут в год, то все плохо?
— Да, потому что мы нарушили свои обязательства.
— Получается, что если все было замечательно и система работала без ошибок весь год, то все хорошо?
— А вот тут нет, и это не так очевидно на первый взгляд. Но об этом ниже
Расскажу вам главную тайну SLA — на него никто не смотрит, пока все хорошо.
Не бывает такого, чтобы менеджер пришел к программисту и сказал: “Вот чуваки из соседнего отдела написали сервис, который делает, что нам нужно, используй”, а программист бы в ответ спросил “А что у них там с SLA?”.
Точнее бывает, но это означает только то, что как минимум один раз до этого похожий сервис у этих ребят уже не выдержал нагрузки. Тогда программист и про мониторинги спросит, и про бэкапы, и про все на свете.
По умолчанию понимание такое: если что-то работает, оно работает всегда.
А теперь представьте такую ситуацию.
Программист знает, что если выполнить команду X, то деньги со счета Васи переведутся на счет Абрама. Что еще нужно, чтобы написать интернет магазин?
Он решает попробовать. Пробует — и все работает.
Чудеса.
Пробует второй раз — тоже отлично, Абрам стал в два раза богаче. Пока только теоретически, мы ведь еще тестируем.
Запускает эту команду тысячу раз — тысяча переводов. Выглядит превосходно.
Приходит время выпускать первую версию магазина на реальных клиентов. Релиз — и опять все работает. Программист молодец, Мастеркард молодец, все молодцы.
И так проходит полгода. За это время магазин превратился в лидера индустрии, программист сделал еще пару проектов и думать забыл про этот кусок кода. И тут бац — Мастеркард падает. Ненадолго, на минуту-две, но этого хватает, чтобы деньги эти две минуты никуда не переводились, а товары все еще продолжали отгружаться, ведь программист забыл добавить проверку на ошибки.
Программист в панике, звонит в Мастеркард, а они ему:
— 99.999% Uptime, пошел к черту.
— Но ведь раньше же работало без перебоев!
— Оцените качество работы службы поддержки по шкале от 1 (неудовлетворительно) до 5 (отлично)
Кто виноват? Очевидно что программист — если ты работаешь с деньгами, нужно быть максимально осторожным. А с другой стороны, оно же всегда работало!
Но все могло бы пойти иначе, если бы на этапе тестирования программист бы увидел какие-нибудь ошибки. Запустил перевод денег 1000 раз, получил 5 ошибок — что-то не так. Может им написать? А не, у них заявленный uptime не 100%, добавлю обработку ошибок на всякий случай. Или бы ошибка проявила себя намного раньше, пока и время на багфиксы заложено, и разработчик еще не все забыл.
Поэтому, если ваша система работает без сбоев целый год, будьте уверены, что есть куча клиентов, которые свято верят в то, что она будет так работать вечно и знать не знают, какие у вас планы на этот счет.
А зачем это все обычному человеку? А затем.
Вы каждый день (иногда за исключением воскресенья) ходите на работу, что-то делаете, общаетесь с людьми.
Вспоминаем вот эту картинку:
Экстраполируем на весь остальной мир и понимаем, что все вокруг ожидают что в будущем вы тоже будете:
- ходить на работу
- что-то делать
- общаться с людьми
и скорее всего примерно так же, как и сейчас. Если будут какие-то изменения, то всем будет лучше, если они будут минимальные и совсем незаметные.
Каждый день мы помогаем окружающему миру сформировать представление о том, что мы будем делать в будущем. Лучше, если это будет хоть как-то похоже на наши реальные планы.
Пример:
Программист работает без отпуска два года, не покладая. Его задолбавшаяся жена дарит ему на день рождения горящую путевку в Антарктиду на двоих. Он пишет заявление на отпуск.
Ожидание: все хвалят его за тяжелые два года, желают хорошо отдохнуть.
Реальность: все бегают по кругу в панике, никто не понимает как дальше жить и кто будет закрывать проект.
Еще пример:
Другой программист работает парт-тайм 20 часов в неделю. Работа у него одна, да еще и интересная, поэтому он эти часы не считает совсем: где-то вышло 25, где-то 35. Внезапно он понимает, что он уже большой мальчик, может работать и 40 часов и переводится на фулл-таймОжидание: он будет делать в 2 раза больше работы
Реальность: он делает столько же, сколько и раньше. Поскольку он очень ответственный, он это понимает, грустит и увольняется. В итоге он счастлив, потому что не успел взять ипотеку.
Резюмируя всё:
Все проблемы можно поделить на две категории:
- Несоответствие чьим-то ожиданиям
- Что-то еще
Как сказал один мудрец: “ваши ожидания — это ваши проблемы”.
На самом деле это не совсем так — можно и нужно влиять на то, что другие люди ожидают от нас. Ходите в отпуск, болейте гриппом и отключайте питание в дата-центрах время от времени