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

Подтвердил и упал: сообщение исчезло Очередь пуста, метрики зелёные, ошибок нет. Задание до воркера дошло и было подтверждено, но действие не выполнено, а повторной доставки не будет. Вымышленный фрагмент на Pika: ручной режим, ack до обработки. Подключение и запуск потребления опущены. def on_message(ch, method, properties, body): ch.basic_ack(delivery_tag=method.delivery_tag) # рано process(body) # здесь процесс падает channel.basic_consume(queue="tasks", on_message_callback=on_message, auto_ack=False) Сценарий срабатывает, если брокер принял ack до падения процесса. Auto-ack…

Pod в Pending: «Insufficient cpu», а узлы простаивают Релиз, новый обработчик отчётов не стартует: в событиях Insufficient cpu. Соседний Pod той же мощности работает, реальная загрузка низкая. Планировщик сравнивает с allocatable узла сумму requests назначенных ему Pod, а не фактическое потребление. Pending при уже назначенном узле — ожидание запуска. Назначение видно по spec.nodeName; Pod в очереди на назначение запросы на конкретном узле ещё не занимает. kubectl describe node node-a kubectl top pod -n reports Вымышленный узел с allocatable 2000m: занято 1750m, новый Pod просит 500m — сум…

Часы поправили. Что проверить у таймера Условный пример: часы опережали внешний источник на семь минут. Их перевели назад, но отметка запуска выгрузки не совпала с ожидаемыми 03:00. Причина ещё не установлена. OnCalendar= задаёт календарное расписание; OnBootSec= и родственные настройки — монотонные интервалы. Они могут сочетаться. systemctl show -p Version systemctl show payload-export.timer \ -p Unit -p TimersCalendar -p TimersMonotonic -p AccuracyUSec journalctl -b -u payload-export.timer -u payload-export.service \ -o json --output-fields=MESSAGE Нужны systemd 236+ и доступ к журна…

После обновления PostgreSQL запрос стал медленнее SQL и данные те же, время выросло. Сравните версии, настройки и планы для параметров из жалобы. Пример для PostgreSQL 18: город связан с округом. orders существует, обе колонки — text. Выполняйте код в одной диагностической сессии: PREPARE q(text, text) AS SELECT order_id FROM orders WHERE city = $1 AND federal_district = $2; EXPLAIN ANALYZE EXECUTE q('Казань', 'ПФО'); Условный фрагмент, остальные поля опущены; числа вымышленные, не результат стенда: Seq Scan on orders (rows=30) actual rows=4200 Оценка ниже факта; причина регрессии не…

Ответ есть. Найти трудно Эксперт снова отвечает на вопросы о выполнении задания. Проверенный ответ уже в общей базе. Прежде чем связывать обращения с нехваткой обучения, проверьте поиск. Вымышленная обезличенная запись проверки обычным участником команды; это не тест конкретного продукта: Заметка «Диагностика исполнения» открывается по прямой ссылке. Ответ и условия применения сохранены. «Как посмотреть лог задачи?» → заметка не найдена. В этом примере слова пользователя расходятся с термином автора. Ответ в личном сообщении помогает сейчас, но препятствие поиска может остаться незамеченны…

Кеш вернул старое после обновления Коммит завершён, ключ удалён, а кеш снова отдаёт старое. Вымышленный cache-aside: два потока, один ключ; псевдокод: B: CACHE.get(key) // промах B: v = DB.get(key) // версия 7 A: DB.set(key, version=8) // коммит завершён A: CACHE.delete(key) B: CACHE.set(key, v) // снова версия 7 B прочитал старое до коммита A, но записал после удаления ключа. Delete эту запись не запрещает. Развилка: сравните версии в кеше и источнике, найдите автора set и момент чтения. Старое прочитано до коммита и записано после delete? Это показанная гонка. Если н…

Имя сервиса совпало. Namespace — нет Клиент в frontend вызывает payments, но нужный сервис — в finance. Вымышленный пример: Pod на Linux без hostNetwork с dnsPolicy: ClusterFirst, DNS-домен cluster.local, URL http://payments:8080. Два обычных ClusterIP-сервиса на порту 8080: frontend/payments — 10.96.10.20, finance/payments — 10.96.20.30. Читающие команды: kubectl get svc -n frontend payments kubectl get svc -n finance payments Фрагмент /etc/resolv.conf контейнера клиента: search frontend.svc.cluster.local svc.cluster.local cluster.local Если приложение использует стандартный системный…

Конвейер вернул 0 — а производитель оборвался Читатель взял одну строку и вышел с 0. Запись производителя после закрытия всех читающих дескрипторов вызывает SIGPIPE; по умолчанию процесс завершается. Вымышленный пример, отдельный Bash-скрипт в Linux; SIGPIPE не игнорируется и не обрабатывается: gen() { for ((i=0; i<100000; i++)); do printf '%s\n' "$i"; done; } consume() { read -r first; return 0; } set +e set +o pipefail gen | consume printf 'rc=%s; steps=%s\n' "$?" "${PIPESTATUS[*]}" set -o pipefail gen | consume printf 'rc=%s; steps=%s\n' "$?" "${PIPESTATUS[*]}" Если gen завершён SIGPIPE…

Транзакция одна. Снимки разные Отчёт считает оплаченные заказы и их сумму двумя SELECT. В PostgreSQL 18 при READ COMMITTED эти числа могут относиться к разным наборам. Вымышленный пример с учебной orders (status, amount). Сессия A: BEGIN; SHOW transaction_isolation; SELECT count(*) FROM orders WHERE status = 'paid'; -- B добавила paid-заказ и выполнила COMMIT. SELECT sum(amount) FROM orders WHERE status = 'paid'; COMMIT; При READ COMMITTED первый SELECT не видит новый заказ, второй включает его сумму: у каждого SELECT без блокирующих оговорок свой снимок на начало запроса. Это учебная посл…

Старое решение: применимо ли оно сейчас? Нагрузка выросла, а в вики осталось только «используем синхронный вызов». Руководителю нужно понять, подходят ли прежние основания для нынешних условий. Но самих оснований в документе нет. ADR — запись архитектурного решения — связывает выбор с контекстом, ограничениями, альтернативами, последствиями и статусом. Вот сокращённый вымышленный пример: Решение: синхронный вызов сервиса расчёта. Контекст: запросов мало, результат нужен сразу; согласованная задержка допустима. Альтернатива: очередь с отдельным получением результата. Последствие: зависимость…