Критично важливе програмне забезпечення — це категорія, що визначається не складністю, а наслідками відмови. Коли корпоративне програмне забезпечення виходить з ладу, користувачі бачать повідомлення про помилку і чекають виправлення. Коли відмовляє критично важливе ПЗ — бойова система командування та управління, застосунок управління повітряним рухом, контролер медичного пристрою — наслідки можуть включати втрату ситуаційної обізнаності, прийняття неправильних рішень на основі застарілих даних або пряму фізичну шкоду. Архітектура, що запобігає цим відмовам, принципово відрізняється від того, що є достатнім для звичайного програмного забезпечення.

Ця стаття розглядає архітектурні патерни та інженерні підходи, що використовуються в оборонних та інших високоризикових областях для досягнення надійності, доступності та відмовостійкості, яких вимагають місійно-критичні системи.

Чим критично важливе ПЗ відрізняється від корпоративного

Відмінність полягає не в складності функцій або обсязі даних. Критично важливе ПЗ відрізняється від корпоративного за трьома ключовими осями.

Наслідки відмов. Корпоративне ПЗ як правило відмовляє у відновлюваний спосіб: незручність для користувача, відкат транзакції, порушення SLA. Критично важливе ПЗ може відмовляти у спосіб, від якого неможливо відновитися — система злиття сенсорних даних, що втрачає стеження на критичному етапі, не може відновити втрачені дані. Ця асиметрія наслідків означає, що запобігання відмові вартує значно більших інженерних інвестицій, ніж відновлення після неї.

Умови експлуатації. Оборонне ПЗ часто працює в деградованих умовах: системи на транспортних засобах на пересіченій місцевості, розгорнуте обладнання при екстремальних температурах, супутниковий зв'язок з високою затримкою та обмеженою пропускною здатністю. Архітектура повинна враховувати умови середовища, з якими корпоративні системи ніколи не стикаються.

Обмеження реального часу. Багато місійно-критичних систем мають жорсткі вимоги реального часу: дані сенсорів повинні оброблятися протягом визначеного часового вікна, рішення — генеруватися до дедлайну, вихідні сигнали керування — застосовуватися в межах визначеного бюджету затримки. Критично важливе ПЗ з вимогами реального часу повинне дотримуватися дедлайнів детерміновано, а не статистично.

Основні архітектурні патерни

Кілька патернів послідовно з'являються в архітектурах місійно-критичних систем. Вони не є взаємовиключними; зрілі системи зазвичай поєднують кілька патернів для досягнення необхідного профілю надійності.

Активно-активне резервування. У активно-активній конфігурації кілька екземплярів сервісу працюють одночасно, всі обробляють запити та підтримують синхронізований стан. Якщо один екземпляр виходить з ладу, інші продовжують роботу без перерви — немає жодного часового проміжку відмовостійкості, протягом якого запити відхиляються або затримуються. Активно-активна конфігурація забезпечує найвищу доступність, але несе найвищу складність: синхронізація стану між екземплярами є технічно складним завданням, особливо в умовах мережевого розділення.

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

Патерн автоматичного вимикача (Circuit Breaker). Запозичений з електротехніки, цей патерн вирішує специфічний режим відмови: каскадні збої, спричинені компонентом, що намагається зв'язатися з недоступною залежністю, блокується або завершує очікування по таймауту, тим самим знижуючи власну доступність. Автоматичний вимикач моніторить виклики до залежності; коли відмови перевищують поріг, він «відкривається» та негайно повертає помилку або кешовану резервну відповідь замість спроби виклику.

Патерн ізоляції (Bulkhead). Названий на честь водонепроникних перегородок у корпусах суден, що запобігають поширенню затоплення по всьому судну, патерн ізоляції відокремлює компоненти один від одного, щоб відмова одного не вичерпувала ресурси, необхідні іншим. На практиці це зазвичай означає виділення окремих пулів потоків або з'єднань різним підсистемам.

Принцип архітектури: Мета відмовостійкості — не запобігти всім відмовам, що неможливо в реальних умовах експлуатації. Мета полягає в тому, щоб відмови залишалися локальними, а не поширювалися; деградація була поступовою, а не катастрофічною; відновлення — автоматичним або керованим, а не таким, що вимагає ручного втручання під тиском.

Поступова деградація під час перебоїв у мережі

Оборонні системи часто працюють у середовищах, де підключення до центральних систем є переривчастим або відсутнє. Система, спроектована лише для роботи в підключеному стані, повністю відмовить при втраті з'єднання. Місійно-критичні системи повинні мати явні можливості роботи в деградованому режимі — система повинна мати визначену, протестовану поведінку для кожного можливого стану підключення.

Проектування поступової деградації починається з інвентаризації можливостей: які функції вимагають підключення, які можуть працювати з кешованими даними прийнятної давності, а які — повністю в автономному режимі. Ця інвентаризація визначає архітектурні рішення щодо того, які дані повинні реплікуватися локально, які операції можуть бути поставлені в чергу для синхронізації при відновленні підключення, а які вимагають з'єднання і повинні бути явно відключені, а не мовчки відмовляти.

Синхронізація стану після повторного підключення є однією з найскладніших проблем у роботі з відключенням. Коли пристрій повторно підключається після тривалого автономного періоду, він повинен узгодити свій локальний стан зі станом сервера — обробляючи конфлікти, відтворюючи операції в правильному порядку та відкидаючи застарілі дані. Політики вирішення конфліктів повинні визначатися явно на етапі проектування.

Тестування: хаос-інжиніринг, ін'єкція збоїв та стрес-тестування

Архітектура стійкості, яка не була перевірена в умовах відмов, є гіпотезою, а не інженерним фактом. Місійно-критичні системи вимагають суворого тестування режимів відмов — не лише функціонального тестування в нормальних умовах.

Тестування ін'єкцією збоїв навмисно вносить відмови в працюючу систему для перевірки того, що обробка збоїв відповідає специфікації. Це включає введення мережевих затримок і втрати пакетів, аварійне завершення процесів, введення пошкоджених даних та симуляцію апаратних збоїв.

Хаос-інжиніринг розширює ін'єкцію збоїв до середовищ, подібних до виробничих, навмисно вносячи випадкові відмови для виявлення слабких місць, які детерміноване тестування може пропустити. В оборонному контексті хаос-інжиніринг повинен проводитися в репрезентативних тестових середовищах, а не у виробничому.

Стрес-тестування оцінює поведінку системи, коли ресурсні обмеження наближаються або перевищуються. Місійно-критичні системи повинні мати визначену поведінку в умовах навантаження, що виходить за межі нормальних операційних параметрів — явне обмеження навантаження або поступова відмова з відповідним сповіщенням, але не невизначена поведінка.