Каждую неделю я записываю небольшие заметки о том, чем занимался и какие открытия сделал. Это помогает структурировать опыт и взглянуть на свои проекты со стороны. На этой неделе было всё: баги с датами, эксперименты с линтерами, автоматизация серверов и даже первый шаг в сторону Haskell. Ниже — мои наблюдения и выводы.

Всю неделю программировал чат-бота. Откровенно заколебался с тайм-зонами. У меня оказалось их три. В одной базе данных UTC, в другой Москва, а в самом чат-боте Тюмень. Работа с тайм-зонами в JavaScript реализована от слова «никак». По умолчанию даты не имеют тайм-зоны. Всё решается через сторонние библиотеки. И пока найдёшь ошибку, почему здесь работает, а здесь то работает, то не работает, можно поседеть.

Я долго мучался с eslint и prettier, так новый конфиг eslint и не победил. Он то алиасы TypeScript не видит, то декораторы. Посмотрел видео Михаила Непомнящего «Next.js 15 перешёл на Biome» https://www.youtube.com/watch?v=FBbywTFHbRU
и перешёл на Biome https://www.npmjs.com/package/@biomejs/biome. Это eslint и prettier в одном флаконе. И он мне это понравился, что не нужно отключил. Работает быстро, т. к. написан на Rust. Пакет рекомендую.

Загрузку файлов на сервер Bitrix24 я победил. Есть 4 варианта, как загружать файлы. Работает по факту только один. Надо файл представить в виде base64 и загрузить в нужный каталог, а чат-бот вернёт ссылку на файл.

Наконец добрался до сисадминской задачи. Поднимал Elastic Stack (ELK) Elasticsearch, Kibana & Logstash на VPS. Решил использовать мои наработки по Ansible. И они сработали на новом сервере. Неделя работы на автоматизацию и в результате 5 минут первоначальной настройки. Кроме того, перенёс файлы Docker на второй большой диск. В целом почти настроил, но не до конца.

Начал изучать Haskell. По бесплатному курсу «Функциональное программирование на языке Haskell» https://stepik.org/course/75/syllabus. Преподаватель тот же, что и у роликов на YouTube, которые я бросил смотреть. В этом курсе он каждое своё утверждение не доказывает как теорему, и это радует. Я в математике после ВУЗа больше не практиковался. Я, конечно, понимаю, что за всеми этими буквами и цифрами заключен большой смысл, но я его уже не понимаю.

Haskell — чисто функциональный язык программирования. И в нём главное — функция.
- Функциональное программирование позволяет создавать сложные функции через композиции.
- Функции передаются как параметры и могут быть получены и возращены.
- Композиции функций позволяют строить более сложные алгоритмы.

В объектно-ориентированном программировании другие особенности.
- Объект является основным элементом.
- Объекты могут содержать другие объекты, создавая иерархию.

Ключевое отличие между функцией и объектом — наличие состояния у объекта, у функции никакого состояния нет.

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

Все эти разнородные задачи — от автоматизации серверов до философии функционального программирования — объединяет одно: практика. Я всё больше убеждаюсь, что рост программиста измеряется не только написанными строками кода, но и способностью искать решения в разных областях. А такие недели напоминают, что развитие всегда идёт параллельными треками — и это делает процесс интересным.

За короткий промежуток времени мне удалось прикоснуться к целому спектру задач: от настройки Click2Call в Asterisk и оптимизации Elastic Stack до запуска нового IVR и первых шагов в Kubernetes. Каждая история оказалась с неожиданными поворотами: техническими, организационными и даже человеческими. Этот опыт хочется зафиксировать и рассказать подробнее.

