🌐 Skill: "Zero Trust" — убиваем VPN ради безопасности и удобства 🔐

В 2026 году классический VPN (когда ты даешь юзеру доступ сразу ко всей подсети) — это дыра в безопасности. Тренд года — Identity-Aware Proxy (IAP). Это когда доступ дается не к сети, а к конкретному приложению (SSH, Web, DB) только после проверки личности через SSO.

Навык: Настройка Cloudflare Tunnel или Boundary от HashiCorp.

Почему это круче:

1. Сервер вообще не светит портами наружу (даже 80 и 443).

2. Юзеру не нужно включать VPN-клиент и ждать коннекта.

3. Полный аудит: ты видишь не "IP зашел в сеть", а "Админ Иван открыл SSH-сессию на сервер БД".

Команда (пример для Cloudflare Tunnel):

cloudflared tunnel run --url localhost:8080 my-internal-app

Это будущее корпоративных сетей.
Тот, кто умеет строить ZTNA (Zero Trust Network Access), стоит на рынке в два раза дороже обычного "VPN-мастера". 🚀

#devops #security #zerotrust #ztna #cloudflare #infrastructure #skills

🧠 Skill: Git Bisect — находим, кто сломал прод, за 5 минут 🕵️‍♂️

Ситуация: вчера деплой Terraform/Ansible работал.
Сегодня утром падает с ошибкой.
За ночь коллеги сделали 50 коммитов.
Читать каждый? Нет.

Используй бинарный поиск по истории git.

Алгоритм действий:

1. git bisect start — начинаем охоту.
2. git bisect bad — говорим: "сейчас всё плохо".
3. git bisect good v1.2 — говорим: "вот в теге v1.2 (три дня назад) всё работало".

Git сам переместит тебя ровно в середину истории. Ты проверяешь (запускаешь план).
Работает? Пишешь git bisect good.
Не работает? Пишешь git bisect bad.

За 4-5 шагов Git найдет тот самый коммит из сотни и покажет автора.

Результат: Ты не гадаешь, а математически точно находишь проблему. Это навык сеньор-уровня. 💎

#git #devops #troubleshooting #skill #versioncontrol #infrastructure #debug

🐧 Linux: Поднимаем локальное зеркало репозиториев, чтобы не зависеть от аплинка 📦

Когда kernel.org или зеркала Debian/Ubuntu становятся недоступны из-за ТСПУ, твоя инфраструктура рискует остаться без патчей безопасности. Решение для 2026 года — свой локальный кэширующий прокси или полноценное зеркало.

Инструмент: apt-cacher-ng (легкий) или debmirror (полная копия).

Как быстро настроить кэширующий сервер:

Установи: sudo apt install apt-cacher-ng

Теперь на всех остальных серверах в сети создай файл /etc/apt/apt.conf.d/00proxy:

Acquire::http::Proxy "http://IP_ТВОЕГО_СЕРВЕРА:3142";

Результат: Пакет скачивается из интернета только один раз первым сервером, остальные забирают его из локалки на скорости 10 Гбит/с. Даже если внешний канал упадет, ты сможешь переустанавливать софт на новых машинах.

#linux #apt #mirror #sysadmin #devops #infrastructure #offline #admin_future

🏷️ Skills: Искусство именования — Чтобы не гадать, что это за сервер

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

Хорошее имя сервера должно отвечать на три вопроса: Что это? Где это? Для чего это?

Правильная схема (Роль-Локация-Окружение-Индекс):

Пример: db-msk-prod-01

1. db — роль (database). Сразу ясно, что внутри.
2. msk — локация (Moscow). Понятно, в каком ДЦ искать.
3. prod — окружение (production/dev/test). Не перепутаешь, где можно проводить тесты.
4. 01 — порядковый номер. Для масштабирования.

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

Для автоматизации и твоего спокойствия. Если тебе прилетает алерт от zabbix-prod-02, ты сразу понимаешь критичность и где физически находится узел. Это упрощает написание скриптов (Ansible/PowerShell), где ты можешь обращаться к группам машин по маске имени.

Вывод: Порядок в именах — это порядок в голове и в коде.

#skills #infrastructure #naming #bestpractices #management #admin_future

