Администрирование

Не отдавайте базу знаний чужому ассистенту

Wake word устройство ловит локально, а дальше все идет на сервер: ASR переводит звук в текст, NLU достает интент, система выполняет действие, TTS озвучивает ответ. Сервер при этом чаще всего чужой. Вместе с аудио туда попадает и то, на чем ассистента обучали — внутренние инструкции, переписка, документы.

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

Подробности — в блоге Рег.облака.

🤖 AI-агенты для Ansible: как делегировать рутину и не писать плейбуки руками — бесплатный стрим 12 августа

Я перестал писать Ansible-плейбуки руками. Вообще. Вместо этого у меня работает AI-агент, который знает лучшие паттерны, понимает мою инфраструктуру и сам пишет роли, модули, соединяет их и поднимает всё необходимое. Недавно он за вечер собрал связку Terraform + Ansible на новом сервере — и справился лучше, чем я ожидал.

На стриме покажу, как это устроено изнутри:

🔧 Архитектура AI-агента для Ansible: база знаний, инструментарий, что дёргать и как дёргать
📜 Как агент пишет роли и модули: промпты, валидация, итеративное исправление ошибок
🖥 Живой пример: поднимем инфраструктуру с нуля руками агента — в реальном времени
💡 Границы применимости: что агент делает хорошо, а что пока лучше делать самому

Андрей Чуян — основатель DebugSkills, автор AI-агента для работы с Ansible, спикер лабораторных по AI-оркестрации и Kubernetes.

📅 12.08.2026, 19:00 (МСК)
📡 ktalk
⏱️ 45 мин контент + 15 мин Q&A

> «Я ушёл из рутины, делегировал Ansible AI-агенту, который занимается этим.» — Андрей Чуян, из диалога с участником на лекции Jenkins

Это не вебинар и не лабораторная. Это живой разговор о том, как AI меняет работу DevOps-инженера уже сегодня. Без продаж, без подписок — просто приходите и смотрите.

Ссылка на регистрацию: https://debug-skills.timepad.ru/event/4127747/

Жду вас! 🤖

Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?

Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?

Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д). 

Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.

В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.

Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).

Поддерживаются три основные метрики сравнения векторов:

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

• Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.

• Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.

Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:

CREATE TABLE items (
 id SERIAL PRIMARY KEY,
 title TEXT,
 embedding VECTOR(1536)
);

Добавим данные для нескольких векторов разных объектов:

INSERT INTO items (title, embedding) VALUES
 ('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
 ('Neural image processing', '[0.42, 0.18, -0.35]'),
 ('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
 ('Document clustering', '[0.09, -0.79, 0.48]');

Теперь сравним их попарно и отсортируем по расстоянию:

SELECT
  a.title AS title_a,
  b.title AS title_b,
  a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;

Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.

В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.

А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

Колонка %steal показывает время, когда система готова работать, а процессор ей не дали. Важна повторяемость: единичный всплеск это шум, рост в одни часы это конкуренция. На контейнерном тарифе лимит виден как троттлинг, steal остается низким.

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat

200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

Строгого удвоения при удвоении потоков не будет, мешают кеш и шина памяти. Настораживает обратное: многопоточный результат равен однопоточному, а mpstat показывает steal.

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

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

Как сравнивать? Не складывайте IOPS, миллисекунды и баллы в один рейтинг. Сначала отсеките тарифы, не проходящие пороги приложения, потом расставьте веса: базе важнее p99 диска, агенту сборки процессор, медиасервису исходящая полоса. Для каждого прогона сохраняйте дату, локацию, образ, версии утилит и команду.

Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.

Для MacBook вышло открытое приложение Himekuri, которое позволяет переворачивать календарь на рабочем столе. Бумага на календаре мнётся, рвётся и улетает вниз экрана. Причём вернуть ее обратно уже нельзя. Закрепить проект можно на рабочем столе, поверх всех окон или использовать как обычное приложение.

Представлен первый релиз эмулятора терминала под необычным названием Shitty. Автор проекта считает его «серьёзным эмулятором терминала с глупым названием». Код решения написан с помощью ИИ-ассистента на C++23 (сbundled libstd, требующей -std=c++26) и распространяется под двойной лицензией MIT и GPL-3.0. Поддерживаются macOS и Linux.

Проект делает ставку на обеспечение низких задержек, быстрого запуска и предсказуемого потребления ресурсов: состояние терминала обрабатывается на CPU, а отрисовка выполняется через бэкенды на базе Vulkan в Linux и Metal в macOS, без использования стороннего графического тулкита. При тестировании производительности вывод 100 МБ ASCII через терминал Shitty показывает ~118 МБ/с, обгоняя alacritty (0.81 с против 0.96 секунд), kitty и ghostty. На «случайных байтах» с некорректным UTF-8 отрыв от alacritty ещё заметнее (~51 МБ/с против ~31 МБ/с). Корректность работы Shitty обеспечивается более чем 5000 тестами, собранными из десятка с лишним внешних наборов — kitty, esctest, vttests из xterm, vttest, tack, libvterm, libtsm, alacritty, ghostty, contour, konsole, mosh. Тесты выполняются с проверкой работы на реальном PTY.

Инфраструктура для разработки на гиперскорости: сервисы самообслуживания и MCP в HyperDrive

ИИ уже помогает писать код за минуты. Но путь до рабочего сервиса по-прежнему занимает дни или недели — из-за ручных инфраструктурных процессов, тикетов и согласований.

На вебинаре покажем, как Internal Developer Platform меняет эту модель: разработчик получает готовую инфраструктуру через каталог стандартных сценариев, а DevOps-инженер управляет платформой, шаблонами и политиками.

Ключевые темы:

• Почему инфраструктура стала главным ограничением скорости разработки

• Почему модель «разработчик → тикет → DevOps» больше не масштабируется

• Что такое Internal Developer Platform на практике

• Как меняются роли DevOps и ИБ

• Как ИИ-агент безопасно и предсказуемо взаимодействует с инфраструктурой через Model Context Protocol

• Живое демо новой IDP-функциональности в HyperDrive: создание окружения, self-service, GitOps, встроенные политики безопасности и путь от запроса до готовой инфраструктуры

Кому будет полезно:

• CTO

• CIO

• Head of Platform Engineering

• Head of DevOps

• Руководителям разработки

• Platform Team

• DevOps-инженерам

Спикеры:

Павел Лавров
Лидер продукта HyperDrive, Orion soft

Даниил Рахновский
Архитектор продукта HyperDrive, Orion soft

Регистрация по ссылке

Облако для продакшена. Что показывают steal, await и реальная полоса?
Два провайдера, одинаковая строка в тарифе: 4 vCPU, 8 ГБ, 100 ГБ SSD, гигабит. Цена расходится на 15 процентов, и непонятно почему. Через неделю тестов выясняется, что p99 отличается в разы. Тариф описывает то, что выделено виртуально. Что происходит в железе, туда не попадает.

Почему синтетика не отвечает на вопрос? Geekbench и sysbench меряют потолок за короткий тест. Продакшен работает иначе: нагрузка неровная, соседи по ноде непредсказуемы. Провайдеры делают оверкоммит, и пока суммарная нагрузка умеренная, все хорошо. Стоит нескольким машинам дать всплеск разом, растет steal, удлиняется дисковая очередь, канал упирается в шейпер. Короткий тест может не попасть в это окно. Нужно от получаса нагрузки, а на суточные паттерны от 24 часов.

CPU steal. Steal это доля времени, когда vCPU готов работать, но гипервизор не дает ему физическое ядро. Приложение получает задержку без видимой причины: процессор загружен, работа не идет.

vmstat 1 30

procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache  us sy id wa st
 2  0      0 512344  81920 210488  31  4 58  1  6

Колонка st справа. Шесть процентов несколько строк подряд это не шум. Разбивку по ядрам дает mpstat -P ALL 1 10, длинный срез пишут в файл через sar -u 1 3600 и сравнивают часы между собой.

До процента можно не смотреть. От одного до пяти наблюдать, если нагрузка чувствительна к задержкам. От пяти до десяти хвосты страдают. Выше десяти это разговор с поддержкой про ноду и тариф.

Для транскодирования и компиляции steal переводится во время выполнения почти линейно. Для API и запросов к базе иначе: медиана держится, а p99 растет, потому что в моменты steal запросы копятся в очереди. Отдельная история это всплески до 20 процентов на пару секунд при спокойном фоне. Такой скачок опаснее ровного высокого steal, он тянет каскад таймаутов.

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

iostat -xz 1 10

В выводе важны два числа: await это время запроса вместе с ожиданием в очереди, avgqu-sz это глубина очереди. Растет второе, следом первое. Профиль OLTP проверяют так:

fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
    --numjobs=4 --iodepth=32 --size=4G --runtime=60 \
    --time_based --ioengine=libaio --group_reporting

Флаг direct обязателен, без него тест уедет в страничный кеш и покажет память вместо диска. В отчете смотрите iops и clat p99, именно второе объясняет хвосты запросов. Ориентир для средней базы это 5000 IOPS на чтении 4К при await ниже 2 мс, для нагруженной 20000 при await ниже миллисекунды.

Очередь выше восьми под OLTP это первый признак насыщения. Загрузка под 100 процентов для SSD не приговор, тревожно когда вместе с ней растет await. У дисков с лимитом IOPS порог срабатывает раньше насыщения железа, и покажет это именно await.

Сеть. Заявленный гигабит это верхний предел, а не гарантия. Шейпинг под нагрузкой в документации обычно не описан.

iperf3 -c 10.0.0.5 -t 60 -P 4
mtr --report --report-cycles 100 10.0.0.5

Четыре потока нужны потому, что один упирается в размер окна и RTT, а не в канал. Минута нужна, чтобы поймать burst лимит: полная полоса первые пятнадцать секунд и просадка дальше это он. Потери на одном промежуточном хопе при чистом трафике дальше это деприоритизация ICMP роутером. Потери подряд на нескольких хопах уже другое.

Проверьте MTU. Overlay сети добавляют заголовок к каждому пакету, 1500 превращаются в 1450, а пакеты с флагом DF молча теряются.

ping -M do -s 1472 10.0.0.5

Порядок проверки. Срез в покое сразу после деплоя, он же точка отсчета. Затем steal под боевой нагрузкой. Дальше fio с профилем приложения и iostat в соседнем терминале. Потом сеть. И наблюдение сутки или трое, иначе суточный паттерн конкуренции пройдет мимо.

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

Плагин для управления задачами в Obsidian

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

Уже работают:

• трёхпанельный интерфейс

• проекты, теги и массовые операции

• приоритеты, сортировка и группировка

• тайм-блокинг и управление с клавиатуры

• вложенные подзадачи и кастомные статусы

• полная совместимость с синтаксисом Tasks

Записал предварительный обзор текущей версии. В видео показываю основные механики и рабочий процесс.

Сейчас реализовано около 20-30% задуманного. Плагин войдёт в обновление 8.0.0 моего Obsidian-хранилища (changelog).

Первые шаги на сервере: что быстрее освоить — консоль или ispmanager

У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.

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

Подробности — в блоге Рег.облака.

Представлен открытый проект pdf-inspector на Rust от команды Firecrawl. Это PDF-парсер, который умеет быстро обрабатывать страницы документов. Проект преобразует содержимое в Markdown, но при этом сохраняет структуру документа и таблицы. Решение работает без ограничений, код опубликован под лицензией MIT.

Антипаттерн при работе с VPS: почему не стоит постоянно работать под root?
Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.

Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.

Как правильно: отдельный пользователь и sudo.

В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:

adduser operator
 usermod -aG sudo operator

Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в

/etc/ssh/sshd_config:
PermitRootLogin no

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

sshd -t && systemctl reload ssh

Мини-чек-лист безопасного старта на VPS

•        Отдельный пользователь создан, команды запускаются через sudo.

•        Публичный ключ добавлен, приватный защищён парольной фразой.

•        Вход по SSH под root отключён.

•        Обновления системы устанавливаются регулярно.

Проверьте настройки доступа к VPS: создайте отдельного пользователя с sudo, протестируйте вход по SSH и только после этого отключите вход под root.

«Bad Apple!! Но это же traceroute! В продолжение моего поста о том, как заставить инструменты traceroute отображать произвольное содержимое, и вдохновлённый выходом на днях ещё одной кавер‑версии Bad Apple, я просто не мог не сделать это», — пояснил Йонас Шефер.

Используя функцию numgen из библиотеки nftables, мы можем изменять количество переходов каждый раз при генерации пакета ICMPv6. Функция numgen возвращает либо случайные числа, либо монотонный счетчик. С помощью счётчика мы можем легко настроить каждый переход так, чтобы он возвращал разный IPv6-адрес при генерации ответного пакета.

Для этого потребовалось ещё две вещи. Во-первых, необходимо отключить ограничение скорости ядра (по умолчанию 1/с) для исходящего трафика ICMPv6 с помощью команды sysctl net.ipv6.icmp.ratelimit=0, иначе всё закончится очень быстро. Вторая проблема заключается в том, что mtr обычно показывает несколько адресов для каждого узла, поскольку это указывает на использование нескольких разных путей для пакета, и это обычно полезная информация.

После всего этого я использовал ffmpeg для передискретизации видео до 8 кадров в секунду (что соответствует интервалу в 125 мс между кадрами) и экспорта уменьшенных (до 30x11 пикселей) отдельных кадров в файлы PNG. Затем я написал скрипт на Python для чтения файлов изображений и преобразования их в набор правил nftables для генерации соответствующих ответов ICMPv6. В результате получается чуть более мегабайта правил nftables, но это определённо того стоит.

Почему дешёвый VPS-сервер может обойтись дорого в продакшене? Тариф в 3–5 долларов в месяц за VPS кажется приятной экономией на старте. Но если тариф выбран только по цене, счёт за простой, срочную миграцию и потерянных клиентов может прийти позже и оказаться выше, чем сэкономленная разница в ценнике.

Что скрывается за низким ценником? За низкой ценой могут стоять оверселлинг, общий диск, ограниченная поддержка и слабые гарантии по SLA. У части провайдеров низкая цена достигается за счёт плотного размещения клиентов на одной ноде: продаётся больше vCPU и RAM, чем физически доступно, в расчёте на то, что нагрузки не совпадут. В результате могут появляться CPU steal time, просадки I/O от соседей по железу и нестабильная производительность общего хранилища. SLA на бюджетном VPS-сервере может отсутствовать или ограничиваться формальным обещанием без понятной компенсации.

Реальные риски в продакшене. Под нагрузкой проблемы проявляются внезапно: API начинает отвечать с задержками, база данных упирается в I/O, сервис падает в самый неподходящий момент. Потеря данных из-за отсутствия бэкапов или срочная миграция перед дедлайном – реальные риски для проектов, которые выбирают инфраструктуру только по цене.

Как считать полную стоимость VPS? Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.

Чек-лист: признаки надёжного VPS:

•        SLA не ниже 99,9%

•        NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами

•        Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов

•        Автоматические бэкапы с проверенным восстановлением

•        Поддержка 24/7 с заявленным временем ответа

•        Гарантированная пропускная способность сети

Прежде чем продлевать текущий тариф, проверьте свой VPS по этому чек-листу. Если несколько пунктов вызывают сомнения – стоит пересмотреть выбор сервера для продакшена до первого серьёзного инцидента.

Что прокачать системному администратору для профессионально роста

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

Профессия давно вышла за пределы настройки серверов и учетных записей. Современному админу приходится работать с контейнерами, автоматизацией, наблюдаемостью и безопасностью. Здесь собрали несколько бесплатных уроков для тех, кто хочет увереннее решать текущие задачи или двигаться в сторону DevOps, SRE и DevSecOps.

↓ Заглянуть под капот Linux
^{Когда проблема находится ниже уровня сервисов и конфигов, полезно понимать, что происходит внутри системы.}

«Что такое модуль ядра. Как его написать, собрать, запустить»
3 августа в 20:00
За один вечер можно пройти путь от исходного кода до загрузки собственного модуля и перестать воспринимать ядро Linux как полностью закрытый черный ящик. Записаться

↓ Быстрее находить причины сбоев
^{Обычный мониторинг сообщает, что сервису плохо. Наблюдаемость помогает понять, где именно все пошло не так.}

«OpenTelemetry — наблюдаемость на блюдечке»
4 августа в 20:00
Метрики, логи и трассировки пригодятся, когда один запрос проходит через несколько сервисов, а источник задержки или ошибки не лежит на поверхности. Записаться

↓ Сделать деплой предсказуемым
^{Если выпуск новой версии зависит от набора ручных команд и памяти конкретного сотрудника, процесс пора автоматизировать.}

«Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера»
10 августа в 20:00
Полезно тем, кто хочет хранить состояние инфраструктуры в Git, контролировать изменения и откатываться без ночной археологии в терминале. Записаться

↓ Перестать искать логи по серверам вручную
^{Чем больше машин и контейнеров, тем меньше хочется подключаться к каждому из них ради одной строки.}

«Системы логирования: ELK, EFK или Graylog?»
17 августа в 20:00
Возможность сопоставить популярные стеки и понять, какой из них лучше подходит под конкретную инфраструктуру, объем данных и доступные ресурсы. Записаться

↓ Подготовиться к сбою до сбоя
^{Единственная точка отказа обычно не беспокоит ровно до того момента, пока не откажет.}

«Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy»
18 августа в 19:00

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

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

С днём системного администратора!

Стабильного коннекта, низкого пинга, работающего резервного копирования!

Почему аптайм зависит не только от VPS-провайдера?

Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.

Что именно гарантирует VPS-провайдер? SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.

Где на самом деле ломается аптайм? На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.

Ошибки на стороне команды. Релиз без стейджинга и механизма отката, отсутствие проверок состояния, ручные правки конфигурации в продакшене: всё это классические источники простоев. Мониторинг, добавленный «потом», не предупреждает о проблеме до того, как её замечают пользователи.

Как повысить реальный аптайм сервиса? Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.

Чек-лист надёжности:

• Бэкапы и снапшоты настроены и проверены

• DNS TTL снижен перед плановыми миграциями

• SSL-сертификаты обновляются автоматически

• Есть процедура отката для каждого релиза

• Мониторинг и алерты подключены до деплоя

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

Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?

Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?

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

Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:

ALTER ROLE replicator WITH REPLICATION;

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

Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:

systemctl reload postgresql

В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.

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

На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.

Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.

Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.

Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based

Есть у меня тулза для бэкапа фоточек с гугла - сделал ее когда бэкапилка QNAP приказала долго жить(TL;DR Google изменил API так, что идея автоматического бэкапа стала бессмысленной)

Первая версия утилиты работала очень топорно и работала на playwright+chromium(это важно)

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

Самое популярное такое решение работает на Firefox. Ну заменить один браузер на другой - что может пойти не так (спойлер: почти всё)

Сначала всё шло хорошо - кастомный FF удалось запустить на playwright с возможностью удаленного исполнения скипта автоматизации как раньше. Сценарий уверенно запустился и дошел до скачивания файлов. Скрипт нажимал ссылку, браузер начинал и успешно завершал загрузку, но скрипт так и висел, ожидая файла

Оказывается, FF в playwright не поддерживает события загрузки файлов, которых ждет. Совсем. Тут и случилось самое страшное. Что за вендорлок, почему я должен использовать именно chromium??? - подумал я..

Решение как заставить FF делать то, что нужно - нашлось быстро. Нужно просто использовать Selenium Grid

Событий загрузки там нет, но зато есть API доступа к скачанным файлам, на котором можно построить цикл ожидания загрузки. Кроме того, в него же удачно вписывалось шифрование кредов, которое раньше реализовывалось через отдельный сервис+контейнер

Первое же тестирование показало новую проблему. Playwright позволяет сохранить все cookies, вообще все и загрузить их в контекст СЕССИИ до загрузки какой-либо страницы. Selenium так не работает: он загружает/проставляет cookies только в контексте СТРАНИЦЫ. Это делает перенос данных авторизации гораздо мучительнее, ведь Google активно сопротивляется сбору cookies авторизации, редиректит с accounts.google.com на myaccount.google.com и т.д.

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

После решения проблем с cookies файлы в скрипте наконец-то стали загружаться.. но только маленькие🤠

Как только загружался 2ГБ архив - скрипт наглухо OOM-ился. Стандартный API загрузки файла передает его целиком, заэнкоженым в base64. Естественно, целиком загнать в base64 2ГБ - жестоко, и столько памяти скрипту бэкапа никто выделять не собирается.

Снова пишем плагин, который рядом с grid выставляет нормальные стриминговые ручки, которые позволяют читать файл кусочками

И вот на этом месте - ура, все работает как надо!
Но не проще ли было месяц назад ПРОСТО ВЗЯТЬ Chromium..🤔

CPU steal time: как измерить, как доказать и когда он ни при чём. В логах пусто, загрузка процессора умеренная, а приложение отвечает вдвое медленнее обычного. Один из кандидатов на объяснение — steal time: время, когда виртуальная машина была готова считать, но не получила физическое ядро.

Метрика простая на вид и очень легко используется неправильно. Ниже — как она устроена, как снять её так, чтобы результат что-то значил, и почему высокий steal сам по себе ещё не диагноз.

Как steal вообще появляется Гипервизор раздаёт физические ядра между виртуальными машинами. Когда планировщик гостевого ядра ставит задачу на vCPU, а гипервизор в этот момент отдал физическое ядро другой машине, гостевое ядро видит, что время прошло, а работа не выполнялась. Эта разница и учитывается как steal.

Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:

• конкуренция с соседними VM на ноде;

• ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;

• накладные расходы самого планировщика гипервизора;

• кратковременные всплески — миграция VM, резервное копирование ноды, обслуживание.

Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:

systemd-detect-virt

Аналог steal для контейнеров — троттлинг по cgroup:

grep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max

Растущий nr_throttled означает, что вы выбираете свою квоту. Это не соседи и не оверселлинг — это ваш лимит, и решается он либо оптимизацией, либо тарифом.

Какие значения считать нормой. Универсальной нормы нет — она зависит от платформы виртуализации, политики провайдера и тарифа. Практические ориентиры, которые у меня обычно работают:

• 0–1% — фон, встречается почти везде, игнорируем.

• 3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.

• выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.

Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.

Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.

Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:

• Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.

• Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.

• Steal ровным фоном 2–3% круглосуточно — накладные расходы платформы, обычно нормально.

Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.

Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:

• вывод sar -u 1 600 или график за несколько часов;

• mpstat -P ALL 1 за минуту — с разбивкой по ядрам;

• ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;

• конкретные временные метки, когда приложение деградировало;

• systemd-detect-virt и параметры тарифа.

Что не поможет

• Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.

• Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.

• Перезагрузка. Помогает только если приводит к переезду на другую ноду, и это лотерея.

Чек-лист

systemd-detect-virt                          # есть ли steal в принципе
vmstat 1                                     # характер: плато или выбросы
mpstat -P ALL 1                              # распределение по ядрам
sar -u 1 600                                 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat       # для контейн