Неделя пролетела как одно мгновение — вроде только началась, а уже пятница. Планы, как обычно, были грандиозные, а реальность внесла свои правки. В итоге получилось много мелких побед, немного философии и целая россыпь новых идей — от телефонии до Prometheus и ИИ.

Возился с телефонией. Общался с менеджерами «Билайна» по поводу фантазий и иллюзий о будущем нашей телефонии. Уйти от 50 транков, всё объединить, настроить в 2 канала: основной и резервный. Фантазии — это, конечно, хорошо, но есть территориальные коммутаторы, региональные счета, разделение на кабельную и мобильную связь и т. д. В общем, каналов будет больше, чем два, но не 50, что тоже хорошо.
Читал логи по дозвонам на заблокированные линии, которые планируем отключить. У нас какие-то странные клиенты: вечером звонят на отключенные линии, слушают отбивку и звонят ещё раз пять-семь. А вдруг робот ответит иначе?

Закончил мини-курс по Prometheus. Prometheus — это аналог Zabbix, собирает метрики, рисует графики, шлёт сообщения по триггерам, если что-то работает не так. Более свежая версия, написанная на Go.
Prometheus мне понравился больше, чем Zabbix. По факту это набор кубиков, главное их правильно вместе соединить. У Zabbix по умолчанию есть всё, 90% этого всего не используется в принципе.
По курсу осталось последнее задание: поднять в Docker блог на WordPress и его промониторить. Мониторить надо хостовую машину, Docker, базу данных, само приложение, я хочу ещё добавить сбор логов. Построить графики и настроить аллерты в Telegram.
Логика работы с Prometheus следующая. В первую очередь вы устанавливаете prometheus как центральный сервер мониторинга. После этого вы ищете у себя все операционные системы, железки, сервисы и приложения, для которых устанавливаете свои экспортеры и подключаете их к prometheus. Затем вы устанавливаете Grafana, подключаете ее к prometheus и на grafana.com ищете уже готовые стандартные dashboards для ваших экспортеров. Вуаля! У вас готовые графики по всем компонентам вашей системы! Затем настраиваете триггеры и пересылку событий триггеров в разные каналы: от почты до Telegram.

Кстати, насчёт своего блога https://infoblog72.ru/ я его решил удалить, его никто не читает. Продолжу вести блог в Telegram и VK.

Потихоньку «щупаю» ИИ. Понравилось видео по Claude «Claude code: полный гайд по разработке с ИИ-агентом» https://www.youtube.com/watch?v=PwtfglP241c. Что понравилось: ИИ-агент отдельно, IDE отдельно. Пишешь, что хочешь получить, а он правит файлы. А то все интеграции с Visual Studio Code (Cursor, WindSurf и т. д.) ну сильно мне не нравятся.
Я всё думал, что мне напоминает работа с ИИ, и понял: это декларативный язык программирования. Вроде SQL или Prolog. Надо описать, что ты хочешь получить в результате, и он это сделает. Хорошо или плохо — другой вопрос.

Продолжаю реализовывать мечту о написании CI/CD для моего бота. Хоть я и бота сдал и задачу закрыл, но хочется сделать всё грамотно. Просто у начальства аппетит приходит во время еды, и я чувствую, моего бота ждут ещё уйма изменений, но с пометками «Важно», «Срочно», «Немедленно». Будет не до CI/CD. Но я уже добился успеха, контейнер с моим ботом попал в Container Registry (Harbor). 26 попытка заливки образа была успешная.

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

У меня выдался насыщенный технический период: одновременно дорабатываю CI/CD, экспериментирую с Docker и Kubernetes, пишу скрипты под Zabbix, настраиваю мониторинг и разбираюсь с очередными сюрпризами от операторов связи. Разнообразие задач огромное, но именно благодаря этому появляется цельная картина и ощущение серьёзного прогресса.

Всё-таки доделал CI/CD на моём чат-боте, но в полуавтоматическом режиме.
Т. к. я работаю над этим проектом один, то я сразу коммичу в main. И не все коммиты предполагают законченный релиз, это могут просто наработки за день.
Поэтому я сделал так: pipeline на создание образов запускаю в ручном режиме. Эта задача создаёт образы и помещает их в registry harbor. А затем я на production вытягиваю образы из registry также в ручном режиме. Хотя по факту это одна команда. Меня такая автоматизация устраивает, не буду автоматизировать всё и вся.
При реализации была ещё была одна проблема. Docker Compose по умолчанию ищет .env в том же каталоге, где лежит docker-compose.yml. А у меня .env лежит в каталоге ./docker/. Поэтому, чтобы не плодить копии, я сделал симлинк: ln -s ./docker/.env .env. Простое, но эффективное решение.

