Лекция 6. Принципы построения систем

Эта лекция

В этой лекции мы рассмотрим требования ГОСТ к созданию автоматизированных систем и модели жизненного цикла разработки ПО, изучим архитектуры систем (монолит, микросервисы, serverless) и облачные модели обслуживания (IaaS, PaaS, SaaS, FaaS), разберём API и форматы данных, а также познакомимся с методологиями Agile, Scrum и DevOps.

Цель

Сформировать представление о требованиях ГОСТ к созданию автоматизированных систем, моделях жизненного цикла разработки ПО, архитектурах и облачных моделях обслуживания систем, API-интеграциях и методологиях разработки Agile/Scrum/DevOps.

Содержание

• Лекция 6. Принципы построения систем
  • Эта лекция
  • Цель
  • Содержание
  • 6.1 Требования ГОСТ и принцип первого руководителя
    • ГОСТ РД 50-680-88
    • ГОСТ 34.601-90
    • Модели жизненного цикла разработки ПО
    • Принцип первого руководителя
  • 6.2 Архитектуры систем: монолит, микросервисы, serverless
    • Монолитная архитектура
    • Микросервисная архитектура
    • Serverless-архитектура
    • Облачные модели обслуживания: IaaS, PaaS, SaaS, FaaS
  • 6.3 API, форматы данных и интеграции
    • API как основа интеграции
    • HTTP REST: методы и статус-коды
    • Форматы данных
  • 6.4 Agile, Scrum и DevOps
    • Agile Manifesto
    • Методология Scrum
    • DevOps-практики
  • Кейс АРК: BI-аналитика и дашборды
    • BI-архитектура и OLAP
  • Транспортный контекст
    • Примеры из «Управления процессами перевозок»
    • Примеры из «Транспортной логистики»
    • Связь с ФГОС 23.05.04 «Эксплуатация железных дорог»
  • Заключение и выводы для специалиста
  • Вопросы для самопроверки

6.1 Требования ГОСТ и принцип первого руководителя

ГОСТ РД 50-680-88

ГОСТ РД 50-680-88 — стандарт для автоматизированных систем на транспорте. Определяет основные требования к проектированию и созданию АС.

ГОСТ 34.601-90

ГОСТ 34.601-90 — стандарт, описывающий этапы создания автоматизированных систем:

---
config:
  look: handDrawn
  theme: neutral
---
graph LR
    A[1. ТЗ] --> B[2. Проект]
    B --> C[3. Рабочий]
    C --> D[4. Внедрение]
    D --> E[5. Эксплуатация]
    
    style A fill:#d9d9d9,stroke:#333
    style E fill:#d9d9d9,stroke:#333

Модели жизненного цикла разработки ПО

Жизненный цикл ПО (SDLC, Software Development Life Cycle) — последовательность этапов, которые проходит информационная система от замысла до вывода из эксплуатации. Классические этапы:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A[Анализ требований] --> B[Проектирование]
    B --> C[Разработка]
    C --> D[Тестирование]
    D --> E[Внедрение]
    E --> F[Сопровождение]

    style A fill:#d9d9d9,stroke:#333
    style F fill:#d9d9d9,stroke:#333

Модели жизненного цикла:

Связь с ГОСТ: этапы ГОСТ 34.601-90 (ТЗ → проект → рабочая документация → внедрение → эксплуатация) реализуют каскадную модель, традиционную для государственных и крупных корпоративных проектов. Современная альтернатива — Agile-подход (см. § 6.4): итеративная поставка, постоянная обратная связь с заказчиком, готовность к изменениям.

Выбор подхода для ТЛК:

Кейс АРК: платформа АРК развивается по Agile-модели — регулярные релизы новых функций без остановки работы клиентов, а соответствие требованиям ГОСТ обеспечивается на этапах внедрения и документирования.

Принцип первого руководителя

Принцип первого руководителя — условие успеха автоматизации является активная поддержка топ-менеджмента.

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

Почему это важно:

6.2 Архитектуры систем: монолит, микросервисы, serverless

Монолитная архитектура

Монолит — единое приложение, где все компоненты связаны и развёртываются вместе.

Применение в ТЛК: Небольшие ТЛК с 1–2 пользователями, простые системы учёта.

