Информационные системы: основы, проектирование и эксплуатация

Понятие и классификация информационных систем

Зачем разбираться в понятии и классификации

В курсе «Информационные системы: основы, проектирование и эксплуатация» мы будем проходить весь путь: от понимания, что такое информационная система, до принципов её проектирования и эксплуатации. Чтобы обсуждать требования, архитектуру, безопасность и сопровождение, важно сначала договориться о базовых терминах и научиться различать типы информационных систем.

Классификация нужна, чтобы:

корректно формулировать требования (например, к доступности и скорости отклика)

выбирать архитектурный подход (централизованный, распределённый, облачный)

понимать ограничения и риски эксплуатации (резервное копирование, обновления, регламенты)

сравнивать решения (например, ERP против CRM, OLTP против аналитики)

Базовые понятия

Данные и информация

Данные — это зафиксированные факты (числа, строки, события), которые сами по себе могут быть неинтерпретируемы.

Информация — это данные, которые поняты в контексте и помогают принимать решения.

Пример:

данные: 2026-02-04, 120, RUB

информация: «04.02.2026 продажа составила 120 рублей»

Система

Система — это набор взаимосвязанных элементов, которые совместно достигают некоторой цели. У системы обычно есть:

цель (что должно быть достигнуто)

граница (что относится к системе, а что — к внешней среде)

входы и выходы (что получает и что выдаёт)

правила взаимодействия элементов

Информационные технологии и информационная система

Информационные технологии (ИТ) — это методы и средства обработки информации (программное обеспечение, серверы, сети, базы данных).

Информационная система (ИС) шире, чем ИТ: она включает не только технологии, но и людей, процессы и правила.

Полезная отправная точка для общего понимания: Информационная система (Википедия)

Понятие информационной системы

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

Важно: ИС существует не ради самой технологии, а ради поддержки деятельности — управления, обслуживания клиентов, производства, логистики, аналитики, обучения и т.д.

Граница информационной системы

При описании ИС полезно явно фиксировать, что входит в систему, а что относится к внешней среде.

Внутри границы ИС обычно находятся:

регламенты и бизнес-процессы (как выполняется работа)

персонал и роли (кто и что делает)

данные и правила их качества

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

инфраструктура (серверы, рабочие места, сеть)

меры защиты (учётные записи, права доступа, аудит)

Снаружи могут быть:

клиенты и партнёры

государственные системы

платёжные провайдеры

внешние справочники и источники данных

Состав и функции информационной системы

Типовые компоненты ИС

Люди: пользователи, администраторы, аналитики, разработчики, владельцы процессов.

Процессы: последовательности действий (например, оформление заказа, согласование договора).

Данные: справочники, документы, транзакции, журналы событий.

Программное обеспечение: прикладные модули, интеграционные сервисы, СУБД.

Аппаратное обеспечение и сеть: серверы, рабочие станции, каналы связи.

Правила и политика: инструкции, требования безопасности, модели доступа.

Базовые функции ИС

Ввод: получение данных (формы, датчики, интеграции).

Обработка: расчёты, проверки, маршрутизация, согласования.

Хранение: базы данных, архивы, резервные копии.

Вывод: отчёты, уведомления, API, выгрузки.

Контроль и обратная связь: журналирование, мониторинг, аудит.

!Схема показывает состав ИС и её взаимодействие с внешней средой

Классификация информационных систем

Классификация — это разбиение ИС на группы по признакам. В реальности одна система почти всегда попадает сразу в несколько категорий (например, корпоративная облачная CRM с веб-интерфейсом и интеграцией по API).

По назначению (для какой задачи)

Операционные (транзакционные): поддерживают ежедневные операции (продажи, склад, платежи).

Управленческие: поддерживают планирование, контроль, KPI, отчётность.

Аналитические: ориентированы на анализ данных и поиск закономерностей.

Справочные: предоставляют доступ к нормативной или справочной информации.

Документооборот и ECM: управление документами, версиями, согласованиями.

Коммуникационные и коллаборационные: совместная работа, заявки, знания.

По уровню управления (кому помогает принимать решения)

Оперативный уровень: исполнители и линейные руководители (быстро, много операций).

Тактический уровень: руководители подразделений (планирование на недели/месяцы).

Стратегический уровень: высшее руководство (обобщение, прогнозирование, сценарии).

По масштабу и охвату

Персональные: для одного пользователя или небольшой группы.

Групповые: для отдела или проекта.

Корпоративные: для всей организации.

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

По архитектуре и способу построения

Централизованные: основные ресурсы и данные сосредоточены в одном центре.

Распределённые: компоненты разнесены, возможны несколько узлов обработки.

Клиент-серверные: клиентское приложение + сервер приложения/БД.

Микросервисные: множество небольших сервисов с чёткими контрактами.

Сервис-ориентированные: функциональность предоставляется как набор сервисов.

По размещению и владению инфраструктурой

On-premise: размещение на инфраструктуре организации.

Облачные (cloud): размещение у провайдера.

Гибридные: часть компонентов в облаке, часть — внутри организации.

По режиму обработки данных

Пакетные (batch): обработка порциями по расписанию (например, ночные расчёты).

Интерактивные: пользователь получает результат сразу.

Потоковые (streaming): обработка событий по мере поступления (телеметрия, клики).

По степени интеграции

Автономные: минимальные связи с другими системами.

Интегрированные: обмениваются данными с другими ИС (шины, API, очереди).

По критичности и требованиям к доступности

Критически важные: простой приводит к существенным потерям или рискам.

Некритичные: допускают более длительные окна недоступности.

Этот признак особенно важен для эксплуатации: от него зависят резервирование, мониторинг, регламенты изменений и требования к восстановлению.

Примеры распространённых классов ИС

| Класс | Для чего обычно используется | Пример результата работы | |---|---|---| | ERP | управление ресурсами предприятия (финансы, закупки, производство) | план закупок, себестоимость, баланс | | CRM | управление взаимодействием с клиентами | воронка продаж, история контактов | | WMS | управление складом | адресное хранение, подбор заказов | | HRM | управление персоналом | штатное расписание, отпуска | | BI / DWH | аналитика и витрины данных | dashboards, управленческая отчётность | | ECM/СЭД | документы и согласования | маршруты согласования, архив |

Как применять классификацию на практике

Чтобы корректно описать систему в проекте (и не спорить на уровне терминов), полезно фиксировать её паспорт по нескольким критериям:

назначение (операционная, аналитическая, смешанная)

охват (отдел, компания, группа компаний)

размещение (on-premise, облако, гибрид)

интеграции (с чем и как обменивается данными)

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

В следующих материалах курса это станет основой для:

выбора архитектуры и модели данных

определения требований к безопасности и доступам

планирования эксплуатации (мониторинг, бэкапы, обновления)

Итоги

Информационная система включает людей, процессы, данные, технологии и правила.

ИС создаётся для поддержки целей деятельности: операций, управления и анализа.

Классификация ИС многомерна: одну и ту же систему можно описать сразу по нескольким признакам.

Правильно выбранные признаки классификации упрощают проектирование и эксплуатацию: от требований к доступности до интеграций и регламентов.

Архитектура ИС: компоненты, интеграция и API

Зачем нужна архитектура, если мы уже разобрали «что такое ИС»

В предыдущей статье мы договорились, что информационная система (ИС) — это не только программный код, но и люди, процессы, данные, инфраструктура и правила. Архитектура в этом контексте — способ упорядочить ИС так, чтобы:

