Почему Bash и shell‑скрипты всё ещё важны для DevOps

Зачем DevOps до сих пор нужен Bash

Bash в DevOps живёт не потому, что «так принято», а потому что большая часть ежедневной работы всё ещё сводится к цепочкам простых действий: собрать информацию, преобразовать вывод, принять решение и применить изменение. Очень часто это буквально «несколько команд в терминале», которые нужно повторить на сервере, в контейнере, на CI‑агенте или в аварийной ситуации — быстро и предсказуемо.

«Пара команд» — это и есть автоматизация

Типичный день DevOps/SRE включает задачи вроде:

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

Почти всегда это начинается с CLI‑инструментов и их вывода. Bash удобен тем, что склеивает утилиты в один сценарий: фильтрация (grep), разбор (awk/sed/jq), контроль ошибок, циклы по хостам, таймауты и ретраи.

Почему shell остаётся базовым навыком для Linux‑инфраструктуры

Linux — стандартная среда для серверов, контейнеров и большинства CI/CD раннеров. Shell доступен «из коробки», не требует установки рантайма и одинаково полезен как на свежем VM, так и внутри минимального контейнера. Это делает Bash универсальным клеем между системами: он помогает работать с файловой системой, правами, процессами, переменными окружения и сетевыми утилитами — тем, что DevOps трогает постоянно.

Что даст эта статья

Дальше — практические примеры, где Bash особенно эффективен, и где он начинает мешать. Мы разберём шаблоны надёжности и безопасности, инструменты качества (линтеры, форматирование, тесты), а в конце — минимальный путь прокачки и чек‑листы для команды.

Роль shell‑скриптов в инфраструктурной автоматизации

Shell‑скрипты в DevOps — это практичный «клей» между утилитами командной строки. Там, где уже есть ssh, curl, jq, sed, awk, tar, systemctl или kubectl, Bash помогает связать их в одну понятную процедуру: взять данные, отфильтровать, преобразовать и передать дальше.

Bash как конвейер из маленьких инструментов

Сильная сторона shell — конвейеры, перенаправления и работа с потоками. Вместо того чтобы писать большой «комбайн», вы собираете цепочку из проверенных инструментов:

kubectl get pods -n app -o json \
  | jq -r '.items[] | select(.status.phase!="Running") | .metadata.name' \
  | xargs -r -n1 kubectl describe pod -n app

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

Скрипты превращают ручные шаги в повторяемый процесс

Типичная инфраструктурная рутина состоит из десятка действий: подготовить переменные, проверить доступность сервиса, сделать бэкап, применить изменение, собрать логи, отправить уведомление. Пока это «чек‑лист в голове», ошибки неизбежны. Скрипт фиксирует порядок действий и делает результат воспроизводимым — особенно когда задачу нужно повторять много раз или передавать другим.

Чем shell отличается от Python/Go/Ansible

Bash не конкурирует с ними напрямую — он закрывает нишу быстрых обвязок:

• Скорость старта: открыть терминал и собрать решение за минуты, без отдельного проекта.
• Минимальные зависимости: shell почти всегда уже есть на Linux‑хостах и в базовых образах.
• Интеграция с CLI: многие DevOps‑инструменты сначала появляются как команда, а уже потом как библиотека.

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

Портируемость и доступность на большинстве систем

Bash ценят в DevOps не потому, что это «самый удобный язык», а потому что он почти всегда под рукой. На голых серверах, в виртуалках, на временных инстансах в облаке, внутри контейнеров и даже в минимальных Linux‑образах (где пакетов минимум) вы чаще всего найдёте хотя бы базовый shell. Это означает: скрипт можно запустить сразу, без предварительной установки окружения.

Bash есть почти везде — и это экономит время

Когда нужно быстро собрать логи, прогнать диагностику, применить небольшой хотфикс или подготовить артефакты сборки, наличие shell «из коробки» решает. Скрипты легко передать через SSH, положить в репозиторий, запустить в CI‑джобе или включить в init‑процедуры контейнера.

