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

На работе довёл до конца упрощённую внутреннюю админку для телефонии. Заодно аккуратно дожал DevOps-часть, без лишнего фанатизма — ровно столько, сколько нужно, чтобы не страдать потом на деплое.

Нашёл для себя очень удобную штуку — https://github.com/jesseduffield/lazydocker
Lazydocker — это терминальный интерфейс для управления Docker-контейнерами, образами и сетями в реальном времени. По сути, всё то же самое, что делаешь руками через CLI, только без простыней команд. Логи, перезапуск, удаление, мониторинг — всё под рукой. Для диагностики и администрирования из консоли — прям то, что нужно.

С установкой, правда, есть нюанс. Не сказать, что сложно, но и не «apt install и поехали»:

export DIR=/usr/local/bin

curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash

lazydocker

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

Посмотрел видео «AI-программист за 500 рублей: правда об агентском кодинге» https://www.youtube.com/watch?v=CjHFdsTW4ug
Обычно такие видео либо про «всё уже заменили нейросети», либо «всё пропало». Здесь редкий случай — спокойный разбор и реальный опыт без крайностей. Смотришь и понимаешь, где это работает, а где пока нет.

Claude в очередной раз улетел в бан. Продавец аккаунта руками разводит — остаётся только ждать. Решил не зависеть от одного инструмента и попробовать альтернативы. Наткнулся на https://kilo.ai/

Kilo AI — open-source ассистент для разработки, который встраивается в IDE и работает не только с отдельными кусками кода, а с проектом целиком.

Интересный момент — поддержка внешних провайдеров через API. Есть, например, OpenRouter — прокси-слой к разным LLM (Claude, GPT, Mistral и др.). Получается, можно не завязываться на одного вендора и переключаться по ситуации.

В итоге картина складывается простая. С одной стороны — инструменты вроде lazydocker, которые экономят время здесь и сейчас. С другой — AI, который пока ещё требует контроля, но уже начинает забирать на себя рутину. Вопрос не в том, заменит или нет, а в том, где именно он реально полезен.

На ближайшие две недели немного выпадаю из онлайна.
Уезжаю в отпуск на Кавказ. Горы, дороги, тишина и попытка хотя бы ненадолго перестать думать про телефонию, Docker, Asterisk и бесконечные логи.

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

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

Съездил на Кавказ и быстро понял: это не отпуск в формате «полежать и отдохнуть». Это когда утром ты идёшь «немного прогуляться», а вечером часы поздравляют тебя с 10 000 шагов, ноги молчат от обиды, а впереди ещё горы, ущелья и дождь с градом.
В статье рассказал про поездку в Кабардино-Балкарию: Нальчик, Чегемское ущелье, Голубые озёра, Эльбрус, Адыр-Су, термальные источники, местные музеи и одну «мистическую шахту», которую специалисты из высокого интернета уже успели записать в работу неандертальцев и инопланетян.
Получился не рекламный тревелог, а честный рассказ: где красиво, где переоценено, где промок, где устал, а где понял, что на Эльбрус без подготовки лезть не надо.
Полная статья здесь:
https://vk.com/@grebenyov-puteshestvie-v-kabardino-balkariu-stranu-chudes

