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

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

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

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

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

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

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

Ассоциация DASA выделяет шесть основных принципов DevOps: 1) Деятельность должна быть ориентирована на заказчика (Customer-Centric Action), включая постоянные инвестиции в продукты и услуги, обеспечивающие максимальную удовлетворённость заказчика, короткие циклы обратной связи и деятельность в духе Lean-стартапов с постоянными инновациями. 2) Ориентация на конечный результат (Create with the End in Mind), что означает отказ от водопадного подхода и процессно-ориентированных моделей в пользу продуктовой ориентации, когда все сотрудники понимают, что создают продукты для реальных заказчиков. 3) Ответственность от начала до конца (End-To-End Responsibility), подразумевающая, что команды отвечают за полный жизненный цикл продукта от концепции до вывода из эксплуатации. 4) Кросс-функциональные автономные команды (Cross-Functional Autonomous Teams), которые должны быть полностью независимыми на протяжении всего жизненного цикла, иметь сбалансированный набор компетенций и T-образные профили специалистов. 5) Постоянное совершенствование (Continuous Improvement), включающее адаптацию к изменяющимся обстоятельствам, сокращение потерь, оптимизацию скорости и затрат, упрощение поставки и постоянное совершенствование продуктов и услуг через экспериментирование и обучение на ошибках. 6) Автоматизируйте всё, что можете (Automate Everything You Can), что охватывает автоматизацию процессов разработки программного обеспечения (непрерывная поставка, непрерывная интеграция, непрерывное развёртывание) и всего инфраструктурного ландшафта (инфраструктура как код).

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

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