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

Предыдущие двенадцать тем курса последовательно выстроили все звенья автономного комплекса: в темах 3–5 был рассчитан суточный энергобаланс, подобрана химия аккумуляторов и спроектирована солнечная генерация; в теме 6 определены принципы компонентного ремонта вычислительной платформы и сформирован запас деталей; темы 7–9 обеспечили программную независимость — локальное зеркало пакетов, офлайн-энциклопедии и стратегию резервного копирования с контролем целостности; темы 10–12 дали средства радиосвязи, локальной меш-сети и электромагнитной защиты вводов. Каждое из этих решений было рассчитано, промоделировано симулятором или проверено в пространстве имён операционной системы.

Однако наличие исправного оборудования и корректных конфигурационных файлов не означает, что система готова к работе в условиях изоляции. Наиболее опасная иллюзия при проектировании автономных систем — убеждение, что закупленный и сложенный на стеллаж комплект железа автоматически решает задачу выживания информационного узла ¹. На практике в момент реального обесточивания и обрыва связи выясняется, что пароль от резервного диска хранился в облачном менеджере паролей, шнур с нужным разъёмом питания остался в другом помещении, аккумулятор за полгода хранения без подзаряда деградировал ниже порога срабатывания BMS, а оператор в состоянии стресса и переохлаждения не может вспомнить порядок подъёма локального DNS-сервера.

Эксплуатационная готовность (англ. operational readiness) — это не статическое свойство закупленного оборудования, а непрерывный динамический процесс ². Комплекс работоспособен ровно настолько, насколько отработаны действия оператора в условиях, максимально приближённых к аварийным. Единственный способ доказать готовность системы — провести натурное учение: физически разомкнуть автоматический выключатель ввода внешней сети, отключить магистральный интернет-кабель и зафиксировать по секундомеру, сколько времени займёт подъём каждого уровня деградации, сколько ватт-часов энергии будет израсходовано и какие скрытые дефекты проявятся в процессе.

Настоящая тема объединяет инженерные решения всех слоёв курса в единый регламент эксплуатации. В ней рассматривается структура документов непрерывности, методика проведения четырёхчасовых комплексных учений, психофизиология человека в условиях депривации и холода, календарный график технического обслуживания и замкнутый контур постоянного улучшения по методике инженерной устойчивости (англ. resilience engineering).

Документы непрерывности и операционная готовность

План непрерывности автономного узла

В корпоративной практике стандартом де-факто для обеспечения выживаемости инфраструктуры является стандарт ISO 22301:2019 ³, регламентирующий систему управления непрерывностью бизнеса (англ. Business Continuity Management System, BCMS). В масштабе персонального или полевого автономного узла громоздкие корпоративные регламенты неприменимы, однако заложенный в них принцип сохраняет силу: план обеспечения непрерывности (англ. Business Continuity Plan, BCP) должен отвечать на вопросы «что сохраняем в первую очередь», «кто и что делает при отказе» и «как восстанавливать систему от простого к сложному».

План непрерывности автономного узла представляет собой сжатый документ, связывающий матрицу сценариев (А, Б, В, Г из темы 1) со шкалой уровней деградации (0–4). Он не содержит рассуждений и теоретических выкладок. Его основа — строгая матрица приоритетов и условий перехода:

План непрерывности регламентирует три критических состояния узла:

1. Переход в автономный режим: последовательность отключения неприоритетных потребителей (инверторы 230 В, внешняя подсветка, фоновые вычислительные задачи) для сохранения емкости накопителя.
2. Удержание деградированного состояния: минимально допустимый профиль энергопотребления, обеспечивающий заданный срок живучести (например, 72 часа для сценария Б при температуре −20 °C).
3. Холодный запуск (англ. cold start): пошаговая процедура развертывания узла из полностью обесточенного состояния при разрушенной локальной конфигурации ⁴.

Одностраничные карточки процедур (SOP)

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

Для оперативного управления аварийной ситуацией вводится стандарт одностраничных стандартных операционных процедур (англ. Standard Operating Procedure, SOP) ⁵. Карточка SOP представляет собой ровно один лист формата А4, содержащий исчерпывающие инструкции для конкретного временного горизонта:

• Карточка «Первые 15 минут» (SOP-15M): локализация инцидента и выход на Уровень 0. Проверка физической безопасности (запах гари, искрение, залитие), изоляция поврежденных кабельных линий, перевод электропитания на защищенную низковольтную шину 12 В постоянного тока, включение терминала аварийной консоли, замер входного напряжения мультиметром.
• Карточка «Первый час» (SOP-1H): стабилизация энергобаланса и подъем Уровней 1 и 2. Включение локального хранилища, запуск системных демонов DNS (unbound) и службы точного времени (chrony), проверка локального IP-адреса, запуск локального веб-сервера справочников Kiwix, подтверждение доступа к документации с резервного клиентского устройства.
• Карточка «Первые сутки» (SOP-24H): переход на долговременный циклический режим. Настройка расписания сеансов радиосвязи (например, 10 минут в начале каждого четного часа), согласование работы зарядных контроллеров MPPT и дизель-генератора, проведение контрольных замеров температуры ячеек АКБ, выполнение инкрементального резервного копирования критических баз данных.

+-----------------------------------------------------------------------+
| КАРТОЧКА SOP-15M: АВАРИЙНЫЙ ПУСК И ВЫХОД НА УРОВЕНЬ 0 (ВЕРСИЯ 2.1)    |
+-----------------------------------------------------------------------+
| 1. БЕЗОПАСНОСТЬ: Убедиться в отсутствии КЗ и запаха гари.             |
|    - Перевести тумблер QS1 (Ввод сети 230 В) в положение «ОТКЛ».       |
| 2. ПИТАНИЕ: Перевести переключатель резерва SA1 в положение «АКБ».    |
|    - Замерить вольтметром напряжение на клеммах контрольной шины ХТ1:  |
|      * НОРМА (LiFePO4 4S): 12,8...13,4 В.                             |
|      * КРИТИЧЕСКИЙ РАЗРЯД: менее 11,8 В -> НЕМЕДЛЕННО ОТКЛЮЧИТЬ ВСЁ.  |
| 3. КОНСОЛЬ: Замкнуть автомат SF2 «Микрокомпьютер узла».               |
|    - Подключить консольный кабель USB-UART к порту ttyUSB0.            |
|    - Запустить терминал: picocom -b 115200 /dev/ttyUSB0                |
| 4. ПРОВЕРКА УРОВНЯ 0:                                                 |
|    - Убедиться в наличии приглашения: "polygon-node login:"           |
|    - Ввести аварийный логин "operator", пароль из пакета N 1.         |
| 5. ТЕЛЕМЕТРИЯ: Зафиксировать в журнале точное время T_start и ток I_0.|
+-----------------------------------------------------------------------+

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

Документы оперативного реагирования подчиняются жестким требованиям устойчивости к внешней среде. Если инструкция по восстановлению сервера лежит на диске этого же сервера — системы не существует ¹. Документы непрерывности оформляются с учетом следующих правил:

1. Физическая автономность: все карточки процедур (SOP-15M, SOP-1H, SOP-24H), схемы кабельной разводки, распиновки разъемов, таблицы соответствия предохранителей и аварийные пароли распечатываются на плотной бумаге, ламинируются матовой пленкой (для исключения бликов от налобного фонаря) и хранятся в водонепроницаемом тубусе непосредственно внутри защитного кейса узла.
2. Бинарность формулировок: в аварийных карточках запрещены фразы «при необходимости», «отрегулируйте оптимально», «попытайтесь настроить». Каждое действие описывается строго бинарно: «Установить переключатель SA2 в положение 1», «Проверить свечение зеленого светодиода HL1: если горит — перейти к шагу 4, если не горит — заменить вставку FU3 на 5 А из ЗИП».
3. Самодостаточность нотации: в карточках не допускаются ссылки на внешние сетевые ресурсы или команды вида apt install, требующие интернета. Все используемые утилиты, скрипты и конфигурационные файлы приводятся с абсолютными путями в локальной файловой системе (/opt/polygon/bin/healthcheck.sh).

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

Иерархия учений: от разбора за столом к натурному отключению

Регламенты и карточки процедур бесполезны без регулярной практики их отработки. Практика аварийной готовности строится по принципу постепенного усложнения ⁶:

+--------------------------------------------------------------+
| 3. Полномасштабное натурное учение (Full-Scale Simulation)   |
|    - Физическое отключение сети и питания на 4..24 ч         |
|    - Работа в реальных климатических условиях                |
+------------------------------^-------------------------------+
                               |
+------------------------------+-------------------------------+
| 2. Частное функциональное учение (Functional Drill)          |
|    - Отработка одного звена: пуск ДВС, замена диска, radio   |
|    - Проверка хронометража конкретной карточки SOP           |
+------------------------------^-------------------------------+
                               |
+------------------------------+-------------------------------+
| 1. Кабинетный разбор за столом (Tabletop Exercise)           |
|    - Пошаговая прокрутка сценария на бумаге без воздействия  |
|    - Выявление логических тупиков, отсутствия ЗИП и паролей  |
+--------------------------------------------------------------+

