Да, метрика может быть полезной, даже если её измерение неидеально, но важно понимать контекст её применения. Например, оценочные значения могут быть полезны внутри одной команды для саморефлексии и поиска точек роста, но они не подходят для сравнения между разными командами. Ключевое условие — метрика должна оставаться релевантной для конкретной задачи, даже если точность её измерения ограничена.

Чтобы проверить систему на наличие ненужных показателей, необходимо убедиться, что каждый показатель напрямую связан с конкретной целью и используется для принятия решений. Если на вопрос «Зачем это измеряется?» нет чёткого ответа, такой показатель, вероятно, лишний. Также важно проверять, влияет ли показатель на поведение сотрудников в нужную сторону и можно ли его достаточно точно измерить без риска фальсификации.

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

Шестой принцип DevOps DASA предполагает широкий взгляд на автоматизацию, включая не только процессы разработки программного обеспечения, но и весь инфраструктурный ландшафт, что реализуется через подход 'инфраструктура как код' (Infrastructure as Code). Это означает, что конфигурация и управление инфраструктурой должны быть определены через код и версионироваться, как и любое другое программное обеспечение. Такой подход позволяет автоматически воссоздавать инфраструктуру, обеспечивать её согласованность в разных средах, быстрее разворачивать новые экземпляры и легко откатываться к предыдущим версиям при необходимости. Инфраструктура как код также интегрируется в процессы непрерывной поставки, что позволяет тестировать изменения инфраструктуры так же, как и изменения приложения, повышая общую надёжность и стабильность системы.

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

В тексте упоминаются две альтернативные модели управления доступом: DAC (Discretionary Access Control, избирательное управление доступом) и MAC (Mandatory Access Control, мандатное управление доступом). RBAC во многих случаях заменяет эти модели из-за своей большей гибкости, прозрачности и соответствия бизнес-процессам. В отличие от DAC, где владелец ресурса сам определяет права доступа, RBAC обеспечивает централизованное управление, что снижает вероятность ошибок. По сравнению с MAC, который часто слишком жесткий и сложный для коммерческих организаций, RBAC предлагает более практичный и масштабируемый подход, особенно для организаций с большим количеством сотрудников и сложной структурой доступа.

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

Термин «аутсорсинг бизнес-процесса» может быть неточным, так как модель сорсинга изначально подразумевает привлечение ресурсов, а не организации процессов. Процесс как форма управления ресурсами и деятельностью должен существовать внутри организации. Предоставляться извне могут непосредственные функции и ресурсы, но не сам процесс управления. Когда поставщик берет на себя управление, заказчик переходит в режим governance (руководства), где управление ресурсами уже не требуется. Следовательно, речь идет не об аутсорсинге процесса, а об аутсорсинге функций внутри этого процесса.

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

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