# Никакого притворного успеха

> Если бэкенд не поддержан, команда говорит это кодом ошибки. Не возвращает пустой результат, не рисует воображаемую схему, не сообщает об успехе.

Source: https://naasson.com/ru/blog/nikakogo-fake-success/
Published: 2026-05-03
Language: ru
Product: Naasson Cloud (https://naasson.com/ru/products/naasson-cloud/)
Publisher: Naasson — https://naasson.com

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

Формулировка звучит как лозунг. На практике это набор конкретных отказов.

## Как это выглядит

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

Если активной топологии нет, построение физической карты падает громко со стабильным кодом, а не создаёт пустую карту.

Если стандарт или бэкенд не поддержан, это видно как честное ограничение, а не как «примерное соответствие».

Если протокол не подключён в этой сборке, драйвер отвечает именно это, а не возвращает нули.

## Почему пустой результат хуже ошибки

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

Обнаруживается это позже и в другом месте. Разбирать приходится не одну команду, а всю цепочку, потому что непонятно, где именно потерялись данные.

Громкая ошибка локальна. Она случается там, где проблема, и в тот момент, когда проблема возникла.

## Стабильные коды вместо текста сообщения

Каждая ошибка имеет собственный код, и код не меняется вместе с формулировкой. Пропала конфигурация проекта — свой код. Неизвестный ключ в конфигурации — свой. Файл состояния попал в индекс git — свой, с отдельным кодом возврата.

Смысл в том, что на код можно опираться. Скрипт различает «конфигурации нет» и «конфигурация неверна» по коду, а не по подстроке в сообщении, которую мы через месяц перепишем.

Все коды собраны в один документ, и все команды зарегистрированы в общем реестре. Это скучная дисциплина, и она единственная известная защита от постепенного расползания поведения.

## Отдельно про опасные операции

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

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

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

## Что мы за это платим

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

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