(утратил силу с 29.05.2023 — приказ Министерства связи ДНР от 03.05.2023 № 83)

В целях оптимизации расходов на создание и развитие информационных систем, в соответствии со статьями 3, 14 Закона Донецкой Народной Республики от 07.08.2015 № 71-IHC «Об информации и информационных технологиях», пунктами 15.2.1., 16.8., 16.9. Временного Положения о Министерстве связи, утвержденного Постановлением Совета Министров Донецкой Народной Республики от 10.01.2015 №1-17

П Р И К А З Ы В А Ю:

1. Утвердить правила применения единых требований к элементам государственных информационных систем (прилагаются).

2. Предприятиям и организациям государственной формы собственности применять требования, указанные в пункте 1 настоящего Приказа, при создании информационных систем.

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

4. Контроль за исполнением настоящего Приказа оставляю за собой.

5. Настоящий Приказ вступает в силу с момента его официального опубликования.

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

Раздел I. Общие положения

1. Цели и задачи правил применения единых требований к элементам государственных информационных систем

1.1. Правила применения единых требований к элементам государственных информационных систем (далее – Правила) разработаны Министерством связи Донецкой Народной Республики и являются документом по обеспечению функционирования информационно-коммуникационной инфраструктуры (далее — ИТ — инфраструктура) Донецкой Народной Республики.

1.2. Соблюдение настоящих Правил является обязательным для государственных учреждений и предприятий Донецкой Народной Республики.

1.3. Целью настоящих Правил является определение основных направлений и условий для оптимального развития ИТ — инфраструктуры в целях повышения эффективности и качества государственного управления в Донецкой Народной Республики.

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

1.5. ИТ — инфраструктура должна соответствовать следующим основным характеристикам:

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

2) предоставления необходимой ИТ — инфраструктуры для решения текущих и перспективных задач государственного управления;

3) унификации и типизации элементов ИТ — инфраструктуры для снижения общей стоимости владения;

4) структуризации ИТ — инфраструктуры на центры обработки данных различного уровня для повышения надёжности, отказоустойчивости и безопасности используемых решений;

5) соответствия международным и государственным стандартам в области информационных и коммуникационных технологий, а также лучшим мировым практикам при построении ИТ–инфраструктуры.

1.6. Для целей настоящих Правил в них используется следующие сокращения:

1) AS — группа IP сетей, управляемых одним или несколькими операторами, имеющими единую политику маршрутизации

2) COBIT — результат обобщения мирового опыта, международных и национальных стандартов и руководств в области управления ИТ, аудита и информационной безопасности;

3) DNS — система доменных имён;

4) DHCP — протокол динамической настройки узла

5) DRS и DRP — технология логического деления вычислительных комплексов в сочетании с планами восстановления после сбоев и восстановления после катастроф;

6) D2D — технология резервного копирования disk-to-disk, когда резервное копирование выполняется с диска хост системы на диск системы резервного копирования. Служит для сокращения времени, необходимого для резервного копирования;

7) D2D2T — схема резервного копирования disk-to-disk-to-tape, последние по времени резервные копии хранятся на жёстких дисках, а затем по мере устаревания переносятся на ленточные картриджи;

8) ERP — автоматизированная система управления предприятием;

9) IDS/IPS — системы обнаружения и предотвращения вторжений и хакерских атак Сегодня системы обнаружения и предотвращения вторжений;

10) IMS — спецификация передачи мультимедийного содержимого в электросвязи на основе протокола IP;

11) ILM — управление жизненным циклом информации;

12) ITIL — свод правил и рекомендаций, описывающий лучшие из применяемых на практике способов (best practice) организации работы ИТ подразделений или ИТ компаний;

13) IP — маршрутизируемый протокол сетевого уровня;

14) MPLS — Multiprotocol Label Switching. Новый стандарт передачи данных в мультисервисных коммуникационных сетям;

15) MTBF — среднее время безотказной работы;

16) NAS — сетевая система хранения данных, сетевое хранилище;

17) NGN- сеть следующего поколения;

18) OSI — Open Systems Interconnection, модель взаимодействия открытых систем;

19) OSPF — один из динамических протоколов маршрутизации;

20) PMI и IPMA — институт управления проектами (PMI) и Международная ассоциации по управлению проектами (IPMA);

21) QoS — качество сетевых услуг;

22) RTO — целевое времени восстановления, т.е. время, необходимое на восстановление данных;

23) SAN — сеть хранения данных;

24) SaaS — программное обеспечение как услуга;

25) SLA — соглашение об уровне сервиса;

26) SNMP — протокол управления сетевыми устройствами;

27) SOA — сервис-ориентированная архитектура;

28) Softswitch — программный коммутатор для сетей следующего поколения;

29) VLAN — виртуальная локальная сеть;

30) xWDM — серия технологий передачи данных по оптическим каналам с уплотнением по длине волны;

31) АВР — автомат ввода резерва;

32) ДЭС — дизель-генераторные электростанции;

33) ДМЗ — демилитаризованная зона;

34) ЗИП — запасные части, инструменты и принадлежности;

35) МСЭ (firewall) — межсетевой экран;

36) МФУ — многофункциональное периферийное устройство;

37) ОС — операционная система;

38) ПК — персональный компьютер;

39) ПО — программное обеспечение;

40) СКС — структурированная кабельная система;

41) СПД — сети передачи данных;

42) СУМ — система управления и мониторинга;

43) СЭД — система электронного документооборота;

44) СХД — система хранения данных;

45) ТСО — общая стоимость владения;

46) УЗО — устройства защитного отключения;

47) ЦОД — центр обработки данных.

1.7. Настоящие Правила в сфере ИТ развивают положения вышеуказанных нормативных документов следующим направлениям:

1) требования по управлению ИТ инфраструктурой;

2) требования к типизации и унификации ИТ-инфраструктуры;

3) требования к поставщикам ИТ продукции и услуг;

4) требования к элементам ИТ-инфраструктуры и их размещению.

2. Адаптация и развитие Правил в сфере ИТ

2.1. В качестве инструмента контроля за внедрением настоящих Правил используется каталог рекомендованных конфигураций, утверждаемый ежегодно приказом Министерства связи Донецкой Народной Республики (далее — КРК).

2.2. Органы государственной власти, государственное учреждения и предприятия Донецкой Народной Республики могут подавать аргументированные предложения в Министерство связи Донецкой Народной Республики в КРК на будущий период.

3. Общие положения построения и управления ИТ-инфраструктурой

3.1. Подход к построению и управлению ИТ-инфраструктурой должен основываться на понятиях «ИТ-сервис» (информационная система) и «ИТ-ресурсы». С точки зрения данного подхода, основные задачи, стоящие перед ИТ-подразделениями государственных учреждений и предприятий Донецкой Народной Республики предполагают:

1) построение ИТ-инфраструктуры, ориентируясь на требования структурных подразделений;

2) сохранение и повышение качества предоставляемых ИТ-сервисов;

3) обеспечение безопасности функционирования ИТ-сервисов;

4) обеспечение непрерывности функционирования ИТ-сервисов;

5) сокращение общей стоимости владения ИТ.

3.2. При построении ИТ-инфраструктуры необходимо использовать следующие подходы и технологии:

1) консолидацию ресурсов;

2) виртуализацию ресурсов;

3) современную архитектуру приложений;

4) модель SaaS;

5) средства интеграции приложений;

6) современную коммуникационную инфраструктуру.

4. Консолидация ресурсов

4.1. При построении и управлении ИТ-инфраструктурой государственным учреждениям и предприятиям Донецкой Народной Республики необходимо максимально консолидировать приложения и данные в ЦОД. С точки зрения эффективного управления данная модель построения ИТ-инфраструктуры обеспечит более высокую:

1) эффективность за счёт снижения ТСО (прежде всего затрат на обслуживание и сопровождение ИТ систем и снижения капитальных затрат на обеспечивающую инфраструктуру);

2) непрерывность (доступность) приложений за счёт более высокой степени резервирования и отказоустойчивости программно-аппаратных средств, применяемых в централизованных ЦОД.

4.2. При построении и модернизации ИТ-инфраструктуры необходимо рассматривать четыре вида консолидации ресурсов:

1) централизация — консолидация географически распределённых серверов в одном или нескольких централизованных дата центрах;

2) консолидация данных — консолидация баз данных и/или устройств хранения для достижения более высокой доступности и управляемости данными;

3) физическая консолидация — объединение серверов под управлением одной и той же операционной системой и с подобными приложениями, на более мощных системах;

4) консолидация приложений и хранилищ данных — размещение различных приложений на мощных серверах с разделяемыми разделами, либо на системах виртуализации.

5. Виртуализация ресурсов

5.1. При построении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо использовать технологии и средства виртуализации ИТ-ресурсов следующих типов:

1) программная виртуализация: виртуализация на уровне операционной системы, позволяющая множеству виртуализированных сред выполняться на одном экземпляре операционной системы;

2) аппаратная виртуализация: виртуализация аппаратных ресурсов, позволяющая выполняться операционным системам, выполняться в окружениях, скрывающих от них физические характеристики платформы-носителя.

5.2. Обязательные области применения виртуализации ресурсов:

1) виртуализация на уровне операционной системы: виртуализирует физический сервер на уровне ОС, позволяя запускать изолированные и безопасные виртуальные серверы на одном физическом сервере;

2) виртуальные машины: окружение, которое представляется для «гостевой» операционной системы, как аппаратное;

3) виртуализация ресурсов: разделение одного физического сервера на несколько частей, каждая из которых видна для владельца в качестве отдельного сервера;

4) виртуализация приложений: процесс использования приложения преобразованного из требующего установки в ОС в не требующий этого.

5.3. Понятие «виртуальные машины» предполагает разделение на:

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

2) виртуализацию рабочих станций: использование на рабочем месте «тонких» клиентов, позволяющих выполнять все необходимые пользователю задачи на сервере в отдельной для каждого клиента виртуализированной операционной системе.

6. Логическое деление вычислительных комплексов

6.1. При построении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо применять технологию аппаратных и программных разделов (partitioning), позволяющую виртуализировать аппаратные ресурсы и сделать их доступными для множества независимых операционных сред.

6.2. Технология логического деления вычислительных комплексов в сочетании с планами восстановления после сбоев и восстановления после катастроф (DRS и DRP) и с использованием двух разнесённых ЦОД (основного и резервного), создаёт основу катастрофоустойчивой инфраструктуры таким образом, что приложение и разделы с критическими  сервисами, выполняемые в основном ЦОД, могут переключаться на резервный ЦОД с минимальными потерями и прозрачно для пользователей приложений.

7. Сервис-ориентированная архитектура

7.1. При построении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо использовать ИТ-решения, имеющим сервис-ориентированную многоуровневую архитектуру.

7.2. Наиболее перспективная архитектура построения приложений является SOA, применение которой упростит интеграцию приложений, как новых программных решений, так и систем предыдущих поколений.

7.3. Архитектура SOA независима от языков программирования, платформ или протокольных спецификаций, с помощью которых сервисы разрабатываются, а также от того, где и с помощью чего они развёрнуты. Практически архитектура SOA требует наличия не только сервисов, но и средств, с помощью которых эти сервисы могут быть обнаружены и подключены, а также множества компонентов, таких, как: серверы приложений, связующее ПО, стандарты описания сервисов, репозиторий и даже специализированные пакеты централизованного управления SOA.

8. Многоуровневая архитектура клиент-сервер

8.1. При построении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо проектировать с использованием трёхуровневой архитектуры «клиент-сервер», представляющей информационную систему в виде совокупности трёх компонент: сервера баз данных, сервера приложений, отвечающего за выполнение логики приложения, и клиентского приложения или клиентского интерфейса («тонкий клиент»).

