[Unit]
Description=GOST-enabled Nginx Web Server
After=network-online.target

[Container]
Image=registry.corp.local/nginx-gost:latest
PublishPort=8080:80
Environment=TLS_MODE=strict
Volume=/srv/web:/usr/share/nginx/html:ro

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl start nginx-gost.service

# 1. Удаляем публичные мусорные репозитории Microsoft
winget source remove msstore
winget source remove winget

# 2. Добавляем корпоративный источник с авторизацией по сертификату
winget source add --name CorpRepo --arg https://repo.internal.local/api --type Microsoft.Rest --accept-source-agreements

# 3. Ставим нужный пакет тихо и без лишних вопросов
winget install Corp.ZabbixAgent --source CorpRepo --exact --silent --accept-package-agreements

# Логинимся через корпоративный OIDC
vault login -method=oidc

# Запрашиваем динамический доступ к роли read-only
vault read database/creds/pg-prod-readonly

# Вывод:
# Key                Value
# ---                -----
# lease_id           database/creds/pg-prod-readonly/gK9...
# lease_duration     15m
# password           A1b2C3d4_dynamic_hash_8f92
# username           v-oidc-adm_ivanov-pg-prod-read-1a2b3c

* Unix Sockets: Обмен данными идет напрямую через ядро Linux без участия сетевого стека (TCP/IP).
* Плюс: Меньше задержки (latency) и нагрузки на CPU.
* Минус: Работает только в рамках одной ОС. Если бэкенд переедет на соседний контейнер/сервер, придется переписывать конфиг.

* TCP (IP:Port): Данные проходят через весь сетевой стек, даже если бэкенд на том же хосте (loopback).
* Плюс: Легко масштабировать — просто меняем `127.0.0.1` на IP другого сервера.
* Вывод: В 2026-м для высоконагруженных локальных связок (Nginx + PHP-FPM/Python) используем сокеты, для микросервисов — TCP.

По умолчанию бэкенд видит IP того, кто к нему обратился — т.е. вашего Nginx. Чтобы передать адрес клиента, мы используем заголовок X-Forwarded-For или X-Real-IP.

* На стороне Nginx: прокидываем заголовок.
* На стороне бэкенда: используем модуль (например, `ngx_http_realip_module`), чтобы подменить адрес источника в логах и логике приложения.
* Важно:* В 2026-м обязательно настраиваем `set_real_ip_from`, чтобы доверять заголовкам только от своих балансировщиков, иначе любой школьник подменит свой IP в HTTP-заголовке.

Буферизация позволяет Nginx «впитать» ответ от бэкенда максимально быстро и отпустить воркер бэкенда заниматься следующими задачами.

* Если включено: Nginx забирает ответ в память (или на диск) и сам медленно отдает его клиенту с плохим 5G-интернетом. Бэкенд свободен.
* Если выключено (off): Бэкенд будет «висеть» открытым, пока клиент не скачает последний байт. При 1000 медленных клиентах ваш бэкенд захлебнется в процессах.
* Исключение: SSE (Server-Sent Events) или стриминг, где данные должны уходить клиенту мгновенно.

upstream backend_cluster {
    server unix:/run/php-fpm.sock weight=5; # Быстрый локальный сокет
    server 192.168.10.50:8080 backup;       # Резерв на случай падения
}

server {
    listen 443 ssl http2;
    server_name service.local;

    # Работа с реальными IP (только от доверенного шлюза)
    set_real_ip_from  10.0.0.1;
    real_ip_header    X-Forwarded-For;

    location / {
        proxy_pass http_backend_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # Защита от "залипания" бэкенда
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        proxy_buffering on;
        proxy_buffer_size 8k;
    }
}

Техническая суть:
Мы переходим на Btrfs с использованием алгоритма ZSTD. В отличие от старого доброго Gzip, ZSTD нативно поддерживается ядром и умеет в «умное» сжатие: если данные не сжимаются (например, уже зашифрованные бинарники), драйвер просто перестает тратить циклы CPU.

Под капотом: Используем механизм Copy-on-Write (CoW). При записи блок данных сначала сжимается в памяти, а затем атомарно пишется на диск. Это не только экономит до 40-60% места на типичных текстовых логах и конфигах, но и продлевает жизнь SSD, так как физических операций записи становится меньше.

# 1. Добавляем опции сжатия в fstab (уровень 3 — золотая середина для ARM)
# UUID=...  /var/log  btrfs  defaults,compress-force=zstd:3,noatime  0  0

