Аварийная автоматизация — бесплатный тест онлайн

Вопрос 1 из 30

Разберите код без пробного запуска; его тема — «Сбор фактов». Какое утверждение точно относится к показанному фрагменту?

date -Is
hostname
ps aux
df -h

Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу. Каждый источник ограничен по времени и записан отдельно, что сохраняет частичный результат при отказе другой команды. Набор даёт базовый снимок, но команды могут зависнуть на проблемном файловом или сетевом ресурсе и смешивают данные без структуры. Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище.

Вопрос 2 из 30

Разберите код без пробного запуска; его тема — «Защита от повторного запуска». Какой вывод об этом варианте можно сделать без догадок о внешнем контексте?

[[ -f /run/fix.lock ]] && exit
touch /run/fix.lock

Каждый источник ограничен по времени и записан отдельно, что сохраняет частичный результат при отказе другой команды. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Явное состояние позволяет оператору понять, где остановилась процедура, и не включает трафик до успешной готовности. Относительное время зависит от часов узла; для корреляции нужны UTC-метки, часовой пояс и границы инцидента.

Вопрос 3 из 30

Разберите код без пробного запуска; его тема — «Частичный сбой». Какой разбор соответствует именно показанной последовательности команд?

disable_traffic
restart_service
enable_traffic

Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Явное состояние позволяет оператору понять, где остановилась процедура, и не включает трафик до успешной готовности. После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча. Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу.

Вопрос 4 из 30

Разберите код без пробного запуска; его тема — «Восстановление». Какое описание не приписывает фрагменту лишних гарантий?

while ! healthcheck; do restart_service; done

Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу.

Вопрос 5 из 30

Разберите код без пробного запуска; его тема — «Проверка и диагностика». Не предполагая намерение автора, что можно утверждать об этой конструкции?

FAIL_STEP=restart ./incident-fix.sh

Переменная полезна только если сценарий специально поддерживает контролируемое внедрение отказа и не может случайно попасть в продуктивную среду. Подмена command внутри Bash легко меняет больше вызовов, чем задумано, и может дать нерепрезентативный тест. Пользователь выбирает и узел, и удалённый shell-код; ошибка или подмена превращает ремонтный инструмент в удалённое выполнение с root-правами. Явное состояние позволяет оператору понять, где остановилась процедура, и не включает трафик до успешной готовности. Белые списки уменьшают пространство команд и узлов, но шаблон имени не подтверждает идентичность сервера и право на конкретный кластер.

Вопрос 6 из 30

Разберите код без пробного запуска; его тема — «Безопасность и переносимость». Какое утверждение точно относится к показанному фрагменту?

host=$1
ssh root@"$host" "$action"

Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Пользователь выбирает и узел, и удалённый shell-код; ошибка или подмена превращает ремонтный инструмент в удалённое выполнение с root-правами. Белые списки уменьшают пространство команд и узлов, но шаблон имени не подтверждает идентичность сервера и право на конкретный кластер.

Вопрос 7 из 30

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

timeout 5 ps -eo pid,ppid,stat,lstart,args > "$case/ps.txt"
timeout 5 df -PT > "$case/df.txt"

Относительное время зависит от часов узла; для корреляции нужны UTC-метки, часовой пояс и границы инцидента. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Каждый источник ограничен по времени и записан отдельно, что сохраняет частичный результат при отказе другой команды. Явное состояние позволяет оператору понять, где остановилась процедура, и не включает трафик до успешной готовности.

Вопрос 8 из 30

Для блока «Защита от повторного запуска» сравнивают несколько внешне похожих решений. Какой вывод наиболее точно привязан к показанной реализации?

exec 9>/run/fix.lock
flock -n 9 || exit 75

Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище. Относительное время зависит от часов узла; для корреляции нужны UTC-метки, часовой пояс и границы инцидента. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу.

Вопрос 9 из 30

Для блока «Частичный сбой» сравнивают несколько внешне похожих решений. Какое утверждение о поведении кода остаётся точным на граничном входе?