она решала задачи бизнеса (а не просто «работала»)

её можно было развивать без постоянных переделок

интеграции с другими системами были предсказуемыми

эксплуатация была управляемой (мониторинг, обновления, масштабирование)

В рамках курса это мост между «классификацией ИС» и практическими темами проектирования/эксплуатации.

Что такое архитектура ИС

Архитектура ИС — это набор ключевых решений о структуре системы: из каких частей она состоит, как эти части взаимодействуют, где хранятся данные, как система масштабируется и как обеспечиваются безопасность и надёжность.

Архитектура обычно фиксируется через:

компоненты (приложения, сервисы, базы данных, брокеры сообщений)

интерфейсы взаимодействия (API, очереди, файлы, интеграционные шины)

правила и ограничения (например, «в БД нельзя ходить напрямую, только через сервис»)

нефункциональные требования (доступность, задержки, безопасность)

Типовые компоненты информационной системы

Пользовательские интерфейсы

Это всё, через что пользователь взаимодействует с ИС:

веб-приложение

мобильное приложение

рабочее место оператора (desktop)

интеграционный клиент (например, другая система, вызывающая API)

Ключевая задача UI — корректно собрать ввод, показать результат и не «протаскивать» в интерфейс сложность внутреннего устройства системы.

Прикладная логика

Прикладная логика реализует правила предметной области:

расчёты и проверки (например, скидки, лимиты)

маршруты согласований

обработка статусов (заказ создан, оплачен, отгружен)

Часто прикладную логику выделяют в отдельный слой или сервисы, чтобы не смешивать её с UI и хранением данных.

Данные и хранилища

Хранилища отвечают за сохранность и доступность данных:

реляционные базы данных для транзакций

документо-ориентированные хранилища для гибких структур

поисковые индексы для быстрого поиска

аналитические хранилища (DWH) для отчётности

Важно помнить, что «данные» — это не только таблицы. Это ещё и:

справочники

журналы событий (логи)

аудит действий

версии документов

Интеграционный контур

Это всё, что соединяет систему с внешней средой или внутренними соседними системами:

API (HTTP, gRPC)

очереди и брокеры сообщений

файловые обмены

интеграционные платформы и шины

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

Безопасность и управление доступом

Безопасность — не отдельная «надстройка», а сквозной компонент:

аутентификация (кто ты)

авторизация (что тебе можно)

аудит (что ты сделал)

защита каналов (например, TLS)

Технологии и стандарты часто встречаются такие:

OAuth 2.0 (RFC 6749)

OpenID Connect

Эксплуатационные компоненты

Чтобы система была управляемой в продакшене, нужны:

мониторинг и метрики

централизованные логи

трассировка запросов между сервисами

управление конфигурацией и секретами

Эти элементы важны даже для небольшой ИС, если она критична по доступности.

!Компонентная схема: UI, API, сервисы, базы данных и интеграции

Слоистая архитектура и архитектурные стили

Слои (layers): простой способ навести порядок

Часто ИС делят на слои, чтобы изолировать изменения:

слой представления (UI)

слой прикладной логики (use cases)

слой доступа к данным (репозитории/DAO)

инфраструктурный слой (сеть, драйверы, внешние API)

Плюс подхода: понятные границы. Минус: при росте системы слои могут превратиться в «монолит с правилами», где изменения всё равно затрагивают многие части.

Монолит и модульный монолит

Монолит — одно развертываемое приложение. Это не «плохо» само по себе: монолит часто проще разрабатывать и эксплуатировать.

Модульный монолит — монолит, внутри которого жёстко выделены модули и запрещены прямые связи «в обход правил». Это часто хорошая ступень до микросервисов.

Микросервисы

Микросервисная архитектура — система как набор небольших сервисов, которые общаются по контрактам (API/события) и разворачиваются независимо.

Плюсы:

независимое масштабирование и релизы

локализация ответственности (команда/сервис)

Риски:

сложнее интеграция и наблюдаемость

больше требований к дисциплине контрактов и совместимости

Полезное чтение по стилю и компромиссам:

Microservices (Martin Fowler)

Интеграция: зачем и почему она часто сложнее разработки

Интеграция нужна, когда одна ИС не живёт в вакууме. Типовые причины:

общий клиент и его справочники (CRM ↔ ERP)

финансовые операции (кассы, банки, платёжные шлюзы)

государственные системы

аналитика (операционные ИС → DWH/BI)

Сложность интеграции обычно связана не с протоколом, а с:

различием моделей данных (в одной системе «клиент», в другой «контрагент»)

разными правилами качества данных

разной скоростью изменений (одна система обновляется раз в год)

требованиями безопасности и аудита

Способы интеграции

#### Синхронная интеграция (request-response)

Пример: сервис A вызывает API сервиса B и ждёт ответ.

плюсы: просто понять, легко отладить

минусы: зависимость по доступности и задержкам (если B «лежит», A тоже страдает)

#### Асинхронная интеграция (сообщения и события)

Пример: сервис A публикует событие «ЗаказОплачен», сервис B обрабатывает его позже.

плюсы: слабее связность, лучше устойчивость к временным сбоям

минусы: сложнее наблюдаемость, появляются «временные расхождения» в данных

!Сравнение request-response и event-driven интеграции

#### Файловый обмен

Иногда это до сих пор разумный выбор:

регулярные выгрузки/загрузки

интеграции с устаревшими системами

Но он требует дисциплины по форматам, версиям и контролю доставки.

API как контракт между компонентами

Что такое API

API — это формализованный интерфейс, через который один компонент системы предоставляет функции и данные другим компонентам.

Практически API — это:

адрес (endpoint) или канал (topic/queue)

формат данных (JSON, Protobuf)

правила (поля обязательны/необязательны, коды ошибок)

требования безопасности (токены, роли)

Основные стили API

#### REST поверх HTTP

REST часто используют для интеграции «снаружи» и для веб/мобайла.

Опираться полезно на базовые свойства HTTP:

методы (GET, POST, PUT, DELETE)

коды ответов (200, 400, 401, 404, 409, 500)

заголовки, кеширование

Справочник по HTTP:

MDN: Обзор HTTP

#### RPC/gRPC

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

gRPC

#### Событийные API

Здесь «контракт» — это структура события и правила публикации/подписки.

AsyncAPI

Документирование и описание API

Чтобы интеграции были воспроизводимыми, API описывают машинно-читаемо.

для REST-подобных HTTP API часто используют OpenAPI Specification

Это помогает:

генерировать клиентские SDK

автоматически проверять контракты

поддерживать единый каталог интерфейсов

Практика проектирования API: ключевые правила

Делайте контракт явным и стабильным

Хороший контракт:

фиксирует обязательные поля и допустимые значения

определяет форматы дат, денег, идентификаторов

описывает ошибки так же строго, как успешные ответы

Плохой контракт:

«возвращаем как получится, потом договоримся»

зависит от случайного порядка полей

требует «угадать», почему пришла ошибка

Версионирование

Когда API меняется, важно не сломать потребителей.

Типовые стратегии:

версионирование в URL (например, /v1/...)

версионирование через заголовки (реже, но бывает)

расширение без ломки (добавили поле — старые клиенты игнорируют)

Ломающие изменения требуют отдельной версии и плана миграции.

Идемпотентность и повторы

В распределённых системах запросы могут повторяться из-за таймаутов и ретраев.

Практический вывод:

операции создания/оплаты часто должны выдерживать повтор (например, через Idempotency-Key)

асинхронные обработчики событий должны быть готовы к дублям

