Авария в дата-центре: как SBL поднял сервер за 3 минуты

Это был обычный вторник, когда сервер неожиданно лег. Аварийное гашение дата-центра. Когда он вернулся, аптайм показывал 16 минут, и нужно было быстро понять: кто выжил, а кто нет.

34 сервиса должны были работать. Вопрос - кто из них реально поднялся.

Проблема: 34 сервиса и ни одного чеклиста

Можно проверять по списку: nginx, xray, PostgreSQL... Так работает обычный чеклист. Проблема в том, что чеклист знает только то, что в него зашили. Если сервис переехал на другой порт или появилась новая зависимость - чеклист об этом не знает.

Можно дать AI-агенту инструкцию: "проверь все сервисы и скажи, что упало". Но агент работает с представлением о системе, а не с реальным знанием. Он может написать "перезапустить nginx", не зная, что xray зависит от того же порта. Быстрый патч - новый баг.

Именно для этого я разработал SBL - System Boundary Layer. Его задача: заставить агента знать систему, а не гадать о ней.

Что такое SBL

SBL - это прослойка на уровне вызова инструментов. Она живёт в хуках on_session_start, pre_tool_call и transform_tool_result, а не в промпте. Это значит: её нельзя "забыть". LLM может потерять контекст после компрессии, но SBL - это Python-код, который выполняется до того, как модель получила управление. При старте сессии он делает полный аудит системы, при опасных операциях - проверяет зависимости, при успешных изменениях - учится новым путям.

Что делает SBL:

• systemctl list-units → какие юниты загружены и в каком состоянии (active, failed, inactive)

• ss -tlnp → какие порты слушаются и какими процессами

• /proc/PID/fd → какие файлы и сокеты открыты у каждого процесса

• Кросс-референс: сервис X слушает порт Y → принадлежит PID Z → открыт конфиг W

• Строит service_map.json - полную карту инфраструктуры

• Строит learned_deps.json - граф зависимостей: кто от кого зависит

Главное: SBL знает не то, что "должно быть", а то, что реально работает. Динамически, а не из статического списка.

Как это сработало при восстановлении

Я запустил SBL-аудит. Механизм сделал полный снимок и сравнил с эталонной картой. Результат: 34 сервиса в карте, 2 в статусе failed.

Первая проблема: xray не стартовал. В логах: bind: address already in use на порту 8443. Сработал кросс-референс SBL: ss -tlnp показал, что порт 8443 занят nginx, а xray тоже хотел этот порт для trojan-inbound. Race condition, которая работала годами (кто первый встал - тот и забрал), после ребута сыграла против xray.

Агент не гадал, что перезапустить. Он увидел реальную картину: два сервиса, один порт, nginx победил, xray упал.

Вторая проблема: устаревший бот ушёл в crash loop. SBL через systemctl показал: unit загружен, но failed. Директория удалена, unit не отключён.

Обе проблемы агент увидел не потому,что "знал" заранее, а потому что SBL дал ему знание о системе - в реальном времени, с зависимостями, с конфликтами.

Результат

34 из 34 сервисов active. От запуска SBL-аудита до полного восстановления - примерно 3 минуты.

Но главное - не скорость. Главное - что агент опирался на реальную картину системы, а не на предположения. SBL показал → увидел конфликт → устранил причину, а не симптом.

Что дальше

Сейчас SBL запускается по запросу агента. Следующий шаг - автоматический crash recovery: при перезагрузке SBL сам делает diff(текущее состояние, последнее хорошее), находит аномалии и применяет исправления. Агенту даже не нужно спрашивать - он просто получает отчёт: "Сервер восстановлен, 2 проблемы исправлено".

ADR-006 описывает этот пайплайн отдельно.

А сегодня SBL, разработанный мной для эпистемического контроля агента, отработал не как теория, а как production-инструмент. Сервер после аварийного гашения поднялся, механизм сделал диагностику, агент восстановил систему на основе знания, а не гадания. Работает.