Важный нюанс: «есть shell» не всегда означает «есть Bash». В некоторых системах /bin/sh указывает на dash (часто в Debian/Ubuntu), и скрипт, написанный с bash‑расширениями, может внезапно сломаться.

Меньше зависимостей от рантаймов и библиотек

Bash хорош там, где нежелательно тащить Python/Node/Go ради простых действий: склейки команд, фильтрации вывода, проверки статусов, небольшого оркестрирования CLI‑утилит. Чем меньше внешних зависимостей — тем предсказуемее поведение в проде и в CI, особенно в минимальных образах.

Учитывайте различия sh/bash/dash и версии Bash

• Явно выбирайте интерпретатор: #!/usr/bin/env bash для Bash‑скриптов и #!/bin/sh для строго POSIX‑совместимых.
• Не смешивайте POSIX‑синтаксис и bash‑фичи «на удачу»: [[ ... ]], массивы, process substitution <( ) — это не POSIX.
• Проверяйте версию Bash (на macOS долго была 3.2): некоторые возможности (например, ассоциативные массивы) требуют Bash 4+.

Если вам нужна максимальная переносимость, пишите POSIX‑sh. Если нужна удобная выразительность — выбирайте Bash, но фиксируйте ожидания по интерпретатору и версии.

Типовые DevOps‑задачи, где Bash особенно полезен

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

Парсинг логов и метрик

Когда инцидент уже случился, время важнее идеальной архитектуры. Связка tail + grep/sed/awk помогает за минуты найти повторяющиеся ошибки, всплески времени ответа или конкретные запросы.

Если логи/ответы приходят в JSON (например, из API или из лог-агрегатора), добавляется jq: можно вытащить поля, посчитать частоты, собрать мини‑отчёт.

Практичный подход — делать скрипт, который:

• читает последние N строк логов;
• выделяет ключевые маркеры (код ответа, тип ошибки, имя сервиса);
• печатает короткую сводку и сохраняет её в файл для тикета.

Массовые операции на серверах

Рутинные задачи редко «сложные», но их много: права доступа, архивирование, ротация, очистка временных каталогов, проверка места на диске, поиск больших файлов. Bash удобен тем, что рядом уже есть find, tar, du, df, chmod/chown.

Типовой пример: перед деплоем или бэкапом проверить свободное место, создать каталог, выставить права, упаковать и удалить старые архивы по сроку — всё в одном сценарии, без лишних зависимостей.

Сетевые проверки и простые smoke‑checks

Для быстрой диагностики «жив ли сервис» часто достаточно нескольких команд:

• curl — проверить HTTP‑статус, время ответа, заголовки;
• dig — убедиться, что DNS резолвит нужное имя;
• nc — проверить, открыт ли порт и принимаются ли соединения.

Такой скрипт легко повесить на регулярный запуск и получать сигнал раньше пользователей: если статус не 200, DNS отдаёт не тот адрес или порт закрыт — это уже повод поднять тревогу и собрать первичные данные для разборов.

Bash в CI/CD: практично и предсказуемо

CI/CD‑пайплайн почти всегда сводится к последовательности простых действий: забрать исходники, собрать, прогнать тесты, упаковать результат и опубликовать артефакты. Bash хорош тем, что позволяет описать эти шаги без «магии» и лишних зависимостей — то, что написано в скрипте, обычно и выполняется на раннере.

Скрипты как шаги пайплайна

Частый паттерн: отдельные маленькие скрипты под задачу, а не один огромный. Например: ./ci/build.sh, ./ci/test.sh, ./ci/package.sh, ./ci/publish.sh. Так проще переиспользовать шаги локально и в разных пайплайнах.

Чтобы поведение было предсказуемым, в начале скриптов закрепляют «строгий режим»:

set -euo pipefail
IFS=$'\n\t'

Это уменьшает риск «тихих» ошибок, когда команда упала, а пайплайн продолжил выполнение.

Переменные окружения и секреты: что можно логировать

