Первая статья из цикла «Аналитик в чужом процессе»
145 тысяч тикетов, почти 87 тысяч "аномалий" и уверенность, что Service Desk полностью сломан. Но один разговор с опытным специалистом первой линии заставил меня выбросить половину критериев, переписать анализатор и полностью изменить выводы. Эта статья — о том, почему большие данные сами по себе ничего не объясняют, если сначала не понять сам процесс.
По профессии я руководитель в ИТ. Когда-то давно кодил на Basic, Pascal и Delphi (диплом писал на нём же). Но с тех пор много воды утекло, и за современными технологиями я следил скорее как управленец.
У одной закрытой группы возникла потребность в мобильном приложении с доступом к статьям. Нанимать разработчика не хотелось — проект некоммерческий. К этому моменту я уже активно использовал ИИ для написания скриптов и даже более сложных программ: создал API-интерфейс, совместимый с OpenAI, который через браузер общался с бесплатным Perplexity и возвращал ответ. На его основе сделал плагин для VS Code — практически бесплатный аналог коммерческих AI-агентов. Поэтому для новой задачи я решил попробовать vibe-кодинг.
Проект требовал клиент-серверной архитектуры: авторизация, разграничение доступа к статьям, мобильное приложение для Android. Обсудив со мной варианты, ИИ помог определиться со стеком: Docker, Nginx, PostgreSQL, Node.js, React, Kotlin. Nginx я знал неплохо, базы данных были знакомы. Node.js и React «умник» пообещал закрыть все потребности — так и вышло. Для Android выбор был невелик, и я решил, что современный Kotlin будет интереснее.
Docker Compose стал обязательным для изоляции: VPS был арендован для других нужд, и не хотелось ничего ломать.
Как связаны ИТ и строительство? Очень тесно — через методологию управления.
Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!
Работа в крупной ИТ-компании — это здорово. Особенно когда проекты есть. И они были.
Но один из крупнейших заказчиков, испытав трудности из-за надвигающегося кризиса, решил оптимизировать расходы и отказаться от поддержки, взяв всё в свои руки.
Годами компания не вникала в проект. У них и так хватало сложностей с другими его частями — поддержку разных компонентов осуществляли разные подрядчики. И вот после недолгих организационных моментов заказчик забрал двух человек из нашей команды к себе. Конечно, это был риск.
Аннотация: Рассказываю, как наша команда реализовала мониторинг состояния шины и аналитику запросов к ней через обратный прокси. Пришлось повозиться, ведь Zabbix из коробки не очень успешно с этим взаимодействует.
В сложных интеграционных системах мониторинг является неотъемлемым инструментом как для инженера, так и для бизнеса. Zabbix показал себя надёжной и гибкой системой, которая позволяет строить понятные дашборды. Но я, как тимлид команды поддержки, столкнулся с тем, что шину Red Hat JBoss Fuse так просто к Zabbix не подключить. Шина работает на JVM, а значит, нужен мониторинг по JMX.
Аннотация: История о том, как команда поддержки прошла путь от ежедневных авралов и взаимных обвинений с заказчиком до изящного решения, победив загадочные зависания легаси шины. В статье описаны не только технические шаги, но и эмоциональные качели двухмесячного инцидента: от отчаяния к надежде и, наконец, к триумфу.
