Admin Future

Используем Get-WinEvent с фильтром по ID 4624 (успешный вход).

# Список успешных входов за последние 24 часа
$Time = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=$Time} | 
Select-Object TimeCreated, @{Name='User'; Expression={$_.Properties[5].Value}} |
Format-Table -AutoSize

Для контроля. Ты сразу увидишь, если в систему заходил кто-то лишний или под учеткой, которая должна быть неактивна. В пятницу перед уходом домой — это отличная привычка для проверки безопасности своей цифровой крепости.

Используй lsof (LiSt Open Files). Это твой рентген для файловой системы. Он покажет всё: какой процесс открыл файл, какой у него PID и что он с ним делает.

# Найти процесс, который занял конкретный файл
lsof /var/log/nginx/access.log

# Посмотреть всё, что открыто в конкретной папке (удобно при размонтировании)
lsof +D /mnt/data/

# Узнать, какие сетевые файлы открыты конкретным пользователем
lsof -u admin -i

Для скорости. Вместо того чтобы гадать и перезапускать сервисы наугад, ты за одну секунду находишь PID процесса и решаешь, что с ним делать — подождать или культурно убить через kill. В пятницу вечером каждая сэкономленная минута приближает тебя к отдыху.

1. Разгрузка головы: Тебе не нужно держать в уме 20 шагов развертывания сервера. Ты просто идешь по пунктам. 2. Идентичность: Все твои серверы настроены одинаково, потому что ты всегда идешь по одному и тому же гайду. 3. Делегирование: С хорошим чек-листом даже младший админ не уронит продакшен при выполнении стандартных задач.

1. Обновить пакеты системы. 2. Настроить правильный часовой пояс. 3. Создать пользователя с sudo и отключить вход для root. 4. Отключить авторизацию по паролю в SSH (только ключи). 5. Настроить фаервол (запретить всё, кроме нужных портов). 6. Установить и проверить агент мониторинга.

Используй PowerShell для контроля состояния питания. В большинстве случаев достаточно нативного WMI/CIM доступа.

# Получаем данные о батарее через CIM
$Battery = Get-CimInstance -ClassName Win32_Battery

if ($Battery) {
    $Status = switch ($Battery.BatteryStatus) {
        1 {"Разряжается"}
        2 {"Питание от сети (ОК)"}
        3 {"Полностью заряжена"}
        default {"Ошибка или Неизвестно"}
    }
    Write-Output "Статус ИБП: $Status"
    Write-Output "Заряд: $($Battery.EstimatedChargeRemaining)%"
} else {
    Write-Warning "ИБП не обнаружен в системе. Проверь USB/COM кабель."
}

Для настройки скриптов автоматического завершения работы. Если заряд падает ниже 10%, сервер должен сам потушить тяжелые базы данных и корректно выключиться, а не просто дождаться обрыва питания.

1. Дельта-копирование: rsync передает только измененные части файлов. Если ты обновил один лог в архиве на 10 ГБ, он не будет перекачивать весь файл. 2. Сохранение прав: Все атрибуты, владельцы и симлинки переезжают на новый сервер в первозданном виде. 3. Докачка: Если связь оборвалась на 99%, rsync продолжит с того же места, а не начнет с нуля.

# Синхронизация папки с удаленным сервером
# -a (archive), -v (verbose), -z (сжатие), -P (прогресс и докачка)
rsync -avzP /var/www/site/ admin@remote-server:/var/www/site/

# Удаление файлов на приемнике, если они исчезли на источнике (зеркалирование)
rsync -avzP --delete /backup/local/ backup-server:/storage/remote/

Для создания быстрых бэкапов и миграции проектов без простоев. Один раз настроил в cron — и спишь спокойно, пока данные текут туда, куда нужно.

В мире отечественных ARM-кластеров и жесткого импортозамещения мы перешли на SDS (Software-Defined Storage). Теперь хранилище — это не дорогая коробка с логотипом вендора, а софт, который объединяет диски обычных серверов в единое пространство.

Главное — абстракция. В SDS интеллект (контроллер, кэширование, дедупликация) перенесен из специализированного железа в софт, работающий на обычных узлах. 1. Масштабируемость: В SAN мы ограничены портами контроллера. В SDS (Ceph, Longhorn) мы просто добавляем новый ARM-узел в кластер, и емкость растет линейно. 2. Отказоустойчивость: В SDS данные размазаны по узлам. Выход из строя целого сервера для нас — штатная ситуация, а не катастрофа. 3. Vendor Lock-in: В 2026-м это критично. Мы не зависим от поставок конкретных запчастей, мы используем любые доступные NVMe накопители.