8.2. Необходимые составляющие трёхуровневой архитектуры:

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

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

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

8.3. При построении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо использовать SaaS — модель использования программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя пользователям доступ к программному обеспечению через сеть.

9. Средства интеграции приложений

9.1. Для построения интегрированной ИТ инфраструктуры, особенно при использовании различных программно-аппаратных сред, государственным учреждениям и предприятиям Донецкой Народной Республики необходимо использовать специализированные программные средства — интеграционные платформы, обеспечивающим доступ в реальном масштабе времени к различным информационным ресурсам, обмен и синхронизацию данных между ними, автоматически, по заданным правилам и расписанию — поддержку единого стандарта обмена информацией между приложениями, независимо от платформ, на которых они существуют.

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

9.3. Продукты такого типа, как правило, строятся на принципах сервис — ориентированной архитектуры и предназначены для решения задач обеспечения достоверности информации в масштабе организации, контроля качества данных, их преобразования, перемещения и объединения, а также управления метаданными.

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

10. Современная коммуникационная инфраструктура

10.1. Для построения сетей передачи данных государственным учреждениям и предприятиям Донецкой Народной Республики необходимо применять технологии построения виртуальной частной сети на базе MPLS/VPN, с использованием услуг, предоставляемых государственными операторами телекоммуникационных услуг. При необходимости, резервирование каналов осуществляется телекоммуникационными операторами, в том числе, с использованием спутниковой связи.

10.2. Построение внутренней сетевой инфраструктуры необходимо производить на базе современных принципов построения сети, обеспечивающих гарантированное QoS.

10.3. Архитектура таких сетей должна состоять из четырёх основных компонентов, а именно:

1) интеллектуальная сетевая инфраструктура на базе протокола IР;

2) интеллектуальные клиентские места с поддержкой протокола IР;

3) служебные серверные приложения;

4) современные пользовательские приложения.

10.4. Основа архитектуры — её распределённая природа, благодаря которой система легко масштабируется. За счёт этого, сетью на базе данной архитектуры можно охватить одно здание или несколько стоящих рядом зданий, объединённых высокоскоростной локальной сетью, предоставить в сети сервисы телефонии, видео-данных для пользователей удалённых офисов и подразделений, объединённых IР сетью.

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

Раздел II. Требования по управлению ИТ — инфраструктурой

11. Оценка необходимости изменений в ИТ — инфраструктуре

11.1. При организации деятельности ИТ-службы государственным учреждениям и предприятиям Донецкой Народной Республики необходимо использовать сервисный подход. Согласно сервисному подходу деятельность ИТ-службы – это оказание качественных и надёжных услуг, удовлетворяющих требованиям других структурных подразделений государственных учреждений и предприятий Донецкой Народной Республики.

11.2. С помощью сервисного подхода осуществляется:

1) организация ИТ в соответствии с требованиями процессов управления;

2) использование описаний ИТ-услуг (сервисов) на языке, понятном их пользователям;

3)  управление ИТ в терминах предоставляемых услуг (сервисов);

4) управление затратами на использование предоставляемых услуг (сервисов);

5) измеримость результатов инвестиций в ИТ и оптимизация совокупной стоимости владения (TCO) услугами (сервисами).

11.3. При решении задач управления ИТ-инфраструктурой имеют значение процессы, связанные с изменениями ИТ-инфраструктуры. Технические решения, связанные с изменениями ИТ-инфраструктуры, должны быть обоснованы, в том числе, с учётом оценки их влияния на стоимость и качество услуг, оказываемых ИТ-службой, и реализованы с учётом настоящих Правил при планировании ИТ-инфраструктуры.

12. Требования по проведению изменений в ИТ-инфраструктуре

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

12.2. При изменении ИТ-инфраструктуры государственным учреждениям и предприятиям Донецкой Народной Республики необходимо учитывать следующие требования:

1) общие требования к тестированию и приёмке изменений;

2) требования «разумного консерватизма» при внедрении новых версий ИТ-компонентов;

3) требования автоматизации тиражирования обновлений ПО;

4) обязательное документирование вносимых изменений.

13. Общие требования к тестированию и приёмке изменений

13.1. Решение о проведении изменений должны приниматься ИТ-службами государственных учреждений и предприятий Донецкой Народной Республики по согласованию с функциональными заказчиками. ИТ-службы государственных учреждений и предприятий Донецкой Народной Республики вправе разработать упрощённый порядок принятия решений о проведении некритичных для процессов управления изменений.

13.2. Перед вводом изменений в эксплуатацию необходимо разработать и протестировать план внесения изменений с обязательным указанием контрольных точек принятия решения об отказе от внесённых изменений и возврате системы в предыдущее состояние. Тестирование плана внесения изменений необходимо производить в среде, аналогичной производственной.

13.3. Тестирование и приёмку изменений необходимо производить в среде, аналогичной производственной.

13.4. Ввод изменений в эксплуатацию предваряется резервным копированием всех элементов системы, подвергшихся изменению.

14. Требования при внедрении, модернизации, обновлении ИТ-компонентов

14.1. Внедрение новых версий ПО должно иметь обоснованные преимущества перед используемыми версиями ПО и не должно ухудшать текущего состояния дел.

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

14.3. Недопустимо использование тестовых версий ИТ-компонентов (альфа, бета версии ПО и т.п.) в режиме промышленной эксплуатации.

14.4. При планировании внедрения новых версий ПО необходимо учитывать долгосрочные планы производителя по выпуску новых версий/релизов.

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

15. Требования к автоматизации тиражирования обновлений ПО

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

15.2. Создание и внедрение решения по автоматизации тиражирования обновлений ПО должно производиться в рамках отдельных проектов ИТ-службы и с использованием собственной серверной системы тиражирования обновлений. Обновление ПО непосредственно с Интернет — портала производителя не допускается.

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

15.4. Тиражирование обновлений в области безопасности критичных для предприятия систем (обновления операционных систем, ПО с непосредственным доступом во внешние сети или Интернет, антивирусные системы и т.п.) подлежит обязательной автоматизации.

15.5. Обновление инфраструктурного ПО (домен-контроллеры, DNS/DHCP/mail-сервера), включающего смену функциональности (помимо обновлений в области безопасности), повышение major-версии необходимо проводить под контролем соответствующего специалиста, предварительно проведя тестирование в тестовой среде, аналогичной производственной.

15.6. Необходима автоматизация тиражирования обновлений клиентской части приложений.

15.7. Перед масштабным тиражированием обновлений необходимо провести тестирование в локальной тестовой среде.

16. Требования по выбору горизонтов планирования для ИТ-приложений

16.1. При планировании ИТ-инфраструктуры государственных учреждений и предприятий Донецкой Народной Республики должен быть обеспечен экономически обоснованный уровень соответствия ресурсов ИТ-инфраструктуры текущим и будущим потребностям.

16.2. Для эффективного планирования ИТ-инфраструктуры государственных учреждений и предприятий Донецкой Народной Республики необходимо учитывать прогноз развития основной деятельности и технического развития ИТ. Поэтому важное значение имеет выбор горизонтов планирования для различных ИТ-приложений и определение базовой методики расчёта производительности и объёма хранимой информации для ИТ-систем.

16.3. Выбор горизонтов планирования ИТ-приложений должен определяться горизонтом планирования государственных учреждений и предприятий Донецкой Народной Республики. При этом горизонт планирования ИТ-инфраструктуры должен быть меньше, чем горизонт планирования ИТ-приложений.

16.4. Необходимо исходить из следующих горизонтов планирования ИТ-приложений:

1) 8-9 лет для приложений класса ERP и приложений управления ИТ, критичных для государственных учреждений и предприятий Донецкой Народной Республики;

2) 5-6 лет для приложений и систем операционного управления ИТ;

3) 3-5 лет для офисных и системных приложений.

16.5. При этом для соответствующих элементов ИТ инфраструктуры государственных учреждений и предприятий Донецкой Народной Республики необходимо установить следующие горизонты планирования:

1) 5-6 лет для приложений класса ERP и приложений управления ИТ, критичных для органов исполнительной власти и государственных учреждений Донецкой Народной Республики;

2) 3-4 года для приложений и систем операционного управления ИТ;

3) 2-3 года для офисных и системных приложений.

17. Требования по расчёту производительности и объёма хранимой информации для ИТ-систем (масштабирование ИТ- систем)

17.1. Расчёт производительности ИТ-систем должен производиться в терминах ИТ-услуг, исходя из планируемых сроков использования (горизонта планирования), объёмов, значений показателей уровня предоставления и производительности услуг.

17.2. При расчёте производительности подлежат учёту нагрузочные возможности всех задействованных в предоставлении ИТ-услуг компонентов: ИТ-услуг, ИТ-систем, компонентов инфраструктуры и систем информационной безопасности, включая клиентские рабочие станции.

17.3. При расчёте производительности ИТ-систем обязателен учёт как средних, так и пиковых показателей нагрузки.

17.4. В общем случае, в ходе расчёта необходимо проводить оценку загрузки по следующим компонентам:

1) сервер приложений;

2) сервер баз данных;

3) серверные средства информационной безопасности (антивирусное обеспечение, программный межсетевой экран, криптографические системы и т.п.);

4) компоненты мониторинга (агенты и т.п.);

5) системное ПО;

6) аппаратная платформа (процессоры, оперативная память, дисковая подсистема, сетевой интерфейс);

7) сети хранения данных (SAN, NAS);

8) сети передачи данных, включая активные устройства (межсетевые экраны, маршрутизаторы и т.п.);

9) сетевые сервисы (сервисы каталога, DNS, DHCPи т.п.);

10) клиентские рабочие станции в аппаратной и программной части.

17.5. Для оценки объёма хранимой информации необходимо использовать собственные статистические данные по объёмам и динамике изменения данных за длительные (от 1 месяца) периоды и максимальные значения в пиковые периоды. При отсутствии собственных данных допустимо использование статистики схожих ведомств и учреждений или экспертных оценок. При внедрении новых сервисов следует придерживаться информации, указываемой производителем, как в области начальных требований, так и в прогнозируемых объёмах увеличения информации. Последний показатель следует корректировать в ходе последующей эксплуатации систем.

17.6. При оценке объёма хранимой информации обязателен учёт не только полезного объёма, но и объёмов системной и служебной информации (системы шифрования, файлы логирования, файлы журналов транзакций и т.п.)

Раздел III.  Каталогизация и классификация элементов ИТ- инфраструктуры

18. Типизация элементов ИТ-инфраструктуры

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

18.2. Под типизацией понимается снижение номенклатуры и повышение качества ИТ-элементов и конфигураций, внедряемых в государственных учреждениях и предприятиях Донецкой Народной Республики.

18.3. Настоящие Правила выдвигают требования к следующим категориям ИТ-инфраструктуры:

1) рабочим местам пользователей (ПК, периферийное оборудование);

2) мультисервисной сети (корпоративная сеть, внешние каналы связи);

3) прикладному ПО;

4) инфраструктуре центров обработки данных (системы хранения и резервирования, серверы).

18.4. Общие требования к указанным категориям и их отдельным элементам приведены в разделе V настоящих Правил. При разработке технических политик и других нормативных документов в области ИТ необходимо учитывать указанные требования.

18.5. В КРК приведены минимально допустимые требования к соответствующим категориям, которые необходимо учитывать при развитии ИТ-инфраструктуры государственных учреждений и предприятий Донецкой Народной Республики.

19. Классификация по уровню использования

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

19.2. С точки зрения данной классификации необходимо выделить следующие классы или уровни инфраструктуры для размещения ИТ-систем:

1) ЦОД I уровня, (центральный уровень при Министерстве связи Донецкой Народной Республики) – обеспечивает централизованное хранение и обработку данных на центральном уровне Донецкой Народной Республики. Ресурсы данного ЦОД используются для консолидации информации с нижележащих уровней, обеспечения информационного взаимодействия в Донецкой Народной Республике и оказания ИТ-сервисов всем организациям, финансируемым из республиканского бюджета Донецкой Народной Республики.

2) ЦОД II уровня – основной центр хранения и обработки данных в рамках одного органа исполнительной власти Донецкой Народной Республики. Услугами данного ЦОД пользуется большинство сотрудников данного органа исполнительной власти и подчинённых ему государственных учреждений и предприятий.

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

20. Классификация по уровню требуемой непрерывности обслуживания и важности для органов государственной власти

20.1. Многие критические управленческие и технологические процессы опираются на компьютерные системы обработки и хранения данных и не могут функционировать без их использования. Поэтому, обеспечение непрерывности обслуживания и доступности ИТ-решений является важнейшим показателем непрерывности государственного управления в целом, и важным классифицирующим фактором для элементов ИТ-инфраструктуры. Исходя из предъявляемых требований к надёжности отдельных элементов и конфигураций ИТ-систем в целом и их восстановлению после сбоев и отказа оборудования, ПО или инфраструктурных элементов, современные ИТ-технологии предоставляют различные архитектурные и конфигурационные решения, обеспечивающие данные требования. С точки зрения обеспечения непрерывности обслуживания управленческих и технологических пользователей и процессов, а также требований к отказоустойчивости, можно предложить следующую классификацию ИТ-решений:

1) mission Critical- к таким системам относятся: остро критические с точки зрения государственного управления или внешних факторов – например, экологии, приложения, а также технологические приложения, работающие в режиме реального времени. Выход из строя этих систем влечёт за собой невосполнимые потери для управления, в т.ч. угрозу жизни и здоровью персонала и населения. Время восстановления подобных систем после отказа менее 10 минут. Для таких систем должны использоваться специализированные серверные платформы и инфраструктурные уровни с полным многократным резервированием всех компонентов, в том числе с использованием резервных удалённых ЦОД;

2) business Critical– системы, критические для управления, с режимом работы 24х7х365. Выход из строя этих систем влечёт за собой значительные потери для государственных учреждений и предприятий Донецкой Народной Республики. Время восстановления подобных систем после отказа менее 2 часов. Для таких систем должны использоваться кластерные решения и инфраструктурные уровни с частичным резервированием используемых инфраструктурных компонентов;

3) business Operational — обычные приложения — системы, не требующие работы в реальном времени, с режимом работы 8х5. Время восстановления подобных систем после отказа 4-6 часа. Для таких систем используется резервирование хранения данных и электропитания;

4) office Production — не критические для управления приложения, персональные данные. Время восстановления подобных систем после отказа 1-2 рабочих дня.

20.2. Необходимо учитывать, что общая непрерывность и отказоустойчивость ИТ-конфигураций определяется соответствующей непрерывностью и отказоустойчивостью её отдельных элементов: аппаратных, программных средств и инфраструктуры, необходимой для её успешного функционирования – каналов связи, системы электропитания и т.д. и, в конечном итоге, зависит от уровня непрерывности и отказоустойчивости его слабейшего компонента (принцип «слабого звена»). Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости должна быть одним из решающих факторов при выборе уровня инфраструктуры ЦОД для размещения ИТ-систем.

21. Принципы создания каталога рекомендованных конфигураций

21.1. Основная цель создания КРК – провести унификацию используемого оборудования и программного обеспечения и обеспечить целостность и управляемость ИТ-инфраструктуры государственных учреждений и предприятий Донецкой Народной Республики.

21.2. При построении и развитии своей ИТ-инфраструктуры государственные учреждения и предприятия Донецкой Народной Республики должны закупать и внедрять только внесённые в КРК ИТ-конфигурации. Закупка конфигураций, которые не входят в КРК, возможна в только виде исключения и в случае согласования с Министерством связи Донецкой Народной Республики.

21.3. Унификация ИТ-решений, используемых в рамках конкретного органа исполнительной власти позволит добиться снижения общего TCO, что подразумевает снижение расходов на закупки, внедрение и эксплуатацию элементов ИТ-инфраструктуры.

21.4. КРК используется во всех государственных учреждениях и предприятиях Донецкой Народной Республики и содержит следующий минимальный набор данных о рекомендованной конфигурации:

1) название конфигурации;

2) класс объекта (функциональный раздел каталога);

3) класс конфигурации по уровню использования;

4) класс конфигурации по уровню непрерывности;

5) набор аппаратных средств, для данной конфигурации;

6) набор программных средств, для данной конфигурации.

21.5. Для каждой позиции КРК необходимо выбрать конкретных производителей и конкретный перечень моделей их оборудования или программного обеспечения, принимая во внимание требования к элементам ИТ-инфраструктуры, приведённые в разделе V.

21.6. В качестве минимальных значений технических и функциональных параметров конфигураций необходимо использовать данные из КРК.

21.7. Принципы создания КРК:

1) конфигурации, включаемые в КРК, должны соответствовать общим требованиям к оборудованию и ПО, изложенным в разделе V настоящих Правил;

2) в качестве минимальных значений технических и функциональных параметров конфигураций необходимо использовать данные из КРК;

3) количество унифицированного оборудования и ПО в каждом функциональном разделе каталога должно быть минимально;

4) использование стандартного оборудования и ПО зарекомендовавшего себя на рынке производителя в данной области, который постоянно развивает и совершенствует свой модельный ряд;

5) обновление КРК регулярное (не реже чем раз в год);

6) использование сложного аппаратно–программного обеспечения разного назначения одного и того же производителя. Такое решение упрощает управление ИТ-инфраструктурой, позволяет снизить эксплуатационные затраты, а также стоимость вновь приобретаемого аппаратно–программного обеспечения;

7) включение в КРК решений не менее чем двух альтернативных производителей для массовых, стандартных ИТ-конфигураций и их элементов.

Раздел IV. Требования к государственным учреждениям и предприятиям Донецкой Народной Республики при выборе поставщиков, производителей и проведении конкурсов

22. Общие требования при выборе поставщиков, производителей и проведении конкурсов

22.1. Конкурсы, проводимые государственными учреждениями и предприятиями Донецкой Народной Республики (далее — Заказчик) должны соответствовать требованиям законодательства Донецкой Народной Республики в сфере проведении закупок товаров, работ и услуг за бюджетные средства и собственные средства.

22.2. При выборе поставщиков и производителей Заказчик руководствуется следующими общими требованиями:

1) при осуществлении импорта оборудования, ПО, услуг поставщик обязан заключить внешнеэкономический договор в установленном законодательством порядке;

2) оплата поставщиком импорта оборудования, услуг, осуществляется только через финансовое учреждение в соответствии с законодательством Донецкой Народной Республики;

3) деятельность поставщиков и производителей должна быть лицензирована, если таковое предусматривает законодательство Донецкой Народной Республики;

4) при подведении итогов конкурса, при прочих равных условиях, преимущество имеют те компании, производство которых отвечает требованиям стандарта системы менеджмента качества ISO 9001:2015 (ГОСТ ISO 9001-2011). Причём в приложении к сертификату должна быть указана именно та деятельность, на предоставление которой претендует данная компания;

5) преимущество имеют те участники конкурса, которые за последние три года успешно завершили два аналогичных контракта на поставку услуг, если они претендует на поставщика услуг, или разработку, инсталляцию, обеспечение технической поддержки для ИТ-систем, если они претендует на поставку программно-аппаратного обеспечения, аналогичных конкурсному предложению по параметрам и сопоставимых по масштабу;

6) минимально приемлемый оборот поставщика за последние 12 месяцев не должен быть меньше, чем сумма договора на поставку услуг или оборудования, умноженная на 5

7) преимущество имеют те участники конкурса, ключевые руководители которых имеют опыт успешной реализации, как минимум, двух контрактов сопоставимого масштаба, из которых минимум один контракт реализован в Донецкой Народной Республике;

8) при подведении итогов конкурса, при прочих равных условиях, преимущество имеют государственные предприятия Донецкой Народной Республике;

9) Заказчик вправе при выборе поставщиков и производителей ориентироваться на более высокие требования, чем это предусмотрено в настоящем документе.

23. Требования к государственным учреждениям и предприятиям Донецкой Народной Республики при выборе поставщиков и производителей оборудования

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

23.2. Предлагаемое поставщиком оборудование должно быть коммерчески доступно на протяжении не менее трёх месяцев, а программное обеспечение не менее двенадцати месяцев.

23.3. Поставщикам сложного программно-аппаратного обеспечения рекомендуется иметь сертификаты соответствия национальных систем сертификации государства импортёра, на всю гамму поставляемого оборудования и ПО в соответствии с действующими техническими требованиями в полном объёме, а также обновлять сертификаты при появлении новых версий программного и аппаратного обеспечения поставляемой продукции.

23.4. В случае поставки оборудования, поставщик должен обладать собственным складом.

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

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

23.7. Предпочтение должно отдаваться производителям, поставляющим оборудование и ПО, адаптированное для использования в Донецкой Народной Республики, если таковая адаптация возможна.

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

23.9. Поставщики должны осуществлять гарантийную поддержку поставленного оборудования и ПО согласно требованиям, к услугам по эксплуатации и сопровождению, приведённым ниже.

23.10. Гарантийный срок на программно-аппаратное обеспечение начинается с момента приёмки ПО или оборудования в эксплуатацию и должен продолжаться не менее 12 месяцев для аппаратного обеспечения и 6 месяцев для ПО.

23.11. Поставщики программно-аппаратного обеспечения могут организовать на территории Донецкой Народной Республики центры обучения с целью первичного обучения специалистов, эксплуатирующих программно-аппаратное обеспечение, их переподготовки при внедрении новых версий и типов оборудования и ПО, или иметь договор со сторонним центром обучения на оказание услуг по обучению, гарантируя при этом, что обучение на учебных курсах данного центра будет достаточно для эксплуатации программно-аппаратного обеспечения.

24. Требования к государственным учреждениям и предприятиям Донецкой Народной Республики при выборе поставщиков услуг

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

24.2. Предпочтение должно отдаваться государственным предприятиям, предоставляющим необходимый вид услуг.

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

24.4. При оказании услуг системной интеграции рекомендуется, чтобы поставщик имел внедрённую у себя на производстве систему управления проектами на основе лучших мировых практик, таких как рекомендации PMI и IPMA. Также предпочтение должно отдаваться компаниям, имеющим сертифицированных руководителей проектов, например, по системе PMI.

25. Требования к государственным учреждениям и предприятиям Донецкой Народной Республики при выборе поставщиков услуг по эксплуатации и сопровождению

25.1. Поставщики услуг по технической поддержке (сопровождению) и участники конкурсов, проводимых Заказчиками для поставки программно-аппаратного обеспечения, должны удовлетворить следующие минимальные требования к организации поддержи и эксплуатации:

1) сервис-центр должен находиться в приемлемой удалённости от заказчика, чтобы иметь возможность устранить неисправность с выездом к заказчику в сроки, установленные соответствующими регламентами взаимодействия, которые, в свою очередь, должны опираться на требования непрерывности, готовности и доступности ИТ-элементов ИТ-инфраструктуры;

