1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.

Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.

Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.

Техническая суть:
Команда создает временный (transient) юнит и позволяет лимитировать ресурсы (CPU, RAM, I/O) «на лету» прямо из командной строки.

# Запускаем скрипт в отдельном слайсе с жестким лимитом по памяти
sudo systemd-run --scope -p MemoryMax=500M -p CPUWeight=50 ./heavy-script.sh
# Посмотреть статус этого временного юнита
systemctl status run-*.scope

Техническая суть:
Ты описываешь не только список программ, но и настройки системы, реестра и функций Windows.

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      directives:
        description: Install VS Code
      settings:
        id: Microsoft.VisualStudioCode
        source: winget
    - resource: Microsoft.Windows.Developer/DeveloperMode
      settings:
        Enabled: true
configurationVersion: 0.2

# Проверить файл и применить настройки
winget configure config.yaml

Техническая суть:
«Фактор автобуса» — это количество членов команды, которых должен переехать автобус, чтобы проект/инфраструктура встали колом. Если твой Bus Factor равен 1 (это ты) — у компании огромные риски, а у тебя — вечный стресс.

1. Документация «для идиота»: Пиши инструкции так, чтобы твой сменщик мог поднять упавший сервис в 3 часа ночи без твоего звонка.

2.Infrastructure as Code (IaC): Твои знания должны быть зафиксированы в коде Ansible/Terraform, а не только в твоей голове.

3. Shared Secrets: Используй командные менеджеры паролей (Vault, Passbolt). Никаких личных блокнотов с паролями от рута.

* Плюсы: Огромное количество настроек, поддержка аппаратного ускорения в большинстве роутеров, работа на сетевом уровне (Layer 3).
* Минусы: Чудовищно сложная настройка (IKEv2, Phase 1, Phase 2, политики шифрования). Код IPsec в ядре Linux — это десятки тысяч строк, в которых до сих пор находят дыры.
* Кейс: Соединить два офиса на оборудовании Cisco/Mikrotik/Juniper.

* Плюсы: Скорость (быстрее IPsec и OpenVPN в разы), простота (всего ~4000 строк кода — легко проверить на баги), мгновенное соединение.
* Минусы: Работает только по UDP (может блокироваться суровыми провайдерами), по умолчанию не имеет динамического управления IP (но это решается обертками типа Tailscale или Netmaker).
* Кейс: Удаленный доступ для сотрудников, связь микросервисов, личный VPN.

# Посмотреть статус пиров и объем переданного трафика
sudo wg show

# Проверить наличие интерфейса и его параметры
ip address show wg0

# Статус соединений
sudo swanctl --list-sas
# ИЛИ (для старых версий)
sudo ipsec statusall

# Проверить политики безопасности в ядре
ip xfrm policy

* Философия: Индексируем абсолютно каждое слово в каждой строке лога.
* Плюсы: Мгновенный полнотекстовый поиск. Мощнейшая аналитика и визуализация. Ты можешь найти ошибку в конкретном запросе среди миллиарда записей за доли секунды.
* Минусы: Прожорливость. Elasticsearch обожает оперативную память (RAM) и «кушает» её гигабайтами. Индексы занимают много места на диске.

input {
  beats { port => 5044 }
}
filter {
  grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }
}
output {
  elasticsearch { hosts => ["localhost:9200"] }
}

* Философия: Мы не индексируем текст. Мы индексируем только метаданные (метки: имя сервера, имя контейнера, уровень лога). Сами логи сжимаются и лежат в дешевом объектном хранилище (S3).
* Плюсы: Потребляет в 10 раз меньше ресурсов, чем Elasticsearch. Идеально интегрируется в Grafana рядом с метриками. Хранение стоит копейки.
* Минусы: Поиск по самому тексту лога (grep) медленнее, чем в ELK, так как системе приходится «на лету» распаковывать чанки данных.

