Код в мешке

👋 Кризис инструментария API: почему разработчики бегут от Postman и его клонов? В мире инструментария API становится популярным паттерн, отражающий ситуацию с другими инструментами разработчиков:

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

Postman, когда-то бывший любимцем всех разработчиков, стал наглядным примером такой трансформации. Переломным для многих моментом стало удаление Scratchpad (офлайн-режим). После этого — снижение производительности и привязка к облачному сервису. Внезапно мы оказались вынуждены синхронизировать свою работу с облаком Postman для доступа к базовому функционалу. Что сейчас происходит с Postman и что делать дальше — читай в статье. 🐸 Библиотека программиста

🔥 База по ИИ-агентам от научного сотрудника Сколтеха и НИУ ВШЭ Знакомьтесь, Екатерина Трофимова. Кандидат компьютерных наук, ресерчер в Центре ИИ Сколтеха и лаборатории LAMBDA. Она объединяет глубокую академическую экспертизу и практику: знает, как ИИ-системы устроены «под капотом» и как встроить их в реальные проекты (в т.ч. для Т-банка). Мы попросили Екатерину собрать список мастхев материалов для тех, кто хочет проектировать агентов в проде. Сохраняйте список. 🛠 Стек и фреймворки: DSPy — алгоритмическая оптимизация промптов (вместо ручного подбора слов). Semantic Kernel и LangMem — инструменты для управления сессионной и долгосрочной памятью. MCP (Model Context Protocol) — новый стандарт от Anthropic для подключения агентов к вашим БД и локальным файлам. 📖 Документация, которую нужно знать: Anthropic Prompt Caching — как кэшировать контекст и радикально резать косты на API. OpenAI Agents SDK / Cookbook — лучшие практики работы с памятью. Augment — платформа для оптимизации работы ИИ-агентов и контроля токенов. 🔬 Хардкорные статьи и препринты (на выходные): Lost in the Middle — почему LLM «слепнут» на длинных текстах и забывают середину контекста. How Do Coding Agents Spend Your Money? — куда улетает бюджет при работе автономных кодинг-агентов. MemGPT — архитектура операционной системы для LLM с иллюзией бесконечной памяти. InjecAgent / AgentSentry — всё о безопасности и защите агентов от инъекций в промпты. Екатерина Трофимова — один из ключевых экспертов нашего курса AgentOps. На своих лекциях она детально разбирает, как проектировать инструменты для агентов, как агент принимает решения о вызове инструментов и какие ограничения возникают в реальном проде 🎁 Акция в честь старта продаж! Прямо сейчас при покупке Инженерного трека вы получаете полный доступ к материалам курса «Разработка ИИ-агентов» в подарок. 👉 Забрать 2 курса по цене 1 и начать обучение

Можно! 🐸 Библиотека программиста

🔒 Планы hh.ru на 2026: привязка к Госуслугам и запрет накрутки опыта

С 2026 года hh.ru делит соискателей на три категории: верифицированные, «серые» и невидимые. Те, кто не привязал Госуслуги и не подтвердил опыт через ЭТК, рискуют отправлять отклики в пустоту.

Разбираем механику новой системы и даем рабочий план — что делать прямо сейчас, чтобы остаться в игре. 👉 Читать статью 🐸 Библиотека программиста

😋 Друзья, признавайтесь, какие каналы у вас не на мьюте в Telegram? А если серьезно — поделитесь, за кем следите (читаете/смотрите) из мира IT? Любые площадки и авторы — сюда 👇

Такое мнение. И как будто бы в точку 🎯 🐸 Библиотека программиста

Помните помощника-скрепку в винде? Пришло время добавить помощника в VS Code 🦮 🐸 Библиотека программиста

По умолчанию 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