2) эксплуатация программно-аппаратного обеспечения, гарантийный срок на которое истёк, должна осуществляться на основе контракта на послегарантийное обслуживание. Указанный контракт должен заключаться с сервис-центром, расположенным на территории Донецкой Народной Республики и обеспечивающим послегарантийное обслуживание программно-аппаратного обеспечения данного типа, а также обладающим специалистами, прошедшими соответствующее обучение (что подтверждается сертификатами поставщика), необходимым оснащением, запасными частями и оформленными должным образом взаимоотношениями с системой сервисной поддержки фирмы–поставщика или производителя. В случаях, когда программно-аппаратное обеспечение применяется в ограниченных объёмах и сервис-центр на территории Донецкой Народной Республики отсутствует, контракт на послегарантийное обслуживание заключается непосредственно с фирмой – поставщиком или её представительством;

3) эксплуатация сложного программно-аппаратного обеспечения, находящегося вне гарантийного срока, без заключённого контракта на послегарантийное обслуживание не осуществляется;

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

5) поставщик услуг по эксплуатации и сопровождению должен обладать квалифицированным техническим персоналом;

6) поставщики сложного программно-аппаратного обеспечения должны силами сервис-центров, расположенных на территории Донецкой Народной Республики, осуществлять модернизацию находящегося в эксплуатации программно-аппаратного обеспечения с целью поддержания его на современном техническом уровне и внедрения новых современных функций и услуг;

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

25.2. Сервис-центр поставщика услуг по эксплуатации и сопровождению должен обеспечивать:

1) поддержку пользователей, в соответствии с требованиями обслуживания в режиме 24/7, по телефону и с помощью электронной почты;

2) решение проблем, возникающих при работе программно-аппаратного обеспечения в объёме, возложенном на него;

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

4) возможность выезда специалистов для устранения неисправностей в соответствии с установленным регламентом. Рекомендуется использовать следующие требования для экстренного выезда специалистов: выезд специалиста в течение не более 12 часов и с прибытием на место в течение не более 24 часов с момента обращения (без учёта транспортных задержек, не зависящих от аккредитованного сервис-центра).

25.3. Не допускается несанкционированное ответственным лицом Заказчика вмешательство (в том числе дистанционное) сервис-центром в работу находящегося в эксплуатации программно-аппаратного обеспечения в случаях:

1) если для проведения ремонтных работ или обслуживания, требуется остановка оборудования, которая повлечёт нарушение бизнес-процессов, нанесение ущерба Заказчику или остановку взаимосвязанного оборудования, которое может привести к аналогичным последствиям, в этом случае время проведения работ должно быть согласовано с Заказчиком.

2) если остановка работы оборудования повлечёт остановку бизнес-процесса или нанесение ущерба Заказчику, сервис-центр должен предоставить оборудование того же класса, которое будет установлено на срок ремонта в течении не более чем (возможное время простоя оборудования) часов, при этом сервис-центр должен иметь ЗИП оборудования;

3) срок ремонта или замены сервис-центром неисправных узлов оборудования не должен превышать двух недель с момента передачи узла на аккредитованный сервис-центр.

25.4. В том случае, когда эксплуатация оборудования и поддержании его работоспособности производится собственными силами Заказчика, без участия сервис-центров, необходимо наличие резерва оборудования, превосходящего или соответствующего по мощности эксплуатируемому оборудованию, при этом ЗИП должны составлять 10% от используемого оборудования.

26. Требования к государственным учреждениям и предприятиям Донецкой Народной Республики при выборе поставщиков услуг по обучению

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

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

Раздел V. Требования к элементам ИТ-инфраструктуры

27. Требования к персональным компьютерам

27.1. Конкретные минимальные требования изложены в КРК.

27.2. При развитии парка персональных компьютеров и выборе закупаемых моделей ПК, ИТ-службы государственных учреждений и предприятий Донецкой Народной Республики должны руководствоваться следующими положениями:

1) аппаратная платформа и программное обеспечение персональных компьютеров должны иметь гибкую и масштабируемую архитектуру;

2) аппаратные характеристики ПК должны соответствовать, либо превосходить минимальные системные требования используемого ПО;

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

4) ПК должен иметь аппаратную либо программную систему удалённого управления для возможности централизованного удалённого администрирования;

5) для повышения качества и скорости администрирования количество различных программно–аппаратных конфигураций персональных компьютеров должно быть ограничено. Рекомендуется использование не более 4 типовых конфигураций.

27.3. Для спецификации требований выделяются следующие ключевые параметры ПК:

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

2) надёжность. Надёжность должна обеспечиваться за счёт аппаратных средств и программного обеспечения и определяться исходя из среднего времени безотказной работы (MTBF);

3) масштабируемость. Масштабируемость должна обеспечиваться архитектурой и конструкцией персонального компьютера за счёт возможности наращивания числа и мощности процессоров, объёмов оперативной и внешней памяти.

28. Типовые конфигурации ПК

28.1. Персональный компьютер для работы с прикладным ПО (офисные системы, финансовые системы, СЭД и т.п.).

28.2. Персональный компьютер повышенной мощности для работы с графическими пакетами, пакетами ПО моделирования, САПР, АСУЭИ, АСУТП и пр. Используется для приложений с развитой графикой, высокими требованиями к производительности процессора и объёмам оперативной памяти.

28.3. Тонкий клиент. Маломощный персональный компьютер для работы с приложениями в терминальной среде, либо с программами-тонкими клиентами в клиент-серверной архитектуре. При такой работе основные ресурсоёмкие операции производятся на сервере.

28.4. Ноутбук для работы мобильных пользователей.

29. Требования к системному ПО рабочих мест пользователей

29.1. Конкретные минимальные требования изложены в КРК.

29.2. ОС офисного назначения должны:

1) соответствовать по типу клиентским ОС;

2) поддерживать все сетевые сервисы, обеспечивающие функционирование корпоративной сети;

3) обеспечивать необходимый уровень информационной безопасности, соответствовать требованиям политики информационной безопасности Донецкой Народной Республики;

4) быть совместимыми с ведомственным стандартом используемого офисного ПО.

30. Требования к периферийным устройствам

30.1. Конкретные минимальные требования изложены в КРК.

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

30.3. Для описания минимальных требований к периферийному оборудованию используется следующая классификация устройств:

1) персональное устройство – находится в постоянном использовании одним сотрудником;

2) групповое устройство – используется в режиме разделения ресурсов группой сотрудников;

3) корпоративное устройство – используется в составе ЦОД I или II уровней.

30.4. Общие требования необходимо применять при выборе и закупке нового периферийного оборудования в целях развития ИТ Заказчика.

30.5. Периферийное оборудование должно отвечать следующим основным требованиям:

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

2) надёжность. Периферийное оборудование должно позволять обеспечивать непрерывность процессов и удовлетворять требованиям, определённым в количественных показателях (MTBF);

3) функциональность. В том случае, если рабочее место сотрудника должно быть оборудовано несколькими видами периферийного оборудования, следует отдавать предпочтение при закупке многофункционального устройства (МФУ), которое должно поддерживать все или частично все следующие функции печатного устройства, сканирующего устройства, копировального устройства, факсимильного устройства;

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

5) безопасность. Выход из строя какого-либо периферийного устройства не должен  влиять на устойчивую работу персональных компьютеров (в случае использования группового или корпоративного устройства – серверов)  с другим периферийным оборудованием;

6) управляемость. Подключение и управление персональным периферийным оборудованием по возможности должны быть простыми и не требовать оперативного использования инструкций и описаний работы устройств;

7) низкая ТСО. Запчасти и расходные материалы для периферийного оборудования должны быть легко доступны и обладать невысокой стоимостью;

8) низкий уровень создаваемого акустического шума. Периферийным оборудование в процессе работы не должно создавать помех окружающим. Уровень шума не должен превышать 55 дБ[A]. Для эксплуатации шумного оборудования должны быть предусмотрены специально выделенные помещения;

9) низкое энергопотребление. Необходимо приобретать оборудование, имеющее режим пониженного энергопотребления (режим ожидания);

10) следует отдавать предпочтение тем периферийным устройствам, которые в штатном режиме имеют возможность обмена информацией через локальную сеть, те периферийные устройства, которые имеют возможность подключаться как к ПК, так и к локальной сети следует подключать к локальной сети.

30.6. Для групповых и корпоративных устройств должны применяться более жёсткие требования, нежели к персональным устройствам. При выборе групповых и корпоративных устройств необходимо исходить из оценки количества пользователей, которые будут эксплуатировать данные устройства.

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

1) наличие клиентского приложения для ПК для приёма и рассылки факсов, а также для сканирования документов;

2) поддержка формата А3;

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

4) двусторонняя печать.

30.8. МФУ должны проходить периодическое техническое обслуживание, которое будет способствовать более высокой отказоустойчивости устройства и снизит TCO. Периодичность данного обслуживания необходимо определять из технических требований по эксплуатации каждого конкретного устройства.

31. Прикладное программное обеспечение

31.1. Прикладное ПО используемое в государственных учреждениях и предприятиях Донецкой Народной Республики должно обладать следующими характеристиками:

1) функциональность – способность ПО максимально эффективно выполнять заявленные функции, с требуемыми характеристиками;

2) функциональная полнота – полный набор функций, которые способно выполнять данное ПО;

3) платформонезависимость – способность ПО функционировать в разных программно-аппаратных средах, под управлением разных операционных систем;

4) производительность – способность ПО обеспечивать сбор, обработку и хранение определённых объёмов информации при заданной конфигурации аппаратной платформы;

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

6) способность к интеграции (Open System Interconnection (OSI), Interoperability) – способность ПО к интеграции и взаимодействию с другими системами, в том числе с системами сторонних производителей, и эксплуатируемыми на других платформах;

7) зрелость – наличие истории развития данного ПО (присутствие данного ПО на рынке в течение определённого промежутка времени, регулярный выпуск производителем новых версий и релизов) и объявленных производителем планов по его развитию;

8) надёжность и отказоустойчивость – способность ПО и систем, построенных на его базе, к бесперебойной, непрерывной работе, а в случае возникновения программно-аппаратных сбоев — способность к быстрому восстановлению работоспособности системы.

31.2. Общая стоимость владения (ТСО) ПО – складывается из затрат на начальное приобретение (разработку) данного ПО, ввод его в эксплуатацию и расходов на его эксплуатацию и сопровождение в течение нормативного срока жизни данного ПО. Общая стоимость владения включает затраты: на обновление программного обеспечения и оборудования; на обучение, обслуживание, администрирование и техническую поддержку.

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

1) универсальное (тиражируемое) ПО – ПО, доступное на рынке и служащее для решения универсальных задач;

2) заказное ПО – ПО, разработанное по заказу ИТ-подразделением или сторонней организацией.

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

31.5. При выборе и внедрении нового прикладного ПО должны соблюдаться следующие требования:

1) всё используемое прикладное ПО должно быть унифицировано и каталогизировано в рамках КРК в виде списка ПО, допустимого к использованию;

2) ПО клиентских ПК должно быть функционально полным и обеспечивать выполнение как стандартных процессов, так и специфических задач данного пользователя;

3) ПО должно быть зрелым: производитель (поставщик) должен гарантировать поддержку, сопровождение данного ПО в течение всего нормативного срока жизни данного ПО;

4) необходимо использовать платформонезависимое ПО, обеспечивающее свободу выбора программно-аппаратных средств для его эксплуатации и, в конечном счёте, снижение общей стоимости владения системой;

5) необходимо использовать производительное, масштабируемое ПО, обеспечивающее гарантии непрерывности бизнес-процессов при росте объёмов обрабатываемой и хранимой информации. Рекомендуется производителю ПО регулярно проводить объёмное и нагрузочное тестирование своего ПО и предоставлять данные о результатах данного тестирования;

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

