Техническое задание на внедрение асм перечень терминов и сокращений

Вид материала

Техническое задание

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

Подобный материал:

• Г. С. Иванов 2011 г. Техническое задание, 198.02kb.
• 1 Геолого-физическая характеристика месторождения, 24.62kb.
• Реферат Перечень сокращений, условных обозначений, символов, единиц и терминов, 46.85kb.
• Отчет о научно-исследовательской работе структура и правила оформления, 299.55kb.
• Н. С. Третьяков «20» октября 2010 г. Документация техническое задание, 170.41kb.
• Техническое задание для создания Медиаплана, 37.74kb.
• Реферат Перечень сокращений, условных обозначений, 101.56kb.
• Техническое задание на выполнение консалтинговых работ (pr-услуг) по проекту «Стоматологическая, 30.03kb.
• Техническое задание на выполнение работы «Разработка Стратегии развития города Харькова, 138.14kb.
• Geographical Information System приветствуется Знание работы сетей на основе tcp/ip, 790.03kb.

Требования к функциям и задачам

Требования к функциям подсистемы мониторинга активного сетевого оборудования

Подсистема мониторинга активного сетевого оборудования в результате проекта должна обеспечить решение следующих задач:

1. Управление ресурсами и компонентами сетевой информационной инфраструктуры, в частности:
   

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

2. Выдачу обобщенной информации о состоянии контролируемых ресурсов.
   
3. Выдачу обобщенной информации о состоянии компонентов сетевой инфраструктуры и зависимых от них сервисов, работоспособность которых они обеспечивают.
   
4. Отображение и документирование информации о состоянии сетевых ресурсов и их взаимосвязей.
   
5. Сбор и хранение информации о показателях производительности компонентов сетевой инфраструктуры
   
6. Информационную поддержку принятия решений по изменению конфигурации и развитию сетевых ресурсов на основе предоставления информации о производительности и состоянии сети.
   
7. Подготовку и публикацию отчетности по составу, количеству, состоянию компонентов и качеству предоставляемых на базе компонентов сервисов.
   

Требования к функциям подсистемы мониторинга серверов и операционных систем

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

1. Мониторинг серверного оборудования, системного и прикладного ПО серверов.
   
2. Разработка собственных скриптов мониторинга на базе встроенного языка программирования PSL.
   
3. Организация «облегченных» вариантов мониторинга без разворачивания серверных компонентов системы мониторинга.
   
4. Для оценки качества контролируемых сервисов при постановке на мониторинг серверов и операционных систем должны отслеживаться группы параметров, перечисленные в Приложении A, Табл. 5 – Параметры мониторинга сервисов.
   
5. Детальный перечень метрик, который должен быть реализован для обеспечения мониторинга объектов по каждому типу параметров из Табл. 5 представлен в Табл. 6 – Типовые параметры мониторинга.
   

Требования к функциям подсистемы управления событиями

Подсистема управления событиями, реализованная в ходе проекта должна обеспечить решение следующих задач:.

1. Централизованная аутентификация пользователей.
   
2. Интеграция подсистемы аутентификации пользователей с LDAP (в т.ч. Active Directory).
   
3. Настройка интерфейса пользователя:
   

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

4. Распределенная обработка событий;
   
5. Организация типов событий в иерархическую модель классов с наследованием атрибутов;
   
6. Обработка событий (модификация, разбор полей, изменение произвольных атрибутов, насыщение событий данными из внешних источников, корреляция) набором последовательно выполняющихся правил;
   
7. Создание правил обработки событий из консоли оператора (при наличии полномочий);
   
8. Прием событий от произвольных систем через пакеты интеграции, CLI или API с последующей их обработкой;
   
9. Выполнение заданных администратором действий (локально с консоли и удаленно на сервере обработки событий), например, запуск внешнего приложения с параметрами;
   
10. Автоматическое или автоматизированное (инициированное оператором) создание инцидентов в системе CA Service Desk на основании выбранного события (с использованием интерфейса электронной почты);
    
