УКЦ ФОРС | Обучение IT

🛠️ Прямой SELECT под ограниченной ролью возвращает ожидаемые строки, под сервисной — ещё одну. Политика RLS существует, но это не доказывает, что она действует для обеих ролей.

Учебная ситуация для PostgreSQL 18 с условной таблицей demo.rls_example: одинаковый запрос в двух сеансах с разными ролями.
SELECT sample_id
FROM demo.rls_example
ORDER BY sample_id;
Вымышленные результаты: limited_role → 101, 102; service_role → 101, 102, 103. Запрос не запускался. Такое расхождение ещё не называет причину. Реальные строки, имена и условия политик перед передачей результатов обезличьте.

Первая развилка — фактический контекст запроса. Для диагностики своей таблицы замените схему и имя в двух запросах к каталогам ниже. Выполните их в тех же сеансах и ролях, где обнаружили расхождение:
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. Разные имена active_role и table_owner не исключают обход. FORCE ROW LEVEL SECURITY подчиняет владельца политике, но не отменяет обход superuser и BYPASSRLS.

rls_active = true подтверждает применение RLS; правильность границы доступа проверяется отдельно по применимым политикам:
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 строки не фильтрует.

Типичная ошибка — менять правило после теста под другой ролью. Полезнее пройти путь от различия результатов через rls_active к возможному обходу и всем применимым политикам. Сохраните порядок проверки роли и политики; такие границы доступа полезно разбирать на практике администрирования PostgreSQL.

🔹🔹🔹🔹

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

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

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

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

• в каких рабочих сценариях применяется новый порядок;

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

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

• где будут разбираться отклонения и спорные случаи.

Цель «лучше знать инструмент» трудно проверить. Формулировка «использовать согласованный чек-лист перед изменением рабочей системы» описывает наблюдаемое действие.

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

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

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ CPU и память в норме, а пользователи не могут войти в сервис.

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

Сервис может использовать мало ресурсов и при этом возвращать ошибку, ждать медленную зависимость, отдавать HTTP 200 со страницей сбоя или ломаться после авторизации.

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

Проверка выполняется Zabbix server или Zabbix proxy. Поэтому результат зависит и от точки запуска: маршрут мониторинга может отличаться от маршрута пользователя.

Вопросы для ревизии:

• Какую пользовательскую операцию подтверждает мониторинг?
• Проверяются ли код, содержимое и время ответа?
• Совпадает ли точка проверки с маршрутом пользователей?
• Видны ли ошибки приложения и зависимостей?
• Сформирует ли триггер проблему именно при отказе сервиса?
• Настроены ли действия и доставка уведомлений?

Один веб-сценарий проверяет только заданный HTTP-маршрут и не воспроизводит всю клиентскую логику.

Обучение по Zabbix помогает связать элементы данных, веб-проверки, триггеры и процесс реагирования.

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ Переменная есть в Docker Compose, но приложение её не видит?

Проверьте, о каком механизме идёт речь.

Подстановка в Compose-файл:

services:
app:
environment:
APP_MODE: ${APP_MODE}

Значение может поступить из оболочки, файла .env или файла, указанного через --env-file.

Посмотреть итоговую конфигурацию можно командой:

docker compose config

Она показывает модель после объединения файлов и подстановки переменных. Перед публикацией вывода проверьте, нет ли в нём секретов.

env_file внутри описания сервиса — другой механизм: он передаёт переменные в контейнер.

ARG также не решает эту задачу автоматически. Он предназначен для этапа сборки и сам по себе не становится переменной окружения запущенного контейнера. Секреты через ARG и ENV передавать не следует.

Проверка работающего контейнера:

docker compose exec app printenv APP_MODE

Здесь сервис называется app.

Команда запускает новый процесс внутри контейнера. Она показывает его окружение, но не подтверждает, что основное приложение прочитало и применило значение. В минимальном образе утилита printenv также может отсутствовать.

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

Для docker stack deploy правила подстановки .env нужно проверять отдельно.

Сохраните эту последовательность диагностики.

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

