Файл: Актуальность темы. Потребность xxi века заключается в оперативности предоставления информации, ее достоверности, своевременности.rtf

После внедрения СС&B архитектура информационной системы компании изменится. И будет выглядеть следующим образом. Рисунок 3.7.


Рисунок 3.7 Диаграмма развертывания архитектуры информационной систем
Сетевая инфраструктура:

Сетевая инфраструктура планируется с обеспечением дублирования каналов связи как между компонентами центра обработки данных (ЦОД), так и каналов связи с удаленными отделениями.

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

Каналы для организации WAN- сети (Wide-Area Network – территориально распределенная сеть организации), предоставленные провайдером, для связи программно-аппаратного комплекса ЦОД с территориально разобщенными площадками должны обеспечивать:

-100 мбит/с для программно-аппаратного комплекса ЦОД

-Минимальные требования к пропускной способности локальной сети в участках подключения конечных пользователей, которые составляют: 32 кбит/с в расчете на одну рабочую станцию, но не менее 512 кбит/с на подразделение, при условии, что на рассматриваемом участке сети нет другой активности, кроме как относящейся к работе системы Oracle CC&B. В случае если рассматриваемый участок сети используется другими службами и приложениями, то необходимо рассчитывать требуемую пропускную способность с учетом также и требований со стороны всех таких служб и приложений.

Сетевое оборудование, предназначенное для обеспечения каналов связи между компонентами ЦОД: серверами СУБД, приложений, административным сервером, сервером BI EE, системой хранения, серверами балансирующими нагрузку, активным сетевым оборудованием должно обеспечивать 1 Гбит/с.

Между серверами уровня базы данных, административным сервером, сервером хранилища, серверами разработки и системой хранения данных должна быть организована сеть хранения данных (SAN – storage area network) обеспечивающая скорость передачи данных не менее 4 гбит/с.

Сервер Баз Данных CC&B:

На сервере содержатся данные, связанные с приложениями CC&B. Платформа, поддерживающая данный сервер, содержит две группы объектов:

1. 
   Файлы, поддерживающие работы сервера базы данных;
   
2. 
   Файлы, в которых содержаться реальные данные;
   

Реляционная база данных, используемая в продукте, располагается на сервере базы данных. OracleUtilities CC&B поддерживает базы данных ORACLE, DB2 или SQL Server. В проекте будет использоваться СУБД Oracle. Роль базы данных в архитектуре CC&B – только хранение и поиск данных. Никакая бизнес-логика, за исключением простейших ограничений, не внедрена на уровне базы данных по соображениям производительности и управляемости.

При установке компонентов базы данных OracleUtilities CC&B в выбранную СУБД (Oracle) процесс установки разворачивает все необходимые для работы таблицы, представления и индексы.

Уровень приложений

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

Сервисы, составляющие основу уровня приложений OracleCustomer&Billing:

1. 
   Web Application Server
   

Предназначен для реализации логики пользовательского интерфейса на уровне приложения посредством динамической генерации HTML-страниц. С помощью WebApplicationServer реализована часть пользовательского интерфейса OracleCustomerCare&Billing. Приложения CC&B базируется на совместимом с J2EE сервере приложений, таком как,OracleWebLogicServer, WebSphere или OracleApplicationServer. Эта конфигурация может работать на различных поддерживаемых платформах Linux, Unix, WindowS. Связь Web-сервисов с клиентом осуществляется по протоколам HTTP и HTTPS. WebApplicationServer обрабатывают запросы, полученные от клиентских рабочих мест.

2. 
   Business Application Server
   

Предназначен для реализации бизнес-правил. Бизнес-правила реализуются в виде объектов, с которыми связано большинство функциональных операций в системе. На данном уровне выполняются все преобразования данных, реализуются механизмы организации ссылочной целостности данных и правила проверки корректности данных, обрабатываются и форматируются результаты SQL запросов к базе данных. Включает следующие компоненты:

• 
  BusinessObjects – Бизнес-логика для каждого объекта системы представлена в виде Java или Cobol объектов. Они содержат все запросы SQL, программный код, структуры для управления данными операций.
  
• 
  Hibernate – используется для доступа к данным реляционной базы данных как к объектам. Если требуется доступ к базе данных используется компонент Hibernate для управления набором соединений к базам данных. Этот механизм резервирует соединения и гарантирует эффективное соединение с базой данных. Hibernate создает набор соединений с базой данных, используя настройки конфигурации, включающие тип соединения и количество соединений которые необходимо создавать в периоды пиковой и нормальной нагрузки в системе. Набор соединений создается при старте, допускает повторное использование подключений в наборе и переподключение в случае возникновения ошибки.
  

