Continuous Architecture in Practice — выпуск 4

Разговор открывается вопросом, зачем авторы вообще делают ставку на устойчивость. По их логике потребность сместилась: доступность теперь понимают как сохранение хотя бы минимального набора функций при любой проблеме, а моду на такое «всегда доступно» задали Amazon, Google и им подобные. Один из ведущих замечает, что сам попадал и на неработающий Google, и на неработающий Amazon, и вспоминает доклад команды государственного портала услуг: банки и крупные сервисы подняли ожидания так, что тот же уровень надёжности люди теперь ждут вообще от всего, и портал целился ровно в эту ставшую нормой планку — четырёхсотые и пятисотые ошибки раньше видели постоянно, а теперь редко. Тут же звучит анонс: в начале следующего года снова будет айтишный каток, официальные объявления впереди, и, по обещанию ведущих, он выйдет лучше прошлогоднего.

Глава, как и остальные в книге, начинается с определений — их сразу пять, среди них fault и failure, high availability и resilience. Участники сходятся, что запоминать их лучше по-английски: в переводе «сбой» и «отказ» расплываются, а различие принципиально — устойчивую систему строят так, чтобы fault не превращался в failure. Отсюда заход про переводы в лоб, после которых терминология перестаёт быть консистентной. Женя рассказывает, как при переводе книг по DDD сводили большую таблицу: как термин перевели у Эванса, как у Вернона, как переводим мы и как вообще говорим между собой; словарик хотят выложить публично, в нём, по его прикидке, под семьдесят или восемьдесят основных терминов. Надёжность авторы определяют как вероятность работы без отказов в течение заданного периода в заданной среде: она строится поверх доступности, система может быть доступной, но ненадёжной.

Главный спор выпуска — о том, как авторы делят high availability и resilience. В первую корзину попадают внешние средства: виртуализация, восстановление, переключение в соседний дата-центр, когда в приложении менять ничего не надо; во вторую — то, что инженер закладывает в коде. Сергей Баранов считает, что здесь смешаны сам подход и техники его реализации, причём техники приводятся актуальные лет десять-пятнадцать назад, а не сегодняшние cloud native; ему кажется, что high availability — скорее баззворд, вокруг которого потом наросли практики, и такого разделения он в индустрии не встречал. Хуже того, в первой части главы подходы буквально противопоставлены — либо одно, либо другое, — и только дальше упоминаются гибриды, хотя в жизни они всегда работали в связке. Женя добавляет знакомую парадигму: «Зачем мне думать про resilience, если у меня супернадёжная база данных» — так рассуждали лет десять назад, когда не было ни микросервисов, ни облаков, зато можно было дойти до админов и попросить супермашину.

Александр переводит спор на уровень приложения: считаешь ли ты кубики под собой волшебно надёжными или встраиваешь тайм-ауты и другие паттерны отказоустойчивости, перемножая вероятности по шардам. Он советует документ облачного провайдера про проектирование поверх высокодоступной инфраструктуры: как устроены зоны и регионы, чем зональный сервис отличается от регионального и глобального и что такое статическая стабильность — во время сбоя лучше не ходить в control plane, а переживать отказ зоны на уже выделенных ресурсах data plane. Рядом он вспоминает работу двух авторов из Google, engineering fellow и вице-президента по облачной инфраструктуре, про архетипы облачного развёртывания: там разобран и вариант с целиком развёрнутым legacy-софтом и горячим резервом в соседней зоне — ровно картинка high availability из книги. Вопрос к ней — цена в облаке, но у заказчиков речь про непрерывность бизнеса, где мультизона почти по умолчанию, а мультирегиональный фолбэк добавляет ненулевой RPO.

Дальше авторы раскладывают надёжность на четыре группы вопросов: что делать при сбое, куда смотреть, что вообще произошло — это постмортемы, где разбирать советуют и удачные случаи, ведь успех, замечают участники, это фолты, которые не стали фейлами, — и чего мы от системы ждём вплоть до предсказания проблем. Один из участников шутит, что вместо этой четвёрки годились бы два вечных вопроса русской литературы, и ему отвечают, что «кто виноват» спрашивать как раз не надо: вопрос учит заметать проблемы под ковёр вместо «в каком сервисе что произошло». Достаётся и девяткам: бизнес просит пять девяток, не понимая, что это значит, разница между соседними иногда несущественна, а сезонность вроде праздников и распродаж в концепцию не заложена. MTBF, напоминают участники, пришёл из статистики отказов микросхем, где железо стабильно, а софт меняется каждый день, поэтому на практике ориентируются на MTTR, стремящийся к нулю; на просьбу привести пример Александр вспоминает статью про Aurora, где MTBF посчитать не берутся и опираются на сегменты по 10 ГиБ, которые сеть позволяет поднять меньше чем за секунду.

Каталог тактик проходят быстро: health-чеки, где сложнее всего разобраться в пробах Kubernetes, из которых называют startup-пробу; алерты, которые от избытка превращаются в бесконечную пилу и перестают работать; изоляция сервиса на отдельную машину; значения по умолчанию как фолбэк — отдать историю без персонализации, если персонализация отвалилась; отдельные пулы соединений под разные сценарии; двухуровневый кэш, где хоть какие-то данные лучше, чем никаких; backpressure, load shedding и rate limit, привязанный к клиенту и соглашению, а не к состоянию системы; тайм-ауты и circuit breaker с тремя состояниями; откаты против компенсаций; бэкапы, которые надо проверять на восстановимость и консистентность. Последняя глава, про блокчейн и искусственный интеллект, вышла ещё поверхностнее, но мысль о роли архитектора участники подхватывают: обесценивать незнакомую технологию — верный способ стать бутылочным горлышком, полномочия в новых темах лучше отдавать командам. Итог по книге: сильны первые две главы, дальше интерес падал, сквозной пример не зацепил, глубины не хватило — но как обзор её скорее рекомендуют. Клуб прощается до следующего года, если только не подвернётся интересный пейпер.