Продуктовые команды сталкиваются с двумя основными проблемами при внедрении CI/CD. Первая проблема связана со строгими требованиями конвейера развёртывания к другим областям разработки. Например, для успешного внедрения CI/CD необходима правильная работа с исходным кодом: единство и дисциплина в использовании Git, отсутствие множества долгоживущих веток и проблем с мержами. Также требуется культура создания и постоянного обновления автоматизированных тестов, и если команда до сих пор сомневается в необходимости автотестов, процесс внедрения будет затруднён. Кроме того, конвейер требует частых релизов, в то время как многие команды привыкли к редким выпускам (раз в месяц или квартал), и изменение этой привычки представляет собой отдельную сложность. Вторая проблема — деградация процесса: после первоначального внедрения команды часто начинают отключать части конвейера (например, автотесты), ссылаясь на срочность задач или дедлайны, что в конечном итоге разрушает весь процесс.

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

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

SLA (Service Level Agreement) — это ключевой элемент управления уровнем ИТ-услуг, фиксирующий обязательства поставщика перед клиентом по доступности, производительности и качеству услуг. Управление уровнем ИТ-услуг включает процессы определения, мониторинга и анализа SLA для обеспечения соответствия ожиданиям заказчика. Однако если управление уровнями услуг ограничено только эксплуатацией и исключает разработку, SLA не может охватывать вопросы времени реализации новых функций, что снижает их ценность для заказчиков и создает недовольство.

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

Оптимальный каталог для учета трудозатрат может включать семь основных групп работ: производство, продажи и account management, маркетинг, внутренняя работа, продукты и методики, партнеры, управление компанией. В примере, описанном в тексте, такой каталог состоит из 54 строк, что может показаться многовато, но в целом остается управляемым. Для средней группы ИТ-специалистов (8-12 человек, 1 линейный руководитель) оптимальным будет каталог из 10-20 позиций для рутинной деятельности и 20-25 позиций с учетом проектной работы. При этом важно помнить, что не все сотрудники участвуют во всех видах работ и не все работы выполняются ежедневно, что делает учет более реалистичным и менее трудоемким. Ключевой принцип при создании такого каталога - сохранять баланс, чтобы не перегружать сотрудников излишней детализацией, но оставить достаточный уровень информации для анализа.

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

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

Системный подход в управлении ИТ-услугами означает анализ и улучшение всей системы в целом, а не отдельных её элементов, с учётом взаимного влияния различных компонентов системы и последствий воздействий на них. Этот подход подразумевает необходимость учитывать совокупное влияние, искать узкие места и направлять усилия в первую очередь на их устранение. В ITSM системный подход закреплён на уровне принципов руководства ITIL® Practitioner и включает анализ системы как набора взаимосвязанных элементов, где изменения в одном элементе влияют на всю систему в целом.

Ключевые индикаторы успешного аутсорсинга: 1. Наличие коммерчески ориентированного руководителя, а не ИТ-директора из материнской компании. 2. Система оплаты руководителя, где отсутствие успехов на открытом рынке приводит к снижению зарплаты ниже рыночной, а успешная коммерческая деятельность обеспечивает значительный доход. 3. Аутсорсинг услуг, имеющих альтернативный спрос и предложение на рынке. 4. Наличие четкого бизнес-плана с перспективами коммерческой деятельности на открытом рынке. 5. Разрешение на извлечение прибыли при оказании услуг материнской компании без чрезмерного влияния на доходы руководства аутсорсера.