CI/CD и инфраструктура: вопросы для собеседования QA

QA в работе с Docker чаще всего использует: `docker ps` — список запущенных контейнеров, `docker logs <container>` — просмотр логов сервиса, `docker exec -it <container> bash` — вход в контейнер для отладки.

Важно понимать разницу между image (шаблон) и container (запущенный экземпляр). `docker-compose up -d` поднимает все зависимости разом, `docker-compose down` — останавливает и удаляет.

Из практики: когда тест падает из-за зависимости, первым делом смотрю `docker logs` нужного контейнера — там 80% ответов на вопрос 'почему не работает'.

Описываю в docker-compose.yml нужные сервисы (приложение, база, очередь) с volumes, networks и depends_on, задавая связи и порядок запуска.

Поднимаю стенд одной командой docker-compose up -d, а для чистого teardown между прогонами делаю docker-compose down -v со сбросом томов.

Фиксирую версии образов, чтобы окружение было повторяемым и одинаковым у всей команды и в CI.

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

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

GitHub Actions — встроен в GitHub, конфигурируется YAML прямо в репозитории, минимальная инфраструктура для поддержки, быстрый старт; GitLab CI — аналог для GitLab, сильная интеграция с GitLab Merge Requests и встроенный container registry.

Из практики: для новых проектов на GitHub выбираю GitHub Actions — меньше накладных расходов. Jenkins беру только когда нужна специфичная инфраструктура или сложная оркестрация.

Тестовый процесс в Docker строю так: Dockerfile для тестов устанавливает зависимости и копирует код, `ENTRYPOINT` запускает pytest/mvn test, allure-results монтирую как volume чтобы забрать отчёт после.

Переменные окружения (URL стенда, токены) передаю через `-e ENV=value` или `.env`-файл — не хардкожу в образе. В CI запускаю `docker run --rm -v $(pwd)/results:/app/results test-image`.

Из практики: монтирование папки результатов через volume — ключевой момент. Без него allure-results останутся внутри контейнера и CI не сможет опубликовать отчёт.

Git нужен QA, чтобы понимать состав изменений и быстро находить источник регрессии.

Я регулярно смотрю историю правок, ветки и отличия между версиями перед проверкой релиза.

Из практики: даже базовые навыки Git заметно ускоряют анализ дефектов.

Docker даёт воспроизводимое окружение: тесты идут одинаково локально и в CI, без «магии» на конкретной машине.

Практики: Dockerfile/образ тестового окружения, docker-compose для поднятия зависимостей (БД, брокеры, моки), healthcheck перед прогоном, запуск на чистом контейнере в CI.

Инструменты: docker-compose, Testcontainers (поднятие контейнеров прямо из тестов), образы Selenium/Selenoid для UI-тестов.

Из практики: это сильно сокращает число «у меня работает, у тебя нет».

QA в CI/CD отвечает за качество конвейера: настраивает и поддерживает тестовые этапы (smoke, regression, integration), определяет quality gates — пороги, при которых сборка блокируется.

QA управляет тестовыми окружениями в пайплайне, анализирует отчёты после каждого прогона, принимает решение о готовности артефакта и эскалирует критичные падения.

Из практики: главная ценность QA в CI/CD — не просто запустить тесты, а сделать так, чтобы команда доверяла зелёной сборке и могла выкатываться уверенно.

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

Тестовые данные держу управляемыми: разделяю постоянные наборы и данные, создаваемые на лету.

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

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

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

Мониторинг: собираю метрики прогонов (pass rate, длительность, доля flaky), вывожу их на дашборды (Allure/Grafana) и настраиваю алерты на рост падений — всё интегрировано в CI.

Из практики: информативные журналы вместе с трендами и алертами сокращают разбор падения в разы и ловят нестабильные тесты раньше.

Стандартные уровни логирования по возрастанию серьёзности: DEBUG (детальная диагностика), INFO (штатные события), WARNING (подозрительные, но не критичные ситуации), ERROR (ошибки, требующие внимания), CRITICAL/FATAL (критический сбой, система не может продолжать).

Уровни позволяют фильтровать вывод: в разработке и при отладке тестов использую DEBUG, на продакшне — WARNING и выше, чтобы не засорять журналы.

Из практики: при разборе инцидента первым делом переключаю уровень на DEBUG и воспроизвожу сценарий — это даёт полную картину без правки кода.

Управление тестовыми окружениями — это про предсказуемость: версии, настройки и данные должны быть понятны и контролируемы.

Я фиксирую конфигурацию и стараюсь минимизировать ручные изменения.

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

Практика непрерывной сборки в QA — это частые прогоны, быстрый отклик и понятный отчёт о рисках.

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

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

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

Canary: новая версия получает небольшой процент трафика (например, 5%), постепенно растущий. Риск ограничен малой аудиторией, дефекты видны на реальных пользователях до полного ролаута. Rolling: постепенная замена инстансов — меньше ресурсов, но нет мгновенного отката.

Из практики: для критичных сервисов предпочитаю canary или blue-green — возможность отката важнее скорости выкладки. Проверяю метрики ошибок в период ролаута, прежде чем расширить трафик.

IaC позволяет создавать тестовые окружения воспроизводимо и автоматически: Terraform поднимает ресурсы в облаке, Docker Compose конфигурирует локальные зависимости, Ansible устанавливает нужные версии.

В тестировании применяю IaC для создания изолированных стендов на каждый PR (ephemeral environments) и их автоматического уничтожения после проверки — это убирает пересечение данных.

Из практики: главный выигрыш — исчезает класс дефектов «работало на стенде, упало в проде» за счёт идентичности конфигураций окружений.

Сверяю, что именно изменилось: версия артефакта, миграции схемы БД, изменения конфигурации, обновления зависимостей и контракты между сервисами.

Проверяю health-check и логи старта, ошибки применения миграций, совместимость нового кода с текущей схемой БД и форматы API между сервисами.

Из практики: если всё сломалось сразу после выкладки — первым делом проверяю миграции и конфиги, они ломают чаще всего. Откат на предыдущую версию — быстрый способ подтвердить гипотезу.

