🟡 Статус: Design draft · v0.6

Это операционное руководство по внедрению: структура проекта, роли, фазы, phase gates и минимальные артефакты. Оно не заменяет детальный проект внедрения, sizing и security review под конкретную среду.

16. Руководство по внедрению: от дизайна к эксплуатации¶

Эта глава отвечает на вопрос, который не закрывается одними шаблонами, тегами и дашбордами:

Как провести внедрение мониторинга как управляемый проект, а не как серию героических правок в Zabbix UI?

В предыдущих главах описано, как должен выглядеть зрелый дизайн:

глава 3 — теги, группы и метаданные;
глава 5 — layered design: шаблоны, теги и смысл событий;
глава 6 — физическая архитектура развёртывания;
глава 9 — runbook;
глава 10 — SLA и сервисный каталог;
глава 11 — дашборды и отчётность;
глава 12 — эксплуатационные процедуры.

Эта глава связывает их в порядок внедрения: кто участвует, какие решения принимаются, какие артефакты должны появиться, где останавливаться и что проверять перед переходом дальше.

Главный принцип руководства¶

Мониторинг нельзя внедрить только силами инженера, который умеет Zabbix.

Зрелый мониторинг — это пересечение четырёх областей:

Техническая платформа
  Zabbix Server, DB, proxies, agents, templates, integrations

Эксплуатационная модель
  on-call, escalation, maintenance, alert review, runbooks

Сервисная модель
  service catalog, owners, criticality, SLA/SLO, business impact

Организационная модель
  роли, права, decision log, change process, handover

Если одна из областей отсутствует, проект обычно деградирует:

Что отсутствует	Что происходит
Нет платформенного дизайна	Zabbix тормозит, БД растёт, proxy ставятся хаотично
Нет эксплуатационной модели	Алерты летят в общий чат, их игнорируют
Нет сервисной модели	Есть CPU/диски, но нет ответа «работает ли 1С?»
Нет организационной модели	Непонятно, кто владелец шаблонов, тегов, runbook и дашбордов

Поэтому внедрение должно идти не как «настроим триггеры», а как программа перехода от технического мониторинга к управляемой эксплуатации.

90-дневная дорожная карта — это не универсальная оценка¶

В книге есть 90-дневная дорожная карта внедрения. Её нельзя читать как обещание, что любой Zabbix-проект делается за 90 дней.

Правильная трактовка:

90 дней — это референсный сценарий для среды среднего размера, где Zabbix уже существует, заинтересованные стороны доступны, область работ ограничена, а команда может принимать решения еженедельно.

Реальные сроки зависят от масштаба среды, зрелости текущего мониторинга, числа площадок, регуляторных ограничений, наличия ITSM/CMDB, готовности владельцев сервисов и объёма alert noise.

Ориентировочные классы среды¶

Класс среды	Примерный масштаб	Типичный срок до управляемого MVP	Комментарий
Lab / small	20–150 hosts, 1–2 площадки	4–6 недель	Можно быстро пройти discovery и pilot, но всё равно нужны tag schema и severity model
Medium	200–800 hosts, 2–5 площадок	8–14 недель	Именно под этот класс подходит 90-дневная дорожная карта внедрения
Large	1000–5000 hosts, много команд	4–9 месяцев	Нужны прокси, governance, staged rollout, несколько пилотов
Enterprise / regulated / OT	5000+ hosts, КИИ/OT/multi-site	6–12+ месяцев	Основное время уходит не на Zabbix, а на согласования, безопасность, владельцев и процессы

Что сильнее всего растягивает сроки¶

Нет владельцев сервисов.
Нет актуального inventory.
Нет единого источника правды по площадкам и критичности.
В Zabbix тысячи старых триггеров без owner и runbook.
Сетевая команда, ИБ или АСУ ТП не согласовали границы мониторинга.
Команда спорит о tag schema больше двух недель.
Нет решения: UI-first, export-to-git, Ansible или другой способ управления конфигурацией.
ITSM отсутствует или не готов принимать автоматические инциденты.
Руководство хочет SLA до появления данных хотя бы за 1–3 месяца.

Вывод: сроки надо планировать не только по количеству хостов, а по скорости принятия решений.