Пришла следующая задача. Пользователь кликнул на ссылку с номером телефона на сайте, и его телефон звонит и соединяет с абонентом, по ссылке которому он кликнул. Эта технология называется Click2Call (c2c).
На Asterisk эта технология реализуется при помощи технологии Asterisk Manager Interface (AMI). Смысл технологии простой: надо подключится к Asterisk через telnet и послать текстовый файл, и Asterisk выполнит команды из него.
Но реализация хитрая, при помощи текстового файла Asterisk позвонит пользователю, а вот чтобы соединить с клиентом, надо использовать context из DialPlan.
Отправку текстового файла можно реализовать через WebSocket и через них же получение ответа, что я и сделал, написав приложение на Typescript.
Я уже радостный хотел сдавать задачу, но была пара нюансов, которые я начал выяснять в Project Manager. Выяснил, то, что написано у меня в тех. задании и то, что имел в виду клиент, это две большие разницы. И моё решение нафиг никому не нужно. Но я его довёл до конца, выложил на хостинг. Может, когда-то кому-то и будет нужно. Т. к. подсистему телефонии в нашем приложении уже давно хотят переписывать. А я разобрался с технологией AMI, поэтому поводу напишу статью в блог.

Затем несколько дней я переносил Elastic Stack (ELK) на другой сервер. При помощи Elastic можно не только логи собирать, но и реализовывать полнотекстовый поиск. Поэтому решили сделать два сервера: один для программистов, другой для админов.
Первоначально, когда я настраивал ELK, я решил писать всё. Это «всё» оказалось горой ненужного мусора, всякие debug, трассировки и т. д. В результате свободное место заканчивалось за пару дней. Сейчас весь мусор остаётся на сервере, а на ELK идут информативные логи. Буду мониторить, что я настроил.

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

Я завершил курс по «Kubernetes и Helm». Теперь, если по шкале от 0 до 10, я знаю Kubernetes (k8s) на 0.1. Он реально огромный. Но курс понравился, хоть и сильно вводный. Автор сначала поднял фронтенд, бекенд и nginx локально. Этот вариант от docker compose отличается мало. А затем всё шаблонизировал через helm. Больше всего не понравилось, в самом k8s всё очень сильно завязано на пробелы в yaml-файлах. Дело в том, что helm код для yaml-файлов генерирует, и при добавлении лишних 2-х пробелов создаётся такая простыня с ошибками. Ощущение, что система умерла в муках и не воскреснет никогда.
Ещё, что не понравилось в k8s. Есть система хранения секретов (пароли, доступы и т. д.), по умолчанию она ничего не защищает. Просто все секреты кодирует в base64. Нет, это решает дополнительными плагинами, но по умолчанию дыра дырой.

Почему я решил изучать Kubernetes? У нас просто в фирме упорно ходят слухи по поводу светлого микросервисного будущего и облачного Kubernetes. Интуиция мне подсказывает, что это светлое будущее реализовывать буду именно я. Но пока есть время на подготовку.

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

Знаете, что такое Click2Call? Это когда нажал на номер на сайте — и твой телефон уже звонит нужному человеку. Удобно, правда? Я решил разобраться, как эта штука работает на Asterisk, и оказалось, что всё не так уж сложно, если знать, куда копнуть.
Я написал статью в блоге, где подробно показал, как настроить manager.conf, проверить подключение через telnet и собрать рабочий AMI-скрипт для звонка. Там же есть пример контекста в extensions.conf и кусок кода на TypeScript, который отправляет команды прямо на сервер. Короче, пошаговый разбор от идеи до живого сценария, который реально работает.
Хочется посмотреть все детали и попробовать самому? Тогда заглядывайте в блог https://infoblog72.ru/moi-proektyi/click2call-na-asterisk-ot-idei-do-rabochego-sczenariya.html — там полная версия с примерами и кодом.

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

Изучил видео по Haskell «Haskell Programming Full Course 2024» https://www.youtube.com/watch?v=TklkNLihQ_A. Было всё понятно, пока не дошли до метапрограммирования — монады, функторы, моноиды.
Т. е. если функция просто перебирает список — это просто функция. А если функция перебирает любую последовательность от дерева до хеш-таблицы, включая списки — это уже абстракция более высокого порядка под названием функтор. Монады с моноидами как-то понял, но слабо. Мне понравилась цитата: «Монада — это просто моноид в категории эндофункторов. Что может быть проще?» Может, для кого-то и проще, но я не разобрался. Кто может объяснить эту цитату, пишите в комментариях.
Функциональное программирование — это хорошо, развивает как профессионала, показывает, что можно программировать по-другому. Пока Haskell поставил на паузу, но буду присматриваться к Rescript https://rescript-lang.org/ на фронте и Elixir https://elixir-lang.org/ на беке.

