Node-architecture #1. High-Reliability система: теорія

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

                [приклади наведені на Python]

Критерій High-Reliability означає «високу надійність», «витривалість» софта в агресивних умовах. Навіть якщо загублений контакт з датчиками, впав доступ до сховищ, зникло підключення до мережі, відмовила частина модулів самого софту — решта компонентів програми продовжують виконувати свою роботу настільки, наскільки це можливо фізично.

Одне з рішень — проектування програми як сукупності «вузлів». Не плутати з ООП або мікросервісами. Node — це Callable adjective елемент, який має можливість бути запущеним безпосередньо, тобто містить в собі секцію if __name__ == "__main__": … Node не обтяжений залежностями та не заплутаний у зовнішніх зв’язках (coupling). Він автономний настільки ж, наскільки автономна будь-яка команда Python і може використовуватися в складі іншої якоїсь структури, аби співпав API.

• Вузол має зону відповідальності, яка недосяжна зовні. Сутності, що знаходяться в цій області та підпорядковані безпосередньо вузлу, називаються сателітами. Важливо: це не тип, це роль. Сателітом може бути як найпростіша функція print("World of Hell"), так і повноцінний Node, що містить складну багаторівневу структуру
• Для взаємозв’язку вузлів у просторі додатка створюється environment, середовище, що містить спільні розділювані ресурси, як мінімум два компоненти: сховище з функціоналом нормалізації (яке незалежно від типу та виду вхідних даних повертає результат у єдиному обумовленому форматі) та транспорт, здатний прийняти й передати дані між будь-якими вузлами.
• Кожний вузол має сценарій локальної деградації, «дефолтну інструкцію» поведінки у разі відриву від спільного середовища взаємодії, він продовжує виконувати роботу в межах своєї функціональності.
• Important : ніяких горизонтальних зв’язків проміж вузлами. Жоден із вузлів не повинен «припускати чи мати на увазі» наявність іншого вузла та будувати свою роботу, спираючись на очікувану поведінку іншого компонента

Приклад реалізації нода:

import datetime
# --- BUSINESS LOGIC (Doers / Satellites) ---
# Satellites are not aware of buffers or time. Only pure mathematics.
def _sum_processor(data_list):
    """Satellite: Pure Addition Function."""
    return sum(data_list) if data_list else None

def _format_packet(result):
    """Satellite: packing in a standard package."""
    return {
    'timestamp': datetime.datetime.now().isoformat(),
    'payload': result
    }

# --- INTERFACE & CONFIGURATION (Setters / Node Logic) ---
def run_sum_node(buffer_source):
    """
    NODE: 'Adder' node.
    Implements a local degradation scenario.
    """
    # 1. Data retrieval (Environment/Buffer simulation)
    raw_data = buffer_source if isinstance(buffer_source, list) else []
    #2. Calling a satellite (logic)
    calculation = _sum_processor(raw_data)
    # 3. Output normalization (packing)
    # Even if calculation is None, return a structure, not an error.
    return _format_packet(calculation)

# --- BUILDING & RUNNING ---
if __name__ == '__main__':
    # Test 1: Normal
    test_buffer = [10, 20, 30]
    print(f"Normal work: {run_sum_node(test_buffer)}")
    # Test 2: Aggressive environment (no data) — Local degradation
    empty_buffer = None
    print(f"Degraded work: {run_sum_node(empty_buffer)}")

Інша ілюстрація реалізації вузла, більш «описова». Умовний бойовий дрон, споряджений на даний момент штурмовою гвинтівкою NATO.

{
  "node_name": "Right_Arm_Subsystem",
  "role": "SYSTEM_INTEGRATOR",
  "comment": "Top-level control of the right limb",
  "satellites": [
    {
      "name": "Weapon_Unit",
      "role": "COMPLEX_SATELLITE (NODE)",
      "status": "Active",
      "internal_structure": {
        "node_name": "Rifle_Module_MK1",
        "description": "Automatic weapon module",
        "satellites": [
          {
            "name": "Magazine_Slot",
            "role": "COMPLEX_SATELLITE (NODE)",
            "state": {
              "magazine_type": "NATO_Standard_20",
              "inventory": {
                "Armor_Piercing": 200,
                "Incendiary": 52,
                "Standard": 800
              }
            },
            "degradation_protocol": {
              "on_empty": "Signal_Reload_Request",
              "on_jam": "Switch_to_Manual_Eject"
            }
          },
          {
            "name": "Optics_Sentry",
            "role": "SIMPLE_SATELLITE",
            "task": "Barrel angle adjustment based on wind sensors"
          }
        ],
        "degradation_protocol": {
          "on_overheat": "Reduce_Rate_of_Fire",
          "on_magazine_lost": "Lock_Trigger_Safe"
        }
      }
    },
    {
      "name": "Shoulder_Servo",
      "role": "SIMPLE_SATELLITE",
      "task": "Recoil vector compensation"
    }
  ],
  "global_degradation_protocol": {
    "on_limb_loss": "Isolate_Neural_Link",
    "on_power_critical": "Lock_In_Current_Position"
  }
}

