Эксплуатация в архитектуре: как инженеры возвращают схему в реальность

Архитектуру часто проектируют так, будто система будет жить в идеальных условиях: всё работает, данные приходят, связь стабильна. А потом систему передают в эксплуатацию — и выясняется, что красивая на схеме архитектура плохо наблюдается, тяжело восстанавливается и непонятна тому, кто разбирается в инциденте посреди ночи. Эксплуатация — это не то, что начинается после архитектуры. Это то, что архитектура либо предусмотрела, либо нет.

В прошлой статье мы выбирали уровни согласованности под реальные сценарии. Теперь посмотрим на систему глазами тех, кто будет её эксплуатировать — и увидим, что многие архитектурные решения рождаются (или должны рождаться) именно из эксплуатационных вопросов.

В статье

• Почему эксплуатация — часть архитектуры, а не этап после
• Наблюдаемость: видеть систему, а не угадывать
• Деградация: как система ведёт себя, когда всё плохо
• Кто разбирается в инциденте в три часа ночи
• Лунная база: эксплуатация в сценарии аварии
• Где аналитик влияет на эксплуатируемость
• Короткий checklist эксплуатируемости
• Что дальше

Почему эксплуатация — часть архитектуры, а не этап после

Решения, которые кажутся «операционными деталями», на самом деле архитектурные. Где границы контуров — там границы зон ответственности при инциденте. Какие данные мы сохраняем — то и сможем увидеть постфактум. Как устроена деградация — то и определит, переживёт ли система частичный отказ. Если это не заложено в архитектуру, эксплуатация будет компенсировать пробелы героизмом и ручными обходами — ровно тем, чего мы хотели избежать ещё в первой статье серии.

Наблюдаемость: видеть систему, а не угадывать

Наблюдаемость (observability) — это способность ответить на вопрос «что сейчас происходит и почему» по тому, что система отдаёт наружу. Обычно говорят о трёх вещах:

• метрики — числа во времени (загрузка, задержки, остатки): видно, что что-то идёт не так;
• логи — структурированные записи событий: видно, что именно произошло;
• трейсы — путь запроса через контуры: видно, где именно затык.

Для архитектуры важно не «добавить логирование потом», а спроектировать, какие вопросы система должна позволять задавать. Observability — это не список инструментов, а способность ответить:

• почему база ушла в деградацию и в какой момент?
• какой датчик или контур инициировал решение?
• какая версия правил приоритизации сработала?
• на каких данных решение было принято и какими они были в тот момент?

Если контур принимает критичное решение, должно быть видно, на основании каких данных, версии правил и контекста он его принял — иначе разбор инцидента превращается в гадание: факт виден, а логика — нет.

Деградация: как система ведёт себя, когда всё плохо

Хорошая система спроектирована не только для штатного режима, но и для постепенного отказа. Деградация — это заранее продуманные уровни «работает хуже, но работает»:

• что отключается первым при нехватке ресурсов;
• что продолжает работать любой ценой;
• как система сообщает, что перешла в деградационный режим;
• как она возвращается обратно, когда условия восстановились.

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

Без явной модели деградации система ведёт себя при отказе непредсказуемо: вместо «отключили некритичное» получается каскадный сбой. Деградация — это архитектурное свойство, а не аварийная импровизация.

Кто разбирается в инциденте в три часа ночи

Хороший тест архитектуры на эксплуатируемость: представить дежурного инженера, которого разбудил алерт, — а в кейсе лунной базы это может быть и член экипажа без связи с Землёй, у которого нет времени читать архитектурный документ. У него мало времени, неполная картина и высокая цена ошибки. Архитектура ему помогает, если:

• понятно, какой контур отвечает за проблему (ясные границы и ownership);
• видно состояние системы без раскапывания пяти подсистем;
• есть деградационный режим, который уже стабилизировал ситуацию;
• действия восстановления предсказуемы и описаны.

Если же для диагностики нужно держать в голове всю систему — архитектура не эксплуатируема, как бы красиво она ни выглядела на схеме.

Лунная база: эксплуатация в сценарии аварии

Сквозной сценарий серии — связь с Землёй пропала на 40 минут, а энергобюджет просел — это, по сути, эксплуатационный инцидент. Посмотрим, что должна обеспечить архитектура, чтобы его пережить:

• Наблюдаемость локально. Экипаж должен видеть состояние без Земли: пороги жизнеобеспечения, энергобаланс, что уже отключено. Если телеметрия видна только на Земле — в этот момент она бесполезна.
• Деградация по уровням. Система сама понижает приоритет некритичных нагрузок, сохраняя жизнеобеспечение, и явно сообщает, что перешла в аварийный режим.
• Журнал решений. Всё, что контур решил локально, фиксируется — чтобы после восстановления связи наземный центр понял, что произошло и почему.
• Короткий runbook. Журнал фиксирует, что произошло, но экипажу нужна и процедура: как проверить текущий режим, что можно включать обратно и в каком порядке, какие действия запрещены до восстановления. Без неё восстановление зависит от того, кто именно сейчас на смене.
• Предсказуемое восстановление. Когда связь вернулась и энергия восстановилась, система выходит из деградации управляемо, а не лавиной отложенных операций.

