---

1.	Методы настройки и сопровождения системного ПО

Системное программное обеспечение (в первую очередь операционная система Windows) управляет аппаратными ресурсами компьютера и обеспечивает среду для выполнения остальных программ.
Основные методы настройки:
Конфигурация системных служб и сервисов:   Осуществляется через оснастку services.msc. Метод заключается в аудите запущенных служб, переводе неиспользуемых сервисов (например, службы удаленного реестра, факсов) в режим запуска «Вручную» или «Отключено» для высвобождения оперативной памяти и повышения безопасности.
Тонкая настройка через системный реестр:   Использование утилиты regedit для изменения скрытых параметров ОС (настройка таймаутов завершения зависших процессов, изменение параметров сетевого стека, отключение неиспользуемых системных компонентов).
Управление автозагрузкой:   Использование «Диспетчера задач» (вкладка «Автозагрузка») или системной утилиты msconfig для исключения программ, замедляющих старт операционной системы.
Оптимизация дисковой подсистемы:   Настройка параметров виртуальной памяти (файла подкачки pagefile.sys), распределение его на наиболее быстрый накопитель (SSD) и фиксация его размера для предотвращения фрагментации.
Методы сопровождения:
Управление обновлениями (Patch Management):   Настройка Центра обновления Windows (через локальные групповые политики gpedit.msc) для контролируемой установки обновлений безопасности и драйверов, исключая сбои системы в рабочее время.
Мониторинг и анализ журналов:   Регулярный аудит системных журналов в консоли «Просмотр событий» (eventvwr.msc). Анализ критических ошибок (Event ID) для предотвращения появления синих экранов смерти (BSOD).
Методы настройки и сопровождения сервисного ПО
Сервисное (утилитарное) ПО предназначено для обслуживания компьютера, диагностики железа и защиты данных.
Основные методы настройки:
Конфигурация систем резервного копирования:   Настройка расписания и правил в программах типа Acronis True Image или *Veeam Agent*. Настройка инкрементного или дифференциального резервного копирования (для экономии места) и выбор целевых хранилищ (сетевые папки, внешние диски).
Настройка систем мониторинга и диагностики:   Конфигурация пороговых значений (например, критической температуры процессора или S.M.A.R.T. параметров жесткого диска) в утилитах *AIDA64* или *HWiNFO* для автоматического оповещения администратора.
Настройка средств оптимизации: Планирование автоматической очистки временных файлов (temp) и дефрагментации/TRIM для накопителей по расписанию.
Методы сопровождения:
Регулярная верификация бэкапов: Периодическое тестовое восстановление данных из созданных архивов на изолированных виртуальных машинах для проверки целостности резервных копий.
Актуализация сигнатурных баз: Конфигурация расписания обновлений для антивирусного ПО и сканеров безопасности.
3. Методы настройки и сопровождения прикладного ПО
Прикладное ПО предназначено для выполнения конкретных пользовательских задач (офисные пакеты, графические редакторы, среды разработки, СУБД).
Основные методы настройки:
Параметризация под аппаратное обеспечение:   Настройка использования аппаратного ускорения (GPU) в тяжелых прикладных программах (например, Photoshop или CAD-системы), выделение фиксированного объема оперативной памяти под нужды конкретного приложения.
Сетевая настройка:   Указание путей к базам данных (например, для 1С или СУБД PostgreSQL/MySQL), настройка портов обмена данными и прокси-серверов в конфигурационных файлах приложения (.ini, .xml, .json).
Профилирование пользовательских сред:   Создание шаблонов, разграничение интерфейсов под роли пользователей, подключение корпоративных словарей и плагинов.
#  Методы сопровождения:
Контроль версий и совместимости:   Разрешение конфликтов динамических библиотек (DLL-hell) путем изоляции компонентов (например, использование локальных манифестов или контейнеризации).
Лицензионный контроль:   Мониторинг ключей активации, своевременное продление коммерческих лицензий и подписок прикладного софта.
Устранение программных сбоев (Troubleshooting):   Сброс поврежденных пользовательских конфигураций, очистка кэша приложений, переустановка поврежденных компонентов или применение официальных хотфиксов (hotfixes) от разработчика.
1.1. Архитектура и принципы технологии Windows Installer
Технология Windows Installer (MSI — Microsoft Installer) представляет собой стандартный интерфейс и службу операционной системы для управления жизненным циклом программного обеспечения: установкой, обновлением, модификацией и полным удалением. В отличие от традиционных скриптовых установщиков (таких как классические EXE-файлы, созданные на базе старых версий InstallShield или null-скриптов), пакет MSI является реляционной базой данных формата базы данных составного файла Microsoft (Structured Storage).
Эта база данных содержит десятки взаимосвязанных таблиц, описывающих:
 Перечень копируемых файлов и структуру каталогов.
 Ключи и параметры реестра, которые необходимо создать или изменить.
 Регистрацию COM-компонентов, библиотек типов и интерфейсов.
 Ярлыки, службы, шрифты и переменные окружения.
 Действия (Actions), выполняемые на различных этапах установки.
