Мера защиты, которая выключила защищаемое

Агент умеет менять своё расписание. Звучит опасно - значит, надо запретить.

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

Под тот же флаг попал файл заданий планировщика.

А планировщик сохраняет своё состояние через перезапись файла. Он пишет во временный, потом подменяет им старый. Флаг неизменяемости эту подмену запрещает.

Результат: ошибка доступа 86 раз за сутки и расписание, которое не отработало больше недели.

Мера защиты от того, чтобы агент менял себе расписание, молча выключила расписание целиком.

Это не единичный курьёз, это класс ошибок. Похожее я видел у себя: защита от лишних выгрузок в облако может отрезать данные, которых локально нет. Новый перехватчик тихо съедает старый рабочий путь. Хук, добавленный ради безопасности, ломает то, что защищал.

Что из этого следует практически:

1) после каждой меры защиты проверяется не она сама, а то, что она защищала. Не «флаг стоит», а «расписание отработало».

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

Статус говорит, что процесс жив. Артефакт говорит, что он работает. Это разные утверждения, и второе дороже.

Что у вас в системе последний раз сломалось молча?

Мера защиты, которая выключила защищаемое | Сетка — социальная сеть от hh.ru