CI/CD живёт на переменных окружения: версии, флаги сборки, адреса реестров, токены. Важно разделять:

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

Практика: включайте подробный вывод точечно, а не глобально. Например, осторожно с set -x: он может утянуть секреты в логи. Если нужно отладить, маскируйте значения (например, печатайте только длину или первые/последние символы).

Повторяемость и детерминированные параметры

Предсказуемость появляется, когда один и тот же скрипт одинаково работает:

• локально у разработчика;
• в контейнере;
• на CI‑раннере.

Для этого фиксируйте версии инструментов (через контейнерный образ или установку конкретных версий), передавайте параметры явно (флаги, пути, теги), и избегайте «зависимостей от окружения» вроде неявных текущих каталогов. Тогда Bash‑шаги становятся не временной заплаткой, а понятным контрактом между кодом и доставкой.

Где здесь может помочь TakProsto.AI

Если у команды много повторяющихся «обвязок» для CI/CD (build/test/package/publish, проверки окружения, dry‑run режимы, сбор диагностик), их удобно стандартизировать. В TakProsto.AI можно быстро набросать внутренний интерфейс (страницу/панель) для запуска типовых операций и генерации параметров, а сами исполнители оставить на Bash: платформа помогает собрать веб‑обвязку и серверную часть (React + Go + PostgreSQL), а скрипты остаются источником правды для того, что реально выполняется на раннере или хосте. При этом важно, что TakProsto.AI работает на серверах в России и использует локализованные/opensource LLM‑модели, что часто критично для инфраструктурных данных и процессов.

Облако и Kubernetes: скрипты как прослойка над CLI

CLI‑инструменты облаков и Kubernetes хороши тем, что дают доступ к возможностям платформы «как есть». Но в реальной эксплуатации нам почти всегда нужна тонкая прослойка: привести параметры к единому виду, добавить проверки, зафиксировать стандарты команды и сделать запуск повторяемым. Здесь Bash особенно удобен: он быстро склеивает команды, читает переменные окружения, работает на билд‑агентах и на админских машинах без лишних зависимостей.

Инфраструктурные «крючки»: bootstrap и healthcheck

Типичный сценарий — маленькие скрипты, которые подготавливают окружение перед основной работой:

• bootstrap: проверяют наличие aws/gcloud/az, kubectl, helm, нужных контекстов, прав и переменных; создают временные каталоги, настраивают KUBECONFIG.
• healthcheck: быстро отвечают на вопрос «сервис жив?»: проверяют доступность API, статус деплоя, наличие нужных секретов/конфигов, возвращают корректные коды выхода для CI.

Важно, что такие «крючки» легко встроить в пайплайны и локальные команды разработчиков — без отдельного приложения.

Автоматизация через CLI облаков и Kubernetes

Bash хорошо подходит для обёрток над командами:

• aws eks update-kubeconfig / gcloud container clusters get-credentials / az aks get-credentials — унифицировать получение доступов к кластерам.
• kubectl — стандартизировать переключение namespace, ожидание готовности (rollout status), сбор диагностик при ошибках.
• helm — задавать одинаковые values и политики релиза (например, атомарные установки, таймауты).

Как писать так, чтобы было безопасно для продакшена

Минимальный набор привычек: включайте строгий режим (set -euo pipefail), цитируйте переменные, делайте явные проверки входных параметров и окружения, добавляйте «сухой запуск» (dry‑run) и подтверждение для опасных операций.

Отдельно стоит логировать ключевые действия и всегда возвращать осмысленные коды выхода — тогда и локальный запуск, и CI/CD ведут себя предсказуемо.

Планировщики и регулярные задачи: cron и systemd

Регулярные задания — это «пульс» эксплуатации: бэкапы, ротация логов, синхронизация артефактов, проверки сертификатов. Bash‑скрипты здесь удобны тем, что их легко запускать по расписанию и так же легко читать при разборе инцидента.

cron vs systemd timers: что выбрать

