SERVICENOW • CIS-DF • LOCAL DECK

Data Foundations

CMDB & CSDM · экзамен на английском

Режим подготовки Пересдача Конспект → тренировки → полный экзамен
В колоде0
Без ответа0
Не знаю0
Сложно0
Знаю0
Готовность0%
Интенсивный конспект ▶ Симулятор экзамена
0 / 0 — — Мой ответ: ещё не отвечено —

КОРОТКИЙ GLOSSARY

Термины для запоминания

Буду дополнять по твоим вопросам

Governance правила и ответственность

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

Главный вопрос: «Как сохранять CMDB правильной?»

Ingestion поступление данных

Процесс, при котором данные попадают или обновляются в CMDB из Discovery, коннекторов, импортов и других источников.

Главный вопрос: «Как данные попадают в CMDB?»

Insight понимание и выводы

Превращает данные CMDB в видимость, выводы и решения: что связано, где есть пробелы и что необходимо исправить.

Главный вопрос: «Что данные показывают и что делать дальше?»

Запомни: Ingest → Govern → Insight. Загрузить данные → сохранить их правильными → понять их и принять решение.

КАРТИНА В ГОЛОВЕ

Короткий конспект по разделам

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

Configuration 47Из чего построена CMDB

Представь CMDB как каталог большого города. Каждый реальный или логический объект — сервер, приложение, сеть или сервис — получает карточку CI. Но карточки разных объектов должны иметь разные поля, поэтому они раскладываются по классам.

  1. Configuration Item [cmdb_ci] — корень семейного дерева. Дочерние классы наследуют поля родителей: Computer → Server → Windows Server.
  2. CI Class Manager управляет этим деревом: классами, полями, обязательными и рекомендуемыми атрибутами, ownership, health-настройками и identification rules. Перед созданием custom class сначала ищут подходящий стандартный класс.
  3. Required может остановить запись через IRE, если значения нет. Recommended обычно не блокирует запись, но снижает Completeness.
  4. Слишком широкий identification rule превращает несколько объектов в один перегруженный CI; плохая идентификация создаёт дубликаты. Поэтому сначала исправляют модель и правила, затем объединяют дубликаты через Duplicate CI Remediator.

Не путай: класс — это не ярлык, а таблица с унаследованным поведением. Principal Class выделяет важные классы и помогает ограничить выбор CI в operational tasks.

Как всё работает вместе

Сначала организация решает, какие реальные объекты ей нужно управлять. Для них выбирают подходящие стандартные классы, поля и relationships. Затем источники находят объекты и через IRE создают или обновляют их CI. Health уже после этого проверяет: заполнены ли нужные поля, нет ли дубликатов и корректны ли связи.

  • Перед custom class обновляют CMDB CI Class Models и ищут подходящий out-of-box класс. Extensible разрешает создавать дочерние классы. Полный доступ дают sn_cmdb_admin/admin; для dictionary editing возможна комбинация itil_admin и personalize_dictionary.
  • Класс CI может уточняться: upgrade — к дочернему классу, downgrade — к предку, switch — в другую ветвь. При downgrade и switch поля исходного класса могут отсутствовать в целевом — тогда class-specific attributes и их данные исключаются. Если glide.class.switch.enabled выключен, cross-branch switch создаёт задачу для ручной проверки.
  • В CI Class Manager запомни маленькую карту интерфейса: Added показывает поля, созданные именно в выбранном классе; Identification Rule задаёт его уникальность; Pinned Classes быстро открывает часто используемые классы. Имя custom CI table должно начинаться с u_cmdb_ci.
  • Relationship имеет направление и смысл: например, Runs on::Runs или Depends on::Used by. Suggested Relationships помогают выбрать стандартную связь; стандартные типы лучше поддерживают отчёты, продукты и upgrades.
  • Один Application Server может обслуживать несколько Applications, а одно Application — работать на нескольких серверах, поэтому между cmdb_ci_app_server и cmdb_ci_appl связь many-to-many.

Пример: две копии одного приложения

Если Installed Application идентифицируется только по имени, две установки могут слиться в overloaded CI. Configuration file path помогает различить установки. Сначала исправляют identification rule, затем в Duplicate CI Remediation Wizard выбирают Master CI. Система первоначально предпочитает запись с большим числом связанных элементов; остальные связываются через Duplicate of, а de-duplication template делает логику повторяемой.