Кабинетный разбор (англ. tabletop exercise) проводится перед любым натурным испытанием. Операторы и проектировщики собираются за столом, вводят случайную вводную из матрицы отказов (например: «Сценарий Б, 03:00 ночи, температура −22 °C, отказ системного SSD основного узла») и пошагово воспроизводят действия по имеющимся документам. На этапе настольного разбора отсеивается до 70 % грубых системных ошибок: обнаруживается, что запасной накопитель не отформатирован, образ восстановления записан на флешку устаревшей версии, а ключ шифрования LUKS утерян.

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

Четырёхчасовое комплексное учение: почему четыре часа

Базовое натурное учение курса длится 4 часа. Это не физическая константа и не норма стандарта, а длительность сценария А из темы 1: отказ внешней сети и питания при доступной сотовой связи, 4 ч (C-01-01). Учение воспроизводит заданный сценарий целиком, поэтому его длительность берётся из постановки (teacher/polygon.json, сценарий А — 4 ч, C-13-03), а не подбирается так, чтобы «успели проявиться эффекты». Сценарии Б (72 ч) и В (336 ч) учением целиком не проверяются: для них учение даёт измеренный расход за 4 часа, который подставляется в модель energy.py вместо оценки профиля.

Из длительности следует и верхняя граница норматива: последний уровень восстановления (L4, внешняя связь) должен быть достигнут не позднее конца сценария, то есть за 240 мин. Тепловые и электрохимические эффекты, которые проявляются только через несколько часов работы, в четырёхчасовом учении могут и не проявиться; это ограничение учения, а не его обоснование.

Учение начинается с вводной: питание от сети отключается автоматом, внешний сетевой кабель отсоединяется. Оператор действует по карточкам SOP и ведёт журнал событий.

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

В ходе учения фиксируются три группы метрик; формат после-учебного отчёта заимствован из HSEEP ⁶ (раздел «Отчёт и план улучшений»).

1. Время восстановления уровней (фактический RTO). Нормативы курса — одни и те же в теме 13, в протоколе учения и в курсовом проекте (C-13-05):

2. Расход энергии. Фактический расход сравнивается с моделью:

\delta_E = \frac{E_{\text{факт}} - E_{\text{модель}}}{E_{\text{модель}}} \cdot 100\,\%

Модель для сценария А — energy.py --profile drill_scenario_a: 68,44 Вт·ч из батареи за 4 ч (C-13-01). Принятые в курсе зоны (C-13-02): |δ_E| ≤ 15 % — норма; 15–30 % — замечание (Minor), разбор обязателен; больше 30 % — существенный дефект (Major): модель узла не описывает реальность, и все расчёты автономии по ней недостоверны. Это условие курса, а не норма стандарта; его смысл — модель с погрешностью больше 15 % уже даёт ошибку автономии сценария Б больше полусуток.

3. Дефекты. Каждое отклонение записывается с категорией:

• критический (Critical): уровень не может быть достигнут — нет кабеля, пароля, исправного носителя;
• существенный (Major): уровень достигнут с превышением норматива RTO или |δ_E| > 30 %;
• незначительный (Minor): неудобство, неточная маркировка, недостающий второстепенный инструмент; сюда же — δ_E в зоне 15–30 %.

Протоколирование и журнал событий

Память в учении не используется: каждое действие фиксируется в журнале с отметкой времени. В П0 журнал ведёт drill_timer.py из окружения ЛР 13; бумажный журнал переносится в него флагом --at.

[00:00:00] [ALERT] Вводная: сеть 230 В отключена, внешний Ethernet разорван.
[00:03:12] [POWER] Нагрузка на батарее, U_bus = 13,28 В.
[00:09:20] [LEVEL] L0: консоль доступна.
[00:21:15] [LEVEL] L1: схема узла прочитана с локального носителя.
[00:41:10] [LEVEL] L2: dig @10.13.0.10 wiki.polygon.internal — ответ получен.
[01:15:00] [FAULT] MAJOR: chrony не принимает время от RTC.
[02:00:00] [RADIO] L4: пакет телеметрии передан (LoRa 868,1 МГц).
[04:00:00] [STOP]  Учение завершено, расход — по журналу power_log.csv.

Журнал — пример формата, а не результат измерения.

Ветка учения для П0: ноутбук на батарее

Читатель без Полигона на железе проводит учение на ноутбуке: ноутбук отключается от сети и 4 часа работает от своей батареи, выполняя карточки SOP над учебным узлом из node_up.sh (каталог с конфигурацией DNS, времени, документацией и архивом). Расход измеряется контроллером батареи ноутбука: ядро Linux публикует energy_now (мкВт·ч) или charge_now (мкА·ч) и voltage_now в /sys/class/power_supply/BAT*/, а upower -d показывает те же величины. Скрипт power_log.py record опрашивает их с заданным периодом и пишет CSV; power_log.py analyze считает расход двумя способами — по счётчику энергии и интегрированием мгновенной мощности.

Погрешность такого измерения оценивается явно. Дискретность счётчика контроллера (у многих ноутбуков — десятки мВт·ч) даёт ошибку в пределах одного-двух шагов. Интервал опроса добавляет ошибку интеграла мощности, если нагрузка меняется быстрее опроса; расхождение двух способов — оценка этой ошибки. Абсолютная калибровка контроллера неизвестна, поэтому результат П0 — расход ноутбука в тех же условиях от учения к учению, а не точная энергия. Для сравнения с моделью узла Полигона в окружении есть синтетический журнал ваттметра sample_power_log.csv: по нему расход за 4 ч — 72,05 Вт·ч, а δ_E относительно модели — +5,3 % (C-13-06, C-13-07). Журнал построен не моделью energy.py: в нём есть два неучтённых потребителя, которые нужно найти по почасовому расходу (ЛР 13).

Человеческий фактор и психология изоляции

Когнитивные искажения и физиология стресса

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

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

• Сужение поля зрения (туннельное зрение): оператор концентрируется на одной частной проблеме (например, не мигает индикатор на сетевой карте) и полностью упускает из виду общее состояние системы (например, то, что напряжение на аккумуляторе упало ниже 11 В).
• Сужение рабочей памяти: под стрессом человек хуже удерживает длинные последовательности действий ⁸. Отсюда требование к карточкам: каждая команда выписана целиком и копируется, а не собирается по памяти; длинный конвейер из awk, sed и nft в карточку не попадает — его заменяет проверенный скрипт.
• Тремор и ухудшение мелкой моторики: на холоде или при выбросе адреналина точность движений пальцев резко падает. Вставить micro-SIM карту в щелевой разъем или припаять оторвавшийся SMD-диод становится практически невыполнимой задачей. Отсюда следует фундаментальное требование к конструкции узла: никаких мелких разъемов и винтов под шлиц 1,5 мм на аварийных узлах коммутации; только надежные винтовые клеммники под стандартную отвертку PH2 или рычажные зажимы WAGO.

Героизм как признак плохого проекта

В популярной культуре преодоление аварий ассоциируется с подвигом: оператор, не спавший двое суток, на морозе голыми руками перебирает генератор и спасает узел от отключения. В системной инженерии и теории устойчивости (resilience engineering) героизм однозначно классифицируется как дефект проектирования ¹⁹.

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

• В системе не были предусмотрены автоматические защиты от разряда (LVD);
• Отсутствовали понятные пошаговые инструкции, рассчитанные на человека в полубессознательном состоянии;
• Время автономного удержания было рассчитано впритык без запаса на ошибку;
• Допущена единая точка отказа в лице единственного носителя ключевых знаний (SPOF-человек).

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

Организация сменности и гигиена сна

В сценариях длительной изоляции (сценарии Б и В длительностью от 3 суток до 2 недель) критическим фактором становится график дежурств. Длительное бодрствование и недосып снижают скорость реакции и повышают вероятность ошибки ⁸; количественные оценки зависят от исследования и задачи, и курс их не приводит. Для проекта существенно другое: график дежурств — это проектное решение, которое записывается в план непрерывности и проверяется учением, а не оставляется на усмотрение дежурного.

Для автономного узла с постоянным дежурством устанавливаются правила гигиены труда:

1. График смен. В курсовом проекте график задаётся как условие варианта; в примерах курса для двух операторов принята схема 6/6 (смена 6 часов, отдых 6 часов). Это условие задачи, а не норма: её пригодность проверяется по журналу учения — растёт ли к концу смены время выполнения одинаковых карточек.
2. Место для сна — в тёмном отапливаемом объёме вне помещения генератора; дежурство «вполглаза» в шуме не считается отдыхом в графике.
3. Формализованная передача смены: заступающий оператор принимает узел по чек-листу приема-передачи (англ. handover checklist):
   • Фактическое напряжение на шине АКБ и текущий ток потребления;
   • Запас топлива в баке и расходных канистрах;
   • Наличие непрочитанных сообщений в очередях пакетного радиообмена;
   • Отметки в журнале ТО о выполненных операциях за прошедшую смену.
4. Принцип четырех глаз (англ. four-eyes principle): любые необратимые деструктивные операции (ручная коммутация силовых силовых кабелей напряжением свыше 48 В, переключение полярности зарядных устройств, стирание или форматирование разделов на резервных накопителях) выполняются только при перекрестном контроле второго человека, даже если один из них имеет наивысшую квалификацию.

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

Календарь регламентных работ

Любая автономная система, оставленная без регулярного профилактического обслуживания, непрерывно деградирует. Конденсаторы в блоках питания теряют емкость из-за высыхания электролита, контакты реле окисляются, ячейки аккумуляторов теряют баланс по напряжению, моторное масло в резервном генераторе расслаивается и окисляется, а файлы на flash-накопителях подвергаются утечке заряда в плавающих затворах (англ. data retention failure) ¹⁰.