state=traffic_disabled
write_state "$state"
if restart_service && readiness; then enable_traffic; state=done; fi

Переменная полезна только если сценарий специально поддерживает контролируемое внедрение отказа и не может случайно попасть в продуктивную среду. Явное состояние позволяет оператору понять, где остановилась процедура, и не включает трафик до успешной готовности. Подмена command внутри Bash легко меняет больше вызовов, чем задумано, и может дать нерепрезентативный тест. Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию.

Вопрос 10 из 30

Для блока «Восстановление» сравнивают несколько внешне похожих решений. Что важно заметить в этом фрагменте до его включения в автоматизацию?

for attempt in 1 2 3; do
  collect_snapshot "$attempt"
  restart_service || break
  healthcheck && recovered=1 && break
done

Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище. Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу. Удалённая фиксированная программа может повторно проверить действие и аудит, избегая передачи произвольного shell-кода. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча.

Вопрос 11 из 30

Для блока «Проверка и диагностика» сравнивают несколько внешне похожих решений. Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

command() { [[ $1 == restart ]] && return 1; builtin command "$@"; }

Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Подмена command внутри Bash легко меняет больше вызовов, чем задумано, и может дать нерепрезентативный тест. Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу.

Вопрос 12 из 30

Для блока «Безопасность и переносимость» сравнивают несколько внешне похожих решений. Фрагмент запускают как часть служебного сценария. Как его следует оценить?

case $action in restart-app|collect-logs) :;; *) exit 64;; esac
case $host in app-[0-9]*) :;; *) exit 64;; esac

Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Белые списки уменьшают пространство команд и узлов, но шаблон имени не подтверждает идентичность сервера и право на конкретный кластер. Удалённая фиксированная программа может повторно проверить действие и аудит, избегая передачи произвольного shell-кода.

Вопрос 13 из 30

В служебном сценарии найден следующий фрагмент по теме «Сбор фактов». Как следует оценить конструкцию, не считая её автоматически исправлением?

journalctl --since -1h > "$case/journal.txt"

Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу. После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча. Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. Относительное время зависит от часов узла; для корреляции нужны UTC-метки, часовой пояс и границы инцидента. Набор даёт базовый снимок, но команды могут зависнуть на проблемном файловом или сетевом ресурсе и смешивают данные без структуры.

Вопрос 14 из 30

В служебном сценарии найден следующий фрагмент по теме «Защита от повторного запуска». Какое суждение правильно описывает показанную реализацию?

operation_id=$(date +%s)

Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Секунда не гарантирует уникальность параллельных запусков; лучше UUID или атомарная запись в координационном хранилище. Попытки ограничены и каждая оставляет снимок, но break после ошибки restart должен вести к явному итоговому отказу.

Вопрос 15 из 30

В служебном сценарии найден следующий фрагмент по теме «Частичный сбой». Какой ответ учитывает и полезный эффект, и остающееся ограничение кода?

trap enable_traffic EXIT

Относительное время зависит от часов узла; для корреляции нужны UTC-метки, часовой пояс и границы инцидента. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Безусловный trap может вернуть трафик после неуспешного ремонта; cleanup и rollback должны учитывать достигнутую стадию. Набор даёт базовый снимок, но команды могут зависнуть на проблемном файловом или сетевом ресурсе и смешивают данные без структуры.

Вопрос 16 из 30

В служебном сценарии найден следующий фрагмент по теме «Восстановление». Код предлагают как альтернативу. Какова его точная техническая оценка?

[[ ${recovered-0} == 1 ]] || enter_safe_mode

После исчерпания попыток система переходит в заранее определённый безопасный режим, а не продолжает обычную работу молча. Белые списки уменьшают пространство команд и узлов, но шаблон имени не подтверждает идентичность сервера и право на конкретный кластер. Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Постоянный дефект создаёт бесконечный цикл перезапусков, стирает диагностику и увеличивает простой. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения.

Вопрос 17 из 30

В служебном сценарии найден следующий фрагмент по теме «Проверка и диагностика». Что является главным свойством этого варианта?

