🪟 Windows: WinGet Configuration — настраиваем рабочее место через YAML 📝

В 2026 году ручная установка софта в Windows — это моветон. Microsoft активно развивает WinGet Configuration (на базе Desired State Configuration — DSC). Теперь ты можешь описать всё состояние системы в одном YAML-файле и применить его на новом сервере или ноутбуке сотрудника.

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

Пример конфигурационного файла (config.yaml):

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

Команда для применения:

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

Зачем это нужно: Это «Terraform для локальной Windows».
Один файл — и через 5 минут у тебя настроенная машина со всеми админскими утилитами.

#windows #automation #winget #dsc #devops #sysadmin #admin_future

🛡️ VPN Wars 2026: Старая школа IPsec против дерзкого WireGuard

Когда дело касается безопасности сетей, выбор протокола — это не только вопрос скорости, но и вопрос того, сколько седых волос у тебя прибавится при дебаге.

🏛️ IPsec: Швейцарский нож из 90-х

IPsec — это стандарт де-факто для корпоративного сектора (Site-to-Site). Он мощный, тяжелый и умеет всё.

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

⚡ WireGuard: Криптографический скальпель

WireGuard перевернул мир VPN. Вместо того чтобы поддерживать всё подряд, он использует только современные и быстрые алгоритмы (ChaCha20, Poly1305, Curve25519).

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

—-

📊 Сравнение в цифрах и фактах

| Характеристика | IPsec (IKEv2) | WireGuard |
| Сложность кода | Огромная (100k+ строк) | Минимальная (~4k строк) |
| Скорость | Высокая (с hardware offload) | Максимальная (даже без offload) |
| Настройка |"Вызовите экзорциста" | 5 минут в текстовом конфиге |
| Крипто-гибкость | Можно выбрать любой шифр | Один набор (только самые лучшие) |
| Стелс-режим | Легко детектируется | Тишина (не отвечает, если ключ неверный) |

---

🛠️ Команды для проверки

Если туннель «прилег», не паникуй. Используй эти команды для диагностики:

Для WireGuard:

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

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

Для IPsec (StrongSwan/Libreswan):

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

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

Вердикт Admin Future: В 2026 году, если у тебя нет жесткого требования от «безопасников» использовать сертифицированный ГОСТ-IPsec, твой выбор — WireGuard. Он проще в поддержке, быстрее и безопаснее за счет меньшей поверхности атаки.

#networking #vpn #ipsec #wireguard #security #sysadmin #devops #admin_future

🔍 ELK vs Loki: Как не утонуть в логах и не разорить компанию на дисках

Логи — это «черный ящик» твоего сервера. Но когда серверов 50, а контейнеров 500, смотреть их по отдельности невозможно.
Нужно решение, которое соберет всё в одну кучу и даст удобный поиск.

🏛️ ELK Stack (Elasticsearch, Logstash, Kibana)

Это «золотой стандарт» индустрии.

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

Пример конфига Logstash (Input/Filter):

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

⚡ Grafana Loki

«Prometheus для логов». В 2026 году Loki стал выбором номер один для Kubernetes и облачных сред.

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

Пример конфига Promtail (агент Loki):

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

---

📊 Что выбрать сисадмину?

| Характеристика | ELK (Elasticsearch) | Loki |
| --- | --- | --- |
| Индексация | Полный текст (Full-text) | Только метки (Labels) |
| Потребление RAM | Очень высокое | Низкое |
| Стоимость хранения | Дорого (нужны быстрые диски) | Дешево (S3/MinIO) |
| Сложность настройки | Высокая | Средняя |
| Лучшее применение | Анализ бизнес-данных, аудит | Технический мониторинг, K8s |

Вердикт Admin Future: Если тебе нужно быстро грепать логи из контейнеров и ты не хочешь тратить на сервер мониторинга больше ресурсов, чем на сами сервисы — ставь Loki. Если же ты работаешь в банке или крупном e-commerce, где нужно строить сложные дашборды по каждой транзакции — твой выбор ELK.

#logging #elk #loki #grafana #devops #sysadmin #monitoring #admin_future

🎓 Собеседование сисадмина. Выпуск #5: Сетевой фундамент (OSI и BGP)

Привет, коллеги! Сегодня мы разберем вопросы, которые 100% прозвучат на собеседовании на позицию Middle/Senior. Забудьте про скучное зазубривание названий уровней — будем говорить о том, как это работает «в полях».

❓ Вопрос 1: «Расскажите о модели OSI на примере открытия веб-страницы. На каком уровне работает Ping, а на каком — HTTPS?»
❌ Ответ новичка: Перечисляет уровни: Физический, Канальный... и так до Прикладного.
✅ Ответ инженера:

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