Функциональное программирование занимательно, но живём мы в реальном мире, я критически посмотрел, что я напрограммировал со своим чат-ботом под Bitrix24, и понял, надо было сразу использовать фреймворк.
Поизучал, что есть из фреймворков для JavaScript, и понял, что мой выбор NestJS https://nestjs.com/.
Вот по нему базовое видео «NestJS — быстрый курс по лучшему Node.js фреймворку» https://www.youtube.com/watch?v=j2-GqaeSueA.
У этого же автора вышло новое видео «Вайб-кодинг: 10 советов, которые сразу сделают ваш код лучше» https://www.youtube.com/watch?v=DDRJg1zp_eI.
И мне понравились инструкции по архитектуре, которые давал автор, чтобы ИИ программировал приложение:
«Краткие требования: реализация на NestJS с CQRS (Command Query Responsibility Segregation).
Основные ограничения:
1. CQRS: команды (изменяют состояние) и запросы (чтение) разделены, отдельные CommandHandler и QueryHandler.
2. Тонкие контроллеры: только DTO + делегирование в CommandBus / QueryBus, бизнес-логика в хендлерах.
3. Идемпотентность: обязательна для команд создания (Idempotency-Key + таблица idempotency_keys).
4. Read-модели: агрегации (daily / weekly / monthly clicks) обновляются асинхронно, статистика eventually consistent.
5. Валидация: nestjs-zod для DTO, бизнес-инварианты — в domain-слое.
6. Авторизация: Guards + проверки владельца в хендлерах.»
Архитектуру CQRS активно использовали на моей одной из прошлых работ, правда, на .Net Core, но это нюансы. Самое интересное, модули для CQRS уже есть в NestJS. Я просто внедрял архитектуру Feature-Sliced Design (FSD) в проект, без слёз сложно вспомнить. Так что фреймворк NestJS достаточно развитый, буду учить его.

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

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

На этой неделе я наконец-то выздоровел, но по ощущениям не до конца. Монады в Haskell меня затянули. Я решил всё-таки разобраться, что же это такое. Если убрать строгие определения, монады — это способ программирования в функциональных языках, но для реальных систем. Это когда данных то нет, то они искажены, то они могут неожиданно прийти из другой системы и т. д. Математики - это всё собрали в красивую функциональную обёртку. Вот хорошее видео «Монады, или зачем программисту математика» https://www.youtube.com/watch?v=SXu4b3C8wtI.

А в этом видео «Виталий Брагилевский — Монады — не приговор» https://www.youtube.com/watch?v=IkXg_mjNgG4 автор показал, что императивный стиль программирования, что функциональный — это просто разный взгляд на решение одних и тех же задач. И ничуть не проще, чем императивный.
Мне понравилась цитата: «Адепты функционального программирования очень любят завлекать неопытных программистов обещаниями идеальной выразительности кода, его стопроцентной корректности, лёгкости поддержки и простоты рефакторинга. Иные даже пророчат высочайшую производительность и попадание после смерти напрямую в райские кущи. Опытные разработчики знают, что ничего такого не бывает, программирование — это тяжёлый труд, а серебряные пули, может, и помогают от вампиров, но никак не в процессе разработки ПО».

На работе я доделал Elastic Stack (ELK). Я всё думал, что за ветвистая наркомания нужна, чтобы просто парсить логи. Начал строить Dashboard и понял, для чего все многочисленные обработчики и конвейеры. По факту есть 2 сервера: один на Debian, а второй на FreeBSD. А в Dashboard должна быть табличка, самые популярные ошибки из логов и количество этих ошибок. Всё хорошо, только логи с ошибками — это текстовые строки. И эти строки сильно разные в Debian и во FreeBSD. И чтобы привести их к сопоставимым параметрам, надо использовать уйму регулярок, агрегирующих функций и т. д. Я сначала сам писал, потом плюнул и отдал на парсинг ChatGPT. Dashboard я построил, но осознал мощь дополнительного функционала.

Начал разбираться с Prometheus и Grafana. Ещё одна система мониторинга, всё думал, почему её админы Kubernetes так любят. Оказалось, система Kubernetes на редкость динамичная — контейнер появился и исчез, контейнеров было 10, а стало 100 и т. д., а в Prometheus вся динамика встроена изначально, а вот в Zabbix это надо программировать вручную. И кроме того, это всё встроено в сам Kubernetes.
Пока разбираюсь, но система интересная.

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

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

