Автопост, который не спамит: заметку пишет человек, расписание проверяет

Платформа30 августа 2026 · 5 минут

Задача, которая выглядит простой

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

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

Почему из коммитов ничего хорошего не выйдет

Мы посмотрели на то, что реально попало бы в ленту. За одну неделю в истории лежали такие записи:

«правки по замечаниям»
«fix: опечатка в подписи колонки»
«ещё раз то же самое, теперь на проде»

Между ними — три изменения, о которых действительно стоило рассказать. Но чтобы отличить одно от другого, нужно понимать смысл работы, а не только текст сообщения. Автоматическая выжимка этого не умеет: она одинаково старательно перескажет и переименование переменной, и переделку начислений.

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

Правило, к которому мы пришли

Автоматизировать нужно доставку, а не сочинение. Машина хорошо отвечает на вопрос «пора ли», и плохо — на вопрос «что сказать».

Как устроено у нас

Заметку к версии пишет тот, кто эту версию делал. Она лежит файлом рядом с кодом: devlog/builds/<номер сборки>.md. Расписание раз в сутки проверяет три вещи:

номер текущей сборки отличается от последнего опубликованного;
файл с заметкой для этой сборки существует;
заметка укладывается в ограничение мессенджера.

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

Сами посты тоже лежат файлами в репозитории, а не в переписке. Три следствия, ради которых это сделано:

текст можно поправить до публикации и увидеть, кто и что менял;
пост переживает смену человека, который ведёт канал;
публикация становится обычной командой, а не ручной операцией «скопировать — вставить — не забыть про форматирование».

Что оказалось неочевидным

Разметка. Мессенджер принимает узкий набор тегов. Всё остальное, включая безобидный амперсанд в примере ссылки, ломает отправку целиком — причём молча, ошибкой на стороне сервера. Текст приходится приводить к разрешённому набору и экранировать, а не «просто отправлять».

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

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

Где это пригодится не только нам

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

Результат тоже одинаковый. Абонент получает «Плановые работы на узле № 42 с 03:00 до 05:00» и не понимает, коснётся это его или нет. Через месяц такие сообщения перестают читать — и настоящее предупреждение о серьёзной аварии тоже проходит мимо.

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

Как это устроено внутриРазборы находок в коде — в канале разработки. Там же выходят заметки о новых сборках, о которых эта статья.

Как это работает в СмИТ Биллинге

Тот же принцип — «машина отвечает за доставку, человек за текст» — в системе выглядит как раздел «Сообщения»: каналы настроены один раз, тексты лежат шаблонами, а отправку запускают события.

Раздел «Сообщения»: пять каналов — почта, SMS, Telegram, VK и push, — шаблоны и счётчик отправленного

Каналов пять: почта, SMS, Telegram, VK и push в мобильное приложение. Текст пишется один раз на тип события, а дальше система сама решает, кому и когда его отправить — по подключению, по балансу, по плановым работам на конкретном узле.

Выключатель у каждого канала отдельный: если SMS-шлюз замолчал, рассылка не встанет целиком — уведомление уйдёт остальными путями, а настройки останутся на месте.

Подробнее

Документация: сообщения и каналы Модуль «ЛК и мобильное приложение» Модуль «Почтовый сервер»

Схемы по теме все схемы →