Что любят спрашивать

  • Dictionary override меняет унаследованное dictionary-поведение только для дочернего класса.
  • Mandatory enforcement через IRE связано с glide.required.attribute.enabled; Recommended Fields настраиваются в CI Class Manager → Health → Completeness.
  • Иконка, Principal Class и class-level Managed by group находятся в Basic Info.
  • Если Asset и CI не синхронизируют нужное поле, добавляют правило в Asset-CI Field Mapping, а не обновляют записи вручную.

Объект → CI → класс → унаследованные поля и правила.

Ingest 45Как данные входят в CMDB

Представь IRE как паспортный контроль. Источник приносит данные, но не должен самовольно писать их прямо в CMDB. Сначала система выясняет, о каком объекте идёт речь и имеет ли источник право менять его поля.

  1. Discovery идёт снизу вверх: Scanning → Classification → Identification → Exploration. Service Mapping идёт сверху вниз от сервиса к его зависимостям. Данные также приходят через Service Graph Connectors, ACC, IntegrationHub ETL и Import Sets.
  2. Identification отвечает: «Это новый CI или уже существующий?» Reconciliation отвечает: «Может ли этот источник изменить конкретный атрибут?»
  3. Если совпадений нет, разрешённый источник может создать CI. Одно совпадение обновляется. Несколько совпадений означают дубликаты; при разрешённом skip-режиме и допустимом количестве выбирается самый старый CI, иначе update отклоняется.
  4. Multisource CMDB сохраняет значения каждого источника отдельно. CMDB 360 показывает пробелы и различия, а Recompute заново определяет победившие значения после изменения правил или источника.

Не путай: Identification выбирает запись; Reconciliation выбирает, чьё значение можно записать в поле.

Как всё работает вместе

У каждого способа загрузки своя роль, но безопасный финал один — payload должен пройти через IRE. Discovery горизонтально ищет инфраструктуру по сети; Service Mapping сверху вниз строит зависимости сервиса; ACC отправляет данные с лёгкого агента; Service Graph Connectors обычно подключают cloud и observability-источники; IntegrationHub ETL и Import Sets преобразуют внешние данные.

  • Discovery задаёт четыре вопроса: Scanning — «ты доступен?», Classification — «кто ты?», Identification — «я тебя уже знаю?», Exploration — «какие у тебя поля и связи?». Примеры собранных данных: OS, RAM и MAC address.
  • ACC особенно полезен для устройств, которые подключаются нерегулярно, и для защищённых сред, где постоянное сетевое сканирование неудобно. Это агентский путь сбора, но итоговые CI всё равно должны пройти через IRE.
  • Если CMDB-данные приходят через Import Set, экзаменационная связка — onBefore transform script + CMDBTransformUtil. Она передаёт данные IRE вместо прямой записи в CMDB table.
  • IRE Data Source Rule решает, может ли источник создавать CI этого класса. Reconciliation касается обновления атрибутов: static rule задаёт фиксированный приоритет источников, dynamic rule выбирает значение по логике вроде most recent или most reported.
  • Reconciliation работает по каждому полю отдельно. Один payload может получить отказ для OS, но заполнить пустую RAM.

Пример: два источника сообщают о сервере

Discovery первым создал сервер и записал OS. Позже менее доверенный импорт прислал другую OS, но также новую RAM. Identification находит тот же CI. Reconciliation защищает OS от перезаписи, но разрешает заполнить RAM. Multisource CMDB сохраняет оба source-specific варианта, CMDB 360 показывает расхождение, а на основной записи остаётся победившее значение.

Точные факты и ловушки

  • При разрешённом skip duplicates и числе совпадений ниже порога IRE/Discovery обновляет самый старый CI по Created date; часто приводимый default threshold — 5. Выше порога update пропускается. Это временный выбор записи, а не полноценное устранение дубликатов.
  • Настройка — glide.identification_engine.skip_duplicates. Multisource включается свойством glide.identification_engine.multisource_enabled, а source-specific значения хранятся в cmdb_multisource_data.
  • Пустые CMDB 360 charts после загрузки данных → проверить job Multisource Dashboard Analytics Population. Один Recompute обычно ограничивают 100,000 CI.
  • Изменённый mapping Service Graph Connector становится ответственностью клиента; baseline updates могут отображаться как skipped changes.

Источник → IRE → найти CI → проверить право на update → сохранить.

Govern 60Как данные остаются правильными