Секреты никогда не должны попадать в Git в открытом виде. Стандарт 2026 года: внешние хранилища (HashiCorp Vault, Cloud KMS) с инъекцией через External Secrets Operator или CSI-драйвер. --- 💡 Золотое правило собеса: Когда вас спрашивают про Kubernetes — интервьюер проверяет не знание синтаксиса kubectl, а понимание того, что происходит под капотом. Фраза "pod упал — я смотрю логи предыдущего запуска через --previous флаг, потому что текущие уже затёрты" — мгновенно выдаёт человека, который это делал в реальном продакшне, а не только читал документацию. Сохраняйте пост — Kubernetes на собесах уже не опциональная тема! #собеседование_AF #kubernetes #k8s #devops #sysadmin #контейнеры #admin_future

🎓 Собеседование сисадмина. Выпуск #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

Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает. --- ❓ Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?» ❌ Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли». ✅ Ответ инженера: Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий. Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний. Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша). Что будет если перепутать:

# ПЛОХОЙ пример: 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

Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией. --- ❓ Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?» ❌ Ответ новичка: «Secrets зашифрованы, поэтому безопасны». ✅ Ответ инженера: Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.

🪟 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" в описании

Важное предупреждение, которое Microsoft тихо упомянула в документации: устройства с включённым hotpatch могут падать при операции "Reset This PC" — после первой фазы сброса машина перезагружается обратно на рабочий стол с ошибкой. Это задокументированная проблема. Если у тебя есть сценарии переустановки через Push Button Reset — проверь это в лабе до мая. Зачем это нужно: Устройства, установившие апрельский baseline и соответствующие требованиям, начнут автоматически получать hotpatch-обновления с 11 мая 2026 года. Если ты ещё не готов — контроль отказа доступен с 1 апреля через Intune. Срок уже прошёл. Проверяй настройки сегодня. Итог: Меньше перезагрузок — это хорошо для uptime и для нервов пользователей. Но "включилось само" в enterprise без понимания механики — это риск. Проверь VBS на всём парке, убедись в апрельском baseline и реши явно: включаешь или отключаешь. Случайных изменений в инфраструктуре не бывает. #windows #hotpatch #intune #autopatch #patching #sysadmin #admin_future

🧠 Skills: Домашняя лаборатория — лучшая инвестиция в карьеру сисадмина Коллеги, разговор о том, что разделяет администраторов, которые растут, от тех, кто стоит на месте. Ответ чаще всего один — наличие личной лаборатории. Домашняя лаборатория — безопасное место для провалов, экспериментов и роста без страха положить продакшн. Облако не заменило homelab. Лаборатория стала ещё актуальнее — это место, где можно практиковать Git, IaC, CI/CD и контейнеры бесплатно, не получив счёт на 100 тысяч долларов из облака. Минимальный стартовый стек в 2026 году:

ЖЕЛЕЗО (один сервер — уже лаборатория):
  Б/у десктоп / NUC: 32GB RAM, SSD 512GB
  Или: старый игровой ноут с 16GB RAM
  Гипервизор: Proxmox VE (бесплатно)

СЕРВИСЫ ДЛЯ ПРАКТИКИ:
  - Proxmox + несколько VM: Linux + Windows Server
  - Self-hosted Git (Gitea) — всё в Git с первого дня
  - Ansible — автоматизируем конфиги вместо ручного тыка
  - Prometheus + Grafana — мониторинг как в продакшне
  - WireGuard — VPN для удалённого доступа к лабе

ЧТО ПРАКТИКОВАТЬ:
  Неделя 1-2: поднять Proxmox, создать несколько VM
  Неделя 3-4: настроить сеть, VLAN, DNS
  Месяц 2:    Ansible playbook для автодеплоя Ubuntu/WinServer
  Месяц 3:    Kubernetes (k3s) + мониторинг
  Месяц 4+:   Сломай и восстанови. Повтори.