Где заканчивается design guide и начинается руководство по внедрению¶

Design guide отвечает:

Как правильно построить модель мониторинга?

Руководство по внедрению отвечает:

Как провести людей, решения и артефакты через внедрение?

Пример разницы:

Тема	Design guide	Руководство по внедрению
Tag schema	Какие теги нужны и где они живут	Кто утверждает значения, как применять, когда gate пройден
Severity	Что значит Disaster/High/Average	Кто имеет право менять severity, как проверять noise ratio
Runbook	Как писать runbook	Какие инструкции runbook должны быть готовы до pilot/rollout
Dashboards	Какие витрины нужны	Кто аудитория, кто owner, как принимать dashboard
SLA	Как описать сервис и SLO	Когда можно обсуждать SLA, кто business owner
Templates	Как проектировать composition	Кто меняет шаблоны, где review, как валидировать

Структура команды внедрения¶

Внедрение мониторинга ломается, если его воспринимают как задачу одного инженера. Нужна минимальная команда и понятные роли.

Участники¶

Роль	Кто обычно	Ответственность
Спонсор проекта	CIO / ИТ-директор	Политическая поддержка, приоритизация, снятие блокеров
Владелец мониторинга	Руководитель эксплуатации / SRE lead / тимлид инфраструктуры	Владелец мониторинга как продукта после внедрения
Архитектор мониторинга	Ведущий инженер / архитектор	Архитектура, tag schema, severity model, template composition, design decisions
Администратор Zabbix	Инженер мониторинга	Реализация в Zabbix: хосты, шаблоны, actions, media, proxies
Владелец платформы и БД	Linux/PostgreSQL/VMware команда	Сервер, БД, backup, HA, capacity, OS hardening
Владелец сетевой инфраструктуры	Сетевая команда	SNMP, routing, firewall rules, proxy placement, network discovery
Владельцы прикладных систем	1С, Exchange, MSSQL, Veeam, ERP/CRM команды	Прикладные метрики, критичность, диагностика, инструкции runbook
Руководитель NOC / дежурной смены	Дежурная служба / L1 lead	Проверка процесса реакции, escalation, acknowledgement, передача в эксплуатацию
Ответственный за ИБ	ИБ	Доступы, секреты, TLS/PSK, audit, внешние integrations
Ответственный за OT / АСУ ТП	АСУ ТП / промышленная автоматизация	Границы OT, допустимые проверки, запрет активного вмешательства
Владелец Service Desk	ITSM команда	Incident/change workflow, maintenance windows, ticket mapping
Владелец бизнес-сервиса	Владелец бизнес-сервиса	Бизнес-критичность, service hours, acceptance, SLA/SLO

Минимальный состав, если людей мало¶

В небольшой организации роли могут совмещаться:

Минимальная роль	Может совмещать
Спонсор проекта	CIO / ИТ-директор + владелец ключевого бизнес-сервиса
Владелец мониторинга	Архитектор мониторинга + администратор Zabbix
Владелец платформы	Эксплуатация Linux / виртуализации / БД
Контакт со стороны сети и ИБ	Представитель сетевой команды + представитель ИБ
Представители прикладных систем	По одному ответственному от 1С, БД, почты и других ключевых систем
Представитель службы поддержки	Человек, который реально получает алерты и реагирует на них

Но даже если один человек совмещает три роли, роли всё равно надо назвать. Иначе неясно, кто принимает решения.

Что делать, если роли нет¶

Это обычная ситуация. В зрелом руководстве должны быть не только идеальные роли, но и модель fallback.

Нет роли	Что делать временно	Что нельзя делать
Нет business service owner	Назначить временного service owner от ИТ	Утверждать SLA от имени бизнеса
Нет NOC / дежурной смены	Маршрутизировать High+ на профильные команды	Делать общий Telegram-чат на всех
Нет CMDB	Вести service catalog и inventory в YAML/Excel	Делать вид, что Zabbix сам является CMDB
Нет ITSM	Фиксировать incidents/changes во внутреннем Jira/YouTrack или таблице в утверждённом контуре	GitHub Issues может быть неприемлем в regulated/enterprise; не терять историю реакций и maintenance
Нет Security owner	Использовать read-only доступы, не трогать OT/SCADA	Открывать firewall rules и ставить агенты без согласования
Нет Zabbix administrator	Назначить технического владельца до старта	Разрешить всем менять шаблоны в UI
Нет владельца tag schema	Назначить Monitoring owner как временного владельца	Позволять каждому придумывать свои значения тегов