PATH="$fakebin:/usr/bin:/bin" ./incident-fix.sh --dry-run

Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Удалённая фиксированная программа может повторно проверить действие и аудит, избегая передачи произвольного shell-кода. Переменная полезна только если сценарий специально поддерживает контролируемое внедрение отказа и не может случайно попасть в продуктивную среду.

Вопрос 18 из 30

В служебном сценарии найден следующий фрагмент по теме «Безопасность и переносимость». Как следует оценить конструкцию, не считая её автоматически исправлением?

ssh -o BatchMode=yes -- "$host" sudo -- /opt/ops/actions "$action"

Пользователь выбирает и узел, и удалённый shell-код; ошибка или подмена превращает ремонтный инструмент в удалённое выполнение с root-правами. Удалённая фиксированная программа может повторно проверить действие и аудит, избегая передачи произвольного shell-кода. Контролируемые заглушки и dry-run позволяют проверить план, но реальный тест прав, cgroup и сети всё равно нужен в изолированном узле. Атомарная блокировка удерживается дескриптором и освобождается ядром при завершении, хотя flock может быть недоступен или ненадёжен на некоторых сетевых ФС. Подмена command внутри Bash легко меняет больше вызовов, чем задумано, и может дать нерепрезентативный тест.

Вопрос 19 из 30

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

Сбор не должен читать бесконечные /proc-файлы, секреты окружения и гигабайтные журналы без лимита; доказательства тоже могут перегрузить систему. Блокировка на одном узле не предотвращает одновременное действие на кластере; область координации должна совпадать с областью изменяемого ресурса. Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Набор даёт базовый снимок, но команды могут зависнуть на проблемном файловом или сетевом ресурсе и смешивают данные без структуры. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код.

Вопрос 20 из 30

Для блока «Защита от повторного запуска» требуется формулировка без лишних обещаний. На какой границе эта техника перестаёт быть достаточной сама по себе?

Блокировка на одном узле не предотвращает одновременное действие на кластере; область координации должна совпадать с областью изменяемого ресурса. Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код. Сбор не должен читать бесконечные /proc-файлы, секреты окружения и гигабайтные журналы без лимита; доказательства тоже могут перегрузить систему.

Вопрос 21 из 30

Для блока «Частичный сбой» требуется формулировка без лишних обещаний. Где заканчивается защита, которую даёт рассматриваемая конструкция?

Сбор не должен читать бесконечные /proc-файлы, секреты окружения и гигабайтные журналы без лимита; доказательства тоже могут перегрузить систему. Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Блокировка на одном узле не предотвращает одновременное действие на кластере; область координации должна совпадать с областью изменяемого ресурса. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код.

Вопрос 22 из 30

Для блока «Восстановление» требуется формулировка без лишних обещаний. Что способно нарушить ожидаемый результат, хотя основной фрагмент написан корректно?

Dry-run не должен писать state-файл, брать долгую глобальную блокировку или вызывать уведомления как реальная операция; побочные эффекты режима проверяются отдельно. Успешный удалённый healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Инструмент должен иметь режим подтверждения для разрушительных шагов и машинный bypass только с отдельной авторизацией; один флаг --force не является политикой доступа. Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код.

Вопрос 23 из 30

Для блока «Проверка и диагностика» требуется формулировка без лишних обещаний. Какой эксплуатационный компромисс здесь нельзя скрывать за успешным кодом возврата?

Инструмент должен иметь режим подтверждения для разрушительных шагов и машинный bypass только с отдельной авторизацией; один флаг --force не является политикой доступа. Dry-run не должен писать state-файл, брать долгую глобальную блокировку или вызывать уведомления как реальная операция; побочные эффекты режима проверяются отдельно. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код. Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Переменная полезна только если сценарий специально поддерживает контролируемое внедрение отказа и не может случайно попасть в продуктивную среду.

Вопрос 24 из 30

Для блока «Безопасность и переносимость» требуется формулировка без лишних обещаний. Что обязательно нужно проверить в соседнем сценарии, чтобы не получить ложную надёжность?