Микросервисная архитектура

Микросервисы — архитектура, где приложение состоит из независимых сервисов, каждый решает свою задачу.

---
config:
  look: handDrawn
  theme: neutral
---
graph TD
    A[API Gateway] --> B[CRM-сервис]
    A --> C[TMS-сервис]
    A --> D[WMS-сервис]
    A --> E[Документооборот]
    A --> F[Аналитика]
    
    B --> G[(БД CRM)]
    C --> H[(БД TMS)]
    D --> I[(БД WMS)]
    
    style A fill:#4a4a4a,stroke:#333,color:#fff

Применение в ТЛК: Средние и крупные ТЛК, облачные платформы (как АРК).

Serverless-архитектура

Serverless — архитектура, где разработчик пишет код, а инфраструктурой управляет провайдер.

Применение в ТЛК: Webhook-уведомления, обработка файлов, API-интеграции.

Облачные модели обслуживания: IaaS, PaaS, SaaS, FaaS

Облачные вычисления — модель предоставления вычислительных ресурсов (серверы, хранилища, приложения) по требованию через сеть. Определение, характеристики и классификация зафиксированы в стандарте NIST SP 800-145.

Пять существенных характеристик облачных вычислений (NIST SP 800-145):

Модели развёртывания облака: публичное облако (ресурсы общего пользования), частное (одна организация), гибридное (комбинация публичного и частного), community-облако (группа организаций).

Модели обслуживания:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TB
    subgraph Облачные модели
        I[IaaS<br/>Инфраструктура] --> P[PaaS<br/>Платформа]
        P --> S[SaaS<br/>ПО как сервис]
        F[FaaS<br/>Функции,<br/>serverless] -.-> P
    end

    style S fill:#d9d9d9,stroke:#333
    style F fill:#4a4a4a,stroke:#333,color:#fff

Связь с архитектурами: FaaS — практическая реализация serverless-подхода: код запускается по событию (webhook, новая заявка) и автоматически масштабируется; SaaS — способ поставки готового ПО, к которому относится платформа АРК.

Выбор модели для ТЛК:

Кейс АРК: АРК — облачная SaaS-платформа: клиент получает готовую систему по подписке, не покупая серверы и не нанимая команду разработки, а обновления и масштабирование выполняет провайдер.

6.3 API, форматы данных и интеграции

API как основа интеграции

API (Application Programming Interface) — интерфейс, позволяющий различным приложениям обмениваться данными.

HTTP REST: методы и статус-коды

HTTP-методы REST API:

HTTP-статус-коды:

Форматы данных

Сравнение форматов данных:

Пример JSON-запроса к API АРК:

{
  "client": {
    "name": "ООО «ТрансЛог»",
    "inn": "7701234567",
    "type": "legal"
  },
  "contact": {
    "email": "info@translog.ru",
    "phone": "+7(495)123-45-67"
  }
}

Тот же запрос в формате XML — используется в ЭДО и корпоративных системах обмена документами:

<?xml version="1.0" encoding="UTF-8"?>
<request>
  <client>
    <name>ООО «ТрансЛог»</name>
    <inn>7701234567</inn>
    <type>legal</type>
  </client>
  <contact>
    <email>info@translog.ru</email>
    <phone>+7(495)123-45-67</phone>
  </contact>
</request>

Тот же запрос в Protobuf — формат двоичный: сначала описывается схема сообщения (.proto-файл), а затем данные заполняются и сериализуются в компактный бинарный вид, недоступный для чтения человеком:

// Схема сообщения (файл client_request.proto)
syntax = "proto3";

message Client {
  string name = 1;  // «ООО «ТрансЛог»»
  string inn  = 2;  // «7701234567»
  string type = 3;  // «legal»
}

message Contact {
  string email = 1; // «info@translog.ru»
  string phone = 2; // «+7(495)123-45-67»
}

message ClientRequest {
  Client  client  = 1;
  Contact contact = 2;
}

После компиляции схемы код заполняет поля теми же данными, что и в JSON/XML, и сериализует сообщение в байты:

// Сериализованное сообщение ClientRequest (иллюстрация):
0A 24 0A 1D D0 9E D0 9E D0 9E 20 C2 AB D0 A2 D1 80 ...
12 1B 0A 10 69 6E 66 6F 40 74 72 61 6E 73 6C 6F 67 ...

