Никакого притворного успеха
Если бэкенд не поддержан, команда говорит это кодом ошибки. Не возвращает пустой результат, не рисует воображаемую схему, не сообщает об успехе.
Есть инвариант, который проходит через весь инструмент и который проще всего нарушить из лучших побуждений: никакой тихой подмены фактов и никакого притворного успеха.
Формулировка звучит как лозунг. На практике это набор конкретных отказов.
Как это выглядит
Если площадка не описана, команда говорит об этом явно, а не дорисовывает воображаемую схему.
Если активной топологии нет, построение физической карты падает громко со стабильным кодом, а не создаёт пустую карту.
Если стандарт или бэкенд не поддержан, это видно как честное ограничение, а не как «примерное соответствие».
Если протокол не подключён в этой сборке, драйвер отвечает именно это, а не возвращает нули.
Почему пустой результат хуже ошибки
Пустой результат проходит проверку на успешность. Скрипт непрерывной интеграции видит нулевой код возврата и идёт дальше. Отчёт формируется, выглядит нормально, просто в нём ничего нет — или, хуже, есть значения по умолчанию.
Обнаруживается это позже и в другом месте. Разбирать приходится не одну команду, а всю цепочку, потому что непонятно, где именно потерялись данные.
Громкая ошибка локальна. Она случается там, где проблема, и в тот момент, когда проблема возникла.
Стабильные коды вместо текста сообщения
Каждая ошибка имеет собственный код, и код не меняется вместе с формулировкой. Пропала конфигурация проекта — свой код. Неизвестный ключ в конфигурации — свой. Файл состояния попал в индекс git — свой, с отдельным кодом возврата.
Смысл в том, что на код можно опираться. Скрипт различает «конфигурации нет» и «конфигурация неверна» по коду, а не по подстроке в сообщении, которую мы через месяц перепишем.
Все коды собраны в один документ, и все команды зарегистрированы в общем реестре. Это скучная дисциплина, и она единственная известная защита от постепенного расползания поведения.
Отдельно про опасные операции
Есть класс действий, которые остаются заблокированными до появления доказанного бэкенда, модели полномочий, резервного копирования и откатной процедуры.
Это относится к живому управлению физической инфраструктурой: электрикой, железом, оборудованием на площадке. Такие команды существуют в интерфейсе, но не выполняют изменений — и говорят об этом прямо, а не делают вид.
Соблазн включить их «в режиме демонстрации» велик, особенно перед показом. Демонстрация, в которой опасная команда отчиталась об успехе, ничего не сделав, — это худший из возможных результатов показа, потому что после него ей начинают верить.
Что мы за это платим
Инструмент выглядит менее готовым, чем мог бы. Список того, что честно сообщает о неподдержанности, длиннее, чем хотелось бы иметь в презентации.
Взамен есть свойство, которое ценнее полноты: если команда отчиталась об успехе, что-то действительно произошло. Из этого можно строить автоматизацию, и на этом можно основывать решения.