Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Рисунок 1.3.1 – Варианты категорирования инцидентов

1. Этап начальной диагностики

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

Если сервис–деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше.

1. Этап исследования и диагностики

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

• установление того, что именно не работает или что именно ищет пользователь;

• определение хронологии событий;

• оценка влияния инцидента, в том числе количества пользователей, которых он затронул;

• поиск в базе знаний аналогичных случаев в прошлом.

1. Закрытие инцидента

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

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

• закрытие категорирования – производится проверка корректности изначально установленной категории инцидента. Если она оказалось неправильной, ее исправление и занесение изменений в запись об инциденте;

• опрос удовлетворенности пользователей осуществляется по звонку или электронной почте для статистики и отображения эффективности работы сервис–деска;

• проверка полноты записи об инциденте;

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

• формальное закрытие инцидента – формальное закрытие записи об инциденте.

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

1. Риски для процесса управления инцидентами

Основные риски для процесса Управления инцидентами:

• большое количество инцидентов, которые не могут быть разрешены в установленные сроки в связи с недостатком ресурсов или их недостаточной подготовкой;

• приостановка разрешения инцидентов из–за некорректной работы поддерживающих инструментов;

• недостаточность или несвоевременность информации из–за некорректной работы поддерживающих инструментов или плохой взаимосвязи с другими процессами;

• несоответствия с основными контрактами и соглашениями, которые возникают вследствие их плохой проработки и нереалистичности согласованных целевых показателей.

Процесс управления инцидентами напрямую связан с управлением рисками. Пример: закончился картридж в принтере. На первый взгляд, это не инцидент ИБ. Но если в этот момент печатается финансовая отчетность генеральному директору или это ПИН принтер, т.е. это инцидент, связанный с доступностью.

2 Анализ деятельности предприятия

В ходе эксплуатации активов ИТ–Инфраструктура Министерством Обороны Российской Федерации (МО РФ) было выявлено огромное количество инцидентов связанных с полным или частичным отсутствием доступа к различным сервисам. В связи с этим был заключён государственный контракт на выполнение работ по централизованному сервисному обслуживанию средств связи, программно–аппаратных комплексов и инфраструктуры информационных технологий Вооруженных Сил Российской Федерации. Исполнителями данного ГК является ОАО «Воентелеком», а также субподрядные организации, в числе которых АО «Ситроникс–КАСУ». Для организации работ по ЦСО ОАО «Воентелеком» была разработана централизованная система управления инцидентами (ЦСУИ). И хотя в ЦСУИ циркулирует несекретная информация, она может раскрыть состав и дислокацию информационных систем объектов МО РФ. В связи с этим офицерами службы защиты государственный тайны был поставлен вопрос о защите информации на рабочих местах инженеров обслуживающих организаций и каналов её передачи.

2.1 Основные цели централизованного сервисного обслуживания

Цели централизованого сервисного обслуживания:

• повышение эффективности использования информационных технологий в деятельности Министерства обороны;

• повышение эффективности планирования и управления затратами на эксплуатацию ИТ­ инфраструктуры Министерства обороны за счёт централизованного контроля.

2.2 Задачи централизованного сервисного обслуживания

Общая задача централизованного сервисного обслуживания – обеспечение устойчивого функционирования ИТ–инфраструктуры Министерства обороны через:

• обеспечение бесперебойной работы телекоммуникационного оборудования, средств вычислительной техники и программных комплексов в соответствии с документированными производителями возможностями (техническими характеристиками);

• обеспечение технической и консультационной поддержки должностных лиц – пользователей сервисов ИТ–инфраструктуры;

• предупреждение вероятных отказов оборудования и программного обеспечения путем проведения своевременной диагностики и регламентно–профилактического обслуживания;

• своевременное устранение возникающих неисправностей путем проведения ремонтно­–восстановительных и пуско–наладочных работ.

2.3 Работа центра авторизации обращений

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

Работа центра авторизации обращений включает:

• прием, классификацию обращений пользователей на выполнение работ в соответствии с Техническими требованиями;

• регистрацию обращений в ЦСУИ;

• назначение заявок на исполнителей, контроль исполнения заявок в соответствии со сроками, установленными Техническими требованиями;

• отражение в ЦСУИ информации о ходе исполнения заявок, проблемных вопросах, возникших в ходе исполнения;

