Admin Future
242 subscribers
50 photos
1 video
4 files
87 links
Превращаем эникейщиков в System Architects.
🚀 Твой навигатор в мире IT-инфраструктуры:

▪️ Hard Skills: Linux, Windows, Network, Security
▪️ Tools: Лучший софт и скрытые фишки
▪️ Mindset: Как думать, чтобы платили много


Админ - @maksimshap
Download Telegram
🎓 Собеседование сисадмина. Выпуск #2: Контейнеры и сетевой хардкор

Привет, коллеги! Продолжаем серию постов для тех, кто хочет уверенно чувствовать себя на техническом интервью. Сегодня разберем три каверзных вопроса, которые обожают задавать на позиции Middle/Senior System Engineer.

Вопрос 1: «В чем разница между CMD и ENTRYPOINT в Dockerfile?»
Ответ новичка: «И то, и другое запускает команду при старте контейнера».
Ответ инженера: * ENTRYPOINT — это основная команда, которая превращает контейнер в исполняемый файл. Её сложно переопределить при запуске (`docker run`).
* CMD — это аргументы по умолчанию для ENTRYPOINT. Если вы укажете свои аргументы в конце `docker run`, они полностью заменят то, что написано в CMD.
* Pro-tip: На собеседовании скажите, что лучшая практика — использовать их вместе. Например: `ENTRYPOINT ["/usr/bin/nginx"]` и `CMD ["-g", "daemon off;"]`. Это позволяет гибко менять параметры запуска, не ломая логику образа.

Вопрос 2: «Что такое Docker-слои и почему размер образа имеет значение?»
Ответ новичка: «Слои — это шаги в Dockerfile. Чем меньше образ, тем быстрее он качается».
Ответ инженера:
1. Каждая инструкция (`RUN`, `COPY`, `ADD`) создает новый слой, который кешируется и занимает место.
2. Copy-on-Write: Если файл меняется в верхнем слое, он копируется из нижнего, что раздувает образ.
3. Безопасность и скорость: Маленький образ (на базе Alpine или Distroless) уменьшает "поверхность атаки" (меньше лишних утилит — меньше дыр) и ускоряет деплой в CI/CD.
Совет: Упомяните Multi-stage builds. Это сразу покажет, что вы умеете собирать оптимизированные образы, оставляя весь "мусор" (компиляторы, исходники) во временных контейнерах.


Вопрос 3: «Клиент жалуется: "Сайт не открывается". Вы пингуете сервер — пинг идет. В чем может быть проблема?»
Ответ новичка: «Наверное, упал веб-сервер, надо перезагрузить».
Ответ инженера: Пинг (ICMP) подтверждает только то, что сетевой уровень (L3) и узел живы.
1. Порты (L4): Проверяем, слушает ли веб-сервер нужный порт (80/443) через `telnet` или `nc -zv`.
2. MTU: Если маленькие пакеты (пинг) проходят, а большие (HTTP-трафик) — нет, проблема в MTU/MSS на пути следования. Пакеты просто дропаются без фрагментации.
3. Firewall: Возможно, ICMP разрешен, а TCP/443 закрыт на внешнем или внутреннем (iptables/nftables) фаерволе.
4. SSL/TLS: Проверяем, не истек ли сертификат. Браузер может блокировать соединение, хотя сервер работает.


💡 Золотое правило собеса: Когда вас спрашивают про траблшутинг, всегда идите по модели OSI снизу вверх. От физики и линков до прикладного уровня. Это демонстрирует системный подход, а не хаотичное "тыканье" в конфиги.

Сохраняйте, запоминайте и не давайте застать себя врасплох!

#собеседование_AF #docker #devops #networking #osi #sysadmin #admin_future
👍3
🐧 Linux: Быстрый тюнинг дескрипторов — исправляем «Too many open files» 📂

Бывает, что сервис (особенно нагруженный Nginx или БД) начинает захлебываться и сыпать ошибками `Too many open files`. Это значит, что процесс уперся в лимит открытых файловых дескрипторов. В 2026 году ручное редактирование `limits.conf` — это долго.