На прошлой неделе я программировал под Zabbix. Необходимо было написать JS-скрипт, чтобы оповещение о проблеме приходило в канал Bitrix24. К сожалению, Zabbix поддерживает только JS версии ES5. По факту надо было собрать данные, их обработать и создать POST-запрос в Bitrix24. С этим я справился. Вот документация https://www.zabbix.com/documentation/6.4/ru/manual/config/items/preprocessing/javascript/javascript_objects, где только JavaScript не встроена.

Смотрю курс «Вечерняя школа Слёрм по Кубернетес» https://www.youtube.com/playlist?list=PL8D2P0ruohOA4Y9LQoTttfSgsRwUGWpu6 и понял, что курс, который я смотрел первоначально, ну совсем базовый. Узнаю уйму нового. Самое интересное, они тоже изначально сообщили, что этот курс тоже базовый, есть более углублённый (и дорогой).
Посмотрел блок, связанный с кластером, там k8s поднимают в кластере 50–100 узлов, и этот кластер считается небольшим. В нашей фирме кластер будет микроскопическим.
Почитал статью «Kubernetes: шпаргалка для собеседования» https://habr.com/ru/companies/gazprombank/articles/788978/ и понял, что очень и очень многого в k8s не знаю. Но в распределённых системах просто и быстро не получится, но я обязательно разберусь.

Меня умиляют мои коллеги. Провожу оптимизацию номерной ёмкости компании. У нас более 70 номеров у 5 операторов связи. Большая часть не используется. Часть номеров запланировано на отключение. Но прежде чем номер отключить, я устанавливаю на этот номер отбивку «Обслуживание данной линии не осуществляется» и скрипт, который записывает, кто на эту линию звонит. Скрипт просто в csv-файл пишет. Проходит 2–3 недели, и коллеги начинают узнавать, а что им клиенты не могут дозвониться, так как линия не работает. По ряду номеров включил всё обратно. У коллег клиенты не могут дозвониться, и им хорошо.

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

Закончил мини-курс по Prometheus. Вроде всё просто и понятно. Но начал делать финальную работу — мониторинг сервера с Wordpress, и оказалось Prometheus не такой и простой, особенно в docker. И есть несколько подходов решения одной и той же задачи. Но я справился, я с сервера с Wordpress собираю логи, метрики хоста, docker, mysql. Строю красивые графики, и при неполадках посылаются сообщения в Telegram. Вот репозиторий https://github.com/orion55/prometheus (2 сервера в одном).
Очень помогли видео «Подключаем мониторинг и логирование» https://www.youtube.com/watch?v=2tFKT4wmiZI. Из него я узнал, что существуют плагины для Docker. Например, плагин для loki docker plugin install grafana/loki-docker-driver --alias loki --grant-all-permissions. Но в новой версии docker он не работает. И это тоже хорошее видео «Мониторинг и логи продакшен уровня — grafana + loki + prometheus + promtail» https://www.youtube.com/watch?v=2JIyHNskK-c.

В общем, движуха продолжается: то я ковыряю CI/CD, то общаюсь с капризными операторами, то разбираю новые схемы в k8s и Prometheus. Местами непросто, местами забавно, но главное — я реально расту и расширяю кругозор. Чем больше погружаюсь, тем отчетливее понимаю, что иду в правильном направлении и набираю хороший темп.

Эта неделя прошла под знаком постоянных доработок и новых открытий. Чат-бот, телефония, Kubernetes — всё смешалось в один рабочий поток, и я решил пройтись по каждому направлению, довести до ума, что давно откладывал, и заодно разобраться в том, что давно хотел понять.

