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

Дайджест Рег.облака за июль

В июле запустили третий этап Free Tier — бесплатный облачный сервер, ресурсов которого хватает уже на бизнес-проекты. Плюс упростили работу с ispmanager, открыли линейку «Стандартные» в двух регионах, добавили готовые образы в аттестованный контур ФЗ-152 и поделились исследованием о спросе на облако и GPU. Ниже — главное.

Запустили третий этап Free Tier — теперь и для бизнес-нагрузок

Расширили бесплатный облачный сервер до конфигурации, которой хватает для корпоративных порталов, крупных интернет-магазинов и ресурсоемких сервисов. На третьем этапе Free Tier дает выделенный облачный сервер бесплатно на два месяца: два виртуальных ядра, 4 ГБ оперативной памяти и 40 ГБ NVMe. Сервер подходит для проектов на «1С-Битрикс», переноса крупных сайтов с виртуального хостинга, баз данных и подготовки CI/CD-сред.

Подробности — на странице программы.

Исследование: спрос смещается к облаку, bare metal и GPU

Посмотрели, как за два года изменился спрос бизнеса на инфраструктуру. В публичном облаке акцент сместился с запуска проектов на резервирование: снапшоты используют 35,2% компаний малого бизнеса и 37% среднего. В dedicated и bare metal стало больше крупных клиентов — число компаний с расходами выше 500 тыс. руб. в месяц выросло более чем вдвое.

Особенно вырос спрос на GPU: за январь–июнь 2026 г. потребление прибавило 507% год к году. Чаще всего берут NVIDIA A4000 — у 63% компаний, и приходят за ускорителями уже не только ИТ, но и электронная коммерция, производство, логистика и финансы.

Все цифры — в исследовании.

Управление ispmanager для выделенных серверов в личном кабинете Рег.облака

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

Открыли линейку «Стандартные» в Москве-1 и Санкт-Петербурге-1

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

Готовые образы GitLab, GitLab Runner, Nextcloud и Portainer в регионе Москва ФЗ-152

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

Разобрали свои продукты в статьях

В июле вышли два продуктовых обзора на Хабре — если пропустили, читайте:

• Логи, бэкапы, образы, артефакты: где мы используем S3 внутри Рег.облака — как объектное хранилище работает у нас под капотом;

• MCP Gateway: когда инструменты перестают быть интеграцией и становятся архитектурой — про MCP-серверы и подход к их устройству.

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Все, что нужно знать DevOps-инженеру: сводка за лето 2026

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

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

• Prometheus 3.5 LTS перестал поддерживаться 31 июля. Новая 3.13 LTS будет поддеживаться до 31 июля 2027. Лучше прямо сейчас запланировать переход всех инстансов Prometheus с 3.5 LTS и других устаревающих версий на актуальную 3.13 LTS. Не забудьте проверить совместимость стека и протестировать обновление в staging.

• В Argo CD обнаружились три уязвимости. Утечка секретов через ServerSideDiff (CVE-2026-43824), обход авторизации (CVE-2026-42880) и RCE в repo-server (CVE-2026-15416). Затронуты 3.2.0–3.2.10 и 3.3.0–3.3.8, учитывая, что как раз вышла свежая версия 3.5, самое время обновиться.

• Self-hosted runner ниже 2.329.0 не зарегистрируется. GitHub просто перестанет пускать к себе раннеров-старичков. Лучше обновиться, чтобы не словить падение CI/CD, на установку свежей версии теперь отводится 30 дней.

• Неявная выкачка кода из форка в pull_request_target и workflow_run теперь запрещена. Если вдруг ваш пайплайн внезапно перестал видеть код PR — поздравляем, вы нашли у себя уязвимый workflow. Это была дыра в безопасности, через которую можно было украсть секреты или изменить ваш код прямо из PR.

• Выпущены патчи Etcd: v3.7.1, v3.6.14 и v3.5.33. Они закрывают утечку watch-ответов через границы RBAC и неограниченное создание goroutine на TLS-handshake. Проверьте, не используете ли вы ту версию etcd, которая дает возможность читать ключи и DoS’ить кластер, ну и не забудьте обновиться.

⚙️Про куберы

Kubernetes научился более умно работать с GPU и другим специальным железом. DRA (Dynamic Resource Allocation) вырос из «пробной» технологии, в штатный механизм. Теперь можно описывать, какое именно устройство вам нужно при выделении, как его делить и что делать при отказе.

Linkerd научился замечать, что конкретный сервис уже перегружен, и направлять новые запросы к другим доступным репликам: у версии Linkerd 2.20 появилась rate-limit-aware балансировка, а destination controller основательно переработали.

Istio добавил экспериментальный agentgateway — отдельный gateway‑proxy для ИИ‑агентов и MCP‑серверов. Еще развивается ambient multicluster: можно соединять сервисы в нескольких Kubernetes‑кластерах в одну mesh‑сеть без sidecar’а в каждом поде.

⛓️‍💥Про цепочки поставок

4 августа произошла масштабнейшая атака на цепочку поставки npm: в более чем 400 легитимных JavaScript‑пакетов встроили червя ChainDrop, который при установке крадет секреты разработчика или CI/CD и с украденным npm‑токеном сам заражает следующие пакеты. Работа для каждого на ближайшие недели — проверить dependency tree и lockfiles на скомпрометированные версии, очистить npm/yarn‑кеши в CI и на рабочих машинах, ну и отозвать и перевыпустить все доступные там секреты с чистого хоста.

CISA обновила минимальные элементы SBOM: подпись автора, инструмент генерации, хеш и алгоритм, лицензия, явные unknowns, машиночитаемость. CRA тоже требует вести машиночитаемый SBOM, поэтому тем, кто работает с рынком ЕС, уже стоит встроить генерацию и хранение SBOM в CI/CD: с декабря 2027 года он станет обязательным.

📊Про наблюдаемость

OpenTelemetry стал graduated-проектом CNCF, это по факту означает, что теперь у нас есть вендоронезависимый стандарт для сбора метрик, логов и трейсов, на который можно опираться при построении наблюдаемости.

Loki 3.6 получил горизонтально масштабируемый compactor. Теперь часть тяжелой работы по удалению логов можно раздать worker‑репликам. Но функция пока экспериментальная.

Grafana Alloy закрепился как официальный дистрибутив OTel Collector. Теперь, если вы строите или обновляете пайплайн сбора телеметрии на Grafana‑стеке, Alloy становится стандартным кандидатом №1, хоть функция пока экспериментальная.

Мы бы рассказали еще про статьи в нашем блоге на тему DevOps, но не можем — места нет.

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

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, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

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