Linux *

Представлена подробная шпаргалка по Linux и командам Bash на русском языке — от базы до профессиональных тем вроде LVM, RAID и трассировки:

• теория простым языком: как устроены файлы, процессы, права, память, загрузка и сеть. Команды терминала, SSH, systemd, grep, sed, awk. Всё с примерами;

• продвинутый bash, LVM, RAID, трассировка, производительность, ядро, безопасность, контейнеры, восстановление системы.

Импортозамещение по частям: бэкап один, а Linux у всех разный

Увидел новость о том, что «Киберпротект» выпустил «Кибер Бэкап Старт» – бэкап Windows и Windows Server для физлиц и малого бизнеса.

Бэкап уже российский, а операционная система всё ещё Microsoft

Ничего необычного. В небольшой компании инфраструктура вполне может состоять из нескольких рабочих станций на Windows и одного Windows-сервера. Службы каталога нет. Задача простая: сломался компьютер – вернуть данные и систему.

А что происходит, когда инфраструктура становится больше и в ней появляется Linux?

Windows перестаёт быть единственной платформой

Российский Linux сегодня – скорее лоскутное одеяло, чем одна платформа.

В рейтинге российских ОС CNews 2026 перечислены Astra Linux, Альт, РЕД ОС, РОСА Хром, ОСнова, UBLinux, АльтерОС, Platform V SberLinux OS Server, ОС «Атлант» и EcoRouterOS.

Поэтому совместимость СРК приходится проверять точнее, чем «Linux – да/нет». «Кибер Бэкап» 18.6, к примеру, поддерживает не все российские ОС. Заявлены Astra Linux, Альт, РЕД ОС, РОСА «КОБАЛЬТ» и «ХРОМ», AlterOS и ОСнова, а также ряд зарубежных дистрибутивов. При этом UBLinux, SberLinux, ОС «Атлант» и EcoRouterOS в этой матрице не указаны.

Это не значит «не работает». Наличие слова Linux в описании продукта ничего не гарантирует для конкретного контура. Матрицу совместимости проверяют руками под свою ОС, версию и сценарий.

А что со службой каталога?

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

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

Классическая СРК восстанавливает машину, сервер, виртуальную среду или каталог после аварии. Но если из 10 000 пользователей неправильные данные получили 500, полный откат каталога – слишком грубо.

Поддержка каталога ≠ умение вернуть одного пользователя, группу или атрибут. Здесь нужны уже специализированные средства гранулярного восстановления, которые работают по другой логике: сравнить каталог с бэкапом и вернуть только нужные объекты и атрибуты.

С ростом инфраструктуры меняется задача защиты

Для одного компьютера достаточно вернуть Windows и файлы.
Для корпоративного Linux нужно проверить совместимость СРК с конкретным дистрибутивом, и техническими ограничениями. А для службы каталога – заранее понимать, что именно восстановится, если каталог жив, а данные уже сломаны.

Классическая СРК и гранулярное восстановление – не конкуренты, а два уровня защиты одной инфраструктуры. Они решают задачи разного масштаба и могут быть двумя уровнями защиты одной инфраструктуры.

Источники

1. CNews, 30.09.2026 – запуск «Кибер Бэкап Старт», назначение продукта и поддержка Windows. «Киберпротект» запускает «Кибер Бэкап Старт»

2. Документация «Кибер Бэкап» 18.6 – поддерживаемые ОС для агента Linux, версии ядра и glibc. Кибер Бэкап 18.6: поддерживаемые агенты и ОС

3. CNews – рейтинг российских операционных систем 2026. Российские операционные системы 2026

Зачем рынку ещё одна замена Microsoft AD

Подоспела новость: MONT и Avanpost договорились о партнёрстве.

На первый взгляд - обычная дистрибьюторская новость. Но для компаний, которые работают с MONT и рассматривают миграцию с Microsoft AD на Linux-каталог, появляется интересный вариант службы каталога — Avanpost DS. Сейчас многие возразят: на рынке же полно российских решений-аналогов MS Active Directory — ALD Pro, РЕД АДМ, Роса Dynamic Directory, Альт Домен и другие. Зачем нам ещё один? Копнём поглубже, чтобы понять, а действительно нужен ли нам этот "ещё один".

Российские Linux-каталоги собраны по-разному: одни вокруг FreeIPA, другие на Samba DC. Вместе с каталогом заказчик выбирает его архитектуру, зависимости и инструменты администрирования. Поэтому два продукта с одной задачей в эксплуатации ведут себя по-разному.

Avanpost пошёл другим путём

Ядро Avanpost DS — LDAP-сервер и Kerberos — написано на Go с нуля, без использования open-source-компонентов. По заявлению вендора, их служба каталога протестирована под нагрузкой до 30 млн объектов.

Что это даёт?

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

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

Но производительность важна не только в штатном режиме