Преимущества использования MSI перед исполняемыми файлами сторонних разработчиков (⁠.exe⁠):
1. Транзакционность (Откат изменений): Если в процессе установки происходит критическая ошибка или пользователь отменяет операцию, служба Windows Installer выполняет механизм Rollback. На основе автоматически создаваемого сценария отката система возвращается в исходное состояние: удаляются скопированные файлы, восстанавливаются прежние ключи реестра.
2. Управление состоянием (Self-Healing / Самовосстановление): Если пользователь или стороннее приложение случайно удалит важный компонент программы (например, динамическую библиотеку ⁠.dll⁠), при следующем запуске через ярлык Windows Installer проверит целостность ключевых путей (Key Paths) компонентов и автоматически запустит процесс восстановления, скопировав недостающий файл из исходного дистрибутива или кэша.
3. Корпоративное развертывание (Групповые политики GPO): Пакеты MSI поддерживают тихую установку (Silent Install) без вывода графического интерфейса пользователя и могут централизованно распространяться администраторами домена Active Directory через групповые политики.
4. Стандартизация обновлений: Использование механизмов патчей (⁠.msp⁠) и трансформаций (⁠.mst⁠) для изменения конфигурации без полной пересборки пакета.
1.2. Структура базы данных MSI
Логическая модель MSI базируется на трех основных понятиях:
 Продукт (Product): Верхний уровень абстракции, представляющий собой законченное приложение или группу приложений (имеет уникальный идентификатор ⁠ProductCode⁠).
 Функциональная возможность (Feature): Часть приложения, которую пользователь может выбрать для установки в графическом интерфейсе (например, «Основная программа», «Документация», «Набор плагинов»).
 Компонент (Component): Минимальная неделимая единица атомарной установки. Компонент группирует связанные ресурсы (файлы, ключи реестра, ярлыки). Каждый компонент обязательно имеет один ключевой путь (⁠Key Path⁠), по которому служба инсталляции проверяет его наличие в системе.
Основные таблицы базы данных MSI:
 ⁠File⁠: Список всех файлов, входящих в дистрибутив, с указанием их размера, версии и связей с компонентами.
 ⁠Directory⁠: Иерархическое дерево каталогов целевой файловой системы.
 ⁠Registry⁠: Набор параметров реестра, разносимых по ульям (HKLM, HKCU).
 ⁠Component⁠: Перечень компонентов, их GUID и ключевых путей.
 ⁠Feature⁠: Описание логических блоков для пользовательского интерфейса.
 ⁠FeatureComponents⁠: Таблица связи «многие-ко-многим» между Feature и Component.
 ⁠InstallExecuteSequence⁠: Порядок выполнения стандартных и пользовательских действий в режиме выполнения с повышенными привилегиями.
 ⁠InstallUISequence⁠: Порядок выполнения действий, отвечающих за отрисовку диалоговых окон интерфейса.
