Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Чтобы определить, является ли сбой RAID-массива инцидентом, нужно учитывать конкретную конфигурацию и условия, при которых массив считается работающим нормально. Например, в RAID 1+0 выход из строя одного диска в зеркале не считается инцидентом, если это не влияет на функциональность массива и его отказоустойчивость остается в допустимых пределах. Однако выход из строя второго диска в том же зеркале может привести к потере надежности и уже будет инцидентом. Важно определить, какие состояния являются нормальными для конкретной системы на основе технических спецификаций, и только после этого принимать решение о классификации происшествия.
При отсутствии полной автоматизации необходимо использовать всю доступную автоматизацию для тестирования и мониторинга ресурсов, а также спланировать развитие средств контроля для критических функций. Стоит выделять расследование недоступности в отдельный процесс с четкими критериями, обязать регистрацию Major-инцидентов и проводить отдельные расследования для каждого случая. Также можно использовать данные ITSM-системы для контроля сроков выполнения работ и обеспечивать прозрачность через регулярную отчетность заказчику и визуализацию доступности ключевых функций.
Управление доступностью (AVA) следует подходу оптимизации: стремится достичь максимального уровня доступности при разумных затратах, анализируя текущие системы, идентифицируя узкие места и внедряя решения, которые повышают надежность без значительного увеличения издержек. AVA фокусируется на повседневных операциях и стремится устранить единые точки отказа в рамках существующего бюджета. Управление непрерывностью (CONT) придерживается подхода создания избыточности: часто требует наличия резервных площадок, дополнительного оборудования, соглашений с поставщиками, которые могут активироваться только в случае чрезвычайной ситуации. Это создает дополнительные затраты, но критически важно для восстановления после серьезных инцидентов, когда обычная оптимизация не сработает.
Для больницы ключевой акцент при совершенствовании услуг делается на доступность и непрерывность ИТ-сервисов, так как любые перебои могут угрожать жизни пациентов. Для торговой сети приоритетами становятся мощность (поддержка роста бизнеса), безопасность (защита коммерческих секретов) и функционал ИТ-решений. Эти различия обусловлены спецификой деятельности каждой организации и ее рисками, поэтому выбор показателей должен учитывать цели бизнеса.
Функциональный VIP-статус отличается от должностного приоритета тем, что определяется не положением сотрудника в организационной структуре, а критичностью выполняемых им бизнес-функций в определенные периоды времени. Например, сотрудник среднего звена, отвечающий за подготовку финансовой отчетности в конце месяца, может иметь функциональный VIP-статус именно в эти периоды, что автоматически повышает уровень влияния инцидентов, с ним связанных. В то время как должностной VIP-статус обычно постоянен и присваивается руководителям высшего звена независимо от текущих бизнес-процессов. Функциональный подход позволяет более гибко учитывать реальную критичность задач, выполняемых сотрудниками, для бизнеса организации.
В большинстве случаев строгие правила документирования инцидентов не соблюдаются из-за недостаточной подготовки сотрудников, нехватки времени и отсутствия четкого контроля со стороны менеджера. Многие ИТ-специалисты привыкли фиксировать информацию в свободной форме, что иногда приводит к включению в записи конфиденциальных данных. Кроме того, отсутствие регулярного аудита таких записей создает дополнительные риски для безопасности информации.
Опора на недостоверную статистику может привести к неправильным решениям при выборе ИТ-решений и процессов. Это может вызвать перерасход бюджета, неоправданные ожидания от внедрения и, как результат, снижение доверия к методологиям управления ИТ-услугами. Кроме того, некорректные данные могут быть использованы в маркетинговых целях без фактического подтверждения эффективности.
В средних и небольших организациях, где нецелесообразно или невозможно назначить высокопоставленного руководителя (например, директора по ИТ) владельцем процесса из-за его загруженности, нужно разрабатывать дополнительные механизмы эскалации и вовлечения. Владелец процесса, не обладающий достаточными полномочиями, должен иметь оперативный и стабильный доступ к административному ресурсу для решения проблем. Это означает, что необходимо создать надежные процедуры, позволяющие владельцу быстро привлекать руководителей подразделений к решению возникающих вопросов. Например, можно ввести регулярные встречи владельца процесса с ключевыми руководителями подразделений или создать комитет управления для обсуждения проблем и принятия решений. Таким образом, даже при ограниченных прямых полномочиях владелец процесса сможет эффективно управлять процессом за счет четко прописанных правил взаимодействия и поддержки со стороны руководства.
Процесс Управления запросами на обслуживание (RFF) не является основным для обработки запросов о статусе инцидента потому, что ответственность за обеспечение прозрачности и коммуникацию информации о статусах инцидентов возложена на процесс Управления инцидентами (INC). Хотя RFF может использоваться в качестве канала коммуникации для передачи информации по запросу пользователя, он не несёт первичную ответственность за организацию такой коммуникации. INC должен спроектировать систему коммуникации и выбрать оптимальную комбинацию каналов (проактивные – автоматическое оповещение и реактивные – выдача информации по запросу), включая использование RFF в качестве одного из возможных механизмов. Использование RFF как основного процесса для подобных запросов приведёт к снижению ответственности INC за качество коммуникаций и, как следствие, к снижению общего качества обслуживания.
В PCF уровень, соответствующий непосредственно исполняемым процессам, обозначается как "процесс". Этот уровень находится третьим в иерархии и обозначается тремя цифрами, разделенными точками (5.2.3, 8.3.4, 11.2.1). Примеры процессов, приведенные в тексте: Управление жалобами клиентов (в рамках группы Планирование и управление обслуживанием клиентов), Ведение финансовой отчетности (в рамках группы Ведение общего бухгалтерского учета и отчетности), Управление связями с правительством (в рамках группы Управление государственными и отраслевыми отношениями). Этот уровень представляет собой конкретные исполнимые процессы предприятия.