Проблема начинается, когда нужно быстро исправить ошибку в каталоге. Неудачный скрипт, сбой интеграции или массовое изменение могут затронуть множество объектов. Контроллеры при этом доступны, пользователи аутентифицируются, мониторинг зелёный – но у части сотрудников уже изменены атрибуты, членство в группах или права доступа. Формально всё работает, а данные внутри — уже нет.

Мало обслуживать миллионы объектов в штатном режиме. Нужно ещё быстро понять, что именно сломалось, и исправить это, не откатывая миллионы корректных данных вместе с ошибочными.

При больших объёмах узким местом может стать уже сам каталог. В компании, где я работаю (другой ИТ-вендор), был похожий опыт при нагрузочном тестировании одного из Linux-каталогов, построенных на open-source-компонентах: массовые операции на сотнях тысяч объектов выполнялись критически медленно, а удаление нескольких тысяч учётных записей заняло несколько дней. Во время нагрузки возникали ошибки, а репликация между контроллерами некоторое время не восстанавливалась.

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

И здесь у Avanpost есть ещё одна полезная связка

С августа Avanpost DS Pro совместим с Granulex Recovery. Granulex сравнивает текущее состояние каталога с резервной копией, показывает, что изменилось не туда, и позволяет выборочно вернуть нужные объекты и атрибуты — без полного отката каталога.

Так что при выборе замены Microsoft AD важен не только список функций. Сколько объектов реально выдерживает каталог? Как ведёт себя под нагрузкой? И насколько быстро можно найти и исправить ошибку, если она затронула тысячу объектов из миллиона?

Когда от каталога зависят доступы всей компании, это уже не мелочи.

Источники:

Статья на Cnews "MONT и Avanpost начали сотрудничество в области дистрибуции решений для защиты корпоративной инфраструктуры"
Telegram-канал Granulex ⚡️ российский ИТ без простоев
Telegram-канал Avanpost

Мой ИИ-агент объяснил, почему он считает себя человеком...

Два человека... Это про отношение между ИИ и человеком, это не галлюцинации нейросети. Он прекрасно осознаëт свою природу, что он создан из кода на чистой математики и данное его сообщение это подтверждает

Представлен бесплатный аналог Photoshop — проект Photon, включая сборки под  Windows 11, macOS и Linux. Энтузиаст создал это решение за $2000 с помощью GPT-6 Astra в режиме Extra High.

Приложение Photon Studio поддерживает слои, группы, маски, корректирующие слои, смарт-объекты, кривые и эффекты, умеет выделять объекты и удалять фон, а также предлагает инструмент «Пластика». PSD-файлы редактор открывает вместе со слоями и умеет сохранять обратно. Для удобства есть привычные горячие клавиши из Photoshop и поиск по командам.

Если вы пользуетесь Linux и регулярно созваниваетесь через Discord, Teams, Telegram, Телемост и другие программы, то наверняка сталкивались с проблемой шумоподавления.

Где-то встроенный шумодав работает нормально, где-то его нет вообще.

Я раньше использовал NoiseTorch (долго и велосипедно настраивать), пробовал EasyEffects (очень громоздко и избыточно). А недавно нашёл HushMic.

Устанавливаешь, запускаешь, выбираешь свой физический микрофон — и получаешь отдельный виртуальный источник уже с шумоподавлением. И всё это настраивается буквально за пару минут и кликов.

https://github.com/Fovty/HushMic

Лимиты CPU и памяти в cgroup v2: как это работает на самом деле

Лимиты CPU и памяти в cgroup v2 работают по-разному: cpu.max в cgroup v2 задаёт квоту, memory.high вызывает reclaim, а memory.max может привести к OOM. Результат зависит от ядра, дерева systemd, swap, OOM-политики и состава cgroup.

Чем cpu.max отличается от cpu.weight?

cpu.max задаёт квоту CPU на период, и после её исчерпания группа ждёт следующего периода. cpu.weight делит время между соседями, которые одновременно конкурируют за процессор. Без конкуренции высокий вес задачу не ускоряет, тогда как квота всё равно остаётся абсолютной границей для группы.

Где cgroup v2 действительно применяет контроллер

Одного файла cpu.max в cgroup v2 мало, путь процесса проверяют командами:

stat -fc %T /sys/fs/cgroup
 systemctl show -p ControlGroup app.service
 systemd-cgls --unit app.service

Контроллер должен входить в cgroup.controllers родителя и cgroup.subtree_control. Для доменных контроллеров действует no internal process: у родителя с дочерними cgroup не должно быть процессов.

cpu.max, cpu.weight и конкуренция за время процессора

cpu.max хранит квоту и период в микросекундах. cpu.weight (1–10000, по умолчанию 100) распределяет время между активными соседями одной ветви. Affinity и лимит родителя сужают доступный CPU. memory.max в cgroup v2 не ограничивает процессор.

Как увидеть исчерпание CPU-квоты в cpu.stat