❓ Вопрос 2: «Что такое TCP Three-Way Handshake (тройное рукопожатие) и зачем оно нужно?»
❌ Ответ новичка: «Это когда сервер и клиент договариваются о связи».
✅ Ответ инженера:

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

❓ Вопрос 3: «BGP — это протокол маршрутизации. Но почему его называют "протоколом, на котором держится интернет", и как одна ошибка в нем может "уронить" полмира?»
❌ Ответ новичка: «Это сложный протокол для больших провайдеров».
✅ Ответ инженера:

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

💡 Золотое правило собеса: Если тебя просят объяснить OSI, всегда добавляй пример из жизни. Фраза «Если у нас проблема с сертификатом SSL — это уровень L7, но если не резолвится имя — это проблема DNS, которая тоже на L7, но проверять её надо отдельно» — сразу выдает в тебе практика.

Сохраняйте пост, чтобы не плавать в теории, когда спросят «за жизнь пакета»!


p.s. На вопрос «Куда делись 5 и 6 уровни?» смело отвечай:
В современной модели TCP/IP функции сеансового уровня и уровня представления были интегрированы непосредственно в приложения на прикладном уровне (Application), так как разработчикам проще управлять сессиями и форматами данных внутри софта, а не на уровне сетевого стека ОС.

#собеседование_AF #networking #osi #tcp #bgp #sysadmin #devops #admin_future

🚀 DevOps: Podman 5.0 — запускаем контейнеры без Root и лишних демонов 🛡️

Если ты всё еще используешь Docker-демона, который крутится под рутом, у нас для тебя новости из 2026 года. Podman окончательно стал взрослым. Главная фишка пятой версии — полностью переписанный сетевой стек (pasta), который сделал Rootless-контейнеры (запуск от обычного юзера) такими же быстрыми, как и обычные.

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

Команды для старта:

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

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

Зачем это нужно: Это стандарт безопасности. В 2026 году запуск Docker под root в продакшене без веской причины считается дурным тоном.

#devops #containers #podman #docker #security #sysadmin #admin_future

🎓 Собеседование сисадмина. Выпуск #6: Базы данных (Reliability & Scalability)

Привет, коллеги! Сегодня разберем три вопроса, которые проверяют твое понимание того, как данные «живут» на дисках и в сети.

❓ Вопрос 1: «Что такое репликация и в чем разница между Synchronous (Синхронной) и Asynchronous (Асинхронной) репликацией?»

❌ Ответ новичка: «Репликация — это когда данные копируются на другой сервер. Синхронная — это быстро, асинхронная — медленнее».
✅ Ответ инженера:

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

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

❓ Вопрос 2: «Что такое индексы в БД, и почему нельзя просто навесить их на каждую колонку таблицы "на всякий случай"?»

❌ Ответ новичка: «Индексы нужны для ускорения поиска. Если их много, то всё будет летать».
✅ Ответ инженера:

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

❓ Вопрос 3: «Как вы будете делать бэкап базы объемом в 1 ТБ, чтобы не "положить" сервис во время процесса?»

❌ Ответ новичка: «Сделаю mysqldump или pg_dump ночью, когда никто не пользуется».
✅ Ответ инженера:

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

💡 Золотое правило собеса: Если тебя спрашивают про базы, всегда упоминай мониторинг. Фраза «Я обязательно настрою алерты на Replication Lag (задержка репликации) и Disk Space» — это музыка для ушей любого тимлида.

Сохраняйте пост, чтобы не «поплыть», когда база скажет «ой»!

#собеседование_AF #database #mysql #postgresql #replication #backup #sysadmin #devops #admin_future

🧠 Skill: Doc-as-Code — почему твоя документация должна лежать в Git 📖

Старые Word-файлы с инструкциями и пыльные страницы в Wiki умирают в тот момент, когда их создали. В 2026 году админ использует подход Documentation as Code (DaC). Это значит, что документация пишется в Markdown, хранится в Git и живет рядом с кодом или конфигами.

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

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

Простой пример Markdown-структуры:

```markdown
# Инструкция: Восстановление БД из бэкапа
## Шаги:
1. Зайти на сервер `db-backup-01`.
2. Выполнить команду: `cat backup.sql | psql database`.
> Важно: Перед этим проверьте наличие свободного места в `/var/lib/postgresql`.

```

Вывод: Навык работы с Markdown и Git-флоу для документации делает тебя системным инженером нового уровня, чьи знания не потеряются при сбое Wiki-сервера.

