Серьёзно, если ты до сих пор руками лазаешь по страницам и сверяешь, не отвалился ли robots.txt или не появился ли вдруг noindex там, где его быть не должно – ты тратишь жизнь впустую. Напиши скрипт. Или попроси написать. Или найди готовый. Неважно. Просто перестань делать это глазами.
Каждый раз, когда я открывал DevTools – где-то умирал маленький сервер
Потому что я снова начинал щёлкать по вкладкам, проверять метатеги, заголовки, canonical’ы – всё то, что должно быть проверено разом, списком, и лучше всего с утренним кофе, пока мозг ещё не знает, что его ждёт.
У меня был кейс: клиент пришёл с жалобой – позиции упали. Сайт на 12k страниц. Все на вид ок. А потом бах – 600 страниц с canonical на 404. Кто это должен был заметить? Конечно, я. Но руками – да никогда. Меня спас парсинг через Python + csv + мат в голос.
Не всё сразу, но хоть что-то
Не нужно строить Гугл в миниатюре. Начни с малого – проверь тайтлы. Один раз. Потом научи скрипт это делать сам. Потом добавь проверку на дубли. Потом – глубину вложенности. Потом – скорость отклика. Ты не обязан всё автоматизировать за вечер пятницы. Но если ты сделаешь хотя бы одну проверку скриптом – это уже победа.
Вот список, с чего я начинал (и да, местами это стыдно, но честно):
- Парсинг sitemap.xml на битые ссылки
- Проверка редиректов (да, curl + bash – живы!)
- Сравнение заголовков с шаблоном (excel + regex – да!)
- Логирование страниц с 302 (кто вообще ещё ими пользуется?!)
Главное – не заморачиваться интерфейсом
У меня всё в консоли. Чёрный экран, белый текст, иногда зелёный. Выглядит как DOS из 90-х. Но он делает свою работу. А я не трачу на это время. Ну разве не в этом суть?
Ты никогда не узнаешь, что ты сломал, пока не проверишь то, что «вроде как не трогал»
Забавный факт: в проекте, где я был уверен, что теги h1 как влитые, оказалось, что на половине карточек товаров они просто исчезли после обновления шаблона. Почему? Потому что фронтендер решил, что h1 внутри таба – плохая идея. И всё.
Я бы это не заметил, если бы не регулярная проверка. Не из-за паранойи. Просто потому что скрипт работает сам. Я – нет. Ну и хорошо.
А теперь представь, что у тебя такой скрипт есть. И работает. И сам пишет тебе в телегу, если что-то не так. Хочешь?
Вот и я тоже. Пошёл дописывать скрипт. Пока ты читаешь.
Как автоматически выявлять критические ошибки в конфигурациях серверов
Начни с самого простого – проверь, что вообще живо
Вот серьёзно – ты удивишься, сколько серверов тихо умирают, пока все делают вид, что всё работает. Самое первое, что я советую – пинг и доступность портов. Можно даже без изысков: скрипт на bash, который раз в час пингует и логирует статус. Это не «высокие технологии», но, блин, работает.
У нас на проекте как-то не заметили, что база три дня не отвечала, потому что никто не смотрел… Ничего. А потом начали копать, и оказалось – ssl-сертификат истёк. Никто не продлил. Потому что «автоматически же всё» – ага.
Ошибки прав – самая тупая и самая частая боль
Вот где боль, так это в правах доступа. У тебя nginx может быть супер-отлаженный, но если root может писать куда угодно, а юзер – никуда, то будь готов к сюрпризам.
Я пользуюсь грубым методом – сканирую все конфиги и логи на наличие 777, 666 и прочей чертовщины. Либо через обычный grep -r "777", либо через мини-скрипты на Python. И потом – ручками гляжу, кто и зачем это сделал. Иногда находишь шедевры, типа /etc/shadow с правами на чтение для всех. Без шуток.
Мониторинг конфигов через git – это не из серии «потом», это сейчас
Настрой автоматическое версионирование конфигураций через git (или хотя бы через etckeeper). Это как тайм-машина: можно отмотать, можно сравнить. Особенно полезно, когда конфиги правят пятеро, каждый думает, что он гений, а потом ничего не работает.
Я использовал это в проекте, где сервер жило 12 админов. Без этого – чистый анархизм. С этим – ну, хотя бы можно понять, кто вчера вечером решил закомментировать firewall.
Оповещения, алерты, но не спам
Знаешь, что бесит больше всего? Когда мониторинг шлёт тебе по 200 писем в день. Поэтому настрой алерты только по реально важным штукам: 95% CPU, сервис упал, диск на 95% забит – да. А вот «на 3 секунды подрос latency» – пусть сам с собой поплачет.
Я лично использую связку Prometheus + Alertmanager и фильтры на почте. А когда совсем лень – zabbix с минимальной конфигурацией. Главное – чтобы не бесило, но и не проспать аварию.
И да, используй чужие наработки
Я раньше пытался всё писать с нуля. Ну, типа «я же крутой». Потом начал брать готовое. Например, вот тут нашёл мегакомбайн для генерации полезных штук, сначала думал – бред, потом затянуло. А здесь наткнулся на хорошие практики, которые легко адаптировать под своё. Даже если текст вроде про другое – мысли применимы.
Вместо финала – странный, но полезный совет
Иногда лучший способ найти косяк – это дать сервер на ревью другому человеку. Без всякой автоматизации. Просто попроси: «глянь конфиги, вдруг я баран». Часто работает. Особенно если ты и правда баран (я был – не раз). А потом уже автоматизируй, что реально повторяется.
Интеграция инструментов аудита в CI/CD-пайплайны: настройка и практические примеры
Ставь линтеры и сканеры туда же, куда ставишь тесты
Первое, что я обычно делаю, – это беру какой-нибудь eslint, stylelint или pylint (ну, зависит от проекта, не суть) и просто впихиваю в пайплайн рядом с юнитами. Типа, билд упал – значит, где-то накосячили. Без лишних эмоций.
И да, не надо устраивать гала-концерт из настройки. Один конфиг, одна команда. В GitLab это может быть eslint --max-warnings=0. В GitHub Actions – аналогично, с run. Пример? Да на прошлом проекте засунул bandit для Python прямо в .gitlab-ci.yml. Полчаса – и всё в строю. Даже пиццу за это время не успел заказать.
Разделяй и властвуй (ну, типа хотя бы визуально)
Я как-то видел пайплайн, где всё подряд валится в один stage. Статический анализ, тесты, деплой – всё кучей. Это как если бы на кухне соль, молоток и йогурт лежали в одном ящике. Ну неудобно же, правда?
Раздели: analyze – один stage, build – другой. Пусть CI чётко показывает, что именно отвалилось. Ты ж не хочешь вечером в пятницу сидеть и гадать, что именно сломалось в деплое: код или инфраструктура?
Сканеры безопасности – не только для параноиков
Нет, реально. Я раньше думал, что вся эта история с уязвимостями – только для банков и параноидальных девопсов. А потом мне пришлось объяснять заказчику, почему мы подтянули зависимость с уязвимостью CVSS 9.8. Было неловко. Очень.
С тех пор я просто втыкаю trivy или dependency-check на этапе билда. Пусть лучше один раз упадёт пайплайн, чем потом краснеть перед клиентом. Кстати, если используешь GitHub – там вообще халява, можно настроить Dependabot Alerts и вообще ничего не делать. Всё за тебя проверяют.
Чисто по-человечески: не душни
Вот тут момент: не стоит заваливать команду сотней «low severity» предупреждений, если никто не собирается их чинить. Ну правда. Лучше сконцентрироваться на двух-трёх правилах, которые реально спасают от беды. Например, отключение eval в JavaScript или запрет на root-пользователя в Dockerfile.
А то будет как у нас в одном проекте: линтер ругался на длину строки, а никто не замечал, что у нас на каждом деплое база пересоздаётся. 😐
Пример из жизни, он же фейл
Был проект, где мы добавили gitleaks только после того, как случайно закоммитили AWS-токен в публичный репозиторий. Да, я знаю. Боль. Теперь gitleaks стоит в pre-commit, в CI, в голове. Всё равно иногда ругается на рандомный текст, но это мелочи.
Ещё пара мыслей, пока не забыл
- Логи от сканеров лучше публиковать как артефакты. Потом проще разбираться.
- Построй графики. Интеграция с SonarQube или хотя бы простой HTML-отчёт – это не понты, а повод гордиться чистым кодом.
- Делай брейкпоинты. Не всё нужно делать синхронно. Некоторые проверки можно отправить в background и просто оповестить в Slack или Mattermost.
Короче, встраивать всё это в пайплайн – не больно. Боль – это чинить последствия, когда всё пошло не туда. Лучше уж немного напрячься заранее. И, честно, тебе же самому потом легче будет спать.
Создание кастомных сценариев аудита с использованием open-source решений
Сразу по делу: начни с bash-скрипта
Да-да, не JSON, не YAML, не XML. Просто обычный старый добрый скрипт. Создаёшь `check.sh`, пихаешь туда то, что тебе реально надо проверить: порты, права, кривые симлинки, что угодно. Вот прям так и пишешь:
#!/bin/bash
echo "Проверяю наличие nginx..."
which nginx || echo "Где nginx, Лебовски?!"
Работает? Работает. А если не работает – значит, и не надо было.
Используй то, что не жалко сломать
Не бери за основу монстров типа OpenVAS или Wazuh – они классные, но их больно настраивать, особенно если у тебя руки уже дрожат от последнего crontab’а. Я чаще всего беру Prowler (если у тебя AWS) или Lychee (если ты параноик по битым ссылкам, как я). Установил, подправил пару флагов – поехали. Главное – не пытайся построить Луну из Docker’ов. Держи всё приземлённо.
Хочешь на выходе не мусор – пиши свои правила
Вот тут, кстати, начинается весёлое. Один раз меня клиент попросил «проверить все каталоги на наличие `.DS_Store`». Что? Серьёзно? Ну окей, вот тебе сценарий:
find / -name ".DS_Store" -print > ds_store_report.txt
Смешно? А он потом это в суд прикладывал как «артефакт неряшливости» подрядчика. Так что да, кастомные проверки – это не каприз. Это прям способ выживания в мире, где `chmod 777` – до сих пор чья-то норма.
Не повторяйся, автоматизируй своё раздолбайство
Я лично люблю `Ansible`. Да, можно и без него. Но если у тебя больше трёх серверов, и ты всё ещё руками заходишь по SSH, чувак, ты живёшь в боли. Запихай свой скрипт в плейбук, вот так:
- name: Проверка на .DS_Store
hosts: all
tasks:
- name: Run custom audit script
script: ./check_ds_store.sh
Один раз написал, потом запускаешь хоть ночью, хоть с телефона. Всё. Спишь спокойно (ну, почти).
Не верь отчётам – верь глазам
Любой инструмент – даже самый open-source’овый – может наврать. У меня был случай: отчёт чистый, а база MySQL с root’ом без пароля. Сюр. Поэтому: запускай, проверяй, читай логи. Не доверяй html-отчётам на 300 страниц. Лучше grep’ни по словам «FAILED», «broken», «wtf». Оно работает.
И не надо всё усложнять
Вот серьёзно, тебе не нужен суперплатформенный фреймворк. Нужно, чтобы работало. И чтобы ты понимал, что происходит. Пиши своё. Скрипты – как хлеб: лучшие – те, что сделал сам, пусть и кривые. Зато тёплые.
Пример «на коленке», но работает:
- Блокнот
- Bash + cron
- Список того, что должно быть (и чего быть не должно)
- grep, awk, иногда sed (когда совсем плохо)
Короче. Придумай себе 10 проверок. Напиши. Запусти. Забудь. Проснись. Удали половину. Добавь ещё три. Это и есть твой кастомный скрипт. Не гламурно. Но честно. А честность в этой теме – вообще-то редкость.
