[drive-download] Том 3+.docx

Google Docs neutral 2026-04-11 18 чанков ~26 мин чтения

Сущности

SSOT SLA SSI ИТ Том ok_rate BI Crisis Cell weighted_ok_rate СУБД

1.1. Назначение Тома 3 1.1.1. Цель и роль Тома 3 в системе документов. Настоящий документ (далее – Том 3) устанавливает требования к технической архитектуре, инфраструктуре данных и ИТ‑сервисам, обеспечивающим функционирование процессов штаба коммуникаций и расчёт метрик и индексов, определённых в Томах 1 и 2. Том 3 описывает, на каких системах, контурах и пайплайнах реализуются регламенты и методики, закреплённые в предыдущих томах.[1] 1.1.2. Задачи технической инфраструктуры штаба. Техническая инфраструктура штаба обеспечивает: сбор, хранение и обработку операционных и мониторинговых данных; расчёт операционных метрик и интегральных индексов (включая SSI и ok_rate); формирование витрин и дашбордов для лиц, принимающих решения; мониторинг здоровья данных и пайплайнов; поддержку режима работы штаба в нормальных и кризисных условиях.[2][1] 1.1.3. Ограничения и область применения. Том 3 описывает целевое состояние и ключевые требования к архитектуре, не являясь детальной низкоуровневой спецификацией для конкретных технологий и поставщиков; выбор конкретного стека, СУБД, BI‑платформ и т.п. осуществляется в рамках отдельных технических заданий при соблюдении настоящих принципов. Требования Тома 3 обязательны для ИТ‑блока, внешних подрядчиков и всех подразделений, влияющих на проектирование и эксплуатацию инфраструктуры данных штаба.[3] 1.2. Связь с Томом 1 и Томом 2 1.2.1. Обслуживание процессов управления (Том 1). Архитектура, описанная в Томе 3, обеспечивает техническую поддержку процессов, ролей и режимов работы штаба, определённых в Томе 1: ведение approval‑flow, фиксацию решений и инцидентов, работу режимов Normal / Attention / Stress / Crisis, функционирование Crisis Cell и резервных режимов. Все ключевые управленческие контуры (ежедневный и недельный циклы, эскалации, кризисные протоколы) опираются на данные и сервисы, описанные в Томе 3.[1] 1.2.2. Обслуживание метрик и индексов (Том 2). Техническая инфраструктура реализует методики расчёта метрик и индексов, описанных в Томе 2: обеспечивает наличие необходимых источников данных, их нормализацию, расчёт операционных показателей, индекса SSI, показателей ok_rate/weighted_ok_rate и других индикаторов качества и стресса. Пайплайны и витрины данных строятся таким образом, чтобы поддерживать периодичность, SLA и правила обработки, определённые в Томе 2.[1] 1.2.3. Соответствие принципам SSOT и прозрачности расчётов. Архитектура данных реализует принцип единого источника истины (Single Source of Truth): все расчёты индикаторов и индексов выполняются на основании согласованных витрин и реестров, а альтернативные «ручные» учёты не используются для официальной отчётности. Структура хранилища, пайплайнов и дашбордов обеспечивает возможность трассировки (data lineage) от любого агрегированного показателя до исходных записей и применённых трансформаций.[1] 1.3. Принципы технической архитектуры 1.3.1. Модульность и масштабируемость. Архитектура строится модульно: контуры сбора данных, хранилище, слой расчёта метрик и слой визуализации проектируются и развёртываются как логически и технически разделённые компоненты, что позволяет независимо масштабировать нагрузку, обновлять отдельные модули и заменять технологии без нарушения целостности системы.[4][2] 1.3.2. Отказоустойчивость и управляемая деградация. Системы и пайплайны проектируются с учётом отказоустойчивости: наличие резервирования, процедур восстановления, контроля задержек данных и сценариев управляемой деградации (prioritization, fallback) в условиях повышенной нагрузки или сбоев. В режиме Crisis обеспечивается приоритетность критичных задач и допустимое временное ограничение второстепенных функций, при сохранении минимально необходимого уровня информированности руководства.[1] 1.3.3. Безопасность и сегментация (security by segmentation). Архитектура предусматривает сегментацию по данным и ролям: разделение сред (dev/test/prod), разграничение доступа к сырым и агрегированным данным, изоляцию региональной информации и ограничение видимости межрегиональных срезов для пользователей регионального уровня. Доступ к чувствительным данным и индикаторам предоставляется только в объёме, необходимом для выполнения функций, с обязательным логированием.[5][6] 1.3.4. Минимизация ручных вмешательств и приоритет автоматизации. Все операции по сбору, обработке и расчёту данных по умолчанию реализуются в автоматизированном режиме; ручные вмешательства в данные и формулы допускаются только через специально предусмотренные процедуры с обязательной фиксацией причин, объёма и авторов. Такой подход снижает риск ошибок и манипуляций, повышает воспроизводимость расчётов и способствует долгосрочной устойчивости системы.[1] 2.1. Контуры данных и потоки 2.1.1. Операционный контур (таск‑трекер, approval‑flow). Операционный контур включает системы постановки и исполнения задач (таск‑трекеры, модули согласования), из которых в инфраструктуру данных поступают события о задачах и материалах: идентификаторы, типы, ответственные, временные метки и статусы стадий approval‑flow. Эти данные формируют основу для расчёта SLA, временных метрик, очередей и индекса SSI по компоненту нагрузки.[1] 2.1.2. Мониторинговый контур (СМИ, соцсети, мессенджеры). Мониторинговый контур агрегирует данные внешнего информационного поля из систем мониторинга СМИ, соцсетей и мессенджеров, включая публикации, сообщения, метаданные по охвату, тональности и риску. Потоки мониторинговых событий используются для выявления инфоповодов, высокорисковых сюжетов и расчёта компонентов индексов шума и стресса, а также для поддержки кризисных режимов.[1] 2.1.3. Контур региональной отчётности. Контур региональной отчётности обеспечивает приём стандартизированных отчётов от региональных штабов через формы, таблицы или API, с фиксацией активностей, материалов, ссылок и базовых показателей охвата. Эти данные используются для расчёта региональных KPI (включая ok_rate), оценки дисциплины отчётности и формирования витрин региональных дашбордов.[1] 2.1.4. Контур качества ссылок (link‑audit). Контур link‑audit обрабатывает ссылки, поступающие из отчётности и мониторинга, выполняя автоматические проверки технической доступности, содержательной релевантности и качества источников; результаты фиксируются в виде статусов, оценок (qualityscore) и вердиктов (OK/FAIL/REVIEW). Эти данные служат основой для расчёта показателей ok_rate и weighted_ok_rate, а также для формирования trust‑score площадок.[1] 2.2. Слои архитектуры 2.2.1. Слой сбора и интеграции (ETL/ELT, коннекторы, API). На слое сбора и интеграции реализуются коннекторы к операционным системам, системам мониторинга и формам отчётности, а также процессы ETL/ELT, обеспечивающие доставку сырых данных в хранилище; при необходимости используется промежуточный staging‑слой. Здесь выполняются базовые проверки формата, дедупликация и обогащение метаданными (источник, время загрузки, версия схемы).[2][3] 2.2.2. Слой хранилища (DWH, Data Lake, витрины KPI). Слой хранилища включает централизованное хранилище данных (DWH/Data Lake), в котором организованы факт‑таблицы и справочники, а также специализированные витрины (Data Marts) для расчёта и потребления KPI. Хранилище реализует принцип SSOT и обеспечивает единообразный доступ к историческим и текущим данным для всех аналитических и отчётных задач.[3][4] 2.2.3. Слой расчёта метрик и индексов (jobs, сервисы расчёта). На слое расчёта реализуются пакетные и потоковые jobs, а также сервисы, отвечающие за трансформацию сырых данных в метрики и индексы в соответствии с методиками Тома 2. Здесь применяются агрегирования, нормализация, вычисление индексов (SSI, PRS и др.), а также логирование версий формул и параметров.[1] 2.2.4. Слой визуализации и отчётности (дашборды, выгрузки). Слой визуализации включает BI‑системы и отчётные сервисы, которые строят дашборды и формируют выгрузки на основе витрин KPI, обеспечивая различные представления для руководства, операционного штаба, аналитиков и регионов. На этом слое реализуются цветовые пороги, флаги low_confidence, ограничения плотности показателей и ролевое ограничение доступа.[5][3] 2.3. Модель данных для метрик и индексов 2.3.1. Справочники и измерения (регионы, площадки, типы материалов, режимы). В модели данных выделяются отдельные таблицы‑измерения (dimension tables) для регионов, площадок и источников, типов материалов, режимов работы штаба, ролей и других сущностей, задающих оси анализа. Каждое измерение имеет стабильный ключ и набор атрибутов, обеспечивающих фильтрацию, группировку и формирование разрезов отчётности.[4][6] 2.3.2. Факт‑таблицы задач и стадий approval‑flow. Факт‑таблицы задач и стадий содержат события по задачам и материалам: временные метки переходов между стадиями, идентификаторы ответственных, флаги нарушений SLA и эскалаций. Эти таблицы являются основой для расчёта временных метрик, долей нарушений и агрегированных операционных показателей.[7][1] 2.3.3. Факт‑таблицы событий мониторинга и ссылок. Отдельные факт‑таблицы хранят события мониторинга (публикации, сообщения, реакции) и данные по ссылкам (URL, технический статус, qualityscore, verdict), связаны со справочниками источников и регионов. На их основе рассчитываются индексы шума, рисков и показатели качества источников, включая ok_rate.[8][1] 2.3.4. Связь модели данных с метриками и индексами Тома 2. Для каждой метрики и индекса из Тома 2 в технической документации фиксируется, какие факт‑таблицы и измерения используются, на каком уровне детализации (grain) и с какими полями. Такая карта соответствия обеспечивает воспроизводимость расчётов и упрощает анализ влияния изменений модели данных на показатели.[6][9] 2.4. Data Lineage и трассировка данных 2.4.1. Принципы фиксации происхождения данных (source → transform → metric). Система ведёт учёт происхождения данных на уровне источников, трансформаций и целевых наборов (lineage), с фиксацией: из какого источника поступили данные, какие шаги обработки были применены, какие витрины и метрики на них опираются. Стандартизируются правила именования, метаданные и форматы описания lineage, чтобы обеспечить единообразие между контурами.[10][11] 2.4.2. Трассировка вычислений индексов (например, SSI). Для ключевых индексов (SSI, PRS и др.) обеспечивается возможность детальной трассировки: от текущего значения индекса в дашборде до конкретных агрегатов, компонент и исходных записей в факт‑таблицах. Это позволяет проверять корректность расчётов, разбирать спорные значения и анализировать влияние отдельных событий на индексы.[12][1] 2.4.3. Использование lineage при разборе спорных значений и инцидентов. Data lineage используется при анализе инцидентов качества данных и спорных управленческих кейсов: для выяснения, где именно произошло искажение (источник, трансформация, витрина) и какие дашборды и решения могли быть затронуты. Результаты таких разборов учитываются при корректировке пайплайнов, модели данных и регламентов работы с данными.[13][14] 3.1. Операционный контур (approval‑flow, SLA) 3.1.1. Интеграция с таск‑трекером и системами согласования. Интеграция с таск‑трекером и модулями согласования реализуется через стандартизированные API или коннекторы, обеспечивающие передачу в инфраструктуру данных событий о создании, изменении и завершении задач и материалов. Для каждой записи фиксируются идентификаторы задач, типы, ответственные, текущие стадии approval‑flow и ключевые временные метки, необходимые для расчёта SLA.[1][2] 3.1.2. Схема логирования статусов и переходов по стадиям. В операционных системах или на уровне ETL настраивается детальное логирование переходов задач между стадиями (черновик, редактура, смысл, утверждение и др.) с указанием времени входа и выхода, причины перехода и инициатора. Логи строятся таким образом, чтобы по ним можно было восстановить полную историю движения задач и автоматически выявлять нарушения нормативов по стадиям и в целом.[2][3] 3.1.3. Передача данных в хранилище для расчёта SLA и операционных метрик. Логи задач и стадий регулярно выгружаются или стримятся в хранилище данных, где формируются факт‑таблицы для расчёта времени прохождения стадий, долей нарушений SLA, долей возвратов и эскалаций. Периодичность загрузки и допустимая задержка обновления этих данных задаются исходя из требований к свежести операционных дашбордов.[4][2] 3.2. Мониторинг информационного поля 3.2.1. Интеграция с источниками данных (новостные API, соцсети, мессенджеры). Для мониторинга информационного поля используются специализированные API‑провайдеры и/или собственные парсеры, интегрированные с новостными лентами, социальными сетями и мессенджерами; обеспечивается приём потоков публикаций с метаданными (тематика, источник, тональность, сущности, охват). Настройки фильтров (по ключевым словам, регионам, персонам) согласуются с тематическими зонами ответственности штаба.[5][6][2] 3.2.2. Очереди сбора и фильтрации событий (stream / batch). Потоки событий мониторинга обрабатываются через очередь сообщений или стриминговую платформу, где выполняются первичная фильтрация, дедупликация, определение релевантности и маршрутизация по контурам (операционный, аналитический, crisis). В конфигурации очередей задаются приоритеты для высокорисковых и кризисных сюжетов, чтобы минимизировать задержку их обработки.[7][8] 3.2.3. Хранение сырых и агрегированных событий мониторинга. Сырые события мониторинга сохраняются в отдельном слое хранилища (raw), а на их основе формируются агрегированные таблицы и витрины (по темам, регионам, источникам, тональности), используемые для индексов шума, рисков и кризисной аналитики. Схемы хранения позволяют как проводить ретроспективный анализ, так и поддерживать оперативные дашборды.[9][2] 3.3. Региональная отчётность 3.3.1. Каналы приёма отчётности (формы, таблицы, API). Приём региональной отчётности реализуется через унифицированные каналы: стандартизированные формы, шаблоны таблиц или API‑endpoint, обеспечивающие структурированную передачу перечня активностей, материалов, площадок, ссылок и базовых метрик. Форматы и обязательные поля соответствуют требованиям Тома 2 и приложениям с шаблонами отчётов.[2] 3.3.2. Автоматические проверки полноты, формата и согласованности данных. При поступлении отчётности выполняются автоматические проверки: наличие всех обязательных полей, корректность форматов дат и ссылок, отсутствие очевидных противоречий (например, охват без материала), базовая валидация по справочникам. Результаты проверок фиксируются, а отчёты с критическими ошибками могут отправляться на доработку или помечаться флагом низкой достоверности.[10][2] 3.3.3. Загрузка отчётности в витрины и связь с региональными KPI. После прохождения проверок отчётные данные загружаются в витрины региональных KPI, где связываются с региональными справочниками и результатами link‑audit. На основе этих витрин рассчитываются региональные показатели активности, качества данных (ok_rate, доля недоступных ссылок) и дисциплины, используемые в дашбордах и отчётности.[2] 3.4. Контур link‑audit и качества ссылок 3.4.1. Архитектура обработки URL (очереди, воркеры, ретраи). Ссылки, поступающие из отчётности и мониторинга, помещаются в очередь обработки; пул воркеров асинхронно выполняет проверки URL с учётом приоритизации и ограничений по частоте запросов. В архитектуре предусмотрены механизмы повторных попыток (retry) при временных сбоях и обработка «зависших» задач.[8][7][2] 3.4.2. Проверка технической доступности (HTTP‑статусы, таймауты, редиректы). Первый этап link‑audit включает проверку технической доступности: HTTP‑статус, корректность домена, обработку редиректов, таймауты, ответы вроде 404/500/403, а также выявление приватных или удалённых материалов. Результаты фиксируются в полях статуса (ok, error404, timeout, private и др.) и используются для расчёта доли недоступных ссылок.[11][2] 3.4.3. Оценка качества содержимого (qualityscore, флаги duplicate/offtopic и др.). При успешном доступе к содержимому выполняется анализ текста/страницы: определяется релевантность заявленному событию, уникальность (флаг duplicate), полнота содержания, признаки манипулятивности или нерелевантности (offtopic). На основе этих признаков рассчитывается qualityscore и выставляются флаги, влияющие на вердикт ссылки и trust‑score площадки.[12][2] 3.4.4. Формирование verdict (OK/FAIL/REVIEW) и запись результатов в SSOT. По результатам технической и содержательной проверки каждой ссылке присваивается итоговый вердикт (OK/FAIL/REVIEW), который вместе с сопутствующими полями (status, qualityscore, flags) записывается в ядро LDataIntegrity как часть единого источника истины. Эти записи используются для расчёта ok_rate/weighted_ok_rate и для контроля качества отчётности регионов и блоков.[2] 3.5. Ограничения на ручные корректировки данных 3.5.1. Запрет прямых изменений в витринах и факт‑таблицах. Прямое редактирование витрин KPI и факт‑таблиц в хранилище запрещается; любые изменения данных должны происходить либо через исходные системы (таск‑трекер, формы отчётности), либо через специально предусмотренный контур ручных правок. Это снижает риск несанкционированных корректировок показателей и нарушений принципа SSOT.[2] 3.5.2. Специальный контур ручных правок (form → review → apply). Для необходимых ручных корректировок (например, исправление очевидных ошибок) создаётся отдельный процесс: заявка на правку через форму, рассмотрение и одобрение уполномоченным лицом, автоматическое применение изменения через контролируемый сервис. Все шаги процесса фиксируются, а изменения применяются таким образом, чтобы сохранялась трассировка до исходной и скорректированной версии данных.[13][14] 3.5.3. Логирование причин, авторов и объёма ручных корректировок. Каждая ручная корректировка сопровождается обязательной фиксацией автора, времени, затронутых записей и обоснования причины изменения; эти данные сохраняются в отдельном журнале и могут использоваться для аудита и разборов спорных кейсов. При регулярных или массовых корректировках инициируется пересмотр соответствующих процессов сбора и обработки данных.[15][2] 4.1. Общие требования к пайплайнам 4.1.1. Периодичность расчёта и SLA на выполнение jobs. Для каждого пайплайна расчёта метрик и индексов устанавливаются периодичность запуска (stream/почасовой/суточный) и целевые SLA по времени завершения, обеспечивающие актуальность данных для дашбордов и отчётности. Нарушения SLA по пайплайнам фиксируются и учитываются в технических показателях качества инфраструктуры.[1][2] 4.1.2. Логирование параметров, версий формул и результатов. Все jobs расчёта метрик и индексов обязаны логировать: время запуска и завершения, используемую версию формул и параметров, объём обработанных записей, агрегированные результаты и статус выполнения. Логи хранятся в централизованной системе и используются для аудита, отладки и воспроизведения расчётов.[3][1] 4.1.3. Мониторинг успешности и времени выполнения пайплайнов. Для пайплайнов настраивается мониторинг успешности запусков, времени выполнения и частоты ошибок, с визуализацией этих показателей и алертами при отклонениях от норм. Это позволяет своевременно выявлять деградацию производительности и риски устаревания данных.[4][5] 4.2. Пайплайн операционных метрик 4.2.1. Расчёт временных показателей (SLA, T_draft, T_edit, T_sense, T_approve). Пайплайн операционных метрик вычисляет длительность прохождения задач по стадиям approval‑flow на основе временных меток в факт‑таблицах: T_draft, T_edit, T_sense, T_approve, а также общую длительность согласования. Расчёты выполняются для заданных разрезов (тип материала, блок, режим, регион).[6][1] 4.2.2. Расчёт доли нарушений SLA, доли возвратов и эскалаций. На основе временных показателей и статусных флагов пайплайн рассчитывает долю материалов с нарушением SLA по стадиям и в целом, долю материалов с возвратами на предыдущие этапы и долю задач, потребовавших эскалации. Эти показатели формируются как суточные и недельные агрегаты для использования в отчётности и индексе SSI.[1] 4.2.3. Формирование суточных агрегатов и витрин для отчётности. Результаты расчёта операционных метрик записываются в отдельные витрины KPI, содержащие суточные и периодические агрегаты по штабу и регионам. Эти витрины являются источником данных для утренних и недельных отчётов, а также для соответствующих дашбордов.[7][1] 4.3. Пайплайн индекса SSI 4.3.1. Сбор и подготовка компонентов (нагрузка, риски, нарушения). Пайплайн SSI агрегирует данные из операционного контура, мониторинга и журналов нарушений, формируя компоненты нагрузки (очереди, объём задач), рисков (высокорисковые/кризисные кейсы) и нарушений (SLA, дисциплина). На этапе подготовки выполняется нормализация входных метрик к согласованным шкалам.[1] 4.3.2. Применение нормализации и весов, расчёт SSI_today. Для каждого периода (например, день) пайплайн применяет функции нормализации к компонентам, а затем рассчитывает SSI_today как взвешенную сумму нормированных компонентов с использованием весов, определённых в Томе 2. Результат сохраняется в витрине индексов с указанием использованных параметров.[8][1] 4.3.3. Расчёт SSI_effective (сглаживание, учёт инерции). На основе временного ряда SSI_today выполняется расчёт сглаженного SSI_effective по заданной формуле (например, экспоненциальное сглаживание с коэффициентом α), отражающего инерцию системы. Именно SSI_effective используется как основной вход для смены режимов и стратегических решений.[9][1] 4.4. Пайплайн ok_rate и weighted_ok_rate 4.4.1. Сбор данных link‑audit и trust‑score площадок. Пайплайн качества ссылок объединяет результаты link‑audit (verdict, qualityscore, flags) с данными о площадках и их trust‑score, формируя таблицу входных записей для расчёта показателей по регионам и каналам. Обеспечивается использование только актуальных результатов проверок за целевой период.[1] 4.4.2. Расчёт ok_rate и weighted_ok_rate по регионам, каналам и штабу. На основе входных данных рассчитываются базовый ok_rate (доля ссылок с вердиктом OK) и weighted_ok_rate, учитывающий trust‑score площадок как вес при усреднении, для каждого региона, канала и в агрегате по штабу. Пороговые значения и правила интерпретации показателей задаются в Томе 2.[7][1] 4.4.3. Подготовка витрин для регионального дашборда и KPI. Результаты расчёта ok_rate и weighted_ok_rate записываются в специализированные витрины, используемые региональным дашбордом, отчётами по регионам и системой KPI для команд. Витрины включают также вспомогательные поля (количество ссылок, доля недоступных ссылок, доля FAIL/REVIEW) для аналитики.[1] 4.5. Управление изменениями формул (feature freeze) 4.5.1. Процедура изменения формул и параметров индексов. Любые изменения формул расчёта метрик и индексов, а также их параметров (веса, пороги, функции нормализации) проходят формализованную процедуру: инициирование, методологическое согласование, техническая оценка, утверждение и плановый релиз. Описание изменений включается в документацию и конфигурацию расчётного слоя.[10][1] 4.5.2. Запрет изменений формул в активной фазе кампании без отдельного решения. В активной фазе кампании вводится режим feature freeze для формул: изменения допускаются только по отдельному решению руководителя штаба и владельца методики с указанием причин и ожидаемого эффекта. Это предотвращает неконтролируемую «подкрутку» индексов в период повышенного стресса.[11][12] 4.5.3. Фиксация изменений формул в журнале методик и журнале релизов. Все изменения формул и параметров индексов фиксируются одновременно в журнале методик (Том 2) и журнале релизов ИТ‑системы с указанием даты, версии, автора, утверждающих лиц и затронутых пайплайнов. Это обеспечивает прослеживаемость влияния изменений на метрики и позволяет корректно интерпретировать динамику показателей во времени.[13][1] 5.1. Общий дашборд штаба 5.1.1. Источники данных и схема выборки. Общий дашборд штаба использует витрины индексов (SSI, PRS при наличии), операционных метрик (SLA, очереди approval‑flow), качества данных (ok_rate, LDataIntegrity) и статусов режимов, формируемые на слое расчёта и хранилища. Схема выборки обеспечивает получение агрегатов по штабу в целом и, при необходимости, сводных показателей по регионам и проблемным зонам.[1][2] 5.1.2. Кэширование и частота обновления. Для общего дашборда применяется комбинированная стратегия: ключевые показатели (режим, SSI_effective, очереди) обновляются с высокой частотой (например, раз в 5–15 минут или почасово), при этом результаты запросов к витринам кэшируются для снижения нагрузки на хранилище. Настройки кэша (TTL, инкрементальные обновления) подбираются с учётом допустимой задержки и требований к отзывчивости интерфейса.[3][4] 5.1.3. Реализация цветовых порогов и сигналов low_confidence. Для основных показателей реализуется цветовая индикация (RAG/«светофор») на основе чётко определённых порогов, согласованных с методиками Тома 2; отдельно визуализируются флаги low_confidence при недостаточном объёме данных или превышении допустимой задержки. Это позволяет ЛПР быстро различать норму, зону внимания и критические состояния, учитывая при этом достоверность данных.[2][5][6] 5.2. Дашборд approval‑flow 5.2.1. Структура данных для очередей и стадий согласования. Дашборд approval‑flow опирается на витрины, агрегирующие данные о количестве задач на каждой стадии, времени нахождения на стадии, нарушениях SLA и возвратах, с возможностью детализации до уровня отдельных задач. Структура данных поддерживает как моментные срезы (текущие очереди), так и исторические ряды для анализа трендов.[7][2] 5.2.2. Фильтры по режиму, типам материалов, блокам и регионам. В интерфейсе дашборда реализуются фильтры по режимам работы штаба, типам материалов, ответственным блокам и регионам, позволяющие операционному руководителю быстро фокусироваться на нужном сегменте. Фильтры должны работать без существенных задержек благодаря оптимизированным запросам и кэшированию.[8][2] 5.2.3. Отображение узких мест (SLA, загрузка стадий). Узкие места визуализируются через выделение стадий с повышенной долей нарушений SLA, чрезмерной длиной очередей или аномально длинным временем обработки, с использованием цветовых индикаторов и подсказок. Это позволяет приоритизировать управленческие действия (перераспределение ресурсов, изменение правил) в рамках approval‑flow.[9][2] 2.5. Политика хранения данных (Data Retention) 2.5.1. Общие принципы retention. Для всех классов данных (сырые события, агрегированные показатели, индексы, технические логи) устанавливаются целевые сроки хранения, исходя из задач управления, требований к аудиту и технических ограничений. Политика хранения документируется и пересматривается не реже одного раза в год владельцем инфраструктуры совместно с владельцем методологии. 2.5.2. Сырые события операционных и мониторинговых контуров. Сырые данные из операционного контура (таск‑трекеры, approval‑flow) и мониторинга информационного поля хранятся в отдельном слое (raw) ограниченный период (например, 3–12 месяцев), достаточный для пересчёта индексов и проведения разборов. По истечении срока они архивируются или удаляются с учётом требований к безопасности и конфиденциальности. 2.5.3. Агрегаты и витрины KPI. Агрегированные данные и витрины KPI (суточные/недельные срезы, региональные показатели, операционные метрики) хранятся дольше, чем сырые события (например, 2–3 года), чтобы обеспечивать анализ динамики, сравнение кампаний и посткризисные разборы. При необходимости старшие периоды могут агрегироваться до более крупного шага (неделя/месяц) для экономии ресурсов. 2.5.4. Индексы и режимные маркеры. Значения ключевых индексов (SSI, PRS и др.), а также записи о режимах работы штаба и ручных override хранятся в горизонте, достаточном для стратегического анализа и институциональной памяти (как минимум срок жизни цикла кампаний). Эти данные рассматриваются как часть управленческой истории и подлежат приоритетной защите от потери. 2.5.5. Технические логи и журналы доступа. Логи работы пайплайнов, access‑логи, журналы изменений конфигураций и ручных корректировок данных хранятся в соответствии с внутренними политиками безопасности (например, 1–3 года), с возможностью выборочного продления хранения для ключевых инцидентов. Для логов могут применяться отдельные правила архивирования и ограничения доступа 5.3. Региональный дашборд 5.3.1. Структура витрины региональных KPI (ok_rate, отчётность, нарушения). Региональный дашборд использует витрину, содержащую для каждого региона показатели своевременности и полноты отчётности, ok_rate и weighted_ok_rate, долю недоступных ссылок, количество нарушений регламентов и базовые метрики активности. Витрина должна быть оптимизирована для сортировки и фильтрации по нескольким полям.[10][2] 5.3.2. Реализация статусов P1/P2/P3 и тепловых карт. Для регионов с устойчивыми отклонениями от целевых показателей рассчитываются статусы P1/P2/P3, которые визуализируются цветом и, при необходимости, отдельными значками; дополнительно могут использоваться тепловые карты по регионам. Логика присвоения статусов согласуется с порогами Тома 2 и реализуется на слое расчёта.[11][2] 5.3.3. Ограничение видимости межрегиональных данных. Региональный дашборд реализует ролевое ограничение: пользователи регионального уровня видят данные только по своему региону (и, при необходимости, по агрегированным группам), тогда как центральный штаб имеет доступ к полному межрегиональному срезу. Это обеспечивает соблюдение принципа сегментации и минимизации лишнего доступа к чужим данным.[12][13][2] 5.4. Технические требования к визуализации 5.4.1. Ограничение числа ключевых показателей на главных экранах. Главные экраны дашбордов для ЛПР (общий дашборд штаба, ключевой экран регионального дашборда) ограничиваются 5–7 ключевыми показателями без прокрутки, чтобы избежать перегрузки и потери фокуса. Дополнительные метрики выносятся на вкладки детализации, всплывающие панели или отдельные отчётные представления.[2][11] 5.4.2. Ролевые представления (руководство, операционный штаб, регионы). Настройки дашбордов предусматривают разные представления в зависимости от роли: агрегированные индексы и сигналы для руководства, операционные метрики и очереди для штаба, региональные KPI и качество отчётности для регионов. Ролевые представления реализуются через фильтры доступа и преднастроенные наборы виджетов.[14][15][2] 5.4.3. Логирование изменений настроек и конфигураций дашбордов. Все изменения конфигураций дашбордов (набор показателей, пороги, фильтры по умолчанию, права доступа) подлежат логированию с указанием автора, времени и сущности изменения, с возможностью восстановления предыдущих конфигураций. Это обеспечивает контроль за эволюцией визуализации и предотвращает несанкционированные изменения, влияющие на интерпретацию данных.[13][2] 6.1. Мониторинг здоровья пайплайнов и задержек данных 6.1.1. Метрики здоровья ETL/стриминга (ошибки, latency, отставание очередей). Для всех ETL и стриминговых процессов вводятся технические метрики: количество ошибок и неуспешных запусков, среднее и максимальное время выполнения, задержка обработки сообщений, размер и отставание очередей. Эти показатели собираются в систему мониторинга и используются для оценки стабильности контура данных.[1][2] 6.1.2. Контроль задержки (data latency) для ключевых витрин. Для витрин, от которых зависят дашборды ЛПР и расчёт SSI/ok_rate, измеряется data latency — интервал между возникновением события в источнике и появлением агрегированного значения в витрине. Для каждой витрины задаются целевые значения задержки и настраиваются алерты при их превышении.[3][4] 6.1.3. Пороговые значения и визуализация технических KPI. Определяются пороговые значения технических KPI (latency, процент ошибок, отставание очередей), при превышении которых состояние пайплайнов считается деградированным; эти показатели визуализируются в отдельном техническом дашборде. Технические KPI используются ИТ‑блоком и владельцем инфраструктуры для приоритизации работ по стабильности.[2][1] 6.2. Алерты и техинциденты 6.2.1. Правила настройки алертов по сбоям загрузки и расчёта индексов. Настраиваются алерты, реагирующие на: сбои загрузки данных из ключевых источников, невыполнение или частые ошибки jobs расчёта метрик и индексов, отклонения latency от целевых значений. Пороговые правила алертов согласуются с требованиями по RPO/RTO и обновлению дашбордов.[5][6] 6.2.2. Каналы и регламент доставки алертов (операционный штаб, ИТ). Алерты по техническим инцидентам доставляются в согласованные каналы (мессенджеры, почта, системы тикетов) с разделением адресатов: оперативные алерты — дежурному ИТ‑персоналу, критические алерты по витринам ЛПР — дополнительно операционному руководителю штаба. В регламенте фиксируются требования к времени реакции и эскалации.[7][8] 6.2.3. Связь алертов с операционным режимом штаба и журналом инцидентов. Информация о критических алертах и техинцидентах отражается в журнале инцидентов и учитывается при обсуждении режима работы штаба и анализе качества данных на weekly reset. При длительных или повторяющихся инцидентах может приниматься решение о временной маркировке показателей как low_confidence или ограничении использования отдельных индексов.[4] 6.3. Резервирование и восстановление (RPO/RTO) 6.3.1. Целевые RPO/RTO для критичных контуров (approval‑flow, SSI, дашборды ЛПР). Для критичных контуров (данные approval‑flow, расчёт SSI и витрины, питающие дашборды руководства) устанавливаются целевые показатели RPO (допустимая потеря данных) и RTO (максимальное время восстановления) и документируются в планах восстановления. Архитектура и процессы эксплуатации должны обеспечивать достижимость этих целей.[9][10] 6.3.2. Резервные каналы и источники данных для отчётности и решений. На случай недоступности основных источников данных или витрин предусматриваются резервные каналы (упрощённые выгрузки, альтернативные формы сбора информации), позволяющие поддерживать минимально необходимый уровень отчётности и принятия решений. Использование резервных данных явно помечается в отчётах и дашбордах.[4][7] 6.3.3. Процедуры восстановления и тесты готовности (disaster recovery drills). Разрабатываются и документируются пошаговые процедуры восстановления для ключевых компонентов (хранилище, пайплайны, дашборды), включая порядок действий, ответственных и контрольные точки. Регулярно проводятся тренировки (drills) по отработке сценариев отказа и восстановления, результаты которых фиксируются и используются для улучшения планов.[11][7] 6.4. Isolation в режиме Crisis 6.4.1. Приоритет вычислительных задач по кризисным пайплайнам. В режиме Crisis вычислительные ресурсы и квоты распределяются с приоритетом в пользу пайплайнов, обслуживающих кризисные индексы, мониторинг и дашборды для Crisis Cell, в том числе через настройку очередей, планировщиков и лимитов. Это минимизирует риск задержек критичных данных в условиях ограниченных ресурсов.[12][4] 6.4.2. Временное ограничение второстепенных расчётов и обновлений. В кризисном режиме допускается временное снижение частоты обновления или приостановка второстепенных расчётов, архивных задач и тяжёлых аналитических запросов, если их выполнение препятствует работе приоритетных пайплайнов. Решения об ограничении принимаются ИТ‑блоком совместно с операционным руководителем и фиксируются в журнале инцидентов.[13][4] 6.4.3. Особый режим мониторинга и алертинга в Crisis. На период Crisis усиливается мониторинг ключевых технических KPI (latency, ошибки, состояние очередей) для приоритетных контуров и настраиваются более агрессивные алерты по деградации, с сокращёнными порогами времени реакции. По завершении кризиса проводится анализ работы инфраструктуры и, при необходимости, корректировка настроек isolation и приоритизации.[14][15][4] 7.1. Модель доступа к данным и дашбордам 7.1.1. Роли (руководство, операционный штаб, аналитики, регионы, ИТ). В системе доступа выделяются как минимум следующие роли: руководство штаба, операционный штаб, аналитический блок, региональные пользователи и ИТ‑персонал, каждая с чётко определённым набором прав на просмотр и управление данными и дашбордами. Ролевая модель согласуется со структурой управления из Тома 1 и используется как основа для настройки прав в хранилище и BI‑среде.[1][2] 7.1.2. Разделение доступа к сырым данным, витринам и индикаторам. Доступ к сырым данным (raw/staging), витринам KPI и агрегированным индикаторам разграничивается: большинство пользователей работают только с витринами и дашбордами, тогда как доступ к сырым данным имеют ограниченные технические и аналитические роли. Это снижает риск утечки чувствительной информации и неконтролируемых интерпретаций «грязных» данных.[3][4] 7.1.3. Ограничение доступа регионов к чужим данным (межрегиональная изоляция). Для региональных пользователей реализуется межрегиональная изоляция с помощью механизмов построчного разграничения доступа (row‑level security) или отдельных витрин: регион видит только свои данные и агрегированные сравнения без раскрытия детализации по другим регионам. Центральный штаб и аналитики имеют доступ ко всем регионам для системного анализа.[2][5][6] 7.2. Аутентификация и авторизация 7.2.1. Единый механизм аутентификации (SSO/IDP). Для всех систем, связанных с дашбордами и данными, используется единый механизм аутентификации (SSO через корпоративный IDP), обеспечивающий централизованное управление учётными записями и минимизацию числа отдельных логинов. Это упрощает управление доступом и снижает риск компрометации учётных данных.[5][7] 7.2.2. Политики паролей, токенов и сессий. Внедряются политики минимальной сложности и регулярной ротации паролей, правила использования и сроков жизни токенов доступа, а также ограничения по времени сессий и автоматический выход при бездействии. Эти требования распространяются на все интерфейсы доступа к данным и дашбордам.[7][8] 7.2.3. Управление доступами при смене ролей и увольнениях. Регламентируется процесс изменения и отзыва прав при смене должности, переходе в другой блок или увольнении: доступы пересматриваются и корректируются автоматически или по заявке, а критичные роли проходят дополнительное согласование. Своевременное отключение и перераспределение прав фиксируется и контролируется ИТ‑блоком.[9][10] 7.3. Логирование доступа и действий 7.3.1. Логи доступа к чувствительным данным и дашбордам. Система ведёт подробные логи доступа к чувствительным данным и ключевым дашбордам: кто, когда и к каким объектам обращался, с какого устройства/адреса и в каком режиме (просмотр, экспорт). Эти логи используются для выявления аномалий и расследования подозрительной активности.[11][12] 7.3.2. Логи изменений в настройках пайплайнов и визуализации. Любые изменения конфигураций пайплайнов, витрин и дашбордов (формулы, фильтры по умолчанию, пороги, права доступа) логируются с указанием автора, времени и сути изменения. Это обеспечивает прозрачность эволюции системы и возможность отката к предыдущим настройкам при необходимости.[13][2] 7.3.3. Использование логов при расследовании инцидентов и аудите. Логи доступа и изменений используются как основной источник данных при расследовании инцидентов безопасности, нарушений регламентов и спорных управленческих решений, а также при проведении внутренних и внешних аудитов. На их основе могут корректироваться политики доступа, усиляться контроль и вноситься изменения в архитектуру безопасности.[12][11] 8.1. Среды и релизный цикл 8.1.1. Разделение сред (dev / test / prod). Инфраструктура данных и дашбордов разворачивается минимум в трёх средах: dev (разработка и эксперименты), test/UAT (тестирование и приёмка) и prod (боевой контур), с чётким разграничением прав и данных между ними. Это позволяет проверять изменения без риска для боевых расчётов и отчётности штаба.[1][2] 8.1.2. Порядок выката изменений (релизный процесс, окна). Вводится формализованный релизный процесс: подготовка изменений и тестирование в dev, регрессионное тестирование и приёмка в test, плановый выкат в prod в согласованные временные окна, с возможностью отката. Для критичных исправлений допускаются внеплановые релизы с отдельным согласованием.[3][1] 8.1.3. Стратегия миграций схем и витрин (migrations). Изменения схем хранилища и структуры витрин выполняются через контролируемые миграции (скрипты или инструменты миграций), проходящие тот же цикл dev → test → prod, с бэкапами и планом отката. Требуется документирование зависимостей, оценки влияния и тестирование совместимости с существующими пайплайнами и отчётами.[4][5] 8.2. Тестирование и контроль качества 8.2.1. Тесты корректности расчёта KPI и индексов. Для ключевых KPI и индексов (SLA‑метрики, SSI, ok_rate и др.) разрабатываются наборы автотестов и контрольных выборок, проверяющих корректность формул, агрегаций и фильтров после изменений. Результаты тестов учитываются при принятии решений о допуске изменений в prod.[6][7] 8.2.2. Тесты производительности и масштабируемости. Перед крупными изменениями архитектуры, моделей данных или объёма нагрузки проводятся тесты производительности (нагрузочные, стресс‑тесты) для оценки времени расчёта, отклика дашбордов и устойчивости к росту данных и пользователей. Выявленные узкие места устраняются до выката.[8][9] 8.2.3. Регулярный регрессионный контроль после изменений формул. Изменения формул расчёта KPI и индексов сопровождаются регрессионным тестированием: сравнение результатов до/после на исторических данных, проверка ожидаемых изменений и отсутствие неожиданных сдвигов. Итоги регрессионных проверок документируются и при необходимости выносятся на обсуждение с владельцем методики.[10][11][6] 8.3. Техподдержка и эксплуатация 8.3.1. Регламент работы ИТ‑поддержки (SLA, приоритизация запросов). Для ИТ‑поддержки инфраструктуры задаются SLA по реакции и решению инцидентов разных приоритетов (блокирующие для дашбордов ЛПР, деградация производительности, инциденты низкого приоритета). Приоритизация учитывает влияние на способность штаба принимать управленческие решения.[12][13] 8.3.2. Связь техподдержки с weekly reset и журналом инцидентов. Результаты работы техподдержки (ключевые инциденты, нарушения SLA, хронические проблемы) отражаются в журнале инцидентов и кратко докладываются на weekly reset штаба для учёта при планировании и корректировке процессов. Это обеспечивает включение технической устойчивости в общую картину управления.[14][6] 8.3.3. Каталог типовых инцидентов и playbook’и реагирования. Формируется каталог типовых инцидентов (сбои загрузки данных, задержки пайплайнов, ошибки расчёта индексов, проблемы доступа к дашбордам) и стандартные сценарии реагирования (playbook’и) с шагами, ответственными и критериями завершения. Каталог регулярно обновляется по мере накопления опыта эксплуатации.[15][12] 8.4. Документация и обучение 8.4.1. Техническая документация по архитектуре и пайплайнам. Для архитектуры данных, пайплайнов расчёта и дашбордов ведётся актуальная техническая документация: схемы, описания слоёв, зависимостей, настроек и процедур, включая ссылки на Том 3 и связанные регламенты. Документация хранится в централизованном репозитории с контролем версий.[16][6] 8.4.2. Руководства для аналитиков и регионов по работе с дашбордами. Для аналитического блока и региональных команд готовятся пользовательские инструкции: как интерпретировать показатели, какие фильтры доступны, как выгружать данные и как действовать при выявлении аномалий. Руководства согласуются с логикой Тома 1 и Тома 2, чтобы избежать расхождений в интерпретациях.[17][6] 8.4.3. Программа обучения и обновления компетенций. Вводится программа регулярного обучения: базовое обучение новых пользователей, обновляющие сессии при значимых изменениях архитектуры или методики, а также специализированные тренинги для аналитиков и ИТ‑персонала. Это обеспечивает устойчивое использование системы в соответствии с её возможностями и регламентами.[18][19]