Заболел в очередной раз ОРВИ, с сентября всё болею, уже достало. Прошлый пост пропустил, так как все выходные «изображал тюленя» на диване. Хочется крикнуть: «Лунная призма дай мне силы», но не поможет.

Попробую выступить в жанре «коротко о длинном». В моей компании на главной странице сайта написаны номера телефонов. И начальник сообщил, чтобы я нарисовал маршрутизацию звонков. Оказалось, на 3 номера телефона приходится 4 оператора связи. Один номер на 8-800 тупо, безусловно переадресуется на тюменский номер. 2 номера приходят на старую версию голосового меню. А внутренняя адресация звонка ну до того дивная, что напоминает скорее горный серпантин, чем прямую дорогу. Убил день, чтобы 3 номера на официальном сайте звонили напрямую на новое голосовое меню. Миром правит не тайная ложа, а явная лажа.

На работе мне поручили написать очередного чат-бота. Он должен читать письма из почтового ящика и пересылать их в «Телеграмм». В письмах необходимо вырезать персональные данные, показывать только сокращённую версию и т. д. Я уже становлюсь экспертом по чат-ботам. Зная, что аппетит начальства приходит во время еды. Чувствую, что мой чат-бот будет ждать уйму доработок. Я решил не изобретать велосипед и использовать фреймворк NestJS https://nestjs.com/. На него есть уйма критики, но он мне как-то понравился. Любая моя проблема гуглится на раз-два. Код получается хоть многословным, но логичным. Есть другой безумно популярный фреймворк на NodeJS — NextJS https://nextjs.org/, но он про другое, он про генерацию страниц на стороне сервера, концепцию Backend for frontend (BFF) и т. п. А NestJS — чисто бэкенд, про вызов функций через API и Cron. Пока мой выбор — NestJS.

Я уже наученный горьким опытом, прежде чем что-то судорожно программировать начал, сначала реализовал архитектуру приложения. Нарисовал и довольный эти кубики и стрелочки начальнику отдела программистов. Он добро посмеялся и указал места, где много оверинжениринга. В результате архитектура получилась простая как табуретка. Сначала чат-бот получает почтовые сообщения. MessageID сохраняет в Redis, чтобы избежать дедупликации. Затем полученные письма отправляет в RabbitMQ, а другой модуль приложения из «кролика» считывает и отправляет 3 раза в Telegram. По результатам этой операции сообщение перемещается в папку Processed или Failed.
А можно обойтись без RabbitMQ? А нельзя, операции получения и отправки должны быть разделены. Telegram может быть недоступен, писем придёт много и т. д. В результате один созвон с начальником сэкономил уйму времени на ненужное программирование.

Haskell меня не отпускает, решил разобраться в нём до конца. На Windows Haskell полный фуфель, программирование в нём напоминает кодинг в блокноте. Что-то написал, а результаты увидишь только после компиляции. А вот бы сделать так, чтобы глупые ошибки видеть ещё до компиляции? Я решил поставить Haskell на MacOS. Больше всего меня добило, что все инструменты Haskell собирают из исходных кодов. Набрал команду и ждёшь 20-30 минут, это линтер собирается. Но я всё-таки установил и сам язык программирования, и линтер, и форматер. Эх, ещё бы IDE для Haskell, но это мечты.
Haskell решил изучать по книге Курта Уилла «Программируй на Haskell», прочитал первую главу, пока понравилась. Почему я решил изучить Haskell? Просто этот язык программирования заложен в основу многих других популярных языков. И когда команда разработки с гордостью заявляет о реализованном новом функционале, на проверку оказывается, это уже до них придумали лет 40-50 назад.

Каждый мой осенний вирус — повод перезапустить не только тело, но и мозг. Очередной бот почти готов, архитектура вычищена, Haskell побеждён наполовину. Возможно, именно так и выглядит взросление программиста — когда вместо таблеток ищешь новые фреймворки и способы думать.

Неделя выдалась насыщенной: боты, почта, Docker и вечные «давайте уточним». Хотел просто закрыть задачи и выдохнуть, но вместо этого получил классический набор приключений — от зависшего начальства до капризной Prisma. Делюсь, как всё это прошло и чем закончилось.

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