Как быстро проверить лимиты конкретного процесса:


# Берем PID процесса (например, 1234) и смотрим его мягкие и жесткие лимиты
cat /proc/1234/limits | grep "Max open files"



Как изменить лимит «на лету» без перезапуска всей системы (через systemd):
Если сервис управляется через systemd, создаем override-конфиг:


sudo systemctl edit nginx



Добавляем в открывшийся файл:


[Service]
LimitNOFILE=65535



Затем: `systemctl daemon-reload` и `systemctl restart nginx`.

Зачем это нужно: Современные приложения открывают сотни соединений и временных файлов.
Стандартный лимит в 1024 — это «бутылочное горлышко», которое ты теперь умеешь расширять за минуту.


#linux #systemd #performance #optimization #sysadmin #admin_future
🪟 Windows Server: Гроза «зависших» сессий — PowerShell-скрипт для очистки RDP 🧹

Знакомая ситуация: ты пытаешься зайти на сервер по RDP, а он тебе: «Превышено максимальное число подключений». Кто-то из коллег просто закрыл крестиком окно вместо Log off, и сессия висит «призраком», занимая слот.

Не нужно гадать, кто это. Выбиваем бездельников одной командой.

Сниппет для поиска и завершения зависших сессий:


# Показать все сессии, которые висят в статусе "Disconnected" более 2 часов
$sessions = qwinsta /server:localhost | Append-Output | Select-String "Disc"
foreach ($sess in $sessions) {
$sessId = ($sess -split '\s+')[2]
rwinsta $sessId /server:localhost
Write-Host "Сессия $sessId принудительно завершена." -ForegroundColor Yellow
}



Админский совет: Настрой этот скрипт в планировщике задач на контроллерах домена и терминальных серверах. Пусть система сама чистит за теми, кто забывает разлогиниться.

#windows #powershell #rdp #sysadmin #automation #server #admin_future
🧠 Skill: Навык «Технического пессимизма» — почему это хорошо 🏗

В IT есть термин — «Happy Path» (счастливый путь). Это когда всё работает идеально, как в мануале.
Но сисадмин-сеньор отличается от джуна тем, что всегда ищет «Unlucky Path».

Технический пессимизм — это умение при внедрении любой новой фичи задавать себе вопросы:

1. «Что, если этот диск умрет прямо сейчас?»
2. «Что, если скрипт автообновления скачает битый пакет?»
3. «Что произойдет, если этот контейнер упадет и не поднимется?»


Это не паранойя, а проектирование отказоустойчивости.

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


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

#skills #mindset #sysadmin #architecture #reliability #admin_future
🔥2👍1👏1💯1
💀 Искусство Post-Mortem: Как писать отчеты об авариях, чтобы тебя повысили, а не уволили

В Google это называют Blameless Post-Mortem (разбор полетов без поиска виноватых). В российских реалиях это часто называют «объяснительная». Разница в том, что объяснительную пишут, чтобы прикрыть свою спину, а Post-Mortem пишут, чтобы прикрыть спину компании.
Вот структура идеального отчета, после которого директор скажет:
«Да, нам нужно купить это железо», а не «Вы уволены».

1️⃣ Правило «Без вины» (No Blame Policy)
Первая строчка любого отчета. Мы ищем причину в системе, а не человека.
Плохо:
«Администратор Иванов случайно удалил таблицу в базе данных».
Хорошо:
«Отсутствие защиты от случайного удаления (подтверждения команды) и наличие прав на DROP TABLE у дежурного инженера в продуктивной среде привело к потере данных».
Почему это работает:
если обвинить Иванова — в следующий раз Иванов скроет ошибку.
Если обвинить процесс — становится понятно, что увольнение одного человека проблему не решит.