Возвращение из отпуска — это отдельный вид онбординга. Вроде тебя не было всего три недели, а рабочие процессы уже лежат в голове где-то в архиве без индекса. Сидишь, вспоминаешь детали, нюансы, странные договорённости, и постепенно мозг снова начинает загружать рабочую конфигурацию. Кажется, всё вспомнил. По крайней мере, пока ничего критичного не забыл.
Параллельно посмотрел видео «Почему все проваливают алгоритмические собеседования?» https://www.youtube.com/watch?v=u_c3WCpEUzY. И в очередной раз понял простую вещь: алгоритмические собеседования — это не проверка «умный ты или нет», а отдельный навык. Его нужно просто нарабатывать. Поэтому поставил себе цель — решить 100 задач. Минимальный план пока простой: хотя бы одна задача в день.
Это сильно напоминает изучение английского. Сначала кажется, что ты почти всё знаешь, а потом реальность аккуратно бьёт по голове учебником грамматики. Мои первые иллюзии о собственном уровне английского оказались, мягко говоря, завышенными. До B1 я шёл примерно 2–3 года. Алгоритмы по объёму меньше английского, но своих нюансов там хватает, и они тоже не прощают самоуверенности.
Начал проходить LeetCode Explore https://leetcode.com/explore/, там много обучающих блоков. Для старта взял Array and String https://leetcode.com/explore/learn/card/array-and-string/. И довольно быстро выяснилось, что самые коварные задачи часто формулируются в одну строку. Вроде читаешь условие — всё понятно. Потом садишься решать — и внезапно понимаешь, что понятным было только первое предложение.
Например, Diagonal Traverse https://leetcode.com/explore/learn/card/array-and-string/202/introduction-to-2d-array/1167/ — нужно просто обойти матрицу по диагонали. Просто, ага. Без ИИ я не догадался, что у элементов на одной диагонали одинаковая сумма индексов, а каждую чётную диагональ нужно разворачивать при формировании ответа. Формально задача маленькая, но идея в ней спрятана очень аккуратно.
Или Two Sum II - Input array is sorted https://leetcode.com/explore/learn/card/array-and-string/205/introduction-to-2d-array/1153/. Вроде классика: два указателя, отсортированный массив, ищем сумму. Но потом всплывает, что индексы в ответе начинаются с 1, а не с 0. Мелочь, но именно такие мелочи и ломают решение. Так что LeetCode — это отдельный вид искусства, где важно не только решить, но и внимательно прочитать условие.
На работе тоже возникла интересная задача: нужно интегрировать 1С и Asterisk, чтобы менеджеры по продажам могли звонить прямо из 1С. Интеграцию делал через продукт 1С:Рарус https://rarus.ru/. Решение занимательное: ставится софт-прослойка между 1С и Asterisk. К Asterisk он подключается через AMI — Asterisk Manager Interface, а в 1С встраивается в виде расширения.
Про популярные способы интеграции с Asterisk я уже писал в статье «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a. В этот раз теория пригодилась на практике. Вместе с программистом 1С всё настроили: звонки идут туда и обратно. Менеджеры могут звонить из 1С, Asterisk честно отрабатывает свою часть.
Но, как обычно, на слове «готово» история не заканчивается. Звонки уже работают, а вот записи разговоров из 1С пока послушать не удаётся. Значит, дальше будет отдельный слой веселья: пути к файлам, имена записей, AMI-события, права доступа и всё то, что обычно прячется за фразой «осталось только подключить записи». Буду думать дальше.
Итог недели простой: после отпуска мозг перезагрузился не сразу, но запустился. Алгоритмы снова напомнили, что навык появляется только через практику, а рабочая телефония — что любая интеграция почти всегда сложнее, чем выглядит в инструкции. Зато скучно не было. А это уже почти рабочий успех.

