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

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

## [Как определяется необходимость увеличения IT-мощностей при росте бизнеса?](https://cleverics.ru/digital/kb-qa/kak-opredelyaetsya-neobkhodimost-uvelicheniya-it-moshchnostey-pri-roste-biznesa/)

Необходимость увеличения IT-мощностей при росте бизнеса определяется на основе анализа бизнес-плана и прогнозов. Например, если компания планирует увеличение продаж на 45% и, соответственно, набор персонала, то IT-инфраструктура должна обеспечить рост доступности и производительности систем пропорционально увеличению количества пользователей. При этом не обязательно требуются серьёзные изменения архитектуры — достаточно заложить увеличение мощностей существующих систем. Анализ включает оценку текущего состояния инфраструктуры (рабочие станции, серверы, телекоммуникации, безопасность) и определение точек роста.

Автор: Андрей Носов

Рейтинг: 135

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

## [Какие ключевые отличия существуют между культурой обычных корпораций и культурой стартапов?](https://cleverics.ru/digital/kb-qa/kakie-klyuchevye-otlichiya-sushchestvuyut-mezhdu-kulturoy-obychnykh-korporatsiy-i-kulturoy-startapov/)

Существует шесть ключевых отличий. Стиль управления: в корпорациях — командный и авторитарный, в стартапах — автономный. Склонность к переменам: корпорации консервативны, стартапы ориентированы на эксперименты. Организационная структура: в корпорациях — функционально-иерархическая, в стартапах — сетевая. Акцент результата: корпорации проектно-ориентированы, стартапы ориентированы на продукт. Модель работы: в корпорациях — водопадная, в стартапах — гибкая и итеративная. Системная архитектура: в корпорациях — монолитная и тщательно спроектированная, в стартапах — слабо связанная и микросервисная. Предпочтения в технологиях: корпорации выбирают патентованные и проприетарные решения, стартапы — открытый исходный код.

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

Рейтинг: 132

Теги: архитектура ИТ, TOGAF и IT4IT, командная работа, управление продуктами, продуктовый подход

## [Как организовать работу внутренних команд в рамках SLM?](https://cleverics.ru/digital/kb-qa/kak-organizovat-rabotu-vnutrennikh-komand-v-ramkakh-slm/)

Работа внутренних команд регулируется через OLA (Operational Level Agreement) или внутренние нормативы. Необходимо: 1) определить правила работы подразделений (приоритеты, сроки, эскалации); 2) провести диалог между руководителями технических и функциональных подразделений; 3) зафиксировать нормативы (например, время решения инцидентов для разных приоритетов); 4) учесть особенности работы с критичными услугами; 5) обеспечить, чтобы нормативы внутренних команд обеспечивали выполнение SLA с потребителем. OLA — это не всегда полноценные соглашения, а скорее нормативы, определяемые посредством диалога.

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

Рейтинг: 126

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

## [Какие архитектурные подходы предшествовали микросервисной архитектуре?](https://cleverics.ru/digital/kb-qa/kakie-arkhitekturnye-podkhody-predshestvovali-mikroservisnoy-arkhitekture/)

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

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

Рейтинг: 119

Теги: DevOps, CI/CD, архитектура ИТ, TOGAF и IT4IT

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

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

Рейтинг: 115

Теги: DevOps, CI/CD, Lean, бережливое производство, архитектура ИТ, TOGAF и IT4IT, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, поддержка пользователей, 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. **Внеочередная работа.** Экстренные изменения отвлекают ресурсы.  Системная структура показывает, что своевременность — это не просто «операционная метрика», а фактор, напрямую влияющий на риски. Улучшение своевременности требует комплексного подхода: управление спросом, увеличение ресурсов, повышение продуктивности, улучшение качества, контроль внеочередной работы.

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

Рейтинг: 100

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

## [Какие инструменты и данные необходимы для расчёта потребности в дисковых массивах?](https://cleverics.ru/digital/kb-qa/kakie-instrumenty-i-dannye-neobkhodimy-dlya-rascheta-potrebnosti-v-diskovykh-massivakh/)

Для расчёта потребности в дисковых массивах необходимы: информация о требуемом объёме хранения данных (из заказа — в гигабайтах), разделение на типы хранилищ (основное хранение рабочих данных, резервное хранение), характеристики доступных типов дисковых массивов (скорость, надёжность, стоимость). Типовая архитектура определяет, какой тип массива используется для каждого типа хранения: например, быстрые SSD-массивы для рабочих данных и более медленные HDD-массивы для резервных копий. Ресурсные нормативы могут учитывать коэффициент репликации, резервирования (RAID), выделение пулов. Расчёт выполняется: объём данных × коэффициент запаса / полезная ёмкость массива = количество массивов. Стоимость включает амортизацию массивов, договоры сопровождения, лицензии на программное обеспечение систем хранения. Все эти параметры фиксируются в типовой архитектуре и ресурсных нормативах.

Автор: Павел Дёмин

Рейтинг: 87

Теги: архитектура ИТ, TOGAF и IT4IT, управление ИТ-активами, ITAM, SAM