cron хорош, когда нужно просто и везде: он есть почти на любом Linux/Unix, конфигурация привычна, а формат расписания минималистичен. Подходит для небольших задач и гетерогенных парков, где важно «чтобы работало одинаково».

systemd timers удобнее на современных дистрибутивах с systemd, когда важны управляемость и наблюдаемость. Таймер можно связать с service‑юнитом, получить единый контроль: запуск/остановка, лимиты, зависимости, окружение, журналы через journalctl. Плюс — можно настроить OnBootSec и OnUnitActiveSec, сделать «периодически после старта», а не строго по минутам.

Идемпотентность: повторный запуск без сюрпризов

Планировщик неизбежно приводит к повторам: скрипт может стартовать после сбоя, после рестарта хоста или при ручном запуске.

Минимальные правила:

• Делайте операции проверяемыми: «создать, если нет», «обновить, если изменилось».
• Используйте lock‑файл или системные механизмы блокировки (например, flock), чтобы не было параллельных запусков.
• Явно задавайте рабочий каталог, переменные окружения и PATH — у cron они отличаются от интерактивной сессии.

Логи, коды возврата, уведомления

Хороший скрипт по расписанию всегда:

• Пишет понятные логи (в файл или stdout/stderr, чтобы systemd/cron могли их собрать).
• Возвращает корректный код завершения: 0 — успех, >0 — ошибка.
• Умеет сигнализировать о сбое: хотя бы через почту cron, а лучше — через вызов вашего алертинга (webhook/CLI), чтобы ошибка не «тихо» копилась неделями.

Надёжность скриптов: шаблоны, которые спасают ночи

Bash‑скрипт часто запускается «сам по себе»: по cron, из пайплайна или как часть инцидентного плейбука. В такой ситуации важнее всего предсказуемость: понятные входные параметры, аккуратные ошибки и гарантированная уборка за собой.

Структура: функции, параметры и help

Начинайте с простого каркаса: несколько функций, единая точка входа main, явные параметры и usage. Это снижает вероятность «магии» и делает поведение скрипта читаемым для коллег.

Хороший минимум:

• usage() с примерами запуска и кодами возврата
• разбор параметров (getopts или простой цикл), обязательные аргументы — явно
• разумные значения по умолчанию (например, таймауты, директории, уровни логирования)
• функции вида log(), die(), require_cmd() — чтобы не размазывать проверки по коду

Когда у скрипта есть чёткий интерфейс, его проще использовать в CI/CD и безопаснее переиспользовать в других репозиториях.

set -euo pipefail: сила и подводные камни

Часто помогает связка:

set -euo pipefail

• -e прерывает выполнение при ошибке команды.
• -u ловит обращение к неинициализированным переменным.
• pipefail не скрывает ошибки внутри пайпов.

Но есть нюансы: -e может вести себя неожиданно в условиях if, while, при использовании || true, командных подстановок и некоторых конструкций с пайпами. Практика: явно обрабатывайте ожидаемые ошибки, а «неожиданные» — пусть падают с понятным сообщением через die.

Временные файлы: mktemp, trap и уборка

Временные файлы — частый источник утечек и конфликтов. Делайте безопасно:

• создавайте через mktemp (не фиксируйте имена руками)
• добавляйте trap на EXIT (и при необходимости INT, TERM), чтобы удалить временные файлы даже при падении

Так скрипты не оставляют мусор, не ломаются из‑за гонок и меньше рискуют случайно перезаписать «чужие» данные.

Безопасность в Bash: частые ошибки и как их избежать

Bash часто используется как «клей» между CLI‑утилитами, поэтому одна неосторожная строка легко превращается в уязвимость или в случайное удаление данных. Хорошая новость: большинство проблем повторяются и лечатся понятными правилами.

Инъекции через переменные и подстановки

Самая частая ошибка — передавать пользовательский ввод или содержимое файлов в команды без строгого контроля. Опасны конструкции вроде eval, неэкранированные подстановки $(...), а также сбор команды строкой.

Старайтесь:

