ИИ не пишет стартапы на миллион. Он забирает скучную работу.

Посмотрел видео «Как изменится разработка с приходом ИИ» https://vk.com/video-163338141_456239886 — и оно слишком точно попало в мои мысли.
Владилен Минин разбирает разработку как цикл: анализ → дизайн → разработка → тестирование → деплой → поддержка. ИИ уже уверенно сидит в разработке и тестировании, но магии не случилось. Запрос уровня «сделай мне AI‑стартап на миллион в день без ошибок» остаётся фантазией. Рабочий вопрос проще: могу ли я отдать это джуну? Если да — это работа для AI‑агента. Всё остальное пока остаётся за человеком.
С языками ровно та же история. Новые не убили старые, и ИИ их тоже не убьёт. Там, где нужен C — будет C, где Java — будет Java. Просто появится ещё один инструмент в стеке. Пузырь это или нет — не так важно. Даже если пузырь, он слишком жирный, чтобы исчезнуть: датацентры с видеокартами никуда не денутся, просто займут своё место.

Параллельно продолжаю делать HTML5‑игру для Telegram «Memento mori». Вот сайт проекта https://mementus.ru/, а вот бот https://t.me/memento_mori_game_bot. Игра уже процентов на 90 готова, в неё можно играть. Осталось довести лендинг и прикрутить мониторинг — и будет законченный продукт, а не вечный «ещё чуть-чуть».

Отдельное приключение — звуки. С картинками было проще. Нужно было найти звук переворачивающейся карты — решил сгенерировать через нейросети. ChatGPT выдал «мелодию» из одной ноты. После десятка попыток стало ясно: это уровень школьника с синтезатором на первом уроке. Подключил SUNO https://suno.com/ — получил трек на 3,5 минуты с мужским вокалом про переворачивание карты. Ну почти.
В итоге всё решилось через https://freesound.org/. Но и там свой цирк — я просто искал фанфары. Обычные, оркестровые, с трубами. А нашёл фанфары на ксилофоне, с криком петуха, в стиле аниме. Отдельный жанр — «композиторы», которые берут нормальную мелодию и мешают туда всё подряд. Найти нормальные фанфары оказалось задачей со звёздочкой. Нашёл. Остальное — техника: выровнять громкость, обрезать хвосты, привести форматы.

С Phaser тоже было весело. Абсолютное позиционирование — это боль. Простая задача: на десктопе 4 кнопки в ряд, на мобилке — 2×2. Во фронте это несколько строк. Здесь — функция с перерасчётом координат, куча арифметики ради четырёх кнопок. И это хороший пример того, как «игровой движок решает всё» — не совсем правда.

Когда начинал писать игру, думал, что буду в основном работать с движком и визуалом. По факту он закрывает только UI: отрисовка, ввод, взаимодействие. Всё остальное — бекенд, бизнес-логика на ООП, графика, devops — съедает львиную долю времени. Сам движок занял процентов десять от всей работы. Такой вот геймдев.

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

В итоге всё упирается не в инструменты, а в задачи: ИИ закрывает рутину, но думать и собирать систему по-прежнему приходится самому. И чем дальше, тем больше становится видно, где заканчивается «магия» и начинается обычная работа.

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

На работе прилетела задача: распознавание и классификация информационных чеков банкоматов. Нужно понять — есть ли смысл вообще лезть в Yandex AI Studio. Я думал, что проблема — распознать чек. Ошибся. Сначала кажется — ну что там, распознать чек. Потом понимаешь, что чек — это вообще не главное. Архитектура выглядела просто: сканируем папку с изображениями, гоним через Gemma 3 для OCR, потом через Qwen3 вытаскиваем структуру и сохраняем в JSON. Всё это на базе Yandex AI Studio.
Я написал спецификацию, показал коллеге. Линейный пайплайн одобрили. Дальше — реальность. Модель внезапно начала плохо распознавать чеки. И тут вскрылась простая вещь: нельзя пытаться распознавать чек прямо на фотографии банкомата. Рабочая стратегия — сначала вырезать сам чек, потом почистить изображение, и только потом отдавать в OCR. Иначе мусор на входе — мусор на выходе.
После OCR тоже не сказка. Текст «грязный» почти всегда. Поэтому минимум:
— убираем лишние пробелы
— нормализуем переносы
Всё выглядит аккуратно на схеме, пока не начинаешь это реально делать.