7) при выборе ПО преимущества должны получать системы с подтверждённым положительным опытом использования в государственных учреждениях;

8) для обеспечения критических процессов и услуг необходимо использовать отказоустойчивое ПО;

9) общая стоимость владения ПО, рассчитанная на весь нормативный срок эксплуатации данного ПО, должна служить важнейшим критерием при выборе того или иного поставщика и ПО;

10) в области информационной безопасности ПО должно соответствовать требованиям политики информационной безопасности Донецкой Народной Республики;

11) ПО должно быть надлежащим образом документировано. Минимальные требования к документации – наличие документов «Руководства пользователя» и «Руководство администратора».

31.6. При закупке нового универсального прикладного ПО должны соблюдаться следующие требования:

1) необходимо закупать ПО в рамках специальных моделей лицензирования, обеспечивающих снижение стоимости закупки;

2) при использовании лицензируемого ПО на него должны быть обязательно получены и надлежащим образом зарегистрированы соответствующие лицензии;

3) использование ПО производителей, зарекомендовавших себя на рынке в данной области. Желательно, чтобы данный производитель присутствовал на рынке с данным или аналогичным ПО не менее трёх лет. Не рекомендуется использование устаревших версий ПО, а также слишком новых, «незрелых» версий ПО;

4) должно быть запрещено к использованию нелицензионное ПО, и ПО, не имеющее поддержки (сопровождения) со стороны производителя;

5) при выборе универсального ПО необходимо руководствоваться общим требованиями к прикладному ПО.

31.7. При разработке нового прикладного ПО должны соблюдаться следующие требования:

1) процесс проектирования, разработки и внедрения заказного ПО должен соответствовать требованиям Приказа Министерства связи Донецкой Народной Республики от 16.10.2015 г. N 85 зарегистрированный Министерством юстиции Донецкой Народной Республики от 02.11.2015 г. №700 «Об утверждении Требований к организации мероприятий создания, развития, эксплуатации и вывода из эксплуатации государственных информационных систем, и дальнейшего хранения содержащейся в их базах данных информации»;

2) необходимости технико-экономического обоснования разработки и внедрения данного ПО;

3) при формировании Технического задания в соответствии с ГОСТ 34.602-89 необходимо подробно сформулировать и описать требования к заказываемому ПО, в частности, к его основным свойствам, перечисленным выше. Заказчик ПО должен представить технико-экономического обоснования разработки и внедрения данного ПО, с учётом требований и принципов минимизации ТСО для данного решения;

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

5) при выборе разработчика ПО необходимо сформулировать требования к применяемым системам управления качеством. Желательно наличие у разработчика сертификата на соответствие его системы управления качеством процессов разработки ПО стандартам семейства ISO 9000 (ГОСТ Р ИСО 9000);

6) в процедуры приёмки ПО необходимо включать передачу разработчиком исходных текстов программ и других объектов, необходимых для создания ПО, согласно требованиям, ГОСТ Р ИСО/МЭК 12207-2010. Процедура приёмки должна обязательно включать в себя контрольную компиляцию переданных исходных текстов, с созданием полностью работоспособной версии ПО, и выполнение контрольного примера на данной версии;

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

31.8. При наличии специального прикладного ПО руководители государственных учреждений и предприятий Донецкой Народной Республики могут принять самостоятельное решение об установке системного ПО, отличающегося от имеющихся в КРК решений, обеспечивающего функционирование данного приложения

32. Требования к мультисервисной сети

32.1. Конкретные минимальные требования изложены в КРК.

32.2. Основными стратегическими положениями и подходами к организации распределённой мультисервисной сети в государственных учреждениях и предприятиях Донецкой Народной Республики является ориентация на архитектуру сетей NGN, позволяющая меняя версии ПО на Softswitch-ах и сами Softswitch-и, расширять функциональные возможности, не меняя оборудование доступа. Помимо этого, согласно архитектуре IMS стандартизируется протокол предоставления сервисов, что позволяет, без доработки интерфейсов взаимодействия, подключать любые услуги от любых сервис-провайдеров.

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

32.4. NGN-сеть построена на следующих принципах:

1) распределённая корпоративная архитектура, обеспечивающая QoS;

2) высокая доступность и надёжность сети;

3) производительность, управляемость и масштабируемость сети;

4) мультисервисная сеть должна проектироваться с учётом требований информационной безопасности.

32.5. Весь трафик должен быть классифицирован на следующие классы, определяющие приоритет обслуживания:

1) трафик реального времени (телефонный, аудио и видео);

2) трафик передачи пользовательских данных;

3) технологический трафик.

32.6. Если технологическое оборудование требует наивысшего класса обслуживания, то его трафику должен быть отдан наивысший приоритет. После этого должен идти трафик реального времени, после которого следует трафик пользовательских приложений. Причём пропускная способность сети и активное сетевое оборудование должны всегда обеспечивать качество для трафика реального времени.

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

32.8. Система виртуализации должна находиться в отдельном VLANе (VLAN управления).

32.9. Архитектура мультисервисной сети должна быть основана на следующих принципах:

1) строиться на трёхуровневой модели;

2) иметь резервирование по оборудованию и каналам (резервирование каналов должно быть физическим и не должно реализовываться в одном магистральном кабеле);

3) поддерживать VLAN;

4) каждый сегмент сети, требующий изоляции, должен иметь ДМЗ;

5) сеть должна обеспечивать необходимую для решения задач производительность;

6) сеть должна обеспечивать QoS для разных классов трафика.

32.10. Мультисервисная сеть для всех ЦОД должна проектироваться, исходя из трёхуровневой модели коммутации:

1) уровень доступа (Access Layer) – коммутаторы 2-го уровня модели OSI с интеллектуальностью 3–4-го уровней модели OSI (с целью обеспечения требований к сетевой безопасности, QoS и т. д.);

2) уровень распределения (Distribution Layer) – коммутаторы 3–4-го уровней модели OSI;

3) магистральный уровень / уровень ядра (Core Layer) – коммутаторы 3–4-го уровней модели OSI.

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

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

32.13. Должны быть соблюдены общие правила проектирования трёхуровневой структуры:

1) любые проблемы с оборудованием и каналами связи на нижележащих уровнях не должны сказываться на верхних уровнях;

2) транзитные резервные маршруты определённого уровня не должны проходить через нижележащие уровни;

3) классификация трафика должны происходить только на уровне доступа;

4)  приоритизация трафика должна поддерживаться всеми уровнями сети. Уровень распределения должен только агрегировать трафик. Ядро сети должно только осуществлять быструю коммутацию и маршрутизацию пакетов;

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

6) удалённые пользователи и внешние каналы связи не должны подсоединяться напрямую к ядру сети. Необходимо использовать коммутаторы доступа для предотвращения лавинообразных перестроек таблиц маршрутизации всей сети;

7) запрещается использование неуправляемых коммутаторов. Минимально допустимый коммутатор в сети — управляемый коммутатор уровня 2.

32.14. Резервирование для ЦОД I уровня должно, а для ЦОД II уровня необходимо организовывать следующим образом:

1) в сети должно быть не менее двух коммутаторов уровня ядра, связанных между собой по 10 (либо выше) GigabitEthernet, либо объединённых в отказоустойчивый стек с эквивалентной пропускной способностью;

2) каждый коммутатор уровня доступа должен иметь соединения каналами Gigabit Ethernet с двумя коммутаторами уровня распределения;

3) каждый коммутатор уровня распределения должен иметь соединения каналами Gigabit Ethernet (либо выше) с двумя коммутаторами уровня ядра;

4) для обеспечения отказоустойчивости в сети должно быть два пограничных маршрутизатора. Маршрутизаторы подключаются каждый к не менее чем двум различным интернет-провайдерам и осуществляют маршрутизацию пакетов по протоколу BGP. Каждый пограничный маршрутизатор должен быть связан с двумя устройствами, обеспечивающими функциональность МСЭ или IDS/IPS;

5) для обеспечения независимости от интернет-провайдеров должна использоваться AS с собственным пулом ip-адресов (не менее /22).

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

1) поэтажные коммутаторы (коммутаторы доступа) должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet;

2) серверы должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet. При необходимости допускается подключение серверов к коммутаторам уровня ядра;

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

4) между двумя зданиями рекомендуется прокладывать оптические каналы. При больших расстояниях, необходимости пропуска большого объёма трафика и больших скоростей передачи данных рекомендуется организовывать каналы связи на основе технологии xWDM и агрегации каналов.

32.16. Надёжность сети должна быть обеспечена при помощи выполнения следующих правил:

1) оборудование магистрального уровня должно иметь резервирование всех компонентов;

2) сеть должна быть спроектирована с учётом требований информационной безопасности в соответствии с требованиями политики информационной безопасности Донецкой Народной Республики;

3) в сети должны использоваться VLAN. VLAN должны в обязательном порядке  быть отделены все ресурсы сети и пользователи, которые имеют повышенную защищённость согласно политике информационной безопасности Донецкой Народной Республики.

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

1) за счёт правильного внедрения трёхуровневой модели коммутации;

2) за счёт масштабируемости коммутаторов, которая должна достигаться за счёт объединения коммутаторов в группы (стеки). Причём каждый коммутатор в стеке должен работать в двух режимах – как главный коммутатор стека и как процессор коммутации пакетов. Должна обеспечиваться отказоустойчивость системы по схеме 1:N (при выходе из строя одного из коммутаторов стека, независимо от выполняемой им функции, остальные будут продолжать выполнение своих функций без остановки работы всей сети);

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

32.18. Система IP-адресации сети должна обеспечивать:

1) разделение адресного пространства на служебный блок (сети, связывающие маршрутизаторы, виртуальные интерфейсы и т.п.) и блок адресов локальной сети. Такое разделение позволяет эффективно строить правила доступа к сетевым устройствам;

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

32.19. Для осуществления аутентификации на уровне доступа для всех устройств, обеспечивающих функционирование сети, и при доступе к консоли управления всеми устройствами, сеть должна обладать следующими возможностями:

1) безопасность портов, т.е. должна быть возможность использования порта коммутатора с предварительно заданными физическими адресами пользовательских ПК (MAC-адреса). При попытке подключения неавторизованного устройства должно производиться отключение этого порта и уведомление системы управления сетью;

2) автоматическое конфигурирование портов коммутаторов, т.е. должна быть автоматизация изменения конфигурации порта на основе логического подключения пользователя к сети;

3) аутентификация административного доступа на Radius или LDAP сервере, т.е. должна быть идентификация, авторизация и учёт при доступе к командной строке устройства;

4) ограничение доступа по IP адресам, с учётом ограничения на доступ к командной строке устройства и системной консоли, а также SNMP трафика;

5) должна быть автоматическая фильтрация трафика неиспользуемых протоколов на портах коммутаторов.

32.20. Для обеспечения высокой доступности сети необходимо использовать следующую функциональность:

1) поддержка протокола RSTP/MSTP или иных протоколов резервирования второго уровня;

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

3) функции автоматического переключения с основного маршрутизатора на резервный в случае отказа основного;

4) балансировка нагрузки между резервируемыми маршрутизаторами;

5) функции внутреннего программного обеспечения для улучшения времени сходимости протоколов маршрутизации и балансировки нагрузки через равноценные маршруты.

32.21. Для поддержки приложений, основанных на технологии многоадресной рассылки IP Multicast, от сетей требуется наличие следующих возможностей:

1) на уровне доступа/распределения – передача пакетов IP Multicast на канальном уровне на скорости физического канала, динамическая регистрация посредством протоколов IGMP и PIM;