Безопасность API

Минимальный набор, который стоит предусмотреть:

аутентификация (например, OAuth2)

авторизация (роли/права)

ограничение частоты запросов (rate limiting)

журналирование действий (кто, когда, что запросил)

Наблюдаемость интеграций

Чтобы поддерживать API в эксплуатации, нужны:

корреляционные идентификаторы запросов (один request_id через все сервисы)

метрики по ошибкам и задержкам

трассировка цепочек вызовов

Иначе типичная ситуация выглядит так: «у нас всё зелёное», но пользователи жалуются, а найти источник долго.

Частые архитектурные ошибки в интеграциях

прямой доступ к базе данных другого приложения вместо API

«общая БД на всех» без владельца данных

отсутствие единого владельца справочников (каждый ведёт клиентов по-своему)

смешивание синхронных и асинхронных процессов без понятных границ

отсутствие стратегии версионирования и обратной совместимости

Итоги

Архитектура ИС описывает ключевые решения о компонентах и их взаимодействии.

Интеграция бывает синхронной и асинхронной; выбор влияет на устойчивость и сложность.

API — это контракт, который нужно документировать, версионировать и защищать.

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

Данные в ИС: модели, базы данных и хранилища

Зачем в курсе отдельно говорить о данных

В первых статьях мы определили, что информационная система — это люди, процессы, технологии и правила, а архитектура задаёт, как компоненты взаимодействуют и интегрируются через API. Почти во всех этих вопросах в центре находятся данные:

данные определяют, что именно система «знает» о предметной области

модель данных определяет границы сервисов и контрактов API

качество, целостность и доступность данных определяют надёжность работы ИС

способ хранения данных влияет на производительность, масштабирование и эксплуатацию

Эта статья даёт базу, чтобы дальше уверенно обсуждать проектирование, интеграции, отчётность и эксплуатационные практики.

Что такое данные в ИС

Данные в ИС — это формализованное представление объектов и событий предметной области.

объект: клиент, товар, сотрудник, договор

событие: заказ создан, оплата получена, товар отгружен

Важно различать:

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

аналитические данные: нужны для анализа и принятия решений (динамика продаж, маржинальность)

метаданные: данные о данных (описания таблиц, схем, владельцы, источники)

Модели данных

Концептуальная модель

Это описание предметной области «человеческим языком», без привязки к СУБД:

какие сущности есть (Клиент, Заказ, Платёж)

какие атрибуты у сущностей (email, дата заказа)

какие связи между сущностями (у Клиента много Заказов)

Концептуальная модель помогает согласовать смысл с бизнесом и снижает риск «не те данные храним».

Логическая модель

Это уточнение концептуальной модели до структуры, близкой к таблицам и связям:

ключи и уникальность (например, email уникален)

связи и обязательность (заказ не может существовать без клиента)

домены значений (статусы заказа из фиксированного набора)

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

Физическая модель

Это реализация в конкретной технологии:

конкретные таблицы, индексы, партиции

типы данных (например, timestamp, numeric)

настройки хранения, репликации, шифрования

Физическая модель напрямую связана с эксплуатацией: бэкапы, рост объёма, миграции схемы.

!Три уровня модели данных и связь между ними

Базы данных и СУБД

База данных — организованное хранилище данных.

СУБД (система управления базами данных) — программная система, которая обеспечивает:

чтение и запись

параллельный доступ пользователей

целостность данных (правила, ограничения)

резервное копирование и восстановление

безопасность доступа

На практике выбор СУБД — архитектурное решение: оно влияет на интеграции, SLA, стоимость владения и требования к компетенциям команды.

Реляционные базы данных

Когда они подходят

Реляционные БД полезны, когда:

данные хорошо укладываются в таблицы и связи

нужна строгая целостность (например, финансовые операции)

важны транзакции и согласованность

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

Таблицы, ключи и связи

Базовые элементы:

таблица — набор строк (записей) и столбцов (полей)

первичный ключ — поле (или набор полей), уникально идентифицирующее запись

внешний ключ — ссылка на запись в другой таблице

Целостность обеспечивается ограничениями:

NOT NULL — поле обязательно

UNIQUE — значение уникально

CHECK — проверка правила (например, сумма не отрицательная)

FOREIGN KEY — запрет «висячих ссылок»

Справка по ограничениям на примере PostgreSQL: PostgreSQL: Constraints

Нормализация: идея без углубления в формальные формы

Нормализация — подход к проектированию таблиц, уменьшающий дублирование и аномалии обновления.

Практическая мысль:

если одно и то же значение хранится в десяти местах, вы неизбежно получите рассинхронизацию

справочники (например, Клиенты) обычно выделяют отдельно и связывают с документами (Заказы)

При этом нормализация не «религия»: иногда ради производительности часть данных осознанно дублируют, но тогда вводят правила синхронизации.

Индексы

Индекс ускоряет поиск, но замедляет вставку/обновление и увеличивает занимаемое место.

Типовые случаи, когда индекс почти всегда нужен:

поиск по идентификатору

частые фильтры по дате/статусу

внешние ключи (для ускорения соединений)

Транзакции и ACID

Транзакция — группа операций, которая должна выполниться как единое целое.

Набор свойств ACID обычно объясняют так:

Atomicity (атомарность): либо выполнится всё, либо ничего

Consistency (согласованность): после транзакции данные удовлетворяют правилам и ограничениям

Isolation (изоляция): параллельные операции не мешают друг другу так, чтобы ломать смысл

Durability (надёжность): после подтверждения результат не пропадает при сбоях

Документация по транзакциям на примере PostgreSQL: PostgreSQL: Transactions

NoSQL: нереляционные хранилища

Термин NoSQL объединяет разные подходы. Общая идея: больше гибкости по модели данных и масштабированию, но часто меньше «строгих гарантий из коробки», чем в классических реляционных БД.

Документные базы

Хранят данные как документы (часто JSON-подобные структуры). Подходят, когда:

у объектов много полей, и они часто меняются

структура может различаться между записями

нужны быстрые чтения «как есть», без сложных соединений

Пример: профили пользователей с разным набором атрибутов.

Справка: MongoDB: Documents

Key-value

Модель «ключ → значение». Часто используется для:

кэшей

сессий

быстрых счётчиков

Колонночные (wide-column)

Оптимизированы для больших объёмов и распределённого хранения, часто применяются для телеметрии и событий.

Графовые базы

Сильны там, где главное — связи и обход графа:

социальные связи

рекомендации

выявление цепочек зависимостей

Операционные и аналитические контуры данных

OLTP и OLAP

Обычно выделяют два типа нагрузок:

OLTP (операционная обработка): много коротких операций, важна скорость и корректность транзакций

OLAP (аналитика): тяжёлые запросы по большим объёмам, агрегации, витрины

Практический вывод для архитектуры:

одна и та же база редко одинаково хорошо обслуживает и OLTP, и OLAP

поэтому часто строят разделение: операционная БД для работы, отдельные решения для аналитики

DWH и витрины данных

DWH (data warehouse, хранилище данных) — централизованное хранилище для аналитики, куда данные поступают из разных источников.

Витрина данных — набор подготовленных таблиц/представлений под конкретные отчёты или подразделение.

Типовой конвейер:

источники (CRM, ERP, сайт)

загрузка и преобразования (ETL/ELT)

DWH

витрины и BI-отчёты

Полезная отправная точка по терминам: Data warehouse

Data lake

Data lake — хранилище, где данные могут сохраняться в «сыром» виде (файлы, логи, события), часто для последующей обработки.

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

