Портал №1 по управлению цифровыми
и информационными технологиями

Я достаю из широких штанин… cmdb неподъёмного размера

Недавнее наблюдение за процессом замены паспорта (гражданина РФ) породило навязчивую мысль об аналогии между наблюдаемым и задачей по построению взаимодействия процессов управления изменениями (Change Management [CHG]) и управления сервисными активами и конфигурациями (Service Assets and Configuration Management [CFG]). Как всё это выглядит в случае с паспортом?
По истечении срока действия общегражданского паспорта его следует заменить. В настоящее время срок действия привязан к возрасту владельца. Замена паспорта – это не просто замена одного документа на другой. В момент, когда граждане обращаются за новым паспортом, запускается механизм проверки. Проверки чего, точно не известно, Как минимум, проверяется регистрация («прописка»). Штампика в вашем старом паспорте не достаточно, нужно подтверждение от службы, занимающейся регистрацией (это может быть «паспортистка» в вашем ЖЭКе или соответствующее подразделение МВД, если например, у вас постоянная регистрация в другом городе).
Проверяются ли места и даты рождения родителей, которые требуется указать в заявлении на замену паспорта, или данные о заграничном паспорте, точно не известно. Ничто не мешает в этой же точке запустить проверку, например, по линии военкомата. Можно заодно и характеристику с работы потребовать (если кто-то ещё помнит, что это такое), — ну, так… чтобы и здесь что-нибудь проверить.
Понятно, что чем больше проверок, тем проще обеспечить логическую целостность данных. И, стало быть, тем лучше работают процессы CHG и CFG. Или нет?
В описываемом мной случае в информационной системе, по которой происходила проверка, отсутствовала информация о месте постоянной регистрации. Т.е. какое-то изменение прошло некорректно (процесс CHG не обеспечил актуализацию данных о «конфигурационной единице» — гражданине в CMDB [configuration management database]). Обнаруженное несоответствие между данными в системе и штампиком в паспорте устраняется путём отправки запроса по почте (обычной, голубиной бумажной) и получения ответа в таком же формате. Сроки никто никакие не гарантирует. В течение всего этого времени паспорт как бы есть, но его как бы нет. sad

При построении процесса CFG одной из важных задач является определение охвата процесса. Какие компоненты нашей инфраструктуры (конфигурационные единицы) нам учитывать? И какие атрибуты этих конфигурационных единиц?
С одной стороны есть соблазн «а давайте учитывать всё». Тем более, что существуют довольно развитые средства (discovery), которые позволяют производить оперативную инвентаризацию инфраструктуры. С другой стороны, переработка всех собранных данных – дело не всегда простое. И чем больше данных, тем больше вероятность ошибки. Кроме того, чем большим количеством данных мы пытаемся управлять, тем «дороже» становится каждое изменение. Поскольку CHG должен произвести актуализацию информации в CMDB по выполнению каждого изменения, а перед изменением оценить влияние, при росте объёма данных и количества взаимосвязей между сущностями, работа CHG замедляется/удорожается. К тому же, нам понадобится спроектировать дополнительные контрольные процедуры, которые повысят нашу уверенность в достоверности данных. Например, регулярный выборочный контроль данных (который тоже сложнее/дороже при большем объёме данных и более сложной их структуре).   

Получается, что при проектировании нашей CMDB, мы в первую очередь должны подумать о том, для чего нам нужна эта база. Кто будет являться потребителями и поставщиками информации? И, если в качестве цели ставить не просто повышения нашей осведомлённости о том, что у нас есть в нашей инфраструктуре, но повышение эффективности нашей работы, требования к структуре DMDB могут получиться совсем иными.

Нужно ли нам при каждом обращении граждан в соответствующие органы осуществлять все возможные проверки (это могут быть прописка, воинская обязанность, психическое здоровье, отсутствие задолженности по налогам, коммунальным платежам и т.д. и т.п.)? Или лучше ограничиться только проверкой регистрации («прописки»)? А может и она в нашей CMDB лишняя? Сколько ресурсов мы тратим на поддержание той или иной информации в актуальном состоянии, и что нам эта информация даёт?

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT