Post #378

Если бы Ивар Якобсон создавал диаграмму устойчивости сейчас, он бы назвал её "диаграммой антихрупкости". Звучит модно, не то что какая-то там робастность! На самом деле нет. Термин "антихрупкость" (antifragile) ввел и раскрутил в одноименной книге Нассим Талеб, трейдер и риск-аналитик (до этого он так же раскрутил термин "черный лебедь"). И в книге он много пишет об отличиях антихрупкости от устойчивости: устойчивость — это способность выдерживать шоковые воздействия и восстанавливаться после них, а антихрупкость — не просто восстанавливаться в то же состояние, а становиться лучше. Как это обеспечить в реальности? Система должна иметь возможность изменять своё поведение без радикальной перестройки внутренней структуры. То есть, структура системы должна обеспечивать возможность таких изменений. Например, один из вариантов — избыточность. Мы почти всегда боремся за отсутствие избыточности и дублирования (принцип DRY), но в случае потенциальной высокой изменчивости среды это может выйти боком (например, см. заметку про это в блоге Гугла). Антихрупкая система допускает избыточность, и при изменении внешних условий какой-то вариант реализации может оказаться более подходящим. Сюда же можно отнести несколько альтернативных вариантов выполнения одного юскейса, что часто забывают. Юскейс — это набор сценариев, ведущих к достижению цели, а не один сценарий. У вас поломался пользовательский интерфейс, но остается чат, в котором ту же задачу можно решить через оператора. При этом часть функций системы может отмереть, перестать использоваться. А часть — соединиться в другой последовательности для выполнения задачи в изменившихся условиях. Это как раз позволяет проследить диаграмма устойчивости — можно ли соединить её элементы (сущности, контроллеры, интерфейсы) другим способом? На этот вызов отвечает (микро)сервисная архитектура. Для этого нужен HATEOAS с набором ссылок в REST. А жестко зафиксированный сценарий юскейса наоборот мешает. Сюда же относятся различные средства мониторинга, автоматические размыкатели и балансировщики. У аналитиков есть проблема: смотреть на сценарий юскейса, как будто это единственный экземпляр юскейса в системе. На самом деле почти все интересные системы сейчас многопользовательские, и каждый раз имеет смысл подумать, что будет, если много экземпляров юскейса выполняется параллельно в одно и то же время. Опять же, на диаграмме устойчивости это можно отметить: сколько экземпляров контроллера запущено (и какая очередь перед ним может возникнуть), есть ли конкурирующие обращения к одной и той же сущности. В антихрупкой системе всё это под мониторингом с цепями обратной связи, то есть регулируется само в положительную сторону, и останавливает каскад ошибок при развитии ситуации в отрицательную сторону. На какой диаграмме можно наметить точки мониторинга?.. Талеб также описывает "стратегию штанги", которая рекомендует фокусироваться только на супер-безопасных выборах (безрисковых) и на супер-рискованных (но потенциально приносящих большой эффект), убирая середину и сбалансированные по риску выборы. Это уже к вопросу про выбор фич. Не нужно делать что-то среднее — нужно прокачивать то, что не меняется и гарантировано приносит пользу, и что-то безумное, что скорее всего зафейлится, но если взлетит — окупит предыдущие фейлы. Но это уже тема для отдельного поста.