Comments 23
Для стандартных вебсервисов вроде Хабра четыре девятки за глаза. Час в год все переживут и даже страдать не будут.
Проблемы начинаются в критичных сервисах. Вроде авторизации у Гугла. Там надо держать пять девяток и думать о шестой. Со всеми вытекающими проблемами.
На что именно уходит время при повышении надежности с 99.99 до 99.999 ?
на "вычесывание" мелких ошибок, приводящих к небольшим сбоям, которые, накапливаясь, влияют на уровень надежности.
У вас есть пять минут даунтайма в год. На все про все, включая ураганы и землетрясения. Вы вообще ничего не можете сделать с сервисом за нормальное время.
Для примера, вы не можете даже релиз выкатить нормально. Релиз надо катить неделями, поддерживая возможность моментально выключить все хосты куда он уже выкачен. Ага, 24/7 надо наблюдать и быть готовым их закрыть при появлении любой проблемы.
Надёжность традиционных АТС составляет пять девяток. Надёжность VoIP обычно 3-4 девятки.
Надёжность скорее не про выкатывание релиза и откатывание его обратно, а про работу этого релиза без сбоев и отказов. Обеспечение такой надёжности обходится дорого, и в случае автора статьи решили его понизить. Поскольку релиз стало пилить гораздо быстрее, раз можно забить на мелочи, то и частота релизов возросла.
На пяти девятках это уже не работает. Код вообще без багов писать нельзя. Это основа всей надежности.
Значит нужны рекавери планы для любого представимого и непредставимого бага. Причем планы простые которые можно задействовать по кнопке или вообще автоматикой. Выключить сервер это лучшее решение. Откат это уже слишком долго.
Откат это уже слишком долго.
Это не так. Откаты бывают разные.
Абсолютное большинство новых релизов выглядит как выкат нового образа docker со stateless микросервисом или stateful микросервисом без изменения схемы БД - такие откатываются тривиальным запуском предыдущей версии образа docker либо автоматически (если новый образ в принципе не стартует или не отдаёт здоровый healthcheck) либо по кнопке если он выглядит рабочим но не работает корректно.
Из оставшихся релизов минимум половина изменяет схему БД обратимым образом (напр. добавляет новые таблицы/колонки), и если использовать для миграции инструменты позволяющие задать SQL-запросы отката и автоматизировать их тестирование, то такие релизы тоже элементарно откатываются (не автоматически, но буквально парой штатных команд - остановить новые инстансы, выполнить откат схемы БД, запустить старую версию - при сильном желании это тоже можно автоматизировать, но заморочиться придётся чуть больше).
И только оставшаяся часть релизов, составляющая незначительный процент, откатывается с большим трудом и медленно (или восстановление БД из бэкапа, или ручное выполнение миграции "обратно" уникальным образом, или срочный релиз новой версии работающей на новой схеме но без бага создавшего проблемы - по сути это даже не откат, но зачастую это самый эффективный способ при условии что проблемный выкат не испортил данные и реальной необходимости восстанавливать их из бэкапа нет).
У вас географически распределенная система. Хорошо если на одном континенте. Количество инстансов трех или четырех значное. Все это обмазано пробами и окнами для гарантии работоспособности при работах на железе.
Простейший откат образа может занимать часы. А вот выключить можно по кнопке.
Откат по сути это выкат - следующей или предыдущей версии это абсолютно не важно и ни на что не влияет (кроме вышеупомянутого незначительного процента случаев когда нужно уникальным образом восстанавливать БД). Соответственно, времени откат занимает ровно столько же, сколько и выкат. Не вижу тут никакой особенности или проблемы, из-за которой вместо выката нужно было бы всё выключать.
Выкатка это целый процесс. С автоматикой, пробами, ограничениями, прогревами и окнами.
Нельзя так просто взять и рестартануть значимую часть кластера с другим бинарем. Сам этот рестарт может вызвать отказ.
При этом выключение значимый частей кластера это нормально. Он должен уметь без них работать. Экскаватор и все такое.
Что значит нельзя? Это штатный процесс выката новой версии, который может происходить хоть несколько раз в день для одного микросервиса. На практике, конечно, это будет скорее один-два раза в неделю, но всё-равно - это только один из микросервисов. А их бывают тьмы и тьмы. И даже если у вас монолит, и он один, всё-равно один-два раза в неделю он должен выкатываться. Потому что если выкатывать раз в месяц или больше - то всё плохо, выкат обязательно превратят в "целый процесс", и частью этого процесса будут регулярные проблемы.
Кто и кому должен? Сервисы с надежностью пять девяток точно никому ничего не должны. И они катаются реже раза в месяц. Выкатка занимающая недели или даже месяц это норма для таких сервисов.
Да. Это целый процесс для надежных сервисов. Быстро катать фичи в них не надо. А вот регламент на любой чих надо написать и потом ему следовать. Без регламента там вообще ничего делать нельзя.
Про это как раз в статье пишут. Очень высокая надежность и скорость разработки противоречат друг-другу. Обеспечить и то и другое не выйдет.
Это типичная точка зрения админов, которые не видят что изменилось между версиями, и, соответственно, для них каждая новая версия это чёрный ящик и потенциальная опасность что всё сломается, причём опасность эта имеет для них одинаковую вероятность для любой версии.
Для разработчиков ситуация выглядит иначе: во-первых они видят что изменилось и могут адекватно оценивать вероятность что-то поломать для каждой версии отдельно, и во-вторых для них вероятность что-то поломать растет экспоненциально по мере увеличения времени между релизами (по ряду причин - от недостаточного тестирования до неожиданных результатов взаимодействия вроде бы не сильно связанных между собой изменений), но самое важное - когда релизится каждое мелкое изменение (отсюда и цифра про три релиза в день - по моему опыту вполне реальная, кстати), то становится на порядок проще понять какое именно изменение что-то сломало и как это чинить (что сильно уменьшает вероятность сделать некорректный фикс и снова положить прод из-за этой же проблемы).
Поэтому частые релизы, с точки зрения разработчиков, как раз способствуют увеличению надёжности выкатов, а вовсе не скорости разработки фич. Потому что эти релизы по большей части содержат не новые фичи, а внутренние изменения/рефакторинг/обновления зависимостей/мелкие багфиксы/оптимизации/etc.
Про это как раз в статье пишут. Очень высокая надежность и скорость разработки противоречат друг-другу.
На мой взгляд, в статье говорится совсем другое. Там речь про то, чтобы контролировать SLO путём заморозки релизов до конца текущего периода если значительная часть бюджета текущего периода была потрачена. Это ничего не говорит о том, с какой частотой рекомендуется делать релизы до наступления такого момента. И речь о фичах в этом контексте идёт только потому, что подразумевается, что новые релизы требует именно бизнес, соответственно его нужно уговаривать отложить эти релизы, а на желание разработчиков продолжать часто релизить мелкие изменения можно тупо забить потому что не они тут решения принимают - что не совсем корректно по сути, но в целом понятно.
На самом деле оптимальная стратегия сильно зависит от конкретного проекта, квалификации команд (причём всех отдельно - и разработчиков и админов и тестировщиков), и доступного бюджета (не ошибок, а финансов - напр. на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода). Универсального ответа подходящего всем - нет, даже если цель одинаковая и соответствует описанной в статье.
О какой надежности можно говорить без хотя бы двух географически разнесенных площадок вообще? Причем любая их них должна вытягивать всю нагрузку без каких-либо проблем.
Вы все еще говорите о типичном софте где фичи важнее надежности. Это нормальные сервисы, но они не про надежность. В них катаем релизы, все хорошо.
Надежность это не про постоянные релизы и доверие разработчикам. Пусть даже самым умным и хорошим. Надежность это про регламенты и инструкции. От человека должно быть минимум зависимостей. Люди меняются, не высыпаются, торопятся и вообще всякое бывает.
Поэтому никому не верим, а просто следуем инструкциям. Медленные релизы и медленная разработка получаются как следствие. Инструкции и следование им требует времени. Пункт "подождать неделю" вполне нормальный. Пункт "катим одну фичу за раз" тоже нормальный. Так можно избежать вала изменений. Да, скорость разработки будет одна фича в месяц. И что?
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему? Сколько бы ни было площадок и как бы они ни были разнесены географически - это никак не мешает выкатывать в них по нескольку релизов в день.
Что до инструкций - то это нормальный подход, никто не спорит. Просто он во-первых не единственный адекватный, и во-вторых он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма. И это только креши, что вообще-то мелочь. Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД. И нередко такие баги связаны со сложной логикой или гонками (race condition), которые бывает крайне сложно поймать любыми тестами даже если точно знаешь что баг есть.
В общем, как редко не выкатывай и как не держись за "старое, проверенное временем" - надёжность 100% всё-равно не получишь. Поэтому, как я уже говорил, тут нет единственно верного ответа, нужен специфичный для конкретного бизнеса/проекта/команды баланс. И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему?
на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода)
Вот к этому. У надежных систем точно есть двухкратная избыточность как минимум. Скорее трехкратная. Чтобы экскаватор который внезапно отключил весь ЦОД никак не повлиял на продакшен. Пожар туда же.
А направить 1 процент прод трафика на любой стенд это вообще не проблема.
И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
А вы много знаете сервисов которые реально работают на пять девяток? Это довольно редкие звери вообще.
Я видел. Но именно что видел из чужих рук. Работать в таком я не хочу.
он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма.
Отлично значит катим два месяца. Куда спешить? Хотя мне кажется это уже перебор. Неделя-две работы дают достаточную гарантию что с сервисом все ок.
Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД
Такое вообще в прод попадать не должно. Даже у обычных сервисов без особой надежности. В надежных сервисах о таких багах и речи не идет. Они чистятся задолго до продакшена.
А направить 1 процент прод трафика на любой стенд это вообще не проблема.
Ну так и я ровно о том же (и география на этот факт особо не влияет). Полноценное зеркало прода в реальности встречается только в мелких проектах, но там это просто игрушка по сути. А в крупных никакого бюджета на это не хватит (точнее он никогда не окупится, поэтому его и выделять не станут). А без этого никакое тестирование до выката в прод не проявит некоторые типы ошибок, которые видны только под большой нагрузкой/на больших данных. Иными словами как не старайся этого избежать, сколько ни откладывай релиз, но тестирование в проде на реальных пользователях всё-равно неизбежно.
Такое вообще в прод попадать не должно.
Не должно. Но и люди и ИИ пишут код с ошибками, они же тестируют его довольно ограничено в меру собственных способностей и бюджета, поэтому кода без багов не бывает. Так что, должно или нет, но оно уже там. В мире есть не так и мало крупных сервисов с кучей девяток - но глючат и временами лежат абсолютно все.
Всё это очень верно и здраво - пока цифры SLO адекватные (и соблюдаются, разумеется). Потому что очень легко нарисовать такой же график, только улетающий в небо на 95% и сказать "у нас лапки, всё что выше - это $$$$$$". Я к тому, что при этом подходе есть возможность замаскировать успокаивающими цифрами реальные проблемы.
За 6 девяток вас наградят посмертно. Раньше просто не узнают об этом
Хорошая статья +
Известный принцип Паретто: за 80% чего-либо, Вы тратите 20% ресурса.
На оставшиеся 20% потратите 80% ресурса.
Причем есть удивительное свойство, типа фрактала, если оставшиеся 20% начнете оценивать, то фокус повторится.
Спасибо за статью, информативно, наглядно и без воды
Получив чётко определённый запас на ошибки, команда... стала смелее, что ли.
Одним словом: страх. А это -- психология.
выйдем на 100% аптайма!
Чем это обернулось? Релизы встали. За квартал мы почти ничего нового не выпустили – каждый боялся быть тем, кто “уронит продакшн” обновлением.
Как хорошо, что еще один человек понял, то что доносит SRE Workbook.
100% аптайм - это 100% надежность. А что это значит на бытовом уровне? То что вы ожидаете , что ваш сервис успешно будет работать после взрыва солнца и схлопывания его в чёрную дыру.
Есть отличный проект https://map.r9y.dev/beck/map.html - карата, которая показывает сколько всего вам нужно, чтобы держать выбранное количество девяток. А как мы знаем переход на следующую девятку, это затраты на порядок больше на поддержание такого сервиса в работе. Нужно ловить баланс. Ручей можно и на дырявой лодке переплыть, если даже после выхода на берег она утонула - для такой цели ее надежности хватило.
Если у вас появились еще вопросы про SLO и вам интересно узнать, как это работает у других - приглашаем в сообщество ALLSLO https://t.me/allslo_ru
Как я перестал гнаться за 100% аптаймом