Эта статья - о шаге, который предшествует настройке маршрутов: как выбрать сигнал, связать его с влиянием на бизнес, определить срочность и проверить, что вызов дежурного действительно оправдан. В качестве сквозного примера возьмём оформление заказа, а в конце свяжем правила детектирования с обработкой в nxs-anomaly.
Критичный сервис лег, Prometheus показывает firing, в общем чате уже бухтят менеджеры, но к исправлению проблемы никто не приступил: один инженер решил, что проблему уже разбирает коллега, а коллега уже не дежурит.
Причина может находиться на любом участке цепочки: правило потеряло метку команды, маршрут выбрал общий канал или у сообщения не оказалось конкретного получателя.
Для того, чтобы разобраться, мы рассмотрим путь одной HTTP 500 ошибки: от счётчика приложения и PromQL до webhook в систему реагирования. По дороге соберём конфигурации, разберём ошибки маршрутизации и проверим, почему повторная отправка не заменяет эскалацию. Для участка с дежурствами используем наш открытый проект nxs-anomaly.
Всем привет, меня зовут Пётр, я DevOps инженер компании Nixys. История с алертами и дежурствами для меня, как и для любого DevOps инженера, довольно противная, потому что не знаешь, что вызывает больше негатива: ложный звонок посреди ночи или критичный алерт, который почему-то не сработал.
Долгое время решением этого были Grafana OnCall, PagerDuty и другие платформы, которые предоставляли возможность установки open-source инструментов для оповещения инженеров, ведения смен и эскалации происшествий. Но в марте 2026 года состоялась полная архивация проекта Grafana OnCall OSS, а PagerDuty полностью прекратила сотрудничество с клиентами из России еще в 2022. И вот, время шло, а крепкой зарубежной opensource замены уровня Grafana так и не появлялось. Это побудило нас самостоятельно взяться за разработку локального проекта для управления алертингом, который мы бы хотели предоставить в открытый доступ.
Команда Nixys готовит к выпуску версию 3.1.0 nxs-universal-chart. Этот релиз аккумулирует все изменения, вошедшие в промежуточные сборки v3.0.10 - v3.0.21, а также новые фичи. Ниже — разбор ключевых нововведений и исправлений.
Итак, вы обучили модель и она показывает ожидаемые результаты. Теперь осталось выкатить её на контур, однако для этого необходим ряд компонентов: нужна маршрутизация трафика, непосредственно инференс. Желателен autoscaling модели, передача чувствительных данных, например креды до хранилища моделей. Ну и мониторинг не помешал бы.
Каждый компонент - это отдельный Helm-чарт, отдельные CRD и отдельная документация. В итоге, вместо быстрого тестирования модели и гипотез, приходится заниматься YAML-инжинирингом и громко ругаться благим матом.
Всем привет, на связи Пётр, инженер компании Nixys. В этой статье я покажу, как собрать полноценный inference-контур из пяти Kubernetes-операторов в одном values.yaml размером в 120 строк, используя nxs-universal-chart.
Релиз nxs-universal-chart 2.8.3 был более двух лет назад и за это время многое поменялось: Ingress Nginx ушел на покой, GitOps по факту стал стандартом управления инфраструктурой, а AI все сильнее входит в наши жизни. Все эти изменения не могли пройти мимо и заставили нас задуматься о том, как адаптировать наши подход и технологии DevOps к вызовам нового времени.
Результатом этих размышлений стал релиз новой версия nxs-universal-chart v3.x: из универсального набора встроенных шаблонов мы постарались превратить его в модульную платформу для поставки приложений в Kubernetes с упором на надежность и современные практики CI/CD процессов.
Всем привет, на связи Пётр, инженер компании Nixys и по совместительству maintainer проекта nxs-universal-chart. В этой статье я расскажу как мы переработали изначальную идею и какие нововведения в чарте это за собой повлекло.
За годы работы с Kubernetes у нас было множество различных задач: от самых типовых развёртываний до крайне специфичных конфигураций и установок. Однако недавно в наших стенах решалась задача, которая заставила нас проявить творческий подход, выйти за рамки Kubernetes и даже немного сжульничать.
Всем привет, на связи Пётр. Сегодня мы рассмотрим автоматическое развёртывание ванильного Kubernetes на Astra Linux через Kubespray + Helm.
Всем привет, меня зовут Пётр. В первой части этого цикла статей мы взглянули на некоторые базовые концепции ClickHouse. В этой же статье продолжим изучать тонкости работы с этой колоночной базой данных и подробно рассмотрим такой аспект как репликация. А ещё разберёмся с сервисами координации Zookeeper и ClickHouse Keeper.
Всем привет, на связи Пётр, инженер компании Nixys. В прошлой статье мы разобрали основные концепции Redis. Теперь рассмотрим базовую репликацию Redis и настроим эту БД на высокий уровень отказоустойчивости.
Всем привет, меня зовут Пётр, я инженер компании Nixys. На современных проектах используется огромное разнообразие баз данных: реляционные, ключ-значение, документоориентированные. Особое место среди них занимают колоночные базы данных, ярким представителем которых является ClickHouse. Это мощный инструмент, который способен обрабатывать миллиарды строк в секунду при минимальном времени ответа. Однако, для максимальной эффективности ClickHouse необходимо понимать ряд фундаментальных моментов для того, чтобы использовать его по назначению. В этой серии статей мы разберем особенности работы ClickHouse, которые помогут в выжимании максимума из этой базы. И сегодня начнём с фундаментальных теоретических моментов, чтобы составить максимально полное общее впечатление, которое поможет нам в дальнейшем.
Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.
В серии статей я попытаюсь осветить неочевидные нюансы при работе с Redis и сегодня начну с основных концепций и понятий. А еще в конце статьи приведу небольшой чек-лист, который может помочь вам в оптимизации этого NoSQL решения.
