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

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

Мы открываем его, видим три колонки цифр и букв, и кажется что все предельно ясно-понятно. Но почему адреса считаются шестнадцатеричными, что такое ниббл и зачем он вообще нужен? В этой статье мы не просто напишем свой hex-редактор на Python — мы разберем, как он устроен, от битового представления до цветовой подсветки. Выясним, чем подсветка по нибблам отличается от подсветки по категориям байтов, и почему градиенты в hex-дампе — это не просто украшение, а рабочий инструмент.

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

Будет и код, и архитектура, и результат, и практика.

Kubernetes ближе к Linux: много компонентов, контроллеров, CRD, операторов и внешних проектов собираются в живую экосистему. Сила там в открытом расширении и конкуренции подходов. Torque я пытаюсь делать ближе к FreeBSD и SQLite: меньше россыпи деталей наружу, больше «батарейки включены», единая система с документацией, доказательствами, логами и объяснениями внутри. Но начинался проект с инстурмента для дебега поэтому давайте рассмотрим как использовать Torque для отладки в k8s.

Две сцены, которые видел в разных компаниях в последний год.

Сцена первая. На стене в кабинете директора по ИТ висит большой телек, на нём дашборд: «Availability 99.83%», зелёные плашки, всё хорошо. В этот же момент этажом ниже бухгалтерия пишет в поддержку: «1С зависла, не можем закрыть смену». Дашборд не врёт — 99.83% хостов реально доступны. Просто из этих хостов 78 — тестовые стенды, 12 — резервные узлы, и ещё пачка в SCADA‑сегменте, который вообще про другое.

Сцена вторая. Заходишь в Zabbix новой компании после предыдущего админа. Четыре тысячи хостов, двенадцать тысяч триггеров, средний возраст триггера три года. Runbook'ов нет. У всего severity High. Алерты падают в один телеграм‑чат на пятьдесят человек, который дежурный молча мьютит первым делом после прихода на смену.

Если хоть одна сцена узнаваемая — статья для вас. Это попытка структурировать ошибки, на которых ломается большинство Zabbix‑инсталляций в крупных компаниях с 1С, Exchange, SCADA, legacy‑Windows‑стеком и КИИ‑сегментами.

Это не учебник и не пошаговая инструкция — каталог граблей из практики работы с крупной разнородной инфрой: 1000+ хостов, 1С, SCADA, КИИ‑сегменты, legacy Zabbix от предшественников. На облачной 20-хостовой инсталляции половина пунктов будет избыточна. Конкретные пороги (CPU > 85%) — отправная точка, не догма. Если текст расходится с реальностью — побеждает реальность.

Привет, Хабр! На связи Юрий Власенко, Senior DevOps инженер в РТЛабс. Сегодня я расскажу о том, как наша команда автоматизировала сложный, бюрократизированный и многоуровневый релизный процесс компании и превратила его в тестируемый объектно-ориентированный код на Groovy (Jenkins).

CKS является довольно специфическим экзаменом по Kubernetes и если вами активно не используются инструменты, которые рассматриваются на экзамене, то подготовка будет сложнее. У меня ушло на подготовку 8 месяцев и две попытки, где большую часть времени не было четкого плана как подготовится к экзамену, так как информации в интернете не так много, как при подготовке к CKA. И вам нужно сдать Certified Kubernetes Administrator (CKA), чтобы вас допустили до CKS.

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

Этап первый — разведывательный

Можно бесплатно порешать задачи на https://killercoda.com/ Есть два неплохих курса, где можно попрактиковаться в решении задач.

https://killercoda.com/ronnyardi

https://killercoda.com/killer-shell-cks

Рекомендую перенести в отдельный документ каждую задачу с вопросом и решением с ссылками на документацию на https://kubernetes.io/docs/home/ и вашим кратким комментарием как вы понимаете, о чем вообще идет речь и сложная ли для вас задача. На первом этапе вам нужно научится быстро ориентироваться в документации. Например, очень много вопросов по Security Context и Network Policy. Нужно понимать какой Security Context можно задавать на уровне пода, а какой на уровне контейнера. Это можно посмотреть через встроенную документацию.

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