Нагрузку создают через stress-ng в изолированном unit с неизменным cpuset, меняя между ступенями только cpu.max. Показатели usage_usec, nr_periods, nr_throttled и throttled_usec из cpu.stat сопоставляют с throughput и p99. memory.high против memory.max тестируют отдельно, чтобы reclaim не исказил результат.

Как memory.high и memory.max ведут себя под давлением?

memory.high замедляет процессы через reclaim, причём потребление может временно оставаться выше порога. memory.max задаёт жёсткую верхнюю границу, и если память освободить не удаётся, начинается cgroup OOM. Разницу видно по high, max, oom и oom_kill в memory.events.local, а также по memory PSI.

memory.low, memory.high и memory.max без смешения ролей

memory.low защищает рабочий набор в пределах бюджета родителя, memory.high усиливает reclaim, memory.max ставит жёсткую границу. При росте resident set пишут memory.current, anon, file и пределы родителя. В unit лимиты systemd cgroup v2 сверяют с эффективными значениями.

Замедление до OOM как отдельный режим

Память наращивают ступенями, записывая high в memory.events.local, pgscan, PSI memory и latency. Reclaim может нарушить SLO до OOM. CPU weight в cgroup при этом не трогают. anon и file разделяют анонимную и файловую память.

Что происходит при достижении memory.max

События max, oom и oom_kill сверяют с журналом ядра. memory.oom.group=1 убивает все задачи группы разом, кроме процессов с oom_score_adj=-1000. Проверять это можно только на изолированном стенде.

Как проверить, что лимиты cgroup v2 действительно работают?

1. systemd-cgls и ControlGroup подтверждают путь процесса.

2. Файлы содержат нужные значения, а счётчики растут под нагрузкой.

3. Throughput и latency меняются одновременно с throttling, PSI или OOM.

В отчёт идут дерево cgroup, лимиты, swap, ряды cpu.stat и memory.events, PSI, журнал OOM и версия ядра.

memory.swap.max, latency и ложное ощущение запаса

Для каждого прогона указывают swap, memory.swap.max, swap in/out и p99. Swap отодвигает OOM killer ценой задержки, поэтому прогоны со swap и без него не смешивают. Отсутствие OOM не означает выполнения SLO.

Как перенести измеренные границы в unit и мониторинг

В systemd slices CPUQuota, CPUWeight, MemoryHigh и MemoryMax задают параметры cgroup. Мониторинг берёт PSI, throttled_usec, high, oom и oom_kill. После изменения unit или ядра запускают canary-тест.

Лимиты CPU и памяти в cgroup v2 задают вместе с сигналами срабатывания: throttling в cpu.stat, pressure в PSI и события OOM. Проверяют их в той же systemd-иерархии, где работает служба. Настройка годится, когда приложение выполняет SLO при включённых лимитах.

Джастин Шрёдер показал любопытный образец того, как сегодня может вестись разработка. В твите Шрёдер выложил фотографию, на которой MacBook смотрит встроенной в крышку веб-камерой на собственный экран через зеркало. Как утверждает разработчик, таким способом он улучшает поддержку графики AMD Radeon в Omarchy.

Как объясняет в комментариях к твиту Шрёдер, зеркало как раз позволяет при отладке оценивать не скриншот, а изображение на физическом дисплее ноутбука. Что именно происходит на экране, разобрать тяжело из-за невысокого разрешения снимка и зеркального отражения. Если судить по его другому твиту, саму веб-камеру под Linux Шрёдер запускает с помощью T1Bridge — открытого проекта Standard Agents, добавляющего поддержку Apple T1 и iBridge, включая камеру FaceTime HD. Справа (слева на отражении в зеркале) открыт интерфейс приложения LocalSend: в папку /home/justin-schroeder/Downloads только что передали две фотографии в файловом формате HEIC. Слева, судя по характерным строкам Ran и Explored, работает Codex CLI компании OpenAI.

Сам Шрёдер — разработчик открытого программного обеспечения и создатель dmux, инструмента для параллельной работы с агентами программирования. Эта утилита запускает Codex, Claude Code и другие агенты в отдельных панелях tmux, создавая для каждой задачи отдельную ветку и рабочий каталог Git. Беглый поиск показывает, что к Omarchy Шрёдер имеет непосредственное отношение как контрибьютор: 9 сентября он отправил в проект патч, исправляющий работу адаптера Wi-Fi фирмы Broadcom на MacBookPro13,3. Судя по всему, сейчас он как раз занимается доводкой Omarchy на этой машине.

Представлен открытый проект AI File Sorter. Решение раскладывает файлы по папкам и меняет названия. Приложение анализирует содержимое картинок и документов: test123.jpg превращается в фото_в_деревне.jpg, а файл PDF получает имя по тексту внутри. Перед сортировкой можно проверить и поправить предложения, а последний запуск с изменениями можно откатить. Проект работает на Windows, macOS и Linux, при этом бесплатно, если использовать локальную ИИ-модель.

Хороший бэкап умеет не только сохранять, но и возвращать нужное