Рисунок 3.8. Архитектура вычислительного комплекса CC&B и MDM

• 
  приложение CCB;
  
• 
  приложение MDM;
  
• 
  приложение аналитики и отчетности Oracle BI, и другие приложения (в случае необходимости)
  
• 
  продукты промежуточного (интеграционного) слоя из состава Oracle SOA Suite;
  
• 
  технологическое ПО Exalogic x2-2.
  

Oracle Exalogic представляет собой платформу для размещения приложений любых видов, включая крупные и высокопроизводительные системы. Oracle Exalogic оптимизирована для Java-приложений, Oracle Fusion Middleware и Oracle’s Fusion Applications, но также применима для большого круга Linux и Solaris приложений, применяемых в настоящее время.

Оборудование Oracle Exalogic поставляется в стандартном 19” 42U серверном шкафу Sun Rack II 1242. В состав конфигурации Oracle Exalogic входят серверы (compute nodes), высокопроизводительная подсистема хранения, а также коммутаторы для подключения оборудования, в т.ч. для внешних подключений. В составе конфигурации также предусмотрены 10 Gigabit Ethernet ports для интеграции в инфраструктуру ЦОД Заказчика.

Предлагаемое решение Oracle Exalogic имеет следующие аппаратные характеристики: 8 x Sun Fire X4170 M2 servers, 2 x Xeon CPU 2.93 GHz 6-core (всего 96 ядер); 576GB 1333 MHz DIMM RAM; 256GB FlashFire SSD; 40TB On-board Disk Storage; QDR InfiniBand adapters. Предустановлена ОС Oracle Enterprise Linux.

В рамках настоящего предложения Oracle Exalogic применяется для размещения как продуктивных сред серверов приложений и web-серверов, так и вспомогательных сред – тестирования, разработки, обучения пользователей.

Для построения серверной платформы систем Oracle CCB и MDM уровня базы данных предлагается использовать решение Oracle Exadata Database Machine в конфигурации X2-2 Half Rack. Данная конфигурация включает 4 сервера базы данных (database servers) и 7 серверов хранения (storage servers).

На Oracle Exadata размещаются следующие компоненты системы:

• 
  СУБД приложения CCB;
  
• 
  СУБД приложения MDM;
  
• 
  СУБД системы аналитики и отчетности Oracle Business Intelligence (c опциями OLAP) с хранилищем данных Oracle Utilities BI Extractors and Schema;
  
• 
  СУБД других приложений (в случае необходимости);
  
• 
  CУБД продуктов промежуточного (интеграционного) слоя из состава Oracle;
  
• 
  SOA Suite (опционально — зависит от интеграционного решения);
  
• 
  технологическое ПО ExaData v2 для обеспечения кластеризации Oracle RAC, сжатия данных Adv Compression, ПО опции Partitioning).
  

Oracle Exadata представляет из себя набор серверного оборудования стандартной архитектуры x86_64 для серверов хранения и серверов баз данных, коммутаторов транспортной подсистемы на основе Infiniband и инфраструктурных компонент (Ethernet коммутатор внутренней сети управления и KVM-переключатель). Оборудование установлено в один стандартный 19” серверный шкаф Sun Rack II 1242.

Транспортная подсистема Exadata включает в себя два коммутатора Oracle Data Center Infiniband Switch (leaf-switch или коммутаторы подключения серверов) для организации взаимодействия внутри комплекса между серверами баз данных и серверами хранения. На основе коммутаторов формируется единая резервированная сеть Infiniband. Каждый сервер включен двумя портами Infiniband QDR 40Gb/s: основным и резервным (в режиме failover), что гарантирует автоматическое переключение на резервный канал связи при выходе из строя одного Infiniband-кабеля или одного из коммутаторов транспортной системы.

Серверы баз данных в составе Oracle Exadata имеют следующую конфигурацию: Oracle Sun Fire X4170 M2, 2 x Six-Core Intel® Xeon® X5670 Processors (2.93 GHz), 96 GB Memory, 4 x 300 GB 10,000 RPM SAS Disks, 2 x QDR (40Gb/s) Ports, 2 x 10 Gb Ethernet Ports, 4 x 1 Gb Ethernet Ports.

