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

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

## [Как DevOps-команды обрабатывают корпоративные стандарты при автономном выборе инструментов?](https://cleverics.ru/digital/kb-qa/kak-devops-komandy-obrabatyvayut-korporativnye-standarty-pri-avtonomnom-vybore-instrumentov/)

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

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

Рейтинг: 79

Теги: DevOps, CI/CD, ISO 20000, архитектура ИТ, TOGAF и IT4IT, аудит, безопасность, командная работа

## [Какие проблемы возникают, когда вспомогательные подразделения осознают только надзорную, но не сервисную функцию?](https://cleverics.ru/digital/kb-qa/kakie-problemy-voznikayut-kogda-vspomogatelnye-podrazdeleniya-osoznayut-tolko-nadzornuyu-no-ne-servi/)

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

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

Рейтинг: 74

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

## [Зачем нужны публичные страницы статуса систем и какие преимущества они дают?](https://cleverics.ru/digital/kb-qa/zachem-nuzhny-publichnye-stranitsy-statusa-sistem-i-kakie-preimushchestva-oni-dayut/)

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

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

Рейтинг: 73

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

## [Как системная структура объясняет проблему низкой своевременности реализации изменений и её влияние на риски?](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, управление рисками, эффективность, оптимизация

## [Как сеть отелей Omenahotels.com иллюстрирует особенности услуг первого типа?](https://cleverics.ru/digital/kb-qa/kak-set-oteley-omenahotels-com-illyustriruet-osobennosti-uslug-pervogo-tipa/)

Сеть отелей Omenahotels.com иллюстрирует услуги первого типа тем, что деятельность сотрудников поставщика не видна заказчику вовсе. Бронирование и оплата выполняются на сайте, регистрация и выезд происходят без участия персонала, вместо ключей используются коды, высылаемые по электронной почте и SMS. Заказчик оценивает только ресурс — номер с определённым набором удобств, вместимостью и уровнем безопасности. Именно поэтому поставщику важно организовать максимально надёжную услугу, обеспечить уверенность в том, что всё будет работать «само» и правильно, поскольку невозможно скомпенсировать снижение качества дополнительными улыбками или работой службы поддержки.

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

Рейтинг: 58

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