История корпоративных систем хранения данных – это путь от жестко специализированных «черных ящиков» к гибким программным платформам. Каждый шаг этой эволюции решал проблемы прошлого, но неизбежно порождал новые противоречия. Сегодня, столкнувшись с радикальным усложнением инфраструктур (от классических ЦОД до частных облаков и объектов КИИ), – отрасль оказалась в точке, где наследие прошлых архитектурных решений стало главным ограничением для будущего. Современная корпоративная инфраструктура перестала быть монолитом. Сегодня это спектр архитектур и моделей потребления, каждая из которых предъявляет уникальные требования к системе хранения данных. С одной стороны - классические ЦОД с четким разделением ролей, ручным управлением и наследием в виде дорогих специализированных массивов. С другой - динамичные частные облака и гибридные среды, где инфраструктура должна предоставляться как сервис, масштабируясь по требованию и работая в условиях множества платформ. Между ними - гиперконвергентные кластеры, среды для критичных приложений (СУБД, VDI) и инфраструктура объектов КИИ, где на первый план выходят экстремальная производительность, отказоустойчивость и соответствие регуляторным требованиям. Все это многообразие объединяет одно требование: система хранения сегодня должна одинаково хорошо работать везде, будь то классический ЦОД или частное облако.

В 1995 году Тату Илонен написал письмо длиной с пост на Хабре и бесплатно получил номер ssh -p 22 user@host, который теперь знает каждый сисадмин. Но до этого порты были однонаправленными, чётные номера считались ненужными, а половина слотов вообще пустовала. О том, как порты стали «дверями» в сервер и что останется от них через десять лет, рассказал в статье. 

Привет, Хабр.

У многих дома крутится сервер или обычный NAS. На жестких дисках годами копится семейный архив: фотки из отпусков, видео с телефонов, старые кадры с мыльниц. Все это лежит гигабайтами в папках вроде “2023_06_12_дача” или просто свалено в кучу в директории DCIM.

В какой-то момент я понял, что хочу навести во всем этом порядок, но не руками. Так родился проект Gailery - локальная веб-галерея для домашнего сервера. Сегодня на моем стенде она безболезненно переваривает огромный личный архив из более чем 100 тысяч фотографий и почти 10 тысяч видеороликов. При этом оригинальные файлы лежат в полной безопасности: папка с медиа монтируется в контейнер в режиме “только чтение” (Read-Only).

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

Привет, Хабр! Меня зовут Артём, в YADRO я работаю инженером инфраструктуры: виртуализация, мониторинг, контейнеризация — это мое ежедневное. Также занимаюсь инфраструктурной автоматизацией. В декабре ко мне пришли коллеги с запросом инфраструктуры под инференс. Но Kubernetes на старте этой истории был для меня темным лесом: уровень «развернуть и передать», не более. Чтобы закрыть пробел в квалификации, решил взяться за проект. Вся история и итоги — далее в посте.

Как я хотел две странички для SAMBA и NFS, а сделал полноценную панель управления NAS на 20+ страницах

Ушел TeamViewer, Veeam не купить, Jira SM превратилась в тыкву. Собрали актуальный стек российского сисадмина в 2026: шесть категорий, только то что реально работает в проде. Внутри — таблица импортозамещения, честные минусы каждого продукта и чек-лист выживания инфраструктуры.

У меня телевизор, который читает файлы с USB-флешки. Флешка отформатирована в FAT32, а значит — максимум 4 ГБ на файл. Типичный вечер выглядит так:

Linux-приложение для тех, кто смотрит фильмы с USB-флешки. Поиск торрентов по Rutor, NoNaMe-Club и RuTracker, скачивание через libtorrent и автоматическое копирование на флешку с умным разбиением MKV-файлов под FAT32. Один бинарник, PyQt5, open source.

Обычный uptime-мониторинг проверяет, отвечает ли сервис на запросы. Cron-job ничего не отвечает — он запускается раз в N часов, делает работу и молча завершается. Если cron перестал запускаться (uptime daemon упал, машина в read-only mode после fsck, disk full) — обычный мониторинг этого не видит.

Решение известно с 70-х — паттерн dead-man-switch (он же heartbeat). Я недавно делал heartbeat-эндпоинты для Valpero. Здесь разберу серверную часть на FastAPI + клиентский bash-pattern, и edge-кейсы которые их ломают.

В конце готовый код, который можно адаптировать под свой стек.

ИТ-менеджер открывает новую ITAM-систему, а вокруг — выгрузка из 1С, Excel от закупок, таблица склада и файл «ноутбуки_финал_точно_последний.xlsx». Рассказываем, как за 90 дней пройти путь от цифровой свалки до учёта, которому можно доверять. Внутри — два чеклиста, RACI-таблица и пошаговый маршрут.