Правило:

Если для решения нет owner — решение не принято, а риск должен быть записан в risk register.

Взаимодействие с отделами¶

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

Инфраструктура / серверная команда¶

Согласовать:

где живёт Zabbix Server;
где живёт БД;
кто делает backup Zabbix DB;
нужен ли HA;
кто отвечает за OS patching;
какие storage/IOPS доступны;
есть ли отдельные среды test/stage/prod;
как мониторить сам Zabbix.

Связанные главы:

Сетевая команда¶

Согласовать:

SNMP policy: v2c или v3;
read-only communities / credentials;
какие интерфейсы являются uplink/core/access;
какие интерфейсы нельзя алармить;
LLDP/CDP доступность;
firewall rules для agent/proxy/server;
proxy placement по площадкам;
network maintenance windows.

Критичный вопрос:

Interface down на access-порту — это алерт или просто событие?

Если это не решить, сеть станет главным источником alert noise.

DBA / владельцы БД¶

Согласовать:

какие инстансы production;
какие БД критичны для сервисов;
какие метрики БД допустимы;
какие SQL-checks можно выполнять и с какой частотой;
какие thresholds опасны/шумны;
кто пишет runbook для blocking/deadlock/backup age;
какие окна обслуживания БД есть.

Нельзя просто взять SQL из интернета и поставить polling раз в 30 секунд на production MSSQL.

1С / application owners¶

Согласовать:

какие базы production;
какие регламентные операции критичны;
что для бизнеса считается деградацией;
какие фоновые задания важны;
где доступен rac;
от какого пользователя можно выполнять диагностику;
где логи 1С;
какие периоды frozen: закрытие месяца, зарплата, отчётность.

Правильная формулировка вопроса:

Не «какие процессы 1С мониторить?», а «по каким признакам вы понимаете, что пользователи скоро начнут звонить?»

ИБ¶

Согласовать:

кто имеет доступ к Zabbix frontend;
какие user groups и permissions допустимы;
какие credentials хранятся в Zabbix;
нужны ли vault/secret handling policies;
TLS/PSK для agents/proxies;
audit логирование изменений;
ограничения на external webhooks;
допустимость Telegram/Email/SMS каналов.

OT / SCADA / АСУ ТП¶

Согласовать до любых технических действий:

где граница IT/OT;
можно ли ICMP;
можно ли TCP port checks;
можно ли ставить proxy в OT-DMZ;
можно ли passive discovery/SPAN (SPAN даёт доступ к чувствительному трафику — нужны: owner данных, режим хранения, права доступа, DPI-система, срок хранения и согласование с ИБ);
какие проверки категорически запрещены;
кто утверждает исключения;
как оформляется change.

Правило:

Если OT owner и ИБ не согласовали мониторинг — OT не трогаем. Только документируем blind spot и риск.

ServiceDesk / ITSM¶

Согласовать:

какие Zabbix problems создают incidents;
какие остаются только notifications;
как маппить severity Zabbix → priority ITSM;
кто закрывает ticket;
как работает auto-resolve (recovery event может закрывать/переводить тикет только при явно согласованной политике: не все случаи auto-close безопасны);
как создаются maintenance windows из change requests;
что делать с flapping events;
какие поля обязательны: service, owner, location, component, impact.

Бизнес-владельцы сервисов¶

Согласовать:

что сервис делает для бизнеса;
кто пользователи;
service hours;
критичность;
acceptable downtime;
frozen periods;
что является деградацией;
какие отчёты нужны;
кому показывать executive dashboard.

С бизнесом нельзя обсуждать CPU > 90%. С бизнесом обсуждают: «можно ли проводить документы», «уходит ли почта», «доступны ли файлы», «прошёл ли backup критичных данных».

Фазы внедрения¶

Ниже — практический lifecycle. Он совместим с 90-дневным roadmap, но не привязан жёстко к календарю.

