47
виде отчетов, формируемых на основании шаблонов локальных документов
предприятия. Решенной задачей считается закрытая в течение трёх дней заявка в
системе sysa.ls1.ru и комментарий исполнителя в ней.
Все обработанные системными администраторами задачи отображаются в
следующих документах и отчетах:
• Ежемесячный отчёт системного администратора о проделанной по
проекту работе;
• Электронный отчет об обработке задач системными администраторами;
• Статистика выполненных задач системными администраторами;
• Отчёт системного администратора об аварии.
В данном дипломном проекте будет использоваться только локальный
классификатор, так как никаких других классификаторов РФ на предприятии не
используется. Классифицироваться, в свою очередь заявки будут по их
приоритету и категории (типовая, не типовая, консультация). Все обращения
имеют внутренний классификатор. Существуют задачи разного типа сложности,
которые классифицируются согласно внутреннему регламенту компании
следующим образом:
• Задача типа D20 — небольшая задача класса D, на которую, как правило
выделяется не более 20 минут. Может включать в себя настройку
конфигурационного файла, простую установку или обновление ПО в не
более 20 минут. В большинстве случаев типовая, за исключением
консультаций. В день отдел поступает до от 15 до 25 заявок данного
класса.
• Задача типа D — несложная задача, в большинстве случаев типовая, с
трудозатратами не более 1 часа. Как правило может включать в себя
разворачивание виртуальной машины, миграция небольшого проекта с
одного сервер на другой, базовая установка операционной системы,
сложный случай установки или обновления ПО. В день в отдел поступает
от 8 до 12 заявок этого типа.
• Задача типа C — несложная задача среднего класса сложности на
несколько часов. Иногда может включать в себя комплекс типовых задач,
а может заключаться в настройке нетипового сервиса, конфигурации,
проекта. В день регистрируется от 4 до 8 задач такого типа.
48
• Задача типа B – тоже самое, что и задача типа С, однако равная по
трудозатратам от 1 до 3 дней. Не типовая.
• Задача типа A – крупный проект, например перенос высоконагружаемого
проекта на новые серверы, или ввод новой ключевой технологии в
инфраструктуру компании. Не типовая. Может занимать от 3 дней до
нескольких недель по своим трудозатратам.
Для решения поставленной задачи задействованы такие классификаторы
объектов, как: тип задачи, сложность задачи, класс задачи.
49
1.4.2. Обоснование проектных решений по программному обеспечению
Поскольку данный проект должен автоматизировать работу отдела
системного администрирования, обоснование проектных решений по
программному обеспечению будет производиться только в рамках этого отдела
и других отделов и департаментов не касается.
Поскольку большинство серверов, которые обслуживаются отделом
системного администрирования работают на ОС Linux, рекомендуется
использовать именно её. В качестве корпоративного стандартна рекомендуется
использовать ОС Centos для серверов. Для системного администратора крайне
важно администрировать инфраструктуру из аналогичного с инфраструктурой
окружения. Использование в этом случае ОС семейства Windows было бы
неуместным так как придется устанавливать большое количество ПО для
комфортной работы системного администратора. При этом работа всё равно не
будет такой продуктивной, как могла бы быть в Linux. Исходя из этого, на
рабочей станции системного администратора должно быть установлено:
• Операционная 64-разрядная система Linux;
• Современный браузер Chrome или Mozilla Firefox;
• Почтовый клиент, который сможет принимать сообщения с
корпоративного почтового сервера по протоколам IMAP и SMTP.
Большинство сотрудников компании используют Mozilla Thunderbird для
этой цели.
• Интерпретатор языка Python для возможности установки пакета Ansible и
его зависимостей.
• Командная оболочка bash для запуска скриптов.
В качестве системы управления конфигурациями рекомендуется
использовать Ansible. В реалиях работы организации ключевым его
достоинством является отсутствие необходимости установки агентов. Установка
агентов систем управления конфигураций может быть сильно затруднена,
например для старых версий ОС – например для FreeBSD ниже 11 версий или
CentOS версии 6 и ниже. Ansible требует только активированный sshd-сервис на
каждом из обслуживаемых серверов. Таким образом, мы сможем обслуживать
гибридную инфраструктуру с абсолютно разным набором ОС. В случае ООО
«Лайтсофт Рисерч» это FreeBSD и CentOS произвольной версии.
50
В качестве системы контроля версий для хранения результатов работы
системы контроля конфигураций будет использован существующий в
инфраструктуре организации сервер с установленным ПО GitLab.
В качестве систем виртуализации принято решение не изменять текущий
набор ПО и оставить виртуализацию OpenVZ для серверов с ОС CentOS 6, XLC
для серверов с CentOS 7 и Jail для серверов с FreeBSD. После внедрения
данного проекта, от ОС FreeBSD и виртуализации FreeBSD Jail планируется
отказаться, как и от OpenVZ и устаревшей CentOS 6.
В качестве системы автоматизации установки ОС рекомендуется
использовать связку isc-dhcpd вместе с tftpd-сервером и модулем pxelinux. Так
как в компании уже активно используется isc-dhcpd, а текущий сервер имеет
большой запас ресурсов, данную роль может занять этот сервер. При этом будут
задействованы уже существующие в компании серверы и сервисы, что
значительно облегчает выбор.
51
1.4.3. Обоснование проектных решений по техническому обеспечению
Под техническим обеспечением в данном проекте подразумевается
совокупность технических средств, на которых будет выполняться
автоматизация. Для выполнения задач автоматизации системного
администрирования, понадобятся следующие элементы технического
обеспечения:
• Узел управления, - основная ЭВМ, на которой будет развернута система
управления конфигурациями Ansible. На данном сервере будет храниться
актуальная копия конфигурации из системы контроля версий GitLab,
запускаться задачи развертывания, установки и настройки ПО на серверах
и другие задачи, которые автоматизируются в рамках данного проекта.
• Сервер системы контроля версий – сервер с установленным ПО GitLab, на
котором будет храниться актуальная версия конфигураций Ansible.
• Сервер установки ОС – сервер с установленным на нем dhcp, tftpd
сервисами и модулем pxelinux предназначенным для автоматизированной
установки операционной системы на серверы проекта «TopHotels».
• Рабочая станция системного администратора – компьютер, с которого
системный администратор производит решение своих непосредственных
задач и управление инфраструктурой.
• Средства организации ЛВС – техническое обеспечение
работоспособности всех серверов и ПК в локальной сети предприятия.
Данная категория технического обеспечения, как правило делится на
активные элементы (коммутаторы, маршрутизаторы, шлюзы) и пассивные
элементы (кабели, комутационные-панели, розетки)
Для каждого элемента технического обеспечения, необходимо перечислить
наиболее важные критерии.
Для серверов важным критерием помимо характеристик, является его
надежность, так как на них закладываются бизнес-процессы. Подразумевается,
что в случае выделения средств на покупку сервера, срок его службы будет не
менее 3-5 лет непрерывной работы. Также одной из важных характеристик
конфигурации сервера является количество автоматизируемых рабочих мест.
Поскольку в данном проекте автоматизируются не рабочие места, а серверы –
критерием является специфика решаемым сервером задач и количество
52
серверов, которые будут учувствовать в автоматизации. Главными
отличительными особенностями обычного ЭВМ от сервера, как правило
являются:
• Стоечное исполнение 19’’ для монтирование в стойки для оборудование;
• Более высокое качество компонентов по причине более высоких
требований к надежности;
• Комплектующие для серверов являются такими же, как и для обычных
ЭВМ, однако могут иметь другие характеристики. Например, разъемы для
процессора, оперативной памяти, SAS-контроллеры.
• Требование к скорости дисковой подсистеме и как правило, наличие
контроллера RAID.
Поскольку стандартом организации являются серверные платформы от Intel, в
таблице 9 приведена характеристика нужного сервера.
Таблица 9
Серверная платформа Intel
Характеристика
Значение
Платформа
Серверная система Intel R1208WT2GSR
Процессор
Процессор Intel® Xeon® E5-2640 v4
Оперативная память
Два модуля 2133Mhz 32Gb DDR4
Жесткий диск
Четыре диска 1Tb WD Blue
Избыточность
Встроенный в платформу коннтроллер RAID10
Сеть
Два модуля 10GBase-T
Поскольку сервер имеет больше ресурсов, чем необходимо для реализации
проекта, он будет разделен на виртуальные серверы, в которых смогут
разместиться система управления конфигурациями Ansible, сервер контроля в
версий и сервер установки ОС.
Поскольку предприятие имеет на складе запасные серверы, покупка данного
сервера не требуется.
Для рабочей станции системного администратора главным критерием
является наличие современной конфигурации и следование стандартам
предприятия. Так как системные администраторы участвуют в важном процессе,
их рабочие станции должны работать быстро и без задержек. Должна быть
53
возможность запуска нескольких локальных виртуальных машин для
тестирования ПО, возможность работы в браузере с большим количеством
открытых вкладок браузера для чтения документации и поиска информации. Для
рабочих станций для системных администраторов ООО «Лайтсофт Рисерч»
покупает компьютеры, описанные в таблице 10.
Таблица 10
Рабочая станция системного администратора
Характеристика
Значение
Корпус
Codegen SuperPower Q3337-A11 или аналог
Процессор
Intel Core i7-8700, OEM
Материнская плата
GIGABYTE Z370 HD3
Система охлаждения
кулер Zalman CNPS7X LED
Оперативная память
32ГБ Kingston HyperX Fury Black, HX424C15FBK2/32
Жесткий диск
SSD 240ГБ, Toshiba TR200, THN-TR20Z2400U8
Сеть
Встроенная в материнскую плату
54
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Под жизненным циклом (ЖЦ) любого проекта подразумевается некоторая
последовательность фаз разрабатываемого проекта, которая задается в
соответствии с потребностью управления проектом. Представляет собой
структуру, содержащую такие элементы, как структуру, процессы, задачи и
фазы, которые осуществляются в процессе разработки, внедрения и
сопровождения проекта на протяжении всего его жизненного цикла. Существует
некоторое количество стандартов, которые описывают процессы жизненного
цикла проекта[7].
Среди наиболее распространенных стандартов рекомендуется выделить
следующие:
• ГОСТ 34.601-90 – наиболее распространенный стандарт, используемый в
Российской Федерации для разработки программного обеспечение.
Необходимо подметить, что в данном стандарте содержится описание
содержания работ на каждом из этапов. Все этапы работ, описанные в
стандарте, в соответствуют каскадной модели жизненного цикла[3].
• ГОСТ Р ИСО/МЭК 12207-2010 – наиболее распространенный стандарт
для организации жизненного цикла программного средства.
Распространяется на все виды заказного ПО. Стандарт не содержит
описания фаз, стадий и этапов, однако содержит рекомендации по их
созданию[2].
• ГОСТ Р 57193–2016 – аналог ГОСТ Р ИСО/МЭК 12207-2010, стандарт
для организации жизненного цикла ИС, отличается от предыдущего
нацеленностью на рассмотрение программно-аппаратных систем в целом,
а не программных средств. Используется взамен устаревшего ГОСТ Р
ИСО/МЭК 15288-2005 и является его обновленным и дополненным
вариантом[1].
• Custom Development Method или Oracle CDM – стандарт разработанный
корпораций Oracle, созданный для проектов, использующих продукты
Oracle. Применяется для классической модели ЖЦ проекта, имеет все
55
общепринятые этапы проектирования и разработки. Рекомендуется для
небольших проектов[6].
• Rational Unified Process (RUP) – стандарт, предлагающий итеративную
модель разработки, который включает основные фазы: начало проекта,
исследование задачи, реализация (например, программирование) и
последующее внедрение проекта. Интересной особенностью является то,
что все описанные фазы могут разбиваться на подэтапы, на которых
выпускаются промежуточные версии. Прохождение всех этапов
подразумевает завершенный разработанный продукт. Если этого не
происходит, то полученный результат в процессе работы проходит те же
фазы. Неотъемлемой частью UML является сопровождение моделей на
базе UML[17].
• Microsoft Solution Framework (MSF) стандарт от корпорации Майкрософт,
по своей концепции схожий с RUP, по аналогии с ним включаяя четыре
фазы: анализ, проектирование, разработка и стабилизация. Является
итерационной, предполагает использование объектно-ориентированного
моделирования. Главное отличие MSF от RUP в том, что она главным
образом ориентирована на разработку бизнес-приложений[16].
• Extreme Programming (XP) или экстремальное программирование. В
основе метода лежит главным образом командная работа, эффективная
коммуникация между заказчиком и исполнителем в течение всей
разработки ИС. Сама разработка заключается в постоянной доработке
существующих прототипов, когда заказчик комментирует результаты
работы, а разработчики делают доработки до получения результата,
который устроит заказчика[5].
Основными критериями для выбора стандарта ЖЦ в данном проекте будут:
• Актуальность стандарта в разрезе быстроразвивающихся технологий;
Стандарт должен учитывать все реалии современных информационных
технологий (ИТ);
• Стандарт должен учитывать не только ЖЦ ПО, а ещё и смежных систем и
продуктов, например таких, как данный проект автоматизации
инфраструктуры, который включает написание программного кода, но не
является окончательной целью проекта;
56
• Стандарт должен быть достаточно гибким, чтобы позволить
сформировать собственные этапы жизненного цикла, иметь возможность
сделать акцент на более нужных проекту этапах, а менее нужные
исключить или подойти к ним с меньшими затратами ресурсов.
Резюмируя описанные выше стандарты, практически все из них не подходят для
данного проекта, так как нацелены в основном на разработку программного
обеспечения. Написание программного кода с дальнейшей эксплуатацией
программы является конечной целью большинства описанных выше стандартов.
Исходя из описанного, для данного дипломного проекта было решено выбрать
стандарт ГОСТ Р 57193–2016 так как он является одним из наиболее
распространенных является аналогос ГОСТ Р ИСО/МЭК 12207-2010[1], являясь
его аналогом, но позволяющим также быть применимым к проекту
автоматизации инфраструктуры, который не является только разработкой ПО.
Данный стандарт не ставит четкие рамки названий этапов жизненного цикла, а
рекомендует их, что также подходит под критерии выбора стандарта ЖЦ ИС.
Рекомендуемые этапы стандартом этапы изображены на рисунке 7.
Анализ требований (замысел). Включает в себя подэтапы:
• Предпроектное обследование и анализ данных:
o Анализ работы веб-проекта «TopHotels» и его архитектуры;
o Анализ стратегии развития проекта «TopHotels»;
o Определение самых ресурсоемких рутинных задач системных
администраторов которые необходимо автоматизировать;
o Поиск и анализ подходящих программных продуктов и решений,
которые будут участвовать в проекте;
• Сбор материалов для проектирования, при этом выдвигаются требования
для проекта; изучается объект автоматизации, даются предварительные
выводы предпроектного варианта ИС;
• Анализ имеющихся документов проекта, разработка документации,
делается технико-экономическое обоснование с техническим заданием на
проектирование ИС.
Основной целью данного этапа и его подэтапов является сбор всей необходимой
информации для выполнения замысла – в данном случае проекта автоматизации.
Это необходимо для того, чтобы во время проектирования были все