El Capitan, Frontier, Aurora, JUPITER Booster — четыре нынешние эксафлопсные системы из рейтинга Top500, первые строчки суперкомпьютерной табели о рангах. Все четыре используют GPU-ускорение. Это архитектурный консенсус, который формировался около десяти лет и к 2024 году стал самоочевидным: хочешь эксамасштаб — используй GPU.

На этом фоне Китай объявляет о суперкомпьютере исключительно на CPU, без единого ускорителя. Это либо достаточно нетривиальное архитектурное решение, либо красивая история про независимость и импортозамещение. Скорее всего, оба варианта одновременно. Но чтобы это понять, нужно посмотреть назад и выяснить, как GPU вообще оказался на вершине суперкомпьютинга и почему это происходило не один год. Да и вообще неплохо бы разобраться, как GPU добрался до вершины суперкомпьютинга, что в этом противостоянии осталось от CPU и почему именно Китай решил поставить на него.

Привет, Хабр! Меня зовут Витя, я проектирую интерфейсы в Selectel. Недавно рассказывал о выделенных ядрах — новой функциональности в облачных серверах, направленной на повышение производительности и стабильную работу вашей инфраструктуры. А сегодня хочу рассказать о новой линейке 10G Net, которую мы также совсем недавно запустили.

Как можно догадаться из названия линейки, ее ключевая особенность — это ширина канала приватной сети в 10 Гбит/с, которая дополняет предложение современных высокочастотных процессоров и памяти. Такой сетап позволяет быстро обрабатывать данные и передавать их между облачными серверами.

Пару недель назад или чуть больше попалась тут статья про то, как вернуть к работе старый компьютер.
Но то ли стиль изложения народу не понравился, то ли еще что - в общем, статью сняли с публикации, а автор явно обиделся. Я думал, он доработает и напишет еще - но что-то не написал.
А зря: были предложены вполне годные вещи, которые я попробовал, и увидел, что это хорошо весьма. Что ж, напишу сам, вдруг кому тоже пригодится.

Почему меня эта тема вообще заинтересовала: у меня, как уже писал раньше, сейчас такой весьма спартанский рабочий компьютер: перепрошитый под Debian TV-box, процессор ARM, питание всего 5 вольт от USB-зарядки.
Начиналось как прикольный эксперимент - а потом понравилось: не гудит, не шумит, электричества не жрёт, места почти не занимает, вопреки ожиданиям работает вполне неплохо.
Единственный минус - памяти всего 4 гигабайта, и увеличить ее физически нельзя.

Причем, для работы-то вполне достаточно, а вот браузер, зараза такая, любит покушать, точнее пожрать.
Не сам браузер - а некоторые сайты, чуть более чем полностью набитые всякими свистелками и анимацией (лучи радости создателям модных современных сайтов с многопоточными скриптами и HD-иконками, типа "img1920х1025.jpg style='width:100px'").
Соответственно, если запущены рабочие программы, и тут повезет открыть такой сайт - начинаются тормозааа, главное успеть его закрыть, пока всю память не выжрал.

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

Политики QoS — это основа для управления веб-трафиком и реализации качественного соединения (особенно на инфраструктуре операторов связи). Мы в VAS Experts предлагаем решение PCEF, которое отвечает за применение политик качества обслуживания и контроль сетевого поведения. Однако сама область QoS активно развивается: регулярно появляются улучшенные алгоритмы и подходы к управлению трафиком, так что системным и сетевым администраторам важно держать руку на пульсе. В этом материале разберем несколько свежих и необычных реализаций — от LLM-систем, позволяющих настраивать сеть текстовыми запросами, до алгоритма, основанного на поведении китов во время охоты.

Как безопасно опубликовать домашний сервер без белого IP и проброса портов: домашний сервер сам устанавливает исходящее SSH-соединение к VPS, на VPS создаётся локальный endpoint обратного SSH-туннеля, а внешний доступ к сервисам отдаётся через Caddy по HTTPS. Backend-порты вроде Nextcloud, Home Assistant или Jellyfin не открываются напрямую в интернет, а остаются доступными только через loopback и reverse proxy. Отдельное внимание уделено hardening: ограниченный пользователь tunneluser, SSH-ключи, autossh, systemd, UFW, проверка sshd_config и диагностика типовых ошибок.