Я дорабатывал своего чат-бота, который события о пропущенных телефонных звонках отправляет в Bitrix24. Коллега указал на одну проблему: бот «торчит» в интернет своим API, и любой желающий может отправить всякую «хрень» в чат Битрикса. Не то чтобы это просто и очевидно, но было бы желание. Поэтому я решил добавить аутентификацию между сервисами. Почитал в интернете, видов аутентификации вагон и маленькая тележка: JWT, SSO, OpenID, HMAC. Пообщался с коллегой-программистом, он сказал, не нужно усложнять, поэтому я реализовал аутентификацию по API Key.
Я командой openssl rand -hex 32 сгенерировал ключ и положил его в файл .env.
И к каждому POST-запросу на сервере телефонии добавил заголовок X-Internal-Token с этим ключом, а сервер проверяет, правильный он или нет. Простая защита лучше, чем никакой.

Продолжил изучать Кубернетес по плейлисту «Вечерняя школа Слёрм по Кубернетес» https://www.youtube.com/playlist?list=PL9G8hWz_wWFPWzxp1YIweOdNW9AD1TARy. У Kubernetes (k8s) есть занимательный механизм Taints and Tolerations.
Taints помечают узлы «нежелательными» для большинства подов: к ним нельзя назначаться без специальных условий. Каждый taint имеет ключ, значение и эффект (NoSchedule, PreferNoSchedule, NoExecute).
Tolerations добавляются в под и разрешают ему игнорировать конкретные taints.
Так достигается изоляция, специализированные узлы и предсказуемое размещение.
Это хитрый фильтр, на определённые узлы можно разместить определённые поды, например Nginx или базу данных.
Механизм RBAC (Role-based access control) я так и не понял, что-то сильно перемудрили с ролями и правами.
Всё хорошо, но этот курс я смотреть больше не буду, он сильно теоретический, преподаватель что-то объясняет, что-то показывает. А вот чтобы это самому это воспроизвести, нужных файлов и инфраструктуры нет.
Решил изучить курс «Kubernetes База» тоже от Слёрм. В нём упор делается именно на многонодовую конфигурацию. Просто пока Кубернетес на одном компьютере, всё просто и понятно, но вот когда компьютеров хотя бы десяток, начинается полная дичь. Особенно если несколько то отключаются, то включаются.
Поэтому дальше сосредотачиваюсь на курсе с практикой, чтобы собрать полноценный кластер и понять, как Kubernetes ведёт себя в боевых условиях.

Эта неделя снова показала: чем глубже копаюсь в инфраструктуре, тем яснее становится общая картина. Где-то подтянул безопасность, где-то разобрался в механизмах Kubernetes, и снова появился азарт двигаться дальше. Продолжу строить свой стек, шаг за шагом превращая хаос в рабочую систему, которой можно доверять.

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

На работе возникла интересная задача: необходимо передавать записи звонков для речевой аналитики в систему распознавания речи. Всё хорошо, но этой AI-системе не нравится смешение голосов. Но для каждого звонка может быть подготовлен единый стереофайл, в котором левый канал содержит речь клиента, а правый канал — речь оператора.
Техническая реализация возможна это возможно следующим образом: сначала в Asterisk записываются две монодорожки — направление к клиенту (-out.wav) и направление от клиента (-in.wav). Затем по завершении звонка эти файлы объединяются в один стереофайл с помощью внешнего скрипта на базе sox или ffmpeg. После этого готовый файл может быть передан в систему анализа речи. Но в каком конкретно формате и куда передавать, я ещё буду разбираться.

Продолжаю изучать Haskell. Наткнулся на книгу «О Haskell по-человечески» https://www.ohaskell.guide/. Haskell стоит на трёх китах, имена которым: функция, тип и класс типов. Они же, в свою очередь, покоятся на огромной черепахе, имя которой — выражение.
Сразу начинает ломаться мозг. Переменных нет, циклов нет. Точнее есть, но иные. Вместо переменных константы, значения в которые прибиты гвоздями навсегда. Если надо что-то изменить, необходимо создать новую константу. Циклов нет, но есть рекурсия. При обработке списков мне понравилась ассоциация с змеёй. У каждого списка, как у змеи, есть голова head (первый элемент) и хвост tail (всё остальное). Вот так можно подсчитать сумму списка.

sumList :: [Int] -> Int
sumList [] = 0
sumList xs = head xs + sumList (tail xs)

main :: IO ()
main = print (sumList [1,2,3])

Но можно это же записать и через префиксную форму sumList xs = (+) (head xs) (sumList (tail xs)).
Почти все ASCII-символы (а также их всевозможные комбинации) можно использовать в качестве операторов в Haskell. Это даёт широкие возможности для реализации различных EDSL (англ. Embedded Domain Specific Language), своего рода «языков в языке». Вот простая композиции действий.
prog = moveUp 3 *> moveRight 2 <* attack "orc" <|> (heal 10 >> defend *> retreat 1)
Ну что может быть в этой функции непонятно? ;-)