На работе возникла задача проверить, безопасен ли код, который пишут наши программисты. Спойлер: нет. И почти сразу появилась «гениальная идея»: давайте внедрим SonarQube, прогоним код через линтер — и всё узнаем.
К сожалению, один линтер не сделает код безопасным. Безопасность приложения — это не одна галочка в CI/CD, а несколько уровней контроля: код, зависимости, Docker-образы, конфигурации, секреты, права доступа и поведение приложения после деплоя.
На уровне кода нужны SAST-инструменты и линтеры. Они помогают находить потенциальные уязвимости ещё до сборки и выката: небезопасную работу с входными данными, SQL-инъекции, XSS, ошибки авторизации и другие проблемные места. Здесь могут пригодиться SonarQube, GitLab SAST, Semgrep.
Отдельно нужно проверять зависимости. Даже если собственный код написан аккуратно, уязвимость может приехать через стороннюю библиотеку. Для этого подходят GitLab Dependency Scanning, OWASP Dependency-Check, Snyk, потому что безопасность ломается не только там, где писал ты сам.
Secret Detection нужен, чтобы не утащить в репозиторий токены, пароли, приватные ключи, API-ключи и другие секреты. Это отдельная боль: один случайно закоммиченный .env или ключ доступа может стоить дороже, чем десяток замечаний от линтера. Для таких проверок можно использовать GitLab Secret Detection, Gitleaks, TruffleHog, detect-secrets, GitGuardian.
Container scanning нужен, чтобы не тащить в production уязвимые базовые образы и системные пакеты. Здесь можно использовать GitLab Container Scanning, Trivy, Grype, Clair, Snyk Container. Отдельная история — DAST: он проверяет уже работающее приложение как «чёрный ящик» и показывает проблемы, которые проявляются только в запущенной системе.
Есть ещё инфраструктурная безопасность: права доступа, сетевые политики, секреты, централизованная авторизация, аудит и мониторинг. Это уже не про один сканер, а про общую дисциплину эксплуатации: кто имеет доступ, где лежат секреты, какие действия логируются и как быстро можно заметить проблему после деплоя.
Вывод простой: линтер — это только первая линия обороны. Нормальная безопасность начинается там, где проверки закрывают весь путь приложения: от кода, зависимостей и секретов до контейнера, инфраструктуры и реального поведения в production. Всё остальное — приятная иллюзия контроля.
Вот хорошие видео на эту тему.
DevSecOps для самых маленьких
https://www.youtube.com/watch?v=jdSyadPFycE
С какого конца начинать безопасную разработку
https://www.youtube.com/watch?v=UHD0q8QW_rM
А теперь немного новостей. У компании Rebrain летом появился формат «Открытый микрофон»: каждый может прийти со своим докладом и выступить на аудиторию. Я подумал: а почему бы и да, у меня же есть статья «Когда связист становится разработчиком, программирование Asterisk на практике» https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a
Я выполнил необходимые требования к спикеру, и мой доклад приняли. Так что 24 июня проведу вебинар на тему статьи. Можно зарегистрироваться здесь: https://rebrainme.com/webinars
Открою тайну: доклад, презентация и демонстрации ещё не готовы. Точнее готовы, но не до конца. Но за две недели я точно их доделаю, потому что инженерная магия обычно начинается сразу после слов «ну тут осталось совсем немного».

Почти всю неделю на работе настраивал SonarQube. Задача из тех, которые сначала выглядят как «ну сейчас быстро подключим», а потом внезапно превращаются в квест с токенами, правами, GitLab и кучей мелких нюансов. Чтобы нормально связать GitLab и SonarQube, нужна туева хуча разных токенов с разными правами. Но я справился.
Сканирование нашего основного проекта занимает примерно 20–30 минут. Важно понимать: SonarQube сканирует весь проект, а не отдельные коммиты. Для проверки коммитов лучше использовать GitLab SAST, но это уже задача на следующую неделю. Один инструмент не закрывает всю безопасность, он просто подсвечивает часть проблем.
Посмотрел результаты сканирования — наш код, мягко говоря, не безопасный. Я даже не думал, что можно допускать такие банальные ошибки, но проект старый, поэтому возможно всё. Хорошая новость в том, что самые критические проблемы уже пофиксили. Плохая — теперь понятно, сколько ещё работы впереди.
По SonarQube рекомендую два видео:
«Никита Грызлов. Мастер-класс. SonarQube. В омут с головой» https://www.youtube.com/watch?v=wFwG8bKuEw4
«Святослав Кокурин из Naumen “Внедряем SonarQube без шума и пыли”» https://www.youtube.com/watch?v=LI36tWHd-Tc
SonarQube — мощная и сложная система промышленного уровня. Если смотрите в сторону DevSecOps, разобраться с ней точно стоит.
В пятницу прилетела ещё одна задача. На проде периодически падают сервисы-консьюмеры, которые обрабатывают очереди RabbitMQ. Только падают они хитро: процессы в системе есть, память и процессор потребляют, вроде бы «работают», но очереди уже не обрабатывают. Формально живые, по факту бесполезные.
Решили реализовать временный костыль. Если количество консьюмеров по очереди становится равно нулю, в Zabbix срабатывает триггер, который запускает скрипт и убивает нужный сервис на проде. Эти сервисы автоматически стартуют каждую минуту, поэтому простой минимальный. Более правильно, конечно, задать программистам вопрос: почему код зависает. Но по собственному опыту знаю: поймать плавающую ошибку, которая возникает раз в несколько дней, — отдельный вид боли.
Bash-скрипт, который убивает сервис по SSH, я написал. Главный вопрос был в другом: как проверить его работу и не устроить пожар на проде. Если специально ронять рабочие службы, меня сожгут где-нибудь между переговоркой и серверной. А Zabbix ещё и выполняет скрипты довольно молча: сработало, не сработало, где упало — разбирайся сам.
В итоге сделал фейковый Item test.trigger, который меняю через команду zabbix_sender -z 127.0.0.1 -s "rabbitmq" -k test.trigger -o 1. К нему привязал тестовый триггер, который запускает мой скрипт. Отладку делал через логи, потому что без логов в таких задачах быстро начинается гадание на кофейной гуще. Когда ошибка больше не нужна, возвращаю всё обратно: zabbix_sender -z 127.0.0.1 -s "rabbitmq" -k test.trigger -o 0.
Получилась вполне рабочая схема: сам создал ошибку, сам её обработал, сам проверил цепочку от Zabbix до скрипта. И главное — на проде ничего ломать не пришлось. Иногда лучший тест — это не героически уронить боевую систему, а спокойно собрать безопасную имитацию проблемы.
Кстати, напоминаю: в следующую среду, 24 июня 2026 года, в 18:00 по МСК, я провожу вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» https://rebrainme.com/webinars/kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-asterisk-na-praktike
Приходите, расскажу про программирование Asterisk, Dialplan, AGI, AMI, ARI и про тот момент, когда обычная телефония внезапно превращается в разработку.