Это два способа обеспечить выживание данных. 1. Replication (обычно x3): Мы храним три полные копии каждого блока на разных узлах. Плюс: Максимальная производительность (чтение очень быстрое) и простота восстановления. Минус: Огромные траты места (платим за 3 ТБ, получаем 1 ТБ полезного объема). Выбираем для БД и горячих виртуалках. 2. Erasure Coding (EC): Данные разбиваются на фрагменты + контрольные суммы (как в RAID 5/6), которые раскидываются по узлам. Плюс: Экономия места (коэффициент может быть 1.5 вместо 3). Минус: Высокая нагрузка на CPU и сеть при записи и восстановлении. Выбираем в 2026-м для холодных данных, архивов и бэкапов.

Мониторинг не лечит, он констатирует смерть. Проблема Split-brain (когда две части кластера думают, что они главные) решается на уровне кворума. 1. Нечетное количество узлов: Минимум 3 (лучше 5) мониторов/контроллеров. 2. Алгоритмы консенсуса: Использование Paxos или Raft. Система не позволит записать данные, если большинство узлов не подтвердило операцию. 3. Fencing: Принудительная изоляция (отключение питания или портов) узла, который ведет себя неадекватно, чтобы он не портил данные в общем сторадже.

# Проверить общий статус здоровья
ceph health detail

# Посмотреть распределение данных и нагрузку на диски
ceph osd df tree

# Если видишь статус DEGRADED — проверяем, не идет ли сейчас Recovery (восстановление)
ceph -s

• Анонимизация: 192.168.1.100 → 10.0.0.x • Удаление секретов: никаких токенов и ключей • Обобщение: без реальных имен серверов

У меня есть конфиг Nginx (анонимизирован). Почему при proxy_pass через IPv6 появляются 502? MTU 1420.

$ServiceName = "YourServiceName"
$Service = Get-Service $ServiceName

if ($Service.Status -eq "Stopping" -or $Service.Status -eq "Pending") {
    $ServicePID = (Get-CimInstance Win32_Service -Filter "Name='$ServiceName'").ProcessId
    Stop-Process -Id $ServicePID -Force
    Write-Host "Служба $ServiceName прибита. Можно запускать заново." -ForegroundColor Cyan
} else {
    Restart-Service $ServiceName -Force
}

• Слияние логов: access.log, error.log и системные логи в одной временной ленте • Подсветка: ошибки — красным, предупреждения — желтым • Фильтрация: нажал /, ввел паттерн — убрал шум

sudo apt install lnav
# Открываем папку с логами
lnav /var/log/nginx/

1. Слияние логов: Он может собрать access.log, error.log и логи системного журнала в одну ленту, отсортированную по времени. Видно всю картину сразу. 2. Подсветка синтаксиса: Ошибки — красным, ворнинги — желтым. Банально, но чертовски эффективно. 3. Фильтрация на лету: Нажал /, ввел паттерн — и лишний шум исчез.

1. Слияние логов: Он может собрать access.log, error.log и логи системного журнала в одну ленту, отсортированную по времени. Видно всю картину сразу. 2. Подсветка синтаксиса: Ошибки — красным, ворнинги — желтым. Банально, но чертовски эффективно. 3. Фильтрация на лету: Нажал /, ввел паттерн — и лишний шум исчез.

1. Никаких имен: Цель — найти слабое место в системе, а не «наказать Ваню». 2. Хронология: Запиши по минутам: что случилось, когда заметили, когда исправили. 3. Root Cause: Найди корень проблемы. «Забился диск» — это не корень. «Логротейт не отработал из-за ошибки в конфиге» — вот это оно.

Инцидент #42: Падение API
Дата: 17.03.2026
Что случилось: Ошибка 502 на фронтенде в течение 15 минут.
Причина: Утечка памяти в новом контейнере, OOM Killer прибил процесс.
Как исправили: Увеличили лимиты RAM, откатили версию образа.
Что сделать, чтобы не повторилось: Настроить алерт на потребление 80% RAM контейнером.

1. Проверка порта: Не надо гадать, закрыл ли порт фаервол в «цифровой крепости». 2. Трассировка: Сразу показывает маршрут до цели. 3. Диагностика: Выдает детальную инфу, почему пакет не дошел.

# Просто проверить, открыт ли порт веб-сервера
tnc 192.168.1.50 -Port 443

# Сделать проверку и сразу увидеть маршрут (TraceRoute)
tnc google.com -TraceRoute

# Проверить только ICMP (старый добрый пинг, но с нормальным объектом на выходе)
tnc 8.8.8.8 -InformationLevel Detailed

Ставь duf (Disk Usage/Free Utility). Она группирует разделы, понимает терминальные темы и рисует понятные прогресс-бары.

sudo apt install duf
duf

