DevOps *

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

Привет, Хабр! Меня зовут Максим Князев, старший системный инженер К2 Кибербезопасность. Сегодня я хочу поговорить об атаках на цепочки поставок на примере того, что все хорошо понимают и любят.

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

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

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

10 лет назад OpenVPN считался надёжным инструментом. Сегодня он блокируется за секунды. За это время сменилось пять поколений протоколов — каждый новый рождался как ответ на то, чему научился цензор. Это история гонки вооружений между математикой и политикой. И она ещё не закончена.

И где мы сейчас ?

🚀 Nginx на автопилоте: Как я перестал тратить время на конфиги и SSL

Бывает так: у тебя есть крутая идея для проекта, ты быстро кодишь бэкенд, но когда де��о доходит до деплоя... Вечер превращается в бесконечную настройку Nginx, борьбу с Certbot, прописывание HSTS-заголовков и попытки вспомнить, как там правильно настраивается кеширование.

Знакомо? Мне — да. Именно поэтому я собрал nginx-template — инструмент, который превращает администрирование сервера в удовольствие. 🛠

Это не просто набор файлов, это полноценный пульт управления вашим сервером через один скрипт — manage.sh.

Почему вам стоит это попробовать:

🔹 Скорость деплоя: Добавление нового домена с автоматической выдачей Let's Encrypt занимает ровно одну команду. Без правок конфигов руками и перезагрузок.

🔹 Image Proxy из коробки: Хотите ресайзить аватарки на лету прямо через Nginx? Теперь это делается одной командой без сторонних микросервисов.

🔹 Умный CDN: Поднимайте кеширующие узлы для статики за секунды. Разгружайте основной сервер и радуйте пользователей мгновенной загрузкой.

🔹 Профессиональная безопасность: Конфиги уже оптимизированы под требования SSL Labs (рейтинг A+), включают защиту от эксплойтов и автообновление IP Cloudflare.

Никаких тяжелых интерфейсов и лишних абстракций. Только чистый, производительный Nginx в Docker и удобная автоматизация на Bash. Вы сохраняете полный контроль над каждым байтом конфига, но избавляетесь от всей рутины.

Пора тратить время на код, а не на настройку прокси. ⚡

🔗 Забирайте готовый стек здесь: github.com/Arlandaren/nginx-template

Понравился подход? Ставьте ⭐ на GitHub — это лучший способ сказать «спасибо» и поддержать развитие Open Source!

Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.

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

В статье расскажу, как «на коленке» собрали многомодульную систему.

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

Этот бинарник — sudo.

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

Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

Монолит без тестов.
Деплой только ночью.
Пять минут гарантированного простоя на каждом релизе.
Логи — в файле.
О проблемах узнаём от клиента.

Малый/средний бизнес МФО, без отдельного DevOps-инженера.
“Специально обученный тимлид”, который знает, какие костыли подпирают систему.

Рассказываю, как из этого получился production baseline: Kubernetes, GitLab CI/CD и наблюдаемость, после которых релизы стали скучными.

На связи — Катя Лысенко и третья часть статьи о системе онбординга. В первых двух (ч.1 и ч.2) мы разобрали основы: как подготовить почву, выстроить маршрут и создать понятный трек для новичка. Но структура — это только половина системы. Вторая половина — то, что делает её живой: регулярная рефлексия, честный разговор и поддерживающая среда, где человек не боится расти и пробовать.

Привет, Хабр! (И тебе, страдалец, который три недели смотрит на мёртвого бота в Битриксе. И тебе, админ, который уже устал объяснять руководству, почему «оно перестало работать». И тебе, безопасник, который узнал, что данные компании летают через какой-то curator.pro и чуть не уронил кружку.)

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

Спойлер: стало хуже. Но мы справились.

Встроенный WebSearch в Claude Code стоит $0.01 за запрос и регулярно падает с «Rate limit reached» — даже на подписке за $200/мес. Я поднял локальный SearXNG, подключил через MCP — и теперь поиск бесплатный, без лимитов, а запросы не уходят на серверы Anthropic. Установка — 10 минут, три файла конфигурации.

Седьмая статья цикла о построении CDC-пайплайна с нуля. Инфраструктура работает, данные текут из PostgreSQL через Kafka в HDFS. Займемся те, что никто не любит(по крайнее мере у нас на работе). Сегодня поднимаем мониторинг и настраиваем алерты в Telegram.

Хостинговые компании России устранили старые проблемы. Большинство хостингов стабильно держат соединения с крупными интернет-провайдерами (BGP-сессии с аплинками) и правильно объявляют свои IP-адреса в глобальной сети (route-объекты). Клиенты получают сервис высокого уровня без лагов.

