Мониторинг: Сервер онлайн, а сайт лежит. Что такое 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

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 #гайд

Linux & macOS: Устал читать man? Получай примеры команд за 1 секунду с tldr

Страницы 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 #команды

macOS: Воспроизводимая среда с Homebrew. Управляем софтом через Brewfile

Каждый раз, настраивая новый 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 #гайд

От Админа к Архитектору: 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 #гайд

Аудит и чистка SSH-ключей в authorized_keys

Со временем файлы ~/.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-серверов

Понедельник начинается не с кофе, а с проверки, что всё работает после выходных. Вместо того чтобы вручную подключаться к каждому серверу, давайте автоматизируем утреннюю рутину.

Этот 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

Linux & systemd: Управляем ресурсами "на лету" без перезагрузки

Представьте, один из сервисов (например, тестовое веб-приложение или скрипт аналитики) начал потреблять слишком много 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 #гайд

Создай свой 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 #стратегия

Windows: Перестань быть слепым. Включаем "чёрный ящик" с помощью Sysmon

Стандартные логи 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

Linux & curl: Ты используешь его неправильно. 3 продвинутых трюка

Все знают 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 #стратегия

Windows DNS: Построй свою "черную дыру". Создаем DNS Sinkhole для защиты от вредоносов

Когда пользователь кликает на фишинговую ссылку, его компьютер сначала обращается к DNS-серверу, чтобы узнать IP-адрес вредоносного домена. Что если мы можем перехватить этот запрос и отправить пользователя в безопасное место (или в никуда)?

Это и есть DNS Sinkhole (или Blackhole) — один из самых эффективных способов блокировки вредоносной активности на уровне всей сети.

Как это реализовать на Windows DNS Server:

Создаем "черную дыру":
Откройте диспетчер DNS.
Создайте новую зону прямого просмотра (Primary Zone).
Имя зоны — это вредоносный домен, который вы хотите заблокировать (например, malicious-site.com).
Создайте в этой зоне запись типа A с * (звездочка) в качестве имени.
В качестве IP-адреса укажите 127.0.0.1 (localhost) или IP-адрес внутреннего сервера с заглушкой "Доступ заблокирован".

Автоматизируем с PowerShell:
Вручную добавлять тысячи доменов — не вариант. Используем PowerShell и списки блокировки.

PowerShell

# Список доменов для блокировки (в реальности он будет загружаться из файла или URL)
$BlockList = @(
    "bad-domain-1.com",
    "phishing-site-2.net",
    "malware-dist-3.org"
)

# IP-адрес нашей "черной дыры"
$SinkholeIP = "127.0.0.1"

foreach ($Domain in $BlockList) {
    Write-Host "Создаю зону для: $Domain"
    # Создаём зону
    Add-DnsServerPrimaryZone -Name $Domain -ReplicationScope "Forest" -PassThru

    # Создаём wildcard A-запись, которая перенаправляет весь трафик
    Add-DnsServerResourceRecordA -ZoneName $Domain -Name "*" -IPv4Address $SinkholeIP
}

Этот скрипт можно поставить в Планировщик Задач для автоматического обновления из публичных блэклистов (например, StevenBlack/hosts).

Взгляд архитектора:
DNS Sinkhole — это первый эшелон обороны. Он не требует установки агентов на клиентские машины и защищает все устройства в сети, включая те, которые сложно контролировать (BYOD, IoT). Это проактивный подход к безопасности, который блокирует угрозу еще до того, as она достигнет своей цели.

#windows #security #dns #powershell #architect #гайд

Linux: Когда top и htop бессильны. Знакомство с perf — скальпелем для анализа производительности

top показывает, какой процесс грузит CPU. perf показывает, какая функция внутри этого процесса грузит CPU. Это инструмент уровня SRE и kernel-разработчиков, но основы его использования должен знать каждый продвинутый админ.

Практический кейс: Веб-сервер Nginx начал потреблять много CPU. Почему?

Собираем данные (профилирование):
Запускаем perf на 10 секунд, чтобы собрать статистику по всей системе с частотой 99 Гц.

Bash

# perf требует прав root или специальной настройки
sudo perf record -F 99 -a -g -- sleep 10

-a — по всей системе, -g — записывать графы вызовов.
В текущей директории будет создан файл perf.data.

Анализируем отчет:
Открываем собранные данные в интерактивном режиме.

Bash

sudo perf report

Вы увидите псевдографический интерфейс, где сможете "проваливаться" внутрь процессов и функций. В нашем случае мы найдем процесс nginx, раскроем его и увидим, что, например, 90% времени CPU тратится на функцию, связанную со сжатием gzip или обработкой SSL.

Другие полезные команды:

sudo perf top — интерактивный режим, похожий на top, но с функциями.

sudo perf stat <command> — запускает команду и показывает детальную статистику по её выполнению (промахи кэша, ошибки страниц и т.д.).