Концепция Infrastructure as Code (IaC) начинается не с Terraform, а с обычного git init в папке с твоими скриптами или конфигами. Под капотом: Использование Git дает тебе машину времени. Ты всегда видишь, кто, когда и зачем изменил параметр в nginx.conf или в настройках active_directory. В 2026-м это стандарт: любой аудит безопасности начинается с просмотра истории коммитов в инфраструктурном репозитории.

# 1. Инициализируем репозиторий для критических конфигов
cd /etc/myapp/
git init

# 2. Создаем понятный коммит (забудь про "fix", пиши суть!)
git add .
git commit -m "CHG: Изменен таймаут коннекта к БД для ARM-кластера (Ticket #404)"

# 3. Если всё сломалось — откат за одну секунду
git checkout HEAD^1 config.yaml
systemctl restart myapp

# 4. Просмотр "кто виноват" (blame)
git blame config.yaml

Личное спокойствие и коллективная ответственность. Когда в команде больше одного человека, Git становится единственным источником правды. Больше никаких config.bak, config.old.2, config_LAST_FINAL. Только чистая история изменений и возможность мгновенного отката.

Используем Get-WinEvent с XML-фильтрацией. Под капотом: Старый Get-EventLog медленный, потому что он выкачивает все события и только потом их фильтрует. Get-WinEvent умеет отправлять запрос (FilterXML или FilterHashtable) прямо в движок журнала. В 2026-м это единственный способ быстро найти событие среди миллионов записей аудита в «цифровой крепости».

# 1. Найти 5 последних ошибок в системном журнале (мгновенно)
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 5

# 2. Кто заблокировал учетку? Ищем событие 4740 в журнале Security
# Работает в разы быстрее через FilterHashtable
$filter = @{
    LogName = 'Security'
    Id = 4740
}
Get-WinEvent -FilterHashtable $filter | Select-Object TimeCreated, Message

# 3. Выгрузка ошибок конкретного приложения за последние 2 часа
$startTime = (Get-Date).AddHours(-2)
Get-WinEvent -FilterXPath "*[System[(Level=2 or Level=3) and TimeCreated[@SystemTime >= '$($startTime.ToUniversalTime().ToString('s'))Z')]]" -LogName "Application"

Оперативность. В 2026 году требования к безопасности (ИБ) обязывают админа реагировать на подозрительные события в течение минут. Прямые запросы к логам позволяют автоматизировать алертинг и не тратить время на ожидание прогрузки тяжелых консолей управления.

Мы переходим на связку fd и ripgrep (rg). Под капотом: В отличие от классического find, который последовательно обходит дерево ФС, fd использует многопоточность и по умолчанию игнорирует скрытые папки и .gitignore. А ripgrep — это grep на стероидах, написанный на Rust, который пролетает сквозь бинарные логи и огромные конфиги, используя SIMD-инструкции процессоров ARM и x86. Это не просто «быстрее», это другой уровень отзывчивости системы.

# 1. Найти все файлы .conf в /etc, измененные за последние 10 минут
# Быстрее, чем ты успеешь моргнуть
fd -e conf -t f --changed-within 10m . /etc

# 2. Найти строку "error" во всех логах, игнорируя бинарный мусор
# -z позволяет искать даже в сжатых .gz архивах (must have 2026)
rg -z "critical_error" /var/log/app/

# 3. Киллер-фича: интерактивный поиск через fzf
# Интегрируем fd в fzf для мгновенного перехода к файлу
alias pf="fd -t f | fzf --preview 'bat --color=always {}' | xargs -r vim"

Для бизнеса это сокращение времени простоя (MTTR). Пока твой коллега смотрит на мигающий курсор find, ты уже нашел проблемную строчку в конфиге, поправил её и ушел обсуждать план миграции на новый сегмент сети.

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

Не всё можно (и нужно) запихивать в 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

Переходим на Docs like Code. Документация пишется в Markdown, хранится рядом с конфигами в Git и правится в том же редакторе, что и скрипты. Под капотом: Markdown — это чистый текст. Он не весит ничего, его легко сравнивать (diff), он идеально индексируется поиском по репозиторию и, самое главное, его понимает любой современный ИИ-помощник, которому ты можешь скормить свой `README.md`, чтобы он быстро нашел ошибку в твоих же схемах.

# Восстановление БД (План "Ой")

## 1. Проверка доступности хранилища
`nvme smart-log /dev/nvme0n1`

## 2. Команда на разворачивание последнего снапшота
> **Важно:** проверь наличие свободного места в LVM!

```bash
zfs rollback pool/db@yesterday

Для выживания. Когда в 3 часа ночи упадет критический сервис, ты не будешь ждать, пока откроется Word. Ты откроешь быстрый просмотр в Git-лабе или терминале и пройдешь по шагам, которые сам же заботливо записал. Хорошая документация — это твой подарок самому себе в будущем.