Вот эти видео действительно полезные:
Yandex AI Studio Series https://www.youtube.com/playlist?list=PL1x4ET76A10aeW4WyNRZXd0cyTvCbThKO
Воркшоп “Как создать мультиагентную систему в Yandex AI Studio” https://www.youtube.com/watch?v=Iyf17k0Hf2M&t=1484s

Параллельно закрыл свою давнюю историю — допилил игру.
Сайт: https://mementus.ru/ Бот: https://t.me/memento_mori_game_bot

В голове всё выглядело просто: изучил Phaser, подключил ИИ — и поехали. На практике оказалось, что кодинг — это максимум половина задачи. Всё остальное: бизнес-логика, графика, звук, DevOps. ИИ в этом помогает, но очень неровно.
Самая неприятная часть — без нормальной спецификации ИИ начинает «фантазировать». Вместо pet-проекта предлагает архитектуру уровня Яндекса с многоуровневыми кэшами и горизонтальным масштабированием на сотни серверов. Пока сам не структурируешь задачу — толку не будет.
Вывод простой: чтобы ИИ дал нормальный результат, нужно самому знать хотя бы половину ответа. А лучше — процентов 70. Он отлично закрывает задачи уровня джуна. Всё, что сложнее — начинает плыть.
Отдельно зашла идея с субагентами: один планирует, второй пишет, третий проверяет. Потому что код может запускаться и «работать», но при этом быть дырявым по безопасности.
С графикой тоже иллюзии быстро закончились. Наброски — ок. Финал — нет. На одной картинке вместо «Кубки» получилось «Кувки», и исправить это ИИ не смог. В итоге часть правок делал руками в Photoshop. Со звуком ещё хуже: песню генерит легко, а вот нормальный звук переворота карты — это уже квест.
Phaser тоже быстро расставил всё по местам. Это не «магия геймдева», а по сути UI-движок: загрузка ресурсов, обработка кликов, анимации, физика. Вся логика — на тебе. Нажал на карту — а дальше куча состояний и правил, которые ты сам описываешь через ООП.
И да, 2D — это ещё цветочки. В 3D надо уже рисовать модели, анимировать, работать со светом и текстурами. Там совсем другой уровень боли.
По итогу: на сам движок ушло процентов 10 работы. Остальное — инфраструктура, логика и куча мелких решений, о которых даже не думаешь в начале.
Параллельно изучал сразу четыре технологии: NextJS, Phaser, Angie и Claude AI. Тяжело. Очень.
В итоге закрыл детскую мечту — сделал свою игру. Детские мечты должны умирать в детстве. Посмотрел на геймдев изнутри и понял: это отдельная вселенная. Пока не моя.

Написал статью "Когда связист становится разработчиком, программирование Asterisk на практике", где обобщил свой опыт разработки под Asterisk:
https://vk.com/@programmer_path-kogda-svyazist-stanovitsya-razrabotchikom-programmirovanie-a

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

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

Неделя ушла на борьбу с одной, казалось бы, простой вещью — чеками банкоматов. На бумаге всё выглядит тривиально: есть код ошибки, его надо распознать и сохранить. В реальности OCR спокойно превращает 6 в 0, 5 в S и делает из фиксированного кода какой-то криптографический ребус, который потом нужно как-то интерпретировать.

Кодов ошибок банкоматов оказалось около 20 тысяч, но плюс в том, что они фиксированы. Я просто сложил их все в PostgreSQL и пошёл от обратного: не доверять OCR, а искать ближайшее совпадение. Беру распознанный код и через нечёткий поиск + расстояние Левенштейна нахожу то, что он «хотел сказать».

Нечёткий поиск — это способ находить строки, которые похожи, а не полностью совпадают с запросом (например, с опечатками или разным написанием).
В PostgreSQL он реализуется через метрики сходства similarity и позволяет искать «ближайшие» совпадения вместо точных.
Есть расстояние Левенштейна — это метрика, которая показывает, сколько минимальных операций (вставка, удаление, замена символа) нужно, чтобы превратить одну строку в другую.

Сначала фильтр по similarity, потом сортировка по расстоянию — и на выходе наиболее вероятный вариант.

SELECT code, levenshtein(code, '526D6O0') AS dist
FROM atm_error_codes
WHERE similarity(code, '526D6O0') > 0.3
ORDER BY dist ASC
LIMIT 1;

Фактически этим запросом я закрываю 1–2 ошибки распознавания без отдельной логики. OCR ошибся — база поправила. Никакой магии, просто аккуратно использованные инструменты. Похожий подход, кстати, используется и в FineReader.

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