Но вот работа с лямбда-функциями весьма красива.

process :: [Int] -> [Int]
process = map (\x -> x * x) . filter (\n -> even n)

Я теперь знаю, откуда Javascript взял свой функциональный подход.

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

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

В Haskell есть бесконечные списки — и это не метафора. Они действительно бесконечные, потому что язык вычисляет значения лениво.
Философия простая: даже если выражение огромное, Haskell считает ровно столько, сколько нужно прямо сейчас. Не больше. Технически это называется вычислением до слабой головной нормальной формы (WHNF) — то есть «понять, что это за штука, но не разворачивать её полностью».
Пример из жизни: nums = [2,4..]
Этот список начинается с двойки и идёт дальше через один — 2, 4, 6, 8… и так без конца. Но если я напишу: take 3 nums Haskell даже не пытается «построить весь список». Он честно говорит: «Мне нужны только первые три — окей, вот 2, 4, 6. Остальное не трогаем».
Или ещё пример: head (map (*2) [1..]) Кажется, что тут бесконечность на бесконечности, но по факту вычисляется только: 1 → умножили на 2 → получили 2 → остановились. Магия? Нет, лень. В хорошем смысле.
Но у ленивой стратегии есть и тёмная сторона — space leak, утечка памяти.
Она возникает, когда мы вроде бы «ничего не считаем», но держим в памяти кучу отложенных вычислений. Типичная ситуация: sum [1..10000000]
Если написать неаккуратно, Haskell может сначала наоткладывать миллионы сложений, а потом внезапно понять, что память закончилась. Формально он был ленивым, а по факту — слишком терпеливым. Поэтому ленивость — это мощный инструмент, но обращаться с ним нужно осознанно.
Haskell я поизучал и решил остановиться, и вот почему. Главная особенность Haskell — в его происхождении. Он вырос из академической среды: университеты, исследователи, строгая математика, чистые абстракции. Отсюда и стиль языка — «строим собор»: всё выверено, логично, красиво, под присмотром умных архитекторов. Рекурсивные типы, функторы, аппликативы, монады — всё на своих местах.
С одной стороны, это огромный плюс. Haskell даёт редкое ощущение интеллектуальной чистоты и надёжности. С другой — он часто кажется далёким от повседневных задач. Академическая логика не всегда совпадает с тем, как думает инженер, которому нужно просто «чтобы работало здесь и сейчас».
Инженерный мир живёт практикой и эксплуатацией. Если идея прекрасна в теории, но требует недель вхождения и особого мышления — она сложна в применении. В этом и напряжение вокруг Haskell: язык мощный и точный, но дружелюбным он становится только после того, как ты к нему дорастаешь. Большинство не дорастает. Я тоже решил отложить функциональное программирование. Но опыт его освоения был весьма занимательным.

Я всё ещё ковыряюсь в Kubernetes. Нашёл на официальном сайте реально хорошие гайды — написаны понятно, без лишней магии, тот же пример с WordPress и MySQL зашёл отлично https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
Но чем дальше лезу, тем сильнее ощущение, что Kubernetes — это какой-то новый Linux: огромный, многослойный и у каждого он «свой». И в какой-то момент поймал себя на мысли, что без живых задач его можно изучать бесконечно и так ни к чему конкретному не прийти. Поэтому решил поставить обучение на паузу и вернуться к нему, когда появится реальная задача, а не просто академический интерес.

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

Перечитал роман «Гиперион» Дэна Симмонса. Впервые я читал его около двадцати лет назад, ещё студентом, и тогда без колебаний поставил ему 10/10. Сейчас впечатление изменилось.

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

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

Само название отсылает к поэме Джона Китса «Гиперион», посвящённой битве олимпийских богов и титанов. Титан Кронос пожирает своих детей, но Зевс освобождает братьев и побеждает его. Гиперион — титан света, готовящийся к войне. Поэма Китса описывает смену старых богов новыми, переход от стихийных сил к персонифицированным божествам. Этот мотив смены эпох и богов напрямую отражается в романе Симмонса.