Интеграция данных: идентификаторы, справочники, контракты

Связь с архитектурой и API из предыдущей статьи прямая: интеграция — это обмен данными, а значит нужны правила.

Идентификаторы

В интеграциях критично договориться:

какой идентификатор считается основным (внутренний, внешний, оба)

как передаётся связь объектов между системами

что делать при дублях и слиянии записей

Master data и справочники

Master data — «основные данные», которыми пользуются многие системы: клиенты, товары, контрагенты, филиалы.

Если нет владельца и правил, возникают типовые проблемы:

в разных системах один и тот же клиент представлен по-разному

отчётность «не бьётся»

интеграции превращаются в постоянные ручные сверки

Контракт данных и версии

Так же как API нужно версионировать, нужно управлять и изменениями данных:

добавили новое поле — старые потребители должны не ломаться

поменяли смысл поля — это уже потенциально ломающая смена

изменили справочник статусов — нужно синхронизировать правила

Способ фиксации контрактов зависит от интеграционного стиля:

для HTTP API часто используют OpenAPI: OpenAPI Specification

для событийных интеграций часто применяют AsyncAPI: AsyncAPI

Качество данных и управление

Даже идеально выбранная СУБД не спасёт, если данные некорректны или неуправляемы.

Измерения качества данных

Чаще всего обсуждают:

точность: соответствует ли значение реальности

полнота: заполнены ли обязательные поля

согласованность: нет ли противоречий между источниками

актуальность: не устарели ли данные

уникальность: нет ли дублей там, где их быть не должно

Правила и ответственность

Практики, которые стоит заложить заранее:

владелец данных (кто отвечает за смысл и правила)

описания полей и справочников (минимальный словарь данных)

контрольные проверки при вводе и интеграциях

Эксплуатация данных: бэкапы, миграции, рост объёма

С точки зрения эксплуатации данные обычно дороже кода: код можно восстановить из репозитория, а данные — нет.

Резервное копирование и восстановление

Минимальные вопросы, на которые должна быть ответная практика:

что именно бэкапится (БД, файлы, объектные хранилища)

как часто делаются копии

как проверяется восстановление (тестовый restore)

как защищаются бэкапы (доступы, шифрование)

Миграции схемы

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

миграции должны быть воспроизводимыми

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

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

Рост данных

По мере роста системы обычно приходят:

партиционирование по датам/ключам

архивирование исторических данных

раздельное хранение «горячих» и «холодных» данных

Как выбрать тип хранилища под задачу

Ниже — практическая шпаргалка. В реальном проекте часто используется несколько типов одновременно.

| Задача | Что важно | Частый выбор | |---|---|---| | Транзакции (заказы, деньги) | строгая целостность, транзакции | реляционная БД | | Гибкие профили, меняющаяся структура | быстрые изменения модели | документная БД | | Кэш, сессии, быстрый доступ по ключу | скорость, простота | key-value | | Отчётность по большим объёмам | агрегации, тяжёлые запросы | DWH/колонночные решения | | Сырые события, логи, файлы | дешёвое хранение, масштаб | data lake | | Сложные связи и обходы графа | связи важнее атрибутов | графовая БД |

Итоги

Данные в ИС описываются моделями трёх уровней: концептуальной, логической и физической.

Реляционные БД сильны транзакциями и целостностью; NoSQL даёт альтернативы под разные нагрузки и модели.

Операционный контур (OLTP) и аналитический контур (OLAP, DWH, витрины) часто разделяют.

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

Эксплуатация данных — это бэкапы, восстановление, миграции схемы и управление ростом объёма.

Анализ требований и моделирование (UML, BPMN)

Зачем это нужно в курсе про информационные системы

В предыдущих статьях мы разобрали:

что такое информационная система и какие бывают классы ИС

как архитектура задаёт компоненты, интеграции и API

почему данные и их модели определяют устойчивость и развитие ИС

Следующий практический шаг перед архитектурой и проектированием данных в реальном проекте — анализ требований и моделирование. Это способ:

зафиксировать, что именно должна делать система и для кого

согласовать процессы и данные между бизнесом и разработкой

уменьшить риск переделок, интеграционных конфликтов и ошибок эксплуатации

Ключевая идея: архитектура и модель данных получаются качественными только тогда, когда понятны процессы, роли, сценарии и ограничения.

Что такое требования

Требования — это проверяемые ожидания к системе: что она должна делать, какие ограничения соблюдать и в каких условиях работать.

Основные виды требований

Бизнес-требования: зачем система нужна организации и какой эффект ожидается.

Пользовательские требования: что должен уметь пользователь в своей роли.

Функциональные требования: конкретные функции системы, сценарии, правила.

Нефункциональные требования: свойства качества и ограничения.

Ограничения: обязательные условия, которые нельзя нарушать.

Нефункциональные требования на практике

Нефункциональные требования часто решают судьбу архитектуры и эксплуатации:

производительность: время отклика, пропускная способность

доступность: допустимые простои, окна обслуживания

надёжность: восстановление после сбоев, устойчивость к ошибкам

безопасность: аутентификация, авторизация, аудит

сопровождаемость: обновления, мониторинг, трассировка

совместимость: требования к интеграциям, версиям API

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

Как получать и уточнять требования

Анализ требований почти всегда итеративный: сначала грубо, потом уточнение до проверяемых формулировок.

Источники требований

интервью с владельцами процессов и пользователями

наблюдение за текущей работой и регламентами

анализ существующих систем и интеграций

нормативные требования и внутренние политики

инциденты и проблемы эксплуатации как источник улучшений

Типовые техники

интервью и воркшопы

разбор сценариев как есть и как должно быть

прототипирование интерфейсов

моделирование процесса и данных

приоритизация

Полезная опора по области бизнес-анализа: BABOK Guide (IIBA)

Как делать требования проверяемыми

Плохое требование невозможно проверить и оно почти гарантирует конфликт на приёмке.

Признаки хорошего требования

однозначность: нет двояких трактовок

проверяемость: понятно, как подтвердить выполнение

атомарность: описывает одну мысль

трассируемость: понятно, откуда взялось и к чему относится

Примеры переформулировки

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

стало: Для 95% запросов поиска заказа время ответа не более 2 секунд при 200 одновременных пользователях

было: Должна быть безопасность

стало: Доступ к операциям возврата средств разрешён только роли Финансист, все операции пишутся в аудит с указанием пользователя, времени и суммы

Артефакты анализа требований

Обычно в проекте живёт не один документ, а набор артефактов.

Контекст и границы системы: что внутри ИС, что во внешней среде

Список ролей и прав: кто что делает

Сценарии и варианты использования: как достигается результат

Бизнес-правила: скидки, лимиты, статусы, проверки

Интеграционные требования: какие системы, какие события или API

Требования к данным: что хранить, качество, справочники, идентификаторы

Нефункциональные требования: доступность, безопасность, эксплуатация

В зрелых командах дополнительно ведут:

матрицу трассируемости: связь требований с реализацией и тестами

каталог данных: определения полей и справочников

BPMN как язык моделирования процессов

Что такое BPMN

BPMN (Business Process Model and Notation) — нотация для описания бизнес-процессов: кто и в каком порядке выполняет действия, какие есть события, развилки и обмены.

Официальная спецификация: BPMN 2.0.2 (Object Management Group)

Когда BPMN особенно полезна

есть несколько ролей и передачи ответственности

процесс включает ожидания, исключения, ручные и автоматические шаги