Онлайн-лабы имеют много страховочных сеток и мягких стен. Лучше всего учишься, когда реально что-то ломаешь и сам чинишь. В курсах редко кто запоминает детали — большинство усваивает общие концепции. Настоящее понимание приходит через самостоятельный разбор проблем. Зачем это нужно: Переход от рутины к стратегическому планированию инфраструктуры — вот реальный карьерный рост администратора. Специалист, который умеет строить воспроизводимую, автоматизированную инфраструктуру — это уже другой грейд и другая зарплата. Итог: лаборатория — это не хобби. Это твой личный учебный полигон, где можно освоить то, что в продакшне трогать страшно. Начни с одного старого ПК и Proxmox. Дальше само затянет. #skills #homelab #карьера #proxmox #sysadmin #admin_future

Итог: ИИ — это очень хороший стажёр с фотографической памятью и нулевым чувством ответственности. Он делает то что просишь, не думает о последствиях и иногда уверенно врёт. Твоя задача — быть опытным тимлидом этого стажёра, а не слепо доверять его выводам. #skills #AI #автоматизация #sysadmin #карьера #powershell #admin_future

🧠 Skills: Как правильно использовать ИИ в работе администратора — без иллюзий и без паники Коллеги, разговор, которого многие избегают, потому что тема кажется либо хайпом, либо угрозой. Ни то ни другое. Это просто новый инструмент — и как любой инструмент, он работает хорошо там, где его применение осмысленно, и создаёт проблемы там, где его применяют вслепую. Первый честный тезис: ИИ не заменит системного администратора в 2026 году. Он заменит конкретные задачи — и освободит время для задач более высокого уровня. Это не успокоение, это факт: понимание инфраструктуры, принятие решений под давлением, архитектурное мышление — это по-прежнему человеческая работа. Где ИИ реально помогает прямо сейчас — три конкретных паттерна:

ПАТТЕРН 1: ГЕНЕРАЦИЯ И ОТЛАДКА СКРИПТОВ

Плохой запрос:
"Напиши мне PowerShell-скрипт для AD"

Хороший запрос:
"Я Senior Systems Administrator. Среда: Windows Server 2025,
PowerShell 7.4, домен corp.local, модуль ActiveDirectory установлен.
Напиши скрипт который находит все неактивные компьютерные аккаунты
(не логинились больше 90 дней), экспортирует в CSV с полями:
Name, LastLogonDate, OU, Enabled.
Добавь обработку ошибок и -WhatIf параметр для безопасного тест-запуска."

Разница: второй запрос даёт рабочий результат с первого раза.
Контекст среды — это ключ. Без него ИИ галлюцинирует cmdlets.

ПАТТЕРН 2: ТРАБЛШУТИНГ КАК ДИАЛОГ

Ситуация: непонятная ошибка в логах, нет времени читать man.
Метод: вставить полный текст ошибки + контекст системы
и спросить "объясни что происходит и дай 3 гипотезы"

Пример:
"На RHEL 9 в journalctl вижу:
kernel: EXT4-fs error (device sdb1): ext4_find_entry:1455
Система: PostgreSQL 15, база на /dev/sdb1 ext4, kernel 6.18.
Что это может быть и что проверить в первую очередь?"

Результат: структурированные гипотезы, команды для диагностики.
Ты всё равно принимаешь решение — ИИ даёт карту возможностей.

ПАТТЕРН 3: ДОКУМЕНТАЦИЯ КАК ПОБОЧНЫЙ ПРОДУКТ

После решения инцидента: скармливаешь ИИ
- timeline событий из логов
- команды которые выполнял
- итог

Просишь: "Напиши postmortem по этому инциденту в формате:
Timeline / Root Cause / Impact / Actions Taken / Prevention"

За 2 минуты получаешь структурированный документ.
Который раньше не писал вообще, потому что "некогда".

Где ИИ НЕ стоит использовать без проверки:

КРАСНЫЕ ФЛАГИ:

[!] Любые деструктивные операции без -WhatIf / --dry-run
    Всегда тестируй сгенерированный скрипт в тестовой среде

[!] Конфигурации безопасности (firewall rules, SELinux policies)
    ИИ не знает твою топологию — он угадывает