Серверы хранения в составе Oracle Exadata имеют следующую конфигурацию: Oracle Sun Fire X4270 M2, 2x Intel 6-Core Xeon 2.26GHz L5640, 24 GB Memory, 12 x 600 GB 15,000 RPM High Performance SAS disks или 12 x 2 TB 7,200 RPM High Capacity SAS disks, 2x Infiniband 4X QDR (40Gb/s) Ports. В каждом сервере хранения установлены по четыре контроллера Flash Accelerator FA20, обслуживающие лишь flash-диски. Доступ к информации на flash-дисках происходит практически с нулевыми задержками, скорость таких дисков может достигать десятков тысяч IOPS. Общий объем flash-дисков составляет 2.6Тбайт.

На уровне СУБД Oracle Exadata реализует Oracle Real Application Cluster (RAC) архитектуру. Предлагаемая конфигурация Oracle RAC даёт линейное масштабирование практически для всех задач, а его коэффициент зависит от качества реализации задачи в плане минимизации конкуренции за ресурсы.

В качестве системы резервного копирования предлагается использовать решение на базе программного обеспечения компании Symantec – NetBackup. NetBackup является ведущим ПО резервного копирования в мире (40% рынка). Система резервного копирования обеспечивает создание резервных копий как с серверов БД и приложений систем CCB и MDM, так и с остальных серверов ОАО «Челябэнергосбыт». Общая архитектура решения представлена на рисунок 3.9.


Рис.3.9. Общая схема системы резервного копирования.
Решение по резервному копированию аппаратно-программного комплекса Oracle DataBase Machine средствами NetBackup было официально протестировано Symantec совместно с Oracle. Описание тестирования представлено в документе: «White Paper: Protecting an Exadata Database Machine with NetBackup for Oracle».

NetBackup позволит производить автоматизированные резервные копии данных по расписанию с Oracle DataBase Machine, а также с других серверов ИТ-инфраструктуры ОАО «Челябэнергосбыт».

В состав решения входят следующее аппаратное обеспечение:

• 
  Сервер резервного копирования IBM x3850 X5.
  
• 
  Ленточная библиотека IBM TS 3310 (320 накопителей LTO5, 6 ленточных приводов LTO5).
  
• 
  FC коммутаторы Cisco MDS 9148 (48 активных портов).
  
• 
  Серверный шкаф IBM 42U Enterprise Rack.
  

В качестве сервера резервного копирования используется сервер IBM x3850 X5 в конфигурации: 2x6 Core 2.00GHz Xeon, 16 GB RAM, 2 x 600 SAS HDD, 2x2 ports FC HBA, 2 ports Infiniband HBA. Операционная система – RedHat Enterprise Linux.

В процессе развертывания приложений Oracle Utilities будет переход на оборудование Enterprise-класса. Целевая конфигурация оборудования приведена в таблице 3.4.:
Таблица 3.4. Целевая конфигурация оборудования