нужно согласовать как работает бизнес до проектирования экранов и API

Базовые элементы BPMN

Пул: участник процесса (например, Компания)

Дорожки: роли внутри пула (Оператор, Склад, Система)

События: старт, завершение, таймер, сообщение

Задачи: действия (ручные или сервисные)

Шлюзы: развилки (например, по условию)

Потоки: последовательность и сообщения

!Пример BPMN-процесса: создание заказа, оплата, резервирование и обработка отказа оплаты

Типичные ошибки в BPMN

смешивание процесса и структуры данных в одной диаграмме

отсутствие исключений: что, если оплата не прошла или склад не подтвердил

слишком большой процесс на одном листе без декомпозиции

отсутствие ролей и ответственности

UML как язык моделирования системы

Что такое UML

UML (Unified Modeling Language) — набор диаграмм для описания структуры и поведения системы: варианты использования, взаимодействия, состояния и модель предметной области.

Официальная спецификация: UML 2.5.1 (Object Management Group)

Какие диаграммы UML чаще всего нужны в ИС

Use Case: кто и какие цели достигает через систему

Activity: логика сценария как поток действий

Sequence: взаимодействие компонентов и порядок вызовов

Class: модель предметной области и связи сущностей

State Machine: жизненный цикл объекта со статусами

Важно: UML — не обязанность, а инструмент. Выбирайте минимальный набор диаграмм, которые реально снимают неопределённость.

Связка требований, BPMN и UML

Практичная схема работы выглядит так:

Зафиксировать границы системы и внешние интеграции.

Описать ключевые бизнес-процессы в BPMN.

Для каждого процесса выделить варианты использования и роли.

Для сложных сценариев уточнить:

1. последовательности взаимодействий (UML Sequence) 2. состояния ключевых сущностей (UML State) 3. структуру данных предметной области (UML Class)

Добавить нефункциональные требования и эксплуатационные ожидания.

Эта связка напрямую влияет на темы курса:

из BPMN и Sequence вырастают границы сервисов и интеграции через API

из Class и правил целостности вырастает логическая и физическая модель данных

из нефункциональных требований вырастают решения по мониторингу, логированию, резервированию

Мини-пример: от требования к моделям

Пример требований

Пусть у нас есть фрагмент требований для операционной ИС обработки заказов:

пользователь роли Оператор может создать заказ

заказ нельзя оплатить, если не зарезервированы товары

если оплата не прошла, бронь на складе снимается

все действия по оплате пишутся в аудит

Где это отразится в моделировании

BPMN: развилка по исходу оплаты и шаг снятия брони

Use Case: Создать заказ, Оплатить заказ, Отменить заказ

State Machine: статусы заказа, например Создан, Зарезервирован, Оплачен, Отменён

Sequence: кто вызывает платёжный сервис, кто отправляет событие на склад, как обрабатываются повторы

!Пример UML Sequence: порядок вызовов и обработка успешной и неуспешной оплаты

Приоритизация и управление изменениями

Требования всегда конкурируют за сроки и бюджет, а изменения неизбежны.

Как приоритизировать

Часто используют подход MoSCoW:

Must: без этого система не выполняет базовую функцию

Should: очень важно, но можно отложить

Could: полезно, но не критично

Won't: не делаем в этой версии

Подход удобен тем, что превращает обсуждение в управляемое решение, а не в спор.

Почему нужна трассируемость

Трассируемость помогает ответить на вопросы:

какие процессы и роли затронет изменение

какие API и интеграции нужно обновить

какие данные и отчёты пострадают

какие тесты и приёмочные критерии должны поменяться

Итоги

Анализ требований превращает ожидания бизнеса в проверяемые формулировки.

BPMN помогает согласовать бизнес-процессы и ответственность ролей.

UML помогает описать поведение и структуру системы: сценарии, взаимодействия, состояния и сущности.

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

Design and Development: SDLC and Agile

How this topic fits the course

Earlier in the course we defined what an information system is, discussed architecture (components, integration, APIs), explored data models and storage, and learned how to elicit and model requirements with UML and BPMN. The next practical question is: how do we organize the work so that requirements become a working system safely and predictably?

This is the role of SDLC (Software Development Life Cycle) and modern delivery approaches such as Agile. In real IS projects, SDLC is not “only for developers”: it connects business goals, requirements, architecture, data, security, testing, release management, and operations.

SDLC: what it is

SDLC is a structured way to plan, build, test, deploy, and maintain software. It helps teams:

reduce uncertainty by defining stages and responsibilities

manage changes (requirements, scope, constraints)

ensure quality (testing, reviews, compliance)

control operational risks (deployment, monitoring, rollback)

SDLC exists in different process models (Waterfall, V-Model, Iterative, Spiral, Agile). The choice depends on uncertainty, risk, compliance constraints, and how fast feedback is needed.

Typical SDLC stages (end-to-end)

Even if a team uses Agile, these activities still exist; they just happen continuously and iteratively.

Discovery and scope

Goal: confirm the business problem, define system boundaries and success criteria.

Typical outputs:

problem statement and business goals

system context (what is inside vs outside the system)

initial stakeholders and risks

Connection to earlier topics:

system boundary and external actors link directly to the IS definition and integration contour.

Requirements and analysis

Goal: translate business goals into testable requirements.

Typical outputs:

functional requirements (features, rules, workflows)

non-functional requirements (availability, performance, security)

process models (often BPMN)

use cases and scenarios (often UML)

Connection:

requirements quality drives architecture, data model, and operational design.

Reference:

BABOK Guide (IIBA)

Architecture and design

Goal: decide on system structure and key technical solutions.

Typical outputs:

component boundaries and responsibilities

integration style and API contracts

data model decisions (OLTP vs OLAP separation, identifiers, master data)

security design (authn/authz, audit)

Connection:

this stage uses the architecture and data concepts from previous articles.

Implementation

Goal: build working software.

Typical practices:

coding standards and code reviews

database migrations as versioned artifacts

API-first or contract-driven development

Testing and quality assurance

Goal: confirm the system works and is safe to operate.

Typical test levels:

unit tests (small components)

integration tests (service-to-service and DB)

end-to-end tests (user scenarios)

performance and security testing (as required)

A helpful industry reference for security testing guidance:

OWASP Testing Guide

Deployment and release

Goal: deliver changes to users safely.

Typical concepts:

release plan and approvals (especially in regulated environments)

deployment strategy (blue-green, canary, rolling)

rollback plan and database migration strategy

Operations and continuous improvement

Goal: keep the system reliable and evolve it.

Typical operational practices:

monitoring, alerting, logs, tracing

incident management and postmortems

capacity management and cost control

backlog of improvements based on incidents and user feedback

Connection:

operational feedback loops often generate new requirements and architecture improvements.

SDLC process models: how they differ

Waterfall

A sequential flow: analysis → design → build → test → deploy. It can work when requirements are stable and compliance requires heavy documentation.

Risks in information systems:

late feedback (users see the product near the end)

expensive changes after design decisions are “frozen”

V-Model

A Waterfall-like model that explicitly maps development stages to corresponding test stages (design ↔ integration tests, requirements ↔ acceptance tests). It is common in safety- and compliance-focused domains.

Iterative and incremental development

Build the system in increments and refine through iterations. This reduces risk compared to a single “big-bang” delivery.

Spiral (risk-driven)

Each cycle focuses on identifying and mitigating key risks (technical, schedule, security). Useful for complex IS programs with high uncertainty.

A concise reference:

Spiral model (Wikipedia)

Agile

Agile is a family of approaches focused on short feedback cycles and incremental delivery. Agile is not “no process”; it is a way to make process adaptive.

Core ideas are summarized in:

Manifesto for Agile Software Development

Agile in practice: roles, events, artifacts

Agile can be implemented in many ways; Scrum is a common framework.

Scrum overview:

Scrum Guide

Typical roles (Scrum-oriented language)

Product Owner: defines priorities and value; clarifies requirements.

Developers: build the product increment.

Scrum Master: helps the team improve and removes impediments.

Typical events

sprint planning

daily synchronization

sprint review (feedback from stakeholders)

retrospective (process improvement)

Typical artifacts

product backlog (ordered list of work)

sprint backlog (what the team commits to for the sprint)

increment (working software)

How Agile connects to architecture, data, and integrations

Agile delivery works well for information systems when you intentionally manage architecture and data integrity.

Architecture in Agile: avoid “architecture by accident”

Common approach: evolutionary architecture.

Practical rules:

decide early on hard-to-change constraints (security model, data ownership, integration contracts)

keep a small set of architecture principles (for example, “no direct access to another service’s database”)

validate decisions with thin slices (end-to-end prototypes)

Data changes must be treated as product changes

In an IS, data is often more valuable than code. Therefore:

schema changes should be versioned and reversible when possible

backwards compatibility should be planned (old consumers may still exist)

master data ownership must be explicit (who is the source of truth)

Integrations require contract discipline

Agile teams often break systems through uncontrolled API changes. To reduce this risk:

document APIs (for HTTP, OpenAPI is common)

version breaking changes and plan migrations

test contracts between producers and consumers

Reference:

OpenAPI Specification

Agile vs Waterfall: a pragmatic comparison

| Aspect | Predictive (Waterfall-like) | Adaptive (Agile-like) | |---|---|---| | Requirements | defined upfront | refined continuously | | Feedback | late | frequent | | Delivery | big releases | incremental releases | | Change cost | high late in project | managed continuously | | Compliance documentation | often heavy | can be produced continuously if required | | Integration risks | discovered late | surfaced earlier via increments |

Key point: many organizations use a hybrid approach—Agile iterations within governance and compliance constraints.

!Side-by-side comparison of linear SDLC vs iterative Agile delivery

Definition of Done, acceptance criteria, and quality gates

To keep Agile delivery safe for information systems, teams align on shared quality standards.

Acceptance criteria

Acceptance criteria make requirements testable. They typically describe:

scenario and expected outcome

business rules and constraints

error handling and edge cases

They connect directly to earlier modeling:

BPMN helps identify normal paths and exceptions

UML sequence diagrams help define service interactions and failure handling

Definition of Done

Definition of Done is a checklist that says when work is truly complete, not “coded”. For IS projects it commonly includes:

code reviewed

automated tests passing

API documentation updated

database migration applied and verified

logs/metrics added for new behavior

security requirements met (authz, audit)

Quality gates are a broader concept: automated and manual checks that stop unsafe changes from reaching production.

DevOps and CI/CD as the operational extension of SDLC

Modern IS delivery often combines Agile planning with DevOps execution.

Key ideas:

CI (Continuous Integration): frequently merge changes and run automated checks.

CD (Continuous Delivery/Deployment): automate release steps to reduce risk.

A widely used reference for DevOps concepts and metrics:

Accelerate (DORA) resources

Practical outcomes for information systems:

faster, safer releases through automation

better reliability through monitoring and operational feedback

clearer ownership of running systems

Common failure modes and how to prevent them

“Agile = no documentation”

Reality: you still need documentation, but you create and update it continuously, focusing on what is operationally and architecturally critical.

“We deliver features, but operations suffer”

Prevention:

include observability, security, and performance in backlog

treat operational incidents as sources of requirements

“Microservices without integration discipline”

Prevention:

define API versioning rules

adopt contract testing for critical integrations

assign ownership of master data

Summary

SDLC is the end-to-end lifecycle that connects requirements, architecture, data, implementation, testing, deployment, and operations.

Agile makes SDLC iterative and feedback-driven, which is especially valuable when requirements evolve.

In information systems, Agile must be paired with strong practices for API contracts, data evolution, security, and operability.

A mature delivery approach often blends Agile planning, engineering quality gates, and DevOps automation to reduce risk while enabling change.

Deployment and Operations: DevOps, Monitoring, SLA

Why this topic matters after architecture, data, and SDLC

In the previous articles you learned how to:

define an information system (people, processes, data, technology, rules)

design architecture and integration via APIs

model and store data (OLTP, OLAP, DWH)

elicit requirements and model processes (UML, BPMN)

organize delivery work (SDLC and Agile)

This article explains what happens when the system must run reliably for real users. A technically correct design can still fail in production if releases are risky, monitoring is weak, or service expectations are unclear.

In practice, deployment and operations are where:

non-functional requirements (availability, performance, security) become measurable targets

integrations and data flows meet real failures (timeouts, duplicates, partial outages)

the organization decides what downtime is acceptable and what it costs

Core concepts

Deployment vs operations

Deployment: moving a change (code, configuration, schema, infrastructure) into an environment where users consume it.

Operations: keeping the system healthy over time: monitoring, incident response, capacity planning, backups, upgrades, security patching.

DevOps (what it is in information systems)

DevOps is an approach that reduces the gap between building software and running it. It focuses on:

shared ownership for production outcomes

automation of build, test, deployment, and infrastructure changes

fast feedback from production (metrics, logs, incidents) back into development

A common reference for reliability-focused operations and measurable outcomes:

Google Site Reliability Engineering (SRE) book

DevOps is not a single tool and not “ops people learn to code”. It is an operating model that makes delivery and operations predictable.

From SDLC to delivery: CI/CD and release safety

CI/CD in one picture

CI (Continuous Integration): every change is integrated frequently and verified automatically.

CD (Continuous Delivery/Deployment): the path to production is automated and repeatable.

!CI/CD pipeline with feedback loops from operations

What should be treated as “a release unit”

In an information system, a release is rarely “just application code”. It typically includes:

application version

configuration changes

database migrations (schema and reference data)

API contract changes (new fields, new endpoints, new events)

infrastructure changes (network rules, compute size, storage)

A safe SDLC treats all these changes as versioned, reviewable artifacts.

Infrastructure as Code (IaC)

Infrastructure as Code means infrastructure is described in code-like files and applied automatically. This makes environments reproducible and reduces “it works on my server” failures.

Key outcomes:

faster environment creation (dev, test, staging)

consistent security settings (network, permissions)

traceability of changes (who changed what and when)

Deployment strategies (how to reduce risk)

Rolling deployment: gradually replace instances with the new version.

Blue-green deployment: keep two environments, switch traffic to the new one.

Canary release: send a small percentage of traffic to the new version, expand if stable.

Choosing a strategy depends on:

how easy rollback is

how risky database changes are

how quickly errors are detected

Observability and monitoring

Monitoring vs observability

Monitoring answers: is the system working right now?

Observability answers: why is it not working? using telemetry designed into the system.

A practical, widely adopted standard for telemetry collection is:

OpenTelemetry

The three key telemetry signals

Metrics: numeric time series (latency, error rate, CPU, queue length).

Logs: detailed events (who did what, errors, warnings).

Traces: end-to-end view of a request across services and integrations.

For distributed information systems (APIs, message brokers, multiple databases), traces and correlation IDs are often the difference between a 10-minute and a 2-day incident.

