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

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

## [Как в DevOps понимается продукт-ориентированность, согласно второму принципу?](https://cleverics.ru/digital/kb-qa/kak-v-devops-ponimaetsya-produkt-orientirovannost-soglasno-vtoromu-printsipu/)

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

Автор: Игорь Гутник

Рейтинг: 922

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, поддержка пользователей, Service Desk, Help Desk, управление продуктами, продуктовый подход, управление процессами, ИТ-процессы, эффективность, оптимизация

## [Почему важно устанавливать четкие временные рамки для CI/CD конвейера?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-ustanavlivat-chetkie-vremennye-ramki-dlya-ci-cd-konveyera/)

Важно устанавливать четкие временные рамки для CI/CD конвейера, чтобы избежать неопределенных ситуаций и иметь объективный критерий эффективности работы. Например, если установлено, что конвейер должен доставлять изменения до продуктивной среды не дольше чем за 15 минут, это создает четкий ориентир для оценки его работы. Такая конкретика не оставляет места для расплывчатых формулировок вроде 'как бы работает, но не очень' или 'вчера был, сегодня нет'. Четкие временные рамки помогают команде понимать, соответствует ли система требованиям и когда требуется вмешательство. Это также способствует дисциплине и ответственности внутри команды, так как все понимают, что конвейер должен работать стабильно и быстро, без компромиссов.

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

Рейтинг: 922

Теги: DevOps, CI/CD, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, командная работа, общие вопросы менеджмента, управление конфигурациями, CMDB, эффективность, оптимизация

## [Как построить действительно полезную CMDB?](https://cleverics.ru/digital/kb-qa/kak-postroit-deystvitelno-poleznuyu-cmdb/)

Для построения полезной CMDB сначала необходимо определить бизнес-цели, которые она должна поддерживать, и выбрать те конфигурационные единицы, которые действительно важны для этих целей. Важно не пытаться включить все возможные элементы, а сфокусироваться на ключевых. Необходимо внедрить процессы автоматического обнаружения и синхронизации данных, чтобы поддерживать актуальность информации. Стоит уделить особое внимание картографированию зависимостей между КЕ, так как это основная ценность CMDB. Необходимо настроить интерфейсы и отчетность так, чтобы информация была доступна нужным людям в необходимом формате. Также важно установить четкую ответственность за поддержание данных в актуальном состоянии и регулярно проводить аудит точности данных.

Автор: Анна Васильева

Рейтинг: 922

Теги: аудит, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, общие вопросы менеджмента, управление конфигурациями, CMDB

## [Почему информация о возможностях внешних поставщиков ИТ-услуг быстро устаревает?](https://cleverics.ru/digital/kb-qa/pochemu-informatsiya-o-vozmozhnostyakh-vneshnikh-postavshchikov-it-uslug-bystro-ustarevaet/)

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

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

Рейтинг: 922

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

## [Как влияет повышенная производительность системы на ее доступность?](https://cleverics.ru/digital/kb-qa/kak-vliyaet-povyshennaya-proizvoditelnost-sistemy-na-ee-dostupnost/)

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

Автор: Константин Нарыжный

Рейтинг: 922

Теги: архитектура ИТ, TOGAF и IT4IT, мониторинг, управление доступностью, управление инцидентами, эффективность, оптимизация

## [Какие проблемы возникают из-за отсутствия четкого разделения ролей владельца и менеджера услуг в ITIL?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-iz-za-otsutstviya-chetkogo-razdeleniya-roley-vladeltsa-i-menedzhera-uslug/)

Отсутствие четкого разделения ролей владельца и менеджера услуг в ITIL может привести к путанице в ответственности, когда неясно, кто отвечает за стратегическое целеполагание, а кто — за оперативное управление. Это может стать причиной конфликтов, дублирования обязанностей или пробелов в управлении, особенно в тех организациях, где внедряются методологии ITSM без адаптации к своим особенностям.

Автор: Константин Нарыжный

Рейтинг: 922

Теги: ITIL, ITSM, общие вопросы менеджмента, управление процессами, ИТ-процессы

## [Когда может быть полезно «делать хоть что-то» вместо бездействия?](https://cleverics.ru/digital/kb-qa/kogda-mozhet-byt-polezno-delat-khot-chto-to-vmesto-bezdeystviya/)

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

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

Рейтинг: 922

Теги: бизнес, ценность, бизнес-заказчик

## [Какие ключевые риски могут возникнуть при неосознанном выборе стратегии управления изменениями?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-riski-mogut-vozniknut-pri-neosoznannom-vybore-strategii-upravleniya-izmeneniyami/)

Применение неумелых действий в процессе внедрения изменений может привести к нескольким критическим рискам: трансформации заинтересованных сотрудников в нейтральных или противников, превращению партнеров в конкурентов или врагов, созданию новых проблем, превосходящих по сложности исходную ситуацию. Например, игнорирование интересов ключевых участников может вызвать сопротивление, а неграмотное распределение ресурсов — потерю доверия к проекту. Основной вывод — выбор стратегии должен быть сознательным и адаптированным под конкретную организацию.

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

Рейтинг: 921

Теги: стратегия, трансформация, ускорение, Time-to-Market, управление изменениями, управление проектами, PRINCE2, управление релизами, управление рисками

## [Почему определение критических функций бизнеса (VBF) так важно для измерения доступности ИТ-услуг?](https://cleverics.ru/digital/kb-qa/pochemu-opredelenie-kriticheskikh-funktsiy-biznesa-vbf-tak-vazhno-dlya-izmereniya-dostupnosti-it-usl/)

Определение критических функций бизнеса (VBF) важно, потому что это позволяет установить прямые связи между бизнес-процессами и ИТ-услугами. Это знание необходимо для того, чтобы понимать, как недоступность ИТ-компонентов влияет на выполнение критически важных бизнес-задач. Без идентификации VBF невозможно определить критерии доступности, которые действительно соответствуют бизнес-потребностям, и таким образом получить ответ на вопрос о том, как недоступность ИТ-услуг влияет на бизнес. Таким образом, VBF служат основой для бизнес-ориентированного подхода к управлению доступностью ИТ-услуг.

Автор: Артём Мукосеев

Рейтинг: 921

Теги: бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, обучение сотрудников, учебные курсы, тренинги, управление доступностью, управление знаниями

## [Как предотвратить подмену процесса управления проблемами управлением инцидентами?](https://cleverics.ru/digital/kb-qa/kak-predotvratit-podmenu-protsessa-upravleniya-problemami-upravleniem-intsidentami/)

Необходимо: 1) Чётко разделять сценарии создания инцидентов (внешние сбои) и проблем (анализ корневых причин по группе инцидентов); 2) Внедрить отдельные этапы для проблем (диагностика, утверждение решения); 3) Обучить персонал специфике процессов; 4) Настроить ITSM-систему для поддержки уникальных атрибутов проблем (например, этапы обработки); 5) Ввести метрики, отличные от инцидент-менеджмента. Ключевой момент — не создавать запись о проблеме 'для галочки' после инцидента, а запускать полноценный анализ причин.

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

Рейтинг: 921

Теги: ITSM, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, Service Desk, Help Desk, управление инцидентами, управление проблемами