DevOps - interview questions

🤔 Что такое SRE, чем отличается от DevOps? - SRE (Site Reliability Engineering) — инженерная практика от Google. - Фокус на доступности, стабильности, SLO, SLA. - Работает с ошибками, алертами, инцидентами. - DevOps — культурный подход, объединяющий разработку и эксплуатацию. SRE — это инженерная реализация DevOps, с акцентом на метрики и надёжность. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Какая компонента запускает под на ноде, какая отвечает за сеть? В Kubernetes разные компоненты отвечают за запуск подов и сетевые настройки. 🚩Какая компонента запускает под на ноде? (`kubelet`) Получает команды от kube-scheduler (назначение подов) Запускает контейнеры через Container Runtime (Docker, containerd, CRI-O) Следит за состоянием подов и перезапускает их при сбоях systemctl status kubelet Посмотреть логи kubelet journalctl -u kubelet -f 🚩Какая компонента отвечает за сеть? (CNI) Назначает IP-адреса подам Организует маршрутизацию трафика между подами и нодами Настраивает Network Policies (безопасность сети) Проверить работающие сетевые плагины kubectl get pods -n kube-system Вывод (если CNI работает нормально) NAME READY STATUS RESTARTS AGE calico-node-xyz 1/1 Running 2 3d Если CNI не работает, поды могут застрять в ContainerCreating kubectl get pods NAME READY STATUS RESTARTS AGE web-server 0/1 ContainerCreating 0 10m Ставь 👍 и забирай 📚 Базу знаний

🤔 Как решать проблему, если ваш коллега удалил /usr/bin/chmod, и нет ОС-донора? - Если chmod удалён, изменить права файла невозможно стандартным способом. - Возможные варианты: - Найти бинарник chmod в другой директории (например, в /bin, /sbin, /usr/local/bin). - Использовать busybox chmod, если busybox установлен. - Если есть root-доступ — попробовать выполнить через python, perl или bash: - python -c 'import os; os.chmod("file", 0o755)' - Или через find с -exec (если chmod встроен туда). - В крайнем случае — смонтировать диск на другой системе (если физически возможно). Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Какой командой можно показать все работающие процессы на Linux? Для отображения всех работающих процессов в Linux можно использовать несколько команд. Самые популярные из них: ps, top, htop и pgrep. Каждая из них имеет свои особенности. 🚩Команда `ps` ps выводит снимок (snapshot) текущих процессов в момент выполнения команды. 🟠`ps aux` Показывает все процессы, запущенные в системе, включая пользователей и системные демоны. ps aux 🟠`ps -ef` Альтернативный стиль вывода всех процессов с более детальной информацией. ps -ef 🚩Команда `top` top — интерактивная утилита для отображения всех запущенных процессов в реальном времени. Вывод обновляется автоматически. Запуск top 🚩Команда `htop` htop — более современная и удобная версия top. Требуется предварительная установка: sudo apt install htop # Для Ubuntu/Debian sudo yum install htop # Для CentOS/RHEL Запуск htop 🚩Команда `pgrep` pgrep используется для поиска процессов по имени, но с дополнительными опциями можно вывести все процессы. Пример pgrep -a "" 🚩Команда `systemctl` (для сервисов) Если вы хотите посмотреть системные службы systemctl list-units --type=service 🚩Какую команду выбрать? 🟠Для быстрого снимка ps aux. 🟠Для мониторинга в реальном времени top или htop. 🟠Для поиска конкретного процесса pgrep . Ставь 👍 и забирай 📚 Базу знаний

