Учебный Центр ФОРС

Producer готов к релизу 02.10, старый consumer обновится 05.10. Можно ли уже удалить поле события? Учебный стек: Avro + Confluent Schema Registry.

Diff схемы `OrderEvent`, S1 → S2:

diff
{
"type": "record",
"name": "OrderEvent",
"fields": [
- {"name": "order_id", "type": "string"},
- {"name": "region", "type": "string"}
+ {"name": "order_id", "type": "string"}
]
}

Reader S1 требует `region` без default. Событие writer S2 не содержит поля — чтение по S1 завершится ошибкой.

Вымышленный лист решения; регистрация и тест не выполнялись. Даты — 2026 год, время московское:

subject: orders-value; действующий режим: BACKWARD
последняя зарегистрированная схема: S1; кандидат: S2
producer v2: пишет по S2; желаемое окно 02.10 21:00
billing v1: reader S1; обновление до v2/S2 — 05.10 02:00
analytics v2: reader S2; готов к обоим форматам
проверка billing v1 / reader S1 ← writer S2: FAIL — нет region
прежний формат S1 поддерживать до: 06.10 12:00
ответственный за решение и исключения: руководитель интеграции
решение на 02.10: NO-GO для удаления region

`BACKWARD` проверяет «новый reader ← предыдущий writer». `BACKWARD_TRANSITIVE` охватывает все предыдущие схемы subject, но не меняет направление. Ни регистрация, ни режим не подтверждают работу всей бизнес-логики consumer.

Решение: сохранить S1, обновить `billing`, проверить поддерживаемые версии с их фактическими reader-схемами. Новое окно producer — после проверок и после 06.10 12:00. Обновление consumer 05.10 не сокращает обещанную поддержку.

Ошибка — принять режим Registry за разрешение любого порядка релизов. Контрактные тесты дают основание оценить это изменение; прочие риски выпуска остаются отдельной задачей.

Сохраните критерии выпуска изменений контракта. Если команде нужно обучение по ИТ-архитектуре, обсудите с УЦ ФОРС подходящее направление и программу.

#ИТархитектура #Avro #КорпоративноеОбучение #УЦФОРС

API обещает: HTTP 200 означает сохранённый отчёт. Ответ 200 есть, отчёта нет.

Учебный фрагмент Java SE 17, не самостоятельная программа. `createReportAsync()` возвращает `CompletableFuture<Report>`, `Report.empty()` — заглушку без сохранения. Типы и логгер условные; HTTP-адаптер отправляет `HttpReply` после нормального завершения возвращённого stage:

java
CompletableFuture<Report> source = createReportAsync();
CompletableFuture<Report> recovered = source.exceptionally(error -> {
log.warn("REPORT_FAILED", error);
return Report.empty(); // fallback не сохранён как отчёт
});
return recovered.thenApply(report -> new HttpReply(200, report));

Вымышленный след, не результат запуска; лог показан схематично:

contract: HTTP 200 = отчёт создан и сохранён
log: REPORT_FAILED; причина — StorageException
source: completed exceptionally; причина — StorageException
recovered: completed normally, value=Report.empty()
response: HTTP 200; saved report: absent

Ошибка осталась в `source`, но обработчик `exceptionally` нормально вернул заглушку. Поэтому `recovered` завершился нормально, а `thenApply` создал ответ 200.

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

Типичная ошибка — принять fallback за бизнес-успех. Добавление `join()` само по себе этого не исправляет: нужно определить, удовлетворяет ли замена контракту и как сообщить клиенту об отказе.

Сохраните пример для ревью асинхронного кода; обработку ошибок Java полезно разбирать на рабочих сценариях.

#Java #CompletableFuture #РазработкаПО #УЦФОРС

Старые Pod Deployment доступны, а новая версия не появляется. `ProgressDeadlineExceeded` сообщает об отсутствии прогресса; причину ищите в сообщении об отказе создать Pod.

Учебный пример для Kubernetes 1.35, namespace `demo`. Выдержки вымышлены, в кластере не получены; это не манифест для применения:

yaml
# Deployment api: три старых Pod доступны, новых нет
spec:
replicas: 3
progressDeadlineSeconds: 600
strategy:
type: RollingUpdate
rollingUpdate: {maxSurge: 1, maxUnavailable: 0}
status:
availableReplicas: 3
updatedReplicas: 0
conditions:
- {type: Available, status: "True", reason: MinimumReplicasAvailable}
- {type: Progressing, status: "False", reason: ProgressDeadlineExceeded}
- {type: ReplicaFailure, status: "True", reason: FailedCreate}
---
# Событие нового ReplicaSet api-new
reason: FailedCreate
message: 'Error creating: pods "api-new-" is forbidden: exceeded quota: object-counts, requested: pods=1, used: pods=3, limited: pods=3'
---
# ResourceQuota object-counts в том же namespace
status:
hard: {pods: "3"}
used: {pods: "3"}

Здесь контроллер не уменьшает старые доступные реплики без замены. Стратегия разрешает дополнительный Pod, а квота уже заполнена: `3 + 1 > 3`. Квота `pods` считает Pod вне фаз `Succeeded` и `Failed`.

Проверьте цепочку: стратегия → conditions → текст события ReplicaSet → `used/hard` квоты. Один `FailedCreate` не доказывает квоту. Если часть новых Pod уже существует, отказ может касаться следующих.

Продление deadline не снимает этот отказ; автоматический откат по превышению deadline не выполняется. Изменять квоту или число реплик стоит после оценки доступности и потребностей namespace.

Сохраните схему проверки rollout; ограничения namespace и стратегии поставки стоит отрабатывать в учебных сценариях DevOps.

#Kubernetes #DevOps #Релизы #УЦФОРС

API доступен другим клиентам, но приложение на Linux иногда не открывает исходящий TCP: `connect()` возвращает `EADDRNOTAVAIL` до HTTP.

Вымышленный снимок для Linux 6.12: IPv4, хостовый namespace, без контейнеров, внешнего NAT и явного `bind()`. На сервере пример не выполнялся:

09:41:12 connect(TCP, bind=no, dst=198.51.100.25:443)
-> EADDRNOTAVAIL; повторов: 7 за 60 с
netns=host; выбранный src=192.0.2.10; адрес присутствует
ip_local_port_range=40000 40003
ip_local_reserved_ports=40001
ESTAB 192.0.2.10:40000
-> 198.51.100.25:443
ESTAB 192.0.2.10:40002
-> 198.51.100.25:443
ESTAB 192.0.2.10:40003
-> 198.51.100.25:443

Диапазон намеренно узкий. Три номера после резерва заняты для того же исходного IP и конечного IP:порта. Второе одновременное соединение с полностью совпадающими адресами и портами невозможно. В примере это объясняет нехватку вариантов; реальный случай требует проверки.

Порядок: errno и этап `connect()` → исходный адрес и отсутствие `bind()` → диапазон, резерв и состояния соединений в том же namespace во время ошибки.

Не считайте все сокеты подряд: локальный порт может использоваться для разных назначений. Timeout на `connect()` сам по себе не доказывает исчерпание; полученный HTTP-ответ относится к следующему этапу. Для контейнеров, NAT и явного `bind()` нужна отдельная диагностика.

Ошибка — расширять диапазон вслепую. Сохраните развилку исходящего соединения; такие сетевые ограничения полезно разбирать на практике Linux.

#Linux #TCP #СетевоеАдминистрирование #УЦФОРС

RLS-политика есть, сервисная роль видит лишнюю строку. Учебный пример PostgreSQL 18:

sql
SELECT sample_id
FROM demo.rls_example
ORDER BY sample_id;

Вымышленные ID (запрос не запускался): `limited_role` → `101, 102`; `service_role` → `101, 102, 103`. Реальные результаты обезличьте.

1. Для своей таблицы замените схему и имя в двух запросах к каталогам ниже. Проверьте метаданные в тех же сеансах и ролях, где обнаружили расхождение:

sql
SELECT current_user AS active_role,
owner.rolname AS table_owner,
c.relrowsecurity AS rls_on,
c.relforcerowsecurity AS force_owner,
pg_catalog.row_security_active(c.oid) AS rls_active,
actor.rolsuper AS is_superuser,
actor.rolbypassrls AS bypasses_rls
FROM pg_catalog.pg_class AS c
JOIN pg_catalog.pg_roles AS owner ON owner.oid = c.relowner
JOIN pg_catalog.pg_roles AS actor ON actor.rolname = current_user
WHERE c.oid = pg_catalog.to_regclass('demo.rls_example');