Для предотвращения «тихих» отказов вводится календарный регламент технического обслуживания (ТО) с разделением на четыре интервала:

Еженедельное ТО (регламентное время: 15 минут)

• Измерение напряжения разомкнутой цепи (НРЦ) аккумуляторного блока;
• Визуальный контроль отсутствия вздутий ячеек LiFePO4 и потеков электролита;
• Проверка доступного свободного места на системных и резервных накопителях (df -h);
• Анализ журналов ядра на предмет появления дисковых ошибок I/O (dmesg | grep -iE 'error|ata|nvme').

Ежемесячное ТО (регламентное время: 1 час)

• Измерение эквивалентного последовательного сопротивления (ESR) аккумулятора методом двух нагрузок (тема 4);
• Контроль баланса ячеек сборки через интерфейс BMS: разбег напряжений не должен превышать 15 мВ в заряженном состоянии;
• Тестовый холодный пуск бензинового генератора: работа на холостом ходу 5 минут, затем под активной нагрузкой 500 Вт в течение 15 минут;
• Тестовая выборочная проверка чтения случайного архива резервной копии restic.

Ежеквартальное ТО (регламентное время: 3 часа)

• Полная верификация целостности архивов и томов восстановления с помощью утилиты par2 (par2 verify *.par2);
• Измерение коэффициента стоячей волны (КСВ) всех подключенных антенно-фидерных трактов портативным анализатором или встроенным измерителем трансивера (норма: КСВ ≤ 1,5 на рабочих частотах);
• Протяжка винтовых силовых клемм динамометрической отверткой с нормированным усилием (для предотвращения ослабления контакта из-за температурных колебаний);
• Проверка срабатывания и целостности варисторов, TVS-диодов и газовых разрядников в щите защиты вводов (тема 12).

Ежегодное ТО (сезонная консервация/расконсервация, регламентное время: 1–2 дня)

• Контрольный цикл разряда-заряда АКБ стабилизированным током 0,2C до напряжения отсечки (10,0 В для 12-вольтовой LFP-сборки) на разрядном стенде для измерения фактической остаточной емкости в ампер-часах;
• Замена моторного масла и свечи зажигания в генераторе независимо от наработки в моточасах;
• Ротация запасов топлива: слив старого бензина в транспортное средство, заливка свежего топлива с добавлением стабилизатора углеводородов;
• Синхронизация и полное обновление локальных зеркал репозиториев (Debian/Ubuntu), скачивание актуальных дампов Wikipedia/Kiwix в формате ZIM;
• Проведение комплексного 4-часового учения с полным обесточиванием.

Ревизия химических источников тока

Химический источник тока — наиболее дорогой, тяжелый и уязвимый элемент автономного узла. В теме 4 было доказано, что для литий-железо-фосфатных аккумуляторов (LiFePO4) напряжение разомкнутой цепи практически не зависит от степени заряда (SoC) в диапазоне от 20 % до 80 % (напряжение держится на уровне 3,25–3,30 В на ячейку).

Поэтому регулярный контроль состояния батареи не может ограничиваться измерением напряжения вольтметром. В регламент ТО закладывается измерение внутреннего сопротивления ячеек R_int методом двух нагрузок:

R_{\text{int}} = \frac{U_1 - U_2}{I_2 - I_1} \quad [\text{Ом}]

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

Верификация резервных копий и данных

Резервная копия, восстановление из которой не проверялось, не может считаться рабочей (тема 9). Проверка восстановления и журнал её результатов — такие же записи журнала обслуживания, как замер батареи; требования к журналам как к доказательству — в ¹¹. Хранение данных на автономном узле подвержено специфическим рискам:

• «Битовая гниль» (англ. bit rot): деградация диэлектрика в ячейках NAND flash или размагничивание доменов HDD;
• Ошибки оператора при ручном копировании;
• Повреждение метаданных файловых систем при аварийных отключениях питания.

Регламент ТО требует не просто проверки успешности завершения скрипта бэкапа (exit code 0), а сквозной верификации. Используется двухуровневая схема защиты:

1. Контроль избыточности через PAR2 (Parchive): для каждого критического архива создаются файлы контрольных блоков с избыточностью 10–15 %:

   par2create -r10 -n1 /backup/archive_2026_10.tar.gz
   

   В ходе квартального ТО запускается процедура верификации:

   par2verify /backup/archive_2026_10.tar.gz.par2
   

   В случае повреждения секторов носителя утилита автоматически восстанавливает исходный файл без обращения к сетевым источникам.
2. Тестовое развертывание в чистую среду: раз в полгода резервный образ системного диска разворачивается в изолированную виртуальную машину QEMU/KVM скриптом, не имеющим доступа к рабочей сети. Считается подтвержденным только тот бэкап, из которого виртуальная машина успешно загрузилась до приглашения авторизации и отдала тестовый HTTP-запрос к локальной базе данных.

Инвентарный журнал узла

Все изменения аппаратной конфигурации, результаты замеров, ремонты и инциденты фиксируются в едином физическом документе — Инвентарном журнале узла (англ. site logbook).

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

Типовая структура записи в журнале ТО:

Дата/Время: 2026-11-15 10:30 UTC
Вид ТО: Ежемесячное регламентное обслуживание.
Оператор: Смирнов А. В.
1. АКБ сборка 4S LiFePO4 100 А·ч:
   U_нрц = 13.25 В. Баланс ячеек: [3.312, 3.315, 3.310, 3.314] В (дельта = 5 мВ).
   Замер ESR (нагрузки R1=2.0 Ом, R2=0.5 Ом): R_int = 2.4 мОм на сборку. Норма.
2. Генератор Huter DY3000L:
   Пуск со 2-й попытки (ручной стартер). Время прогрева 3 мин.
   Напряжение под нагрузкой 1.2 кВт (ТЭН) = 224 В, частота 50.8 Гц.
   Уровень масла в норме. Наработка: +0.4 моточаса (всего: 42.6 м/ч).
3. Верификация данных:
   restic check --read-data-subset=10%: SUCCESS. Ошибок нет.
Замечания/ЗИП: требуется пополнить запас моторного масла SAE 10W-30 (остаток 0.5 л).
Подпись: [подпись]

Цикл постоянного улучшения и анализ инцидентов

Анализ инцидентов без поиска виноватых (Blameless Postmortem)

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

Если человек совершил ошибку (например, подключил аккумулятор с переполюсовкой или удалил рабочий конфигурационный файл), наказание оператора приводит лишь к тому, что в следующий раз сбои будут скрываться до серьёзных последствий. Культура открытого разбора (англ. blameless postmortem), сформулированная в концепции Just Culture (Деккер ¹³, Оллспоу ¹²), базируется на следующих постулатах:

• Человек принципиально несовершенен, подвержен усталости и стрессу;
• Ошибка оператора — это не первопричина аварии, а симптом плохой конструкции системы;
• Если кабель можно воткнуть с неправильной полярностью — инженер обязан был применить ключ на разъеме (например, разъем Anderson Powerpole с механической блокировкой переполюсовки);
• Если критический файл можно случайно удалить одной командой rm — система обязана иметь права доступа только для чтения или механизм снапшотов файловой системы.

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

Методология анализа первопричин: диаграмма Исикавы и метод «Пяти почему»

Для поиска глубинных системных корней сбоя применяется техника «Пяти почему» (англ. Five Whys) ¹⁴. Рассмотрим реальный пример анализа сбоя, произошедшего в ходе учебного развертывания:

Проблема: Во время 4-часового учения автономный узел не смог поднять Уровень 2 в отведенный 1 час (RTO превышен на 45 минут) из-за падения DNS-сервера unbound.

1. Почему упал unbound? — При старте сервис сообщил об ошибке разбора конфигурационного файла /etc/unbound/unbound.conf.
2. Почему файл конфигурации оказался некорректным? — В нем была указана директива перенаправления запросов к вышестоящему DNS-серверу 1.1.1.1, который был недоступен из-за физического отключения интернета, а локальная зона не была объявлена авторитарной (auth-zone).
3. Почему файл содержал внешние адреса в автономной системе? — Конфигурация была скопирована из лабораторного стенда с доступом в интернет за два дня до учения без предварительного тестирования в изолированном окружении.
4. Почему непроверенная конфигурация попала на боевой узел? — В регламенте подготовки к учению отсутствовал шаг предварительной верификации манифеста профиля узла скриптом валидации.
5. Почему отсутствовал шаг валидации? — Разработчик профиля посчитал синтаксическую проверку unbound-checkconf достаточной и не учел, что синтаксически корректный конфиг может содержать фатальные скрытые зависимости от внешних сетевых сервисов.

Системное исправление: В репозиторий автономного профиля добавлен обязательный pre-commit хук, запускающий тестовый контейнер в сетевом пространстве имен unshare -n без шлюза по умолчанию и проверяющий разрешение локальных имен при полностью изолированной петле обратной связи. Наказывать оператора или автора конфига бессмысленно — внедрен технический барьер, исключающий человеческую забывчивость.

После-учебный отчёт и план улучшений