Паломничество к «святой земле» имеет в мире «Гипериона» ключевое значение. Считается, что Шрайк исполнит желание одного из паломников, а остальных принесёт в жертву. Один из героев — военный — уже сталкивался с Шрайком, обитающим в Гробницах Времени, которые движутся из будущего в прошлое. Он видел своих спутников, распятых на Древе Боли. При этом идея о том, что один металлический бог с лезвиями вместо тела способен решить проблемы цивилизации, копившиеся веками, вызывает у меня серьёзные сомнения.

Особенно запоминается история священника Поля Дюре. Католическая церковь в XXVIII веке находится в упадке и фактически превратилась в маргинальную секту. Основная религия галактики — дзен-гностицизм, который Симмонс намеренно описывает фрагментарно. Можно лишь предположить, что в его основе — отказ от ритуалов и акцент на личном, внутреннем общении с Богом. Учитель Дюре на Гиперионе заражается крестоформом — паразитом, прикрепляющимся к позвоночнику и воскрешающим человека после смерти. Каждое возрождение сопровождается деградацией личности: стирается память, притупляется разум. Формально это путь к бессмертию, но по сути — утрата человечности, вечная жизнь без свободы и воли.

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

Война показана через призму опыта профессионального солдата Федмана Кассада — мусульманина, тактика и офицера элитных подразделений. Его история — размышление о войне как о замкнутом, самовоспроизводящемся круге, в котором меняются только декорации.

Профессор этики Сол Вайнтрауб сталкивается с проклятием своей дочери Рахели: она молодеет с каждым днём, превращаясь из женщины в младенца. Вайнтрауб — иудей, ему снятся сны, в которых Яхве требует принести дочь в жертву. Он размышляет об этике жертвоприношения и вступает в спор с библейским мифом об Аврааме. Если бы сын Авраама погиб, считает Вайнтрауб, тот не стал бы поклоняться такому Богу — потому что Бог стал бы злым.

Если двадцать лет назад «Гиперион» вызывал у меня безоговорочный восторг, то сегодня он оставляет более противоречивые чувства. Это осознанно фрагментарное произведение — смесь космооперы, философского трактата, религиозной притчи, хоррора и киберпанка. Роман обрывается намеренно: основные события начинаются уже в следующей книге — «Падение Гипериона». Шрайк, Гробницы Времени и многие ключевые загадки долго остаются без объяснений.

И всё же это великая книга. В моём личном рейтинге — 9/10. Рекомендую к прочтению.

Перед Новым годом решил наконец системно разобраться с AI.
Не «поиграться», а именно понять, как он работает и как выжимать из него максимум.
Остановился на ChatGPT — использую его каждый день, логично начать с того, что уже встроено в рабочий процесс.
Начал с бесплатного курса «Как упростить жизнь с помощью нейросетей» от Т-Ж https://t-j.ru/pro/ai-text/. Курс короткий, но неожиданно полезный. Самое ценное — про формулирование запросов. Оказывается, это отдельный навык, а не «ну я и так написал нормально».
Отдельно зашла статья про креативность. SCAMPER, латеральное мышление, метод фокальных объектов — внезапно понял, что креатив можно не ждать, а вызывать по инструкции. В итоге курс прошёл быстро, даже сертификат дали.
Параллельно начал курс «Практическое руководство по ChatGPT 5». Там уже про более продвинутые вещи: проекты, ассистенты, сценарии использования. Досмотрел примерно до середины — отложил, но вернусь.
Если кажется, что ты уже «мастер промптов», очень рекомендую игру Say What You See от Google Arts & Culture. https://artsandculture.google.com/experiment/say-what-you-see/jwG3m7wQShZngw
Дают картинку — твоя задача описать её так, чтобы нейросеть сгенерировала максимально похожую. Сначала легко. Потом начинается ад. Абстракции, детали, композиция. Очень хорошо отрезвляет и показывает, как сложно на самом деле точно описывать то, что видишь.

А потом неожиданно в жизнь ворвался SQL.
На работе начали сыпаться отчёты: где звонили, где не звонили, по каким линиям, в какие даты. Полез разбираться — и понял, что в датах и регулярках SQL «плаваю». Пришлось учиться.

Нашёл курс «SQL для анализа данных с Глебом Михайловым», курс интересный. Он показывает, как работать с данными как дата-аналитик через Google Colab https://colab.research.google.com/. Идея хорошая, но без практики не зашло.