#skills #documentation #markdown #git #devops #sysadmin #admin_future

🍦 Священная Read-Only Friday: Искусство вовремя убрать руки от клавиатуры

В мире системного администрирования есть легенда о «Последнем Коммите». О том самом «незначительном исправлении», которое вносится в пятницу в 17:00, а в 19:00 превращается в тыкву, блокирующую выезды из города, семейные ужины и здоровый сон.

🚫 Почему мы не катим в пятницу?

Это не лень. Это управление рисками.
Любое изменение в сложной системе имеет период «дозревания». Баги, утечки памяти или конфликты зависимостей редко проявляются в первые пять минут. Им нужно время под нагрузкой. Если ты вносишь изменения в понедельник — у тебя есть четыре дня, чтобы всё исправить в рабочем режиме. В пятницу вечером ты остаешься один на один с монитором, пока остальной мир отдыхает.

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

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

🛠 Чем заняться, если руки чешутся?

Read-Only — это не «ничегонеделание». Это время для задач, которые обычно откладываются «на потом» из-за текучки.

1. Инвентаризация и аудит. Пройдись по списку софта. Где-то наверняка висят тестовые виртуалки, которые уже три месяца просто едят ресурсы. Прибей их (но сначала убедись трижды!).
2. Документация. Самый скучный, но важный пункт. Опиши ту самую «кривую» схему проброса портов, которую ты собрал на коленке в прошлом месяце. Твой будущий «Я», когда сервер упадет в 3 часа ночи, скажет тебе спасибо.
3. Автоматизация отчетов. Напиши скрипт, который будет каждое утро присылать тебе в Telegram статус бэкапов или место на дисках. Это безопасная работа, которая не трогает продакшен.
4. Самообразование. Почитай про eBPF, разберись с новыми фишками Kubernetes или посмотри доклад с недавней конференции. Инвестируй время в свои мозги, а не в потенциальные инциденты.

🧘‍♂️ Ментальное здоровье

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

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

Помни: Хорошего админа не видно и не слышно, когда всё работает. Пятница — лучший день, чтобы подтвердить это звание.

#longread #sysadmin #philosophy #readonlyfriday #devops #it_culture #admin_future

🚀 Skills: Инфраструктурный нигилизм. Почему «надежность» больше не цель

Помните, как мы гордились серверами с аптаймом в 500 дней? В 2026 году такой сервер — это позор и огромная дыра в безопасности. Если ваша система не перезагружалась полтора года, значит, она не видела патчей ядра, обновлений микрокода ARM и критических фиксов библиотек.

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

Главный навык админа сегодня — не «поддержать жизнь», а «уметь убить и воскресить». Мы переходим от концепции надежности железа к концепции Resilience (упругости). Инфраструктура должна быть эфемерной.

Под капотом: Мы внедряем **Immutability** (неизменяемость). Конфигурация сервера не правится руками через SSH. Если нужно изменить один параметр в `sysctl`, вы меняете его в коде (IaC), пересобираете образ и пересоздаете инстанс.

Практика:

Ваш рабочий день должен начинаться не с проверки мониторинга «всё ли зеленое», а с проверки «пройдет ли сегодня автоматический редеплой 10% инфраструктуры».

# Пример декларативного описания состояния (Inspec / Goss)
# Мы проверяем не "как долго оно работает", а "соответствует ли оно стандарту 2026 года"

file:
  /etc/ssh/sshd_config:
    exists: true
    contains:
      - "Protocol 2"
      - "PermitRootLogin no"
      - "PubkeyAuthentication yes"
      - "KexAlgorithms curve25519-sha256@libssh.org" # Квантово-устойчивые алгоритмы

command:
  check_kernel_version:
    exec: "uname -r"
    exit-status: 0
    stdout:
      - "6.12" # Мы не сидим на старье

Зачем это нужно:

Это избавляет вас от «дрейфа конфигураций» (configuration drift). Когда у вас 1000 серверов, вы не можете быть уверены, что на 734-м какой-то стажер не поправил конфиг руками в три часа ночи. Только полная пересборка гарантирует идентичность и предсказуемость.

Вывод: Ваша ценность как инженера — в скорости восстановления системы с нуля, а не в умении годами латать дырявое корыто.

#skills #iac #observability #resilience #devops #admin_future

🚀 Skills: GitOps Lite. Почему твой /etc должен быть репозиторием

Помнишь то чувство ужаса, когда ты поправил конфиг, сервис упал, а ты забыл, что именно изменил? В 2026 году фраза «я сейчас всё верну как было по памяти» звучит как признание в профнепригодности. Админ сегодня — это не тот, кто много помнит, а тот, кто всё записывает в Git.

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

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