HSEEP ⁶ — американская методика организации учений — завершает каждое учение двумя документами: после-учебным отчётом (англ. after-action report, AAR) и планом улучшений (англ. improvement plan, IP) (C-13-10). Курс берёт эту пару без бюрократической части. AAR содержит: цель и сценарий учения; метрики (RTO по уровням, δ_E, дефекты по категориям); что сработало; что не сработало и почему (разбор без поиска виноватых, в практике эксплуатации — postmortem ⁷). IP — таблица мер: дефект, мера, ответственный, срок, критерий закрытия. Мера считается закрытой только после проверки в следующем учении. drill_timer.py --export-report формирует протокол с разделом AAR/IP по журналу событий.

Динамика метрик от учения к учению

Одно учение показывает состояние; ряд учений показывает, улучшается ли система. Метрики каждого учения сводятся в трендовую таблицу:

Таблица — учебный пример (trend_example.csv в окружении ЛР 13), а не результат реальных учений. Критерий «система улучшается», принятый в курсе: в последнем учении нет критических дефектов; ни один RTO не ухудшился относительно предыдущего учения, а превышения норматива сокращаются; число существенных дефектов не растёт; |δ_E| не растёт; число открытых мер IP не растёт. Для примера все пять условий выполнены, и drill_trend.py выдаёт вердикт «улучшается», а L2 последнего учения — 52 мин при нормативе 60 (C-13-08). Критерий нарочно строгий: одно ухудшение отменяет вердикт и требует разбора.

Ротация ролей

Учение проверяет не только систему, но и то, что её может восстановить любой член команды. Поэтому роли — руководитель учения (вносит вводные и скрытые дефекты), оператор (действует по карточкам), наблюдатель (ведёт журнал и хронометраж) — меняются от учения к учению по кругу. Если RTO растёт, когда оператором становится другой человек, дефект не в человеке, а в карточке: она опирается на знание, которого в ней нет. Ротация — прямое средство против «человека — единой точки отказа» из подраздела о героизме. drill_timer.py --roles записывает распределение ролей в протокол, чтобы тренд можно было разложить по составу смены.

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

Концепция инженерной устойчивости (resilience engineering) Эрика Холлнагеля ² описывает систему как замкнутый кибернетический контур из четырех способностей:

1. Предвидеть (Anticipate): анализ потенциальных угроз до их возникновения. Разработка матрицы сценариев, расчет профилей энергопотребления в energy.py, моделирование скин-эффекта и бюджета радиолиний.
2. Отслеживать (Monitor): непрерывный сбор фактов о текущем состоянии. Датчики напряжения, тока, температуры, демоны мониторинга дисков и сервисов, регулярные записи в журнале ТО. Отслеживание фиксирует приближение к границам устойчивости до отказа.
3. Реагировать (Respond): активация формализованных процедур в момент возмущения. Переход на аварийное питание, развертывание по карточкам SOP, локализация дефектов.
4. Учиться (Learn): преобразование опыта реальных инцидентов и плановых комплексных учений в изменения проектных моделей, аппаратной компоновки и регламентов.

Система, лишённая контура «Учиться», повторяет один и тот же сценарий аварии.

Числовой пример: энергобаланс четырёхчасового учения

Разберём до последней цифры расход энергии в учении по сценарию А для узла Полигона и сравним его с журналом ваттметра.

Исходные параметры

Батарея Полигона — LiFePO4 100 А·ч × 12,8 В, DoD 0,8, полезная энергия 1024 Вт·ч (teacher/polygon.json). Потребители питаются от шины 12 В через преобразователи с КПД 0,90. Внешней генерации во время учения нет. Профиль нагрузки учения — файл teacher/sim/profiles/drill_scenario_a.csv с шагом 1 минута:

• базовый режим, все 4 часа: микрокомпьютер 6,5 Вт, коммутатор 2,5 Вт, приём LoRa 0,3 Вт, индикация 0,7 Вт — итого 10,0 Вт со стороны потребителей;
• первые 15 минут каждого часа добавляются накопитель SSD 2,5 Вт, поиск в Kiwix 8,0 Вт и передатчик 11,1 Вт — итого +21,6 Вт.

Мощности потребителей — оценки профиля для примера, а не измерения; в проекте их заменяют замеры ЛР 3.

Расчёт по модели

Энергия со стороны потребителей: 10,0 Вт · 4 ч + 21,6 Вт · 1 ч = 40,0 + 21,6 = 61,6 Вт·ч (C-13-04). Из батареи с учётом КПД преобразователей: 61,6/0,90 = 68,44 Вт·ч (C-13-01). Тот же результат даёт модель:

python3 teacher/sim/energy.py --profile drill_scenario_a --scenario А --eta-discharge 0.9 --json

{"hours": 4.0, ..., "load_wh": 61.6, ..., "battery_out_wh": 68.44, ..., "end_soc": 0.9332, ...}

К концу учения батарея сохраняет 93,3 % полезной энергии (C-13-09): 1 − 68,44/1024 = 0,9332. Учение сценария А, таким образом, почти не расходует запас, и его ценность — в измерении профиля и времени восстановления, а не в проверке ёмкости.

Сравнение с журналом и разбор расхождения

Журнал sample_power_log.csv в окружении ЛР 13 — синтетический: он имитирует ваттметр на шине Полигона и построен не моделью energy.py, а отдельным генератором с двумя потребителями, которых в профиле нет. Расход по счётчику — 72,05 Вт·ч, по интегралу мгновенной мощности — 72,22 Вт·ч; расхождение способов 0,17 Вт·ч при шаге счётчика 0,05 Вт·ч (C-13-06).

Отклонение от модели: (72,05 − 68,44)/68,44 · 100 % = +5,3 % (C-13-07) — в зоне нормы. Норма не означает «объяснять нечего»: 3,61 Вт·ч расхождения должны быть разложены на причины полностью. Почасовой расход (17,55; 17,50; 18,50; 18,50 Вт·ч) показывает ступеньку +1,0 Вт·ч в час начиная с третьего часа — потребитель мощностью 1,0 Вт, включившийся через 2 ч (2,0 Вт·ч). Оставшиеся 3,61 − 2,0 = 1,61 Вт·ч равномерно распределены по 4 часам — это постоянный потребитель около 0,4 Вт (1,6 Вт·ч). Сумма 2,0 + 1,6 = 3,6 Вт·ч объясняет расхождение в пределах дискретности счётчика. В ЛР 13 этот разбор выполняется по журналу, а ответ сверяется с генератором после заполнения журнала работы.

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

Что эта модель не учитывает

1. Профиль — оценка. Мощности потребителей в drill_scenario_a.csv заданы, а не измерены; температурная зависимость потребления не моделируется. Следствие: первое учение почти всегда даёт расхождение, и его разбор уточняет профиль.
2. Только сценарий А. Учение 4 ч не проверяет многосуточные эффекты сценариев Б и В: саморазряд, холод, деградацию батареи. Следствие: автономия Б и В по-прежнему рассчитывается моделью, учение лишь уточняет её вход.
3. Человек. Метрики RTO зависят от состава и усталости смены; одно учение не отделяет свойство системы от свойства оператора. Следствие: выводы делаются по тренду нескольких учений с ротацией ролей.
4. Контроллер батареи ноутбука в П0 не калиброван. Следствие: в ветке П0 сравниваются учения между собой, а не с моделью узла Полигона.

Итоги темы

Готовность автономного узла подтверждается не составом оборудования, а учением по заданному сценарию с измеренными метриками. План непрерывности связывает сценарии темы 1 с уровнями деградации L0–L4 и их нормативами RTO (15, 30, 60, 120 и 240 мин); карточки SOP на 15 минут, час и сутки — интерфейс между системой и уставшим человеком без сети, поэтому они бумажные, одностраничные и не содержат внешних зависимостей.

Четырёхчасовое учение воспроизводит сценарий А целиком: его длительность — условие задачи, а не физическая константа. Учение измеряет три вещи: время восстановления каждого уровня, расход энергии относительно модели energy.py и число дефектов по категориям. Расхождение расхода в пределах 15 % — норма, но и оно разбирается до конца: в числовом примере 3,6 Вт·ч расхождения полностью разложены на два неучтённых потребителя. В ветке П0 то же учение проводится на ноутбуке с батареей, а расход берётся из /sys/class/power_supply с явной оценкой погрешности.

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

Учение заканчивается отчётом AAR и планом улучшений IP, мера закрывается только проверкой в следующем учении. Ряд учений сводится в трендовую таблицу, и система считается улучшающейся, только если не ухудшилась ни одна метрика. Календарь обслуживания и журнал узла поддерживают состояние между учениями: эталонные замеры батареи, проверка восстановления данных, ревизия защиты вводов. Вместе они замыкают цикл «предвидеть — отслеживать — реагировать — учиться».

Литература

1. Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. — Ashgate, 2014.
2. Hollnagel E., Woods D. D., Leveson N. Resilience Engineering: Concepts and Precepts. — Ashgate, 2006.
3. ISO 22301:2019. Security and resilience — Business continuity management systems — Requirements. — ISO, 2019.
4. NIST Special Publication 800-34 Rev. 1. Contingency Planning Guide for Federal Information Systems. — NIST, 2010.
5. NASA SP-2016-6105 Rev 2. NASA Systems Engineering Handbook. — NASA, 2016.
6. Homeland Security Exercise and Evaluation Program (HSEEP). — FEMA, 2020.
7. Beyer B., Jones C., Petoff J., Murphy N. R. (eds.) Site Reliability Engineering: How Google Runs Production Systems. — O'Reilly, 2016.
8. Reason J. Human Error. — Cambridge University Press, 1990.
9. Dekker S. The Field Guide to Understanding 'Human Error'. — Ashgate, 2014.
10. Linden D., Reddy T. B. Handbook of Batteries. 3rd ed. — McGraw-Hill, 2002.
11. Chuvakin A., Schmidt K., Phillips C. Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management. — Syngress, 2012.
12. Allspaw J. Blameless PostMortems and a Just Culture. — Code as Craft, Etsy, 2012. https://codeascraft.com/2012/05/22/blameless-postmortems/
13. Dekker S. Just Culture: Balancing Safety and Accountability. 3rd ed. — CRC Press, 2016.
14. Ohno T. Toyota Production System: Beyond Large-Scale Production. — Productivity Press, 1988.

Дополнительные материалы

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

1. В чем заключается фундаментальная разница между классической надёжностью (reliability) и эксплуатационной готовностью (operational readiness) автономной системы?
2. Почему план непрерывности (BCP) не должен содержать подробных теоретических обоснований и ссылок на внешние стандарты? Для кого и в каких условиях он пишется?
3. Каким требованиям должна удовлетворять одностраничная стандартная операционная процедура (SOP) для обеспечения ее безошибочного выполнения оператором в темноте при температуре −20 °C?
4. Почему временной горизонт процедур разделен именно на 15 минут, 1 час и 24 часа? Какие процессы в аппаратных и программных подсистемах определяют эти границы?
5. Что такое «кабинетный разбор за столом» (tabletop exercise)? Почему натурное учение проводят только после него?
6. Почему учение по сценарию А длится 4 часа и что учение такой длительности не может проверить для сценариев Б и В?
7. Перечислите физиологические и когнитивные изменения человека под воздействием острого стресса и переохлаждения. Как эти изменения должны учитываться в конструкции разъемов и щитов питания?
8. Почему в методологии Resilience Engineering синдром «героизма» оператора считается признаком конструкторского дефекта системы?
9. Какие четыре способности формируют адаптивный контур устойчивости Эрика Холлнагеля? Как данные протокола учения замыкают этот контур на этап проектирования?
10. Каким образом культура открытого разбора инцидентов (blameless postmortem) стимулирует операторов сообщать о скрытых дефектах и собственных ошибках?
11. В чем состоит методология анализа первопричин методом «Пяти почему» (Five Whys)? Покажите разницу между непосредственной причиной сбоя и системной первопричиной.
12. Почему измерение напряжения разомкнутой цепи (НРЦ) вольтметром не дает объективной информации о степени износа ячеек LiFePO4? Какой параметр батареи измеряется методом двух нагрузок?
13. Что входит в после-учебный отчёт (AAR) и план улучшений (IP) и когда мера плана считается закрытой?
14. Какой критерий «система улучшается» принят в курсе и почему одно ухудшение метрики отменяет вердикт?
15. Для чего в регламент обслуживания автономного хранилища данных включена обязательная утилита par2? Какую долю избыточности обычно закладывают в контрольные блоки?
16. С какой целью резервные генераторы с ДВС требуют регулярного ежемесячного пуска именно под активной электрической нагрузкой, а не просто работы на холостом ходу?

Глоссарий темы

Шпаргалка по инструментам

Консольные команды регламентного аудита Linux-узла

# 1. Проверка состояния хранилищ и дисковых ошибок ядра
df -hT / /mnt/*
smartctl -H /dev/nvme0n1 || smartctl -H /dev/sda
dmesg -T --level=err,crit,alert

# 2. Проверка состояния локального DNS и сетевых сокетов
unbound-checkconf /etc/unbound/unbound.conf
ss -tulpn | grep -E ':(53|123|80|443|8080)'
dig @127.0.0.1 wiki.polygon.internal +short

# 3. Аудит синхронизации времени chrony
chronyc tracking
chronyc sources -v

# 4. Верификация целостности резервного архива restic
export RESTIC_REPOSITORY="/mnt/backup/repo"
export RESTIC_PASSWORD_FILE="/etc/polygon/restic.key"
restic check --read-data-subset=10%

# 5. Создание и проверка избыточности par2
par2create -r10 -n1 /mnt/backup/schematics.tar.gz
par2verify /mnt/backup/schematics.tar.gz.par2

Учение: хронометраж, энергия, тренд (окружение ЛР 13)

./node_up.sh && ./healthcheck.sh                     # учебный узел и проверка L0–L2
./inject_fault.sh --list                             # перечень скрытых дефектов
./drill_timer.py --init --scenario А --roles "руководитель=Р,оператор=О,наблюдатель=Н"
./drill_timer.py --start
./drill_timer.py --event LEVEL_2 --desc "DNS и NTP локальны"
./drill_timer.py --export-report drill_report.md     # протокол с AAR/IP
./power_log.py record --interval 60 --duration 14400 --out power.csv
./power_log.py analyze power.csv
./drill_trend.py trend.csv --add my_drill.json --date 2026-10-22 --scenario А
python3 teacher/sim/energy.py --profile drill_scenario_a --scenario А --eta-discharge 0.9 --json
upower -d | grep -E 'energy|energy-rate|voltage'
cat /sys/class/power_supply/BAT*/energy_now

Шаблон карточки SOP-1H (Первый час)

=======================================================================
КАРТОЧКА SOP-1H: ВЫХОД НА УРОВНИ 1 И 2 (СЕРВИСЫ ПЛОЩАДКИ)
=======================================================================
ВХОДНЫЕ УСЛОВИЯ: Уровень 0 достигнут. Терминал ttyS0 открыт. U_bus >= 12.4 В.
-----------------------------------------------------------------------
ШАГ 1. МОНТИРОВАНИЕ ХРАНИЛИЩА (Уровень 1)
[ ] 1.1. Смонтировать раздел документации: mount /dev/disk/by-label/POLYGON_DOCS /mnt/docs
[ ] 1.2. Проверить чтение индекса: test -f /mnt/docs/index.html && echo "DOCS OK"
[ ] 1.3. В случае ошибки ФС: запустить fsck -y /dev/disk/by-label/POLYGON_DOCS

ШАГ 2. ЛОКАЛЬНАЯ СЕТЬ И АДРЕСАЦИЯ (Уровень 2)
[ ] 2.1. Поднять интерфейс локальной сети: ip link set eth0 up
[ ] 2.2. Назначить статический IP узла: ip addr add 10.0.0.1/24 dev eth0
[ ] 2.3. Запустить локальный DHCP-сервер: systemctl restart dnsmasq

ШАГ 3. СЛУЖБЫ ИМЕН И ВРЕМЕНИ
[ ] 3.1. Запустить локальный резолвер: systemctl restart unbound
[ ] 3.2. Тестовый запрос: dig @127.0.0.1 wiki.polygon.internal +short
         ОЖИДАЕМЫЙ ВЫВОД: 10.0.0.1. Если пусто -> SOP-DNS-ERR.
[ ] 3.3. Запустить службу точного времени: systemctl restart chrony
[ ] 3.4. Проверить локальный захват RTC: chronyc tracking | grep "Reference ID"

ШАГ 4. СПРАВОЧНИКИ KIWIX
[ ] 4.1. Запустить службу Kiwix: systemctl start kiwix-serve
[ ] 4.2. Проверить локальный порт 8080: curl -I http://127.0.0.1:8080/
-----------------------------------------------------------------------
КРИТЕРИЙ ГОТОВНОСТИ УРОВНЯ 2: 
Со смартфона оператора открывается страница http://10.0.0.1:8080/ в браузере.
Зафиксировать в журнале: время T_L2 и текущее напряжение шины U_bus.
=======================================================================

Что почитать и посмотреть

1. Reason J. Managing the Risks of Organizational Accidents. — Ashgate, 1997. Классическая работа Джеймса Ризона, вводящая модель «швейцарского сыра» (Swiss Cheese Model). Описывает накопление скрытых системных дефектов и латентных условий, приводящих к аварии.
2. Dekker S. The Field Guide to Understanding 'Human Error'. — Ashgate, 2014. Практическое руководство по исследованию инцидентов. Доказывает несостоятельность концепции «человеческой ошибки» как первопричины сбоя и формулирует основы системного анализа.
3. Woods D. D., Dekker S., Cook R., Johannesen L., Sarter N. Behind Human Error. — CRC Press, 2010. Фундаментальное исследование когнитивных факторов в критических системах: распределение внимания, принятие решений в условиях неполноты информации и перегрузка оператора.
4. NIST SP 800-34 Rev. 1. Contingency Planning Guide for Federal Information Systems. — NIST, 2010. Эталонный федеральный стандарт США по разработке планов непрерывности (BCP), планов аварийного восстановления (DRP) и методике проведения штабных и натурных учений.
5. Gawande A. The Checklist Manifesto: How to Get Things Right. — Metropolitan Books, 2009. Книга Атула Гаванде о роли чек-листов в экстремальных условиях хирургии, авиации и строительства. Обоснование структуры, лаконичности и строгости формулировок операционных карточек.
6. Limoncelli T. A., Chalup S. R., Hogan C. J. The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems. — Addison-Wesley, 2014. Главы, посвященные процедурам аварийного восстановления (Disaster Recovery), практикам GameDay (учениям с умышленным разрушением элементов инфраструктуры) и культуре Postmortem.
7. Allspaw J. Kitchen Soap: Blameless PostMortems. https://kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/ Статья Джона Оллспоу, положившая начало инженерной культуре проведения открытых разборов инцидентов в крупных IT-системах.

