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

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

## [Какие существуют подходы к устранению дефектов в разработке ПО?](https://cleverics.ru/digital/kb-qa/kakie-sushchestvuyut-podkhody-k-ustraneniyu-defektov-v-razrabotke-po/)

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

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

Рейтинг: 877

Теги: Agile и гибкие методы разработки ПО, бизнес, ценность, бизнес-заказчик, разработка ПО

## [Какие есть примеры критериев недоступности для ресурсных ИТ-услуг?](https://cleverics.ru/digital/kb-qa/kakie-est-primery-kriteriev-nedostupnosti-dlya-resursnykh-it-uslug/)

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

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

Рейтинг: 877

Теги: Agile и гибкие методы разработки ПО, разработка ПО, управление доступностью

## [Как формируются модели стандартных изменений в ИТ-организациях?](https://cleverics.ru/digital/kb-qa/kak-formiruyutsya-modeli-standartnykh-izmeneniy-v-it-organizatsiyakh/)

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

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

Рейтинг: 877

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

## [Как определение завершения по DevOps влияет на позицию конечного пользователя в процессе разработки?](https://cleverics.ru/digital/kb-qa/kak-opredelenie-zaversheniya-po-devops-vliyaet-na-pozitsiyu-konechnogo-polzovatelya-v-protsesse-razr/)

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

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

Рейтинг: 877

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

## [Почему важно определять не только технические, но и бизнес-требования к резервному копированию?](https://cleverics.ru/digital/kb-qa/pochemu-vazhno-opredelyat-ne-tolko-tekhnicheskie-no-i-biznes-trebovaniya-k-rezervnomu-kopirovaniyu/)

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

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

Рейтинг: 877

Теги: SLA, бизнес, ценность, бизнес-заказчик, общие вопросы менеджмента, управление инцидентами, управление процессами, ИТ-процессы, управление рисками, управление уровнем услуг, SLM

## [Какие ошибки могут возникнуть при измерении доступности без четких критериев?](https://cleverics.ru/digital/kb-qa/kakie-oshibki-mogut-vozniknut-pri-izmerenii-dostupnosti-bez-chetkikh-kriteriev/)

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

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

Рейтинг: 877

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

## [Почему ITIL рекомендует закрывать инциденты на первой линии поддержки?](https://cleverics.ru/digital/kb-qa/pochemu-itil-rekomenduet-zakryvat-intsidenty-na-pervoy-linii-podderzhki/)

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

Автор: Дмитрий Подольский

Рейтинг: 877

Теги: ITIL, мотивация персонала, стимулирование, поддержка пользователей, Service Desk, Help Desk, управление инцидентами

## [Какова роль управления уровнем услуг (SLM) при согласовании срочных изменений, требующих внеплановых простоев?](https://cleverics.ru/digital/kb-qa/kakova-rol-upravleniya-urovnem-uslug-slm-pri-soglasovanii-srochnykh-izmeneniy-trebuyushchikh-vneplan/)

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

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

Рейтинг: 877

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

## [Как изменяется приоритет проблемы в процессе её расследования?](https://cleverics.ru/digital/kb-qa/kak-izmenyaetsya-prioritet-problemy-v-protsesse-ee-rassledovaniya/)

Приоритет проблемы может изменяться в течение времени, если к ней привязываются новые инциденты. Факт привязки новых инцидентов увеличивает суммарный вес проблемы, что может повысить её приоритет. Это требует постоянного пересмотра приоритетов проблем в ходе их расследования и устранения.

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

Рейтинг: 877

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

## [Почему сотрудники часто негативно относятся к введению метрик в организации?](https://cleverics.ru/digital/kb-qa/pochemu-sotrudniki-chasto-negativno-otnosyatsya-k-vvedeniyu-metrik-v-organizatsii/)

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

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

Рейтинг: 876

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