Однако все эти достижения могут в один момент разлететься на кусочки.

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

В качестве одного из возможных инструментов для поиска может применяться утилита grep. Grep (сокращение от global/regular expression/print) является одним из самых мощных и часто используемых инструментов в арсенале системного администратора и разработчика. На первый взгляд, её задача проста — найти строки в тексте, соответствующие шаблону. Например, вхождение какого-либо слова в текстовом файле Однако истинная мощь grep раскрывается при использовании регулярных выражений (regex).

В этой статье мы разберём три основных типа регулярных выражений, используемых в экосистеме grep: Basic (BRE), Extended (ERE) и Perl-compatible (PCRE) и рассмотрим несколько практических примеров.

В этой статье разбираем важную тему микросервисной архитектуры — «толстые» образы. Приведен пример реальной практики снижения размера с 800 МБ до 120 МБ, почему Uber перешел на distroless и как 7 простых шагов по multi-stage сборке сделают ваш деплой в разы быстрее и безопаснее. Будут схемы слоев и реальные цифры. Под катом — готовый рецепт оптимального образа для продакшна.

AI-агенты пишут код за секунды.
Через месяц этот код начинает ломаться — не из-за багов, а потому что мир вокруг него изменился.

Я столкнулся с этим, когда Express API, сгенерированный Claude, умер через 28 дней.
Перегенерация помогала… ровно до следующего обновления зависимостей.

В итоге я попытался решить не проблему кода, а проблему воспроизводимости AI-решений — и случайно пришёл к идее CI/CD для мира, где код пишет не человек, а модель.

В статье — про «гниение» AI-кода, Execution Plans, проверку смысла вместо проверки файлов и почему в большинстве случаев чинить можно без повторного вызова LLM.

HAProxy часто появляется в инфраструктуре незаметно. Сначала это просто балансировщик: принял трафик, отправил дальше — всё понятно. Потом появляется второй сервис, третий, routing по домену, path, заголовкам, SNI, а заодно canary и временные исключения. И вот конфиг, который когда-то помещался на один экран, превращается в логическую задачу со звёздочкой.

В этот момент почти всегда всплывают ACL. Кто-то использует их осознанно, кто-то — по принципу: нашёл в примере, вроде работает. Рядом с ACL неизбежно стоит mode: tcp или http. Снаружи это выглядит как простая настройка, но на деле — фундаментальное решение, от которого зависит, какие данные HAProxy вообще видит и какие условия способен проверить.

Проблема в том, что HAProxy не делает догадок. Он последователен и выполняет конфигурацию ровно так, как она написана. Отсюда и классика жанра: ACL есть, но backend не выбирается; mode вроде http, но заголовки недоступны; routing работает почти всегда, кроме пятницы.

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

Облако по природе своей устроено так, что деньги из него утекают как песок сквозь пальцы. Не потому что провайдеры жадные или инженеры попались безответственные. Всему виной органический рост: тут один сервис поднял новый кластер, здесь команда не выключила стейджинг после релиза, там забыли про снапшот двухлетней давности. По отдельности каждый из этих факапов – вроде не катастрофа. Но в конце месяца счета неизменно напоминают о том, что думать так — большое заблуждение. В прошлых материалах цикла мы уже разбирали типичные боли тех, кто работает с облаками, и рассматривали, почему счета растут, хотя инфраструктура не меняется. А сегодня поговорим про первый и самый важный методологии FinOps, которая должна решить эти проблемы: Inform.

Практики FinOps в Telegram| Бот

Почему начинать с оптимизации — плохая идея

Первая мысль, которая появляется, когда счет за облако в очередной раз оказывается процентов на 40 выше запланированного, — взять и что-нибудь урезать. Неважно что. Лишь бы сократить расходы. Ну, оно вроде и логично. Режем лишнее – оставляем нужное – сокращаем траты.

Вот только вся проблема в том, что без понимания структуры затрат такая оптимизация — это что угодно, только не она. Потому что так можно запросто угробить десяток-другой человекочасов на тюнинг компонента, который дает 2% от общего счета, и не заметить, что 60% уходит на базы данных, про которые никто не вспоминал с момента основания компании. Или, скажем, прибить сервис, который выглядел как заброшенный, но на самом деле держал чей-то продакшн. И ходи потом доказывай, что не верблюд.

С недавних пор в Kubernetes можно включать swap. Говорят, теперь можно забыть о внезапном вытеснении и убийствах подов. Но так ли это на самом деле, если риски никуда не делись?

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

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

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