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

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

## [Почему в интеллектуальной работе проявления социальной лени могут быть менее опасны, чем в физическом труде?](https://cleverics.ru/digital/kb-qa/pochemu-v-intellektualnoy-rabote-proyavleniya-sotsialnoy-leni-mogut-byt-menee-opasny-chem-v-fiziches/)

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

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

Рейтинг: 1220

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

## [В чем отличие подхода к измерению эффективности в ITIL v3 и IT4IT?](https://cleverics.ru/digital/kb-qa/v-chem-otlichie-podkhoda-k-izmereniyu-effektivnosti-v-itil-v3-i-it4it/)

Главное отличие в подходе к измерению эффективности между ITIL v3 и IT4IT заключается в объектах измерения. В ITIL v3 критические факторы успеха (CSF) и ключевые показатели эффективности (KPI) определены для каждого из 26 процессов, что делает акцент на измерении отдельных процессов. В IT4IT же CSF и KPI относятся к целым Value Stream'ам (потокам создания ценности), а не к отдельным функциональным компонентам внутри этих потоков. Это означает, что IT4IT имеет более целостный взгляд на измерение эффективности, фокусируясь на том, как весь поток создает ценность для бизнеса, тогда как ITIL v3 предоставляет более детализированные измерения по отдельным процессам. Хотя и в ITIL v3 есть упоминания о ключевых факторах успеха для фаз жизненного цикла, в IT4IT этот аспект проработан более системно и детально для каждого Value Stream.

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

Рейтинг: 1217

Теги: ITIL, архитектура ИТ, TOGAF и IT4IT, бизнес, ценность, бизнес-заказчик, измерение и оценка ИТ, метрики, KPI, отчётность, дашборды, Канбан, WIP-лимиты, поток создания ценности (Value Stream), эффективность, оптимизация

## [Что такое эффект социальной лени и как он проявляется в интеллектуальной деятельности?](https://cleverics.ru/digital/kb-qa/chto-takoe-effekt-sotsialnoy-leni-i-kak-on-proyavlyaetsya-v-intellektualnoy-deyatelnosti/)

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

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

Рейтинг: 1216

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

## [Что такое технический долг и как он формируется в процессе разработки?](https://cleverics.ru/digital/kb-qa/chto-takoe-tekhnicheskiy-dolg-i-kak-on-formiruetsya-v-protsesse-razrabotki/)

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

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

Рейтинг: 1211

Теги: архитектура ИТ, TOGAF и IT4IT, командная работа, трансформация, ускорение, Time-to-Market, управление продуктами, продуктовый подход

## [Какие риски связаны с переходом на микросервисную архитектуру без должного планирования?](https://cleverics.ru/digital/kb-qa/kakie-riski-svyazany-s-perekhodom-na-mikroservisnuyu-arkhitekturu-bez-dolzhnogo-planirovaniya/)

Риски перехода на микросервисную архитектуру без должного планирования включают превращение системы в неуправляемый «войлочный шар», когда компоненты слабоорганизованно взаимодействуют друг с другом. Это приводит к значительному росту сложности в диагностике проблем и выявлении причин инцидентов. Система может оказаться в сложном (Complex) домене, где управление становится дорогостоящим и менее эффективным. Отсутствие надлежащего мониторинга приведет к задержкам в обнаружении проблем и увеличению времени восстановления после сбоев. Без правильного управления конфигурациями и зависимостями изменения в системе станут рискованными, требующими сложного координационного планирования. Все это может сделать микросервисную архитектуру менее выгодной по сравнению с монолитным подходом.

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

Рейтинг: 1208

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

## [Как микросервисная архитектура влияет на диагностику проблем и инцидентов?](https://cleverics.ru/digital/kb-qa/kak-mikroservisnaya-arkhitektura-vliyaet-na-diagnostiku-problem-i-intsidentov/)

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

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

Рейтинг: 1202

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

## [Почему многие компании, прошедшие Agile-трансформацию, не получают ожидаемых результатов по ускорению разработки?](https://cleverics.ru/digital/kb-qa/pochemu-mnogie-kompanii-proshedshie-agile-transformatsiyu-ne-poluchayut-ozhidaemykh-rezultatov-po-us/)

Многие компании не достигают ожидаемых результатов по ускорению разработки, потому что внедряют Agile формально, без глубокого понимания и реализации всех необходимых изменений. Как отмечается, современная разработка часто сводится к 'половине Скрама сделанной плохо и использованию Jira', не затрагивая фундаментальных аспектов организации ресурсов, архитектуры, управления входящими задачами и организации производства. Для реального кратного ускорения необходим системный подход к преобразованиям, а не частичное внедрение отдельных практик без работы над основными препятствиями.

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

Рейтинг: 1190

Теги: Agile и гибкие методы разработки ПО, архитектура ИТ, TOGAF и IT4IT, трансформация, ускорение, Time-to-Market, управление релизами

## [Какие элементы должны присутствовать в технической документации для поддержки внедренных решений?](https://cleverics.ru/digital/kb-qa/kakie-elementy-dolzhny-prisutstvovat-v-tekhnicheskoy-dokumentatsii-dlya-podderzhki-vnedrennykh-reshe/)

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

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

Рейтинг: 1186

Теги: архитектура ИТ, TOGAF и IT4IT, поддержка пользователей, Service Desk, Help Desk, управление проблемами

## [Какие требования предъявляются к менеджеру по управлению проблемами?](https://cleverics.ru/digital/kb-qa/kakie-trebovaniya-predyavlyayutsya-k-menedzheru-po-upravleniyu-problemami/)

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

Автор: Игорь Фадеев

Рейтинг: 1185

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

## [Входит ли Ops в круг деятельностей, которые можно привлекать у внешних специалистов, не занятых в развитии продукта на полную ставку?](https://cleverics.ru/digital/kb-qa/vkhodit-li-ops-v-krug-deyatelnostey-kotorye-mozhno-privlekat-u-vneshnikh-spetsialistov-ne-zanyatykh/)

Да, Ops входит в перечень технических направлений, которые может быть целесообразно привлекать со стороны, но с определенными нюансами. В контексте организации работы команды и делегирования ответственности, Ops (операционная деятельность, эксплуатация) может быть передана внешним исполнителям при условии наличия четкой архитектуры инфраструктуры, стандартизированных процессов и четких SLA. Однако стоит учитывать, что уровень ответственности за эксплуатацию напрямую зависит от критичности этих операций для продукта. Например, если продукт требует настройки и постоянного мониторинга кастомизированного middleware, то привлечение внешних экспертов может быть частичным и не подходит для критически важных систем. В идеале, команда должна сохранить контроль над конфигурированием и автоматизацией middleware, тогда как физическое развертывание и управление базовыми ресурсами (IaaS) могут быть переданы внешней стороне.

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

Рейтинг: 1171

Теги: DevOps, CI/CD, SLA, архитектура ИТ, TOGAF и IT4IT, командная работа, мониторинг, общие вопросы менеджмента, управление конфигурациями, CMDB, управление продуктами, продуктовый подход, управление релизами, управление уровнем услуг, SLM, эффективность, оптимизация