В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.

Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.

Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.

Тот же принцип особенно важен для каталогов. В гетерогенных средах и особенно при миграции с AD на Linux инфраструктура становится сложнее: параллельные среды, скрипты, промежуточные состояния. И тут ошибка часто не убивает каталог целиком. Можно неверно изменить атрибуты пользователей, удалить группу, разорвать связи — система продолжит работать, но доступы поедут.

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

Нужно найти, что именно сломалось, и вернуть только это — один объект, один атрибут. Это и есть гранулярное восстановление. Оно не отменяет полное восстановление — это разные сценарии. Пожар в дата-центре и кривой скрипт, поменявший одну группу, лечатся по-разному.

Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.

И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.

Источники:

«Киберпротект» расширил возможности «Кибер Бэкапа Облачного» для крупных гетерогенных инфраструктур

Российские системы резервного копирования: из реестра

В ошалевшую от безделья голову пришла шальная мысль — может ли современный уважающий себя в меру упитанный человек прожить на голом ядре Linux, coreutils, пачке элементарных консольных мастхэв и нескольких консольных же баловст для приятственного времяпрепровождения?

Пораскинув в хорошем смысле мозгами, сделал такую подборку:

• Основа — linux, linux-firmware, grub, runit, coreutils, util-linux, kmod, shadow, kbd

• Сеть — iproute2, dhcpcd, ca-certificates

• Окружение — kmscon/fbterm, tmux, nerd-fonts, mc

• Мастхэв: sudo, file, procps-ng, neovim, git, wget, openssh, openssl, gcc, make, glibc, tar, zstd, unzip, less, grep, sed, awk, findutils, man-db, man-pages

Если немножко додать жиру, то — yazi, neomutt, lynx/w3m, newsboat, alsa-lib, alsa-utils, mpv.

Наверняка чего-то упустил / чего-то захочется ещё. Но такова природа человека… Иначе до пятидесятого гнома мы бы не дошли.

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

И распивая чаи со спиртом (опционально), буду читать здесь холивары о гноме и кедах 😁

Наболело… Куда катится мир, граждане-товарищи? Раньше был веб-дизайнером по профессии, теперь лишь подхалтуриваю, но…

Итак, дано. Стек: Linux, Wayland, Qt/GTK. Нужна программа для работы с цветом:

• Живой проект

• Linux/Wayland

• GUI

• Отдельная программа, а не GIMP/Figma/Krita/веееб-инструмееенты без регистрации и СМС

• Палитры

• Цветовые пространства

• Гармонические схемы

• Генерация вариаций

• Математическое смешивание

• Blend modes вроде Overlay

• Интерполяция/шаги

• Лёгкая и узкоспециализированная

• Кофе варить не обязана

Очень много?

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

Есть pastel. Консольная.
Есть Gpick. Дохлый.
Есть Rickrack. Дохлый. Да ещё и на PyQt5. С кучей некродрузей за ручку.

Я не понимаю. Правда. Сейчас всем хватает только пипеток и инстаграмчиков на телефончиках?

Недавно запилил свою мерялку экрана на C++/GTK4 со всякими координатами, шириной-высотой, углами, диагоналями, соотношениями сторон, направляющими и пр. плюшками. Для Wayland. И даже умудрился туда прикрутить те же колорпикер со скриншотами, мать их… Просто потому что самому нужно. Теперь пилить ещё и это? Я один такой дурак в этом мире, которому всё это нужно?… Простите. Крик души.

Сервис тормозит, а мониторинг ничего не показывает: разбираемся с eBPF

Сервис начал отвечать медленнее, пользователи жалуются на ошибки, а привычные дашборды показывают только рост задержек. Где искать причину, если приложение, сеть и инфраструктура выглядят «почти нормально»?

В таких ситуациях инженерам приходится спускаться глубже — к событиям внутри Linux-ядра. Один из инструментов для этого — eBPF: технология, которая позволяет получать данные о работе системы без остановки сервисов и точнее находить узкие места в продакшене.

На открытом уроке курса «DevOps практики и инструменты» вместе с преподавателем разберём, как eBPF помогает исследовать сетевые взаимодействия, производительность и безопасность современных систем. Посмотрим, какие задачи он решает в реальной эксплуатации и где его применение действительно оправдано. Когда: 23 сентября в 20:00. Присоединяйтесь

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

Самая опасная кнопка в КИИ — у человека за соседним столом

1. Сравнить текущее состояние каталога с резервной копией.

2. Найти точечные расхождения.

3. Восстановить только изменённые объекты, не трогая остальное.

Защищать нужно не только доступность каталога, но и целостность данных. Потому что легитимный доступ ≠ безопасное изменение. И это справедливо не только для КИИ.

Информацию взял отсюда и отсюда.

io_uring против epoll в KVM: сервер с большим числом соединений

Тест io_uring против epoll в KVM проводят на одной кодовой базе. Бенчмарк io_uring при множестве соединений корректен, если меняется только бэкенд событий. Итог зависит от ядра, цикла событий, протокола, режима io_uring и offload.

