48
RAID5: Чередование чётности (Striped parity). В отличии от RAID4 данные и
четность чередуются по всем дискам массива. Очень хорошо иметь дополнительный
вакантный диск (hot spare disk) на случай, если один из дисков массива выйдет из
строя. Минимально три диска в массиве.
RAID6: Двойное чередование чётности (Dual parity). Описание: Похож на
RAID5 с той разницей, что в массиве присутствует два диска контроля четности, что
повышает надежность системы. Минимально четыре диска в массиве.
RAID10. Из групп массивов RAID1 строится RAID0. Считается самым
быстрым и надежным массивом. Повышена надежность сохранности данных.
Массив будет жизнеспособен пока в каждой группе массивов RAID1 будет рабочим
последний диск. Один из самых дорогих вариантов RAID.
RAID50. Из групп массивов RAID5 строится RAID0. Объединение массивов
RAID5 в RAID0 увеличивает пропускную способность данных. Используется в
приложениях, где необходима экономия дискового пространства при сохранении
высокой производительности.
Технология RAID используется на серверах групп WebServer и MS SQL
Server. Для веб-сервера на первом месте производительность дисковой подсистемы,
а для базы данных скорость и надежность ценятся больше всего.
Виртуальные сервера размещены на брендовом оборудовании в надежном
дата-центре, что позволяет обеспечить высокую доступность сервисов. Благодяря
использованию облачного провайдера можно отказаться от крупных
единовременных затрат, связанных с покупкой ресурсов, их размещением и
обеспечением работоспособности (электроснабжение, охлаждение, ремонт и пр.).
Используемые системы хранения данных:
NetApp V6240, 96 дисков*600Gb 10K RPM, 24 дисков*3 Tb 7,2K RPM, 56
дисков FC, 26 дисков SSD, порты доступа: 8*FC 2/4/8Gb для подключения полок,
4*Ethernet 1GbE, 8 * Ethernet 10G. Модули для кэширования: FlashCache 1TB
Серверное оборудование представлено линейкой серверов компании HP:
• HP DL585
• HP DL380
• HP DL360
49
Важным моментом для выполнения требований ФЗ-152 является
использование инфраструктуры с полным набором необходимых
сертифицированных Средств Защиты Информации (далее СЗИ), технических и
административных мер защиты информации задействованных для выполнения
требований Федерального закона "О персональных данных" от 27.07.2006 N 152-ФЗ.
[9]
Рабочие станции сотрудников в компании Открытие Факторинг
стандартизированы, и построены на базе компьютеров компании DELL. Ниже
приведены основные характеристики:
Процессор: Intel Core i3, i5 и i7 восьмого поколения; процессоры Intel Xeon
семейства E-2100; технология Intel Turbo Boost и встроенные графические адаптеры
Intel HD Graphics на некоторых процессорах, опциональная технология vPro.
Операционная система: Windows 10 Pro стандартная, 64-разрядная.
Видеоплата: профессиональные графические платы с поддержкой
двухмерной графики Intel HD Graphics 630.
Оперативная память: 8 Гбайт (2 х 4 Гбайт) памяти DDR4 без ECC
Жесткий диск: 500 Гбайт, 7 200 об/мин, 2,5 дюйма. [10]
50
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Успешным можно назвать проект, в котором от момента запуска системы в
промышленную эксплуатацию, до момента завершения работы системы
соблюдаются следующие требования:
• достаточный набор функций и адаптивность к изменениям к новым
условиям заказчика;
• предсказуемая производительность;
• прогнозируемое и равномерное время обработки каждого запроса;
• высоки уровень доступности системы, с учетом возможных обновлений и
сбоев инфраструктуры;
• понятная эксплуатация и поддержка пользователей ПО;
• обеспечение и соблюдение требований службы информационной
безопасности.
Без хорошего проектного решения и продуманной архитектуры трудно
построить эффективную систему. Эффективность проектирования и реализации
системы подтверждает её производительность при нагрузочный тестах и при
реальной продакшен нагрузке.
Можно выделить три основных области, которые проектировщик должны
учитывать, разрабатывая программные системы:
• проработка объектов и связей между ними, для корректного построения базы
данных;
• пользовательский интерфейс и UX, для простого доступа пользователи к
информации и снижения затрат консультации и поддержку решения в
продакшен среде;
• учет конструкции сетей, баз данных и файловых серверов. Применение
многопоточных и асинхронных паттернов обработки данных.
Любой реальный ИТ проект, создается в определенной среде и должен
учитывать все особенности и ограничения, существующие в этой среде или
компании.
51
Любая методология проектирования или разработка программных продуктов
определяет набор методов и критериев оценки. Ключевые ИТ процессы,
описываемые в каждой методологии: постановка задачи, планирование ресурсов,
мониторинг статуса проекта, контроль сроков и корректности реализации.
Организация труда, идеологические принципы, план и контроль над текущими
процессами определяют основные отличия между методологиями. Выделим 4 вида:
• Waterfall — подразумевает строгое последовательное выполнение всех
этапов, каждый из которых должен завершиться перед началом следующего.
• RUP (Rational Unified Process) — описывает абстрактный общий процесс, на
основе которого организация или проектная команда должна создать
специализированный процесс, ориентированный на ее потребности.
• Agile — серия подходов к разработке программного обеспечения, которая
характеризуется акцентом на людях и их взаимодействии, рабочем продукте,
а также на гибкости и реагировании на изменения.
• Scrum — система разработки ПО, основана на делении всего процесса на
итерации, где в конце каждой из них команда готова предоставить
демоверсию продукта [11].
Немного подробнее остановимся на подходе Scrum. Вся разработка делится на
спринты (зачастую 2-3 недели). Есть backlog(список задач) для всего периода
разработки и для каждого спринта отдельно. Каждая задача имеет свой story point
(оценку сложности).
Модель жизненного цикла ПО при работе по Scrum можно изобразить
следующим образом [12]:
52
Рисунок 12. Спиральная модель разработки ПО
У каждого участника процесса есть своя роль:
• Scrum-команда – это команда, работающая над проектом (разработчики,
тестеры, дизайнеры).
• Scrum-мастер – человек, который следит, чтобы соблюдались принципы
скрама.
• Product owner – заказчик.
Так как в этой системе ставка сделана на общение, то присутствует большое
количество митингов:
• Stand-up – короткий митинг, проводится каждый день, принимают участие все
члены команды, и каждый участник отвечает на 3 вопроса: что делал? Что
будет делать? И какие есть блокеры?
• Планнинг – проводится в начале спринта и на этом собрании определяют
какие задачи должны быть выполнены за следующий спринт.
• Ретроспектива – проводится в конце спринта и её суть – выяснить, что было
сделано хорошо и что можно было улучшить.
53
Одним из общепринятых в отрасли и хорошо себя показавшим вариантов
визуализации потока задач является канбан. В канбане задачи сдаются
индивидуально. Задача независимо от других задач проходит по всем этапам на
доске и как только она выполнена её можно показать заказчику. Канбан доска
состоит из колонок, каждая из которых это отдельный процесс разработки. На
некоторые столбцы (например, in progress) вводят ограничения по количеству тасок,
которые там могут находиться. Это помогает легко и быстро находить проблемные
места в распределении задач.
Рисунок 13. Канбан
Благодаря этому контроль за выполнением становится более гибким, а
разработчики быстрее реагируют на возникающие проблемы. Традиционное
планирование отходит на второй план, его место занимает журнал спринтов.
Именно такой подход Scrum + Kanban принят в отделе разработки ПО компании
Открытие Факторинг [13].
Жизненный цикл программного обеспечения перечисляет все состояния, которые
должен пройти проект, начиная с идеи и высокоуровнего описания концепции и
заканчивая выводом системы из эксплуатации. Модели предлагают разные способы
перехода между этапами жизненного цикла, но все основные этапы учитываются в
каждой модели.
1. Стратегия.
Первым этапом необходимо провести обследование системы, это необходимо
для оценки объема работы и основных категорий затрат на проект. После
обследования мы получаем реальный объема проекта, и понимание его основных
целей и задач, а также определяем сущности, термины и ключевые функции. Чаще
всего обследование делают бизнес-аналитики и ведущие специалисты по
разработке. Открыто общаясь с владельцами системы они собирают основные
артефакты для дальнейшего анализа. Предложенные ими концепции и интерфейсы
54
обсуждаются с пользователями системы, проверяется их понятность и доступность.
Можно выделить два основных подхода к определению стратегии: единоразовый и
цикличный.
2. Анализ
Собранная и проверенная информация о проекте и требования к нему
уточняется и формализуется на этапе анализа. По итогу этого этапа мы получаем
информационную модель, и ключевые документы для дальнейших шагов проекта.
Если область проекта или другие ограничения не позволяют собрать
исчерпывающее описание всех модулей, то цикличный подход может помочь
собрать достаточно требований при переходе на следующий цикл разработки.
Повторный анализ, проведенный после получения реальных данных и первый
версии системы часто оказывается эффективнее чем попытка собрать все требования
на первом цикле анализа. По итогу анализа нужно зафиксировать два вида
артефактов:
• функции, плюс информация о событиях, процессах и сотрудниках;
• сущности, основные объекты предметной области проекта.
Один из подходов, используемый более десяти лет, в настоящее время
утрачивает актуальность, но продолжает поддерживать и развивать существующие
системы. Это подход формализации проекта — Unified Modelling Language (UML),
позволяющий в виде строгой нотации сформировать описание всех функций и
сущностей проектируемой системы. На рынке можно найти большое количество
ПО, реализующего UML, например Rational Rose, Microsoft Visio.
3. Проектирование
Задача этапа проектирования – получение модели данных. Проектировщики
получают входные данные от бизнес-аналитиков и формируют схемы базы данных,
хранилища данных и набор спецификации модулей системы (модель функций).
В небольших проектах группа сотрудников выступает сразу в нескольких
ролях, однако и в этом случае необходимо явно разделять этапы жизненного цикла
и описывать все необходимые результаты каждого этапа. Это повышает качество
проектирования системы и позволяет учесть и исправить многие ошибки на ранних
этапах, которые в противном случае потребовали намного больше ресурсов на
исправление в дальнейшем.
55
Документы, создаваемые проектировщиком, должны соблюдать стандарт или
принятую в компании нотацию. Все аспекты проектируемой системы принято
собирать в спецификацию. Общепринятые подходы к спецификации позволяют
собрать требования и сделать их понятными для различных групп потребителей, от
руководства компании и менеджеров, до разработчиков и сотрудников службы
эксплуатации. UML подход позволяет сформировать иерархию классов уже на этом
этапе.
Задачами проектирования являются:
• проверка полноты проведенного анализа системы;
• проверка конфликтов в требованиях;
• определение критического маршрута проекта, описание рисков и
ограничений;
• определение архитектуры системы;
• анализ возможных интеграций и способов реализации задачи (покупка
модулей ПО, разработка или аутсорс)
• модель базы данных и других вдов хранилищ;
• определение спецификации и средств разработки;
• описание процесса тестирования;
• учет требований информационной безопасности.
4. Реализация
Разработку спецификации можно отнести к стратегическим задачам, а саму
реализацию к тактической. На этапе разработки при тесном общении
проектировщиков, разработчиков и групп тестировщиков решаются основные
вопросы технической реализации и возможности её дальнейшего тестирования. При
активной разработке проектировщик становится сотрудником группы разработки,
выполняя роль выделенного эксперта по процессам и модулям системы.
Важно регулярно проводить демо встречи с заказчиком системы, показывая
текущий прогресс и получая обратную связь, для корректировки дальнейших
планов.
Для перехода на этап тестирования разработанный код должен быть
скомпилирован, собран и развернут на тестовом стенде. Обычно за настройку и
поддержание работы таких систем отвечает системный администратор или DevOps.
56
Важно полностью автоматизировать этот процесс, одним из популярных подходов
является CI\CD, при котором код проходит все необходимые этапы, включая
автоматическое тестирование перед передачей на ручную приемку тестировщиком.
Часто разработка и тестирование идут одновременно, что ускоряет ход проекта, но
добавляет сложности с отслеживанием статуса задач и возвратом их на доработку.
Без системы для отслеживания задач и багов скорость разработки проекта очень
сильно снижается.
5. Тестирование
Тестирование делится на оперативное, когда проверяется одна новая функция
и на комплексное, когда проверяется поведение всей системы или всех бизнес-
процессов в ней. Комплексное тестирование проводится намного реже, но позволяет
проверить работу основных сценариев ПО до ввода новой версии в эксплуатацию. В
отрасли считается стандартом отношение тестировщиков к разработчикам 1 к 3.
В сложных проектах обязательно нужно использовать системы отслеживания
ошибок — bug tracking, которая часто совмещена с системой отслеживания задач.
Такие системы помогают решить множество текущих задач по управлению
командой разработки и сильно автоматизировать работу отдела.
• автономные тесты модулей, unit-тесты которые пишут разработчики;
• функциональные тесты, контролируют связность компонентов;
• системный тест – группа тестов проверяющая работу всех основных
сценариев использования;
• приемосдаточный тест – применяется для передачи системы из отдела
разработки в отдел эксплуатации или заказчику;
• тесты производительности и нагрузки – контролирует соблюдение
требований проектировщика и стабильности системы.
В тесты каждой группы обязательно входят тесты моделирования отказов.
Проверяется реакция сервиса или компонента в условиях сбоя сетей, дисков или
других компонентов. Можно выделить следующие виды такого тестирования:
• отказ отдельного компонента или сервиса;
• ошибка группы сервисов системы;
• отказ основных модулей информационной системы;
• отказ ОС или системных компонентов;
57
• жесткий сбой (отказ питания, сбой при чтении\записи).
На основании результатов этих тестов формируется документ для
оперативного решения и уменьшения негативных последствий сбоев при
промышленной эксплуатации. За проведением и результатами этих тестов должен
следить проектировщик или архитектор системы, как лицо ответственное за систему
в целом.
Дополнительно тестировщики и разработчики создают генераторы тестовых
данных, без которых сложно проверить поведение системы или это будет занимать
большое время. Они используются для проведения тестов функциональности
системы, тестов надежности системы и тестов производительности системы.
6. Внедрение
Опытная эксплуатация обычно вводит систему в работу частично, по модулям
или по сервисам. Постепенно увеличивая количество пользователей или процессов,
за которые отвечает новая система.
Можно выделить три этапа ввода в эксплуатацию:
• стартовая загрузка информации, справочников и списков;
• сбор или миграции информации из предыдущих систем;
• выход на полную нагрузку.
К первому и второму этапу нужно подготовится уже на стадии
проектирования системы, иначе несогласованность данных или их несоответствие
ограничениям в новой системе может сорвать ввод даже в опытную эксплуатацию.
Нужно применить методы контроля качества данных, их валидации и ручной
проверке (в части случаев). Такие ошибки должны быть исправлены как можно
быстрее. Если отладку на реальных или промышленных данных произвести
невозможно (например, по требованиям ИБ), нужно смоделировать их на тестовом
контуре системы.
Выход системы на проектную мощность при успешном соблюдении
этапности и контроле со стороны проектировщика — это формальная настройка
параметров системы, которая не должна быть сложной.
7. Эксплуатация и техническая поддержка
Исчерпывающее описание кейсов, ситуаций и регламент решения проблем —
это ключевой аспект успешной эксплуатации системы. Штатное расписание, учет