Практика:
Начни внедрять GitOps на минималках прямо сейчас. Это спасет твою нервную систему:

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

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

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

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

Зачем это нужно:

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

#skills #git #iac #devops #bestpractices #admin_future

🚀 Skills: Платформенный инженер — Эволюция сисадмина

Мир меняется. В 2026 году границы между админом, DevOps и SRE окончательно размылись, породив концепцию Platform Engineering. Если ты до сих пор вручную создаешь виртуалки по заявкам в Jira, ты рискуешь стать «узким местом» для всей компании.

Кто такой платформенный инженер:

Это админ, который не делает работу за других, а создает инструменты (Self-Service), чтобы другие могли сделать её сами.

Как сменить фокус:

1. От заявок к API: Вместо «напиши мне скрипт для бэкапа», дай разработчику кнопку в интерфейсе или CLI-утилиту, которая сделает это по шаблону.
2. Внутренний продукт: Твои «пользователи» — это другие айтишники в компании. Твоя задача — сделать их жизнь проще, создав надежную платформу (IDP — Internal Developer Platform).
3. Стандартизация: Вместо зоопарка из разных версий ОС и БД, создай «золотые образы» и шаблоны конфигураций, которые обновляются автоматически.

Зачем это нужно:

Чтобы не сгореть на работе. Платформенный подход позволяет одному человеку управлять инфраструктурой для сотен разработчиков без хаоса и ночных звонков. Это путь от «тушителя пожаров» к архитектору систем.

#skills #platformengineering #devops #career #automation #admin_future

📦 Linux: Наводим порядок в Docker — удаляем «висячие» ресурсы

Коллеги, признавайтесь: как часто вы заходите на сервер и обнаруживаете, что Docker сожрал всё место образами годичной давности и остановленными контейнерами, которые «может еще пригодятся»? В 2026-м контейнеризация повсюду, и мусор в /var/lib/docker — это главная причина алертов по дискам.

Не нужно удалять всё по отдельности. Есть одна команда-швейцарский нож, которая вычистит всё лишнее, не сломав работающий прод.

Магическая команда для терминала:

# Удаляем неиспользуемые контейнеры, сети и "висячие" (dangling) образы
docker system prune -f

# А если нужно вычистить ВООБЩЕ всё неиспользуемое (включая старые тома)
docker system prune -a --volumes -f

Чтобы не плодить сущности. Каждый docker build оставляет после себя слои, а каждый docker stop — мертвое тело контейнера. Регулярный запуск этой команды (лучше в cron раз в неделю) экономит десятки гигабайт и избавляет от путаницы при просмотре списка образов.

Вывод: Чистый Docker — залог быстрого деплоя. Не превращайте свой сервер в кладбище контейнеров.

#linux #docker #devops #cleanup #sysadmin #admin_future

🧠 Skills: Культура Blameless Post-Mortem — как чинить системы, а не людей

Все падают. Даже инфраструктура технологических гигантов периодически ложится отдыхать. Отличие сильной IT-команды от слабой заключается не в количестве инцидентов, а в том, что происходит на следующий день. В 2026 году метод поиска крайнего инженера — это прямой путь к деградации инфраструктуры. Встречайте концепцию Blameless Post-Mortem (Безобвинительный разбор инцидентов) из практик SRE.

Что это такое:

Это документ и встреча, цель которых — понять ПОЧЕМУ произошел сбой, а не КТО его устроил. Главный принцип: мы исходим из того, что каждый сотрудник в момент инцидента действовал с хорошими намерениями и принимал оптимальные решения на основе той информации и инструментов, которые у него были.

Как провести правильный Post-Mortem:

— Запрет на слово КТО: Вместо «Кто удалил боевую базу данных?» мы спрашиваем «Какая последовательность действий привела к удалению?» и «Почему система позволила это сделать без подтверждения?».
— Хронология — это база: Соберите точный таймлайн. Во сколько пришел алерт, когда начали чинить, когда восстановили. Только сухие факты из систем мониторинга и рабочих чатов без эмоциональных окрасов.
— План действий: Итогом должен стать список системных задач в трекере. Например: «Настроить права доступа так, чтобы деструктивные команды не работали на проде без апрува второго администратора».

Если за ошибку наказывают, инженеры начинают скрывать проблемы и не зовут на помощь до последнего. В культуре Blameless люди сами приходят и говорят: «Я нашел уязвимый процесс в наших регламентах, давайте закроем дыру, пока не рвануло».

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

#skills #sre #postmortem #management #devops #admin_future

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