Представь управление библиотекой. Мало занести книги в каталог: нужны владельцы, правила проверки, исправления и понятный конец жизненного цикла.

  1. CMDB Process Owner задаёт стратегию и правила; CMDB Administrator настраивает платформу; CI Analyst исправляет записи. Владельцы сервисов и приложений отвечают за данные своей области.
  2. Сначала устраняют причину плохих данных — например, IRE rule, — и только потом чистят дубликаты. Иначе интеграция создаст их снова.
  3. Data Manager автоматизирует действия: Retire оставляет CI в CMDB как retired; Archive убирает его с возможностью восстановления в retention period; Delete удаляет без восстановления. Attestation спрашивает владельца, существует ли CI; Certification проверяет заданные значения; Delete CMDB Related Entry чистит связанные записи вне иерархии CI.
  4. Health Inclusion Rule определяет, что считать в метрике. Remediation Rule запускает исправление найденной проблемы. Lifecycle Policy управляет продолжающимся жизненным циклом CI.

Не путай: Managed by — кто управляет CI; Support group — кто оказывает поддержку; Change group — кто обрабатывает изменения. Offering-level группа может быть точнее class-level группы.

Как всё работает вместе

Governance начинается не с кнопки Delete, а с ответа на четыре вопроса: зачем нужна CMDB, кто владеет данными, как измеряется успех и кто исправляет проблему. Governance charter связывает outcomes, KPI и critical success factors. Configuration Control Board задаёт направление и приоритеты, а владельцы областей подтверждают данные, которые CMDB-команда не может знать сама.

  • Data Manager вместе с Platform Owner, архитекторами, security и domain owners ведёт foundational governance. CMDB Process Owner отвечает за стратегию; Administrator — за техническую настройку; CI Analyst — за качество назначенных записей.
  • Data Manager policy проходит путь критерий → опубликованная policy → task/result → действие. Типы: Retire, Archive, Delete, Attestation, Certification и Delete CMDB Related Entry.
  • Dynamic CI Group получает меняющийся набор CI из saved query CMDB Group. Technology Management Service Offering добавляет operational context и может синхронизировать Managed by, Support и Change groups в эти CI.
  • Lifecycle лучше вести через life_cycle_stage и более детальный life_cycle_stage_status. Life Cycle Mapping [life_cycle_mapping] переводит legacy statuses в новую модель, а Life Cycle Control [life_cycle_control] задаёт допустимые Stage/Status для каждого класса. После включения Lifecycle Sync незакрытые mappings проверяют в Discrepancy Report.
  • Recommended fields задаются в CI Class Manager. Создание задач при провале этих health checks включается в Health Preferences / Health Metrics — название области немного различается между версиями.
  • Data refresh rules разрешают источнику с меньшим приоритетом снова обновлять атрибут, когда источник с высоким приоритетом неактивен заданное время.

Пример: старые серверы портят метрику

Сначала проверяют, действительно ли серверы неактуальны и почему источник перестал их обновлять. Legitimate exceptions исключают из конкретной метрики через Health Inclusion Rule. Для реальной ошибки Remediation Rule запускает workflow и создаёт Remediation Task. После подтверждённого End of Life policy может Retire CI, затем Archive его для возможного восстановления или Delete без восстановления. Для группы дубликатов Main CI предлагается по трём признакам: больше relationships, свежее Updated, старше Created.

Точные факты и ловушки

  • data_manager_admin создаёт и публикует policies; data_manager_user работает с tasks/results. Путь: CMDB Workspace → Management.
  • Archive сохраняет возможность восстановления в retention period; Delete — нет. Перед lifecycle policies проверяют mappings legacy status → Life Cycle Stage/Status.
  • Staleness обычно рассчитывается по Updated [sys_updated_on]; число 60 days — порог, а не поле. В часто цитируемом baseline-сценарии out-of-box Orphan rules — 0, но в реальном instance их могут настроить.
  • Data Foundations Dashboard содержит Best Practices, Customizations, Data Management Practices, ITSM Processes. Метрики prescribed; CMDB Health используют для гибких rules и scope.
  • Offering-level group может перекрыть class-level Managed by. Синхронизация связана с business rule CSDM - Sync Group Attributes.

Назначить владельца → задать правила → найти проблему → исправить → корректно завершить lifecycle.

Insight 52Как понять, что говорят данные

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

  1. CMDB Health показывает качество: Completeness — заполнены ли нужные поля; Correctness — нет ли duplicate, stale и orphan CI; Compliance — проходят ли audits; Relationships — здоровы ли связи.
  2. Stale CI определяется настроенным правилом, часто с default 60 days. Orphan определяется orphan rule и может означать не только отсутствие связи, но и отсутствие требуемых данных.
  3. Data Foundations Dashboard проверяет предписанные ServiceNow практики и даёт remediation playbooks. Его 90-day freshness metric — не то же самое, что default 60-day staleness rule.
  4. CMDB 360 сравнивает источники. Query Builder строит вопрос как граф классов и отношений. Unified Map визуально показывает providers и consumers вокруг CI или сервиса.