2) магистральный уровень – передача пакетов IP Multicast на канальном и сетевом уровнях на скорости физического канала, масштабируемые протоколы маршрутизации трафика IP Multicast.

32.22. Оборудование уровня доступа должно обладать возможностью классификации трафика (Traffic Classification), т.е. должна быть обеспечена возможность классифицировать трафик по типам приложений, физическим и сетевым адресам источников и получателей, портам коммутаторов. Классифицированный трафик должен получать метку, обозначающую назначенный пакетам уровень приоритета, тем самым давая возможность устройствам сети соответствующим образом обслуживать этот трафик. Должна быть обеспечена реклассификация пакетов на основе заданной администратором политики качества обслуживания. Например, пользователь назначает высокий приоритет своему трафику и передаёт его в сеть. Этот приоритет может затем быть понижен в соответствии с сетевой политикой, а не на основе требований пользователя. Данный механизм должен быть ключевым в обеспечении качества обслуживания в рамках всей сети.

32.23. Оборудование магистрального уровня должно обладать следующей функциональностью:

1) предотвращение и управление перегрузками, т.е. должна быть обеспечена возможность управлять поведением сети при перегрузках, отбрасывая определённые пакеты на основе классификации или политики в моменты перегрузки сети и множества очередей на интерфейсах. Администратор должен устанавливать пороговые значения для различных уровней приоритета;

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

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

4) предоставлять возможность углублённого анализа потоков сетевого и транспортного уровней при помощи протокола IPFIX (RFC 3917), Netflow, J-Flow или другого протокола предоставления агрегированной статистики по     ip-потокам.

32.24. В ЦОД I и II уровня помимо обеспечения резервирования основных узлов оборудования магистрального уровня, необходимо обеспечить такое же резервирование для оборудования уровня распределения.

32.25. Во всем активном сетевом оборудовании должны быть средства мониторинга политики качества обслуживания и безопасности, планирования сети и сервисов:

1) должна быть обеспечена возможность сбора статистики с точностью до порта сети для анализа производительности и выявления узких мест сети;

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

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

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

5) должна быть обеспечена возможность доступа к интерфейсу управления устройством и отчётам через стандартный WEB–браузер с использованием протокола HTTPS;

6) должна быть возможность подключения к устройству для его настройки с использованием протокола ssh;

7) должна быть обеспечена возможность автоматической конфигурации Fast/Gigabit Ethernet портов, виртуальных сетей, транков VLAN;

8) должна быть обеспечена возможность автоматического распознавания топологии сети посредством агентов распознавания топологии;

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

32.26. Все активное оборудование должно иметь конструктивное 19” стоечное исполнение.

32.27. Основной протокол передачи аудио- и видеоинформации – IP. Допускается использование традиционной аналоговой телефонии в следующих случаях:

1) унаследованные существующие телефонные станции;

2) экономическая целесообразность. Данное исключение действует до момента, когда стоимость VoIP телефонов станет сопоставима с ценой аналогового телефона.

32.28. VoIP преимущественно должна внедряться по технологии SIP, т.к. данная технология, по сравнению с H.323, используется в сетях следующего поколения и имеет большую функциональность. При этом необходимо обращать внимание на совместимость реализации протокола SIP между оконечными устройствами и программно-аппаратным комплексом, обеспечивающим функциональность учрежденческой телефонной станции. Данная совместимость должна выражаться в поддержке основного функционала по обработке поступающих звонков с оконечных устройств. В целях недопущения проблем, связанных с несовместимостью реализации протокола SIP, необходимо устанавливать оконечные устройства (телефоны) и программно-аппаратные комплексы, обеспечивающие функциональность учрежденческой телефонной станции, одного производителя, либо проводить тщательное лабораторное тестирование совместимости аппаратуры разных производителей.

32.29. Системы видеоконференцсвязи должны поддерживать Web-конференции.

32.30. Видеоконференцсвязь должна организовываться на технологии IP с использованием стандартов H.323/H.264 и используя SIP протоколы.

32.31. При пакетной передачи за эталон качества речи должен быть принят уровень качества, равный 4,3 — 5,0 баллам по шкале MOS/PAMS (Mean Opinion Score, субъективный метод оценки согласно рекомендации Р.800). Необходима настройка QoS для голосового трафика на всех каналах связи, а также на коммутаторах доступа, access level.

32.32. Необходимый кодек G711, для узких и не качественных линий, в том числе АДСЛ, допускается в редких случаях G729 с условием выполнения транскодинга за счёт клиента.

32.33. Канал связи, предоставляемый организации оператором телекоммуникационных услуг должен обладать следующими характеристиками: задержка передачи данных не более 50мс, джиттер — до 5мс.

33. Требования к внешним каналам связи

33.1. В целях унификации необходимо выделить следующие используемые виды каналов связи:

1) телефонные цифровые потоки E1 PRI;

2) выделенные каналы передачи данных с шириной от 64 кбит/с до 2 Мбит/с и выше;

3) арендуемые каналы сети передачи данных.

33.2. При выборе вида канала связи преимущество необходимо отдавать каналам связи, которые подключаются к сети MPLS оператора, т.к. только сети MPLS в настоящее время эффективно обеспечивают QoS для мультисервисного трафика при приемлемой стоимости услуги. Интерфейс подключения – Ethernet, точка-точка.

33.3. Каналы связи для соединений точка–точка или точка–многоточка между ЦОД I и II уровней должны организовываться посредством технологии MPLS или иной технологии, обеспечивающей выполнение необходимых требований по пропускной способности канала и качеству предоставления услуги, которую поддерживает оператор связи. При этом должен быть заключён договор, который предусматривает обеспечение QoS для аудио- и видеоданных, если таковые имеются. Требования должны быть указаны в соответствующем SLA.

33.4. С целью резервирования коммуникаций для ЦОД I уровня обязательно, а для ЦОД II уровня необходимо наличие подключения к двум независимым операторам.

33.5. При подключении ЦОД I и II уровней оператор связи должен обеспечить круглосуточную службу технической поддержки, которая в любое время суток не только принимает заявки, но и устраняет инциденты.

33.6. Качество спутниковых каналов связи должно соответствовать требованиям законодательства Донецкой Народной Республике.

33.7. При приёме каналов спутниковой связи оператор должен предоставить протоколы проведения приёмочных испытаний.

34. Требования к инфраструктуре центров обработки данных

34.1. Конкретные минимальные требования к системам обработки, хранения и резервного копирования данных изложены в КРК.

34.2. Общие требования к системам обработки, хранения и резервного копирования данных для всех ЦОД:

1) Производительность. Производительность оборудования должна складываться из производительности основных подсистем. Необходимо отслеживать нагрузку основных подсистем, выявлять узкие места и наращивать, по мере необходимости, производительность путём оптимизации конфигурации, установки дополнительных модулей либо замены текущих модулей на более производительные. В рабочем режиме сервер должен иметь загрузку основных ресурсов не более чем на 75%, чтобы выдерживать пиковую нагрузку в случае необходимости;

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

3) масштабируемость. Необходимо использовать оборудование, имеющего, в случае необходимости, возможность увеличения производительности;

4) готовность. Степень отказоустойчивости оборудования должна обеспечиваться за счёт уменьшения единичных точек отказа, технологии объединения нескольких серверов в кластер, использование систем высокой отказоустойчивости от ведущих производителей.

34.3. Выбор серверного оборудования должен зависеть от тех задач (приложений), которые они будут решать. Учитывая, что разброс задач огромен и при возрастании количества пользователей и объёмов данных, требования к вычислительным ресурсам резко повышаются, поэтому требуется:

1) выбирать серверы, позволяющие постепенно масштабировать ресурсы и увеличивать производительность;

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

34.4. Серверы должны обеспечивать:

1) высокую скорость обработки данных при сниженных затратах на обслуживание;

2) простоту управления для быстрого изменения и перераспределения ресурсов в зависимости от потребностей;

3) высокую надёжность и непрерывность обработки и доступа к информации;

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

5) быть энергоэффективными.

34.5. В ЦОД I и II уровней требуется устанавливать высокопроизводительные серверные платформы ведущих производителей среднего и высшего уровней производительности.

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

34.7. Высокопроизводительные серверные платформы должны иметь ряд встроенных систем высокой доступности, таких как:

1) резервные вентиляторы и блоки питания горячей замены;

2) диски и адаптеры I/O горячего подключения;

3) динамическая очистка и перераспределение страниц памяти;

4) динамическое перераспределение процессоров и способность к восстановлению;

5) интегрированная служба оповещения о событиях, работающая в режиме реального времени;

6) встроенная расширенная система обнаружения неисправностей с выделенным сервисным процессором и шиной; наличие удалённой консоли.

34.8. Во всех серверных решениях должно быть уделено большое внимание предотвращению возможных сбоев. Для ЦОД I и II уровней должны быть реализованы соответствующие функции, при помощи которых осуществляется непрерывный контроль состояния всех компонентов сервера и анализ тенденций изменения контролируемых показателей. При обнаружении какой-либо потенциальной проблемы, например возможного перегрева процессора, специальные функции динамического перераспределения ресурсов должны обеспечить перенос процессов с потенциально–сбойного компонента на исправный без прерывания выполнения приложений. При этом администратор системы и/или служба технической поддержки должны получить уведомление и подробный отчёт о происшедшем событии.

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

34.10. ПО, реализующее технологию виртуализации серверов, должно реализовывать следующую функциональность:

1) функция декомпозиции: компьютерные ресурсы должны рассматриваться как единый однородный пул, распределяемый между виртуальными машинами; множество приложений и операционных систем должны сосуществовать на одной физической компьютерной системе;

2) функция изоляции: виртуальные машины должны быть полностью изолированы друг от друга;

3) аварийный отказ одной из них не должен оказывать никакого влияния на остальные;

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

5) совместимость должна гарантироваться посредством представления виртуальной аппаратуры приложениям и ОС как стандартной.

34.11. В ЦОД I уровня обязательно, а в ЦОД II уровня рекомендуется использовать дисковый массив для хранения основных прикладных данных и функцию хранения данных передавать сети хранения данных (SAN) с последующей виртуализацией SAN. Встроенные диски серверов использовать только для системных целей, используя технологию избыточности RAID.

34.12. В случае если для ЦОД II уровня не используются сети SAN, то должны быть использованы устройства NAS с функциональностью виртуализации.

34.13. Для ЦОД I и II уровней должна быть внедрена технология виртуализации на всех уровнях ИТ-инфраструктуры:

1) локальная сеть – технология VLAN;

2) сервера – технология виртуализации серверов;

3) сети и системы хранения данных – технология виртуализации SAN или NAS.

34.14. ОС предназначенные для обслуживания серверных приложений и промышленных систем должны:

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

2) обеспечивать высокий уровень быстродействия приложений;

3) обладать встроенными возможностями для организации удалённого мониторинга всех основных сервисов ОС.

34.15. Главными приоритетами в развитии систем хранения данных должны быть:

1) наличие, в случае необходимости возможность наращивания ёмкости систем хранения данных, встроенных механизмов дублирования и репликации данных;

2) концентрирование систем хранения данных в едином месте, причём количество территориально-удалённых мест должно быть ограничено и иметь резервный ЦОД;

3) расширение возможностей восстановления после аварий;

4) уменьшение времени восстановления;

5) уменьшение окон резервного копирования (интервалов времени, отведённых для подготовки резервной копии) для критически важных приложений.

34.16. Должны быть выделены следующие уровни системы хранения данных:

1) сверхоперативный уровень. Данные этого уровня используются высоконагруженными СУБД, сервисами. Оборудование должно иметь максимальное быстродействие, поддерживать большой объём кеш-памяти, использовать жёсткие диски с максимальным быстродействием: Flash, Fibre channel со скоростью вращения 15 k;

2) оперативный уровень. Данные с этого уровня достаточно часто используются пользователями. Соответственно оборудование должно быть достаточно быстродействующим и иметь высокую степень доступности. Необходимо использовать быстрые диски SCSI/SAS со скоростью вращения 15k или 10k либо SSD со скоростью чтения/записи. Уровень долгосрочного хранения данных – постоянное место хранения данных, которое помимо производительности должно обладать надёжностью. Необходимо использовать диски SATA;

3) электронный архив. Программно-аппаратный комплекс, который обеспечивает физическую сохранность электронных данных вне зависимости от действий пользователей. Данные, помещённые в электронный архив, не подлежат не санкционированным модификациям. При изменении исходных данных в электронном архиве должна храниться как исходная копия, так и все её модификации. Электронных архив должен создаваться на неперезаписываемых оптических носителях информации. Данное устройство должно иметь интерфейс Fibre Channel и подсоединяться к сети SAN.

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

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

34.18. Система хранения данных должна иметь:

1) единые средства для репликации данных, которые должны перемещать данные между уровнями систем хранения данных, приводя в соответствие ценность данных и этап их жизненного цикла с показателями доступности, производительности, безопасности и стоимости уровня хранения;

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

34.19. СХД должна иметь способность управлять логическими разделами памяти внешних устройств. Логические разделы должны распределять ресурсы одного физического устройства хранения данных на несколько виртуальных устройств, каждое из которых должно независимо настраиваться для отдельных приложений и/или групп пользователей. Эта стратегия эффективно работает при хранении значительных объёмов разнотипных данных, поэтому логические разделы должны стать частью многоуровневой инфраструктуры хранения данных.

34.20. Система управления СХД должна быть интегрирована в саму СХД, без использования дополнительного серверного оборудования.

34.21. В ЦОД I уровня должна быть внедрена технология SAN (ориентированная на хранение информации на блочном уровне, технология SAN может использовать в качестве среды передачи данных как технологию FibreChannel, так и технологию Ethernet с использованием протокола iSCSI), как удовлетворяющая всем необходимым требованиям.

34.22. В ЦОД II уровня также необходима технология SAN, но допускается возможность развёртывания устройств NAS (устройства хранения, подключаемые непосредственно к локальной или глобальной сети, NAS используется для хранения информации на файловом уровне, и обычно поддерживают доступ к файлам по протоколам NFS, CIFS/SMB, FTP, HTTP) для организации файловых сервисов. При этом должна быть стратегически выбрана одна технология или продуман и обоснован подход одновременного использования и SAN и NAS без взаимных конфликтов, обеспечивающий виртуализацию для серверных систем и общее управление единым пулом СХД.

34.23. Целью внедрения и использования технологии SAN должно стать обеспечение реальной консолидации ресурсов хранения и их совместного использования, т.к. ёмкость хранения должна подключаться ко многим серверам, в том числе и удалённым, а машины, обрабатывающие данные, должны освобождаться от задач управления ресурсами и их хранения.

34.24. При внедрении технологии SAN должно быть обеспечено:

1) независимость топологии SAN от storage–систем и серверов;

2) удобное централизованное управление;

3) удобное резервирование данных без перегрузки локальной сети и серверов;

4) высокое быстродействие;

5) высокая масштабируемость;

6) высокая гибкость;

7) высокая готовность.

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

34.26. При выборе и внедрении конкретного оборудования и ПО для реализации SAN должны быть реализованы следующие сервисы виртуализации:

1) виртуализация подключения к SAN. К дисковому массиву через SAN должны получать доступ несколько серверов и распределение физических портов массива между ними не должно являться управленческой проблемой и не должно стать препятствием для полного использования возможностей СХД. СХД должна позволять создавать несколько виртуальных портов на одном физическом порте Fibre Channel, а также управлять этими портами;

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

3) СХД должна обеспечивать надёжные сервисы управления логическими дисками (LUN) и томами для распространения расширенных сервисов управления информацией и хранением данных на модульные системы хранения данных, поддерживающие различные типы дисков;

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

34.27. При построении SAN в ЦОД I уровня на коммутаторах необходимо создавать две независимые Fabric (Dual fabric). Dual fabric позволяет избежать единой точки отказа в SAN, обеспечивая высокий уровень надёжности и отказоустойчивости. Кроме того, изменения конфигурации, регламентные работы (например, установка нового firmware) на коммутаторах одной из Fabric не сказываются на работе другой. Применение Dual fabric совместно с программным обеспечением, реализующим поддержку альтернативных путей доступа и распределение нагрузки, для соединения серверов и устройств хранения (пути должны быть распределены между разными Fabric) позволяет создать надёжную SAN. Также необходимо предусматривать наличие на серверах ПО Dynamic multipathing для обеспечения непрерывной работы приложений с двумя фабриками.

34.28. Необходимо выбирать оборудование, поддерживающее Fibre Channel с пропускной способностью 8 Гбит/с. с поддержкой скоростей передачи данных 4/2/1 Гбит/с. В случае обеспечения более высокой скорости передачи данных по магистральным каналам необходимо использование транкинга (trunking) — объединения нескольких каналов передачи данных в один канал.

34.29. В тех случаях, когда требуется обеспечить высокую надёжность и доступность приложений и информационных систем для пользователей, необходимо использовать технологии кластеризации приложений. В зависимости от требуемой величины надёжности и доступности системы, которую необходимо обеспечить, целесообразно применять либо кластеры, работающие в режиме активный/резервный (high-availability clusters), либо параллельные кластеры (parallel clusters), обеспечивающие более высокий уровень доступности. При выборе прикладного ПО необходимо учитывать возможности систем по работе в кластерных конфигурациях.

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

34.31. Сохранение данных можно обеспечить как средствами СХД (синхронное/асинхронное зеркалирование данных на резервный ЦОД), так и средствами приложений. Например, при работе с СУБД настраивается пересылка в удалённый ЦОД журналов изменений, которые ведут большинство СУБД. Резервный центр при этом не обслуживает пользователей, однако обязан иметь комплект оборудования и ПО для поддержки соответствующей базы данных нужного объёма, способный успевать вносить в неё изменения по мере поступления журналов из основного центра.

34.32. Для обеспечения катастрофоустойчивости необходимо на резервном ЦОДе иметь вычислительные мощности не ниже используемых на резервируемом ЦОДе.

35. Требования к помещениям и инженерным системам

35.1. Конкретные минимальные требования к помещениям и инженерным системам изложены в КРК.

35.2. Серверные помещения ЦОД I и II уровней должны удовлетворять следующим общим требованиям:

1) запрещается размещать серверные помещения в помещениях, оснащённых большим количеством инженерных сооружений, которые представляют потенциальную опасность для оборудования;

2) запрещается размещать серверные помещения под помещениями столовой, туалетов и других помещений, связанных с потреблением воды;

3) во избежание протечек воды с крыши запрещается размещать серверные помещения на последнем этаже здания;

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

5) необходимо при возможности серверные комнаты располагать в помещении, не имеющем внешних стен здания;

6) необходимо использовать огнеупорные двери на входе в серверное помещение;

7) серверная комната должна быть оснащена достаточным контуром заземления;

8) серверное помещение должно быть без оконных проёмов с глухими стенами. В помещении серверной, а также на пути транспортировки оборудования, ширина дверей должна быть не менее 1100 мм. Высота дверного проёма должна быть не менее 2100 мм;

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

10) физический доступ к серверной комнате должны иметь только уполномоченные сотрудники ИТ-подразделений и обслуживающих организаций;

11) для ограничения физического доступа к серверной комнате должны использоваться автоматизированные системы контроля доступа;

12) для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется, чтобы серверная комната была оснащена источником бесперебойного питания, системой кондиционирования, дизель – генератором, системой регулирования чистоты и влажности воздуха, серверными и телекоммуникационными шкафами (высота шкафа 42 U), стойками,

13) для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется, чтобы серверная комната была оснащена системами контроля состояния внутренней среды – системой раннего дымообнаружения, датчиками доступа, датчиками физического состояния оборудования (разрешается использовать встроенные в оборудование датчики физического состояния), датчиками температуры/влажности, системой видеонаблюдения;

14) в серверной комнате необходимо иметь фальшпол. Фальшпол является необходимым компонентом, т.к. под него нагнетается охлаждённый воздух, под ним располагаются кабели электроснабжения и слаботочная инфраструктура. Рекомендуется фальшпол из МДФ – плиток на металлической основе с ламинированным покрытием или съёмный фальшпол с покрытием «керамогранит» размером 600 х 600 мм. Высота над уровнем пола – от 100 до 800 мм, для серверных помещениях наиболее оптимально 350 – 500 мм. Для распределения потоков холодного воздуха от системы кондиционирования необходимо использовать перфорированные панели;

15) в серверной комнате запрещается использование ковровых покрытий;

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

17) при расчёте площади помещений исходить из СН 512-78 и минимальным размером серверного помещения ширина — 3м, длина 3м и высота 2.6 м. Свободное пространство с лицевой и тыловой сторон 90 см, с боковых сторон 70 см от каждого шкафа, если иного не предусмотрено техническим проектом или рабочей документацией.

35.3. Общие требования к СКС для ЦОД I и II уровней следующие:

1) СКС должна быть спроектирована с избыточностью по количеству подключений;

2) рабочее место должно иметь, как минимум, один разъем для подключения к ЛВС и один разъем для подключения к телефонной сети;

3) максимальная длина кабеля между активным оборудованием не должна превышать 90 м.;

4) СКС должна соответствовать ГОСТ Р 53246-2008 и ГОСТ Р 53245-2008, которые определяют общие требования к основным узлам СКС и методику испытания, соответственно;

5) кабельные компоненты должны быть не менее категории 5е для подключения АРМ, либо оборудования на коммутаторы уровня доступа и не менее категории 6 либо оптических подключений для подключения коммутаторов уровня доступа к коммутаторам уровня распределения и далее;

6) во всех типах ЦОД также должны использоваться кабельные компоненты не менее категории 6;

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

8) СКС должны быть документирована;

9) на СКС должна предоставляться гарантия производителя на работоспособность на срок не менее 5 лет. Подрядчик должен быть сертифицирован производителем и иметь проверенное измерительное оборудование. При проведении приёмочных испытаний подрядчик должен предоставить протоколы тестирования СКС на соответствие установленным нормам.

35.4. Требования к фальшпотолкам и фальшполам для ЦОД I и II уровней следующие:

1) просвет между фальшполом и фальшпотолком должен быть не менее 2500 мм;

2) расстояние между строительным полом и фальшполом должно быть не менее 300 мм. (рекомендуемое 400 мм.);

3) крутизна устанавливаемого на входе в серверное помещение пандуса не должна превышать значение 1:10;

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

5) поверхности под фальшполом должны окрашиваться или герметизироваться для предотвращения отслаивания и пыления штукатурки или бетона перекрытия;

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

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

8) предусмотреть установку вентиляционных решёток и кабельных вводов для телекоммуникационных стоек;

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

10) для усиления прочности предусмотреть установку стрингеров расчётный мощности.

35.5. Общие требования к системе электроснабжения для ЦОД I и II уровней следующие:

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

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

3) при организации питания ПК, периферийных устройств и офисной техники рекомендуется после автоматов в поэтажных щитах устанавливать УЗО согласно действующим нормам;

4) систему электроснабжения для ЦОД I уровня следует организовывать от двух территориально разнесённых трансформаторных подстанций. Кабельные линии должны идти независимыми маршрутами. Требуется использовать АВР, осуществляющие выбор и переключение между основными и резервными линиями;