2️⃣ Хронология — это твой щит
Менеджеры всегда спрашивают: «Почему так долго чинили?»
В отчете должна быть поминутная хронология:
• 14:00 — мониторинг Zabbix зафиксировал рост latency
• 14:05 — дежурный инженер получил алерт и начал диагностику
• 14:15 — выявлена проблема с дисковым массивом
• 14:20 — принято решение переключить трафик на резервный ЦОД
Зачем это нужно:
показывает, что команда работала, а время уходило, например, на согласования с бизнесом. Часто именно здесь рождаются аргументы для пересмотра SLA.


3️⃣ Метод «5 Почему» (5 Whys) — путь к бюджету
Главная цель — найти Root Cause.
Пример: упал сайт.
Почему? — закончилось место на диске.
Почему? — логи заняли всё пространство.
Почему? — ротация логов не сработала.
Почему? — конфиг изменили вручную с ошибкой.
Почему? — нет CI/CD для конфигов и автоматической проверки.
Вывод:
нужно не «чистить диск», а внедрять Ansible, GitLab CI и закладывать ресурсы на DevOps и тестовую инфраструктуру.


4️⃣ Переводи с «эльфийского» на деньги
Директору не важны OOM-killer и race condition.
Ему важны потери бизнеса.
Раздел Impact:
• Downtime: сервис недоступен 45 минут
• Losses: потеряно ~1500 транзакций
• Risks: высокие репутационные риски (жалобы VIP-клиентов)
Когда появляется цифра потерь, просьба купить сервер уже выглядит как инвестиция, а не расход.


5️⃣ Action Items: как мы потратим ваши деньги
Что делаем, чтобы это не повторилось.
Сейчас (без затрат):
• исправлен конфиг
• добавлен алерт
Среднесрочно:
• переработка скриптов деплоя
Долгосрочно (бюджет):
Проблема: текущий сервер БД не справляется с пиками нагрузки.
Риск: повтор аварии в ближайшие 2 месяца.
Решение: кластер из двух серверов + лицензия Enterprise-backup.


Итог
Никогда не упускай хороший кризис.
Пока всё работает — IT выглядит как статья расходов.
Когда всё ломается — ты становишься человеком, которому дают ресурсы.
Пиши Post-Mortem честно, сухо и с цифрами — и вместо увольнения получишь доверие, уважение и бюджет на апгрейд.
Стабильного прода и мудрых руководителей 🤝

#лонгрид #карьера #postmortem #management #money #sysadmin #admin_future
🔥6👍1
🌐 Рунет 2028: Автономность, Эльбрусы и Китай

Согласно отчету, через два года ландшафт российской IT-инфраструктуры изменится кардинально. Вот ключевые поинты, к которым нам стоит готовиться:

1. Софт: Реестр распухнет до 30 000 наименований
Импортозамещение ПО идет полным ходом. Если сейчас мы иногда морщимся от пересборки Open Source под новыми лейблами, то к 2028 году, по прогнозам, отечественный софт закроет почти все ниши.
👉 Вывод для админа: Знание Astra Linux, РЕД ОС и отечественных VDI/СУБД переходит из разряда «было бы неплохо» в «обязательное требование».

2. Железо: 50% критической инфраструктуры на «Байкалах» и «Эльбрусах»
Это самый амбициозный пункт. РАЭК ожидает, что половина серверов и рабочих станций в КИИ (Критической Информационной Инфраструктуре) будет работать на российских процессорах.
👉 Вывод для админа: Придется учиться работать не только с x86_64, но и понимать специфику архитектуры «Эльбрус» (VLIW) и ARM («Байкал»). Оптимизация софта под эти камни станет отдельным скиллом.

3. Зависимость сменит вектор: Запад ➡️ Восток
Полной изоляции не будет. Зависимость от технологий США и ЕС сменится (и уже сменяется) на зависимость от Китая и Индии. Вектор сотрудничества — БРИКС, особенно в сферах ИИ и кибербезопасности.
👉 Вывод для админа: Учимся читать документацию не только на английском, но и привыкаем к особенностям китайского железа (Huawei, Kunpeng и др.).