[!] Чувствительные данные в промпте
    Не вставляй пароли, ключи, имена пользователей в публичные ИИ

[!] "ИИ сказал что так правильно" как аргумент
    ИИ уверенно ошибается. Всегда проверяй по официальной документации

Практический подход — три правила зрелого использования ИИ: Первое — контекст решает всё. Чем точнее описана среда (ОС, версия, конкретная задача, ограничения), тем выше качество ответа. Потрать 30 секунд на формулировку — сэкономишь 30 минут на исправление. Второе — ИИ как черновик, не как финал. Каждый сгенерированный скрипт читай как код коллеги на code review: понимаешь ли что делает каждая строка? Нет — разбирай дальше или переписывай. Третье — документируй промпты которые работают. Если нашёл промпт который даёт хорошие результаты для регулярной задачи (аудит AD, проверка сертификатов, генерация отчётов) — сохрани его в своём репозитории промптов. Это твои инструменты, не одноразовые запросы. Зачем это важно: Инженер, который умеет правильно использовать ИИ, решает за день то, на что раньше уходила неделя. Не потому что ИИ умнее — а потому что рутинная часть задачи делается быстрее, и остаётся больше времени на то, что требует реального опыта и суждения. В 2026 году это уже конкурентное преимущество на рынке труда, а не опциональный навык.

🪟 Windows: Secure Boot 2011 → 2026 — у тебя есть два месяца до истечения сертификатов Коллеги, это тот случай, когда Microsoft предупреждает заранее и громко — но в суете патч-вторников и инцидентов это всё равно тонет. Поэтому говорим сегодня, пока ещё есть время. Сертификаты Secure Boot, которые Microsoft выпустила в 2011 году, начинают истекать в июне 2026 года. Затронуты физические и виртуальные машины на всех поддерживаемых версиях: Windows 10, Windows 11, Windows Server 2016, 2019, 2022, 2025 — всё железо с 2012 года. Что произойдёт если не обновить: устройства продолжат запускаться и работать нормально, стандартные обновления Windows продолжат устанавливаться. Однако они больше не смогут получать новые средства защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва и средства защиты от вновь обнаруженных уязвимостей уровня загрузки. С октября 2026 года — никаких security-фиксов для Windows Boot Manager. Критический нюанс для серверов: в отличие от клиентских Windows-машин, которые получают сертификаты 2023 года автоматически через Windows Update, Windows Server требует ручного действия. Сертификаты на сервера автоматически не прилетают. Аудит и обновление прямо сейчас:

# ШАГ 1 — Инвентаризация: проверяем статус на каждом сервере

# Проверяем текущий статус обновления сертификатов
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status" -ErrorAction SilentlyContinue |
    Select-Object UEFICA2023Status

# Возможные значения:
# (пусто / ключ отсутствует) = обновление не начато
# "InProgress"               = в процессе
# "Updated"                  = готово, сертификаты 2023 установлены

# Проверяем включён ли Secure Boot вообще
Confirm-SecureBootUEFI

# Проверяем через Event Log — Event ID 1808 = сертификаты успешно обновлены
Get-WinEvent -LogName System |
    Where-Object {$_.Id -eq 1808} |
    Select-Object TimeCreated, Message |
    Format-List

# ШАГ 2 — Для серверов БЕЗ сертификатов 2023: запускаем обновление вручную

# Инициируем обновление Secure Boot certificates
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
    -Name "AvailableUpdates" `
    -Value 0x5944

# Запускаем scheduled task для обновления
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

# Смотрим статус — должен появиться "InProgress"
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status"

# ПЕРЕЗАГРУЖАЕМ сервер, затем запускаем task ещё раз
Restart-Computer -Force
# После перезагрузки:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Статус должен смениться на "Updated"

# ШАГ 3 — Массовый аудит через домен (все серверы сразу)
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -ExpandProperty Name

$results = foreach ($server in $servers) {
    try {
        $status = Invoke-Command -ComputerName $server -ScriptBlock {
            $s = Get-ItemProperty `
                -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
            [PSCustomObject]@{
                Server = $env:COMPUTERNAME
                Status = if ($s) { $s.UEFICA2023Status } else { "NotStarted" }
                SecureBootEnabled = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
            }
        } -ErrorAction Stop
        $status
    } catch {
        [PSCustomObject]@{Server = $server; Status = "Unreachable"; SecureBootEnabled = $null}
    }
}

