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

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

## [Для чего используется статус 'Ожидание' в системах управления инцидентами и заданиями?](https://cleverics.ru/digital/kb-qa/dlya-chego-ispolzuetsya-status-ozhidanie-v-sistemakh-upravleniya-intsidentami-i-zadaniyami/)

Статус 'Ожидание' используется для откладывания обрабатываемого объекта (инцидента, обращения, задания) в сторону, когда его обработка невозможна по объективным причинам. Основные случаи применения: ожидание возвращения пользователя из отпуска, ожидание поставки техники, получение ответа от другой службы или специалиста. Цель статуса - структурировать рабочий процесс, отделяя задания, требующие активных действий, от тех, которые временно невыполнимы без внешнего воздействия.

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

Рейтинг: 1320

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

## [Что представляет собой ограничение работ в процессе (WIP) в системе Kanban и для чего оно нужно?](https://cleverics.ru/digital/kb-qa/chto-predstavlyaet-soboy-ogranichenie-rabot-v-protsesse-wip-v-sisteme-kanban-i-dlya-chego-ono-nuzhno/)

Ограничение работ в процессе (WIP) в системе Kanban — это установленный верхний предел количества задач, которые могут одновременно находиться на определённом этапе процесса. Это ограничение необходимо для предотвращения перегрузки рабочих этапов, снижения времени ожидания и повышения скорости прохождения задач через весь процесс. В DevOps-практиках WIP также позволяет зарезервировать ресурсы для неплановых задач, таких как решение инцидентов. В канбане можно устанавливать как общие ограничения для всего процесса, так и отдельные ограничения для разных категорий задач, что делает систему более гибкой и устойчивой к возникающим проблемам.

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

Рейтинг: 1270

Теги: DevOps, CI/CD, Канбан, WIP-лимиты, управление инцидентами

## [Чем отличается System Lead Time от Customer Lead Time в гибкой разработке?](https://cleverics.ru/digital/kb-qa/chem-otlichaetsya-system-lead-time-ot-customer-lead-time-v-gibkoy-razrabotke/)

System Lead Time (время в системе) считается от точки принятия обязательств (красный флажок) до момента поставки результата заказчику, тогда как Customer Lead Time считается от момента принятия решения о реализации задачи (зеленый флажок) до момента поставки. System Lead Time является одной из ключевых характеристик эффективности разработки, по которой можно с высокой вероятностью предсказывать сроки выпуска для новых задач, выявлять риски и классифицировать задачи.

Автор: Павел Капусткин

Рейтинг: 1256

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

## [В каких областях бизнеса применяются SLA, помимо ИТ-сферы?](https://cleverics.ru/digital/kb-qa/v-kakikh-oblastyakh-biznesa-primenyayutsya-sla-pomimo-it-sfery/)

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

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

Рейтинг: 1239

Теги: DevOps, CI/CD, SLA, бизнес, ценность, бизнес-заказчик, управление уровнем услуг, SLM

## [Что такое Customer Lead Time и от чего он зависит?](https://cleverics.ru/digital/kb-qa/chto-takoe-customer-lead-time-i-ot-chego-on-zavisit/)

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

Автор: Павел Капусткин

Рейтинг: 1234

Теги: DevOps, CI/CD, Lean, бережливое производство, бизнес, ценность, бизнес-заказчик

## [Когда необходимость в CI/CD может быть не столь очевидной для команды?](https://cleverics.ru/digital/kb-qa/kogda-neobkhodimost-v-ci-cd-mozhet-byt-ne-stol-ochevidnoy-dlya-komandy/)

Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.

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

Рейтинг: 1227

Теги: Agile и гибкие методы разработки ПО, DevOps, CI/CD, командная работа, поддержка пользователей, Service Desk, Help Desk, управление конфигурациями, CMDB, управление продуктами, продуктовый подход, управление релизами

## [Какие аспекты включает документ об архитектурных и технологических стандартах для разработки новых информационных решений?](https://cleverics.ru/digital/kb-qa/kakie-aspekty-vklyuchaet-dokument-ob-arkhitekturnykh-i-tekhnologicheskikh-standartakh-dlya-razrabotk/)

Документ об архитектурных и технологических стандартах для разработки новых информационных решений включает следующие аспекты: определение допустимых языков программирования и сред разработки, утверждённых платформ и систем управления базами данных (СУБД), стандарты и протоколы взаимодействия компонентов системы, механизмы развёртывания и настройки локаторов прикладных серверов и middleware, требования к интерфейсу пользователя и администратора системы, стандарты по резервному копированию и восстановлению данных, требования к системам мониторинга и журналирования событий, правила форматирования и хранения логов, возможные ограничения на периоды стабильности системы (freeze периоды), требования к безопасности и аудиту. Такой документ обеспечивает техническую согласованность разрабатываемых решений с существующей инфраструктурой и позволяет избежать использования подходов и технологий, которые создают сложности при эксплуатации или сопровождении системы.

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

Рейтинг: 1226

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

## [Что включает в себя эффективный план отката при развертывании ИТ-релизов?](https://cleverics.ru/digital/kb-qa/chto-vklyuchaet-v-sebya-effektivnyy-plan-otkata-pri-razvertyvanii-it-relizov/)

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

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

Рейтинг: 1198

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

## [Почему отсутствие культуры автоматизированного тестирования препятствует внедрению CI/CD?](https://cleverics.ru/digital/kb-qa/pochemu-otsutstvie-kultury-avtomatizirovannogo-testirovaniya-prepyatstvuet-vnedreniyu-ci-cd/)

Отсутствие культуры автоматизированного тестирования серьёзно препятствует внедрению CI/CD, потому что конвейер развёртывания требует надёжной и быстрой проверки изменений перед их выпуском в продакшен. Без достаточного количества актуальных автотестов невозможно гарантировать, что каждое изменение кода не нарушает существующую функциональность. Если команда до сих пор ведет дебаты о том, 'стоит ли', 'нужно ли' или 'можем ли мы себе позволить писать автотесты', это указывает на фундаментальную неготовность к CI/CD. Автотесты являются неотъемлемой частью конвейера, они должны запускаться автоматически на каждом этапе и блокировать дальнейшее продвижение изменений при обнаружении ошибок. Отказ от постоянного обновления автотестов приведет к тому, что со временем они перестанут быть актуальными, будут «краснеть» и вынуждать команду вручную обходить проблемы, что полностью разрушает идею непрерывной интеграции и развертывания.

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

Рейтинг: 1197

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

## [Какие преимущества дает применение картирования потока создания ценности в ИТ-разработке?](https://cleverics.ru/digital/kb-qa/kakie-preimushchestva-daet-primenenie-kartirovaniya-potoka-sozdaniya-tsennosti-v-it-razrabotke/)

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

Автор: Светлана Сапегина

Рейтинг: 1191

Теги: DevOps, CI/CD, бизнес, ценность, бизнес-заказчик, Канбан, WIP-лимиты, командная работа, общие вопросы менеджмента, постоянное улучшение, совершенствование, CSI, PDCA, поток создания ценности (Value Stream), эффективность, оптимизация