🆚 Битва мониторинга: Zabbix vs Prometheus
Выбор системы мониторинга — это архитектурное решение. Нет «плохого» инструмента, есть неподходящий под задачу. Разберем, когда и что выбирать.
1. Zabbix: Классический «Комбайн»
Модель: Push & Pull. Централизованный сервер, агенты на хостах.
Сила: «Все в одном». Графики, алерты, карты сети, инвентаризация — всё из коробки. Отлично мониторит "железо", OS, стандартные сервисы.
Слабость: Тяжеловесный. Сложнее масштабировать на тысячи микросервисов. Хранит данные в SQL (MySQL/PostgreSQL), что может стать узким местом.
Вердикт: Идеален для Enterprise, статической инфраструктуры (Pet-servers), мониторинга сетевого оборудования.
2. Prometheus: Герой Cloud-Native
Модель: Pull (в основном). Сервер сам ходит к сервисам и забирает метрики (scraping).
Сила: Работает с Time Series Database (TSDB) — невероятно быстр для метрик. Создан для динамических сред (Kubernetes, Docker), где контейнеры живут минуты. Язык запросов PromQL очень гибок.
Слабость: Сам по себе «голый». Для визуализации нужен Grafana, для алертов — Alertmanager. Не хранит долгие исторические данные без доп. настройки (Thanos/VictoriaMetrics).
Вердикт: Стандарт де-факто для DevOps, микросервисов и K8s.
🏆 Итог: Строите завод или офис с принтерами и свичами? Zabbix. Поднимаете HighLoad кластер в Kubernetes? Prometheus + Grafana. Умный админ часто использует связку: Zabbix для железа, Prometheus для приложений.
#monitoring #zabbix #prometheus #devops #architecture #сравнение
Выбор системы мониторинга — это архитектурное решение. Нет «плохого» инструмента, есть неподходящий под задачу. Разберем, когда и что выбирать.
1. Zabbix: Классический «Комбайн»
Модель: Push & Pull. Централизованный сервер, агенты на хостах.
Сила: «Все в одном». Графики, алерты, карты сети, инвентаризация — всё из коробки. Отлично мониторит "железо", OS, стандартные сервисы.
Слабость: Тяжеловесный. Сложнее масштабировать на тысячи микросервисов. Хранит данные в SQL (MySQL/PostgreSQL), что может стать узким местом.
Вердикт: Идеален для Enterprise, статической инфраструктуры (Pet-servers), мониторинга сетевого оборудования.
2. Prometheus: Герой Cloud-Native
Модель: Pull (в основном). Сервер сам ходит к сервисам и забирает метрики (scraping).
Сила: Работает с Time Series Database (TSDB) — невероятно быстр для метрик. Создан для динамических сред (Kubernetes, Docker), где контейнеры живут минуты. Язык запросов PromQL очень гибок.
Слабость: Сам по себе «голый». Для визуализации нужен Grafana, для алертов — Alertmanager. Не хранит долгие исторические данные без доп. настройки (Thanos/VictoriaMetrics).
Вердикт: Стандарт де-факто для DevOps, микросервисов и K8s.
🏆 Итог: Строите завод или офис с принтерами и свичами? Zabbix. Поднимаете HighLoad кластер в Kubernetes? Prometheus + Grafana. Умный админ часто использует связку: Zabbix для железа, Prometheus для приложений.
#monitoring #zabbix #prometheus #devops #architecture #сравнение
🔄 Windows Server 2025: Эра Hotpatching. Перезагрузки отменяются?
Мы привыкли: поставил патч → перезагрузил сервер → молишься, чтобы поднялся. В Windows Server 2025 (и через Azure Arc) технология Hotpatching становится мейнстримом. Как это работает под капотом?
Архитектура: Вместо замены файлов на диске, система патчит код в оперативной памяти работающего процесса.
Ядро загружает новую версию функции в память.
Ставит "трамплин" (jump) в начале старой функции, который перенаправляет поток выполнения на новую.
Состояние процесса сохраняется.
✅ Плюсы:
Аптайм 99.9% (ребут нужен только раз в квартал для кумулятивных обновлений).
Патчи весят меньше (только дельта кода).
Мгновенная установка.
❌ Минусы:
Требует Virtualization Based Security (VBS).
Пока лучше всего работает в связке с Azure Arc / Azure Automanage.
Мысль админа: Мы движемся к модели "Immutability" (неизменности), где сервер живет вечно без ребутов, либо пересоздается с нуля. Hotpatching — это мост между этими мирами.
#windows2025 #hotpatching #architecture #servercore #futureadmin
Мы привыкли: поставил патч → перезагрузил сервер → молишься, чтобы поднялся. В Windows Server 2025 (и через Azure Arc) технология Hotpatching становится мейнстримом. Как это работает под капотом?
Архитектура: Вместо замены файлов на диске, система патчит код в оперативной памяти работающего процесса.
Ядро загружает новую версию функции в память.
Ставит "трамплин" (jump) в начале старой функции, который перенаправляет поток выполнения на новую.
Состояние процесса сохраняется.
✅ Плюсы:
Аптайм 99.9% (ребут нужен только раз в квартал для кумулятивных обновлений).
Патчи весят меньше (только дельта кода).
Мгновенная установка.
❌ Минусы:
Требует Virtualization Based Security (VBS).
Пока лучше всего работает в связке с Azure Arc / Azure Automanage.
Мысль админа: Мы движемся к модели "Immutability" (неизменности), где сервер живет вечно без ребутов, либо пересоздается с нуля. Hotpatching — это мост между этими мирами.
#windows2025 #hotpatching #architecture #servercore #futureadmin
🆚 Reverse Proxy: Nginx vs Traefik
В 2025 году выбор прокси — это выбор парадигмы. Старая школа против Cloud-Native.
1. Nginx
Философия: «Конфиг — это закон». Всё прописывается в файлах .conf.
Плюсы: Невероятная производительность (C++), кэширование, работа со статикой, стандарт индустрии.
Минусы: Для обновления конфига нужен reload. В динамической среде (где контейнеры создаются и умирают ежеминутно) требует «костылей» (шаблонизаторы типа consul-template).
Вердикт: Идеален как фронт-балансировщик, ingress-контроллер для монолитов и отдачи статики.
2. Traefik
Философия: «Конфиг — это Discovery». Он сам слушает Docker/Kubernetes API и на лету создает маршруты.
Плюсы: Магия автоматизации. Повесил лейбл на контейнер — Traefik уже знает, куда слать трафик и сам выписал Let's Encrypt сертификат. Встроенный Dashboard.
Минусы: Медленнее Nginx на высоком трафике (написан на Go). Сложнее в тонкой настройке заголовков/буферов.
Вердикт: Король микросервисов и Docker Swarm/K8s.
📌 Итог: Если у вас статические IP и виртуальные машины — ставьте Nginx. Если у вас Docker/K8s и сервисы скачут по нодам — Traefik сэкономит вам сотни часов написания конфигов.
#devops #nginx #traefik #proxy #architecture #сравнение
В 2025 году выбор прокси — это выбор парадигмы. Старая школа против Cloud-Native.
1. Nginx
Философия: «Конфиг — это закон». Всё прописывается в файлах .conf.
Плюсы: Невероятная производительность (C++), кэширование, работа со статикой, стандарт индустрии.
Минусы: Для обновления конфига нужен reload. В динамической среде (где контейнеры создаются и умирают ежеминутно) требует «костылей» (шаблонизаторы типа consul-template).
Вердикт: Идеален как фронт-балансировщик, ingress-контроллер для монолитов и отдачи статики.
2. Traefik
Философия: «Конфиг — это Discovery». Он сам слушает Docker/Kubernetes API и на лету создает маршруты.
Плюсы: Магия автоматизации. Повесил лейбл на контейнер — Traefik уже знает, куда слать трафик и сам выписал Let's Encrypt сертификат. Встроенный Dashboard.
Минусы: Медленнее Nginx на высоком трафике (написан на Go). Сложнее в тонкой настройке заголовков/буферов.
Вердикт: Король микросервисов и Docker Swarm/K8s.
📌 Итог: Если у вас статические IP и виртуальные машины — ставьте Nginx. Если у вас Docker/K8s и сервисы скачут по нодам — Traefik сэкономит вам сотни часов написания конфигов.
#devops #nginx #traefik #proxy #architecture #сравнение
🏗 Архитектура: Как НЕ нужно называть домен Active Directory
Вы поднимаете новый контроллер домена. Рука тянется написать company.local? Остановитесь. Имя домена AD выбирается один раз, а последствия вы будете разгребать годами. Миграция/переименование домена — это ад, которого лучше избежать на старте.
Вот 3 главные ошибки и одно правильное решение.
❌ Ошибка 1: Зона .local (company.local) Классика 2000-х, которая в 2025 году стала проблемой.
Почему плохо: Конфликтует с протоколом mDNS (Bonjour), который используют macOS, Linux и IoT-устройства для поиска соседей.
Последствия: Глюки при подключении маков, принтеров и Linux-серверов. Плюс — вы никогда не купите доверенный SSL-сертификат для .local.
❌ Ошибка 2: Совпадение с публичным сайтом (company.ru) Называете AD так же, как ваш внешний сайт.
Почему плохо: Привет, Split-Brain DNS. Контроллеры домена считают, что company.ru — это они.
Последствия: Юзеры внутри офиса вводят company.ru, чтобы попасть на сайт фирмы, а попадают на страницу входа IIS контроллера домена (или получают ошибку). Приходится костылить www и мучаться с записями.
❌ Ошибка 3: Однословные имена (CORP) Single Label Domains (SLD).
Почему плохо: Устарело. Многие современные приложения (включая продукты Microsoft) просто откажутся работать с таким доменом корректно.
✅ Как сделать правильно (Best Practice)
Используйте субдомен от вашего реального публичного домена.
Пример: если ваш сайт future-admin.ru, назовите AD: 👉 corp.future-admin.ru 👉 ad.future-admin.ru 👉 int.future-admin.ru
В чем профит:
SSL: Вы можете купить Wildcard-сертификат *.corp.future-admin.ru и он будет валиден везде.
DNS: Никаких конфликтов с внешним сайтом.
Azure/Entra ID: Идеальная синхронизация с облаком без лишних суффиксов.
Собственность: Вы гарантированно владеете этим пространством имен в интернете.
💡 Совет архитектора: Даже если у вас маленькая фирма «Рога и Копыта», стройте AD так, будто завтра вы будете интегрироваться с Azure или поглощать конкурентов.
#activedirectory #windows #architecture #bestpractice #dns #security
Вы поднимаете новый контроллер домена. Рука тянется написать company.local? Остановитесь. Имя домена AD выбирается один раз, а последствия вы будете разгребать годами. Миграция/переименование домена — это ад, которого лучше избежать на старте.
Вот 3 главные ошибки и одно правильное решение.
❌ Ошибка 1: Зона .local (company.local) Классика 2000-х, которая в 2025 году стала проблемой.
Почему плохо: Конфликтует с протоколом mDNS (Bonjour), который используют macOS, Linux и IoT-устройства для поиска соседей.
Последствия: Глюки при подключении маков, принтеров и Linux-серверов. Плюс — вы никогда не купите доверенный SSL-сертификат для .local.
❌ Ошибка 2: Совпадение с публичным сайтом (company.ru) Называете AD так же, как ваш внешний сайт.
Почему плохо: Привет, Split-Brain DNS. Контроллеры домена считают, что company.ru — это они.
Последствия: Юзеры внутри офиса вводят company.ru, чтобы попасть на сайт фирмы, а попадают на страницу входа IIS контроллера домена (или получают ошибку). Приходится костылить www и мучаться с записями.
❌ Ошибка 3: Однословные имена (CORP) Single Label Domains (SLD).
Почему плохо: Устарело. Многие современные приложения (включая продукты Microsoft) просто откажутся работать с таким доменом корректно.
✅ Как сделать правильно (Best Practice)
Используйте субдомен от вашего реального публичного домена.
Пример: если ваш сайт future-admin.ru, назовите AD: 👉 corp.future-admin.ru 👉 ad.future-admin.ru 👉 int.future-admin.ru
В чем профит:
SSL: Вы можете купить Wildcard-сертификат *.corp.future-admin.ru и он будет валиден везде.
DNS: Никаких конфликтов с внешним сайтом.
Azure/Entra ID: Идеальная синхронизация с облаком без лишних суффиксов.
Собственность: Вы гарантированно владеете этим пространством имен в интернете.
💡 Совет архитектора: Даже если у вас маленькая фирма «Рога и Копыта», стройте AD так, будто завтра вы будете интегрироваться с Azure или поглощать конкурентов.
#activedirectory #windows #architecture #bestpractice #dns #security
👍1
🐢 Сервер тормозит: Метод USE
«Всё тормозит» — худшая заявка от пользователя. С чего начать диагностику? Не тыкайте наугад в top. Используйте методологию USE, разработанную Бренданом Греггом (гуру производительности).
Shutterstock
Для каждого ресурса (CPU, Memory, Disk, Network) проверяем три параметра:
U — Utilization (Утилизация): Сколько времени ресурс был занят работой? (Например, диск загружен на 90%).
S — Saturation (Насыщение): Есть ли очередь задач, которые не могут обработаться? (Высокий Load Average при низкой утилизации CPU).
E — Errors (Ошибки): Есть ли явные ошибки оборудования или драйвера? (Dropped packets, I/O errors).
Шпаргалка команд для Linux:
CPU: vmstat 1, top (Utilization), uptime (Saturation).
Memory: free -m (Utilization), vmstat 1 (si/so - Saturation/Swapping).
Disk: iostat -xz 1 (%util, await).
Network: sar -n DEV 1, ip -s link (Errors/Drops).
Сначала ищем узкое место, потом лечим.
#performance #linux #troubleshooting #architecture #brendangregg
«Всё тормозит» — худшая заявка от пользователя. С чего начать диагностику? Не тыкайте наугад в top. Используйте методологию USE, разработанную Бренданом Греггом (гуру производительности).
Shutterstock
Для каждого ресурса (CPU, Memory, Disk, Network) проверяем три параметра:
U — Utilization (Утилизация): Сколько времени ресурс был занят работой? (Например, диск загружен на 90%).
S — Saturation (Насыщение): Есть ли очередь задач, которые не могут обработаться? (Высокий Load Average при низкой утилизации CPU).
E — Errors (Ошибки): Есть ли явные ошибки оборудования или драйвера? (Dropped packets, I/O errors).
Шпаргалка команд для Linux:
CPU: vmstat 1, top (Utilization), uptime (Saturation).
Memory: free -m (Utilization), vmstat 1 (si/so - Saturation/Swapping).
Disk: iostat -xz 1 (%util, await).
Network: sar -n DEV 1, ip -s link (Errors/Drops).
Сначала ищем узкое место, потом лечим.
#performance #linux #troubleshooting #architecture #brendangregg
🔥2
🏗 Docker: Multistage Build — худеем в 10 раз
Типичная ошибка новичка: в Docker-образе лежат исходники, компиляторы (GCC, Go), кэши и сам бинарник. Образ весит 800 МБ. Архитектор использует Multistage Build.
Суть: в одном Dockerfile мы сначала собираем приложение, а потом копируем только результат в чистый, крошечный образ.
Пример (Go/C++/Rust):
Профит:
1. Размер: Было 800 МБ → Стало 20 МБ.
2. Безопасность: В проде нет компиляторов и исходного кода — хакеру сложнее развернуться.
3. Скорость: Быстрее пушится в Registry и скачивается на сервер.
Если ваши образы весят гигабайты — сегодня самое время их переписать.
#docker #devops #optimization #bestpractice #architecture
Типичная ошибка новичка: в Docker-образе лежат исходники, компиляторы (GCC, Go), кэши и сам бинарник. Образ весит 800 МБ. Архитектор использует Multistage Build.
Суть: в одном Dockerfile мы сначала собираем приложение, а потом копируем только результат в чистый, крошечный образ.
Пример (Go/C++/Rust):
# Этап 1: Сборка (Builder)
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp main.go
# Этап 2: Финал (Production)
# Берем Alpine (5 МБ) или Distroless
FROM alpine:latest
WORKDIR /root/
# Копируем ТОЛЬКО бинарник из первого этапа
COPY --from=builder /app/myapp .
CMD ["./myapp"]
Профит:
1. Размер: Было 800 МБ → Стало 20 МБ.
2. Безопасность: В проде нет компиляторов и исходного кода — хакеру сложнее развернуться.
3. Скорость: Быстрее пушится в Registry и скачивается на сервер.
Если ваши образы весят гигабайты — сегодня самое время их переписать.
#docker #devops #optimization #bestpractice #architecture
👍1
🔄 Идемпотентность: Главное слово в словаре архитектора
Если вы пишете скрипты или Ansible-плейбуки, вы обязаны понимать концепцию Идемпотентности. Без этого автоматизация превращается в хаос.
Определение: Операция считается идемпотентной, если её многократное повторение приводит к тому же результату, что и однократное выполнение, не вызывая ошибок и дублирования данных.
Пример на Bash:
❌ Не идемпотентно:
✅ Идемпотентно:
Почему это важно: В современном мире (Ansible, Terraform, Kubernetes) агент запускается каждые 15-30 минут. Если ваш скрипт не идемпотентен, он каждый раз будет ломать конфиги, дублировать строки или перезапускать сервисы без причины.
Правило: Пишите любой скрипт так, будто он будет запускаться каждую минуту.
#devops #architecture #coding #bestpractice #theory #automation
Если вы пишете скрипты или Ansible-плейбуки, вы обязаны понимать концепцию Идемпотентности. Без этого автоматизация превращается в хаос.
Определение: Операция считается идемпотентной, если её многократное повторение приводит к тому же результату, что и однократное выполнение, не вызывая ошибок и дублирования данных.
Пример на Bash:
❌ Не идемпотентно:
# Если запустить 2 раза, в файле будет две записи
echo "127.0.0.1 myapp.local" >> /etc/hosts
✅ Идемпотентно:
# Проверяем, есть ли запись, и добавляем только если нет
grep -q "myapp.local" /etc/hosts || echo "127.0.0.1 myapp.local" >> /etc/hosts
Почему это важно: В современном мире (Ansible, Terraform, Kubernetes) агент запускается каждые 15-30 минут. Если ваш скрипт не идемпотентен, он каждый раз будет ломать конфиги, дублировать строки или перезапускать сервисы без причины.
Правило: Пишите любой скрипт так, будто он будет запускаться каждую минуту.
#devops #architecture #coding #bestpractice #theory #automation
👑 PowerShell: Где мои FSMO роли?
Если ваш контроллер домена "приуныл", первое, что нужно знать — держит ли он FSMO (Flexible Single Master Operations) роли. Потеря рядового DC — это ерунда. Потеря PDC Emulator или Schema Master — это проблема.
Забудьте про netdom query fsmo. Делаем красиво через объекты.
Скрипт:
Pro Tip: Сохраните этот вывод. В случае аварии вы должны знать, какой именно сервер захватывать (Seize) принудительно.
#activedirectory #powershell #windows #fsmo #architecture
Если ваш контроллер домена "приуныл", первое, что нужно знать — держит ли он FSMO (Flexible Single Master Operations) роли. Потеря рядового DC — это ерунда. Потеря PDC Emulator или Schema Master — это проблема.
Забудьте про netdom query fsmo. Делаем красиво через объекты.
Скрипт:
# Получаем роли уровня Домена
$Domain = Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
# Получаем роли уровня Леса
$Forest = Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
# Выводим красивый отчет
Write-Host "🌲 Forest Roles:" -ForegroundColor Cyan
$Forest | Format-List
Write-Host "🏰 Domain Roles:" -ForegroundColor Cyan
$Domain | Format-List
Pro Tip: Сохраните этот вывод. В случае аварии вы должны знать, какой именно сервер захватывать (Seize) принудительно.
#activedirectory #powershell #windows #fsmo #architecture
metrics: SLA, SLO, SLI — Хватит путать эти аббревиатуры
На собеседовании на позицию Lead/Architect этот вопрос валит 50% кандидатов. Все говорят: «Ну, это про аптайм». Давайте разберем раз и навсегда.
1. SLI (Indicator) — Что мы меряем? Это конкретная метрика в графике.
Пример: Количество 500-х ошибок HTTP или Latency (задержка) ответа.
Факт: «Сейчас 99.5% запросов успешны».
2. SLO (Objective) — Какая у нас цель? Это внутренняя планка качества, к которой стремится команда.
Пример: «Мы хотим, чтобы 99.9% запросов были успешны».
Зачем: Если мы нарушаем SLO, мы останавливаем релизы новых фич и чиним стабильность (Error Budget).
3. SLA (Agreement) — За что нас накажут? Это внешний контракт с клиентом (юридический документ).
Пример: «Если аптайм упадет ниже 99.0%, мы вернем вам 30% оплаты».
Важно: SLA всегда ниже, чем SLO. У вас должен быть буфер безопасности.
Памятка архитектора: Не обещайте бизнесу 100% SLA. Это технически невозможно и бесконечно дорого. Обещайте «три девятки» (99.9%) и спите спокойно.
#sre #devops #metrics #sla #architecture #learning
На собеседовании на позицию Lead/Architect этот вопрос валит 50% кандидатов. Все говорят: «Ну, это про аптайм». Давайте разберем раз и навсегда.
1. SLI (Indicator) — Что мы меряем? Это конкретная метрика в графике.
Пример: Количество 500-х ошибок HTTP или Latency (задержка) ответа.
Факт: «Сейчас 99.5% запросов успешны».
2. SLO (Objective) — Какая у нас цель? Это внутренняя планка качества, к которой стремится команда.
Пример: «Мы хотим, чтобы 99.9% запросов были успешны».
Зачем: Если мы нарушаем SLO, мы останавливаем релизы новых фич и чиним стабильность (Error Budget).
3. SLA (Agreement) — За что нас накажут? Это внешний контракт с клиентом (юридический документ).
Пример: «Если аптайм упадет ниже 99.0%, мы вернем вам 30% оплаты».
Важно: SLA всегда ниже, чем SLO. У вас должен быть буфер безопасности.
Памятка архитектора: Не обещайте бизнесу 100% SLA. Это технически невозможно и бесконечно дорого. Обещайте «три девятки» (99.9%) и спите спокойно.
#sre #devops #metrics #sla #architecture #learning
🛡 Правило 3-2-1 устарело. Встречайте 3-2-1-1-0
Нас всех учили правилу бэкапов 3-2-1:
* 3 копии данных.
* 2 разных носителя.
* 1 копия офлайн (вне офиса).
В 2025 году, в эру программ-вымогателей (Ransomware), этого мало. Шифровальщики научились находить сетевые бэкапы и шифровать их тоже.
Новый стандарт — 3-2-1-1-0:
* 3 копии данных.
* 2 разных типа носителей.
* 1 копия вне офиса (Cloud/Remote).
* 1 копия Immutable (Неизменяемая) или Air-Gapped (Физически отключенная).
Immutable: Это флаг в S3 (AWS/MinIO) или Veeam Hardened Repository. Даже если хакер получит root-права, он не сможет удалить или зашифровать этот бэкап в течение заданного времени (например, 30 дней).
* 0 ошибок при проверке восстановления (SureBackup). Бэкап, который вы не тестово не развернули — это не бэкап, а надежда.
Проверьте свои репозитории. Если у вас нет Immutable-копии — вы беззащитны перед шифровальщиком.
#backup #security #ransomware #veeam #architecture #bestpractice
Нас всех учили правилу бэкапов 3-2-1:
* 3 копии данных.
* 2 разных носителя.
* 1 копия офлайн (вне офиса).
В 2025 году, в эру программ-вымогателей (Ransomware), этого мало. Шифровальщики научились находить сетевые бэкапы и шифровать их тоже.
Новый стандарт — 3-2-1-1-0:
* 3 копии данных.
* 2 разных типа носителей.
* 1 копия вне офиса (Cloud/Remote).
* 1 копия Immutable (Неизменяемая) или Air-Gapped (Физически отключенная).
Immutable: Это флаг в S3 (AWS/MinIO) или Veeam Hardened Repository. Даже если хакер получит root-права, он не сможет удалить или зашифровать этот бэкап в течение заданного времени (например, 30 дней).
* 0 ошибок при проверке восстановления (SureBackup). Бэкап, который вы не тестово не развернули — это не бэкап, а надежда.
Проверьте свои репозитории. Если у вас нет Immutable-копии — вы беззащитны перед шифровальщиком.
#backup #security #ransomware #veeam #architecture #bestpractice
🔥2
🧠 eBPF: Почему все о нем говорят?
Если вы слышите слово eBPF из каждого утюга, но боитесь спросить, что это — объясняем за 30 секунд.
Раньше, чтобы добавить новую фичу в ядро Linux (или глубоко отладить его), нужно было писать модуль ядра (Kernel Module). Ошибка в модуле = Kernel Panic (синий экран смерти).
eBPF (Extended Berkeley Packet Filter) — это безопасная виртуальная машина прямо внутри ядра Linux. Она позволяет запускать ваши скрипты (песочницу) в пространстве ядра без риска обрушить систему и без пересборки ядра.
Что это дает админу в 2025:
Супер-мониторинг: Утилиты нового поколения (типа bcc-tools) видят каждый чих системы, не нагружая её.
Сетевая магия: Инструменты типа Cilium фильтруют пакеты быстрее, чем iptables, потому что делают это до того, как пакет попадет в сетевой стек.
Попробовать прямо сейчас: Поставьте bpfcc-tools (Ubuntu) или bcc-tools (CentOS). Запустите execsnoop. Вы увидите каждый новый процесс, запускаемый в системе в реальном времени.
#linux #kernel #ebpf #future #architecture #learning
Если вы слышите слово eBPF из каждого утюга, но боитесь спросить, что это — объясняем за 30 секунд.
Раньше, чтобы добавить новую фичу в ядро Linux (или глубоко отладить его), нужно было писать модуль ядра (Kernel Module). Ошибка в модуле = Kernel Panic (синий экран смерти).
eBPF (Extended Berkeley Packet Filter) — это безопасная виртуальная машина прямо внутри ядра Linux. Она позволяет запускать ваши скрипты (песочницу) в пространстве ядра без риска обрушить систему и без пересборки ядра.
Что это дает админу в 2025:
Супер-мониторинг: Утилиты нового поколения (типа bcc-tools) видят каждый чих системы, не нагружая её.
Сетевая магия: Инструменты типа Cilium фильтруют пакеты быстрее, чем iptables, потому что делают это до того, как пакет попадет в сетевой стек.
Попробовать прямо сейчас: Поставьте bpfcc-tools (Ubuntu) или bcc-tools (CentOS). Запустите execsnoop. Вы увидите каждый новый процесс, запускаемый в системе в реальном времени.
#linux #kernel #ebpf #future #architecture #learning
🗺️ Карта сокровищ: Почему схема важнее твоей памяти
Представь: 3 января. Ты на даче, без связи. Падает критический сервис. Дежурный админ открывает консоль и видит мешанину из IP-адресов, контейнеров и балансировщиков. Он звонит тебе, но ты недоступен.
Ошибка Джуна: Держать архитектуру в голове. "Я же всё помню".
Правило Сеньора: То, что не задокументировано — не существует.
Перед праздниками сделай команде подарок — актуальную схему.
Почему это важно:
1. Bus Factor: Если завтра тебя переманят в Google, проект не должен встать.
2. Скорость траблшутинга: По схеме проблема локализуется за 5 минут ("Ага, это отвалился Redis-кэш"), в консоли — за час.
3. Онбординг: Новички скажут тебе спасибо.
Не обязательно рисовать в Visio. Используй draw.io или Mermaid (схемы как код). Главное — чтобы это было.
#skills #architecture #documentation #devops #mindset #busfactor
Представь: 3 января. Ты на даче, без связи. Падает критический сервис. Дежурный админ открывает консоль и видит мешанину из IP-адресов, контейнеров и балансировщиков. Он звонит тебе, но ты недоступен.
Ошибка Джуна: Держать архитектуру в голове. "Я же всё помню".
Правило Сеньора: То, что не задокументировано — не существует.
Перед праздниками сделай команде подарок — актуальную схему.
Почему это важно:
1. Bus Factor: Если завтра тебя переманят в Google, проект не должен встать.
2. Скорость траблшутинга: По схеме проблема локализуется за 5 минут ("Ага, это отвалился Redis-кэш"), в консоли — за час.
3. Онбординг: Новички скажут тебе спасибо.
Не обязательно рисовать в Visio. Используй draw.io или Mermaid (схемы как код). Главное — чтобы это было.
#skills #architecture #documentation #devops #mindset #busfactor
💾 RAID: Геометрия надежности
Мы говорим: "Поставь в RAID 10". А вы помните физику процесса? Визуальное понимание того, как лежат блоки, спасает при восстановлении массива.
Быстрый рекап по картинке:
1. RAID 0 (Stripe): Данные "размазаны" по дискам (A1, A2).
🚀 Скорость: Максимальная (xN).
💀 Надежность: Ноль. Сдох один диск — потеряли всё.
2. RAID 1 (Mirror): Данные дублируются (A1 = A1).
🛡️ Надежность: Высокая.
📉 Цена: Платим за 2 диска, получаем место как за 1.
3. RAID 5 (Parity): Данные + Контрольная сумма (Parity) размазаны по всем дискам.
⚖️ Баланс: Если один диск умер, данные вычисляются по формуле из остальных.
🐢 Минус: Медленная запись (надо считать контрольную сумму).
4. RAID 10: Зеркало (1) внутри Страйпа (0). Лучшее из двух миров, но дорого.
Сохраните схему. Когда джун спросит, почему RAID 5 тормозит на запись, просто покажите блок Parity.
#storage #raid #theory #hardware #architecture #infographics #basics
Мы говорим: "Поставь в RAID 10". А вы помните физику процесса? Визуальное понимание того, как лежат блоки, спасает при восстановлении массива.
Быстрый рекап по картинке:
1. RAID 0 (Stripe): Данные "размазаны" по дискам (A1, A2).
🚀 Скорость: Максимальная (xN).
💀 Надежность: Ноль. Сдох один диск — потеряли всё.
2. RAID 1 (Mirror): Данные дублируются (A1 = A1).
🛡️ Надежность: Высокая.
📉 Цена: Платим за 2 диска, получаем место как за 1.
3. RAID 5 (Parity): Данные + Контрольная сумма (Parity) размазаны по всем дискам.
⚖️ Баланс: Если один диск умер, данные вычисляются по формуле из остальных.
🐢 Минус: Медленная запись (надо считать контрольную сумму).
4. RAID 10: Зеркало (1) внутри Страйпа (0). Лучшее из двух миров, но дорого.
Сохраните схему. Когда джун спросит, почему RAID 5 тормозит на запись, просто покажите блок Parity.
#storage #raid #theory #hardware #architecture #infographics #basics
❤3
🧠 Skill: Навык «Технического пессимизма» — почему это хорошо 🏗
В IT есть термин — «Happy Path» (счастливый путь). Это когда всё работает идеально, как в мануале.
Но сисадмин-сеньор отличается от джуна тем, что всегда ищет «Unlucky Path».
Технический пессимизм — это умение при внедрении любой новой фичи задавать себе вопросы:
Это не паранойя, а проектирование отказоустойчивости.
Этот навык делает твою жизнь скучной в хорошем смысле слова — у тебя не случается «внезапных» катастроф, потому что ты к каждой из них уже подготовил план «Б».
#skills #mindset #sysadmin #architecture #reliability #admin_future
В IT есть термин — «Happy Path» (счастливый путь). Это когда всё работает идеально, как в мануале.
Но сисадмин-сеньор отличается от джуна тем, что всегда ищет «Unlucky Path».
Технический пессимизм — это умение при внедрении любой новой фичи задавать себе вопросы:
1. «Что, если этот диск умрет прямо сейчас?»
2. «Что, если скрипт автообновления скачает битый пакет?»
3. «Что произойдет, если этот контейнер упадет и не поднимется?»
Это не паранойя, а проектирование отказоустойчивости.
* Вместо «я просто обновлю базу», ты делаешь снапшот.
* Вместо «бэкап настроен», ты пробуешь его восстановить раз в месяц.
* Вместо «у нас один мощный канал интернета», ты закладываешь второй, пусть даже медленный.
Этот навык делает твою жизнь скучной в хорошем смысле слова — у тебя не случается «внезапных» катастроф, потому что ты к каждой из них уже подготовил план «Б».
#skills #mindset #sysadmin #architecture #reliability #admin_future
🔥2👍1👏1💯1
🧠 Skills: Собеседование сисадмина. Выпуск #13 — вопросы на архитектурное мышление
Коллеги, продолжаем рубрику. После 12 выпусков про конкретные технологии — пора разобрать тип вопросов, который действительно отделяет Senior от Middle. Это не вопросы на знание команд. Это вопросы на мышление.
Такие вопросы начинаются с "Как бы вы спроектировали..." или "Что бы вы сделали если...". Здесь нет единственно правильного ответа — есть правильный процесс мышления.
---
❓ Вопрос 1: «Вам нужно обеспечить доступность сервиса 99.9%. Как вы это спроектируете?»
❌ Ответ junior: "Поставим резервный сервер"
✅ Ответ инженера:
Начинаем с математики. 99.9% = 8.7 часов даунтайма в год. Это значит одна авария на несколько часов — и мы в рамках SLA. Дальше думаем откуда бывают падения:
---
❓ Вопрос 2: «Production упал. Действия?»
❌ Ответ junior: "Смотрю логи, перезапускаю сервисы"
✅ Ответ инженера — ответ через фреймворк:
---
❓ Вопрос 3: «Как бы вы мигрировали monolith на микросервисы не останавливая продакшн?»
❌ Ответ junior: "Переписали бы всё с нуля"
✅ Ответ инженера — Strangler Fig pattern:
💡 Золотое правило архитектурного собеса:
Интервьюер оценивает не правильность ответа, а структуру мышления. Хороший ответ: "Я бы начал с уточняющих вопросов..." Плохой ответ: сразу называет конкретное решение без понимания контекста.
#собеседование_AF #skills #architecture #sysadmin #карьера #admin_future
Коллеги, продолжаем рубрику. После 12 выпусков про конкретные технологии — пора разобрать тип вопросов, который действительно отделяет Senior от Middle. Это не вопросы на знание команд. Это вопросы на мышление.
Такие вопросы начинаются с "Как бы вы спроектировали..." или "Что бы вы сделали если...". Здесь нет единственно правильного ответа — есть правильный процесс мышления.
---
❓ Вопрос 1: «Вам нужно обеспечить доступность сервиса 99.9%. Как вы это спроектируете?»
❌ Ответ junior: "Поставим резервный сервер"
✅ Ответ инженера:
Начинаем с математики. 99.9% = 8.7 часов даунтайма в год. Это значит одна авария на несколько часов — и мы в рамках SLA. Дальше думаем откуда бывают падения:
ИСТОЧНИКИ НЕДОСТУПНОСТИ:
Железо → N+1 серверы, RAID, горячая замена
ОС / Software → Автоматический рестарт (systemd Restart=on-failure)
Деплой → Blue/Green, canary, rollback за 5 мин
Сеть → Два аплинка, bonding, BGP failover
Дата-центр → Два ЦОДа (Active/Passive или Active/Active)
Человек → Change management, maintenance window, runbook
Следующий вопрос интервьюеру: "Что именно входит в downtime по SLA?"
ICMP недоступность? Ответ > 2 сек? Ошибки > 1%?
Определение downtime меняет всю архитектуру.
---
❓ Вопрос 2: «Production упал. Действия?»
❌ Ответ junior: "Смотрю логи, перезапускаю сервисы"
✅ Ответ инженера — ответ через фреймворк:
1. ОЦЕНИВАЕМ МАСШТАБ (2 мин)
Что упало? Всё или часть?
Затронуты пользователи? Сколько?
Есть ли revenue impact? Уведомить бизнес?
2. КОММУНИКАЦИЯ (параллельно)
Статусная страница: incident opened
Stakeholders: уведомлены, ждут апдейта каждые 15 мин
Команда: war room открыт
3. МИТИГАЦИЯ ДО РАССЛЕДОВАНИЯ (если есть quick win)
Откат последнего деплоя если был недавно
Failover на резервный узел
Включение maintenance mode
4. ROOT CAUSE
Когда началось? (корреляция с изменениями)
Что изменилось? (деплои, патчи, конфиги, трафик)
Логи: что в момент начала падения?
5. FIX + VERIFY + POSTMORTEM
Не закрываем инцидент пока не уверены в причине.
Postmortem через 48ч — фокус на системе, не на людях.
---
❓ Вопрос 3: «Как бы вы мигрировали monolith на микросервисы не останавливая продакшн?»
❌ Ответ junior: "Переписали бы всё с нуля"
✅ Ответ инженера — Strangler Fig pattern:
Принцип: не заменяем монолит целиком,
а постепенно "душим" его новыми сервисами.
Шаг 1: Ставим reverse proxy перед монолитом
(nginx, Envoy — всё идёт через него)
Шаг 2: Выделяем НАИМЕНЕЕ связанный модуль
(обычно: авторизация, уведомления, отчёты)
Пишем его как отдельный сервис
Шаг 3: Переключаем трафик на новый сервис (1% → 10% → 100%)
Feature flag или weighted routing на прокси
Шаг 4: Мониторим: latency, error rate, бизнес-метрики
Всё хорошо → деплоим полностью
Хуже → мгновенный rollback через прокси
Шаг 5: Повторяем для следующего модуля
Монолит умирает постепенно — без единого "дня X".
Это занимает месяцы, но без простоя продакшна.
💡 Золотое правило архитектурного собеса:
Интервьюер оценивает не правильность ответа, а структуру мышления. Хороший ответ: "Я бы начал с уточняющих вопросов..." Плохой ответ: сразу называет конкретное решение без понимания контекста.
#собеседование_AF #skills #architecture #sysadmin #карьера #admin_future