Go *

Я пилю VantageDNS, privacy-focused recursive DNS-резолвер с фильтрацией. Edge-фронт на Go, 10 нод по миру, миекговский miekg/dns под капотом. На каком-то этапе у меня закончились отговорки, и пришлось писать DNSSEC validator. Своими руками. Ночью. Под кофе восьмой кружки.

Ниже расскажу, как устроен trust chain, что есть в стандартной библиотеке, какие грабли разложены по дороге, и почему алгоритм 14 я до сих пор обхожу как кота во дворе.

eBPF называют «безопасным по умолчанию». Но что, если это не так?

Все хвалят eBPF за «безопасность и изоляцию». Но что если данные из вашей eBPF-мапы может прочитать любой процесс с правами root?

Я не буду учить писать свой eBPF-хелпер. Я покажу практический пример демонстрации этой уязвимости.

Пора разобрать вопрос, о котором часто молчат: почему данные из eBPF-мап могут быть доступны не только вашему агенту.

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

Если честно, то лично я считаю, что это не просто «альтернатива», а предпочтительный выбор по умолчанию для большинства API (где конфигурация — это именно данные).

По большому счёту, паттерн Resolvable Config Struct просто наводит порядок в тех структурах Config и Options, которыми мы все пользуемся на порядок-два чаще, чем Functional Options. Чтобы его внедрить понадобится лишь минимальный рефакторинг, потому что всеми элементами этого паттерна мы и так постоянно пользуемся, просто сейчас там бардак, в который нужно добавить немного строгости чтобы стало намного лучше.

Мой поинт не в том, что Functional Options были ошибкой. Скорее это был разумный ответ на плохие конструкторы и наивные Config-структуры образца «просто положим всё в поля и как-нибудь разберёмся». Но сегодня есть решение получше, и его стоит внедрять.

Привет. В предыдущих статьях этого цикла мы разбирали, как Kubernetes-объекты читаются (первая — informer и кэш в controller-runtime) и записываются (вторая — Server-Side Apply, patch’и, managedFields). Сегодня — про их жизненный цикл.

Между kubectl apply и появлением объекта в etcd проходит целая цепочка: admission chain, мутирующие и валидирующие вебхуки, schema-валидация, встроенные плагины. Между kubectl delete и реальным исчезновением объекта может пройти от миллисекунд до часов — в зависимости от того, какие на нём финализаторы и какая стратегия каскадного удаления выбрана. Механизм при этом универсален для любого ресурса: Pod, Deployment, ваш CRD — жизненный цикл у всех один.

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

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

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

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

io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.

Когда сервис падает с too many open files, первое желание — проверить ulimit -n и поднять лимит повыше. Но в Linux эта ошибка редко сводится к одной настройке: в игру вступают файловые дескрипторы, сокеты, лимиты процесса, настройки контейнерного рантайма и поведение самого приложения.

В статье разбираем, что на самом деле означает EMFILE, где смотреть реальные ограничения в Kubernetes и как отличить нехватку лимита от утечки, которая рано или поздно снова уронит прод.

В прошлой статье я рассказывал, как мы встроили VLESS + Reality прямо в наше iOS-приложение через sing-box, чтобы обход блокировок был не задачей пользователя, а деталью реализации. Если коротко: TLS-рукопожатие проксируется на посторонний крупный сайт, активный пробинг упирается в этот сайт, IP относимся как к расходнику, конфиг доставляется отдельно от сборки. Подход работает, и для подавляющего большинства соединений из России работает прямо сейчас.

Кроме одного класса сетей, в которых не работал.

Внутри этого класса оказались, в том числе, корпоративные подсети, гостевой Wi-Fi в некоторых аэропортах и часть регионального покрытия одного из операторов. Картина в логах одна и та же. Туннель поднимается, TCP-соединение на relay открывается, TLS-рукопожатие начинается, и через секунду sing-box на сервере пишет в журнал: REALITY: processed invalid connection. Сразу обрыв, нет ретраев которые что-то меняют.

Эта статья про то, что мы увидели в этих сетях, почему Reality в одиночку их не пробивает, и что мы поставили рядом, чтобы пробивал. Если читали предыдущую часть, продолжайте отсюда. Если не читали, важен один тезис: туннель у нас живёт внутри приложения, через sing-box, скомпилированный в нативный фреймворк, без системного VPN.

Оптимизация кода сервисов на Go под реальную нагрузку

Когда сервис на Go начинает «тормозить» под реальной нагрузкой, проблема почти всегда не в самом языке и даже не в алгоритмах. Чаще всего узкие места лежат на уровне работы с памятью, сериализации данных и неочевидных накладных расходов рантайма. Если сервис упирается в сеть, базу данных или внешние API — оптимизация кода даёт ограниченный эффект. Но в CPU-bound сценариях (парсинг JSON, агрегации, обработка данных) каждая лишняя аллокация и копирование начинают стоить дорого.

