Основные положения Технической политики ОАО

24. Приложение
«Основные положения Технической политики ОАО «Московская объединенная электросетевая компания»в области информационных технологий.»
Содержание
1. Общие положения
1.1. Цели и задачи Технической политики ИТ
1.2. Ожидаемый эффект от реализации Технической политики ИТ
1.3. Нормативно-техническое обеспечение ИТ-деятельности
1.4. Адаптация и развитие политики
2. Современные тенденции в области ИТ
2.1. Консолидация ресурсов
2.2. Виртуализация ресурсов
2.2.1. Логическое разделение вычислительных комплексов
2.3. Современная архитектура приложений
2.3.1. Сервис-ориентированная архитектура
2.3.2. Многоуровневая архитектура клиент-сервер
2.4. Средства интеграции приложений
2.5. Современная коммуникационная инфраструктура
2.6. Единое информационно-технологическое пространство
3. Организация управления ИТ
3.1. Задачи управления ИТ
3.2. Методология управления ИТ
3.2.1. Уровни зрелости управления ИТ
3.2.2. Модель разработки планов по ИТ
3.2.3. Модель разработки и внедрения решений в области ИТ
3.2.4. Модель предоставления услуг ИТ
3.2.5. Модель управления архитектурой ИТ
3.2.6. Модель управления ресурсами ИТ
3.2.7. Модель сорсинга
3.2.8. Модель распределения процессов между организациями
3.3. Поддержка пользователей
3.4. Стратегия коммуникации
3.5. Стратегия сорсинга
3.6. Целевые показатели эффективности ИТ
3.7. Управление активами ИТ
3.8. Управление проектами и разработкой прикладных систем
4. Управление ИТ-инфраструктурой
4.1. Оценка необходимости изменений в ИТ-инфраструктуре
4.2. Проведение изменений в ИТ инфраструктуре
4.2.1. Общие требования к тестированию и приемке изменений
4.2.2. Требования «разумного консерватизма»
4.2.3. Автоматизация тиражирования обновлений ПО
4.3. Планирование ИТ-инфраструктуры
4.3.1. Выбор периодов планирования для ИТ-приложений
4.3.2. Расчет производительности и объема хранимой информации для ИТ-систем
(масштабирование ИТ-систем)
5. Каталогизация и классификация элементов ИТ-инфраструктуры
5.1. Типизация элементов ИТ-инфраструктуры
5.2. Классификация по уровню использования
5.3. Классификация по уровню требуемой непрерывности обслуживания
и важности для бизнеса
5.4. Принципы создания Каталога рекомендованных конфигураций
6. Требования к поставщикам, производителям
и проведению конкурсов
6.1. Общие требования
6.2. Требования к поставщикам и производителям оборудования
6.3. Требования к поставщикам услуг
6.3.1. Общие требования к поставщикам услуг
6.3.2. Требования к поставщикам услуг по эксплуатации и сопровождению
6.3.3. Требования к поставщикам услуг по обучению
6.4. Требования к проведению конкурсов
7. Технические требования к элементам ИТ-инфраструктуры
7.1. Требования к рабочим местам пользователей
7.1.1. Требования к персональным компьютерам
7.1.2. Требования к системному ПО рабочих мест пользователей
7.1.3. Требования к периферийным устройствам
7.2. Требования к мультисервисной сети
7.2.1. Требования к корпоративной распределенной мультисервисной сети
7.2.2. Требования к внешним каналам связи
7.3. Прикладное программное обеспечение
7.3.1. Общие требования к прикладному ПО
7.3.2. Общие требования к универсальному прикладному ПО
7.3.3. Общие требования к заказному прикладному ПО
7.3.4. Интеграция приложений
7.3.5. Прикладные сервисы
7.4. Требования к вычислительной инфраструктуре центров обработки данных
7.4.1. Общие требования
7.4.2. Требования к серверам
7.4.3. Требования к системам хранения данных
7.4.4. Обеспечение высокой доступности приложений
7.4.5. Резервное копирование данных
7.4.6. Обеспечение катастрофоустойчивости
7.5. Требования к обеспечению информационной безопасности
7.5.1. Общие требования
7.5.2. План обеспечения непрерывности бизнеса и восстановления после аварии
7.6. Требования к системе управления и мониторинга
7.6.1. Общие требования
7.6.2. Требования к структуре СУМ ЦОД I и II уровней
7.6.3. Требования к функциональности СУМ ЦОД I и II уровней
7.6.4. Требования к функциональности СУМ ЦОД III уровня
7.6.5. Требования к управлению и мониторингу мультисервисной сети
7.7. Требования к созданию и вводу в действие систем. Требования к документации
7.7.1. Требования к техническому заданию
7.7.2. Требования к технорабочему проекту
7.7.3. Требования к программам и методикам испытаний
7.7.4. Требования к эксплуатационной документации
7.7.5. Требования к поставке оборудования и ПО
7.7.6. Требования к вводу в действие
8. Сертификация программного обеспечения и программнотехнических комплексов
9. Стратегия реализации Технической политики ИТ
9.1. Фаза 0
9.2. Фаза 1
9.3. Фаза 2
9.4. Унифицированные решения
9.5. Планирование перехода к целевому состоянию
Приложение 1
Определения, обозначения и сокращения
Приложение 2
Ориентировочные минимальные требования к рабочим
местам пользователей
2.1. Требования к характеристикам ПК
2.2. Требования к периферийным устройствам
Приложение 3
Требования к компонентам мультисервисной сети
3.1. Требования к оборудованию локальных вычислительных сетей
3.2. Требования к оборудованию IP-телефонии и передачи голоса через IP
3.3. Требования к оборудованию обеспечения информационной безопасности
3.4. Требования к оборудованию сетей хранения
3.5. Требования к оборудованию телеприсутствия
3.6. Требования к протоколам сетевого оборудования
3.7. Требования к коммутаторам
3.8. Требования к системе видеоконференцсвязи
Приложение 4
Требования к помещениям и инженерным системам центров
обработки данных
4.1. Требования к помещениям
4.2. Требования к структурированным кабельным системам
4.3. Требования к электроснабжению
4.4. Требования к системам кондиционирования и холодоснабжения
4.5. Требования к системам раннего обнаружения пожара и газового пожаротушения
4.6. Требования к комплексным системам безопасности
Каталог рекомендованных конфигураций (КРК)
1. Общие положения
Основные положения технической политики в области информационных технологий (далее – Техническая
политика ИТ) разработаны в соответствии с поручением Правления ОАО РАО «ЕЭС России» (протокол от
07.11.2006 № 1564пр/1) и являются документом по обеспечению функционирования ИТ-инфраструктуры
ОАО «Московская объединенная электросетевая компания» (далее – ОАО «МОЭСК»).
Соблюдение требований Технической политики ИТ является обязательным для ОАО «МОЭСК».
1.1. Цели и задачи Технической политики ИТ
Цель Технической политики ИТ - это повышение эффективности и качества производственной деятельности ОАО «МОЭСК», путем определения основных направлений и требований для оптимального развития
ИТ-инфраструктуры и наиболее полного соответствия возможностей ИТ-инфраструктуры потребностям,
описанным в концепции автоматизации МРСК-РСК, на каждой фазе реализации.
Техническая политика ИТ содержит совокупность технических требований и рекомендаций, определяет
правила унификации и типизации технологий и оборудования, использование которых направленно на повышение качества ИТ-обеспечения сбора, обработки и хранения информации в информационных системах управления ОАО «МОЭСК».
Эффективная, современная и надежная ИТ-инфраструктура должна отвечать следующим основным требованиям:
соответствие используемых технических решений масштабам бизнес-задач, бизнес-целям и бизнесстратегиям ОАО «МОЭСК»;
предоставление необходимой ИТ-инфраструктуры для решения текущих и перспективных задач управления электросетевым комплексом;
унификация и типизация элементов ИТ-инфраструктуры для снижения общей стоимости владения (ТСО);
структуризация ИТ-инфраструктуры на центры обработки данных (ЦОД) различного уровня для повышения надежности, отказоустойчивости и безопасности используемых решений;
соответствие международным и российским стандартам в области ИТ, а также лучшим мировым практикам при построении ИТ-инфраструктуры.
Развитие в ОАО «МОЭСК», информационных технологий на основе современных организационно-экономических и технологических подходов позволит обеспечить выполнение бизнес-функций и увеличение
капитализации компании.
Основные направления развития информационных технологий связаны:
с улучшением управляемости распределительным комплексом за счет полного сквозного информационно-технологического обеспечения бизнес-процессов;
с реализацией и развитием единого информационно-технологического пространства;
с обеспечением постоянной ориентации ИТ на поддержку выполнения бизнес-целей и согласованием
долгосрочных планов развития ИТ со стратегическими целями бизнеса;
с переходом к целевому, процессно-ориентированному, прозрачному и управляемому информационнотехнологическому обеспечению;
с повышением экономической эффективности информационно-технологического обеспечения за счет
сокращения стоимости владения инфраструктурой и конкурентоспособности ИТ.
Основные задачи, требующие решения в рамках реализации Технической политики ИТ:
стандартизация применяемых решений и интерфейсов;
сертификация используемых средств;
унификация и сокращение числа информационных систем;
оптимальная сбалансированная централизация планирования, управления и закупок;
комплексная интеграция компонентов ИТ между собой и с внешними системами;
интенсификация использования материальных и людских ресурсов, организация эффективного обучения и переподготовки персонала ИТ и конечных пользователей;
организация эффективного сопровождения и поддержки систем, в том числе за счет активного управляемого аутсорсинга;
модернизация и замена оборудования и программного обеспечения;
унификация структур (служб, отделов), занятых в комплексе ИТ.
1.2. Ожидаемый эффект от реализации Технической политики ИТ
Эффективность деятельности ОАО «МОЭСК», достигается за счет следующих факторов:
надежности работы сетей путем исключения ошибок в оперативно-технологическом управлении и
уменьшения ограничений по пропускной способности, позволяющих снизить вероятность и длительность ограничений или прекращения подачи электроэнергии потребителям;
снижения потерь при передаче электроэнергии;
уменьшения вероятности и длительности периодов снижения качества электроэнергии на всех этапах
ее транспортировки и распределения;
сокращения расходов по управлению и эксплуатации сетей.
Организация вертикально-интегрированной структуры целевого информационно-технологического обеспечения позволит повысить эффективность информационных и телекоммуникационных систем за счет
их совместного использования и унификации, освободить бизнес-подразделения от рутинных и непрофильных видов деятельности, обеспечить выполнение требований информационной безопасности.
Существенным фактором явится возможность концентрации ограниченных ресурсов на решении наиболее приоритетных задач деятельности, прежде всего связанных:
с обеспечением бесперебойного снабжения потребителей электроэнергией;
со снижением простоев и отказов работы оборудования электросетей;
с сокращением затрат на ремонты и обслуживание оборудования;
с повышением капитализации ОАО «МОЭСК».
Кроме прямой экономии будет получен эффект от:
оперативного получения достоверной информации о фактическом состоянии деятельности управляемых компаний на различных уровнях в любой момент времени (прозрачность);
существенного снижения производственных издержек, связанного с минимизацией влияния «человеческого фактора».
Реализация настоящей Технической политики обеспечит возможность получения достоверной и полной информации в целях обеспечения эффективности управления. Наличие стандартных решений в ОАО
«МОЭСК», и согласованных интерфейсов позволит руководству компании получать необходимую оперативную информацию в режиме on-line.
В целом по всей структуре ОАО «МОЭСК» можно выделить следующие возможные источники эффективности, связанные с развитием и внедрением ИТ:
снижение сроков и объемов затрат на ликвидацию аварий, ремонт и проведение обслуживания оборудования энергосетей за счет внедрения системы управления ТОРО;
уменьшение величины накладных расходов, включая расходы административно-управленческого аппарата, за счет более качественного планирования, внедрения системы документооборота;
122
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
снижение закупочных цен на материалы за счет внедрения системы управления материально-техническим снабжением и системы управления взаимоотношениями с поставщиками, что приводит к сокращению себестоимости по основной деятельности;
увеличение объема реализации по основной деятельности за счет внедрения системы управления взаимоотношениями с клиентами;
оптимизация структуры активов/обязательств за счет внедрения систем управления финансами и инвестициями;
увеличение объема ввода новых объектов в срок за счет внедрения систем управления инвестициями
и проектами;
оптимизация доли планируемого ремонта в составе ремонтных работ за счет внедрения системы управления ТОРО;
продление срока службы оборудования за счет внедрения системы ТОРО;
снижение потерь и недоотпуска электроэнергии за счет интеграции ERP-систем и АСТУ и представления полной и оперативной информации для принятия управленческих решений.
1.3. Нормативно-техническое обеспечение ИТ-деятельности
Настоящая Техническая политика ИТ опирается на следующие нормативные документы ОАО РАО «ЕЭС
России», ОАО «ФСК ЕЭС» и ОАО «МОЭСК»:
концепция технической политики ОАО РАО «ЕЭС России» (утверждена приказом ОАО РАО «ЕЭС России»
от 12.11.2004 № 660);
стандарт предоставления услуг в области информационных технологий Холдинга ОАО РАО «ЕЭС России» (утвержден решением Правления ОАО РАО «ЕЭС России» от 07.09.2005 № 1289пр/1);
стандарт управления услугами в области информационных технологий Холдинга ОАО РАО «ЕЭС России» (утвержден решением Правления ОАО РАО «ЕЭС России» от 07.09.2005 № 1289пр/1);
система стандартов по организации закупочной деятельности в ОАО РАО «ЕЭС России» и ОАО «ФСК
ЕЭС» (утверждены приказами ОАО РАО «ЕЭС России» от 14.04.2004 № 177 и от 21.07.2005 № 473);
концепция повышения эффективности управления ИТ-деятельностью в Холдинге ОАО РАО «ЕЭС России» (утверждена решением Правления ОАО РАО «ЕЭС России» от 28.11.2005 № 1351пр/2);
основные положения Технической политики Холдинга в области информационных технологий ОАО
РАО «ЕЭС России» (утверждены решением Правления ОАО РАО «ЕЭС России» от 07.11.2006 №
1564пр/1);
концепция автоматизации МРСК-РСК (утверждена Первым заместителем Председателя Правления ОАО
«ФСК ЕЭС» Чистяковым А.Н. 30.12.2005);
стандарт по управлению деятельностью по предоставлению ИТ-услуг в ОАО «ФСК ЕЭС» (утвержден решением Правления ОАО «ФСК ЕЭС» от 10.10.2006 № 275);
стандарт по управлению деятельностью по предоставлению ИТ-услуг в ОАО «МОЭСК» (утвержден решением Совета директоров ОАО «МОЭСК» от 15.10.2005 г. №12);
временное положение о проведении сертификации программного обеспечения и программно-технических комплексов для МРСК-РСК (утверждено совместным распоряжением ОАО РАО «ЕЭС России» и
ОАО «ФСК ЕЭС» от 23.08.2006 № 214р/211р).
Техническая политика ИТ предназначена не только для ИТ-служб, но и для представителей других департаментов, служб и организаций, подведомственных ОАО «МОЭСК» (ДЗО).
В частности она может быть полезна:
руководству ДЗО в части планирования перспектив развития и учета вопросов развития ИТ-инфраструктуры в общей стратегии развития предприятия;
МОСКВА 2008
123
службе закупок ДЗО - для формирования конкурсных документов на ИТ-оборудование и услуги;
службам, ответственным за стратегическое планирование, в части учета требований по перспективному развитию ИТ-инфраструктуры с учетом рекомендованных горизонтов планирования;
службе по работе с персоналом ДЗО - для составления квалификационных требований к ИТ-персоналу
и программ повышения его квалификации.
Техническая политика ИТ развивает положения вышеуказанных нормативных документов ОАО РАО «ЕЭС
России» , ОАО «ФСК ЕЭС» и ОАО «МОЭСК» по следующим направлениям:
рекомендации ДЗО по вопросам развития ИТ-инфраструктуры;
требования к типизации и унификации ИТ-инфраструктуры;
требования к поставщикам ИТ-продукции и услуг;
требования к элементам ИТ-инфраструктуры и их размещению;
перечень рекомендуемых технических параметров оборудования и конфигурационных решений.
1.4. Адаптация и развитие политики
В качестве инструмента контроля за внедрением Технической политики ИТ используется Каталог рекомендованных конфигураций (КРК). Данный каталог должен содержать перечень типовых элементов ИТинфраструктуры, рекомендованных к использованию в ОАО «МОЭСК». Основная цель создания КРК провести унификацию используемого оборудования и программного обеспечения и обеспечить целостность, управляемость и безопасность ИТ-инфраструктуры. Рекомендации по созданию КРК приведены в
главе 4 настоящей Технической политики ИТ. В качестве методических рекомендаций к составлению КРК
в приложениях приведены рекомендуемые требования к техническим параметрам элементов ИТ-инфраструктуры.
2. Современные тенденции в области ИТ
В современных подходах к построению и управлению информационно-вычислительными средами рассматривают не «отдельный компьютер» или «программу» и даже не «программно-аппаратный комплекс».
Вместо этого оперируют понятиями «ИТ-сервис» и «ИТ-ресурсы».
С точки зрения данного подхода, основные задачи, стоящие перед современными ИТ-подразделениями,
- это:
построение ИТ-инфраструктуры в соответствии с требованиями бизнес-подразделений;
сохранение и повышение качества предоставляемых ИТ-сервисов;
обеспечение безопасности и непрерывности функционирования сервисов (информационных систем);
сокращение общей стоимости владения ИТ (Total Cost Ownership - далее TCO).
При построении ИТ-инфраструктуры в ОАО «МОЭСК», рекомендуется использовать следующие современные подходы и технологии:
консолидацию ресурсов;
виртуализацию ресурсов;
современную архитектуру приложений;
средства интеграции приложений;
современную коммуникационную инфраструктуру.
124
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
2.1. Консолидация ресурсов
Современная ИТ-инфраструктура и, прежде всего коммуникационная среда создают предпосылки для консолидации приложений и данных в современных Центрах обработки данных - ЦОД.
С точки зрения бизнеса, данная модель построения ИТ-инфраструктуры обеспечивает более высокую:
эффективность за счет снижения ТСО (прежде всего затрат на обслуживание и сопровождение ИТ-систем и снижения капитальных затрат на обеспечивающую инфраструктуру);
непрерывность (доступность) приложений за счет более высокой степени резервирования и отказоустойчивости программно-аппаратных средств, применяемых в централизованных ЦОД.
При построении и модернизации ИТ-инфраструктуры рекомендуется рассматривать четыре вида консолидации ресурсов:
1. Централизация (Centralization) - консолидация географически распределенных серверов в одном или
нескольких ЦОД.
2. Консолидация данных (Data Consolidation) - консолидация баз данных и/или устройств хранения для достижения более высокой доступности и управляемости данными.
3. Физическая консолидация (Physical Consolidation) - объединение серверов под управлением одной и той
же операционной системы и с подобными приложениями на более мощных системах.
4. Консолидация приложений и хранилищ данных (Application Consolidation) - размещение различных
приложений на «больших» серверах с разделяемыми разделами или mainframe.
В качестве оценки текущей или планируемой консолидации ресурсов можно применять понятие «рейтинга
консолидации», определяемое как количество серверов entry level, low end и middle range класса, которые
были заменены или могут быть заменены на одну систему более высокого класса. Рекомендованные значения данного показателя находятся в диапазоне 15-20 единиц. Практика показывает, что общая стоимость владения консолидированным решением значительно ниже, чем стоимость владения его
различными компонентами в случае их раздельной установки.
Консолидация ресурсов должна производиться с учетом административных уровней управления, в соответствии с отдельно разрабатываемым нормативным документом «Политика информационной безопасности при проектировании, внедрении и эксплуатации информационно-телекомуникационных систем».
2.2. Виртуализация ресурсов
Современное понятие «виртуализация ресурсов» включает в себя технологии и программные средства,
разработанные различными производителями, такие как: выделение ресурсов по требованию, виртуальные машины, эмуляторы операционных сред, разбиение ресурсов на логические разделы.
В части серверной виртуализации основные предпосылки применения технологий следующие:
неуклонное повышение мощности единичного сервера, зачастую превышающее потребности конкретного приложения;
большое число наследуемых приложений на устаревающих операционных системах и аппаратных платформах;
тенденции к консолидации ИТ-инфраструктуры.
Рекомендуется использовать технологии и средства виртуализации ИТ-ресурсов при построении ИТ-инфраструктуры.
Варианты виртуализации зависят от целей и платформ, для которых она применяется. Основными средствами виртуализации для Windows-платформ являются виртуальные машины или эмуляторы опера-
МОСКВА 2008
125
ционных сред, дополнением к ним служат технологии кластеризации и технологии миграции виртуальных
машин в любых возможных направлениях: P2V (Physical To Virtual), V2P (Virtual to Physical) и V2V (миграция между платформами виртуализации).
Технологии виртуализации для серверов класса Enterprise и операционных систем high availability различаются у разных производителей серверов данного класса и базируются на основе разделения вычислительных ресурсов на логические разделы (partitions).
2.2.1. Логическое разделение вычислительных комплексов
Технология аппаратных и программных разделов (partitioning) - это архитектурный подход к корпоративной ИТ-инфраструктуре, позволяющий виртуализировать аппаратные ресурсы и сделать их доступными
для множества независимых операционных сред. Изначально разработанная для mainframe эта технология позволяет разделить один сервер на несколько полностью независимых аппаратных или программных
виртуальных серверов или логических разделов. Технология с небольшими различиями поддерживается
ведущими производителями ИТ-оборудования. Технологии partitioning в сочетании с планами восстановления после сбоев и восстановления после катастроф (DRS - Disaster Recovery System и DRP - Disaster Recovery Plan) и с использованием двух разнесенных ЦОД (основного и резервного) создают основу
катастрофоустойчивой инфраструктуры таким образом, что приложение и разделы с критическими приложениями, выполняемые в Основном ЦОД, могут переключаться на Резервный ЦОД с минимальными потерями и прозрачно для пользователей приложений.
2.3. Современная архитектура приложений
Рекомендуется отдавать предпочтение ИТ-решениям, имеющим современную, сервис-ориентированную
многоуровневую архитектуру.
2.3.1. Сервис-ориентированная архитектура
Наиболее перспективная архитектура построения приложений на настоящее время – Service Oriented Architecture (SOA – сервис-ориентированная архитектура). На данный момент более 60% компаний рассматривают сервис-ориентированную архитектуру как основу для построения и выполнения своих
бизнес-приложений. При этом в ближайшие два-три года большинство производителей будут использовать технологии, основанные на Web-сервисах в качестве расширения существующих решений.
Основная задача SOA – облегчить интеграцию приложений как новых программных решений, так и систем
предыдущих поколений. Архитектура SOA независима от языков программирования, платформ или протокольных спецификаций, с помощью которых сервисы разрабатываются, а также от того, где и каким способом они развернуты. Архитектура SOA требует наличия не только сервисов, но и средств, с помощью
которых эти сервисы могут быть обнаружены и подключены, а также таких компонентов, как: серверы приложений, связующее ПО, репозиторий, специализированные пакеты централизованного управления SOA.
2.3.2. Многоуровневая архитектура клиент-сервер
В настоящее время большинство информационных систем проектируются с использованием трехуровневой архитектуры, представляющей информационную систему в виде совокупности трех компонент: сервера
баз данных, сервера приложений, отвечающего за выполнение логики приложения, и клиентского приложения или клиентского интерфейса («тонкий клиент»). Основными преимуществами выделения логики
приложения в отдельную составляющую являются возможность повторного использования логики приложения, легкость корректировки компонентов, повышение производительности используемого сервера
базы данных, возможность масштабирования системы в целом и независимость системы от конкретного
производителя системы управления базами данных. Кроме того, системы, построенные в трехуровневой
126
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
архитектуре, существенно проще и дешевле в эксплуатации, так как все исправления и конфигурационные
настройки вносятся централизованно.
Составляющие трехуровневой архитектуры:
уровень представления (реализующий функции ввода и отображения данных);
прикладной уровень (реализующий универсальные сервисы, а также функции, специфичные для определенной предметной области);
уровень доступа к информационным ресурсам (реализующий фундаментальные функции хранения и
управления информационно-вычислительными ресурсами).
2.4. Средства интеграции приложений
Для построения интегрированной ИТ-инфраструктуры, особенно при использовании различных программно-аппаратных сред, рекомендуется использовать специализированные программные средства - Интеграционные платформы. Интеграционная платформа должна обеспечивать доступ в реальном масштабе
времени к различным информационным ресурсам, обмен и синхронизацию данных между ними, автоматически, по заданным правилам и расписанию - поддержку единого стандарта обмена информацией между
приложениями, независимо от платформ, на которых они существуют.
Базовые функциональные возможности должны включать в себя средства проверки корректности, очистки,
объединения структурированных и неструктурированных данных, репликации данных и публикации информации о событиях, а также средства корпоративного поиска.
Продукты такого типа, как правило, строятся на принципах сервис-ориентированной архитектуры и предназначены для решения задач обеспечения достоверности информации в масштабе организации, контроля
качества данных, их преобразования, перемещения и объединения, а также управления метаданными.
Применение данных технологий позволяет, с помощью соответствующих сервисов, предоставляемых приложениям, процессам и отдельным пользователям, быстро сопоставить, согласовать и объединить разрозненные данные, поступающие из различных источников.
2.5. Современная коммуникационная инфраструктура
Для построения корпоративных Сетей передачи данных рекомендуется применять технологии построения
виртуальной частной сети на базе MPLS/VPN, с использованием услуг, предоставляемых крупными телекоммуникационными операторами национального масштаба. Передачу голосовых и видео данных также
рекомендуется использовать сети на базе MPLS/VPN, с использованием в местах предоставления услуг
IP-конвергентных решений.
Построение сетевой инфраструктуры рекомендуется производить на базе современных принципов построения сети, обеспечивающих гарантированное качество сетевых услуг (QoS).
Необходимое для этого резервирование каналов осуществляется телекоммуникационными операторами,
в том числе с использованием спутниковой связи.
Архитектура таких сетей состоит из четырех основных компонентов, а именно:
1. Интеллектуальная сетевая инфраструктура на базе протокола IР.
2. Интеллектуальные клиентские места с поддержкой протокола IР.
3. Служебные серверные приложения.
4. Современные пользовательские приложения.
Основа архитектуры - распределенность сети, благодаря которой система легко масштабируется. За счет
этого сетью можно охватить одно здание или несколько стоящих рядом зданий, объединенных высоко-
МОСКВА 2008
127
скоростной локальной сетью, предоставить в сети сервисы телефонии, видео и данных для пользователей
удаленных офисов и подразделений, объединенных IР-сетью.
Защита данных в сетях передачи данных, как во внутренних, так и во внешних, должна строиться на базе
отдельно разрабатываемого нормативного документа - Политики информационной безопасности при
проектировании, внедрении и эксплуатации информационных систем.
2.6. Единое информационно-технологическое пространство
Важной характерной особенностью ИТ в ОАО «МОЭСК» является необходимость поддержки и управления
федеративными данными (поступающими в единый центр из различных филиалов и подразделений). Под
этим понимается архитектура, которая обеспечивает управление и доступ к данным и метаданным независимо от их внутренней логической структуры и физических границ их расположения в целях организации взаимодействия систем и различных подразделений внутри организации и с внешними организациями.
Для эффективного использования этих данных необходима разработка общей метамодели, которая позволяет управлять отношениями между различными «оригинальными» моделями данных и делать их,
таким образом, прозрачными на корпоративном уровне. Суть федеративных данных состоит в одинаковом
определении на некотором новом уровне абстракции общих элементов данных для различных информационных систем компании. В результате должно быть организовано единое информационно-технологическое пространство (ЕИТП), охватывающее все организации, подведомственные ОАО «МОЭСК».
ЕИТП - это совокупность баз данных, технологий их ведения и использования, информационно-телекоммуникационных систем и сетей, организационных структур, функционирующих на основе общих принципов и по общим правилам, обеспечивающих информационное взаимодействие участников ЕИТП, а также
удовлетворение их информационных потребностей.
Для построения ЕИТП создаваемое информационное обеспечение должно удовлетворять следующим требованиям:
1. Стандартизация бизнес-процессов и нормативной базы - это стандартизация разрозненных систем
управления, единых подходов к управлению предприятиями отрасли, единых рыночных механизмов
деятельности на базе стандартного программного обеспечения (ПО), стандартных наборов оборудования и сервисных продуктов.
2. Централизация общих технологий и компетенций - стандартизованные потребности (единые ERP-системы, ПО, серверные системы, бизнес-приложения и т.п.) должны обеспечиваться из единого центра
или из крупных региональных центров. Компетенции, которые необходимы для удовлетворения этих
потребностей, программные продукты и оборудование концентрируются в этих центрах.
3. Оптимальный баланс централизации сервисов и компетенций - те потребности, которые не могут быть
удовлетворены централизованным образом, удовлетворяются путем обслуживания пользователей «на
местах», при этом оперативные службы сохраняют свою локализацию в местах возникновения потребностей.
Важнейшим условием реализации ЕИТП является создание типовых проектных решений (ТПР). ТПР - ПО
или программно-технический комплекс (ПТК), позволяющие автоматизировать какой-либо общий для всех
организаций-участников вид деятельности (например, бухгалтерский и налоговый учет, планирование и
бюджетирование и т.п.). Еще одним условием реализации ЕИТП является сертификация внедряемых ТПР
(см. раздел 8 настоящего документа).
128
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Реализация ЕИТП может основываться на преимущественном использовании хранилищ данных, содержащих «очищенную» и достоверную информацию для стратегического управления и интеграции между различными подразделениями. Такие хранилища должны строиться с использованием универсальных средств
и обеспечивать работу как со структурированной информацией, такой как записи в реляционных базах данных, так и с более общим содержанием - документами, графическими и мультимедийными данными.
ЕИТП предоставляет оперативный доступ (при наличии, естественно, соответствующих прав доступа) с любого рабочего места ко всем видам данных, возникающих и накапливаемых в системе. Информация, порождаемая в любой точке, становится доступна всем заинтересованным пользователям. Соответственно,
распоряжения и поручения руководства, решения и выводы специалистов доставляются автоматически (например, средствами электронной почты) до всех адресатов. Становится возможной групповая работа специалистов одного или нескольких подразделений, в том числе территориально удаленных друг от друга, над
общими проектами или документами на своих рабочих местах. ЕИТП, естественно, подразумевает создание надежных эффективных каналов связи между структурами и их подразделениями в масштабах ОАО «МОЭСК».
Использование ЕИТП обеспечивает прозрачность управления. Это достигается за счет однородности информационных источников и потоков, сопоставимости любой структурированной информации, возможности быстрого доступа к любой информации из любой точки входа, высокого уровня информационной
безопасности, единых стандартов качества обслуживания.
ЕИТП позволяет также унифицировать основные бизнес-процессы в ОАО «МОЭСК». Создаются предпосылки для реализации прогрессивного процессного подхода к ведению бизнес-процессов, обеспечивается
возможность централизованного управления ходом бизнес-процессов. При этом все участники бизнеспроцессов - руководство, менеджеры, исполнители - имеют прямой доступ к единой информационной
среде. В результате каждый бизнес-процесс строго регламентируется, система не позволяет отклоняться
от установленной последовательности действий. Вместе с тем имеется возможность оперативно корректировать любой бизнес-процесс (проводить его реинжиниринг).
Таким образом, создание ЕИТП в ОАО «МОЭСК» позволит существенно повысить качество управления
электросетевым комплексом.
3. Организация управления ИТ
3.1. Задачи управления ИТ
В связи с усилением роли ИТ в деятельности ОАО «МОЭСК», и существующим разрывом между требуемым
и текущим состоянием становится необходимым проведение реформы системы управления ИТ.
Базовыми принципами этой реформы являются следующие:
механизм принятия решений в области информационно-технологического обеспечения формализован, утвержден и неукоснительно соблюдается всеми подразделениями и участниками;
осуществляется централизованное управление основными ИТ-ресурсами;
реализация существенных новшеств в сфере информационно-технологического обеспечения рассматривается и выполняется как проект, причем этот проект имеет бизнес-обоснование и бюджет, а его руководитель непосредственно отвечает за достижение поставленных целей в рамках бюджета;
локальные действия/инициативы организаций на местах проводятся только в рамках единого механизма принятия решений и бюджетирования;
система управления информационно-технологическим обеспечением направлена на повышение эффективности инвестиций, качества управления ресурсами и снижение издержек.
МОСКВА 2008
129
3.2. Методология управления ИТ
Организация управления ИТ должна строиться в соответствии с рекомендациями Стандарта предоставления услуг в области информационных технологий в Холдинге ОАО РАО «ЕЭС России» и Стандарта управления услугами в области информационных технологий в Холдинге ОАО РАО «ЕЭС России»,
утвержденными решением Правления ОАО РАО ЕЭС России (протокол от 07.09.2005 № 1289пр/1), а также
Стандарта по управлению деятельностью по предоставлению ИТ-услуг в ОАО «ФСК ЕЭС», утвержденного
решением Правления ОАО «ФСК ЕЭС» (протокол от 10.10.2006 № 275), Стандарт по управлению деятельностью по предоставлению ИТ-услуг в ОАО «МОЭСК» (утвержден решением Совета директоров ОАО
«МОЭСК» от 15.10.2005 г. №12).
Они являются сводом требований, которым в обязательном порядке должны соответствовать как внутренние, так и внешние ИТ-структуры, оказывающие услуги в сфере информационных технологий для всех
ДЗО ОАО РАО «ЕЭС России». Допускается использование стандартов управления ИТ, принятых в организациях, подведомственных ОАО «МОЭСК», и не противоречащих указанным стандартам ОАО РАО «ЕЭС
России», ОАО «ФСК ЕЭС» и ОАО «МОЭСК» (далее - Стандарты управления ИТ).
3.2.1. Уровни зрелости управления ИТ
Управление (как процесс) ИТ является наиболее важным элементом, так как правильная реализация данного элемента позволит эффективно управлять всеми другими элементами.
Эффективность бизнеса
Стабильные
высокая
эффективность
Спорадические
низкая
эффективность
Ра
оде
ие м
звит
Сегодня
Реактивное
управление ИТ
• Неформальные операционные процессы и
модель управления
• Нестандартизированные
процессы принятия
решений
• Акцент на удовлетворение потребностей в
ресурсах в краткосрочной перспективе
• Не полный мониторинг
производительности работ
Базовый уровень
пр
ли у
ав ле
ния
ИТ
Целевой
уровень
Базовые компоненты
• Наличие Управляющего комитета по вопросам ИТ с четко определенными ролями
• Наличие четко определенных процессов
и ключевых заинтересованных сторон и
распространение соответствующей
информации
• По всем проектам, превышающим определенный порог, имеются ТЭО
• В рамках всей организации последовательно применяется стандартный шаблон ТЭО
• Согласованные между всеми заинтересованными сторонами объективные
критерии приоретизации проектов для
оценки преимуществ и рисков
• Набор сбалансированных метрик и
базовых показателей для управления ИТ
Перспектива развития
• Проактивная вовлеченность бизнеса
• Сформированные органы по принятию
бизнес/ИТ решений
• Согласование инвестиций в ИТ и бизнес
приоритетов
• Повышение эффективности является основным
движущим фактором
• Баланс между краткосрочными/долгосрочными
планами, рисками/поощрениями
• Совместный процесс приоритезации проектов
между бизнес/ИТ
• ИТ управляется на основе четких критериев
производительности
• Мониторинг показателей сбалансированной
системы показателей
• Поощрение связано с результатами деятельности,
постоянно применяются ключевые показатели
эффективности
Этап зрелости модели управления ИТ
Мировой
уровень
Рис. 1. Этапы зрелости модели управления ИТ.
Основные мероприятия по достижению целевого уровня зрелости (см. рис. 1):
определить органы управления, роли, сферы ответственности и регламенты деятельности управляющих органов;
использовать шаблон технико-экономического обоснования (ТЭО) для стандартизации запросов на
утверждение проекта;
130
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
определить пороговые значения для рассмотрения проектов на заседаниях органов управления ИТ;
не реже 1 раза в год сверять концепцию автоматизации и техническую политику в области ИТ на соответствие стратегическим бизнес-задачам;
применять систему сбалансированных показателей для оценки эффективности управления ИТ;
внедрить регистр учета рисков.
Внедрение модели управления ИТ позволит получить следующие преимущества:
точное и своевременное внедрение системы сбалансированных показателей повысит производительность ИТ при более низких расходах;
использование обоснованного утверждения основных проектов приведет к их четкому пониманию и
поддержке бизнес руководством;
участие в процессе пересмотра Проектного офиса по вопросам ИТ повышает степень информированности представителей бизнеса о возможностях повышения эффективности работ в соответствующих
сферах ответственности;
наличие четкого структурированного процесса утверждения, приоритезации и переутверждения проектов (в случае изменения объема работ, бюджета) даст более точное соответствие расходов на ИТ потребностям бизнеса.
3.2.2. Модель разработки планов по ИТ
Основные мероприятия по достижению целевого уровня зрелости:
стратегия в области ИТ, состоящая из концепции автоматизации и технической политики, должна определяться бизнес-потребностями;
планы ИТ должны балансировать долгосрочную (3 года) и краткосрочную (12 месяцев) перспективу:
долгосрочная стратегия ИТ используется Правлением и уточняется ежегодно (см. рис. 2);
план на краткосрочную перспективу используется Координационным советом по ИТ для контроля
расходов, ресурсов, результатов и статусов проектов и проходит ежемесячные проверки;
все проекты в области ИТ должны иметь утвержденное на соответствующем уровне комплексное описание проекта;
приоритезация проектов должна производиться по критерию преимущества/риски.
Исходны е данны е
для стратегии
Процесс ежегодной разработки стратегии ИТ
Описание
Описание
текущего
текущего
состояния
состояния
Бизнес подразд
Другие
функциональные
департаменты
Оценка
Оценка недостатков
недостатков
ии разработка
разработка
пути
пути реализации
реализации
стратегии
стратегии
Согласование
Согласование
отдельны
отдельныхх
потребностей
потребностей
Разработка
Разработка
бизнес
бизнес
плана
плана
Вы
Выработка
работка
планам
планам
мероприятий
мероприятий
Определение
Определение
будущего
будущего
состояния
состояния
Корпоративны е
департаменты
План и
показатели
Новы е
возможности ,
проекты
Реализация
Реализация
проектов
проектов
Постоянная
актуализация
бизнес
потребностей
Планирование
Планирование ии
Бю
Бюджетирование
джетирование
проектов
проектов
Скользящее
краткосрочное
планирование
Мониторинг
Мониторинг ии
контроль
контроль
Актуализация
Актуализация
проекта
проекта
Рис. 2. Схема ежегодного уточнения стратегии в области ИТ.
МОСКВА 2008
131
Развитие системы по разработке стратегии и планов ИТ позволит получить следующие преимущества:
стратегия в области ИТ будет обеспечивать согласованность развития ИТ с бизнес–потребностями;
стратегия в области ИТ будет постоянно уточняться, что будет обеспечивать ее адекватность потребностям;
бизнес руководители смогут повышать уровень знаний в области ИТ;
проекты будут приоритезированы точно в соответствии со стратегией;
утвержденная стратегия ИТ всегда в актуальном состоянии.
3.2.3. Модель разработки и внедрения решений в области ИТ
Основные мероприятия по достижению целевого уровня зрелости:
необходимо максимизировать возможности для повторного использования уже внедренных решений;
необходимо вовлекать пользователей на всех стадиях внедрения решений, от начальной до конечной;
необходимо внедрить, использовать и актуализировать технический инструментарий:
средство разработки ТЭО;
инструмент управления проектами.
Организация Проектного офиса по управлению вопросами ИТ (см. рис. 3) значительно повышает вероятность полного и своевременного выполнения проектов:
Куратор проекта
Руководитель ИТ
ИТ архитектор
Менеждер
проекта
Разработчик
решений
Команда
проекта
Помощник
менеджера проекта
Рис. 3. Схема организации Проектного офиса по управлению вопросами ИТ.
стандарт предоставления услуг в Холдинге РАО «ЕЭС России» в области управления проектами определяет роль и ответственность менеджеров проекта;
проектный офис по управлению вопросами ИТ характеризуется:
высокой степенью аутсорсинга в процессе выполнения проекта;
работники временно вовлекаются в процесс управления проектом ИТ;
менеджеры проектов привлекаются в основном на временной основе;
только такие роли, как офис поддержки проекта и управление портфелем проекта, могут определяться как постоянные;
Примерная структура Проектного офиса по управлению вопросами ИТ:
руководитель Департамента ИТ, архитектор ИТ и ассистент проекта выполняют ключевые функции
и помогают менеджеру проекта;
спонсор проекта, менеджер проекта и внутренняя проектная группа временно работают в Проектном офисе по управлению вопросами ИТ, а также выполняют свою основную работу;
разработчик решения - это работник внешнего подрядчика, привлеченного к выполнению проекта.
132
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
решение об организации Проектного офиса по управлению вопросами ИТ должно приниматься Координационным советом по ИТ.
Рациональная организация разработки и внедрения решений ИТ позволит получить следующие преимущества:
внедряются хорошо проработанные решения;
экономятся время и деньги в процессе разработки при обеспечении качественного и надежного результата;
пользователям прививаются понимание и навыки, необходимые для использования новых решений.
3.2.4. Модель предоставления услуг ИТ
Основные шаги по внедрению базовой модели:
модель оказания услуг, описанная в Стандартах предоставления ИТ-услуг в ОАО РАО «ЕЭС России»,
должна реализовываться поэтапно;
по всем запросам на обслуживание в каждом регионе должно быть определено единое контактное
лицо;
структуры и процессы оказания услуг должны быть стандартизированы для дальнейшей централизации процессов;
необходимо ввести соглашения о качестве предоставляемых ИТ-услуг в целях повышения уровня обслуживания и внедрить бизнес-отношения в области ИТ, что также способствует дальнейшей оптимизации ИТ.
Клиент
Клиент
Поль
Пользователи
зователи
Услуги
Услуги
SLAs
SLAs
Потребители
Потребители
Запросы
Запросы
Управление
Управление
обслуживанием
обслуживанием
Обслуживание
Обслуживание
клиентов
клиентов
Контроль
Контроль
обслуживания
обслуживания
Управление
Управление
деятельностью
ю
деятельность
Операцион-
Операционное
ное обслуобслуживание
живание
OLAs
OLAs
Запросы
Запросы
Операционная
Операционнаядеятельность
деятельность
Рис. 4. Схема организации ИТ-сервиса.
Необходимо постепенно совершенствовать ИТ-сервис, используя модель «песочных часов» (см. рис. 4),
а именно:
совершенствовать существующие взаимоотношения с клиентами;
четко определять, измерять и представлять отчетность по оказанным услугам в рамках бизнеса;
выполнение работ должно соответствовать требованиям к услугам;
ориентация на оказание услуг.
МОСКВА 2008
133
Характеристики модели «песочные часы»:
организация, ориентированная на потребителя, состоящая из нескольких департаментов, способных
разделять ежедневное предоставление услуг от проектов, связанных с внедрением изменений;
охватывает подразделения, управляющие взаимоотношениями с клиентами, управляющие предоставлением услуг потребителям, внедряющие новые услуги и занимающиеся ежедневным оказанием услуг;
формирует основу высокоуровневого организационного дизайна.
Структуры и процессы оказания услуг должны быть стандартизированы в целях обеспечения централизации.
При наличии специалистов с необходимыми навыками и соответствующей инфраструктуры ИТ могут быть
централизованы следующие службы:
служба поддержки;
обслуживание приложений;
разработка приложений;
администрирование систем;
управление телекоммуникациями.
Предпосылки централизации:
стандартизация организационных подразделений;
стандартизация процессов;
унифицированная инфраструктура и приложения;
введение соглашений об уровне обслуживания (SLA).
Предпосылки введения соглашений об уровне обслуживания (SLA):
утвержденный и стандартизированный каталог услуг (см. Стандарт предоставления услуг в области информационных технологий Холдинга ОАО РАО «ЕЭС России», утвержденный решением Правления ОАО
РАО «ЕЭС России» от 07.09.2005 № 1289пр/1);
стандартизированные процессы оказания услуг (имеется спецификация, реализовано в соответствии
со Стандартом управления услугами в области информационных технологий Холдинга ОАО РАО «ЕЭС
России», утвержденным решением Правления ОАО РАО «ЕЭС России» от 07.09.2005 № 1289пр/1);
унифицированная ИТ-инфраструктура и приложения;
руководители бизнеса обучены до среднего уровня ИТ-грамотности;
установлены и утверждены цены на обслуживание в области ИТ.
В результате могут быть получены следующие преимущества:
четкий и понятный процесс оказания услуг;
одна точка контакта обеспечивает более легкую и гибкую поддержку пользователей;
централизация и стандартизация обеспечивают эффективность и более высокий уровень навыков обслуживающего персонала;
внутренние соглашения об уровне обслуживания обеспечивают измерение предоставляемых услуг и
устанавливают четкие взаимоотношения в рамках бизнеса;
централизованное дистанционное обслуживание повысит надежность предоставления ИТ-услуг (локальный ИТ-сервис останется там, где это будет признано рациональным).
134
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
3.2.5. Модель управления архитектурой ИТ
Основные предлагаемые шаги по внедрению базовой модели:
ввести роль архитектора ИТ для систематического развития архитектуры ИТ (см. рис. 5).
Руководитель
ИТ
Разработка
ИТ
Архитектор
ИТ
Оказание
ИТ услуг
Рис. 5. Схема руководства развитием архитектуры ИТ.
внедрить процедуры оценки и выбора комплексного ПО для подготовки решений руководства и снижения капитальных затрат;
архитектура инфраструктуры должна выбираться в соответствии с лучшей практикой и международными стандартами;
необходимо оптимизировать сети для централизации предоставления ИТ-услуг;
необходимо обеспечить непрерывность предоставления ИТ-услуг;
необходимо документировать, вести учет и по мере необходимости корректировать архитектуру ИТ.
Развитие системы по управлению архитектурой ИТ позволит получить следующие преимущества:
архитектор ИТ может в целом контролировать архитектуру ИТ, обеспечивая постепенное интегрированное ее развитие;
архитектор ИТ, подотчетный только CIO, будет иметь возможность оказывать влияние и участвовать во
всех проектах;
корпоративная сеть обеспечит централизацию ИТ-услуг;
стандартизированная инфраструктура повысит эффективность оказываемых услуг;
стандартный процесс выбора приложений обеспечит качество и соответствие бизнес-требованиям.
3.2.6. Модель управления ресурсами ИТ
Основные шаги по внедрению базовой модели:
интегрировать процесс подготовки и утверждения бюджета ИТ в процесс ежегодного бюджетного планирования (см. рис. 6);
сформировать программу постоянного обучения персонала для повышения навыков и эффективности;
сформировать центры компетенций для более эффективного использования навыков и компетенций;
разработать решение для сбора, хранения, анализа и обмена информацией и знаниями.
Развитие системы по управлению ресурсами ИТ позволит получить следующие преимущества:
управление знаниями позволяет получать информацию и делиться лучшей практикой между различными организациями;
система бюджетирования ИТ, являющаяся частью общей системы бюджетирования, обеспечит выделение надлежащих ресурсов;
обучение собственных кадров сократит зависимость от внешних поставщиков услуг и увеличит эффективность собственной работы.
МОСКВА 2008
135
центры компетенций или центры повышения квалификации позволят расширить возможности специалистов в части внесения улучшений в процесс.
Янв
Февр Март Июнь Июль Авг
Сент
Окт
Нояб
Дек
Нояб
Дек
Ежегодный процесс корпоративного бюджетирования
Янв
Февр Март Июнь Июль Авг
Ежегодный процесс
ИТ бюджетирования
Сент
Окт
Управление программой
Изменение
Оценка Старт
Планирование
Ежегодное стратегическое
планирование
Бюджетирование
Корректировка Контроль и управление
ИТ стратегии
взаимосвязных
в середине года
инициатив
Оценка по карте
сбалансированных
ПРИМЕЧАНИЕ: Если время проведения работ не указано,
показателей
это не означпет постоянного их проведения
Бюджетирование в соответствии
со «Стандартом предоставления
услуг в области
информационных технологий
в холдинге РАО «ЕЭС России»
Оценка и планирование
проекта, ресурсов,
Навыков и возможностей
Рис. 6. Схема процесса бюджетирования в области ИТ.
3.2.7. Модель сорсинга
В соответствии со Стандартами управления ИТ должна быть принята одна из следующих моделей сорсинга:
инсорсинг - использование внутренних специализированных подразделений для оказания ИТ-услуг;
аутсорсинг - передача функций по оказанию ИТ-услуг на исполнение во внешнюю по отношению специализированную Сервисную Организацию;
смешанная модель - ряд сервисов предоставляется собственным Сервисным подразделением организации (Инсорсинг), другие сервисы предоставляются внешней Сервисной организацией (Аутсорсинг).
С учетом значительного разнообразия используемых программных продуктов и технических средств наиболее целесообразным представляется выбор смешанной модели.
В данной модели в организации должны быть созданы две вертикали управления в части ИТ:
директор по ИТ - Служба Заказчика в части ИТ-услуг;
руководитель Сервисной службы ИТ - Сервисная служба ИТ.
Основные принципы разделения ответственности:
за управление ИТ отвечает Директор по ИТ (стратегический уровень управления) и Служба Заказчика
(тактический и оперативный уровни управления);
служба Заказчика отвечает за удовлетворение ИТ-потребностей бизнес-подразделений и контролирует
исполнение контрактов на ИТ-услуги;
сервисная служба ИТ, как правило, не подчиняется административно ни Директору по ИТ, ни Службе
Заказчика;
ИТ-персонал организации, оказывающий ИТ-услуги, находится в составе Сервисной службы ИТ.
136
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Служба Заказчика управляет ИТ в части:
взаимоотношений с бизнесом;
ИТ-бюджета и контроля ИТ;
ИТ-архитектуры и стандартов;
информационной безопасности и соответствия нормативно-правовым требованиям;
технологий и инноваций.
При этом служба Заказчика является единой (и единственной) точкой контакта по вопросам ИТ для бизнес-подразделений организации.
Сервисная Служба ИТ - организационная структура, осуществляющая деятельность в форме инсорсинга
и входящая в состав организации. Она выполняет следующие функции:
поставщика ИТ-услуг конечным пользователям;
сопровождения и эксплуатации информационных систем.
3.2.8. Модель распределения процессов между организациями
При распределении процессов между ОАО «МОЭСК» - ОАО «ФСК ЕЭС» (Департамент информатизации и
Центр управления межрегиональными распределительными сетевыми комплексами), МРСК-РСК, прочими
ДЗО - гибридная (федеральная) модель организации ИТ является наиболее приемлемой, так как позволяет
использовать знания и навыки специалистов на всех уровнях и способствует совершенствованию общей
координации и контроля.
Преимущества гибридной (федеральной) модели (см. также рис. 7):
адекватное реагирование на внешние изменения, адаптивность к изменяющимся условиям бизнеса;
высокая ориентированность на потребителей благодаря высокому уровню владения и вовлечения в
ИТ-процессы различных организаций, которым нужны решения, адаптированные под потребителей;
быстрая разработка решений благодаря стандартизации, более полному пониманию нужд потребителя,
совместному использованию информации.
Недостатки
Неотзывчивость
Отсутствие ответственности за результат
Отсутствие контроля
бизнес с подразделением
за черезмерными затратами
центра
Не отвечает
потребностям
каждого бизнес
подразделения
Функциональное
лидерство в
области ИТ
Целостная
перспектива развития
организации
Пользователи
Экономия от
корректируют
масштаба
ивестиции в ИТ
Подразделение
Контроль
несет ответстандартов
ственность за
результат
Экспертиза
в предметной
Соответствие
области
потребностям
бизнес
подразделений
Централизованная модель
Сконцентрированный
сбыт
Недостатки
Избыточная общая
стоимость группы
Меняющиеся стандарты
компетенции в ИТ
Повторное изобретение
колеса
Отсутствие
синерпии
Децентрализованная модель
Синерпия
Достоинства гибридной модели
Рис. 7. Преимущества использования гибридной (федеральной) модели организации ИТ.
использование технологических достижений. В быстро меняющихся технологических условиях ограниченные квалифицированные людские ресурсы компании являются стратегическим активом и должны
использоваться максимально эффективно. По своей структуре федеральная модель обеспечивает
условия для этого;
МОСКВА 2008
137
контроль затрат путем централизованного оказания услуг. В условиях конкуренции компаниям необходимо контролировать и минимизировать свои затраты. Обеспечивая поддержку структуре объединенного
оказания услуг и необходимую поддержку в процессе ее контролирования, федеральная модель позволяет компаниям получить, где это возможно, максимальную экономию от больших масштабов.
Стратегическое руководство ИТ в ОАО «МОЭСК», осуществляет ОАО «ФСК ЕЭС» (Департамент информатизации и Центр управления межрегиональными распределительными сетевыми комплексами), которое:
разрабатывает и утверждает концептуальные документы в области ИТ;
организует сертификацию программных продуктов и программно-технических комплексов.
На организации уровня ОАО «ФСК ЕЭС» - МРСК возлагаются функции утверждения программ развития,
проведение централизованных конкурсов (торгов) и контроль за отчетностью.
Организации уровня РСК являются ответственными за поддержку информационных систем - самостоятельно каждая в своей зоне. При этом в область их ответственности входят такие вопросы, как:
формирование и согласование с вышестоящей организацией (МРСК или его филиалами) Программ
развития информационных технологий;
внедрение утвержденных изменений информационных систем;
подготовка материалов к конкурсам на приобретение оборудования, материалов и программного обеспечения;
контроль исполнения договоров поставки и внедрения;
формирование отчётности для вышестоящей организации.
Вне зависимости от типа применяемой модели управления ИТ основным принципом взаимодействия ИТслужб с бизнес-подразделениями должна являться модель провайдера услуг. При этом под ИТ-услугой
понимается комплекс процессов, активов и ресурсов, направленных на удовлетворение потребности бизнеса компании в информационных технологиях, возникающей в процессе деятельности. Результат предоставления услуги имеет явно выраженную ценность для бизнеса и формулируется в терминах
бизнес-пользователя.
Такой подход находится в соответствии с принятой мировой практикой для крупных международных компаний. По оценкам компании Gartner, внедрение такой системы позволяет добиться эффективного сокращения операционных расходов до 40-45%.
Методологической основой для реализации такого подхода является ITIL (IT Infrastructure Library), которая
представляет собой достаточно полное описание лучшей практики организации процессов управления информационными технологиями в организации. Основная идея связана с предложенным в ITIL принципом
сервисного подхода к реализации функций управления информационными системами. В соответствии с
этим принципом ИТ-служба (Служба Заказчика), с одной стороны, обеспечивает предоставление ИТ-услуг
бизнес-подразделениям, с другой - выступает от имени организации (бизнес-подразделений) получателем этих услуг со стороны внешних организаций (или собственной Сервисной службы).
При взаимодействии Службы Заказчика с поставщиком ИТ-услуг должен использоваться механизм соглашений об уровне обслуживания (Service Level Agreement - SLA). Это позволяет гарантировать качество
ИТ-услуг, предоставляемых пользователям. Важным преимуществом такого подхода является тот факт, что
потребитель (бизнес-подразделение) заказывает не отдельные ИТ-сервисы, такие, как администрирование
сервера или подключение работника к сети, а услугу в целом, которая обладает определенной ценностью
для бизнеса (например, поддержка работы бухгалтерской системы и т.п.).
Для повышения качества управления ИТ рекомендуется создание в организациях уровня ОАО «ФСК ЕЭС»
- МРСК коллегиального управляющего органа. В его состав должны войти директора по ИТ подведомственных организаций, руководители Служб Заказчика и Сервисных Служб ИТ, руководители бизнес-подразделений.
138
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
В функции такого органа входит:
обсуждение бюджета ИТ организации и выработка рекомендаций;
определение приоритетов развития ИТ;
оценка качества взаимодействия служб ИТ и бизнес-подразделений;
выработка предложений по реализации крупных проектов в области ИТ и контроль за ходом их выполнения.
3.3. Поддержка пользователей
Важную роль в организации предоставления ИТ-услуг играет сервисная служба поддержки пользователей (Service Desk). Эта служба должна сочетать функции единой точки обращения всех пользователей к
внутренней сервисной организации по оперативным вопросам (Call Center), оказания помощи по работе с
компонентами ИТ (Help Desk), а также сама оказывать определенные услуги на рабочих местах.
Сервисная служба поддержки пользователей должна оказывать содействие по всем проблемам ИТ,
включая:
проблемы с инфраструктурой (клиентские места, сети, серверы, аппаратное обеспечение и операционные системы);
проблемы при работе с приложениями;
вопросы, связанные с такими процедурами, как перемещение, обучение, модернизация (upgrades).
3.4. Стратегия коммуникации
Одним из ключевых факторов успеха при реализации Технической политики ИТ является создание и эффективная работа совместных команд с участием как специалистов ИТ, так и бизнес-подразделений, а
также четкое определение и разделение ответственности между ними. При этом должно быть достигнуто
согласованное понимание проблем, целей и задач, как со стороны непосредственных участников процесса,
так и со стороны руководства организаций.
Для решения этой задачи необходимо предусматривать постоянное активное информирование всех категорий участников и руководителей в соответствии с их интересами, а также гласное и открытое обсуждение целей и хода реализации преобразований. Такая стратегия коммуникации, помимо периодической
отчетности в соответствии с положениями о коллегиальных органах управления ИТ, должна включать следующие элементы:
регулярные обсуждения требований к ИТ и приоритетных задач с руководством и ведущими специалистами бизнес-подразделений;
региональные и отраслевые совещания с приглашением руководителей подведомственных организаций по вопросам перехода к новой модели предоставления ИТ-услуг и последующего развития модели;
целевое информирование бизнес-подразделений о возможностях новых технологий на специализированных семинарах;
постоянное предоставление информации о ходе реализации Технической политики через Интранет и
внутренние информационные бюллетени.
3.5. Стратегия сорсинга
Существенным элементом в работе Службы Заказчика ИТ является формирование стратегии выбора исполнителей отдельных работ и проектов - так называемой стратегии сорсинга.
МОСКВА 2008
139
Разработка стратегии сорсинга должна проводиться с учетом следующих факторов:
тактические и долгосрочные цели бизнеса. При этом определяется, как цели бизнеса влияют на роль
ИТ в организации, каковы задачи ИТ с точки зрения развития бизнеса;
внутренняя эффективность ИТ - насколько эффективно предоставляются данные ИТ-услуги внутренними ИТ-подразделениями;
внешние возможности рынка ИТ-услуг. Какие ИТ-услуги и сервисы доступны на рынке при удовлетворительном соотношении «цена/качество»;
модели сорсинга. Каковы наилучшие практики применения моделей сорсинга? Какие из существующих
моделей ИТ-сорсинга применимы для отдельных функциональных областей деятельности организации
(процессов и поддерживающих их систем)?
управление сорсингом - данный фактор определяет оптимальные и эффективные средства управления ИТ-услугами и взаимоотношениями с внешними провайдерами ИТ-услуг.
Стратегия сорсинга может быть комбинированной, то есть для разных компонентов информационных технологий могут применяться различные модели.
3.6. Целевые показатели эффективности ИТ
Качественной характеристикой эффективности ИТ обычно является интегральная оценка бизнес-подразделениями соответствия реальной ситуации ожиданиям. Для количественной оценки может быть использована система объективных обобщенных показателей эффективности, которые характеризуют как
финансовую сторону вопроса, так и степень удовлетворения пользователей со стороны ИТ (как хорошо это
делается?). Комплекс таких показателей должен быть разработан и утвержден для каждой организации
уровня ОАО «ФСК ЕЭС» - МРСК.
Эти показатели должны определяться на основе постоянного контроля процессов и мониторинга состояния компонентов ИТ, включая:
инструментальный мониторинг состояния компонентов ИТ;
мониторинг состояния реализации проектов в области ИТ;
оценка качества предоставления ИТ-услуг со стороны потребителей.
Инструментальный мониторинг состояния представляет собой развитие традиционных систем управления
сетевыми ресурсами и реализуется с помощью специализированных программных средств. Основная задача - это определение состояния компонентов ИТ на уровне доступности бизнес-услуг. Для этого в состав
информационной системы включаются специализированные агенты-серверы, которые периодически осуществляют выполнение типичных бизнес-запросов путем обращения к базам данных, формирование тестовых сообщений и файлов и т.п. Данные о результатах и времени выполнения запросов регистрируются,
а сводная информация представляется в виде информационной панели (dashboard).
Мониторинг состояния проектов в области ИТ также будет использовать средства интерактивного представления, позволяющие сформировать наглядную картину состояния в плане уровня завершенности, соответствия бюджету, наличия отклонений и уровне риска. Это позволит постоянно иметь объективную
картину состояния и при необходимости принимать управляющие воздействия.
Качество уровня услуг определяется на основе выяснения мнения пользователей относительно степени
удовлетворенности услугами ИТ. Такие опросы (анкетирования) должны проводиться регулярно, не менее
2 раз в год по всем бизнес-подразделениям. Кроме того, возможно проведение выборочных оценок среди
пользователей по фактам их обращений в справочную службу на предмет их удовлетворенности качеством, сроками и результативностью обслуживания.
140
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
3.7. Управление активами ИТ
С учетом значительной величины капитальных затрат на ИТ, особенно актуальна четкая организация процессов
управления существующими активами и закупками новых активов (имеются в виду как аппаратные средства,
так и ПО). При этом должно обеспечиваться улучшение обслуживания при одновременном снижении затрат
путем управления всем жизненным циклом средств ИТ, начиная с приобретения и заканчивая их списанием.
Для обеспечения эффективного управления активами ИТ целесообразно внедрение специализированной
системы учета, которая должна быть интегрирована с процессами, используемыми для организации снабжения, списания активов и управления изменениями.
Основными источниками эффекта от внедрения системы управления активами ИТ могут являться:
сокращение расходов на приобретение лицензий и их поддержку за счет применения корпоративных
соглашений и более точного управления профилем пользователей;
снижение расходов за счет использования схем лицензирования на одновременно работающих пользователей, вместо именованных или постоянных;
уменьшение расходов на установку и обновления версий ПО на рабочих местах, на оборудование за
счет более рационального использования и получения объемных скидок.
Вопросы организации закупок оборудования, программного обеспечения и услуг в части ИТ рассмотрены
в разделе 6 настоящей Технической политики ИТ.
3.8. Управление проектами и разработкой прикладных систем
Реализация проектов должна быть поддержана специализированной системой управления проектами, учитывающей передовой международный опыт индустрии создания ИТ и базирующейся на международных
стандартах и рекомендациях в этой области. Она включает в себя технологию управления этими проектами, определяющую состав процессов управления и их логическую последовательность, систему стандартов, регламентирующих наиболее ответственные моменты технологии управления, а также
программные инструментальные средства, выполняющие наиболее трудоемкие функции управления процессами и повышающие качество и надежность самого управления.
Принципиальными моментами реализации проектов разработки прикладных программных систем
являются:
формирование модели синхронизации глобальных и локальных релизов;
группировка изменений в пакеты и сокращение числа выпускаемых версий, что позволит улучшить качество за счет более полного и тщательного тестирования;
организация и внедрение сквозного процесса управления качеством разработки;
развитие кадрового потенциала и компетенций за счет непрерывного обучения и внедрения лучших
практик;
внедрение систем проектного учета ресурсов.
4. Управление ИТ-инфраструктурой
4.1. Оценка необходимости изменений в ИТ-инфраструктуре
При организации деятельности ИТ-службы рекомендуется использовать сервисный подход, основы которого изложены в Стандарте управления деятельностью по предоставлению ИТ-услуг в ОАО «МОЭСК». При
таком подходе деятельность ИТ-службы - это оказание качественных и надежных услуг, удовлетворяющих требованиям других подразделений компании.
МОСКВА 2008
141
С помощью сервисного подхода осуществляется:
организация ИТ в соответствии с требованиями бизнес-процессов;
использование описаний ИТ-услуг (сервисов) на языке, понятном их пользователям;
управление ИТ в терминах предоставляемых услуг (сервисов);
управление затратами на использование предоставляемых услуг (сервисов);
измеримость результатов инвестиций в ИТ и оптимизация совокупной стоимости владения (TCO) услугами (сервисами).
При решении задач управления ИТ-инфраструктурой важное значение имеют процессы, связанные с изменениями ИТ-инфраструктуры. Технические решения, связанные с изменениями ИТ-инфраструктуры,
должны быть обоснованы, в том числе с учетом оценки их влияния на стоимость и качество услуг, оказываемых ИТ-службой, и реализованы с учетом приведенных ниже рекомендаций по внесению изменений и
планированию ИТ-инфраструктуры.
При оценке необходимости изменений необходимо также учитывать современные направления развития
информационных технологий, возможность внедрения новых продуктов, позволяющих расширить текущий
функционал. Для оценки эффективности изменений рекомендуется организовывать внедрение новых разработок в пилотных зонах, с последующим тиражированием в случае положительного эффекта. В проектах такого типа возможно использование тестовых версий ИТ-компонентов, участвующих в программах
публичного тестирования.
4.2. Проведение изменений в ИТ инфраструктуре
Процесс проведения изменений в ИТ-инфраструктуре - это процесс использования стандартизованных
методов и процедур, позволяющих осуществить изменения эффективно, своевременно и с минимальными негативными последствиями для бизнес-процессов.
При изменении ИТ-инфраструктуры необходимо учитывать требования, изложенные ниже.
4.2.1. Общие требования к тестированию и приемке изменений
Процесс тестирования и приемки изменений ИТ-инфраструктуры должен удовлетворять следующим
общим требованиям:
решение о проведении изменений должны приниматься Службой заказчика по согласованию с функциональными заказчиками. Служба заказчика вправе разработать упрощенный порядок принятия решений о проведении некритичных для бизнес-процессов изменений;
аеред вводом изменений в эксплуатацию необходимо разработать и протестировать план внесения изменений с обязательным указанием контрольных точек принятия решения об отказе от внесенных изменений и возврате системы в предыдущее состояние. Тестирование плана внесения изменений
необходимо производить в среде, аналогичной производственной;
тестирование и приёмку изменений необходимо производить в среде, аналогичной производственной.
4.2.2. Требования «разумного консерватизма»
При внедрении, модернизации, обновлении ИТ-компонентов должны быть соблюдены следующие общие
требования «разумного консерватизма»:
внедрение новых версий ПО должно иметь обоснованные преимущества перед используемыми версиями ПО и не должно ухудшать текущего состояния дел;
142
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
для критически важных бизнес-процессов недопустимо внедрение последних версий промышленного
ПО и/или его компонентов, за исключением используемых в схожей промышленной среде более 2 лет
и имеющих при этом не менее 2 корректирующих обновлений от производителя (релизов, патчей, сервис-паков, обновлений ПО и т.п.);
недопустимо использование тестовых версий ИТ-компонентов (альфа, бета версии ПО и т.п.) в режиме
промышленной эксплуатации;
при планировании внедрения новых версий ПО рекомендуется учитывать долгосрочные планы производителя по выпуску новых версий/релизов.
4.2.3. Автоматизация тиражирования обновлений ПО
Автоматизация тиражирования обновлений ПО должна выполняться с учетом следующих общих требований и рекомендаций:
создание и внедрение решения по автоматизации тиражирования обновлений ПО должно производиться в рамках отдельных проектов ИТ-службы и с использованием собственной серверной системы
тиражирования обновлений. Обновление ПО непосредственно с Интернет-портала производителя не
допускается;
функциональные возможности автоматизированной системы тиражирования обновлений должны позволять реализацию полного и упрощенного циклов управления изменениями, проводить автоматическую проверку (аудит) тиражирования обновлений;
тиражирование обновлений в области безопасности критичных для предприятия систем (обновления
операционных систем, ПО с непосредственным доступом во внешние сети / Интернет, антивирусные системы и т.п.) подлежит обязательной автоматизации;
тиражирование обновлений в области безопасности и функциональных обновлений на рабочие станции и инфраструктурные ИТ-компоненты (домен-контроллеры, DNS/DHCP-серверы и т.п.) в части системного и офисного ПО подлежит обязательной автоматизации;
рекомендуется автоматизация тиражирования обновлений клиентской части бизнес-приложений.
4.3. Планирование ИТ-инфраструктуры
При планировании ИТ-инфраструктуры должен быть обеспечен экономически обоснованный уровень соответствия ресурсов ИТ-инфраструктуры текущим и будущим потребностям деятельности организации. Для
эффективного планирования ИТ-инфраструктуры необходимо в первую очередь учитывать прогноз развития основной деятельности организации и технического развития ИТ. Поэтому для каждой организации
важное значение имеет выбор горизонтов планирования для различных ИТ-приложений и определение
базовой методики расчета производительности и объема хранимой информации для ИТ-систем.
4.3.1. Выбор периодов планирования для ИТ-приложений
Выбор периодов планирования ИТ-приложений должен определяться периодами планирования организации. При этом периоды планирования ИТ-инфраструктуры должны быть меньше, чем периоды планирования ИТ-приложений.
Рекомендуется исходить из следующих периодов планирования ИТ-приложений:
8-9 лет для приложений класса ERP и приложений управления ИТ, критичных для бизнеса;
5-6 лет для бизнес-приложений и систем операционного управления ИТ;
3-5 лет для офисных и системных приложений.
МОСКВА 2008
143
При этом для соответствующих элементов ИТ-инфраструктуры рекомендуется установить следующие горизонты планирования:
5-6 лет для приложений класса ERP и приложений управления ИТ, критичных для бизнеса;
3-4 года для бизнес-приложений и систем операционного управления ИТ;
2-3 года для офисных и системных приложений.
4.3.2. Расчет производительности и объема хранимой информации для ИТ-систем (масштабирование ИТ-систем)
Расчёт производительности ИТ-систем должен производиться в терминах ИТ-услуг, исходя из планируемых сроков использования (периодов планирования), объёмов, значений показателей уровня предоставления и производительности услуг.
При расчёте производительности подлежат учёту нагрузочные возможности всех задействованных в предоставлении ИТ-услуг компонентов: ИТ-систем, компонентов инфраструктуры и систем информационной
безопасности, включая клиентские рабочие станции.
При расчёте производительности ИТ-систем обязателен учёт как средних, так и пиковых показателей нагрузки. Рекомендуется для расчёта производительности использовать предоставляемый производителем
инструментарий - нагрузочные кривые и рекомендации.
В общем случае, в ходе расчёта рекомендуется проводить оценку загрузки по следующим компонентам:
сервер приложений;
сервер баз данных/СУБД;
системы информационной безопасности (антивирусное обеспечение, программный межсетевой экран,
криптографические системы и т.п.);
компоненты мониторинга (агенты и т.п.);
системное ПО;
аппаратная платформа (процессоры, оперативная память, дисковая подсистема, сетевой интерфейс);
сети хранения данных (SAN, NAS);
сети передачи данных, включая активные устройства (межсетевые экраны, маршрутизаторы и т.п.);
сетевые сервисы (Active Directory, DNS, DHCP, WINS и т.п.);
клиентские рабочие станции в аппаратной и программной части.
Для оценки объёма хранимой информации рекомендуется использовать собственные статистические данные по объёмам и динамике изменения данных за длительные (от 1 месяца) периоды и максимальные
значения в пиковые периоды. При отсутствии собственных данных допустимо использование статистики
схожих предприятий или экспертных оценок.
При оценке объёма хранимой информации обязателен учёт не только полезного объёма, но и объёмов системной и служебной информации (системы шифрования, файлы логирования, файлы журналов транзакций и т.п.).
5. Каталогизация и классификация элементов ИТ-инфраструктуры
5.1. Типизация элементов ИТ-инфраструктуры
Унификация и типизация элементов ИТ-инфраструктуры позволяет значительно снизить расходы и облегчить внедрение новых ИТ-решений, снизить затраты на подготовку ИТ-персонала, упростить сопровождение и обслуживание этих решений в будущем и, в конечном итоге, значительно снизить общую
стоимость владения ИТ-инфраструктурой в целом.
Под типизацией понимается снижение номенклатуры и повышение качества ИТ-элементов и конфигураций, внедряемых в ОАО «МОЭСК».
144
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Данная техническая политика определяет требования к следующим категориям ИТ инфраструктуры:
рабочим местам пользователей (ПК, периферийное оборудование);
мультисервисной сети (корпоративная сеть, внешние каналы связи);
прикладному ПО;
инфраструктуре центров обработки данных (системы хранения и резервирования, серверы, системное ПО);
Общие требования к указанным категориям и их отдельным элементам приведены в главе 6 настоящей Технической политики ИТ. При разработке технических политик и других нормативных документов в области
ИТ необходимо учитывать указанные требования.
В приложениях к Технической политике ИТ приведены рекомендуемые минимально допустимые технические требования к соответствующим категориям. При развитии ИТ-инфраструктуры в ОАО «МОЭСК», необходимо учитывать данные рекомендации. Также данные рекомендации необходимо учитывать при
разработке и внедрении Каталогов Рекомендованных Конфигураций.
5.2. Классификация по уровню использования
При построении современной ИТ-инфраструктуры для определения места установки (размещения) ИТ-решения необходимо провести классификацию данного решения в зависимости от совокупности следующих параметров: состава пользователей данной системы, степени агрегации информации, способа
хранения и обработки данных, решаемых задач, уровня сложности и т.д.
С точки зрения данной классификации рекомендуется выделить следующие классы или уровни инфраструктуры для размещения ИТ-систем:
центр обработки данных группы предприятий (ЦОД I уровня - ОАО «ФСК ЕЭС», МРСК) - обеспечивает
централизованное хранение и обработку данных в масштабе всей организации. Ресурсы данного ЦОД
используются для консолидации информации с нижележащих уровней, обеспечения информационного взаимодействия предприятий и оказания ИТ-сервисов всем подчиненным организациям;
центр обработки данных предприятия (ЦОД II уровня - РСК) - обеспечивает централизованное хранение
и обработку данных в масштабе одного достаточно крупного предприятия;
центр обработки данных подразделения (ЦОД III уровня) - обеспечивает централизованное хранение и
обработку данных в рамках небольшого предприятия, подразделения или здания.
В разделе 7.4 настоящей Технической политики ИТ содержатся общие требования к оборудованию ЦОД
различного уровня. Кроме того, в приложениях приведены текущие рекомендованные минимальные требования к ИТ-конфигурациям и их элементам (программно-аппаратным средствам, системам связи и коммуникаций). ИТ-конфигурации с заявленными характеристиками ниже приведенных минимальных
значений не рекомендуется закупать и вводить в эксплуатацию в ОАО «МОЭСК».
5.3. Классификация по уровню требуемой непрерывности обслуживания и
важности для бизнеса
Многие критические бизнес- и технологические процессы опираются на компьютерные системы обработки
и хранения данных и не могут функционировать без их использования. Поэтому обеспечение непрерывности обслуживания и доступности ИТ-решений является важнейшим показателем непрерывности бизнеса и важным классифицирующим фактором для элементов ИТ-инфраструктуры.
Исходя из предъявляемых бизнес-требований к надежности отдельных элементов и конфигураций ИТ-систем в целом и их восстановлению после сбоев и отказа оборудования, ПО или инфраструктурных элементов, современные ИТ-технологии предоставляют различные архитектурные и конфигурационные
решения, обеспечивающие эти требования.
МОСКВА 2008
145
С точки зрения обеспечения непрерывности обслуживания бизнес- и технологических пользователей и
процессов, а также требований к отказоустойчивости, можно предложить следующую классификацию ИТрешений:
Mission Critical - системы, работающие в режиме «боевого дежурства». К таким системам относятся: остро критические с точки зрения бизнеса или внешних факторов (например, экологии)
приложения, Центры управления сетью (ЦУС), технологические приложения, работающие в режиме реального времени. Выход из строя этих систем влечет за собой невосполнимые потери
для бизнеса, в том числе угрозу жизни и здоровью персонала. Рекомендованное время восстановления подобных систем после отказа – не более 10 минут. Для таких систем должны использоваться специализированные серверные платформы и инфраструктурные уровни с полным
многократным резервированием всех компонентов, в том числе с использованием резервных удаленных ЦОД;
Business Critical - системы, критические для бизнеса, с режимом работы 24х7х365. Выход из строя этих
систем влечет за собой значительные бизнес потери для предприятия. Рекомендованное время восстановления подобных систем после отказа не более 2-х часов. Для таких систем должны использоваться кластерные решения и инфраструктурные уровни с частичным резервированием используемых
компонентов;
Business Operational - обычные бизнес-приложения - системы, не требующие работы в реальном времени, с режимом работы 8х5. Рекомендованное время восстановления подобных систем после отказа
- 4-6 часов. Для таких систем рекомендуется использовать резервирование хранения данных и электропитания;
Office Production - не критические для бизнеса приложения, персональные данные. Выход из строя этих
систем не влияет на динамику КПЭ предприятия. Рекомендованное время восстановления подобных систем после отказа - 1-2 рабочих дня.
Необходимо учитывать, что общая непрерывность и отказоустойчивость ИТ-конфигураций определяется соответствующей непрерывностью и отказоустойчивостью ее отдельных элементов: аппаратных, программных средств и инфраструктуры, необходимой для их успешного функционирования
- каналов связи, системы электропитания и т.д. и, в конечном итоге, зависит от уровня непрерывности и отказоустойчивости его слабейшего компонента (принцип «слабого звена»). Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости должна быть одним из
решающих факторов при выборе уровня инфраструктуры (ЦОД) для размещения ИТ-систем. В разделе 6.4 Требования к инфраструктуре центров обработки данных (системы хранения и резервирования, серверы) содержатся общие требования к таким конфигурациям в разрезе ЦОД различного
уровня.
5.4. Принципы создания Каталога рекомендованных конфигураций
ОАО «МОЭСК», необходимо разработать и внедрить каталог рекомендованных конфигураций (КРК) для построения ИТ-решений. Данный каталог должен содержать перечень типовых элементов ИТ-инфраструктуры, рекомендованных к использованию согласно Технической политике ИТ. Основная цель создания
КРК - провести унификацию используемого оборудования и программного обеспечения и обеспечить целостность и управляемость ИТ-инфраструктуры.
При построении и развитии своей ИТ-инфраструктуры ОАО «МОЭСК», должно закупать и внедрять только
внесенные в указанный каталог ИТ-конфигурации. Закупка конфигураций, которые не входят в данный
список, возможна только в виде исключения при наличии обоснования.
Унификация ИТ-решений позволит добиться снижения общего TCO, что подразумевает снижение расходов на закупки, внедрение и эксплуатацию элементов ИТ-инфраструктуры.
146
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Каталог создается в каждой организации уровня ОАО «ФСК ЕЭС» - МРСК и должен содержать следующий
минимальный набор данных по рекомендованной конфигурации:
название конфигурации;
рекомендуемый набор аппаратных средств для данной конфигурации;
рекомендуемый набор программных средств для данной конфигурации.
При создании каталога рекомендованных конфигураций необходимо руководствоваться следующими основными принципами:
все конфигурации, включаемые в каталог, должны соответствовать общим требованиям к оборудованию и ПО, изложенным в разделе 6 настоящей Технической политики ИТ;
в качестве рекомендованных минимальных значений технических и функциональных параметров конфигураций необходимо использовать данные, приведенные в приложениях к настоящей Технической политике ИТ;
количество унифицированного оборудования и ПО в каждом функциональном разделе каталога должно
быть минимально;
рекомендуется использовать стандартное оборудование и ПО зарекомендовавшего себя на рынке производителя в данной области, который постоянно развивает и совершенствует свой модельный ряд;
каталог должен регулярно (не реже одного раза в год) пересматриваться и обновляться;
рекомендуется использовать аппаратно-программное обеспечение разного назначения одного и того же
производителя. Такое решение упрощает управление ИТ-инфраструктурой, позволяет снизить эксплуатационные затраты, а также стоимость вновь приобретаемого аппаратно-программного обеспечения;
для массовых, стандартных ИТ-конфигураций и их элементов рекомендуется включать в каталог решения не менее двух альтернативных производителей.
6. Требования к поставщикам, производителям и проведению конкурсов
При проведении закупок необходимо руководствоваться требованиями законодательства Российской Федерации, а также внутренних организационно-распорядительных документов, регламентирующих закупочную деятельность.
В настоящем разделе изложены основные требования, касающиеся выбора поставщиков программно-аппаратных комплексов и услуг, производителей программно-аппаратных комплексов, а также системных интеграторов, осуществляющих развёртывание ИТ-инфраструктуры.
Организация вправе при выборе поставщиков и производителей ориентироваться на более высокие требования, чем это предусмотрено в настоящей Технической политике ИТ.
6.1. Общие требования
К поставщикам и производителям рекомендуется предъявлять следующие общие требования:
деятельность поставщиков и производителей должна быть лицензирована, если это предусмотрено
Российским законодательством;
при подведении итогов конкурса, при прочих равных условиях, преимущество имеют те компании, производство которых отвечает требованиям стандарта системы менеджмента качества ISO 9001:2000
(ГОСТ Р ИСО 9001-2001). Причем в приложении к сертификату должна быть указана именно та деятельность, на предоставление которой претендует данная компания;
за последние три года участник конкурса должен успешно завершить, как минимум, два аналогичных контракта на поставку услуг, если он претендует на роль поставщика услуг, или на разработку, инсталляцию,
обеспечение технической поддержки для ИТ-систем, если он претендует на поставку программно-аппаратного обеспечения, аналогичных конкурсному предложению по параметрам и сопоставимых по масштабу;
МОСКВА 2008
147
минимально приемлемый среднегодовой оборот поставщика за последние три года не должен быть
меньше, чем сумма договора на поставку услуг или оборудования, умноженная на 5;
ключевые руководители поставщика должны иметь опыт успешной реализации, как минимум, двух
контрактов сопоставимого масштаба, из которых минимум один контракт должен быть реализован в
Российской Федерации.
6.2. Требования к поставщикам и производителям оборудования
К поставщикам и производителям программно-аппаратного обеспечения рекомендуется предъявлять следующие требования:
производитель аппаратного обеспечения должен иметь сертификат, выданный признанным органом по
сертификации, на соответствие своей системы менеджмента качества требованиям ISO 9001:2000 (ГОСТ
Р ИСО 9001-2001);
аппаратная платформа и программное обеспечение должны быть стандартизованы и сертифицированы на соответствие стандартам, считающимся общепринятыми в предметной области данного программно-аппаратного обеспечения, иметь гибкую и масштабируемую архитектуру;
предлагаемое поставщиком оборудование должно быть коммерчески доступно на протяжении не менее
трех месяцев, а программное обеспечение - не менее шести месяцев;
поставщики сложного программно-аппаратного обеспечения должны своевременно получать
сертификаты соответствия на всю гамму поставляемого оборудования и ПО в соответствии с
действующими техническими требованиями в полном объеме, а также обновлять сертификаты
при появлении новых версий программного и аппаратного обеспечения поставляемой продукции;
поставщик должен быть авторизован производителем на тот перечень услуг, которые поставщик будет
оказывать заказчику. При этом предпочтение должно отдаваться поставщикам, имеющим более высокий статус (уровень) отношений с производителем;
в случае поставки оборудования поставщик должен обладать собственным складом;
поставщик должен осуществлять страхование груза при доставке;
поставщик должен обладать сертифицированным техническим персоналом на ту предметную область,
в которой поставщик будет оказывать заказчику услуги;
предпочтение должно отдаваться производителям, поставляющим оборудование и ПО, адаптированное
для использования в Российской Федерации, если таковая адаптация возможна;
предпочтение должно отдаваться поставщикам, предоставляющим документацию на оборудование и
ПО на русском языке;
поставщики должны осуществлять гарантийную поддержку поставленного оборудования и ПО согласно требованиям к услугам по эксплуатации и сопровождению, приведенным ниже;
гарантийный срок на программно-аппаратное обеспечение начинается с момента приемки ПО или оборудования в эксплуатацию и должен продолжаться не менее 12 месяцев для аппаратного обеспечения
и 6 месяцев - для ПО;
поставщики программно-аппаратного обеспечения должны организовать на территории Российской Федерации центры обучения с целью первичного обучения специалистов, эксплуатирующих программно-аппаратное обеспечение, их переподготовки при внедрении новых версий и типов оборудования и ПО или
иметь договор со сторонним центром обучения, гарантируя при этом, что обучение на учебных курсах данного центра будет достаточно для эксплуатации поставляемого программно-аппаратного обеспечения.
148
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
6.3. Требования к поставщикам услуг
6.3.1. Общие требования к поставщикам услуг
К поставщикам услуг рекомендуется предъявлять следующие требования:
предпочтение должно отдаваться компаниям, предоставляющим услуги в соответствии с международными стандартами, принятыми для данного типа услуг. Данное соответствие рекомендуется документально подтверждать или наличием соответствующего сертификата, или выборочной проверкой
нормативных и рабочих документов;
поставщик услуг должен иметь сертифицированных специалистов как по функционалу предоставляемых
услуг, так и с точки зрения процессной организации предоставления услуг. В частности, рекомендуется учитывать соответствие бизнес-процессов поставщика рекомендациям ITIL и COBIT по предоставлению услуг;
при оказании услуг системной интеграции рекомендуется, чтобы поставщик имел внедренную у себя
на производстве систему управления проектами на основе лучших мировых практик, таких как рекомендации PMI и IPMA. Также предпочтение должно отдаваться компаниям, имеющим сертифицированных руководителей проектов, например, по системе PMI.
6.3.2. Требования к поставщикам услуг по эксплуатации и сопровождению
К поставщикам услуг по технической поддержке (сопровождению) и участникам конкурсов, проводимых
для поставки программно-аппаратного обеспечения, рекомендуется предъявлять следующие требования:
сервис-центр должен находиться в приемлемой удаленности от заказчика, чтобы иметь возможность
устранить неисправность с выездом к заказчику в сроки, установленные соответствующими регламентами взаимодействия, которые, в свою очередь, должны опираться на требования непрерывности,
готовности и доступности элементов ИТ-инфраструктуры;
эксплуатация сложного программно-аппаратного обеспечения, гарантийный срок на которое истек,
должна осуществляться на основе контракта на послегарантийное обслуживание. Указанный контракт
должен заключаться сервис-центром, расположенным на территории Российской Федерации и обеспечивающим послегарантийное обслуживание программно-аппаратного обеспечения данного типа. В
случаях, когда программно-аппаратное обеспечение применяется в ограниченных объемах и сервисцентр на территории Российской Федерации отсутствует, контракт на послегарантийное обслуживание
заключается непосредственно с фирмой-поставщиком или ее представительством;
в отдельных случаях допускается осуществлять послегарантийное обслуживание силами сервис-центра, организованного самой организацией, при наличии специалистов, прошедших соответствующее
обучение (что подтверждается сертификатами поставщика), необходимого оснащения, запасных частей и оформленных должным образом взаимоотношений с системой сервисной поддержки фирмыпоставщика или производителя;
эксплуатация сложного программно-аппаратного обеспечения, находящегося вне гарантийного срока,
без заключенного контракта на послегарантийное обслуживание или без наличия у ДЗО сервис-центра
не допускается;
поставщик услуг по эксплуатации и сопровождению оборудования должен обладать собственным складом запасных частей, который должен находиться в приемлемой удаленности от места установки оборудования;
поставщик услуг по эксплуатации и сопровождению должен быть авторизован производителем на эти
виды деятельности. При этом предпочтение должно отдаваться поставщикам, имеющим более высокий статус (уровень) отношений с производителем;
МОСКВА 2008
149
поставщик услуг по эксплуатации и сопровождению должен обладать сертифицированным техническим
персоналом;
поставщики сложного программно-аппаратного обеспечения должны силами сервис-центров, расположенных на территории Российской Федерации, осуществлять модернизацию находящегося в эксплуатации программно-аппаратного обеспечения с целью поддержания его на современном
техническом уровне и внедрения новых современных функций и услуг;
обслуживание и модернизация должны осуществляться для всех установленных типов оборудования
и ПО данного поставщика и для всех версий указанного оборудования и ПО, в том числе тех, поставки
которых закончились до вступления в силу настоящего документа.
сервис-центры поставщика услуг по эксплуатации и сопровождению должны обеспечивать:
поддержку пользователей, в соответствии с требованиями непрерывности, по телефону и с помощью электронной почты;
решение проблем, возникающих при работе программно-аппаратного обеспечения, в объеме, возложенном на данный сервис-центр;
возможность внесения оперативных коррекций в программное обеспечение, находящееся в эксплуатации, с использованием современных средств передачи информации (сетей передачи данных
и др.);
возможность выезда специалистов для устранения неисправностей в соответствии с установленным
регламентом. Рекомендуется использовать следующие требования для экстренного выезда специалистов: выезд специалиста в течение не более 12 часов и с прибытием на место в течение не
более 24 часов с момента обращения (без учета транспортных задержек, не зависящих от сервисцентра);
не допускается несанкционированное руководителем ИТ вмешательство (в том числе дистанционное) сервис-центров в работу находящегося в эксплуатации программно-аппаратного обеспечения;
срок ремонта или замены сервис-центром неисправных узлов оборудования не должен превышать
двух недель с момента передачи узла на сервис-центр. Для этого сервис-центр должен иметь необходимый комплект запасных узлов, а также, при необходимости, ремонтное оборудование и службы.
6.3.3. Требования к поставщикам услуг по обучению
Поставщики услуг должны удовлетворять следующим минимальным требованиям к обучению работников
заказчика:
уровень обучения должен быть достаточным для самостоятельной эксплуатации программно-аппаратного обеспечения в типичных ситуациях, возникающих в процессе эксплуатации. Квалификация
обучаемых должна подтверждаться соответствующими сертификатами, дающими право на эксплуатацию программно-аппаратного обеспечения данного типа;
пропускная способность центров обучения должна быть достаточной для того, чтобы обеспечивать
подготовку и переподготовку персонала для всего действующего и вновь вводимого программно-аппаратного обеспечения данного типа.
6.4. Требования к проведению конкурсов
Участники конкурсов, проводимых для поставки программно-аппаратного обеспечения и/или услуг,
должны соответствовать всем дополнительным требованиям, указанным для поставщиков и производителей в настоящей Технической политике ИТ, а также соответствовать всем основным требованиям, которые предъявляет Система стандартов по организации закупочной деятельности ОАО РАО «ЕЭС России»
(приказы ОАО РАО «ЕЭС России» от 14.04.2004 № 177 и от 21.07.2005 № 473).
150
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
7. Технические требования к элементам ИТ-инфраструктуры
Данные технические требования рассматриваются в разрезе лучших мировых практик по созданию ИТинфраструктуры для современных корпораций.
Отдельные требования предъявляются к следующим категориям инфраструктурных элементов:
рабочие места пользователей;
персональные компьютеры;
системное ПО рабочих мест пользователей;
периферийные устройства;
прикладное ПО;
корпоративная распределенная мультисервисная сеть;
инфраструктура центров обработки данных;
системы обработки и хранения данных;
помещения и инженерные системы;
информационная безопасность;
системы управления и мониторинга.
7.1. Требования к рабочим местам пользователей
В данном разделе рассматриваются общие требования к парку персональных компьютеров, эксплуатируемых в ОАО «МОЭСК», к системному ПО рабочих мест пользователей, а также к периферийным устройствам, входящим в ИТ-инфраструктуру организаций.
Ориентировочные минимальные технические характеристики указанного оборудования согласно рекомендациям Основных положений Технической политики Холдинга в области информационных технологий
ОАО РАО «ЕЭС России», утвержденных решением Правления ОАО РАО «ЕЭС России» от 07.11.2006 №
1564пр/1, представлены в приложении 2 к настоящей Технической политике ИТ.
7.1.1. Требования к персональным компьютерам
7.1.1.1. Общие требования
При развитии парка персональных компьютеров и выборе закупаемых моделей ПК необходимо руководствоваться следующими положениями:
аппаратная платформа и программное обеспечение персональных компьютеров должны быть стандартизованы и сертифицированы, иметь гибкую и масштабируемую архитектуру;
для обеспечения общего уровня услуг управление данными всех ПК должно быть унифицировано, то
есть для ПК должно быть организовано централизованное распространение программного обеспечения с помощью единого инструмента распространения обновлений программного обеспечения;
для повышения качества и скорости администрирования количество различных программно-аппаратных конфигураций персональных компьютеров должно быть ограничено. Рекомендуется использование не более 4 типовых конфигураций.
Для спецификации технических требований выделяются следующие ключевые параметры ПК:
Производительность
Производительность персональных компьютеров должна обеспечиваться за счет:
параметров быстродействия процессора;
объема оперативной памяти;
МОСКВА 2008
151
скорости внутренних шин передачи данных;
качества и быстродействия графической подсистемы;
устройств ввода/вывода.
Надежность
Надежность должна обеспечиваться за счет аппаратных средств и программного обеспечения и определяться исходя из среднего времени безотказной работы (MTBF).
Масштабируемость
Масштабируемость должна обеспечиваться архитектурой и конструкцией персонального компьютера за
счет возможности наращивания:
количества и мощности процессоров;
объемов оперативной и внешней памяти.
7.1.1.2. Требования к типизации конфигураций
Весь парк ПК предлагается разделить на следующие типовые конфигурации:
персональный компьютер для работы с бизнес-ориентированным прикладным ПО (офисные системы,
финансовые системы, ERP и т.п.);
VIP персональный компьютер для работы высшего руководства компании;
Графическая рабочая станция для работы с графическими пакетами, пакетами ПО моделирования,
САПР, АСКУЭ, АСУТП и пр. Используется для приложений с развитой графикой и высокими требованиями к производительности процессора;
ноутбук для работы мобильных пользователей. Допустимо отдельно выделить ноутбук для VIP пользователей.
7.1.2. Требования к системному ПО рабочих мест пользователей
Операционные системы (ОС) офисного назначения должны:
соответствовать по типу клиентским ОС;
поддерживать все сетевые сервисы, обеспечивающие функционирование корпоративной сети;
обеспечивать высокий уровень информационной безопасности;
быть совместимыми с корпоративным стандартом используемого офисного ПО.
7.1.3. Требования к периферийным устройствам
Рассматриваются требования к следующим классам периферийных устройств:
устройства печати (принтеры):
монохромные принтеры (персональные и группового использования);
цветные принтеры (персональные и группового использования) для офисной и фотографической печати;
цветные рулонные принтеры для дизайна, картографии (персональные и группового использования);
устройства сканирования:
сканеры персональные;
сканеры фотографические и дизайнерские;
сканеры широкоформатные;
многофункциональные устройства (МФУ):
персональные МФУ;
МФУ группового и корпоративного использования;
устройства копирования бумажных документов:
персональные копиры;
копиры группового использования;
копиры корпоративные - мини-типографии;
152
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
факсимильные аппараты.
Требования к специализированным устройствам, имеющим узкое технологическое применение (термопринтеры, принтеры штрих-кодов, наклеек, типографии), а также ко всем видам технологического периферийного оборудования, используемого в АСУТП, не рассматриваются. Использование
специализированного оборудования принимается на основе конкретных технических требований технологического процесса.
Для описания минимальных требований к периферийному оборудованию используется следующая классификация устройств:
персональное устройство - находится в постоянном использовании одним работником;
групповое устройство - используется в режиме разделения ресурсов группой работников;
корпоративное устройство - используется в составе ЦОД I или II уровней.
7.1.3.1. Общие требования
В данном разделе излагаются общие требования, которые необходимо применять при выборе и закупке нового периферийного оборудования в целях развития ИТ.
Периферийное оборудование должно отвечать следующим основным требованиям:
Производительность. Периферийное оборудование должно обеспечивать потребности бизнеса организации и удовлетворять требованиям, определенным в количественных показателях (например, количество копий в минуту, разрешение сканируемого изображения и т.д.);
Надежность. Периферийное оборудование должно позволять обеспечивать непрерывность бизнеспроцессов и удовлетворять требованиям, определенным в количественных показателях (MTBF);
Функциональность. В том случае, если рабочее место работника должно быть оборудовано несколькими
видами периферийного оборудования, следует отдавать предпочтение при закупке МФУ, которое
должно поддерживать все или большую часть следующих функций:
печатного устройства;
сканирующего устройства;
копировального устройства;
факсимильного устройства.
Совместимость. Периферийное оборудование должно сопрягаться технически и программно с персональными компьютерами, независимо от типа процессора и операционной системы. Минимально необходима совместимость с Windows 2000, XP;
Безопасность. Выход из строя какого-либо периферийного устройства не должен влиять на устойчивую работу персональных компьютеров с другим периферийным оборудованием;
Управляемость. Подключение и управление периферийным оборудованием должны быть простыми и
не требовать оперативного использования инструкций и описаний работы устройств;
Низкая стоимость владения. Запчасти и расходные материалы для периферийного оборудования
должны быть легко доступны и обладать невысокой стоимостью;
Низкий уровень создаваемого акустического шума. Периферийное оборудование в процессе работы не
должно создавать помех окружающим Уровень шума не должен превышать 55 дБ[A]. Для эксплуатации шумного оборудования должны быть предусмотрены специально выделенные помещения.
7.1.3.2. Требования к групповым и корпоративным устройствам
Для групповых и корпоративных устройств должны применяться более жесткие требования, нежели для
персональных устройств. При выборе групповых и корпоративных устройств необходимо исходить из
оценки количества пользователей, которые будут эксплуатировать данные устройства.
МОСКВА 2008
153
Помимо указанных выше общих требований, для групповых и корпоративных устройств необходимо рассмотреть наличие следующего функционала:
наличие клиентского приложения для ПК для приема и рассылки факсов, а также для сканирования документов;
поддержка формата А3;
потоковое сканирование документов с автоматическим преобразованием в нужный формат с поддержкой сетевого сохранения файлов.
Для МФУ должно обеспечиваться периодическое техническое обслуживание, которое будет способствовать более высокой доступности устройства и снизит TCO. Периодичность данного обслуживания необходимо определять из технических требований по эксплуатации каждого конкретного устройства.
7.2. Требования к мультисервисной сети
В данном разделе рассматриваются требования к распределенной мультисервисной сети: к ее архитектуре, протоколам и оборудованию.
Более детальные требования и технические характеристики мультисервисной сети с учетом рекомендаций Основных положений Технической политики Холдинга в области информационных технологий ОАО
РАО «ЕЭС России», утвержденных решением Правления ОАО РАО «ЕЭС России» от 07.11.2006 № 1564пр/1,
представлены в приложении 3 к настоящей Технической политике ИТ.
7.2.1. Требования к корпоративной распределенной мультисервисной сети
7.2.1.1. Общие требования
Основные положения и подходы к организации корпоративной распределенной мультисервисной сети
(КРМСС):
ориентация на архитектуру сетей следующего поколения (NGN).
Данная архитектура называется также архитектура softswitch (softswitch - пакетный коммутатор для сетей
нового поколения, является носителем интеллектуальных возможностей сети, координирует управление
обслуживанием вызовов, сигнализацию и функции, обеспечивающие установление соединения через одну
или несколько сетей). Данная архитектура позволяет, меняя версии ПО на Softswitch-ах и сами Softswitchи, расширять функциональные возможности без замены оборудования доступа. Кроме этого, согласно архитектуре IMS (Interactive Multimedia Subsystem), стандартизируется протокол предоставления сервисов, что
позволяет без доработки интерфейсов взаимодействия подключать любые услуги от любых сервис-провайдеров;
все сервисы должны предоставляться единой мультисервисной сетью, обеспечивающей качество обслуживания (QoS).
Телефония, аудиоконференцсвязь, видеоконференцсвязь и передача данных должны основываться на
единой конвергентной мультисервисной сети, которая позволяет предоставлять указанные сервисы, обеспечивая необходимый и достаточный уровень QoS;
распределенная корпоративная архитектура, обеспечивающая QoS;
высокая доступность и надежность сети;
производительность, управляемость и масштабируемость сети;
мультисервисная сеть должна проектироваться с учетом требований информационной безопасности.
Весь трафик классифицируется на следующие классы:
трафик реального времени (телефонный, аудио и видео);
154
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
трафик администрирования сети (SNMP и т.п.);
трафик систем технологического управления (АИИС КУЭ, АСУТП, ТМ и т.п.)
трафик систем управления предприятием (ERP, BI, e-mail и т.п.);
низкоприоритетный трафик (public Internet и пр.)
Приоритет обслуживания определяется в каждом конкретном случае в зависимости от важности соответствующего приложения. При этом пропускная способность сети и активное сетевое оборудование должны
всегда обеспечивать достаточное качество для трафика реального времени.
При аварийных ситуациях ресурсы сети должны отдаваться технологическому трафику, части трафика реального времени и пользовательского трафика в том объеме, в котором это необходимо для обеспечения
бесперебойной работы основного технологического оборудования и обслуживающего его персонала. Данные правила должны быть реализованы в настройках оборудования и вступать в силу при наступлении
аварийной ситуации.
7.2.1.2. Требования к архитектуре сети
Архитектура мультисервисной сети должна быть основана на следующих принципах:
строиться на трехуровневой модели;
иметь резервирование по оборудованию и каналам;
поддерживать VLAN;
архитектурно разбиваться на демилитаризованные зоны (ДМЗ);
сеть должна обеспечивать необходимую для бизнеса производительность;
сеть должна обеспечивать QoS для разных классов трафика.
Мультисервисная сеть должна проектироваться, исходя из трехуровневой модели коммутации:
уровень доступа (Access Layer) - коммутаторы 2-го уровня модели OSI с интеллектуальностью 3–4-го
уровней модели OSI (с целью обеспечения требований к сетевой безопасности, QoS и т. д.);
уровень распределения (Distribution Layer) - коммутаторы 3-4-го уровней модели OSI;
магистральный уровень / уровень ядра (Core Layer) - коммутаторы 3-4-го уровней модели OSI.
Выбранная архитектура сети должна позволять наращивать сеть путем добавления новых блоков, обеспечивать высокий детерминизм поведения сети, требовать минимальных усилий и средств для поиска и
устранения неисправностей. Интеллектуальные сервисы 3-го уровня модели OSI (в том числе протокол
OSPF) должны обеспечивать сокращение области, затрагиваемой при возникновении разнообразных проблем с неисправным или неверно настроенным оборудованием, а также балансировку нагрузки между
уровнями (внутри уровней) иерархии и быструю сходимость.
Должны быть соблюдены общие правила проектирования трехуровневой структуры:
любые проблемы с оборудованием и каналами связи на нижележащих уровнях не должны сказываться
на верхних уровнях;
транзитные резервные маршруты данного уровня не должны проходить через нижележащие уровни;
классификация и приоритезация трафика должны происходить только на уровне доступа. Уровень распределения должен только агрегировать трафик. Ядро сети должно осуществлять только быструю коммутацию пакетов;
время сходимости таблиц маршрутизации и их объем должны быть оптимизированы для каждого
уровня посредством выбора оптимальной схемы резервирования;
удаленные пользователи и внешние каналы связи не должны подсоединяться напрямую к ядру сети.
Необходимо использовать коммутаторы доступа для предотвращения лавинообразных перестроек таблиц маршрутизации всей сети.
МОСКВА 2008
155
Резервирование для ЦОД I уровня должно, а для ЦОД II уровня рекомендуется организовывать следующим образом:
в сети должно быть два коммутатора уровня ядра, связанные между собой по GigabitEthernet или 10 GigabitEthernet;
каждый коммутатор уровня доступа должен иметь соединения каналами Gigabit Ethernet с двумя коммутаторами уровня распределения;
каждый коммутатор уровня распределения должен быть соединен по каналам Gigabit Ethernet с двумя
коммутаторами уровня ядра;
в сети должно быть два пограничных маршрутизатора, которые должны быть связаны с двумя различными операторами связи, предоставляющими доступ в Интернет и услуги VPN между ЦОД I и II
уровня. Каждый пограничный маршрутизатор должен быть связан с двумя устройствами, обеспечивающими функциональность межсетевого экрана (МСЭ) или IDS/IPS.
Производительность сети для ЦОД I и II уровня должна быть обеспечена следующим образом:
поэтажные коммутаторы (коммутаторы доступа) должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet;
серверы должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet;
коммутаторы уровня распределения и ядра должны быть выбраны соответствующей производительности. При выборе уровня производительности необходимо учитывать требование поддержки всех требуемых протоколов с требуемым уровнем QoS;
между двумя зданиями рекомендуется прокладывать оптические каналы.
Надежность сети должна быть обеспечена при помощи выполнения следующих правил:
выход из строя любого устройства сети не должен приводить к отказу в работоспособности оконечных
устройств в количестве, превышающем количество портов в данном устройстве сети;
оборудование магистрального уровня должно иметь резервирование;
сеть должна быть спроектирована с учетом требований информационной безопасности.
Поддержка сетевой безопасности для ЦОД I уровня обязательно, для ЦОД II уровня – в случае, если того
требует политика информационной безопасности, должна быть реализована следующим образом:
выделить следующие сегменты сети с целью последующего применения отдельных политик информационной безопасности к каждому сегменту:
сегменты демилитаризованной зоны (ДМЗ), в которых размещены публичные ресурсы Internet, серверы удаленного доступа к корпоративным ресурсам из Internet и Extranet;
сегмент внутренних защищенных серверов компании;
сегмент локальных пользователей;
связь ДМЗ между собой должна проходить через оборудование, которое обеспечивает функциональность МСЭ/IDS/IPS на скорости физического канала;
после пограничных маршрутизаторов сети, которые обеспечивают выход в Интернет и поддержку каналов VPN между ЦОД I и II уровней, должно стоять оборудование, обеспечивающее функциональность
МСЭ/IDS/IPS на скорости физического канала;
помимо ДМЗ, на сети должны использоваться виртуальные локальные сети (VLAN). С помощью VLAN
должны в обязательном порядке защищаться все ресурсы сети и пользователей, которые должны
иметь повышенную защищенность согласно политике информационной безопасности.
Поддержка масштабируемости для всех ЦОД должна быть обеспечена следующим образом:
за счет правильного внедрения трехуровневой модели коммутации;
156
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
за счет масштабируемости коммутаторов, которая должна достигаться за счет объединения в группы
(стеки). Причем каждый коммутатор в стеке должен работать в двух режимах – как главный коммутатор стека и как процессор коммутации пакетов. Должна обеспечиваться отказоустойчивость системы
по схеме 1:N. То есть при выходе из строя одного из коммутаторов стека, независимо от выполняемой
им функции, остальные будут продолжать выполнение своих функций без остановки работы всей сети;
рекомендуется использовать для ЦОД I и II уровней динамический протокол внутренней маршрутизации OSPF как обладающий хорошей масштабируемостью, быстрой сходимостью, учитывающий качество каналов связи и занимающий минимальную полосу канала.
Система IP-адресации сети для всех ЦОД должна обеспечивать:
разделение адресного пространства на служебный блок (сети, связывающие маршрутизаторы, виртуальные интерфейсы и т.п.) и блок адресов локальной сети. Такое разделение позволяет эффективно
строить правила доступа к сетевым устройствам;
распределение адресного пространства локальной сети блоками в соответствии с иерархической структурой подразделений. Такое разделение позволяет производить агрегирование адресов, что приводит
к уменьшению таблиц маршрутизации и упрощает управление сетью.
Для осуществления аутентификации на уровне доступа для всех ЦОД и при доступе к консоли управления
всеми устройствами сеть должна обладать следующими возможностями:
безопасность портов, то есть должна быть возможность использования порта коммутатора с предварительно заданными физическими адресами пользовательских ПК. При попытке подключения неавторизованного устройства должно производиться отключение этого порта и уведомление системы
управления сетью;
автоматическое конфигурирование портов коммутаторов, то есть должна быть автоматизация изменения конфигурации порта на основе логического подключения пользователя к сети;
аутентификация административного доступа на Radius сервере, то есть должна быть идентификация,
авторизация и учет при доступе к командной строке устройства;
ограничение доступа по IP адресам с учетом ограничения на доступ к командной строке устройства и
системной консоли, а также SNMP трафика;
автоматическая фильтрация трафика неиспользуемых протоколов на портах коммутаторов.
Для обеспечения высокой доступности сети для ЦОД I уровня необходимо, а для ЦОД II и III уровня рекомендуется использовать следующую функциональность:
поддержка виртуальных частных сетей (VLAN) на уровне алгоритма «связующего дерева» (Spanning
Tree), то есть должна быть возможность работы отдельного алгоритма Spanning Tree в каждой виртуальной сети для управления путями трафика с точностью до отдельной подсети и обеспечения простого механизма отказоустойчивости на канальном уровне. Также должна иметься возможность
управления параметром веса порта в алгоритме Spanning Tree для виртуальной сети на транковых портах для загрузки обоих каналов соединения Dual Homing (метод подключения устройств, обеспечивающий основное и резервное соединение);
поддержка дополнительных функций в коммутаторах для протокола Spanning Tree:
поддержка множественных групп Spanning Tree в одной сети;
оптимизация алгоритма Spanning Tree для переключения на резервные каналы за время менее 5
секунд;
отсутствие задержки алгоритма Spanning Tree при включении пользовательского порта;
поддержка возможности объединять в единый логический канал несколько физических соединений
между коммутаторами;
функции автоматического переключения с основного маршрутизатора на резервный, в случае отказа
основного;
МОСКВА 2008
157
балансировка нагрузки между резервируемыми маршрутизаторами;
функции внутреннего программного обеспечения для улучшения времени сходимости протоколов маршрутизации и балансировки нагрузки через равноценные маршруты.
Для поддержки приложений, основанных на технологии многоадресной рассылки IP Multicast, от сетей
ЦОД I и II уровня требуется наличие следующих возможностей:
на уровне доступа/распределения - передача пакетов IP Multicast на канальном уровне на скорости физического канала, динамическая регистрация посредством IGMP и CGMP;
магистральный уровень - передача пакетов IP Multicast на канальном и сетевом уровнях на скорости физического канала, масштабируемые протоколы маршрутизации трафика IP Multicast.
Требования к точкам радиодоступа Wi-Fi:
точки радиодоступа Wi-Fi должны поддерживать стандарт IEEE 802.11g (2,4 ГГц, 54 Мбит/с);
должно быть уделено особое внимание вопросам безопасности. В частности, вопросу аутентификации
и защищенности канала;
для аутентификации пользователей рекомендуется использовать Radius сервер.
7.2.1.3. Требования к телефонии, аудио- и видеоконференцсвязи
Основной протокол передачи аудио- и видеоинформации - IP. Допускается использование традиционной
аналоговой телефонии в следующих случаях:
унаследованные существующие телефонные станции;
экономическая целесообразность. Данное исключение действует до момента, когда стоимость VoIP телефонов станет сопоставима с ценой аналогового телефона.
Требования к поддержке сигнализации:
на цифровых каналах E1 должна использоваться сигнализация EuroISDN;
сигнализация Q.SIG.
VoIP преимущественно должна внедряться по технологии SIP, так как данная технология, по сравнению с
H.323, используется в сетях следующего поколения и имеет более развитую функциональность. При этом
необходимо обращать внимание на совместимость реализации протокола SIP между оконечными устройствами и программно-аппаратным комплексом, обеспечивающим функциональность учрежденческой телефонной станции. Данная совместимость должна выражаться в поддержке основного функционала по
обработке поступающих звонков с оконечных устройств. В целях недопущения проблем, связанных с несовместимостью реализации протокола SIP, рекомендуется устанавливать оконечные устройства (телефоны) и программно-аппаратные комплексы, обеспечивающие функциональность учрежденческой
телефонной станции, от одного производителя.
Системы видеоконференцсвязи должны поддерживать Web-конференции и интегрироваться с офисными
приложениями.
Серверы аудиоконференцсвязи должны поддерживать или иметь возможность расширения для поддержки
видеоконференцсвязи.
Видеоконференцсвязь должна организовываться по технологии IP - H.323.
При пакетной передаче за эталон качества речи должен быть принят уровень качества, равный 4 баллам
по шкале MOS/PAMS (Mean Opinion Score, субъективный метод оценки согласно рекомендации Р.800). Рекомендуется использовать кодек G.729 (MOS = 4.07). Требования к параметрам качества пакетной передачи:
задержка пакетов – до 150 мс, джиттер - до 50 мс.
При наличии двух и более провайдеров, включая традиционную телефонию и VoIP, рекомендуется ис-
158
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
пользовать LCR – выбор провайдера по наименьшей стоимости. При этом оборудование VoIP должно обеспечивать мониторинг качества канала связи.
7.2.1.4. Требования к оборудованию
Оборудование уровня доступа должно обладать возможностью классификации трафика (Traffic Classification), то есть должна быть обеспечена возможность классифицировать трафик по типам приложений,
физическим и сетевым адресам источников и получателей, портам коммутаторов. Классифицированный
трафик должен получать метку, обозначающую назначенный пакетам уровень приоритета, тем самым
давая возможность устройствам сети соответствующим образом обслуживать этот трафик. Должна быть
обеспечена реклассификация пакетов на основе заданной администратором политики качества обслуживания. Например, пользователь назначает высокий приоритет своему трафику и передает его в сеть. Этот
приоритет может затем быть понижен в соответствии с сетевой политикой, а не на основе требований
пользователя. Данный механизм должен быть ключевым в обеспечении качества обслуживания в рамках
всей сети.
Оборудование магистрального уровня должно обладать следующей функциональностью:
предотвращение и управление перегрузками, то есть должна быть обеспечена возможность управлять
поведением сети при перегрузках, отбрасывая определенные пакеты на основе классификации или политики в моменты перегрузки сети и множества очередей на интерфейсах. Администратор должен
устанавливать пороговые значения для различных уровней приоритета;
планирование, то есть должна быть обеспечена возможность осуществлять приоритетную передачу
пакетов, основанную на классификации или политике качества обслуживания, при помощи нескольких
очередей;
резервирование основных узлов, к которым могут относиться: блок питания, блок вентиляторов, процессорный модуль.
В ЦОД I и II уровня, помимо обеспечения резервирования основных узлов оборудования магистрального
уровня, рекомендуется обеспечить такое же резервирование для оборудования уровня распределения.
Во всем активном оборудовании сети ЦОД I и II уровней должны быть средства мониторинга политики качества обслуживания и безопасности, планирования сети и сервисов:
возможность сбора статистики RMON с точностью до порта сети для анализа производительности сети;
возможность перенаправлять трафик отдельных портов, групп портов и виртуальных портов на анализатор протоколов для детального анализа;
возможность углубленного анализа потоков сетевого и транспортного уровней при помощи протокола
NetFlow;
возможность расширенного мониторинга событий в реальном времени для расширения возможностей
диагностики, помимо внешних анализаторов;
возможность сбора и сохранения информации о существенных сетевых событиях, включая изменения
конфигураций устройств, изменения топологии, программные и аппаратные ошибки;
возможность доступа к интерфейсу управления устройством и отчетам через стандартный WEB-браузер;
возможность автоматической конфигурации Fast/Gigabit Ethernet портов, виртуальных сетей, транков
VLAN;
возможность автоматического распознавания топологии сети посредством агентов распознавания топологии.
В целях обеспечения производительности локальной сети, ее масштабируемости, удовлетворения требованиям информационной безопасности и обеспечения качества обслуживания мультисервисного трафика,
запрещается использовать концентраторы (хабы). Вместо них должны использовать только коммутаторы.
МОСКВА 2008
159
В целях обеспечения бесперебойной работы необходимо обращать внимание на соответствие оборудования, предназначенного для наружной установки (VSAT, radioethernet и т.п.), местным климатическим условиям, в т.ч. диапазону температур, допустимой влажности, ветровым нагрузкам.
7.2.1.5. Требования к управляемости
в КРМСС должно быть обеспечено централизованное управление. Система мониторинга и управления
сети (NMS) должна входить в состав центрального узла связи КРМСС;
NMS должна иметь графический интерфейс пользователя (GUI);
NMS должна обеспечивать диагностику работы устройств и компонент каждого узла сети;
NMS должна обеспечивать сбор, обработку и хранение статистической информации по функционированию всей сети и каждого узла в отдельности, с возможностью ее обработки, получения статистических отчетов с целью контроля загрузки сети, а также контроля и учета всех видов трафика;
мониторинг сети должен производиться в реальном масштабе времени;
NMS должна обеспечивать включение в сеть новых узлов и организацию новых каналов без перерывов в функционировании NMS и сети в целом.
7.2.2. Требования к внешним каналам связи
Внешние каналы связи должны обеспечивать телефонию, аудиоконференцсвязь, видеоконференцсвязь и
передачу данных в соответствии с требованиями приложений. Детально данный вопрос будет рассмотрен
в отдельном документе.
7.3. Прикладное программное обеспечение
Прикладное программное обеспечение (прикладное ПО) является одним из основных компонентов современной ИТ-инфраструктуры. С точки зрения конечного пользователя, именно прикладное ПО помогает решать те или иные бизнес-задачи.
В рамках данной Технической политики ИТ рассматриваются следующие основные характеристики прикладного ПО:
функциональность - способность ПО максимально эффективно выполнять заявленные функции, с требуемыми характеристиками;
функциональная полнота - полный набор функций, которые способно выполнять данное ПО;
платформонезависимость (portability) - способность ПО функционировать в разных программно-аппаратных средах, под управлением разных операционных систем;
производительность (performance) - способность ПО обеспечивать сбор, обработку и хранение определенных объемов информации при заданной конфигурации аппаратной платформы;
масштабируемость (scalability) - способность ПО корректно работать на малых и на больших системах
с производительностью, которая увеличивается пропорционально вычислительной мощности системы
(количества процессоров, дисковых массивов, серверов и т.д., используемых для эксплуатации данного ПО);
способность к интеграции (Open System Interconnection (OSI), Interoperability) - способность ПО к интеграции и взаимодействию с другими системами, в том числе с системами сторонних производителей,
и эксплуатируемыми на других платформах;
зрелость (maturity) - наличие истории развития данного ПО (присутствие данного ПО на рынке в течение определенного промежутка времени, регулярный выпуск производителем новых версий и релизов) и объявленных производителем планов по его развитию;
160
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
надежность и отказоустойчивость (reliability and fault-tolerance) - способность ПО и систем, построенных на его базе, к бесперебойной, непрерывной работе, а в случае возникновения программно-аппаратных сбоев - способность к быстрому восстановлению работоспособности системы;
общая стоимость владения (ТСО) ПО - складывается из затрат на начальное приобретение (разработку)
данного ПО, ввод его в эксплуатацию и расходов на его эксплуатацию и сопровождение в течение нормативного срока жизни данного ПО. Общая стоимость владения включает затраты: на обновление программного обеспечения и оборудования, на обучение, обслуживание, администрирование и
техническую поддержку.
С точки зрения процессов разработки, поставки и сопровождения всю совокупность прикладного ПО можно
разделить на две группы:
1. универсальное (тиражируемое) ПО - ПО, доступное на рынке и служащее для решения универсальных
задач.
2. заказное ПО - ПО, разработанное по заказу организации ИТ-подразделением или сторонней организацией.
7.3.1. Общие требования к прикладному ПО
При выборе и внедрении нового прикладного ПО должны соблюдаться следующие требования:
все используемое прикладное ПО должно быть унифицировано и каталогизировано в рамках КРК в
виде списка ПО, допустимого к использованию;
ПО клиентских ПК должно быть функционально полным и обеспечивать выполнение как стандартных
бизнес-процессов, так и специфических бизнес-задач данного пользователя;
ПО должно быть зрелым: производитель (поставщик) должен гарантировать поддержку, сопровождение данного ПО в течение всего нормативного срока жизни данного ПО;
рекомендуется использовать платформонезависимое ПО, обеспечивающее свободу выбора программно-аппаратных средств для его эксплуатации и, в конечном счете, снижение общей стоимости владения системой;
рекомендуется использовать производительное, масштабируемое ПО, обеспечивающее гарантии непрерывности бизнес-процессов при росте объемов обрабатываемой и хранимой информации. Желательно, чтобы производитель ПО регулярно проводил объемное и нагрузочное тестирование своего ПО
и предоставлял данные о результатах тестирования;
рекомендуется использовать только ПО, обладающее способностью к интеграции с другими системами
и обладающее открытой архитектурой, то есть поддерживающее стандарты OSI. При выборе ПО необходимо учитывать возможности его интеграции в существующую ИТ инфраструктуру предприятия;
при выборе ПО преимущества должны получать системы с подтвержденным положительным опытом
использования в электроэнергетике;
для обеспечения критических бизнес-процессов и услуг рекомендуется использовать отказоустойчивое
ПО в комбинации с резервированием серверной платформы и инфраструктуры ЦОД (в соответствии с
рекомендациями раздела 6.4 настоящей Технической политики ИТ);
общая стоимость владения ПО, рассчитанная на весь нормативный срок его эксплуатации, должна служить одним из определяющих критериев при выборе того или иного поставщика и ПО;
в области информационной безопасности ПО должно соответствовать требованиям документа «Политика информационной безопасности при проектировании, внедрении и эксплуатации информационнотелекоммуникационных систем ОАО РАО «ЕЭС России»;
ПО должно быть надлежащим образом документировано. Минимальные требования к документации наличие документов «Руководство пользователя» и «Руководство администратора».
МОСКВА 2008
161
7.3.2. Общие требования к универсальному прикладному ПО
При закупке нового универсального прикладного ПО должны выполняться следующие требования:
при использовании лицензируемого ПО на него должны быть обязательно получены и надлежащим
образом зарегистрированы соответствующие лицензии;
рекомендовано к использованию ПО производителей, зарекомендовавших себя на рынке в данной области. Желательно, чтобы данный производитель присутствовал на рынке с данным или аналогичным
ПО не менее трех лет. Не рекомендуется использование устаревших версий ПО, а также слишком новых,
«незрелых» версий ПО;
должно быть запрещено к использованию ПО, не имеющее как лицензий, так и поддержки (сопровождения) со стороны производителя;
при выборе универсального ПО необходимо руководствоваться общими требованиями к прикладному
ПО, а также рекомендациями настоящей Технической политики ИТ.
7.3.3. Общие требования к заказному прикладному ПО
При разработке нового прикладного ПО должны соблюдаться следующие требования:
процесс проектирования, разработки и внедрения заказного ПО должен соответствовать требованиям
раздела 7.7 настоящей Технической политики ИТ;
необходимо технико-экономическое обоснование разработки и внедрения данного ПО.
при формировании Технического задания в соответствии с ГОСТ 34.602-89 в разделе «Требования к
системе» необходимо подробно сформулировать и описать требования к заказываемому ПО, в частности к его основным свойствам, перечисленным выше. Заказчик ПО должен представить технико-экономическое обоснование разработки и внедрения данного ПО, с учетом бизнес-требований
функционального заказчика (ФЗ) и принципов минимизации ТСО для данного решения;
при выборе разработчика ПО основное внимание должно уделяться опыту предыдущей работы данного
разработчика по созданию (проектированию, реализации и внедрению) подобных систем. Желательно
требование реализации не менее трех аналогичных по функционалу и функциональной полноте проектов в течение последних двух лет;
при выборе разработчика ПО необходимо сформулировать требования к применяемым системам управления качеством. Желательно наличие у разработчика сертификата на соответствие его системы управления качеством процессов разработки ПО стандартам семейства ISO 9000 (ГОСТ Р ИСО 9000);
рекомендуется включать в процедуры приемки ПО передачу разработчиком исходных текстов программ и других объектов, необходимых для создания ПО, согласно требованиям ГОСТ Р ИСО/МЭК
12.207-99. Процедура приемки должна обязательно включать в себя контрольную компиляцию переданных исходных текстов с созданием полностью работоспособной версии ПО и выполнение контрольного примера на данной версии;
в договоре на разработку ПО необходимо отражать распределение авторских и смежных прав на конечный продукт, а также ограничения на его дальнейшее использование сторонами.
7.3.4. Интеграция приложений
При формировании общей архитектуры ИТ должна обеспечиваться интеграция приложений, что позволит
обеспечить совместное функционирование разнородных, не связанных на технологическом уровне, но работающих в едином бизнес-процессе, приложений. При этом можно выделить три области: интеграцию
приложений в рамках ERP-системы, интеграцию с системами технологического управления на уровнях
(АСТУ) и, наконец, интеграцию с системами внешних организаций.
162
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Как показывает практика, ни одна из существующих систем и даже ни один отдельно взятый поставщик
(например, SAP или Oracle) не могут обеспечить эффективную реализацию всей требуемой функциональности прикладного уровня ИТ. Поэтому интеграция различных приложений будет неизбежной и должна
рассматриваться как стратегический элемент реализации ИТ-систем.
Критическим, с точки зрения повышения эффективности работы ERP-системы в целом, будет являться использование единой системы словарей и справочников. В перспективе также должна быть рассмотрена возможность внедрения общекорпоративного интеграционного программного обеспечения, которое обеспечит
гарантированный и надежный обмен данными с поддержкой «интеллектуальной обработки», когда содержание самих данных определяет правила их обработки и маршрутизации внутри информационной системы.
Важно отметить, что внедрение интеграционных элементов, включая хранилище данных, в уже сложившуюся архитектуру требует от бизнес- и ИТ-персонала разработки такой стратегии управления данными и приложениями,
которая будет постоянно поддерживать этот процесс в активном состоянии. Обязательной составляющей такой
стратегии должна быть реализация надежных механизмов архивирования, включая контрольные журналы.
Особенностью систем управления в ОАО «МОЭСК», то есть в электросетевом комплексе, является то, что
непосредственное влияние ИТ на технико-экономические показатели определяется на уровне АСТУ. Поэтому принципиально важным для достижения эффективности внедрения является тесная интеграция ERPсистем с АСТУ.
Контур управления технологическими процессами обеспечивает получение достоверной информации о
фактических параметрах технологических процессов, потребляемых материальных ресурсах и состоянии оборудования, снижает возможности для манипуляций при оплате услуг по транспортировке электроэнергии, создает объективную базу для причинно-следственного анализа основной деятельности
компаний.
В состав АСТУ входят, в частности, такие подсистемы, как:
автоматизированная система диспетчерско-технологического управления (АСДТУ);
автоматизированная система управления технологическими процессами (АСУ ТП);
автоматизированная измерительная информационная система коммерческого учета электроэнергии
(АИИС КУЭ).
АСТУ решает следующие основные задачи:
диспетчерское технологическое управление;
сбор и передача оперативной информации;
сбор, долговременное хранение и представление технологической информации;
мониторинг и диагностика состояния оборудования;
коммерческий и технический учет электроэнергии.
Большинство прикладных систем АСТУ имеет иерархически-распределенную структуру с инсталляциями
на объектах электрической сети уровня предприятий РСК.
Реализация ERP-систем должна производиться в тесной координации с развитием АСТУ и обеспечивать необходимые интеграционные связи между системами. Актуальность интеграции обусловлена, прежде всего,
тем, что основные бизнес-процессы тесно связаны с непосредственным использованием технологической
информации с объектов электрохозяйства. Организация информационного взаимодействия между уровнем бизнес-приложений и прикладными системами АСТУ позволяет построить более эффективное управление бизнес-процессами в ОАО «МОЭСК».
Информационное взаимодействие ERP-систем с АСТУ является двунаправленным:
со стороны АСТУ поступает информация о техническом состоянии оборудования, объемах переданной
электроэнергии, конфигурации сети и технологических параметрах объектов электрохозяйства;
МОСКВА 2008
163
со стороны ERP-систем поступает нормативная справочная информация о технологическом оборудовании, плановых ремонтах, рабочих процедурах, нормативах, договорах и клиентах.
Еще одной важнейшей задачей является интеграция ERP-систем с внешними информационными системами, включая системы генерирующих и сбытовых компаний, системного оператора и т.п.
7.3.5. Прикладные сервисы
К этой категории относятся те ИТ-решения и технологии, которые находят применение сразу для нескольких направлений деятельности - на прикладном или системном уровнях.
Например, географические информационные системы (ГИС) используются для решения большого количества различных прикладных задач, включая экологию, маркетинг, строительство объектов и т.п. Благодаря внедрению корпоративной ГИС, которая обеспечивает централизованное управление топографической
основой и различными тематическими покрытиями, достигается множественный эффект централизованного хранения и управления данными. Применение ГИС будет постоянно расширяться, в том числе при
анализе, моделировании и проектировании пространственных объектов. Средства ГИС могут использоваться прежде всего в системах оперативного управления, ТОиР, а также при проектировании и строительстве объектов.
Для руководства ОАО «МОЭСК», ГИС позволит строить обзорные электронные карты, представляющие в
наглядном виде информацию по всем аспектам деятельности. При этом важным фактором является обеспечение защиты данных, связанных с картографической информацией высокого разрешения.
Важным элементом ИТ является Корпоративный портал, который должен обеспечивать следующие основные возможности:
единая точка входа для всех прикладных ИТ-систем;
единая система обеспечения безопасности доступа к данным и функциям внешних систем;
единообразный интерфейс взаимодействия с пользователем;
поддержка различных типов доступа (локальный, удаленный) и устройств (КПК, мобильный телефон,
информационный киоск и т.п.);
сквозная система поиска (федеративный поиск).
Примером прикладного сервиса системного уровня является выделенный сервис доступа к данным. В его
задачи входят, в частности:
поддержка каталогов пользователей;
поддержка каталогов информационных ресурсов (баз данных);
аутентификация пользователей и интеграция с корпоративной инфраструктурой;
поддержка метаданных для организации доступа.
7.4. Требования к вычислительной инфраструктуре центров обработки
данных
В данном разделе рассматриваются требования к системам обработки, хранения и резервного копирования данных ЦОД.
Унифицированные решения описаны в разделе 9.4 настоящей Технической политики ИТ, требования к помещениям и инженерным системам ЦОД согласно рекомендациям Основных положений Технической политики Холдинга в области информационных технологий ОАО РАО «ЕЭС России», утвержденных решением
Правления ОАО РАО «ЕЭС России» от 07.11.2006 № 1564пр/1, представлены в приложении 4 к настоящей
Технической политики ИТ.
164
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
7.4.1. Общие требования
Общие требования к системам обработки, хранения и резервного копирования данных для всех ЦОД:
производительность;
производительность оборудования должна складываться из производительности основных подсистем. Необходимо отслеживать нагрузку основных подсистем, выявлять узкие места и наращивать,
по мере необходимости, производительность путем установки дополнительных модулей;
на рабочем режиме сервер должен иметь загрузку основных ресурсов не более чем на 75%, чтобы
выдерживать пиковую нагрузку, в случае необходимости;
виртуализация;
масштабируемость;
готовность.
Степень готовности оборудования должна обеспечиваться за счет:
уменьшения единых точек отказа;
технологии объединения нескольких серверов в кластер;
использования систем высокой готовности от ведущих производителей.
7.4.2. Требования к серверам
Выбор серверного оборудования должен зависеть от тех задач (приложений), которые они будут решать.
Учитывая, что разброс задач огромен, а при возрастании количества пользователей и объемов данных требования к вычислительным ресурсам резко повышаются, рекомендуется:
выбирать серверы, позволяющие постепенно масштабировать (наращивать) ресурсы и увеличивать
производительность;
использовать технологию виртуализации, которая позволяет разделять ресурсы высокопроизводительного сервера между приложениями, которые требуют не очень больших ресурсов для своей реализации, на аппаратном и программном уровнях.
Данных подход, который сочетает в себе установку масштабируемых серверов и технологию виртуализации, позволит уменьшить TCO и увеличить прозрачность и управляемость всей вычислительной инфраструктуры за счет динамического перераспределения ресурсов.
Серверы должны обеспечивать:
высокую скорость обработки данных при сниженных затратах на обслуживание;
простоту управления для быстрого изменения и перераспределения ресурсов в зависимости от потребностей;
высокую надежность и непрерывность обработки и доступа к информации;
интеграцию их в существующую инфраструктуру и совместную работу с уже использующимися системами обработки данных.
Рекомендуется устанавливать в ЦОД I и II уровней высокопроизводительные серверные платформы ведущих производителей среднего и высшего классов производительности, в ЦОД III уровня - низшего и среднего классов.
При выборе серверов рекомендуется отдавать предпочтение платформам, поддерживающим не менее
двух процессоров с двухядерной архитектурой.
Высокопроизводительные серверные платформы должны иметь ряд встроенных свойств высокой доступности, таких как: резервные вентиляторы и блоки питания горячей замены; диски и адаптеры I/O горячего подключения; динамическая очистка и перераспределение страниц памяти; динамическое
перераспределение процессоров и способность к восстановлению; интегрированная служба оповещения
о событиях, работающая в режиме реального времени; встроенная расширенная система обнаружения
МОСКВА 2008
165
неисправностей с выделенным сервисным процессором и шиной; наличие удаленной консоли.
Во всех серверных решениях должно быть уделено большое внимание предотвращению возможных сбоев.
Для ЦОД I и II уровней должны быть реализованы функции, при помощи которых осуществляется непрерывный контроль состояния всех компонентов сервера и анализ тенденций изменения контролируемых показателей. При обнаружении какой-либо потенциальной проблемы, например, возможного перегрева
процессора, специальные функции динамического перераспределения ресурсов должны обеспечить перенос процессов с потенциально–сбойного компонента на исправный без прерывания выполнения приложений. При этом администратор системы и/или служба технической поддержки должны получить
уведомление и подробный отчет о происшедшем событии.
ПО, реализующее технологию виртуализации серверов, должно давать возможность быстро и просто разделять вычислительные ресурсы в зависимости от требований приложений, а также уменьшать общее
число серверов, позволяя нескольким виртуальным серверам размещаться на одном физическом, рационально используя его вычислительные ресурсы и память.
ПО, реализующее технологию виртуализации серверов, должно реализовывать следующую функциональность:
функция декомпозиции:
компьютерные ресурсы должны рассматриваться как единый однородный пул, распределяемый
между виртуальными машинами;
множество приложений и операционных систем должны сосуществовать на одной физической компьютерной системе;
функция изоляции:
виртуальные машины должны быть полностью изолированы друг от друга, аварийный отказ одной
из них не должен оказывать никакого влияния на остальные;
данные не должны передаваться между виртуальными машинами и приложениями, за исключением случаев использования общих сетевых соединений со стандартной конфигурацией;
совместимость:
совместимость должна гарантироваться посредством представления виртуальной аппаратуры приложениям и ОС как стандартной.
В ЦОД I уровня обязательно, а в ЦОД II уровня рекомендуется использовать дисковый массив для хранения
основных прикладных данных, а функцию хранения данных передавать сети хранения данных (SAN) с последующей виртуализацией SAN. Встроенные диски серверов использовать только для системных целей.
Если для ЦОД II уровня не используются сети SAN, то должны быть использованы устройства NAS с функциональностью виртуализации.
Таким образом, для ЦОД I и II уровней должна быть внедрена технология виртуализации на всех уровнях
ИТ-инфраструктуры:
локальная сеть - технология VLAN;
серверы - технология виртуализации серверов;
сети и системы хранения данных - технология виртуализации SAN или NAS.
ОС для обслуживания серверных приложений и промышленных систем должны:
быть высоконадежными и защищенными;
обеспечивать высокий уровень быстродействия приложений;
поддерживать кластеризацию и grid-системы;
обладать встроенными возможностями для организации удаленного мониторинга всех основных сервисов ОС.
166
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
7.4.3. Требования к системам хранения данных
Главными приоритетами в развитии систем хранения данных должны быть:
наращивание емкости систем хранения данных;
концентрирование систем хранения данных в едином месте, причем количество территориально-удаленных мест должно быть ограничено;
расширение возможностей восстановления после аварий;
уменьшение времени восстановления;
уменьшение окон резервного копирования (интервалов времени, отведенных для подготовки резервной копии) для критически важных приложений.
Должны быть выделены следующие уровни системы хранения данных:
оперативный уровень;
уровень долгосрочного хранения данных;
эектронный архив;
уровень резервного копирования данных.
Оперативный уровень - данные с этого уровня достаточно часто используются пользователями. Соответственно, оборудование должно быть достаточно быстродействующим и иметь высокую степень доступности. С учетом соотношения цена-качество рекомендуется использовать диски SATA.
Уровень долгосрочного хранения данных - постоянное место хранения данных, которое помимо производительности должно обладать высокой надежностью.
Электронный архив - хранилище данных, которое обеспечивает физическую сохранность данных вне зависимости от действий пользователей. Данные, помещенные в электронный архив, нельзя стереть или изменить.
При изменении данных в электронном архиве должна храниться как исходная копия, так и все ее модификации. Электронный архив должен создаваться на базе специальных программно-аппаратных решений с гарантированной неизменяемостью сохраняемых данных, например, на оптических носителях информации.
Рекомендуется внедрить ПО для управления жизненным циклом информации (ILM), которое, согласно настроенным правилам, должно автоматически перемещать данные между разными уровнями хранения в зависимости от их востребованности.
Кроме этого, ПО управления контентом должно перемещать данные в единую систему хранения по заранее настроенным правилам, в зависимости от бизнес-критичности информации, непосредственно с рабочих ПК пользователей.
Система хранения данными должна иметь:
единые средства для репликации данных, которые должны перемещать данные между уровнями систем
хранения данных, приводя в соответствие ценность данных и этап их жизненного цикла с показателями доступности, производительности, безопасности и стоимости уровня хранения;
масштабируемую виртуализацию, позволяющую управлять ресурсами многоуровневой системы хранения данных как одним пулом, который необходимо разделять между пользователями и обслуживать
как единое целое.
Система хранения данных должна иметь способность управлять логическими разделами внешней памяти.
Логические разделы должны распределять ресурсы одного физического устройства хранения данных на
несколько виртуальных устройств, каждое из которых должно независимо настраиваться для отдельных
приложений и/или групп пользователей. Эта стратегия эффективно работает при хранении значительных
объемов разнотипных данных, поэтому логические разделы должны стать частью многоуровневой инфраструктуры хранения данных.
МОСКВА 2008
167
В настоящее время существуют следующие технологии хранения данных:
концепция NAS (Network Attached Storage) устройства хранения, подключаемого непосредственно к локальной или глобальной сети, ориентированная на файловые сервисы;
концепция сети хранения данных (SAN), ориентированная на обработку блоков данных, хранящихся в
базах данных;
интерфейс iSCSI (Internet Small Computer System Interface), с помощью которого можно создавать сети
хранения данных без использования дорогостоящего волоконно-оптического оборудования.
Все эти решения объединяет одна характеристика - попытка снизить ТСО системы хранения, внедряя эффективное управление «островками» информации, изолированно располагающимися в гетерогенной
среде, включающей различные ОС, форматы данных и пользовательские интерфейсы.
В ЦОД I уровня должна быть внедрена технология SAN как наиболее перспективная, развивающаяся и удовлетворяющая всем необходимым требованиям. Для ЦОД II уровня также рекомендуется технология SAN,
но допускается возможность развертывания устройств NAS для организации файловых сервисов. При этом
должна быть стратегически выбрана одна технология или продуман и обоснован подход одновременного
использования и SAN, и NAS без взаимных конфликтов, обеспечивающий виртуализацию для серверных
систем и общее управление единым пулом систем хранения данных.
В ЦОД III уровня рекомендуется использовать технологию WAFS (Wide-Area File Services) - файловые
службы для глобальных сетей, при организации удаленного доступа к единой системе хранения данных для
совместной работы с файлами. Технология WAFS в данном случае должна поддерживаться в ЦОД II уровня
или в устройствах сети SAN и/или устройствах NAS, или сетевым оборудованием доступа.
Целью внедрения и использования технологии SAN должно стать обеспечение реальной консолидации ресурсов хранения и их совместного использования, так как емкость хранения должна подключаться ко многим серверам, в том числе и удаленным, а машины, обрабатывающие данные, должны освобождаться от
задач управления ресурсами и их хранения.
При внедрении технологии SAN должны быть обеспечены:
независимость топологии SAN от storage-систем и серверов;
удобное централизованное управление;
удобное резервирование данных без перегрузки локальной сети и серверов;
высокое быстродействие;
высокая масштабируемость;
высокая гибкость;
высокая готовность.
При выборе и внедрении конкретного оборудования и ПО для реализации SAN необходимо соблюдать следующее требование: система хранения данных должна поддерживать уровни логической абстракции (виртуализации)
между физическими портами на данном дисковом массиве, блоками данных на конкретных дисковых группах
и логическими томами или файлами, к которым серверы или приложения должны иметь доступ.
В частности, должны быть реализованы следующие сервисы виртуализации:
виртуализация подключения к SAN.
К дисковому массиву через SAN должны получать доступ несколько серверов, распределение физических
портов массива между ними не должно являться управленческой проблемой и не должно стать препятствием для полного использования возможностей системы хранения данных.
Система хранения данных должна позволять создавать несколько виртуальных портов на одном физическом порте Fibre Channel, а также управлять этими портами;
168
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
виртуализация логических дисков и томов;
любая модификация приложения (например, добавление новых серверов, устройств хранения
данных или функций) требует выполнения сложного комплекса действий по изменению настроек
как на серверах, так и на дисковых массивах. Эти действия не должны быть причиной ошибок и
простоев и не должны увеличивать время, необходимое на развертывание и модификацию приложения;
система хранения данных должна обеспечивать надежные сервисы управления логическими дисками (LUN) и томами для распространения расширенных сервисов управления информацией и
хранением данных на модульные системы хранения данных, поддерживающие различные типы
дисков;
необходимо иметь соответствующее аппаратное обеспечение с производительностью, достаточной
для значительного повышения масштабируемости и гибкости решений по виртуализации без ущерба
для доступности данных или без увеличения расходов на управление системой хранения данных.
Из всех возможных архитектур построения сети SAN рекомендуется использовать коммутаторы со способом объединения «Центр-Периферия» (Core-Edge) как наиболее оптимальным с точки зрения производительности, масштабируемости и надежности.
При построении SAN в ЦОД I уровня на коммутаторах (за исключением класса Director) рекомендуется создавать две независимые Fabric (конструкция Dual fabric). Dual fabric позволяет избежать единой точки отказа в SAN, обеспечивая высокий уровень надежности и отказоустойчивости. Кроме того, изменения
конфигурации, регламентные работы (например, установка нового firmware) на одной из Fabric не сказываются на работе другой. Применение Dual fabric совместно с программным обеспечением, реализующим
поддержку альтернативных путей доступа и распределение нагрузки для соединения серверов и устройств
хранения (пути должны быть распределены между разными Fabric), позволяет создать надежную SAN.
Также необходимо предусматривать наличие на серверах ПО Dynamic multipathing для обеспечения непрерывной работы приложений с двумя фабриками.
Рекомендуется выбирать оборудование, поддерживающее Fibre Channel с пропускной способностью 4
Гбит/с с поддержкой скоростей передачи данных 2/1 Гбит/с. В случае обеспечения более высокой скорости передачи данных по магистральным каналам и при отсутствии возможности ее увеличения за счет использования транкинга (trunking), рекомендуется использовать для этих целей оборудование с пропускной
способностью 10 Гбит/с.
7.4.4. Обеспечение высокой доступности приложений
В тех случаях, когда требуется обеспечить высокую надежность и доступность приложений для пользователей и ИС, необходимо использовать технологии кластеризации приложений. В зависимости от требуемой величины надежности и доступности системы (см. определение в п. 4.3 настоящей Технической
политики ИТ), которую необходимо обеспечить, целесообразно применять либо кластеры, работающие в
режиме активный/резервный (high-availability clusters), либо параллельные кластеры (parallel clusters),
обеспечивающие более высокий уровень доступности. При выборе прикладного ПО необходимо учитывать возможности систем по работе в кластерных конфигурациях.
7.4.5. Резервное копирование данных
Резервное копирование данных ИС для всех ЦОД должно осуществляться в соответствии с методикой резервного копирования, которая должна содержать описание процессов резервного копирования различных ИС и регламентов их выполнения.
МОСКВА 2008
169
Для резервного копирования данных должен быть использован следующий подход:
локальное резервное копирование данных для их быстрого восстановления;
удаленное резервное копирование данных для обеспечения катастрофоустойчивости.
Локальное резервное копирование данных должно осуществляться на мобильный носитель с сервера резервного копирования. Сервер резервного копирования является также промежуточным оборудованием,
которое должно уменьшать окно резервного копирования посредством предварительного копирования
данных на систему быстрых дисков SATA, которая должна располагаться в сети SAN.
Также в сети SAN для ЦОД I уровня должно быть организовано, а для ЦОД II уровня рекомендуется организовать автоматическое блочное резервное копирование данных на другое физическое устройство, отличное от исходного (data mirroring).
Должен быть принят и утвержден порядок резервного копирования, в котором необходимо регламентировать периоды и окна резервного копирования для полного и инкрементного резервного копирования.
Способы резервного копирования следует выбирать в зависимости от следующих параметров:
RTO - целевое время восстановления, то есть время, необходимое для восстановления данных;
RPO - целевая точка восстановления, то есть момент, до которого необходимо восстановить данные или,
другими словами, это фактически допустимый объем потерянных данных.
Заметим, что для некоторых приложений эти параметры могут отличаться на порядок. Например, для Web-сервера допустима потеря данных (RPO) за последние несколько дней, но обычно перерыв в их работе (RTO) не должен превышать нескольких минут. Поэтому рекомендуется уделять пристальное внимание параметру RTO.
При планировании процессов резервного копирования следует учесть наличие в инфраструктуре различных ОС и приложений, а также место хранения данных и выбрать единое ПО для обеспечения резервного
копирования. Необходимо также учесть возможности интеграции этого ПО с имеющимися системами хранения данных и используемыми приложениями, данные которых подлежат резервному копированию.
Для реализации резервного копирования данных различных ИС требуется составить единый план резервного копирования, в котором должны быть отражены виды выполняемого резервного копирования, их периодичность, объем резервируемых данных и продолжительность выполнения резервного копирования,
а также хронологическая последовательность выполнения процессов резервного копирования. Также следует предусмотреть осуществление резервного копирования системных данных для восстановления ОС
серверов и, в случае необходимости, клиентских рабочих станций.
7.4.6. Обеспечение катастрофоустойчивости
Катастрофоустойчивость должна обеспечиваться за счет копирования данных на территориально удаленный резервный ЦОД. Степень удаленности резервного ЦОД должна определяться, исходя из тех угроз, от
которых планируется защитить данные. Перечень угроз должен быть сформулирован в «Плане обеспечения непрерывности бизнеса» (если таковой имеется в организации).
С целью обеспечения катастрофоустойчивости все важные для бизнеса данные или их резервные копии
(в зависимости от значения параметра точки восстановления данных RPO) рекомендуется с установленной
периодичностью копировать (реплицировать) из ЦОД II уровня на территориально-удаленный ЦОД I уровня.
Рекомендуется для ЦОД I уровня иметь резервный ЦОД, на который в свою очередь реплицировать данные ЦОД I уровня.
Обеспечение катастрофоустойчивости должно осуществляться в соответствии с методикой восстановления ИС, которая должна содержать описание процессов восстановления различных ИС и регламентов их
выполнения.
Все важные для бизнеса и технологически важные данные с ЦОД III уровня должны в синхронном режиме
копироваться в ЦОД II уровня.
170
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Вне зависимости от принятой модели удаленной репликации данных должен быть установлен порядок
хранения и обращения с резервными копиями данных, где бы они ни находились. Установленный порядок
должен гарантировать сохранность резервных копий данных, а также их высокую доступность при возникновении необходимости восстановления данных.
По принципу хранения и использования необходимо выделить два типа данных:
неструктурированные данные (файлы);
структурированные данные, которые хранятся в СУБД.
Для репликации неструктурированных данных необходимо использовать специализированное ПО - агенты
резервного копирования. Для репликации структурированных данных необходимо пользоваться средствами СУБД или ПО, совместимого с данной СУБД.
Вид репликации (полный или инкрементальный) необходимо выбрать в зависимости от объема данных, ширины канала связи (времени репликации), критичности времени восстановления данных при аварии. Рекомендуемый порядок может быть следующим: ежедневное инкрементальное копирование данных и
еженедельно полное копирование данных. Указанный порядок должен быть зафиксирован в документах
по обеспечению непрерывности бизнеса и восстановлению после аварий.
7.5. Требования к обеспечению информационной безопасности
7.5.1. Общие требования
Информация, обрабатываемая и хранимая в ИТ-системах организаций, подведомственных ОАО «МОЭСК»,
критична с точки зрения возможных тяжелых последствий как для процессов передачи электроэнергии
(обеспечении электрической связи), так и для государства в целом.
Системы информационной безопасности должны базироваться на соответствующих нормативных документах, принятых в Российской Федерации.
Стратегическими целями обеспечения информационной безопасности являются:
обеспечение необходимых организационно-управленческих условий для развития и поддержания бизнеса;
обеспечение непрерывности бизнеса.
Главным направлением развития систем информационной безопасности (ИБ) в ближайший период будет
являться комплексное решение спектра задач, увязывающих все основные уровни обеспечения информационной безопасности - экономический, нормативно-методический, технологический и технический, а
именно:
1. Оценка экономической эффективности корпоративной системы защиты информации.
2. Оценка организационно-управленческих условий обеспечения ИБ, в том числе оценка соответствия типовым требованиям и рекомендациям ведущих международных стандартов в области защиты информации и лучшей международной практики.
3. Оценка технологического и технического уровней обеспечения ИБ, в том числе:
защиты от несанкционированного доступа;
защиты каналов связи распределенных узлов информационной системы;
идентификации, аутентификации, авторизации удаленных пользователей и программ;
защиты удаленных узлов распределенной информационной системы;
защиты информационной системы как целостной единой системы, а также ее систем управления.
МОСКВА 2008
171
4. Совершенствование, поддержка и развитие текущей системы защиты информации.
Для решения этих задач требуется проведение аудита, совершенствование и сопровождение специального
комплекса аппаратно-программных средств защиты информации.
Принципиальными элементами комплексного подхода к обеспечению безопасности являются следующие:
обоснование и расчет финансовых вложений в обеспечение безопасности на основе технологий анализа рисков, соотнесение расходов на обеспечение безопасности с потенциальным ущербом и вероятностью его возникновения;
постоянный процесс повышения квалификации и переподготовки кадров, проведение специализированных тренингов по применению средств защиты информации, технологиям защиты информации, а
также обучение работников основам экономической безопасности;
ежегодная переоценка состояния информационной безопасности;
рассмотрение вопросов обеспечения ИБ как составной части более общей проблематики обеспечения
непрерывности бизнеса. При этом работы, связанные с оценкой защищенности, анализа рисков и планирования непрерывности бизнеса, основываются на одних и тех же методиках управления информационными рисками.
7.5.2. План обеспечения непрерывности бизнеса и восстановления после аварии
Актуальность обеспечения непрерывности бизнеса для компании обусловлена необходимостью сохранения (повышения) устойчивости и стабильности функционирования корпоративной информационной системы в целом в условиях неблагоприятного воздействия внешних и внутренних факторов техногенного
и/или природного характера. Перспективные решения в этой области будут включать, в частности, создание резервных центров обработки информации.
Для решения задач по обеспечению непрерывности бизнеса предстоит разработать и поддерживать в актуальном состоянии следующие документы:
планы действий в чрезвычайных ситуациях для продолжения выполнения критически важных функций
ИТ в резервных или поврежденных бизнес-структурах и единицах;
планы восстановления критически важных технологий и приложений ИТ бизнеса;
планы поддержки со стороны ИТ восстановления бизнеса в целом для продолжения выполнения критически важных функций в условиях внешних и внутренних воздействий.
Указанные документы должны включать в себя следующие пункты, которые необходимы для регламентации работ в области ИТ:
перечень внешних и внутренних угроз для бизнеса. К внешним угрозам необходимо отнести техногенные, природные, человеческие и прочие угрозы;
план обеспечения бесперебойного функционирования организации в случае нештатной ситуации - детальный перечень мероприятий, которые должны быть выполнены до, во время и после чрезвычайного
происшествия или бедствия. Этот план должен быть документирован и регулярно испытываться для
того, чтобы убедиться, что в случае нештатной ситуации он обеспечит продолжение деятельности организации и наличие резерва критически важных ресурсов;
план должен учитывать определенное целевое время восстановления данных (RTO), которое определяется с точки зрения требований непрерывности к бизнес-процессам. В зависимости от RTO план должен ранжировать все ресурсы и задачи компании на 3 приоритета:
приоритет 1 - задания, которые должны выполняться в соответствии с установленным графиком;
приоритет 2 - задания, которые могут выполняться при наличии времени и ресурсов;
приоритет 3 - задания, которые не должны выполняться в случае бедствия;
план должен содержать процедуры выполнения следующих функций:
ввод в действие процедур для чрезвычайных ситуаций;
172
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
уведомление работников, поставщиков и заказчиков;
формирование группы (групп) восстановления;
оценка последствий бедствия;
переезд в альтернативное рабочее помещение (помещения);
восстановление функционирования критически важных приложений;
восстановление основного рабочего помещения;
информирование персонала компании о временных способах доступа к информационным ресурсам: телефония, передача данных, местонахождение общих информационных ресурсов компании;
резервному копированию подлежат все программы и данные (включая их настройки), обеспечивающие
работоспособность системы и выполнение ею своих задач (системное и прикладное программное обеспечение, базы данных и другие наборы данных), а также архивы, журналы транзакций, системные журналы и т.д. Резервному копированию подлежат все настройки активного сетевого оборудования;
вся проектная документация (технический проект, рабочая документация, эксплуатационная документация) подлежит резервному копированию на электронный носитель. На нее распространяются общие
правила хранения и использования, как на другие данные, подлежащие копированию на случай восстановления системы;
все программные средства, используемые в системе, должны иметь эталонные (дистрибутивные)
копии. Их местонахождение и сведения о лицах, ответственных за их создание, хранение и использование, должны быть указаны в соответствующих документах. Там же должны быть указаны перечни наборов данных, подлежащих страховому копированию, периодичность копирования, место хранения и
ответственные лица за создание, хранение и использование страховых копий данных;
необходимые действия персонала по созданию, хранению и использованию резервных копий программ
и данных должны быть отражены в функциональных обязанностях соответствующих категорий персонала;
каждый носитель, содержащий резервную копию, должен иметь метку, содержащую данные о классе,
ценности, назначении хранимой информации, ответственном лице за создание, хранение и использование, дату последнего копирования, место хранения и прочее.
7.6. Требования к системе управления и мониторинга
В данном разделе рассматриваются требования к системам управления и мониторинга (СУМ).
7.6.1. Общие требования
Задачи системы управления и мониторинга:
повышение эффективности использования ИТ-инфраструктуры;
поддержание высокого уровня обслуживания прикладных систем;
превентивное решение потенциальных проблем;
сокращение потерь из-за простоев при восстановлении данных.
Система управления и мониторинга ИТ-инфраструктуры ЦОД должна удовлетворять следующим общим
требованиям:
СУМ должна быть масштабируема в рамках ИТ-структуры;
СУМ должна обеспечивать мониторинг объектов управления различных типов и производителей в гетерогенной сети;
СУМ должна обеспечивать возможность включения в контур мониторинга существующих и проектируемых объектов управления;
режим работы СУМ должен совпадать с режимом функционирования объектов управления.
МОСКВА 2008
173
7.6.2. Требования к структуре СУМ ЦОД I и II уровней
СУМ должна состоять из следующих основных подсистем:
подсистема мониторинга и управления Корпоративной сети передачи данных и периферийного оборудования;
подсистема мониторинга и управления серверными комплексами, операционными системами и приложениями;
подсистема мониторинга и администрирования ПК;
подсистема мониторинга и администрирования оборудования и процессов резервного копирования.
7.6.3. Требования к функциональности СУМ ЦОД I и II уровней
СУМ должна обеспечивать выполнение следующих функций:
удаленный доступ к серверу управления через активные консоли;
поддержка параллельной работы нескольких операторов (со своими полномочиями и зоной ответственности) с сервером управления;
защита доступа к серверу управления по любым вариантам входа в систему со стороны неуполномоченных лиц;
разграничение на области компетенции по решению возникающих проблем;
различный уровень графического представления информации для различного эксплуатационного персонала в зависимости от его роли в эксплуатационном процессе;
удаленный мониторинг объектов управления;
мониторинг контролируемых объектов при помощи агентов;
выбор параметров мониторинга и настройка порогов срабатывания агентов для оценки текущего состояния систем;
централизованная регистрация событий, происходящих в контролируемых объектах КСПД, операционных системах, СУБД, приложениях, информационных сервисах;
расширение списка регистрируемых событий и адаптация к используемым приложениям и существующим технологиям;
централизованная обработка всех регистрируемых событий;
оповещение операторов системы о работе информационных ресурсов посредством выдачи информационного сообщения на консоль оператора;
анализ производительности работы объектов управления;
автоматическая обработка и графическое представление оперативной информации по состоянию информационных сервисов;
сбор, хранение и анализ параметров функционирования объектов управления;
удаленный доступ к серверу управления через активные консоли.
7.6.4. Требования к функциональности СУМ ЦОД III уровня
СУМ ЦОД III уровня должна обеспечивать выполнение следующих функций:
мониторинг основных параметров элементов ИТ-инфраструктуры;
обнаружение и локализация отказов элементов ИТ-инфраструктуры.
Система мониторинга должна интегрироваться с системами мониторинга ЦОД I и II уровней.
7.6.5. Требования к управлению и мониторингу мультисервисной сети
Мониторинг IP-сетей, управление конфигурациями, сбоями, производительностью, а также методы и средства инвентаризации IP-сетей должны быть строго регламентированы и автоматизированы.
Соответствующая база данных для ЦОД I и II уровней должна содержать полную и достоверную инфор-
174
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
мацию обо всех элементах сети в иерархическом порядке с учетом географической иерархии, с одной стороны, и функциональной иерархии (приложения, IP-сети, базовые сети) - с другой.
Функционально база данных может быть представлена как две взаимодействующие базы данных: инвентаризационная и системы управления событиями в сети.
Инвентаризационная база данных должна объединять информацию от различных источников и предоставлять ее в удобной форме.
Рекомендованный набор информации для включения в инвентаризационную базу данных:
о топологии сети и установленном оборудовании в управляемых сетях;
подробная информация об используемых каналах связи (в случае арендованных каналов - информация об организации, предоставившей канал) и способах связи;
полную спецификацию оборудования: текущую версию ПО, заводские и инвентаризационные номера,
текущий и предыдущие файлы конфигурации, версию ПО, контактную информацию обслуживающей
организации, место установки и ответственные лица;
для сетевого оборудования - подробное описание интерфейсов в табличном виде с указание IP-адресов, подключенных сетей или серверов приложений для LAN-интерфейсов, используемых каналов
связи (физических и виртуальных), протоколов маршрутизации и подключенного удаленного оборудования для WAN-интерфейсов.
Автоматизированная система обработки событий для ЦОД I и II уровней должна обеспечивать:
сбор и хранение информации о сбоях, неисправностях, превышении критических порогов и т.п. активного оборудования и каналов связи;
уведомление обслуживающего персонала о возникающих проблемах и передачу этой информации по
иерархической структуре (административной, топологической, системной) в соответствии с установленными административными правилами;
отображение истории обработки события (кем, когда, какие действия были предприняты);
сохранение истории событий по каждому объекту управления;
привязку события к объекту, то есть в инвентаризационной составляющей должна быть ссылка на историю событий объекта и наоборот.
Кроме этого, система обработки событий должна предоставлять аналитическую информацию в соответствии с заданными административными требованиями (например, выборку по объектам, на которых не
были своевременно проведены профилактические работы, выборку по событиям, которые не были закрыты в течение месяца, и т.п.).
7.7. Требования к созданию и вводу в действие систем. Требования к документации
В данном разделе описываются минимальные требования к созданию и вводу в действие информационных систем и элементов ИТ-инфраструктуры, а также требования к документации, которая сопровождает
создание и ввод в действие и на основе которой осуществляется дальнейшее сопровождение информационных систем и ИТ-инфраструктуры.
При создании и вводе в действие систем и элементов ИТ-инфраструктуры должны быть соблюдены следующие стадии:
1. Стадия предпроектного обследования (подготовка ТЭО и исходных данных для ТЗ).
2. Стадия создания «Технического задания».
3. Стадия создания «Технорабочего проекта» - для объектов ИТ-инфраструктуры.
МОСКВА 2008
175
4. Стадия создания «Программ и методик испытаний».
5. Стадия создания «Эксплуатационной документации».
6. Стадия поставки оборудования и ПО.
7. Стадия монтажа, пусконаладочных работ, предварительных (автономных и комплексных) испытаний.
8. Стадия опытной (опытно-промышленной) эксплуатации.
9. Стадии приемочных испытаний в промышленную эксплуатацию.
10. Стадия промышленной эксплуатации.
На стадии промышленной эксплуатации должны выполняться регламентированные процессы управления
инцидентами и изменениями (ИТ сервис-менеджмент). В процессе их осуществления службой заказчика
собираются и систематизируются обращения пользователей, классифицированные как запросы на изменение системы. При накоплении достаточного количества запросов на изменение или при появлении запроса с наивысшим приоритетом инициируется новый проект, начиная со стадии предпроектного
обследования. Таким способом обеспечивается цикл непрерывного улучшения качества эксплуатируемых
систем.
Вся документация должна удовлетворять следующим ГОСТам:
оформление документов - ГОСТ 24.301-80;
эскизный проект - ГОСТ 2.119-73;
проектно-сметная документация - ГОСТ 34.201-89;
техническое задание на создание - ГОСТ 34.602-89;
технорабочий проект - РД 50-34.698-90;
технический проект - РД 50-34.698-90 с учетом СНиП 11-01-95; ГОСТ 2.120-73;
спецификация оборудования - ГОСТ 21.110-95;
рабочий проект - РД 50-34.698-90 с учетом СНиП 11-01-95; ГОСТ 21.101-97;
конструкторская документация - ГОСТ 24.302-80, ГОСТ 24.304-80;
эксплуатационная документация - ГОСТ 2.601-95;
программы и методики испытаний - РД 50-34.698-90; ГОСТ 34.603-92.
7.7.1. Требования к техническому заданию
Следует выделять два вида заданий: задание на проектирование и техническое задание (ГОСТ 34.602-89).
Задание на проектирование - приложение к договору, в котором перечисляются все документы, которые
должны быть разработаны, в том числе Техническое задание (ТЗ). Задание на проектирование может быть
опущено, если к договору сразу прилагается техническое задание на создание системы.
ТЗ является основным документом, определяющим требования и порядок создания (развития или модернизации) информационной системы или элементов ИТ инфраструктуры, в соответствии с которым проводится их разработка и приемка при вводе в действие.
Включаемые в ТЗ требования должны ясно и четко описывать функциональность будущей системы и соответствовать современному уровню развития технологий и не уступать аналогичным требованиям, предъявляемым к лучшим современным аналогам.
ТЗ должно обязательно содержать следующие разделы согласно ГОСТу, которые могут быть разделены
на подразделы:
общие сведения;
назначение и цели создания (развития) системы;
характеристика объектов автоматизации;
требования к системе;
состав и содержание работ по созданию системы;
176
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
порядок контроля и приемки системы;
требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в
действие;
требования к документированию;
источники разработки.
7.7.2. Требования к технорабочему проекту
Данной стадии может предшествовать разработка Эскизного проекта, в котором должны быть описаны
все основные технические решения и проведен их сравнительный анализ с другими возможными решениями.
Технорабочий проект должен состоять из технического проекта и рабочей документации.
Технический проект должен содержать как минимум следующие документы:
пояснительная записка;
схема связи или блок-схема;
спецификация оборудования;
сводный сметный расчет и Локальный сметный расчет.
Пояснительная записка должна содержать:
описание предлагаемого технического решения;
обоснование предлагаемого технического решения - сравнение его с другими возможными решениями,
а также анализ современных технологий и подходов к решению поставленной задачи.
Рабочая документация должна содержать, как минимум, альбом на каждую площадку (серверное помещение).
Вместо технического проекта может быть разработан рабочий проект, если отсутствует создание нового
технического решения, которое было создано ранее и имеется технический проект, который описывает и
обосновывает данное техническое решение.
В этом случае рабочий проект должен содержать, как минимум, следующие документы:
пояснительная записка;
рабочая документация;
сводный сметный расчет и Локальный сметный расчет.
7.7.3. Требования к программам и методикам испытаний
Программы и методики испытаний должны быть разработаны и утверждены до проведения соответствующих работ.
Должны быть разработаны следующие программы и методики:
программа и методика предварительных испытаний, которая должна включать автономные и комплексные испытания;
программа опытной (опытно-промышленной) эксплуатации;
программа и методика приемочных испытаний.
7.7.4. Требования к эксплуатационной документации
Эксплуатационная документация для оборудования должна содержать следующие разделы:
руководство по эксплуатации;
схема электрическая функциональная;
формуляр (на каждый узел связи);
схема электрических соединений (перечень элементов и таблица соединений);
ведомость эксплуатационных документов;
ведомость ЗИП.
МОСКВА 2008
177
Руководство по эксплуатации должно подробно описывать порядок работы с оборудованием вплоть до
перечня команд. Назначение руководства по эксплуатации - уменьшение влияния человеческого фактора
за счет документирования всей работы с оборудованием и ПО.
Эксплуатационная документация для ПО должна содержать следующие документы:
«Руководство оператора»;
«Руководство администратора».
7.7.5. Требования к поставке оборудования и ПО
Требования по поставке и сопровождению изложены в разделе 6 настоящей Технической политики ИТ.
7.7.6. Требования к вводу в действие
Рекомендуется осуществлять следующие этапы испытаний системы перед ее вводом в действие:
предварительные (автономные и комплексные) испытания;
опытная (опытно-промышленная) эксплуатация;
приемочные испытания для приемки системы в промышленную эксплуатацию.
Рекомендуется на этапе предварительных испытаний предусматривать тестирование программных систем
при помощи компаний, специализирующихся в данной области;
все оборудование, вводимое в промышленную эксплуатацию, должно иметь соответствующие сертификаты соответствия, если это предусмотрено законодательством.
Для программного обеспечения должна быть предусмотрена разработка, поставка и проверка актуальности
на момент проведения опытной (опытно-промышленной) эксплуатации (контрольная компиляция и сборка).
8. Сертификация программного обеспечения и программно-технических
комплексов
В настоящее время объективной реальностью в формировании архитектуры ИТ является наличие для каждой функциональной области деятельности в ОАО «МОЭСК», большого числа различных продуктов от разных производителей. Полная замена всех таких приложений и переход на единые стандартные приложения
по всем организациям потребует значительных инвестиций и сроков. С учетом этого необходимым условием обеспечения качества работы ИТ-систем является сертификация не только новых, но и уже используемых ТПР.
Целью сертификации является проверка соответствия ТПР установленным для ОАО «МОЭСК» требованиям по функциональности и общей архитектуре автоматизированных систем. Для организации сертификации на уровне ОАО «ФСК ЕЭС» создан Экспертный совет. К проведению сертификации могут
привлекаться специализированные компании.
Сертификация позволяет: создать единые корпоративные правила формирования технических требований
к ТПР, используемым в ОАО «МОЭСК», унифицировать используемые технические решения, повысить их
качество и надежность, создать условия для повышения качества и снижения стоимости сопровождения,
исключить возможность использования в ОАО «МОЭСК» технических решений, не соответствующих требованиям стандартов, отраслевой и корпоративной нормативно-технической документации и условиям
применения, и тем самым - уменьшить риск финансовых потерь.
Представление для сертификации программных продуктов (и технических средств - при необходимости)
может осуществляться либо по инициативе организаций, подведомственных ОАО «МОЭСК», эксплуатирующих данное ПО, либо по инициативе компаний-разработчиков ПО. Сертификат выдается на опреде-
178
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
ленный срок и подлежит пересмотру при смене требований функциональной области или смене версии ПО.
Использование в организациях, подведомственных ОАО «МОЭСК», программного обеспечения или программно-технических комплексов, не имеющих сертификата, не допускается.
Порядок проведения сертификации ТПР для организаций, подведомственных ОАО «МОЭСК», на данный момент определяется Временным положением о проведении сертификации программного обеспечения и
программно-технических комплексов для МРСК-РСК, утвержденное совместным распоряжением ОАО РАО
«ЕЭС России» и ОАО «ФСК ЕЭС» от 23.08.2006 № 214р/211р.
9. Стратегия реализации Технической политики ИТ
В соответствии с изложенными выше основными направлениями Технической политики ИТ стратегическим направлением развития ИТ будет переход от комплекса относительно слабосвязанных отдельных
приложений к внедрению интегрированных систем.
В этой связи актуальными становятся вопросы интеграции приложений в рамках общей системы. Другой
аспект внедрения интегрированных систем будет связан с необходимостью расширения возможностей
корпоративной сети передачи данных.
Вместе с тем следует учитывать такие факторы, как:
достаточно длительный срок внедрения новых интегрированных систем в масштабе ОАО «МОЭСК»;
целесообразность сохранения отдельных «локальных» систем и продуктов на некоторых предприятиях.
C учетом длительности процесса реформирования ИТ, а также имеющихся различий в существующем состоянии ИТ в ОАО «МОЭСК», и ограниченности инвестиций целесообразно планировать пофазное развитие ИТ-систем. Эти фазы - 0, 1 и 2 - кратко описаны ниже. Детальное описание фаз развития ИТ дано в
утвержденной Концепции автоматизации МРСК-РСК.
Важными принципиальными факторами предлагаемого подхода являются:
переход к следующей фазе в ОАО «МОЭСК», не зависит от других организаций;
в ОАО «МОЭСК» возможен переход к следующей фазе не обязательно сразу по всем функциональным
областям бизнеса. Допустимой является ситуация, когда, например, в течение определенного времени
бюджетирование, бухгалтерский и налоговый учет будут реализованы в рамках интегрированной ERPсистемы, а управление ремонтами - с использованием локальных унаследованных систем.
Однозначные временные границы для фаз не устанавливаются. Внедрение средств ИТ, соответствующих
определенной фазе, будет определяться готовностью и доступным бюджетом, таким образом предполагается определенный переходный период. В целом реализация фазы 2 в масштабе ОАО «МОЭСК» может,
в зависимости от выделяемого финансирования и существующего состояния ИТ, потребовать 3-5 лет.
9.1. Фаза 0
Фаза 0 соответствует текущему состоянию ИТ. Основная задача – паспортизация существующих систем и
ИТ-инфраструктуры. Другие задачи связаны с обеспечением простейшей интеграции существующих систем
«as is», для формирования оперативной отчетности. При этом предполагается, что для обмена данными
могут использоваться различные средства, в том числе электронная почта и т.п., а консолидация данных
на уровне ОАО «МОЭСК» осуществляется вручную с использованием имеющихся средств. В частности,
для сбора отчетности в соответствии с «Корпоративным регламентом информационного обмена между
подразделениями КЦ, ЦУР, БЕ, ДЗО ОАО РАО «ЕЭС России» целесообразно использовать существующие
средства сбора данных, разработанные в ОАО «ГВЦ Энергетики».
МОСКВА 2008
179
9.2. Фаза 1
На Фазе 1 реализуется настоящая Техническая политика ИТ в соответствии с планами и программами развертывания прикладных систем в рамках системных проектов. Развитие ИТ направляется прежде всего на
унификацию и стандартизацию элементов архитектуры. В ходе этой фазы основное внимание должно
быть уделено системам сбора данных с организаций уровня РСК и их обработке на уровне МРСК. Для этого
на уровне управления и филиалов МРСК внедряются промышленные решения на базе ERP-систем и создаются хранилища данных.
9.3. Фаза 2
На Фазе 2 достигается целевое состояние ИТ в рамках всей структуры ОАО «МОЭСК». Предполагается, что
это целевое состояние будет реализовано, по крайней мере, на уровнях ОАО «ФСК ЕЭС» и МРСК-РСК с использованием промышленных систем классов ERP/EAM/SCM от ведущих производителей. Главными принципами реализации являются: комплексность решения, которое должно охватить все функциональные
области, и интеграция систем как по уровням управления, так и с внешними производственными и экономическими информационными системами.
9.4. Унифицированные решения
В процессе создания ИТ-систем были заложены и прошли проверку внедрением и тиражированием ряд технических решений, удовлетворяющих современным требованиям к элементам ИТ-инфраструктуры и основным положениям настоящей Технической политики ИТ (раздел 7). Это позволяет ограничить
номенклатуру возможно равноценных, но разноплатформенных решений и в результате получить значительную экономию средств. Описанные ниже унифицированные решения относятся к целевой среде ИТ.
Прикладное ПО унифицируется путем создания типовых проектных решений и их последующей сертификации (см. раздел 8). В качестве примеров можно привести ERP решение компании SAP AG (mySAP), систему бюджетного управления на базе SAP и 1С, для систем электронного документооборота –
Автоматизированную систему управленческого документооборота (АСУД), созданную на базе программного продукта Documentum.
Унифицированные решения представляют собой базовые компоненты для создания программно-технических комплексов, к ним относятся:
вычислительная инфраструктура центров обработки данных c организацией виртуальных машин и системами управления и мониторинга;
прикладные системы;
корпоративная распределенная мультисервисная сеть с системами управления и мониторинга;
средства обеспечения информационной безопасности;
средства доступа мобильных пользователей к корпоративным ресурсам;
офисные ИТ-ресурсы, включая серверы, средства организации виртуальных машин, ПК пользователей, пакеты офисных программ, средства организации работы с общими офисными ИТ ресурсами и
централизованного управления пользовательскими ПК;
средства интеграции приложений.
180
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Основные унифицированные решения в виде Каталога рекомендованных конфигураций представлены в
приложении 5 к настоящей Технической политике ИТ.
9.5. Планирование перехода к целевому состоянию
Основные принципы реализации Технической политики в области ИТ следующие:
ОАО «МОЭСК», самостоятельно определяет последовательность и темпы перехода к целевому состоянию при условии соответствия общей стратегии, описанной выше, и обеспечения необходимой регламентной отчетности для ОАО «ФСК ЕЭС» и ОАО РАО «ЕЭС России»;
общее методологическое обеспечение и контроль развития ИТ осуществляет ОАО «ФСК ЕЭС».
Техническая политика ИТ и дополнительные, связанные с ней документы - прежде всего формализованное описание архитектуры ИТ и регламенты процессов, должны постоянно отражать происходящие изменения. Поэтому существенным фактором является обеспечение «жизненного цикла» этих документов проверка соответствия и поддержка актуальности, внесение изменений, рецензирование, информирование заинтересованных специалистов и руководителей.
В частности, предполагается, что Техническая политика ИТ разрабатывается на период 3-5 лет, но оценивается и при необходимости корректируется ежегодно.
Практическая реализация Технической политики ИТ может быть связана с рядом рисков, которые должны
быть приняты во внимание при разработке планов реализации, а именно:
Тип риска
Определение
Примеры
Действия
Бизнес/экономический
Риск того, что изменения в бизнесе
окажутся настолько значительными,
что планируемые выгоды могут не быть
достигнуты или инициатива может быть
не реализована
Ограничение возможных
инвестиций в ИТ
Фокусировка на изменении модели услуг, ограничение функционала новых внедряемых систем
наиболее актуальными задачами
Организационный
Риск того, что организационные изменения могут свести на нет ценность и
выгоды проекта
Внутренняя реорганизация, введение
альтернативных структур
управления ИТ
Планирование, коммуникация и отчетность
Технологический
Риск того, что выбранная технология не
соответствует ожиданиям или не окажется подходящей для получения нужных
результатов
По отдельности системы
не охватывают всей
области ИТ, отдельные
продукты не обеспечивают
нужной производительности
Тщательный анализ и выбор наиболее соответствующих разделов с применением лучшей
практики, приоритет на развитие интеграции,
разработка компонентной архитектуры
Риск реализации
Риск того, что организация не сможет
реализовать проект в заданные временные и бюджетные рамки, или риск, что
создание работоспособного решения
завершится неудачей
Неадекватное планирование, отсутствие четких
требований к результатам
и срокам
Превентивная и постоянная подготовка персонала
в области ITIL, управления проектами, менеджмента отношений с потребителями, привлечение
квалифицированных внешних консультантов и
партнеров
Риск сложности
Риск неудачи в том случае, если степень
сложности сильно увеличивается из-за
масштабов систем, величины требуемых
изменений или количества вовлеченных
сторон
Неполный учет
интересов всех бизнесподразделений
Организация коллегиальных органов управления,
активное участие в их работе функциональных заказчиков и постоянная обратная связь, внедрение
методологии управления проектами и портфелями инвестиций
Операционный
Риск того, что эксплуатационные расходы
новой системы возрастут до нерентабельного уровня
Стоимость услуг для
потребителей существенно превышает текущее
значение
Последовательное применение моделей оценки,
постоянное сравнение с рыночными ценами,
обеспечение четкой связи между затратами и
результатами для бизнеса
МОСКВА 2008
181
Приложение 1
к Технической политике ИТ
Определения, обозначения и сокращения
Стандартные термины и сокращения, используемые в Технической политике ИТ, приведены в соответствии с Тезаурусом ОАО РАО «ЕЭС России». Расшифровка специфических терминов и сокращений приведена в тексте по
месту употребления. В данной таблице приведены наиболее употребляемые технические термины, встречающиеся в в Технической политике ИТ.
182
Термин, сокращение
Описание
АВР
Автоматы выбора резерва
АИИС КУЭ
Автоматизированная информационно-измерительная система коммерческого учета электроэнергии
АСДТУ
Автоматизированная система диспетчерского технологического управления
АСТУ
Автоматизированные системы технологического управления
АСУ ТП
Автоматизированная система управления технологическими процессами
БЕ
Бизнес-единица
ГИС
Географические информационные системы
ДЗО
Дочерние и зависимые общества
ДМЗ
Демилитаризованные зоны
ЕИТП
Единое информационно-технологическое пространство
ИБ
Информационная безопасность
ИТ
Информационные технологии
КИС
Корпоративная информационная система
КПК
Карманный персональный компьютер
КЦ
Корпоративный центр ОАО РАО «ЕЭС России»
МРСК
Межрегиональная распределительная сетевая компания
МСЭ (firewall)
Межсетевой экран
МФУ
Многофункциональное периферийное устройство
ОС
Операционная система
ПО
Программное обеспечение
ПТК
Программно-технический комплекс
РСК
Распределительная сетевая компания
СКС
Структурированные кабельные системы
СУМ
Система управления и мониторинга
ТОиР
Техническое обслуживание и ремонт
ТПР
Типовое проектное решение - ПО или ПТК, позволяющие автоматизировать какой-либо общий для всех организацийучастников вид деятельности (например, бухгалтерский и налоговый учет, планирование и бюджетирование и т.п.)
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Термин, сокращение
Описание
ЦОД
Центр Обработки Данных
ЦУ МРСК
Центр управления МРСК в ОАО «ФСК ЕЭС»
ЦУР
Центр управления реформой ОАО РАО «ЕЭС России»
МОЭСК
Московская объединенная электросетевая компания
COBIT
Результат обобщения мирового опыта, международных и национальных стандартов и руководств в области управления ИТ, аудита и информационной безопасности
ERP
Автоматизированная система управления предприятием
IPMA
Международная ассоциации по управлению проектами
ITIL
IT Infrastructure Library - Свод правил и рекомендаций, описывающий лучшие из применяемых на практике способов
(best practice) организации работы ИТ подразделений или ИТ компаний
Middleware
Программная среда интеграции приложений
MPLS
Multiprotocol Label Switching - новый стандарт передачи данных в мультисервисных коммуникационных сетях
MTBF
Среднее время безотказной работы
NGN
Сеть следующего поколения
OSI
Open Systems Interconnection, модель Взаимодействия открытых систем
OSPF
Один из динамических протоколов маршрутизации
PMI
Институт управления проектами
QoS
Качество сетевых услуг
RPO
Целевая точка восстановления, т.е. момент, до которого необходимо восстановить данные или, другими словами, это
фактически допустимый объем потерянных данных
RTO
Целевое времени восстановления, т.е. время, необходимое на восстановление данных
SLA
Service Level Agreement - Соглашение об уровне обслуживания
SNMP
Протокол управления сетевыми устройствами
SOA
Сервис ориентированная архитектура - современная архитектура ИТ систем
Softswitch
Пакетный коммутатор для сетей следующего поколения
TCO
Общая стоимость владения
VLAN
Виртуальная локальная сеть
WAFS
Wide-Area File Services - файловые службы для глобальных сетей
Wi-Fi
Технология беспроводных сетей
xWDM
Серия технологий передачи данных по оптическим каналам с уплотнением по длине волны
МОСКВА 2008
183
Приложение 2
к Технической политике ИТ
Ориентировочные минимальные требования к рабочим местам пользователей1
2.1. Требования к характеристикам ПК
Технические
характеристики
VIP персональный
компьютер
Персональный
компьютер
Графическая рабочая
станция
Ноутбук
Аналогично Intel от 2,4
ГГц
Аналогично Intel от 1,8
ГГц
Аналогично Intel от 1,8 до
2,8 ГГц Core 2 Duo
Аналогично Intel от 1,8 до
2,2 ГГц
Частота системной шины
(FSB)
не ниже 800 МГц
не ниже 800 МГц
не ниже 800 МГц
не ниже 700 МГц
Оперативная память
1 ГБ DDR400 или
DDR2-400/533
512 МБ DDR400 или
DDR2-400/533
1-2 ГБ DDR400 или
DDR2-400/533
512 МБ-2 ГБ DDR400 или
DDR2-400/533
200 Gb SATA
100 Gb SATA
200 – 300 Gb SATA
60 - 100 Gb SATA
6хUSB 2.0, VGA, аудио
вход/выход, разъём для
микрофона, COM, LPT,
2xPS/2, RJ–45
6хUSB 2.0, VGA, аудио
вход/выход, разъём для
микрофона, COM, LPT,
2xPS/2, RJ-45
6хUSB 2.0, VGA, аудио
вход/выход, разъём для
микрофона, COM, LPT,
2xPS/2, RJ-45
2хUSB 2.0, VGA, аудио
вход/выход, разъём для
микрофона, 2xPS/2, RJ-45
Видео
128 МБ
128 МБ
128 МБ 3D ускоритель
Не менее 64 Мб
Монитор
LCD 17”
LCD 17”
Не менее LCD 19”
По необходимости
Сетевой адаптер
10/100 - 10/100/1000
10/100 - 10/100/1000
10/100 - 10/100/1000
10/100 - 10/100/1000
Дисковод
Дисковод DVD-CDRW
combo
Дисковод DVD-RW combo
Дисковод DVD-RW combo
Дисковод DVD-RW combo
Оптическая мышь,
Клавиатура
Оптическая мышь,
Клавиатура
Оптическая мышь,
Клавиатура
Оптическая мышь
Наличие контроля температуры процессора и
оборотов вентилятора
Наличие контроля температуры процессора и
оборотов вентилятора
Наличие контроля температуры процессора и
оборотов вентилятора
Наличие контроля температуры процессора
3 года
3 года
3 года
3 года
Процессор
Жесткий диск
Внешние порты ввода/
вывода
Устройства ввода/вывода
Система мониторинга
Гарантия
1Примечание: Технические характеристики оборудования и программного обеспечения, содержащиеся в этом и
последующих приложениях, приводятся с учетом рекомендаций Основных положений Технической политики Холдинга в области информационных технологий ОАО РАО «ЕЭС России», утвержденных решением Правления ОАО
РАО «ЕЭС России» от 07.11.2006 № 1564 пр/1. Приведенные характеристики носят рекомендательный характер,
они будут регулярно пересматриваться по мере развития соответствующих программно-технических средств.
Минимальные требования к монитору:
монитор LCD, TFT, цветной, диагональ – не менее 15''
размер шага между пикселями – не более 0,264 мм
рабочее разрешение – не ниже 1280х1024
угол просмотра – не хуже чем: по горизонтали 150 град., по вертикали 140 град;
яркость – не ниже 250 кд/м2
контрастность – не ниже чем 450:1
время отклика пикселя – не более 16 мс
цветовая палитра – макс. 24-бит. (16777216 цветов)
энергопотребление – не более 34 Вт
поддержка DDC2B
соответствие эргономическому стандарту ТСО’03
соответствие стандартам Energy Star (EPA) и DPMS по энергосбережению
184
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
2.2. Требования к периферийным устройствам
2.2.1. Требования к принтерам
Вид
Принтер
лазерный
монохромный
Принтер цветной офисный
лазерный
Принтер цветной офисный
струйный
Принтер
цветной для
дизайна и
фотопечати
Принтер
цветной для
проектирования и картографии
Категория
Характеристика
Минимальное значение
Скорость монохромной печати А4
18 стр./мин (формат А4)
Разрешение при печати
600x600 точек на дюйм
Время выхода первого отпечатка
не более 10 с
Устройство подачи бумаги
кассета на 250 листов
Формат бумаги
A4, B5, A5, Letter, Executive, конверты C5/COM10/DL/Monarch
Интерфейс с ПК
USB
Персональный
Персональный
Персональный
Скорость печати
цветная печать: 8 стр./мин (формат A4)
Разрешение при печати
600x600 точек на дюйм
Время выхода первого отпечатка
не более 20,0 с в монохромном и цветном режиме
Устройства подачи бумаги
кассета на 250 листов
Формат бумаги
A4, B5, A5, Legal, Letter, Executive, конверты C5/COM10/DL/Monarch/
B5, каталожные карточки
Интерфейс с ПК
USB 2.0
Разрешение при печати
2400 х 1200 точек на дюйм
Способ печати
4–цветная система печати
Скорость цветной печати
страница полного формата A4: 120 с
Формат материала для печати
A4, B5, A5, Letter, Legal, конверты (размер DL или Commercial 10),
10 x 15 см, 13 x 18 см
Интерфейс с ПК
USB
Разрешение при печати
4800 x 2400 точек на дюйм
Способ печати
6–цветная система струйной печати, объём капли 2 пл
Скорость фотопечати
печать «в край» (без полей), формат 10x15 см: 25 с
Тип материала для печати
обычная бумага, конверты, профессиональная фотобумага
Формат материала для печати
A4, B5, A5, Letter, Legal, конверты (формата DL или Commercial 10),
10 x 15 см, 10 x 18 см (широкоформатная), 13 х 18 см, 20 х 25 см,
формат кредитной карты (54 x 86 мм) кассета: A4, B5, Letter
Плотность материала для печати
64 – 105 г/м
Персональный
Прямая печать на DVD/CD
Да
Интерфейс с ПК
USB 2.0
Разрешение при печати
1200x1200 точек на дюйм
Способ печати
5–цветная система
Формат материала для печати
A2
Интерфейс с ПК
USB 2.0 или Fast Ethernet
Персональный
МОСКВА 2008
185
Вид
Принтер
лазерный
Принтер
цветной для
фотопечати,
проектирования и картографии
Принтер
Принтер
цветной для
фотопечати,
проектирования и картографии
Категория
Групповой
Групповой
Корпоративный
Корпоративный
Характеристика
Минимальное значение
Тип
Монохромный или цветной
Двусторонняя печать
Да
Скорость монохромной печати А4
30 стр./мин (формат А4)
Разрешение при печати
1200x1200 точек на дюйм
Время выхода первого отпечатка
не более 10 с
Устройство подачи бумаги
кассета на 500 листов
Формат бумаги
A3, A4, B5, A5, LTR, Executive, конверты C5/COM10/DL/Monarch
Интерфейс
Сервер печати с FastEthernet
Поддержка языков
PCL5e, PCL6
Разрешение при печати
1200x1200 точек на дюйм
Способ печати
6–цветная система
Формат материала для печати
A1
Интерфейс с ПК
Сервер печати Fast Ethernet
Время печати A1
4 минуты
Требуется применять МФУ
См. требования к МФУ
Разрешение при печати
1200x1200 точек на дюйм
Способ печати
12–цветная система
Формат материала для печати
60 дюймов
Интерфейс с ПК
Сервер печати Fast Ethernet
Время печати A1
1 минута
2.2.2. Требования к сканерам
Вид
Сканер
Сканер
186
Категория
Персональный
офисный
Групповой /
Корпоративный
Характеристика
Минимальное значение
Тип
Настольный планшетный
Сканирование
Чёрно белое и цветное
Оптическое разрешение
3200x3200 точек на дюйм
Интерфейс
USB 2.0
Разрядность сканирования
24 бита
Максимальный формат документа
A4
Необходимо использовать МФУ. См. требования к МФУ
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
2.2.3. Требования к копировальным устройствам
Вид
Категория
Копир черно-белый
Копир черно-белый
Копир черно-белый
Персональный
Характеристика
Минимальное значение
Скорость копирования А4
20 стр./мин
Разрешение
600 x 600 dpi
Выход первой копии
не более 8 секунд
Полный дуплекс
Копирование 1–>2, 2–>2, 2–>1
Одно сканирование – много копий
Да
Лоток для бумаги
250 листов
Типы носителей
Бумага, плёнки, этикетки
Производительность
20000 копий/месяц
Число одновременно выполняемых копий
50
Скорость копирования А4
30 стр./мин
Разрешение
1200 x 1200 dpi
Выход первой копии
не более 6 секунд
Полный дуплекс
Копирование 1–>2, 2–>2, 2–>1
Одно сканирование – много копий
Да
Сортировщик копий
Да
Степлер
Да
Масштабирование
Да
Лоток для бумаги
1000 листов
Типы носителей
Бумага, плёнки, этикетки до A3
Производительность
150000 копий/месяц
Число одновременно выполняемых копий
500
Скорость копирования А4
80 стр./мин
Разрешение
600 x 600 dpi
Выход первой копии
не более 4 секунд
Полный дуплекс
Копирование 1–>2, 2–>2, 2–>1
Одно сканирование – много копий
Да
Сортировщик копий
Да
Степлер
Да
Масштабирование
Да
Групповой
Корпоративный
МОСКВА 2008
Лоток для бумаги
5000 листов
Типы носителей
Бумага, плёнки, этикетки до A3
Производительность
500000 копий/месяц
Число одновременно выполняемых копий
1000
187
Вид
Копир цветной
Копир цветной
188
Категория
Характеристика
Минимальное значение
Скорость копирования А4
20 стр./мин
Разрешение
1200 x 1200 dpi
Выход первой копии
6 секунд
Полный дуплекс
Копирование 1–>2, 2–>2, 2–>1
Одно сканирование – много копий
Да
Сортировщик копий
Да
Степлер
Да
Масштабирование
Да
Лоток для бумаги
1000 листов
Типы носителей
Бумага, плёнки, этикетки до A3
Производительность
150000 копий/месяц
Число одновременно выполняемых копий
500
Скорость копирования А4
50 стр./мин
Разрешение
2400 x 2400 dpi
Выход первой копии
4 секунды
Полный дуплекс
Копирование 1–>2, 2–>2, 2–>1
Одно сканирование – много копий
Да
Сортировщик копий
Да
Степлер
Да
Масштабирование
Да
Лоток для бумаги
5000 листов
Типы носителей
Бумага, плёнки, этикетки до A3
Ресурс
300000 копий/месяц
Число одновременно выполняемых копий
1000
Групповой
Корпоративный
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
2.2.4. Требования к многофункциональным устройствам (МФУ)
Вид
Категория
МФУ с лазерной печатью
МФУ со струйной печатью
Персональный
Персональный
МОСКВА 2008
Характеристика
Минимальное значение
Скорость монохромной печати А4
18 стр./мин (формат А4)
Разрешение при печати
600x600 точек на дюйм
Функции аппарата
печать, сканирование и копирование
Тип сканера
планшетный
Время выхода первого отпечатка
не более 10 с
Устройство подачи бумаги
кассета на 250 листов
Формат бумаги
A4, B5, A5, LTR, Executive, конверты C5/COM10/DL/Monarch
Разрешение при сканировании
1200x2400 точек на дюйм
Глубина цветного сканирования
24 бита
Разрешение при копировании
600x600 точек на дюйм
Скорость копирования
20 копий/мин
Количество копий за цикл
50
Интерфейс с ПК
USB
Скорость печати
цветная печать: 8 стр./мин (формат A4)
Разрешение при печати
1200x1200 точек на дюйм
Время выхода первого отпечатка
не более 20,0 с в монохромном и цветном режиме
Устройства подачи бумаги
кассета на 250 листов
Формат бумаги
A4, B5, A5, Legal, Letter, Executive, конверты C5/COM10/DL/
Monarch/ B5, каталожные карточки
Функции аппарата
печать, сканирование и копирование
Тип сканера
планшетный
Время выхода первого отпечатка
не более 10 с
Разрешение при сканировании
2400x2400 точек на дюйм
Глубина цветного сканирования
24 бита
Разрешение при копировании
600x600 точек на дюйм
Скорость копирования
20 копий/мин
Количество копий за цикл
50
Интерфейс с ПК
USB 2.0
189
Вид
МФУ с
лазерной
печатью
МФУ с
лазерной
печатью
190
Категория
Групповое
Характеристика
Минимальное значение
Принцип
цифровой
Запас бумаги
кассета на 1000 листов
Формат бумаги
A3, A4, B5, A5, Legal, Letter, Executive, конверты C5/COM10/
DL/Monarch/ B5, каталожные карточки
Функции аппарата
печать, сканирование, копирование, отправка на электронный ящик
Плотность бумаги
64 – 163 г/м2
Время выхода первой копии (1:1, A4)
не более 8 с
Скорость копирования (1:1, A4)
30 копий/мин
Разрешение сканирования
600x600 dpi аппаратное
Разрешение печати
2400x600 dpi с интерполяцией
Максимальное количество копий за один цикл
500
Языки описания страниц
PCL5c, Adobe PostScript 3
Двусторонняя печать
Да
Автоподача при сканировании
Да
Сортировщик копий
Да
Интерфейс
Fast Ethernet
Принцип
цифровой
Функции аппарата
печать, сканирование, копирование, брошюрование, отправка
на электронный ящик
Запас бумаги
стойка на 2500 листов
Формат бумаги
A3, A4, B5, A5, Legal, LTR, Executive, конверты C5/COM10/
DL/Monarch/B5, каталожные карточки
Плотность бумаги
64 – 209 г/м2
Время выхода первой копии (1:1, A4)
не более 8 с
Скорость копирования (1:1, A4)
50 копий/мин
Разрешение сканирования
600x600 dpi аппаратное
Разрешение печати
2400x600 dpi с интерполяцией
Материалы для копирования
Обычная бумага, пленки (прозрачные, матовые и самоклеющиеся), конверты, трансферные материалы, мелованная и
метализированная бумага
Корпоративное
Максимальное количество копий за один цикл
500
Языки описания страниц
PCL5c, Adobe PostScript 3
Жесткий диск
20 Гбайт
Двусторонняя печать
Да
Автоподача при сканировании
Да
Сортировщик копий
Да
Степлер
Да
Интерфейс
Fast Ethernet
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
2.2.5. Требования к факсам
Вид
Категория
Факсимильный аппарат
со струйной печатью
Факсимильный аппарат с
лазерной печатью
Факсимильный аппарат с
лазерной печатью
Персональный
Характеристика
Минимальное значение
Группа факса
3
Тип сканера
Полистовой
Телефонная линия
Коммутируемая телефонная сеть общего пользования
Устройство автоматической подачи
документов
15 листов
Формат документа
A4
Разрешение при печати
360x360 точек на дюйм
Ресурс бумаги
50 листов – устройство автоматической подачи бумаги
Скорость модема
14,4 кбит/с (передача); 9,6 кбит/с (приём)
Проводная телефонная трубка
Да
Автоответчик
Да
Группа факса
3
Тип сканера
Полистовой
Телефонная линия
Коммутируемая телефонная сеть общего пользования
Устройство автоматической подачи
документов
50 листов
Формат документа
A4
Групповой
Корпоративный
Разрешение при печати
1200x1200 точек на дюйм
Полутона
256 оттенков серого
Ресурс бумаги
500 листов – устройство автоматической подачи
бумаги
Скорость модема
33,6 кбит/с
Проводная телефонная трубка
Да
Необходимо использовать МФУ
Приложение 3
к Технической политике ИТ
Требования к компонентам мультисервисной сети
3.1. Требования к оборудованию локальных вычислительных сетей
Выбираемое оборудование для построения уровня ядра и распределения локальной вычислительной сети
должно обладать следующими свойствами:
поддерживать обработку пользовательских данных на основе информации уровней 2-7 (L2-L7) модели
взаимодействия открытых систем OSI;
коммутирующая производительность не менее 720 Гбит/с;
МОСКВА 2008
191
возможность обработки до 400 Mpps пакетов в секунду в режиме распределенной коммутации;
модульное исполнение;
поддерживать технологию организации виртуальных локальных сетей VLAN, а также образовывать
транковые соединения между коммутаторами в соответствии со стандартом 802.1q;
возможность резервирования коммутационных и управляющих ресурсов, источников электропитания;
возможность установки сервисных модулей, обеспечивающих интегрированную функциональность
межсетевого экранирования, системы обнаружения и предотвращения вторжений, терминации VPN,
мониторинга и анализа трафика, шлюза голос-через-IP (VoIP), сервисов беспроводной сети;
широкий выбор интерфейсов, от 10/100 Ethernet до 10G Ethernet, с возможностью выбора, как медных
электрических интерфейсов, так и оптических интерфейсов с широким диапазоном поддерживаемых
типов оптического волокна, дистанций и т.д., в том числе поддержку технологий грубого/тонкого
спектрального уплотнения Coarse Wavelength Division Multiplexing/Dense Wavelength Division Multiplexing;
механизмы обеспечения быстрого восстановления после сбоев – от 1 до 3-х секунд в случае сбоя
активного управляющего модуля и переключения на резервный, находящийся в режиме «горячего
резервирования»;
поддержка механизмов Non-Stop-Forwarding (NFS), обеспечивающих быстрое восстановление после
сбоев на уровне протоколов 3-го уровня;
модульную операционную систему, позволяющую проводить модернизацию и перезапуск отдельных
программных компонент без влияния на основную операционную систему;
поддерживать технологию In-Service Software Upgrades (ISSU), позволяющую модернизировать
операционную систему устройства без перерыва в сервисах;
поддерживать протоколы резервирования «шлюза по умолчанию» Virtual Router Redundancy Protocol/Hot Standby Router Protocol/Gateway Load Balancing Protocol;
обеспечивать аппаратную поддержку маршрутных таблиц и таблиц служебной информации в объеме,
необходимом для крупных корпоративных сетей и сетей операторов связи;
иметь аппаратную поддержку IPv6;
иметь аппаратную поддержку технологии организации виртуальных частных сетей MPLS (MultiProtocol
Label Switching) VPN;
обеспечивать дистанционное электропитание устройств, подключаемых к портам интерфейсных
модулей в соответствии со стандартом 802.3af;
поддерживать высокопроизводительные голосовые и видео- приложения на основе технологии
многоадресной рассылки IP Multicast;
поддерживать протоколы динамической маршрутизации Open Shortest Path First/Enhanced Interior Gateway Routing Protocol/Border Gateway Protocol;
поддерживать возможность аутентификации пользователей и ресурсов в соответствии со стандартами
802.1x и контроля сетевого доступа Network Admission Control;
поддерживать технологию Channeling, позволяющую объединять в виртуальное транковое соединение
до 8-ми физических интерфейсов 10/100/1000 Ethernet, 10G Ethernet;
поддерживать протоколы IEEE 802.1w Rapid Spanning Tree, IEEE 802.1s MSTP, Per-VLAN Rapid Spanning Tree;
поддерживать технологию зеркалирования данных на выбранный порт или VLAN из группы портов;
обеспечивать поддержку технологии Time Domain Reflectometer, позволяющую тестировать кабельную
систему и определять неисправности в кабельной системе;
обеспечивать поддержку механизмов обеспечения качества обслуживания;
обеспечивать поддержку Jumbo Frames;
поддерживать протоколы мониторинга и управления SNMP v1/2c/3, NTP, SYSLOG, TFTP, RCP, TELNET, SSH;
поддерживать механизмы обеспечения параметров качества обслуживания QoS – классификацию, организацию очередей, предотвращение перегрузок, полисинг (ограничение трафика), перезапись полей,
управления очередями;
192
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
поддерживать модульный интерфейс конфигурации параметров качества обслуживания MQC;
иметь механизмы защиты контрольной шины устройства (Control Plane Policing);
механизмы классификации трафика должны принимать решение на основе следующей информации:
класса обслуживания DSCP, класса обслуживания IP Precedence, идентификатора VLAN, типа протокола
сетевого/транспортного уровней и выше, MAC-адреса, значения бита CoS в заголовке 802.1q, длинны
пакета, входящего интерфейса, списка контроля доступа (ACL), значения EXP поля MPLS;
должен поддерживаться механизм управления перегрузками Weighted Random Early Detection;
должен поддерживаться механизм управления очередями Weighted Round Robin, Deficit Weighted Round
Robin, Shaped Round Robin, приоритетные очереди Priority Queuing.
Выбираемое оборудование для построения уровня доступа локальной вычислительной сети должно обладать следующими свойствами:
иметь модульное или фиксированное исполнение;
поддерживать обработку пользовательских данных на основе информации L2-L7 модели OSI;
коммутаторы фиксированной конфигурации должны иметь возможность образовывать высокопроизводительные стеки с единой высокопроизводительной шиной до 32 Гбит/с и возможностью единого
управления стеком коммутаторов из интерфейса командной строки/графической системы управления,
а также, с возможностью организации единых процессов функционирования служебных протоколов в
масштабе стека;
поддерживать технологию организации виртуальных локальных сетей VLAN, а также образовывать
транковые соединения между коммутаторами в соответствии со стандартом 802.1q;
возможность резервирования коммутационных и управляющих ресурсов, источников электропитания;
широкий выбор интерфейсов, от 10/100 Ethernet до 10G Ethernet, с возможностью выбора, как медных
электрических интерфейсов, так и оптических интерфейсов с широким диапазоном поддерживаемых
типов оптического волокна, дистанций и т.д., в том числе поддержку CWDM;
механизмы обеспечения быстрого восстановления после сбоев – от 1 до 3-х секунд в случае сбоя активного управляющего модуля и переключения на резервный, находящийся в режиме «горячего резервирования»;
поддержка механизмов NSF, обеспечивающих быстрое восстановление после сбоев на уровне протоколов 3-го уровня;
поддерживать протоколы резервирования «шлюза по умолчанию» VRRP/HSRP;
обеспечивать аппаратную поддержку маршрутных таблиц и таблиц служебной информации в объеме,
необходимом для крупных корпоративных сетей и сетей операторов связи;
обеспечивать дистанционное электропитание устройств, подключаемых к портам интерфейсных модулей в соответствии со стандартом 802.3af;
поддерживать высокопроизводительные голосовые и видео- приложения на основе IP Multicast;
поддерживать протоколы динамической маршрутизации OSPF/EIGRP/BGP;
поддерживать возможность аутентификации пользователей и ресурсов в соответствии со стандартами
802.1x и NAC;
поддерживать технологию Channeling, позволяющую объединять в виртуальное транковое соединение
до 8-ми физических интерфейсов 10/100/1000 Ethernet, 10G Ethernet;
поддерживать протоколы IEEE 802.1w Rapid Spanning Tree, IEEE 802.1s MSTP, Per-VLAN Rapid Spanning Tree;
поддерживать технологию зеркалирования данных на выбранный порт или VLAN из группы портов;
обеспечивать поддержку технологии Time Domain Reflectometer, позволяющую тестировать кабельную
систему и определять неисправности в кабельной системе;
обеспечивать поддержку механизмов обеспечения качества обслуживания;
обеспечивать поддержку Jumbo Frames;
поддерживать протоколы мониторинга и управления SNMP v1/2c/3, NTP, SYSLOG, TFTP, RCP, TELNET, SSH;
МОСКВА 2008
193
поддерживать механизмы обеспечения параметров качества обслуживания QoS – классификацию, организацию очередей, предотвращение перегрузок, полисинг (ограничение трафика), перезапись полей,
управления очередями;
поддерживать модульный интерфейс конфигурации параметров качества обслуживания MQC;
должен поддерживаться механизм управления очередями Weighted Round Robin, Shaped Round Robin,
приоритетные очереди Priority Queuing;
должен поддерживаться механизм управления перегрузками Weighted Tail Drop.
3.2. Требования к оборудованию IP-телефонии и передачи голоса через IP
Оборудование IP-телефонии должно обладать следующими свойствами:
должна быть обеспечена возможность разделения трафика голоса и данных путем использования различных VLAN, а также возможность автоматической конфигурации настроек, относящихся к протоколу
IP, для абонентских терминалов;
должна отсутствовать возможность для конечного пользователя изменять конфигурацию VLAN, использующегося для транспортировки голосового трафика;
в точке сети, где осуществляется взаимодействие голосового VLAN и VLAN данных, должны быть обеспечены меры безопасности, регламентирующие такое взаимодействие;
должна обеспечиваться возможность для пользователя запускать приложения на IP-телефоне;
решение может строиться на базе стандартных (Microsoft Windows, UNIX) и частных разработок операционных систем;
в качестве сигнальных протоколов в решении могут применяться стандартные (MGCP, SIP, H.323), а
также частные разработки производителей;
в качестве аппаратных платформ для построения центра обработки вызовов могут быть использованы
как стандартные платформы, так и собственные разработки производителей;
решение должно обеспечивать возможность построения отказоустойчивого центра обработки вызовов.
система должна иметь возможность хранения пользовательской информации – имени пользователя,
телефонного номера пользователя, короткого номера пользователя и представлять эти данные в стандартной форме при необходимости экспорта;
служба каталогов, в которых хранятся персональные данные, должна иметь возможность взаимодействия с внешней службой каталогов, такой, например, как active directory;
должна быть обеспечена поддержка индустриальных стандартов, использующихся при передаче голоса через IP:
голосовой кодек G.711;
голосовой кодек G.729a;
стандарт H.323 V2;
стандарт протокола сигнализации Q.931;
поддержка факса группы 3;
транспортный протокол RTP и CRTP;
стандарт MGCP;
стандарт SIP;
стандарты H.225, H.245;
ПО сервера обработки вызовов должно устанавливаться на платформу, имеющую средства обеспечения отказоустойчивого функционирования;
пользовательская база данных и база данных конфигураций должны иметь средства обеспечения отказоустойчивости:
возможность организации репликации
автоматизированную процедуру репликации;
194
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
решение должно обеспечивать автоматическую регистрацию абонентских терминалов – устройство,
подключенное к ЛВС, автоматически регистрируется в системе обработки вызовов и сразу после этого
может быть задействовано;
изменения в конфигурации абонентского терминала также должны автоматически сохраняться в системе, после отключения и нового подключения терминала к ЛВС должны автоматически загружаться
в устройство;
система должна иметь возможность интеграции с внешними приложениями;
каждый DSP-ресурс должен иметь джиттер-буфер;
система должна быть совместима со стандартом ITU G.165 для поддержки эхо-подавления;
все телефоны должны иметь возможность присвоения уникального IP-адреса;
все телефонные аппараты должны иметь встроенный спикерфон для организации громкой связи;
каждый телефон должен иметь встроенный графический дисплей (предпочтительно цветной);
телефон должен иметь программируемые клавиши для организации короткого набора, мониторинга занятости линий, доступа к адресной книге, работы с приложениями;
IP-телефон должен иметь встроенный коммутатор Ethernet для подключения ПК;
IP-телефон должен иметь функционал, позволяющий отслеживать набранные/отвеченные/пропущенные вызовы;
телефон должен иметь возможность выбора номера из списка набранных/отвеченных/пропущенных
звонков в экранном меню для последующего набора;
IP-телефон должен иметь возможность выбора варианта сигнала вызова абонента;
IP-телефон должен иметь поддержку по меньшей мере двух различных кодеков: G.711, G.729a;
абонентские терминалы и голосовые шлюзы должны обеспечивать маркирование соответствующих
пакетов для обеспечения параметров качества обслуживания;
устройства сети должны автоматически определять наличие IP-терминала и применять требуемую конфигурацию параметров QoS к сетевому порту, к которому производится подключение устройства. Параметры конфигурации порта должны автоматически возвращаться в исходное состояние после
отключения IP-терминала;
сервер обработки вызовов должен поддерживать стандарт ITU-T H.323 для возможности организации
взаимодействия между IP-телефонами и мультимедийными устройствами, поддерживающими стандартный стек протоколов, например, Microsoft NetMeeting;
в случае использования частной реализации сигнального протокола, система обработки вызовов
должна поддерживать как минимум один из открытых стандартов, например SIP или H.323;
абонентский терминал (IP-телефон) должен обладать следующей функциональностью:
возможность приоритезации голосовых пакетов;
регулировка громкости;
автоматическое эхоподавление;
программируемые кнопки для реализации следующих функций - перевод звонка в случае занятости абонента, перевод звонка по неответу абонента, перевод всех звонков, удержание звонка/снятие с удержания, парковка звонка/снятие с парковки, передача вызова;
инициирование конференции;
служба каталогов – возможность набора номера из корпоративного справочника, детализированного списка набранных номеров, пропущенных и принятых звонков;
возможность подключения гарнитуры;
повтор последнего набранного номера;
возможность принимать несколько звонков на одну линию;
поддержка нескольких линий на аппарат;
поддержка музыки на удержании;
МОСКВА 2008
195
196
регулировка громкости звонка;
возможность организации общей линии на нескольких аппаратах;
выключение спикерфона;
кнопки быстрого набора;
поддержка видео;
должна существовать возможность удаленного электропитания аппарата в соответствии с рекомендацией IEEE 802.3af;
загрузка конфигурационного файла по TFTP/FTP;
IP-телефонное решение также должно обеспечивать следующие функции:
автоматический выбор занимаемой полосы пропускания для каждого из соединений в зависимости
от параметров соединения;
детализированная информация о соединении (CDR);
сбор статистики и генерация отчетов;
поддержку интерфейсов JTAPI/TAPI;
консоль оператора;
возможность администрирования системы через Web-интерфейс;
Web-интерфейс пользователя – параметры клавиш быстрого набора, пользовательские настройки;
справочная информация и документация, доступная через Web-интерфейс;
переадресация звонков должна осуществляться по следующим условиям:
абонент занят;
абонент не отвечает;
всех звонков;
система обработки вызовов должна обеспечивать возможность переадресации звонков в случае, если
вызываемый аппарат временно отсутствует в системе. Должна обеспечиваться возможность предварительной настройки функции;
система обработки вызовов должна обеспечивать возможность переадресации звонков в случае, если вызываемый абонент не отвечает. Должна обеспечиваться возможность предварительной настройки функции;
система обработки вызовов должна обеспечивать функцию ожидания, перенаправляя поступивший
вызов в очередь и позволяя пользователю обработать несколько одновременных вызовов;
система обработки вызовов должна обеспечивать возможность парковки внешних и внутренних вызовов;
функция парковки вызова должна позволять пользователю перехватывать вызов на другом IP-телефоне, используя код доступа;
функция парковки вызова должна обеспечивать возможность отображения на IP-телефонах участников
виртуальной группы, к которой принадлежит вызываемый абонент, информации о запаркованном звонке;
если припаркованный звонок не отвечен в течение заданного промежутка времени, он должен быть
перенаправлен на телефонный аппарат, инициировавший парковку вызова;
система обработки вызовов должна обеспечивать возможность реализации функции удержания звонка,
при использовании которой поступивший вызов помещается в очередь. Вызовы, находящиеся на удержании, должны оставаться активными, однако ни вызывающий абонент, ни вызываемый абонент не
должны иметь возможность аудио-контакта. В момент постановки звонка на удержание должна обеспечиваться возможность обработки других вызовов;
IP-телефон должен иметь возможность через заданный промежуток времени возвращаться к исходному состоянию, предшествовавшему установлению соединения, в случае, если соединение было завершено некорректно;
система IP-телефонии должна иметь возможность проигрывания музыки на удержании. Музыка
должна проигрываться в следующих случаях:
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
вызов находится на удержании;
вызов находится в процессе переадресации;
вызов запаркован;
система должна обеспечивать возможность организации конференцсвязи двух типов – конференция, инициированная абонентом в процессе вызова (ad-hoc) и конференция с возможностью добавления абонентов
по набору дополнительного телефонного номера, ассоциированного с конференцией (meet-me);
должна обеспечиваться возможность динамической конфигурации IP-телефонных аппаратов на основании виртуального профиля пользователя, без привязки к месту подключения IP-телефона;
решение должно обеспечивать возможность пользователя импортировать собственные настройки в IP
телефон, без необходимости реконфигурации терминала используя web-интерфейс. Вместо web-интерфейса должен использоваться login-сервис с аутентификацией пары логин/пароль, принадлежащей пользователю. Пользовательский интерфейс login-сервиса должен быть доступен с IP-телефона;
система обработки вызовов должна обеспечивать сохранение информации о соединениях в общепринятом стандарте, с возможностью экспорта и обработки внешним приложением;
решение должно обеспечивать возможность интеграции с существующим оборудованием видеоконференцсвязи, поддерживающим открытый стандарт ITU-T H.323;
возможности поддержки видеотелефонии должны обеспечивать поддержку видео в соединениях точкаточка и многоточечных конфигурациях;
решение должно обеспечивать возможность управления полосой пропускания видеозвонков через ГВС,
в противном случае возможно возникновение дефицита полосы пропускания канала связи для других
приложений;
решение должно предоставлять возможность альтернативного соединения в случае, когда видеозвонок невозможен, в связи с дефицитом полосы пропускания канала ГВС;
решение должно обеспечивать единую базу информации о соединениях (CDR) для видео- и аудио- вызовов;
решение должно обеспечивать единый план нумерации для терминалов с поддержкой только голоса
и терминалов с поддержкой голоса и видео;
предлагаемое решение должно обеспечивать возможность управления системой в целом. Система
управления должна иметь графический интерфейс, дополнительно может использоваться интерфейс
командной строки;
решение должно предусматривать механизмы отказоустойчивости в распределенной архитектуре с
централизованной обработкой вызовов, при отказе канала ГВС должна существовать возможность осуществления телефонных звонков в пределах удаленного офиса, а также автоматической перемаршрутизации звонков через ТФОП вместо ГВС.
Оборудование для передачи голоса через IP должно обладать следующими свойствами:
должна существовать возможность реализации одновременной функциональности маршрутизатора/шлюза VoIP;
должны поддерживаться аналоговые интерфейсы FXS, FXO, E&M;
должны поддерживаться цифровые интерфейсы E1, BRI;
должны поддерживаться механизмы организации очередей и управления очередями для обеспечения
параметров качества обслуживания Low Latency Queuing (LLQ), Class-Based Weighted Fair Queuing (WFQ),
CB-WFQ, Class-Based CB-Weighted Random Early Detection;
должны поддерживаться стандарты Media Gateway Control Protocol (MGCP), H.323 и Session Initiated
Protocol (SIP);
должен быть поддержан протокол Resource Reservation Protocol, а также существовать механизмы
обеспечения качества сервиса Call Admission Control (CAC).hjv
МОСКВА 2008
197
3.3. Требования к оборудованию обеспечения информационной безопасности
Оборудование построения виртуальных частных сетей IP VPN на основе технологий шифрования трафика
должно обеспечивать следующие возможности:
обеспечивать поддержку IPSec ESP и AH при использовании ГОСТ 28147-89;
обеспечивать полную совместимость с IKE и IPSec-решениями (RFC 2401-2412);
поддерживать технологию трансляции сетевых адресов Поддержка NAT Transparent IPSec;
поддерживать совместимость с разными системами PKI (Microsoft с CryptoPro, Notary-Pro, Валидата,
RSA Keon);
поддерживать сертификаты – LDAPv3, x509v3, PKCS#7, #10 и #12, CRL;
поддерживать IKE при использовании ГОСТ Р 34.10-94, ГОСТ Р 31.10-2001;
обеспечивать приоритезацию мультимедийного трафика;
обеспечивать отказоустойчивость за счет автоматического переключения на резервный шлюз;
обеспечивать перенос IP-адресов отказавшего устройства на резервное устройство;
поддерживать технологию обнаружения отказавшего устройства DPD (Dead Peer Detection).
Межсетевые экраны должны обеспечивать следующие возможности:
представлять решение на базе специализированной аппаратной платформы, ориентированное на высокую производительность, вплоть до скорости канала;
поддерживать технологии организации виртуальных частных сетей VPN;
иметь встроенную систему обнаружения атак;
обеспечивать фильтрацию URL и блокировать ПО P2P сетей и систем обмена сообщениями;
обеспечивать функциональность прозрачного межсетевого экрана второго уровня;
обеспечивать функциональность виртуальных межсетевых экранов на базе одного физического устройства;
иметь возможность создания отказоустойчивых конфигураций;
поддерживать трансляцию сетевых адресов NAT и PAT;
обеспечивать контроль приложений, в том числе IP-телефонии;
поддерживать стек протоколов IPv4 и IPv6;
поддерживать ролевое управление с разграничением функциональности;
поддерживать технологию организации виртуальных частных сетей VLAN;
обеспечивать защиту от подмены IP/MAC-адресов;
поддерживать списки контроля доступа;
обеспечивать возможность ограничения использования ресурсов;
поддерживать различные механизмы аутентификации, в том числе RADIUS и TACACS+;
обеспечивать контроль доступа по времени;
защищать от атак “переполнение буфера”, нарушения RFC, аномалий, подмены адреса;
обеспечивать антивирусную защиту в трафике HTTP, FTP, SMTP, POP3;
защищать от программ-шпионов;
обнаруживать и блокировать спам;
обеспечивать защиту от перехвата и подмены идентификационной информации;
защищать в режиме реального времени web-доступ, web-почту и передачу файлов через Web;
обеспечивать контентную фильтрацию почтовых сообщений, позволяющую избежать несанкционированной отправки конфиденциальной информации.
Системы обнаружения и предотвращения вторжений должны обеспечивать следующие возможности:
поддерживать широкий спектр алгоритмов обнаружения атак (сигнатуры, аномалии, эвристика, отклонения от RFC и других);
198
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
обеспечивать защиту от методов обхода;
возможность работы одновременно в двух режимах – обнаружения и предотвращения атак;
обнаруживать атаки на IP-телефонию и АСУ ТП (SCADA);
обнаруживать скрытой работы интернет-пейджеров;
обеспечивать автоматический выбор реагирования в зависимости от степени угрозы;
поддерживать протокол SDEE для обеспечения взаимодействия устройств различных производителей;
обеспечивать высокую производительность;
обнаруживать атаки в инкапсулированном трафике MPLS, GRE, IPv6, Mobile IP-in-IP;
интеграция с коммутаторами и маршрутизаторами для блокирования атак путем изменения ACL или
ограничения скорости передачи трафика (Rate Limiting);
возможность распределения нагрузки между несколькими сенсорами и обеспечение отказоустойчивости;
выборочное блокирование (не всего IP-адреса, а только атакующего сервиса)
поддерживать технологию организации виртуальных частных сетей VLAN;
иметь возможность эффективного предотвращения атак в коммутируемых сетях.
Программное обеспечение защиты рабочих станций и серверов от несанкционированного воздействия
должно обеспечивать следующие возможности:
интегрироваться с Active Directory, LDAP, NIS;
поддерживать автоматическую смену политик контроля в зависимости от имени пользователя и его
местоположения в сети;
обеспечивать 2 типа корреляции событий безопасности – локальную и централизованную (от нескольких агентов);
обеспечивать прозрачность установки, не требующую участия владельца компьютера;
автоматизировать создание политик контроля;
инвентаризировать установленное ПО;
интегрироваться в архитектуру контроля сетевого доступа NAC;
делегировать отдельные функции управления агентом пользователю;
функционировать на платформах Windows (серверы; рабочие станции, включая Tablet PC), Linux, Solaris, VMWare;
интегрироваться с сетевыми системами предотвращения атак;
поддерживать специальные группы правил для блокирования утечки информации;
обеспечивать контроль загрузки с несанкционированных носителей (CD, дискета, сеть и т. д.) за счет
интеграции с технологией Intel AMT.
Оборудование мониторинга, анализа и реакции на события должно обеспечивать следующие возможности:
собирать информацию о сетевых событиях, изучать топологию сети и конфигурацию маршрутизаторов, коммутаторов и межсетевых экранов, а также анализировать сетевой трафик;
создавать топологическую схему сети, содержащую информацию о конфигурации устройств и действующих политиках безопасности;
интегрироваться в архитектуру контроля сетевого доступа NAC;
обеспечивать динамическую сеансовую корреляцию, включая:
обнаружение аномалий, включая информацию NetFlow;
корреляцию событий на основе поведения и правил;
общие встроенные и определенные пользователем правила;
автоматическую нормализацию транслированных сетевых адресов;
МОСКВА 2008
199
строить топологическую схему сети, включая:
маршрутизаторы, коммутаторы и межсетевые экраны уровня 2 и 3;
модули и устройства сетевой системы обнаружения вторжений;
ручное или по графику построение;
SSH, SNMP, Telnet и зависящие от конкретного устройства взаимодействия с устройствами;
анализировать уязвимости, в том числе:
снятие следов нарушений на основе сети или конечного узла;
анализ конфигурации коммутаторов, маршрутизаторов, межсетевых экранов и NAT;
автоматическая обработка данных сканирования уязвимостей;
автоматический и пользовательский анализ ложных срабатываний;
обеспечивать анализ нарушений и ответную реакцию:
иметь инструментальную панель управления отдельными событиями безопасности;
объединять данные сеансовых событий с контекстом всех правил;
обеспечивать графическое представление пути атаки с подробным анализом;
формировать профили устройств на пути атаки с определением MAC-адресов конечных узлов;
обеспечивать графическое и подробное последовательное представление типа атаки;
предоставлять подробные данные нарушения, включая правила, необработанные события, общие
уязвимости и способы воздействия на сеть, а также варианты отражения;
осуществлять мгновенный анализ нарушений и определение ложных срабатываний;
определять правила с помощью графического интерфейса пользователя для поддержки собственных правил и анализа по ключевым словам;
оценивать нарушения с выдачей по пользователям рабочего листа с описанием пошаговых действий;
оповещать, включая электронную почту, пейджер, системный журнал и SNMP;
формировать запросы и отчеты:
поддерживать графический интерфейс пользователя, поддерживающий большое число стандартных и настраиваемых запросов;
генерировать отчеты с наглядным интерфейсом, позволять создавать неограниченное число пользовательских отчетов;
поддерживать текстовый, графический и общий формат отчетов, поддерживающий экспорт в
файлы HTML;
создавать готовые к печати, групповые, типовые и прочие отчеты;
обеспечивать централизованное создание отчетов для параметров NAC фазы 2;
администрирование:
поддерживать web-интерфейс HTTPS;
поддерживать ролевое администрирование с заданными полномочиями;
поддерживать иерархическое управление несколькими системами;
поддерживать автоматические обновления, включая поддержку устройств, новых правил и функций.
3.4. Требования к оборудованию сетей хранения
Оборудование сетей хранения должно обеспечивать следующие возможности:
должна поддерживаться интегрированная в коммутатор хранения возможность разбиения сети на независимые логические фабрики, с гранулярностью до уровня портов, допускающие независимое управление (до уровня отдельных команд) и мониторинг различными группами администраторов и
операторов, при сохранении консолидации сетевого оборудования на физическом уровне;
должна поддерживаться интегрированная в коммутатор хранения возможность доступа к разделен-
200
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
ным ресурсам хранения (ленточные библиотеки, ограниченные среды на площадках катастрофоустойчивости и пр.) из любых логических фабрик сети хранения без необходимости слияния этих фабрик и распространения в них нежелательных событий из других фабрик;
должна поддерживаться интегрированная в коммутатор хранения возможность организации межкоммутаторных связей (InterSwitchLinks) в единый межкоммутаторный канал для обеспечения балансировки нагрузки и бесперебойной работы в случае отказа одной из межкоммутаторных связей с
возможностью использования такого общего канала всеми логическими фабриками, вне зависимости
от количества фабрик и межкоммутаторных связей. Все межкоммутаторные связи в таком канале
должны быть равноправными для обеспечения бесперебойности работы в случае отказа любой из них;
должна поддерживаться интегрированная в коммутатор хранения функциональность, позволяющая
проводить как индивидуальную настройку параметров качества обслуживания для различных приложений, которым требуется первоочередной и надёжный доступ к данным (Quality of Service), так и возможность управления трафиком с использованием возможностей протокола FiberChannel
(FabricShortesePathFirst) для более гибкого обеспечения отказоустойчивости;
должна обеспечиваться возможность гибкого и безопасного разграничения доступа к портам, фабрикам, WWN-именам и логическим томам на уровне ролей;
должна поддерживаться интегрированная в коммутатор хранения возможность управления сетевыми
устройствами хранения как при помощи GUI-интерфейса, так и командной строки (CommandLineInterface), с возможностью получения информации/управления функциональностью по каждому отдельному устройству/узлу в сети хранения из любого интерфейса управления по мере необходимости;
должен обеспечиваться безопасный внешний доступ к коммутатору хранения как GUI, так и CLI, обеспеченный различными методами аутентификации и шифрования в канале управления (SSH, AAA RADIUS/TACACS+, SFTP и других.);
должна обеспечиваться интегрированная в коммутатор хранения возможность обеспечения безопасности данных за счет их шифрования в канале передачи - при расширении сети хранения за счет протокола FCIP стандартными средствами (IPSec);
должна поддерживаться интегрированная в коммутатор хранения возможность расширения сети хранения за счет протоколов FICON, iSCSI, FCIP для обеспечения гибких и минимальных по затратам возможностей подключения;
должна обеспечиваться возможность сертифицированной поддержки расширения сети хранения за
счет протоколов SDH и применения технологий спектрального разделения потоков данных CWDM и
DWDM, предпочтительно, единым поставщиком;
должна обеспечиваться возможность трассировки прохождения пакетов данных по сети хранения, проверки FC соединения при помощи FC Ping, возможность зеркалирования потока с целью диагностики
функционирования порта или передачи данных для обработки третьим приложением без прерывания
потока данных и нарушения его целостности по основному каналу между серверами и системой хранения;
должна обеспечиваться интегрированная в коммутатор хранения возможность компрессии данных,
ускорения работы приложений за счет как перемещения функций некоторых устройств (медийный сервер) на уровень сети, так и проксирования операций записи с целью оптимизации работы приложений
по распределенной сети хранения.
3.5. Требования к оборудованию телеприсутствия
Оборудование телеприсутствия должно обеспечивать следующие возможности:
представлять собой конфигурацию, которая позволяет организовать в любом ограниченном пространстве место для полноценных персональных переговоров или совещаний малых рабочих групп;
МОСКВА 2008
201
обеспечивать, наряду с передачей полноразмерного видеоизображения каждого участника совещания
с ультравысоким разрешением (720p на 1080p), передачу объемного звука с качеством, аналогичным
качеству CD;
обеспечивать интеграцию с корпоративными системами планирования совещаний (продукты семейства MS Exchange, Microsoft Office SharePoint Server) и системами унифицированных коммуникаций;
обеспечивать функциональность начала сеанса по нажатию одной кнопки;
обеспечивать возможность совместного использования графической информации для участников сеанса телеприсутствия;
обеспечивать полное видимое соответствие натуральному размеру собеседника;
обеспечивать студийное качество видеосигнала, освещения и акустики;
неизменное качество видео- и аудио- информации вне зависимости от местоположения комплекса телеприсутствия;
система должна представлять собой законченное решение, содержащее в своем составе камеры, кодеки, микрофоны, громкоговорители, осветительное оборудование, а также идентичные комплекты
мебели для создания полной имитации присутствия.
3.6. Требования к протоколам сетевого оборудования
Рекомендуется закупать сетевое оборудование, которое поддерживает следующие протоколы:
Основные протоколы
IP (RFC 791)
ICMP (RFC 792,1256)
TCP (RFC 793)
UDP (RFC 768)
TELNET (RFC 854)
BootP (RFC 951, 1542)
Telnet Client/Server
FTP и/или TFTP
Протоколы управления, мониторинга и сбора статистики
SNMP v1/v2/v3
DHCP Client/Server/Relay
Syslog
NTP Client
RMON 1(4 groups)
Policy MIB
Протоколы безопасности
DoS Prevention
ACLs
AAA
RADIUS (RFC 2138)
SSHv2
Secure Copy v2
802.1x Client
3.7. Требования к коммутаторам
Рекомендуется закупать коммутаторы, которые поддерживают следующие протоколы:
802.1s Multiple Spanning Tree
802.1p Priorities
802.1q VLAN Tagging
802.3ad Link Aggregation
802.3ae 10 GbE
802.1w Rapid STP
IGMP v3 (RFC 2236)
IGMP Snooping
ECMP (8 Paths)
Diff Serv
Все коммутаторы должны иметь GBIC порты/слоты для стекирования.
202
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
3.8. Требования к системе видеоконференцсвязи
поддерживать работу в сетях как IP (H.323), так и ISDN (H.320);
поддерживаемые протоколы: H.323 v4, H.239, VNC, Telnet, RTP, HTTP, DHCP, SIP;
обеспечивать соединение точка-точка на скорости не менее 768 Кбит/сек по IP и не менее 384 Кбит/с по ISDN;
поддерживать режим передачи двух видео потоков в одном канале связи одновременно для передачи
и получения как изображения докладчика, так и дополнительного изображения (компьютер, документальная камера, вспомогательная камера);
поддерживать протоколы кодирования видео потока H.261, H.263, H.263+, H.263++, H.264 с разрешениями 4CIF (704x576), CIF (352x288), QC1F (176x144), чересстрочный CIF (352x576) и частотой обновления до 25 кадров/сек;
поддерживать протоколы кодирования аудио потока G.711, G.729;
интерфейс H.323: RJ45 Ethernet, 10/100/1000 Мбит/с full/half duplex
обеспечивать подключение ПК и других источников сигнала (документкамера, видеокамера и т.д.).
Приложение 4
к Технической политике ИТ
Требования к помещениям и инженерным системам центров обработки
данных
4.1. Требования к помещениям
Серверные помещения всех ЦОД должны удовлетворять следующим общим требованиям:
запрещается размещать серверные помещения в подвалах и иных помещениях, оснащенных большим количеством инженерного оборудования, которое представляет потенциальную опасность для вычислительной техники;
серверная комната должна представлять собой помещение с ограниченным доступом, предназначенное для размещения серверного оборудования;
конструкция серверной комнаты должна соответствовать следующим требованиям:
поддерживать требуемую непрерывность рабочих процессов;
защищать ценное оборудование и данные;
физический доступ к серверной комнате должны иметь только уполномоченные сотрудники ИТподразделений и обслуживающих организаций;
для ограничения физического доступа к серверной комнате целесообразно использовать автоматизированные системы контроля доступа;
в зависимости от уровня ЦОД серверная комната должна быть оснащена:
источником бесперебойного питания;
системой кондиционирования;
системой регулирования чистоты и влажности воздуха;
серверными и телекоммуникационными шкафами, стойками;
системами контроля состояния внутренней среды:
системой раннего дымообнаружения;
датчиками доступа;
датчиками физического состояния оборудования;
датчиками температуры/влажности;
системой видеонаблюдения;
в серверной комнате рекомендуется иметь фальшпол. Фальшпол является необходимым компонентом,
так как под него нагнетается охлажденный воздух, под ним располагаются кабели электроснабжения
МОСКВА 2008
203
и слаботочная инфраструктура. Рекомендуется фальшпол из МДФ–плиток на металлической основе с
ламинированным покрытием, размером 600 х 600 мм. Высота над уровнем пола – от 100 до 800 мм, для
серверных помещений наиболее оптимально 350 – 500 мм;
рекомендуется при расчете площади помещений исходить из расчета 2 кв. м на один 19-дюймовый
шкаф, если иного не предусмотрено техническим проектом или рабочей документацией.
При проектировании серверных помещений и узлов связи необходимо руководствоваться следующими
документами:
РД 45.120–2000. Нормы технологического проектирования. Городские и сельские телефонные сети;
ВСН 332–93. Инструкция по проектированию электроустановок предприятий и сооружений электросвязи, проводного вещания, радиовещания и телевидения;
ПОТ РО–45–005–95. Правила по охране труда при работах на кабельных линиях связи и проводного вещания (радиофикации);
ПОТ РО–45–007–96. Правила техники безопасности при работах на телефонных станциях и телеграфах;
ВСН 45.122–77. Инструкция по проектированию искусственного освещения предприятий связи;
ВСН 116–93. Инструкция по проектированию линейно–кабельных сооружений связи;
ГОСТ 464–79. Заземление для стационарных установок проводной связи, радиорелейных станций, радиотрансляционных узлов и антенн систем коллективного приема телевидения. Нормы сопротивления;
СНиП 21–01–97. Противопожарная безопасность зданий и сооружений;
СНиП 2.09.02–85. Производственные здания.
4.2. Требования к структурированным кабельным системам
Структурированные кабельные системы (СКС) для ЦОД всех уровней, к которым относятся вертикальная
и горизонтальная разводка кабелей, шкафы и кроссовое оборудование, должны удовлетворять следующим общим требованиям:
СКС должна включать в себя горизонтальную и вертикальную разводку. Горизонтальная разводка –
кабель 5 категории, вертикальная разводка должна быть оптической и должна позволять состыковывать коммутаторы доступа с коммутаторами уровня распределения (а также, соответственно, коммутаторы уровня распределения с коммутаторами уровня ядра) по GigabitEthernet или 10G Ethernet;
на СКС должна предоставляться гарантия производителя на работоспособность на срок не менее 15 лет.
Подрядчик должен быть сертифицирован производителем и иметь поверенное измерительное оборудование. При проведении приемочных испытаний подрядчик должен предоставить протоколы тестирования СКС на соответствие установленным нормам;
рекомендуется, чтобы каждый шкаф имел высоту не менее 42U (стандартный телекоммуникационный
шкаф), а также имел производительную систему вентиляции. При сверхплотном размещении большого количества шкафов с оборудованием, например, в ЦОД I уровня, необходимо отдельно просчитывать вопросы, связанные с вентиляцией. В частности, рекомендуется рассмотреть возможность
организации холодных и горячих коридоров.
4.3. Требования к электроснабжению
Общие требования к системе электроснабжения ЦОД всех уровней следующие:
в серверное помещение электропитание должно подаваться от главного щита здания, где бы данное помещение ни находилось. Также от главного щита здания проводится кабель заземления. Все провода должны
иметь соответствующее сечение согласно техническому проекту и цвет согласно нормативным документам;
питание ПК, периферийных устройств, офисной техники, серверов, систем хранения и активного сетевого оборудования должно быть отделено от питания промышленных установок. Питание должно осуществляться от отдельных поэтажных автоматов, а те, в свою очередь, отдельно должны
подсоединяться к главному щиту здания через отдельную систему автоматов;
204
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
при организации питания ПК, периферийных устройств и офисной техники рекомендуется после автоматов в поэтажных щитах устанавливать устройства защитного отключения (УЗО) согласно действующим нормам;
систему электроснабжения для ЦОД I уровня следует организовывать от двух территориально разнесенных трансформаторных подстанций. Кабельные линии должны идти независимыми маршрутами.
Требуется использовать автоматы выбора резерва (АВР), осуществляющие выбор и переключение
между основными и резервными линиями;
для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется использовать дизель–генераторные электростанции (ДЭС). В схеме электроснабжения они должны располагаться после вводов кабелей электропитания в здание. В случае полного пропадания электропитания, либо несоответствия его требуемым
параметрам (напряжение, частота, «чистота») должен осуществляться автоматический запуск ДЭС с переводом нагрузки на нее. ДЭС должны иметь запас топлива, рассчитанный не менее чем на 8 часов непрерывной работы, и возможность пополнения топливом без остановки генератора. ДЭС должны иметь
возможность непрерывной работы до 3 месяцев при условии налаженной поставки топлива;
для ЦОД I и II уровней должны быть установлены после в вода кабелей электропитания в здание или после
ДЭС, при ее наличии, централизованные источники бесперебойного питания (ИБП) типа on–line. Это обязательное требование, так как наиболее опасными являются короткие скачки напряжения, длительностью
2 – 3 секунды. Кроме этого, существуют и такие негативные факторы, наносящие существенный ущерб, как
превышение напряжения, изменение частоты, гармоники, нарушение заземления, межфазовый потенциал
и т.п. Допускается не устанавливать к ИБП аккумуляторных батарей, если это экономически нецелесообразно и предусмотрены другие ИБП (персональные или групповые) с аккумуляторными батареями, которые обеспечат требуемое время удержания работоспособности системы.
ЦОД должен быть оснащен источниками бесперебойного электропитания, к которым предъявляются следующий требования:
номинальная мощность – не менее 3000 ВA;
технология – двойное преобразование On–Line;
коэффициент полезного действия (при электроснабжении поддерживаемых устройств от внешней
сети) – 90% и использование активного корректора коэффициента мощности;
выходное напряжение:
форма – синусоида;
номинальное значение – 220 В;
время работы от батарей:
нагрузка 3000 ВA – не менее 5 минут;
тестирование батареи:
при включении;
ручное;
автоматическое периодическое;
аппаратная защита батареи от глубокого разряда;
возможность подключения дополнительной батареи;
высокочастотный Инвертор и Корректор Мощности;
диапазон входных напряжений 120 В...300 В;
многофункциональный ЖК–дисплей;
возможность сегментирования нагрузок и раздельное управление сегментами;
функция аварийного отключения (EPO);
возможность оснащения: внешние батарейные отсеки;
звуковая индикация режима работы от батарей с возможностью отключения;
возможность оснащения: один порт RJ–45 для подключения к ЛВС Ethernet для мониторинга и управления источником бесперебойного питания по протоколу SNMP.
МОСКВА 2008
205
4.4. Требования к системам кондиционирования и холодоснабжения
Требования к системам кондиционирования и холодоснабжения для ЦОД всех уровней:
серверные помещения должны быть оборудованы промышленной системой кондиционирования и вентиляции (системы холодоснабжения) согласно СНиП 2.04.05–91;
система холодоснабжения должна обеспечивать поддержание внутри помещения рабочей температуры в пределах от 19 до 24°С и влажности – от 40 до 80%;
резервирование системы холодоснабжения ЦОД I уровня обязательно, а для ЦОД II уровня рекомендуется осуществлять по схеме с N+1 (с одним запасным кондиционером). Все кондиционеры должны
быть подключены к единой системе управления. Программное обеспечение должно позволять осуществлять ротацию запасного кондиционера, что позволяет более эффективно расходовать ресурс системы холодоснабжения в целом;
для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется организовывать приток свежего воздуха с улицы, так как воздух, постоянно циркулирующий через компьютерные шкафы и кондиционеры,
"выгорает" и требует обновления. Приток рекомендуется осуществлять через специальную установку,
нагревающую и осушающую уличный воздух. Кроме того, она должна создавать внутри помещения
дополнительное давление, что препятствует проникновению внутрь пыли;
для увлажнения воздуха в ЦОД I и II уровней рекомендуется использовать парогенераторы. Сухой воздух малоэффективен для охлаждения системой хладоснабжения в силу физических принципов кондиционирования. При понижении влажности электростатический потенциал увеличивается, что может
быть причиной вывода оборудования из строя.
4.5. Требования к системам раннего обнаружения пожара и газового пожаротушения
Требования к системе раннего обнаружения пожара и газового пожаротушения для ЦОД всех уровней:
ЦОД должны быть оборудованы системой автоматического пожаротушения (ГОСТ 12.1.004–91.ССБТ).
Система пожаротушения не должна наносить вред оборудованию;
система газового пожаротушения должна сработать в зачаточной фазе развития пожара, то есть когда
происходит тление нагревающихся элементов или начальное воспламенение, и за время менее одной
минуты потушить очаги возгорания;
комплекс предупреждения о пожаре и пожаротушения должен сообщить о потенциальной возможности возгорания намного раньше, чем придется задействовать систему тушения. Это должно быть достигнуто установкой большого количества высокочувствительных дымовых, оптических, химических,
спектральных и прочих пожарных извещателей, увязанных в единую интеллектуальную систему оповещения о пожаре и пожаротушения, а также комплексом организационных мероприятий. В него должен входить постоянный визуальный осмотр оборудования, соблюдение пожарных норм и правил, а
также правил эксплуатации электроустановок;
рекомендуется использовать огнетушащие смеси на основе хладонов либо инертных газов, так как они
наносят наименьший ущерб оборудованию;
требуется предусмотреть систему удаления газа из помещения после срабатывания системы пожаротушения.
4.6. Требования к комплексным системам безопасности
Комплексные системы безопасности ЦОД должны состоять из:
системы видеонаблюдения;
системы разграничения физического доступа.
206
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»
Требования к системе видеонаблюдения:
система видеонаблюдения должна собирать и передавать видеоинформацию в режиме реального времени;
система видеонаблюдения должна записывать и воспроизводить цветное изображение;
должен храниться как минимум недельный архив информации системы доступа в помещения для расследования возможных инцидентов.
Требования к системе разграничения физического доступа:
должна быть использована система разграничения доступа на основе proximity–карт, которая состоит
из сервера управления, системы контроллеров и считывателей, а также индивидуальных карт (ключей);
данные системы (архив информации) должны храниться минимум три месяца.
Приложение 5
к Технической политике ИТ
Каталог рекомендованных конфигураций (КРК)
№
п/п
Наименование
Программно-техническая
платформа
Прикладная
платформа
Область применения
1.
Планирование и бюджетирование
RISC – AIX
SAP
2.
Планирование и бюджетирование
Intel – Windows
1С
ЦОД уровня 3
3.
Управленческий документооборот
RISC – AIX
Documentum
ЦОД уровня 1
4.
Управление персоналом
RISC – AIX
SAP
ЦОД уровня 1, 2
5.
Управление персоналом
Intel – Windows
1С
ЦОД уровня 3
6.
Расчет зарплаты
RISC – AIX
SAP
ЦОД уровня 1, 2
7.
Расчет зарплаты
Intel – Windows
1С
ЦОД уровня 3
8.
Мотивация персонала на основе КПЭ
RISC – AIX
SAP
ЦОД уровня 1, 2
9.
Управление на основе КПЭ
RISC – AIX
SAP
ЦОД уровня 1, 2
10.
Управление ТОиР
RISC – AIX
SAP
ЦОД уровня 1, 2
11.
Бухгалтерский, налоговый учет и отчетность
RISC – AIX
SAP
ЦОД уровня 1, 2
12.
Бухгалтерский, налоговый учет и отчетность
Intel – Windows
1С
ЦОД уровня 3
13.
Управление имуществом
RISC – AIX
SAP
ЦОД уровня 1, 2
14.
Управление закупочной деятельностью
RISC – AIX
SAP
ЦОД уровня 1, 2
15.
Управление активами
RISC – AIX
SAP
ЦОД уровня 1, 2
16.
Корпоративный портал
RISC – AIX
SAP
ЦОД уровня 1, 2
17.
Информационно-аналитическая система
учета и расчета за электроэнергию
RISC – AIX
SAP
ЦОД уровня 1, 2
18.
Офисные ИТ-ресурсы
Intel – Windows
Microsoft
Все организации
19.
Рабочие места пользователей
Intel – Windows (от 2000/ХР)
Microsoft Office 2000/XP
Все организации
20.
Мобильные устройства
Windows XP и Windows
Mobile
Все организации
21.
Архив электронных документов
RISC – AIX
ЦОД уровня 1, 2
22.
Управление и мониторинг серверов
HP OpenView
ЦОД
23.
Управление и мониторинг ПК
Microsoft System Center
Все организации
24.
Интеграция приложений
WebSphere IBM, SAP XI
ЦОД
25.
Средства виртуализации
Intel – VMware
Офисные ИТ-ресурсы,
ЦОД уровня 3
МОСКВА 2008
ЦОД уровня 1, 2
207
ДЛЯ ЗАМЕТОК
208
ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ ОАО «МОСКОВСКАЯ ОБЪЕДИНЕННАЯ ЭЛЕКТРОСЕТЕВАЯ КОМПАНИЯ»