В российских стандартах (ГОСТ 27.002-89, ГОСТ Р 53480-2009) применяется термин «готовность», заимствованный из теории надежности и ориентированный на технические характеристики. Международные стандарты ITIL и ISO/IEC 20000 используют термин «доступность» (availability), который в контексте ИТ-управления включает не только техническую работоспособность, но и организационные аспекты предоставления услуги. Это различие сохраняется в профессиональной литературе и требует адаптации терминологии при локализации документов.

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

Для управления программными активами рекомендуется использовать стандарт ISO 19770, который предоставляет фреймворк для эффективного управления активами и уделяет особое внимание соответствию лицензионным соглашениям. Также полезна библиотека IBPL, содержащая лучшие практики управления ИТ-активами.

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

Новый подход стимулирует не только быстрое устранение инцидентов, но и профилактику их возникновения. Поскольку инциденты, влияющие на бизнес (te > Tmin), снижают общий рейтинг даже при соблюдении Tmax, поставщикам услуг становится невыгодно допускать сбои. Это приводит к повышению общей надежности ИТ-инфраструктуры и снижению количества инцидентов, что напрямую улучшает доступность сервисов и минимизирует риски для бизнес-операций.

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

Курс 'Flow Metrics: управление потоковым производством на основе данных' — это дистанционный программный курс для самостоятельного изучения, который занимает около 8-10 часов, хотя доступ к материалам предоставляется на полгода. В курсе содержится более 70 паттернов для 7 ключевых метрик потока. Обучение ориентировано на практическое применение, включая работу с графиками и диаграммами. Курс учит не столько находить готовые ответы в данных, сколько формулировать правильные вопросы, необходимые для анализа потока создания ценности.

Основные недостатки MAC-модели: 1) Низкая гибкость — все ресурсы одного уровня допуска (например, 'секретно') доступны всем, у кого есть мандат на этот уровень, что не учитывает индивидуальные обязанности пользователей. 2) Сложность управления при увеличении количества классов секретности: если добавить новый гриф (например, 'для внутреннего пользования'), система становится громоздкой и менее наглядной. 3) Необходимость жёсткой классификации всех данных, что требует постоянного мониторинга и обновления грифов при изменении важности информации. 4) Несоответствие бизнес-логике — модель подходит для военных и государственных структур, но слабо применима в коммерческих организациях, где доступ должен учитывать функции сотрудников, а не статус секретности.

Core Chronic Conflict (CCC) в контексте DevOps - это нисходящая спираль, обусловленная конфликтом интересов между разработкой и эксплуатацией системы, которая приводит к замедлению времени вывода решений в продуктив, снижению качества услуг, увеличению количества и продолжительности сбоев, накапливанию проблем и перманентному тушению пожаров. Этот конфликт является фундаментальной проблемой в ИТ, возникающей из-за противоречия между необходимостью быстро внедрять изменения и поддерживать стабильность и надежность системы. CCC проявляется в виде нескольких актов, где каждая попытка решить проблему приводит к усугублению ситуации и усилению негативных циклов, в конечном итоге приводя к кризису в работе ИТ-организации.

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