¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
Admin Future
Ir al canal en Telegram
Превращаем эникейщиков в System Architects. 🚀 Твой навигатор в мире IT-инфраструктуры: ▪️ Hard Skills: Linux, Windows, Network, Security ▪️ Tools: Лучший софт и скрытые фишки ▪️ Mindset: Как думать, чтобы платили много Админ - @maksimshap
Mostrar más242
Suscriptores
Sin datos24 horas
-167 días
-1330 días
Archivo de publicaciones
242
🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей
Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.
Это не героизм. Это провал организации процесса.
Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.
Три кита нормального on-call:
Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.
ШАБЛОН МАТРИЦЫ ЭСКАЛАЦИИ
Уровень 1 (0–15 мин): Дежурный инженер (primary)
-> Автоматический runbook, первичная диагностика
Уровень 2 (15–30 мин): Дежурный инженер (secondary)
-> Подключается если primary не отвечает или нужна помощь
Уровень 3 (30–60 мин): Тимлид / старший инженер
-> Техническое решение нестандартной ситуации
Уровень 4 (60+ мин): Руководитель
-> Только для бизнес-решений: откат релиза,
уведомление клиентов, привлечение вендора
ПРАВИЛО: каждый уровень получает уведомление автоматически.
Никакого "позвони сам если не справляешься" — это перекладывание
ответственности на усталого человека в 3 ночи.
Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.
Аудит алертов раз в квартал — три категории:
[ACTIONABLE] Алерт требует действия в течение 15 минут.
Будит людей. Должен быть в PagerDuty/Grafana OnCall.
[WATCHFUL] Алерт требует внимания в рабочее время.
Тикет в очередь, не звонок ночью.
[NOISE] Алерт не требует никаких действий.
Отключить немедленно.
Реальная статистика большинства команд при честном аудите:
- 20% алертов — ACTIONABLE
- 30% — WATCHFUL
- 50% — NOISE (которые будят людей ночью годами)
Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.
Шаблон постмортема за 30 минут:
## Постмортем: [Название инцидента] | [Дата] | Severity: P[1-3]
### Что случилось (2-3 предложения)
### Timeline (с точными временными метками)
### Влияние на пользователей и бизнес
### Root Cause (система/процесс, не человек)
### Что сработало хорошо
### Что нужно улучшить
### Action items:
| Задача | Владелец | Дедлайн |
|--------|----------|---------|
| ... | ... | ... |
ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
❌ "Инженер не заметил алерт"
✅ "Алерт не имел достаточного приоритета в системе"
❌ "админ забыл обновить конфиг"
✅ "Процедура деплоя не включала проверку конфигурации"
242
🪟 Windows: OSConfig — GPO умерло, долго живёт drift control
Коллеги, у вас в домене есть сервера, где кто-то "временно" отключил NTLMv1 и забыл вернуть? Или изменил политику аудита "под задачу"? Или коллега поставил TLS 1.0 для совместимости с каким-то древним ПО и не сказал? Я видел такое. Называется configuration drift, и он медленно разрушает безопасный периметр, который ты тщательно выстраивал.
В Windows Server 2025 Microsoft тихо привезла ответ на этот вопрос: OSConfig. Каждые несколько часов OSConfig сканирует отклонения от baseline-конфигурации и автоматически исправляет их — без необходимости ждать GPO-обновления или вмешательства вручную.
Базовая линия безопасности включает более 300 настроек безопасности, соответствующих отраслевым стандартам. После применения параметры автоматически защищены от дрейфа — это одна из ключевых особенностей платформы.
Разворачиваем и настраиваем:
# Устанавливаем модуль из PSGallery (нужен WS2025)
Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force
# Смотрим доступные сценарии
Get-OSConfigMetadata | Format-Table Name, Description -Wrap
# Сценарии: SecurityBaseline, SecuredCore, AppControl, Defender
# Применяем baseline для Member Server (более 300 настроек разом)
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer
# Для Domain Controller — отдельный сценарий
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController
# Проверяем что применилось и нет расхождений
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer
# Включаем drift control (автоисправление отклонений)
# По умолчанию проверка каждые 4 часа
Get-OSConfigDriftControl
# Ужесточаем — проверка каждые 45 минут
Set-OSConfigDriftControl 45
# Смотрим конкретный параметр и его текущее состояние
Get-OSConfigDesiredConfiguration `
-Scenario SecurityBaseline/WS2025/MemberServer `
-Setting AuditDetailedFileShare
# Кастомизируем под свои нужды (без потери drift control)
# Например, разрешаем RDP drive redirection (отключено по умолчанию)
Set-OSConfigDesiredConfiguration `
-Scenario SecurityBaseline/WS2025/MemberServer `
-Name RemoteDesktopServicesDoNotAllowDriveRedirection `
-Value 0
# Проверяем соответствие требованиям CIS/DISA STIG
# (OSConfig покрывает их автоматически при применении baseline)
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer |
Where-Object {$_.ComplianceState -ne "Compliant"} |
Select-Object Name, ExpectedValue, ActualValue
242
🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры
Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.
Почему это важно для нас, а не только для датацентров?
Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.
Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.
Практика — запускаем готовый планировщик на продакшн-хосте:
# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds
# Ubuntu 26.04 (из репозитория):
apt install scx-scheds
# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS
# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &
# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state # -> enabled
cat /sys/kernel/sched_ext/root/ops # -> lavd
# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2
# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
{
"name": "critical",
"matches": [["CgroupPrefix", "system.slice/nginx"]],
"kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
},
{
"name": "background",
"matches": [["CgroupPrefix", ""]],
"kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
}
]
EOF
# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма
242
🧠Skills: Технический долг инфраструктуры — как объяснить бизнесу, почему "оно работает" это не аргумент
Коллеги, поговорим о разговоре, который рано или поздно происходит у каждого из нас. Ты приходишь к руководителю и говоришь: нам нужно время и ресурсы, чтобы переписать вот это, обновить вот то, заменить вот это. Он смотрит на тебя и говорит: "А что сейчас не работает?" И технически он прав — оно работает. Просто это бомба с таймером.
Это и есть технический долг инфраструктуры. И проблема не в том, что ты его не видишь. Проблема в том, что ты не умеешь его показать.
По данным McKinsey, 30 процентов ИТ-директоров считают, что более 20 процентов их бюджета уходит на обслуживание технического долга. Переведи это на язык своей компании — и разговор с руководством сразу становится другим.
Практический фреймворк: инвентаризация и приоритизация долга
Разделите ваши проблемы на понятные категории с указанием риска:
— Инфраструктурный долг: серверы без IaC, ручной деплой. Риск: Высокий. Чинить нужно первым, так как рутина умножает все остальные проблемы. — Долг зависимостей: условная CentOS 7 в продакшене. Риск: Критический. — Долг безопасности: сервисные учетные записи с паролями пятилетней давности. Риск: Критический. — Долг документации: инфраструктуру знает только один админ, нет инструкций по восстановлению. Риск: Средний, но становится критичным при любых изменениях в команде. — Архитектурный долг: монолитные решения без возможности быстрого отката. Риск: Высокий. Стратегическая задача.Формула для разговора с руководством:
Стоимость долга = (часы в неделю на поддержку) умножить на (ставку инженера) умножить на 52 недели.Пример: Поддержка старой ОС без обновлений: 3 часа в неделю х 3000 рублей в час х 52 = 468 000 рублей в год. Это только один пункт из вашего списка. Миграция на новую систему займет 80 часов один раз = 240 000 рублей. Окупаемость очевидна любому директору. Как говорить об этом с бизнесом — три правила:
Первое. Никогда не говори "нам нужно переписать". Говори: "Сейчас мы тратим X часов в месяц на поддержку этого. После модернизации — Y. Разница = Z рублей в год." Фраза "это сэкономит бизнесу полмиллиона в год" работает значительно лучше технических терминов. Второе. Приоритизируй по принципу "что упадет первым и сколько это будет стоить". Инфраструктурный долг и долг безопасности надо чинить первыми. Старая ОС без патчей в 2026 году — это не техдолг, это открытая дверь для шифровальщика. Третье. Веди реестр долга публично. В трекере, видимом команде и руководству. Описание, риск, стоимость поддержки в год, стоимость устранения. Когда руководитель видит список из 15 строк с итоговой суммой потерь внизу — разговор о выделении времени идет иначе.Зачем это нужно: Технический долг не исчезает от того, что о нем молчат. Он накапливается — тихо, как проценты по кредиту. И платить по нему приходится либо планово (когда ты контролируешь ситуацию), либо аварийно (когда упало в пятницу вечером). Второй вариант всегда дороже. Итог: Твоя работа — не только чинить то, что сломалось. Твоя работа — объяснять руководству, что сломается следующим и во сколько это обойдется. Инженер, который умеет переводить технический долг в деньги — это человек, с которым бизнес разговаривает на равных. #skills #techdebt #sysadmin #карьера #инфраструктура #admin_future
242
🪟 Windows: Hotpatch по умолчанию с мая 2026 — разбираемся, что это значит для твоей инфраструктуры
Коллеги, тихая, но важная новость: начиная с майского обновления безопасности 2026 года, Windows Autopatch включает hotpatch-обновления по умолчанию для всех eligible-устройств под управлением Microsoft Intune. Если ты управляешь парком Windows 11 24H2 через Intune — с мая твои машины начнут получать патчи безопасности без перезагрузки. Автоматически. Хочешь ты этого или нет.
Разберём механику, подводные камни и что делать прямо сейчас.
Как это работает: hotpatch следует строгому квартальному циклу: в январе, апреле, июле и октябре — полное накопительное обновление с перезагрузкой (baseline), в остальные месяцы — hotpatch-пакеты, которые патчат только код запущенных процессов в памяти, без рестарта. Итого: 4 перезагрузки в год вместо 12.
Звучит идеально. Но есть нюансы:
# Проверяем, готово ли устройство к hotpatch
# Требования: Windows 11 24H2+, VBS включён, апрельский baseline установлен
# 1. Проверяем версию и билд
Get-ComputerInfo | Select-Object WindowsVersion, OsBuildNumber, OsDisplayVersion
# 2. Проверяем статус Virtualization-Based Security (обязательное требование)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (хорошо), 0 = Not enabled (hotpatch не получим)
# 3. Смотрим в Intune — статус по устройствам (через Graph API)
# Или через портал: Intune -> Devices -> Monitor -> Hotpatch quality update report
# 4. Если нужно ОТКЛЮЧИТЬ hotpatch для группы устройств или всего тенанта
# Intune -> Devices -> Windows updates -> Quality updates -> Edit policy
# Переключить "When available, apply without restarting" -> Block
# 5. Через реестр на конкретной машине (для тестовых сценариев)
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
-Name "HotPatchRestrictions" `
-Value 1 -Type DWORD
# Value 1 = отключить hotpatch, Value 0 = включить
# 6. Проверяем, какой тип обновления был установлен последним
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
# Hotpatch-обновления будут иметь KB-номер с пометкой "Hotpatch" в описании
242
🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно
Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.
Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.
Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.
Сначала — аварийный аудит. Находим всё, что ещё на SysV:
# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null
# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"
# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
while read unit _; do
unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
[[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
done
# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s
# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service
242
По умолчанию Kubernetes Secrets хранятся в etcd только в формате base64, а не в зашифрованном виде. В продакшне необходимо включать шифрование данных at rest и ограничивать доступ через RBAC.
Base64 — это кодировка, а не шифрование. Любой, у кого есть доступ к etcd или к объекту Secret в API — видит пароль в открытом виде.
Как это исправить — три уровня защиты:
# Уровень 1: Включаем Encryption at Rest в etcd
# В конфиге kube-apiserver добавляем:
# --encryption-provider-config=/etc/kubernetes/enc/enc.yaml
# enc.yaml:
# resources:
# - resources: ["secrets"]
# providers:
# - aescbc:
# keys:
# - name: key1
# secret: <base64-encoded-32-byte-key>
# - identity: {}
# Уровень 2: RBAC — минимальные права на чтение Secrets
kubectl create role secret-reader \
--verb=get,list \
--resource=secrets \
--namespace=production
# Уровень 3 (продакшн-стандарт 2026): External Secrets Operator
# Secrets хранятся в Vault / AWS Secrets Manager / Azure Key Vault
# Kubernetes их НИКОГДА не держит у себя в etcd
# Манифест ExternalSecret:
# apiVersion: external-secrets.io/v1beta1
# kind: ExternalSecret
# spec:
# secretStoreRef:
# name: vault-backend
# data:
# - secretKey: db-password
# remoteRef:
# key: production/db
# property: password
242
🎓 Собеседование сисадмина. Выпуск #12: Kubernetes — то, что спрашивают в 2026 году
Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.
Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".
---
❓ Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»
❌ Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».
✅ Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.
Алгоритм траблшутинга:
# Шаг 1 — Смотрим текущие логи
kubectl logs <pod-name> -n <namespace>
# Если контейнер упал слишком быстро — логи уже улетели.
# Берём логи предыдущего запуска:
kubectl logs <pod-name> -n <namespace> --previous
# Шаг 2 — Описание pod: ищем Reason в Last State
kubectl describe pod <pod-name> -n <namespace>
# Смотрим секцию "Last State" и "Events"
# Причины бывают разные:
# OOMKilled -> контейнер убит за превышение лимита памяти
# Error (exit 1) -> приложение упало само (ошибка конфига/зависимость)
# RunContainerError -> не может стартовать (нет образа, нет прав на том)
# Шаг 3 — Если OOMKilled: смотрим лимиты и правим манифест
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# Временно поднимаем memory limit, чтобы убедиться в диагнозе:
# resources.limits.memory: 512Mi -> 1Gi
# Шаг 4 — Проверяем ConfigMap и Secret: существуют ли они в этом namespace?
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>
# Если приложение не может найти конфиг — оно упадёт с exit code 1
# ПЛОХОЙ пример: Liveness смотрит на /ready (страница прогрева)
# При старте приложению нужно 30 секунд на инициализацию БД.
# Liveness видит 503 -> убивает контейнер -> перезапускает -> снова 503
# -> бесконечный CrashLoopBackOff на старте.
# ПРАВИЛЬНАЯ конфигурация:
livenessProbe:
httpGet:
path: /healthz # Легкая проверка: "процесс жив?"
port: 8080
initialDelaySeconds: 10
periodSeconds: 15
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready # Тяжелая проверка: "готов принимать трафик?"
port: 8080
initialDelaySeconds: 20 # Даём время на прогрев
periodSeconds: 5
failureThreshold: 2
242
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---
## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"
## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica
## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.
## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.
## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)
## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)
## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni
242
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму
Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.
Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить Богдану, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.
Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.
Шаблон runbook, который реально работает:
---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---
## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"
## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica
## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.
## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.
## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)
## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)
## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni
242
🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться
Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.
Звучит хорошо. Но есть нюанс.
Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.
Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:
# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor
# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory
$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor
foreach ($OU in $OUs) {
$acl = Get-Acl "AD:$($OU.DistinguishedName)"
$acl.Access | Where-Object {
$_.ActiveDirectoryRights -match "CreateChild" -and
$_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
# ObjectType для msDS-DelegatedServiceAccount
} | Select-Object IdentityReference, ActiveDirectoryRights |
ForEach-Object {
[PSCustomObject]@{
OU = $OU.Name
Identity = $_.IdentityReference
Rights = $_.ActiveDirectoryRights
}
}
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation
# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable
# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
"*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
Select TimeCreated, Message | Format-List
242
🐧 Linux: Ядро 7.0 вышло — и вот что из этого реально важно для продакшна
Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.
Три изменения, за которыми стоит следить:
Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.
Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.
Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.
Как проверить, что вы не сломаетесь при переходе:
# Смотрим текущую версию и параметры компиляции
uname -r
cat /boot/config-$(uname -r) | grep -E "CONFIG_MODULE_SIG|CONFIG_RUST"
# Проверяем подписи установленных DKMS-модулей
dkms status
# Все модули должны пересобраться под новое ядро автоматически
# Для XFS — проверяем здоровье до обновления (на всякий случай)
xfs_info /dev/sda1
dmesg | grep -i xfs | grep -iE "error|corrupt|repair"
# После перехода на 7.0 — смотрим, что новый самохил XFS активен
dmesg | grep -i "xfs.*repair\|xfs.*heal"
# Ubuntu 26.04 LTS получит 7.0 из коробки (выход 23 апреля)
# На текущих системах — через mainline PPA для тестирования:
sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update && apt list --upgradable | grep linux-image
242
🧠 Skills: Твоя инфраструктура работает. А ты — нет. О выгорании инженера
Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.
Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.
Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?
Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.
Практический алгоритм выхода из режима "я незаменим":
Шаг 1 — ИНВЕНТАРИЗАЦИЯ НАГРУЗКИ Фиксируй всё что делаешь 2 недели в любом трекере. Цель: увидеть реальную картину, а не ощущение. Шаг 2 — РАЗДЕЛЕНИЕ НА КАТЕГОРИИ [A] Только я (требует моей экспертизы) [B] Может делать обученный коллега [C] Должно быть автоматизировано [D] Не нужно делать вообще Шаг 3 — ИЗБАВЛЕНИЕ ОТ КАТЕГОРИИ D Гарантированно 20-30% задач там. Просто перестать делать и посмотреть что случится. Обычно — ничего. Шаг 4 — АВТОМАТИЗАЦИЯ КАТЕГОРИИ C Один скрипт, одна задача. Не "потом". Сейчас. Это инвестиция, а не трата времени. Шаг 5 — ДЕЛЕГИРОВАНИЕ КАТЕГОРИИ B Задокументировать -> передать -> принять что будет сделано не идеально, но достаточно хорошо. Шаг 6 — ЖЁСТКИЕ ГРАНИЦЫ Рабочий чат отключается в 19:00. Это не грубость. Это профессиональная гигиена.Зачем это нужно: К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой. Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе. #skills #burnout #sysadmin #teamwork #карьера #admin_future
242
🪟 Windows: SMB через порт 445 в 2026 году — это как ходить в интернет через telnet
Коллеги, признайтесь: у скольких из вас в DMZ или для удалённого офиса проброшен TCP 445 с каким-нибудь ACL "только для своих"? Я видел такое на аудите буквально в прошлом квартале, и это зрелище не для слабонервных.
Windows Server 2025 принёс кое-что важное для всех изданий, не только Azure Edition: SMB over QUIC — это SMB, инкапсулированный в QUIC-протокол и работающий через UDP 443 с TLS 1.3. Для удалённого пользователя это выглядит как обычная сетевая папка, но транспорт полностью зашифрован и firewall-friendly. Никакого VPN, никакого открытого 445-го.
Включаем через PowerShell (WAC для 2025 пока не поддерживает, только PS):
# 1. Убеждаемся что SMBv1 мёртв
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# 2. Включаем аудит — смотрим кто ещё не умеет шифрование
Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
# 3. Привязываем сертификат к SMB over QUIC
# (сертификат нужен с SAN = FQDN файл-сервера, можно Let's Encrypt)
$thumb = (Get-ChildItem Cert:\LocalMachine\My |
Where-Object {$_.Subject -like "*fileserver*"}).Thumbprint
Set-SmbServerCertificateMapping `
-Name "QuicCert" `
-Thumbprint $thumb `
-StoreName "My" `
-Force
# 4. Включаем QUIC-листенер на интерфейсе
New-SmbServerNetworkInterface `
-InterfaceAlias "Ethernet" `
-QuicListener $true
# 5. Проверяем — клиент должен видеть QUIC
Get-SmbConnection | Select ServerName, Dialect, TransportName
# TransportName = QUIC — победа
242
🐧 Linux: Bcachefs выгнали из ядра — и это хорошая новость для тех, кто понимает
Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.
Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.
Что это означает на практике — собираем пул с erasure coding:
# Устанавливаем DKMS-модуль (Ubuntu 24.04 / Debian 13)
apt install bcachefs-tools bcachefs-dkms linux-headers-$(uname -r)
# Форматируем пул из 4 дисков с erasure coding (аналог RAID 5)
# 3 диска данных + 1 диск паритета
bcachefs format \
--label=storage \
--erasure_code \
--replicas=1 \
/dev/sdb /dev/sdc /dev/sdd /dev/sde
# Монтируем (UUID рекомендуется для надёжности)
mount -t bcachefs /dev/sdb:/dev/sdc:/dev/sdd:/dev/sde /mnt/storage
# Проверяем статус пула
bcachefs fs usage /mnt/storage
# Смотрим здоровье устройств
bcachefs show-super /dev/sdb
242
🕵️♂️ Security: DPI переезжает в ваш смартфон. Как и зачем российские приложения ищут VPN
Коллеги, пока мы воевали с ТСПУ и маскировали трафик на серверах, регуляторы изящно сменили тактику. Цензура и DPI переезжают прямо на клиентские устройства.
К 15 апреля 2026 года Минцифры обязало российский бигтех (Яндекс, Сбер, VK, маркетплейсы) жестко ограничивать пользователей с включенным VPN. Не выполнишь — лишение IT-аккредитации. И маркетплейсы уже взяли под козырек: с 7 апреля Ozon и Wildberries начали резать загрузку каталогов при активном туннеле.
Как это выглядит под капотом (спойлер — это легализованное шпионское ПО):
Ребята из RKS Global декомпилировали 30 самых популярных ру-приложений для Android. Результаты аудита: 22 из 30 приложений целенаправленно ищут VPN, а 19 — молча отправляют этот статус на сервера (и далее товарищу майору).
Методы детекции, которые сейчас зашиты в ваш телефон:
— Чтение интерфейсов: Приложения (как мессенджер MAX) сканируют систему на наличие поднятых tun/ppp/tap адаптеров.
— Прямой запрос: Самокат и МегаМаркет через queryIntentServices("android.net.VpnService") тупо собирают список всех VPN-клиентов на устройстве.
— Скан соседей: Avito держит в манифесте блок queries на 200+ чужих пакетов. Он точно знает, стоят ли у вас клиенты конкурентов или запрещенные соцсети.
— Поведенческая биометрия: Банки (Т-Банк, Сбер, ВТБ) пишут каждое касание экрана (dispatchTouchEvent) с координатами и силой нажатия.
— Поиск инструментов: Яндекс Браузер целенаправленно ищет установленный Tor, а Яндекс Музыка сканирует систему на наличие Frida (инструмент динамического анализа), защищаясь от реверс-инжиниринга.
Как с этим жить инженеру?
Разделяй и властвуй. Идеальный сетап в 2026 году — это физически второй (старый) смартфон чисто под банки и маркетплейсы. Если телефон один, вас спасет только аппаратная виртуализация Android — Work Profile (через приложение Shelter).
Скрипт для параноиков. Проверяем через ADB, кто из приложений имеет системное право сканировать другие программы на вашем телефоне (тот самый QUERY_ALL_PACKAGES):
adb shell pm list packages --user 0 | sed 's/package://' | while read pkg; do adb shell dumpsys package $pkg | grep -q "android.permission.QUERY_ALL_PACKAGES" && echo "$pkg"; done
Зачем это нужно:
Чтобы понимать масштаб угрозы. Если приложение из этого списка вам не жизненно необходимо — сносите. Для оставшихся в живых: жестко отрезаем работу в фоне (Настройки — Батарея — Ограничено), отзываем доступ к контактам, логам звонков и локации.
Итог: Государство успешно делегировало цензуру частному бизнесу. Split tunneling больше не спасает — приложения видят поднятый tun0 на уровне системы. Поднимайте VPN-туннели аппаратно на домашних роутерах (MikroTik/Keenetic), чтобы телефон получал уже «чистый» Wi-Fi без локальных VPN-клиентов.
#security #vpn #android #privacy #sysadmin #admin_future
242
🌐 Networking: WireGuard + wg-quick — это хорошо. WireGuard + netbird — это продакшн
Коллеги, WireGuard как замена OpenVPN уже давно не новость. Но я вижу, как большинство коллег до сих пор управляют им через wg-quick и ручное редактирование конфигов на каждом узле. Добавить новый хост — значит зайти на каждый пир, добавить PublicKey и AllowedIPs руками. В сети на 15 узлов это уже ад.
В 2026 году для mesh VPN на базе WireGuard есть нормальный инструментарий. Один из лучших — Netbird (self-hosted, open source, с management plane и ACL через UI или API).
Поднимаем self-hosted Netbird за 10 минут:
# На управляющем сервере (Ubuntu 24.04 LTS)
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/netbird_management_linux_amd64.tar.gz \
| tar -xz -C /usr/local/bin
# Используем официальный docker-compose (рекомендуемый путь)
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/docker-compose.yml
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/.env.example -O .env
# Правим .env: домен, TURN-сервер, OIDC-провайдер (или отключаем auth для лаборатории)
nano .env
docker compose up -d
# На каждом узле (Linux, Windows, macOS — клиент один и тот же)
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://your-netbird-domain:443 --setup-key YOUR_KEY
242
🪟 Windows: LAPS v2 + Entra ID — хватит хранить пароль локального админа в Excel
Коллеги, я знаю, что где-то в вашей сети до сих пор живёт локальный Administrator с паролем из 2019 года, который записан в заметках у Богдана. И Богдан уже полгода как уволился.
Классический LAPS первого поколения умел ротировать пароль и класть его в AD — и это было неплохо. Но LAPS v2, встроенный в Windows Server 2025 и Windows 11, это уже другой уровень: шифрование пароля в AD, история паролей, поддержка Entra ID (Azure AD) для гибридных сред и ротация по требованию через PowerShell или Intune.
Включаем и настраиваем правильно:
# 1. Обновляем схему AD (один раз, на DC)
Update-LapsADSchema
# 2. Настраиваем права на OU с рабочими станциями
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"
# 3. Создаём GPO-политику через PowerShell (или через GUI GPMC)
# Путь в GPO: Computer -> Admin Templates -> LAPS
# Ключевые параметры:
# - Enable password backup to AD: Enabled
# - Password complexity: Large letters + small + digits + specials
# - Password age: 30 days
# - Enable encrypted password: Enabled <-- вот это обязательно в v2
# 4. Смотрим пароль для конкретной машины (только авторизованным)
Get-LapsADPassword -Identity "PC-FINANCE-01" -AsPlainText
# 5. Принудительная ротация после инцидента
Invoke-LapsPolicyProcessing # на машине
# или удалённо:
Reset-LapsPassword -Identity "PC-FINANCE-01"
242
🐧 Linux: eBPF-трейсинг вместо strace — хирургия без анестезии
Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.
В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.
Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:
# Все открываемые файлы процессом nginx в реальном времени
bpftrace -e '
tracepoint:syscalls:sys_enter_openat
/comm == "nginx"/
{
printf("%s -> %s\n", comm, str(args->filename));
}
'
# Латентность read() по перцентилям — находим I/O-узкое место
bpftrace -e '
tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_read /@start[tid]/
{
@lat = hist(nsecs - @start[tid]);
delete(@start[tid]);
}
'
242
👻 WINDOWS: ОХОТА ЗА ПРИЗРАКАМИ. УДАЛЯЕМ МЕРТВЫЕ SID ИЗ ПРАВ ДОСТУПА
При реорганизации инфраструктуры и чистке домена от легаси-объектов мы часто удаляем старые учетные записи. Но права доступа на файловых серверах (NTFS ACL) остаются. Вместо имен пользователей там появляются неопознанные SID (начинаются с S-1-5-21...).
Это не просто эстетическая проблема. При миграции серверов или глубоком аудите эти мертвые души сильно тормозят пересчет прав, ломают наследование и создают хаос в политиках безопасности.
PowerShell скрипт для поиска и удаления мертвых SID:
$Path = "C:\Shares\Department"
$ACLs = Get-Acl -Path $Path
$Rules = $ACLs.Access | Where-Object { $_.IdentityReference -match "^S-1-5-21" }
foreach ($Rule in $Rules) {
$ACLs.RemoveAccessRule($Rule) | Out-Null
Write-Host "Удален мертвый SID: " $Rule.IdentityReference
}
Set-Acl -Path $Path -AclObject $ACLs