Углубление

Очерк 1. Длительная изоляция: что из опыта зимовок переносится в проект

Сценарии Б и В (72 и 336 ч) — это дни и недели работы малой группы в шуме, холоде и однообразии. Опыт полярных станций и длительных экспедиций описывается в литературе по-разному, и курс не приводит из него количественных оценок: они зависят от группы, условий и методики исследования. Переносятся в проект качественные выводы, которые можно проверить учением. Первые сутки люди склонны переоценивать силы и пренебрегать сном — поэтому график смен задаётся планом заранее, а не решается на месте. Со временем растёт доля ошибок в рутинных операциях — поэтому рутина выносится в карточки и скрипты, а её выполнение фиксируется в журнале. Межличностные трения усиливаются при неясном распределении обязанностей — поэтому роли и порядок передачи смены записаны. Проверка всех трёх выводов одна: время выполнения одной и той же карточки в начале и в конце смены, записанное в журнал учения.

Очерк 2. Концепция Just Culture: почему поиск виновных убивает надежность

Традиционная модель расследования аварий («кто нажал не ту кнопку?») приводит к двум катастрофическим следствиям:

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

Концепция Just Culture («Культура справедливости») разделяет действия человека на три категории:

• Человеческая ошибка (Human Error): оговорка, опечатка, непроизвольное действие при нормальном намерении. Реакция: утешить оператора, изменить конструкцию системы или интерфейса.
• Рискованное поведение (At-Risk Behavior): сознательный выбор обходного пути, когда инструкция нарушается из лучших побуждений (например, работа без заземления ради ускорения запуска). Реакция: разобрать причины неудобства штатного регламента, устранить стимулы к нарушениям.
• Злонамеренное пренебрежение (Reckless Behavior): осознанное пренебрежение очевидным недопустимым риском (например, включение генератора в закрытом жилом помещении). Только этот случай влечет за собой административные санкции.

Применение Just Culture к автономному Полигону означает, что любая опечатка или сгоревшая плата в ходе учения воспринимается как ценный источник данных для модернизации схемы защиты.

Практическое занятие 13. План непрерывности и чек-листы для Полигона

• Раздел курса: тема 13 «Учения, регламенты, эксплуатационная готовность»

Цель занятия

Выработать практический навык проектирования эксплуатационной документации автономного узла: составления матрицы приоритетов плана непрерывности (BCP), разработки лаконичных одностраничных операционных карточек (SOP) для различных временных горизонтов (15 минут, 1 час, 24 часа), формирования чек-листов консервации и холодного пуска, а также расчета регламентов технического обслуживания и энергозатрат на проведение учений.

Краткая теория

1. Архитектура плана непрерывности (BCP)

План непрерывности автономного комплекса связывает внешние условия (сценарии А, Б, В, Г) с уровнями работоспособности (0–4) через два ключевых показателя:

• Целевое время восстановления (RTO): максимальный допустимый интервал между моментом наступления отказа и моментом восстановления сервиса до гарантированного уровня.
• Целевая точка восстановления (RPO): допустимый возраст данных, определяющий периодичность резервного копирования.

Связь между RTO, мощностью потребления и располагаемой емкостью аккумулятора определяется неравенством живучести:

T_{\text{surv}} = \frac{C_{\text{bat}} \cdot U_{\text{nom}} \cdot \text{DoD} \cdot \eta_{\text{dc}} \cdot K_t}{P_{\text{avg}}} \ge T_{\text{scen}} \quad [\text{ч}]

где C_{\text{bat}} — номинальная емкость батареи (А·ч), U_{\text{nom}} — номинальное напряжение (В), \text{DoD} — глубина разряда, \eta_{\text{dc}} — КПД преобразования, K_t — температурный коэффициент емкости (K_t = 1{,}0 при +20 °C; K_t \approx 0{,}85 для LiFePO4 при 0 °C; K_t \approx 0{,}50 для свинцово-кислотных АКБ при −20 °C), P_{\text{avg}} — средняя мощность нагрузки выбранного уровня деградации (Вт), T_{\text{scen}} — расчетная длительность сценария.

2. Принципы конструирования одностраничных карточек SOP

Операционная карточка должна удовлетворять четырем критериям:

1. Объем: ровно одна страница (до 40–50 строк текста).
2. Линейность: отсутствие ветвлений глубиной более одного уровня. Если условие не выполнено — дается однозначное аварийное действие.
3. Физическая проверяемость: каждый шаг завершается проверкой («зеленый светодиод горит», «напряжение > 12,2 В», «пингуется адрес 10.0.0.1»).
4. Безопасность: критические действия требуют подтверждения и соблюдения правила «четырех глаз».

3. Оптимизация регламентов технического обслуживания

Совокупные годовые затраты времени на регламентное ТО автономного узла складываются из регулярных проверок:

T_{\text{maint}} = 52 \cdot t_{\text{week}} + 12 \cdot t_{\text{month}} + 4 \cdot t_{\text{quart}} + 1 \cdot t_{\text{year}} \quad [\text{ч}]

Расход топлива на регламентные тестовые пуски бензогенератора мощностью P_{\text{gen}} за год:

V_{\text{fuel}} = 12 \cdot \left( t_{\text{warm}} \cdot q_{\text{idle}} + t_{\text{test}} \cdot q_{\text{load}} \right) \quad [\text{л}]

где q_{\text{idle}} — удельный часовой расход на холостом ходу (л/ч), q_{\text{load}} — удельный часовой расход под нагрузкой (л/ч), t_{\text{warm}} — время прогрева (ч), t_{\text{test}} — время работы под тестовой нагрузкой (ч).

Разобранные примеры

Пример 1. Расчет допустимого времени восстановления (RTO) по запасу емкости

Условие: Автономный узел развернут по Сценарию Б (длительность T_{\text{scen}} = 72 часа, температура окружающей среды −10 °C). Энергосистема узла: сборка LiFePO4 4S 12,8 В емкостью C = 100 А·ч. При температуре −10 °C температурный коэффициент емкости LFP составляет K_t = 0{,}75. Допустимая глубина разряда \text{DoD} = 0{,}80, КПД преобразователей \eta_{\text{dc}} = 0{,}90. Мощности потребителей по уровням деградации:

• Уровень 0 (консоль, питание): P_0 = 8{,}0 Вт;
• Уровень 1 (диски, Kiwix): P_1 = 14{,}0 Вт;
• Уровень 2 (локальная сеть, DNS, Wi-Fi): P_2 = 24{,}0 Вт.

Определить:

1. Максимально возможную длительность работы на Уровне 2.
2. Возможно ли выдержать 72 часа только на Уровне 2?
3. Какую максимальную долю времени в сутки узел может находиться на Уровне 2, если остальное время он деградирует до Уровня 0, чтобы проработать ровно 72 часа?

Решение:

1. Вычислим полезный запас энергии батареи с учетом температуры: E_{\text{useful}} = C \cdot U_{\text{nom}} \cdot \text{DoD} \cdot \eta_{\text{dc}} \cdot K_t = 100 \cdot 12{,}8 \cdot 0{,}80 \cdot 0{,}90 \cdot 0{,}75 = 691{,}2 \quad [\text{Вт}\cdot\text{ч}]

2. Время непрерывной работы только на Уровне 2 (P_2 = 24{,}0 Вт): T_2 = \frac{E_{\text{useful}}}{P_2} = \frac{691{,}2}{24{,}0} = 28{,}8 \quad [\text{ч}] Вывод: непрерывная работа на Уровне 2 возможна лишь 28,8 ч, что существенно меньше требуемых 72 часов. План непрерывности обязан предусматривать деградацию до Уровня 0.

3. Найдем среднюю допустимую мощность нагрузки P_{\text{target}} на интервале 72 часа: P_{\text{target}} = \frac{E_{\text{useful}}}{T_{\text{scen}}} = \frac{691{,}2}{72} = 9{,}60 \quad [\text{Вт}] Пусть x — доля времени суток, в течение которой активен Уровень 2 (P_2 = 24{,}0 Вт), а (1 - x) — доля времени на Уровне 0 (P_0 = 8{,}0 Вт). Составим уравнение баланса: x \cdot P_2 + (1 - x) \cdot P_0 = P_{\text{target}} x \cdot 24{,}0 + (1 - x) \cdot 8{,}0 = 9{,}60 16{,}0 \cdot x + 8{,}0 = 9{,}60 \implies 16{,}0 \cdot x = 1{,}60 \implies x = 0{,}10 \quad (10\,\%) В часах в сутки: t_{\text{L2\_day}} = 24 \cdot 0{,}10 = 2{,}4 \quad [\text{ч/сутки}] \quad (2 \text{ часа } 24 \text{ минуты})

Инженерный вывод для BCP: Карточка регламента для сценария Б должна предписывать включение сетевых сервисов и Wi-Fi (Уровень 2) не более чем на 20 минут в начале каждого двухчасового интервала (суммарно 2,4 ч в сутки), удерживая узел в остальное время на Уровне 0.

Пример 2. Расчет годового бюджета регламентного ТО генератора