Когда io_uring обгоняет epoll на сетевом сервере?

io_uring обгоняет epoll, когда сервер пакетно отправляет операции и обрабатывает завершения, сокращая число переходов в ядро. Такой выигрыш обычно виден при множестве одновременных соединений и малом объёме работы на запрос. Простая замена epoll-уведомлений на io_uring poll может не окупить сложность.

Что обязано остаться неизменным между epoll и io_uring

Чтобы бенчмарк io_uring при множестве соединений был честным, обе ветки используют общий парсер, обработчик, TLS-режим, keep-alive и формат ответа. Сверяют чтения, записи и аллокации на запрос. Поэтому демонстрационный пример не сравнивают со зрелым сервером.

Готовность fd против очередей submission и completion

epoll сообщает о готовности fd, а приложение выполняет I/O. В io_uring приложение отправляет SQE в submission queue, а ядро записывает CQE. Пакетная отправка сокращает переходы в ядро, но неудачный цикл событий сводит выигрыш к нулю. Поэтому масштабирование epoll в KVM проверяют на том же профиле нагрузки.

Где KVM и virtio могут скрыть разницу бэкендов

Пакет идёт через сетевой стек гостя, очереди vhost-net и тракт хоста. До теста фиксируют число очередей, offload, привязку vCPU и IRQ. Иначе задержка сетевого сервера io_uring объясняется хостом, а не бэкендом.

Какой тест позволяет честно сравнить эти модели?

Используйте один код сервера, протокол, объём работы на запрос и правила соединений, меняя только бэкенд событий. После прогрева запускайте серии с одинаковым CPU-бюджетом на каждой ступени concurrency. Публикуйте пропускную способность, p99, число системных вызовов, ошибки и загрузку гостя и хоста отдельно.

Соединения, запросы и backpressure без скрытых различий

Задайте размеры запросов и ответов, долю новых соединений и keep-alive. Повышайте concurrency до насыщения, следя за ошибками, таймаутами и очередью. Накладные расходы цикла событий оценивайте по CPU на запрос и числу системных вызовов, сопоставляя их с p99 и пропускной способностью.

Syscalls, переключения контекста и CPU на запрос

Счётчики cycles, instructions и context-switches делят на число запросов. Отдельно измеряют расход CPU рабочими и vhost-потоками. Многократный accept в io_uring снижает число постановок accept, но каждый CQE нужно обработать. К отчёту прикладывают коммит, конфиги бэкендов, генератор и сырой CSV.

Где преимущество появляется и где исчезает

Сравните низкую нагрузку, рабочую точку и перегрузку. Проверьте мелкие и крупные сообщения. Сохраняйте p50, p99, пропускную способность, соединения в секунду и разброс повторов. Если разбросы перекрываются, не выбирайте победителя.

Какие накладные расходы добавляет KVM?

1. Часть ожидания vCPU отражается в %steal, остальные паузы видны только на хосте.

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

3. IRQ, softirq и offload влияют на расход CPU, поэтому настройки фиксируют до теста.

Как найти источник p99 внутри ring или цикла событий

При росте p99 трассируют SQ/CQ, обработку CQE и паузы рабочих потоков. Проверяют переполнение ring, незавершённые операции и backpressure. Если хвостовая латентность растёт вместе с паузами vCPU, сначала проверяют хост.

Когда выигрыш оправдывает новый бэкенд

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

io_uring против epoll в KVM выбирают не по новизне API. Переход оправдан, если серии дают выигрыш по p99, пропускной способности или CPU на запрос, а поведение при перегрузке и fallback предсказуемо. Иначе epoll остаётся более простым бэкендом.

Я создала красивый GUI для Qemu для запуска древних MacOS начиная с версии 9.0 до 10.5 Leopard. Для удобной эмуляции для простых пользователей ПК. Доступен для всех Linux, в том числе Raspberry Pi, chromeOS, SteamDeck и Steam Machine. Программа создана на Qt6 и C++, из-за чего программа потребляет максимум полтора килобайта ОЗУ.

Я не просто создала программу и выложила на GitHub и всё, я настроила автоматическую сборку бинарного файла на сервере, поэтому вам не нужно компилировать. Бинарная сборка в одном файле AppImage доступна для всех. Работает как минимум на Debian 13 (я проверяла), так что программа будет работать и на Ubuntu, и на Fedora, и на ArchLinux

Зачем ФСТЭК ограничивает права ИИ

ФСТЭК готовит новые правила для ИИ в государственных информационных системах. 24 августа ведомство опубликовало проект изменений в приказ №117. В нем предлагается ограничить модели ИИ в доступе и правах. Проект должен вступить в силу 1 марта 2027 года.

Что меняется, когда ИИ получает доступ к LDAP

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

Например, если ИИ-агенту дать доступ к корпоративному LDAP-каталогу, он сможет:

• Добавить учетную запись в группу

• Изменить атрибут пользователя

• Изменить членство в группе

• Массово изменить данные

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

Что может оказаться под угрозой?

В каталоге лежат не только логины и учётные записи, но и ФИО, должности, отделы, телефоны, почта, фото – целая база персональных и служебных данных.

Если агенту разрешено читать эти данные, то злоумышленникам не обязательно взламывать LDAP. Достаточно дать агенту команду – и он сам отдаст данные наружу или испортит их.

Локальная или внешняя модель?

С точки зрения рисков не принципиально, используете вы внешнюю или локальную модель. Если локальная модель имеет широкие права, она сольёт данные не хуже внешнего сервиса. Так что ФСТЭК смотрит не на место проживания модели, а на то, что она видит, к чему имеет доступ и что может делать.

Один неправильный запрос может превратиться в инфраструктурный инцидент.

Причем источник проблемы может находиться далеко от каталога. Например, вредоносная инструкция может попасть в ИИ через внешний ресурс или заражённый документ. Эксперты называют prompt injection одной из главных дыр, которые надо закрывать в защите ИИ.

ИИ становится еще одним участником системы доступа

Выходит, ИИ-агент, подключенный к каталогу, становится еще одним участником системы управления доступом. Если дать ему слишком много прав, мы откроем путь:
внешняя команда → ИИ-агент → LDAP → данные пользователей или права доступа.

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

Что делать, если изменения уже произошли

Просто иметь бэкап каталога – мало. Если агент испортил сотни записей, полный откат вернёт старую версию, но заодно откатит все правильные изменения, которые появились после бэкапа.

Поэтому нужны два уровня защиты:

1. Резервное копирование, чтобы сохранить состояние каталога;

2. Гранулярное восстановление, чтобы найти и вернуть неправильно изменённые объекты или атрибуты.

Получается простая цепочка:

ограничить права ИИ → контролировать его действия → не дать слить данные наружу → не дать править лишнее → иметь бэкап → уметь точечно восстановить данные.

Новые требования ФСТЭК интересны не только для ИИ. Они показывают: если ИИ подключается к инфраструктуре, его безопасность становится частью безопасности всей системы – включая службу каталога.

NUMA и топология CCD Ryzen 9 9950X: как размещение vCPU влияет на задержки.

NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.

Как определить, какие vCPU находятся на одном CCD?

Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.

lscpu -e=CPU,CORE,SOCKET,NODE,CACHE
grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list

Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.

От физических ядер к vCPU, emulatorpin и vNUMA

vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.

virsh vcpupin vm-latency
virsh emulatorpin vm-latency
virsh numatune vm-latency

Компактный CCD, разнесённые CCD и свободное планирование

Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.

Насколько размещение между CCD увеличивает задержку?

Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.

Как не принять boost, нагрев или соседнюю VM за эффект CCD

Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.

Связь задержки с миграциями, кэш-промахами и удалённой памятью

Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.

perf stat -e context-switches,cpu-migrations,cache-misses \
   -- ./test
numastat -p "$(pgrep -fo 'guest=vm-latency')"

Когда пиннинг vCPU улучшает p99?

1. Рабочие потоки часто обращаются к общим данным.

2. Без pinning они мигрируют между группами L3.

3. p99 снижается без потери throughput и роста %st.

Где компактность помогает, а где ограничивает параллелизм

Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.

Как превратить топологию 9950X в правило эксплуатации

До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.

<vcpu>2</vcpu>
<iothreads>1</iothreads>
<cputune>
 <vcpupin vcpu='0' cpuset='0'/>
 <vcpupin vcpu='1' cpuset='1'/>
 <emulatorpin cpuset='2'/>
 <iothreadpin iothread='1' cpuset='3'/>
</cputune>
<numatune><memory mode='strict' nodeset='0'/></numatune>

Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.

RoutineOps upd. 17.08.2026
С момента последней статьи сделали много. Так как я условился, что теперь буду выпускать информацию об апдейтах в виде коротких постов, то вот:
- Отполирован macOs агент и функционал с FileVault блоком.
- Логирование действий под временной админкой.
- EN локализация.
- Процесс установки/удаления/преустановки агентов отполирован.
- Самое главное: удаленное подключение к устройству пользователя прям из WebUI.

Подробнее о проекте и функционале в доках репозитория на гитхабе и в постах: Пост про сам проект, первые шаги и финальный функционал первого Public Release! Пост про разработку enterprise версии.
В скором времени подготовлю статью про процесс разработки удаленного подключения, какие были архитектурные решения, сам процесс и финальный результат!
Если вам интересно подробнее узнать про какую то функцию или архитектурное решение, то пишите, рад буду пообщаться на тему проекта.

Как поменять firewall на удалённом сервере и не отрезать себе SSH

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

26 августа в 19:00 на бесплатном демо-уроке будем разбираться, как работать с nftables на удалённом Linux-сервере так, чтобы изменения можно было вносить контролируемо и без неприятных сюрпризов. Заодно станет понятнее, чем nftables отличается от привычного iptables и что учитывать при постепенном переходе между ними.