Курсы УКЦ ФОРС в октябре: 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 — падает.

Почему?

Потому что сервис может запускаться в другом окружении.

Сценарий:

запускаем скрипт вручную → работает

создаём systemd unit → ошибка:

— команда не найдена;
— файл не найден;
— конфигурация отсутствует.

Частая ошибка диагностики:

сразу искать проблему в приложении.

Но сначала нужно проверить контекст запуска.

Что отличается:

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

Проверяем unit:

User=

Кто запускает сервис?

WorkingDirectory=

Откуда выполняется команда?

Environment=
EnvironmentFile=

Какие переменные передаются?

ExecStart=

Что именно запускается?

Важно:

ulimit, PATH и переменные вашей shell не являются доказательством того, что их получил systemd-сервис.

Главный источник информации:

journalctl -u имя-сервиса

Смотрите:

— ошибку;
— пользователя;
— момент запуска;
— код завершения.

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

запустить сервис от root, чтобы «проверить, работает ли».

Так можно скрыть проблему с правами или окружением.

Правильный порядок:

unit-файл
→ пользователь
→ рабочий каталог
→ переменные
→ права
→ журнал.

Вывод:

Работа команды в терминале не гарантирует её работу через systemd.

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

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ ANALYZE выполнили. Запрос стал медленнее. Почему?

Сценарий:

SQL не менялся.

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

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

Первая мысль:

«Статистика сломалась».

Но ANALYZE работает иначе.

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

Новая статистика может привести к выбору другого плана.

И этот план не всегда окажется быстрее.

Проблема часто не в самой статистике, а в том, насколько хорошо планировщик оценил количество строк.

Проверка начинается с:

EXPLAIN ANALYZE BUFFERS

Сравните:

— старый план;
— новый план;
— actual time;
— rows estimate;
— actual rows;
— прочитанные блоки.

Особое внимание:

оценка:

100 строк

факт:

500 000 строк

Такое расхождение может изменить выбор стратегии выполнения.

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

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

Но сначала нужно понять:

— почему изменился путь выполнения;
— что изменилось в статистике;
— насколько оценки совпали с реальностью.

Последовательность:

план до изменений
→ новый план
→ EXPLAIN ANALYZE BUFFERS
→ сравнение estimate/actual
→ только потом изменение настроек.

Вывод:

ANALYZE обновляет данные для планировщика, но не обещает, что каждый новый план будет быстрее.

Сначала нужно понять логику выбора PostgreSQL.

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ В production одновременно живут несколько версий одной технологии. Как обучать команду?

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

И не обязательно учить всех только на newest version.

Полезнее сначала построить карту:

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

Общим могут быть:

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

Отдельно стоит разбирать только те различия версий, которые реально меняют работу:

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

Практику тоже полезно привязывать к реальной среде, если version-specific различия влияют на задачи участника.

Рабочая модель может выглядеть так:

общая база
→ version-specific модули
→ практика на нужной версии

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

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

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ StatefulSet откатили на good template, а rollout всё ещё завис?

При RollingUpdate + OrderedReady это documented forced rollback scenario.

bad revision
→ Pod не Ready
→ rollout остановился
→ template reverted
→ broken Pod остался
→ controller продолжает ждать его Ready

Простого rollback .spec.template может быть недостаточно.

После revert проблемный Pod, уже созданный по bad revision, может потребовать удаления, чтобы controller пересоздал его по good template.

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

— ordinal;
— Ready и Events;
— .spec.podManagementPolicy;
— .spec.updateStrategy;
— currentRevision/updateRevision;
— controller-revision-hash;
— PVC и retention policy;
— application role и quorum.

Почему так осторожно?

StatefulSet Pod имеет стабильную identity и часто связан с persistent storage.

Обычный Pod delete не равен force delete.

--force --grace-period=0 особенно рискован: Kubernetes предупреждает, что force deletion StatefulSet Pod может нарушить at-most-one semantics.

При обычном RollingUpdate обновление идёт от большего ordinal к меньшему и ждёт Ready текущего Pod.

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

