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

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

## [Как соотносятся Service Design Package и методологии DevOps и Agile?](https://cleverics.ru/digital/kb-qa/kak-sootnosyatsya-service-design-package-i-metodologii-devops-i-agile/)

Вопрос актуальности SDP в контексте развития DevOps и Agile имеет значение, поскольку в новых версиях ITIL некоторые лучшие практики будут перенесены, а пробелы, касающиеся управления релизами и развертыванием, будут заполнены методиками и принципами DevOps и Agile. Базовые идеи SDP — структурированное описание услуги, её требований, планов тестирования и развертывания — остаются востребованными, но подход к их формированию и использованию может адаптироваться под agile-подходы с более короткими итерациями и непрерывной поставкой.

Автор: Шамиль Бабаев

Рейтинг: 64

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, ITIL, управление релизами, эффективность, оптимизация

## [Какую роль сыграла конференция Velocity 2009 года в развитии движения DevOps?](https://cleverics.ru/digital/kb-qa/kakuyu-rol-sygrala-konferentsiya-velocity-2009-goda-v-razvitii-dvizheniya-devops/)

Конференция Velocity 2009 года сыграла ключевую роль в развитии движения DevOps. На этой конференции Джон Олспо и Пол Хаммонд выступили с докладом «10 развёртываний в день», который произвёл неизгладимое впечатление на участников и считается отправной точкой движения DevOps. Вдохновлённый этим докладом, Патрик Дебуа организовал первую специализированную конференцию DevOpsDays в городе Гент, Бельгия, в том же 2009 году. Джин Ким, присутствовавший на докладе, позже выпустил книгу «Проект Феникс» (2013) и основал компанию IT Revolution, которая занимается популяризацией темы и организует мероприятия «DevOps Enterprise Summit».

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

Рейтинг: 61

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

## [Какова роль обучения персонала в применении DevOps?](https://cleverics.ru/digital/kb-qa/kakova-rol-obucheniya-personala-v-primenenii-devops/)

Необходимо не просто обучить, а именно постоянно обучать персонал, а также создать условия и механизмы обмена знаниями и опытом. Эти механизмы следует тестировать: работающие — поощрять, неработающие — убирать и заменять новыми. Нельзя допускать перекосов в сторону исключительно технических аспектов (например, только построение конвейера развёртывания). Следует уделять соизмеримое внимание идеологическим аспектам DevOps, созданию новой культуры организации и выполнения работ в ИТ.

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

Рейтинг: 61

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

## [Как системная структура объясняет проблему противоречия целей подсистем общим целям системы?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-protivorechiya-tseley-podsistem-obshchim-tselyam-sistem/)

Системная структура объясняет проблему противоречия целей подсистем общим целям системы через механизм локальной оптимизации, который приводит к субоптимальному поведению системы в целом.  Пример из управления ИТ: группы поддержки заинтересованы в соблюдении своих нормативов на обработку назначенных им заданий (локальные цели), даже если это не обеспечивает выполнение общего норматива на время обработки исходного запроса пользователя (общая цель системы).  Механизм: 1. Каждая группа поддержки имеет свои KPI — например, время обработки назначенного инцидента, количество закрытых заявок. 2. Сотрудники оптимизируют свою работу под эти KPI — например, быстро закрывают простые инциденты, чтобы выполнить норматив по количеству. 3. Однако сложные инциденты, которые требуют больше времени и могут нарушить норматив, откладываются или эскалируются. 4. В результате общий норматив на время обработки запроса пользователя (Lead Time) не выполняется, несмотря на то что каждая подсистема формально выполняет свои нормативы.  Системная структура «конвейера» показывает, что Lead Time складывается из Queue Time и Processing Time на каждом этапе. Если каждая группа оптимизирует только свой Processing Time, но не учитывает влияние на Queue Time для следующих этапов, общий Lead Time может расти.  Это пример ошибки №3 по Форрестеру: цели подсистем противоречат общим целям системы. Решение — выстраивать KPI, которые отражают вклад каждой подсистемы в общий результат (например, общий Lead Time), а не только локальные показатели.

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

Рейтинг: 61

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

## [Как системная структура объясняет проблему низкой доли изменений, документированных в соответствии с требованиями, и её влияние на управление проблемами?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-dokumentirovannykh-v-sootvetstvii/)

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

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

Рейтинг: 60

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

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

Системная структура объясняет проблему низкой доли обращений, решённых с применением базы знаний (PSR — Problem Solution Rate), и её влияние на затраты через взаимосвязь «конвейера» и «лаборатории».  Механизм: 1. PSR характеризует, какая доля обращений решается с применением базы знаний. 2. Низкая доля означает, что сотрудники не используют базу знаний при решении обращений. 3. Это приводит к тому, что:    - Каждое обращение решается «с нуля» — сотрудники тратят время на диагностику и поиск решения.    - Увеличивается Processing Time — решение без базы знаний занимает больше времени.    - Увеличиваются затраты — больше ресурсов тратится на обработку каждого обращения.    - Снижается продуктивность — сотрудники не используют накопленный опыт.    - Увеличивается нагрузка на вторую и третью линии — первая линия не имеет готовых решений. 4. Низкая доля, в свою очередь:    - Увеличивает Cost per ticket.    - Увеличивает MTRS.    - Снижает удовлетворённость пользователей.  Факторы, влияющие на низкую долю:  1. **Недостаточное содержание базы знаний.** Мало статей, они устарели или не покрывают типичные ситуации. 2. **Низкое качество статей.** Статьи написаны непонятно или не соответствуют реальным сценариям. 3. **Неудобный поиск.** Сотрудники не могут быстро найти нужную статью. 4. **Недостаточная интеграция.** База знаний не интегрирована с системой обработки инцидентов. 5. **Отсутствие стимулов.** Сотрудники не мотивированы использовать базу знаний.  Системная структура показывает, что PSR — это индикатор эффективности «лаборатории» и её интеграции с «конвейером». Улучшение PSR требует развития базы знаний, улучшения инструментов поиска и интеграции, обучения и мотивации сотрудников. Высокий PSR напрямую снижает затраты на управление инцидентами.

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

Рейтинг: 60

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

## [Как системная структура объясняет проблему низкой своевременности реализации изменений и её влияние на риски?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-svoevremennosti-realizatsii-izmeneniy-i-ee-vliya/)

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

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

Рейтинг: 60

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

## [Можно ли применять DevOps для резкого снижения накопленного технологического долга?](https://cleverics.ru/digital/kb-qa/mozhno-li-primenyat-devops-dlya-rezkogo-snizheniya-nakoplennogo-tekhnologicheskogo-dolga/)

Нет, увлечение DevOps в сложных ситуациях, скорее всего, не принесёт большой пользы и совершенно определённо не даст быстрых побед. Напротив, организационные и технологические перемены могут привести к хаосу и потере остатков управляемости. Исправлять запущенные проблемы следует аккуратно, вдумчиво и рассудительно, не надеясь на DevOps как на лекарство от хронических заболеваний.

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

Рейтинг: 55

Теги: DevOps, CI/CD

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

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

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

Рейтинг: 50

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

## [Как системная структура объясняет проблему низкой доли изменений, реализованных с первой попытки, и её влияние на удовлетворённость пользователей?](https://cleverics.ru/digital/kb-qa/kak-sistemnaya-struktura-obyasnyaet-problemu-nizkoy-doli-izmeneniy-realizovannykh-s-pervoy-popytki-i/)

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

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

Рейтинг: 50

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