# 2. Если раздел уже смонтирован, применяем на лету к существующим данным
btrfs filesystem defragment -r -czstd /var/log

# 3. Смотрим реальное потребление (df тут бессилен)
# Утилита compsize показывает магию чисел
compsize /var/log

# Вывод будет примерно такой:
# Processed 12405 files, 204856 blocks.
# Raw size: 12.4G
# Compressed size: 4.1G (33.06%)

Экономия дискового пространства в 3 раза без потери производительности (а на медленных дисках — даже с приростом, так как узкое место — шина данных, а не CPU). Плюс, мгновенные снапшоты позволяют откатить неудачное обновление системы за секунды.

Мы используем Windows LAPS (Local Administrator Password Solution), который теперь нативно интегрирован в ОС и Active Directory. Больше никаких сторонних костылей.

Как это работает: Каждая машина в домене генерирует уникальный, сложный пароль для своей учетки локального администратора. Этот пароль шифруется и сохраняется в защищенном атрибуте объекта компьютера в AD. Доступ к чтению этого атрибута жестко ограничен через ACL только для группы «Trusted Admins». Каждые 30 дней (или по вашему триггеру) пароль ротируется автоматически.

# 1. Проверяем состояние LAPS на конкретном сервере
Get-LapsDiagnostics -ComputerName "SRV-DB-01"

# 2. Получаем текущий пароль (требуются права доступа к зашифрованному атрибуту)
Get-LapsADPassword -Identity "SRV-DB-01" -AsClearText

# Вывод:
# ComputerName  Password            Expiration
# ------------  --------            ----------
# SRV-DB-01     $tr0ng_P@ss_2026!   10.04.2026 14:00:00

# 3. Принудительно заставляем сервер сменить пароль прямо сейчас
Set-LapsADPasswordExpiration -Identity "SRV-DB-01" -In 0

Полное исключение атаки типа Pass-the-Hash. Даже если злоумышленник вытащит хеш с одного сервера, он не сможет зайти под ним на другой. Админ больше не знает паролей — он получает их по требованию под присмотром аудита.

Техническая суть:
Используем eBPF (Extended Berkeley Packet Filter). Это технология, которая позволяет запускать микропрограммы прямо внутри ядра Linux без его пересборки или загрузки модулей.

Под капотом: Мы вешаем «хуки» на системные вызовы (kprobes) или функции в пользовательском пространстве (uprobes). eBPF-программа собирает статистику в реальном времени с нулевым влиянием на производительность. Вы видите всё: от задержек записи на диск конкретным процессом до того, какой именно микросервис рвет TCP-сессию.

# Запускаем однострочник, который строит гистограмму задержек I/O
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } 
             kretprobe:vfs_read /@start[tid]/ { 
                 $lat = (nsecs - @start[tid]) / 1000000; 
                 if ($lat > 10) { @[comm] = lhist($lat, 0, 100, 10); }
                 delete(@start[tid]); 
             }'

# На выходе получаем четкую картину:
# @[postgres]:
# [10, 20)      |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 152
# [20, 30)      |@@@@                                | 18
# [50, 60)      |@                                   | 2

Обнаруживаем «невидимые» проблемы: блокировки в ядре, микро-всплески трафика или утечки дескрипторов. В эпоху Cloud-Native и сложных распределенных систем это единственный способ не сойти с ума при поиске иголки в стоге сена.

Это классическая проблема MTU (Maximum Transmission Unit) и MSS (Maximum Segment Size). Когда мы упаковываем трафик в туннель (WireGuard, IPsec, GRE), добавляются дополнительные заголовки. Пакет становится больше стандартных 1500 байт и либо дропается, либо фрагментируется (что убивает производительность).
Если на промежуточном узле (или на DPI провайдера в 2026-м) запрещена фрагментация (флаг DF), пакет просто исчезнет в черной дыре. Решение: Нужно уменьшать MSS на интерфейсе туннеля (обычно до 1300-1400 байт), чтобы TCP-сессия сразу договаривалась о меньшем размере полезной нагрузки.

Load Average — это не только про CPU. Это очередь процессов в состоянии Running (R) и Uninterruptible Sleep (D). Если CPU свободен, значит, процессы «стоят в очереди» к дисковой подсистеме или ждут ответа от сети (состояние I/O Wait).
Разберем состояния подробнее:
High CPU Usage: Процессы в состоянии R. Решается оптимизацией кода или добавлением ядер.
High I/O Wait: Процессы в состоянии D. Причина: «умирающий» диск, перегруженная NFS-шара или проблемы с контроллером на ARM-сервере. Процессы отправили запрос на запись и замерли.
Zombie Processes: Состояние Z. Код не закрывает дочерние процессы. На LA влияют косвенно, но забивают таблицу процессов.