1.3. Инструментарий для создания и перепаковки (Repackaging)
Для сборки пакетов MSI стороннего ПО, не имеющего нативного инсталлятора такого формата, применяются два основных подхода:
1. Декларативное описание (Инструментарий WiX Toolset): Свободный набор инструментов, позволяющий создавать пакеты из XML-описаний. Процесс компиляции схож с разработкой ПО: исходный код ⁠.wxs⁠ компилируется утилитой ⁠candle.exe⁠ в объектный файл ⁠.wixobj⁠, а затем связывается линкером ⁠light.exe⁠ в готовый ⁠.msi⁠.
2. Снапшотный метод (Перепаковка через снимок системы): Использование утилит типа Advanced Installer, Advanced Repackager или EMCO MSI Package Builder. Метод заключается в создании «снимка» (Snapshot) чистой операционной системы до запуска инсталлятора стороннего производителя (⁠.exe⁠) и второго снимка — после завершения установки. Утилита сравнивает два состояния файловой системы и реестра, вычленяет изменения и автоматически генерирует проект MSI.
1.4. Практический пример: Разработка проекта в WiX Toolset
Ниже представлен детальный исходный XML-код конфигурации проекта WiX для упаковки сторонней утилиты командной строки:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="A1B2C3D4-E5F6-7A8B-9C0D-1E2F3A4B5C6D" 
             Name="ThirdParty Custom Utility" 
             Language="1049" 
             Version="2.4.1" 
             Manufacturer="External Vendor Corp." 
             UpgradeCode="0F1E2D3C-4B5A-6F7E-8D9C-0B1A2C3D4E5F">
        
        <Package InstallerVersion="200" 
                 Compressed="yes" 
                 InstallScope="perMachine" 
                 Description="Перепакованный пакет утилиты стороннего производителя" 
                 Comments="Сборка выполнена в рамках учебной практики" />

        <MajorUpgrade DowngradeErrorMessage="Более новая версия [ProductName] уже установлена в системе." />
        <MediaTemplate EmbedCab="yes" />

        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder">
                <Directory Id="INSTALLFOLDER" Name="ThirdParty Utility">
                    <Directory Id="BINDIR" Name="bin" />
                    <Directory Id="DOCDIR" Name="docs" />
                </Directory>
            </Directory>
            <Directory Id="ProgramMenuFolder">
                <Directory Id="ApplicationProgramsFolder" Name="ThirdParty Utility"/>
            </Directory>
        </Directory>

        <ComponentGroup Id="ProductComponents" Directory="BINDIR">
            <Component Id="MainExecutableComponent" Guid="11223344-5566-7788-99AA-BBCCDDEEFF00">
                <File Id="MainExe" Source="SourceFiles\utility.exe" KeyPath="yes" />
                <File Id="ConfigJson" Source="SourceFiles\config.json" />
            </Component>
            <Component Id="HelperLibraryComponent" Guid="55667788-99AA-BBCC-DDEE-FF0011223344">
                <File Id="CoreDll" Source="SourceFiles\core.dll" KeyPath="yes" />
            </Component>
        </ComponentGroup>

        <ComponentGroup Id="DocumentationComponents" Directory="DOCDIR">
            <Component Id="ReadmeComponent" Guid="99AABBCC-DDEE-FF00-1122-334455667788">
                <File Id="ReadmeTxt" Source="SourceFiles\readme.txt" KeyPath="yes" />
            </Component>
        </ComponentGroup>

        <DirectoryRef Id="ApplicationProgramsFolder">
            <Component Id="ApplicationShortcut" Guid="AABBCCDD-EEFF-0011-2233-445566778899">
                <Shortcut Id="ApplicationStartMenuShortcut" 
                          Name="Run Custom Utility" 
                          Description="Запуск сторонней утилиты"
                          Target="[BINDIR]utility.exe"
                          WorkingDirectory="BINDIR"/>
                <RemoveFolder Id="CleanUpShortCut" On="uninstall"/>
                <RegistryValue Root="HKLM" 
                               Key="Software\ExternalVendor\CustomUtility" 
                               Name="installed" 
                               Type="integer" 
                               Value="1" 
                               KeyPath="yes"/>
            </Component>
        </DirectoryRef>

        <Feature Id="ProductFeature" Title="Основная программа" Level="1">
            <ComponentGroupRef Id="ProductComponents" />
            <ComponentRef Id="ApplicationShortcut" />
        </Feature>
        
        <Feature Id="DocFeature" Title="Документация" Level="1">
            <ComponentGroupRef Id="DocumentationComponents" />
        </Feature>
    </Product>