Пустой ответ этого запроса к `pg_class` — повод проверить базу, схему и имя; выводов о RLS он не даёт. `rls_on` — настройка таблицы; `rls_active` — действие RLS для роли. При `rls_on = true` и `rls_active = false` проверьте superuser, `BYPASSRLS` и права владельца, включая унаследованные при `force_owner = false`. Разные имена не исключают обход; `FORCE` не отменяет его для superuser/`BYPASSRLS`.

2. `rls_active = true` подтверждает применение RLS. Правильность границы доступа проверьте по политикам:

sql
SELECT policyname, roles, cmd, qual
FROM pg_catalog.pg_policies
WHERE schemaname = 'demo' AND tablename = 'rls_example';

Для прямого SELECT смотрите `cmd = SELECT`/`ALL`, `roles` с учётом `PUBLIC` и членства, `qual` как `USING`. Без применимой политики действующая RLS закрывает строки. При нескольких применимых политиках один `qual` не определяет видимость: важно сочетание; подробности вне этого сценария. При `rls_on = false` сохранённая политика не фильтрует.

Ошибка — править политику до проверки роли. Сохраните порядок проверки роли и политики; такие границы доступа полезно разбирать на практике администрирования PostgreSQL.

#PostgreSQL #RLS #АдминистрированиеБД #УЦФОРС

Курс прошли все, а одну задачу сотрудники по-прежнему выполняют по-разному.

Посещаемость и итоговый тест полезны, но не показывают, применяет ли команда знания в работе.

После обучения стоит определить:

• какие действия должны измениться;

• где применяется новый подход;

• какие чек-листы, шаблоны и инструкции нужно обновить;

• как команда будет разбирать отклонения;

• по каким признакам оценивать применение договорённостей.

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

Типичная ошибка — считать завершённый курс конечной точкой. Единая практика появляется, когда знания переходят в конкретные действия и процессы.

УЦ ФОРС может помочь спроектировать корпоративное обучение вокруг рабочих сценариев вашей команды.

#КорпоративноеОбучение #ИТОбучение #УЦФОРС

CPU и память в норме, а сервис недоступен пользователям?

Ресурсные метрики нужны для диагностики, но не подтверждают выполнение рабочей операции.

Проверяйте по симптому:

• нет ответа — DNS, сеть, балансировщик, reverse proxy и слушающий процесс;

• неожиданный HTTP-код — маршрут, аутентификацию, приложение и зависимости;

• код ожидаемый, но результат неверный — содержимое ответа, редиректы и признак успешной операции;

• растёт время ответа — приложение, базу данных и внешние системы;

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

В Zabbix 7.4 веб-сценарий может проверять последовательность HTTP-шагов, код, содержимое и время ответа, а также фиксировать ошибочный шаг и последнее сообщение об ошибке.

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

Сохраните вопросы для ревизии мониторинга.

#Zabbix #Мониторинг #DevOps #УЦФОРС

Переменная указана в Docker Compose, но приложение её не видит?

Сначала проверьте итоговую конфигурацию:

docker compose config

Не публикуйте вывод без проверки: в нём могут оказаться чувствительные значения.

Затем проверьте окружение работающего контейнера. В примере сервис называется app:

docker compose exec app printenv APP_MODE

Учитывайте:

* .env и --env-file могут использоваться для подстановки в Compose-файл;
* env_file у сервиса передаёт переменные в контейнер;
* ARG действует во время сборки и сам по себе не попадает в окружение контейнера;
* после изменения переменных контейнер может потребоваться пересоздать;
* exec проверяет новый процесс, а не то, применило ли значение основное приложение;
* в минимальном образе команды printenv может не быть;
* секреты нельзя безопасно передавать через ARG или ENV.

Сохраните схему проверки конфигурации.

#Docker #DevOps #УЦФОРС

Курсы УКЦ ФОРС в октябре: PostgreSQL, Linux, Docker, Kubernetes, ИИ и Python

В октябрьском расписании — обучение для разработчиков, администраторов, DevOps-инженеров и специалистов, которые работают с базами данных, Linux-системами, контейнеризацией и ИИ.

