Go *

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

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

Но если сценарий становится нелинейным (появляются развилки, выбор пользователя ведёт на разные экраны) всё усложняется. С этим E2E-тесты ещё справляются: пишем несколько тестов, каждый под свой путь. Сложнее, но решаемо.

Мы столкнулись с этим при работе с платформой в Услугах Авито: пользователь заполняет форму заявки, переходя между экранами. Логика переходов между экранами зависела от категории услуги, типа экрана и выбранных опций. Сценариев стало попросту слишком много. Пришлось искать другой путь. 

Меня зовут Константин Горностаев, QA в Авито, в этой статье я расскажу о подходе, который позволил нам решить эту задачу и получил название «система фейков».

Баланс между производительностью, читаемостью и поддерживаемостью — ключевая задача при разработке микросервисов на Go. На практике всё сложнее из-за неочевидных факторов: от влияния частоты вызовов GC на время отклика до последствий избыточной вложенности в контрактах API. Если не учесть эти нюансы, даже грамотно спроектированный сервис может просаживаться по RPS (requests per second) — или его может быть сложно обновлять и дорабатывать.

Меня зовут Артём Кущ. Я Go-разработчик в команде VK Видео. В статье поделюсь подходами к оптимизации микросервисов и расскажу, как балансировать между скоростью и простотой.

Добрый день, это моя первая статья на Хабре, прошу не судить.

Я хочу рассказать вам немного о моём исследовании и то как стоит честно относиться к LLM моделям, так как вы скорее всего знаете, что такое LLM модель не будем терять времени на её определение давайте перейдём к сути моей работы: LLM не дают гарантии правильности ответа особенно операций с большим количеством шагов и формальным рассуждением, даже когда ответ правдоподобный или оказывается верный. (Вы же все видели дисклеймер ChatGPT can make mistakes.Check important info)

Начнём с самого начала 4 сентября 2025 года прошло исследование о галлюцинациях в моделях (в котором участвовали инженеры OpenAI), и одно из утверждений было, что даже при наличии безошибочных обучающих данных статистическая целевая функция, минимизируемая в процессе предварительного обучения, приведет к языковой модели, генерирующей ошибки, почему же это так потому, что сама природа LLM моделей вероятностная.

Но так как мы живём в мире где мы внедряем системы LLM повсюду появляется закономерный вопрос как же верифицировать LLM и тут у инженеров есть готовый по их мнению инструментарий, который массово внедряется:

Базовый сценарий: вы пушите образ в Container Registry, и ничего не происходит. Чтобы обновить Serverless Container, нужно идти в консоль и накликивать обновление контейнера. Странно, что такой автоматизации нет «из коробки», но её легко собрать на коленке.

Я прошел этот путь и упаковал всё в готовый репозиторий:

Cloud Function на Go, которая ловит события Registry.

Terraform-конфиг, который разворачивает всю обвязку.

Разбор формата событий YMQ (самая неочевидная часть).

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

Пример паттерна Pub/Sub на Go с подробным описанием кода. Пример подходит для знакомства с паттерном в процессе обучения, собеседования. В статье есть ссылка на полноценную библиотеку, созданную на основе данного примера.

Как в одиночку собрать полноценный сервис мониторинга с проверками из 10 точек мира, алертами в Telegram/Slack и собственным агентом? Делюсь личным опытом выбора стека: почему FastAPI выиграл у Django, как TimescaleDB справляется с миллионами строк логов и зачем писать агент на Go, если основной код на Python. Только практика, архитектурные решения и честный расчет стоимости инфраструктуры в €11/мес.

Меня зовут Сергей, я разработчик в «Финаме». Торгую на бирже около четырех лет. Большую часть дня провожу в терминале - пишу код, деплою, работаю с инструментами. И в какой-то момент заметил нестыковку: все мое рабочее пространство уже в консоли, кроме одной вещи - торгового терминала.

Так появился Finam Terminal - TUI-клиент с открытым кодом для торговли через API брокера «Финам». Написан на Go в свободное время, работает прямо в консоли, весит ~24 МБ. В этой статье расскажу, зачем он нужен, как устроен и почему наличие хорошего API у брокера - это приглашение что-то построить.

OpenClaw — это 180K звёзд на GitHub, но и 800 МБ node_modules, конфликты зависимостей и Node.js рантайм. Кто-то переписал его на Go: один бинарник на 35 МБ, 3-5x меньше RAM, деплой в одну команду. Разбираю, зачем это было нужно, что даёт мультиагентная архитектура на горутинах, и имеет ли смысл переходить с OpenClaw.

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