№	Тип сервера	Назначение
1	Oracle Exadata	Единый слой БД для промышленных модулей (схемы БД для Oracle Utilities CC&B, Oracle Utilities MDM, Oracle BI, Oracle SOA.
2	Oracle Exalogic (домен приложений Production-системы)	Слой приложений Production-системы (сервисы Web Application Server CC&B, Business Application Server CC&B, сервисы SOA, BI, MDM
3	Oracle Exalogic (домен тестовых сред)	Среды тестирования, разработки, обучения и др. вместе с БД

На рис. 3.10 ниже приводится целевая архитектура аппаратного комплекса для развертывания приложений ИСАУБ в промышленной эксплуатации.

Пользовательские рабочие станции:

1. 
   ОС Windows (XP, Seven)
   
2. 
   Веб-браузер InternetExplorer (версия 9.0 или выше)
   
3. 
   AdobeReader (версия 10.1.7) – программа для просмотра файлов в формате *.pdf (отчеты, системная документация)
   
4. 
   PL/SQLDeveloper - интегрированная среда разработки на языках SQL и PL/SQL, ориентированная на применение в среде OracleDatabase (для пользователей, занимающихся администрированием системы)
   
5. 
   eTokenPKIClient 5.1 – программа, обеспечивающая работу USB-ключа eToken с функцией смарт- карты (средство аутентификации пользователей)
   
6. 
   Антивирус Касперского (версия 6.0) – антивирусное обеспечение
   
7. 
   Пакет приложений MSOffice
   
8. 
   Специализированные программы для определенных категорий пользователей
   

Рисунок 3.10. Целевая архитектура аппаратного комплекса
Для обеспечения сохранности данных, как на этапе построения системы, так и при эксплуатации необходимо производить регулярное резервное копирование.

Политика резервного копирования на этапе построения системы существенно отличается от политики резервирования данных в ходе эксплуатации, так как при эксплуатации системы основная цель резервного копирования – обеспечить помимо сохранности данных и возможность восстановления данных в минимальное время. При этом нет необходимости хранить старые (обычно, больше 2 недель) резервные копии.

На этапе построения системы основное назначение резервного копирования – обеспечить сохранность текущей версии прототипа системы с возможностью отката на значительное время назад, при этом нет жестких требований к времени восстановления, т.к. восстановления обычно могут быть спланированы заранее. Также важно не запутаться во множестве архивов, поэтому инкрементальное копирование тестовых сред нецелесообразно. Если время копирования и восстановления позволяют, для резервного копирования БД тестовых сред удобно использовать DataPump.

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

Наименование архива	Содержание	Частота копирования	Срок хранения
Промышленная среда
PROD_<ИМЯ СЕРВЕРА>-<ИМЯ_КАТАЛОГА_ФС><ДАТА_КОПИРОВАНИЯ>-FULL	Архив полной копии приложений Oracle Utilities MDM, CC&B, SOA, BI промышленной системы (выполняется при остановленных сервисах)	Еженедельно (на выходных) а также после установки обновлений.	Согласно политике предприятия, обычно 1 месяц.
PROD_-<ДАТА_КОПИРОВАНИЯ>-FULL	Архив полной копии базы (выполняется при остановленной БД и сервисах приложений Oracle)	Еженедельно (на выходных)	Согласно политике предприятия, обычно 1 месяц.
PROD_-<ДАТА_КОПИРОВАНИЯ>-INC	Инкрементальная копия базы (выполняется на работающей системе)	Ежедневно (ночью или в другой период минимальной загрузки)	Согласно политике предприятия, обычно 1 месяц.
Продолжение таблицы 3.5.
Тестовые среды
<ИМЯ_СРЕДЫ>_<ИМЯ СЕРВЕРА>-<ИМЯ_КАТАЛОГА_ФС><ДАТА_КОПИРОВАНИЯ>	Архив полной копии приложений Oracle Utilities MDM, CC&B, SOA, BI промышленной системы (выполняется при остановленных сервисах)	По инициативе владельца среды	По согласованию с владельцем среды.
<ИМЯ_СРЕДЫ>-<ДАТА_КОПИРОВАНИЯ>	Полная копия или export базы (выполняется при остановленных сервисах)	По инициативе владельца среды	По согласованию с владельцем среды.

Порядок резервного копирования, контроль, хранение копий, порядок полного или частичного восстановления данных определяются документом «Регламент резервирования и восстановления».

Меры по обеспечению надежности

В рамках выполнения программы внедрения информационной системы абонентского учёта и биллинга предприятия на базе Oracle СС&B планируется выполнение работ по модернизации существующего Центра Обработки Данных, в том числе:

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

В рамках выполнения этих работ должны быть обеспечены два критерия надежности системы:

1. 
   сохранность работоспособности;
   
2. 
   сохранность информации;
   

Техническая архитектура выбрана, исходя из необходимости обеспечить восстановление работоспособности ИСАУБ в течение __ часов (за исключением случаев полной потери работоспособности ЦОД в результате пожара и т.п.). Целевое серверное оборудование (Exlogic/Exadata) не имеет единой точки отказа, поэтому отказ единичной компоненты оборудования не приводит к потере доступности системы. Однако для выполнения требований к обеспечению доступности необходимо отсутствие единых точек отказа также в инфраструктурных звеньях, таких как сетевое оборудование, каналы связи, электропитание, кондиционирование и т.п..

Глава 4. Внедрение информационной систем, оценка эффективности проекта
4.1 Календарный план
Для начала необходимо определить список задач, определить, как компания будет внедрять данный программный продукт. После этого составим календарный план. Дальше необходимо определить, сколько ресурсов организация задействует на данном проекте, и рассчитать трудовые и материальные затраты. Все это можно рассчитать и составить в Microsoft Project.

Приведем список задач по внедрению:

1.Подготовка технического задания на внедрение:

1. 
   Обследование объекта внедрения, выявление специфических особенностей;
   
2. 
   Описание будущих бизнес-процессов;
   
3. 
   Описание настроек;
   
4. 
   Ознакомительное обучение управленческого персонала и ключевых пользователей с целью детальной и объективной проработки технических вопросов;
   

2. Адаптация системы:

1. 
   Настройка системы в соответствии с результатами работ предыдущего этапа;
   
2. 
   Разработка отчетности в соответствии с требованиями;
   
3. 
   Разработка сценариев тестирования для запуска в опытную эксплуатацию;
   

3. Подготовка объекта к автоматизации:

1. 
   Развертывание системы;
   
2. 
   Перенос данных;
   
3. 
   Обучение пользователей в соответствии с утвержденными бизнес-процессами;
   
4. 
   Обучение технических специалистов;
   

4. Опытная эксплуатация:

1. 
   Приемочные испытания;
   
2. 
   Доработка системы в соответствии с замечаниями по результатам тестирования
   

5.Промышленная эксплуатация:

1. 
   Ввод в промышленную эксплуатацию;
   

В Приложении А представлен календарный график. Календарный график представлен в диаграмме Ганта.

Длительность проекта составляет – 689 дней.

Дальше необходимо определить трудовые ресурсы проекта:

1. 
   Руководитель проекта со стороны Исполнителя;
   
2. 
   Руководитель проекта со стороны Заказчика;
   
3. 
   Архитектор проекта;
   
4. 
   Инженер-технолог;
   
5. 
   Программист со стороны Исполнителя;
   
6. 
   Программист со стороны Заказчика;
   
7. 
   Консультант по обучению;
   
8. 
   Консультант проекта;
   

Рисунок 4.1. Статистика проекта

В приложении Б представлен Лист ресурсов. В листе ресурсов указано не только должность, но и заработная плата (руб./ч.), а также, сколько выделяется трудовых единиц на данный проект. Также в приложении Б. Лист ресурсов указаны не только трудовые ресурсы, но и материальные.

Исходя из полученных данных получается, наглядно можно посмотреть на рис 4.1.
4.2 Оценка рисков проекта, мероприятия по минимизации рисков
Для того, чтобы избежать отрицательных моментов в проекте, необходимо разработать программу по управлению рисками. Для начала необходимо определить существующие риски. После этого, провести качественный анализ, он покажет какова вероятность возникновения риска, и насколько значителен риск. После этого, проведем количественный анализ, где можно будет выделить самый значительный риск для проекта, и как он повлияет на проект, если осуществится.
4.2.1 Идентификация рисков

Итак, выявим основные риски для проекта, таблице 4.1.:
Таблица 4.1. Идентификация рисков

Классификация:	Риск.
Технические риски	1.Недостаточная мощность эксплуатационного оборудования;
	2.Сбой программного обеспечения;
	3.Постоянные перебои в базе данных;
Персонал:	4.Нехватка квалифицированных специалистов;
	5.Отсутствие мотивации членов проектной группы;
	6.Сильное сопротивление персонала к изменениям;
Организационные риски	7.Серьезные изменения в законодательстве РФ;
	8.Появление новых требований/бизнес-процессов в ходе проекта;
	9.Отсутствие финансирования со стороны инвесторов
	10.Серьезные отступления от методологии внедрения

4.2.2 Качественный анализ рисков

Для проведения качественного анализа необходимо сформировать матрицу последствий и матрицу вероятностей, матрица представлена в таблице 4.2. и 4.3.
Таблица 4.2.Матрица вероятностей

Диапазон	Расчетное значение	Формулировка	Числовая оценка
0-20%	10%	Низкая вероятность	1
21-40%	30%	Средняя вероятность	2
41-60%	50%	Вероятность вше среднего	3
61-80%	70%	Высокая вероятность	4
81-100%	90%	Очень высокая вероятность	5

Таблица 4.3. Матрица Последствий:

Числовая оценка	Денежная оценка
1	0 – 550 тыс.руб.
2	550-1000 тыс. руб.
3	1000 тыс. руб. – 3000 тыс. руб.
4	3000 тыс. руб. – 10 000 тыс. руб.
5	Более 10 000 тыс. руб.

Проранжируем риски, расположив их в матрице вероятностей и последствий, данная матрица представлена в Таблице 4.4.:
Таблица 4.4 Матрице вероятностей и последствий

Последствия/ вероятность	0 – 550 тыс.руб.	550-1000 тыс. руб.	1000 тыс. руб. – 3000 тыс. руб.	3000 тыс. руб. – 10 000 тыс. руб.	>10 000 тыс. руб.
0-20%		2,3,1	10		9
21-40%	10		5		4
41-60%
61-80%	7			8
81-100%					6

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