Условие: Для резервного энергоснабжения узла используется инверторный генератор мощностью 2,0 кВт с четырехтактным бензиновым двигателем. Регламент предписывает ежемесячный контрольный пуск: 5 минут холостого хода для прогрева (q_{\text{idle}} = 0{,}40 л/ч) и 25 минут работы под нагрузкой 1,0 кВт (q_{\text{load}} = 0{,}85 л/ч). Кроме того, в регламент входит одно ежегодное 4-часовое учение с непрерывной работой под нагрузкой 0,8 кВт (q_{\text{drill}} = 0{,}75 л/ч). Стоимость бензина АИ-92 составляет 55 руб./л, объем масляного картера — 0,6 л масла SAE 10W-30 (замена 1 раз в год, стоимость 900 руб./л).

Определить:

1. Суммарную годовую наработку генератора в моточасах.
2. Годовой расход бензина на регламентные процедуры.
3. Полную годовую стоимость расходных материалов на обслуживание генератора.

Решение:

1. Наработка за один ежемесячный пуск: t_{\text{month}} = \frac{5 + 25}{60} = \frac{30}{60} = 0{,}50 \quad [\text{моточаса}] Наработка за 12 месяцев: T_{\text{month\_all}} = 12 \cdot 0{,}50 = 6{,}00 \quad [\text{моточасов}] С учетом годового учения (4,0 часа): T_{\text{year\_total}} = 6{,}00 + 4{,}00 = 10{,}00 \quad [\text{моточасов}]

2. Расход топлива за один ежемесячный пуск: V_{\text{one}} = \left(\frac{5}{60} \cdot 0{,}40\right) + \left(\frac{25}{60} \cdot 0{,}85\right) = 0{,}0333 + 0{,}3542 = 0{,}3875 \quad [\text{л}] Расход за 12 месяцев: V_{\text{12\_month}} = 12 \cdot 0{,}3875 = 4{,}65 \quad [\text{л}] Расход на 4-часовое учение: V_{\text{drill}} = 4{,}0 \cdot 0{,}75 = 3{,}00 \quad [\text{л}] Суммарный расход бензина за год: V_{\text{total}} = 4{,}65 + 3{,}00 = 7{,}65 \quad [\text{л}]

3. Расчет стоимости расходных материалов:

   • Стоимость топлива: 7{,}65 \cdot 55 = 420{,}75 руб.
   • Стоимость масла: 0{,}6 \cdot 900 = 540{,}00 руб.
   • Итоговая годовая стоимость: S_{\text{total}} = 420{,}75 + 540{,}00 = 960{,}75 \quad [\text{руб.}]

Задачи для самостоятельного решения

Параметры задач определяются номером варианта N (N = 1 \dots 16).

Таблица вариантов

Во всех вариантах принять:

• Глубина разряда \text{DoD} = 0{,}80, КПД преобразования \eta_{\text{dc}} = 0{,}90.
• Температурный коэффициент: для сценария А K_t = 1{,}00; для сценария Б K_t = 0{,}75; для сценария В K_t = 0{,}85.
• Удельный расход генератора: холостой ход (t_{\text{warm}} = 5 мин) q_{\text{idle}} = 0{,}45 л/ч; под тестовой нагрузкой q_{\text{load}} = 0{,}80 л/ч. Длительность тестовой работы генератора в месяц задана столбцом t_{\text{test}}. Годовое учение требует 4,0 часа непрерывной работы при расходе 0,70 л/ч.

Задания

Задача 1. Вычислить полезную емкость аккумуляторной батареи E_{\text{useful}} в Вт·ч с учетом условий сценария, глубины разряда и КПД преобразования.

Задача 2. Вычислить максимально допустимое время непрерывной работы T_{2\_\text{max}} (в часах) исключительно на Уровне 2 (P_2). Сравнить с длительностью сценария T_{\text{scen}}: достаточно ли емкости без введения режима периодической деградации?

Задача 3. При условии, что T_{2\_\text{max}} < T_{\text{scen}}, рассчитать максимальное допустимое суммарное время работы на Уровне 2 в сутки t_{\text{L2\_day}} (в часах в сутки) при чередовании с Уровнем 0 (P_0), гарантирующее непрерывную работу в течение всего времени T_{\text{scen}}. Если T_{2\_\text{max}} \ge T_{\text{scen}}, записать «24,0 ч/сутки».

Задача 4. Рассчитать суммарный годовой расход бензина V_{\text{fuel}} (в литрах) на проведение 12 ежемесячных контрольных пусков генератора и одного комплексного 4-часового учения.

Ответы

Расчетные формулы для проверки:

• E_{\text{useful}} = C \cdot U \cdot 0{,}80 \cdot 0{,}90 \cdot K_t
• T_{2\_\text{max}} = E_{\text{useful}} / P_2
• P_{\text{target}} = E_{\text{useful}} / T_{\text{scen}}
• Если P_{\text{target}} \ge P_2, то t_{\text{L2\_day}} = 24{,}0 ч/сутки; иначе: x = (P_{\text{target}} - P_0) / (P_2 - P_0); если x < 0, то t_{\text{L2\_day}} = 0 (дефицит даже на Уровне 0); иначе t_{\text{L2\_day}} = 24 \cdot x ч/сутки.
• V_{\text{month}} = (5/60 \cdot 0{,}45) + (t_{\text{test}}/60 \cdot 0{,}80)
• V_{\text{fuel}} = 12 \cdot V_{\text{month}} + (4{,}0 \cdot 0{,}70)

Таблица ответов по вариантам

Примечание к сценарию В (варианты 4, 6, 9, 10, 12, 15, 16): сценарий В длится 336 ч (2 недели, C-01-03) без генерации и топлива. При заданных параметрах энергии батареи не хватает даже на круглосуточное удержание уровня 0: P₀ · 336 ч больше полезной энергии. План непрерывности в этих вариантах обязан предусмотреть генерацию (тема 5) или периодическое отключение и уровня 0 с пробуждением по таймеру RTC; ответ «0,00 (дефицит на L0)» — правильный и означает, что требование сценария без генерации невыполнимо.

Лабораторная работа 13. Учение по сценарию А: время, энергия, дефекты

• Раздел курса: тема 13 «Учения, регламенты, эксплуатационная готовность»

Введение

В теме 13 учение описано как измерение: время восстановления каждого уровня, расход энергии относительно модели и число дефектов по категориям. Эта работа проводит такое учение для учебного узла Полигона на одном ноутбуке. Узел — каталог с конфигурацией локального DNS и времени, документацией с описью контрольных сумм, архивом данных и показанием напряжения шины; его создаёт скрипт node_up.sh, а healthcheck.sh проверяет уровни L0–L2. Root не нужен: ни системные службы, ни /run работа не трогает.

Учение проводится вдвоём или в одиночку. Руководитель учения вносит скрытый дефект скриптом inject_fault.sh, оператор восстанавливает узел по карточкам SOP, наблюдатель ведёт хронометраж drill_timer.py. В одиночку роли совмещаются, а дефект выбирается случайно (--fault RANDOM), чтобы оператор не знал его заранее.

Расход энергии в ветке П0 измеряется батареей ноутбука: ноутбук работает 4 часа от батареи, а power_log.py читает показания контроллера из /sys/class/power_supply. Если батареи нет (настольный компьютер, виртуальная машина), используется синтетический журнал ваттметра sample_power_log.csv, построенный не той моделью, с которой его сравнивают. В нём есть расхождение с моделью, которое нужно разложить на причины.

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

Цель работы

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

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

• проводить кабинетный разбор сценария по карточкам SOP и находить в них недостающие шаги;
• фиксировать время достижения уровней L0–L4 и сравнивать его с нормативами RTO;
• находить скрытый дефект узла по результатам проверки уровней и устранять его по карточке;
• измерять расход энергии ноутбука за учение и оценивать погрешность измерения;
• раскладывать расхождение «модель — журнал» на причины по почасовому расходу;
• оформлять протокол учения с отчётом AAR и планом улучшений IP;
• сводить учения в трендовую таблицу и применять критерий «система улучшается».

Теоретический минимум

Теория — тема 13: разделы о плане непрерывности и карточках SOP, «Метрики эксплуатационной готовности», «Ветка учения для П0», «После-учебный отчёт и план улучшений», «Динамика метрик от учения к учению», «Числовой пример».

Расход энергии: модель сценария А — energy.py --profile drill_scenario_a (тема 13). Отклонение δ_E ≤ 15 % — норма, 15–30 % — замечание, больше 30 % — существенный дефект.

Перечень оснащения

• Ноутбук с Linux (Debian 13 «trixie» или Ubuntu 26.04 LTS) и батареей; без батареи — любая машина с Linux, ветка с синтетическим журналом.
• python3, bash, coreutils. Необязательно: par2 (часть 4), dnsmasq и dig (продвинутая часть), upower.
• Архив окружения lr-env, карточки cards/sop_15m.txt и cards/sop_1h.txt — распечатанные.
• Часы или секундомер, бумажный журнал на случай отказа ноутбука.

mkdir -p ~/polygon/lr13 && cd ~/polygon/lr13
unzip ~/Загрузки/lr-env.zip && cd lr-env
./node_up.sh
./healthcheck.sh

Условия безопасности. Ноутбук работает от своей батареи в штатном режиме; разряжать батарею ниже уровня, при котором система сама уходит в сон, не требуется. Батарея не вскрывается, защита контроллера не отключается.

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