🤔 Как проверять, что запрошенные пару сервисов видят друг друга? 1. Ping – проверяет, доступен ли хост (ping ). 2. Traceroute (traceroute/mtr) – показывает маршрут пакетов. 3. Nslookup/Dig – проверка DNS-резолвинга (nslookup domain.com). 4. Telnet/NC – проверка доступности порта (nc -zv ). 5. Curl/Wget – проверка HTTP-доступа (curl -I Ссылка скрыта 6. Tcpdump/Wireshark – анализ сетевого трафика. 7. Kubernetes Debug (kubectl exec, logs, describe) – если сервисы в K8s. Если сервисы не видят друг друга, проверяют маршрутизацию, iptables, firewall, DNS. Ставь 👍 если знал ответ, 🔥 если нет Забирай 📚 Базу знаний

🤔 Как сделать rebase на main branch? Выполнить rebase на main в Git означает "перенести" ваши изменения поверх актуального состояния основной ветки (main). 🟠Переключаемся на вашу текущую ветку Допустим, вы работаете в ветке feature-branch: git checkout feature-branch 🟠Выполняем rebase на `main` Сначала убедимся, что main обновлена: git checkout main git pull origin main Теперь выполняем сам rebase: git checkout feature-branch git rebase main 🟠Разрешение конфликтов (если есть) Если у вас есть конфликты, Git остановит процесс и попросит их решить. Откройте файлы с конфликтами, исправьте их. Добавьте исправленные файлы: git add Продолжите rebase: git rebase --continue 🟠Обновление удалённого репозитория Если rebase прошёл успешно, вам нужно форсированно обновить удалённую ветку (так как история изменилась): git push origin feature-branch --force Ставь 👍 и забирай 📚 Базу знаний

🤔 Как диагностировать проблемы с локальным сервером который не отвечает на ping? Если сервер не пингуется, это не значит, что он не работает – проблема может быть в сети, настройках брандмауэра или самом сервере. 🚩Пошаговая диагностика 1⃣Проверить, действительно ли сервер включен Подойти к серверу и проверить: Горят ли индикаторы сети (LAN) на сервере? Реагирует ли на клавиатуру/монитор? Не завис ли сервер? (Может помочь Hard Reboot). 2⃣Проверить, есть ли связь на L2-уровне (MAC-адреса) Проверяем, видит ли наш компьютер MAC-адрес сервера через `arp`. Запрос ARP arp -a | grep 192.168.1.100 Если MAC-адрес есть → пакеты доходят до сервера, но он не отвечает. Если MAC-адреса нет → возможны проблемы с сетью (кабель, порт, VLAN, DHCP, статика). Дополнительно проверить соединение ethtool eth0 # Проверить состояние сетевого адаптера ip link show eth0 # Интерфейс должен быть UP 3⃣Проверить, отвечает ли сервер на другие запросы (SSH, HTTP, RDP) Если ping отключен (ICMP заблокирован брандмауэром), но сервер работает, попробуем другие протоколы. Пробуем зайти по SSH (если это Linux) ssh [email protected] Пробуем зайти по RDP (если это Windows) rdesktop 192.168.1.100 Пробуем зайти через HTTP (если там веб-сервер) curl -I Ссылка скрыта 4⃣Проверить сетевой интерфейс на сервере Подключаемся к серверу (если возможно) и проверяем, есть ли у него сеть. Проверяем IP-адрес сервера ip a или ifconfig -a Пробуем пропинговать шлюз с сервера ping 192.168.1.1 5⃣Проверить брандмауэр и iptables на сервере Если сервер не отвечает на ICMP, его может блокировать брандмауэр. Linux (firewalld, iptables, ufw) iptables -L -n | grep DROP # Проверяем правила iptables ufw status # Проверяем UFW (если используется) firewall-cmd --list-all # Проверяем firewalld Если ICMP запрещен → разрешаем его iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT ufw allow proto icmp firewall-cmd --add-icmp-block=echo-reply --permanent firewall-cmd --reload Windows (Проверить ICMP в брандмауэре Windows) netsh advfirewall firewall show rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" Если правило отключено → включаем netsh advfirewall firewall add rule name="ICMP Allow" protocol=icmpv4:8,any dir=in action=allow 6⃣Проверить маршрутизацию и сеть Если сервер и клиент находятся в разных VLAN или подсетях, проверяем маршрут. На клиенте traceroute 192.168.1.100 # Linux tracert 192.168.1.100 # Windows Проверить маршруты на сервере ip route show Если маршрут отсутствует → добавляем вручную ip route add 192.168.1.0/24 via 192.168.1.1 Ставь 👍 и забирай 📚 Базу знаний

🤔 Как в docker compose вместо yaml файла использовать json файл? Docker Compose поддерживает использование JSON-файлов вместо стандартного YAML-файла. Формат JSON полностью совместим с YAML, так как YAML является надмножеством JSON. Для этого достаточно создать JSON-файл с описанием конфигурации контейнеров и передать его с помощью опции -f. 🚩Шаги по использованию 🟠Создайте JSON-файл конфигурации Файл должен содержать описание сервисов в формате JSON. Например, вместо YAML version: "3.9" services: web: image: nginx ports: - "80:80" В формате JSON будет так { "version": "3.9", "services": { "web": { "image": "nginx", "ports": ["80:80"] } } } 🟠Запустите Docker Compose с этим файлом Используйте флаг -f, чтобы указать Docker Compose, какой файл использовать docker-compose -f docker-compose.json up 🟠Проверка работы Вы можете проверить статус контейнеров, как обычно: docker-compose -f docker-compose.json ps 🚩Почему использовать JSON? 🟠Совместимость JSON часто используется в API, CI/CD-пайплайнах и других инструментах, которые могут генерировать конфигурации автоматически. 🟠Простота обработки JSON легко парсить программно, что может быть полезно в скриптах и интеграциях. 🟠Стандартизация Некоторые команды и проекты могут предпочитать JSON как более строгий и распространенный формат. 🚩Пример использования 1⃣Создайте файл docker-compose.json { "version": "3.8", "services": { "app": { "image": "python:3.9", "volumes": ["./app:/app"], "working_dir": "/app", "command": "python app.py" } } } 2⃣Запустите docker-compose -f docker-compose.json up Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие коды ответа мы получаем от веб-сервера? Коды ответа (HTTP status codes) от веб-сервера представляют собой числовые коды, которые отправляются клиенту (обычно веб-браузеру) в ответ на его запрос. Эти коды помогают клиенту понять, что произошло с его запросом: был ли он успешен, произошла ли ошибка, требуется ли дополнительное действие и т.д. 🚩HTTP-коды ответа разделены на пять основных категорий: 🟠1xx (Информационные): Запрос принят, продолжается обработка. 100 Continue: Сервер получил начальную часть запроса, и клиент должен продолжать. 101 Switching Protocols: Сервер принимает запрос на изменение протокола. 🟠2xx (Успех): Запрос успешно обработан. 200 OK: Запрос успешно обработан, и сервер возвращает запрошенные данные. 201 Created: Запрос успешно выполнен, и в результате создан новый ресурс. 202 Accepted: Запрос принят для обработки, но обработка еще не завершена. 204 No Content: Запрос успешно выполнен, но сервер не возвращает никакого содержимого. 🟠3xx (Перенаправление): Для завершения обработки запроса требуется дальнейшее действие со стороны клиента. 301 Moved Permanently: Запрашиваемый ресурс был перемещен на новый постоянный URL. 302 Found: Запрашиваемый ресурс временно доступен по другому URL. 304 Not Modified: Запрашиваемый ресурс не изменился со времени последнего доступа (кэширование). 307 Temporary Redirect: Запрашиваемый ресурс временно доступен по другому URL. Клиент должен использовать исходный метод для нового запроса. 🟠4xx (Ошибка клиента): Ошибка в запросе клиента. 400 Bad Request: Сервер не может обработать запрос из-за неверного синтаксиса. 401 Unauthorized: Запрос требует аутентификации. 403 Forbidden: Сервер понял запрос, но отказывается его выполнять. 404 Not Found: Запрашиваемый ресурс не найден на сервере. 405 Method Not Allowed: Метод, указанный в запросе, не разрешен для запрашиваемого ресурса. 409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. 🟠5xx (Ошибка сервера): Ошибка на стороне сервера при попытке обработки запроса. 500 Internal Server Error: Общая ошибка сервера. Сервер не может выполнить запрос. 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса. 502 Bad Gateway: Сервер, действуя как шлюз или прокси, получил неверный ответ от вышестоящего сервера. 503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания. 504 Gateway Timeout: Сервер, действуя как шлюз или прокси, не дождался ответа от вышестоящего сервера. Ставь 👍 и забирай 📚 Базу знаний