Docker — это платформа для упаковки приложений вместе с их окружением (библиотеки, зависимости, конфиги) в изолированные контейнеры. Контейнер можно запустить одинаково на любом хосте с Docker.

Главные задачи: убрать различие «у меня работает, на сервере нет», ускорить деплой, обеспечить воспроизводимость окружения, упростить масштабирование сервисов.

Из практики: Docker особенно полезен в командах, где разработка, тестирование и продакшен — разные машины. Тестировщик может одной командой поднять стек и проверить интеграции.

Образ — это шаблон, неизменяемая упаковка слоёв файловой системы с приложением и зависимостями. По одной аналогии — это «класс».

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

Из практики: из одного образа можно запустить сколько угодно контейнеров. Образы хранятся в реестре (например, Docker Hub), контейнеры — на хосте.

Dockerfile — это текстовый файл с рецептом сборки образа. Каждая инструкция создаёт новый слой.

Самые частые: FROM (базовый образ), WORKDIR (рабочая директория), COPY/ADD (копировать файлы), RUN (выполнить команду на этапе сборки), ENV (переменные окружения), EXPOSE (документировать порт), CMD (команда по умолчанию при запуске), ENTRYPOINT (фиксированная точка входа).

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

ENTRYPOINT задаёт основную команду, которая всегда выполняется при docker run. CMD задаёт аргументы по умолчанию или команду, которую можно легко переопределить из docker run.

Если задан только CMD — она и есть точка входа. Если оба заданы — CMD передаётся в ENTRYPOINT как аргументы. docker run image arg1 переопределит CMD, но не ENTRYPOINT (для смены ENTRYPOINT нужен флаг --entrypoint).

Из практики: ENTRYPOINT используют, когда контейнер должен вести себя как одна конкретная утилита (например, postgres, nginx). CMD — для гибкости запуска.

Каждая инструкция в Dockerfile (FROM, COPY, RUN и т.д.) создаёт отдельный слой файловой системы. Образ — это набор этих слоёв, наложенных друг на друга.

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

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

Самые ходовые: -d (фоновый режим), -p host:container (проброс порта), -v volume:path (том), --name (имя контейнера), --rm (удалить после остановки), -e KEY=VALUE (переменная окружения), --network (сеть), -it (интерактивный режим с терминалом).

Пример полноценного запуска: docker run -d --name api -p 8080:8080 -e DB_HOST=db --network app-net myapp:1.0

Из практики: --rm удобно для одноразовых задач (миграции, скрипты) — не накапливаются мёртвые контейнеры. -d — для сервисов.

Файл .dockerignore исключает файлы и папки из контекста сборки, который отправляется демону Docker. Синтаксис похож на .gitignore.

Помогает избегать копирования node_modules, .git, локальных .env и больших артефактов в образ, ускоряет сборку и уменьшает размер итогового образа.

Из практики: первое, что добавляют в новый проект с Dockerfile, рядом с ним. Иначе COPY . . затащит всё подряд, включая секреты.

Bind mount — это прямая привязка папки или файла хоста к пути в контейнере. -v /home/user/app:/app. Контейнер видит реальную файловую систему хоста.

Именованный том (named volume) управляется Docker: -v mydata:/var/lib/db. Том живёт отдельно от контейнера, хранится в каталоге Docker и не зависит от структуры хоста.

Из практики: bind mount удобен для разработки — изменения файлов сразу видны в контейнере. Named volume — для продакшена, для данных БД и логов, которые должны переживать перезапуск.

docker-compose — это инструмент для описания и запуска многоконтейнерных приложений через один файл docker-compose.yml. В нём задают сервисы, сети, тома, переменные окружения.

Одной командой docker compose up можно поднять весь стек (API + БД + Redis + бот), а docker compose down — остановить и убрать.

Из практики: для локальной разработки и интеграционных тестов — практически обязательный инструмент. Для продакшена крупных систем переходят на Kubernetes.

depends_on в базовой форме гарантирует только порядок запуска: указанные сервисы стартуют раньше зависимого. Но он не ждёт, пока зависимый сервис будет готов принимать соединения.

Чтобы дождаться готовности, есть формат depends_on с condition: service_healthy — тогда compose ждёт прохождения healthcheck зависимого сервиса.

Из практики: для БД и брокеров без healthcheck приложение должно само ретраить подключение или использовать wait-for-it/dockerize-скрипт. Лучше — добавить healthcheck в БД и condition: service_healthy.

Compose создаёт для проекта общую сеть. Каждый сервис попадает в неё и доступен другим по имени сервиса как по хосту. Если в compose есть сервисы db и api, внутри api можно обратиться к db:5432.

Контейнеры из разных compose-проектов по умолчанию в разных сетях и не видят друг друга. Чтобы связать — создают external network и подключают сервисы из обоих проектов.

Из практики: внутри сети compose работает встроенный DNS, поэтому обращение по имени сервиса всегда стабильно, в отличие от IP-адресов, которые могут меняться.

Healthcheck — это команда, которую Docker периодически выполняет внутри контейнера, чтобы понять, жив ли сервис. По её exit code контейнер помечается healthy или unhealthy.

Задаётся в Dockerfile (HEALTHCHECK CMD ...) или в compose (healthcheck: test: ...). Параметры: interval, timeout, retries, start_period.

Из практики: для HTTP-сервиса часто пишут curl -f http://localhost:8080/health || exit 1. Для БД — pg_isready или mysqladmin ping. Healthcheck позволяет depends_on ждать готовности.

Multi-stage build — это сборка в один Dockerfile, разделённая на несколько этапов через FROM ... AS name. На одном этапе компилируют/собирают, на следующем копируют только итоговые артефакты, и базовый образ финального этапа — минимальный.

Это даёт небольшой итоговый образ без компиляторов и dev-зависимостей. Особенно ценно для Go, Java, Node.js со сборкой.