Ключевая особенность Go — автоматическое управление памятью через garbage collector. Это удобно, но под нагрузкой GC становится заметным фактором:

Всем привет! Меня зовут Миша, я разрабатываю платформу Яндекс Еды. В декабре я рассказывал, как Temporal без боли решает привычную проблему распределённой бизнес‑логики.

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

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

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.

Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.

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

Написать свою in-memory базу данных — это своеобразный способ изучить Go под капотом и сделать значимый пет-проект. Создавать обычную обертку над map скучно. Поэтому я задался вопросом: а что если написать по настоящему быстрый движок с бинарным хранением, а сверху прикрутить интерактивного ИИ-ассистента, с которым можно общаться на естественном языке, заставляя его самостоятельно выполнять цепочки запросов?

Мы делаем мессенджер. Весной 2026 наш бэкенд начал отваливаться у части пользователей из России: HTTPS‑запросы к API таймаутятся, WebSocket не поднимается. Картина знакомая всем, кто держит сервис с одним доменом и одним IP.

Для мессенджера это приговор. Не «неудобно», а именно приговор: приложение, которое не может даже подключиться, бесполезно. И вариант «попросите пользователя сначала включить VPN» нас не устраивал совсем. Ниже разберу, почему мы в итоге встроили обход прямо в приложение, на чём он работает и на какие грабли мы наступили. Без маркетинга, по делу.

Привет, Хабр! Меня зовут Даниил, я программист и архитектор, разрабатываю программное обеспечение и спецификации для создания ПО в YADRO. Продолжаю цикл статей об организации рабочего места по методу Spec-Driven Development. В первой части мы настроили агента Claude Code. Во второй расскажу, как настроить harness — программную инфраструктуру, выступающую оберткой для LLM, и наконец поделюсь решением задач по методу SDD.

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

На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.

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

Сначала всё выглядело как типичная AI-история успеха.

За пару вечеров LLM помогла превратить Google Sheets для учёта финансов в настоящее приложение. Потом появился backend, sync между устройствами, mobile-first UX, AI-рекомендации, rollback, conflict resolution, миграции, Docker images, golden tests и React-компонент на 10 537 строк.

Оказалось, что AI действительно радикально ускоряет старт разработки. Но production начинается сильно позже демки.

В последние годы для команд, которые работают с зарубежной инфраструктурой из России, обычный корпоративный VPN перестал быть чем-то, что можно один раз настроить и забыть. OpenVPN, WireGuard, IPsec, различные TLS- и QUIC-обёртки могут работать стабильно месяцами, а потом внезапно начать деградировать: где-то соединение не устанавливается, где-то режется UDP, где-то DPI начинает узнавать сигнатуры, где-то провайдер меняет правила фильтрации.

Для компании это превращается не в техническую мелочь, а в операционный риск. Инженеры не могут попасть на серверы. DevOps не может проверить прод. Администратор не может забрать бэкап. Пентестер не может подключиться к стенду заказчика. При этом инфраструктура может находиться в Европе, США, Азии или у любого другого зарубежного провайдера, а сотрудники — физически находиться в РФ.

В какой-то момент мы пришли к простой мысли: если из корпоративной сети ещё можно установить исходящее SSH-соединение, то можно попробовать использовать сам OpenSSH не только как инструмент администрирования, но и как транспорт для L3-туннеля. В OpenSSH для этого давно существует режим ssh -w, который поднимает туннель через tun-устройство.

Идея статьи не в том, чтобы объявить ssh -w «лучшим VPN на все времена». Это не замена WireGuard для нормальной постоянной инфраструктуры и не серебряная пуля против любых сетевых ограничений. Но это очень полезный аварийный и корпоративный вариант: работает поверх обычного SSH, не требует отдельного VPN-демона на сервере, может быть поднят на дешёвом VPS, использует привычную модель ключей OpenSSH и позволяет строить полноценную маршрутизацию на L3.

В вакансиях на hh всё чаще встречаются требования: Go + Python, Go + PHP. Для веб-разработки python и php во многом похожи, и у меня уже был опыт работы с ними.

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

Пока в приложении две роли и три проверки, авторизация умещается в if user.Role == "admin". Но стоит добавить пару ресурсов, ролей и исключений — и условные проверки начинают расползаться по хендлерам, дублироваться и жить своей жизнью.

В этой статье разберём, как навести порядок с помощью Casbin: вынесем правила доступа из кода в конфиг, пройдём путь от простого ACL до RBAC с иерархией ролей, соберём HTTP-сервер на Go с авторизационной middleware и обсудим грабли, на которые легко наступить по дороге.