Привет, Хабр! Меня зовут Владислав Белогрудов, я работаю в команде разработки и сервисов управления в YADRO. Мой текущий проект — информационная система на Go. 

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

Под катом рассмотрим, что такое слайсы и string (строки) изнутри, как использовать их с sync.Pool для ускорения — без «внутренностей» последнего, но с точки зрения клиента. Расскажу о полезных трюках, приведу значения измерений производительности и познакомлю с альтернативными решениями. 

Как защитить свой VDS сервер: 53 000 попыток взлома за 5 дней

Представьте себе: вы арендовали скромный VDS, чтобы поэкспериментировать. Ничего грандиозного — пара тестовых сайтов, простенький веб-сервер на nginx, пара скриптов в cron для автоматизации рутины, SSH для удалённого доступа. Обычная песочница для разработчика, никому, казалось бы, не интересная. Сервер тихо живёт своей жизнью где-то в облаке, отдаёт странички, выполняет задачи, ждёт ваших команд. Вы даже не подозреваете, что за этой тишиной уже разворачивается настоящая цифровая охота.

За два года работы в технической поддержке облачного хостинга я видел множество взломов, помогал клиентам с восстановлением серверов. Видел всё: от примитивных майнеров до полностью стёртых проектов без бэкапов. Сейчас я работаю инженером технической поддержки в компании CleverData (входит в холдинг LANSOFT).

Однажды, ради чистого любопытства, я решил заглянуть в логи свежеиспечённого VDS, созданного всего пять дней назад...

• блокировать коммуникации botnet и malware с управляющими центрами (C&C);
• снизить нагрузку на кэширующий DNS и канал связи;
• блокировать доступ по списку «запрещенных» сайтов (как для предприятий, так и для провайдеров);
• перенаправлять пользователей на локальные ресурсы.

Недавно на Youtube появилась документалка о Python. Примерно в середине ленты есть драматический эпизод о том, как переход от Python 2 к 3 разделил сообщество (спойлер: в конечном итоге этого не случилось).

Первые версии Python 3 (3.0-3.4) в основном делали упор на стабильность и упрощение перехода пользователей с версии 2.7. В 2015 была выпущена версия 3.5 с новой фичей: ключевыми словами async и await для выполнения корутин.

Миновало десять лет и девять релизов, через считанные недели выпустят финальную версию Python 3.14.

Пока все отвлеклись на фичи разноцветного REPL в 3.14, в release notes появились серьёзные заявления, связанные с конкурентностью и параллелизмом.

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

Чаще всего для проксирования трафика используются два протокола: SOCKS и HTTP. Для их реализации существует множество инструментов, а благодаря спецификациям их легко интегрировать с различными системами. Оба протокола имеют свои плюсы и минусы, поэтому для понимания принципов проксирования мы подробно разберем их работу. Хотя в статье мы местами рассматриваем прокси с точки зрения пентестера, она будет полезна всем, кто хочет разобраться в этой теме.

Разбор самых фундаментальных шаблонов проектирования на языке программирования python: наблюдатель, адаптер, команда, компоновщик, декоратор, фасад, фабрика, итератор, заместитель, одиночка, состояние, шаблонный метод.

В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (chunks), формируют репозиторий.

Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.

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

Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.

Привет! Меня зовут Ваня, я системный администратор в Selectel. Допустим, вы уже «пришли к просветлению» и признали, что ZFS — удобная, функциональная и вообще единственная правильная файловая система. Осталось только понять, как начать ее использовать. Об этом и поговорим под катом!

Будем оптимизировать программы на Go. Выжимать последние наносекунды, чтобы код приближался по скорости к Си или ассемблерному. Цель - скорость, чтобы процессор был загружен на 100% при высокопроизводительные вычислениях.

Работаем с Haproxy, маршрутизация по GeoIP и ограничения, настройка mTLS для защиты сервисов, выгрузка метрик в Prometheus. Настройка панели 3X-UI для работы с Unix Socket и персональный DNS over HTTPS.

Привет, Хабр! В предыдущих частях руководства мы разобрали rsync вдоль и поперек - от базового синтаксиса до продвинутых "трюков" для бэкапов и деплоя. Казалось бы, вот он, идеальный инструмент на все случаи жизни. Но как часто бывает в IT, универсальных решений не существует.

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

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