• не использовать eval вовсе; если кажется, что он нужен — обычно можно обойтись массивами аргументов;
• явно ограничивать допустимые значения (whitelist), например для имён окружений dev|stage|prod;
• отделять опции от параметров: command -- "$value", чтобы значение не стало «флагом».

Квотирование и пробелы в путях

Пробелы, табы и символы вроде * в именах файлов ломают скрипты и иногда приводят к выполнению «не тех» операций. Правило простое: почти всегда заключайте переменные в кавычки: "$var".

Отдельно опасны шаблоны удаления:

• rm -rf $DIR/* (если DIR пустой или содержит пробелы — последствия непредсказуемы)

Лучше использовать проверки и безопасные формы:

: "${DIR:?DIR is required}"
rm -rf -- "$DIR"/*

Минимальные права, секреты и аудит

Запускайте скрипты с минимально нужными правами: не «на всякий случай» через root. Для секретов не храните токены в репозитории и не печатайте их в логах (осторожнее с set -x). Перед выполнением чужих команд избегайте curl | sh: скачайте файл, проверьте хэш/подпись, затем запускайте.

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

Инструменты качества: линтеры, форматирование и тесты

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

ShellCheck и shfmt: базовый контроль качества

ShellCheck — линтер, который подсвечивает опасные места и даёт конкретные рекомендации: где нужны кавычки, почему [ лучше заменить на [[ (в Bash), где переменная может быть пустой, а где команда в пайпе скрывает код возврата.

shfmt решает другую боль — единый стиль. Когда все скрипты форматируются одинаково, код проще читать на ревью, меньше спорят о пробелах, а рефакторинг становится безопаснее.

Минимальная практика для команды:

• прогонять ShellCheck на каждый скрипт в репозитории;
• запускать shfmt в режиме проверки (без автоправок) в CI, а автоправки — локально.

Юнит‑тесты на скрипты: bats-core или простые обвязки

Для критичных скриптов полезны тесты. bats-core позволяет проверять коды возврата, stdout/stderr и сценарии ошибок.

Если не хочется тащить фреймворк, подойдут простые обвязки: функции assert_eq, assert_status, временная директория через mktemp -d, подмена зависимостей через PATH (кладёте «фейковые» утилиты раньше настоящих).

Как встроить проверки в CI, чтобы не ловить ошибки на продакшене

В CI сделайте отдельный job “shell-quality”:

• shellcheck **/*.sh
• shfmt -d . (проверка форматирования)
• запуск тестов (bats test/ или ./test/run)

И главное — договоритесь: без зелёного job’а скрипты не попадают в основной бранч. Это дешевле, чем разбирать ночной инцидент из‑за одной пропущенной пары кавычек.

Границы Bash: когда выбирать другие инструменты

Bash хорош там, где нужен быстрый «клей» между утилитами и API через CLI. Но у него есть естественные ограничения: сложные структуры данных, поддержка больших проектов и предсказуемая обработка ошибок быстро превращаются в боль. Важно не «запрещать Bash», а вовремя распознавать момент, когда выгоднее переключиться на другой инструмент.

Признаки, что Bash «не тянет»

Если вы узнаёте ситуацию ниже — это сигнал перейти на Ansible/Terraform/Python или хотя бы вынести часть логики из shell:

• Скрипт превратился в мини‑приложение: десятки флагов, режимы работы, сложная валидация, много ветвлений.
• Появилась необходимость надёжно работать с JSON/YAML, массивами объектов, зависимостями версий (в Bash это обычно больно без «обвязки»).
• Требуются идемпотентность и декларативность (например, «приведи систему к состоянию X», а не «выполни шаги 1–10»).
• Всё чаще ловите неочевидные ошибки из‑за пробелов, спецсимволов, подстановок, отличий окружений.
• Нужны модульность, тесты, переиспользование библиотек, нормальная типизация и читаемость для команды.

Скрипт как тонкая обвязка поверх IaC, а не замена IaC

Практичный паттерн: Terraform/Ansible описывают инфраструктуру и конфигурацию, а Bash остаётся «клеем» вокруг них. Примеры:

• подготовить переменные окружения и секреты (получить токены из vault‑CLI);
• собрать артефакты и выполнить terraform plan/apply с единым набором флагов;
• сделать безопасные pre/post‑checks (доступность кластера, наличие нужных ролей/неймспейсов).

Так Bash не конкурирует с IaC, а упрощает повторяемые операции и стандартизирует запуск.

Гибридный подход: Bash + Makefile + контейнеры/таск‑раннеры

Чтобы не плодить «магические» скрипты, часто выигрывает связка:

• Makefile как интерфейс команд (make deploy, make lint, make plan),
• контейнер или task‑раннер (Taskfile, just) для фиксированного окружения,
• Bash для коротких шагов внутри целей.

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

Как прокачать Bash в команде: минимальный путь и чек‑листы

Командный Bash становится сильным не тогда, когда кто‑то «знает все флаги», а когда у всех одинаковые базовые привычки: как писать, где хранить заготовки, как проверять перед выкладкой. Это снижает количество «магии» и ускоряет ревью.

План обучения: 10–15 команд и 5 паттернов (80% результата)

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

Команды: grep, sed, awk (на уровне простых полей), find, xargs, curl, jq, tar, ssh, rsync, systemctl/journalctl, kubectl, docker, date, tee.

Паттерны:

• строгий режим (set -euo pipefail) и аккуратные значения по умолчанию;
• явная обработка аргументов (--dry-run, --env, --timeout);
• идемпотентность (повторный запуск не ломает систему);
• предсказуемое логирование + понятные коды возврата;
• безопасная работа с временными файлами и очистка через trap.

Набор заготовок: меньше вариативности — меньше ошибок

Храните «скелет» скрипта в отдельном репозитории/папке и копируйте его как старт.

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

log() { printf '%s %s\n' "$(date -Is)" "$*" >&2; }
die() { log "ERROR: $*"; exit 1; }

usage() { cat <<'USAGE'
Usage: script.sh --env <name> [--dry-run]
USAGE
}

env=""; dry_run=0
while [[ $# -gt 0 ]]; do
  case "$1" in
    --env) env="${2:-}"; shift 2;;
    --dry-run) dry_run=1; shift;;
    -h|--help) usage; exit 0;;
    *) die "Unknown arg: $1";;
  esac
done
[[ -n "$env" ]] || die "--env is required"

workdir="$(mktemp -d)"; trap 'rm -rf "$workdir"' EXIT
log "Starting for env=$env dry_run=$dry_run"

Чек‑лист перед продакшеном

Перед тем как запускать скрипт «на живом», пройдитесь по короткому списку:

• Безопасность: нет eval, переменные в кавычках, секреты не пишутся в логи, права на файлы/ключи ограничены.
• Тесты: хотя бы один прогон в «песочнице» + --dry-run режим.
• Документация: --help, примеры запуска, что меняет и как откатить.
• Наблюдаемость: понятные сообщения, контекст (env/регион/кластер), корректные коды возврата для CI.

Если закрепить эти правила в шаблоне PR и использовать один скелет, качество Bash в команде растёт почти автоматически.

Как масштабировать командные скрипты без потери управляемости

Когда bash‑обвязок становится много, обычно возникает потребность в «контрольной панели»: единые параметры запусков, история, доступы, понятные кнопки для типовых операций (диагностика, сбор логов, pre/post‑checks), а также быстрый откат.

Один из практичных вариантов — вынести интерфейс и управление в TakProsto.AI: там можно собрать внутреннее приложение через чат (веб‑часть на React, backend на Go, БД PostgreSQL), добавить роли, логирование и, при необходимости, экспорт исходников. При этом сами bash‑скрипты продолжают жить в репозитории и запускаться в вашем привычном окружении (CI‑раннеры, админ‑хосты, контейнеры), а TakProsto.AI становится удобной оболочкой для стандартизации запусков. Для команд это часто означает меньше ручных ошибок и меньше «магии» вокруг того, кто и как запускает инфраструктурные процедуры.