5) для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется использовать ДЭС. В схеме электроснабжения они должны располагаться параллельно вводам кабелей электропитания в здание. Для правильной работы ДЭС и двух независимых вводов должен быть предусмотрено устройство автоматического включения резервного питания. В случае полного пропадания электропитания, либо несоответствия его требуемым параметрам (напряжение, частота, «чистота») должен осуществляться автоматический запуск ДЭС, и нагрузка переводится на неё. ДЭС должна иметь запас топлива, рассчитанный не менее чем на 8 часов непрерывной работы и возможность пополнения топливом без остановки генератора. ДЭС должны иметь возможность непрерывной работы до 3 месяцев при условии налаженной поставки топлива;

6) для ЦОД I и II уровней после ввода кабелей электропитания в здание или после ДЭС, при её наличии, должны быть установлены централизованные источники бесперебойного питания (ИБП) двойного преобразования.

35.6. Требования к электроснабжению шкафов для ЦОД I и II уровней следующие:

1) к каждому шкафу должно быть подведено питающее напряжение 220±10% В переменного тока от двух независимых источников через индивидуальные автоматические выключатели и при необходимости, 48 В ±5% постоянного тока от двух независимых источников через индивидуальные автоматические выключатели;

2) подключение оборудования, имеющего два блока питания, осуществлять к двум независимым источникам. Подключение оборудования, имеющего один блок питания, осуществлять к одному из источников питания, равномерно распределяя нагрузку в соответствии с энергопотреблением, указанным в паспорте оборудования;

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

35.7. Требования к системам кондиционирования и холодоснабжения для ЦОД I и II уровней следующие:

1) серверные помещения должны быть оборудованы промышленной прецизионной системой кондиционирования и вентиляции (системы холодоснабжения) согласно СП 60.13330.2012;

2) в задачи системы холодоснабжения должно входить поддержание внутри помещения рабочей температуры в пределах от 19 до 24 °С и влажности от 40 до 80%;

3) резервирование системы холодоснабжения ЦОД I уровня обязательно, а для ЦОД II уровня рекомендуется осуществлять по схеме с N+1 (с одним запасным кондиционером). Все кондиционеры должны быть подключены к единой системе управления. Программное обеспечение должно позволять осуществлять ротацию запасного кондиционера, что позволяет более эффективно расходовать ресурс системы холодоснабжения в целом;

4) для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется организовывать приток свежего воздуха с улицы. Приток рекомендуется осуществлять через специальную установку, подготавливающую уличный воздух. Кроме того, она должна создавать внутри помещения дополнительное давление, что препятствует проникновению внутрь пыли;

5) для увлажнения воздуха в ЦОД I и II уровней рекомендуется использовать парогенераторы. Сухой воздух малоэффективен для охлаждения системой хладоснабжения в силу физических принципов кондиционирования. При понижении влажности электростатический потенциал увеличивается, что может быть причиной вывода оборудования из строя;

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

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

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

35.8. Требования к системе раннего обнаружения пожара и газового пожаротушения для ЦОД I и II уровней следующие:

1) ЦОД должны быть оборудованы системой автоматического пожаротушения (ГОСТ 12.1.004–91.ССБТ). Система пожаротушения не должна наносить вред оборудованию;

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

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

4) рекомендуется использовать огнетушащие смеси на основе хладонов либо инертных газов, т.к. они наносят наименьший ущерб оборудованию;

5) требуется предусмотреть систему удаления газа из помещения после срабатывания системы пожаротушения;

6) при срабатывании системы газового пожаротушения должны отключаться все системы нагнетающие воздух в помещение ЦОД.

35.9. Требования к телекоммуникационным шкафам и стойкам для ЦОД I и II уровней следующие:

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

2) для улучшения температурного режима размещение шкафов (стоек) организуют рядами, с образованием «горячих» и «холодных» коридоров. Промежутки между шкафами не допускаются;

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

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

5) закрытые шкафы нуждаются в дополнительных мерах по обеспечению требуемого температурного режима. Для этого применяются дополнительные вентиляторы, встраиваемые системы охлаждения, модули отвода горячего воздуха.

35.10. Требования к комплексным системам безопасности (системы видеонаблюдения и системы разграничения физического доступа) для ЦОД I и II уровней следующие:

1) система видеонаблюдения должна собирать и передавать видеоинформацию в режиме реального времени;

2) система видеонаблюдения должна записывать и воспроизводить цветное изображение;

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

4) должен храниться как минимум недельный архив информации системы доступа в помещения для расследования возможных инцидентов;

5) система разграничения физического доступа должна быть использована система разграничения доступа на основе proximity –карт (стандарт ISO 14443), которая состоит из сервера управления, системы контроллеров и считывателей, а также индивидуальных карт (ключей);

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

35.11. Требования к охранной сигнализации для ЦОД I и II уровней следующие:

1) охранная сигнализация серверного помещения должна быть выполнена отдельно от систем безопасности здания. Сигналы оповещения выводятся в помещение круглосуточной охраны в виде отдельного пульта. Дополнительно сигналы оповещения могут доставляться средствами связи: телефон, СМС, пейджер;

2) контролю и охране подлежат все входы и выходы серверного помещения, объем помещения, оконные проёмы (если есть);

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

35.12. Требования к обеспечению непрерывности предоставления услуг для ЦОД I и II уровней следующие:

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

2) резервному копированию подлежат все настройки активного сетевого оборудования;

3) резервному копированию подлежит вся проектная документация (технический проект, рабочая документация, эксплуатационная документация);

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

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

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

35.13. Для исполнения требований к обеспечению непрерывности предоставления услуг для ЦОД I и II уровней государственным учреждениям и предприятиям Донецкой Народной Республики необходимо иметь план обеспечения непрерывности предоставления услуг и восстановления после аварии. Данный план должен включать в себя следующее пункты, которые необходимы для регламентации работ в области ИТ:

1) перечень внешних и внутренних угроз. К внешним угрозам необходимо отнести техногенные, природные, человеческие и прочие угрозы;

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

3) план должен учитывать определённое целевое время восстановления данных (RTO), которое определяется с точки зрения требований непрерывности к бизнес-процессам.

35.14. В зависимости от RTO план обеспечения непрерывности предоставления услуг и восстановления после аварии должен ранжировать все ресурсы и задачи компании на 3 приоритета:

1) приоритет 1 – задания, которые должны выполняться в соответствии с установленным графиком;

2) приоритет 2 – задания, которые могут выполняться при наличии времени и ресурсов;

3) приоритет 3 – задания, которые не должны выполняться в случае бедствия;

35.15. План обеспечения непрерывности предоставления услуг и восстановления после аварии должен содержать процедуры выполнения следующих функций:

1) ввод в действие процедур для чрезвычайных ситуаций;

2) уведомление сотрудников, поставщиков и заказчиков;

3) формирование группы (групп) восстановления;

4) оценка последствий бедствия;

5) переезд в альтернативное рабочее помещение (помещения);

6) восстановление функционирования критически важных приложений;

7) восстановление основного рабочего помещения;

8) информирование персонала государственных учреждений и предприятий Донецкой Народной Республики о временных способах доступа к информационным ресурсам: телефония, передача данных, местонахождение общих информационных ресурсов компании;

36. Требования к системе управления и мониторинга

36.1. Конкретные минимальные требования к системе управления и мониторинга изложены в КРК.

36.2. Задачи системы управления и мониторинга:

1) повышение эффективности использования ИТ–инфраструктуры;

2) поддержание высокого уровня обслуживания прикладных систем;

3) превентивное решение потенциальных проблем;

4) сокращение потерь из-за простоев при восстановлении данных.

36.3. СУМ ИТ инфраструктуры ЦОД должна удовлетворять следующим требованиям:

1) СУМ должна быть масштабируема в рамках ИТ структуры;

2) СУМ должна обеспечивать мониторинг объектов управления различных типов и производителей в гетерогенной сети;

3) СУМ должна обеспечивать возможность включения в контур мониторинга существующих и проектируемых объектов управления;

4) режим работы СУМ должен совпадать с режимом функционирования объектов управления.

36.4. СУМ ЦОД I и II уровней должна состоять из следующих основных подсистем:

1) подсистема мониторинга и управления распределённой сетью передачи данных и периферийного оборудования;

2) подсистема мониторинга и управления серверными комплексами, операционными системами и приложениями;

3) подсистема мониторинга и администрирования ПК;

4) подсистема мониторинга и администрирования оборудования и процессов резервного копирования.

36.5. СУМ ЦОД I и II уровней должна обеспечивать выполнение следующих функций:

1) удалённый доступ к серверу управления через активные консоли;

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

3) защита доступа к серверу управления по любым вариантам входа в систему со стороны неуполномоченных лиц;

4) разграничение на области компетенции по решению возникающих проблем;

5) различный уровень графического представления информации для различного эксплуатационного персонала, в зависимости от его роли в эксплуатационном процессе;

6) удалённый мониторинг объектов управления;

7) мониторинг контролируемых объектов при помощи агентов;

8) выбор параметров мониторинга и настройка порогов срабатывания агентов, для оценки текущего состояния систем;

9) централизованная регистрация событий, происходящих в контролируемых объектах СПД, операционных системах, СУБД, приложениях, информационных сервисах;

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

11) централизованная обработка всех регистрируемых событий;

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

13) оповещение операторов системы о возникших проблемах посредством выдачи звукового сигнала;

14) при необходимости оповещение операторов системы о возникших проблемах посредством SMS уведомлений на мобильный телефон;

15) анализ производительности работы объектов управления;

16) автоматическая обработка и графическое представление оперативной информации по состоянию информационных сервисов;

17) сбор, хранение и анализ параметров функционирования объектов управления.

18) мониторинг вспомогательных систем ЦОД и состояния среды в серверных помещениях.

36.6. Мониторинг IP–сетей, управления конфигурациями, сбоями, производительностью, а также методы и средства инвентаризации IP–сетей должны быть строго регламентированы и автоматизированы.

36.7. Соответствующая база данных для ЦОД I и II уровней должна содержать полную и достоверную информацию обо всех элементах сети в иерархическом виде с учётом географической иерархии с одной стороны и функциональной иерархии (приложения, IP–сети, базовые сети) с другой.

36.8. Функционально база данных может быть представлена как две взаимодействующие базы данных: инвентаризационная и системы управления событиями в сети.

36.9. Инвентаризационная база данных должна объединять информацию от различных источников и предоставлять её в удобной форме. Требуемый набор информации для включения в инвентаризационную базу данных:

1) о топологии сети и установленном оборудовании в управляемых сетях;

2) актуальные схемы топологии сети;

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

4) полную спецификацию оборудования: текущую версию ПО, заводские и инвентаризационные номера, текущий и предыдущие файлы конфигурации, версию ПО, контактную информацию обслуживающей организации, место установки и ответственные лица;

5) для сетевого оборудования – подробное описание интерфейсов в табличном виде с указанием IP–адресов, VLAN, подключённых сетей или серверов приложений для LAN–интерфейсов, или используемых каналов связи (физических и виртуальных), протоколов маршрутизации и подключённого удалённого оборудования для WAN–интерфейсов;

36.10. Автоматизированная система обработки событий для ЦОД I и II уровней должна обеспечивать:

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

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

3) отображение истории обработки события (кем, когда, какие действия были предприняты);

4) сохранение истории событий по каждому объекту управления;

5) привязку события к объекту, т.е. в инвентаризационной составляющей должна быть ссылка на историю событий объекта и наоборот.

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