Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
При поверхностном подходе не учитываются ключевые аспекты: полный охват ИТ-ландшафта, группировка прав доступа в бизнес-роли, интеграция с кадровыми системами, поддержание актуальности прав при изменении статуса сотрудников, возможность выбора наборов доступов на основе примера другого сотрудника, организация регулярных проверок выданных прав и оперативное устранение несоответствий. Например, простой учёт прав без их систематизации и привязки к бизнес-процессам приводит к несоответствиям и росту рисков, выявляемых только во время внешних аудитов.
SLA не должны быть самоцелью, поскольку они являются инструментом для построения и поддержания успешных сервисных отношений, а не конечной целью. Если организация фокусируется исключительно на подписании SLA без учета уровня зрелости, типа сервисных отношений или культурного соответствия, это может привести к формализму и конфликтам. Вместо этого важно помнить, что долгосрочные отношения, основанные на доверии, сотрудничестве и общих целях, гораздо важнее формальных соглашений. SLA должен способствовать регулярным обсуждениям бизнес-целей и улучшению услуг, а не становиться поводом для поиска виноватых.
Цикл Деминга способствует непрерывному улучшению бизнес-процессов благодаря своей итеративной природе. Каждый полный цикл PDCA позволяет внести небольшие, но проверенные изменения в процесс, минимизируя риски и обеспечивая стабильность. Поскольку этап Корректируй может заключаться в запуске нового цикла с учетом накопленного опыта, процесс улучшения становится непрерывным. Это позволяет постоянно находить и устранять узкие места, повышать эффективность процессов и качество предоставляемых услуг или продуктов без радикальных изменений, которые могут нарушить стабильность операционной деятельности.
При проектировании эффективной системы управления событиями необходимо учитывать ряд важных аспектов: определить конечных потребителей информации и их конкретные потребности; разработать модель данных, соответствующую бизнес-требованиям; настроить сбор данных таким образом, чтобы только релевантная информация попадала в систему; установить четкие процедуры реагирования на различные типы событий; организовать регулярный пересмотр и корректировку требований к мониторингу; предусмотреть контроль не только за возникновением событий, но и за отсутствием критически важных операций. Без комплексного подхода к организации процессов системы мониторинга становятся источником шума, а не информационной поддержки.
Baseline — это эталонные данные, которые фиксируются в момент нормальной работы системы и отражают нагрузку на основные компоненты оборудования (процессор, память, дисковая и сетевая подсистемы) и характеристики потребления (количество пользователей, операций и т.п.). Эти данные нужны для сравнения с текущим состоянием системы в случае возникновения проблем с производительностью. Сравнивая текущие метрики с baseline, можно определить, какие именно элементы изменили своё поведение и стали причиной замедления работы системы.
Аналитика Pink Elephant показывает статистически значимую отрицательную корреляцию между долей экстренных изменений и долей изменений, выполненных корректно с первой попытки. Это означает, что увеличение количества экстренных изменений приводит к снижению качества их выполнения. Поскольку экстренные изменения часто обходят стандартные этапы проверки и тестирования, повышается риск ошибок и последующих сбоев системы. Процесс управления изменениями по своей сути направлен на снижение таких рисков, поэтому высокая доля экстренных изменений свидетельствует о недостаточном контроле.
Основная идея подхода Tipu заключается в том, что Continual Service Improvement (CSI) нужно организовывать не после внедрения базовых процессов управления ИТ-услугами, а с самого начала, в рамках первых инициатив. Это позволяет постепенно и органично «достраивать» систему управления, отталкиваясь от реальных задач заказчика и используя набор процессных элементов, которые можно внедрить в относительно короткие сроки. Подход предполагает создание не идеальных процессов, а работающих решений с последующим наращиванием уровня зрелости через интегрированный CSI подход.
Непосредственный руководитель должен знать и одобрять доступ сотрудника к информационным системам, поскольку сотрудник выполняет определенные функциональные обязанности. Отклонения от этих обязанностей должны вызывать вопросы. Руководитель принимает решение о выдаче доступа, основываясь на знании профиля нагрузки и задач своего подчиненного, проверяя, соответствует ли запрашиваемый доступ выполняемым сотрудником функциям. Это позволяет контролировать, чтобы сотрудник запрашивал доступ исключительно для выполнения своих трудовых обязанностей.
Такой подход создаёт ощущение безопасности за счёт формального выполнения аудиторских запросов, но игнорирует реальные уязвимости: сотрудник может иметь доступы, несоответствующие его текущей должности, а ручная обработка изменений приводит к задержкам в отмене прав после увольнения. Например, данные для аудита могут быть актуальными на момент проверки, но в промежутках между аудитами система скапливает критические несоответствия, что увеличивает риск утечки данных или злоупотребления правами.
Типичный диапазон значения Incident Rate составляет от 0.8 до 1.2 инцидентов в месяц на одного пользователя. Крайние случаи могут достигать 0.4–2.3, но чаще всего величина находится в пределах 0.3–2.0. Для сравнения, совокупное количество всех обращений пользователей (включая сервисные запросы и инциденты) колеблется от 1 до 2 в месяц на одного пользователя.