Системное администрирование *

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

Второе. Некоторым может показаться, что в статье много негатива. Я не испытываю неприязни или ненависти к каким-то конкретным людям. Не потому, что я добрый. А потому, что я рассматриваю их как явление. Как некоторую стихию, которую невозможно победить и перевоспитать. И моё несогласие с законами физики никак не избавит меня от последствий, если я вдруг решу выпрыгнуть в окно. Со стихией бороться бесполезно, такие люди были, есть и будут всегда и везде. Можете назвать это не явлением, можете назвать это типажом. Очевидно также, что конкретный человек может включать в себе несколько типажей и менять их с течением лет под воздействием внешних обстоятельств. И сам я не исключение.

Третье. Разбирать ситуации я буду на примере системного администрирования. Но вы можете подставлять свои должности и технологии, суть не поменяется.

Четвёртое. Многим кажется, что я то встаю на сторону руководителей, то на сторону простых сотрудников. Прочитав эту статью до конца вы поймёте, на чьей я стороне.

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

Многим из нас не раз приходилось настраивать интеграцию того и сего c Active Directory по LDAP, и в этот момент начинается судорожный поиск в гугле, как же делалась эта конкретная штука, было же что-то такое. Пусть обобщённая информация останется здесь.

В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.

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

Это история о том, как желание просто проверить, жив ли мой блог, привело к трём дням танцев с бубном вокруг SSL-сертификата, а затем — к созданию собственного сервиса мониторинга, который теперь используют сотни разработчиков. Расскажу, почему существующие решения перестали устраивать, как мы реализовали поддержку UDP и ICMP в облаке и почему мониторинг должен быть «скучным».

5 лет назад мы пытались внедрить видеодетекцию движения для промышленного освещения. Программист не справился, проект лёг в ящик. В январе 2026-го я собрал работающий MVP за 40 минут с помощью Claude Code — без единого программиста нужного стека в команде

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

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

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

В физическом мире USB-порт — дыра в периметре. Воткнул флешку — и у тебя либо данные утекли, либо малварь приехала, либо оба сценария одновременно. Stuxnet, обнаруженный в 2010-м (но активный с ~2007), пробил air gap завода в Натанзе — первоначально через завербованного агента, а дальше распространялся через USB-накопители. FIN7 в 2021-22 годах рассылали по почте подарочные коробки (от имени Amazon и HHS) с «флешками» — на деле это были Arduino ATMEGA32U4, эмулирующие клавиатуру и набивающие PowerShell-команды быстрее любого оператора. Конечная цель — Cobalt Strike, затем ransomware (BlackMatter, REvil). BadUSB, продемонстрированный на Black Hat 2014, показал, что любое USB-устройство может прикинуться клавиатурой и вводить команды — и VID/PID фильтрация тут не спасёт, потому что идентификаторы прошиты в firmware и перешиваются за минуту.

VDI в теории решает часть проблем: данные живут на сервере, а не на эндпоинте. Но USB-редиректор эту изоляцию пробивает — если разрешить проброс mass storage, пользователь утащит файлы на флешку ровно так же, как с физического ПК. А если не разрешить — придут люди со смарт-картами и принтерами, и скажут «нам нужно работать».

Вот тут начинается инженерный компромисс, который не решается одним галочкой в политике.

Три предыдущие статьи были про картинку. Картинка — вещь терпимая: можно сжать, можно потерять кадр, можно догнать следующим. Человеческий глаз прощает многое.

Со звуком всё иначе.

150 миллисекунд задержки — и собеседник начинает перебивать. 200 — и вы оба замолкаете, ждёте, потом говорите одновременно. 300 — созвон превращается в пытку. Это не абстрактные цифры из RFC, это реальность, которую каждый испытывал на плохом Zoom-звонке. (Кстати, порог в 150 мс — это ITU-T G.114, одна из самых цитируемых рекомендаций в телеком-индустрии. Не потому что магическое число, а потому что дальше начинаются перебивания.)

А теперь представьте: вы построили VDI, развернули 500 рабочих мест, люди довольны. И тут приходит запрос от call-центра: «Мы хотим работать через VDI тоже». Или от отдела продаж: «Нам нужен софтфон в виртуалке».

Вот тут начинается отдельная история.

Недавно наткнулся на статью про Echovault на Хабре — инструмент для памяти AI-агентов, написанный на Python. Автор описывал ровно ту же боль, что и я испытывал месяцами. Идея хорошая, реализация — рабочая. Но Python. Я ничего не имею против языка, просто не мой выбор для инструментов, которыми пользуюсь каждый день. Люблю скомпилированные бинарники: кинул файл — и работает, без virtualenv, без pip, без «а какая у тебя версия питона». Поэтому я взял идею и переписал её с нуля на Go. Получился Pantry.

Расскажу, зачем это вообще нужно и что внутри.

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

Мы все привыкли к классическому раскладу: для поддержки есть сервис деск, в проектных командах — Jira, у ИБ — свои системы. При этом одни и те же сотрудники могут решать заявки, участвовать в проектах и устранять инциденты — сами или совместно с безопасниками. 

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

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

Привет, меня зовут Станислав Пьянов, я DevOps-техлид в KTS.

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

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

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

В статье разбираю, как собрать отказоустойчивую виртуализацию на базе Astra Linux:
DRBD + GFS2 + Pacemaker против Ceph.

Многогранный мониторинг Angie - продолжение истории

 Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром. Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

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

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

Десять лет в девопсе. Десять. И я гуглю tar -xzf. Не раз в год — раз в неделю. Ну, может раз в десять дней, если повезёт. Открываю хром, набираю «tar extract gz linux», пролистываю три рекламы, нахожу ответ на SO, копирую, вставляю, закрываю вкладку. Через неделю — по новой.

Я не идиот. Точнее, может и идиот, но не поэтому. Просто tar — это такой синтаксис, который у меня физически отказывается залезать в долговременную память. Там дефис или нет? xzf или xfz? Или zxf? Вроде порядок не важен? Или важен?..

Короче. Месяц назад я написал скрипт, который это решил. А потом скрипт решил больше, чем я хотел.

Многие уже видели старенькую схему Брендана Грегга, где каждой подсистеме сопоставлены CLI-утилиты. Она правда полезная, но когда «горит», мы бежим в интернет, а не выискиваем систему и команду. В статье я собрал тулзы с картинки, а также добавил опенсорсных утилит, которые пригодятся для мониторинга. 

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

Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен». В этой статье хочу разобрать, откуда берутся такие «невидимые» перерасходы и почему без прозрачного учета ИТ-активов они могут годами оставаться незамеченными. 

Прим: Дополняет мою статью "Скрипт полной миграции из GitLab на свой сервер".

После успешной миграции

А что делать со старым репозиторием?
Было бы логично использовать GitLab и другие хостинги в качестве вторичных (запасных).

Но как это делать? И еще не вручную?
Для синхронизации с remotes одновременно на свой Gogs и на все GitLab, GitHub, Bitbucket, ... remotes, об этом и других "хаках" ниже:

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