В сетевых метриках VDS/VPS легко запутаться, потому что каких их только нет. В статье разберу ключевые, расскажу, как их читать, и посоветую 10 лучших утилит для мониторинга сети.
Часто в учебной литературе по Linux приведены скучные и неинтересные примеры написания модулей ядра. Я решил исправить этот пробел и показать, что разработка небольшого модуля — это задача под силу многим, если понимаешь базовые принципы разработки программ.
Как я сделал приложение для обхода Discord и YouTube на macOS (и Windows тоже)
TL;DR: Написал open-source десктопное приложение UnblockPro на Electron, которое в один клик обходит DPI-блокировки Discord, YouTube и других сервисов. Работает на macOS и Windows. Без VPN, без серверов, без абонентки. Код на GitHub — by-sonic/unblock-pro.
Зачем вообще это было нужно
С осени 2024 года ситуация с доступом к Discord и YouTube в России стала, мягко говоря, непростой. VPN — вариант, но:
Платные сервисы стоят денег и сливают скорость
Бесплатные — сливают данные
Не все работают стабильно
Настраивать VPN для каждого устройства — боль
История пока не окончилась и полноценный доступ к инфраструктуре я не вернул. В этой статье я на своем примере покажу, к каким катастрофическим последствиям может привести одна ошибка — использование одного домена для всей инфраструктуры. Моя история - это предупреждение для рядовых айтишников. Не претендую на качественную техническую статью, поэтому буду писать её простым слогом.
Если мониторинг показывает, что ЦП большую часть времени в простое, а оперативка не выбивается из нормальных значений, значит, узкие места нужно искать в других подсистемах. В статье расскажу про основные причины заторможенности Linux-сервера и как проверить, есть ли они у вас.
Привет, Хабр! Меня зовут Рома Корчагин, я занимаюсь внедрением процессов безопасной разработки в продукте «Штурвал» от «Лаборатории Числитель». Наша платформа позволяет создавать сотни кластеров и управлять ими силами небольшой команды.
Считается, что практики DevOps действительно ускоряют разработку, но классические методы безопасности за этим прогрессом не успевают. В этой статье я расскажу, можно ли автоматизировать внедрение Sec в DevOps и при этом снизить нагрузку на разработчиков. Разберём четыре основных подхода — и отдельно поговорим про Shift-Down Security, который, на мой взгляд, отлично закрывает недочёты остальных.
Мы немного в когнитивном диссонансе, потому что история дикая и сделать правильно в ней явно будет неправильно. Сейчас объясню, но сначала хронология обращений в поддержку VDS-хостинга.
В один прекрасный день в техподдержку прилетает тикет. Пишет человек, что его почта была взломана и он утерял доступ к своему аккаунту. Пишет с личной почты с публичного сервиса типа @mail.ru.
Аккаунт зарегистрирован на почту внутри домена, домен и сервер, соответственно, скомпрометированы, по всей видимости. Просит восстановить доступ к серверу и перевязать всё на его личный ящик.
Мы, естественно, на слово не верим. Запросили дополнительные документы: паспорт и всё возможное, связанное с аккаунтом. Он присылает скан паспорта. ФИО в паспорте совпадает с данными в профиле аккаунта. Во-вторых, самое главное — банковские чеки и квитанции об оплате этого самого сервера за последние месяцы. Мы смотрим: документы в порядке, деньги платил именно он. Ситуация штатная: человек — назовём его первым человеком-пауком — потерял почту, подтвердил личность, подтвердил оплаты. Мы переносим аккаунт на его личную почту и отдаём доступ.
И тут с почты внутри домена приходит такой же тикет, только на другое имя. Мол, утерял доступ, верните.
…Был обычный ноябрьский вечер, 2024 год шёл к своему завершению: на носу была «чёрная пятница». Я вернулся домой в Новосибирск из почти двухнедельной командировки, пробыв в пути 12 часов и поспав часа четыре. В 19:07 алерт сообщил мне о падении одного из контроллеров. В целом, проблема не критичная, так как сервисы зарезервированы. Но всё же одним глазом я заглянул в чат с разбором.
Через час ситуация стремительно ухудшилась: каскадом начали отказывать узлы, отвечающие за внешнюю связность. А затем развитие событий приняло фатальный оборот — в какой‑то момент одновременно отказали сервисы внешней связности сразу в двух зонах доступности…
Это был один из самых крупных региональных инцидентов в облаке, после которого мы многое изменили в сети, чтобы сделать её устойчивее. С того момента прошло больше года, так что пришла пора рассказать эту историю от начала и до конца.
В прошлой статье я уже показал наши основные подходы к повышению отказоустойчивости в этой ситуации. Однако за кадром остался сам процесс разработки новых решений и то, как мы мыслили, чтобы найти наилучший выход. Сегодня расскажу об этом подробнее. Статья основана на моём недавнем выступлении на Highload++ и дополнена по следам дальнейших расследований инцидентов.
Когда проект вырастает из простых задач, каждый повторный запрос к базе данных превращается в бесполезную нагрузку на диски и процессор. И вместо того чтобы заставлять систему раз за разом искать, фильтровать и считывать одни и те же данные, логичнее отдавать их напрямую из оперативной памяти.
В этой статье разберем, как эффективно внедрить слой кэширования на связке Redis + Spring Boot 3 / Java 21.
Пробежимся по базовым командам Redis, реализуем cache‑aside вручную и через аннотации Spring Cache, а затем разберем два полезных паттерна для микросервисов: Fixed‑Window Rate Limiter и распределенный лок. Не пугайтесь сложных терминов, все понятным языком рассказал под катом.
Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов.
Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес.
Один из элементов «мозаики» такой геораспределенной системы — балансировщик нагрузки с возможностью использования адресов из anycast-подсети, которую выделяет поставщик услуг. В этой статье мы не будем затрагивать вопрос передачи данных и их консистентность на двух разных площадках — разберем только сетевую составляющую. Подробности под катом!
Тезис: следует создать такой дистрибутив Linux, который по умолчанию выполняет двоичные файлы Windows через Wine.
Если я найду файл в формате .exe, которому 20 лет, я по-прежнему смогу запустить его на современной Windows. Попробуйте проделать подобное с двоичным файлом Linux, которому всего год. Совершенно не гарантированно, что он запустится, в зависимости от того, какие обновления успели произойти. Также не гарантируется, что заработает даже сегодняшний двоичный файл Linux, если собрать его в одном дистрибутиве, а попытаться запустить на разных других дистрибутивах. Возникает ровно такая же проблема, связанная с версиями установленных библиотек.
Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.
Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.
Portainer — удобный интерфейс управления контейнерами (Docker/Kubernetes) из браузера, но почему-то о нём ещё не все знают. В статье расскажу, что это такое, зачем он вообще нужен и как установить.
Однажды передо мной встала задача: на произвольном роутере локальной сети выделить интернет-трафик пользователей и перенаправить его по другому маршруту, не трогая при этом локальный трафик.
В принципе банальщина, решить которую можно множеством способов. Например, для локального трафика задать статические маршруты, а шлюзом по умолчанию сделать роутер, куда нужно перенаправить трафик. Схема рабочая, но трудоёмкая. Ведь для каждого роутера придётся вручную корректировать таблицы маршрутизации.
Хотелось сделать универсальный скрипт, с помощью которого можно было бы легко и быстро управлять трафиком. Идея в том, что можно задавать статические маршруты не для локального трафика, а для внешнего, и при этом не трогать шлюз по умолчанию. Дело осталось за малым — получить перечень всех внешних IP-подсетей, чтобы на их основе строить маршруты.
Ну и как в жизни бывает, автоматизация работы привела к гораздо большим трудозатратам, нежели явная работа руками. Проблема оказалась там, где не ждали — готового перечня внешних IP-подсетей найти не удалось. А раз нет, значит придется делать самому.
Как думаете, что будет, если взять шесть одинаковых ноутбуков и поставить на них все версии Windows, которые выходили за последние 25 лет? Какая окажется быстрее? Логика подсказывает, что новая должна обойти старую. Все-таки тут и оптимизация лучше, и код новее, и алгоритмы эффективнее. Но реальность оказалась куда более прозаичной: двадцатипятилетняя XP, которая сегодня работает в основном на банкоматах, обошла Windows 11 по большинству показателей. Звучит как какой-то абсурд, но факты — штука упрямая.
Каждый, кто проводит в терминале больше пяти минут, сталкивается с одним и тем же: одни и те же длинные команды приходится набирать снова и снова, а рутинные действия отнимают время и внимание. Сначала терпишь, потом — начинаешь оптимизировать.
Простейший алиас в .bashrc или .zshrc кажется небольшим открытием. Первый рабочий скрипт, сохранённый в ~/.local/bin, ощущается как прорыв. Это не просто про лень — это про эффективность, про оптимизацию работы.
Со временем такая «мелкая оптимизация» собирается в целый личный фреймворк или набор утилит для командной строки. Это уже не пара заплаток, а твоя собственная среда, отточенная под конкретные задачи. В этой статье я хочу показать свою коллекцию таких скриптов и алиасов — не как идеальный стандарт, а как пример живого подхода. Возможно, какие-то решения окажутся полезными и вам, а главное — побудят создать что-то своё, ещё более удобное.
Недавно, перебирая хлам скопившийся на пыльных антресолях, я обнаружил старенький MacBook 2,1 (A1181) образца 2008 года выпуска. Этот MacBook мне на день рождения, который состоялся более 15-ти лет назад, подарила супруга. Большим ценителем яблочной продукции я так и не стал, но некоторое время использовал эту машинку в качестве второй — для чтения почты или просмотра ютуба, брал с собой в туристические поездки. Мне нравился дизайн корпуса и клавиатуры этой машинки, местами даже где-то меня привлекала операционная система MacOS X являющаяся родственником FreeBSD. Но сейчас не об этом. В те времена вычислительная техника персонального применения стремительно устаревала — появлялись процессоры с всё большим числом ядер и большей тактовой частотой, состоялся полный переход от 32-битных архитектур к 64-х битным и т. д. Всё это сильно расслабило разработчиков и, как следствие, требования софта к железу выросли просто непомерно. Таким образом, данная машинка очень быстро «морально устарела». Я пару раз проводил апгрейд — сначала добавил немного SDRAM, потом заменил HDD на SSD, несколько раз апгрейдил MacOS X. Но к 2012 году машинка всё равно стала мало пригодной для работы и отправилась на антресоли.
Две недели назад этот MacBook попался мне на глаза. Я включил его и обнаружил, что MacOS X прекрасно загружается и даже подключается к WiFi, только вот в Safari все сертификаты давно протухли и ни один Web сайт не открывается. Но тут меня посетила совершенно здравая мысль - почему бы не оживить эту машинку установкой на неё современной ОС, такой как например FreeBSD ? К тому же появился повод — одна из моих дочерей доросла до своего компьютера, а покупать ей сейчас новый ноут для посещение «учи.ру» меня, откровенно говоря, «жаба душит». Короче, я быстренько заказал новую АКБ на известном китайском маркетплейсе и принялся изучать вопрос «как пропатчить KDE MacBook для FreeBSD».
В данной статье я расскажу о некоторых особенностях яблочных ноутбуков мало знакомых даже опытным маководам, о тонкостях установки FreeBSD, о проблеме под названием UEFI, о баге в ядре ОС FreeBSD с которым я столкнулся и помог зафиксить, о прекращении поддержки DRM-KMOD драйверов в 32-х битной ветке ОС FreeBSD и о том, как мне все же удалось портировать их для FreeBSD 14.3-RELEASE/i386. И еще о некоторых мелочах, знание о которых необходимы для того, чтобы сделать ОС FreeBSD пригодной для эксплуатации на этом стареньком MacBook-е, и чтобы Ваш кислотно-щелочной баланс всегда оставался в полном порядкеTM.
У каждого системного администратора должен быть набор программных решений для практически любой ситуации — некая серверная аптечка первой помощи. В статье собрал базовый минимум ПО для «лечения» основных болезней серверов на Linux и Windows.
15 января 2026 г. — Let’s Encrypt официально объявил о широкой доступности короткоживущих (short-lived) сертификатов с временем жизни около 160 часов (чуть более шести дней) и сертификатов, работающих с IP-адресами вместо доменных имен.
Есть все признаки того, что 2026 год наконец-то станет годом десктопного Linux.
Под катом — разбор причин этого сдвига и обзор перспективных дистрибутивов для игр, максимальной производительности и экспериментов с современным Linux.