По совету руководителя программистов зашёл на https://sql-academy.org/ — и вот это уже то, что нужно. Теория сразу закрепляется практикой. Впервые нормально уложились в голове запросы по датам — ровно то, что нужно для отчётов.
Например,

-- Извлекает часть даты (год, месяц, день и т. д.) для указанной даты
SELECT EXTRACT(YEAR FROM DATE '2022-06-16') AS year;

И тут сложился интересный инсайт.
SQL и промпты к AI очень похожи. Оба — декларативные языки. Ты не объясняешь, как делать, ты точно формулируешь, что хочешь получить. И если на входе мусор, на выходе будет ровно такой же мусор. Garbage in — garbage out.

В общем, неожиданно полезная неделя декабря: чуть больше понимания, как формулировать мысли — и для машин, и для себя.

На работе всплыла интересная задача. Менеджер по продажам звонит клиенту и общается с ним. Спустя некоторое время клиент перезванивает — уже на общий номер отдела продаж. Идея простая: АТС должна соединить клиента с тем менеджером, с которым он общался ранее.
Алгоритм довольно прямолинейный: берём номер клиента; ищем его в исходящих звонках отдела продаж; если нашли — соединяем с нужным менеджером; если нет — отправляем звонок в общую очередь отдела. По сути, такой «реверс‑прокси» для мини‑АТС.
Все звонки пишутся в MySQL. Значит, логичное решение — выполнить SQL‑запрос к CDR и получить номер менеджера. Но до меня это уже реализовали: написали bash‑скрипт, который выполняет SQL‑запрос, парсит результат регулярными выражениями и возвращает номер менеджера.
Я около двух часов пытался разобраться в логике этого скрипта и в том, что именно делают эти регулярки. Код нечитаемый, поддерживать его сложно — как инструкция к китайскому квадрокоптеру, переведённая через автопереводчик. К тому же реализация архитектурно неудачная: из dialplan запускается внешняя команда; основной поток блокируется; клиент слышит паузу; результат пишется во временный файл; потом файл читается и удаляется. Работает — да. Но выглядит как решение «на коленке».

В Asterisk есть несколько программных интерфейсов, и один из них — AGI (Asterisk Gateway Interface). AGI позволяет вызывать внешние программы (Node.js, Python, C и т.д.) прямо из dialplan и передавать им всю информацию о звонке: CallerID, канал, переменные. Скрипт, в свою очередь, управляет логикой — что воспроизвести, куда направить вызов, какие переменные установить.
Механика работы довольно простая. Asterisk запускает скрипт и передаёт ему окружение в виде набора строк формата «ключ: значение». После пустой строки начинается интерактивный режим: скрипт отправляет команды вроде SET VARIABLE, EXEC Dial или STREAM FILE, а Asterisk синхронно отвечает результатами выполнения. Всё происходит пошагово и предсказуемо. Без временных файлов, без bash‑магии, с нормальным кодом и понятной логикой.
Для начала я написал простой AGI‑скрипт на Node.js, который воспроизводит в трубке «Привет, мир». Ирония в том, что именно это оказалось самым сложным этапом. Саму бизнес‑логику — SQL‑запрос и выбор нужного менеджера — буду дописывать уже после Нового года.

