🟢 Статус: Conceptually stable · v0.1
Концепция устойчива, проверена опытом, литературой и практикой.
15. Anti-patterns — что НЕ делать¶
Сводный реестр граблей, на которых ломается большинство инсталляций Zabbix. Если читать только одну главу из книги — лучше эту: она убережёт от 80% ошибок.
Структурирована по разделам, ссылается на конкретные главы для подробностей.
Анти-паттерны архитектуры¶
❌ "Поставить Zabbix и забыть"¶
Zabbix — это не инструмент, а конвейер. Если у вас нет runbook'ов, корреляции, постмортемов — у вас не мониторинг, а декорация. См. главу 6.
❌ Нет прокси там, где нужна изоляция или буферизация¶
Для небольшой однородной среды без удалённых площадок и OT-сегментов один Zabbix Server без proxy может быть вполне нормальным решением. Антипаттерн — отсутствие прокси там, где есть: удалённые площадки с ненадёжным каналом, DMZ/OT-сегменты, требования к изоляции сетей, или нужна буферизация при потере связи. Прокси нужны не для масштаба, а для изоляции и устойчивости. См. главу 6.
❌ Ставить Zabbix Agent внутрь SCADA / OT-сегмента¶
Заманчиво: «поставим агенты на АРМ оператора и контроллер, будем видеть всё». Так делать в лоб нельзя — и причин три:
Архитектурно. Модель Purdue (и более современный IEC 62443) требует, чтобы трафик между IT и OT шёл через брокеринг в Industrial DMZ — jump-сервер, репликация Historians, шлюзы. Прямой коннект из IT-Zabbix в Level 2 к HMI — это и есть то самое неконтролируемое прохождение между уровнями, от которого модель защищает.
Нормативно. Open-source Zabbix сам по себе не обеспечивает соответствие требованиям. Применение в контуре ЗОКИИ требует архитектурного проектирования, согласований с ИБ/регулятором, применения СЗИ и сертифицированных средств там, где это требуется по оценке рисков и требованиям регулятора. Существуют сертифицированные сборки на базе Zabbix (например, UDV ITM), которые могут закрывать отдельные требования — уточняйте у владельца ЗОКИИ и ИБ.
Операционно. В отрасли давно есть специализированные пассивные системы: PT ISIM, Kaspersky Industrial CyberSecurity for Networks, UDV DATAPK. Они слушают копию трафика через SPAN-порт или однонаправленный диод данных и видят АСУ-специфику (Modbus, OPC, S7) на уровне DPI. Zabbix этого не умеет.
Где Zabbix в OT уместен — верхние уровни (Historians, серверы SCADA на Windows, инженерные станции), при нескольких условиях: отдельный Zabbix Proxy в DMZ, белый список метрик, согласование с ИБ. Контроллеры и АРМ нижних уровней — только согласованные read-only проверки (ICMP, SNMP read-only, TCP-check до OPC-сервера) после оценки риска с командой АСУ ТП и ИБ. Даже ICMP является активным зондированием — уточняйте допустимость с командой АСУ ТП.
❌ Дашборд для CIO на основе доступности хостов¶
CIO смотрит на бизнес-сервисы. Если у вас «доступность инфраструктуры 99.8%» — он не знает, работает 1С или нет. См. главу 1.
Анти-паттерны группировки и тегов¶
❌ Засовывать бизнес-смысл в host groups¶
Group: 1C-prod-warehouse-critical — это не group, это конкатенация тегов в имя. Используйте теги, а группы — для RBAC. См. главу 3.
❌ Тег criticality=critical на половине хостов¶
Если 50% хостов «критичные» — это значит «никакие». Calibration: P1 — это уровень бизнес-сервиса; P2 — деградация без полной остановки; P3 — техническое внимание.
❌ "Назовём теги, как захочется"¶
Без зафиксированной tag schema (с разрешёнными значениями каждого тега) через полгода у вас будет service=1c, service=1C, service=1с, service=erp. И фильтры/дашборды не работают.
❌ Не использовать LLD¶
Заводить диски, интерфейсы, БД руками = неуправляемый беспорядок через год. См. главу 4.
❌ Использовать LLD без фильтров¶
Discovery всех services Windows / всех интерфейсов / всех БД без фильтров = десятки тысяч мусорных items. LLD всегда идёт с фильтрами и lifecycle-политикой.
Анти-паттерны severity¶
❌ Disaster на всё «плохо延
rphost=0 — не Disaster, если у вас десять rphost'ов. Disaster = бизнес-сервис лежит. См. главу 2.
❌ Новые Disaster/High без runbook¶
Disaster без ссылки на runbook = дежурный ищет в Google в 3 ночи. Для новых триггеров: Disaster/High не принимается без runbook или хотя бы escalation stub (к кому звонить, ссылка на документацию). Для legacy: мигрировать партиями — Disaster получают хотя бы stub немедленно, High закрываются итеративно по мере инцидентов.
❌ Чистить severity inflation в первый месяц¶
Перенастроите → переделаете шаблоны → опять переделаете. Сначала стандартизация (фаза 2), потом чистка.
❌ "Зелёный backup job = бэкап работает"¶
Veeam job может быть зелёным с retention policy, которая выбросила нужные точки. Мерять надо возраст последнего успешного восстановимого бэкапа, не статус job.
Анти-паттерны Discovery / онбординга¶
❌ Поднимать Netbox / iTop "пока есть время"¶
Это полугодовой проект сам по себе. Для Discovery достаточно Excel + Confluence/Bookstack. CMDB — это потом.
❌ Запускать nmap по всей инфраструктуре без ИБ¶
На предприятии с КИИ это путь до неприятного разговора с СБ. Сканирование сегментов только после согласования и в рамках выделенных слотов.
❌ Чистить шаблоны / удалять старое в Discovery¶
Read-only месяц значит read-only. Любая правка в фазе 1 = откат планов фазы 2.
❌ "Я знаю как надо" — без интервью с командой¶
Технически правильный мониторинг, который не учитывает реальные процессы команды, умирает через 2 месяца. Интервью обязательны.
Анти-паттерны эксплуатации¶
❌ Не мониторить сам мониторинг¶
Упал Zabbix Server → вы слепые → вы об этом не знаете. Self-monitoring + независимый watchdog обязательны. См. главу 12.
❌ Принимать алерты без maintenance windows¶
Каждый патч-день = шквал ложных P1. Сделайте Maintenance Windows процессом, привязанным к Change Request.
❌ "Постмортем — это документ ни для кого"¶
Без обратной связи в шаблоны / runbook'и постмортем — потеря времени. Каждый Major Incident → как минимум одно изменение в системе мониторинга.
❌ Подписывать SLA без 3 месяцев данных¶
«Доступность 99.9%» из потолка = провал через квартал. Сначала измеряем, потом обязуемся. См. главу 10.
❌ SLA с бизнесом без поддержки OLA/UC¶
UC (Underpinning Contract) — с внешним поставщиком. OLA (Operational Level Agreement) — внутри ИТ-команд. Оба должны быть не слабее SLA, на который вы подписались с бизнесом — иначе SLA невозможно выполнить. Если провайдер даёт 99.5%, нельзя обещать бизнесу 99.9% без резервирования. Согласуйте OLA и UC до подписания SLA.
Анти-паттерны интеграций¶
❌ Нет стратегии retention с первого дня¶
Retention и DB-стратегия обязательны с первого дня — даже если это просто настроенный housekeeping. При 4К+ хостах и 1-минутных интервалах таблицы history* разрастаются до сотен ГБ. Для высокого NVPS (≥1000 NVPS) TimescaleDB или нативное партиционирование — правильный путь; выбирается по NVPS, объёму хранения и компетенции команды. Без какой-либо стратегии retention перформанс деградирует неизбежно.
❌ Grafana — алертинг¶
Grafana — для визуализации. Алертинг — в Zabbix. Если делать алерты ещё и в Grafana — у вас две системы правды, которые расходятся.
❌ Тяжёлые UserParameter "напрямую"¶
UserParameter подчиняется timeout агента. Длинные rac session list, PowerShell-парсеры логов, тяжёлые SQL-запросы напрямую = ZBX_NOTSUPPORTED и флап.
Правильно: cron-скрипт раз в 1–2 минуты собирает JSON → Zabbix читает dependent items. Или zabbix_sender/trapper для асинхронной подачи.
Анти-паттерны коммуникации¶
❌ "Алерт в Telegram-чат на 50 человек"¶
Все привыкли игнорировать. Каналы должны быть узкоцелевыми: дежурная смена, профильная команда, эскалация CIO — отдельно.
❌ Отсутствие Major Incident Communication Plan¶
В момент падения 1С в 08:30 уже поздно думать, кто звонит директору и кто пишет «1С временно недоступна» 300 пользователям. Это процесс, который пишется в нормальное время.
❌ Постмортем без участия бизнеса¶
Если на постмортеме нет владельца бизнес-сервиса — вы починили технику, но не процесс, а инцидент повторится.
Анти-паттерны "хочу как у Гугла"¶
❌ "У них SRE — давайте и нам"¶
SRE-практики придуманы для веб-сервисов с автоскейлом и blue-green-деплоем. На заводе с 1С и SCADA половина практик не работает. Берите отдельные паттерны (runbook'и, постмортемы, error budgets) — не модель целиком.
❌ Prometheus вместо Zabbix потому что "Prometheus модный"¶
Prometheus прекрасен для cloud-native стека. Для legacy Windows-инфраструктуры с 1С, Exchange, SCADA и SNMP-периметра Zabbix объективно сильнее. Зрелость инструмента ≠ модность.
❌ "Микросервисный мониторинг" на монолите¶
Если у вас в проде монолит и три старые VM — distributed tracing не нужен. Хорошо настроенный stack Zabbix + Grafana + ELK часто закрывает основной контур задач.
Анти-паттерны git / docs-as-code¶
❌ Класть Zabbix-экспорт в git "как файлы"¶
Конфликты при merge будут болезненными. См. главу 8 — GitOps — там описан реалистичный спектр подходов.
❌ Документация в Word / OneDrive / Confluence без структуры¶
Дежурный в 3 ночи не найдёт инструкцию. Структура Book → Chapter → Page или runbook URL прямо в триггере обязательна.
Резюме¶
Если коротко:
- Думайте сервисами, не хостами
- Severity = действие, не цвет
- Tag schema — фундамент
- Каждый Disaster имеет runbook
- SLA после 3 месяцев данных, не до
- Постмортем меняет шаблоны, иначе зачем
- SCADA — агент в L0–L2 не ставить; верхние уровни — по согласованию с ИБ
- Чистка severity inflation — после стандартизации, не до
Эти восемь правил закрывают 80% типовых граблей. Остальные 20% — нюансы конкретного контекста.