What to monitor in an information system

| Layer | Typical signals | Why it matters | |---|---|---| | User experience | page/API latency, failed transactions | this is what users feel | | Application/API | HTTP error rates, timeouts, dependency failures | most outages start here | | Integrations | external API latency, message backlog, retry counts | integration failures propagate | | Data stores | DB slow queries, replication lag, lock waits, disk usage | data issues can stop the business | | Infrastructure | CPU, memory, network, storage IOPS | capacity and noisy-neighbor issues | | Security | authentication failures, permission denials, audit anomalies | security incidents are outages too |

Alerting (how to avoid “alert storms”)

Alerting should be designed around user impact and clear action.

Good alerts are:

actionable (someone can do something specific)

tied to an SLO or a known failure mode

routed to the right owner

Bad alerts are:

too sensitive (constant noise)

not owned (“someone should look at it”)

not connected to any business impact

A common pattern is to separate:

symptom alerts: user-visible problems (high error rate, high latency)

cause signals: details used for diagnosis (CPU, logs, traces)

Reliability targets: SLI, SLO, SLA

Definitions (and how they relate)

SLI (Service Level Indicator): a measurable metric that reflects service health for users.

SLO (Service Level Objective): the target value for an SLI, used to manage reliability.

SLA (Service Level Agreement): a formal commitment to customers or internal stakeholders, often with consequences.

A reliable way to align these concepts is described in the SRE approach:

SRE book: Service Level Objectives

Examples of SLIs for common information systems

| System type | Typical SLI | Practical meaning | |---|---|---| | CRM/ERP web app | availability of core actions | users can create/view records | | Payment processing | successful payment rate | money flows correctly | | Integration hub | message processing delay | data arrives within expected time | | Analytics/BI | data freshness | dashboards reflect recent reality |

Error budget (why SLOs affect delivery speed)

An error budget is the allowed amount of unreliability implied by an SLO. Teams can use it to balance:

shipping new features faster

keeping the system stable

If reliability is worse than the SLO target, the team typically pauses risky releases and focuses on stability work (performance fixes, capacity, better fallbacks, safer migrations).

SLA design for real organizations

What an SLA usually contains

An SLA is a business document, but it must be technically implementable.

Typical sections:

service scope (which functions are covered)

availability target and measurement method

performance expectations (for key operations)

support hours and response times

incident communication rules

planned maintenance windows

exclusions (force majeure, customer misconfiguration)

Availability: what exactly is measured

Availability statements must define:

what counts as “up” (login works, order placement works, API returns success)

the measurement point (from user perspective, from load balancer, synthetic checks)

the time window (monthly, quarterly)

Without these details, availability numbers become meaningless and disputed.

Recovery targets: RTO and RPO

For critical information systems, you also define:

RTO (Recovery Time Objective): how long it may take to restore service after a major failure.

RPO (Recovery Point Objective): how much data loss (time-wise) is acceptable.

These targets directly influence:

backup frequency and retention

replication strategy

disaster recovery procedures and cost

Incident management and operational readiness

Incident lifecycle (practical minimum)

Detect (monitoring, user reports, synthetic checks)

Triage (severity, scope, immediate mitigations)

Restore (roll back, fail over, disable a feature, scale up)

Communicate (status updates to stakeholders)

Learn (post-incident review, fix root causes, improve runbooks)

Runbooks and on-call readiness

A runbook is a step-by-step operational instruction for a known issue or procedure.

A good runbook includes:

how to confirm the problem (which dashboard/log query)

safe mitigations (restart, scale, toggle feature flag)

escalation path (who owns which subsystem)

rollback steps for recent releases

This is where architecture decisions show their operational consequences:

if services are loosely coupled, partial failures are survivable

if one service depends synchronously on many others, one failure becomes a cascade

Data operations: backups, migrations, and integrity in production

Backups are not real until restore is tested

Key operational practices:

automate backups

store backups securely with access controls

periodically test restoration into a non-production environment

Database migrations as a deployment risk

Schema changes can be harder to roll back than code. Common safety rules:

make backward-compatible schema changes first (add new columns, keep old ones)

deploy application changes that can work with both old and new schemas

remove old schema elements later, after consumers are migrated

This connects directly to earlier topics:

API and data contract versioning

integration patterns (synchronous calls vs asynchronous events)

Security in operations (baseline)

Operational security is not only about prevention, but also about detection and traceability.

Minimum operational controls for many information systems:

strong authentication and role-based authorization

audit logging for sensitive actions

n- secrets management (no passwords in source code)

patching policy and vulnerability response

least privilege access for infrastructure and databases

For a widely used security reference in application operations:

OWASP Application Security Verification Standard (ASVS)

What “good operations” looks like

A practical checklist for operational maturity:

monitoring dashboards reflect user-facing SLIs

alerts are actionable and tied to SLOs

releases are automated, repeatable, and observable

incidents produce improvements (not just blame)

backups and restore procedures are tested

data and API evolution is managed with compatibility rules

Summary

DevOps connects delivery and operations through shared ownership and automation.

Monitoring and observability require metrics, logs, and traces designed into the system.

SLI/SLO/SLA provide a hierarchy from measurement to internal targets to formal commitments.

Operational practices (incident management, runbooks, backups, safe migrations) turn architecture and data decisions into reliable production behavior.

Безопасность и надежность информационных систем

Зачем отдельная тема про безопасность и надежность

В предыдущих статьях курса мы разобрали, что информационная система состоит из людей, процессов, данных и технологий, как устроена архитектура и интеграции через API, как проектируются модели данных, как формулируются требования (UML/BPMN) и как организуется жизненный цикл поставки (SDLC/Agile) и эксплуатация (DevOps, мониторинг, SLA).

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

Практическая цель статьи: научиться превращать общие пожелания вида «нужно безопасно и стабильно» в конкретные решения и проверяемые договоренности.

Базовые определения и различия

Что такое безопасность информационной системы

Безопасность ИС — это способность системы защищать данные и функции от несанкционированного доступа, изменений и сбоев, обеспечивая управляемый риск.

Классическая модель целей безопасности — триада CIA:

Конфиденциальность: данные доступны только тем, кому положено.

Целостность: данные не изменяются незаконно или незаметно.

Доступность: система и данные доступны, когда это нужно.

Важно: доступность входит и в безопасность, и в надежность. В проектах часто разделяют фокус:

безопасность отвечает на вопрос «как не допустить злоупотреблений и компрометации»

надежность отвечает на вопрос «как продолжать работать при сбоях и изменениях»

Что такое надежность

Надежность ИС — это способность системы стабильно предоставлять сервис в ожидаемых условиях и корректно восстанавливаться при сбоях.

В эксплуатации надежность обычно измеряют через:

SLI: измеряемые индикаторы (ошибки, задержки, успешность операций)

SLO: целевые значения для управления качеством

SLA: формальные обязательства (часто с последствиями)

Эти термины подробно связывались с мониторингом и SLA в статье про эксплуатацию.

Модель угроз и рисков: от абстракций к решениям

Активы, угрозы, уязвимости, риск

Чтобы не обсуждать безопасность на уровне лозунгов, удобно пользоваться простой логикой:

Актив: что мы защищаем (данные клиентов, деньги, доступ к управлению)

Угроза: что может пойти не так (фишинг, взлом, ошибка конфигурации)

Уязвимость: слабое место (нет MFA, старые библиотеки, открытый порт)

Риск: вероятность и ущерб, если угроза реализуется