Часть 1. Кабинетный разбор

Задание

До натурного учения карточки проверяются за столом. Руководитель зачитывает вводную: «Сценарий А, 09:00, сеть 230 В отключена, внешний канал недоступен». Оператор проговаривает действия по cards/sop_15m.txt и cards/sop_1h.txt, не выполняя их; наблюдатель записывает каждый шаг, для которого в карточке нет данных (пароль, адрес, путь, номинал).

Предсказание. До разбора записать, сколько пробелов в карточках будет найдено и на каком уровне (L0, L1 или L2) их больше.

Что должно получиться

Список пробелов карточек с уровнем и предложенной правкой; правки вносятся в карточки до части 2. Если пробелов не найдено, записать, почему: карточки полные или разбор был поверхностным (проверить, назван ли в карточке адрес DNS-сервера узла и порог напряжения шины).

Часть 2. Старт учения и уровень L0

Задание

Распределить роли и записать их в сессию. Затем руководитель вносит скрытый дефект; оператор не видит команду.

./drill_timer.py --init --scenario А --operator "Оператор-1" \
  --roles "руководитель=Р,оператор=О,наблюдатель=Н"
./node_up.sh --force
./inject_fault.sh --fault RANDOM --quiet          # выполняет руководитель
./drill_timer.py --start

Ветка П0 с батареей: отключить ноутбук от сети и в отдельном терминале запустить журнал расхода на 4 часа с опросом раз в минуту:

./power_log.py record --interval 60 --duration 14400 --out power.csv

Если батареи нет, power_log.py record печатает SKIP: … — тогда расход берётся из синтетического журнала (часть 5).

Предсказание. Записать время, за которое будет достигнут L0, и проверку, которая, вероятнее всего, провалится из-за внесённого дефекта.

Оператор выполняет карточку SOP-15M и запускает проверку уровней:

./healthcheck.sh
./drill_timer.py --event LEVEL_0 --desc "консоль, шина измерена"

Что должно получиться

Время L0 по drill_timer.py и вывод healthcheck.sh в журнале. Если OK L0 не получен из-за дефекта шины, L0 не отмечается, а дефект регистрируется (--fault MAJOR или CRITICAL) и разбирается в части 3.

Часть 3. Уровни L1 и L2, поиск и устранение дефекта

Задание

Оператор выполняет карточку SOP-1H: проверяет документацию по описи, конфигурацию DNS и времени. Каждая строка FAIL из healthcheck.sh — дефект; его категория записывается сразу, а время устранения — после исправления.

./healthcheck.sh
./drill_timer.py --fault MAJOR --desc "строка FAIL из healthcheck"
# … устранение по карточке …
./healthcheck.sh
./drill_timer.py --fault-resolved --desc "что сделано"
./drill_timer.py --event LEVEL_1 --desc "документация совпадает с описью"
./drill_timer.py --event LEVEL_2 --desc "DNS и NTP локальны"

Дефекты, которые может внести руководитель, перечислены в ./inject_fault.sh --list; оператор открывает список только после устранения. Исправление выполняется в каталоге узла node/ обычными командами (ls -l, chmod, редактор, sha256sum -c), без root.

Предсказание. Записать, сколько минут займёт устранение и уложится ли L2 в 60 минут.

Разбор дефекта ведётся без поиска виноватых, по методу «пяти почему» из темы 13: почему проверка провалилась; почему узел оказался в таком состоянии; почему карточка не помогла найти причину быстрее; почему этого не обнаружил кабинетный разбор; какое изменение карточки, скрипта или конструкции сделает повторение невозможным. Ответ на последний вопрос — мера плана улучшений: она записывается сразу, пока подробности свежи, с критерием закрытия, который можно проверить в следующем учении (например, «healthcheck.sh проверяет права каталога управления DNS, и карточка SOP-1H содержит команду исправления»).

Если оператор не может найти причину за 30 минут, руководитель учения вправе дать подсказку; подсказка фиксируется в журнале событием HINT и учитывается в разборе как признак пробела в карточке.

Что должно получиться

Время L1 и L2, дефект с категорией, временем обнаружения и устранения; healthcheck.sh в конце части выводит «Итого проваленных проверок: 0». Если L2 не уложился в норматив, это результат учения, а не ошибка выполнения работы.

Часть 4. Данные: блочное повреждение и par2

Задание

Узел хранит архив node/data/archive.bin с файлами восстановления par2 (если par2 установлен). Блоки восстановления позволяют восстановить столько повреждённых блоков, сколько их создано, — не больше.

Предсказание. Записать, восстановится ли архив при повреждении одного блока и при повреждении трёх блоков, и почему.

./node_up.sh --force
./inject_fault.sh --fault DATA_CORRUPT --blocks 1
./healthcheck.sh | grep DATA
(cd node/data && par2 repair archive.bin.par2 && sha256sum -c archive.sha256)

./node_up.sh --force
./inject_fault.sh --fault DATA_CORRUPT --blocks 3
(cd node/data && par2 repair archive.bin.par2; sha256sum -c archive.sha256)

Без par2 выполняется только обнаружение порчи (healthcheck.sh, строка DATA), и в журнале записывается, что восстановление не проверено.

Что должно получиться

Два результата восстановления и объяснение второго: число повреждённых блоков против числа блоков восстановления. Если второй опыт неожиданно восстановил архив, записать, сколько блоков восстановления было создано (par2 verify), и пересмотреть предсказание.

Часть 5. Расход энергии и разбор расхождения

Задание

Учение завершается через 4 ч после старта. Модель расхода для узла Полигона:

python3 ../../../teacher/sim/energy.py --profile drill_scenario_a --scenario А --eta-discharge 0.9 --json

(путь указан для архива, лежащего на своём месте в копии репозитория курса).

Предсказание. Для своей ветки записать ожидаемый расход: для ноутбука — по его средней мощности из upower -d в начале учения, умноженной на 4 ч; для синтетического журнала — модельное значение и знак ожидаемого расхождения.

Ветка с батареей:

./power_log.py analyze power.csv

Ветка без батареи (синтетический журнал ваттметра Полигона):

./power_log.py analyze sample_power_log.csv --model-wh 68.44

По почасовому расходу найти потребителей, которых нет в профиле модели: определить, когда каждый включился и какая у него мощность, и проверить, что их сумма объясняет расхождение в пределах дискретности счётчика. Записать в протокол:

./drill_timer.py --energy-model 68.44 --energy-fact <расход>
./drill_timer.py --stop
./drill_timer.py --export-report drill_report.md

Для ветки с батареей ноутбука модель Полигона не применима: в протокол записывается собственный расход ноутбука и его погрешность (шаг счётчика, расхождение двух способов расчёта), а сравнение выполняется со следующим учением.

Что должно получиться

Расход, его погрешность, δ_E и его зона (для синтетического журнала), список неучтённых потребителей с мощностью и временем включения, протокол drill_report.md с разделами AAR/IP. Только после заполнения журнала можно открыть tools/make_sample_log.py и сверить найденных потребителей с генератором.

Часть 6. Тренд и критерий улучшения

Задание

В trend_example.csv — три предыдущих учения (учебный пример). Добавить к ним своё и применить критерий «система улучшается» из темы 13.

Предсказание. До запуска записать, будет ли вердикт «улучшается» после добавления своего учения, и какое условие критерия, вероятнее всего, нарушится.

cp trend_example.csv trend.csv
./drill_timer.py --json > my_drill.json
./drill_trend.py trend.csv --add my_drill.json --date "$(date +%F)" --scenario А --ip-open 4

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

Что должно получиться

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

Продвинутая часть. Настоящий DNS в изолированном пространстве

Если установлены dnsmasq и dig, ответ локального DNS проверяется настоящим сервером в пространстве имён без сети и без root:

./dns_up.sh --name wiki.polygon.internal

Предсказание: изменится ли ответ после дефекта DOC_STALE или DNS_UPSTREAM. Проверить и записать.

Журнал работы

Графы «Предсказание» и «Факт» заполняются по ходу работы; эталонных значений в тексте нет.

Контрольные вопросы

1. Почему учение длится именно 4 часа и что из этого следует для норматива уровня L4?
2. Чем кабинетный разбор отличается от натурного учения и какие дефекты он находит лучше?
3. Почему оператор не должен видеть, какой дефект внесён? Как этого добиться в одиночку?
4. Почему превышение RTO в учении — результат, а не ошибка выполнения работы?
5. Почему par2 восстанавливает один испорченный блок и не восстанавливает три при двух блоках восстановления? Почему рассеянная порча отдельных байтов хуже для par2, чем порча целого блока?
6. Какие две величины даёт контроллер батареи ноутбука и какие ошибки вносит каждая из них в расход за учение?
7. Почему расход ноутбука нельзя сравнивать с моделью узла Полигона, но можно сравнивать между учениями?
8. Как по почасовому расходу отличить постоянного неучтённого потребителя от включившегося в середине учения?
9. Почему δ_E = 5 % — норма, но расхождение всё равно разбирается до конца?
10. Почему критерий «система улучшается» отменяется одним ухудшением? Какие недостатки у такого строгого критерия?
11. Зачем менять роли от учения к учению и как это видно в трендовой таблице?
12. Что входит в AAR и чем мера плана улучшений отличается от пожелания?