Phase 0 — Мобилизация
Phase 1 — Инвентаризация
Phase 2 — Дизайн и стандартизация
Phase 3 — Пилот
Phase 4 — Развертывание
Phase 5 — Передача в эксплуатацию

Фаза 0 — Мобилизация¶

Цель: запустить проект так, чтобы он не утонул в неопределённости.

На выходе:

sponsor назначен;
monitoring owner назначен;
scope определён;
ключевые заинтересованные стороны известны;
доступы read-only согласованы;
способ ведения decisions и backlog выбран;
риск «нет владельцев» зафиксирован.

Типовые действия:

Провести kickoff.
Зафиксировать цели: visibility, alert hygiene, service dashboards, SLA readiness, передача в эксплуатацию.
Зафиксировать out of scope: production-ready custom templates, full CMDB, full ITSM automation, OT deep monitoring — если это не входит.
Создать project folder/repo/wiki-space.
Завести decision log.
Завести risk register.
Согласовать календарь workshops.

Decision points:

Кто владелец мониторинга после проекта?
Кто имеет право утверждать tag schema?
Кто принимает severity model?
Какие сервисы входят в MVP?
Что считается успехом первой версии?

Фаза 1 — Инвентаризация¶

Цель: понять реальное состояние, не меняя production.

Принцип:

Read-only first. Не чинить, не удалять, не «быстро поправить триггер». Сначала измерить хаос.

На выходе:

выгрузка инвентаря;
матрица покрытия;
список текущих шаблонов;
список текущих actions и media types;
отчёт по шумным триггерам;
отчёт по игнорируемым проблемам;
карта стейкхолдеров;
черновик сервисного каталога;
реестр рисков;
первый отчёт для CIO (one-pager).

Что собрать из Zabbix:

версии компонентов: Zabbix Server, proxy, agents, DB (PostgreSQL/MySQL), OS, frontend/PHP, plugins/integrations — с проверкой end-of-support;
hosts, groups, templates, tags;
active problems;
problem age;
events за 30/90 дней;
top noisy triggers;
disabled hosts/items/triggers;
actions and media types;
users/user groups;
proxies;
web scenarios;
current maintenance windows.

Что собрать вне Zabbix:

vCenter/Hyper-V inventory;
AD computers;
DHCP leases;
DNS zones;
Veeam protected workloads;
network devices;
списки бизнес-сервисов;
pain log от команд.

Discovery не должен пытаться доказать, что Zabbix плохой. Он должен показать:

Что видно
Что не видно
Что видно неправильно
Что шумит
Что никто не обслуживает
Какие решения надо принять

Фаза 2 — Дизайн и стандартизация¶

Цель: утвердить модель, по которой дальше будет жить мониторинг.

Это самая важная фаза. Если её пропустить, rollout просто размножит старый хаос.

На выходе:

утверждённая tag schema;
модель host groups;
severity model;
модель template composition;
соглашения об именовании;
политика maintenance windows;
политика покрытия инструкциями runbook;
аудитории дашбордов;
первоначальный сервисный каталог;
decision log с принятыми ADR.

Ключевые решения:

Какие mandatory tags используются?
Где живёт service: host, service catalog, trigger exceptions?
Что такое criticality=P1/P2/P3/P4?
Что значит Disaster?
Какие alerts уходят в active notification, а какие только в dashboard?
Как проектируются templates: base/role/application/synthetic?
Кто имеет право менять templates?
Как сохраняется история изменений: UI, export-to-git, Ansible, hybrid?
Какие dashboards нужны в MVP?
Какие services входят в MVP SLA-readiness?

Связанные главы:

Фаза 3 — Пилот¶

Цель: проверить модель на ограниченном scope, до массового rollout.

Пилот должен быть достаточно маленьким, чтобы его можно было контролировать, и достаточно реальным, чтобы вскрыть проблемы.

Типичный pilot scope:

20–50 hosts;
2–4 business services;
2–3 команды эксплуатации;
1–2 интеграции notifications;
5–10 инструкций runbook;
один NOC dashboard;
один per-service dashboard.

Хороший пилот включает разные типы объектов:

Windows host;
Linux host;
network device;
database;
application host;
backup check;
synthetic check.

На выходе:

теги применены;
шаблоны подключены;
маршрутизация алертов проверена;
инструкции runbook привязаны;
дашборды проверены;
уровень шума измерен до/после;
результаты пилота задокументированы;
корректировки зафиксированы.

Pilot не считается завершённым, если:

alerts уходят неизвестно кому;
NOC не понимает, что делать;
High/Disaster без runbook;
service dashboard показывает CPU, но не показывает состояние сервиса;
tag schema пришлось менять вручную для каждого dashboard.

Фаза 4 — Развертывание¶

Цель: масштабировать утверждённую модель на согласованный scope.

Rollout делается волнами:

Волна 1 — критичные сервисы / P1
Волна 2 — инфраструктурный каркас
Волна 3 — прикладные сервисы
Волна 4 — остальные production-хосты
Волна 5 — test/dev/dr при необходимости

Для каждой волны:

Подготовить список hosts/services.
Проверить owner и criticality.
Применить tags.
Привязать templates.
Проверить problems.
Настроить routing.
Проверить dashboards.
Обновить service catalog.
Зафиксировать exceptions.

Rollout не должен быть Big Bang. Чем больше среда, тем меньше должна быть первая волна.

Phase 5 — Передача в эксплуатацию¶

Цель: передать систему в штатную эксплуатацию.

Передача в эксплуатацию — это не презентация. Это доказательство, что команда может работать без автора внедрения.

На выходе:

owners назначены;
регулярный alert review запущен;
change process для templates описан;
onboarding нового хоста описан;
runbook coverage измеряется;
dashboards имеют owners;
SLA reports имеют owners;
процесс postmortem описан;
backlog после проекта передан.

Команда должна уметь:

добавить новый host;
назначить tags;
выбрать templates;
создать maintenance window;
разобрать problem event;
открыть runbook;
изменить trigger через process;
найти owner сервиса;
понять, почему alert не ушёл;
обновить dashboard;
провести еженедельный разбор алертов.

Точки принятия решений¶

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

Минимальный формат — ADR: Architecture Decision Record.

Архитектурные решения¶

ID	Решение	Когда принять
ADR-001	Zabbix deployment model: standalone / HA / managed DB	Phase 0–1
ADR-002	PostgreSQL model: standalone / HA / existing DB platform	Phase 0–1
ADR-003	Proxy topology: где нужны proxies	Phase 1–2
ADR-004	Agent mode: active / passive / mixed	Phase 2
ADR-005	Encryption: PSK/TLS policy	Phase 2
ADR-006	OT/SCADA monitoring boundary	До любых OT-checks
ADR-007	Grafana: now / later / not needed	Phase 2
ADR-008	ITSM integration scope	Phase 2–3

Проектные решения¶

ID	Решение	Связанная глава
ADR-010	Mandatory tag schema	03
ADR-011	Host group hierarchy	03
ADR-012	Severity model	02
ADR-013	Naming conventions	05
ADR-014	Template composition model	05
ADR-015	LLD policy	04
ADR-016	Maintenance windows policy	12
ADR-017	Runbook coverage policy	09
ADR-018	Dashboard audiences	11
ADR-019	SLA/SLO model	10

Операционные решения¶

ID	Решение
ADR-020	Кто владелец мониторинга после проекта
ADR-021	Кто имеет право менять templates
ADR-022	Можно ли менять Zabbix через UI (включая emergency/break-glass path: кто имеет право на экстренное изменение UI, как это фиксируется)
ADR-023	Как фиксировать drift
ADR-024	Кто отвечает за noisy alerts
ADR-025	Как проходит еженедельный разбор алертов
ADR-026	Как onboard'ится новый host
ADR-027	Как decommission'ится старый host
ADR-028	Как создаются maintenance windows
ADR-029	Какие alerts создают ITSM tickets

Sizing и capacity: где это место в руководстве¶

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

Sizing нельзя делать только после Развертывания. Правильный подход — в два этапа:

Sizing baseline (Phase 0–1): оценочные цифры по хостам, items, NVPS, retention — утвердить до Phase 3/pilot.
Уточнение sizing (после Пилотного развертывания): скорректировать по фактическому item rate, preprocessing нагрузке, web scenarios, LLD cardinality, queue и DB write latency.