Взгляд архитектора:
perf позволяет находить коренные причины (root cause) проблем с производительностью, а не бороться с симптомами. Умение работать с такими инструментами отличает инженера, который может оптимизировать систему на низком уровне, от админа, который в любой непонятной ситуации просто добавляет CPU.

#linux #performance #sre #perf #monitoring #команды

AI-промпт: "Напиши за меня PowerShell скрипт для аудита локальных администраторов"

Одна из самых частых задач ИБ-аудита — проверить, кто входит в группу локальных администраторов на всех рабочих станциях. Давайте заставим AI сгенерировать для нас готовый к работе скрипт.

Промпт (для ChatGPT/Gemini/Copilot):

Выступи в роли Senior PowerShell-разработчика и эксперта по безопасности Active Directory.

Напиши PowerShell-скрипт, который выполняет следующие действия:
1.  Берёт список всех активных компьютеров из указанного Organizational Unit (OU) в Active Directory.
2.  Для каждого компьютера из списка получает членов локальной группы "Администраторы" (Administrators).
3.  Игнорирует стандартных членов группы (Administrator, Domain Admins).
4.  Выводит результат в виде таблицы: Компьютер, Пользователь/Группа.
5.  Экспортирует результат в CSV-файл для дальнейшего анализа.
6.  Скрипт должен содержать комментарии, объясняющие ключевые шаги.

Предоставь готовый к выполнению код.
Почему это работает:

Роль: Senior PowerShell-разработчик и эксперт по безопасности задают высокий стандарт качества кода и правильность подходов.

Декомпозиция: Мы разбили задачу на 6 четких шагов. AI не нужно додумывать, что мы хотим.
Исключения: Указание "игнорирует стандартных членов" делает результат сразу полезным, отсекая шум.
Формат вывода: Мы просим не просто вывести на экран, а создать CSV-файл, что характерно для реальной задачи.
Результат: Вы получите готовый скрипт на 20-30 строк, который можно сразу использовать. Архитектор не тратит время на написание рутинных скриптов, он тратит время на анализ их результатов.

#ai4admin #powershell #security #activedirectory #automation #промпты

Self-Hosted: Ваша личная IT-империя. Альтернативы SaaS-сервисам

Мы привыкли платить за подписки: почта, облачное хранилище, видеозвонки, таск-трекеры. Но что, если можно запустить всё это на своём сервере, полностью контролируя данные и избавляясь от ежемесячных платежей?

Наши коллеги-энтузиасты собрали гигантскую подборку open-source приложений для запуска почти любых сервисов прямо у вас. Почта (Mailu), облачное хранилище (Nextcloud), видеоконференции (Jitsi), менеджер паролей (Vaultwarden), стриминг-платформы (Jellyfin) — всё в одном месте.

Что внутри:

Список self-hosted альтернатив для десятков популярных SaaS.

Ссылки на GitHub и документацию.

Часто — готовые docker-compose.yml для быстрого старта.

Взгляд архитектора:
Это не просто про экономию. Это про суверенитет данных и создание идеального Home Lab. Разворачивая эти сервисы, вы на практике оттачиваете ключевые навыки: работа с Docker, настройка Nginx в роли reverse proxy, конфигурация бэкапов и мониторинга.

Главный архитектурный принцип здесь — свобода в обмен на ответственность. Вы получаете полный контроль, но безопасность, обновления и аптайм — теперь ваша задача.

Забираем бесценную подборку по ссылке:
https://github.com/Atarity/deploy-your-own-saas

#selfhosted #linux #docker #devops #saas #гайд

Windows: Не отключай Firewall! Управляй им как профи через PowerShell

Самый частый "совет" по решению проблем с сетью в Windows — "отключи брандмауэр". С точки зрения безопасности — это катастрофа. Графический интерфейс файрвола действительно неудобен, но у архитектора есть PowerShell.
Управлять правилами из командной строки — быстро, удобно и, главное, автоматизируемо.
Базовые команды, которые нужно знать:
Проверить статус всех профилей (Domain, Private, Public):
PowerShell

Get-NetFirewallProfile | Format-Table Name, Enabled

Создать простое правило (например, разрешить входящий SSH):
PowerShell

New-NetFirewallRule -DisplayName "Allow SSH In" -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow -Profile Domain, Private

Найти и временно отключить правило:
PowerShell

# Находим правило по имени
Get-NetFirewallRule -DisplayName "Allow SSH In"

# Отключаем его, не удаляя
Disable-NetFirewallRule -DisplayName "Allow SSH In"

Управлять правилами на удалённом сервере:
Используем CIM-сессии для удалённого выполнения.
PowerShell

$session = New-CimSession -ComputerName WEBSRV01
Get-NetFirewallRule -CimSession $session -DisplayName "Allow-File-And-Printer-Sharing"

Взгляд архитектора:
Брандмауэр — это не помеха, а критический компонент эшелонированной обороны (Defense in Depth). Использование PowerShell позволяет применять Конфигурацию как Код (CaC) к правилам безопасности. Вы можете хранить скрипты с правилами в Git, версионировать их и раскатывать на сотни серверов, гарантируя единый стандарт безопасности по всей инфраструктуре.