4. Баланс между контролем и свободой
РАЭК прямым текстом говорит: российская модель будет балансировать между жестким госконтролем и безопасностью. Это неизбежно приведет к «этическим противоречиям».
👉 Вывод для админа: DPI, фильтрация трафика и требования по хранению данных будут только ужесточаться.

Мысли вслух:
С одной стороны, унификация софта и свое железо — это круто для безопасности (в теории). С другой — цифра в 50% замещения железа к 2028 году звучит очень оптимистично, учитывая сложности с производством чипов.

Коллеги, а вы верите, что через 2 года половина стоек в дата-центрах КИИ будет на отечественных процессорах? Или это останется красивой цифрой в отчетах?

#новости_IT #импортозамещение #эльбрус #байкал #раэк #интернет #admin_future
👍2👏1
🐧 Linux: Когда `/var/log/journal` съел диск — правильная диета для логов 🧹

Классика жанра: мониторинг орет, что на корневом разделе осталось 0 байт. Ты лезешь разбираться и видишь, что системный журнал `systemd-journald` разросся до размеров Вселенной, храня логи за последние три года.

Удалять файлы руками через `rm` — плохая примета (можно сломать целостность журнала). Делаем красиво через штатные инструменты.

Команды для очистки:


# 1. Смотрим, сколько реально занимают логи
journalctl --disk-usage

# 2. Оставляем логи только за последние 2 дня (остальное в /dev/null)
sudo journalctl --vacuum-time=2d

# 3. ИЛИ ограничиваем жестким размером (например, оставить 500 МБ)
sudo journalctl --vacuum-size=500M



Админский лайфхак: Чтобы не чистить вручную каждый раз, пропиши в `/etc/systemd/journald.conf` параметр `SystemMaxUse=1G` и перезапусти службу.


#linux #systemd #logs #maintenance #sysadmin #troubleshooting #admin_future
🪟 Windows: Понедельник — день «Locked Out». Спасаем пользователей массово 🔓

Утро понедельника у хелпдеска всегда одинаковое: "Я вводил пароль правильно, но оно не пускает!". После выходных пальцы пользователей забывают моторику, Caps Lock нажимается случайно, и половина офиса сидит с заблокированными учетками.

Не надо кликать мышкой в ADUC каждого страдальца. PowerShell спасет твой утренний кофе.


# Найти всех, кто заблокировался, и показать время блокировки
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOutTime | Format-Table -AutoSize

# Если ты чувствуешь себя великодушным — разблокировать ВСЕХ одной командой
Search-ADAccount -LockedOut | Unlock-ADAccount



Только убедись перед массовой разблокировкой, что это реальные пользователи, а не брутфорс-атака на RDP!


#windows #powershell #activedirectory #monday #automation #sysadmin #admin_future
🧠 Skill: Проблема XY — почему пользователи просят не то, что им нужно 🧩

Самый важный навык админа — не верить пользователю на слово.
Пользователь приходит и говорит: «Открой мне порт 5555 на фаерволе!» (Это решение X, которое он придумал).
Ты спрашиваешь: «Зачем?»
Он мнется и выдает: «Ну мне надо файлы передать на сервер бухгалтерии» (Это проблема Y).

Если ты просто откроешь порт, ты создашь дыру в безопасности. А правильное решение проблемы Y — настроить пользователю SFTP или дать доступ к Nextcloud.

Суть скилла:
Никогда не выполняйте технические просьбы («дай админку», «ребутни сервер», «пропиши маршрут») без вопроса «Какую бизнес-задачу мы этим решаем?».
В 90% случаев пользователь придумал кривое решение для простой проблемы. Твоя работа — дать правильное решение, а не быть "руками" пользователя.


#skills #mindset #xyproblem #communication #sysadmin #security #admin_future
👍4🔥2
🎓 Собеседование сисадмина. Выпуск №3: Траблшутинг и «Железная» логика