Иногда одна демонстрация на вебинаре превращается в две недели борьбы с окружением, зависимостями и чужими настройками. А одна строка в systemd — в почти недельный квест.
Провёл вебинар «Когда связист становится разработчиком: программирование Asterisk на практике» на Rebrain. И понял одну простую вещь: самое сложное в докладе — не выступление, а всё, что происходит до него.
Тему я заявлял как обзор технологий Asterisk для разработчиков. Планировал рассказать про четыре инструмента: Dialplan, AGI (Asterisk Gateway Interface), AMI (Asterisk Manager Interface) и ARI (Asterisk REST Interface).
Но реальность быстро внесла свои коррективы. Выяснилось, что ARI даже для простого примера требует слишком глубокого погружения. Тратить несколько недель только ради одной демонстрации не хотелось, поэтому пришлось отказаться.
Со всем остальным тоже оказалось не так просто. На работе эти технологии давно функционируют, и я уже не замечаю, насколько большое окружение за ними стоит. Например, для демонстрации AMI понадобился CDR. Начал поднимать всё с нуля — и сразу выяснилось, что «из коробки» оно не работает.
CDR потребовал MySQL. MySQL оказался привязан не к тому интерфейсу. Исправил. Затем выяснилось, что структура базы данных не подходит под мою версию Asterisk. Переделал. Чтобы показать простую функцию — соединить клиента с тем менеджером, с которым он разговаривал ранее, — пришлось буквально перешерстить полобраза Ubuntu.
Потом решил выложить исходники на GitHub. Часть проекта работала в Docker, поэтому пришлось ещё разбираться с GitHub Actions, чтобы автоматически публиковать Docker-образы. Огромный пласт работы, который никто во время вебинара даже не увидит.
И так было практически с каждой демонстрацией. Со стороны кажется: «показать небольшой пример». На практике — две недели настройки, поиска несовместимостей и чтения документации.
В итоге всё заработало. Но появилась другая проблема. Доклад, который я рассчитывал провести за полтора часа, уложился примерно в сорок минут.
На вебинар зарегистрировались 115 человек. Формат был «открытый микрофон»: после выступления можно заполнить анкету с обратной связью.
И тут финальный штрих.
Анкету заполнил... один человек.
Возможно, тема оказалась слишком узкой. Менеджер Rebrain уже предложила выступить ещё раз в августе. Похоже, в следующий раз придётся выбирать что-то более массовое. Узкоспециализированные темы интересны далеко не всем.