#windows #security #powershell #firewall #networking #гайд

Linux & API: Парсим JSON в терминале как боги с помощью jq

curl-нул API и получил в ответ стену текста в формате JSON? Пытаться разобрать это глазами или через grep — прошлый век. Для работы со структурированными данными в терминале есть свой sed и awk — это утилита jq.
jq — это легковесный и сверхмощный обработчик JSON для командной строки.
Установка: sudo apt install jq или brew install jq.
Практический пример с GitHub API:

Получаем и красиво форматируем JSON:

Bash

# Просто передаём вывод curl в jq с фильтром '.' (точка)
curl -s 'https://api.github.com/users/torvalds' | jq '.'
``
Извлекаем одно значение:

Bash

# Получаем значение ключа "name"
curl -s 'https://api.github.com/users/torvalds' | jq '.name'
# Результат: "Linus Torvalds"

Извлекаем несколько значений и создаем свой объект:

Bash

curl -s 'https://api.github.com/users/torvalds' | jq '{user: .login, company: .company, location: .location}'

Работаем с массивами (самое мощное):

Bash

# Получаем список репозиториев и выводим только их имена
curl -s 'https://api.github.com/users/torvalds/repos' | jq '.[ ].name'
`
[ ] — итератор по массиву.

Взгляд архитектора:
jq — это клей для современной автоматизации. Он позволяет строить сложные и надёжные пайплайны в bash-скриптах, которые работают с API облачных провайдеров, системами мониторинга и любыми другими сервисами, говорящими на JSON. Это превращает нечитаемые данные в полезную информацию прямо в терминале.

#linux #jq #json #api #bash #devops #команды

Проект на выходные: Nginx Proxy Manager. Управляем реверс-прокси и SSL через GUI

Редактировать конфиги Nginx вручную для каждого нового сервиса — рутина, в которой легко ошибиться. Если вы поднимаете много веб-приложений (особенно в своей Home Lab), вам нужен инструмент, который делает это красиво.

Nginx Proxy Manager — это готовое решение в Docker-контейнере, которое даёт вам удобный веб-интерфейс для управления всеми вашими сайтами и реверс-прокси.

Ключевые фичи:

Графический интерфейс: Забудьте про правку конфигов. Добавляйте хосты, настраивайте редиректы и защиту парой кликов.

Бесплатные SSL-сертификаты: Встроенная интеграция с Let's Encrypt. Он сам получит и будет автоматически продлевать сертификаты для ваших доменов.

Списки доступа (Access Lists): Ограничивайте доступ к сервисам по IP или через логин/пароль.

Простая установка: Запускается одной docker-compose командой.

Готовый docker-compose.yml для старта:

YAML

version: '3.8'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # Public HTTP Port:
      - '80:80'
      # Public HTTPS Port:
      - '443:443'
      # Admin Port:
      - '81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Запустите docker-compose up -d, откройте http://<ваш_ip>:81 и начните настраивать.

Взгляд архитектора:
Этот инструмент не просто экономит время. Он стандартизирует и защищает ваши точки входа. Best practice (как, например, SSL для всего) становятся настройкой по умолчанию, а не чем-то, что можно забыть. Это идеальный способ навести порядок в зоопарке ваших веб-сервисов.

#linux #docker #nginx #selfhosted #гайд #weekendproject

Linux: Вы всё ещё просто "листаете" логи? Раскрываем всю мощь less

Пятница, конец дня. Нужно быстро найти причину сбоя в лог-файле на несколько гигабайт. Все знают less, но большинство используют только стрелки и клавишу q. А ведь это мощнейший инструмент для анализа.

5 трюков, которые ускорят вашу работу:

F (Follow mode): Нажмите Shift + F в открытом файле. less перейдет в режим tail -f и будет показывать новые строки в реальном времени. Чтобы выйти из этого режима и вернуться к поиску, нажмите Ctrl + C.

/ и ? (Поиск): /слово — ищет "слово" от текущей позиции вниз. ?слово — ищет вверх. Клавиши n и N — переход к следующему/предыдущему совпадению.

& (Фильтрация): Введите & и паттерн (например, &ERROR). less скроет все строки, которые не содержат ERROR. Чтобы сбросить фильтр, введите & и нажмите Enter. Это как grep, но без выхода из файла.

m и ' (Метки): Находясь на важной строке (например, начало транзакции), нажмите m и любую букву (например, a). Вы создали метку "a". Теперь, промотав файл на тысячу строк вниз к ошибке, вы можете мгновенно вернуться к метке, нажав ' и ту же букву ('a).

-N (Номера строк): Запускайте less -N your_log_file.log, чтобы видеть номера строк. Незаменимо, когда обсуждаете лог с коллегой.

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

#linux #less #cli #logging #команды #productivity