11. Возможность получения информации из системы Service Desk (в случае использования поддерживаемых интерфейсов системой Service Desk и наличия штатных механизмов интеграции) о зарегистрированных инцидентах с оборудованием, программным обеспечением или сервисом, указанным в выбранном событии;
    
12. Предоставление настраиваемых отчетов как исторических, так и на текущий момент времени.
    

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

Подсистема контроля доступности и производительности сервисов должна решать следующие задачи:

1. Создание и выполнение тестовых сценариев работы пользователей в системах, перечисленных в Табл. 7 – Тестовые сценарии для контроля сервисов.
   
2. Измерение времени выполнения синтетических транзакций «из конца в конец», т.е. контроль скорости работы бизнес приложений с точки зрения пользователя;
   
3. Создание пользовательских скриптов (на основании записи реальной транзакции) для измерения интегральной оценки времени отклика тестируемого приложения;
   
4. Подстановка заданных пользовательских данных во время исполнения скрипта для приложений, требующих пользовательского ввода информации;
   
5. Параллельное выполнение множества синтетических транзакций;
   
6. Выполнение скриптов в фоновом режиме, без участия пользователя;
   
7. Выполнение транзакций на основе следующих протоколов: Web transaction (HTML/HTTP/S), низкоуровневые сетевые операции по протоколу HTTP/S, E-mail (SMTP/POP), Directory server (LDAP), FTP, приложения на базе стандартного стека TCP/IP, Terminal Emulation (AT386), Web Services: XML/SOAP (возможность записи Web Service client), Database (MS SQL, ODBC, ADO), Terminal Services: Microsoft Terminal Server, Java RMI/EJB;
   
8. Выполнение транзакций путем вызова Web-сервисов и оценки результата их вызова;
   
9. Получение статистических данных через интерфейсы JMX;
   
10. Вызов сторонних клиентов или утилит для получения данных через интерфейсы RMI;
    
11. Предоставление настраиваемых отчетов как исторических, так и на текущий момент времени.
    

Требования к функциям подсистемы мониторинга услуг

Модуль определения влияния на услуги должен обеспечить решение следующих задач:

1. Построение сервисно-ресурсной модели (далее СРМ) с использованием графического интерфейса для сервисов, входящих в проект (на основе компонентов инфраструктуры, для которых реализован мониторинг):
   

• использование набора стандартных элементов Atrium CMDB для построения СРМ;
  
• возможность задания ответственных за элементы СРМ;
  
• возможность задания стоимостных характеристик для элементов СРМ;
  
• задание метода определения статуса объекта в зависимости от статуса объектов нижнего уровня;
  
• задание правил привязки событий к элементам СРМ в зависимости от типов и значений атрибутов событий.
  

2. Ведение (создание/редактирование/удаление) СРМ в единой конфигурационной базе данных (CMDB);
   
3. Возможность экспорта СРМ в CMDB;
   
4. Возможность импорта СРМ из CMDB;
   
5. Возможность автономной работы при недоступной CMDB;
   
6. Графическое отображение СРМ в консоли оператора с привязкой событий к элементам СРМ (цветовая индикация состояния элементов);
   
7. Просмотр СРМ в графическом интерфейсе в режимах поиска зависимых объектов и зависящих объектов (сверху-вниз и снизу-вверх);
   
8. Возможность установки режима обслуживания для элементов СРМ;
   
9. Возможность моделирования обработки СРМ;
   
10. Возможность изменения оператором статуса для выбранного элемента СРМ;
    
11. Возможность создания инцидентов в ServiceDesk для выбранного элемента СРМ по инициативе оператора;
    
12. Возможность получения информации из ServiceDesk о зарегистрированных инцидентах для выбранного элемента СРМ (если используюется ServiceDesk, имеющий средства коробочной интеграции с Системой);
    
13. Предоставление настраиваемых отчетов как исторических, так и на текущий момент времени.
    
14. Накопление данных и создания отчетов по качеству услуг, входящих в проект на основе соотношения времени доступности услуги и периодов ее предоставления, а так же весов конечных параметров, используемых при оценке (в том числе возникших за период сбоев).