Собрали ближайшие даты в одном посте.

ИИ и нейросети

Курс по нейросетям: LLM Alchemy — Высшее искусство обучения локальных моделей⁠ — ХИТ
13–16 октября

Курс по нейросетям для пользователей — Работа с локальными и облачными моделями⁠ — Мало мест
26–27 октября

Kubernetes

Kubernetes: от основ до CI/CD⁠ — ХИТ
26–30 октября

Docker и Kafka

Технология контейнеризации Docker⁠ — ХИТ
5–9 октября

Apache Kafka с нуля: архитектура, настройка, интеграция⁠
19–23 октября

PostgreSQL

Администрирование PostgreSQL 16. Резервное копирование и репликация⁠
5–6 октября

PostgreSQL 16. Оптимизация запросов⁠
7–9 октября

Миграция с Oracle на Postgres: Подходы, проблемы и решения. Практический курс⁠ — ХИТ
5–6 октября

Отказоустойчивый кластер СУБД PostgresSQL на основе Patroni⁠ — ХИТ
28–30 октября

Администрирование PostgreSQL 16. Базовый курс⁠
28–30 октября

Linux и РЕД ОС

Linux (CentOS). Уровень 1. Основы администрирования и безопасности⁠
5–9 октября

Linux (CentOS). Уровень 2. Администрирование сервисов и сетей
13–16 октября

Диагностика и устранение неполадок Linux⁠ — ХИТ
19–23 октября

Основы администрирования РЕД ОС. 2024⁠
5–9 октября

Расширенное администрирование РЕД ОС. 2024⁠
12–16 октября

Python

Python основы программирования⁠
19–21 октября

Python расширенные возможности⁠
22–23 октября

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

Скрипт работает вручную, а через systemd — падает.

В терминале вы могли перейти в каталог проекта, активировать Python venv и экспортировать переменные. Системный сервис автоматически эти действия не повторяет.

Начните с unit-файла и журнала. `report-worker.service` — учебное имя; замените его именем своего сервиса:

systemctl cat report-worker.service
journalctl -u report-worker.service -n 50 --no-pager

Проверяйте по ошибке:

• Не найдена утилита — сравните `PATH` и путь к ней. Если не стартует сам сервис, отдельно проверьте `ExecStart` и интерпретатор скрипта.

• Не найден файл — проверьте `WorkingDirectory` и относительный путь. Без настройки системный сервис запускается из корня файловой системы, видимого процессу.

• Нет переменной — проверьте настроенные источники окружения, например `Environment`, `EnvironmentFile` или обёртку. `export` из терминала автоматически не передаётся.

• Отказано в доступе — сверьте пользователя, группы, права, ACL и доступ к каталогам. Затем проверьте ограничения unit и политики безопасности ОС. Не расширяйте права вслепую.

Если журнал пуст, проверьте права на его чтение и место, куда пишет приложение. Перед передачей вывода удалите секреты.

Успешный ручной запуск подтверждает работу только в условиях конкретной сессии.

Такие задачи полезно разбирать на практике при обучении Linux.

Сохраните чек-лист диагностики.

#Linux #systemd #DevOps #Администрирование #УЦФОРС

После ANALYZE запрос стал медленнее. Это не всегда ошибка статистики

Сценарий:

SQL тот же.

Запрос раньше работал нормально.

После ANALYZE появился другой план.

И время выполнения выросло.

Почему?

ANALYZE обновляет статистику для планировщика PostgreSQL.

Но новая статистика не гарантирует лучший план.

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

Проверяйте не только сам план.

Используйте:

EXPLAIN ANALYZE BUFFERS

Сравните:

— старый план;
— новый план;
— оценочное количество строк;
— фактическое количество строк;
— прочитанные блоки.

Если PostgreSQL ожидал мало строк, а получил значительно больше — нужно проверить качество оценки.

Типичная ошибка:

сразу менять индексы.

Сначала разберитесь:

— почему выбран другой путь;
— насколько точны оценки;
— что изменилось в данных и статистике.

Вывод:

ANALYZE помогает планировщику принимать решения, но не гарантирует лучший план.

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

Сохраните сценарий анализа изменения плана PostgreSQL.

На курсах по PostgreSQL такие случаи разбираются через статистику, планировщик и EXPLAIN ANALYZE.

