# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

## [Какие мифы и заблуждения существуют вокруг CMDB?](https://cleverics.ru/digital/kb-qa/kakie-mify-i-zabluzhdeniya-sushchestvuyut-vokrug-cmdb/)

Основные мифы о CMDB: 1) «CMDB даёт ответы на любые вопросы» — представление о CMDB как о волшебной системе, из-за чего возникает стремление собрать в неё всё, что только можно, что приводит к перегрузке данными и снижению соотношения сигнал/шум. 2) «Без CMDB невозможно управлять ИТ» — многие организации успешно существуют без CMDB в представлении ITIL. 3) «CMDB — это исключительно технология» — отождествление CMDB с работой агентов и коннекторов для автоматического сбора информации, при этом вопросы решаемых задач отходят на второй план. 4) «Достаточно воспользоваться готовой типовой моделью CMDB от вендора» — подмена подхода «от задачи» подходом «от стандартной возможности», что аналогично списыванию в школе. Под влиянием этих мифов рискует быть создана тяжёлая, перегруженная, неудобная и бесполезная система.

Автор: Денис Денисов

Рейтинг: 68

Теги: ITIL, управление конфигурациями, CMDB

## [Как технология контейнеризации помогает в управлении микросервисами?](https://cleverics.ru/digital/kb-qa/kak-tekhnologiya-konteynerizatsii-pomogaet-v-upravlenii-mikroservisami/)

Контейнеризация позволяет организовать изолированное рабочее пространство для каждого сервиса без выделения отдельной полной виртуальной машины. Все операции по созданию и управлению контейнерами выполняются программно. Это включает автоматическое динамическое добавление дополнительных мощностей при повышении спроса и автоматическое освобождение ресурсов при снижении нагрузки, что обеспечивает эффективное использование инфраструктуры и масштабируемость.

Автор: Олег Скрынник

Рейтинг: 67

Теги: управление конфигурациями, CMDB

## [Какие компоненты инфраструктуры обычно отсутствуют в упрощённой модели, но должны быть учтены в реальной?](https://cleverics.ru/digital/kb-qa/kakie-komponenty-infrastruktury-obychno-otsutstvuyut-v-uproshchennoy-modeli-no-dolzhny-byt-uchteny-v/)

В упрощённой модели часто отсутствуют: система мониторинга, система резервного копирования, структура печати (формирование бухгалтерских чеков и актов предоставления услуг), тестовая среда, среда разработки, копия приложения. В реальной модели все эти компоненты присутствуют и требуют учёта собственных затрат: серверы для мониторинга, хранилища для резервных копий, среды для тестирования и разработки. Это существенно обогащает дерево модели и увеличивает количество элементов, на которые необходимо распределять затраты.

Автор: Андрей Труфанов

Рейтинг: 64

Теги: аллокация затрат, расчёт себестоимости услуг, мониторинг, управление конфигурациями, CMDB, экономика и финансы

## [Почему дополнительная ценность от ИТ-решений носит временный характер?](https://cleverics.ru/digital/kb-qa/pochemu-dopolnitelnaya-tsennost-ot-it-resheniy-nosit-vremennyy-kharakter/)

Дополнительная ценность может быть продемонстрирована только на этапе внедрения ИТ-решений и раннего периода их использования. Конкурентные преимущества недолговечны: очень скоро конкуренты сделают то же самое, и революционные ещё вчера ИТ-решения станут средством экономии, а затем и частью базовой инфраструктуры — если они вообще оправдают себя.

Автор: Роман Журавлёв

Рейтинг: 63

Теги: бизнес, ценность, бизнес-заказчик, управление конфигурациями, CMDB, управление релизами

## [Как системная структура объясняет проблему низкой доли инцидентов, решённых с помощью стандартных решений, и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-intsidentov-reshennykh-s-pomoshchyu-standar/)

Системная структура объясняет проблему низкой доли инцидентов, решённых с помощью стандартных решений, рекомендованных процессом управления проблемами (IRPS), и её влияние на риски.  Механизм: 1. IRPS характеризует, какая доля инцидентов решается с помощью стандартных решений, разработанных процессом управления проблемами. 2. Низкая доля означает, что стандартные решения либо не разрабатываются, либо не используются. 3. Это влияет на риски:    - Каждый инцидент решается индивидуально — повышается вероятность ошибок.    - Качество решений снижается — сотрудники могут применять неоптимальные или неправильные решения.    - MTRS растёт — время восстановления увеличивается.    - Инциденты могут эскалироваться в критичные — TMR растёт.    - Инциденты повторяются — пользователи страдают от одних и тех же проблем. 4. Высокие риски, в свою очередь:    - Увеличивают финансовые потери.    - Снижают удовлетворённость пользователей.    - Усиливают давление бизнеса на ИТ.    - Формируют разрушительный цикл.  Факторы, влияющие на низкую долю:  1. **Недостаточная работа по выявлению проблем.** Стандартные решения не создаются. 2. **Низкое качество стандартных решений.** Решения не работают. 3. **Недостаточная интеграция.** Решения не интегрированы с процессом обработки инцидентов. 4. **Отсутствие доверия.** Сотрудники не доверяют стандартным решениям. 5. **Изменение инфраструктуры.** Решения устаревают.  Системная структура показывает, что IRPS — это индикатор эффективности «лаборатории» и фактор, напрямую влияющий на риски. Улучшение IRPS требует улучшения процесса управления проблемами, обеспечения актуальности решений и их интеграции с процессом обработки инцидентов.