Матрица деградации выше говорит, что делает система; экипажу в момент аварии нужен ещё и actionable-алерт с runbook — что делать человеку, по шагам. Разница между «правильно объяснили» и «почти рабочим шаблоном» — вот в такой заготовке:

Алерт energy-budget-low. Условие: доступный энергобюджет < 60% планового резерва на текущий цикл жизнеобеспечения дольше 2 минут. Приоритет: экипажу, требует действия (не информационный).

Runbook ENERGY-LOW:

1. Проверить. Панель энергетики: текущий баланс и прогноз до конца цикла. Убедиться, что это просадка бюджета, а не сбой датчика (сверить с резервным замером).
2. Отключить по порядку. Фоновую аналитику → высокочастотную некритичную телеметрию → зарядку роботов-активов.
3. Понизить. Обогрев и освещение нежилых модулей до минимума.
4. НЕ делать. Не трогать жизнеобеспечение (воздух/вода/давление); не запускать энергоёмкую логистику; не применять буфер команд Земли до восстановления связи.
5. Выйти из режима. Когда энергобаланс выше порога два цикла подряд — включать отключённое в обратном порядке (по одному, контролируя баланс), а не всё разом.
6. Зафиксировать. Время, причину, что отключено и в каком порядке — в журнал решений (для последующего разбора).

Такой runbook снимает зависимость восстановления от того, кто именно сейчас на смене: порядок действий, запреты и критерий выхода заданы заранее.

flowchart TD
  obs["Локальная наблюдаемость
(пороги, энергобаланс)"] --> dec["Контур решений"]
  dec -->|понижает приоритет| deg["Деградация по уровням"]
  dec -->|фиксирует| jrn["Журнал решений"]
  deg --> rb["Runbook восстановления"]
  rb --> recover["Управляемое восстановление"]
  jrn -.->|после связи| ground["Наземный центр"]

Где аналитик влияет на эксплуатируемость

Эксплуатация кажется зоной инженеров, но многое закладывается ещё на уровне требований и доменной модели — там, где работает аналитик:

• определить, что считается инцидентом и какие сценарии система обязана переживать;
• зафиксировать, какие данные должны быть видны для принятия решений (не «всё подряд», а нужное);
• описать уровни деградации на языке домена: что критично, что можно отключить;
• согласовать, какие алерты actionable (требуют действия), а какие лишь информационные: плохие алерты быстро превращаются в шум, на который перестают реагировать;
• принести в разговор реальность эксплуатации: кто, как и в каких условиях будет с этим жить.

Это прямое продолжение мысли из всей серии: дорогие решения рождаются задолго до кода — и эксплуатируемость не исключение.

Короткий checklist эксплуатируемости

Перед тем как считать архитектуру готовой, проверьте:

1. Что должно быть видно, чтобы понять состояние системы без раскопок?
2. Какие сценарии отказа система обязана переживать?
3. Есть ли явная модель деградации — что отключается и в каком порядке?
4. Понятно ли при инциденте, какой контур отвечает за проблему?
5. Фиксируются ли критичные решения для последующего разбора?
6. Какие есть алерты и что каждый из них требует сделать?
7. Есть ли runbook для ключевых инцидентов?
8. Предсказуемо ли восстановление после отказа?
9. Как понять, что восстановление завершено, а не просто исчезли симптомы?
10. Сможет ли дежурный (или экипаж без связи) разобраться, не держа в голове всю систему?

Если на эти вопросы нет ответа, систему придётся эксплуатировать героизмом, а не архитектурой.

Что дальше

Мы прошли всю серию по частям: рамку кейса, роль аналитика, problem statement, требования-драйверы, доменную модель, C4, взаимодействия, согласованность и эксплуатацию. Осталось собрать это в одну картину. Финальная статья серии — сквозной итоговый кейс: собираем рабочую систему лунной базы — проходит один сценарий от требований до эксплуатации, показывая, как все решения складываются вместе.

См. также

• Согласованность данных: где нужна строгая, а где достаточно «в итоге»
• Взаимодействия и интеграции: где ломается кажущаяся простота
• Почему аналитику недостаточно только требований
• Внешнее: Google — Site Reliability Engineering (наблюдаемость, SLO, on-call, actionable-алерты), Michael Nygard — «Release It!» (деградация, bulkhead, circuit breaker, стабильность под отказом).