Привет, коллеги! Сегодня разберем три вопроса, которые отделяют «человека с сертификатом» от реального системного администратора.
Здесь важен не просто правильный ответ, а понимание физики процессов.

Вопрос 1: «На сервере Linux резко вырос Load Average (LA), при этом CPU Usage всего 10%. Что происходит и где искать проблему?»
Ответ новичка: «Наверное, какой-то процесс завис, надо ребутнуть сервер или убить лишние задачи».
Ответ инженера:
Load Average — это очередь процессов, ожидающих выполнения. Если CPU свободен, значит, процессы стоят в очереди Disk I/O (ожидание ввода-вывода).
Что делать: Смотрим колонку %wa (iowait) в top или запускаем iostat -x 1.
Причина: Скорее всего, «умирает» диск, перегружена дисковая полка или база данных делает тяжелый Swapping. Нужно искать процесс, который генерирует максимум чтений/записей через iotop.
Pro-tip: Упомяните, что LA может расти и из-за сетевых задержек (NFS/Samba), если файловая система примонтирована по сети и «отвалилась».

Вопрос 2: «Пользователи жалуются, что "интернет тормозит". Пинг до 8.8.8.8 идеальный (2 мс), но страницы открываются по 10 секунд. Ваши действия?»
Ответ новичка: «Позвоню провайдеру, пусть проверят линию, или почищу куки в браузере».
Ответ инженера:
Если ICMP (пинг) летит быстро, проблема на уровнях выше.
DNS: Самая частая причина. Резолвер тормозит, и браузер тратит 5–8 секунд только на то, чтобы узнать IP сайта. Проверяем через dig или nslookup.
MTU/MSS: Если пинг (маленький пакет) проходит, а HTTP (большой пакет) — нет, значит, где-то на пути пакеты дропаются из-за фрагментации. Проверяем пингом с большой нагрузкой: ping -s 1472 -M do 8.8.8.8.
Браузер/Прокси: Проверяем настройки WPAD или наличие «кривых» корпоративных расширений/антивирусов, которые инспектируют трафик.

Вопрос 3: «В RAID 10 вылетел один диск. Насколько это критично и каковы ваши действия по замене?»
Ответ новичка: «RAID 10 надежный, ничего страшного. Просто вытащу старый и вставлю новый в любое время».
Ответ инженера:
RAID 10 — это «зеркало страйпов».
Риски: Если вылетит второй диск в той же зеркальной паре — массив рассыплется и данные будут потеряны. Это критическая ситуация.
Действия: * Проверить статус массива через утилиту контроллера (например, perccli или mdadm).
Важно: Перед заменой убедиться, что у нас есть свежий бэкап. Ребилд (восстановление) — это огромная нагрузка на диски, и именно в этот момент чаще всего «сыпется» второй диск в паре.
Менять диск лучше в часы минимальной нагрузки на сервер, чтобы ускорить процесс ребилда и снизить риск отказа остальных дисков.


💡 Золотое правило собеса: Если не знаешь ответа — описывай, как ты будешь его искать.
Фраза «Я полезу в /var/log/syslog и посмотрю ошибки ввода-вывода» звучит в сто раз лучше, чем «Я не знаю».


Сохраняйте пост, это база, которая спасает на интервью!

#собеседование_AF #sysadmin #linux #networking #raid #troubleshooting #admin_future
👍3
🐧 Linux: Переходим на `nftables` — гибкое управление трафиком без боли

Если ты всё еще используешь `iptables`, пора признать: пора двигаться дальше. В 2026 году `nftables` — это стандарт. Он быстрее, эффективнее и позволяет писать правила, которые читаются как стихи (ну, почти). Главная фишка — использование «сетов» (sets), которые позволяют проверять тысячи IP-адресов за один проход.

Техническое решение:
Создаем динамический список для блокировки тех, кто слишком активно стучится на 22 порт.


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


# Создаем таблицу и цепочку
nft add table inet my_filter
nft add chain inet my_filter input { type filter hook input priority 0 \; }