Эта задача неожиданно упёрлась не только в Asterisk, но и в SQL. Сейчас я прохожу курс на [https://sql-academy.org/](https://sql-academy.org/): сначала всё было элементарно, но как только начались соединения таблиц, сложность задач резко выросла.
Параллельно я скачал книгу Е. П. Моргунова «PostgreSQL. Профессиональный SQL» и довольно быстро понял, что всё изученное ранее — по сути, арифметика. В книге разбираются графы, рекурсии и другие нетривиальные конструкции, которые уже ощущаются как «высшая математика» для SQL.
SQL вообще не такой простой язык, как может показаться на первый взгляд. На нём можно писать полноценные программы. Я даже знаю один банк, где вся бизнес‑логика была реализована исключительно на хранимых процедурах.

P.S. В Telegram‑чате меня как‑то спросили: «Такое ощущение, что ты только работаешь и учишься — отдыхать успеваешь?»
Успеваю. Просто это технический блог. Даже на один пост при готовом материале уходит около часа. А на большие и сложные статьи, например по ZFS, может уйти три‑четыре недели на сбор и проверку информации. Если подробно описывать вообще всё, что происходит, всё свободное время уйдёт только на блог. Зато следующим постом подведу итоги года и расскажу, что было у меня по разным сферам жизни.

Друзья, поздравляю вас с Новым 2026 годом 🎄✨
Пусть он начнётся без критических инцидентов 🚨, внезапных «падений продакшена» ❌ и срочных правок в последний момент. Желаю, чтобы системы работали стабильно ⚙️, решения принимались осознанно 🧠, а технический долг постепенно сокращался 📉 — без авралов и выгорания.

Пусть в новом году будет больше понятных архитектур 🏗, аккуратных конфигов 📄 и задач, которые действительно развивают 🚀. Желаю, чтобы обучение приносило удовольствие 📚, новые технологии ложились в голову без боли 💡, а сложные проблемы решались не за счёт нервов, а за счёт опыта и спокойствия 😌.

Спасибо, что читаете этот блог 🙌, делитесь мыслями и находите здесь что-то полезное для себя. В 2026 году желаю нам всем больше здравого инженерного подхода 🧩 и удовольствия от того, что мы делаем 😊. С Новым годом 🎉 — пусть он будет стабильным, продуктивным и технологически чистым!

2025: длинная дистанция без иллюзий
Коротко о главном
2025 год оказался не годом достижений, а годом выживания и пересборки. Без громких побед, зато с большим объёмом честной внутренней работы: переосмысление профессии, денег, здоровья и собственных ожиданий. Если описывать его одной метафорой — это был бег с препятствиями без зрителей и аплодисментов.
Работа и рынок
Конец 2024 года я встретил увольнением и пятью месяцами поиска работы. За это время рынок труда показал себя во всей красе: он сломан, перегрет и абсолютно не гуманен к соискателю. Поиск работы превратился в отдельную профессию: курсы по алгоритмам, soft skills, работа с карьерными коучами и постоянная правка резюме. Результат — 1–2 собеседования в неделю вместо привычных 1–2 в день.
Эффект «импортозамещения» закончился: деньги в IT кончились, неключевые проекты закрылись, а рынок окончательно стал рынком работодателя. Когда финансовая подушка начала стремительно таять, я вернулся к очевидному: за плечами 20 лет системного администрирования.
Попытка вернуться в профессию выглядела сюрреалистично. Вакансии сисадминов напоминали цирк с грустными клоунами: от кандидата требуется всё, платить готовы почти ничего. Школы, больницы, государственные учреждения — текучка, завалы и выжженная земля. Один визит в поликлинику как кандидата, скорее для расширения кругозора, окончательно убедил меня: на таком месте можно застрять на годы, разгребая чужие ошибки.
В итоге я нашёл компанию, где работаю сейчас. Она занимается продажей и обслуживанием банковского оборудования. Я пришёл как связист по Asterisk. Около 500 абонентов, до меня — пять разных специалистов, каждый оставил после себя собственный почерк. Горы Perl-скриптов, криво переписанных на bash, неиспользуемый код и отсутствие целостной архитектуры. Цветущий сад я не вырастил, но значительную часть мусора удалось вывезти.
Что удалось сделать
1. Голосовое меню Asterisk и интеграция с Bitrix24. Третья попытка оказалась удачной. Базовый принцип — ни один звонок не должен пропадать. Сколько проживёт текущая версия, покажет время.
2. Оптимизация телефонии: отключены два оператора связи и половина телефонных номеров, которые фактически не использовались, но стабильно съедали бюджет.
3. OfeliaMerge — отдельный проект и утилита для конвертации cron-задач из bash-формата в формат Ofelia при миграции серверов.
Отдельным открытием стал процесс найма разработчиков изнутри. На одну вакансию за день может прийти до полутора тысяч резюме. Сначала автоматическая фильтрация по ключевым словам через AI, затем живое общение и отбор самых сильных кандидатов. Рынок работодателя без иллюзий.
Здоровье
Со здоровьем всё было тяжело. Головные боли преследовали весь год: ощущение, будто в голову несколько раз в день забивают гвоздь. Проблема оказалась сосудистой. После смены нескольких неврологов я нашёл цефалголога, и назначенное лечение наконец дало ощутимый эффект.
С сентября по декабрь — почти непрерывные ОРВИ. Только восстановишься — снова сляжешь. К вечеру состояние было таким, будто весь день разгружал вагоны. Плюс удаление зуба и регулярные визиты в аптеки. Этот год наглядно показал: здоровье — это не фон, а полноценный проект, требующий внимания и ресурсов.
Финансы
Финансово 2025 год прошёл под словом «апож». Финансовая подушка была полностью израсходована за время поиска работы. Портфель на фондовом рынке из-за последних геополитических событий превратился в сверхдолгосрочную инвестицию на 20–30 лет.
Криптопортфель показал минус 70 процентов за год — около 3000 долларов. Убыток пока бумажный, выходить из позиций я не стал.
С переходом на новую работу доход снизился примерно в три раза, а расходы остались прежними. Пришлось провести аудит: отключить неиспользуемые подписки, оптимизировать траты, перейти на более дешёвые решения. Итог — жизнь по средствам.
Финансовые цели на 2026 год простые и приземлённые:
1. Финансовая подушка безопасности.
2. Отпуск.
3. Наращивание криптопортфеля.
Системное администрирование
Из программиста я снова стал системным администратором. В работе — Asterisk, FreeBSD, ZFS, Debian, Zabbix.

FreeBSD оказалась отдельным испытанием. Она похожа на Linux ровно до первого серьёзного шага в сторону, а дальше начинаются собственные правила игры: свои ключи, свои подходы, свои грабли. Docker нет, вместо него — Jail. NodeJS пришлось собирать из исходников. Зато ZFS из коробки — мощь: снапшоты, кеширование, сжатие. Если бы не лицензия, эта файловая система давно стала бы стандартом де-факто.
DevOps
Основная система готовится к переезду в Kubernetes, поэтому год прошёл под знаком k8s. Я прошёл два курса и много практиковался. Kubernetes не столько сложный, сколько объёмный. Чтобы повторить возможности docker-compose даже на одной ноде, требуется минимум 1–2 месяца обучения, а также время и терпение.
Параллельно я поработал с Ansible и написал плейбук для первичной настройки Debian, познакомился со стеком Prometheus и Grafana и сделал демопроект для мониторинга WordPress. В сравнении с Zabbix связка Prometheus + Grafana показалась мне более гибкой и удобной.
Впереди — Terraform. Поднимать десятки серверов вручную желания нет.
Программирование
Фронтенд на текущей работе не нужен. Основной фокус — бэкенд и чат-боты для Bitrix24. Asterisk оказался куда сложнее, чем кажется: 25 лет разработки продукта и четыре разных программных интерфейса.
Я прошёл курсы по NodeJS и NestJS, прочитал книгу В. И. Светлакова «Архитектура бэкенда». Рост как специалиста ощущается отчётливо: от проблем с синтаксисом — к вопросам архитектуры и проектирования.
Я познакомился с очередями сообщений через RabbitMQ, следующим шагом для меня станет Kafka. Параллельно я изучал разные языки программирования: прошёл курс по Haskell и хочу попробовать Rust, C и C++. В конце года решил повторить использование SQL — отчёты по АТС быстро показывают пробелы в знаниях.
Сильное влияние на моё восприятие программирования оказали книги Тейта Брюса «Семь языков за семь недель» и «Код. Тайный язык информатики» Чарльза Петцольда. Они расширяют взгляд на Computer Science и заставляют иначе смотреть на привычные технологии.
Искусственный интеллект
В 2025 году я осознанно начал разбираться в AI. Раньше использовал его поверхностно, теперь понимаю, насколько плохо знал возможности инструментов. В 2026 году планирую идти глубже и использовать их более системно.
English
Летом я закрыл уровень B1+. Для текущей работы этого достаточно: документацию читаю, обучающие видео понимаю. Главное осознание — офлайн-курсы дают лишь небольшую часть результата, остальное обеспечивают самостоятельная практика и дисциплина.
Хобби, культура и отдых
Музыка осталась важной частью жизни. Домашний звук вышел на новый уровень, концерты и живые выступления по-прежнему радуют. Было много книг, спектаклей, экскурсий и лекций. Этот блок я намеренно оставляю кратким — он про эмоции и впечатления, а не про отчёты.
Итог
2025 год стал для меня годом тихой, но важной внутренней работы. Без показных побед, зато с честным взглядом на себя, свои ограничения и реальные возможности. Я выхожу из него не идеальным и не успешным по чек-листу, но более устойчивым и собранным. А значит, всё происходившее имело смысл.