#PostgreSQL #SQL #DBA #БазыДанных #ОптимизацияSQL #УЦФОРС

В production несколько версий одной технологии?

Не обязательно делать отдельный курс под каждую.

Сначала разложите:

роль
→ версия
→ рабочие операции
→ общие навыки
→ version-specific различия
→ практика

Общую базу можно изучать вместе.

А отдельно разбирать только те различия, которые реально меняют:

— команды;
— конфигурацию;
— диагностику;
— эксплуатацию;
— миграцию.

Если версия влияет на реальные действия сотрудника, практику стоит привязать именно к этой среде.

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

Поможем собрать программу с общей базой и практикой под версии, с которыми команда действительно работает.

#УЦФОРС #КорпоративноеОбучение #ИТОбучение #ИТИнфраструктура #РазвитиеКоманды

StatefulSet template уже откатили, а rollout всё ещё стоит?

При RollingUpdate + OrderedReady это возможно.

bad revision
→ Pod не Ready
→ rollout stop
→ template revert
→ broken Pod остаётся
→ controller продолжает ждать его

Kubernetes документирует такой forced rollback scenario.

Иногда Pod, уже созданный по bad revision, нужно пересоздать по reverted template.

Но не удаляйте его автоматически.

Сначала проверьте:

ordinal
→ Ready / Events
→ currentRevision / updateRevision
→ controller-revision-hash
→ PVC / retention policy
→ роль Pod в приложении

И не путайте обычный delete с:

--force --grace-period=0

Force deletion StatefulSet Pod может нарушить at-most-one semantics.

Сохраните последовательность диагностики StatefulSet, который остановился на одном ordinal Pod.

#УЦФОРС #Kubernetes #DevOps #StatefulSet #Эксплуатация

Очередь ThreadPoolExecutor растёт, threads заняты, появляются rejections?

Не начинайте с увеличения maximumPoolSize.

Для execute():

до corePoolSize
→ новые threads
после core
→ сначала queue
queue не принимает
→ threads до maximumPoolSize
queue + pool saturated
→ RejectedExecutionHandler

Поэтому тип queue критичен.

С new LinkedBlockingQueue<>() pool обычно не растёт выше core: backlog накапливается в практически неограниченной queue.

С bounded queue overload становится заметнее, но нужна осмысленная rejection/backpressure strategy.

Соберите:

core/max
→ poolSize
→ activeCount
→ queue size/capacity
→ incoming/completed rate
→ task latency
→ rejection handler
→ downstream latency

И помните: getActiveCount() — приблизительная metric, а RejectedExecutionException зависит от выбранной policy.

Только после этого меняйте pool.

Сохраните параметры, которые нужно собрать до изменения размера thread pool.

#УЦФОРС #Java #Backend #ThreadPoolExecutor #Производительность

Файл удалили, а место не освободилось?

Проверьте, не держит ли его process открытым.

open file
→ rm / unlink
→ pathname исчез
→ FD остался открыт
→ blocks всё ещё заняты

Отсюда типичный симптом:

du → файла уже нет
df -h → место почти не изменилось

Для локальной filesystem:

lsof +L1

Для конкретного PID:

/proc/<pid>/fd/

Если видите:

... -> logfile (deleted)

process всё ещё держит файл открытым.

Не начинайте с kill -9.

Сначала выясните, можно ли безопасно сделать reopen, reload или controlled restart.

И помните: df/du mismatch не всегда означает deleted open file — эту причину нужно подтвердить.

Сохраните этот сценарий для случаев, когда rm не возвращает место на filesystem.

#УЦФОРС #Linux #DevOps #ФайловыеСистемы #Эксплуатация

После crash таблица PostgreSQL осталась, а данные исчезли?

Проверьте:

CREATE UNLOGGED TABLE ...

UNLOGGED table не crash-safe.

После crash или unclean shutdown PostgreSQL автоматически очищает её содержимое. Сама relation при этом остаётся.

Эти данные также не реплицируются на standby.

Поэтому UNLOGGED — не просто «более быстрая таблица».

Перед использованием спросите:

— можно ли потерять всё содержимое;
— есть ли source of truth для восстановления;
— нужны ли данные на standby;
— что сделает приложение с пустой таблицей после аварии;
— действительно ли WAL является bottleneck.