Из практики: можно сократить образ Node-приложения с 1 ГБ до 100 МБ. Финальный stage берёт alpine или distroless, а build stage — полноценный SDK.

Реестр — это сервис, где хранятся образы. Docker Hub — публичный реестр по умолчанию. Есть GitHub Container Registry (ghcr.io), GitLab Container Registry, AWS ECR, Google Artifact Registry, Yandex Container Registry, а также self-hosted решения вроде Harbor или Sonatype Nexus.

Образ адресуется по схеме registry/namespace/image:tag. Если registry опущен — подразумевается Docker Hub.

Из практики: для приватного кода и в банках/энтерпрайзе обычно нужен self-hosted registry. Чтобы не публиковать образы наружу и хранить рядом с CI.

Главные приёмы: использовать минимальный базовый образ (alpine, slim, distroless), multi-stage build, объединять RUN-инструкции и чистить кеш менеджера пакетов в той же команде, не копировать лишние файлы (через .dockerignore).

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

Из практики: для Node.js — npm ci --omit=dev на финальном stage; для Python — pip install --no-cache-dir; для Debian — apt-get install ... && rm -rf /var/lib/apt/lists/* в одном RUN.

По умолчанию Docker пишет stdout/stderr контейнера в файл на хосте через json-file driver. Команды docker logs container и docker compose logs читают этот файл.

Без ротации файл может разрастись и съесть диск. В daemon.json или в конкретном run/compose задают параметры драйвера: max-size, max-file. Также можно использовать другие драйверы: journald, syslog, fluentd, gelf, awslogs.

Из практики: на проде обязательно настраивают ротацию или внешний сборщик логов (ELK, Loki, CloudWatch). Иначе через несколько недель сервер встанет из-за заполненного диска.

Доступные политики: no (по умолчанию, не перезапускать), on-failure[:max-retries] (только при ненулевом exit code), always (всегда, включая остановку демона), unless-stopped (как always, но не перезапускать, если контейнер был остановлен вручную).

Задаются через --restart в docker run или restart в compose.

Из практики: для сервисов чаще всего unless-stopped — хорошо переносит перезагрузки сервера, но уважает ручную остановку. on-failure подходит для воркеров, которые должны падать и подниматься заново при ошибках.

По умолчанию процесс в контейнере работает от root внутри контейнера. Это означает: при побеге из контейнера (например, через уязвимость или неверно настроенный volume) злоумышленник получает root на хосте.

В Dockerfile добавляют RUN groupadd ... && useradd ..., потом USER appuser перед CMD. На уровне runtime можно ограничить капабилити (--cap-drop ALL), запретить privileged режим и использовать read-only файловую систему.

Из практики: для прод-сервисов запуск от non-root — стандарт. Это требует подумать о правах на копируемые файлы и volume.

ARG — переменная времени сборки (build-time). Доступна только в Dockerfile во время docker build, не сохраняется в образе как переменная окружения. Передаётся через --build-arg.

ENV — переменная окружения, доступна и при сборке, и в работающем контейнере. Сохраняется в образе и видна процессам внутри.

Из практики: ARG подходит для версий зависимостей и флагов сборки. ENV — для настроек рантайма (порт, путь к конфигу). Секреты не передавайте ни через ARG, ни через ENV — они попадут в историю слоёв.

docker exec запускает новый процесс внутри уже работающего контейнера. Типично docker exec -it container bash — открыть оболочку для отладки рядом с основным процессом.

docker attach подключает терминал к stdin/stdout уже запущенного основного процесса. Это как «подсмотреть» вывод и (опасно) отправить ввод тому же процессу. Выход через Ctrl+P, Ctrl+Q без остановки.

Из практики: для зайти и посмотреть — exec, для понаблюдать за foreground-процессом — attach. Случайное Ctrl+C в attach может остановить весь сервис.

Сначала смотрят логи: docker logs container_name (или docker compose logs service). Обычно там видно ошибку запуска: не хватает переменной окружения, не подключается БД, не найден файл.

Если логи пустые, проверяют exit code (docker ps -a) — он подскажет, был ли это сбой команды, OOM kill или сигнал. Также проверяют, что команда правильно задана в CMD/ENTRYPOINT.

Из практики: типичные причины — отсутствует /app/index.js, не выставлена переменная окружения, неправильный путь к конфигу, healthcheck завершает контейнер. Запуск с docker run --rm -it image bash помогает зайти внутрь без выполнения CMD.

Флаги docker run: --memory=512m, --memory-swap, --cpus=1.5, --cpu-shares. В compose — mem_limit, cpus, либо через deploy.resources (требует swarm mode для жёсткого применения).

Если контейнер превысит лимит памяти, ядро его убьёт (OOMKilled). По CPU — будет throttle, но процесс не упадёт.

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

docker system prune удаляет неиспользуемые объекты: остановленные контейнеры, висячие образы (без тегов и не используемые), кеш сборки, неиспользуемые сети. С флагом -a добавит все неиспользуемые образы (включая помеченные тегами).

С флагом --volumes удаляет ещё и неиспользуемые тома — а это уже про данные.

Из практики: prune без --volumes сравнительно безопасен на dev-машине. На проде или общем dev-сервере лучше точечно: docker container prune, docker image prune.

Базовый рецепт: bind mount исходного кода в контейнер (-v $(pwd):/app), запуск сервиса в режиме watch (npm run dev, nodemon, uvicorn --reload и т.п.) и проброс портов.

Зависимости (node_modules, venv) лучше держать в отдельном анонимном томе или внутри образа, чтобы не было конфликта между хостом и контейнером (особенно при разных архитектурах).

Из практики: на macOS/Windows bind mount может быть медленным — для крупных проектов смотрят на :cached, :delegated mount options или на специальные решения вроде Docker Desktop sync.

Testcontainers — это библиотеки для Java, Python, Go, .NET и др., которые из кода теста поднимают Docker-контейнеры (БД, брокеры, эмуляторы) и удаляют их после.

Это даёт настоящие зависимости в тестах без моков: реальная PostgreSQL, реальная Kafka, реальный Redis. Каждый тест может получить чистый контейнер на изолированном порту.

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

Процесс — это запущенная программа со своим адресным пространством, набором ресурсов и хотя бы одним потоком исполнения. У каждого процесса есть свой PID.

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

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

Это три стандартных потока ввода-вывода у каждого процесса. stdin (файловый дескриптор 0) — ввод, обычно с клавиатуры. stdout (1) — обычный вывод. stderr (2) — поток для ошибок и диагностики.

Разделение нужно, чтобы пользовательский вывод и сообщения об ошибках можно было направлять в разные места: cmd > out.txt 2> err.txt.

Из практики: в скриптах и контейнерах stdout идёт в обычные логи, а stderr — туда же, но с пометкой как ошибка. В программах важно писать ошибки именно в stderr.

> перенаправляет stdout в файл, перезаписывая его. >> добавляет в конец файла. < читает stdin из файла. | передаёт stdout одной команды в stdin другой (пайп).

Также есть 2> (перенаправление stderr), &> (и stdout, и stderr — в bash). Конструкция 2>&1 направляет stderr туда же, куда сейчас идёт stdout.

Из практики: пайпы позволяют собирать сложные цепочки обработки из простых утилит: cat file | grep error | wc -l. Это сердце философии Unix.

Каждый файл имеет три набора прав: для владельца (user), группы и остальных (other). Каждый набор состоит из r (чтение), w (запись) и x (исполнение, или для каталога — вход).

В выводе ls -l: например, -rwxr-xr-- значит «обычный файл, владелец — rwx, группа — r-x, остальные — r--».

Из практики: для скрипта нужны r и x. Для каталога x обязателен, чтобы открыть его и обратиться к содержимому. Для секретов выставляют 600 — только владелец читает и пишет.

chmod меняет права доступа к файлу или каталогу (rwx для user/group/other). chown меняет владельца и/или группу файла.

Пример: chmod 644 file.txt задаёт права rw-r--r--. chown alice:devs file.txt делает alice владельцем, а devs — группой.

Из практики: в Docker частая проблема — bind mount из хоста с одним владельцем в контейнер с другим. Решают через chown внутри контейнера или единый UID/GID.

grep ищет строки, соответствующие шаблону, в файлах или stdin. По умолчанию выводит подходящие строки.

Ключевые флаги: -i (без учёта регистра), -r (рекурсивно по каталогу), -n (показать номер строки), -v (инвертировать — показать несовпадающие), -E (расширенные регулярные выражения), -c (только количество).

Из практики: типовые задачи — найти ошибку в логе (grep -i error app.log), найти все использования функции в коде (grep -rn 'fooBar' src/), посчитать строки (grep -c).

sed — это потоковый редактор: ищет шаблон, заменяет, удаляет, вставляет строки. Типовое sed -i 's/foo/bar/g' file заменяет все foo на bar.

awk — это язык обработки построчных текстовых данных. Хорошо работает со столбцами: awk '{print $1, $3}' file выведет первый и третий столбец каждой строки. Поддерживает условия, агрегаты, массивы.

Из практики: для простой замены — sed. Для отчётов по логам и арифметики на ходу — awk. Часто sed и awk встречаются вместе в одной команде через пайп.

find рекурсивно обходит файловую систему и возвращает пути файлов, удовлетворяющих условиям: имя, тип, размер, время изменения, права и т.д.

Примеры: find . -name '*.log' (найти логи), find /var/log -mtime +7 -delete (удалить старше недели), find . -type f -size +100M (большие файлы).

Из практики: find удобно сочетать с -exec или с xargs для массовых действий: find . -name '*.tmp' -delete или find . -name '*.js' | xargs grep TODO.

Жёсткая ссылка (hard link) — это второе имя для того же файла. Файл существует, пока есть хотя бы одна ссылка на его inode. Создаётся через ln file link.

Символическая ссылка (soft link, symlink) — это отдельный файл, который содержит путь к цели. Если цель удалить, ссылка останется, но будет «битой». Создаётся через ln -s target link.

Из практики: hard link нельзя сделать между разделами и для каталогов. Symlink делают для удобной адресации (current → release-2024), для общих библиотек, для переключения версий.

ps показывает снимок процессов (ps aux — все процессы со всеми пользователями). top и htop — интерактивные мониторы с обновлением (htop удобнее: цвета, фильтры, дерево). vmstat и iostat — статистика памяти и ввода-вывода.

Для дискового пространства — df (по разделам), du (по файлам/каталогам). Для сети — ss, netstat, iftop. Для нагрузки на конкретный процесс — pidstat, strace.

Из практики: на любом сервере первый шаг при «что-то тормозит» — htop, потом iostat, потом df. Часто проблема в одном жадном процессе или заполненном диске.

kill отправляет сигнал процессу по PID. По умолчанию SIGTERM (15) — попросить корректно завершиться. SIGKILL (9) — принудительно убить, процесс не успеет ничего почистить. SIGINT (2) — то же, что Ctrl+C. SIGHUP (1) — обычно «перечитать конфиг».

Полный список: kill -l. Послать: kill -SIGTERM 1234 или kill -9 1234.

Из практики: всегда сначала SIGTERM, чтобы процесс закрыл соединения и записал данные. SIGKILL — только если завис и не реагирует.

В системах с systemd логи централизованы в journald. Смотрят через journalctl: journalctl -u nginx (для сервиса), journalctl -f (хвост в реальном времени), journalctl --since '1 hour ago'.

Также остаются «классические» файлы в /var/log: syslog, auth.log, kern.log, messages. Сервисы могут писать в свои подкаталоги: /var/log/nginx/, /var/log/postgresql/.

Из практики: для большинства задач хватает journalctl — он умеет фильтровать по сервису, по времени, по приоритету. Файлы в /var/log часто заполняют дублирующую роль и/или нужны для совместимости со старыми инструментами.

df показывает занятое место по разделам файловой системы (df -h — в человеко-читаемом виде). Это вид «сверху»: сколько свободно на /, /var, /home и т.д.

du показывает занятое место по конкретным файлам и каталогам. Например, du -sh /var/log/* покажет, кто занимает место в каталоге логов.

Из практики: «заполнился диск» начинают с df, чтобы понять какой раздел. Потом идут с du по корню этого раздела вглубь, чтобы найти большие каталоги.

ss и netstat — открытые порты и соединения. ip a и ip r — интерфейсы и маршрутизация (замена устаревшим ifconfig/route). dig и nslookup — DNS-запросы. curl и wget — HTTP-запросы. ping и traceroute — доступность и путь до хоста. nc (netcat) — открыть/проверить TCP-порт.

Для диагностики типового сценария «сервис не отвечает»: ss -tnlp (слушает ли процесс порт), curl http://host:port/health, dig service.example.com.

Из практики: ss быстрее netstat и подробнее. dig +short — компактный вывод для скриптов. tcpdump и Wireshark — когда нужно посмотреть пакеты.

systemd — это система инициализации и менеджер сервисов в большинстве современных дистрибутивов. Заменяет старый sysvinit. Управляет порядком запуска, зависимостями, рестартами, журналом.

Юнит-файл (.service, .timer, .socket) — описание сервиса: какую команду запустить, в каком окружении, как рестартить, от кого. Лежат в /etc/systemd/system/ или /usr/lib/systemd/system/.

Из практики: для своих приложений на сервере пишут unit-file с ExecStart, Restart=on-failure, User=appuser. После systemctl daemon-reload и systemctl enable --now myapp сервис стартует при загрузке.

cron — это служба, выполняющая задания по расписанию. Расписание задают в файле crontab пятью полями: минута, час, день месяца, месяц, день недели, и шестым — команда.

Пример: 0 3 * * * /usr/local/bin/backup.sh — каждый день в 3:00. Управление: crontab -e (редактировать своё расписание), crontab -l (показать).

Из практики: для своего пользователя — crontab -e. Для системных задач — /etc/cron.daily, /etc/cron.hourly или /etc/crontab. Логирование в cron часто скудное — лучше явно перенаправлять stdout/stderr в файл.

.bash_profile (или .profile) выполняется при логин-сессии — когда вы заходите по ssh или через консоль до запуска оболочки. .bashrc выполняется при каждом запуске интерактивной non-login оболочки (новый терминал в графическом сеансе).

Обычная практика — основные настройки писать в .bashrc, а в .bash_profile делать source ~/.bashrc, чтобы они применялись и при логине.

Из практики: alias, PS1, переменные окружения для разработки часто кладут в .bashrc. Системные переменные среды и однократная инициализация — в .bash_profile.

Переменная окружения — это пара имя=значение, доступная процессу. Передаются от родителя к ребёнку: при запуске процесса они наследуются.

Установка в текущей оболочке: VAR=value. Передача дочерним: export VAR=value. Просмотр всех: env или printenv. Передача одноразово: VAR=value command.

Из практики: PATH, HOME, USER — системные. APP_ENV, DB_URL, API_KEY — типичные приложения. В контейнерах их задают в Dockerfile (ENV) или при запуске (-e). На сервере — в unit-файле systemd.

tar — это архиватор без сжатия, обычно используется в связке с gzip/bzip2/xz. tar -czf archive.tar.gz dir/ — упаковать и сжать. tar -xzf archive.tar.gz — распаковать. -t — показать содержимое.

gzip сжимает один файл. zip — формат, привычный по Windows, поддерживает множество файлов внутри.

Из практики: для логов и каталогов чаще tar.gz. Для одного большого файла — gzip. Для совместимости с пользователями Windows — zip.

Сгенерировать пару ключей: ssh-keygen -t ed25519. Получатся ~/.ssh/id_ed25519 (приватный) и ~/.ssh/id_ed25519.pub (публичный). Скопировать публичный на сервер: ssh-copy-id user@host (или вручную в ~/.ssh/authorized_keys на сервере с правами 600).

После этого ssh user@host пускает без пароля. Приватный ключ — секрет, его никогда не передают по сети.

Из практики: для каждого устройства/проекта удобно делать отдельную пару. Парольная фраза + ssh-agent даёт удобство и безопасность.

xargs читает аргументы из stdin и подставляет их в указанную команду. Полезен, когда нужно превратить список (например, выход find) в аргументы для команды, которая не читает stdin.

Пример: find . -name '*.tmp' | xargs rm. С -0 и find ... -print0 — безопасно для имён с пробелами и переносами строк. С -n N — пакетами по N аргументов.

Из практики: xargs быстрее, чем find -exec ... \; для большого количества файлов, потому что собирает аргументы в один или несколько вызовов команды.

nohup запускает команду так, что она переживёт закрытие терминала: игнорирует SIGHUP и пишет вывод в nohup.out. Удобно для долгих задач.

screen и tmux — это терминальные мультиплексоры. Они создают сессии, в которых можно отсоединиться и потом вернуться (attach/detach), даже после разрыва ssh. tmux умеет ещё панели, плагины и считается более современным.

Из практики: для одноразового запуска — nohup. Для интерактивной работы по ssh, отсоединения и возвращения — tmux. Серверные приложения лучше запускать через systemd, а не через screen/tmux.

umask — это маска, которая ограничивает права создаваемых файлов и каталогов. Из стандартных прав 666 (для файлов) или 777 (для каталогов) вычитаются биты umask.

Типичный umask 022 даёт файлам 644 (-rw-r--r--), каталогам 755 (drwxr-xr-x). umask 077 — только владельцу.

Из практики: для чувствительных сред (бэкапы, секреты) ставят umask 077 в скриптах. В Dockerfile это меняется через ENV или явно перед командой.

lsof выводит список открытых файлов — а в Linux «всё файл», поэтому это и обычные файлы, и сокеты, и пайпы, и устройства.

Частые сценарии: lsof -i :8080 (кто держит порт), lsof -p PID (что открыл процесс), lsof | grep deleted (открытые удалённые файлы, которые не освобождают место).

Из практики: одна из первых утилит, к которой обращаются при «не могу удалить файл», «порт занят», «диск заполнен, но du ничего не показывает».

/proc — это виртуальная файловая система, отдающая информацию о ядре и процессах в виде файлов. На диске её нет, ядро формирует ответы на лету.

/proc/PID/ — папка каждого процесса (status, cmdline, fd, environ, limits). /proc/cpuinfo, /proc/meminfo, /proc/loadavg, /proc/net/* — системная информация.

Из практики: cat /proc/PID/environ покажет переменные окружения процесса. /proc/PID/fd — открытые файловые дескрипторы. Многие утилиты (ps, lsof) под капотом читают /proc.

Staging — это окружение, максимально близкое к проду по конфигурации, данным и интеграциям. На нём проводят финальное тестирование перед релизом.

Между dev (нестабильно, частые изменения) и prod (только пользователи). На staging можно безопасно ронять и пересобирать без вреда клиентам.

Из практики: качество staging-окружения напрямую влияет на качество релизов. Идеально, если оно автоматически синхронизируется по конфигу и почти по данным с продом (с маскированием PII).

Canary — выкатывание новой версии на небольшую долю пользователей (1-5%), мониторинг метрик, постепенное увеличение, или откат при проблемах.

Staged rollout — поэтапная раскатка по сегментам (география, версия клиента, процент пользователей). Принцип тот же: уменьшить blast radius проблем.

Из практики: QA участвует в выборе метрик, по которым принимается решение «продолжать или откатить»: ошибки, латентность, конверсия, жалобы в support.

bridge — сеть по умолчанию: каждый контейнер получает свой IP, проброс портов на хост через -p. host — контейнер использует сеть хоста напрямую, без изоляции и без -p.

host даёт минимальные накладные расходы, но теряется изоляция и нельзя запустить два сервиса на одном порту.

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

Docker context — это набор настроек подключения к Docker-движку: локальному, удалённому по SSH, к Kubernetes. Переключение через docker context use <name>.

Удобно, когда нужно работать с несколькими стендами — dev на ноутбуке, staging на удалённой машине.

Из практики: docker context create позволяет создать своё подключение. Списком — docker context ls.

При сборке Docker кеширует каждый слой и переиспользует, если инструкция и контекст не изменились. Это резко ускоряет повторные сборки.

Хитрость в порядке: положите менее изменчивые шаги выше (FROM, копирование package.json, install зависимостей), а часто меняющиеся (COPY исходного кода) — ниже.

Из практики: для Node.js — сначала COPY package*.json + npm ci, потом COPY .. Это даёт мгновенную сборку при правке кода без изменений зависимостей.

BuildKit — современный движок сборки в Docker. Параллельная сборка независимых stage, продвинутый кеш (cache mount, secret mount), SBOM, удобные ошибки.

Включается переменной DOCKER_BUILDKIT=1 или флагом --buildkit, а в Docker Desktop включён по умолчанию.

Из практики: для Multi-stage builds BuildKit ускоряет процесс заметно. Также можно безопасно передавать секреты в build (--mount=type=secret), не оставляя их в слоях.

Distroless — минимальный образ без shell, package manager и большинства утилит. Только runtime для приложения (например, JRE) и нужные библиотеки.

Преимущества: меньше attack surface (нет sh для подключения через RCE), меньше размер, меньше CVE.

Из практики: для production-сервисов distroless — отличный выбор. Минус: отладка сложнее, нет bash. Поэтому часто debug-вариант с shell держат отдельно.

Entrypoint script — это shell-скрипт, выполняющийся при старте контейнера и подготавливающий окружение перед запуском основного процесса (миграции, ожидание зависимостей, генерация конфига).

Заканчивается через exec "$@" — чтобы основной процесс получил PID 1 и сигналы шли ему.

Из практики: типовое применение — wait-for-db, миграции, заполнение шаблона конфига. ENTRYPOINT ["/app/entrypoint.sh"] CMD ["node", "server.js"].

Чистый Docker запускает контейнеры на одной машине. Для продакшена нужно: балансировка, авто-рестарт, скейлинг, обновления без даунтайма, секреты, кросс-хостовая сеть.

Orchestrator (Kubernetes, Nomad, Swarm) управляет кластером машин с контейнерами и решает эти задачи декларативно.

Из практики: для маленьких проектов хватает Docker Compose + reverse proxy. Когда сервисов десятки и нужна горизонтальная масштабируемость — Kubernetes.

Использовать .dockerignore, выбирать минимальный базовый образ, multi-stage build, объединять связанные RUN, использовать pinned версии, USER non-root, HEALTHCHECK, корректный CMD/ENTRYPOINT.

Также: не класть секреты в слои, использовать BuildKit secret/cache mounts, кешировать зависимости отдельно от кода.

Из практики: один раз настроенный Dockerfile по best practices экономит часы на сборках и снижает риски безопасности в проде.

Регулярно пересобирать образ с актуальной базой (FROM node:20-alpine с обновлениями), сканировать на CVE (trivy, grype, snyk), обновлять npm/pip-зависимости.

Автоматизация: Dependabot/Renovate создают PR при появлении новых версий. CI на каждый PR запускает сканер уязвимостей.

Из практики: образ, не пересобираемый месяцами, накапливает CVE. Правило — пересобирать минимум раз в месяц, даже если приложение не менялось.

Rolling update: поднять новую версию рядом со старой, дождаться healthcheck, переключить трафик, остановить старую. Blue-green: две полные среды, переключение между ними.

В Docker Swarm/Kubernetes это делается декларативно одной командой. В простом Docker Compose — нужна ручная оркестрация.

Из практики: важны хороший healthcheck (чтобы балансировщик понимал готовность) и совместимость старой и новой версии в момент перехода (особенно для БД-миграций).

sh — POSIX shell, базовый стандарт. bash — расширенный (Bash = Bourne Again Shell), с массивами, более удобными конструкциями. zsh — ещё современнее, с автодополнением, плагинами (oh-my-zsh).

Скрипты с #!/bin/sh — переносимые. С #!/bin/bash — могут использовать bash-isms (например, [[ ]] вместо [ ]).

Из практики: для скриптов, которые должны работать везде — sh. Для повседневной работы и сложных скриптов — bash или zsh.

Pipe (|) направляет stdout одной команды в stdin другой. Это позволяет собирать сложные обработки из простых утилит, по принципу UNIX.

Каждая утилита делает одну вещь хорошо, pipe соединяет их в конвейер.

Из практики: cat access.log | grep ERROR | awk '{print $1}' | sort | uniq -c | sort -rn — мощный one-liner для топа IP с ошибками.

Каждая программа возвращает exit code (0-255). 0 — успех, не-ноль — ошибка. Доступен через $? в bash.

В скриптах: команда && следующая (выполнить если успешно), команда || альтернатива (если ошибка). set -e — упасть на первой ошибке.

Из практики: всегда возвращайте осмысленные коды из своих скриптов. CI-системы по ним определяют успех джобы.

Перед выполнением команды shell разворачивает аргументы: brace ({a,b,c} → a b c), tilde (~/), parameter ($VAR, ${VAR:-default}), command ($(cmd) или backticks), arithmetic ($((1+2))), word splitting, pathname (*.txt).

Порядок важен — например, command expansion происходит до word splitting.

Из практики: понимание expansion критично для написания корректных скриптов. Кавычки меняют поведение: "$VAR" не делает word splitting.

cgroups (control groups) — механизм ядра Linux для ограничения и учёта ресурсов (CPU, RAM, IO, network) для группы процессов.

На них построена изоляция контейнеров: Docker через runc создаёт cgroup для каждого контейнера и применяет лимиты.

Из практики: лимиты контейнера в docker run --memory=512m работают через cgroups. Для своих сервисов на голой машине можно применять systemd slices.

Namespaces — механизм ядра Linux для изоляции системных ресурсов. Виды: pid (свой набор PID), net (свой сетевой стек), mount (свои монтирования), user (свой UID), ipc, uts (hostname).

Контейнеры используют комбинацию namespaces, чтобы процесс думал, что он один на машине.

Из практики: понимание namespaces помогает осознать, что контейнер — это не VM, а изолированный процесс. PID 1 в контейнере = первый процесс в pid-namespace.

OOM (Out Of Memory) killer — механизм ядра: когда заканчивается RAM (и swap), ядро выбирает процесс и убивает его, чтобы освободить память.

Выбор по oom_score — обычно убивается процесс с самой большой памятью. Можно изменить приоритет через oom_score_adj.

Из практики: в логах /var/log/messages или journalctl видно «Out of memory: Killed process». В Docker контейнер с лимитом памяти убивается ядром при превышении, выходит со статусом 137.

strace показывает системные вызовы процесса в реальном времени. strace -p PID — подключиться к существующему. strace command — запустить и трассировать.

Применяют для отладки: какой файл не открывается, на каком syscall зависает, какие переменные окружения читает.

Из практики: спасает в ситуациях «приложение зависло, логов нет». -c даёт статистику syscall'ов, -e trace=network ограничивает по группе.

У каждого процесса есть лимит на открытые файлы (включая сокеты). По умолчанию 1024. Смотрят через ulimit -n или в /proc/PID/limits.

Поднимают через ulimit -n (для shell), /etc/security/limits.conf (постоянно), LimitNOFILE в unit-файле systemd.

Из практики: для серверов под нагрузкой 1024 мало — поднимают до десятков-сотен тысяч. Признак исчерпания — «Too many open files».

iptables — классический инструмент управления netfilter (фильтрация пакетов, NAT). Работает с правилами в таблицах: filter (INPUT/OUTPUT/FORWARD), nat, mangle.

Современная замена — nftables, более удобный синтаксис и единый интерфейс. Многие дистрибутивы переходят. В Kubernetes/Docker используется iptables/nftables для сетевой магии.

Из практики: тестировщик видит iptables в логах firewalls и при отладке сетевых проблем («почему пакет блокируется»). Прямые правки — задача админа.

docker stats показывает текущее использование ресурсов контейнерами: CPU%, MEM USAGE/LIMIT, MEM%, NET I/O, BLOCK I/O.

Обновляется в реальном времени. Не агрегирует по времени — для долгосрочного мониторинга нужны Prometheus, cAdvisor, etc.

Из практики: первый шаг при «контейнер тормозит» — docker stats. Видно сразу, кто ест ресурсы.

Docker Swarm — встроенный в Docker оркестратор. Проще Kubernetes, но менее функционален: rolling update, scaling, secrets, overlay-сеть между нодами.

Использует те же docker-compose файлы (с некоторыми изменениями) — низкий порог входа.

Из практики: для маленьких команд и простых сервисов Swarm может быть достаточно. Но индустрия консолидировалась на Kubernetes, и Swarm развивается медленно.

Контейнер — это процесс с изолированными namespaces (PID, NET, MNT, UTS, IPC, USER) и ограниченными ресурсами через cgroups (CPU, RAM, IO).

Namespaces изолируют видимость. Cgroups — ограничивают потребление. Это два разных механизма ядра Linux, вместе создающие контейнер.

Из практики: понимание разделения помогает дебажить — почему контейнер видит чужой процесс (namespace), почему он OOM-killed (cgroup).

docker secret — механизм Swarm для безопасной передачи секретов. Секрет хранится в зашифрованном виде, монтируется в контейнер как tmpfs-файл.

Compose без Swarm не поддерживает полноценные secrets — обычно используют env-переменные (хуже) или внешний secret manager (HashiCorp Vault, AWS Secrets Manager).

Из практики: для Kubernetes есть Secret-ресурс. В нашем мире best practice — внешние secret managers.

buildx — расширенный билдер на основе BuildKit. Поддерживает мультиплатформенную сборку (одной командой собрать для amd64 и arm64), кеш на удалённом storage, output типы (registry, oci, tar).

Особенно полезен для CI и для разработчиков на Apple Silicon — собрать образ под x86 на ARM-машине.

Из практики: для мультиплатформенных образов — обязателен. docker buildx build --platform linux/amd64,linux/arm64 --push .

COPY --from=<stage> копирует файлы из предыдущего stage. <stage> — имя (через AS name) или индекс. Также можно копировать из других образов: COPY --from=alpine:3.18 /etc/.

Это основа multi-stage build — собирать в одном stage, копировать артефакты в финальный минимальный.

Из практики: классический пример — golang build в первом stage, scratch + бинарь во втором. Образ < 10 МБ.

docker-compose.override.yml автоматически мержится с docker-compose.yml при запуске. Также можно указать несколько файлов через -f.

Удобно для разных окружений: базовый compose + override для dev/staging/prod.

Из практики: разделение «общая конфигурация + специфика среды» — стандартная практика. В .gitignore часто кладут override-файлы разработчиков.

Образ — это immutable шаблон, набор слоёв файловой системы + метаданные (CMD, ENV). Контейнер — это запущенный экземпляр образа с дополнительным write-слоем.

Образ существует в реестре или локально. Контейнер — на хосте, в running/exited/paused состоянии.

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

docker exec -it <container> <command> запускает новый процесс внутри уже работающего контейнера. Часто docker exec -it <c> bash — открыть оболочку для отладки.

Это новый процесс рядом с основным, не привязан к ENTRYPOINT.

Из практики: основной способ зайти внутрь контейнера для проверки. Для контейнеров без bash используют sh.

docker login <registry> авторизует у реестра. Без указания — Docker Hub. Сохраняет credentials в ~/.docker/config.json.

Для приватных реестров (ghcr.io, ECR, GAR) — нужна авторизация перед push/pull. В CI используются токены, иногда специальные хелперы (ecr login).

Из практики: для CI лучше короткоживущие токены, не пароли. Никогда не коммитьте config.json.

CI — Continuous Integration: автоматическая сборка и тестирование на каждый коммит. CD — Continuous Delivery (готовность к деплою) или Deployment (автоматический деплой).

QA: пишет автотесты, поддерживает их стабильность, отвечает за quality gates (не пускать в продакшен с failing-тестами), мониторит регрессии.

Из практики: цель CI/CD — чтобы изменение от коммита до прода занимало минуты, а не дни. Тесты — главное условие безопасности.

Grafana — open-source платформа для визуализации метрик. Подключается к Prometheus, InfluxDB, Elasticsearch, и многим другим. Создаёт дашборды с графиками, gauges, таблицами.

Также Grafana Loki — для логов, Tempo — для трасс, Mimir — для метрик.

Из практики: де-факто стандарт для мониторинга в SRE. QA смотрит дашборды, чтобы видеть здоровье системы и регрессии после релиза.

Sentry — система мониторинга ошибок в коде. Подключается SDK к приложению: автоматически ловит exceptions, группирует, показывает stack trace, environment, breadcrumbs.

Также: Sentry Performance — APM-функции, Releases — отслеживание по релизам, Source Maps — расшифровка minified кода.

Из практики: незаменимо для production-приложений. Без Sentry многие ошибки пользователей остаются неизвестными.

Системы CI/CD: GitHub Actions, GitLab CI, Jenkins, CircleCI, Bitbucket Pipelines, TeamCity.

Запускают pipeline на коммит/PR: сборка, тесты, деплой. Конфигурация в коде (yaml-файлы).

Из практики: для GitHub-проектов чаще GitHub Actions. Для self-hosted с большой кастомизацией — Jenkins. Bitbucket — для команд Atlassian-экосистемы.

Kubernetes (K8s) — оркестратор контейнеров для production. Сущности: Pod (минимальная единица — один или несколько контейнеров), Deployment (управление репликами), Service (сетевой адрес), Ingress (HTTP-маршрутизация), ConfigMap/Secret (настройки), Namespace (изоляция).

Декларативный подход: описываете желаемое состояние, K8s приводит систему к нему.

Из практики: становится стандартом для production. Большая кривая обучения, но даёт много возможностей.

Helm — пакетный менеджер для Kubernetes. Charts — шаблоны манифестов с параметрами (values.yaml). Можно установить готовое приложение одной командой.

Полезно: переиспользование, версионирование, разные окружения с разными values.

Из практики: для своих сервисов чаще делают свой chart. Для готовых решений (Postgres, Redis, monitoring) — chart-ы с artifacthub.io.

Continuous testing — практика выполнения тестов автоматически на каждый коммит/PR/деплой. Цель — мгновенная обратная связь о качестве.

Включает: pre-commit hooks, CI-pipeline, smoke в production, регулярные регрессии.

Из практики: тесты должны быть быстрыми и стабильными — иначе continuous testing превращается в boilerplate. Цель — feedback в течение минут.

Управление тестовыми окружениями: создание, поддержание актуальности, изоляция данных, синхронизация конфигов с продом.

Цель — чтобы тесты в окружении давали те же результаты, что и в проде.

Из практики: дорого, но окупается. Для крупных систем — отдельный человек/команда. На многих проектах автоматизация через IaC (Terraform) и Docker.

CI (Continuous Integration) — практика частого мерджа кода в общую ветку с автоматическими тестами и сборкой на каждый commit. Цель — рано находить интеграционные проблемы.

CD (Continuous Delivery / Deployment) — автоматическая доставка артефактов до прода. Delivery — до момента готовности к деплою (нажми кнопку). Deployment — автоматический деплой в прод после успешного pipeline.

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

Docker — упаковка приложения вместе с зависимостями в изолированный контейнер, который одинаково работает на любой машине с Docker. Решает «у меня работает».

Kubernetes — система оркестрации контейнеров: разворачивает, масштабирует, балансирует, перезапускает упавшие. Объекты: Pod (контейнер/группа), Deployment (управление версией), Service (сетевой адрес), Ingress (внешний доступ).

Из практики: аналитику не обязательно деплоить руками, но понимать смысл объектов (Pod, Service) полезно — это меняет, как обсуждать масштабируемость и доступность с командой.