Минимальные вопросы sizing baseline:

Минимальный вопросник для sizing¶

Сколько хостов сейчас?
Сколько хостов ожидается через 12–24 месяца?
Сколько items в среднем приходится на один хост?
Сколько NVPS сейчас и сколько ожидается после расширения?
Какой retention нужен для history?
Какой retention нужен для trends?
Сколько web scenarios и шагов в них планируется?
Сколько объектов создаётся через LLD?
Сколько proxies нужно по площадкам и сегментам?
Какая доля метрик проходит preprocessing?
Сколько пользователей, дашбордов и регулярных отчётов будет в системе?
Какие требования к HA Zabbix Server и БД?
Какие требования к backup/restore самого Zabbix?
Где ожидаемый bottleneck: CPU, БД, disk I/O, сеть, frontend/API, preprocessing?

Официальная документация Zabbix подчёркивает, что hardware examples — это стартовая точка, а каждая инсталляция уникальна и требует benchmark в staging/development перед production:

Zabbix requirements: https://www.zabbix.com/documentation/current/en/manual/installation/requirements
Zabbix server concepts: https://www.zabbix.com/documentation/current/en/manual/concepts/server
Zabbix proxy concepts: https://www.zabbix.com/documentation/current/en/manual/concepts/proxy

Sizing calculator в объём этой главы не входит. Здесь фиксируются только контрольные точки:

До начала пилота должен быть утверждён sizing baseline — исходная оценка масштаба и нагрузки: количество хостов, items, NVPS, retention, proxies, web scenarios, LLD-объектов и требований к HA/backup.

До промышленного развёртывания должен быть проведён хотя бы минимальный performance sanity check: проверка очередей Zabbix, нагрузки на БД, disk I/O, preprocessing, frontend/API и поведения системы под ожидаемой нагрузкой.

Подробные файлы для следующей итерации:

examples/project/sizing-questionnaire.md
examples/project/sizing-baseline.md
examples/decisions/adr-005-retention-and-sizing-baseline.md

Контрольные точки фаз¶

Контрольная точка фазы — это момент, когда команда проверяет: можно ли переходить к следующему этапу проекта.

Это не бюрократия ради бюрократии, а защита от типовой ошибки: «пошли дальше, хотя базовые решения ещё не приняты». В мониторинге такая ошибка дорого стоит: неутверждённая tag schema ломает дашборды, неописанная severity model создаёт шум, а пилот без sizing превращается в гадание.

Краткая модель:

Контрольная точка	Когда	Главный вопрос
Gate 0	До старта проекта	Есть владелец, границы проекта и необходимые доступы?
Gate 1	После discovery	Мы понимаем текущее состояние и основные разрывы?
Gate 2	После design	Утверждена модель целевого состояния?
Gate 3	После пилота	Модель работает на ограниченном контуре?
Gate 4	После rollout	Модель масштабирована, измерима и не развалилась при расширении?
Gate 5	После передачи в эксплуатацию	Команда может поддерживать систему без автора внедрения?

Полный чеклист вынесен в examples/project/phase-gates.md. В живом репозитории это рабочий артефакт для копирования и адаптации под конкретный проект.

Минимальный viable implementation¶

Не каждая организация готова сразу сделать ideal enterprise monitoring. Поэтому нужен минимальный viable implementation — такой объём, ниже которого проект лучше не называть внедрением зрелого мониторинга.

Минимум:

Есть владелец мониторинга.
Есть agreed tag schema.
Все production hosts в MVP/rollout scope имеют mandatory tags.
Severity model утверждена.
Disaster/High имеют понятную маршрутизацию.
Есть хотя бы NOC/current problems dashboard.
Для P1/P2 сервисов есть service catalog draft.
Для Disaster alerts есть инструкции runbook или documented escalation.
Есть maintenance process.
Есть еженедельный разбор алертов.
Есть backup самого Zabbix.
Есть понятный onboarding нового host.

Если нет хотя бы пунктов 1–5, это не mature monitoring project. Это настройка инструмента.

Типовые ошибки при внедрении¶

1. Начали с шаблонов, не договорившись о тегах¶

Итог: шаблоны технически работают, но dashboards, actions и reports строятся вручную и расходятся.

