DevOps разработчик МТС - Middle / Реальное собеседование.

10 июля 2025 г. · 70 мин. чтения

Сегодня мы разберем живое и местами спорное техническое интервью, в котором кандидат демонстрирует уверенную базу по сетям, Linux и контейнерам, но регулярно уходит в импровизацию и рассуждения вместо коротких точных формулировок. Диалог получается насыщенным: интервьюер глубоко копает в детали (от HTTP/ICMP до OOM Killer и cgroups), мягко поправляет неточности и показывает, как на реальных собеседованиях проверяется не только знание терминов, но и умение мыслить, спорить и аргументировать.

Вопрос 1. Распределить сетевые протоколы по уровням модели OSI от нижнего к верхнему.

Таймкод: 00:04:30

Ответ собеседника: неполный. Кандидат верно относит IP и ICMP к сетевому уровню, HTTP к прикладному, называет канальный и транспортный уровни, но не даёт полного и структурированного распределения всех протоколов по уровням.

Правильный ответ:

Модель OSI состоит из 7 уровней (снизу вверх), и каждый протокол работает на одном или нескольких уровнях. Важно не просто перечислить, но и понимать роль каждого уровня и типичные протоколы, которые на нем используются.

Физический уровень (Physical)
- Отвечает за передачу битов по физической среде: электрические, оптические, радиосигналы.
- Примеры:
  - Не протоколы в классическом смысле, а технологии/стандарты:
    - Ethernet (физическая часть)
    - DSL
    - Wi-Fi (радиоуровень)
    - Оптические стандарты (например, 100BASE-FX)
- В контексте интервью часто подчеркивают, что "чистых" протоколов здесь мало; это спецификации среды.
Канальный уровень (Data Link)
- Обеспечивает доставку кадров между соседними устройствами в пределах одного канала/сегмента сети.
- Функции: MAC-адресация, обнаружение и частично коррекция ошибок, управление доступом к среде.
- Примеры протоколов:
  - Ethernet (кадровый формат)
  - PPP (Point-to-Point Protocol)
  - HDLC
  - Frame Relay
  - VLAN (802.1Q)
  - ARP часто относят к "промежуточному" между канальным и сетевым, но ближе к низким уровням, так как работает с сопоставлением IP ↔ MAC.
Сетевой уровень (Network)
- Отвечает за маршрутизацию пакетов между сетями (end-to-end across multiple segments).
- Функции: логическая адресация, маршрутизация, фрагментация.
- Примеры протоколов:
  - IP (IPv4, IPv6)
  - ICMP (служебные сообщения: echo, unreachable и т.д.)
  - IGMP (для управления multicast-группами)
  - Маршрутизирующие протоколы:
    - OSPF
    - BGP
    - RIP
    - EIGRP (проприетарный)
- Важно: ICMP и IGMP работают "поверх" IP и логически относятся к сетевому уровню.
Транспортный уровень (Transport)
- Обеспечивает доставку данных между процессами: надёжность, упорядочивание, контроль перегрузки, мультиплексирование по портам.
- Примеры протоколов:
  - TCP (надёжный, с установлением соединения, контроль потока и перегрузки)
  - UDP (ненадёжный, без установления соединения, минимальные накладные расходы)
  - SCTP (менее распространён, но важен концептуально)
- Связь с разработкой: именно здесь живут порты, которые используем в HTTP-серверах на Go.
Сеансовый уровень (Session)
- Управление сессиями: установление, поддержание, завершение логических "сеансов" между приложениями.
- В классическом виде в интернете часто "размыт" между транспортным и прикладным уровнями.
- Примеры:
  - Некоторые реализации RPC
  - Диалоговые протоколы, механики поддержания сессий
- В реальной практике часто не выделяется явно, но концептуально важен.
Представительский уровень (Presentation)
- Форматирование и преобразование данных: кодирование, шифрование, сжатие.
- Примеры:
  - SSL/TLS (часто рассматривают как между транспортным и прикладным)
  - Кодеки, форматы сериализации (JSON, XML, Protobuf, ASN.1)
- В стеке TCP/IP эти функции обычно реализуются библиотеками и протоколами "поверх" транспорта.
Прикладной уровень (Application)
- Протоколы, с которыми взаимодействуют приложения напрямую.
- Примеры:
  - HTTP/HTTPS
  - DNS
  - FTP, SFTP
  - SMTP, IMAP, POP3
  - SSH
  - gRPC (поверх HTTP/2)
- Важно: прикладной уровень в OSI — это не "UI", а протоколы, используемые программами.

Примеры из практики для разработчика на Go:

HTTP-сервер:

Прикладной: HTTP
Транспортный: TCP
Сетевой: IP
Канальный/Физический: Ethernet/Wi-Fi

Пример простого HTTP-сервера на Go (наглядная связь уровней сверху вниз):

package main

import (
    "fmt"
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Hello, network stack!")
}

func main() {
    http.HandleFunc("/", handler)

    // Прикладной уровень: HTTP
    // Транспортный уровень: TCP (порт 8080)
    // Сетевой уровень: IP
    // Канальный/физический: Ethernet/Wi-Fi и т.д.
    log.Println("Starting server on :8080")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal(err)
    }
}

Ключевой момент для собеседования: уметь уверенно и без путаницы разложить протоколы по уровням, понимать роль IP/ICMP (сетевой), TCP/UDP (транспортный), HTTP/DNS (прикладной), Ethernet (канальный/физический), и осознавать, что модель OSI — концептуальная, а интернет-стек TCP/IP — практическая реализация с более компактным набором уровней.

Вопрос 2. Назвать типы блоков данных (PDU) на уровнях модели OSI, минимум на первых четырёх.

Таймкод: 00:06:20

Ответ собеседника: неправильный. Кандидат говорит, что не может ответить на вопрос.

Правильный ответ:

Для каждого уровня модели OSI используется свой термин для единицы данных (PDU — Protocol Data Unit). Минимум для первых четырёх уровней важно знать точно, так как это часто проверяют на собеседованиях, чтобы понять, насколько глубоко вы понимаете сетевой стек.

Основная цепочка снизу вверх:

Физический уровень (Physical)
- PDU: биты (bits)
- На этом уровне данные представлены просто как поток сигналов (электрических, оптических, радиосигналов), которые интерпретируются как 0/1.
- Здесь нет адресации и заголовков в привычном смысле, только физическая передача.
Канальный уровень (Data Link)
- PDU: кадр (frame)
- Кадр включает:
  - Заголовок канального уровня (например, MAC-адрес источника и назначения в Ethernet)
  - Полезную нагрузку (обычно пакет сетевого уровня, например IP)
  - Контрольную сумму (FCS/CRC)
- Ответственен за передачу между соседними узлами в рамках одного сегмента сети и обнаружение ошибок на линке.
Сетевой уровень (Network)
- PDU: пакет (packet)
- Пакет включает:
  - Заголовок сетевого уровня (IP-адреса источника и получателя, TTL, протокол и т.д.)
  - Полезную нагрузку (сегмент транспортного уровня)
- Обеспечивает маршрутизацию между сетями (end-to-end через несколько маршрутизаторов).
- Примеры: IPv4, IPv6 пакеты.
Транспортный уровень (Transport)
- PDU: сегмент (segment) для TCP, датаграмма (datagram) для UDP.
- Обычно в собеседованиях говорят:
  - TCP: segment
  - UDP: datagram
- Содержит:
  - Порты источника и назначения
  - Номера последовательности, флаги (для TCP)
  - Данные приложения
- Обеспечивает логическое соединение между процессами/сервисами, мультиплексирование по портам, надёжность (TCP), либо минимальные накладные расходы (UDP).

Далее по классике (для полноты картины):

Сеансовый уровень (Session)
- PDU: сообщение (message) или session PDU (формально, но редко используется в практике напрямую).
Представительский уровень (Presentation)
- PDU: данные (data) в терминах форматирования, кодирования, шифрования.
Прикладной уровень (Application)
- PDU: сообщение/запрос/ответ (message), в контексте конкретного протокола:
  - HTTP request/response
  - DNS query/response и т.д.

Важно понимать идею инкапсуляции:

Прикладной уровень формирует свое сообщение.
Транспортный уровень оборачивает его в сегмент/датаграмму.
Сетевой уровень оборачивает сегмент в IP-пакет.
Канальный уровень оборачивает пакет в кадр.
Физический уровень передает кадр в виде последовательности бит.

Пример связи этого с Go-кодом (концептуально):

Когда вы пишете:

conn, err := net.Dial("tcp", "example.com:80")
if err != nil {
    // обработка ошибки
}
defer conn.Close()

_, err = conn.Write([]byte("GET / HTTP/1.1\r\nHost: example.com\r\n\r\n"))

Логически происходит следующее:

Ваш HTTP-запрос — PDU прикладного уровня (HTTP message).
Он инкапсулируется в TCP-сегмент (транспортный уровень).
TCP-сегмент инкапсулируется в IP-пакет (сетевой).
IP-пакет инкапсулируется в Ethernet-кадр (канальный).
Кадр уходит по сети в виде битов (физический).

На собеседовании достаточно уверенно назвать:

Физический: биты
Канальный: кадр (frame)
Сетевой: пакет (packet)
Транспортный: сегмент (TCP) / датаграмма (UDP)

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

Вопрос 3. Указать общее количество TCP-портов.

Таймкод: 00:06:50

Ответ собеседника: неполный. Сначала называет примерно 65 000, затем пытается уточнить, но даёт неверное число; правильное значение ему подсказывают.

Правильный ответ:

Общее количество TCP-портов — 65 536.

Диапазон портов:

Порты нумеруются 16-битным целым числом без знака.
Диапазон значений: от 0 до 65 535 включительно.
Итог: 65 536 возможных портов.

Классификация портов (важно знать на собеседовании):

0–1023 — well-known ports (системные, зарезервированные):
- 22 — SSH
- 25 — SMTP
- 53 — DNS (TCP/UDP)
- 80 — HTTP
- 443 — HTTPS
1024–49151 — registered ports:
- Используются различными приложениями/сервисами, регистрируются IANA.
49152–65535 — dynamic/private/ephemeral ports:
- Обычно используются для исходящих подключений клиентских приложений.

Применение в Go (практический контекст):

Когда вы поднимаете сервер:

ln, err := net.Listen("tcp", ":8080")
if err != nil {
    panic(err)
}
defer ln.Close()

Вы явно выбираете порт 8080 из диапазона registered.
При исходящих соединениях без явного указания локального порта ОС выбирает ephemeral-порт из верхнего диапазона.

Кандидату важно уверенно назвать:

"Всего 65 536 портов, диапазон 0–65535"
и понимать базовое разделение на well-known, registered и ephemeral.

Вопрос 4. Перечислить основные диапазоны TCP-портов и их назначение.

Таймкод: 00:07:17

Ответ собеседника: неполный. Упоминает системные, пользовательские и динамические порты, но не называет точные границы диапазонов и корректные термины.

Правильный ответ:

Для TCP (и аналогично для UDP) порты представляют собой 16-битное беззнаковое число в диапазоне 0–65535. IANA определяет три основных диапазона портов:

Диапазон 0–1023: well-known ports (system ports)
- Назначение:
  - Используются для стандартных, широко известных протоколов и сервисов.
  - Обычно требуют повышенных прав (root/admin) для привязки на сервере.
- Примеры:
  - 20/21 — FTP
  - 22 — SSH
  - 25 — SMTP
  - 53 — DNS (TCP/UDP)
  - 80 — HTTP
  - 110 — POP3
  - 143 — IMAP
  - 443 — HTTPS
- На собеседовании важно назвать корректный диапазон: 0–1023 и термин "well-known" или "system".
Диапазон 1024–49151: registered ports
- Назначение:
  - Порты, которые могут быть зарегистрированы под конкретные приложения/продукты.
  - Используются серверными и пользовательскими приложениями, когда не требуется системный well-known порт.
  - Не требуют привилегированных прав в большинстве ОС.
- Примеры:
  - 1433 — Microsoft SQL Server
  - 3306 — MySQL
  - 5432 — PostgreSQL
  - 6379 — Redis
  - 8080 — часто альтернативный порт для HTTP
- Термин: "registered ports" (зарегистрированные порты).
Диапазон 49152–65535: dynamic / private / ephemeral ports
- Назначение:
  - Временные (эфемерные) порты, автоматически выделяемые клиентским приложениям для исходящих соединений.
  - Используются для установления сессий:
    - Клиент → выбирает свободный ephemeral-порт.
    - Сервер → слушает well-known/registered порт.
- Пример сценария:
  - Браузер инициирует соединение к example.com:443.
  - ОС выбирает локальный порт, например 52734 (из эфемерного диапазона).
  - Соединение: client:52734 -> server:443.
- Важно: конкретные границы эфемерных портов могут варьироваться в зависимости от ОС и настроек, но стандарт IANA определяет 49152–65535.

Практический контекст для разработки на Go:

Серверное приложение (явный порт):

// Слушаем зарегистрированный порт 8080
ln, err := net.Listen("tcp", ":8080")
if err != nil {
    panic(err)
}
defer ln.Close()

Клиентское соединение (OS выбирает ephemeral):
```
conn, err := net.Dial("tcp", "example.com:443")
if err != nil {
    panic(err)
}
defer conn.Close()
```
В этом случае:
- Порт 443 — well-known (HTTPS) на стороне сервера.
- Локальный порт клиента — динамический/ephemeral из диапазона 49152–65535 (или системно настроенного).

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

0–1023 — well-known (system) ports
1024–49151 — registered ports
49152–65535 — dynamic/ephemeral ports

Вопрос 5. Объяснить, на каком протоколе основана утилита ping и как она используется для диагностики сетевых проблем.

Таймкод: 00:08:06

Ответ собеседника: правильный. Правильно указывает использование ICMP, описывает проверку доступности узла, влияние блокировки ICMP, применение ping как первого шага диагностики, оценку задержки и стабильности соединения, упоминает определение IP по доменному имени.

Правильный ответ:

Утилита ping основана на протоколе ICMP (Internet Control Message Protocol), который относится к сетевому уровню (находится поверх IP). ICMP не используется для передачи пользовательских данных; его задача — служебные сообщения, диагностика и сигнализация об ошибках.

Как работает ping:

Клиент отправляет ICMP Echo Request на целевой IP-адрес.
Целевой хост (если настроен и доступен) отвечает ICMP Echo Reply.
По времени между отправкой запроса и получением ответа рассчитывается RTT (round-trip time).
На основе серии запросов можно оценить:
- доступность узла;
- задержку (min/avg/max);
- стабильность соединения (джиттер);
- процент потерь пакетов.

Ключевые моменты для диагностики:

Если:
- Домен не резолвится → проблема с DNS.
- DNS отдал IP, но ping не отвечает:
  - Узел недоступен (down).
  - Проблемы маршрутизации.
  - Фильтрация/блокировка ICMP (firewall, security policy).
Поэтому:
- Отсутствие ответа на ping не всегда означает, что сервис "мертв" — ICMP может быть заблокирован, при этом HTTP/HTTPS и другие протоколы продолжают работать.
Ping — типичный первый шаг:
- Проверить базовую связность.
- Проверить, резолвится ли доменное имя: многие реализации ping показывают IP, к которому идет запрос.
- Оценить сетевые проблемы до более сложных инструментов (traceroute, mtr, tcpdump и т.д.).

Роль ICMP и типовые сообщения:

Echo Request / Echo Reply — основа ping.
Destination Unreachable
Time Exceeded
Redirect
Эти сообщения используются маршрутизаторами и хостами для сигнализации о проблемах доставки.

Минимальный практический пример диагностики (концептуально):

Проверка:
- ping example.com:
  - Если нет ответа:
    - nslookup example.com или dig example.com — проверить DNS.
    - ping <IP> — проверить напрямую IP.
    - Проверить firewall, VPN, маршруты.

Использование в контексте разработки:

Понимание того, что утилита ping не использует TCP/UDP:
- Нельзя "попрингуем порт 80" через стандартный ping — для этого используются другие инструменты (например, tcping, curl, nc), которые работают поверх TCP/UDP.
Для сервисов, доступность которых вы проверяете, важно:
- Не полагаться только на ICMP.
- Проверять именно прикладной протокол (HTTP, gRPC и т.п.).

Таким образом, корректное объяснение на собеседовании:

Ping использует ICMP (Echo Request/Reply) на сетевом уровне.
Применяется для:
- проверки базовой сетевой доступности;
- измерения задержки и потерь;
- первичной диагностики проблем маршрутизации и DNS.
И с оговоркой:
- отсутствие ответа на ping не гарантирует недоступность сервиса — ICMP может быть заблокирован.

Вопрос 6. Объяснить, что означает ответ ping Destination Host Unreachable и чем он отличается от request timeout.

Таймкод: 00:14:40

Ответ собеседника: правильный. После обсуждения уточняет, что Destination Host Unreachable указывает на отсутствие маршрута до узла назначения (проблему маршрутизации), а не просто общую недоступность сети, и отличает это от request timeout.

Правильный ответ:

Для корректной диагностики сети важно различать типы ошибок, которые возвращает ping (через ICMP).

Destination Host Unreachable:

Это сообщение формируется в виде ICMP Destination Unreachable (код зависит от причины).
Как правило, его отправляет:
- либо локальный хост (если не знает, куда дальше отправлять пакет),
- либо промежуточный маршрутизатор, который не может доставить пакет до следующего узла.
Типичные причины:
- Нет маршрута до подсети/хоста в таблице маршрутизации.
- Шлюз недоступен.
- Некорректная маска сети или gateway.
- Сегмент сети, где находится хост назначения, недостижим с точки зрения маршрутизаторов.
Семантика:
- Сеть в целом может быть доступна.
- Конкретный хост или подсеть недоступны по маршруту.
- Ошибка явная и приходит сразу (или почти сразу), а не по таймауту.

Request timeout (Request timed out / Ping timeout):

Ping не получает ни ICMP Echo Reply, ни ICMP-ошибку в пределах заданного времени.
Возможные причины:
- Пакеты теряются по пути (проблемы канала).
- Хост "лежит" (power off, OS down).
- ICMP-запросы или ответы блокируются firewall'ом (на хосте, на промежуточных узлах, на периметре).
- Перегруженность сети или сильная задержка.
Семантика:
- Это не специфичное сообщение протокола ICMP, а вывод утилиты ping: "я ничего не получил в ожидаемое время".
- В отличие от Destination Host Unreachable, нет явного сигнала от сети о причине.

Ключевые отличия:

Destination Host Unreachable:
- Явная ICMP-ошибка.
- Говорит: "Маршрут до хоста/подсети недоступен".
- Проблема на уровне маршрутизации или доступности конкретного сегмента.
Request timeout:
- Отсутствие любого ответа.
- Причина может быть неочевидна:
  - фильтрация ICMP,
  - падение хоста,
  - потеря пакетов,
  - временные проблемы.

Типичная логика диагностики:

Если сразу видим Destination Host Unreachable:
- Проверяем routing table, gateway, VPN, настройки подсети.
Если видим timeouts:
- Проверяем:
  - доступность IP другими средствами (например, TCP к нужному порту);
  - настройки firewall;
  - наличие packet loss (mtr/traceroute/tcpdump);
  - жив ли хост вообще.

Для разработчика и оператора важно:

Не делать упрощённый вывод "ping не работает → сервис мёртв".
Понимать:
- Destination Host Unreachable = структурная проблема маршрута или сегмента.
- Request timeout = отсутствие ответа, причины нужно уточнять дальше.

Вопрос 7. Описать структуру HTTP-запроса и HTTP-ответа и указать обязательные элементы.

Таймкод: 00:16:55

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

Правильный ответ:

HTTP — текстовый протокол уровня приложения, построенный по модели запрос–ответ. Важно чётко знать структуру как запросов, так и ответов, обязательные части и то, какие поля критичны для корректной работы.

Структура HTTP-запроса:

Запрос состоит из трех логических частей:

Стартовая строка (request line)
Заголовки (headers)
Пустая строка + тело (body) — опционально, зависит от метода и контекста.

Формат стартовой строки:

METHOD SP REQUEST-URI SP HTTP-VERSION CRLF

Примеры:

GET /index.html HTTP/1.1
POST /api/v1/users HTTP/1.1

Ключевые элементы:

METHOD:
- Основные методы:
  - GET — получить ресурс.
  - POST — передать данные на сервер.
  - PUT — создать/заменить ресурс.
  - PATCH — частичное изменение.
  - DELETE — удалить.
  - HEAD, OPTIONS и др.
- Метод определяет семантику, идемпотентность, наличие/назначение тела.
REQUEST-URI (path + optional query):
- Путь к ресурсу: /, /users, /api/v1/items?id=10.
- В HTTP/1.1 в запросе к прокси может быть полная форма URL (absolute URI).
HTTP-VERSION:
- Например: HTTP/1.0, HTTP/1.1, HTTP/2 (для HTTP/2 формат на уровне wire другой, но логическая модель сохраняется).
- В HTTP/1.1 версия в стартовой строке обязательна.

Обязательные заголовки (особенно для HTTP/1.1):

Host:
- Обязателен в HTTP/1.1.
- Указывает целевой хост: Host: example.com или Host: example.com:8080.
- Нужен для виртуального хостинга и маршрутизации на сервере.
Content-Length или Transfer-Encoding (для запросов с телом):
- Обязательны для корректного определения границ тела, если оно есть.
Другие важные (но не строго обязательные по протоколу):
- User-Agent — информация о клиенте.
- Accept, Accept-Encoding — предпочтения форматов.
- Content-Type — тип данных тела запроса (особенно важен для POST/PUT/PATCH).

Тело (body):

Не всегда присутствует:
- GET обычно без тела (хотя стандарт не запрещает, но это редко используется и может быть плохо поддержано).
- POST/PUT/PATCH чаще всего с телом.
Для тела:
- Content-Type определяет формат (например, application/json, application/x-www-form-urlencoded, multipart/form-data).
- Content-Length или chunked-передача определяют границы.

Минимальный корректный пример запроса HTTP/1.1:

GET / HTTP/1.1
Host: example.com
User-Agent: curl/8.0
Accept: */*

Структура HTTP-ответа:

Ответ также состоит из трех частей:

Стартовая строка (status line)
Заголовки
Пустая строка + тело (опционально, зависит от кода и протокола)

Формат статусной строки:

HTTP-VERSION SP STATUS-CODE SP REASON-PHRASE CRLF

Пример:

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
HTTP/1.1 503 Service Unavailable

Ключевые элементы:

HTTP-VERSION:
- Обычно HTTP/1.1 в текстовом виде.
STATUS-CODE:
- Трехзначный код, определяет результат обработки:
  - 1xx — информационные
  - 2xx — успех (200, 201, 204 и т.п.)
  - 3xx — редиректы (301, 302, 304 и т.д.)
  - 4xx — ошибки клиента (400, 401, 403, 404, 429 и т.д.)
  - 5xx — ошибки сервера (500, 502, 503, 504 и т.д.)
REASON-PHRASE:
- Человекочитаемое пояснение, формально часть протокола в HTTP/1.1, но семантически вторично.

Заголовки ответа (важные):

Date — время формирования ответа.
Server — информация о сервере (может быть скрыта по соображениям безопасности).
Content-Type — тип возвращаемого контента (обязателен, если есть тело с данными).
Content-Length или Transfer-Encoding — для определения длины тела.
Connection — управление соединением (например, keep-alive, close).
Cache-Control, ETag, Last-Modified — для кеширования.
Location — при редиректах (3xx).

Тело (body):

Может отсутствовать:
- Например, при 204 No Content, 304 Not Modified, некоторых 1xx.
При 200 OK обычно содержит представление ресурса (HTML, JSON, файл и т.д.).
Тип тела обязательно должен соответствовать заголовку Content-Type.

Минимальный пример успешного ответа:

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13

Hello, world!

Связь с Go:

При использовании стандартной библиотеки net/http многие детали формируются автоматически, но важно понимать, что происходит "под капотом".

Пример простого HTTP-сервера:

package main

import (
    "fmt"
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    // Чтение важных частей запроса
    fmt.Println("Method:", r.Method)
    fmt.Println("Path:", r.URL.Path)
    fmt.Println("Host:", r.Host)
    fmt.Println("User-Agent:", r.Header.Get("User-Agent"))

    // Формирование ответа
    w.Header().Set("Content-Type", "text/plain")
    w.WriteHeader(http.StatusOK)
    _, _ = w.Write([]byte("Hello, HTTP!\n"))
}

func main() {
    http.HandleFunc("/", handler)
    log.Println("Listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Здесь:

net/http сам формирует статусную строку, заголовки по умолчанию и т.д.
Мы явно управляем:
- статус-кодом (WriteHeader),
- заголовками (Header().Set),
- телом ответа (Write).

Ключевое, что стоит уверенно сказать на собеседовании:

Запрос:
- Стартовая строка: METHOD, путь (URI), версия.
- Обязательный Host в HTTP/1.1.
- Заголовки + опциональное тело.
Ответ:
- Статусная строка: версия, код, reason phrase.
- Заголовки.
- Опциональное тело (в зависимости от кода и протокола).
Понимать логику текстового формата, заголовков и роли Content-Type/Content-Length.

Вопрос 8. Перечислить версии HTTP и объяснить разницу между HTTP/1.0 и HTTP/1.1.

Таймкод: 00:21:19

Ответ собеседника: неполный. Упоминает версии 1.0, 1.1, 2, 3 и отмечает постоянные соединения в 1.1, но не раскрывает остальные ключевые отличия и не даёт достаточного контекста.

Правильный ответ:

На практике важно знать эволюцию HTTP и чётко понимать, чем HTTP/1.1 отличается от HTTP/1.0, так как это влияет на производительность, поведение кэша, работу соединений и архитектуру backend-сервисов.

Известные версии HTTP:

HTTP/0.9 (исторический, устаревший):
- Только метод GET.
- Без заголовков.
- Ответ — только тело (обычно HTML).
- Нет статус-кодов в привычном виде.
HTTP/1.0:
- Введены:
  - Стартовая строка ответа со статус-кодом.
  - Заголовки запросов и ответов.
- По умолчанию:
  - Одно соединение TCP на один запрос (no persistent connections).
  - Для следующего запроса — новое соединение.
- Ограниченная поддержка кэширования и Host.
HTTP/1.1:
- Долгое время — де-факто стандарт.
- Расширяет и исправляет HTTP/1.0.
- Важные улучшения:
  - По умолчанию persistent connections (keep-alive).
  - Обязательный заголовок Host.
  - Поддержка chunked transfer encoding.
  - Улучшения кэширования (Cache-Control и др.).
  - Дополнительные статус-коды и методы.
  - Возможность конвейеризации (HTTP pipelining, но в реальности почти не используется из-за проблем).
HTTP/2:
- Бинарный протокол (вместо текстового на wire-уровне).
- Мультиплексирование: несколько запросов/ответов в одном TCP-соединении без head-of-line blocking на уровне HTTP.
- Сжатие заголовков (HPACK).
- Приоритезация запросов.
- Семантика HTTP (методы, коды, заголовки) сохраняется, меняется только формат и транспорт.
HTTP/3:
- Работает поверх QUIC (UDP-based).
- Мультиплексирование без head-of-line blocking TCP.
- Встроенный TLS, улучшения латентности и устойчивости к потерям.
- Также сохраняет семантику HTTP/1.1/2 на уровне методов/статусов/заголовков.

Ключевые отличия HTTP/1.0 vs HTTP/1.1:

Постоянные соединения (Persistent connections)

HTTP/1.0:
- По умолчанию: одно соединение = один запрос/ответ.
- После ответа сервер закрывает соединение.
- Можно использовать Connection: keep-alive, но это не стандартизовано одинаково и поддержка не гарантирована.
- Итог: много TCP-handshake, высокая латентность, лишняя нагрузка.
HTTP/1.1:
- По умолчанию соединения persistent (keep-alive).
- Соединение используется для нескольких последовательных запросов.
- Закрытие соединения должно быть явным: Connection: close.
- Это существенно снижает накладные расходы:
  - меньше handshake,
  - выше производительность,
  - лучше подходит для загрузки страниц с множеством ресурсов.

Обязательный заголовок Host

HTTP/1.0:
- Host не обязателен.
- В эпоху, когда один IP = один сайт.
HTTP/1.1:
- Host обязателен в каждом запросе.
- Позволяет виртуальный хостинг:
  - несколько доменов на одном IP.
- Пример:
  - Host: example.com

Chunked transfer encoding

HTTP/1.0:
- Длина тела должна быть известна заранее (Content-Length), или соединение закрывается для обозначения конца.
HTTP/1.1:
- Введён chunked transfer encoding:
  - Позволяет отправлять данные по частям, не зная общей длины заранее.
  - Критично для стриминга, long-polling, динамической генерации ответов.
- Пример заголовка:
  - Transfer-Encoding: chunked

Управление кэшированием

HTTP/1.0:
- Базовая поддержка через Expires, Pragma.
HTTP/1.1:
- Введён Cache-Control:
  - Cache-Control: max-age=3600, no-cache, no-store и т.д.
- Более точный контроль поведения кэшей.

Дополнительные методы и статус-коды

HTTP/1.1:
- Методы: OPTIONS, PUT, DELETE, TRACE, CONNECT (формализованы).
- Больше статус-кодов и уточнённая семантика.
- Улучшения для прокси, кешей, ошибок.

Pipelining (теоретически)

HTTP/1.1 разрешает отправку нескольких запросов подряд без ожидания ответов (pipelining).
На практике почти не используется из-за:
- проблем с реализациями,
- head-of-line blocking.
HTTP/2 решает это корректно через бинарное мультиплексирование.

Связь с HTTP/2 и HTTP/3 (кратко и по сути):

HTTP/2:
- Решает ключевые проблемы HTTP/1.1 с множеством параллельных запросов:
  - один TCP,
  - мультиплексирование,
  - сжатие заголовков.
HTTP/3:
- Убирает зависимость от TCP, снижает задержки при потере пакетов и при установлении соединений.

Пример на Go (использование HTTP/1.1 по умолчанию):

package main

import (
    "io"
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    // Важные поля HTTP/1.1
    log.Println("Method:", r.Method)
    log.Println("Host:", r.Host)
    log.Println("Proto:", r.Proto) // Обычно "HTTP/1.1"

    w.Header().Set("Content-Type", "text/plain")
    w.WriteHeader(http.StatusOK)
    _, _ = io.WriteString(w, "Hello over HTTP/1.1 with keep-alive!\n")
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", handler)

    // net/http по умолчанию говорит на HTTP/1.1 (и может использовать HTTP/2 с TLS)
    log.Println("Listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", mux))
}

Краткий ответ, которого ожидают на собеседовании:

Версии: 0.9 (историческая), 1.0, 1.1, 2, 3.
Разница 1.0 vs 1.1:
- В 1.1:
  - persistent connections по умолчанию;
  - обязательный Host;
  - chunked transfer encoding;
  - улучшенное кэширование (Cache-Control);
  - формализованы дополнительные методы и статусы.
- Это даёт лучшую производительность и гибкость по сравнению с 1.0.

Вопрос 9. Назвать ключевые отличия HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3.

Таймкод: 00:21:19

Ответ собеседника: неполный. Упоминает persistent-соединения в HTTP/1.1, бинарность и оптимизации в HTTP/2, работу HTTP/3 поверх QUIC/UDP, но даёт частичное и местами неточное описание отличий.

Правильный ответ:

Нужно уметь не просто перечислить версии, а чётко понимать архитектурные отличия и последствия для производительности, масштабируемости и реализации backend-сервисов.

Краткий обзор версий:

HTTP/0.9 — исторический, только GET, без заголовков, устарел.
HTTP/1.0 — первые полноценные заголовки и статус-коды.
HTTP/1.1 — основной текстовый стандарт, долгое время доминировавший в вебе.
HTTP/2 — бинарный фрейминг, мультиплексирование поверх одного TCP-соединения.
HTTP/3 — HTTP поверх QUIC (UDP), решает проблемы TCP HOL blocking на транспорте.

Ключевые отличия по версиям:

HTTP/1.0

Текстовый протокол.
По умолчанию:
- Одно TCP-соединение = один HTTP-запрос.
- После ответа соединение закрывается.
Host необязателен:
- Плохо подходит для виртуального хостинга.
Ограниченные механизмы кэширования.
Нет стандартизованного chunked transfer encoding:
- Для обозначения конца тела часто используют закрытие соединения.

Вывод:

Большие накладные расходы на установку TCP (и TLS).
Неэффективен для страниц с множеством ресурсов.

HTTP/1.1

Основные улучшения (по сравнению с 1.0):

Persistent connections по умолчанию:
- Соединения не закрываются после каждого ответа.
- Используются повторно для нескольких запросов.
- Закрытие: Connection: close.
Обязательный заголовок Host:
- Позволяет несколько доменов на одном IP.
Chunked transfer encoding:
- Transfer-Encoding: chunked
- Позволяет стримить данные, не зная длины заранее.
Улучшенное кэширование:
- Cache-Control, ETag, If-None-Match, If-Modified-Since.
Дополнительные методы и статусы формализованы.
Pipelining (теоретически):
- Можно послать несколько запросов подряд без ожидания ответов.
- На практике почти не применяется из-за head-of-line blocking и проблем с реализациями.

Проблема HTTP/1.1:

Для реального параллелизма браузеры открывают несколько TCP-соединений к одному хосту.
Head-of-line blocking на уровне HTTP/1.1 + TCP делает доставку неэффективной при большом количестве ресурсов.

HTTP/2

Главная идея: сохранить семантику HTTP (методы, заголовки, коды), но радикально улучшить транспорт на уровне одного TCP-соединения.

Ключевые особенности:

Бинарный протокол:
- Не текстовый "по проводам".
- Данные разбиваются на фреймы.
- Проще парсинг, надёжнее протокол.
Мультиплексирование:
- Несколько параллельных потоков (streams) в рамках одного TCP-соединения.
- Запросы и ответы разделены на фреймы и перемешаны без конфликтов.
- Устраняет head-of-line blocking на уровне HTTP (но не на уровне TCP).
Сжатие заголовков:
- HPACK.
- Уменьшает overhead от повторяющихся заголовков (Cookie, User-Agent и т.п).
Приоритезация:
- Клиент может задавать приоритет потоков.
Совместимость:
- Семантика HTTP остаётся прежней.
- Часто используется поверх TLS (практически везде).

Ограничения:

Всё ещё один TCP-поток:
- Потеря одного пакета блокирует доставку последующих (TCP HOL blocking на уровне транспорта).
- Особенно болезненно на мобильных/нестабильных сетях.

HTTP/3

Реакция на ограничения HTTP/2/TCP.

Ключевые особенности:

Работает поверх QUIC:
- QUIC — протокол поверх UDP.
- Встроенный криптографический уровень (аналог TLS 1.3).
- Быстрая установка соединения (0-RTT/1-RTT).
Мультиплексирование без транспортного head-of-line blocking:
- Каждый поток логически независим.
- Потеря пакета в одном потоке не блокирует остальные.
Лучше поведение в реальных сетях:
- При смене IP (мобильные сети) соединение может сохраняться за счёт connection ID.
Сохраняется семантика HTTP:
- Методы, заголовки, коды те же.
Требует поддержки со стороны клиента, сервера и инфраструктуры (CDN, балансировщики и т.п.).

Сводка ключевых отличий по сути:

HTTP/1.0:
- Текстовый, одно соединение на запрос, нет нормальных persistent-соединений.
HTTP/1.1:
- Текстовый, keep-alive по умолчанию, Host обязателен, chunked encoding, лучше кэширование.
HTTP/2:
- Бинарный фрейминг.
- Мультиплексирование нескольких запросов в одном TCP-соединении.
- Сжатие заголовков (HPACK), приоритезация.
- Но всё ещё страдает от TCP head-of-line blocking.
HTTP/3:
- Поверх QUIC/UDP.
- Мультиплексирование без транспортного HOL blocking.
- Быстрый старт, лучше устойчивость к потерям и смене сети.

Пример практического восприятия в Go:

Стандартная библиотека net/http:

HTTP/1.1:
- Используется по умолчанию.
HTTP/2:
- Включается автоматически при использовании https (TLS) с сервером, который поддерживает h2.
HTTP/3:
- Требует дополнительных библиотек/реализаций (например, quic-go), пока не классика встроенного стека.

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

package main

import (
    "fmt"
    "net/http"
)

func main() {
    client := &http.Client{}
    resp, err := client.Get("https://www.google.com")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Println("Protocol:", resp.Proto) // Может быть HTTP/2.0, HTTP/1.1 и т.д.
}

Ожидаемый ответ на собеседовании (если кратко и по делу):

1.0 — нет keep-alive по умолчанию, простая модель, много соединений.
1.1 — persistent connections по умолчанию, Host обязателен, chunked, лучше кэширование.
2 — бинарный, мультиплексирование в одном TCP, сжатие заголовков.
3 — поверх QUIC/UDP, мультиплексирование без HOL blocking TCP, быстрее и устойчивее в реальных сетях.

Вопрос 10. Назвать команды для просмотра списка запущенных процессов в Linux.

Таймкод: 00:25:27

Ответ собеседника: правильный. Называет ps aux, top/htop и использование /proc для просмотра процессов.

Правильный ответ:

Для просмотра запущенных процессов в Linux используются несколько ключевых инструментов. Важно знать не только команды, но и их типичные режимы использования, так как это базовый навык при отладке, поиске утечек, зависаний и проблем с нагрузкой, в том числе для Go-сервисов.

Основные команды:

Классический способ разового просмотра состояния процессов.

Часто используемые варианты:

ps aux
- Показывает все процессы в системе (all users, BSD-стиль форматирования).
- Колонки включают:
  - USER, PID, %CPU, %MEM, VSZ, RSS, STAT, START, TIME, COMMAND.
ps -ef
- SysV-стиль вывода, также выводит все процессы.
Полезные примеры:
- Найти процессы Go-приложения:
  - ps aux | grep my-go-service
- Посмотреть дерево процессов:
  - ps auxf
  - или ps -ejH

Используется для:

Быстрой проверки, запущен ли процесс.
Снятия снимка состояния в конкретный момент.

Интерактивный просмотр процессов в реальном времени.

Команда: top
Возможности:
- Сортировка по CPU, памяти и др.
- Фильтрация, поиск по имени процесса.
- Завершение процессов (через k).
Подходит для:
- Диагностики нагрузки.
- Поиска процессов, потребляющих слишком много CPU/Memory.

htop

Улучшенная версия top (если установлена).

Команда: htop
Отличия от top:
- Цветной интерфейс.
- Удобная навигация, поиск, фильтрация.
- Древовидное представление процессов.
Удобен для:
- Визуального анализа нагрузки.
- Быстрой диагностики продакшн-сервера.

/proc

Виртуальная файловая система, представляющая состояние ядра и процессов.

ls /proc — список PID и служебных файлов.
/proc/<PID>/cmdline — команда запуска.
/proc/<PID>/status — информация о процессе.
/proc/<PID>/fd — открытые файловые дескрипторы.
/proc/<PID>/maps, /proc/<PID>/smaps — память процесса.

Использование:

Более детальная диагностика конкретного процесса.
Анализ утечек файловых дескрипторов, памяти, goroutines (через интеграцию с pprof для Go).

Дополнительно (как расширение кругозора):

pgrep — поиск процессов по имени:
- pgrep my-go-service
ps -C my-go-service — поиск по имени команды.
systemctl status <service> — для unit-ов systemd (не список всех процессов, но важный для сервисов).

Практический пример для Go-сервиса:

Предположим, у нас запущен бинарник orders-service.

Найти процесс:
```
ps aux | grep orders-service
```
Посмотреть нагрузку в динамике:
```
top
# или
htop
```
Проверить детали процесса по PID (например, 12345):
```
cat /proc/12345/cmdline
cat /proc/12345/status
ls -l /proc/12345/fd
```

На собеседовании достаточно уверенно назвать:

ps (ps aux / ps -ef)
top
htop
просмотр через /proc

и понимать их типичное применение для диагностики и сопровождения приложений.

Вопрос 11. Объяснить разницу между процессом и потоком в Linux с точки зрения изоляции и использования ресурсов.

Таймкод: 00:26:12

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

Правильный ответ:

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

Ключевые отличия:

Изоляция адресного пространства и ресурсов

Процесс:
- Имеет своё виртуальное адресное пространство.
- Память одного процесса недоступна напрямую из другого (без специальных механизмов: shared memory, IPC).
- Имеет собственный набор:
  - дескрипторов файлов,
  - таблицу страниц,
  - контекст выполнения (PID, сигналы, приоритеты),
  - окружение (environment variables),
  - текущий каталог и т.д.
- Ошибка работы с памятью (segfault) обычно "роняет" только этот процесс, не всю систему.
Поток (thread):
- Существует внутри процесса.
- Все потоки одного процесса разделяют:
  - общее адресное пространство,
  - глобальные переменные,
  - кучу (heap),
  - открытые файловые дескрипторы,
  - сокеты,
  - другие ресурсы процесса.
- У каждого потока свой:
  - стек,
  - набор регистров (контекст),
  - идентификатор (TID).
- Ошибка с памятью в одном потоке (гонки, запись не туда, use-after-free) может повредить общую память и уронить весь процесс.

Вывод:

Процесс — единица изоляции.
Поток — единица исполнения внутри одной изолированной области памяти.

Использование ресурсов

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

Модель исполнения в Linux

В Linux и процессы, и потоки реализованы через общую примитивную сущность ядра (task) с разными флагами разделения ресурсов (clone). Поэтому:

Потоки в Linux технически — "легковесные процессы", разделяющие часть контекста.
Инструменты типа ps/top могут показывать потоки как отдельные записи (в зависимости от опций).

Взаимодействие и синхронизация

Межпроцессное взаимодействие (IPC):
- Каналы (pipes), сокеты, shared memory, message queues, signals.
- Более формальные и "тяжёлые" механизмы.
Межпоточная синхронизация:
- Мьютексы, RW-мьютексы, семафоры, условные переменные, атомики.
- Работают внутри общего адресного пространства.
- Ошибки в синхронизации → гонки, дедлоки, сложно отлавливаемые баги.

Практический контекст для Go

Go использует собственную модель конкурентности — горутины, которые:

Не являются ни процессами, ни системными потоками напрямую.
Это легковесные "зелёные" потоки, мультиплексируемые рантаймом Go поверх пула системных потоков (M:N модель).
Все goroutine внутри одного процесса Go:
- разделяют память процесса,
- требуют корректной синхронизации (mutex, channels, atomics).
OS видит ограниченное число потоков (runtime управляет ими), а не миллионы горутин.

Пример: конкурентная обработка HTTP-запросов в Go:

package main

import (
    "fmt"
    "log"
    "net/http"
    "runtime"
)

func handler(w http.ResponseWriter, r *http.Request) {
    // Каждое соединение/запрос обрабатывается в отдельной goroutine.
    fmt.Fprintln(w, "Handled by goroutine")
}

func main() {
    log.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))

    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Здесь:

Один процесс.
Несколько потоков ОС (управляются рантаймом).
Тысячи/десятки тысяч goroutine, разделяющих память.
Типичные проблемы — гонки данных, а не "межпроцессная" изоляция.

Когда выбирать процессы, а когда потоки

Использовать процессы, когда:
- нужна изоляция (безопасность, отказоустойчивость, ограничение ресурсов через cgroups/namespace);
- части системы могут падать независимо (воркеры, sandbox).
Использовать потоки (или goroutine), когда:
- нужна высокая производительность и общее состояние;
- важна дешёвая конкуррентность внутри одного сервиса.

Краткая формулировка, ожидаемая на собеседовании:

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

Вопрос 12. Пояснить, что такое переключение контекста процесса (context switching) и почему многопоточность дешевле множества процессов.

Таймкод: 00:28:24

Ответ собеседника: неполный. С подсказками признаёт, что это переключение выполнения между процессами на CPU и что потоки легче, но не даёт чёткого определения и не раскрывает влияние на производительность.

Правильный ответ:

Переключение контекста (context switch) — это операция операционной системы по приостановке выполнения одного потока управления (процесса или потока) и возобновлению другого. Это базовый механизм планировщика, позволяющий:

делить процессорное время между множеством задач;
реализовывать многозадачность;
эффективно использовать несколько ядер CPU.

Что включает в себя переключение контекста:

При context switch ядро должно:

Сохранить состояние текущего потока/процесса:
- регистры CPU (включая указатель стека, счётчик команд);
- флаги;
- при необходимости часть сопутствующего состояния.
Загрузить состояние следующего потока/процесса:
- восстановить регистры;
- переключить стек;
- продолжить исполнение с нужной инструкции.
Если переключаемся между разными процессами:
- переключить адресное пространство:
  - изменить таблицу страниц (page tables);
  - это приводит к "засорению" TLB и кэшей;
- обновить связанные с процессом структуры ядра.

Это делает context switch:

не бесплатной операцией;
чувствительной к частоте переключений и уровню (поток vs процесс).

Почему многопоточность дешевле, чем множество процессов:

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

Общая память и ресурсы

Потоки:
- Разделяют:
  - адресное пространство,
  - кучу,
  - глобальные данные,
  - открытые файловые дескрипторы, сокеты.
- При переключении между потоками одного процесса не требуется менять таблицы страниц.
- Это:
  - дешевле по времени,
  - меньше бьёт по кэшам CPU и TLB.
Процессы:
- У каждого своё виртуальное адресное пространство.
- Переключение между процессами:
  - требует смены контекста памяти,
  - сильнее нарушает кэш-локальность,
  - обычно дороже по циклам CPU.

Стоимость создания и уничтожения

Новый процесс:
- fork/clone с отдельным адресным пространством.
- Настройка памяти, дескрипторов, метаданных.
- Существенно тяжелее.
Новый поток:
- Создаётся внутри существующего процесса.
- Требуется только стек, TCB (thread control block) и регистрация в планировщике.
- Быстрее и дешевле по памяти.

Взаимодействие между единицами исполнения

Потоки:
- Лёгкое взаимодействие через общую память.
- Используются мьютексы, условные переменные, атомики, каналы (в случае Go).
Процессы:
- IPC (sockets, pipes, shared memory, message queues).
- Сложнее и дороже в настройке и рантайм-стоимости.

Кэш-локальность и производительность

Переключение между потоками одного процесса чаще сохраняет полезные данные в кэшах:
- код, общие структуры, кучи.
При переключении процессов кэши чаще промахиваются:
- другой код, другие данные, другие таблицы страниц.
Это напрямую бьёт по latency и throughput.

Итого:

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

Контекст для Go:

Go использует модель:

множество goroutine;
ограниченное количество системных потоков;
планировщик Go мультиплексирует goroutine поверх потоков ОС.

Преимущества:

Создание goroutine гораздо дешевле создания OS-потока или процесса.
Переключения между goroutine внутри одного процесса частично управляются рантаймом и могут быть очень дешевыми.
Но всё равно, когда планировщик Go переключается между разными OS-потоками или ядро планирует потоки, мы упираемся в обычный context switch ОС.

Пример (упрощённый) конкурентной обработки в Go:

package main

import (
    "log"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    // Каждое соединение обрабатывается в отдельной goroutine (net/http делает это автоматически)
    w.Write([]byte("ok"))
}

func main() {
    http.HandleFunc("/", handler)
    log.Println("Listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Один процесс.
Несколько OS-потоков.
Много goroutine.
Context switch в основном между потоками, а внутри — дешёвые переключения goroutine.

Краткая формулировка, которая ожидается на собеседовании:

Context switching — это переключение CPU между задачами (процессами/потоками) с сохранением и восстановлением их состояния.
Переключение между процессами дороже:
- разное адресное пространство, переключение таблиц страниц, кэш-промахи.
Потоки легче:
- разделяют память и ресурсы, context switch внутри одного процесса дешевле.
Поэтому многопоточность (несколько потоков в одном процессе) обычно эффективнее, чем множество отдельных процессов при тех же задачах.

Вопрос 13. Объяснить разницу между системным вызовом и обычной функцией.

Таймкод: 00:31:27

Ответ собеседника: правильный. Говорит, что системный вызов — это обращение к ядру через специальный интерфейс для операций вроде запуска процессов и работы с сокетами; демонстрирует верное общее понимание, хотя не уточняет деталей реализации.

Правильный ответ:

При проектировании и отладке backend-систем важно ясно понимать границу "пользовательское пространство vs ядро" и что именно означает системный вызов по сравнению с обычной функцией.

Ключевое различие:

Обычная функция:
- Выполняется целиком в пространстве пользователя (user space).
- Работает только с теми ресурсами и памятью, которые уже доступны процессу.
- Не меняет режим работы CPU (остается в user mode).
- Не имеет прямого доступа к "привилегированным" операциям: управление устройствами, низкоуровневая работа с памятью, создание сокетов на уровне ядра и т.д.
- Примеры:
  - Собственные функции в Go.
  - Функции стандартной библиотеки, которые не лезут в ядро (например, работа со слайсами, строками, хеш-таблицами и т.п.).
Системный вызов (syscall):
- Это контролируемый вход из пользовательского пространства в ядро (kernel space).
- Позволяет приложению запросить у ядра выполнение "привилегированной" операции:
  - работа с файлами и сокетами;
  - управление процессами/потоками;
  - работа с памятью (mmap, brk);
  - таймеры, сигналы, IPC и т.д.
- Приводит к переключению режима процессора:
  - из user mode → в kernel mode (через спец. инструкцию: int 0x80, sysenter, syscall и т.п., в зависимости от архитектуры).
- Включает проверку прав, валидацию аргументов, работу с ядром и возврат результата обратно в user space.
- Дороже, чем вызов обычной функции:
  - context switch user ↔ kernel,
  - дополнительные проверки,
  - возможные побочные эффекты на кэш и конвейер CPU.

Важно: стандартные библиотеки часто "прячут" системные вызовы

На практике разработчик редко вызывает "голые" системные вызовы:

В C:
- Обычно используют glibc (или другую libc), которая:
  - предоставляет функции вроде open, read, write, socket, fork.
  - внутри уже вызывает соответствующие системные вызовы (sys_enter).
В Go:
- Пакеты os, net, syscall, x/sys/unix:
  - дают абстракции над системными вызовами.
  - например, os.Open, net.Dial, http.ListenAndServe внутри приводят к open/bind/listen/accept и т.д.
- Напрямую пакет syscall сейчас считается низкоуровневым и частично deprecated в пользу golang.org/x/sys.

Примеры в контексте Go:

Обычная функция (чисто в user space, без ядра):

func add(a, b int) int {
    return a + b
}

func main() {
    x := add(2, 3) // просто переход по адресу функции + операции с регистрами
    _ = x
}

Здесь нет взаимодействия с ядром.
Вызов максимально дешёвый.

Работа с файлом (через системные вызовы, но скрытые за стандартной библиотекой):

package main

import (
    "log"
    "os"
)

func main() {
    f, err := os.Open("data.txt") // внутри будет системный вызов open()
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close() // внутри будет close()

    buf := make([]byte, 128)
    _, err = f.Read(buf) // внутри read()
    if err != nil {
        log.Fatal(err)
    }
}

os.Open / File.Read / Close вызывают системные вызовы:
- open, read, close.
Каждый такой вызов:
- переходит в kernel mode,
- ядро работает с файловой системой/дескрипторами,
- возвращается в user space.

Прямой низкоуровневый вызов (пример, не для продакшена):

package main

import (
    "golang.org/x/sys/unix"
    "log"
)

func main() {
    fd, err := unix.Open("data.txt", unix.O_RDONLY, 0) // почти прямой syscall
    if err != nil {
        log.Fatal(err)
    }
    defer unix.Close(fd)
}

Здесь мы ближе к реальному системному вызову.

Почему это важно:

Производительность:
- Системные вызовы дороже обычных функций.
- Высокочастотные операции ввода-вывода, синхронизации и сетевого взаимодействия требуют аккуратного проектирования.
- Нужна минимизация количества syscall в "горячих" путях (batching, буферизация).
Безопасность и изоляция:
- Только ядро имеет полный доступ к ресурсам.
- Syscall — точка контроля (права, лимиты, sandbox, seccomp).
Отладка:
- При диагностике проблем полезно различать:
  - логика в коде (ошибки в алгоритмах, гонки),
  - ограничения/ошибки на уровне ядра (EMFILE, ENOMEM, permission denied, timeouts).

Краткая формулировка для собеседования:

Обычная функция — выполняется в user space, не требует перехода в ядро, работает только с уже доступной процессу памятью и данными.
Системный вызов — специальный механизм для обращения из user space в kernel space, чтобы выполнить привилегированные операции (файлы, сеть, процессы). Он дороже по стоимости и всегда проходит через ядро.

Вопрос 14. Объяснить разницу между системным вызовом и обычной функцией.

Таймкод: 00:34:17

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

Правильный ответ:

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

Обычная функция:
- Работает целиком в пользовательском пространстве (user space).
- Не меняет режим процессора.
- Не может напрямую выполнять привилегированные операции (работа с устройствами, управление памятью ядра, создание сокетов на низком уровне и т.п.).
- Это ваш код или код библиотек, который оперирует доступной процессу памятью и данными.
Системный вызов (syscall):
- Формальный интерфейс между пользовательским пространством и ядром.
- Вызывает переход в режим ядра (kernel mode) через специальную инструкцию.
- Позволяет запрашивать у ядра операции:
  - работа с файлами и сокетами;
  - создание процессов/потоков;
  - управление памятью;
  - IPC и др.
- Дороже, чем обычный вызов функции, из-за перехода user ↔ kernel и дополнительных проверок.

Пример в Go:

Обычная функция:

func sum(a, b int) int {
    return a + b
}

Вызов, ведущий к системному вызову (скрыт в stdlib):

f, err := os.Open("file.txt") // внутри — системный вызов open()

Ключевая мысль:

Любая операция, затрагивающая ресурсы ОС (файлы, сеть, процессы, таймеры на уровне ядра), в конечном счёте реализуется через системные вызовы.
Обычные функции работают "поверх" уже предоставленных ресурсов и не меняют глобальное состояние системы через ядро напрямую.

Вопрос 15. Назвать системный вызов для создания нового процесса в Unix/Linux.

Таймкод: 00:35:54

Ответ собеседника: правильный. Сначала путается, затем верно называет fork как базовый системный вызов для создания процесса.

Правильный ответ:

Базовый системный вызов для создания нового процесса в классических Unix-системах и Linux — это fork.

Кратко по сути:

fork:
- Создаёт новый процесс путём "раздвоения" текущего.
- Новый процесс называется дочерним (child), исходный — родительским (parent).
- Дочерний процесс получает:
  - копию (copy-on-write) адресного пространства родителя;
  - копии дескрипторов файлов;
  - почти всё состояние, кроме:
    - PID (уникальный),
    - некоторые поля (время запуска, статистика и т.п.).
- Возвращаемые значения:
  - в родительском процессе fork() возвращает PID дочернего процесса (> 0);
  - в дочернем процессе fork() возвращает 0;
  - при ошибке — отрицательное значение в родителе, дочерний не создаётся.

Типичный паттерн в C (для понимания семантики):

pid_t pid = fork();
if (pid == -1) {
    // ошибка
} else if (pid == 0) {
    // код дочернего процесса
} else {
    // код родительского процесса
}

Дальнейший запуск программы:

Часто после fork в дочернем процессе вызывают один из exec*-вызовов:
- execve, execl, execvp и т.п.
- Они заменяют текущее исполнение новым двоичным файлом (новой программой), сохраняя PID.
Комбинация fork + exec — классический способ запуска новых программ в Unix-подобных системах.

Альтернативы и уточнения для Linux:

В Linux системный вызов clone:
- Более низкоуровневый механизм, который лежит в основе:
  - реализации потоков (pthread),
  - контейнеров (namespaces, cgroups),
  - других форм "легковесных" процессов.
- Позволяет гибко указывать, какие ресурсы разделять (адресное пространство, файловые дескрипторы и т.д.).
vfork:
- Оптимизированный вариант (исторически) для сценария "fork сразу за которым exec".
- В современных Linux чаще fork+оптимизации ядра (copy-on-write) достаточно.

Пример в Go (концептуально):

Go-код напрямую fork обычно не вызывает, но под капотом:

Когда вы запускаете внешнюю команду:

package main

import (
    "log"
    "os/exec"
)

func main() {
    cmd := exec.Command("ls", "-la")
    output, err := cmd.CombinedOutput()
    if err != nil {
        log.Fatal(err)
    }
    log.Println(string(output))
}

Внутри exec.Command на Unix:
- используется последовательность, аналогичная fork+exec для создания нового процесса.
Это демонстрирует:
- системные вызовы низкоуровневые,
- прикладной код обычно работает через более высокоуровневые обёртки.

Вопрос 16. Перечислить основные сигналы в Unix/Linux, их назначение и возможность игнорирования.

Таймкод: 00:37:40

Ответ собеседника: правильный. Называет SIGTERM (корректное завершение), SIGKILL (принудительное завершение) и SIGINT (Ctrl+C), верно указывает, что SIGTERM можно обработать или игнорировать, а SIGKILL — нет.

Правильный ответ:

Сигналы в Unix/Linux — это механизм асинхронного уведомления процессов о событиях: запрос завершения, ошибка, таймер, изменение терминала и т.п. Понимание сигналов критично для корректного shutdown-сценария сервисов, graceful остановки, reload конфигурации и управления процессами в продакшене.

Ключевые моменты:

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

Основные сигналы и их назначение:

SIGINT (2)
- Источник:
  - Обычно посылается при нажатии Ctrl+C в терминале.
- Назначение:
  - Прервать работу процесса по инициативе пользователя.
- Обработка:
  - Можно перехватить.
  - Можно использовать для мягкой остановки (graceful shutdown).
- Игнорирование:
  - Можно проигнорировать (но это ухудшает UX и управление процессом).
SIGTERM (15)
- Источник:
  - Стандартный сигнал "корректного завершения":
    - kill <pid> без указания сигнала.
    - Системные менеджеры (systemd, Kubernetes) при остановке/перезапуске сервисов.
- Назначение:
  - Вежливая просьба завершиться.
- Обработка:
  - Обычно используется для graceful shutdown:
    - остановка приёма новых запросов,
    - завершение активных,
    - закрытие соединений,
    - сброс буферов, сохранение состояния.
- Игнорирование:
  - Можно обработать или даже проигнорировать.
  - Но игнорирование в продакшене — плохая практика: внешние системы ожидают, что процесс корректно завершится по SIGTERM.
SIGKILL (9)
- Источник:
  - kill -9 <pid>.
- Назначение:
  - Немедленное, безусловное уничтожение процесса ядром.
- Обработка:
  - Нельзя перехватить.
  - Нельзя переопределить.
  - Нельзя игнорировать.
- Последствия:
  - Процесс не успевает выполнить cleanup:
    - не закроет файлы,
    - не сбросит буферы,
    - не освободит ресурсы "логически" (хотя ядро зачистит память и дескрипторы).
- Использовать только при крайней необходимости (когда процесс не реагирует на SIGTERM).
SIGQUIT (3)
- Источник:
  - Обычно Ctrl+\ в терминале.
- Назначение:
  - "Срочное" завершение сдампом состояния (core dump).
- Обработка:
  - Можно перехватить.
- Полезен для:
  - диагностики: получить core dump для анализа.
SIGHUP (1)
- Историческое значение:
  - "Hangup" — разрыв соединения с терминалом.
- Современное использование:
  - Часто трактуется как сигнал "перечитай конфигурацию" или "перезапусти логирование".
- Обработка:
  - Обычно перехватывается демонами.
SIGSTOP, SIGTSTP, SIGCONT
- SIGSTOP:
  - Немедленная остановка процесса.
  - Нельзя перехватить или игнорировать.
- SIGTSTP:
  - "Stop" от терминала (Ctrl+Z), можно обработать.
- SIGCONT:
  - Продолжить выполнение остановленного процесса.
SIGALRM (14)
- Источник:
  - Таймеры (alarm()).
- Используется для:
  - прерывания по таймауту.
SIGSEGV, SIGBUS, SIGFPE и др.
- Сигналы ошибок:
  - SIGSEGV — ошибка доступа к памяти.
  - SIGFPE — арифметическая ошибка (деление на ноль и т.д.).
- Обычно означают баги и приводят к аварийному завершению.

Практическое применение в Go (graceful shutdown):

Типичный паттерн обработки SIGTERM/SIGINT в HTTP-сервисе:

package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    srv := &http.Server{Addr: ":8080"}

    go func() {
        log.Println("Starting server on :8080")
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("listen: %v", err)
        }
    }()

    // Ловим SIGINT и SIGTERM
    stop := make(chan os.Signal, 1)
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)

    <-stop // ждем сигнал

    log.Println("Shutting down gracefully...")

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    if err := srv.Shutdown(ctx); err != nil {
        log.Printf("Forced to shutdown: %v", err)
    }

    log.Println("Server stopped")
}

Здесь:

SIGINT (Ctrl+C) и SIGTERM (от orchestrator/systemd) инициируют контролируемую остановку.
SIGKILL, если будет послан, завершит процесс сразу, не дав выполнить Shutdown.

Краткая формулировка для собеседования:

Назвать:
- SIGINT — прерывание (Ctrl+C), можно обработать/игнорировать.
- SIGTERM — аккуратное завершение, рекомендуется обрабатывать для graceful shutdown.
- SIGKILL — жёсткое убийство, нельзя перехватить или игнорировать.
Понимать, что:
- большинство сигналов можно обработать или проигнорировать,
- SIGKILL и SIGSTOP — всегда исполняются ядром без участия процесса.

Вопрос 17. Объяснить назначение Out-Of-Memory Killer в Linux и принцип выбора процессов для завершения.

Таймкод: 00:40:25

Ответ собеседника: неполный. Верно указывает, что OOM Killer срабатывает при исчерпании памяти и завершает процессы, частично говорит о влиянии объёма памяти и привилегий, но путает с nice и не описывает корректно метрики OOM score и механизм выбора.

Правильный ответ:

Out-Of-Memory Killer (OOM Killer) — это механизм ядра Linux, который активируется, когда системе критически не хватает памяти и она не может удовлетворить очередной запрос на выделение памяти даже после попыток освободить ресурсы (drop cache, reclaim pages и т.п.). Его задача — спасти систему от полной неработоспособности (total stall / kernel panic), жертвуя одним или несколькими процессами.

Ключевая идея:

Когда физическая память + swap фактически исчерпаны, ядро должно:
- либо "умереть" (panic),
- либо принудительно завершить некоторые процессы.
OOM Killer выбирает "наиболее подходящую жертву" по набору критериев и посылает ей SIGKILL.

Важно: OOM Killer — это крайняя мера, симптом серьёзных проблем в приложении, конфигурации или лимитах (особенно актуально в контейнерах и Kubernetes).

Когда срабатывает OOM Killer:

Типичный сценарий:
- Приложения активно аллоцируют память.
- Система исчерпала свободную память и swap.
- Алгоритмы reclaim не могут освободить достаточный объём.
- Ядро не может удовлетворить очередной запрос (например, выделение страницы).
В этот момент:
- Ядро запускает механизм OOM.
- Вычисляет метрики для процессов.
- Выбирает один или несколько кандидатов для убийства.

Принцип выбора процесса: OOM score и связанные параметры

Основные сущности:

OOM score

Для каждого процесса ядро рассчитывает "оценку убиваемости" — oom_score.
Посмотреть можно через:
- /proc/<pid>/oom_score
Чем выше значение, тем вероятнее процесс будет выбран OOM Killer-ом.
На оценку влияют:
- Объём потребляемой памятью (RSS, shared, и пр.).
- Относительная "важность" процесса.
- Наличие/значения модификаторов (oom_score_adj).

OOM score adjustment: oom_score_adj

/proc/<pid>/oom_score_adj (значения от -1000 до +1000).
Позволяет явно подсказать ядру, насколько "ценен" или "жертвенен" процесс.
Интерпретация:
- -1000:
  - Практически запрет на убийство (почти "OOM-immune").
  - Так часто помечают критичные системные сервисы.
- 0:
  - Значение по умолчанию.
- Положительные значения:
  - Увеличивают вероятность быть убитым.
В контейнерных и оркестрационных средах (Kubernetes) этим параметром часто управляют автоматически.

Что ещё учитывается:

В классических реализациях (упрощённо):

Объём памяти:
- Чем больше памяти потребляет процесс, тем привлекательнее он как "жертва":
  - убийство одного жирного процесса может быстро освободить много памяти.
Тип процесса:
- Системные/привилегированные процессы, критичные для работы системы, обычно имеют низкий oom_score (либо явно занижен).
Родственные связи и роли:
- Иногда учитывается, является ли процесс сессией пользователя, демоном и т.п.

Важно:

nice и приоритет планировщика напрямую не определяют выбор жертвы OOM.
- nice — про планирование CPU, не про память.
- Хотя в некоторых версиях/патчах косвенное влияние возможно, на практике для собеседования важно: приоритет CPU не равен приоритету для OOM.
Точный алгоритм может немного отличаться между версиями ядра, но концепция одна:
- высокая память + высокий oom_score_adj = высокий шанс быть убитым.

Поведение в контейнерах и cgroups:

В современных системах память часто лимитируется через cgroups.
Если процесс внутри контейнера превышает лимит memory cgroup:
- OOM может быть локальным для cgroup:
  - ядро убьёт процессы внутри этой группы, не затрагивая систему целиком.
- Это критично для Kubernetes:
  - контейнер, превышающий limit, получает OOMKill;
  - Pod перезапускается согласно политикам.
Для диагностики:
- Смотрим логи kubelet, dmesg, события Kubernetes:
  - пометка OOMKilled.

Практический пример: Go-сервис под OOM

Типичный сценарий:

Утечка памяти (goroutine leak, неосвобождаемые структуры, кэш без лимита).
Рост RSS до лимита cgroup или всей машины.
Начинаются ошибки allocation.
OOM Killer убивает именно этот сервис:
- потому что он:
  - потребляет много памяти;
  - имеет высокий oom_score;
  - не помечен как особо важный.

Для анализа:

Проверяем:
- dmesg | grep -i kill
- journalctl -k | grep -i oom
- события в Kubernetes (если в кластере).
В Go:
- Используем pprof (net/http/pprof), метрики runtime, лимитируем кэши и очереди.

Пример установки oom_score_adj (низкоуровнево, не Go-код):

echo 500 > /proc/12345/oom_score_adj

Увеличиваем вероятность, что процесс с PID 12345 станет жертвой OOM.

Краткая формулировка для собеседования:

OOM Killer:
- Механизм ядра, который срабатывает при критической нехватке памяти.
- Цель — освободить память и спасти систему, убив один или несколько процессов.
Выбор процесса:
- На основе oom_score:
  - учитывает потребление памяти,
  - тип процесса,
  - модификатор oom_score_adj.
- SIGKILL выбранному процессу.
- Процессы с высоким потреблением памяти и без пониженного oom_score_adj — главные кандидаты.
Приоритет CPU (nice) и обычные пользовательские ожидания не являются главным критерием, важно именно поведение по памяти и конфигурация OOM-параметров.

Вопрос 18. Объяснить разницу между виртуальной и резидентной памятью процесса в Linux (поля VIRT и RES в top/htop).

Таймкод: 00:44:56

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

Правильный ответ:

Понимание разницы между виртуальной (VIRT) и резидентной (RES) памятью критично для диагностики утечек, оценки "настоящего" потребления памяти сервисом и интерпретации метрик в продакшене.

Основные определения:

Виртуальная память (VIRT в top/htop)

Виртуальная память процесса — это общий объём адресного пространства, который:

выделен или отображен (mapped) процессу;
включает:
- кучу (heap),
- стеки потоков,
- сегмент кода (text),
- статические данные (data/bss),
- memory-mapped файлы (включая shared libraries, mmap),
- анонимные выделения (malloc/new, в Go — runtime, heap),
- потенциально отрезервированные области, которые ещё не поддержаны физическими страницами.

Важно:

VIRT — это не "столько физической памяти занято".
Это сумма всех виртуальных регионов в адресном пространстве процесса.
Многие из этих регионов:
- могут быть разделяемыми (shared) с другими процессами;
- могут быть отложенно выделенными;
- могут никогда полностью не "материализоваться" в RAM.

Примеры:

Большой mmap файла на 1 ГБ:
- Увеличит VIRT примерно на 1 ГБ.
- Но фактически (RES) будут использоваться только прочитанные страницы.
Аллокатор или рантайм (включая Go) может резервировать память под арену:
- VIRT вырастет,
- но реальное использование физической памяти (RES) будет меньше, пока страницы не используются.

Резидентная память (RES в top/htop)

Резидентная память — это та часть виртуальной памяти процесса, которая в данный момент реально размещена в физической памяти (RAM) и привязана к страницам этого процесса.

Иначе:

RES = фактически загруженные в RAM страницы, относящиеся к этому процессу.
Это ближе всего к ответу на вопрос: "Сколько реальной памяти сейчас ест процесс?"

Нюансы:

RES включает:
- частные (private) страницы процесса;
- а также долю shared страниц (например, разделяемые библиотеки, shared memory), которые могут учитываться полностью в нескольких процессах при простом просмотре.
Поэтому простая сумма RES по всем процессам:
- переоценивает общую память (из-за shared).
Для оценки реального footprint конкретно важны:
- private memory,
- anonymous RSS,
- инструменты вроде smem, pmap, cgroups, метрики уровня контейнера.

Отношение к swap

Важный момент: VIRT ≠ "RAM + swap".

Swap — это механизм, куда ядро может выгружать содержимое некоторой части страниц из резидентного набора.
Если страница выгружена в swap:
- она не считается в RES;
- она всё ещё является частью виртуального адресного пространства процесса (VIRT);
- при обращении к ней произойдет page fault и загрузка обратно в RAM.
То есть:
- VIRT описывает логическое адресное пространство.
- RES — те страницы из этого пространства, которые реально находятся в RAM.
- Swap — возможное место хранения некоторых страниц, временно вытесненных из RAM.

Почему VIRT может быть очень большим, а RES относительно маленьким

Типичные причины:

Memory-mapped файлы (большие базы данных, логи, образы).
Lazy allocation:
- аллокатор или рантайм резервирует диапазоны адресов, но физические страницы выделяются по мере обращения.
Go, Java, базы данных:
- часто выделяют/резервируют арены памяти "с запасом".
- Это раздувает VIRT, но RES растёт плавно, по мере реального использования.

Практический пример интерпретации

Предположим, вы видите в top:

VIRT: 2.0g
RES: 300m

Интерпретация:

Процесс "имеет" до 2 ГБ виртуального адресного пространства:
- код, стеки, кучи, mmap, резерв.
Реально держит в RAM около 300 МБ.
Это не утечка только потому, что VIRT большой.
Смотреть нужно на RES (и, глубже, на private RSS) и на динамику.

Контекст для Go-приложений

В Go:

Рантайм управляет кучей, делает GC, может:
- резервировать виртуальную память под будущие аллокации;
- возвращать или не возвращать память ОС (зависит от версии Go, настроек, поведения аллокатора).
Поэтому:
- VIRT может быть выше ожидаемого.
- RES даёт более реалистичную оценку текущего потребления.
Для продвинутой диагностики:
- используйте pprof (heap, allocs),
- смотрите на GODEBUG=madvdontneed=1 и поведение возврата памяти,
- анализируйте метрики runtime.ReadMemStats.

Простой Go-пример для связи с пониманием:

package main

import (
    "fmt"
    "time"
)

func main() {
    var data [][]byte
    for i := 0; i < 1000; i++ {
        // Аллоцируем по 1 МБ
        b := make([]byte, 1<<20)
        data = append(data, b)
        time.Sleep(10 * time.Millisecond)
    }

    fmt.Println("Allocated ~1GB logically, watch top/htop...")
    time.Sleep(5 * time.Minute)
}

Возможная картина:

VIRT заметно вырастет.
RES может быть существенно меньше 1 ГБ:
- из-за оптимизаций, поведения аллокатора, возможного возврата памяти.

Краткая формулировка для собеседования:

Виртуальная память (VIRT):
- общий объём адресного пространства процесса (включая код, кучу, стеки, mmap, резерв),
- не равен напрямую использованию физической памяти.
Резидентная память (RES):
- часть виртуальной памяти, которая реально находится в RAM,
- ключевой показатель фактического потребления памяти.
Swap:
- хранит выгруженные страницы виртуальной памяти;
- страницы в swap остаются частью VIRT, но не входят в RES.

Вопрос 19. Объяснить, что такое резидентная память процесса и может ли её значение быть равно нулю.

Таймкод: 00:46:48

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

Правильный ответ:

Резидентная память (RSS, поле RES в top/htop) — это объём виртуальной памяти процесса, который в данный момент реально занят физическими страницами RAM и отображён в адресное пространство процесса.

Ключевые моменты:

RSS включает:
- код процесса;
- кучу;
- стеки потоков;
- загруженные динамические библиотеки;
- memory-mapped файлы и shared memory, те страницы которых реально загружены в RAM.
RSS не включает:
- страницы, выгруженные в swap;
- "просто зарезервированные" виртуальные области, к которым ещё не было обращений.

Таким образом:

Виртуальная память — "что процесс может адресовать".
Резидентная — "что прямо сейчас занимает физическую память".

Может ли резидентная память быть равна нулю?

Для "живого" процесса в нормальном состоянии — по сути нет.

Причины:

Чтобы процесс выполнялся, ему нужны хотя бы:
- несколько страниц кода;
- стек;
- базовые структуры рантайма;
Эти страницы должны быть в RAM в момент выполнения инструкций.
Даже если ядро агрессивно вымещает страницы в swap, при любой активной инструкции или обращении к памяти нужные страницы подгружаются обратно, и RSS > 0.

Где можно увидеть нули или почти нули:

Очень краткоживущие процессы:
- при просмотре через псевдо-снимок или инструменты, могут отображаться с нулевым или почти нулевым RSS из-за времени выборки/форматирования.
Зомби-процессы:
- зомби не имеют адресного пространства и не занимают память как обычные процессы;
- их RSS по сути нулевой, остаётся только запись в таблице процессов до wait() родителем.
Артефакты измерения:
- в некоторых утилитах/контейнерных окружениях можно увидеть странные значения из-за особенностей учёта или гонок чтения статистики.

Практически корректный ответ для собеседования:

Резидентная память — это реально используемая физическая память процесса (его часть виртуальной памяти, находящаяся в RAM).
У работающего процесса RSS не может быть строго ноль, поскольку исполнение требует хотя бы нескольких страниц в памяти.
Нулевые или близкие к нулю значения возможны только как артефакт (зомби, момент чтения статистики, особенности отчётности), но не как нормальное устойчивое состояние активного процесса.

Вопрос 20. Указать причину, по которой после удаления файла место на диске не освобождается.

Таймкод: 00:48:47

Ответ собеседника: правильный. Правильно указывает, что файл всё ещё открыт каким-то процессом, и предлагает найти этот процесс и завершить его.

Правильный ответ:

Основная причина, по которой после удаления файла (rm, unlink) место на диске не освобождается:

Файл всё ещё открыт хотя бы одним процессом.

Ключевая идея:

В Unix-подобных системах удаление файла через rm или unlink удаляет запись (link) из директории, но не сразу освобождает данные на диске.
Пока существует:
- хотя бы один открытый файловый дескриптор, указывающий на этот inode,
- или ещё есть другие жёсткие ссылки на него,
ядро продолжает хранить содержимое файла, и занимаемое место не возвращается в файловую систему.

Только когда:

удалены все directory entries (links), и
закрыты все файловые дескрипторы,

ядро может освободить место.

Типичный сценарий:

Лог-файл растёт (nginx, приложение, Go-сервис).
Вы делаете rm /var/log/app.log.
В ls файл не виден, но df показывает, что место не освободилось.
Причина:
- процесс по-прежнему пишет в файл, который теперь "безымянный":
  - link удален, но дескриптор ссылается на inode.
Решение:
- найти процесс и закрыть файл (перезапуск/ротация).

Как найти такой процесс:

Использовать lsof:
```
lsof | grep deleted
```
или
```
lsof /path/to/file
```
Использовать fuser:
```
fuser -v /path/to/mountpoint
```
В lsof вы увидите записи вида:
- /var/log/app.log (deleted)
рядом с PID процесса, который всё ещё держит этот файл открытым.

После закрытия файла процессом:

или после его завершения,
система освободит место автоматически.

Практический контекст для Go-сервисов и логов:

При лог-ротации нельзя просто rm текущий лог-файл, по которому продолжает писаться.
Правильный подход:
- использовать механизмы logrotate, которые:
  - делают copytruncate или mv + SIGHUP/reopen логов;
  - либо использовать встроенные ротаторы.
Если сервис пишет в файл напрямую:
- по переименованию и удалению старого файла нужно заставить процесс открыть новый файл (через сигнал или перезапуск).

Кратко для собеседования:

Место не освобождается, потому что удалён только directory entry, а файл остаётся открытым в одном или нескольких процессах.
Нужно найти этот процесс (lsof | grep deleted) и закрыть дескриптор или перезапустить процесс.

Вопрос 21. Объяснить разницу между жёсткой ссылкой и символической ссылкой в файловых системах.

Таймкод: 00:49:14

Ответ собеседника: правильный. Корректно объясняет: символическая ссылка указывает на путь (имя) файла и может ссылаться на ресурсы в других файловых системах; жёсткая ссылка указывает напрямую на inode в пределах одной файловой системы, увеличивает счётчик ссылок и не зависит от имени исходного файла.

Правильный ответ:

Жёсткие и символические ссылки — фундаментальная концепция Unix-подобных файловых систем. Правильное понимание важно для работы с логами, деплойментом, атомарными обновлениями бинарников, а также для корректной диагностики проблем с файлами.

Ключевые определения:

Жёсткая ссылка (hard link)

Это дополнительное имя (directory entry), которое напрямую указывает на тот же inode, что и исходный файл.
Все жёсткие ссылки на один и тот же inode:
- равноправны,
- "оригинального" файла как особого объекта нет.
У файла есть:
- inode (метаданные + указатели на данные),
- один или несколько directory entries (имён), указывающих на этот inode.

Свойства:

Работает только в пределах одной файловой системы:
- нельзя сделать hard link на файл, находящийся на другом разделе/диске.
При создании жёсткой ссылки:
- увеличивается link count in inode (счётчик ссылок).
При удалении одного из имён (rm):
- уменьшается link count;
- данные и inode остаются, пока счётчик ссылок > 0 или есть открытые дескрипторы.
Жёсткая ссылка указывает на inode, а не на путь:
- если переименовать или переместить один directory entry:
  - остальные ссылки продолжают указывать на те же данные.
Нельзя (обычно) создавать жёсткие ссылки на директории (за исключением специальных . и ..), чтобы избежать циклов и усложнения обхода.

Пример:

echo "data" > original.txt
ln original.txt copy.txt      # создаём жёсткую ссылку
ls -li

Вы увидите:

одинаковый inode у original.txt и copy.txt;
link count >= 2.

Удаление:

rm original.txt
cat copy.txt   # данные на месте

Символическая ссылка (symbolic link, symlink)

Это отдельный файл-объект особого типа, который содержит путь (строку) к целевому файлу или директории.
По сути: "ярлык" на имя, а не на inode напрямую.

Свойства:

Может ссылаться:
- на файлы и директории;
- на объекты в других файловых системах;
- на несуществующий путь (ломаная ссылка).
Разыменование происходит на уровне файловой системы:
- при обращении к symlink ОС читает путь внутри ссылки и пытается перейти по нему.
Если целевой файл удалён или переименован:
- symlink не обновляется автоматически;
- он становится "битым" (dangling symlink).
Символическая ссылка имеет собственный inode:
- со своими правами, владельцем, временем создания.
- Но права на symlink обычно игнорируются при доступе к цели (важны права цели).

Пример:

ln -s /var/log/app/current.log app.log.link
ls -l

app.log.link → /var/log/app/current.log (по пути).

Если удалить /var/log/app/current.log:

app.log.link останется, но будет указывать в никуда.

Сравнение по сути

Уровень ссылки:
- Hard link: на inode (данные).
- Symlink: на путь (имя).
Зависимость от исходного файла:
- Hard link:
  - нет "главного" файла;
  - все имена равноправны;
  - удаление одного имени не влияет на доступ через другие.
- Symlink:
  - зависит от пути;
  - переименование/перемещение цели ломает ссылку.
Ограничения:
- Hard link:
  - только в пределах одной файловой системы;
  - обычно нельзя на директории.
- Symlink:
  - можно на что угодно, включая директории и другие ФС;
  - может быть битым.
Использование:
- Hard link:
  - когда нужно несколько полных имён для одних и тех же данных.
  - полезно для бэкапов (с сохранением места), некоторых системных структур.
- Symlink:
  - для гибких "указателей":
    - current → current_xxx
    - /usr/bin/tool → /opt/tool/bin/tool
  - удобен для деплоя версий, переключения конфигураций.

Практический пример для деплоя бинарника Go:

Типичная схема:

ln -s /opt/app/releases/app-v3/app /usr/local/bin/app

Меняем версию:
- создаём новый релизный каталог,
- собираем новый бинарник,
- переключаем symlink на новый путь (атомарная операция),
- старый бинарник можно удалить после того, как перестанут использовать.
Здесь используется именно символическая ссылка:
- hard link был бы негибким, особенно при разных FS.

Краткое резюме для собеседования:

Жёсткая ссылка:
- ещё одно имя для того же inode;
- все ссылки равноправны;
- работает только в рамках одной ФС;
- данные живут, пока есть хотя бы одна ссылка или открытый дескриптор.
Символическая ссылка:
- отдельный файл, хранящий путь к цели;
- работает через имена, может ссылаться на другие ФС и директории;
- может стать битой, если цель изменена или удалена.

Вопрос 22. Определить, какие хосты с заданными IP и масками смогут обмениваться ICMP-пакетами друг с другом через L2-коммутатор.

Таймкод: 00:51:05

Ответ собеседника: неполный. Отмечает, что один хост в другой подсети и что /32 означает сеть из одного узла; правильно замечает, что первый и третий в одной сети, и что /32 изолирует хост. Однако путается в формулировках "кто с кем общается" и не даёт чёткого списка успешных и неуспешных ICMP-направлений.

Правильный ответ:

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

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

IP-адрес;
маска подсети.

Нужно определить, какие из них смогут "пинговать" друг друга (ICMP Echo/Reply), при условии:

только L2-коммутатор (нет маршрутизатора);
стандартное поведение IP-стека:
- хост посылает ARP-запрос только к адресам из своей подсети;
- для адресов вне своей подсети он попытается отправить пакет через шлюз (gateway), если он настроен; если нет — трафик не уйдёт корректно.

Ключевые принципы:

На чистом L2-уровне (switch):
- Коммутатор видит только MAC-адреса.
- Он не разделяет IP-сети, не маршрутизирует.
- Решение о том, отправлять ли ARP/ICMP, принимает сам хост, исходя из своей IP/маски.
Для успешного ICMP (ping) между двумя хостами без маршрутизатора необходимо:
- Оба хоста должны:
  - считать друг друга находящимися в одной IP-подсети;
  - то есть:
    - IP1 & MASK1 == IP2 & MASK1
    - и IP2 & MASK2 == IP1 & MASK2
  - (двусторонняя проверка: маршрутизация должна сходиться с обеих сторон).
- Тогда:
  - каждый будет отправлять ARP по адресу другого;
  - узнают MAC;
  - ICMP Echo и Echo Reply пойдут напрямую на L2.
Если один из хостов использует маску /32:
- /32 означает:
  - сеть состоит только из одного адреса — самого хоста.
- Такой хост:
  - никого, кроме самого себя, не считает "локальным".
  - Любой чужой IP трактуется как внешний, требующий отправки через шлюз.
- Если шлюз не настроен или отсутствует маршрутизатор:
  - он не сможет отправить ICMP непосредственно другим.
- Другие хосты:
  - могут считать /32-хост "локальным" (если их маска и адреса это позволяют),
  - попытаются отправить ему ARP.
  - Но /32-хост, даже получив пакет (на L2 он достижим), при формировании ответов ICMP будет считать отправителя "вне подсети" и пытаться слать ответ через gateway.
  - Без роутера корректного bidirectional общения не будет.
- Важно: для "реальной" двусторонней связи нужно совпадение логики с обеих сторон.
Хост в другой подсети:
- Если IP/маска хоста даёт network другой, чем у остальных:
  - он не будет слать ARP напрямую к ним;
  - он ожидает, что трафик пойдёт через настроенный шлюз.
- На голом L2-коммутаторе без маршрутизатора:
  - ICMP к другим подсетям не будет работать.

Типичный итог для подобных задач:

Хосты, у которых:
- совпадает сеть при применении их собственных масок друг к другу,
- и это совпадает взаимно, — смогут успешно обмениваться ICMP-пакетами (ping туда и обратно).
Хост с маской /32:
- фактически будет изолирован (если нет маршрутизатора и статических настроек).
Хост, находящийся в другой сети (по своей маске):
- не сможет обмениваться ICMP с остальными через один только L2-коммутатор.

Если опираться на описанный в вашем разборе пример:

"Первый и третий находятся в одной сети и могут полноценно общаться" — это корректно:
- Оба считают друг друга локальными,
- ARP проходит, ICMP Echo/Reply ходят в обе стороны.
"Хост с /32" — изолирован:
- Сам себя видит как единственного в сети;
- Без маршрутизатора не будет полноценного двустороннего обмена ICMP с другими.
"Хост в другой подсети" — не имеет L3-связности с остальными без роутера:
- Пинга между ним и остальными не будет.

Правильный, ожидаемый формат ответа на собеседовании:

Чётко:
- Выполнить для каждой пары: IP & mask → network.
- Проверить, совпадают ли сети с точки зрения обоих хостов.
Сформулировать:
- Какие конкретно хосты:
  - могут пинговать друг друга в обе стороны (двусторонняя связность);
  - какие — нет.
Указать:
- /32 → всегда только сам себе локален;
- другая подсеть → нужен маршрутизатор.

Это показывает понимание не только L2, но и поведения IP-стека, ARP и подсетей.

Вопрос 23. Объяснить, на каких механизмах в Linux основана контейнеризация и какова роль cgroups и namespaces.

Таймкод: 00:56:24

Ответ собеседника: неполный. Верно называет cgroups и namespaces как основу изоляции и ограничения ресурсов контейнеров, но не перечисляет конкретные типы namespaces, не раскрывает, какие ресурсы контролируются cgroups, и даёт только общее объяснение.

Правильный ответ:

Контейнеризация в Linux — это не "магия Docker", а комбинация уже существующих механизмов ядра, которые вместе дают:

изоляцию ресурсов,
ограничение потребления,
контролируемое окружение выполнения.

Ключевые механизмы:

namespaces — изоляция "того, что видит" процесс;
cgroups — контроль "сколько потребляет" процесс;
плюс:
- chroot/pivot_root,
- файловые системы (overlayfs, aufs и др.),
- capability-модель и LSM (AppArmor, SELinux) для безопасности.

Рассмотрим подробно.

Namespaces: логическая изоляция

Namespaces "разрезают" глобальные ресурсы системы так, чтобы процессы в одном namespace:

видели свою "локальную картину мира",
были изолированы от процессов и ресурсов в других namespace.

Основные типы namespaces (ключевые для контейнеров):

PID namespace
- Изолирует пространство идентификаторов процессов.
- Процесс внутри контейнера:
  - видит свои PID, начинающиеся с 1;
  - не видит процессы хоста и других контейнеров.
- Снаружи (на хосте) процесс виден с "реальным" PID.
- Это основа иллюзии "собственной машины".
UTS namespace
- Изолирует hostname и NIS domain name.
- Контейнер может иметь свой hostname, не влияя на хост.
Mount (MNT) namespace
- Изолирует таблицу монтирования.
- Контейнер видит свой набор файловых систем (rootfs, /proc, /dev и т.п.).
- Операции mount/unmount внутри контейнера не влияют на хост.
Network namespace
- Изолирует сетевой стек:
  - интерфейсы,
  - маршруты,
  - iptables/conntrack,
  - сокеты.
- Для контейнера можно:
  - создать отдельный набор интерфейсов (veth + bridge),
  - выдать собственный IP, маршруты, firewall.
- Это ключ к сетевой изоляции: каждый контейнер — как отдельная "машина" в сети.
IPC namespace
- Изолирует механизмы межпроцессного взаимодействия:
  - System V IPC (sem, shm, msg),
  - POSIX message queues.
- Контейнер не видит IPC-объекты других контейнеров/хоста.
User namespace
- Изолирует идентификаторы пользователей и групп.
- Позволяет:
  - маппить root внутри контейнера на непривилегированного пользователя на хосте.
- Это важнейший механизм безопасности:
  - процесс думает, что он root (UID 0),
  - но на хосте это, например, UID 100000 без реальных привилегий.
Cgroup namespace
- Изолирует видимость иерархий cgroups.
- Контейнер видит себе "локальное" дерево cgroups, не видит полную структуру хоста.

Совокупно namespaces дают изоляцию:

процессов,
сети,
файловой системы,
имён хоста,
пользователей,
IPC,
cgroups.

cgroups: контроль и лимитирование ресурсов

Control Groups (cgroups) — механизм ядра для:

ограничения,
учета (accounting),
приоритезации,
изоляции использования ресурсов для групп процессов.

Основные типы ресурсов, контролируемые cgroups (cgroups v1/в2, обобщённо):

Память (memory)
- Ограничение:
  - max использование RAM + (опционально) swap.
- Можно задать:
  - limit,
  - soft limit,
  - поведение при OOM (внутри cgroup).
- В контейнерах:
  - memory limit в Docker/Kubernetes → cgroup memory limit.
  - При превышении: OOM внутри контейнера, процесс помечается OOMKilled, система при этом жива.
CPU
- Контроль доли CPU:
  - cpu.shares — относительный приоритет.
  - cpu.cfs_quota_us / cpu.cfs_period_us (v1) или cpu.max (v2) — "сколько времени CPU можно съесть".
- В контейнерах:
  - --cpus, --cpu-shares, requests/limits в Kubernetes.
Block I/O (blkio / io)
- Ограничения на:
  - скорость чтения/записи,
  - IOPS.
- Важно для мульти-тенантных окружений.
PIDs
- Лимит на количество процессов/потоков в группе.
- Предотвращает fork-бомбы внутри контейнера.
Devices
- Управляет доступом к устройствам /dev.
- Разрешает/запрещает использование конкретных устройств.
Network (через tc, но связанно с cgroups)
- Возможно ограничение сетевой пропускной способности.

В cgroups v2 всё это объединено в единое иерархическое дерево с более строгой и понятной моделью.

Как это всё складывается в контейнер:

Когда вы запускаете контейнер (через Docker, containerd, CRI-O, runc и т.п.):

Создается набор namespaces:
- PID, NET, MNT, UTS, IPC, USER, CGROUP.
Для процесса контейнера:
- монтируется rootfs (часто на основе образа + overlayfs).
- настраиваются сетевые интерфейсы, маршруты.
- задаются лимиты через cgroups:
  - память, CPU, pids и т.п.

В результате процесс:

верит, что:
- он PID 1 в своей системе,
- у него свой hostname,
- свои интерфейсы,
- свой root-диск,
- свои пользователи.
на деле:
- это обычный процесс на хосте,
- помещённый в соответствующие namespaces и cgroups.

Практический взгляд для Go-разработчика:

Память и OOM:
- Если в Kubernetes задать:
  - memory limit 512Mi
- и Go-сервис съест больше:
  - cgroup memory limit сработает,
  - ядро запустит OOM внутри этой cgroup,
  - контейнер/Pod получит статус OOMKilled.
- Нужно:
  - следить за heap, pprof,
  - учитывать лимиты cgroups (runtime.ReadMemStats не знает их из коробки, но можно читать cgroup-файлы).
CPU:
- Ваш сервис может видеть "много" ядер, но cgroups ограничит реальное время CPU.
- Нужно правильно настраивать GOMAXPROCS:
  - современные версии Go учитывают cgroup-limits,
  - но важно понимать влияние на планирование.
Изоляция:
- Ошибки/паники в одном контейнере не ломают другие:
  - это просто процессы в разных namespaces/cgroups.
- Но ядро общее:
  - баги в драйверах/ядре — общие.

Краткая формулировка для собеседования:

Контейнеризация в Linux основана на:
- namespaces — логическая изоляция окружения (PID, сеть, FS, hostname, пользователи, IPC, cgroups),
- cgroups — лимитирование и учёт ресурсов (память, CPU, I/O, pids и др.),
- плюс файловые системы (overlayfs) и механизмы безопасности.
Namespaces отвечают за "что видит процесс".
Cgroups отвечают за "сколько он может съесть".
Вместе они дают контейнеры как лёгкую альтернативу полноценной виртуализации.

Вопрос 24. Перечислить, какие ресурсы можно ограничивать с помощью cgroups при работе контейнеров.

Таймкод: 00:58:44

Ответ собеседника: неполный. Упоминает CPU и память, неуверенно говорит о дисковом I/O и других ресурсах, без перечисления и детализации.

Правильный ответ:

Control Groups (cgroups) позволяют ограничивать, учитывать и приоритизировать потребление ресурсов группой процессов (включая контейнеры). Важно знать не только CPU и память, но и другие ключевые контролируемые ресурсы, особенно в контексте высоконагруженных систем, Kubernetes и multi-tenant среды.

Ниже — обобщённый список (с учётом cgroups v1/v2; точные контроллеры могут отличаться между версиями ядра, но концепция сохраняется).

Основные ресурсы, которые можно ограничивать с помощью cgroups:

Память (memory)

Что можно делать:

Ограничивать максимальный объём используемой памяти (RAM).
Ограничивать использование swap или полностью запрещать его.
Отслеживать использование памяти (RSS, cache, anon).
Реализовывать OOM-политику внутри cgroup:
- при превышении лимита — OOM Killer убивает процессы внутри группы, а не весь хост.

Применение в контейнерах:

Docker/Kubernetes:
- --memory, --memory-swap
- resources.limits.memory
Критично для Go:
- утечки или агрессивные кэши приведут к OOMKill внутри контейнера при превышении limit.

CPU (cpu, cpuacct / cpu in cgroup v2)

Что можно делать:

Ограничивать долю CPU:
- квоты (quota/period, в v2 — cpu.max),
- относительные shares (приоритет относительно других групп).
Считать использование CPU (accounting):
- время в user/system, по ядрам и т.п.

Применение:

Docker/Kubernetes:
- --cpus, --cpu-shares, --cpu-quota
- resources.requests/limits.cpu
Позволяет не допустить, чтобы один контейнер съел все ядра.

Block I/O (blkio / io)

Что можно делать:

Ограничивать скорость чтения/записи (bytes/s) для конкретных устройств.
Ограничивать IOPS.
Приоритизировать доступ к диску.

Применение:

Важно для:
- баз данных,
- шумных соседей на shared storage.
Не дать одному контейнеру "забить" диск для всех.

PIDs (pids)

Что можно делать:

Ограничивать количество процессов/потоков в cgroup.
Защищаться от fork-бомб и неконтролируемого размножения воркеров.

Применение:

В контейнерах:
- предотвращает ситуацию, когда один сервис создаёт столько процессов/потоков, что рушит весь узел.

Devices

Что можно делать:

Разрешать или запрещать доступ к конкретным устройствам:
- /dev/sda, /dev/null, /dev/random, GPU-устройства и т.п.
Управлять:
- правом читать/писать,
- создавать новые устройства.

Применение:

Безопасность контейнеров:
- контейнер не должен иметь доступ ко всем устройствам хоста.

Network (через net_cls / net_prio и интеграцию с tc)

В классическом виде:

net_cls:
- помечает пакеты классовыми ID для дальнейшего shaping/фильтрации.
net_prio:
- приоретизация сетевого трафика.
В связке с tc/iptables/ebpf:
- можно ограничивать и приоритизировать сетевой трафик для группы процессов.

В реальных системах:

Используется для QoS, ограничений bandwidth per container/tenant.

CPUSET

Что можно делать:

Привязка процессов к конкретным:
- CPU/ядрам,
- NUMA-нодам.
Контроль локальности памяти и CPU.

Применение:

На нагруженных серверах:
- выделять ядра под отдельные сервисы;
- уменьшать contention и улучшать cache locality.

Cgroup / misc (в cgroups v2)

Дополнительные контроллеры:
- unified интерфейс,
- более строгая модель иерархий,
- улучшенный учёт и управление.

Как это выглядит с точки зрения контейнера:

Когда вы запускаете контейнер:

Docker / containerd / CRI создаёт для него cgroup.
На эту cgroup навешиваются:
- лимиты памяти,
- квоты CPU,
- лимиты pids,
- blkio-ограничения и т.п.
Все процессы внутри контейнера:
- наследуют ограничения своей cgroup.

Пример (концептуально) для запуска контейнера:

docker run \
  --memory=512m \
  --cpus=1.5 \
  --pids-limit=256 \
  --device-read-bps /dev/sda:10mb \
  my-service:latest

За этим стоят:

memory cgroup — 512 МБ;
cpu cgroup — квоты ~1.5 CPU;
pids cgroup — максимум 256 процессов/потоков;
blkio cgroup — лимит на чтение с /dev/sda.

Краткая формулировка, ожидаемая на собеседовании:

С помощью cgroups можно ограничивать и учитывать:
- память (RAM/swap),
- CPU (квоты, приоритет),
- дисковый I/O (скорость, IOPS),
- количество процессов/потоков (pids),
- доступ к устройствам,
- сетевые параметры (через net_cls/net_prio и tc),
- привязку к CPU/NUMA (cpuset).
Эти механизмы лежат в основе ресурсных лимитов контейнеров в Docker/Kubernetes.

Вопрос 25. Назвать способы диагностики контейнера без доступа к shell внутри него.

Таймкод: 01:00:27

Ответ собеседника: правильный. Указывает использование docker exec для запуска команд без интерактивного shell и docker inspect (или аналогов рантайма) для просмотра конфигурации, сетевых настроек, томов и других параметров, подчёркивает творческий подход к отладке.

Правильный ответ:

В продакшене нередко нет полноценного shell внутри контейнера (distroless-образы, минимальные rootfs, ограничения безопасности). При этом контейнер нужно диагностировать: понять, жив ли процесс, какие у него ресурсы, сеть, конфигурация, монтирования, логи.

Ключевая идея: максимально использовать средства хоста, оркестратора и рантайма, не полагаясь на интерактивный bash внутри контейнера.

Основные способы диагностики без shell внутри:

Логи контейнера

Docker:
- docker logs <container>
- docker logs -f <container> — потоковое чтение.
- Важно: приложение должно писать в stdout/stderr.
Kubernetes:
- kubectl logs <pod> [-c container]
- kubectl logs -f <pod>

Используем для:

анализа паник, stacktrace Go-приложения;
проверки старта, конфигурации, ошибок подключения к БД/очередям;
вывода health-check’ов.

Инспекция метаданных и конфигурации

Docker:
- docker inspect <container>
  - информация о:
    - образе,
    - переменных окружения,
    - томах,
    - порт-маппингах,
    - сетях,
    - cgroups, лимитах ресурсов,
    - командной строке (Cmd, Entrypoint),
    - capabilities, security options.
Kubernetes:
- kubectl describe pod <pod>
- kubectl get pod <pod> -o yaml

Используем для:

проверки, с каким образом реально запущен контейнер;
какие env vars переданы (DB_URL, feature-флаги);
какие volume mounts, configMap, secret подключены;
какие лимиты CPU/Memory выставлены;
какие пробки (liveness/readiness) настроены и как они себя ведут.

Одноразовые команды без интерактивного shell

Даже если нет /bin/bash, можно:

Docker:
- docker exec <container> ps aux
- docker exec <container> ls /
- docker exec <container> /app/my-binary --version
- Если в образе только ваш Go-бинарник:
  - можно добавить диагностические флаги и вызывать их через exec.
Kubernetes:
- kubectl exec <pod> -- ps aux
- kubectl exec <pod> -- ls /
- kubectl exec <pod> -- /app/my-binary --debug-dump

Важно:

exec не требует обязательно bash:
- можно запускать любую доступную в контейнере программу.

Полезный приём для distroless:

иметь встроенный subcommand/флаг диагностики:
- myservice debug dump-config
- myservice debug health
- и вызывать его:
  - kubectl exec pod -- myservice debug dump-config

Проверка сетевого состояния снаружи

Со стороны хоста / других контейнеров:
- curl, wget к сервису: проверка HTTP/gRPC.
- nc/telnet — проверка открытых портов.
- ping (если релевантно).
- В Kubernetes:
  - kubectl exec <debug-pod> -- curl http://<service>:<port>/healthz
Инспекция сетей:
- Docker:
  - docker network ls
  - docker network inspect <network>
- Kubernetes:
  - проверка Service, Endpoints:
    - kubectl get svc
    - kubectl get endpoints

Используем для:

проверки, слушает ли приложение нужный порт;
доступен ли он по сервисному имени;
корректны ли network policies.

Диагностика ресурсов и ограничений

С хоста:

Найти PID основного процесса контейнера:
- docker inspect -f '{{.State.Pid}}' <container>
Посмотреть ресурсы:
- ls -l /proc/<pid>
- /proc/<pid>/cmdline
- /proc/<pid>/environ
- /proc/<pid>/limits
- /proc/<pid>/fd
- /proc/<pid>/smaps, /proc/<pid>/status
Проверить cgroups:
- /proc/<pid>/cgroup
- Сопоставить с лимитами по памяти/CPU.

В Kubernetes:

Node-level диагностика:
- kubectl describe node
- смотреть pressure (MemoryPressure, DiskPressure, PIDPressure).

Используем для:

анализа потребления памяти/CPU;
поиска утечек (роста RSS);
проверки, не упирается ли контейнер в лимит pids/memory.

Использование дополнительных "debug/sidecar" контейнеров

Если основной образ минимален:

В Kubernetes можно:
- запускать временный debug pod в той же сети/namespace:
  - kubectl run -it debug --image=busybox --restart=Never -- sh
- использовать ephemeral containers:
  - kubectl debug -it <pod> --image=busybox

Через них:

смотреть сеть, DNS, доступность сервисов;
проверять тома (если подключены в тот же pod);
делать curl/ps/ls и прочую диагностику.

Трассировка и профилирование снаружи

Для Go-сервисов:

Включить pprof/metrics endpoints (предпочтительно только на внутреннем интерфейсе/через auth):
- /debug/pprof/heap
- /debug/pprof/profile
- /metrics (Prometheus)

Снимать профили:

go tool pprof http://service:8080/debug/pprof/heap

Использовать:
- eBPF-инструменты,
- strace, lsof, tcpdump, perf,
- прикрепляясь к PID на хосте (с осторожностью и соблюдением безопасности).

Журналы и события оркестратора

Kubernetes:
- kubectl describe pod:
  - события, restarts, причины OOMKilled, CrashLoopBackOff.
Docker:
- docker ps -a
- docker inspect → статус, коды выхода.

Это помогает:

отличить падения по OOM от логических ошибок;
понять, когда и почему контейнер рестартует.

Краткая формулировка, ожидаемая на собеседовании:

Без shell внутри контейнера мы используем:
- логи (docker logs / kubectl logs),
- inspect/describe для конфигурации, env, томов, сетей, лимитов,
- одноразовые exec-команды (ps, ls, собственные debug-флаги бинарника),
- сетевую проверку снаружи (curl/nc из других контейнеров/хоста),
- анализ /proc и cgroups по PID контейнера,
- debug/sidecar/ephemeral контейнеры,
- pprof/metrics и события оркестратора.
То есть диагностика контейнеров должна опираться на инструменты окружения, а не на наличие интерактивного bash внутри образа.

Вопрос 26. Перечислить основные типы сетей Docker и кратко описать их назначение.

Таймкод: 01:04:07

Ответ собеседника: правильный. Называет bridge, host, none, overlay и macvlan; даёт корректные пояснения по назначению каждого типа.

Правильный ответ:

Docker-сети определяют, как контейнеры взаимодействуют друг с другом, с хостом и внешним миром. Понимание типов сетей критично при проектировании архитектуры, особенно для распределённых систем, сервис-мешей и безопасной сегментации.

Основные типы сетей в Docker:

bridge (по умолчанию для standalone Docker)

Описание:
- Частная виртуальная сеть на хосте.
- Контейнеры получают IP из этой сети и общаются друг с другом через виртуальный bridge.
- Вне сети доступны через:
  - NAT (masquerade) при исходящих соединениях;
  - port mapping (publish) для входящих запросов.
Особенности:
- Изоляция между разными bridge-сетями.
- Явно создаваемые пользовательские bridge-сети предпочтительнее default bridge:
  - удобнее именование, встроенный DNS между контейнерами.
Использование:
- Типичный сценарий:
  - web-контейнер, db-контейнер в одной bridge-сети,
  - db не публикуется наружу,
  - доступ к web — через -p 80:80.

Пример:

docker network create mynet
docker run -d --name api --network mynet my-api
docker run -d --name db --network mynet my-db
# api может обратиться к db по имени "db"

host

Описание:
- Контейнер использует сетевой стек хоста напрямую.
- Нет отдельного контейнерного IP, нет NAT/bridge.
- Порты процесса в контейнере = порты хоста.
Особенности:
- Меньше накладных расходов (нет NAT).
- Нет сетевой изоляции по отношению к хосту:
  - конфликты портов,
  - потенциально выше риски безопасности.
Использование:
- Высокопроизводительные сервисы,
- сервисы, чувствительные к сетевой латентности,
- некоторые сетевые агенты/демоны.

Пример:

docker run --network host my-api
# Сервис слушает, например, :8080 на хосте напрямую

none

Описание:
- У контейнера нет настроенной сети Docker.
- Только loopback (lo).
Особенности:
- Полная изоляция от сети:
  - нет доступа ни к хосту, ни к другим контейнерам, ни наружу.
- Можно вручную навесить свои интерфейсы (для спец-сценариев).
Использование:
- Жёстко изолированные задачи,
- тесты,
- контейнеры, к которым обращаются через shared volumes/IPC, а не по сети.

Пример:

docker run --network none my-job

overlay

Описание:
- Логическая сеть поверх нескольких Docker-хостов.
- Используется Docker Swarm и рядом решений для multi-host.
- Контейнеры на разных физических/виртуальных хостах получают IP в одной overlay-сети и могут общаться напрямую.
Особенности:
- Прозрачная маршрутизация между нодами кластера.
- Требует координации (key-value store, встроенный в Swarm/engine).
Использование:
- Распределённые приложения,
- микросервисы в кластере Docker Swarm,
- межхостовая коммуникация без ручной настройки туннелей.

macvlan

Описание:
- Каждому контейнеру назначается свой MAC-адрес и IP в физической сети.
- Для внешней сети контейнер выглядит как полноценный хост в L2-сегменте.
Особенности:
- Нет NAT: контейнеры доступны напрямую по своим IP.
- Требует аккуратной сетевой настройки:
  - поддержка со стороны свитчей,
  - учёт политики безопасности и ARP.
Использование:
- Интеграция с "голой" инфраструктурой:
  - когда контейнеры должны быть первоклассными участниками корпоративной сети;
  - для legacy-систем, привязанных к IP-диапазонам.
- NIDS/инструментарий, требующий прямого L2-доступа.

Краткое резюме, которого ожидают на собеседовании:

bridge:
- стандартная приватная сеть на одном хосте,
- контейнеры общаются друг с другом, наружу через NAT/port mapping.
host:
- общая сеть с хостом,
- минимум изоляции, нет отдельного IP.
none:
- без сети,
- максимум изоляции, только lo.
overlay:
- сеть поверх нескольких хостов,
- для кластеров и распределённых систем.
macvlan:
- контейнеры получают IP/MAC в физической сети,
- выглядят как отдельные машины без NAT.

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

Вопрос 1. Распределить сетевые протоколы по уровням модели OSI от нижнего к верхнему.​

Вопрос 2. Назвать типы блоков данных (PDU) на уровнях модели OSI, минимум на первых четырёх.​

Вопрос 3. Указать общее количество TCP-портов.​

Вопрос 4. Перечислить основные диапазоны TCP-портов и их назначение.​

Вопрос 5. Объяснить, на каком протоколе основана утилита ping и как она используется для диагностики сетевых проблем.​

Вопрос 6. Объяснить, что означает ответ ping Destination Host Unreachable и чем он отличается от request timeout.​

Вопрос 7. Описать структуру HTTP-запроса и HTTP-ответа и указать обязательные элементы.​

Вопрос 8. Перечислить версии HTTP и объяснить разницу между HTTP/1.0 и HTTP/1.1.​

Вопрос 9. Назвать ключевые отличия HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3.​

Вопрос 10. Назвать команды для просмотра списка запущенных процессов в Linux.​

Вопрос 11. Объяснить разницу между процессом и потоком в Linux с точки зрения изоляции и использования ресурсов.​

Вопрос 12. Пояснить, что такое переключение контекста процесса (context switching) и почему многопоточность дешевле множества процессов.​

Вопрос 13. Объяснить разницу между системным вызовом и обычной функцией.​

Вопрос 14. Объяснить разницу между системным вызовом и обычной функцией.​

Вопрос 15. Назвать системный вызов для создания нового процесса в Unix/Linux.​

Вопрос 16. Перечислить основные сигналы в Unix/Linux, их назначение и возможность игнорирования.​

Вопрос 17. Объяснить назначение Out-Of-Memory Killer в Linux и принцип выбора процессов для завершения.​

Вопрос 18. Объяснить разницу между виртуальной и резидентной памятью процесса в Linux (поля VIRT и RES в top/htop).​

Вопрос 19. Объяснить, что такое резидентная память процесса и может ли её значение быть равно нулю.​

Вопрос 20. Указать причину, по которой после удаления файла место на диске не освобождается.​

Вопрос 21. Объяснить разницу между жёсткой ссылкой и символической ссылкой в файловых системах.​

Вопрос 22. Определить, какие хосты с заданными IP и масками смогут обмениваться ICMP-пакетами друг с другом через L2-коммутатор.​

Вопрос 23. Объяснить, на каких механизмах в Linux основана контейнеризация и какова роль cgroups и namespaces.​

Вопрос 24. Перечислить, какие ресурсы можно ограничивать с помощью cgroups при работе контейнеров.​

Вопрос 25. Назвать способы диагностики контейнера без доступа к shell внутри него.​

Вопрос 26. Перечислить основные типы сетей Docker и кратко описать их назначение.​

Вопрос 1. Распределить сетевые протоколы по уровням модели OSI от нижнего к верхнему.

Вопрос 2. Назвать типы блоков данных (PDU) на уровнях модели OSI, минимум на первых четырёх.

Вопрос 3. Указать общее количество TCP-портов.

Вопрос 4. Перечислить основные диапазоны TCP-портов и их назначение.

Вопрос 5. Объяснить, на каком протоколе основана утилита ping и как она используется для диагностики сетевых проблем.

Вопрос 6. Объяснить, что означает ответ ping Destination Host Unreachable и чем он отличается от request timeout.

Вопрос 7. Описать структуру HTTP-запроса и HTTP-ответа и указать обязательные элементы.

Вопрос 8. Перечислить версии HTTP и объяснить разницу между HTTP/1.0 и HTTP/1.1.

Вопрос 9. Назвать ключевые отличия HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3.

Вопрос 10. Назвать команды для просмотра списка запущенных процессов в Linux.

Вопрос 11. Объяснить разницу между процессом и потоком в Linux с точки зрения изоляции и использования ресурсов.

Вопрос 12. Пояснить, что такое переключение контекста процесса (context switching) и почему многопоточность дешевле множества процессов.

Вопрос 13. Объяснить разницу между системным вызовом и обычной функцией.

Вопрос 14. Объяснить разницу между системным вызовом и обычной функцией.

Вопрос 15. Назвать системный вызов для создания нового процесса в Unix/Linux.

Вопрос 16. Перечислить основные сигналы в Unix/Linux, их назначение и возможность игнорирования.

Вопрос 17. Объяснить назначение Out-Of-Memory Killer в Linux и принцип выбора процессов для завершения.

Вопрос 18. Объяснить разницу между виртуальной и резидентной памятью процесса в Linux (поля VIRT и RES в top/htop).

Вопрос 19. Объяснить, что такое резидентная память процесса и может ли её значение быть равно нулю.

Вопрос 20. Указать причину, по которой после удаления файла место на диске не освобождается.

Вопрос 21. Объяснить разницу между жёсткой ссылкой и символической ссылкой в файловых системах.

Вопрос 22. Определить, какие хосты с заданными IP и масками смогут обмениваться ICMP-пакетами друг с другом через L2-коммутатор.

Вопрос 23. Объяснить, на каких механизмах в Linux основана контейнеризация и какова роль cgroups и namespaces.

Вопрос 24. Перечислить, какие ресурсы можно ограничивать с помощью cgroups при работе контейнеров.

Вопрос 25. Назвать способы диагностики контейнера без доступа к shell внутри него.

Вопрос 26. Перечислить основные типы сетей Docker и кратко описать их назначение.