Почему байты выглядят «непонятно»

Protobuf — это бинарный формат, а не текстовый: человек не должен читать его глазами, его читает программа по заранее известной схеме.

1. Данные без имён полей. В JSON и XML каждое значение сопровождается именем поля:

"name": "ООО «ТрансЛог»"

Имена ("name", "inn", "type") занимают место в каждом сообщении. При миллионе сообщений вы миллион раз передаёте одни и те же слова. В Protobuf имена полей хранятся только в схеме (.proto-файл), которая есть у отправителя и получателя, а в самих данных вместо имени пишется номер поля — одно число:

string name = 1;   // поле №1
string inn  = 2;   // поле №2
string type = 3;   // поле №3

2. Как читается байт 0A. Protobuf читает поток парами «ключ → значение», где ключ кодирует номер поля и тип данных по формуле:

ключ = (номер_поля << 3) | тип_провода

Разбор 0A:

• 0A = 0000 1010 в двоичном виде;
• тип провода = младшие 3 бита = 010 = 2 — «данные длиной N» (строки, вложенные сообщения, байты);
• номер поля = оставшиеся биты = 0001 = 1.

По схеме поле №1 в ClientRequest — это Client client, значит дальше идёт вложенное сообщение Client.

3. Как читается 24. Следующий байт 24 = 36 — это длина вложенного сообщения Client в байтах. Программа читает следующие 36 байт и разбирает их как Client.

4. Внутри Client — снова 0A 1D ...:

• 0A → поле №1, тип «длина»; в схеме Client поле №1 — string name;
• 1D = 29 → длина строки имени — 29 байт.

Дальше идут эти 29 байт:

D0 9E D0 9E D0 9E 20 C2 AB D0 A2 D1 80 ...

Это UTF-8 для текста «ООО «ТрансЛог»»:

«Непонятные» байты — это просто русский текст в кодировке UTF-8, только без кавычек и имён полей вокруг.

5. Дальше 12 1B ...:

• 12 = 0001 0010 → тип провода 010 = 2, номер поля 0010 = 2 → поле №2 в ClientRequest — это Contact contact;
• 1B = 27 → длина вложенного Contact = 27 байт;
• внутри: 0A 10 69 6E 66 6F 40 ... → поле №1 (email), длина 16, дальше 69 6E 66 6F 40 74 72 61 6E 73 6C 6F 67 ... — ASCII-строка info@translog....

6. Почему так устроено:

Protobuf не предназначен для чтения человеком: его смысл — быстро, компактно и строго передавать данные между программами с общей схемой. Если нужна читаемость — берут JSON или XML, но платят за это размером и скоростью разбора.

Вывод: JSON удобен для чтения и отладки, XML — обязателен в корпоративном ЭДО, Protobuf даёт минимальный размер сообщения и высокую скорость сериализации, но требует описания схемы и компиляции кода.

Webhooks — механизм обратной связи: приложение АРК отправляет HTTP POST-запрос на указанный URL при наступлении события (новая заявка, изменение статуса).

6.4 Agile, Scrum и DevOps

Agile Manifesto

Agile — семейство методологий разработки, основанных на итеративном подходе и адаптивности.

Четыре ценности Agile Manifesto:

Методология Scrum

Scrum — фреймворк Agile для управления разработкой продукта.

Роли Scrum:

Артефакты Scrum:

Церемонии Scrum:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A["Планирование спринта"] --> B["Ежедневный скрам"]
    B --> C["Разработка"]
    C --> D["Обзор спринта"]
    D --> E["Ретроспектива"]
    E --> A
    
    style A fill:#d9d9d9,stroke:#333
    style D fill:#d9d9d9,stroke:#333
    style E fill:#4a4a4a,stroke:#333,color:#fff

DevOps-практики

DevOps — культура и практика взаимодействия разработки (Development) и эксплуатации (Operations).

CI/CD (Continuous Integration / Continuous Delivery):

---
config:
  look: handDrawn
  theme: neutral
