Сергей Озеранский
رفتن به کانال در Telegram
О разработке, DevOps, DevSecOps, архитектуре, безопасности. Без воды и скучных теорий - только реальный мой опыт, инсайты из практики и немного жизни.
نمایش بیشتر2 348
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+97 روز
-3330 روز
در حال بارگیری داده...
کانالهای مشابه
هیچ دادهای
مشکلی وجود دارد؟ لطفاً صفحه را تازه کنید یا با مدیر پشتیبانی ما تماس بگیرید.
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+27
در 2 کانالها
اوت '26
+20
در 0 کانالها
Get PRO
ژوئیه '26
+21
در 2 کانالها
Get PRO
ژوئن '26
+44
در 0 کانالها
Get PRO
مه '26
+14
در 0 کانالها
Get PRO
آوریل '26
+26
در 0 کانالها
Get PRO
مارس '26
+87
در 0 کانالها
Get PRO
فوریه '26
+117
در 0 کانالها
Get PRO
ژانویه '26
+89
در 0 کانالها
Get PRO
دسامبر '25
+141
در 0 کانالها
Get PRO
نوامبر '25
+174
در 3 کانالها
Get PRO
اکتبر '25
+285
در 2 کانالها
Get PRO
سپتامبر '25
+372
در 0 کانالها
Get PRO
اوت '25
+98
در 1 کانالها
Get PRO
ژوئیه '25
+252
در 2 کانالها
Get PRO
ژوئن '25
+193
در 0 کانالها
Get PRO
مه '25
+259
در 1 کانالها
Get PRO
آوریل '25
+218
در 1 کانالها
Get PRO
مارس '25
+484
در 3 کانالها
Get PRO
فوریه '25
+574
در 1 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 19 سپتامبر | 0 | |||
| 18 سپتامبر | +2 | |||
| 17 سپتامبر | +3 | |||
| 16 سپتامبر | +1 | |||
| 15 سپتامبر | +2 | |||
| 14 سپتامبر | +2 | |||
| 13 سپتامبر | +3 | |||
| 12 سپتامبر | +4 | |||
| 11 سپتامبر | +5 | |||
| 10 سپتامبر | 0 | |||
| 09 سپتامبر | +1 | |||
| 08 سپتامبر | 0 | |||
| 07 سپتامبر | 0 | |||
| 06 سپتامبر | +2 | |||
| 05 سپتامبر | 0 | |||
| 04 سپتامبر | +1 | |||
| 03 سپتامبر | 0 | |||
| 02 سپتامبر | +1 | |||
| 01 سپتامبر | 0 |
پستهای کانال
Я вот не понимаю, зачем люди идут в OSS и контрибьютят на отвали. Ценности в этом ноль для всех: ни мейнтейнеру, ни самому контрибьютору.
По-моему, OSS как раз то место, где инженер должен выложиться на максимум. И контрибьютить в OSS пиздец как круто. Тут никто не бьет тебя по рукам со словами "нет времени делать хорошо". Нет дедлайна от продакта, нет "давай на скорую руку, потом поправим". Есть только ты, твоя работа и твое творчество.
Поэтому для себя я делаю простой вывод: то, что человек делает в OSS, это потолок того, что он вообще умеет. Лучше уже не будет.
Вы скажете, что я слишком строг. Но как можно нести PR на ревью, когда у тебя падает линтер? Серьезно. Такое несут, и это дичь. Даже сейчас, когда есть LLM. И даже вопрос не в линтере, речь в том числе про степерь погруженности в задачу, про изучение документации и прочего, что помогает сделать ожидаемое действительностью.
Я не строгий, я объективный. OSS это тоже работа, и на нее уходит время. Причем не только время контрибьютора, но и мейнтейнеров, которые по ту сторону так же впахивают, часто бесплатно и по вечерам, чтобы выдать продукт, которым пользуются люди. Да, OSS это продукт. И к нему применимо все то же, что и к продуктовой разработке.
Я очень уважаю мейнтейнеров, ведь я бесплатно пользуюсь результатами их труда. Поэтому, если я что-то контрибьючу, то сначала сам все проверяю: тесты, линтер, описание, чтобы было понятно, что и зачем. Сверяюсь со стандартами репозитория и так далее. Для меня это и есть благодарность. И это в первую очередь не звездочка на гитхабе, а PR, который не нужно гонять по кругу из десяти правок. Чтобы мейнтейнерам было приятно его открыть, а не тошно.
Уважайте чужое время. В OSS это особенно видно.
| 2 | Помните про https://github.com/ozeranskii/httptap?
Я писал о нем давно еще - > тут.
Наклепал много issue, для тех кто хочет вкатиться в OSS или попрактиковаться себя и свою LLM - welcome. Только, пожалуйста, без нейрослопа и не будьте meat-proxy. Не хочу тратить время на фиксы фиксов. Ибо вот даже простой фикс, я исправил (смотри историю коммитов в PR), так как почитал документацию, а автор видимо нет. | 717 |
| 3 |  Поломали или у меня поломалось? Как у вас? | 458 |
| 4 | А вот сейчас я не понял. Первый раз такое на Max 20x | 566 |
| 5 | Я понимаю, что полностью нейротекст читать, возможно, неинтересно. Но в части моих текстов я не припомню такого, чтобы мой текст был полностью написан с помощью LLM, потому что я хочу как раз сохранять свою естественность, своё настроение, свой стиль и так далее. Мой стиль, на самом деле, ещё и можно иногда перепутать с искусственным интеллектом, потому что я привык излагать свои мысли достаточно подробно, чётко и разжёвывать. У меня была проблема, и сейчас она иногда проявляется, что я слишком детально рассказываю что-либо людям — просто потому, что мне это интересно, я хочу, чтобы человек понял. Я, наверное, был бы хорошим преподавателем, но мне нужны хорошие ученики, которым это интересно. И я хороший ментор — это моя и субъективная, и объективная оценка, иначе люди не шли бы ко мне за менторской помощью.
Соответственно, у меня был даже случай, когда в одном из постов меня по сути обвинили в том, что это искусственный интеллект. Это был не последний пост, уже давно, и я, по-моему, даже особо ничего не ответил: ну сказано и сказано, а вопроса нет, то есть на что отвечать? На комментарии не всегда будешь отвечать, потому что комментарий может и не предполагать какого-то призыва к действию. Не то чтобы это обидно, но я вижу в этом в первую очередь вот это наше искажение восприятия реальности: мы стали меньше доверять, и искусственный интеллект это доверие нам подорвал. Раньше тоже было всякое разное, но это в большей степени создавали люди, а сейчас искусственный интеллект может создавать кучу фейков и прочего-прочего в интернет-пространстве, так что наша когнитивная нагрузка на фильтрацию контента стала только выше. | 609 |
| 6 | Искусственный интеллект нас очень сильно продвинул вперёд, но создал, как мне кажется, ещё одну проблему. Он подорвал доверие людей к людям.
Раньше, до искусственного интеллекта, мы хоть как-то верили тому, что люди пишут или создают какой-то цифровой контент в интернете. Да, был Photoshop, да, были и другие инструменты, которые ровно так же на самом деле помогали людям с созданием цифрового контента, как сейчас в том числе помогает искусственный интеллект. Раньше мы, как мне кажется, в принципе не сильно обращали внимание на то, что какая-то картинка отретуширована или в неё внесены какие-то корректировки. Мне, говорю за себя, в целом было на это особо без разницы: я знал, что за интересным мне контентом стоят реальные люди, и мне было интересно их слушать и воспринимать. А то, что мне было неинтересно, я и так не читал.
Сейчас искусственный интеллект — это тот же самый Photoshop, только в части текстов, так мне кажется. И лично я некоторые свои тексты перед публикацией пропускаю через искусственный интеллект, чтобы он исправил мои ошибки. Потому что пишу я с ошибками: я часто тороплюсь, пишу неправильные окончания слов — думаю, вы это частенько замечаете, и даже кто-то мне об этом пишет, я потом исправляю. Это очень классно: с одной стороны, я таким образом знаю, что мои тексты читают, что мне указывают на ошибки. Но я хочу давать качественный контент, который будет приятен для чтения и при этом, даже с условием того, что пост по сути обработал искусственный интеллект, всё ещё сохранять моё авторство, моё настроение, мой стиль изложения и так далее. Я не создаю тексты с нуля в искусственном интеллекте, я лишь ретуширую тексты, и то не все. Для меня как раз важно сохранить ту самую человечность.
Но вот что я заметил: у инженеров есть профессиональная деформация, и она во многом проявляется и в части искусственного интеллекта, я её сейчас вижу очень отчётливо. Когда-то давно, когда искусственный интеллект только начал приходить к нам в разработку, мы стеснялись его, так как считали, что он принижает наше профессиональное участие, да и профессионализм тоже как бы занижает — тем, что мы по факту пользуемся подсказкой. А старые инженеры привыкли решать задачи сами, проходя весь путь через пот, слёзы и кровь, и искусственный интеллект немножко шатал в этом направлении психику, мне кажется. Дальше люди приняли, что это нормально, что это всего лишь инструмент, который позволяет писать код эффективнее. И разработка уже на самом деле никогда не станет прежней. Я сомневаюсь, что в будущем мы решим, что писать код руками лучше. Где-то лучше, конечно, наверное, ещё остаются такие секторы, но в массовых задачах это как будто теряет какой-то практический смысл, и объяснить неиспользование искусственного интеллекта в разработке уже намного сложнее, чем его использование.
И когда инженер постоянно общается с искусственным интеллектом, он так или иначе видит какие-то паттерны его поведения и начинает замечать такие же похожие паттерны — или сам их воспроизводить — в написании текстов. Например, вы читаете одно и то же каждый день, общаетесь с одной и той же системой искусственного интеллекта, и когда видите где-то что-то похожее на то, что уже встречали в своей ежедневной работе, это сразу воспринимается как «кто-то что-то сделал с помощью искусственного интеллекта». Я думаю, вы понимаете, о чём я. И я считаю, что это частично профдеформация. Человек, который нацелен на то, чтобы изучить что-то новое, даже если это, как мне кажется, отретушировано с помощью искусственного интеллекта, пропустит этот момент, потому что в тексте всё равно есть экспертиза человека, который его написал. | 521 |
| 7 | Принес вам полезность - infosec.mozilla.org
Это публичные security-гайдлайны Mozilla. Рекомендации по безопасности написаные инженерами для инженеров. Регулярно заглядываю, при настройке чего либо и так же LLM у меня имеет этот сайт в списке референсов по DevDecOps, на равне с OWASP и NIST.
Чем полезен сайт:
— Web Security - чеклист заголовков и настроек для веба (CSP, HSTS, cookies, CORS). У каждого пункта приоритет и объяснение, зачем.
— OpenSSH - какие алгоритмы и ciphers оставить, какие выкинуть, готовые конфиги сервера и клиента. Тот случай, когда не нужно изобретать, а достаточно следовать best practices.
— Rapid Risk Assessment - методика оценки рисков сервиса. Понятный алгоритм и формула.
— Key Management - алгоритмы, длины ключей, сроки ротации.
— ssl-config.mozilla.org (configurator.tlsref.org) - генератор TLS-конфигов под nginx/haproxy/postgres и еще десяток серверов.
Если делаете сервис, на который не наплевать, то это сэкономит вам (или вашей LLM) время.
Сохраняй пост, чтобы потом его никогда не прочитать. | 604 |
| 8 | Ситуация. У вас сборка образа стала падать на этапе проверки CVE. Вы проверили и видите, что базовый образ Debian, который вы используете, еще не имеет обновленных пакетов, но сами пакеты fixed.
Ваши действия?
1. apt-get update && apt-get -y upgrade && rm -rf /var/lib/apt/lists/*
2. добавить CVE в игнор, с датой окончания игнорирования
3. собрать собственный базовый образ
3. свой вариант в комментариях | 639 |
| 9 | С приходом LLM увеличилась скорость разработки, точнее скорость написания кода, в первую очередь. Конечно, LLM помогает на разных стадиях, но именно написание кода — это, наверное, та функциональность, которая ушла в массы. Давайте честно: мы и раньше не всегда успевали делать код-ревью коллег, а тут появился новый коллега, а иногда и не один, и звать его LLM — с кучей субагентов, и каждый выдаёт какую-то информацию. Собственно, отсюда и нейрослоп. Но, как мне кажется, его перестают бояться, ибо «кому вообще нужен этот ваш код, главное — фича есть». Качество тут будет хромать: баги, стоимость поддержки, безопасность. Понятно, что решать это теперь тоже будет LLM (ага).
Второй момент. Вчерашний джун теперь может «выдать» то, в чём сам не разобрался и чего не понял. Вот тут страшновато: каким бы прекрасным ни был промпт и как бы LLM его ни обработала, результат надо проверять. А как это сделать инженеру, если ему LLM про Кафку, а он про неё не алё? Поэтому у него два выхода, точнее три:
— вникнуть, изучить и стать лучше;
— довериться LLM, она умная;
— оставить как есть, другие разберутся (я про сеньоров в команде, которые стали инженерами до LLM и пропускали всё это дерьмо через себя).
При этом для себя LLM оцениваю очень позитивно: я стал сильно производительнее, и результат нашего с ней труда меня устраивает. Работаю я так же, как и без неё, только код руками теперь почти не пишу. Но так же его читаю, так же проектирую, так же задаю кучу вопросов и перепроверяю всё, что мне сказано. И новое изучаю быстрее — тут вообще сильно прокачался. Но опять же: я много раз видел, как LLM решает, казалось бы, лёгкую задачу с третьего-четвёртого раза. Не потому что она глупая, а потому что не видела того, что видел я, и не думала о том, о чём думаю я. Вот это и делает меня не meat-proxy. И я очень этому рад )))
И виноват тут не LLM. Я считаю, что человек по природе ленив, а быстрый результат — это, как правило, дофаминовый допинг. LLM его выдаёт щедро: не нужно теперь читать документацию и вникать в детали (на самом деле нужно, и даже сильнее, чем до LLM). К чему это приведёт — пока не знаю. | 1 215 |
| 10 |  22 октября Kubernetes-сообщество встречается офлайн в Москве!
Кому будет интересна конференция:
– DevOps- и SRE-инженерам;
– специалистам по Kubernetes и облачной инфраструктуре;
– платформенным инженерам;
– архитекторам и техническим руководителям;
– всем, кто занимается эксплуатацией и развитием инфраструктуры.
Что будет в течение дня?
🎤 Доклады
Про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру, Service Mesh, безопасность, экономику платформ, bare metal и ЦОДы.
⚡️ Активности партнеров
Дополнительная возможность пообщаться с участниками конференции и включиться в интерактивные форматы от партнеров.
🍻 Афтепати
После основной программы нетворкинг продолжится уже в неформальной обстановке.
А еще на Kuber Conf можно не только прийти как участник, но и выступить! До 15 сентября принимаются заявки на доклады — делитесь практическими кейсами и экспертизой, которые могут быть полезны Kubernetes-сообществу.
👉 Так что не откладывайте, регистрируйтесь и зовите коллег — все подробности по ссылке! | 328 |
| 11 | Мой товарищ ищет дизайнера.
```
Ищу web-дизайнера на несколько задач.
Задачи достаточно простые.
Оплата почасовая( от 2500 час) или фикс за проект.
Задачи:
🔸Продающий лендинг для услуги брендирования школьных товаров.
🔸Продающий лендинг для БАДов.
🔸Сделать дизайн двух новых страниц в готовом проекте, дизайн система есть.
```
Контакт для связи @DmitriyGrigoriev | 375 |
| 12 | При расхождении: ERROR в лог и одна строка adjustment, где баланс до — это сумма леджера, а баланс после — хранимый остаток. Сам остаток не меняется. Баланс — источник истины для того, сколько клиенту можно тратить, и сверка не должна молча менять эту сумму. Она фиксирует разницу и делает так, что леджер снова объясняет остаток целиком. Повторный запуск ничего не найдёт: разница уже записана.
В норме таких строк ноль. Каждая — повод искать баг. | 1 |
| 13 | Леджер: журнал, которому можно верить
Баланс говорит, сколько у клиента денег. Леджер объясняет, откуда взялась эта цифра. Теперь про него: как устроена таблица, почему в неё нельзя записать неверную строку и что происходит, когда одну и ту же операцию присылают дважды.
Только добавление
Леджер — таблица, в которую можно только вставлять. У репозитория нет методов update и delete для неё. Ошибку в леджере не исправляют, её объясняют новой записью.
В каждой строке: тип операции, сумма, баланс до, баланс после, ключ идемпотентности, ссылка на источник (джоба, платёж, возврат) и кто это сделал.
Семь типов операций
Три уменьшают баланс:
debit — списание за джобу,
refund — возврат клиенту через платёжного провайдера,
reversal — зарезервирован для внутренних отмен.
Три увеличивают:
credit — пополнение,
bonus — начисление сверх оплаты,
free_grant — стартовый грант.
Седьмой, adjustment, единственный со знаковой суммой: его пишет сверка, о которой ниже.
Направление операции задаётся типом, а не знаком. Сумма всегда положительная. Так по одной колонке видно, что это за операция, и нельзя случайно записать "списание на минус пять долларов".
Postgres проверяет арифметику
На таблице стоит CHECK:
(type IN ('debit','refund','reversal')
AND balance_after = balance_before - amount)
OR (type IN ('credit','bonus','free_grant')
AND balance_after = balance_before + amount)
OR type = 'adjustment'
Строку, в которой числа не сходятся, база отклонит, даже если в коде баг. Это последняя линия обороны, и она не зависит от того, кто и откуда пишет.
Откуда берутся баланс до и после? В прошлом посте списание делалось одним UPDATE с RETURNING, и именно возвращённое значение попадает в леджер. Одна транзакция: изменили баланс, получили новый остаток, вставили строку с ним. Разойтись эти два числа не могут.
Одна операция — одна запись
Мир вокруг нашего кода ненадёжен. Платежный провайдер присылает webhook об оплате, не получает ответ вовремя и присылает ещё раз. Воркер списания падает после UPDATE, но до commit, и повторяет цикл. Ретрай после сетевой ошибки. Во всех случаях операция одна, а попыток несколько.
Каждая операция несёт уникальный ключ: payment:<id платежа>, job:<id>:period:<начало периода>, refund:<id возврата>, grant:user:<id>. На колонке UNIQUE-индекс. Защита от дублирования на уровне БД.
Схема записи:
SAVEPOINT → UPDATE баланса → INSERT в леджер с ON CONFLICT DO NOTHING.
Если INSERT вернул строку, savepoint фиксируется. Если не вернул, ключ уже есть: savepoint откатывается, UPDATE баланса отменяется вместе с ним, а наружу возвращается существующая запись с пометкой "уже применено".
Почему не проверить ключ до UPDATE? Потому что между проверкой и вставкой второй процесс успеет сделать то же самое. Арбитром должен быть уникальный индекс, а не код. Savepoint нужен, чтобы откатить только эту операцию, не трогая внешнюю транзакцию: воркер списания держит блокировку на строке джобы, и терять её из-за дубликата нельзя.
Леджер это не двойная запись
В бухгалтерии каждая операция затрагивает два счёта, и сумма дебетов всегда равна сумме кредитов. У нас single-entry: одна строка, один аккаунт, направление в типе. Платформа ведёт только один вид счёта — обязательства перед клиентами. Выручка, комиссии провайдера и деньги на расчётном счёте живут в бухгалтерии. Если появятся внутренние взаиморасчёты между несколькими видами счетов, double-entry окупится. Пока это усложнение без выгоды.
Сверка
Баланс — денормализованная сумма леджера. Это ускоряет горячий путь, но два числа могут разойтись, если где-то есть баг. Раз в десять минут воркер считает по леджеру сумму со знаками для каждого аккаунта и сравнивает с хранимым остатком. | 1 227 |
| 14 | Знаковая корректировка — служебный путь, и баланс она не трогает. Её пишет только фоновая сверка баланса с леджером, когда находит расхождение: одна строка, которая объясняет разницу, без изменения остатка. Ручных правок остатка нет вообще: можно начислить бонус, но он пройдёт через тот же путь, что и пополнение, с записью в леджер. | 1 |
| 15 | Баланс: как хранить деньги клиента и не ошибиться
В прошлом посте разделили биллинг и леджер: баланс разрешает операции, леджер их объясняет. Сегодня про первую половину — таблицу баланса.
Одна строка на клиента
Баланс — это отдельная таблица с одной строкой на аккаунт. В ней текущий остаток и два накопительных счётчика: сколько всего зачислено и сколько всего потрачено. Счётчики не участвуют в решениях, они для дашборда и аналитики. Решает только остаток.
В чём хранить
Не во float. Это база: 0.1 + 0.2 в двоичной арифметике не равно 0.3. Баланс меняется каждые несколько секунд работы каждой джобы, это тысячи мелких списаний, и ошибка округления в нём накапливается.
Не в центах. Ставка раннера — доли цента за минуту, а списываем мы за секунды. В центах такая операция либо округляется в ноль, либо требует накопителя дробных остатков рядом с балансом.
Мы храним целое число микро-долларов: 1 USD = 1 000 000 единиц, BIGINT в Postgres. Целочисленная арифметика точна, а шести знаков после запятой хватает, чтобы за всю джобу накопить погрешность меньше одной единицы. Decimal живёт только на границах: ввод суммы пополнения и вывод пользователю.
Побочный эффект: ошибка в значении это значит ошибиться не на проценты, а в миллион раз. Поэтому число 1 000 000 в коде встречается ровно один раз, в модуле с прайсингом, а конвертация в доллары и обратно идёт только через две функции рядом с ним. Всё остальное работает в единицах и о долларах не знает.
Одна точка изменения
Баланс меняется только в одном классе — репозитории биллинга. Ни один сервис, роутер или воркер не пишет UPDATE в эту таблицу напрямую. Это единственный способ гарантировать, что каждое изменение остатка сопровождается записью в леджер, проверкой лимитов и корректным ключом идемпотентности.
Списание одним запросом
Классическая ошибка: прочитать баланс, проверить в коде, что хватает, и записать новое значение. Между чтением и записью успевает другая операция, и клиент уходит в минус, которого никто не разрешал.
У нас проверка и изменение — одно выражение:
UPDATE tenant_billing
SET credits_balance = credits_balance - :amount
WHERE tenant_id = :id
AND credits_balance - :amount >= -:buffer
RETURNING credits_balance
Postgres берёт блокировку на строку, проверяет условие уже под ней и возвращает новый остаток. Два параллельных списания выстраиваются в очередь, второе видит результат первого. Никаких SELECT FOR UPDATE и логики сравнения в приложении.
Если запрос затронул ноль строк, это одно из двух: аккаунта нет или денег не хватает. Различаем отдельным запросом и поднимаем разные ошибки.
Зачем буфер
Обратите внимание на -:buffer в условии. Баланс может уйти в минус, но не ниже $1.
Причина в природе продукта. Проверки денег на старте джобы нет: пока баланс в порядке, раннеры клиента доступны, и джоба стартует. Дальше она работает минуты, а списание идёт по ходу. Если ровно на нуле отклонить очередное списание, джоба упадёт на середине, клиент потеряет и время, и уже потраченные деньги. Буфер даёт ей доработать.
При уходе ниже нуля аккаунт получает отметку блокировки, и его раннеры ставятся на паузу: новые джобы не получают исполнителя, работающие платформа не прерывает. Отметка ставится один раз и не перетирается повторными списаниями, так что видно, когда именно клиент ушёл в минус. Пополнение, выводящее баланс в плюс, отметку снимает.
Кто решает блокировать, а кто выполняет — разные слои. Репозиторий умеет только списать и вернуть остаток. Решение "остаток отрицательный, значит блокируем" принимает сервис. Так политику можно менять, не трогая механику.
Три способа уменьшить баланс
Обычное списание с буфером — для джоб. Увеличивает счётчик потраченного.
Принудительное списание без буфера — для возвратов. Клиент запросил refund после того, как потратил часть пополнения; возврат всё равно применяется целиком, баланс уходит в глубокий минус, аккаунт приостанавливается. Счётчик потраченного не трогается: возврат — это не расход. | 785 |
| 16 | Как устроены биллинг и леджер в tempus.build
tempus.build продаёт минуты CI-раннеров по предоплате. Списание посекундное, ошибки в деньгах недопустимы, а каждая финансовая операция должна быть прозрачна для аудита. Начну с теории, а в следующем посте покажу, как это реализовано.
Немного теории
В заголовке два слова: биллинг и леджер. Это два связанных инструмента, но самодостаточных и решающих разные задачи. И прежде чем разбирать их, важно развести ещё одну вещь: биллинг не проводит платежи.
Проведением платежей занимается платёжный провайдер: авторизует карту, списывает деньги, делает расчет. Для tempus.build это внешняя система. Биллинг узнаёт от неё только факт: "от клиента X пришло N денег" — и с этого момента начинается его работа.
Биллинг — это тарификация и учёт. Он знает, сколько стоит секунда раннера, зачисляет пополнения, списывает за выполненные джобы и отвечает на вопрос "сколько у клиента денег сейчас и хватит ли на эту операцию". Его рабочий инструмент — баланс: одно число, которое читают перед каждой операцией и меняют после. Деньги в реальном мире биллинг не двигает, он ведёт их учёт внутри продукта.
Леджер отвечает на вопрос "как мы к этому числу пришли". Это история: журнал всех движений, каждое с суммой, направлением и причиной. В бухгалтерии этой идее очень много лет: ни одна запись в книге не стирается, ошибка исправляется новой записью.
Зачем разделять баланс и леджер? Потому что у них разные, местами противоположные требования.
Состояние должно быть быстрым и атомарным. Перед стартом джобы нужно за один запрос узнать, хватает ли денег, и сразу их зарезервировать, пока конкурирующая операция не сделала то же самое.
История должна быть неизменяемой и полной. По ней разбирают споры с клиентом, сверяют платежи с платёжными системами и банками, ищут баги в расчётах, строят аналитику. Если её можно править задним числом, ей нельзя верить. Это единственный источник истины обо всех движениях средств по балансу аккаунта.
Если хранить только баланс, при любой аномалии нечем объяснить, откуда взялась цифра. Если хранить только историю, каждая проверка "хватает ли денег" превращается в SUM по всей истории под блокировкой в БД. На горячем пути это неприемлемо. Да и просто неудобно.
Поэтому обе сущности живут рядом, но с чёткими ролями: баланс разрешает операции, леджер их объясняет. Главная инженерная задача — чтобы они никогда не разошлись. | 806 |
| 17 |  Зато точно. Или не очень? 😅
Пишите, в чём храните например, деньги или баллы: float, decimal, integer в минимальных единицах или свой вариант. | 960 |
| 18 |  Пойду смотреть, как и зачем команда Deckhouse сводит свои продукты в одну платформу.
Сейчас у них целая экосистема инфраструктурных решений. 17.09.26 в 12:00 коллеги объяснят, что меняется. Особенно для тех, у кого рядом живут контейнеры, виртуалки и ИИ-нагрузки.
Отдельно обещают сценарии для частных облаков и платформ данных.
Если у вас инфраструктура размазана по нескольким средам, послушайте вместе со мной | 349 |
| 19 | Если вы все еще хотите разбираться в программировании, а не просто просто нажимать “Yes” в консоле, то нашел интересный репозиторий https://github.com/faif/python-patterns
Это коллекция паттернов проектирования и идиом на Python.
Глобально, ничего нового там нет. Это в основном классические паттерны «банды четырёх», просто собранные на примерах и в одном месте. Так что, если хочется развиваться, то такое, я считаю, нужно знать даже с LLM. | 1 185 |
| 20 | Хочется обнять всех, кому сейчас тяжело из-за того, что происходит с интернетом.
Я не в РФ, но сталкиваюсь с этим регулярно. Чуть больше года назад был в Мск месяц и страдал. И даже близко не представляю, насколько это тяжко сейчас. Держитесь 🫂 | 1 245 |