Для NVMe-накопителей в 2026 году классические атрибуты SMART не всегда информативны. Нужно использовать nvme-cli и смотреть на два критических параметра:
Percentage Used: Это прямой показатель износа ячеек. Если там 95%+, диск пора менять превентивно, даже если он работает идеально.
Available Spare: Это резервные блоки. Если этот показатель начал падать ниже 10% — значит, резервные ячейки кончаются, и контроллер скоро переведет диск в режим Read-only (защита данных при смерти).
Media and Data Integrity Errors: Любое число выше нуля — это повод для немедленной миграции данных.

# 1. Пытаемся пропихнуть стандартный пакет через туннель
# -M do запрещает фрагментацию, -s задает размер (1472 + 28 байт заголовка = 1500)
ping -M do -s 1472 10.10.1.1

# 2. Если получаем "Frag needed and DF set", ищем рабочее значение опытным путем:
ping -M do -s 1300 10.10.1.1

# 3. Нашли рабочее число? Правим MSS для проходящего трафика через nftables
# Актуально для 2026 года в Linux-роутерах:
nft add rule inet fw mangle forward oifname "wg0" tcp flags syn tcp option maxseg size set 1360

# 4. Или проверяем износ диска на ARM-сервере:
nvme smart-log /dev/nvme0n1 | grep percentage_used

Мы переходим на XDP (eXpress Data Path). Это база для современного сетевого админа. XDP позволяет запускать eBPF-код прямо в контексте драйвера сетевой карты, до того, как ядро вообще начнет создавать структуру `sk_buff`.

Под капотом: Пакет перехватывается на уровне RX-очереди. Мы можем либо пробросить его дальше (XDP_PASS), либо мгновенно аннигилировать (XDP_DROP), либо отправить обратно (XDP_TX). Это дает нам производительность, близкую к DPDK, но без необходимости писать драйверы в пользовательском пространстве и терять интеграцию с ОС.

# 1. Устанавливаем xdp-tools (стандарт для современных дистрибутивов)
# 2. Вешаем фильтр, который будет дропать всё, что не соответствует нашим ACL
# на уровне драйвера (native mode) или программно (skb mode)

xdp-loader load eth0 ./drop_malicious_traffic.o --mode native

# 3. Мониторим статистику прохождения пакетов через eBPF-карты
bpftool map dump name xdp_stats_map

# Пример простейшего правила для xdp-filter (современная замена многим задачам iptables)
xdp-filter load eth0 -p ipv6 --ip 2001:db8:dead:beef::/64 -a drop

Экономия ресурсов CPU. Пока

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

Используем нативный модуль Microsoft.PowerShell.SecretManagement. Это абстрактный слой, который позволяет скриптам запрашивать секреты, не зная, где они лежат: в локальном зашифрованном Vault, в KeePassXC или в корпоративном HashiCorp Vault.

Под капотом: Модуль отделяет логику скрипта от реализации хранилища. Скрипт просит «дай мне пароль от сервиса X», а SecretManagement сам идет в зарегистрированное расширение (Extension Vault) и достает его. В памяти скрипта секрет живет только в виде объекта `SecureString`.

# 1. Устанавливаем необходимые модули
Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore -Force

# 2. Регистрируем локальный защищенный сейф (требует мастер-пароль или привязку к сессии)
Register-SecretVault -Name LocalSafe -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

# 3. Сохраняем секрет один раз (интерактивно)
Set-Secret -Name "Service_DB_Prod" -Secret "MySuperSecurePassword2026!"

# 4. В скрипте теперь только чистая логика:
$dbSecret = Get-Secret -Name "Service_DB_Prod" -AsPlainText # Используйте plain text только для передачи в API!
Invoke-Sqlcmd -ServerInstance "DB-SRV-01" -Password $dbSecret -Query "SELECT 1"

Ваши `.ps1` файлы теперь абсолютно чисты. Их можно спокойно пушить в Git, передавать коллегам и не бояться, что при увольнении придется ротировать сотню паролей, которые вы «где-то там» прописали.

Главный навык админа сегодня — не «поддержать жизнь», а «уметь убить и воскресить». Мы переходим от концепции надежности железа к концепции Resilience (упругости). Инфраструктура должна быть эфемерной.