---
graph LR
    A["Код в репозиторий"] --> B["Автоматическая сборка"]
    B --> C["Автоматическое тестирование"]
    C --> D["Развёртывание на тестовом стенде (staging)"]
    D --> E["Проверка качества"]
    E --> F["Развёртывание в рабочую среду (production)"]
    
    style A fill:#d9d9d9,stroke:#333
    style F fill:#d9d9d9,stroke:#333

Ключевые практики DevOps:

Кейс АРК: BI-аналитика и дашборды

Встроенная BI-аналитика АРК предоставляет руководителям инструменты для принятия решений на основе данных.

Основные компоненты BI-модуля АРК:

BI-архитектура и OLAP

BI (Business Intelligence) — совокупность технологий сбора, хранения и анализа данных для поддержки принятия решений. Типовая BI-архитектура:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A[Источники данных<br/>TMS, WMS, CRM, ERP] --> B[ETL<br/>Extract, Transform, Load]
    B --> C[Хранилище данных<br/>DWH]
    C --> D[OLAP-куб<br/>многомерный анализ]
    D --> E[Дашборды и отчёты]

    style D fill:#4a4a4a,stroke:#333,color:#fff

ETL (Extract, Transform, Load) — извлечение данных из источников, их преобразование и загрузка в хранилище данных (DWH).

OLAP (On-Line Analytical Processing) — технология многомерного анализа данных. Данные организуются в OLAP-куб, где оси — измерения, а ячейки — меры.

Пример для ТЛК: OLAP-куб «Клиент × Направление × Время» с мерой «Маржа». Drill-down от годовой маржи к марже отдельной перевозки выявляет убыточные направления, а pivot сравнивает динамику по клиентам.

В АРК многомерный анализ реализован встроенными дашбордами с фильтрами, срезами и drill-down (показатели ниже), а внешние отчёты строятся в Yandex DataLens через REST API (см. ниже).

Показатели в дашбордах АРК:

Yandex DataLens — внешний BI-инструмент:

DataLens позволяет подключаться к данным АРК через API/HTTP REST и строить внешние дашборды:

1. Получение API-ключа в настройках АРК
2. REST API запрос к эндпоинтам АРК (GET /api/reports/...)
3. Подключение DataLens к API АРК
4. Построение визуализаций: графики, диаграммы, таблицы
5. Настройка обновлений в реальном времени

Практическое задание: Постройте дашборд со встроенной аналитикой АРК и подготовьте внешний дашборд в DataLens для лабораторной работы 6.

Транспортный контекст

Примеры из «Управления процессами перевозок»

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

• Соответствие ГОСТ РД 50-680-88 при создании АС управления перевозками
• Микросервисная архитектура для интеграции с системами РЖД
• REST API для обмена данными с грузовладельцами

Примеры из «Транспортной логистики»

В автомобильной логистике Agile/Scrum применяется для:

• Итеративной разработки мобильных приложений для водителей
• Быстрого реагирования на изменения рынка
• Регулярных релизов новых функций каждые 2 недели

Связь с ФГОС 23.05.04 «Эксплуатация железных дорог»

Заключение и выводы для специалиста

1. ГОСТ — не бюрократия, а проверенный путь. Стандарты ГОСТ 34.601-90 и РД 50-680-88 обеспечивают системный подход и снижают риски провала проектов.

2. Архитектура определяет возможности. Монолит подходит для малого бизнеса, микросервисы — для масштабируемых платформ, serverless — для event-driven задач.

3. API — язык общения систем. Без понимания REST API невозможно построить интеграцию между системами ТЛК.

4. Agile/Scrum — стандарт индустрии. Итеративная разработка с регулярными релизами позволяет быстрее реагировать на изменения рынка.

5. BI-аналитика — основа принятия решений. Дашборды с EBITDA, маржинальностью и ABC/XYZ-анализом дают полную картину бизнеса.

Вопросы для самопроверки

1. Какие пять требований ГОСТ РД 50-680-88 к автоматизированным системам вы знаете?

2. В чём различие между монолитной, микросервисной и serverless архитектурой? Когда какая применяется?

3. Какие четыре HTTP-метода REST API вы знаете? Для чего каждый из них?

4. Какие четыре ценности Agile Manifesto вы знаете?

5. Какие компоненты BI-аналитики предоставляет система АРК?