Не путай: высокий score доказывает здоровье только тех классов, правил и CIs, которые попали в scope. Если результат выглядит странно, сначала проверь scope, inclusion rules и свежесть scheduled jobs.

Как всё работает вместе

Insight отвечает не одним score, а последовательностью: измерить → сузить проблему → увидеть связи или источники → принять действие. CMDB Health измеряет качество управляемого набора CI; Data Foundations проверяет prescribed practices и предлагает playbooks; специальные инструменты помогают исследовать причину.

  • Completeness спрашивает «поля заполнены?», но заполненное поле может быть неверным. Correctness ищет duplicate, stale и orphan. Compliance использует Desired State и Scripted Audits. Relationships оценивает связи.
  • CMDB 360 исследует источники: gaps не равны Completeness, а differences не обязательно означают reconciliation error. Источники могут законно расходиться, пока reconciliation выбирает победителя.
  • Query Builder строит сохраняемый графовый запрос; Properties выбранного node добавляет output columns, filters ограничивают результаты, а разрешённые Non-CMDB Tables позволяют, например, добавить Incident.
  • NLQ запускают в CMDB Workspace: он превращает естественный язык в начальный запрос. Сложный multi-table результат открывают через View in Query Builder, уточняют и только затем сохраняют или планируют.
  • Unified Map тоже открывают в CMDB Workspace. Он объединяет прежние Application Service maps и Dependency View; фильтры Discovery source и CI type убирают лишнее из большой карты.
  • Для Desired State audit, питающего Compliance scorecard, нужны три части: Certification Filter → Certification Template → Audit.

Пример: «Какие базы Seattle связаны с инцидентами?»

В Query Builder добавляют Database node, ставят filter Location = Seattle и подключают Incident из Non-CMDB Tables. В Properties выбирают нужные output fields. Перед scheduled query ограничивают количество результатов. Если нужна только наглядная цепочка providers/consumers вокруг одного CI, быстрее открыть Unified Map: это единый современный вид поверх Application Service maps и Dependency View.

Точные факты и ловушки

  • Если из 800 серверов 700 non-duplicate, duplicate metric не проходит 100. Но orphan и duplicate counts могут различаться из-за разных scopes и Inclusion Rules.
  • NLQ для Query Builder активирует glide.cmdb.query.nlq.activated. Sensitive non-CMDB tables скрывают blacklist-настройкой; scheduled results защищают лимитом.
  • Health scores не появятся, пока не активированы соответствующие CMDB Health scheduled jobs. Поэтому пустой dashboard сначала проверяют на job, а не принимают за нулевое качество.
  • IRE-generated de-duplication tasks подсвечиваются на Home во вкладке Important actions; назначенную работу затем можно вести через My Work. Это две точки входа, а не противоречащие ответы.
  • CMDB 360 charts пусты → проверить Multisource Dashboard Analytics Population. В remediation playbook Data Foundations ищи объясняющие блоки Problem Overview и Problem Analysis.
  • 60 days — часто приводимый default staleness; 90 days — prescribed freshness metric Data Foundations. Это разные проверки.

Health измеряет качество; 360 сравнивает источники; Query Builder спрашивает; Unified Map показывает связи.

CSDM 48Как связать приложения, сервисы и бизнес

Представь CSDM как общую карту метро. Это не отдельный продукт, а договорённость о том, какие сущности использовать и как соединять их, чтобы разные ServiceNow-продукты понимали одну модель.

  1. Foundation содержит общие опорные данные. Design & Planning содержит Business Application — стратегическое описание приложения. Service Delivery содержит operational Service Instance и Technology Management Services. Service Consumption содержит Business Services и их Offerings.
  2. Business Application — идея и portfolio record: «у нас есть система Inventory». Service Instance — реально работающий экземпляр: «Inventory Production в Европе». Именно operational instance нужен для incident, problem и change.
  3. Technology Management Service Offering описывает техническое предложение, commitments и группы; через Dynamic CI Group оно управляет изменяющимся набором CIs. Business Service Offering связывает потребление бизнеса с Service Instance.
  4. Внедрение идёт Foundation → Crawl → Walk → Run → Fly: сначала базовые данные, затем Business Application ↔ Service Instance, потом техническое ownership, затем Business Offering ↔ Service Instance и наконец стратегические связи с Information Objects.

Не путай: Business Application — не production CI. Service Instance раньше назывался Application Service; Technology Management Service/Offering раньше назывались Technical Service/Offering.