Успешный локальный healthcheck не всегда означает восстановление пользовательского трафика; критерий должен включать внешний путь и стабилизационный интервал. Инструмент должен иметь режим подтверждения для разрушительных шагов и машинный bypass только с отдельной авторизацией; один флаг --force является политикой доступа. Инструмент должен иметь режим подтверждения для разрушительных шагов и машинный bypass только с отдельной авторизацией; один флаг --force не является политикой доступа. Компенсирующее действие само может завершиться ошибкой; сценарий обязан сообщить исходный и откатный сбой, не затирая первый код. Dry-run не должен писать state-файл, брать долгую глобальную блокировку или вызывать уведомления как реальная операция; побочные эффекты режима проверяются отдельно.

Вопрос 25 из 30

В тесте «Аварийная автоматизация» разбирается тема «Сбор фактов». Что в этой теме является свойством языка, а не случайностью конкретного запуска?

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

Вопрос 26 из 30

В тесте «Аварийная автоматизация» разбирается тема «Защита от повторного запуска». Какое утверждение точнее всего описывает контракт рассматриваемого механизма?

Аварийная команда может быть запущена несколькими операторами; блокировка и уникальный идентификатор операции нужны до первого изменяющего шага. Аварийная автоматизация особенно опасна из-за широких прав: входы должны быть белым списком, команды — фиксированными, а действия — ограниченными областью инцидента. Аварийный сценарий сначала собирает неизменяющие данные с временными метками и идентификатором узла, а затем выполняет действия; команды диагностики тоже имеют таймауты. Многошаговое аварийное действие должно записывать состояние после каждого шага и уметь безопасно продолжить или остановиться после перезапуска. Два процесса могут одновременно пройти проверку до touch; файл также останется после аварийного завершения.

Вопрос 27 из 30

В тесте «Аварийная автоматизация» разбирается тема «Частичный сбой». Какое правило позволяет правильно разобрать эту тему до запуска кода?

Многошаговое аварийное действие должно записывать состояние после каждого шага и уметь безопасно продолжить или остановиться после перезапуска. Если restart_service упал, трафик остаётся выключенным; если enable_traffic выполняется без проверки готовности, запросы вернутся к неисправному узлу. Автоматическое восстановление должно иметь проверяемый критерий успеха, предел попыток и безопасный режим остановки, а не бесконечно «лечить» симптомы. Аварийный сценарий сначала собирает неизменяющие данные с временными метками и идентификатором узла, а затем выполняет действия; команды диагностики тоже имеют таймауты. Аварийная команда может быть запущена несколькими операторами; блокировка и уникальный идентификатор операции нужны до первого изменяющего шага.

Вопрос 28 из 30

В тесте «Аварийная автоматизация» разбирается тема «Восстановление». Какое свойство механизма нельзя подменять удачным примером запуска?

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

Вопрос 29 из 30

В тесте «Аварийная автоматизация» разбирается тема «Проверка и диагностика». Какая формулировка связывает частные примеры одним проверяемым правилом?

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

Вопрос 30 из 30

В тесте «Аварийная автоматизация» разбирается тема «Безопасность и переносимость». Что в этой теме является свойством языка, а не случайностью конкретного запуска?

Аварийный сценарий нужно репетировать на стенде с внедрением отказов: недоступный диск, зависшая команда, отказ отката, два запуска и заполненный журнал. Аварийная команда может быть запущена несколькими операторами; блокировка и уникальный идентификатор операции нужны до первого изменяющего шага. Аварийная автоматизация особенно опасна из-за широких прав: входы должны быть белым списком, команды — фиксированными, а действия — ограниченными областью инцидента. Пользователь выбирает и узел, и удалённый shell-код; ошибка или подмена превращает ремонтный инструмент в удалённое выполнение с root-правами. Аварийный сценарий сначала собирает неизменяющие данные с временными метками и идентификатором узла, а затем выполняет действия; команды диагностики тоже имеют таймауты.