Автор: Павел Дёмин, Дмитрий Исайченко

Рейтинг: 60

Теги: бизнес, ценность, бизнес-заказчик, поддержка пользователей, Service Desk, Help Desk, постоянное улучшение, совершенствование, CSI, PDCA, управление инцидентами, управление конфигурациями, CMDB, управление проблемами, управление рисками, эффективность, оптимизация

## [Почему приобретённые ранее приложения и инфраструктура часто не используются в полной мере?](https://cleverics.ru/digital/kb-qa/pochemu-priobretennye-ranee-prilozheniya-i-infrastruktura-chasto-ne-ispolzuyutsya-v-polnoy-mere/)

Предыдущие годы позволяли многим компаниям не сильно беспокоиться о целесообразности закупок аппаратного и программного обеспечения. В результате в ИТ-подразделениях прямо в коридорах или на складах пылятся нераспакованные коробки с оборудованием, закупленным несколько лет назад, но так и не введённым в эксплуатацию.

Автор: Олег Скрынник

Рейтинг: 58

Теги: управление конфигурациями, CMDB

## [Почему не следует устанавливать плановые показатели по количеству регистрируемых проблем?](https://cleverics.ru/digital/kb-qa/pochemu-ne-sleduet-ustanavlivat-planovye-pokazateli-po-kolichestvu-registriruemykh-problem/)

Установка обязательного количества проблем для регистрации за определённый период является некорректным подходом, поскольку количество реальных проблем в инфраструктуре не зависит от желаний руководства. Бесполезно требовать регистрации, например, десяти проблем в месяц, если их объективно меньше или если организация не готова выделить ресурсы на их обработку. Количество проблем должно определяться реальным состоянием инфраструктуры, выбранными источниками выявления и доступными ресурсами.

Автор: Евгений Шилов

Рейтинг: 45

Теги: управление конфигурациями, CMDB

## [Как определить, какие ИТ-активы необходимо учитывать в базе конфигураций?](https://cleverics.ru/digital/kb-qa/kak-opredelit-kakie-it-aktivy-neobkhodimo-uchityvat-v-baze-konfiguratsiy/)

Определение перечня учитываемых ИТ-активов зависит от ответа на вопрос «Зачем?» — то есть от конкретных бизнес-потребностей. Например, если требуется подробный материальный учёт и ограничение охвата обслуживания, то учёт рабочих станций необходим: без информации о том, где и кем они эксплуатируются, эти требования невозможно выполнить. В таком случае в базе конфигураций может оказаться порядка 15 тысяч позиций и более. Однако в организации с собственным ИТ-департаментом для целей учёта рабочих станций может быть достаточно информации в бухгалтерской системе, а для ИТ-департамента более ценной будет информация о «железе», задействованном в предоставлении ИТ-услуг. В таком случае учёт рабочих станций в базе конфигураций несёт больше трудностей, чем пользы, а основной акцент делается на управление конфигурациями ИТ-услуг.

Автор: Павел Дёмин, Дмитрий Исайченко

Рейтинг: 40

Теги: бизнес, ценность, бизнес-заказчик, управление ИТ-активами, ITAM, SAM, управление конфигурациями, CMDB

## [Какие технологии предшествовали появлению управления ИТ-инфраструктурой как программным кодом?](https://cleverics.ru/digital/kb-qa/kakie-tekhnologii-predshestvovali-poyavleniyu-upravleniya-it-infrastrukturoy-kak-programmnym-kodom/)

Появлению управления ИТ-инфраструктурой как программным кодом предшествовали две технологии: виртуализация и облачные вычисления. Виртуализация позволила ввести дополнительный уровень абстракции между исполняемым кодом и системным программным обеспечением, разделив компетенцию между «прикладниками» и «системщиками». Облачные вычисления предоставили доступные, надёжные и безопасные вычислительные ресурсы, которыми можно управлять удалённо. Объединение этих технологий с интерфейсом командной строки (ключевая парадигма Unix-систем) дало возможность создавать и управлять ИТ-инфраструктурой с помощью программного кода.

Автор: Олег Скрынник

Рейтинг: 40

Теги: командная работа, управление конфигурациями, CMDB