Моя лента

От ядра Linux до дообучения языковых моделей: открытые вебинары недели

Как устроить обмен сообщениями между сервисами, найти причины сбоев в распределённой системе, превратить бизнес‑требования в понятные задачи или подготовить модель к работе в реальной среде?

С 3 по 6 августа эксперты OTUS проведут 24 бесплатных демо-урока по разработке, инфраструктуре, архитектуре, аналитике, машинному обучению и другим направлениям. Выбирайте интересующую область и присоединяйтесь.

Системное администрирование, сети и безопасность

• 3 августа, 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 3 августа, 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 3 августа, 20:00. «Какие результаты должен давать DevSecOps‑проект бизнесу и команде». Записаться

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

Разработка и программирование

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 3 августа, 20:00. «Оживляем код: первые шаги в ООП на Python». Записаться

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python: асинхронность, процессы, потоки». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 5 августа, 20:00. «Как AI меняет работу C#‑разработчика». Записаться

Архитектура, системный и бизнес‑анализ

• 4 августа, 19:00. «Будущее корпоративного архитектора: навыки, тренды, технологии». Записаться

• 4 августа, 20:00. «Как аналитику работать с рисками». Записаться

• 5 августа, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться

• 5 августа, 20:00. «MVP глазами бизнес‑аналитика: от идеи до первых функций». Записаться

• 6 августа, 20:00. «Пользовательские сценарии на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика». Записаться

Машинное обучение и работа с данными

• 4 августа, 20:00. «PostgreSQL как память ИИ‑агентов: MVCC, очереди и партиции под нагрузкой». Записаться

• 5 августа, 20:00. «Сделайте модель своей: дообучение LLM методом QLoRA без кода». Записаться

• 6 августа, 18:00. «Практика работы с Docker — ввод модели в эксплуатацию». Записаться

• 6 августа, 20:00. «Базовая структура ML: задачи, pipeline, метрики и функции потерь». Записаться

Битрикс24

• 3 августа, 20:00. «Кастомизация компонентов в Битрикс24». Записаться

• 4 августа, 19:00. «Эффективная работа с диском Битрикс24». Записаться

Управление проектами

• 5 августа, 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться

Тестирование игр

• 4 августа, 20:00. «Как стать тестировщиком игр: первый шаг в GameDev». Записаться

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

Один оператор сравнения чуть не удалил тысячу пользователей 

На днях наводил порядок в логике автопродления подписок Telegram-бота.
Казалось, задача на полчаса.

Если кратко: у пользователя заканчивается подписка, и бот проверяет дату планируемой оплаты.
Если срок подписки истёк и продления нет, то пользователь попадает в очередь на удаление. Всё просто.

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

Сначала я подумал, что платёж не успел записаться в базу. Проверил – платёж записался.

Потом начал искать проблему в часовом поясе. Тоже нет.

Дальше полез смотреть SQL-запросы, логи, время выполнения задач. Потратил на это больше часа и уже начал подозревать, что где-то появилась гонка между обработчиком платежей и задачей проверки подписок. Стал разбираться…

Причина оказалась намного проще: в фундаменте не стоял тот оператор сравнения.

Вместо subscription_end < now
я написал subscription_end <= now.

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

Если задача проверки запускалась в тот же момент, когда обновлялась дата окончания подписки, пользователь попадал в удаление при совпадении времени окончания и времени проверки .

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

В тот момент у меня была тестовая база, поэтому последствия не были бы критичными.  Максимум, произошло бы несколько некорректных удалений.
Но я сразу представил, что было бы в продакшене. Если бы ошибка попала в релиз, задача удаления прошлась бы по всем пользователям, которые удовлетворяли этому условию.

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

Что изменил:

1. Перенастроил удаление: теперь оно происходит не сразу.

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

2. Настроил перепроверку актуального состояния подписки через x часов, чтобы отсечь ложные срабатывания.

Если пользователь оплатил доступ или подписка продлилась, удаление отменяется.

3. Добавил тест на этот сценарий, чтобы избежать повторения <=ошибки.

Раньше я проверял только обычные случаи.
Теперь отдельно проверяются пограничные значения времени.

Мораль:
даже очевидные условия нужно проверять на границах. 

Смотришь на условие и кажется, что ошибиться невозможно. Но однажды выясняется, что была допущена элементарная ошибка, которая убила тонну времени.

Всегда нужно помнить о границе условий. Именно там чаще всего и живут самые неприятные ошибки.

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

Открытый проект .MD this page позволяет преобразовать веб-страницу в чистый Markdown, готовый для ChatGPT, Claude, Gemini и других нейросетей. Решение очищает код сайта от рекламы, баннеров и другого мусора для отправки на обработку в ИИ. Есть предпросмотр, экспорт в .md и опция для мгновенного копирования сайта.

Как Kubernetes, Jira и Keycloak не помогли выпустить продукт

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

Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.

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

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

Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.

Меня позвали разобраться.

Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.

Когда доступ появился, меня встретила авторизация через Keycloak.

Напомню: разработчиков трое.

Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.

Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.

Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.

Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.

Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.

Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.

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

Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.

Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.

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

Забавно, что это полная противоположность истории с The Signal.

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

Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.

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

Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.

А вы в какой крайности?

Дебаж 🐞с ноги 🦶

Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!

Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.

Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.

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

Огромное вам спасибо! 

P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!

Проект: https://github.com/wie-project/kakehashi

Статья на Хабре: https://habr.com/ru/articles/1065502/

Пост на Hacker News: https://news.ycombinator.com/item?id=49145937