# Создаем сет для "плохих парней" с таймаутом в 1 час
nft add set inet my_filter blackhole { type ipv4_addr \; flags timeout \; }

# Добавляем правило: если более 5 попыток за минуту — в бан
nft add rule inet my_filter input tcp dport 22 meter flood { ip saddr timeout 1m limit rate over 5/minute } add @blackhole { ip saddr } drop

# Дропаем всех, кто в блэкхоле
nft insert rule inet my_filter input ip saddr @blackhole drop



#linux #networking #nftables #security #firewall #sysadmin #admin_future
1🔥1
🪟 Windows: Ищем «протухающие» сертификаты через PowerShell

Забытый SSL-сертификат на внутреннем веб-сервере или в хранилище `LocalMachine` — это классический повод для экстренного вызова админа из отпуска. Чтобы этого не случилось, давай автоматизируем проверку.

Технический разбор:
В Windows есть встроенный провайдер `Cert:`, который позволяет работать с сертификатами как с обычными файлами.


Сниппет для поиска проблем:


# Найти все сертификаты в личном хранилище компьютера,
# срок действия которых истекает в ближайшие 30 дней
Get-ChildItem -Path Cert:\LocalMachine\My |
Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) -and $_.NotAfter -gt (Get-Date) } |
Select-Object Subject, NotAfter, Thumbprint |
Format-Table -AutoSize



Зачем это нужно: Закинь этот скрипт в ежедневный Task Scheduler с отправкой письма на почту, и ты никогда не пропустишь момент, когда пора обновлять сертификат на твоем AD FS или IIS.


#windows #powershell #security #pki #certificates #automation #admin_future
🧠 Skill: «Git-гигиена» — пиши коммиты для людей, а не для галочки

В 2026 году даже «чистый» админ живет в парадигме **Infrastructure as Code (IaC)**. Твои конфиги Ansible, Terraform или просто Bash-скрипты лежат в Git. Но есть проблема: коммиты типа `fixed bug`, `update` или `.....` — это мусор. Через полгода ты сам не поймешь, что там изменилось.

Как делать правильно:

1. Заголовок до 50 символов: Краткая суть (что изменилось).
2. Пустая строка после заголовка: Это стандарт Git для корректного отображения в логах.
3. Тело коммита: Опиши ПОЧЕМУ ты это сделал. Какой баг пофиксил или какой тикет в Jira закрыл.


Пример идеального коммита:


feat(network): переход на nftables для SSH-фильтрации

