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

Сообщение пришло повторно — бонусы начислились дважды Ночью очередь доставила событие оплаты, а утром в заказе оказалось два одинаковых начисления бонусов. Повторной доставки никто не ждал, но побочное действие сработало второй раз. Вымышленный сценарий. RabbitMQ, AMQP 0-9-1, ручные подтверждения; очередь сохраняется при отключении потребителя. Здесь обработчик получает сообщение order.paid и начисляет бонусы по заказу: { "type": "order.paid", "order_id": 51234, "amount": 1500 } Обработчик зафиксировал начисление в базе и попытался отправить ручной ack. Соединение с брокером закрылось прежде, чем брокер получил подтверждение. Неподтверждённое сообщение вернулось в очередь, и брокер доставил его повторно — возможно, другому потребителю. Незащищённый обработчик выполнился снова и начисли…

Том подключён, но данные не сохраняются. Куда пишет контейнер? Пересоздали контейнер приложения — пользовательские данные пропали, а внутри каталога тома пусто. Разберёмся на вымышленном стенде: один контейнер, один том, один путь записи. Артефакт. В compose.yaml том подключён к каталогу /var/lib/app: services: app: image: registry.example.com/stand/app:1.0 volumes: - app-data:/var/lib/app volumes: app-data: При этом приложение настроено писать в другое место. В его конфигурации задан каталог данных — параметр storage.dataDir (имя вымышленное, это не стандарт Docker, а настройка конкретного приложения): storage: dataDir: /opt/app/data Восстановим картину до пересоздания. Команды только читают каталоги; для них нужны работающий сервис app, sh и ls внутри Linux-конт…

Свободные блоки есть, а сервису писать некуда Сервис работает под непривилегированным пользователем и получает ошибку записи. GNU df показывает Avail = 0, хотя полный счётчик свободных блоков ещё положительный. На ext4 такую разницу может объяснять резерв блоков. Проверка состоит из двух шагов. 1. Найдите файловую систему реального пути записи. Уточните путь в конфигурации приложения и сопоставьте его с монтированием. Ниже — вымышленный пример; для своего сервиса подставьте фактические значения: systemctl cat myapp.service findmnt -T /var/lib/myapp # TARGET SOURCE FSTYPE OPTIONS # / /dev/mapper/vg0-applv ext4 rw,relatime Unit-файл помогает разобраться в запуске сервиса, но путь записи может находиться в конфигурации самого приложения. Если сервис изолирован, отдельно проверьте,…

Функция с SECURITY DEFINER сделала не то, что ожидали Функция для отчёта доступна, но сумма получена из другой таблицы. На ревью проверьте, какой объект она нашла по имени. SECURITY DEFINER означает выполнение с правами владельца функции. В показанном SQL-теле AS $$…$$ неквалифицированное имя orders разрешается по действующему search_path при выполнении. Учебный пример для PostgreSQL 18: две схемы с таблицами orders и одна функция. Все объекты создаёт и вызывает одна роль в отдельной учебной базе, где этих схем ещё нет. CREATE SCHEMA sales; CREATE TABLE sales.orders (id bigint, amount numeric); INSERT INTO sales.orders VALUES (1, 1000); CREATE SCHEMA staging; CREATE TABLE staging.orders (id bigint, amount numeric); INSERT INTO staging.orders VALUES (1, 5); SET search_path = sales, pg…

ИИ прочитал документ. Кто разрешил ему создать заявку? Сотрудник просит найти порядок оформления доступа. Помощник читает документ с посторонней инструкцией оформить заявку на изменение прав и пытается выбрать инструмент создания заявки. Сотрудник просил справку. Это вымышленная учебная ситуация. Косвенная prompt injection действует через читаемый материал: он может повлиять на выбор модели, но не должен давать ей полномочия. Развилка: подготовить черновик для обсуждения или создать запись в рабочей системе. Для этого сценария руководитель задаёт три ограничения: 1. Разрешённые материалы, данные и поля определяет приложение. Помощник может подготовить черновик. 2. Создание требует подтверждения конкретного содержимого уполномоченным сотрудником: системы, прав, получателя и основания. …

Разрешение просрочено, документ остался: чего не гарантирует TTL? TTL в MongoDB удаляет данные в фоне. Документ может ещё существовать после истечения срока. Поиск по ID поэтому не доказывает, что разрешение действует. Учебный пример для MongoDB 8.0: обычная отдельная коллекция permits_demo, чтение с primary. Вымышленный документ: { _id: "demo-permit", expiresAt: ISODate("2026-10-08T10:00:00Z") } expiresAt должен быть BSON Date. Индекс учебной коллекции: db.permits_demo.createIndex( { expiresAt: 1 }, { expireAfterSeconds: 0 } ); Проверка в 10:01 UTC: const now = ISODate("2026-10-08T10:01:00Z"); db.permits_demo.findOne({ _id: "demo-permit" }); // Ещё может вернуть документ. db.permits_demo.findOne({ _id: "demo-permit", expiresAt: { $gt: now } }); // Для этого документа ожидае…