Но я узнал у коллеги-админа, а какие, собственно, ящики начальство может предложить. Он дал пару почтовиков, и мне поплохело, там около 10 тыс. сообщений в каждом. За день сотня сообщений стабильно приходит. Сидел переписывал под эти объёмы. Даже завёл базу данных PostgreSQL, чтобы хранить неотправленные сообщения. В моих мечтах и фантазиях почты должно было приходить в разы меньше. Эх...

Но ещё правил ошибки в моём первом боте для Bitrix24. Создал багфикс, дай, думаю, задеплою на production. Залил исходники на удалённый сервер, а Docker-образ не собирается, оказывается, библиотека Prisma ORM русских не любит. Поднимать VPN на внутреннем сервере — результат так себе. Я прекрасно знаю про container registry, и он у нас даже поднят, но залогиниться я туда не могу, сколько я ни бился. Пообщался с коллегой, он подсказал простую идею: Docker-контейнеры — это просто файл, в котором каждая команда создаёт слой. Этот файл можно сохранить у себя и восстановить на production. Сказано — сделано.

; Сохраняем образ на своём компьютере
docker save -o chat-bot.tar chat-bot:latest

; Восстанавливаем образ на production
docker load -i chat-bot.tar

Сам создал себе проблему, сам решил. А container registry я внедрю.

Посмотрел 2 хороших видео блогера Soer по функциональному программированию.
«Три реализации задачи в функциональном стиле» https://www.youtube.com/watch?v=aoFZG6l8iiU и «FizzBuzz: четыре варианта решения на JS» https://www.youtube.com/watch?v=TWmmfDvcYO0. Оба видео очень хорошо показывают причудливую логику функционального программирования.

В общем, как обычно: хотел просто написать бота, а в итоге прокачал терпение, DevOps-скиллы и немного философию. Главное — не забывать сохранять образы, не только Docker, но и собственные.

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

Завершил разработку бота, который пересылает сообщения из почты в Telegram. Проблему с библиотекой Prisma удалось обойти: отправил маршрут на роутере на адрес https://binaries.prisma.sh через сервис из трёх букв, который нельзя называть. Может кому пригодиться. Блокировку осуществляет не сама Prisma, а сервис Cloudflare, где она расположена.

Мечту о написании CI/CD для моего бота я не оставляю. У нас в качестве Container Registry используется система Harbor https://goharbor.io/. Поговорил с инженером, который поднял эту систему. Основной критерий выбора этой системы был, что у неё хорошая админка, и всё. Оказалось, что контейнер из-под Windows на неё не залить, чтобы я не делал. А вот под Linux всё идёт с полпинка. Буду «мучить» Linux.
Ещё есть мечта ошибки ошибки бота отправить на Sentry, но времени не хватает.

Почти всю неделю занимался телефонией. Делал прозвонку по номерам компании. Часть номеров должна быть отключена прошлым связистом, но по факту не отключена. А компания за них платит деньги...
Анализировал статистику, кто и по каким транкам и номера внутри транка звонят. Транков уйма, номеров ещё больше, а звонят максимум на десяток. Отключил ненужное. Но пока отключение хитрое, это не написание официальных писем, а просто установка заглушки, что «Линия не обслуживается». Но на этой заглушке я установил логирование. Через пару дней выяснил, что один номер отключил зря. Включил обратно. До нового года хотим отключить всё ненужное и оставить пару операторов связи и телефоны, которые используются. Пока полный зоопарк.

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

Был на митапе тюменских программистов «ИИ в разработке» https://vkvideo.ru/video-64545043_456239475, узнал уйму нового, буду внедрять. Но фото получилось какое-то замученное.

Неделя пролетела как одно мгновение — вроде только началась, а уже пятница. Планы, как обычно, были грандиозные, а реальность внесла свои правки. В итоге получилось много мелких побед, немного философии и целая россыпь новых идей — от телефонии до 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. Местами непросто, местами забавно, но главное — я реально расту и расширяю кругозор. Чем больше погружаюсь, тем отчетливее понимаю, что иду в правильном направлении и набираю хороший темп.