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

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

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

Высокий спрос и качество сервиса в российских компаниях связаны обратной зависимостью: чем выше спрос по сравнению с предложением, тем ниже качество обслуживания. Предприниматели не тратят усилия на улучшение сервиса, так как клиенты вынуждены пользоваться услугами даже при их посредственном качестве. Например, при построении множества торговых центров спрос все равно превышает предложение, поэтому компании не чувствуют давления на повышение стандартов. Принцип "карась жирный идёт" отражает установку бизнеса — если клиенты все равно приходят, улучшать сервис не требуется.

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

Реактивная часть управления доступностью относится к учету и регистрации фактов и периодов недоступности услуги. Она включает мониторинг и измерение доступности через фиксацию инцидентов недоступности. Этот процесс позволяет отслеживать, когда и как долго услуга была недоступна, а также выявлять причины и последствия простоев. Особенно важно это при массовых инцидентах, которые имеют высокую вероятность стать инцидентами недоступности, так как они直接影响 точку потребления услуги и требуют коммуникации с пользователями.

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

В контексте управления уровнем ИТ-услуг процесс SLM (Service Level Management) соответствует циклу PDCA (Plan-Do-Check-Act). Этот процесс ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Таким образом, SLM обеспечивает постоянное улучшение качества ИТ-услуг через планомерное выявление и устранение недостатков.

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

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