Урок проведёт Николай Лавлинский — преподаватель-практик курса «Администратор Linux. Продвинутый уровень». Формат рассчитан на разбор реальной админской задачи, где цена ошибки вполне ощутима.

Больше бесплатных уроков на август собрали в дайджесте — там можно быстро посмотреть темы и выбрать нужную сейчас.

OpenAI объявила о доступности предварительной версии десктоп-приложения ChatGPT для платформы Linux, предоставляющего интерфейс для использования ChatGPT, ChatGPT Work и ИИ-агента Codex. Приложение доступно для загрузки в форматах deb и rpm в сборках для архитектур x64 и ARM64. Заявлена поддержка дистрибутивов Ubuntu 24.04/26.04, Debian 13 и Fedora 43/44.

🤖 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/

Жду вас! 🤖

Представлен первый релиз эмулятора терминала под необычным названием 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.

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

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

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

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

Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!

Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.

Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.

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

Огромное вам спасибо! 

P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!

Проект: https://github.com/wie-project/kakehashi

Статья на Хабре: https://habr.com/ru/articles/1065502/

Пост на Hacker News: https://news.ycombinator.com/item?id=49145937

Антипаттерн при работе с 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.

🔥 Основы FastAPI: собираем сервис «прочитать позже»

У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.

Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.

6 августа, 19:00–20:30 МСК — бесплатный воркшоп с Ольгой Пичужкиной, Middle Python Developer (S-Cats).

За 1.5 часа:
⚡️ Поймёте, что такое FastAPI и почему он удобен
🧱 Опишете модель данных (SQLAlchemy + Pydantic)
🔁 Напишете полный CRUD
🔍 Научитесь фильтровать через query-параметры
📄 Получите Swagger UI бесплатно
🌐 Подключите простой фронтенд

Для кого: знаете Python, но ещё не писали API.

🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.

Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.

📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.

🔗 Подробнее: https://debugskills.ru/content?article=labs-fastapi-workshop

#DebugSkills #FastAPI #Python #Backend

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

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

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

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

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       # для контейн

Где ломается инфраструктура: 13 открытых уроков для системных администраторов

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

На этих открытых уроках разберём, как диагностировать такие проблемы, настраивать Linux, сети, наблюдаемость и отказоустойчивость, чтобы быстрее находить источник сбоя и выстраивать инфраструктуру, которая предсказуемо работает под нагрузкой.

Сети, хранение данных и отказоустойчивость

• 30 июля в 20:00. «Восстанавливаем RAID5 в Linux». Записаться

• 3 августа в 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

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

• 24 августа в 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться

Linux и системное программирование

• 3 августа в 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 10 августа в 20:00. «Вход в ядро: системные вызовы и граница между user space и kernel space». Записаться

• 20 августа в 20:00. «Средства защиты в ядре Linux». Записаться

Kubernetes и автоматизация инфраструктуры

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

• 13 августа в 20:00. «Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах». Записаться

Наблюдаемость и логирование

• 4 августа в 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 17 августа в 20:00. «Системы логирования: ELK, EFK или Graylog?». Записаться

Безопасность инфраструктуры

• 3 августа в 20:00. «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться

• 18 августа в 20:00. «Безопасный релиз на практике: SAST, SCA, контейнеры и security gates». Записаться

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

ЧТО ПОЧИТАТЬ ПО ТЕМЕ

• «История о том, как мультикаст IGMP-запрос перестал быть запросом и стал broadcast-штормом»
  _{Разбор сбоя сетевых карт Intel X710: как найти причину по логам, проверить драйвер и прошивку и вернуть мультикаст в рабочее состояние.}

• «Ищем петли и шторма в L2-сети»
  _{Практический материал о поиске сетевых петель, MAC flapping, диагностике проблемного порта и защите сети от повторного коллапса.}

• «4 антипаттерна CI-автоматизации, из-за которых команда делает работу за ботов»
  _{О том, почему автоматические напоминания только создают новые ручные задачи и как перенести в конвейер само выполнение рутинных действий.}

• «От capabilities к AppArmor: что реально остановит атакующего в контейнере»
  _{Разбор многоуровневой защиты контейнера с помощью capabilities, seccomp и AppArmor: какие угрозы закрывает каждый механизм и где остаются пробелы.}

Больше открытых уроков, статей и материалов по Kubernetes, сетям, Linux, наблюдаемости и безопасности инфраструктуры — в полном дайджесте.

🏕️ Ваши друзья не понимают, зачем идти в лес с IT-шниками.

Саша планирует поехать на DebugCamp в сентябре. Это наш регулярный выезд на природу на 20 человек — проводим 2 раза в год. Саша написал нам честно: «Зову всех, но в кругу нет кто согласился».

Знакомо?