• информирование заявителей о планируемых дате и времени прибытия специалиста;

• информирование заявителей о контрольном сроке выполнения заявки в момент приема и регистрации заявки; информирование заявителей о ходе исполнения заявок (в случае соответствующего обращения заявителя);

• корректность оформления закрытия заявок и правильность оформления документов по закрытию;

• информирование заявителей о планируемом сроке выполнения заявки в случае превышения контрольного срока выполнения заявок со следующей периодичностью: категории ЭО 1–2 один раз в течение двух рабочих дней, категории ЭО 3–5 один раз в течение трех рабочих дней (таблица 2.3.1).

Таблица 2.3.1 – «Категорирование ЭО»

Заявки на работы и их регистрационные атрибуты используются:

• как основание для выполнения специалистами Исполнителя работ по выполнению работ ЦСО;

• в управлении работами по выполнению работ ЦСО;

• в информировании представителей Заказчика и пользователей о ходе исполнения работ по ЦСО;

• в формировании отчетности перед Заказчиком по номенклатуре, количественным и качественных характеристикам фактически выполненных работ.

2.4 Порядок выполнения работ

После получения заявки одним из способов, приведённых в п. 3.2.1 Технических требований, центр авторизации обращений должен зарегистрировать ее в ЦСУИ и назначить специалисту (группе специалистов) Исполнителя.

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

Закрытие заявки осуществляется оператором центра авторизации обращений после проверки сервисного листа по корректности закрытия заявки.

Отмена заявок осуществляется только по согласованию с заявителем с оформлением сервисного листа до окончания отчетного периода.

В случае отказа в приеме заявки оператор центра авторизации обращений обязан сообщить заявителю причину неприёма заявки и зарегистрировать данное обращение как не принятое с указанием причины.

Причинами неприема заявки могут быть:

• отсутствие данного актива в утвержденных представителем Заказчика Актах передачи на ЦСО;

• подача заявки не уполномоченным лицом;

• подача заявки на выполнение работ, не предусмотренных перечнем работ.

2.6 Работа Централизованной Системы Управления Инцидентами

Целью проведения работ по предоставлению централизованной системы управления инцидентами (ЦСУИ) в ИТ–инфраструктуре Министерства обороны является:

• обеспечение управления заявками на работы;

• обеспечение управления исполнением работ по ЦСО;

• обеспечение учета затрат на выполнение работ по единичным расценкам;

• обеспечение автоматического формирования печатных форм (отчетных и других документов по контракту); обеспечение хранения копий всех документов по контракту в формате PDF с привязкой к ЭО и заявкам;

• обеспечение формирования промежуточной и заключительной статистической отчетности по выполняемым работам;

• обеспечение Заказчика и Исполнителя своевременной и достоверной информацией о номенклатуре, количественных и качественных характеристиках фактически выполняемых работ.

2.7 Требования к выполняемым работам

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

В процессе выполнения Исполнителем работ по ЦСО информационная система управления инцидентами Исполнителя должна обеспечивать:

• регистрацию заявок с автоматическим присвоением номера (сквозная нумерация);

• автоматическое установление контрольного срока (дата, время) исполнения заявки в соответствии с условиями Технических требований;

• возможность внесения информации о конечном исполнителе заявки;

• возможность внесения сведений о ходе исполнения заявки;

• возможность внесения сведений об использованных материалах;

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

• возможность оперативного получения статистической информации о выполняемых работах по ЦСО в различных разрезах;

• предоставление сведений о ходе исполнения заявок;

• предоставление возможности автоматически произвести расчет качества выполненных работ по ЦСО за любой интервал времени (с точностью до дня).

• учет, обработку, распределение неограниченного потока заявок от заявителей в реальном масштабе времени;

• тарификацию выполненных работ в соответствии с единичными расценками по контракту;

• расчет стоимости выполненных работ по ЭО, видам активов и по отдельным заявкам (типам заявок);

• автоматическое формирование отчетных документов по Контракту (сервисных листов, ведомостей, актов передачи/снятия активов на ЦСО, актов сдачи–приемки работ и др);

• защиту информации ограниченного доступа в соответствии требованиями нормативных правовых актов Российской Федерации и с учетом максимального уровня конфиденциальности информации, обрабатываемой в ЦСУИ.

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

Характеристики

Список файлов ВКР