Под капотом: Мы внедряем **Immutability** (неизменяемость). Конфигурация сервера не правится руками через SSH. Если нужно изменить один параметр в `sysctl`, вы меняете его в коде (IaC), пересобираете образ и пересоздаете инстанс.

# Пример декларативного описания состояния (Inspec / Goss)
# Мы проверяем не "как долго оно работает", а "соответствует ли оно стандарту 2026 года"

file:
  /etc/ssh/sshd_config:
    exists: true
    contains:
      - "Protocol 2"
      - "PermitRootLogin no"
      - "PubkeyAuthentication yes"
      - "KexAlgorithms curve25519-sha256@libssh.org" # Квантово-устойчивые алгоритмы

command:
  check_kernel_version:
    exec: "uname -r"
    exit-status: 0
    stdout:
      - "6.12" # Мы не сидим на старье

Это избавляет вас от «дрейфа конфигураций» (configuration drift). Когда у вас 1000 серверов, вы не можете быть уверены, что на 734-м какой-то стажер не поправил конфиг руками в три часа ночи. Только полная пересборка гарантирует идентичность и предсказуемость.

В 2026-м «права пользователя» не значат ничего, если злоумышленник получил root или скомпрометировал гипервизор. Неизменяемость (Immutability) должна быть на уровне протокола хранения.
Мы используем Object Lock в S3-совместимых хранилищах (например, MinIO или отечественные облака).
Режим Compliance Mode (WORM — Write Once Read Many) гарантирует, что даже владелец аккаунта или «рут» не сможет удалить файл до истечения Retention-периода.
На уровне Linux-серверов это реализуется через XFS/ZFS snapshots с блокировкой удаления на уровне ядра или использование файловых атрибутов append-only (chattr +a), которые в связке с eBPF-мониторингом делают удаление данных невозможным без физического доступа к консоли.

Главная засада в том, что HTTP/3 работает поверх UDP, а не TCP.
Для админа это означает полный пересмотр правил фаервола (нужно открывать 443/UDP) и проблемы с классическими балансировщиками, которые привыкли к TCP-сессиям.
Connection Migration: QUIC позволяет клиенту менять IP (например, при переходе с Wi-Fi на 6G) без разрыва TLS-сессии. Для систем мониторинга и безопасности это выглядит как магия или атака, если не настроить корректное отслеживание ID соединений.
В 2026-м мы также обязаны учитывать отечественные TLS-сертификаты, которые в связке с QUIC иногда требуют специфического тюнинга MTU, чтобы пакеты не дропались на DPI.

Периметра больше не существует. Любой «умный» чайник или китайский ARM-терминал на складе — это потенциальная точка входа.
Zero Trust подразумевает, что мы не доверяем никому по умолчанию, даже серверу в соседней стойке.
Мы внедряем микросегментацию на уровне L7 через Service Mesh (например, Cilium с eBPF).
Вместо правил «IP A может ходить к IP B», мы пишем политики «Сервис А (подтвержденный сертификатом) может дергать только метод GET /api/v1 у Сервиса B». Всё остальное — drop по умолчанию. Это предотвращает горизонтальное перемещение (lateral movement) хакера по сети.

# 1. Создаем корзину с поддержкой Object Locking (в 2026-м это стандарт)
mc mb --with-lock myminio/backups-2026

# 2. Устанавливаем политику неизменяемости на 30 дней
# В режиме COMPLIANCE даже root не сможет удалить файл
mc retention set compliance 30d myminio/backups-2026

# 3. Проверяем статус файла
mc stat myminio/backups-2026/db_dump_march.tar.gz

# Вывод покажет:
# Object-Lock-Retain-Until-Date: 2026-04-11 12:00:00
# Любая попытка 'mc rm' выдаст 'Access Denied' до этой даты.

Собеседование в 2026-м — это проверка не на знание команд, а на архитектурную паранойю. Вы должны уметь строить системы, которые выживут, даже если половина вашей инфраструктуры захвачена. Бэкап, который можно удалить — это не бэкап, а иллюзия. Сеть без Zero Trust — это проходной двор.

Переходим на связку iproute2 (`ip`) и **iproute2-ss** (`ss`).
Под капотом: Старый `netstat` читает информацию из `/proc/net/`, что при большом количестве соединений превращается в пытку для CPU и диска. Современная утилита `ss` (Socket Statistics) использует механизм Netlink, запрашивая данные напрямую у ядра. Это в десятки раз быстрее и точнее, особенно когда у тебя тысячи IPv6-соединений.