scrape_configs:
- job_name: system
  static_configs:
  - targets: [localhost]
    labels:
      job: varlogs
      __path__: /var/log/*.log

Модель OSI — это карта для поиска неисправностей.
L1 (Физический): Горит ли линк на сетевухе? Не перебит ли кабель?
L2 (Канальный): Видим ли мы MAC-адрес соседа? Работают ли VLAN-ы? (Инструмент: `arp -a`).
L3 (Сетевой): Здесь живут IP и **Ping (ICMP)**. Маршрутизация пакетов между сетями.
L4 (Транспортный): Порты! TCP (с гарантией доставки) и UDP (быстро, но без гарантии).
L7 (Прикладной): Здесь живет HTTPS, DNS, SSH.
Суть: Если не работает сайт (L7), сначала проверь пинг (L3) и линк (L1). Идем снизу вверх.

Это процесс установления надежного соединения. Состоит из трех шагов:
1. SYN: Клиент шлет запрос «Привет, давай свяжемся, мой номер (Sequence Number) — X».
2. SYN-ACK: Сервер отвечает «Привет! Я согласен. Твой номер X подтверждаю, мой номер — Y».
3. ACK: Клиент говорит «Ок, твой Y подтверждаю, погнали данные!».
Зачем: Это гарантирует, что обе стороны готовы к передаче, и позволяет синхронизировать номера пакетов, чтобы данные пришли в правильном порядке.

* BGP (Border Gateway Protocol) — это протокол обмена маршрутами между Автономными Системами (AS). Весь интернет — это лоскутное одеяло из AS.
* Суть проблемы: В BGP нет встроенной проверки доверия. Если крупный провайдер (или злоумышленник) случайно анонсирует, что «самый короткий путь к серверам Google лежит через меня» (BGP Hijacking), весь мировой трафик пойдет туда и «умрет».
* Пример: Именно из-за ошибок в BGP-конфигурациях случались глобальные сбои у Facebook и WhatsApp, когда они буквально «исчезали» из глобальной таблицы маршрутизации.

Техническая суть:
Утилита позволяет не только смотреть SMART, но и управлять очередями, форматировать блоки под разный размер (LBA) и проверять реальный износ ячеек памяти (NAND Endurance).

# Установка (если еще нет)
sudo apt install nvme-cli

# Вывести список всех NVMe дисков и их базовую инфу
sudo nvme list

# Показать детальный лог здоровья (критические предупреждения, температуру, износ)
sudo nvme smart-log /dev/nvme0n1

Техническая суть:
Podman не требует запущенного демона (daemonless) и позволяет запускать контейнеры в изолированных User Namespaces. Если хакер «сломает» контейнер, он окажется внутри системы с правами обычного бесправного пользователя.

# Запуск контейнера от обычного пользователя (без sudo!)
podman run -d --name my-app -p 8080:80 nginx

# Генерируем systemd-юнит, чтобы контейнер сам стартовал после ребута
podman generate systemd --name my-app --files --new

Техническая суть:
Ты создаешь фейковый файл (например, id_rsa, kubeconfig или AWS Access Key) и кладешь его в «соблазнительное» место. Как только кто-то попытается им воспользоваться, сервер-приемник зафиксирует IP и время обращения.

# Создаем уникальный домен-приманку через сервис (например, canarytokens.org)
# Если кто-то выполнит резолв этого имени:
host secret-token-unique-id.canarytokens.com
# Тебе тут же упадет письмо/алерт с IP того, кто это сделал.

Репликация — это механизм синхронизации данных между Master (Writer) и Replica (Reader).
* Асинхронная: Мастер записывает данные и тут же подтверждает успех клиенту, не дожидаясь реплики.
* *Плюс:* Максимальная скорость.
* *Минус:* Риск потери данных при падении Мастера (те миллисекунды данных, что не успели улететь на реплику).

* Синхронная: Мастер ждет, пока реплика подтвердит получение данных, и только потом отвечает клиенту.
* *Плюс:* Гарантия сохранности данных.
* *Минус:* Если реплика «залагает» или упадет сеть — встанет и запись на Мастере.

Индекс — это отдельная структура (обычно B-Tree), которая позволяет не сканировать всю таблицу целиком.
* Проблема: Каждый индекс занимает место на диске. Но главное — любой индекс замедляет запись (INSERT/UPDATE). При каждом изменении данных базе приходится обновлять и все связанные с этой колонкой индексы.
* Вывод: Индексы нужно создавать только на те колонки, по которым реально идет частая фильтрация (WHERE) или сортировка (ORDER BY).

Логический бэкап (dump) на терабайтной базе — это плохая идея. Он будет делаться вечно и создаст огромную нагрузку.
* Правильный путь: 1. Снапшоты на уровне ФС/LVM: Замораживаем ФС на секунду, делаем снапшот, размораживаем и спокойно копируем данные.
2. Физический бэкап: Инструменты вроде `pg_backrest` для PostgreSQL или `Percona XtraBackup` для MySQL. Они копируют сами файлы данных «на лету», не блокируя чтение и запись.
3. Бэкап с реплики: Самый надежный способ. Снимаем бэкап с репликационного сервера, чтобы вообще не нагружать основной Master-сервер.

Техническая суть:
zRAM создает сжатое блочное устройство прямо в оперативной памяти. Когда RAM начинает заканчиваться, ядро сжимает неиспользуемые страницы и складывает их в этот «быстрый swap», не обращаясь к медленному диску. Степень сжатия часто достигает 1:3.

# Устанавливаем утилиту
sudo apt install zram-tools

# Настройка в /etc/default/zramswap:
# ALGO=zstd (самый эффективный алгоритм сжатия в 2026-м)
# PERCENT=50 (выделяем до 50% RAM под сжатый пул)

# Перезапуск сервиса
sudo systemctl restart zramswap

# Проверка статуса
zramctl

Техническая суть:
Параметр `-Parallel` в командлете `ForEach-Object` позволяет запускать скрипт-блоки одновременно в разных потоках. Лимит потоков можно задать через `-ThrottleLimit`.

$servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' | Select-Object -ExpandProperty Name

# Опрашиваем по 20 серверов одновременно
$servers | ForEach-Object -Parallel {
    Get-Service -Name "Spooler" -ComputerName $_ | Select-Object Machinename, Status
} -ThrottleLimit 20

Техническая суть:

1. Версионность: Ты всегда видишь, кто и когда изменил инструкцию по восстановлению бэкапа.
2. Peer Review: Ты можешь создать Pull Request с описанием новой схемы сети, а коллеги проверят его на ошибки.
3. Автоматизация: При пуше в Git документация может сама собираться в красивый статический сайт (через MkDocs или Hugo).

Золотые правила Read-Only Friday:

* Никаких обновлений прошивок на центральных свитчах.
* Никаких массовых изменений GPO в Active Directory.
* Никаких «да я только одну строчку в конфиге nginx поправлю».
* Никаких миграций баз данных.

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

[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