Windows: Настрой рабочее место за 10 минут с помощью Winget
Установка софта на новый Windows-компьютер — это боль: найти сайты, скачать десяток .exe и .msi, прокликать инсталляторы. Современный админ автоматизирует это, управляя софтом как пакетами в Linux.
Winget — это официальный менеджер пакетов от Microsoft, встроенный в современные Windows 10/11.
Базовые команды (откройте PowerShell или Terminal):
Найти приложение: winget search PowerToys
Установить приложение: winget install Microsoft.PowerToys (можно использовать ID из поиска)
Обновить всё: winget upgrade --all (команда, меняющая жизнь)
Создать список установленного ПО: winget export -o C:\temp\my_apps.json
Установить всё из списка: winget import -i C:\temp\my_apps.json (ключевая команда для клонирования окружения!)
Готовый скрипт для быстрой настройки:
Сохраните как setup_workstation.ps1 и запустите.
PowerShell
Взгляд архитектора:
Эта методология обеспечивает идентичность и воспроизводимость окружений. Новый сотрудник получает настроенный ПК за минуты, а не за полдня. Конфигурационные файлы (my_apps.json или скрипты) можно хранить в репозитории, версионировать и применять централизованно.
#windows #winget #automation #powershell #чеклисты
Установка софта на новый Windows-компьютер — это боль: найти сайты, скачать десяток .exe и .msi, прокликать инсталляторы. Современный админ автоматизирует это, управляя софтом как пакетами в Linux.
Winget — это официальный менеджер пакетов от Microsoft, встроенный в современные Windows 10/11.
Базовые команды (откройте PowerShell или Terminal):
Найти приложение: winget search PowerToys
Установить приложение: winget install Microsoft.PowerToys (можно использовать ID из поиска)
Обновить всё: winget upgrade --all (команда, меняющая жизнь)
Создать список установленного ПО: winget export -o C:\temp\my_apps.json
Установить всё из списка: winget import -i C:\temp\my_apps.json (ключевая команда для клонирования окружения!)
Готовый скрипт для быстрой настройки:
Сохраните как setup_workstation.ps1 и запустите.
PowerShell
# Список обязательного ПО (используйте ID из `winget search`)
$packages = @(
"Microsoft.PowerToys",
"Microsoft.VisualStudioCode",
"7zip.7zip",
"VideoLAN.VLC",
"Google.Chrome",
"Notepad++.Notepad++",
"Docker.DockerDesktop",
"Git.Git"
)
Write-Host "--- Начинаю установку обязательного ПО ---" -ForegroundColor Green
foreach ($pkg in $packages) {
Write-Host "Устанавливаю: $pkg"
# -e требует точного совпадения ID, --accept-source-agreements принимает соглашения
winget install -e --id $pkg --silent --accept-source-agreements
}
Write-Host "--- Обновляю оставшиеся пакеты ---" -ForegroundColor Green
winget upgrade --all --silent --accept-source-agreements
Write-Host "--- Настройка завершена! ---" -ForegroundColor Cyan
Взгляд архитектора:
Эта методология обеспечивает идентичность и воспроизводимость окружений. Новый сотрудник получает настроенный ПК за минуты, а не за полдня. Конфигурационные файлы (my_apps.json или скрипты) можно хранить в репозитории, версионировать и применять централизованно.
#windows #winget #automation #powershell #чеклисты
👍2
VPN: Почему WireGuard — это будущее, а OpenVPN — классика?
Выбор VPN-решения — важное архитектурное решение, влияющее на безопасность, производительность и простоту поддержки. Давайте сравним два титана.
OpenVPN: Проверенный временем танк
На рынке с 2001 года, де-факто стандарт в корпоративном мире.
✅ Плюсы:
Надёжность: Проверен десятилетиями.
Гибкость: Огромное количество настроек, может работать через TCP-порт 443, маскируясь под HTTPS-трафик, чтобы обходить файрволы.
Поддержка: Поддерживается практически любым железом и ПО.
❌ Минусы:
Сложность: Сотни опций в конфиге. Настроить его правильно — нетривиальная задача.
Кодовая база: ~400,000 строк кода. Это усложняет аудит безопасности.
Производительность: Заметный оверхед, что сказывается на скорости.
WireGuard: Современный истребитель
Относительно новый протокол, который быстро стал стандартом благодаря своей простоте и скорости. С 2020 года включён в ядро Linux.
✅ Плюсы:
Простота: Конфигурация в разы проще. Вся логика построена на обмене публичными ключами.
Производительность: Очень быстрый, с минимальными задержками, почти не влияет на скорость соединения.
Безопасность: Минималистичная кодовая база (~4,000 строк), что делает аудит простым и эффективным. Использует только современные и надёжные криптографические примитивы.
❌ Минусы:
Только UDP: Не будет работать в сетях, где разрешён только TCP-трафик.
Меньше «обвязок»: Корпоративные решения (как панели управления пользователями) всё ещё догоняют.
Вердикт архитектора:
Используйте OpenVPN, если вам нужна максимальная совместимость со старым оборудованием или критична работа в очень ограниченных сетях (например, отельный Wi-Fi, который режет всё кроме HTTPS).
Для всех остальных задач WireGuard — очевидный выбор. Это будущее VPN для связи «точка-точка», подключения удалённых сотрудников и соединения облачных сетей. Простота, скорость и безопасность — ключевые архитектурные преимущества.
А что вы используете в своих проектах и почему? Делитесь в комментариях!
#security #networking #linux #wireguard #vpn #architect #сравнение
Выбор VPN-решения — важное архитектурное решение, влияющее на безопасность, производительность и простоту поддержки. Давайте сравним два титана.
OpenVPN: Проверенный временем танк
На рынке с 2001 года, де-факто стандарт в корпоративном мире.
✅ Плюсы:
Надёжность: Проверен десятилетиями.
Гибкость: Огромное количество настроек, может работать через TCP-порт 443, маскируясь под HTTPS-трафик, чтобы обходить файрволы.
Поддержка: Поддерживается практически любым железом и ПО.
❌ Минусы:
Сложность: Сотни опций в конфиге. Настроить его правильно — нетривиальная задача.
Кодовая база: ~400,000 строк кода. Это усложняет аудит безопасности.
Производительность: Заметный оверхед, что сказывается на скорости.
WireGuard: Современный истребитель
Относительно новый протокол, который быстро стал стандартом благодаря своей простоте и скорости. С 2020 года включён в ядро Linux.
✅ Плюсы:
Простота: Конфигурация в разы проще. Вся логика построена на обмене публичными ключами.
Производительность: Очень быстрый, с минимальными задержками, почти не влияет на скорость соединения.
Безопасность: Минималистичная кодовая база (~4,000 строк), что делает аудит простым и эффективным. Использует только современные и надёжные криптографические примитивы.
❌ Минусы:
Только UDP: Не будет работать в сетях, где разрешён только TCP-трафик.
Меньше «обвязок»: Корпоративные решения (как панели управления пользователями) всё ещё догоняют.
Вердикт архитектора:
Используйте OpenVPN, если вам нужна максимальная совместимость со старым оборудованием или критична работа в очень ограниченных сетях (например, отельный Wi-Fi, который режет всё кроме HTTPS).
Для всех остальных задач WireGuard — очевидный выбор. Это будущее VPN для связи «точка-точка», подключения удалённых сотрудников и соединения облачных сетей. Простота, скорость и безопасность — ключевые архитектурные преимущества.
А что вы используете в своих проектах и почему? Делитесь в комментариях!
#security #networking #linux #wireguard #vpn #architect #сравнение
Windows: Глубокая диагностика без скриптов с msinfo32
В арсенале каждого Windows-администратора есть PowerShell, но иногда нужно получить полный срез системы за 5 секунд, не написав ни строчки кода. Для этого существует msinfo32 (Сведения о системе) — встроенный инструмент, который многие недооценивают.
Это не просто список железа. Это ваш цифровой паспорт системы для быстрой диагностики.
На что смотрит профессионал:
Ресурсы оборудования → Конфликты и совместное использование: Первое место для поиска проблем с драйверами. Если два устройства делят одни и те же ресурсы (IRQ, порты ввода-вывода), здесь вы это увидите.
Компоненты → Устройства с неполадками: Показывает все устройства, которые система не смогла корректно запустить. Экономит время на поиске в Диспетчере устройств.
Программная среда → Отчеты об ошибках: Быстрый доступ к истории сбоев приложений и системы. Помогает понять, какая программа вызывает проблемы, не копаясь в журналах событий.
Взгляд архитектора: используем msinfo32 на 100%
Просто запустить утилиту — это уровень админа. Архитектор использует её для удалённой диагностики и автоматизации.
Удалённое подключение
Не нужно подключаться по RDP, чтобы проанализировать проблемный сервер.
В окне msinfo32 выберите Вид → Удалённый компьютер и введите имя или IP-адрес машины.
Требование: На удалённой машине в брандмауэре должна быть разрешена входящая группа правил «Инструментарий управления Windows (WMI)».
Автоматизация и создание отчётов
msinfo32 отлично работает из командной строки. Это позволяет интегрировать его в скрипты для инвентаризации или аудита.
PowerShell
Кейс: Настройте в Планировщике заданий еженедельное создание отчётов с ключевых серверов. При возникновении сбоя у вас всегда будет «снимок» здоровой конфигурации для сравнения.
В мире сложных систем мониторинга, msinfo32 остаётся незаменимым инструментом первого эшелона для быстрой и точной диагностики.
#windows #msinfo32 #diagnostics #команды #admin #audit
В арсенале каждого Windows-администратора есть PowerShell, но иногда нужно получить полный срез системы за 5 секунд, не написав ни строчки кода. Для этого существует msinfo32 (Сведения о системе) — встроенный инструмент, который многие недооценивают.
Это не просто список железа. Это ваш цифровой паспорт системы для быстрой диагностики.
На что смотрит профессионал:
Ресурсы оборудования → Конфликты и совместное использование: Первое место для поиска проблем с драйверами. Если два устройства делят одни и те же ресурсы (IRQ, порты ввода-вывода), здесь вы это увидите.
Компоненты → Устройства с неполадками: Показывает все устройства, которые система не смогла корректно запустить. Экономит время на поиске в Диспетчере устройств.
Программная среда → Отчеты об ошибках: Быстрый доступ к истории сбоев приложений и системы. Помогает понять, какая программа вызывает проблемы, не копаясь в журналах событий.
Взгляд архитектора: используем msinfo32 на 100%
Просто запустить утилиту — это уровень админа. Архитектор использует её для удалённой диагностики и автоматизации.
Удалённое подключение
Не нужно подключаться по RDP, чтобы проанализировать проблемный сервер.
В окне msinfo32 выберите Вид → Удалённый компьютер и введите имя или IP-адрес машины.
Требование: На удалённой машине в брандмауэре должна быть разрешена входящая группа правил «Инструментарий управления Windows (WMI)».
Автоматизация и создание отчётов
msinfo32 отлично работает из командной строки. Это позволяет интегрировать его в скрипты для инвентаризации или аудита.
PowerShell
# Сохранить полный отчёт о локальной машине в .nfo формате
msinfo32 /nfo C:\Reports\local_system_info.nfo
# Создать текстовый отчёт с удалённого сервера
msinfo32 /report C:\Reports\remote_server.txt /computer WEBSRV01
Кейс: Настройте в Планировщике заданий еженедельное создание отчётов с ключевых серверов. При возникновении сбоя у вас всегда будет «снимок» здоровой конфигурации для сравнения.
В мире сложных систем мониторинга, msinfo32 остаётся незаменимым инструментом первого эшелона для быстрой и точной диагностики.
#windows #msinfo32 #diagnostics #команды #admin #audit
✍2
Linux: Забудь про ifconfig. Настраиваем сеть декларативно с Netplan
В современных Ubuntu и других дистрибутивах редактирование файла /etc/network/interfaces — это устаревший подход. На смену ему пришёл Netplan — декларативный инструмент для настройки сети через простой YAML-синтаксис.
Вы больше не пишете команды "как настроить". Вы описываете "какой должна быть сеть".
Задача: Настроить на сервере статический IP-адрес.
1. Находим файл конфигурации:
Все конфиги лежат в /etc/netplan/. Обычно это файл вроде 01-netcfg.yaml или 50-cloud-init.yaml.
Bash
2. Редактируем конфигурацию:
Открываем найденный файл и приводим его к следующему виду. Внимание: YAML чувствителен к отступам! Используйте два пробела.
YAML
3. Применяем конфигурацию:
Две команды для проверки и применения.
Bash
Почему это взгляд архитектора?
✅ Декларативность: Конфиг описывает конечное состояние. Его легко читать, версионировать в Git и использовать в системах автоматизации (Ansible, Terraform).
✅ Атомарность: Команда netplan apply применяет изменения атомарно. Если в конфиге ошибка, он не сломает вам сеть посреди процесса.
✅ Универсальность: Netplan — это "фронтенд", который может управлять разными "бекендами" (systemd-networkd или NetworkManager), скрывая от вас сложность их настройки.
#linux #networking #netplan #ubuntu #architect #команды
В современных Ubuntu и других дистрибутивах редактирование файла /etc/network/interfaces — это устаревший подход. На смену ему пришёл Netplan — декларативный инструмент для настройки сети через простой YAML-синтаксис.
Вы больше не пишете команды "как настроить". Вы описываете "какой должна быть сеть".
Задача: Настроить на сервере статический IP-адрес.
1. Находим файл конфигурации:
Все конфиги лежат в /etc/netplan/. Обычно это файл вроде 01-netcfg.yaml или 50-cloud-init.yaml.
Bash
ls /etc/netplan/
2. Редактируем конфигурацию:
Открываем найденный файл и приводим его к следующему виду. Внимание: YAML чувствителен к отступам! Используйте два пробела.
YAML
network:
version: 2
renderer: networkd # Используем systemd-networkd, стандарт для серверов
ethernets:
ens18: # Имя вашего интерфейса (узнать: ip a)
dhcp4: no # Отключаем DHCP
addresses:
- 192.168.1.100/24 # Статический IP и маска
gateway4: 192.168.1.1 # Шлюз
nameservers:
addresses: [8.8.8.8, 1.1.1.1] # DNS-серверы
3. Применяем конфигурацию:
Две команды для проверки и применения.
Bash
# Проверяем синтаксис файла
sudo netplan generate
# Применяем изменения
sudo netplan apply
Почему это взгляд архитектора?
✅ Декларативность: Конфиг описывает конечное состояние. Его легко читать, версионировать в Git и использовать в системах автоматизации (Ansible, Terraform).
✅ Атомарность: Команда netplan apply применяет изменения атомарно. Если в конфиге ошибка, он не сломает вам сеть посреди процесса.
✅ Универсальность: Netplan — это "фронтенд", который может управлять разными "бекендами" (systemd-networkd или NetworkManager), скрывая от вас сложность их настройки.
#linux #networking #netplan #ubuntu #architect #команды
Windows & Security: Внедряем LAPS. Прощайте, одинаковые пароли локальных админов!
Использование одного и того же пароля для локального администратора на всех машинах — это огромная дыра в безопасности. Если злоумышленник его получает, он получает всю сеть (атака Pass-the-Hash).
LAPS (Local Administrator Password Solution) — это бесплатный инструмент от Microsoft, который решает эту проблему элегантно.
Как это работает:
Устанавливается агент на клиентские машины.
Агент генерирует уникальный, сложный пароль для встроенной учетной записи "Администратор".
Пароль сохраняется в атрибуте объекта-компьютера в Active Directory.
Пароль автоматически меняется по заданному расписанию (например, каждые 30 дней).
План внедрения (взгляд архитектора):
Расширение схемы AD:
На контроллере домена выполните из PowerShell: Update-AdmPwdADSchema. Это добавит два новых атрибута для хранения пароля и даты его смены.
Настройка прав доступа:
Выдайте права на чтение пароля только определённым группам (например, "Администраторы домена" или "Help Desk").
PowerShell
Развёртывание через GPO:
Создайте новую групповую политику.
В разделе Конфигурация компьютера → Политики → Административные шаблоны → LAPS включите политику "Enable local admin password management".
Через GPO также разверните MSI-пакет с агентом LAPS на все нужные компьютеры.
Получение пароля:
Используйте утилиту LAPS UI, которая идёт в комплекте, или PowerShell:
PowerShell
Результат: Вы централизованно управляете паролями, которые уникальны для каждой машины. Это не просто "удобство", это фундаментальное усиление безопасности вашей инфраструктуры.
#windows #security #laps #activedirectory #gpo #architect #гайд
Использование одного и того же пароля для локального администратора на всех машинах — это огромная дыра в безопасности. Если злоумышленник его получает, он получает всю сеть (атака Pass-the-Hash).
LAPS (Local Administrator Password Solution) — это бесплатный инструмент от Microsoft, который решает эту проблему элегантно.
Как это работает:
Устанавливается агент на клиентские машины.
Агент генерирует уникальный, сложный пароль для встроенной учетной записи "Администратор".
Пароль сохраняется в атрибуте объекта-компьютера в Active Directory.
Пароль автоматически меняется по заданному расписанию (например, каждые 30 дней).
План внедрения (взгляд архитектора):
Расширение схемы AD:
На контроллере домена выполните из PowerShell: Update-AdmPwdADSchema. Это добавит два новых атрибута для хранения пароля и даты его смены.
Настройка прав доступа:
Выдайте права на чтение пароля только определённым группам (например, "Администраторы домена" или "Help Desk").
PowerShell
# Даём группе 'HelpDesk' право читать пароли на OU 'Workstations'
Set-AdmPwdReadPasswordPermission -OrgUnit "Workstations" -AllowedPrincipals "HelpDesk"
Развёртывание через GPO:
Создайте новую групповую политику.
В разделе Конфигурация компьютера → Политики → Административные шаблоны → LAPS включите политику "Enable local admin password management".
Через GPO также разверните MSI-пакет с агентом LAPS на все нужные компьютеры.
Получение пароля:
Используйте утилиту LAPS UI, которая идёт в комплекте, или PowerShell:
PowerShell
Get-ADComputer -Identity "PC001" -Properties "ms-Mcs-AdmPwd" | Select-Object "ms-Mcs-AdmPwd"
Результат: Вы централизованно управляете паролями, которые уникальны для каждой машины. Это не просто "удобство", это фундаментальное усиление безопасности вашей инфраструктуры.
#windows #security #laps #activedirectory #gpo #architect #гайд
AI-промпт: Генерация Regex за 30 секунд
Регулярные выражения (Regex) — мощнейший инструмент для парсинга логов, валидации данных и поиска. Но писать их вручную — это боль. Давайте делегируем это AI.
Задача: Нам нужен Regex для проверки пароля. Требования: минимум 8 символов, одна заглавная буква, одна строчная буква, одна цифра и один спецсимвол.
Плохой промпт: сделай regex для пароля
Результат будет неточным и без объяснений.
Хороший промпт (для ChatGPT/Gemini/Copilot):
Почему это работает?
Роль: эксперт по регулярным выражениям задаёт контекст.
Чёткие правила: Вы даёте машине исчерпывающие требования.
Формат вывода: Вы заставляете AI структурировать ответ, что делает его полезным и понятным.
Экономьте своё время на рутине. Архитектор ценит свой мыслительный ресурс и автоматизирует всё, что можно автоматизировать.
#ai4admin #regex #powershell #bash #automation #промпты
Регулярные выражения (Regex) — мощнейший инструмент для парсинга логов, валидации данных и поиска. Но писать их вручную — это боль. Давайте делегируем это AI.
Задача: Нам нужен Regex для проверки пароля. Требования: минимум 8 символов, одна заглавная буква, одна строчная буква, одна цифра и один спецсимвол.
Плохой промпт: сделай regex для пароля
Результат будет неточным и без объяснений.
Хороший промпт (для ChatGPT/Gemini/Copilot):
Выступи в роли эксперта по регулярным выражениям.
Создай Regex-паттерн для валидации пароля, который соответствует следующим правилам:
1. Минимальная длина: 8 символов.
2. Максимальная длина: 64 символа.
3. Должен содержать как минимум одну заглавную букву (A-Z).
4. Должен содержать как минимум одну строчную букву (a-z).
5. Должен содержать как минимум одну цифру (0-9).
6. Должен содержать как минимум один специальный символ из набора: !@#$%^&*()_+-=[]{}|;:,.<>?
Предоставь ответ в следующем формате:
- **Паттерн:** [сам regex]
- **Объяснение:** Детально разбери каждую часть паттерна и объясни, как она работает, используя lookaheads.
- **Примеры:** Приведи 3 примера строк, которые соответствуют паттерну, и 3 примера, которые не соответствуют.
Почему это работает?
Роль: эксперт по регулярным выражениям задаёт контекст.
Чёткие правила: Вы даёте машине исчерпывающие требования.
Формат вывода: Вы заставляете AI структурировать ответ, что делает его полезным и понятным.
Экономьте своё время на рутине. Архитектор ценит свой мыслительный ресурс и автоматизирует всё, что можно автоматизировать.
#ai4admin #regex #powershell #bash #automation #промпты
❤2
Windows: Хватит кликать по Event Viewer! Фильтруем логи как профи с PowerShell
Журнал событий (Event Viewer) — мощный инструмент, но его графический интерфейс медленный и неудобный для поиска конкретных событий. Когда на сервере происходят тысячи событий в минуту, вам нужен скальпель, а не молоток.
Get-WinEvent — это ваш скальпель. Этот PowerShell-командлет позволяет мгновенно фильтровать и анализировать любые системные журналы.
Практические примеры:
Найти 10 последних ошибок в системном журнале:
PowerShell
Level=2 — это ошибки (Errors).
Найти все неудачные попытки входа (RDP/локальные) за последние 24 часа:
Это самый мощный способ — фильтрация через хеш-таблицу.
PowerShell
Проверить тот же лог на удалённом сервере:
Просто добавьте параметр -ComputerName.
PowerShell
Интерактивный поиск:
Для быстрой визуальной фильтрации отправьте результат в Out-GridView.
PowerShell
Откроется интерактивное окно, где можно сортировать и фильтровать события по любому полю.
Взгляд архитектора:
Умение быстро работать с логами из командной строки — это основа для создания систем автоматического реагирования. Скрипты на основе Get-WinEvent могут отправлять алерты в Telegram/Slack при появлении критических событий, собирать статистику для отчётов по безопасности и проводить аудит действий пользователей по всей инфраструктуре.
#windows #powershell #security #logging #audit #команды
Журнал событий (Event Viewer) — мощный инструмент, но его графический интерфейс медленный и неудобный для поиска конкретных событий. Когда на сервере происходят тысячи событий в минуту, вам нужен скальпель, а не молоток.
Get-WinEvent — это ваш скальпель. Этот PowerShell-командлет позволяет мгновенно фильтровать и анализировать любые системные журналы.
Практические примеры:
Найти 10 последних ошибок в системном журнале:
PowerShell
Get-WinEvent -LogName System -MaxEvents 10 -FilterXPath "*[System[Level=2]]"
Level=2 — это ошибки (Errors).
Найти все неудачные попытки входа (RDP/локальные) за последние 24 часа:
Это самый мощный способ — фильтрация через хеш-таблицу.
PowerShell
$StartTime = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625 # ID события "An account failed to log on"
StartTime = $StartTime
} | Select-Object TimeCreated, Message
Проверить тот же лог на удалённом сервере:
Просто добавьте параметр -ComputerName.
PowerShell
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4625}
Интерактивный поиск:
Для быстрой визуальной фильтрации отправьте результат в Out-GridView.
PowerShell
Get-WinEvent -LogName Application | Out-GridView
Откроется интерактивное окно, где можно сортировать и фильтровать события по любому полю.
Взгляд архитектора:
Умение быстро работать с логами из командной строки — это основа для создания систем автоматического реагирования. Скрипты на основе Get-WinEvent могут отправлять алерты в Telegram/Slack при появлении критических событий, собирать статистику для отчётов по безопасности и проводить аудит действий пользователей по всей инфраструктуре.
#windows #powershell #security #logging #audit #команды
Linux: Настрой и забудь. Автоматические обновления безопасности с Unattended-Upgrades
Обновлять пакеты вручную — хорошая практика, но на десятках или сотнях серверов она нереализуема. Пропущенное обновление безопасности может стать причиной взлома.
Архитектурно правильное решение — автоматизировать установку только критически важных обновлений безопасности, чтобы минимизировать риски простоя и обеспечить базовую защиту. В Ubuntu/Debian для этого есть unattended-upgrades.
Пошаговая настройка:
Установка (если его ещё нет):
Bash
Основная конфигурация:
Откройте файл /etc/apt/apt.conf.d/50unattended-upgrades. Найдите и раскомментируйте (уберите //) строку, отвечающую за security-апдейты:
Это разрешает установку обновлений только из репозитория безопасности.
В этом же файле можно настроить отправку отчётов на email или автоматическую перезагрузку, если она требуется.
Включение автоматического запуска:
Откройте файл /etc/apt/apt.conf.d/20auto-upgrades и убедитесь, что его содержимое выглядит так:
Первая строка включает ежедневное выполнение apt update. Вторая — ежедневный запуск unattended-upgrade.
Проверка и отладка:
Вы можете запустить процесс в "сухом" режиме, чтобы посмотреть, что именно будет обновлено:
Bash
Все логи работы хранятся в /var/log/unattended-upgrades/.
Взгляд архитектора:
Это не просто скрипт в кроне. Это компонент зрелой стратегии управления уязвимостями. Он обеспечивает постоянный базовый уровень безопасности для всего парка машин, освобождая время инженера для более сложных задач. Риск "сломать всё" минимален, так как обновления приложений и ядра (которые могут повлиять на совместимость) остаются для установки вручную.
#linux #security #automation #ubuntu #debian #гайд
Обновлять пакеты вручную — хорошая практика, но на десятках или сотнях серверов она нереализуема. Пропущенное обновление безопасности может стать причиной взлома.
Архитектурно правильное решение — автоматизировать установку только критически важных обновлений безопасности, чтобы минимизировать риски простоя и обеспечить базовую защиту. В Ubuntu/Debian для этого есть unattended-upgrades.
Пошаговая настройка:
Установка (если его ещё нет):
Bash
sudo apt update
sudo apt install unattended-upgrades
Основная конфигурация:
Откройте файл /etc/apt/apt.conf.d/50unattended-upgrades. Найдите и раскомментируйте (уберите //) строку, отвечающую за security-апдейты:
// Раскомментировать эту строку:
"${distro_id}:${distro_codename}-security";
Это разрешает установку обновлений только из репозитория безопасности.
В этом же файле можно настроить отправку отчётов на email или автоматическую перезагрузку, если она требуется.
Включение автоматического запуска:
Откройте файл /etc/apt/apt.conf.d/20auto-upgrades и убедитесь, что его содержимое выглядит так:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Первая строка включает ежедневное выполнение apt update. Вторая — ежедневный запуск unattended-upgrade.
Проверка и отладка:
Вы можете запустить процесс в "сухом" режиме, чтобы посмотреть, что именно будет обновлено:
Bash
sudo unattended-upgrades --dry-run --debug
Все логи работы хранятся в /var/log/unattended-upgrades/.
Взгляд архитектора:
Это не просто скрипт в кроне. Это компонент зрелой стратегии управления уязвимостями. Он обеспечивает постоянный базовый уровень безопасности для всего парка машин, освобождая время инженера для более сложных задач. Риск "сломать всё" минимален, так как обновления приложений и ядра (которые могут повлиять на совместимость) остаются для установки вручную.
#linux #security #automation #ubuntu #debian #гайд
Мониторинг: Сервер онлайн, а сайт лежит. Что такое Health Checks и зачем они вам?
Классический мониторинг (CPU, RAM, Disk) отвечает на вопрос: «Жива ли операционная система?». Но он не отвечает на главный вопрос: «Работает ли наш сервис?». Сервер может быть в порядке, но приложение внутри — зависнуть или потерять связь с базой данных.
Health Checks (проверки здоровья) — это конечные точки (endpoints) в вашем приложении, которые отвечают на вопрос о его внутреннем состоянии.
Простой пример:
Представьте, что у вас есть веб-приложение. Вы создаёте в нём специальный URL, например, /health.
Когда система мониторинга обращается к http://myapp.local/health, приложение выполняет внутреннюю проверку:
Может ли оно подключиться к своей базе данных?
Доступен ли кэш (Redis)?
Есть ли место в очереди сообщений (RabbitMQ)?
Если всё хорошо, оно возвращает HTTP-статус 200 OK и простое сообщение {"status": "ok"}.
Если есть проблема (например, отвалилась БД), оно возвращает 503 Service Unavailable.
Как это проверить даже вручную?
Bash
Взгляд архитектора:
Health checks — это основа для построения отказоустойчивых и самовосстанавливающихся систем.
Балансировщики нагрузки (Nginx, HAProxy) используют их, чтобы автоматически убирать из ротации "заболевшие" серверы.
Оркестраторы (Kubernetes, Docker Swarm) с помощью health checks понимают, что контейнер завис, и его нужно автоматически перезапустить.
Системы мониторинга (Zabbix, Prometheus) создают на их основе осмысленные алерты, которые сигнализируют о реальной проблеме, влияющей на пользователя.
Начните требовать от разработчиков такие эндпоинты. Это переход от мониторинга инфраструктуры к мониторингу качества сервиса (SRE).
#devops #monitoring #sre #architect #linux #гайд
Классический мониторинг (CPU, RAM, Disk) отвечает на вопрос: «Жива ли операционная система?». Но он не отвечает на главный вопрос: «Работает ли наш сервис?». Сервер может быть в порядке, но приложение внутри — зависнуть или потерять связь с базой данных.
Health Checks (проверки здоровья) — это конечные точки (endpoints) в вашем приложении, которые отвечают на вопрос о его внутреннем состоянии.
Простой пример:
Представьте, что у вас есть веб-приложение. Вы создаёте в нём специальный URL, например, /health.
Когда система мониторинга обращается к http://myapp.local/health, приложение выполняет внутреннюю проверку:
Может ли оно подключиться к своей базе данных?
Доступен ли кэш (Redis)?
Есть ли место в очереди сообщений (RabbitMQ)?
Если всё хорошо, оно возвращает HTTP-статус 200 OK и простое сообщение {"status": "ok"}.
Если есть проблема (например, отвалилась БД), оно возвращает 503 Service Unavailable.
Как это проверить даже вручную?
Bash
curl -s -o /dev/null -w "%{http_code}" http://myapp.local/health
# Ожидаемый здоровый ответ: 200
# Любой другой ответ (500, 503, 000) - это сигнал тревоги
Взгляд архитектора:
Health checks — это основа для построения отказоустойчивых и самовосстанавливающихся систем.
Балансировщики нагрузки (Nginx, HAProxy) используют их, чтобы автоматически убирать из ротации "заболевшие" серверы.
Оркестраторы (Kubernetes, Docker Swarm) с помощью health checks понимают, что контейнер завис, и его нужно автоматически перезапустить.
Системы мониторинга (Zabbix, Prometheus) создают на их основе осмысленные алерты, которые сигнализируют о реальной проблеме, влияющей на пользователя.
Начните требовать от разработчиков такие эндпоинты. Это переход от мониторинга инфраструктуры к мониторингу качества сервиса (SRE).
#devops #monitoring #sre #architect #linux #гайд
👍2
Linux & macOS: Устал читать man? Получай примеры команд за 1 секунду с tldr
Страницы man — это исчерпывающе, но когда тебе срочно нужно запаковать папку в tar или найти файл по размеру, читать трактат на 10 страниц нет времени.
tldr (Too Long; Didn't Read) — это утилита, которая показывает самые частые примеры использования команд. Никакой "воды", только практика.
Установка:
Bash
Сравним на примере tar:
man tar: Выдаст вам огромный мануал об истории tar, всех возможных флагах и опциях.
tldr tar: Покажет вам это:
Ещё пара примеров:
tldr find — покажет, как искать по имени, расширению, размеру.
tldr docker — даст базовые команды для работы с контейнерами и образами.
Взгляд архитектора:
Эффективность инженера измеряется не знанием наизусть всех флагов, а скоростью решения задачи. tldr — это инструмент для оптимизации самого ценного ресурса: вашего времени. Он помогает держать фокус на проблеме, а не на синтаксисе.
#linux #macos #cli #tldr #productivity #команды
Страницы man — это исчерпывающе, но когда тебе срочно нужно запаковать папку в tar или найти файл по размеру, читать трактат на 10 страниц нет времени.
tldr (Too Long; Didn't Read) — это утилита, которая показывает самые частые примеры использования команд. Никакой "воды", только практика.
Установка:
Bash
# macOS
brew install tldr
# Ubuntu/Debian
sudo apt install tldr
# Другие ОС (через Node.js)
npm install -g tldr
Сравним на примере tar:
man tar: Выдаст вам огромный мануал об истории tar, всех возможных флагах и опциях.
tldr tar: Покажет вам это:
# Создать архив из файлов:
tar -cvf target.tar file1 file2
# Создать gzip-архив:
tar -czvf target.tar.gz file1 file2
# Распаковать архив в текущую директорию:
tar -xvf source.tar
# Распаковать gzip-архив:
tar -xzvf source.tar.gz
# Посмотреть содержимое архива:
tar -tvf source.tar
Ещё пара примеров:
tldr find — покажет, как искать по имени, расширению, размеру.
tldr docker — даст базовые команды для работы с контейнерами и образами.
Взгляд архитектора:
Эффективность инженера измеряется не знанием наизусть всех флагов, а скоростью решения задачи. tldr — это инструмент для оптимизации самого ценного ресурса: вашего времени. Он помогает держать фокус на проблеме, а не на синтаксисе.
#linux #macos #cli #tldr #productivity #команды
👍2
macOS: Воспроизводимая среда с Homebrew. Управляем софтом через Brewfile
Каждый раз, настраивая новый Mac, вы вручную ставите десятки утилит и приложений через brew install ...? Это долго и легко что-то забыть.
Архитектурный подход — описать всё необходимое ПО в одном файле и развернуть среду одной командой. Для Homebrew такой файл называется Brewfile.
Как это работает:
Создаём "снимок" текущей системы:
Если у вас уже настроен Mac, создайте Brewfile из установленных пакетов:
Bash
Эта команда создаст в текущей директории файл Brewfile со всем, что у вас установлено.
Создаём Brewfile вручную (рекомендуется):
Создайте текстовый файл с именем Brewfile и опишите в нём всё, что вам нужно. Это даёт чистую и осознанную конфигурацию.
Ruby
Разворачиваем на новой машине:
Скопируйте ваш Brewfile на новый Mac (например, через Git) и выполните:
Bash
Homebrew сам установит всё, что перечислено в файле.
Взгляд архитектора:
Brewfile — это Конфигурация как Код (Configuration as Code) для вашей рабочей станции.
Воспроизводимость: Гарантирует, что на любой вашей машине будет одинаковый набор инструментов.
Версионирование: Храните его в Git. Теперь у вас есть история изменений и резервная копия вашей идеальной среды.
Автоматизация: Ускоряет настройку нового компьютера с нескольких часов до нескольких минут.
#macos #homebrew #automation #iac #гайд
Каждый раз, настраивая новый Mac, вы вручную ставите десятки утилит и приложений через brew install ...? Это долго и легко что-то забыть.
Архитектурный подход — описать всё необходимое ПО в одном файле и развернуть среду одной командой. Для Homebrew такой файл называется Brewfile.
Как это работает:
Создаём "снимок" текущей системы:
Если у вас уже настроен Mac, создайте Brewfile из установленных пакетов:
Bash
brew bundle dump
Эта команда создаст в текущей директории файл Brewfile со всем, что у вас установлено.
Создаём Brewfile вручную (рекомендуется):
Создайте текстовый файл с именем Brewfile и опишите в нём всё, что вам нужно. Это даёт чистую и осознанную конфигурацию.
Ruby
# Добавляем сторонний репозиторий (tap)
tap "homebrew/cask-fonts"
# CLI-утилиты (formulae)
brew "git"
brew "htop"
brew "wget"
brew "tldr"
# GUI-приложения (casks)
cask "visual-studio-code"
cask "iterm2"
cask "docker"
# Шрифты для терминала/редактора
cask "font-fira-code-nerd-font"
Разворачиваем на новой машине:
Скопируйте ваш Brewfile на новый Mac (например, через Git) и выполните:
Bash
brew bundle install
Homebrew сам установит всё, что перечислено в файле.
Взгляд архитектора:
Brewfile — это Конфигурация как Код (Configuration as Code) для вашей рабочей станции.
Воспроизводимость: Гарантирует, что на любой вашей машине будет одинаковый набор инструментов.
Версионирование: Храните его в Git. Теперь у вас есть история изменений и резервная копия вашей идеальной среды.
Автоматизация: Ускоряет настройку нового компьютера с нескольких часов до нескольких минут.
#macos #homebrew #automation #iac #гайд
🔥2
От Админа к Архитектору: 5 столпов, на которых стоит ИТ-инфраструктура
Проектировать надёжные системы, а не просто чинить их — значит мыслить в нескольких измерениях одновременно. Это и есть работа архитектора. Любое техническое решение, от выбора типа VM до настройки VPN, должно оцениваться по этим пяти критериям.
🛡️ Безопасность (Security):
Не просто "настроить файрвол". Это принцип наименьших привилегий, управление доступом (IAM), шифрование данных (в пути и в хранилище), регулярный аудит и управление секретами.
Вопрос для самопроверки: Где ваши скрипты хранят пароли?
⚙️ Надёжность (Reliability):
Не просто "99% аптайма". Это отказоустойчивость (fault tolerance), планы аварийного восстановления (DRP), регулярное тестирование бэкапов и построение самовосстанавливающихся систем (например, health checks в Kubernetes).
Вопрос для самопроверки: Вы уверены, что ваши бэкапы можно восстановить прямо сейчас?
🚀 Производительность (Performance Efficiency):
Не просто "купить процессор помощнее". Это правильный выбор ресурсов под задачу, оптимизация баз данных, использование кеширования (Redis, CDN) и мониторинг узких мест (bottlenecks).
Вопрос для самопроверки: Какой компонент вашей системы упадёт первым при росте нагрузки в 10 раз?
💰 Оптимизация затрат (Cost Optimization):
Не просто "выбрать самый дешёвый сервер". Это понимание моделей ценообразования (особенно в облаках), автоматическое отключение dev-стендов на ночь, использование spot-инстансов и постоянный поиск ресурсов, которые тратят деньги впустую.
Вопрос для самопроверки: Сколько стоит час простоя вашего главного сервиса? А час его работы?
🛠️ Операционное совершенство (Operational Excellence):
Фундамент, на котором стоят остальные. Это автоматизация всего, что можно (Infrastructure as Code), CI/CD для развёртывания, централизованный сбор логов и метрик, и наличие понятных инструкций (runbooks) для решения инцидентов.
Вопрос для самопроверки: Какую рутинную задачу вы автоматизируете следующей?
Начните оценивать любую задачу через призму этих пяти пунктов, и вы заметите, как меняется качество ваших решений.
#architect #devops #sre #security #career #гайд
Проектировать надёжные системы, а не просто чинить их — значит мыслить в нескольких измерениях одновременно. Это и есть работа архитектора. Любое техническое решение, от выбора типа VM до настройки VPN, должно оцениваться по этим пяти критериям.
🛡️ Безопасность (Security):
Не просто "настроить файрвол". Это принцип наименьших привилегий, управление доступом (IAM), шифрование данных (в пути и в хранилище), регулярный аудит и управление секретами.
Вопрос для самопроверки: Где ваши скрипты хранят пароли?
⚙️ Надёжность (Reliability):
Не просто "99% аптайма". Это отказоустойчивость (fault tolerance), планы аварийного восстановления (DRP), регулярное тестирование бэкапов и построение самовосстанавливающихся систем (например, health checks в Kubernetes).
Вопрос для самопроверки: Вы уверены, что ваши бэкапы можно восстановить прямо сейчас?
🚀 Производительность (Performance Efficiency):
Не просто "купить процессор помощнее". Это правильный выбор ресурсов под задачу, оптимизация баз данных, использование кеширования (Redis, CDN) и мониторинг узких мест (bottlenecks).
Вопрос для самопроверки: Какой компонент вашей системы упадёт первым при росте нагрузки в 10 раз?
💰 Оптимизация затрат (Cost Optimization):
Не просто "выбрать самый дешёвый сервер". Это понимание моделей ценообразования (особенно в облаках), автоматическое отключение dev-стендов на ночь, использование spot-инстансов и постоянный поиск ресурсов, которые тратят деньги впустую.
Вопрос для самопроверки: Сколько стоит час простоя вашего главного сервиса? А час его работы?
🛠️ Операционное совершенство (Operational Excellence):
Фундамент, на котором стоят остальные. Это автоматизация всего, что можно (Infrastructure as Code), CI/CD для развёртывания, централизованный сбор логов и метрик, и наличие понятных инструкций (runbooks) для решения инцидентов.
Вопрос для самопроверки: Какую рутинную задачу вы автоматизируете следующей?
Начните оценивать любую задачу через призму этих пяти пунктов, и вы заметите, как меняется качество ваших решений.
#architect #devops #sre #security #career #гайд
Аудит и чистка SSH-ключей в authorized_keys
Со временем файлы ~/.ssh/authorized_keys на серверах превращаются в свалку из десятков ключей: от бывших сотрудников, старых ноутбуков, CI/CD систем. Каждый забытый ключ — это потенциальная дверь в вашу инфраструктуру.
Воскресенье — идеальное время для ревизии.
Ваш чек-лист по аудиту:
Найдите все файлы authorized_keys:
Bash
Проверьте на слабые типы ключей:
Ключи ssh-dss (DSA) и ssh-rsa длиной 1024 бит считаются устаревшими и небезопасными.
Bash
Что делать: Свяжитесь с владельцем и попросите сгенерировать новый ключ типа ed25519 или rsa (3072/4096 бит).
Добавьте осмысленные комментарии:
Каждый ключ должен иметь комментарий, отвечающий на вопрос «Кто, откуда и когда?». Это золотой стандарт.
Сверяйте отпечатки (fingerprints):
Чтобы не сравнивать гигантские строки, получите отпечаток публичного ключа. Это проще и надёжнее.
Bash
Сравните его с отпечатком ключа на сервере.
Взгляд архитектора:
Это не просто уборка, это управление жизненным циклом доступа. В зрелых системах доступ должен быть не только выдан, но и своевременно отозван. Регулярный аудит ключей — это базовый элемент гигиены безопасности, который предотвращает инциденты, а не реагирует на них.
#linux #security #ssh #audit #гайд #чеклисты
Со временем файлы ~/.ssh/authorized_keys на серверах превращаются в свалку из десятков ключей: от бывших сотрудников, старых ноутбуков, CI/CD систем. Каждый забытый ключ — это потенциальная дверь в вашу инфраструктуру.
Воскресенье — идеальное время для ревизии.
Ваш чек-лист по аудиту:
Найдите все файлы authorized_keys:
Bash
# Ищем в домашних директориях и у root
find /home /root -name "authorized_keys"
Проверьте на слабые типы ключей:
Ключи ssh-dss (DSA) и ssh-rsa длиной 1024 бит считаются устаревшими и небезопасными.
Bash
# Эта команда подсветит строки со старыми типами ключей
grep -E 'ssh-dss|ssh-rsa' /path/to/authorized_keys
Что делать: Свяжитесь с владельцем и попросите сгенерировать новый ключ типа ed25519 или rsa (3072/4096 бит).
Добавьте осмысленные комментарии:
Каждый ключ должен иметь комментарий, отвечающий на вопрос «Кто, откуда и когда?». Это золотой стандарт.
ssh-ed25519 AAAA... alice@workstation-2025-10-05
ssh-ed25519 AAAA... jenkins-ci@build-server
Сверяйте отпечатки (fingerprints):
Чтобы не сравнивать гигантские строки, получите отпечаток публичного ключа. Это проще и надёжнее.
Bash
# Команда выполняется на машине, где лежит ПУБЛИЧНЫЙ ключ
ssh-keygen -lf my_key.pub
Сравните его с отпечатком ключа на сервере.
Взгляд архитектора:
Это не просто уборка, это управление жизненным циклом доступа. В зрелых системах доступ должен быть не только выдан, но и своевременно отозван. Регулярный аудит ключей — это базовый элемент гигиены безопасности, который предотвращает инциденты, а не реагирует на них.
#linux #security #ssh #audit #гайд #чеклисты
План на неделю: 3 технологии, на которые стоит потратить время
Воскресенье — лучший день, чтобы инвестировать в себя и спланировать обучение. Вот три технологии из разных областей, изучение которых сделает вас более ценным специалистом уже на этой неделе.
Для админов Windows: Chocolatey
Что это: Мощный, управляемый сообществом менеджер пакетов для Windows. "Старший брат" Winget.
Зачем: У Chocolatey огромный репозиторий пакетов и расширенные возможности для скриптов установки/удаления. Умение работать и с Winget, и с Chocolatey позволяет решать 100% задач по автоматизации ПО в Windows-среде. Это признак эксперта.
Для админов Linux: Podman
Что это: Движок для контейнеров без демона, позиционируется как полная замена Docker.
Зачем: Podman по умолчанию работает в режиме rootless (без прав суперпользователя), что гораздо безопаснее. Он нативно интегрируется с systemd для управления жизненным циклом контейнеров. Понимание его преимуществ — это шаг в сторону современных и более защищённых контейнерных сред.
Для всех (концепция): Zero Trust (Нулевое доверие)
Что это: Модель безопасности, основанная на принципе «никогда не доверяй, всегда проверяй». В ней нет понятия «внутренней доверенной сети». Каждый запрос, даже внутри периметра, должен быть аутентифицирован и авторизован.
Зачем: Это будущее корпоративной безопасности в мире облаков и удалённой работы. Изучите базовые понятия: микросегментация, Identity-Aware Proxy (IAP), MFA. Это изменит ваш подход к проектированию сетей и доступов.
Выберите одну тему и посвятите ей пару вечеров. Какой будет ваш выбор?
#career #learning #windows #chocolatey #linux #podman #security #zerotrust
Воскресенье — лучший день, чтобы инвестировать в себя и спланировать обучение. Вот три технологии из разных областей, изучение которых сделает вас более ценным специалистом уже на этой неделе.
Для админов Windows: Chocolatey
Что это: Мощный, управляемый сообществом менеджер пакетов для Windows. "Старший брат" Winget.
Зачем: У Chocolatey огромный репозиторий пакетов и расширенные возможности для скриптов установки/удаления. Умение работать и с Winget, и с Chocolatey позволяет решать 100% задач по автоматизации ПО в Windows-среде. Это признак эксперта.
Для админов Linux: Podman
Что это: Движок для контейнеров без демона, позиционируется как полная замена Docker.
Зачем: Podman по умолчанию работает в режиме rootless (без прав суперпользователя), что гораздо безопаснее. Он нативно интегрируется с systemd для управления жизненным циклом контейнеров. Понимание его преимуществ — это шаг в сторону современных и более защищённых контейнерных сред.
Для всех (концепция): Zero Trust (Нулевое доверие)
Что это: Модель безопасности, основанная на принципе «никогда не доверяй, всегда проверяй». В ней нет понятия «внутренней доверенной сети». Каждый запрос, даже внутри периметра, должен быть аутентифицирован и авторизован.
Зачем: Это будущее корпоративной безопасности в мире облаков и удалённой работы. Изучите базовые понятия: микросегментация, Identity-Aware Proxy (IAP), MFA. Это изменит ваш подход к проектированию сетей и доступов.
Выберите одну тему и посвятите ей пару вечеров. Какой будет ваш выбор?
#career #learning #windows #chocolatey #linux #podman #security #zerotrust
Быстрая проверка всех Windows-серверов
Понедельник начинается не с кофе, а с проверки, что всё работает после выходных. Вместо того чтобы вручную подключаться к каждому серверу, давайте автоматизируем утреннюю рутину.
Этот PowerShell-скрипт пробежится по списку ваших серверов и покажет статус ключевых служб, аптайм и свободное место на диске.
Код скрипта:
PowerShell
Как использовать:
Заполните массив $servers именами ваших машин.
Адаптируйте список $services под вашу инфраструктуру.
Запустите и получите полный отчёт за минуту.
Взгляд архитектора:
Это не просто скрипт, это элемент проактивного мониторинга. Он позволяет поймать проблему до того, как о ней сообщат пользователи. Следующий шаг — интегрировать его в Планировщик заданий и настроить отправку отчёта в почту или Telegram, превратив ручную проверку в полностью автоматическую систему.
#windows #powershell #automation #скрипты #monitoring
Понедельник начинается не с кофе, а с проверки, что всё работает после выходных. Вместо того чтобы вручную подключаться к каждому серверу, давайте автоматизируем утреннюю рутину.
Этот PowerShell-скрипт пробежится по списку ваших серверов и покажет статус ключевых служб, аптайм и свободное место на диске.
Код скрипта:
PowerShell
# Список серверов для проверки
$servers = @(
"DC01",
"WEBSRV01",
"SQLSRV01",
"FILESRV01"
)
# Список критически важных служб
$services = @(
"dns", # DNS Server
"w3svc", # IIS
"MSSQLSERVER", # SQL Server
"LanmanServer" # Server (File Sharing)
)
Write-Host "--- Начинаю утреннюю проверку серверов ---"
foreach ($server in $servers) {
Write-Host "`n[+] Проверяю сервер: $server" -ForegroundColor Yellow
# Проверяем доступность сервера
if (-not (Test-Connection -ComputerName $server -Count 1 -Quiet)) {
Write-Host " - Статус: НЕДОСТУПЕН" -ForegroundColor Red
continue
}
# Получаем аптайм
$osInfo = Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName $server
$uptime = (Get-Date) - $osInfo.LastBootUpTime
Write-Host (" - Аптайм: {0:N0} дней, {1} часов" -f $uptime.TotalDays, $uptime.Hours)
# Проверяем место на диске C:
$disk = Get-CimInstance -ClassName Win32_LogicalDisk -ComputerName $server -Filter "DeviceID='C:'"
$freeSpaceGB = [math]::Round($disk.FreeSpace / 1GB, 2)
Write-Host " - Свободно на диске C:: $freeSpaceGB GB"
# Проверяем статус служб
Write-Host " - Статус служб:"
foreach ($service in $services) {
$svc = Get-Service -Name $service -ComputerName $server -ErrorAction SilentlyContinue
if ($svc) {
if ($svc.Status -eq "Running") {
Write-Host " - $($svc.DisplayName): OK" -ForegroundColor Green
} else {
Write-Host " - $($svc.DisplayName): $($svc.Status)" -ForegroundColor Red
}
}
}
}
Как использовать:
Заполните массив $servers именами ваших машин.
Адаптируйте список $services под вашу инфраструктуру.
Запустите и получите полный отчёт за минуту.
Взгляд архитектора:
Это не просто скрипт, это элемент проактивного мониторинга. Он позволяет поймать проблему до того, как о ней сообщат пользователи. Следующий шаг — интегрировать его в Планировщик заданий и настроить отправку отчёта в почту или Telegram, превратив ручную проверку в полностью автоматическую систему.
#windows #powershell #automation #скрипты #monitoring
👍2
Linux & systemd: Управляем ресурсами "на лету" без перезагрузки
Представьте, один из сервисов (например, тестовое веб-приложение или скрипт аналитики) начал потреблять слишком много CPU или памяти, влияя на работу основных служб. Классическое решение — убить процесс. Архитектурное — ограничить его аппетиты.
systemd позволяет управлять ресурсами (CPU, память, I/O) для любого сервиса с помощью cgroups (Control Groups), и делать это "на лету".
Практический кейс: Ограничить сервис analytics.service максимум 20% CPU и 512MB RAM.
Проверяем текущее потребление:
systemd-cgtop — это htop для контрольных групп. Он покажет, какие сервисы и пользователи сколько ресурсов потребляют.
Bash
Устанавливаем ограничения "на лету":
Эти настройки будут действовать до перезагрузки сервиса или системы. Идеально для экстренных ситуаций.
Bash
Закрепляем настройки на постоянной основе:
Чтобы ограничения применялись при каждом запуске, нужно добавить их в unit-файл сервиса.
Bash
В открывшийся файл добавьте секцию [Service] с параметрами:
Ini, TOML
Сохраните файл и перезагрузите конфигурацию: sudo systemctl daemon-reload.
Взгляд архитектора:
Это гарантия качества обслуживания (QoS) на уровне одного сервера. Управляя ресурсами, вы предотвращаете ситуацию, когда один второстепенный процесс кладёт всю систему. Это фундаментальный подход для построения стабильной и предсказуемой инфраструктуры, особенно в средах с множеством сервисов (multi-tenant).
#linux #systemd #cgroups #sre #гайд
Представьте, один из сервисов (например, тестовое веб-приложение или скрипт аналитики) начал потреблять слишком много CPU или памяти, влияя на работу основных служб. Классическое решение — убить процесс. Архитектурное — ограничить его аппетиты.
systemd позволяет управлять ресурсами (CPU, память, I/O) для любого сервиса с помощью cgroups (Control Groups), и делать это "на лету".
Практический кейс: Ограничить сервис analytics.service максимум 20% CPU и 512MB RAM.
Проверяем текущее потребление:
systemd-cgtop — это htop для контрольных групп. Он покажет, какие сервисы и пользователи сколько ресурсов потребляют.
Bash
sudo systemd-cgtop
Устанавливаем ограничения "на лету":
Эти настройки будут действовать до перезагрузки сервиса или системы. Идеально для экстренных ситуаций.
Bash
# Ограничиваем CPU до 20%
sudo systemctl set-property analytics.service CPUQuota=20%
# Ограничиваем память до 512MB
sudo systemctl set-property analytics.service MemoryMax=512M
Закрепляем настройки на постоянной основе:
Чтобы ограничения применялись при каждом запуске, нужно добавить их в unit-файл сервиса.
Bash
# Открываем unit для редактирования
sudo systemctl edit analytics.service
В открывшийся файл добавьте секцию [Service] с параметрами:
Ini, TOML
[Service]
CPUQuota=20%
MemoryMax=512M
Сохраните файл и перезагрузите конфигурацию: sudo systemctl daemon-reload.
Взгляд архитектора:
Это гарантия качества обслуживания (QoS) на уровне одного сервера. Управляя ресурсами, вы предотвращаете ситуацию, когда один второстепенный процесс кладёт всю систему. Это фундаментальный подход для построения стабильной и предсказуемой инфраструктуры, особенно в средах с множеством сервисов (multi-tenant).
#linux #systemd #cgroups #sre #гайд
🔥4
Создай свой Runbook: Перестань быть героем, начни строить систему
Герой — это админ, который в 3 часа ночи в одиночку поднимает упавший сервер. Профессионал — это тот, кто создал Runbook (или Playbook), по которому этот сервер может поднять любой дежурный инженер за 15 минут.
Runbook — это подробная пошаговая инструкция по решению конкретной проблемы или выполнению стандартной операции.
Из чего состоит хороший Runbook:
Название: Чёткое и понятное. Пример: "Восстановление работы веб-сервера после сбоя БД".
Контекст: Когда применять эту инструкцию? Какие симптомы у проблемы? Пример: "Сайт отдаёт ошибку 503, в логах приложения ошибки подключения к PostgreSQL".
Пошаговые действия: Команды, которые нужно выполнить, скриншоты, куда нажать. Каждый шаг должен быть атомарным и проверяемым.
Проверка результата: Как убедиться, что проблема решена? Пример: "Выполнить curl -I site.com, ожидаемый ответ — HTTP/2 200".
План отката (Rollback): Что делать, если инструкция не помогла или сделала хуже?
Контакты: К кому обратиться за помощью, если ничего не помогает.
Где хранить?
Начните с простого: корпоративная Wiki (Confluence, Notion) или даже репозиторий в Markdown-файлах. Главное — чтобы это было доступно всей команде.
Взгляд архитектора:
Runbook — это способ кодификации знаний. Он снижает зависимость от конкретных людей, ускоряет решение инцидентов и является основой для дальнейшей автоматизации. Задача архитектора — не просто решать проблемы, а создавать систему, которая решает их предсказуемо и масштабируемо.
#devops #sre #runbook #architect #стратегия
Герой — это админ, который в 3 часа ночи в одиночку поднимает упавший сервер. Профессионал — это тот, кто создал Runbook (или Playbook), по которому этот сервер может поднять любой дежурный инженер за 15 минут.
Runbook — это подробная пошаговая инструкция по решению конкретной проблемы или выполнению стандартной операции.
Из чего состоит хороший Runbook:
Название: Чёткое и понятное. Пример: "Восстановление работы веб-сервера после сбоя БД".
Контекст: Когда применять эту инструкцию? Какие симптомы у проблемы? Пример: "Сайт отдаёт ошибку 503, в логах приложения ошибки подключения к PostgreSQL".
Пошаговые действия: Команды, которые нужно выполнить, скриншоты, куда нажать. Каждый шаг должен быть атомарным и проверяемым.
Проверка результата: Как убедиться, что проблема решена? Пример: "Выполнить curl -I site.com, ожидаемый ответ — HTTP/2 200".
План отката (Rollback): Что делать, если инструкция не помогла или сделала хуже?
Контакты: К кому обратиться за помощью, если ничего не помогает.
Где хранить?
Начните с простого: корпоративная Wiki (Confluence, Notion) или даже репозиторий в Markdown-файлах. Главное — чтобы это было доступно всей команде.
Взгляд архитектора:
Runbook — это способ кодификации знаний. Он снижает зависимость от конкретных людей, ускоряет решение инцидентов и является основой для дальнейшей автоматизации. Задача архитектора — не просто решать проблемы, а создавать систему, которая решает их предсказуемо и масштабируемо.
#devops #sre #runbook #architect #стратегия
🔥3❤2
Windows: Перестань быть слепым. Включаем "чёрный ящик" с помощью Sysmon
Стандартные логи Windows (Event Log) показывают, что произошло. Sysmon (System Monitor) показывает, как это произошло. Это бесплатная утилита из набора Sysinternals от Марка Руссиновича, которая превращает ваш сервер в настоящий бортовой самописец.
Sysmon — это не антивирус. Это инструмент для Threat Hunting (охоты на угрозы). Он логирует то, что обычно остаётся невидимым:
Создание процессов с хешами файлов.
Сетевые соединения для каждого процесса.
Загрузку драйверов и DLL.
Изменения в WMI и реестре.
Быстрый старт:
Скачайте Sysmon с сайта Microsoft (Sysinternals Suite).
Создайте конфигурационный файл. Начинать с нуля сложно, поэтому используйте проверенный шаблон от SwiftOnSecurity. Он отфильтровывает 95% шума и оставляет только потенциально вредоносные события.
PowerShell
Установка и запуск:
PowerShell
Где смотреть логи?
Все события Sysmon пишутся в стандартный Event Viewer по пути: Журналы приложений и служб / Microsoft / Windows / Sysmon / Operational.
Пример реального кейса:
Вы видите, что powershell.exe установил подозрительное сетевое соединение с IP-адресом в Китае (Событие ID 3). Открыв событие создания этого процесса (ID 1), вы видите его родительский процесс — winword.exe. Это классический признак фишинговой атаки через макрос в документе. Со стандартными логами вы бы этого не увидели.
Взгляд архитектора:
Sysmon — это основа для построения централизованной системы сбора и анализа логов (SIEM). Отправляя события Sysmon в ELK Stack, Splunk или Graylog, вы получаете полную картину происходящего в вашей инфраструктуре и можете выявлять сложные атаки на ранних стадиях.
#windows #security #sysmon #sysinternals #threat_hunting #architect
Стандартные логи Windows (Event Log) показывают, что произошло. Sysmon (System Monitor) показывает, как это произошло. Это бесплатная утилита из набора Sysinternals от Марка Руссиновича, которая превращает ваш сервер в настоящий бортовой самописец.
Sysmon — это не антивирус. Это инструмент для Threat Hunting (охоты на угрозы). Он логирует то, что обычно остаётся невидимым:
Создание процессов с хешами файлов.
Сетевые соединения для каждого процесса.
Загрузку драйверов и DLL.
Изменения в WMI и реестре.
Быстрый старт:
Скачайте Sysmon с сайта Microsoft (Sysinternals Suite).
Создайте конфигурационный файл. Начинать с нуля сложно, поэтому используйте проверенный шаблон от SwiftOnSecurity. Он отфильтровывает 95% шума и оставляет только потенциально вредоносные события.
PowerShell
# Скачиваем конфиг
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile sysmonconfig.xml
Установка и запуск:
PowerShell
# Устанавливаем Sysmon как службу с нашим конфигом
.\sysmon.exe -accepteula -i sysmonconfig.xml
Где смотреть логи?
Все события Sysmon пишутся в стандартный Event Viewer по пути: Журналы приложений и служб / Microsoft / Windows / Sysmon / Operational.
Пример реального кейса:
Вы видите, что powershell.exe установил подозрительное сетевое соединение с IP-адресом в Китае (Событие ID 3). Открыв событие создания этого процесса (ID 1), вы видите его родительский процесс — winword.exe. Это классический признак фишинговой атаки через макрос в документе. Со стандартными логами вы бы этого не увидели.
Взгляд архитектора:
Sysmon — это основа для построения централизованной системы сбора и анализа логов (SIEM). Отправляя события Sysmon в ELK Stack, Splunk или Graylog, вы получаете полную картину происходящего в вашей инфраструктуре и можете выявлять сложные атаки на ранних стадиях.
#windows #security #sysmon #sysinternals #threat_hunting #architect
👍2
Linux & curl: Ты используешь его неправильно. 3 продвинутых трюка
Все знают curl https://google.com. Но curl — это не просто браузер в терминале, это швейцарский нож для работы с любым HTTP-ресурсом. Пора использовать его как профессионал.
Трюк 1: Анализ времени ответа (профилирование)
Когда сайт тормозит, где именно проблема: DNS, TCP-соединение, SSL-рукопожатие или ожидание ответа от сервера? curl может разложить всё по полочкам.
Bash
Вы получите JSON с точным временем каждого этапа соединения.
Трюк 2: Отправка JSON и заголовков (тестирование API)
Не нужно ставить Postman, чтобы протестировать API.
Bash
Трюк 3: Повтор запроса при ошибке (для скриптов)
Ваш скрипт упал, потому что сеть моргнула? curl может сам повторить запрос.
Bash
Взгляд архитектора:
curl — это не просто утилита, это универсальный кирпичик для построения систем автоматизации и мониторинга. Глубокое понимание его возможностей позволяет писать надёжные скрипты, создавать health checks для сервисов и проводить отладку сетевых взаимодействий без привлечения тяжеловесных инструментов.
#linux #curl #devops #api #networking #команды
Все знают curl https://google.com. Но curl — это не просто браузер в терминале, это швейцарский нож для работы с любым HTTP-ресурсом. Пора использовать его как профессионал.
Трюк 1: Анализ времени ответа (профилирование)
Когда сайт тормозит, где именно проблема: DNS, TCP-соединение, SSL-рукопожатие или ожидание ответа от сервера? curl может разложить всё по полочкам.
Bash
# Создаём файл curl-format.txt с нужными переменными
cat > curl-format.txt <<EOF
{
"time_namelookup": "%{time_namelookup}",
"time_connect": "%{time_connect}",
"time_appconnect": "%{time_appconnect}",
"time_pretransfer": "%{time_pretransfer}",
"time_starttransfer": "%{time_starttransfer}",
"time_total": "%{time_total}"
}
EOF
# Запускаем curl с нашим форматом вывода
curl -w "@curl-format.txt" -o /dev/null -s https://habr.com/
Вы получите JSON с точным временем каждого этапа соединения.
Трюк 2: Отправка JSON и заголовков (тестирование API)
Не нужно ставить Postman, чтобы протестировать API.
Bash
# Отправляем POST-запрос с JSON-телом и кастомным заголовком
curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer mysecrettoken" \
-d '{"username":"admin","status":"active"}' \
http://api.example.com/users
Трюк 3: Повтор запроса при ошибке (для скриптов)
Ваш скрипт упал, потому что сеть моргнула? curl может сам повторить запрос.
Bash
# Попробовать 5 раз с задержкой в 10 секунд между попытками
curl --retry 5 --retry-delay 10 https://updates.example.com/latest.zip -O
Взгляд архитектора:
curl — это не просто утилита, это универсальный кирпичик для построения систем автоматизации и мониторинга. Глубокое понимание его возможностей позволяет писать надёжные скрипты, создавать health checks для сервисов и проводить отладку сетевых взаимодействий без привлечения тяжеловесных инструментов.
#linux #curl #devops #api #networking #команды
Pets vs Cattle: Главный принцип облачной архитектуры, который должен знать каждый админ
Этот знаменитый афоризм из мира облачных вычислений меняет всё. Он разделяет серверы на два типа и определяет, как вы должны к ним относиться.
Pets (питомцы):
Это серверы, к которым вы относитесь как к домашним любимцам.
У них есть уникальные имена (db-master-01, mail-srv).
Вы их холите и лелеете, ставите обновления вручную, лечите, когда они "болеют".
Если такой сервер падает — это катастрофа, все бегут его поднимать.
Примеры: Контроллер домена, основной сервер баз данных, старый монолитный сервер приложений.
Cattle (скот):
Это серверы, к которым относятся как к стаду.
У них нет имён, только номера (web-worker-001, web-worker-002).
Их никто не лечит. Если один сервер "заболел", его просто "пристреливают" (удаляют), а на его место автоматически приходит новый, созданный из того же образа.
Потеря одного сервера — не событие. Система в целом продолжает работать.
Примеры: Веб-серверы за балансировщиком, воркеры в Kubernetes-кластере, инстансы в Auto Scaling Group.
Взгляд архитектора:
Цель современной архитектуры — превратить как можно больше "питомцев" в "стадо". Это достигается через автоматизацию (Ansible, Terraform), контейнеризацию (Docker, Kubernetes) и проектирование приложений, которые не хранят состояние локально (stateless). Такой подход позволяет строить масштабируемые, отказоустойчивые и легко управляемые системы.
Задайте себе вопрос: сколько в вашей инфраструктуре "питомцев", и что нужно сделать, чтобы их стало меньше?
#architect #cloud #devops #petsvscattle #sre #стратегия
Этот знаменитый афоризм из мира облачных вычислений меняет всё. Он разделяет серверы на два типа и определяет, как вы должны к ним относиться.
Pets (питомцы):
Это серверы, к которым вы относитесь как к домашним любимцам.
У них есть уникальные имена (db-master-01, mail-srv).
Вы их холите и лелеете, ставите обновления вручную, лечите, когда они "болеют".
Если такой сервер падает — это катастрофа, все бегут его поднимать.
Примеры: Контроллер домена, основной сервер баз данных, старый монолитный сервер приложений.
Cattle (скот):
Это серверы, к которым относятся как к стаду.
У них нет имён, только номера (web-worker-001, web-worker-002).
Их никто не лечит. Если один сервер "заболел", его просто "пристреливают" (удаляют), а на его место автоматически приходит новый, созданный из того же образа.
Потеря одного сервера — не событие. Система в целом продолжает работать.
Примеры: Веб-серверы за балансировщиком, воркеры в Kubernetes-кластере, инстансы в Auto Scaling Group.
Взгляд архитектора:
Цель современной архитектуры — превратить как можно больше "питомцев" в "стадо". Это достигается через автоматизацию (Ansible, Terraform), контейнеризацию (Docker, Kubernetes) и проектирование приложений, которые не хранят состояние локально (stateless). Такой подход позволяет строить масштабируемые, отказоустойчивые и легко управляемые системы.
Задайте себе вопрос: сколько в вашей инфраструктуре "питомцев", и что нужно сделать, чтобы их стало меньше?
#architect #cloud #devops #petsvscattle #sre #стратегия