Ключевой вывод: безопасность и надежность — это управление рисками, а не попытка сделать систему «абсолютно защищенной».

Связь с требованиями и моделированием

Безопасность и надежность должны попадать в требования так же, как бизнес-функции:

требования к ролям, правам и аудиту связываются с UML Use Case и моделями ролей

исключения и обходные сценарии (таймауты, отказ внешнего API) должны быть отражены в BPMN и UML Sequence

требования к целостности данных влияют на логическую и физическую модель данных

Принцип глубокой защиты

Один контроль редко спасает. Практичнее мыслить слоями.

!Слои защиты в ИС: от пользователя и сети до сервисов и данных

Типовые слои и примеры контролей:

уровень пользователя: MFA, обучение, управление устройствами

уровень сети: сегментация, firewall, WAF

уровень приложений и API: аутентификация, авторизация, лимиты, валидация

уровень данных: права доступа, шифрование, контроль целостности

уровень эксплуатации: мониторинг, реагирование, управление изменениями

Управление доступом: аутентификация, авторизация, аудит

Аутентификация

Аутентификация отвечает на вопрос «кто ты».

Практики:

многофакторная аутентификация (MFA) для админов и критичных операций

единый провайдер идентификации (SSO), где это уместно

запрет хранения паролей в открытом виде, корректное хеширование

Стандарты и протоколы часто встречаются такие:

OAuth 2.0

OpenID Connect

Авторизация

Авторизация отвечает на вопрос «что тебе можно».

Распространенные модели:

RBAC: права на основе ролей (Оператор, Финансист, Администратор)

ABAC: права на основе атрибутов (роль, подразделение, регион, тип операции)

Практический принцип: минимально необходимые права (least privilege).

Аудит и журналирование

Аудит нужен не только для расследований, но и для контроля корректности действий.

События, которые обычно стоит писать в аудит:

вход в систему и выдача токенов

изменение прав и ролей

операции с деньгами и критичными справочниками

действия администраторов

Важно различать:

логи для диагностики (ошибки, трассировка)

аудит для юридически значимых действий (кто, что, когда)

Защита данных: целостность, шифрование, резервное копирование

Целостность данных

Целостность обеспечивается комбинацией:

ограничений и транзакций на уровне БД (ключи, NOT NULL, FOREIGN KEY)

проверок на уровне прикладной логики

контрактов данных в интеграциях (схемы, версии)

Связь с прошлой статьей про данные прямая: ошибки целостности чаще всего проявляются как эксплуатационные инциденты и «не бьется отчетность».

Шифрование: в канале и на хранении

Минимальный базис:

шифрование трафика между компонентами (обычно TLS)

шифрование чувствительных данных на хранении (диски, объектные хранилища, секреты)

При проектировании важно заранее определить:

что считается чувствительными данными

где нужны маскирование и токенизация

как управляются ключи и доступ к ним

Резервные копии и проверка восстановления

Бэкапы — часть и безопасности, и надежности.

Практический минимум:

резервное копирование по расписанию

хранение копий с ограниченным доступом

регулярная проверка восстановления (тестовый restore)

Ключевой принцип эксплуатации: резервная копия без проверенного восстановления — это гипотеза, а не гарантия.

Безопасность приложений и API

Валидация входных данных

Многие уязвимости появляются из-за неконтролируемого ввода.

Практики:

строгая валидация на границе (API gateway и сервис)

ограничение размеров запросов

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

Типовые классы уязвимостей

Удобный ориентир для команд разработки:

OWASP Top 10

Связь с архитектурой: часть рисков снижается на уровне стиля интеграции и контрактов, а не только «починкой кода».

Защита API

Типовые меры для API, которые обсуждались и в статье про интеграции:

аутентификация и авторизация на каждом запросе

rate limiting и защита от перебора

идемпотентность для критичных операций создания и оплаты

версионирование и обратная совместимость

Надежность: проектирование отказоустойчивости

От чего защищаемся в надежности

Частые источники отказов:

падение экземпляра приложения или узла

недоступность внешнего API

деградация БД (медленные запросы, блокировки)

ошибки релизов и миграций

исчерпание ресурсов (CPU, память, диск)

Паттерны устойчивости в интеграциях

!Паттерны устойчивости: таймауты, повторы, circuit breaker, очереди

Практики, которые резко снижают количество инцидентов:

таймауты на внешние вызовы, чтобы не зависать бесконечно

ретраи только там, где операция безопасна или идемпотентна

circuit breaker: временно «отключать» вызовы к падающей зависимости

очереди и асинхронность для выравнивания пиков и изоляции сбоев

дедупликация событий и запросов, если возможны повторы

Идемпотентность и повторы

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

Идемпотентная операция — та, которую можно повторить без изменения смысла результата.

Типовые техники:

Idempotency-Key на запросах создания платежей/заказов

хранение состояния обработки события и игнорирование дублей

Это соединяет тему надежности с темой API-контрактов и эксплуатационной наблюдаемости.

Непрерывность: RTO, RPO и аварийное восстановление

Для критичных ИС, кроме «обычных» инцидентов, планируют сценарии катастроф:

потеря зоны доступности или дата-центра

массовая порча данных

компрометация учетных записей администраторов

Два ключевых показателя:

RTO: за какое время нужно восстановить сервис

RPO: какой объем потери данных допустим по времени

Эти цели определяют стоимость и архитектуру:

частоту бэкапов

репликацию

необходимость горячего резерва

процедуры и регулярные учения восстановления

Мониторинг безопасности и надежности

Из статьи про эксплуатацию: метрики, логи и трассировка — основа наблюдаемости. Для безопасности и надежности важно, чтобы наблюдаемость поддерживала расследование.

Практики:

единый корреляционный идентификатор запроса через сервисы

метрики SLI, отражающие пользовательский опыт (ошибки операций, задержки)

алерты, привязанные к SLO и влиянию на пользователей

отдельный контроль «подозрительных» событий (аномальные логины, всплески отказов авторизации)

Ориентир по управлению киберрисками на уровне организации:

NIST Cybersecurity Framework

Безопасность и надежность в SDLC и DevOps

Технически правильные меры не заработают, если не встроены в процесс.

Практики в поставке изменений

автоматические проверки зависимостей и уязвимостей

обязательные code review для критичных модулей

окружения и инфраструктура как код

безопасные миграции БД с учетом обратной совместимости

Управление изменениями и инцидентами

релизные стратегии (canary, blue-green), чтобы снижать риск

постинцидентные разборы с фиксацией улучшений

runbooks для типовых аварийных процедур

Это связывает безопасность и надежность с темой SDLC: требования переходят в реализацию, а затем в эксплуатацию с обратной связью.

Минимальный практический чек-лист для проекта ИС

Точки, которые полезно проверить уже на этапе проектирования:

есть список ролей, прав и критичных операций, требующих аудита

определены чувствительные данные и правила их обработки

зафиксированы интеграции и контракты API, включая версионирование

определены SLI/SLO для ключевых пользовательских операций

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

есть план обработки отказов внешних зависимостей (таймауты, ретраи, fallback)

Итоги

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

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

Надежность опирается на наблюдаемость и инженерные паттерны устойчивости: таймауты, ретраи, circuit breaker, асинхронность, идемпотентность.

RTO и RPO превращают «хотим не терять данные» в конкретные требования к бэкапам, репликации и аварийному восстановлению.

Практики SDLC и DevOps делают безопасность и надежность воспроизводимыми: через автоматизацию, контроль изменений и дисциплину контрактов.