Как всё работает вместе

CSDM соединяет три взгляда на одну реальность: что бизнес планирует, что реально работает и что потребитель получает. Если использовать prescribed out-of-box tables, references, lifecycle и relationships, Incident, Change, APM, Security и другие продукты видят одну и ту же картину.

  • Foundation: организации, locations, product models и lifecycle. Именно Foundation tab измеряет согласованность product models, locations и business units; примеры метрик — Locations with Parent Locations и Named Product Models with Product Owners.
  • Crawl: Business Application ↔ Service Instance. Эта связь даёт operational context для Vulnerability Response и Security Incident Response.
  • Walk: Technology Management Services/Offerings, CMDB Groups и Dynamic CI Groups; проверяются Support/Change groups и связь Dynamic CI Group ↔ CMDB Group.
  • Run: Business Service Offering ↔ Service Instance. Fly: Business Application ↔ Information Object и зрелые strategic relationships. Information Object особенно помогает SecOps понимать operational risk в контексте Business Application.

Пример: Inventory

Inventory как portfolio concept — Business Application. Inventory vX Production Europe — Service Instance, который выбирают в поле Configuration Item у Incident или Change. Если одно изменение охватывает много CI, их собирают в Dynamic CI Group и саму группу всё равно указывают в поле Configuration Item. Его инфраструктурой коллективно управляет Technology Management Service Offering. Бизнес-потребитель получает Business Service Offering, связанное с этим Service Instance.

Точные факты и ловушки

  • Домены: Business Process — Foundation; Business Application — Design & Planning; Service Instance — Service Delivery; Business Service — Service Consumption.
  • Service — управляемая capability; Offering — конкретный потребляемый или operational вариант с commitments и consumers.
  • Application Service Wizard связывает Service Instance с Business Application и Offerings. Digital Portfolio Management помогает owners управлять portfolios, services, offerings и products.
  • Enterprise Architect ведёт Business Capability hierarchy; service_admin управляет services/offerings. Для Query Builder: read-role просматривает и запускает, full role создаёт и изменяет queries.

План приложения → работающий экземпляр → техническая поддержка → потребляемый бизнес-сервис.

Rapid facts 20Как быстро распознать правильный инструмент

Этот раздел — диспетчер, а не новая тема. В scenario question сначала найди существительное, которым нужно управлять. Оно почти всегда ведёт к нужному инструменту.

  • Класс, таблица, inheritance → CI Class Manager.
  • Входящая запись, duplicate, право источника обновлять поле → IRE.
  • Retire, Archive, Delete, Attestation → CMDB Data Manager.
  • Качество и score → CMDB Health; различия источников → CMDB 360.
  • Сложный вопрос о классах и связях → Query Builder; визуальная зависимость → Unified Map.
  • Пробел в CSDM maturity → CSDM Data Foundations Dashboard.

Красные флаги: direct write в cmdb_ci обходит IRE; удаление исключений ради красивого score уничтожает правильные данные. Archive выбирают, когда восстановление нужно; Delete — когда оно должно быть невозможно.

Алгоритм scenario question

  1. Найди существительное: CI, source, field, policy, score, relationship, application или service.
  2. Найди действие: создать, идентифицировать, обновить, измерить, визуализировать, исправить, архивировать.
  3. Определи слой: Configuration строит модель; Ingest загружает; Govern управляет; Insight объясняет; CSDM связывает business и operations.
  4. Отбрось опасные ответы: direct CMDB write, массовое delete без причины, custom model при наличии стандартного, красивый score без проверки scope.

Пример выбора инструмента

Фраза «показать, какие source values отличаются» ведёт к CMDB 360. «Кто зависит от этого CI?» — к Unified Map/dependency view. «Построить сохраняемый запрос по нескольким классам и Incident» — к Query Builder. «Исправить следующий CSDM maturity gap» — к Data Foundations Dashboard.

Четыре пары, которые нельзя смешивать

  • CMDB Process Owner задаёт стратегию; CI Analyst исправляет записи.
  • Business Application — portfolio; Service Instance — production operations.
  • Service Mapping обнаруживает и строит service dependencies; Unified Map визуализирует уже известные связи.
  • Mandatory может блокировать; Recommended прежде всего влияет на Completeness. 60-day stale не равно 90-day freshness.

Govern + Insight + Ingest ≈ 74% опубликованного веса, повторявшегося в Quizlet-наборах.

Найди объект вопроса → выбери инструмент, который управляет именно этим объектом.

БЫСТРЫЙ ОБЗОР

Все выбранные карточки