Архитектура проходного двора

В прошлом коротком посте я писал, как психанул и неделю жил в режиме «НЕТ». Эффект был неожиданный: прод не упал, а я впервые выжил. Но эксперимент — это одно. А продакшен-решение — другое.

Я сел анализировать, почему вообще этот эксперимент понадобился. И понял: я годами жил с архитектурой Default Allow.

В InfoSec это считается дичью. Представьте админа, который открыл все порты, отключил фаервол и пускает любой пакет, если у того в хедере написано «Ну пожалуйста». Этот сервер ляжет за 5 минут. Но именно так мы строим коммуникацию.

  • Коллега просит «глянуть» (контекстное переключение)? — ACCEPT.

  • Заказчик пишет в личку в 22:00? — ACCEPT.

  • Родственники просят починить утюг в выходной? — ACCEPT.

Мы боимся отказать, потому что у нас нет протокола отказа. Мы считаем, что «Да» — это норма, а «Нет» — это конфликт. В итоге: мой Uptime падает, Latency растет, а я обслуживаю чужой трафик.

Я решил переписать свой iptables и внедрить политику Default Deny на уровне личности. Вот моя документация.

ШАГ 1: Анализ трафика (Access Logs)

Прежде чем блокировать, надо понять, кто нас DDoS-ит. Я поднял логи (историю чатов и календаря) за месяц. Весь мусорный трафик делится на 3 класса:

  1. «Паразитная нагрузка»: Запросы, которые можно делегировать или вообще не делать. («Пришли отчет, который никто не читает»).

  2. «Асинхронный ад»: Люди, которые не умеют в текст и шлют войсы, или звонят без предупреждения. Это блокирует мой I/O поток.

  3. «Эмоциональный пинг»: Коллеги, которые приходят не за решением, а чтобы слить тревогу. («Ой, всё пропало, мы не успеем»). Они жрут CPU, не принося полезной нагрузки.

ШАГ 2: Конфигурация (Ruleset)

Я написал для себя жесткий конфиг. Это не «личные границы» (психологический термин, который никто не понимает). Это SLA (Service Level Agreement).

Я опубликовал его для команды. Выглядит примерно так (псевдокод):

YAML

# HUMAN_FIREWALL_CONFIG.yaml

policy: DEFAULT_DENY

rules:
  - id: jira_ticket_required
    match: "Task request without link"
    action: DROP
    response: "400 Bad Request. Нет тикета — нет задачи. Заведи, пожалуйста."

  - id: no_voice_messages
    match: "Audio content"
    action: REJECT
    response: "415 Unsupported Media Type. Я не слушаю войсы. Пиши текстом."

  - id: deep_work_window
    time: "10:00 - 14:00"
    action: DO_NOT_DISTURB
    exception: "Critical Production Incident"

ШАГ 3: Реализация ответов (HTTP Response Codes)

Самое сложное — внедрить это в живое общение. Сказать «Нет» страшно. Но я нашел хак. Я перестал оправдываться («извини, не могу, у меня кошка рожает») и начал выдавать стандартизированные коды ошибок.

Когда ты отвечаешь как система — четко, нейтрально и предсказуемо — люди не обижаются. Они адаптируются.

Сценарий 1: «Срочно глянь!»

Вместо того чтобы бросать всё и смотреть, я выдаю 503 Service Unavailable.

«Сейчас я занят архитектурой. Вернусь к входящим в 16:00. Если это блокирует релиз — пиши техлиду».

Сценарий 2: Нытье в курилке

Вместо того чтобы включаться и успокаивать, я выдаю 204 No Content. Я просто молчу и киваю. Я не выделяю ресурсы на обработку этого скрипта. Человек видит, что сервер не отвечает, и уходит к другому.

Сценарий 3: Манипуляция («Ты же профессионал, сделай овертайм»)

Это попытка SQL-инъекции в моё чувство вины. Ответ: 403 Forbidden.

«Я не работаю по выходным. Это правило. Можем обсудить в понедельник в 10:00».

Результаты патча

Прошло почти две недели.

  1. Нагрузка на CPU упала на 40%. Я перестал греть воздух.

  2. Окружение обучилось. Нейросетка коллег поняла: «Сюда с мусором нельзя, тут стоит WAF (Web Application Firewall)». Трафик стал чище.

  3. Уважение. Надежный сервер, который работает по правилам, ценят больше, чем глючный, который пытается угодить всем и падает.

Вывод

Ваша безотказность — это уязвимость. Если у вас нет документации к вашему API, пользователи (коллеги, родные) будут тыкаться в вас рандомными запросами, пока не сломают.

Напишите свой конфиг. Опубликуйте его. И держите порт 80 закрытым для всех, кто не прошел авторизацию.

P.S. Если тема инженерного подхода к себе («Личный DevOps») заходит — я собрал свои наработки в PDF-гайд «System Diagnostics». Там есть чек-лист по поиску утечек памяти и базовые настройки «Фаервола». Без маркетинга, чисто мануал. Лежит в моем ТГ-канале (ссылка в профиле).