Для проверки:

pg_class.relpersistence = 'u'

означает unlogged.

И важная оговорка: речь именно о crash / unclean shutdown. Штатный restart сам по себе не означает очистку содержимого.

Сохраните вопросы, которые стоит задать до использования UNLOGGED для рабочих данных.

#УЦФОРС #PostgreSQL #DBA #ПроизводительностьБД #Эксплуатация

Нужно обучить 50 специалистов?

Перед массовым запуском полезно проверить программу на небольшой группе.

Но пилот — не вопрос:

«Понравился ли курс?»

Проверять стоит:

— уровень сложности;
— входные требования;
— лаборатории;
— последовательность тем;
— связь с рабочими задачами.

Пилотная группа должна отражать ключевые сегменты будущей аудитории.

Если взять только самых сильных инженеров, результат может оказаться слишком оптимистичным.

Рабочая схема:

задачи команды
→ пилот
→ обучение
→ обратная связь
→ корректировка
→ масштабирование

Пилот не гарантирует успех массового обучения.

Но помогает не масштабировать уже заметную проблему.

Поможем подобрать корпоративную программу и при необходимости выстроить обучение поэтапно — от пилотной группы до масштабирования на команду.

#УЦФОРС #КорпоративноеОбучение #ИТОбучение #РазвитиеКоманды #LND

CronJob есть, schedule правильный, а запуск пропущен?

Проверьте не только cron-expression.

Два ключевых поля:

concurrencyPolicy
startingDeadlineSeconds

Например:

schedule: "*/5 * * * *"
concurrencyPolicy: Forbid

Если предыдущий Job работает 8 минут, запуск на пятой минуте будет пропущен.

Forbid не ставит его в очередь.

startingDeadlineSeconds отвечает за другое:

насколько поздно после scheduled time Kubernetes ещё может начать missed Job.

Диагностика:

schedule/timeZone
→ previous Job duration
→ concurrencyPolicy
→ startingDeadlineSeconds
→ Jobs
→ Events

Для Kubernetes 1.32+ проверьте:

batch.kubernetes.io/cronjob-scheduled-timestamp

— annotation с исходным scheduled time.

И помните: CronJob не гарантирует exactly-once execution во всех сбоях, поэтому Job лучше проектировать идемпотентным.

Сохраните диагностическую последовательность для периодических задач в Kubernetes.

#УЦФОРС #Kubernetes #DevOps #CronJob #Эксплуатация

Package после deploy VALID, а старая session получила:

ORA-04068: existing state of packages has been discarded

Причина может быть в stateful PL/SQL package.

У каждой session — собственная package instantiation.

Если package уже использовался и хранил state, а затем был recompiled или invalidated:

old session
→ next package call
→ old state discarded
→ ORA-04068

Package затем может re-instantiate, но прежнее session state уже потеряно.

Поэтому два вывода опасны:

VALID → проблемы нет

и

ORA-04068 → просто retry

Проверьте:

deploy time
→ long-lived sessions
→ package state
→ first call after deploy
→ ORA-04068
→ connection pool behavior
→ business meaning of lost state

Object validity и continuity session state — разные вещи.

Сохраните этот сценарий для change review систем, где PL/SQL packages хранят session state.

#УЦФОРС #Oracle #PLSQL #DBA #Эксплуатация

Ansible изменил config, но сервис не перезапустился?

Проверьте, не упала ли следующая task после notify.

По умолчанию:

config changed
→ handler notified
→ later task failed
→ handler на этом host не выполняется

Результат:

файл уже новый
сервис ещё не перечитал его

Есть:

force_handlers: true

или:

--force-handlers

Но это не универсальное решение.

Если failure означает, что deployment ещё не готов, forced restart может сделать хуже.

И unreachable host может помешать handler даже при force handlers.

Отдельно существует:

meta: flush_handlers

Он позволяет выполнить уже notified handlers раньше, но тоже требует понимания failure path.

Проверяйте:

play recap
→ changed task
→ notify
→ failed task
→ handler execution
→ фактическое состояние сервиса

Сохраните этот сценарий для ревью playbook, который меняет конфигурацию production-сервисов.

#УЦФОРС #Ansible #DevOps #Автоматизация #Эксплуатация