Continuous Deployment и Continuous Delivery отличаются уровнем автоматизации доставки изменений в продуктивную среду. Continuous Delivery означает, что изменения готовы к релизу в любой момент (вся цепочка тестирования и подготовки автоматизирована), но непосредственный выпуск в производство требует ручного подтверждения. В то время как Continuous Deployment полностью автоматизирует процесс, так что каждое изменение, прошедшее все этапы конвейера, автоматически разворачивается в продуктивную среду без человеческого вмешательства. Continuous Deployment предпочтительнее, потому что устраняет 'волшебный рубильник' — ситуацию, когда решение о релизе принимает отдельный человек, создавая бутылочное горлышко и возможные ошибки. Это приводит к более стабильному и предсказуемому процессу, где нет искушения временно отключать какие-либо части конвейера (например, автотесты) из-за срочных заказов или дедлайнов. Continuous Deployment обеспечивает максимальную скорость и надежность доставки новых функций конечным пользователям.

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

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

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

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

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

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

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

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

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