# 1. Вместо 'ifconfig' — смотрим адреса и статистику ошибок на интерфейсе
ip -c -s link show eth0
ip -6 addr # Только IPv6, только хардкор

# 2. Вместо 'netstat -tulpn' — ищем, кто слушает порты
# -l (listening), -n (numeric), -p (process), -t (tcp), -4/6 (family)
ss -ltnp4

# 3. Киллер-фича: ищем все соединения от конкретного IP, которые тупят
ss -o state established '( dport = :http or sport = :http )'

# 4. Мониторим изменения в сети в реальном времени (кто поднял интерфейс, кто упал)
ip monitor

Для личного спокойствия. Когда сервер под нагрузкой «приляжет», старый `netstat` может просто зависнуть, пытаясь распарсить `/proc`. `ss` выдаст результат мгновенно, позволив тебе быстро найти и отстрелить проблемный процесс.

Используем PowerShell Remoting (WinRM) через CLI. Это позволяет выполнять команды на сотнях серверов одновременно, не видя перед собой ни одного рабочего стола.

Под капотом: WinRM работает через HTTP/HTTPS (порты 5985/5986). В 2026-м мы настраиваем его на работу по TLS 1.3 с авторизацией по сертификатам. Это безопаснее, быстрее и позволяет автоматизировать рутину через обычные текстовые команды.

# 1. Подключаемся к удаленному Server Core узлу (интерактивно)
Enter-PSSession -ComputerName "SRV-DB-01"

# 2. Магия: узнаем свободное место на дисках сразу на всей группе серверов
Invoke-Command -ComputerName "SRV-APP-01", "SRV-APP-02", "SRV-APP-03" -ScriptBlock {
    Get-Volume | Select-Object DriveLetter, FileSystemLabel, 
    @{Name="FreeGB";Expression={[Math]::Round($_.SizeRemaining / 1GB, 2)}}
}

# 3. Перезапускаем службу только если она "висит"
Invoke-Command -ComputerName "SRV-PRINT-01" -ScriptBlock {
    Restart-Service -Name "Spooler" -Force
}

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

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

* KubeVirt позволяет управлять VM как обычными подами. Это дает единый IaC-стек (Terraform/Crossplane): тебе не нужно отдельно описывать сеть для виртуалки и отдельно для контейнера.
* Мы получаем общие механизмы мониторинга, логирования и сетевые политики (Cilium/Calico) для всего парка сразу. В 2026-м инфраструктура должна быть однородной, даже если внутри — зоопарк из систем.

Проблема не в скорости ядер (ARM Neoverse в 2026-м рвет конкурентов), а в накладных расходах на эмуляцию устройств и обработку прерываний.

* Чтобы не терять 20-30% мощности, мы используем VirtIO и механизмы Hardware-assisted virtualization (вроде ARM Virtualization Extensions).
* Для сетевого трафика мы пробрасываем устройства через SR-IOV или используем DPDK, чтобы пакеты шли в обход виртуального свитча прямо в гостевую ОС. Это критично для отечественных ARM-кластеров, где мы выжимаем максимум из каждого ватта энергии.

Cloud-Init — это стандарт де-факто для автоматической настройки инстанса при первом запуске.

* Виртуалка в KubeVirt — это эфемерная сущность. Мы не заходим на неё «настроить сеть». Cloud-Init получает метаданные, сам создает пользователей, прокидывает SSH-ключи, настраивает статику в IPv6 и монтирует диски.
* Если виртуалка не поднялась через Cloud-Init — мы её прибиваем и пересоздаем. Ручная правка конфигов внутри VM — это путь к «дрейфу конфигурации» и хаосу в мониторинге.

# vm-arm64-prod.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-app-server
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4 # Оптимизировано под ARM ядра
        resources:
          requests:
            memory: 8Gi
        devices:
          disks:
            - name: containerdisk
              disk: {}
            - name: cloudinitdisk
              disk: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: registry.corp.local/vms/debian-13-arm64:latest
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |
              #cloud-config
              users:
                - name: admin_future
                  ssh_authorized_keys:
                    - ssh-ed25519 AAAAC3Nza...
              runcmd:
                - systemctl start specialized-service

Переход на KubeVirt и ARM — это не мода, а экономика. Ты либо управляешь тысячей серверов как одной сущностью, либо тонешь в тикетах на «создание одной маленькой виртуалки». В 2026 году админ — это не «хранитель ключей от серверной», а архитектор автоматизированных фабрик по переработке трафика.