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

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

## [Как DevOps-команды управляют своими инструментами и технологиями?](https://cleverics.ru/digital/kb-qa/kak-devops-komandy-upravlyayut-svoimi-instrumentami-i-tekhnologiyami/)

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

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

Рейтинг: 88

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

## [Как 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/chto-predstavlyayut-soboy-metriki-sootvetstviya-protsessa-normativnoy-dokumentatsii/)

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

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

Рейтинг: 68

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

## [Как IDM-система обрабатывает ситуацию, когда необходимо срочно предоставить доступ в обход стандартного процесса согласования?](https://cleverics.ru/digital/kb-qa/kak-idm-sistema-obrabatyvaet-situatsiyu-kogda-neobkhodimo-srochno-predostavit-dostup-v-obkhod-standa/)

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

Автор: Денис Денисов, Александр Омельченко

Рейтинг: 65

Теги: аудит, управление доступом, IDM, ролевые модели, RBAC, ABAC

## [Как выявляются невостребованные доступы при аудите?](https://cleverics.ru/digital/kb-qa/kak-vyyavlyayutsya-nevostrebovannye-dostupy-pri-audite/)

Для выявления невостребованных доступов используются различные методы. Можно анализировать, когда последний раз сотрудник обращался к ресурсу. Например, администраторы файловых серверов используют радиочастотное ПО, которое показывает, кто и когда обращался к определенной сетевой папке. Если с определенной даты (например, с 2013 года) никто не обращался к ресурсу, это потенциальный кандидат на удаление, архивирование или изъятие из общего доступа. Данные выгружаются, статистика обращения направляется владельцу информации, который принимает окончательное решение — закрывать доступ или оставлять. Также при аудите можно выявлять доступы, выданные давно и не отозванные, что позволяет обнаружить накопленные ненужные права.

Автор: Денис Денисов

Рейтинг: 58

Теги: аудит, управление доступом, IDM, ролевые модели, RBAC, ABAC, управление запросами на обслуживание