$results | Sort-Object Status | Export-Csv "secureboot_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$results | Group-Object Status | Format-Table Name, Count

Зачем это важно для карьеры: Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных. Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер. #skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future

🧠 Skills: Мониторинг vs Observability — в чём разница и почему это важно для карьеры Коллеги, разговор о вещи, которая кажется очевидной, но на практике разделяет инфраструктурных инженеров на два поколения. Мониторинг — это когда знаешь заранее, что может сломаться, и смотришь на это. Дашборд с CPU, памятью, диском, статусом сервиса. Алерт когда CPU > 90%. Всё понятно, всё предсказуемо. Observability — это когда можешь понять, что сломалось, даже если не знал заранее о такой поломке. Это способность задавать произвольные вопросы к системе в любой момент — без предварительной настройки метрики для каждого конкретного случая. Разница не в инструментах. Разница в том, как мы думаем об инфраструктуре. Два де-факто открытых стандарта в observability сегодня — Prometheus и OpenTelemetry. 65% организаций инвестируют в оба. Prometheus зрелее и больше используется в production (59%), OpenTelemetry быстрее растёт — 35% сейчас находятся на стадии POC и готовятся к масштабированию. Практика: строим минимальный observability-стек на своём парке серверов:

# docker-compose.yml — базовый стек: Prometheus + Grafana + Node Exporter
# Разворачивается за 10 минут, даёт реальную видимость

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'  # Храним 30 дней истории
    ports:
      - "9090:9090"
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node_exporter
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    ports:
      - "9100:9100"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme_immediately
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

# prometheus.yml — базовая конфигурация
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  # Сам Prometheus
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Метрики хоста
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']
        labels:
          env: 'production'
          datacenter: 'main'

  # Если есть несколько серверов — добавляем все
  - job_name: 'servers'
    static_configs:
      - targets:
          - '192.168.1.10:9100'
          - '192.168.1.11:9100'
          - '192.168.1.12:9100'

# Три PromQL-запроса, которые реально нужны каждый день:

# 1. Топ-5 процессов по CPU (не просто средний по системе)
topk(5, rate(namedprocess_namegroup_cpu_seconds_total[5m]))

# 2. Свободное место на дисках с предсказанием когда кончится
predict_linear(node_filesystem_avail_bytes[6h], 4*3600) < 0

# 3. Доступная память — реальная, не та что показывает free
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

Ключевая идея: observability as code — это когда конфигурации мониторинга управляются как код: версионируются в Git, проходят code review, разворачиваются через те же CI/CD-пайплайны, что и инфраструктура. Те же инструменты, те же принципы. Что это значит на практике: дашборды и алерты живут в репозитории. Когда поднимается новый сервер через IaC — мониторинг на него появляется автоматически. Когда сервер уходит — метрики перестают собираться и дашборд обновляется сам. Ноль ручной работы.

🧠 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:
  | Задача | Владелец | Дедлайн |
  |--------|----------|---------|
  | ...    | ...      | ...     |

ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
  ❌ "Инженер не заметил алерт"
  ✅ "Алерт не имел достаточного приоритета в системе"
  ❌ "админ забыл обновить конфиг"
  ✅ "Процедура деплоя не включала проверку конфигурации"

Зачем это нужно: Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся. Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация. #skills #oncall #incident #postmortem #sysadmin #sre #admin_future

🧠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

🧠 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

Зачем это нужно: Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске. Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости. #skills #documentation #runbook #sysadmin #teamwork #admin_future