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

Компонента A в SLA означает 'Agreement' (соглашение) и представляет собой осознанное согласие двух сторон по поводу условий предоставления услуг. Это включает в себя согласованные параметры уровня обслуживания, обязательства каждой стороны, процедуру пересмотра соглашения, а также механизмы контроля соблюдения и применения санкций в случае нарушения условий. Без этой компоненты SLA превращается просто в набор требований без взаимных обязательств.

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

Кроме термина 'владелец процесса' в литературе по процессному управлению используются такие альтернативные названия, как 'управляющий процесса' (process manager), 'распорядитель процесса' (process steward) и 'спонсор процесса' (process sponsor). Эти термины часто применяются в тех случаях, когда человек, назначенный на роль, не обладает всеми необходимыми полномочиями для полноценного управления процессом, и термин 'владелец' становится условным. Например, 'распорядитель' (steward) лучше отражает роль человека, который не владеет процессом в прямом смысле, но ответственен за его развитие и поддержание в рабочем состоянии. Выбор термина зависит от конкретной ситуации и уровня полномочий, которыми обладает назначенный человек.

При отсутствии ранее существовавшей документации по управлению активами и конфигурациями рекомендуется использовать название "План управления сервисными активами и конфигурациями" (SACM plan). Это соответствует рекомендациям ITIL v3 2011 (раздел Service Transition, 4.3.5.2). При необходимости, учитывая специфику организации, название может быть адаптировано к таким вариантам как "Положение" или "Регламент". Ключевой момент - документ должен описывать целевой уровень управления сервисными активами и конфигурациями, который организация определяет самостоятельно. Структура документа должна включать разделы по охвату, требованиям, политикам и стандартам, организационной структуре, описанию процедур и связям с другими процессами.

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

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

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

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

Для проверки соответствия CMDB требованиям управления мощностями необходимо выполнить следующие шаги: во-первых, убедиться, что в CMDB построены логические модели приложений и услуг, включающие физические ресурсы и функциональные роли, такие как СУБД, web-сервер, файл-сервер. Во-вторых, проверить наличие в связях между элементами атрибутов и логики, которые переносят потребность в мощностях и стоимость обеспечения. В-третьих, проверить поддержку плановых объектов для моделирования целевой архитектуры. Эта проверка позволит не только определить, можно ли использовать CMDB для планирования мощностей, но и выявить конкретные области для улучшения системы.