В тестах A/B мы попытались замедлять выдачу страниц с шагом 100 миллисекунд и обнаружили, что даже очень небольшие задержки приводят к существенному падению доходов. — Грег Линден, Amazon.com

• Операции, которые хорошо выполняются в небольших масштабах, становятся нежизнеспособными с ростом числа пользователей. Обычно это операции O(N) или O(N²). Когда база пользователей мала, всё работает отлично. Продукт спешат вывести на рынок. По мере роста базы возникает всё больше неожиданных патологических ситуаций — и сервис останавливается.
  
• Много отдельных источников неоптимальной работы, «смерть от тысячи порезов».

Почти тридцать лет назад, когда Google только выходил на свою победную тропу, у её основателей почти не было железа.

Компания, сначала известная как Backrub и работающая на кампусе Стэнфорда, держала свой первый экспериментальный сервер в коробе из кубиков Duplo. Сервер вмещал 40 гигабайт данных. Позже удалось перейти на скромную серверную стойку. А в 2025 году весь поиск Google уже невозможно уместить даже в одном дата‑центре — и так давно.

И всё же, если включить смекалку и вложить немало труда, можно собрать нечто почти сравнимое с современным Google — на машине, по размеру близкой к тому самому первому серверу. И даже разместить её… в собственной прачечной.

dumbproxy уже упоминался на Хабре в одной из моих прошлых статей. Это HTTP(S) прокси-сервер, который работает через TLS, напрямую совместим с браузерами и браузерными расширениями, и имеет заметное количество дополнительных функций, расширяющих его границы применимости и облегчающих его использование.

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

Go ценят за предсказуемость и простые решения в стандартной библиотеке, а в сервисах чаще всего упираемся в IP, разбор host:port, CIDR и сериализацию. Сегодня это удобно закрывается стандартным net/netip: компактные value-типы, корректный парсинг адресов и портов, работа с зонами, проверка принадлежности сетям и быстрые операции без лишних аллокаций. В статье рассмотрим этот пакет подробнее.

Команда Go for Devs подготовила перевод статьи о том, как оптимизировать использование памяти в Go-приложениях. Автор делится двадцатью приёмами — от выбора ресивера метода и правильной инициализации slice до кастомного управления памятью и профилирования с pprof. TL;DR: мелкие улучшения складываются в заметный прирост производительности и стабильности.

После начала Специальной Военной Операции многие западные компании объявили о прекращении своей деятельности в России и Белоруссии и некоторые из них стали блокировать пользователям с российскими и белорусскими IP-адресами доступ на свои ресурсы в сети Интернет. Яркими примерами таких блокировок являются сайты: intel.com, dell.com, chatgpt.com, community.cisco.com, mongodb.com, tenable.com, wiki.zimbra.com, releases.hashicorp.com, registry.terraform.io, vagrantcloud.com, solarwinds.com и множество других.

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

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

В этой статье будет рассказано о том, как сконфигурировать роутеры марки Keenetic (возможно и других марок, поддерживающих установку пакетов из репозитория Entware) для развертывания на них программного пакета обеспечивающего расширенное управление маршрутизацией. Будет приведена инструкция как установить на роутер Telegram-бота для быстрого и удобного управления маршрутизацией трафика.

В это статье НЕ БУДЕТ инструкций о том откуда взять работающий VPN и НЕ БУДЕТ инструкций о том как обходить блокировки Роскомнадзора. Обсуждать это в комментариях к статье тоже НЕ НУЖНО.

Моя статья посвящена изучению современных инструментов и технологий и объясняет то как получить доступ к легальным сайтам, доступ к которым изнутри страны не ограничен и которые самостоятельно закрыли доступ для пользователей из России и Белоруссии.

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

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

Если вы не согласны хоть с чем-то из вышеописанного - вам следует немедленно прекратить чтение настоящей статьи.

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

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

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

Лично я познакомился с новым поколением прокси‑серверов из материалов многоуважаемого пользователя MiraclePtr. Например, эта статья послужит отличной иллюстрацией, что такое XTLS и Shadowsocks, о которых пойдет речь ниже.