Отдельный цирк был с AI-агентом. Сломалась сборка из-за библиотеки figlet, и «умное» решение оказалось простым: удалить библиотеку и захардкодить ascii-арт. Логика железная. Пришлось руками дожимать до нормального решения и заменить на cfonts. В очередной раз убедился: AI отлично ускоряет, но мусора генерирует не меньше.

В итоге для CLI-интерфейса взял @clack/prompts https://www.npmjs.com/package/@clack/prompts — неожиданно аккуратная библиотека. Минимум лишнего, всё работает как надо.

Чем дальше копаюсь в таких задачах, тем яснее вижу: проблема редко в «сложной технологии». Обычно всё ломается на стыке — OCR, данные, логика. И вот там уже начинается настоящая работа.

Хотел просто переименовать файлы — получил счёт на тысячу рублей.

Начал делать CLI-утилиту smart-renamer https://github.com/orion55/smart-renamer — автоматическое переименование медиафайлов с переводом названий на русский через YandexGPT. На входе обычный «зоопарк» скачанных файлов вроде:

The.Walking.Dead.S05E03.720p.BluRay.x264-DEMAND.mkv
Game.of.Thrones.2011.S01E01.WEB-DL.1080p.mkv
Pochuvstvuj.moj.golos.2026.NF.WEB-DLRip.AVC/

На выходе хочется получить что-то человеческое:

Ходячие мертвецы/0503.mkv
Игра престолов/01.mkv
Почувствуй мой голос.mkv

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

Сначала попробовал через Яндекс.Переводчик. На выходе получается полная дичь. Английские и русские названия фильмов живут своей жизнью и редко совпадают. Решил пойти «умнее» — подключить AI. Написал жирный промпт, добавил логику «если не знаешь — сходи в интернет», взял YandexGPT 5.1 Pro, включил многопоточность, ретраи — всё как положено.

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

В итоге выкинул всё это великолепие и поставил более простую модель Alice AI LLM. И внезапно всё заработало: без интернета, без ретраев, без параллелизма. Просто возвращает нужные названия. Вывод банальный, но неприятный: «умнее» не значит «лучше», особенно когда платишь за каждый токен.

Отдельный бонус — код от Claude. Поймал странный баг: функция ничего не возвращает, хотя должна. Начал разбираться — а там тихо мутируется исходный массив. Та самая классика с тихими, почти невидимыми side-эффектами. По факту — глупая новичковая ошибка: не уследил за мутацией и сам себе сломал логику. Та самая ситуация, где «всё вроде правильно», но не работает. Когда ткнул в это ИИ носом — исправилось. А если бы не ткнул?

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

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

На работе делаю упрощённую внутреннюю админку для телефонии и решил активно подключить ИИ. В какой-то момент отпустил контроль — и на простое приложение для 2–3 админов внезапно была реализована двухуровневая аутентификация. При том, что логина и пароля там более чем достаточно. Хорошее напоминание: ИИ ускоряет, но думать за тебя не будет.

С дизайном история вышла не менее показательная. Решил «пусть сам предложит концепт» — и получил: «Signal Console», тёмная панель в стиле профессиональных коммутаторов, монохромный шрифт, LED‑индикаторы, кислотный циан. Звучит красиво, но по факту это просто внутренняя админка. Киберпанк там лишний.

С фронтендом ещё веселее. ИИ решил не использовать готовые библиотеки и начал писать всё с нуля, включая таблицу со сортировками, фильтрацией и пагинацией. Уже проходил это на проекте — через спринт такие идеи умирают. Пришлось аккуратно объяснять, что «изобретать таблицу» — путь в никуда.

Параллельно решил перейти с npm на pnpm. Разница простая: npm тащит зависимости прямо в проект и дублирует их, из-за чего всё разрастается. pnpm хранит пакеты глобально и подсовывает их через hard links — быстрее и заметно экономит место. Пока разбираюсь, но подход выглядит разумнее.

Начал читать «Грокаем машинное обучение» Луиса Серрано. Книга заявлена как «для самых маленьких», без сложной математики и с простым Python. Но даже так читается тяжело. А если открыть приложение с формулами — производные, интегралы — становится понятно, где заканчивается «игра с ИИ» и начинается настоящее машинное обучение.

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

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

На работе довёл до конца упрощённую внутреннюю админку для телефонии. Заодно аккуратно дожал 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 и про тот момент, когда обычная телефония внезапно превращается в разработку.