</Wix>
Процесс сборки данного пакета через командную строку:
1. ⁠candle.exe project.wxs -out project.wixobj⁠ — синтаксический анализ и генерация промежуточного объектного представления.
2. ⁠light.exe project.wixobj -out CustomUtility.msi⁠ — валидация таблиц баз данных, внедрение бинарных файлов внутрь CAB-архива инсталлятора, создание результирующего MSI-файла.
ГЛАВА 2. ОРГАНИЗАЦИЯ ЗАЩИТЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНЫХ СИСТЕМ
2.1. Классификация угроз безопасности ПО
Защита программного обеспечения на уровне компьютерных систем охватывает защиту программного кода от анализа и реверс-инжиниринга, защиту исполняемой среды от внедрения вредоносного кода, а также управление правами доступа пользователей к программным компонентам.
Угрозы классифицируются по трем направлениям:
1. Нарушение конфиденциальности данных и алгоритмов: Несанкционированный доступ к коммерческой тайне внутри исполняемых модулей (обратная разработка, декомпиляция).
2. Нарушение целостности: Модификация исполняемого кода приложения (патчинг, внедрение инъекций, вредоносных закладок).
3. Нарушение доступности: Использование уязвимостей переполнения буфера или утечек памяти для вызова отказа в обслуживании (DoS).
2.2. Программно-аппаратные методы защиты
Для противодействия угрозам реверс-инжиниринга (особенно актуального для управляемого кода, такого как .NET (C#) или Java, который компилируется в промежуточный байт-код) применяются следующие методы защиты программных продуктов:
Обфускация (Запутывание кода)
Процесс преобразования исходного или байт-кода в форму, сохраняющую функциональность, но крайне сложную для анализа человеком и декомпиляторами. Применяемые алгоритмы обфускации:
 Переименование идентификаторов: Замена осмысленных имен классов, методов и переменных на бессмысленные последовательности (например, ⁠a⁠, ⁠b⁠, ⁠_1⁠).
 Запутывание потока управления (Control Flow Obfuscation): Разбиение линейных алгоритмов на сложные структуры ветвления, внедрение «мертвого» кода, ложных циклов и условных переходов, которые никогда не выполняются, но запутывают граф вызовов декомпилятора.
 Шифрование строк: Скрытие строковых констант (ключей API, путей, сообщений об ошибках) в бинарном файле с помощью алгоритмов XOR, AES. Расшифровка происходит динамически в оперативной памяти непосредственно перед использованием строки.
Применение протекторов кода и упаковщиков
Специализированное ПО (VMProtect, Themida), которое компилирует критически важные участки кода в байт-код уникальной виртуальной машины, интерпретируемой встроенным в протектор движком во время выполнения. Это делает классическую декомпиляцию практически невозможной. Также протекторы внедряют:
 Анти-отладку (Anti-Debugging): Проверка системных API на наличие подключенного отладчика (например, функции ⁠IsDebuggerPresent⁠).
 Анти-дамп (Anti-Dump): Защита от считывания образа программы из оперативной памяти.
2.3. Защита на уровне операционной системы и сетевого окружения
Защита функционирующего ПО внутри компьютерной системы требует правильной настройки системных политик безопасности.
Ограничение прав доступа и списки ACL
Разграничение прав пользователей в файловой системе NTFS осуществляется с помощью списков контроля доступа (ACL — Access Control List). Программные каталоги (⁠C:\Program Files⁠) конфигурируются таким образом, чтобы права на запись и модификацию исполняемых файлов имели только учетные записи с правами ⁠Администратор⁠ или ⁠TrustedInstaller⁠. Обычным учетным записям пользователей делегируются права исключительно на «Чтение и выполнение». Это предотвращает подмену исполняемых файлов и библиотек вредоносными программами.
Использование групповых политик (AppLocker / SRP)
Для предотвращения запуска несанкционированного или потенциально опасного ПО в операционной системе настраивается подсистема AppLocker. Формируются жесткие правила выполнения программ, базирующиеся на:
 Цифровых подписях издателей (Publisher): Разрешается запуск ПО, подписанного доверенными сертификатами (например, Microsoft, Oracle).
 Хэш-суммах файлов (Hash): Блокируется запуск любых модифицированных исполняемых файлов, чья контрольная сумма (SHA-256) не совпадает с эталонной.
 Путях файловой системы (Path): Запрет выполнения исполняемых файлов из пользовательских каталогов с правами на запись, таких как ⁠C:\Users\...\AppData\Local\Temp⁠.
ГЛАВА 3. АНАЛИЗ РИСКОВ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ПРОДУКТА
3.1. Теоретические основы управления рисками
Риск в контексте инженерии программного обеспечения — это вероятностное событие, наступление которого негативно влияет на сроки разработки, стоимость проекта, качество программного кода или эксплуатационные характеристики итогового продукта. Процесс управления рисками регламентируется международными стандартами (например, ISO/IEC 16085) и состоит из четырех циклов: идентификация, качественная/количественная оценка, планирование реагирования, непрерывный мониторинг.
3.2. Качественная оценка и Матрица критичности рисков
Для проведения качественной оценки применяется метод определения двух параметров: Вероятность наступления риска (P) и Степень влияния на проект (I). Оба параметра оцениваются по шкале от 1 (минимальный) до 5 (критический). Общий уровень критичности риска вычисляется как произведение:
R = P x I


Ниже приведена детальная проектная матрица рисков, разработанная в ходе анализа условного программного продукта (информационной системы):
Идентификатор	Категория риска	Описание рискового события	Вероятность (P)	Влияние (I)	Критичность (R)	Стратегия реагирования и превентивные меры (Минимизация)
RSK-01	Технический	Конфликт совместимости со старыми версиями ОС Windows (Win 7/8) при развертывании пакета.	3	4	12	Минимизация: Раннее создание виртуального тестового стенда; использование обратной совместимости API.
RSK-02	Безопасность	Обнаружение критических уязвимостей (0-day) в используемых сторонних Open-Source библиотеках.	4	5	20	Предотвращение: Автоматическое сканирование зависимостей через Snyk/OWASP Dependency Check в CI/CD пайплайне.
RSK-03	Технологический	Ошибки и ограничения выбранного игрового движка (например, Construct 2) при масштабировании логики игры.	2	4	8	Принятие/Обход: Архитектурное разделение графического интерфейса и вычислительной логики для возможности переноса.
RSK-04	Человеческий фактор	Недостаточная квалификация инженеров в области написания безопасных скриптов развертывания (WiX/MSI).	3	3	9	Передача/Обучение: Проведение внутренних технических семинаров, парное программирование, аудит кода старшим инженером.
RSK-05	Управление	Нечетко сформулированные функциональные требования заказчика, приводящие к постоянному изменению ТЗ.	4	4	16	Минимизация: Использование гибких методологий (Agile/Scrum), фиксация спринтов, еженедельные демонстрации прототипов.
 3.3. Планирование реагирования на риски
Разрабатываются четыре основных сценария работы со сквозными рисками:
 1. Уклонение от риска (Avoidance): Изменение плана проекта с целью полной ликвидации угрозы (например, отказ от интеграции нестабильного стороннего модуля).
 2. Минимизация (Mitigation): Снижение вероятности или последствий (например, проведение регулярного рефакторинга кода снижает технический долг).
 3. Передача (Transfer): Перенаправление ответственности третьей стороне (аутсорсинг разработки сложного модуля безопасности специализированной компании).
 4. Принятие (Acceptance): Осознанное решение не предпринимать никаких действий ввиду низкой критичности или экономической нецелесообразности защитных мер (выделяется резервный бюджет времени).
# ГЛАВА 4. ПРОВЕДЕНИЕ ТЕСТИРОВАНИЯ КАЧЕСТВА ПРОГРАММНОГО МОДУЛЯ ПО ОПРЕДЕЛЕННОМУ СЦЕНАРИЮ
 4.1. Методология тестирования программных модулей
Тестирование программного модуля (компонентное тестирование) направлено на верификацию изолированной единицы исходного кода (класса, функции, метода) на соответствие заложенным требованиям. В рамках практики было проведено сценарное функциональное тестирование модуля авторизации и валидации данных пользователей информационной системы методом «черного ящика» (Black Box Testing).
Критерии оценки качества модуля базировались на стандарте ISO/IEC 25010 (функциональная полнота, корректность, защищенность).
 4.2. Разработка сценария и тест-кейсов (Test Cases)
Для полной проверки функционала разработан детальный перечень тест-кейсов, покрывающих как позитивные сценарии использования, так и негативные (ввод некорректных данных, граничные значения).
 Сценарий: Проверка компонента валидации регистрационной формы
# Тест-кейс TC-001 (Позитивный)
 * Название: Валидация корректных учетных данных.
 * Предусловия: Модуль запущен, база данных доступна, учетная запись отсутствует в системе.
 * Шаги выполнения:
   1. Ввести в поле Логин значение: user_2026.
   2. Ввести в поле Email значение: test.user@steeit.ru.
   3. Ввести в поле Пароль значение: P@ssw0rd_Secure!.
   4. Нажать кнопку «Зарегистрироваться».
 * Ожидаемый результат: Модуль возвращает статус Success (Код 201). Данные зашифрованы и успешно внесены в СУБД. Пользователь перенаправлен на страницу личного кабинета.
 * Фактический результат: Статус Success, запись создана.
 * Статус: Пройден (Passed).
# Тест-кейс TC-002 (Негативный — Граничные значения)
 * Название: Проверка минимальной длины пароля.
 * Предусловия: Модуль запущен.
 * Шаги выполнения:
   1. Ввести корректный логин и email.
   2. Ввести в поле Пароль строку длиной 5 символов: 12345.
   3. Нажать кнопку «Зарегистрироваться».
 * Ожидаемый результат: Модуль блокирует отправку формы. Возникает ошибка валидации: «Длина пароля не может быть менее 8 символов». Статус выполнения: ValidationError (Код 400).
 * Фактический результат: Форма заблокирована, отображено корректное сообщение об ошибке.
 * Статус: Пройден (Passed).
# Тест-кейс TC-003 (Негативный — Безопасность / Инъекция)
 * Название: Проверка устойчивости к SQL-инъекциям в поле авторизации.
 * Предусловия: Модуль находится в режиме обработки запросов аутентификации.
 * Шаги выполнения:
   1. В поле Логин ввести строку: ' OR '1'='1.
   2. В поле Пароль ввести: any_string.
   3. Нажать кнопку «Войти».
 * Ожидаемый результат: Запрос обрабатывается как строка. Система выдает ошибку: «Неверный логин или пароль». Не происходит обхода авторизации или падения СУБД. Статус: Unauthorized (Код 401).
 * Фактический результат: Допущена ошибка экранирования символов. Модуль выдал внутреннюю ошибку сервера Internal Server Error (Код 500), раскрыв структуру SQL-запроса в стек-трейсе.
 * Статус: Провален (Failed) — Оформлен Баг-репорт (Дефект зарегистрирован).
 4.3. Регистрация дефектов и регрессионное тестирование
По результатам провала тест-кейса TC-003 был составлен отчет об ошибке (Bug Report) со следующим содержанием:
 * Критичность: Высокая (High).
 * Уязвимость: Небезопасная фильтрация входных данных, приводящая к SQL-инъекции.
 * Локализация: Класс AuthService, метод ValidateUserCredentials().
После исправления программного кода разработчиками (внедрение параметризованных SQL-запросов и ORM-экранирования вместо динамической конкатенации строк) было проведено регрессионное тестирование — повторное выполнение всего набора тест-кейсов (TC-001 – TC-003) для подтверждения исправления дефекта и контроля того, что изменения кода не нарушили работу остальных смежных функций. Повторный прогон зафиксировал статус Passed для всех кейсов.
# ГЛАВА 5. НАСТРОЙКА ОТДЕЛЬНЫХ КОМПОНЕНТ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
 5.1. Архитектура конфигурационных файлов ПО
Современное ПО проектируется в соответствии с принципами слабой связанности (Loose Coupling). Все изменяемые параметры, сетевые адреса, учетные записи и режимы работы выносятся из скомпилированного бинарного кода в текстовые конфигурационные файлы конфигурации. Это позволяет настраивать компоненты приложения под конкретную инфраструктуру без необходимости перекомпиляции исходного кода.
Основные форматы конфигурационных файлов:
 * JSON (JavaScript Object Notation) — популярен в веб-приложениях, Node.js, .NET Core. Поддерживает сложную иерархию и типы данных.
 * XML (Extensible Markup Language) — классический Enterprise-формат, поддерживающий строгую валидацию схем (XSD).
 * YAML / INI — форматы с высокой читаемостью, активно используемые в системном администрировании и конфигурациях CI/CD.
 5.2. Практическая настройка веб-сервера и СУБД приложения
В ходе выполнения работ по развертыванию программного обеспечения компьютерной системы была произведена детальная настройка двух ключевых компонентов: СУБД *PostgreSQL* и бэкенд-модуля приложения.
Ниже представлен пример рабочей конфигурации прикладного модуля (файл appsettings.json), настроенной в процессе прохождения практики:
```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "System.Net.Http": "Error"
    },
    "FileProvider": {
      "Path": "C:\\Logs\\Application\\sys_log.txt",
      "RollingInterval": "Day"
    }
  },
  "ConnectionStrings": {
    "ProductionDatabase": "Server=192.168.10.25;Port=5432;Database=AppProductionDb;User Id=db_app_user;Password=K9$mLx#2pQ!zW;Maximum Pool Size=100;Connection Timeout=30;"
  },
  "ApplicationSettings": {
    "EnableSelfHealing": true,
    "CacheTimeoutMinutes": 15,
    "AllowedHosts": "localhost;192.168.10.*",
    "Security": {
      "MaxLoginAttempts": 5,
      "LockoutDurationSeconds": 900,
      "RequireTwoFactor": false
    }
  }
}

```
 Анализ выполненных настроек конфигурации:
 1. Блок логирования (Logging): Задан уровень детализации Information. Ошибки сетевого стека ограничены уровнем Error во избежание переполнения диска. Настроен ротационный файловый провайдер: логи записываются в каталог C:\Logs\Application\, файлы разделяются посуточно (RollingInterval: Day).
 2. Строка подключения к БД (ConnectionStrings): Задан статический IP-адрес сервера баз данных внутри защищенного периметра (192.168.10.25), стандартный порт PostgreSQL 5432. Пул подключений ограничен значением 100 для предотвращения исчерпания ресурсов ОЗУ сервером баз данных. Время ожидания сессии ограничено 30 секундами.
 3. Безопасность (Security): Ограничено количество попыток неверного ввода пароля (до 5), после чего учетная запись блокируется на 15 минут (900 секунд). Поле AllowedHosts ограничивает обработку входящих сетевых пакетов только локальным хостом и подсетью уровня предприятия.
# ГЛАВА 6. ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ВИДОВ РАБОТ НА ЭТАПЕ ПОДДЕРЖКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНОЙ СИСТЕМЫ
 6.1. Модель жизненного цикла поддержки ПО
Этап поддержки (эксплуатации и сопровождения) является наиболее длительным в жизненном цикле ПО. Согласно стандарту ISO/IEC 14764, сопровождение разделяется на четыре основные категории:
 1. Исправляющее (Corrective): Устранение дефектов и багов, обнаруженных конечными пользователями в процессе эксплуатации продукта.
 2. Адаптирующее (Adaptive): Модификация ПО для сохранения работоспособности при изменении внешних условий (аппаратной части, обновлении ОС, изменении нормативных законов).
 3. Совершенствующее (Perfective): Добавление новых функциональных возможностей по запросам пользователей, улучшение производительности интерфейса.
 4. Профилактическое (Preventive): Нахождение скрытых проблем и оптимизация кода до того, как они приведут к явным сбоям системы.
 6.2. Регламент выполнения работ по поддержке на предприятии
В процессе практики были изучены и практически отработаны следующие технологические процедуры поддержки ИТ-инфраструктуры и программного обеспечения компьютерной системы:
 Работа с системой Service Desk (Обработка инцидентов)
Поступающие от пользователей заявки о сбоях ПО регистрируются в централизованной системе учета. Инженер поддержки выполняет следующий алгоритм:
 * Классификация и определение приоритета: На основе критичности сбоя (например, полная остановка сервиса — приоритет Critical, ошибка опечатки в интерфейсе — приоритет Low).
 * Диагностика: Сбор логов с рабочей станции пользователя (%appdata%/Local/CrashDumps), анализ системных событий Windows.
 * Локализация и обходное решение (Workaround): Предоставление временного решения для восстановления бизнес-процесса пользователя без изменения основного кода (например, очистка кэша, перезапуск службы).
 * Закрытие инцидента: Фиксация решения в базе знаний (Knowledge Base) для ускорения обработки аналогичных инцидентов в будущем.
 Мониторинг производительности и сбор метрик
Поддержка серверных компонент ПО включает непрерывный мониторинг использования системных ресурсов. Для этого настраиваются счетчики производительности (Performance Counters):
 * Процент утилизации ядер центрального процессора (% Processor Time).
 * Объем доступной физической оперативной памяти (Available MBytes).
 * Длина очереди к дисковым накопителям (Avg. Disk Queue Length).
При превышении пороговых значений (например, утилизация CPU > 85% в течение 10 минут) система мониторинга автоматически генерирует оповещение (Alert), сигнализирующее о необходимости проведения оптимизации или горизонтального масштабирования (добавления ресурсов).
 Регламентное резервное копирование и архивация
Обеспечение непрерывности бизнеса требует строгого выполнения графика резервного копирования баз данных и конфигурационных сред прикладного ПО. В рамках регламента поддержки выполняются:
 * Ежедневное инкрементное копирование (сохраняются только изменения за сутки).
 * Еженедельное полное резервное копирование (Full Backup) с выгрузкой архивов на изолированный сервер хранения (отделенный от основной сети сетевым экраном для защиты от вирусов-вымогателей).
# ЗАКЛЮЧЕНИЕ
В результате прохождения учебной практики и выполнения индивидуального задания были детально изучены и практически применены методы инженерии, настройки, защиты и сопровождения программного обеспечения компьютерных систем.
Разработка инсталляционных пакетов формата MSI продемонстрировала важность стандартизации развертывания ПО в корпоративной среде. Полученные навыки качественного анализа рисков и сценарного компонентного тестирования позволяют минимизировать вероятность появления критических ошибок на этапе промышленной эксплуатации программных модулей. Регламентные работы по настройке конфигурационных сред и поддержке инфраструктуры закрепили понимание принципов обеспечения высокой доступности, отказоустойчивости и информационной безопасности современных вычислительных комплексов.