• Вкладена автономія: Якщо рівень Weapon_Unit «вистрілено», рівень Right_Arm_Subsystem не падає. Вона переходить у on_limb_loss (ізоляція зв’язків). Він щойно перестав отримувати дані від сателіта, але сам живий.

• Сценарій на будь-який випадок: У кожного рівня свій Default.

• Порожній магазин? Вузол «Зброя» просто не одержить набій, але продовжує відстежувати ціль.
• Зброя перегрілася? Вузол «Рука» продовжує тримати напрямок, але не тисне на спуск.

• Ізоляція складності: Програмісту, який прише логіку Right_Arm_Subsystem, не потрібно знати, скільки бронебійних набоїв в магазині і чи є такі взагалі. Він спілкується лише з Weapon_Unit. Інформація про набої схована за трьома периметрами захисту. Це і є дисциплина кордонів.

Продовжуючи ідею «робота»: якщо він скачає ПДР Японії з усіма їх особливостями, це ніяк не торкнеться функціоналу «правої руки з автоматом». І якщо не скачає, а зависне чи буде змушений ходити пішки — теж. Навіть якщо тіло робота рознесе прямим влученням ракети, у ноді «Права Нога» залишаться сателіти «GPS» та «боді-камера», які продовжать працювати.

Protocol / Interface vs. Рантайм-контракт

Стандартні typing.Protocol або ABC фіксують наявність методів, але не гарантують поведінку системи в агресивному середовищі.

• Protocol (Static/Structural Typing): Декларує, що об’єкт має метод .fire(). Якщо метод не знайдено на етапі виклику або імпорту — додаток генерує AttributeError або не проходить перевірку типів.
• Node Contract: Вузол не просто «обіцяє» наявність методу. Він гарантує результат. Якщо внутрішня логіка (сателіт) не може виконати завдання, Вузол зобов’язаний повернути нормалізовану відповідь згідно зі сценарієм локальної деградації.

Принцип ізоляції: Якщо Protocol — це форма ключа, то Вузол — це шлюз. Шлюз не просто перевіряє форму ключа, він забезпечує автономну роботу відсіку, навіть якщо ключ зламаний або відсутній.

Тип (Type) vs. Роль (Role)

Ключова відмінність в управлінні життєвим циклом та областю видимості.

• Тип — це глобальна ідентичність. Клас Ammunition залишається ним у всіх частинах додатка. Його методи доступні кожному, хто має посилання на об’єкт.
• Роль — це контекстна ідентичність. Один і той же фрагмент коду може виступати в різних ролях залежно від місця в каскаді: — Вузол-Директор: При запуску як оркестратора зовнішньої логіки (наприклад, імпорт сторонніх важких бібліотек).
  • Сателіт: При виклику як внутрішнього ресурсу іншого Вузла.
  • Точка входу: При автономному запуску для самотестування або локальної роботи.

Інкапсуляція vs. Дисципліна кордонів

В ООП інкапсуляція має рекомендаційний або синтаксичний характер (_private, __mangled). У вузловій архітектурі це механічна заборона.

1. Заборона горизонталі: Жоден вузол не може «припускати» наявність сусіда. Обмін інформацією — суворо через Environment (Транспорт/Сховище). Це виключає створення «павутини залежностей», характерної для ООП-проєктів.
2. Герметичність сателітів: Сателіт не має власного API для зовнішнього світу. Спроба викликати сателіт в обхід його Вузла — це порушення протоколу. Вузол є єдиним легальним фільтром, який приймає зовнішнє живлення та розподіляє його між своїми васалами.

Підсумковий тезис

Якщо ООП прагне до повторного використання коду через абстракцію, то Node-architecture прагне до незалежності виконання через ізоляцію.