stuck ordinal
→ Ready
→ revision
→ reverted template
→ PVC/application semantics
→ manual intervention

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ ThreadPoolExecutor saturated, а CPU ещё не 100%?

Это возможно: threads могут ждать database, HTTP, filesystem, locks или другой blocking dependency.

Для execute() логика такая:

threads < corePoolSize
→ новый thread
core достигнут
→ сначала queue
queue не принимает
→ threads растут до maximumPoolSize
queue не принимает + pool at max
→ RejectedExecutionHandler

Отсюда важная ловушка.

corePoolSize = 10
maximumPoolSize = 100
queue = new LinkedBlockingQueue()

Без заданной capacity такая queue практически неограниченная.

После загрузки core threads задачи будут накапливаться в queue, а pool обычно не вырастет до 100.

Поэтому увеличение maximumPoolSize может ничего не изменить.

С bounded queue executor после её заполнения может расти выше core — до max.

Но bounded queue сама по себе overload не решает: нужна понятная rejection/backpressure strategy.

RejectedExecutionException тоже не обязательна.

Её бросает AbortPolicy; другая policy может вести себя иначе.

Перед tuning соберите:

— core/max pool size;
— poolSize и approximate activeCount;
— тип и capacity queue;
— incoming и completed rate;
— task latency;
— rejection policy;
— downstream latency.

Главный вопрос:

это временный burst
или
incoming rate стабильно выше completion rate?

Во втором случае большая queue только откладывает проблему.

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ Удалили большой log, а df -h почти не изменился?

Проверьте deleted open files.

Механика:

process открыл файл
→ получил FD
→ rm / unlink удалил pathname
→ process продолжает держать файл открытым
→ blocks остаются заняты

Поэтому возможна картина:

du → файл уже не видит
df → filesystem всё ещё занят

Это не ошибка одной из команд.

du считает объекты в directory hierarchy.

df показывает использование blocks всего filesystem.

Для локальной filesystem проверьте:

lsof +L1

Она помогает найти open files с link count 0.

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

/proc//fd/

Там можно увидеть:

17 -> /var/log/app.log (deleted)

Это означает: pathname удалён, но process всё ещё держит descriptor.

Место окончательно освобождается, когда закрыт последний open descriptor и нет других hard links на файл.

Важно:

— не начинайте с kill -9;
— не считайте restart единственным решением;
— сначала проверьте, можно ли сделать корректный reopen/reload;
— не трактуйте любое df ≠ du как доказательство deleted open file.

И отдельная оговорка: на NFS semantics отличаются, поэтому lsof +L1 нельзя механически интерпретировать так же, как на локальной filesystem.

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹

🛠️ После crash PostgreSQL таблица существует, а строки исчезли?

Проверьте, не была ли она:

CREATE UNLOGGED TABLE ...

Для UNLOGGED это может быть ожидаемым поведением.

PostgreSQL не записывает данные такой таблицы в WAL, поэтому WAL overhead ниже.

Но цена — другие durability guarantees:

— UNLOGGED table не crash-safe;
— после crash или unclean shutdown её содержимое автоматически очищается;
— содержимое не реплицируется на standby.

То есть:

таблица есть
+
данных после аварии нет

не обязательно означает corruption.

Тип relation можно проверить через:

SELECT relname, relpersistence
FROM pg_class
WHERE relname = 'work_queue';

u означает unlogged.

Дальше спросите:

— был ли именно crash/unclean shutdown, а не обычный restart;
— что хранилось в таблице;
— можно ли восстановить содержимое;
— есть ли другой source of truth;
— нужны ли эти данные на standby;
— действительно ли WAL был bottleneck.

Самый важный вопрос до использования UNLOGGED:

«Что сделает приложение, если после аварии таблица окажется пустой?»

Если данные можно безопасно перестроить — модель может быть подходящей.

Если это единственная копия критичных данных — решение требует пересмотра.

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

😄VK | 💬Макс | 🌐 Cайт

🔹🔹🔹🔹