Ни один тикет не обновлен. Таймер не запущен. Чат на тысячу строк, но он испарится, как только закроешь сессию. А когда коллега спросит, что было сделано за день, ты будешь восстанавливать картину по памяти. Удачи.

Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.

Когда VPN на телефоне уже не спасает, а DPI провайдера научился резать WireGuard за секунды, приходит время переносить обфускацию на роутер. В этой статье расскажу, как я сделал полноценный аддон для Asuswrt-Merlin с веб-интерфейсом, выборочной маршрутизацией и поддержкой AmneziaWG 2.0. И почему пришлось отказаться от kernel module.

Проблема:

У меня ASUS GT-AX11000 с прошивкой Asuswrt-Merlin. Обычный WireGuard на роутере через встроенный клиент Merlin работает, но провайдер его видит и режет. AmneziaWG решает эту проблему за счёт обфускации, DPI не может отличить трафик от обычного UDP.

На телефоне и ПК есть клиент Amnezia VPN, и там всё работает. Но есть нюанс...

Pusk — self-hosted сервер алертов на 16 МБ. Один бинарник, без внешних сервисов, частично совместим с Telegram Bot API (13 методов из 80+).

Типичная ситуация: несколько серверов, Zabbix собирает метрики, Python‑боты шлют алерты в Telegram. У кого‑то это веб‑проект, у кого‑то видеонаблюдение, у кого‑то живые эфиры, где 2 минут без алерта = зрители видят чёрный экран. Работало годами.

А потом канал до API отвалился. Причина неважна — лимиты, блокировки, авария на стороне провайдера. Алерты встали. Нужен был свой канал доставки, который не зависит от внешних сервисов.

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

Команда «Онтико» решила не делать вид, что это просто «ещё один виток роста», и в 2026 году меняет сам формат IT-конференций! GolangConf 2026 — это уже не про «послушать доклады», которые кто-то просЛушал, а кто-то просРушал :) Мы будем разбираться с тем, что реально болит у команд прямо сейчас.

Перед командой встала типичная для высоконагруженных сервисов постановка по обработке сообщений:

1. Порядок обработки в рамках одной логической партиции

2. Очень много ключей партиций

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

4. Ретраи и отложенные сообщения

Ни одна готовая «одна технология» не закрывает это из коробки без компромиссов. Ниже — как мы к этому пришли и что в итоге сделали в виде библиотеки smart-redis-queue (очередь на Redis, логика в Lua-скриптах).

Всем привет, меня зовут Кирилл Вересников, я бэкенд-разработчик в iSpring.

Мы делаем iSpring LMS — платформу для корпоративного онлайн-обучения. Исторически это был модульный монолит на PHP, а затем система начала постепенно дополняться микросервисами. Самые нагруженные и часто меняющиеся части мы выносили из монолита, а новый функционал всё чаще сразу делали в микросервисах.

Эта статья будет полезна тем, кто:

- постепенно выносит части монолита в сервисы;

- устал от старых nginx-конфигов, которые годами копились ради обратной совместимости;

- ищет способ стандартизировать входной трафик и убрать бизнес-логику из прокси;

- выбирает между nginx и envoy.

Написал SOCKS5-прокси на Go, который прячет трафик внутри WebRTC TURN-сессий WB Stream — видеоплатформы Wildberries. Отреверсил их HTTP API, выяснил что под капотом LiveKit, написал минимальный protobuf-парсер чтобы вытащить ICE-серверы из JoinResponse, и прокинул KCP-соединение с VPS через чужой TURN-relay. В посте — полный разбор с кодом: от первого HTTP-запроса до момента, когда google.com открывается через видеоконференцию Wildberries.

Привет! Это снова Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наши операторы продолжают бороздить просторы K8s, а инсталляторы — разворачивать новые кластеры, и мы готовы поделиться с вами новыми полезностями.

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

Telegram практически заблокирован. Max — официальный, удобный, но его не хотят ставить даже те, кто в курсе, что именно VK-экосистема уже хранит половину их цифровой жизни. В этом зазоре появляется вопрос: а нужен ли вообще «свой» мессенджер, и если да — каким он должен быть? Я попробовал ответить не словами, а кодом.

Продолжаю пилить на Go утилиту для работы с TUN-интерфейсами. В предыдущей версии пакеты проходили путь system <-> tun10 <-> go app <-> tun11 <-> inet. Основная цель тогда была одна — разобраться с TUN-интерфейсами и сетевыми настройками. В текущей версии я добавил простейший udp relay, вынес сложность в конфиг и в целом переработал проект.

Что ж... Недавно я увлекся C++, поэтому давайте разберемся в какой-нибудь технологии и напишем по ней статью. Мой выбор пал на WebRTC и клиент на Qt.