- Удалены старые правила iptables из конфига
- Внедрены динамические сеты для защиты от брутфорса
- Исправлена проблема с ложными срабатываниями на IP офиса (тикет #402)



Хорошая история коммитов — это лучшая документация твоей работы.

#skills #git #iac #devops #bestpractices #sysadmin #admin_future
📦 S3 vs FTP: Почему пора перестать гонять файлы по старинке

Многие по привычке воспринимают S3 (Object Storage) как просто «бесконечную флешку в интернете». Но если копнуть глубже, разница между ним и обычным файловым сервером (FTP/SFTP/NFS) огромна.

1. Иерархия против Плоской структуры
FTP (File Storage): Это дерево. Папки, подпапки, файлы. Если у тебя миллион файлов в одной директории, команда ls или попытка открыть её через клиент заставит сервер «призадуматься» на пару минут.
S3 (Object Storage): Здесь нет папок. Вообще. Есть только Bucket (корзина) и Key (ключ/путь). То, что ты видишь как /uploads/2026/march/photo.jpg — это просто длинное имя одного объекта. Это позволяет S3 находить любой файл среди миллиардов других за фиксированное время.


2. Протоколы и Доступ
FTP: Это отдельный протокол, порты 21 (или 22 для SFTP), проблемы с пассивным режимом и фаерволами.
S3: Это HTTP/HTTPS. Твой файл — это URL. Доступ к нему осуществляется через стандартные REST API запросы (GET, PUT, DELETE). Это делает S3 идеальным для веба: браузеры и мобильные приложения общаются с ним «на одном языке».


3. Масштабируемость и Отказоустойчивость
FTP: Ты ограничен объемом диска на сервере. Кончилось место? Покупай новый диск, расширяй раздел, делай LVM. Упал сервер — файлы недоступны.
S3: Он практически бездонен. Тебе не нужно думать о месте. Более того, облачные провайдеры (AWS, Selectel, Yandex Cloud) реплицируют твои данные между разными дата-центрами. Вероятность потери данных в S3 стремится к нулю.


4. Метаданные
FTP: У файла есть размер и дата изменения. Всё.
S3: Ты можешь прицепить к объекту любые метаданные: Content-Type, Author, Project-ID или даже свои кастомные теги. По этим тегам потом можно настраивать политики автоматического удаления или перемещения в «холодное» (дешевое) хранилище.


🛠 Инструмент админа: rclone
Если тебе нужно перекинуть данные с древнего FTP в современное S3-хранилище, не мучайся со скриптами. Используй rclone — это «швейцарский нож» для облаков.
Команда для синхронизации:


# Настраиваем конфиг через rclone config, а затем:
rclone sync my_ftp:/var/www/uploads my_s3_bucket:backup-2026 -P


Когда НЕ нужен S3?
Если твоей программе нужно постоянно открывать файл, менять в нем одну строчку и сохранять (например, база данных SQLite или редактирование кода «на лету») — S3 не подойдет. Он работает по принципу «перезапиши объект целиком».

#storage #s3 #ftp #cloud #devops #sysadmin #rclone #admin_future
🔥1🤔1💯1
🛡️ Безопасность Linux-сервера за 10 минут: Базовый чек-лист 🛡️

1. Обновление и чистка
Первым делом — актуальные патчи. Уязвимости нулевого дня (0-day) в 2026-м вылетают часто, поэтому система должна быть свежей.

sudo apt update && sudo apt upgrade -y
# Удаляем лишние пакеты, которые могут быть вектором атаки
sudo apt autoremove && sudo apt autoclean


2. Защита SSH (Самый важный этап)
Забудь про пароли. Только ключи. И никакого входа под root.
Что сделать: Отредактируй /etc/ssh/sshd_config.

# Установи следующие параметры:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
# Опционально: смени порт с 22 на нестандартный (например, 2222)
Port 2222

Применить: sudo systemctl restart ssh

3. Настройка фаервола (UFW или nftables)
Закрываем всё, что не используем. Если это веб-сервер, нам нужны только 80, 443 и наш порт SSH.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # Твой новый порт SSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable


4. Fail2Ban: Защита от брутфорса
Даже если пароли отключены, боты будут нагружать твой процессор попытками входа. Fail2Ban просто забанит их на уровне IP после пары неудачных попыток.

sudo apt install fail2ban -y
# Конфиг по умолчанию для SSH обычно уже включен.
# Проверить статус:
sudo fail2ban-client status sshd


5. Аудит открытых портов
Проверь, не слушает ли какая-нибудь база данных или служебный демон весь интернет.

# Ищем все слушающие порты
sudo ss -tulpn

Если видишь 0.0.0.0:5432 (PostgreSQL) или 0.0.0.0:6379 (Redis) — это беда. Они должны слушать только 127.0.0.1 или внутреннюю сеть.

Итог: Эти простые действия отсекают 99% автоматизированных атак.
Остальное — это уже тонкий тюнинг и специфические настройки под конкретный проект.



#security #linux #sysadmin #hardening #cybersecurity #fail2ban #ufw #admin_future
3🔥21
Небольшой оффтоп, но полезный.

Друзья, вы знаете, что рекламы в этом канале обычно нет. Но тут случай особый.

Моя подруга Марина профессионально занимается туризмом.
Она завела свой канал в Телеге, где выкладывает реально годные варианты туров и честные обзоры отелей (без прикрас, как есть).

Я вижу, как она работает: постоянно на связи, перепроверяет каждую бронь, выбивает лучшие условия.
Если вы (как и я) не любите тратить часы на поиск путевок и разбираться в нюансах перелетов — просто делегируйте это ей.

Подпишитесь, чтобы не потерять контакт проверенного специалиста. Впереди сезон отпусков, точно пригодится.

📲 Ссылка на канал: Твоя Стихия https://t.me/turtskrd
🎓 Собеседование сисадмина. Выпуск №4: Виртуализация и Хранение данных

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

Вопрос 1: «Почему опасно держать снапшот (Snapshot) виртуальной машины дольше пары дней?»
Ответ новичка: «Снапшот занимает много места на диске, и можно просто забыть, что он есть».
Ответ инженера:
1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.


Вопрос 2: «В чем разница между Thin (Тонкими) и Thick (Толстыми) дисками? Что вы выберете для высоконагруженной БД?»
Ответ новичка: «Тонкие диски экономят место, а толстые — нет. Для базы выберу толстые, потому что они надежнее».
Ответ инженера:
Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.


Вопрос 3: «Что такое Split-brain в кластере высокой доступности (HA) и как его предотвратить?»
Ответ новичка: «Это когда два сервера работают одновременно. Предотвратить можно, настроив хороший мониторинг».
Ответ инженера:
Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.


💡 Золотое правило собеса: Помни, что Снапшот — это не бэкап. Это временная точка отката перед рискованной операцией. Если на вопрос «как вы делаете бэкапы» ты ответишь «делаю снапшоты раз в неделю» — собеседование для тебя закончится мгновенно.

Сохраняйте, коллеги! Это те знания, которые превращают «админа-кнопкотыка» в системного архитектора.

#собеседование_AF #virtualization #storage #snapshot #highavailability #proxmox #vmware #admin_future
👏2🔥1
🐧 Linux: systemd-run — запускаем тяжелые задачи в «песочнице» без лишних конфигов

Часто бывает нужно запустить скрипт или тяжелую задачу (например, пересборку логов или парсинг), но ты боишься, что она «отъест» все ресурсы у боевого веб-сервера. Создавать полноценный .service файл лень? Используй systemd-run.

Техническая суть:
Команда создает временный (transient) юнит и позволяет лимитировать ресурсы (CPU, RAM, I/O) «на лету» прямо из командной строки.

Команда для запуска с лимитом памяти в 500МБ:

# Запускаем скрипт в отдельном слайсе с жестким лимитом по памяти
sudo systemd-run --scope -p MemoryMax=500M -p CPUWeight=50 ./heavy-script.sh
# Посмотреть статус этого временного юнита
systemctl status run-*.scope

Зачем это нужно:
Это намного надежнее, чем просто nice или ionice.
Ты гарантируешь, что скрипт не уронит сервер по OOM (Out Of Memory), даже если в коде утечка.

#linux #systemd #optimization #performance #sysadmin #admin_future
🪟 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
🔥3
🧠 Skill: «Фактор автобуса» (Bus Factor) — почему незаменимость это плохо

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

Техническая суть:
«Фактор автобуса» — это количество членов команды, которых должен переехать автобус, чтобы проект/инфраструктура встали колом. Если твой Bus Factor равен 1 (это ты) — у компании огромные риски, а у тебя — вечный стресс.

Как прокачать этот скилл:
1. Документация «для идиота»: Пиши инструкции так, чтобы твой сменщик мог поднять упавший сервис в 3 часа ночи без твоего звонка.

2.Infrastructure as Code (IaC): Твои знания должны быть зафиксированы в коде Ansible/Terraform, а не только в твоей голове.

3. Shared Secrets: Используй командные менеджеры паролей (Vault, Passbolt). Никаких личных блокнотов с паролями от рута.


Вывод: Чем выше Bus Factor твоей команды, тем более зрелым инженером ты считаешься.
Сеньор — это тот, кто может уйти в отпуск на месяц и его ни разу не дернут.

#skills #management #career #documentation #sysadmin #mindset #admin_future