На работе тоже приключение.
Написал скрипт. Всё работает, но он пишет логи. Если ничего с ними не делать, через какое-то время они разрастутся до гигабайтов и благополучно съедят всё свободное место. Логичное решение — настроить logrotate. Только вот логи почему-то не ротируются.
logrotate падал с ошибкой:

Файловая система доступна только для чтения

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

systemctl cat logrotate.service

ProtectSystem=full

то выясняется, что systemd запускает logrotate в режиме, где каталоги /usr, /boot и /etc доступны только для чтения. А мой лог как раз лежал внутри /usr/local/....
Решение оказалось элементарным:

systemctl edit logrotate.service

[Service]
ReadWritePaths=/usr/local/scripts

Пять минут на исправление.
И почти неделя на поиск причины.
Если вам кажется, что какая-то задача простая, скорее всего, вы просто ещё не начали её делать.
Обе истории показывают, что в IT самая сложная часть часто скрыта за самой обычной задачей. То, что выглядит как быстрый пример или простая настройка, на деле может обернуться неделями подготовки и поиска неочевидной причины. Поэтому к любому «это же быстро» лучше сразу относиться с долей скепсиса.

На работе возникла задача: посчитать количество минут переговоров отдела продаж и сервиса. Казалось бы, что может пойти не так? Ответ: всё.
Все записи разговоров у нас хранятся в одной папке, файлов там тысячи, очень много тысяч. Я написал bash-скрипт, который в 12 потоков перебирает записи, определяет длительность, вытаскивает дату и пытается понять, кто кому звонил. Первый этап прошёл относительно бодро: машина шумит, скрипт работает, файлы считаются — красота.
Дальше нужно было выделить из этого океана звонков продажи и сервис. Я вспомнил, что у нас же есть адресная книга: достаточно взять оттуда номера нужных отделов, скрестить со звонками — и готово. Наивный оптимистичный человек.
Адресная книга у нас в Bitrix24, но не просто адресная книга, а какой-то встроенный сайт в iframe, который, судя по всему, проектировали в состоянии творческого безумия: экспортировать нормально нельзя, копировать удобно нельзя, жить с этим тоже нельзя. Решил сделать скриншот.
Скриншот получился длинный, очень длинный: сотрудников много, страданий тоже. Скормил скриншот ChatGPT, она посмотрела на это произведение корпоративного UX и бодро сказала, что такое не распознаётся. Ладно.
Режем длинный JPG на куски и собираем PDF:

magick input.jpg -crop x3000 +repage page_%03d.jpg
magick page_*.jpg output.pdf

PDF распознал через FineReader, он превратил результат в DOCX. Но DOCX ChatGPT ест плохо, зато Markdown — уже гораздо бодрее. Конвертируем:

pandoc /mnt/d/Телефоны.docx -t gfm -o phones.md

