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

Я не программист и не инженер. Я предприниматель, который собирает нейросетевые автоматизации для бизнеса. За полтора года такой работы я заменил нейросетью несколько отделов: где-то из семи человек оставался один, где-то двое.

В интернетах все чаще слышу мнение, что «ИИ скоро заменит всех», но я убедился, что это не так. С рутиной нейросеть и правда справляется блестяще, а на чём-то очень простом и человеческом ломается.

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

В начале июля разработчик Ноа Кейгл выпустил Hannah Montana Linux v26.0 — современный ремастер того самого розового дистрибутива-мема из 2008 года. Тут можно улыбнуться, поностальгировать и решить, что вся новость закончена, но давайте не будем спешить. За этой несерьезной обложкой прячется на редкость наглядный пример того, что такое дистрибутив Linux на самом деле. А заодно становится понятно, почему нельзя просто оставить старую версию и жить дальше. Тут надо разобраться во всем по порядку и ответить на некоторые вопросы. Этим и займемся.

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

Спор вокруг Unix и его возможного следа в Linux уже пережил банкротства, смену владельцев, несколько переименований компаний и даже смерть одного из главных участников. В последние годы могло показаться, что он утих, но нет. В июне 2026 года в Апелляционном суде второго округа США прошли слушания по делу Xinuos против IBM. Компания, которая когда-то купила остатки бизнеса SCO, пытается доказать, что у нее есть основания требовать компенсации. И хотя перспективы выглядят скромно, сам факт возвращения спора показывает, насколько запутанной оказалась история прав на одну из важнейших операционных систем прошлого.

В первой части мы собирали свой собственный минимально необходимый образ системы с рабочим столом Mate и остановились на собраном архиве mate-rootfs.sqfs.

Во второй части мы сделаем установку образа на основной диск, произведём разметку диска, и сделаем загрузку нашего ядра Linux без посредников в виде grub, systemd-boot

Привет, Хабр! В прошлых статьях мы уже обсуждали эволюцию подходов к мониторингу — от ручного анализа данных до использования MCP-серверов для взаимодействия с LLM  и сравнивали философию open-source стека (Prometheus + Grafana) с готовыми APM-платформами . Сегодня я хочу применить этот опыт к специфичной, но крайне важной области — мониторингу систем на платформе «1С:Предприятие».

Задача мониторинга 1С-ландшафта традиционно считалась нетривиальной. Причин несколько: это и закрытость платформы, и специфические источники данных, и сложность интерпретации происходящего для бизнеса. Однако за последние годы инструментарий сильно шагнул вперед. Давайте разберем, какие вообще существуют способы заглянуть под капот работающей 1С — от классических штатных средств до современных решений, строящих единую картину наблюдаемости.

Мировой кризис взвинтил цены на память и комплектующие. В такой ситуации лучшая стратегия — рационально относиться к старому железу. Например, у Meta* в новых DDR5-серверах работает старая память DDR4 через кастомную ASIC-микросхему Vistara без потери производительности. То есть ребята разработали собственный чип, карту-переходник для CXL и драйверы для ядра Linux — лишь бы использовать старую память.

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

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

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

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

Когда инфраструктура начинает сбоить, причина редко остаётся в одном слое: за проблемой с деплоем тянутся пайплайны, контейнеры и секреты, а за деградацией сервиса – логи, сеть, база данных или настройки Linux. В этом дайджесте собрали практические материалы по K8s, CI/CD, DevSecOps, наблюдаемости, PostgreSQL и отказоустойчивости – для тех, кто хочет быстрее находить слабые места и лучше понимать, как связаны компоненты современной инфраструктуры.

ИТ‑департаменты и интеграторы часто сталкиваются с дилеммой: закупить партию дешёвых потребительских «коробочек» для склада, цеха или digital signage либо инвестировать в специализированные решения. В этом обзоре мы критически разберём актуальное портфолио промышленных ПК на примере линейки MSI Industrial — от ультракомпактных «кирпичей» до локальных ИИ‑суперкомпьютеров — и посмотрим, как обстоят дела с их поставками в Россию.

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

Docker — отличный инструмент, но «отличный» не значит «единственный» и тем более не значит, что он подходит для любой задачи. На одиночном сервере с одним-двумя приложениями Docker может принести больше проблем, чем пользы. Демон, образы, слои, сети и тома упрощают упаковку и запуск приложений, но на одиночке или небольшом VDS они избыточны. Под катом о том, в каких случаях Docker не нужОн, чем его заменить и как. 

Полгода назад я пришёл в новую организацию, и мне достался парк машин. Десяток на Windows, несколько маков, пачка линуксовых ноутов у разработчиков. Невыносимым было другое. Навешанные до меня политики и блокировки со стороны ИБ связывали руки так, что здраво администрировать домен было попросту нельзя: любое рутинное действие упиралось в чужие ограничения. Тогда я и полез искать решение, которое помогло бы мне нормально админить этот парк.

Готового, что легло бы на мою ситуацию, я так и не нашёл — и в итоге сел писать своё. Ниже — не анонс, а разбор инженерных решений, которые по дороге пришлось принять, и честная карта того, где у этой конструкции проходит настоящая граница безопасности. Последнее для меня важнее всей остальной механики: MDM по определению даёт слишком много власти над чужими машинами, и делать вид, что это не так, было бы нечестно. Поэтому архитектуру ниже я разбираю не как список возможностей, а как ответ на вопрос «где это ломается».

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

До этого я сравнивал интересные мне хостинги примерно раз в год — не видел смысла делать это чаще. После недавнего сравнения российских VPS/VDS-хостингов прошло не так много времени, но появился повод вновь вернуться к этой теме. А именно, в комментариях вполне ожидаемо спросили «а где остальные крупные игроки?», да и в личку написало несколько представителей компаний с предложением протестировать их услуги. Поэтому пока старые цифры не остыли, по просьбам трудящихся решил добавить к результатам тестов ещё несколько компаний, которые мне показались интересными. 

Под катом — результаты тестирования уже 9 серверов от следующих компаний: трёх новых (FirstVDS, AdminVPS, Рег.ру) и 6 старых (Timeweb, RUVDS, CLO, AEZA, VDSina и Selectel). Теперь, когда результатов стало больше, можно не только посмотреть на новичков, но и оценить, насколько они меняют в целом общую картинку.

Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11.

Рассмотрим нестандартный вариант установки Kubernetes, а именно установка кластера без control-plane ноды как таковой в стандартном ее восприятии. Установим кластер Kubernetes где слой control-plane будет просто хостом без CRI, только базове systemd сервисы. "Спрячем" control-plane от лишних глаз.

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

Мы прошли этот путь и набили шишки. До внедрения проектного офиса (ПО) ситуация была следующей.

Есть паттерн, который я вижу почти в каждом кластере, куда прихожу: liveness-проба, скопированная из туториала, которая годами тихо делает продакшен хуже. Не «не помогает» — именно делает хуже: превращает локальные замедления в каскадные рестарты и красивые инциденты на ровном месте.

Тезис статьи простой: liveness-проба — это не «проверка здоровья». Это заявление «если этот запрос не ответил — процесс нужно убить». И в большинстве конфигураций, которые я встречал, это заявление ложно.

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

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