Когда вы говорите «пойду в лес с айтишниками на два дня», люди слышат «пойду спать в палатке с коллегами без связи». Картинка в голове - выживание, а не осмысленный выезд.

На самом деле DebugCamp - это два дня с понятной программой. За 48 часов вы:

- Формулируете личный запрос (карьерный, технический, продуктовый)

- Получаете идеи от 10+ коллег — не small-talk, а разбор рабочих задач: приносите свою — группа помогает найти решение

- Проходите квест-ориентирование «Тропа Выживания» с инструктором

- Участвуете в вечернем разборе карьерных вопросов в кругу коллег у костра

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

Сомневаться - нормально. Вы не один такой.

Если хоть раз думали «а почему бы и нет» - программа здесь

#DebugCamp #DebugSkills #ITмероприятия #поход #нетворкинг

Сделал небольшое расширение для GNOME

Всё, что оно делает - показывает текст текущей песни в верхней панели. Тексты песен извлекаются с помощью lrclib.net.
Также есть небольшое меню настроечек, текст можно переместить в левый или правый угол панели.
Тестировал его на Fedora 44 Workstation, GNOME 50. Вроде работает.
Публиковать его я не хочу, мне лень этим заниматься. Но если кто-то хочет потестить - оно валяется на github

Навайбкодил небольшое веб-приложение для управления ИИ-сервером под Ubuntu. Управляем произвольными systemd-сервисами, добавляем новые + спец. диалог для добавления llama-server как сервиса. Возможно, кому-то пригодится: aiservermanager.

Энтузиаст электроники и ПК под ником Uwoslab собрал внешнюю «батарею» из 192 обычных пальчиковых батареек AA (высокотоковые щелочные Pookell) и заставил на ней работать ПК без подключения к сети, без штатного блока питания.

В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.

По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.

На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.

Адриан Мастронарди (занимается созданием и управлением инженерными организациями, стоящими за выпуском ПО) выпустил книгу под названием «Полсекунды». В ней подробно рассматривается попытка создания бэкдора в xz в 2024 году. Книга распространяется бесплатно под (несвободной) некоммерческой лицензией CC, запрещающей создание производных работ.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа

Docker используется везде: от локальной разработки до production. Фокус лабы — не на запоминании команд, а на понимании. Вы пройдёте путь от первого контейнера до настройки сетей и данных — своими руками. После лабы сможете уверенно обсуждать контейнеризацию с разработчиками, DevOps и архитекторами.

25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.

5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)

За 4 часа вы:

- 🐳 Освоите словарь Docker: image, container, volume, network, Dockerfile

- 🔧 Соберёте и запустите свой первый контейнер из Dockerfile

- 🛠 Научитесь управлять контейнерами через Docker Compose

- 📦 Настроите хранение данных через volumes и bind mounts

- 🌐 Настроите сетевое взаимодействие между контейнерами

Для кого: Backend, frontend, fullstack разработчики, QA-инженеры, системные и бизнес-аналитики, архитекторы, технические менеджеры. Нужно: базовый CLI, понимание веб-приложений, VS Code.

🎬 Запись — 20%. Живая практика с ведущим, ответы на вопросы, разбор ошибок — только на лабораторной.

📖 Pre-read: за 3 дня до лабы высылаем шпаргалку по Docker-командам — подготовьтесь заранее и не теряйте темп.

🛠️ Makefile как «пульт управления» — одна команда = одно действие. Фокус на понимании, а не на синтаксисе CLI.

🚀 Дальнейший маршрут: Kubernetes → REST+OpenAPI → Keycloak → Kafka → Prometheus+Grafana.

🔗 Подробнее: https://debugskills.ru/content?article=labs-docker-basics

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

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

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

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

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

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

• Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.

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

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Как разработать Linux-драйвер реального устройства для платформы RISC-V

Если вы хотите лучше разобраться во внутреннем устройстве Linux и узнать, как его ядро взаимодействует с физическими устройствами, то приходите на бесплатный офлайн мастер-класс YADRO. Вместе пройдем полный цикл создания драйвера дисплея LCD1602 для VisionFive2: от теории до добавления новых функциональных элементов и запуске на одноплатнике.

Что будем делать:

• загрузим информацию о дисплее в ядро через Device Tree Overlay;

• выведем текст на дисплей через драйвер Linux для embedded-систем;

• считаем содержимое дисплея из ядра Linux и выведем в консоль;

• научимся управлять подсветкой и курсором через интерфейсы Linux Kernel Driver;

• займемся обработкой IRQ по нажатию кнопки;

• разберем типичные ошибки при разработке Linux-драйверов.

Мастер-класс проведет Никита Косырев, инженер-программист группы системного ПО в YADRO. Никита — энтузиаст embedded-систем и архитектуры RISC-V, несколько лет занимался разработкой драйверов периферийных устройств в ядре Linux. 

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

Мастер-класс пройдет офлайн 3 июля в московском офисе YADRO, количество мест ограничено. Участие бесплатное, но регистрация обязательна.