Телефонная книга была устроена примерно так: «Продажи»\ 101 Иванов\ 102 Петров. А мне нужно было: 101 Продажи\ 102 Продажи, то есть вместо фамилии — название отдела. Тут ChatGPT наконец-то сказала: «Вот теперь нормально, работаем» — и сделала нужное преобразование.
Дальше я скрестил распознанную телефонную книгу со списком звонков через сводную таблицу в Excel, и тут барабанная дробь: больше всех в организации звонит отдел «Прочее». Мощный отдел, сильная команда — никто их не видел, но звонят они больше всех.
Начал разбираться. Оказалось, что отделов продаж у нас не один: кто-то работает с юрлицами, кто-то с ИП, кто-то с отдельными направлениями, а в отчёте всё это нужно видеть укрупнённо. Потом выяснилось, что адресная книга не соответствует реальности: кто-то уволился, кого-то приняли, номера переехали, часть сотрудников живёт в системе как археологический слой.
Пошёл вручную актуализировать телефоны менеджеров по продажам в Bitrix24, добавил уволенных, потому что старые звонки тоже должны попадать в отчёт. Количество «Прочего» уменьшилось, но не сдалось.
Потом выяснилось, что имя телефона не всегда соответствует человеку: условно, телефон когда-то был закреплён за Ивановым, Иванов ушёл, пришёл Петров, а телефон всё ещё называется «Иванов». Петров работает, Иванов звонит — всё логично.
Затем руководитель задал очень правильный вопрос: — А где менеджеры по продажам московского офиса? Их не было вообще. Оказалось, что они работают с корпоративных SIM-карт, то есть в нашей красивой статистике по АТС их звонков просто нет. Теперь на следующей неделе буду созваниваться с оператором связи и выяснять, как настроить запись звонков с корпоративных SIM-карт.
Но и это был не финал. Оказалось, что звонки сервисных инженеров из-за особенностей нашей корпоративной системы пишутся в отдельную папку, конечно же. Снова запускаю сканер в 12 потоков, теперь уже по этой папке — маразм крепчал, еноты пели.
Потом нашёлся ещё большой пласт автоматических звонков от корпоративной системы, они тоже попадали в общую статистику и делали вид, что являются полезной человеческой активностью. В итоге только с третьей или четвёртой попытки удалось свести всё воедино.
Вывод простой: задача «просто посчитать минуты разговоров» легко превращается в археологическую экспедицию по корпоративным данным, где каждый новый слой отвечает на один вопрос и задаёт три новых. Прогулка по граблям с завязанными глазами удалась.

Кажется, компьютерное зрение — это просто: показал ИИ фотографию и получил готовый инженерный отчёт. На практике между фотографией и отчётом внезапно вырастает небольшой конвейер из трёх агентов, чистки данных, проверок и 53 страниц документации. Потому что за каждой «простой» задачей обычно скрывается целая система обязательных шагов.
На работе возникла задача: есть фотография со списком ошибок, по которым нужно найти описания и подготовить инженерный отчёт по устранению. Думаете, ИИ увидит фотографию и сразу выдаст правильный результат одним промптом? Вот чтобы да — так таки совсем даже нет. ИИ хорошо выполняет ровно одно действие, поэтому задачу пришлось разбирать на отдельные этапы.
Сначала первый агент распознаёт фотографию и возвращает одну длинную строку текста. Эту строку нужно почистить от лишних пробелов, переносов, непечатных символов и прочего мусора. Мусор на входе, мусор на выходе — магии не произошло. Только после этого результат можно передавать следующему агенту.
Второй агент выполняет классификацию и превращает строку в JSON: выделяет дату, коды ошибок и остальные данные. Иногда в поле даты внезапно появляются значения из XIX века — видимо, ИИ решил, что мы работаем с архивами времён паровых машин. Но результат снова приходится проверять и чистить, потому что 0 и D, l и 1 выглядят слишком похоже. Код ошибки может казаться правильным, но при этом не существовать в принципе. Затем убираем дубли, выбираем последние ошибки и применяем остальные правила обработки.
И только третий агент получает проверенные коды и пишет инженерный отчёт. Разной степени фэнтезийности, поэтому его результат тоже нельзя принимать на веру. В итоге простая задача превращается в мультиагентную систему из трёх агентов. Хорошо хоть без общей памяти, иначе приключение стало бы ещё интереснее.
Дополнительно вся система должна работать в четыре потока. На этой неделе я в основном писал документацию со всеми ошибками, исключениями и частными случаями — получилось 53 страницы. По собственному опыту знаю: программируешь обработку редкой ошибки, которая, как тебе кажется, должна происходить раз в тысячу лет. На проде она встречается пару раз в день, и возникает немой вопрос: «Как?»
Есть замечательное видео «Как AI помогает запускать стартапы: вайбкодинг, OpenClaw и ограничения для бизнеса» https://www.youtube.com/watch?v=kQAWgM_b0XI. Разработчик написал ИИ-сервис: загружаешь фотографию с телефона и получаешь готовое фото на паспорт или визу. Вроде бы банальная задача — убрать фон. Но фотография должна соответствовать уйме бюрократических требований, причём для каждой страны они разные, и простая идея снова превращается в задачу со звёздочкой.
В четверг был на встрече тюменских IT-шников, в том числе обсуждали резюме. Вспомнили старое резюме одного матёрого айтишника: текущее место работы — гардероб, хобби — женский баскетбол в качестве зрителя. С лёгкой долей абсурда, но зато запоминается. Я понял, что определённо что-то в этой жизни упустил.
В общем, ИИ действительно умеет распознавать фотографии и писать отчёты. Нужно только построить вокруг него систему из агентов, фильтров, проверок, многопоточности и документации на 53 страницы. А так — всё просто.

