CI/CD, или конвейер развёртывания, является основным и необходимым компонентом DevOps. Даже если DevOps понимается только как набор технических практик, без конвейера развёртывания невозможно говорить о существовании DevOps в принципе. Конвейер автоматизирует процесс интеграции кода, тестирования и доставки приложений в рабочую среду. Он является ключевым элементом, который обеспечивает непрерывную доставку и развертывание изменений, что критически важно для современной разработки программного обеспечения. CI/CD позволяет командам быстрее доставлять изменения конечным пользователям, снижая при этом риски ошибок и упрощая процесс выпуска новых версий продукта.

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

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

Срочное изменение предполагает определённый временной приоритет, но допускает относительную градацию (например, «очень срочно» или «не так срочно»), что часто ведёт к злоупотреблению термином. Экстренное изменение (emergency) в ITIL — это категория, не подразумевающая градаций: оно требует немедленного выполнения без отлагательств, так как связано с критическими сбоями или угрозами безопасности. Например, если сервис полностью недоступен для клиентов, это emergency — все ресурсы переключаются на его исправление, тогда как «срочное» изменение может укладываться в запланированные сроки.

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

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

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

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

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

CMDB (Configuration management data base) - это специализированная база данных, предназначенная для хранения информации о компонентах ИТ-инфраструктуры и их взаимосвязях. CMDB служит центральным хранилищем данных конфигурационных единиц (КЕ), включая их атрибуты, статусы и зависимости. Эта система позволяет ИТ-организациям получить единую точку зрения на все элементы инфраструктуры, что критически важно для эффективного управления изменениями, инцидентами и проблемами. CMDB обеспечивает прозрачность и понимание того, как различные компоненты взаимодействуют между собой и поддерживают конечные пользовательские услуги.