🧠 Skills: CMDB — кладбище данных или реальный инструмент. Зависит от одного решения

Коллеги, у большинства из нас есть CMDB. У меньшинства она актуальна. Это не проблема инструмента — это проблема подхода.

Классический путь: потратили месяц на заполнение, полгода спустя данные устарели, никто не верит, никто не обновляет. Инструмент есть, пользы нет.

Главная ошибка — CMDB заполняется вручную и живёт отдельно от реальных изменений инфраструктуры. Основная проблема CMDB — сложность актуализации данных. Идея CMDB формировалась в эпоху статичных «железных» конфигураций. Для современных динамичных сред нужен другой подход.

Единственный подход который работает в 2026 — автообнаружение + IaC как источник истины:

РАБОЧАЯ СХЕМА ДЛЯ CMDB:

Источники данных (автоматически, не вручную):
  ├── Terraform/Ansible state → что задеплоено и как
  ├── Netbox/NetAct → сетевые устройства и IP
  ├── Zabbix/Prometheus → что живёт и что мониторится
  └── AD/Entra → пользователи и машины

Принцип: если изменение не прошло через IaC —
оно не существует с точки зрения CMDB.

Что хранить в CMDB (только это, ничего лишнего):
  [CI]        Сервер / VM / контейнер
  [Атрибуты]  ОС, IP, owner, окружение (prod/stage/dev)
  [Связи]     Что от чего зависит (БД → приложение → балансер)
  [Статус]    Active / Decommissioned / Maintenance

Что НЕ хранить:
  ✗ Версии ПО (это в Ansible inventory)
  ✗ Пароли и ключи (это в Vault)
  ✗ История изменений (это в Git)

Ключевой вопрос перед добавлением любого атрибута в CMDB: кто будет поддерживать это актуальным и как? Если ответа нет — атрибут не нужен.

Зачем это нужно:
CMDB с актуальными зависимостями отвечает на вопрос "что упадёт если я выключу этот сервер?" за секунды, а не за час расследования. Это разница между проактивным и реактивным администрированием.

Итог: хорошая CMDB — это не большая, а актуальная. Лучше 50 записей которым все верят, чем 5000 которые никто не читает.

#skills #cmdb #itsm #infrastructure #sysadmin #admin_future

🧠 Skills: Cattle vs Pets — принцип которому 15 лет, но половина инфраструктур его игнорирует

Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.

Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.

Как выглядят «питомцы» в реальной жизни:

ПРИЗНАКИ "ПИТОМЦА":
  - У сервера есть имя собственное: "Старый-Файловый",
    "Сервак-Богдана", "Этот-трогать-нельзя"
  - Никто не знает что на нём запущено кроме одного человека
  - Последний раз переустанавливали в 2019 году
  - Конфиги правились руками, в git не попадали
  - Апгрейд невозможен — "упадёт всё"

ПРИЗНАКИ "СКОТА":
  - Серверы называются по роли + номер: web-01, db-03
  - Любой сервер можно удалить и поднять заново за минуты
  - Конфигурация полностью в Ansible/Terraform
  - Нет уникальных ручных настроек которые нигде не записаны
  - Новый член команды может задеплоить среду с нуля

Практический переход от питомцев к скоту — четыре шага:

# ШАГ 1: Аудит — какие серверы у нас "питомцы"?
# Признак: uptime больше года без переустановки
uptime -s  # дата последнего старта
# Если дата 2023 и раньше на продакшн-сервере — питомец

# ШАГ 2: Документируем что реально запущено (chef-solo, ansible-pull)
# На подозрительном сервере:
ss -tlnp          # что слушает
systemctl list-units --type=service --state=running
crontab -l; ls /etc/cron.d/   # кроны
find /etc -newer /etc/os-release -type f 2>/dev/null | head -20
# Последнее — файлы изменённые после установки ОС

# ШАГ 3: Описываем текущее состояние как Ansible playbook
# ansible-pull или ручное написание по результатам аудита
# Проверяем идемпотентность:
ansible-playbook site.yml --check --diff

# ШАГ 4: Blue/Green замена
# Поднимаем новый сервер по playbook
# Переключаем трафик (DNS, LB)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай

Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.

Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.

Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.

#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future