Неделя получилась неожиданно насыщенной. Большую часть времени разбирался с сервисом обработки чеков: где-то боролся с ограничениями ChatGPT, где-то ловил совсем неожиданные баги в OCR, а заодно успел немного повоевать со спамерами в Telegram.
На работе продолжаю делать микросервис для обработки чеков с ошибками. В качестве LLM использую ChatGPT и Codex. В целом всё отлично, но периодически упираюсь в лимиты тарифа за $20. Оказалось, проблема далеко не только у меня. Решение нашлось простое: купить второй аккаунт и переключаться между ними через codex-auth — https://github.com/loongphy/codex-auth. По сути, утилита просто подменяет файл auth.json с текущим токеном ChatGPT. Мелочь, а экономит нервы.
Параллельно разбирался с безопасностью загрузки изображений. Обрабатываю фотографии чеков, и нейросеть настоятельно рекомендовала проверять файл не только по расширению, но и по сигнатуре. Решил разобраться, зачем это нужно. Оказалось, это вполне распространённая атака: под видом JPG можно прислать исполняемый файл или другой вредоносный контент. Поэтому доверять файлам из интернета только потому, что они заканчиваются на .jpg, точно не стоит.
Потом решил проверить систему на нестандартных данных. Вместо фотографии чека отправил... фотографию котика. Казалось бы, сервис должен быстро ответить: «Это не чек». Но вместо этого он ушёл в глубокие раздумья.
Начал разбираться. Сначала выяснилось, что таймаут распознавания по умолчанию — десять минут. А с тремя попытками ожидание легко превращалось в полчаса. Сократил время до минуты. Но ошибка всё равно не возвращалась.
Следующая находка оказалась интереснее. Сообщение с ошибкой уходило не в очередь результатов, а в DLQ (Dead Letter Queue — очередь сообщений, которые не удалось обработать). А ведь DLQ предназначена для незапланированных серьёзных сбоев, а не для ситуации «пользователь прислал не тот документ». Исправил маршрутизацию.
И тут появился ещё один сюрприз. OCR каким-то образом сумел извлечь из фотографии котика 42 байта текста. До сих пор не понимаю, что именно он там увидел. В итоге пришлось добавить ещё один уровень проверки: если после OCR получается бессмысленный набор символов, данные отправляются на классификатор, который уже принимает решение, похож ли результат на настоящий чек.
В итоге понял простую вещь. Если пользователь прислал ерунду, корректно сообщить ему, что это именно ерунда, зачастую сложнее, чем обработать правильный документ. Именно такие пограничные случаи обычно и отнимают больше всего времени.
Ещё одна неожиданная история произошла с Telegram-каналом. За несколько дней туда набежало больше десяти тысяч ботов. Очень много аккаунтов с арабскими и китайскими именами. Для защиты поставил Lols Anti Spam (@LolsBot) и несколько дней методично чистил подписчиков. В итоге количество сократилось примерно до тысячи.
Ради интереса посмотрел, что именно блокировал бот. В основном это были предложения лёгкого заработка, крипта, займы и прочие «уникальные возможности». Поэтому небольшое напоминание.
Прежде чем кликнуть по очередной ссылке с обещанием быстрого богатства, задайте себе простой вопрос: почему совершенно незнакомый человек хочет сделать богаче именно вас? Скорее всего, заработать собирается он, а платить будете вы.
По моему опыту, 99,99% подобных схем — обычный обман.
И сразу отвечу на возможный вопрос. Мой канал — это просто дневник IT-инженера. Здесь нет розыгрышей, криптосхем, инвестиционных советов или предложений «заработать миллион за вечер». Только реальные рабочие задачи, технологии и инженерные находки.
Как говорил Козьма Прутков: «Бди!»