Лечение: остановить rollout, утвердить tag schema, провести retagging pilot.

2. Сделали dashboards без audience¶

Итог: красивые экраны, которыми никто не пользуется.

Лечение: каждый dashboard должен иметь audience, owner, refresh rate и действие.

3. SLA подписали до измерений¶

Итог: ИТ взяло обязательства, не понимая baseline.

Лечение: сначала SLO/internal targets, потом 1–3 месяца измерений, потом SLA.

4. Все alerts отправили в один канал¶

Итог: усталость от алертов за две недели.

Лечение: routing по service/owner/severity/notification tags.

5. OT начали мониторить как обычную сеть¶

Итог: конфликт с АСУ ТП/ИБ, потенциально опасные проверки.

Лечение: OT только после согласования границ и read-only/passive модели.

6. Нет владельца после внедрения¶

Итог: через 3 месяца всё возвращается в хаос.

Лечение: назначить Monitoring owner в Phase 0, не в конце проекта.

Чеклист приёмки¶

Критерии передачи мониторинга в эксплуатацию¶

Проект можно считать переданным в эксплуатацию, если выполнены следующие условия:

Если чеклист не закрыт, проект не завершён. Он просто дошёл до состояния «что-то работает».

Как проводить воркшопы по принятию решений¶

ADR не должны писаться одним архитектором в одиночку. Хороший decision workshop выглядит так:

До встречи архитектор готовит контекст, варианты и предварительную рекомендацию.
На встрече участники обсуждают не «что красивее», а последствия: сеть, безопасность, эксплуатация, стоимость, SLA, ownership.
После встречи owner фиксирует ADR в статусе Accepted или Proposed с открытыми вопросами.
На phase gate проверяется, какие ADR ещё не закрыты и блокируют ли они следующий этап.

Минимальный состав участников для разных типов решений:

Тип решения	Кто должен участвовать
Модель развёртывания	Архитектор мониторинга, владелец платформы, владелец БД, сетевая команда, ИБ
Режим работы агентов и шифрование	Архитектор мониторинга, сетевая команда, ИБ, владелец платформы
Схема тегов	Владелец мониторинга, NOC / дежурная смена, владельцы сервисов, Service Desk
Композиция шаблонов	Архитектор мониторинга, администратор Zabbix, владельцы прикладных систем и платформ
Retention и sizing	Владелец платформы / БД, владелец мониторинга, спонсор проекта при влиянии на бюджет
Дашборды	Руководитель NOC / дежурной смены, владельцы сервисов, представитель CIO, владелец Grafana
GitOps и управление изменениями	Владелец мониторинга, администратор Zabbix, руководитель эксплуатации, ИБ

Правило: если на встрече нет команды, которая потом будет жить с последствиями решения, решение преждевременно.

Связанные project artifacts¶

Для применения этой главы в реальном проекте см.:

examples/project/raci-matrix.md — роли и ответственность;
examples/project/phase-gates.md — gates и acceptance criteria;
examples/project/implementation-checklist.md — пошаговый чеклист внедрения;
examples/project/decision-log.md — журнал принятых и предлагаемых решений;
examples/decisions/README.md — процесс ADR и каталог типовых решений;
examples/decisions/adr-template.md — шаблон Architecture Decision Record;
examples/decisions/adr-001..007 — примеры решений по deployment model, agent mode, tag schema, template composition, retention/sizing, dashboards и GitOps.

Следующая итерация может добавить:

examples/project/sizing-questionnaire.md;
examples/project/risk-register.md;
examples/project/workshop-plan.md.

Резюме¶

Зрелый мониторинг внедряется не через «настроить Zabbix», а через управляемую последовательность:

Роли → Обследование → Решения → Проектирование → Пилот → Развёртывание → Передача в эксплуатацию → Регулярный пересмотр

Техническая реализация важна, но она вторична относительно трёх вещей:

кто владеет мониторингом;
какие решения приняты и зафиксированы;
может ли команда эксплуатировать систему без автора внедрения.

Если эти три вещи есть — Zabbix можно развивать. Если их нет — даже хороший Zabbix постепенно превратится в кладбище шаблонов, красных лампочек и забытых исключений.