DevOps *

IMPulse - Open Source менеджмент инцидентов. Freeze, Jira, ChatOps

Прошло достаточно времени с прошлой публикации: мы добавили много нового и хотим поделиться этим и нашими планами.

Из нового

• У нас появился механизм Freeze, который выполняет пару задач. С одной стороны он отключает уведомления по инциденту на некоторое время, например на выходные. С другой - исключает создание таких же инцидентов на время "заморозки". Этот функционал похож на Silence Alertmanager'а.

• Появилась интеграция с системой трекинга задач, Jira.

• Теперь есть возможность просматривать закрытые (архивные) инциденты.

• Добавлены метрики.

• IMPulse теперь можно запускать в нескольких экземплярах. В случае недоступности основного (primary) инстанса, работу подхватит запасной (standby).

• Webhook'и стали ещё мощнее. Теперь с их помощью можно очень гибко формировать JSON для отправки в любую сторонюю систему.

• Появилась интеграция с алертами из Grafana.

• IMPulse научился перечитывать (reload) конфигурацию без полной перезагрузки. Также вы можете добавить проверку конфигурации в CI/CD перед её применением.

• В UI теперь есть индикатор online / offline, чтобы понимать, актуальная ли сейчас информацию на экране. К слову, несмотря на внешнюю простоту, UI очень гибок: умеет фильтровать инциденты по лейблам (в качестве фильтров можно использовать regex'ы), можно сортировать инциденты по нескольким столбцам, а также выделять цветом интересующие данные.

• В случае заполнения диска, IMPulse теперь продолжит работать. Обновления по инцидентам будут храниться в оперативной памяти пока не появится место на диске. Настройте алерты на ERROR логи, чтобы вовремя среагировать.

Планы

В первой статье я уже упоминал, что мы считаем крайне важным для всех, кто работает с инцидентами, иметь общий контекст. Многие решения при проектировании принимались, исходя из этого. Сейчас можно констатировать, что ChatOps стал основой IMPulse и дальнешее движение будет под этим знаменем. Мы будем глубже интегрироваться с мессенджерами, чтобы команде дежурных / devops'ов не нужно было переходить в UI. Да, обязательно останутся задачи, которые не решить в рамках мессенджера, но мы постараемся минимизировать их количество.

Здесь часть из наших планов на ближайшие пару месяцев:

• добавить работу с группами в Slack и Mattermost;

• добавить в UI механизм аутентификации;

• перенести кнопки для работы с инцидентами в UI;

• реализовать механизм подавления инцидентов на основе правил по аналогии с Inhibition в Prometheus. Если согласно правилам инцидент становится дочерним, то уведомления по нему прекращаются пока не будет решена основная проблема. Это позволит уменьшить количество активности по инцидентам.

По поводу других новшест мы пока сохраним интригу!

Критика и советы

Мы растём, решаем всё больше проблем, но конечно же всегда остаются незакрытые потребности. Будем рады услышать, чего не хватает лично вам и постараемся с этим помочь. Особенно интересно услышать мнение людей, которые ищут куда мигрировать с Grafana OnCall. Мы открыты к обратной связи и критике, будем рады услышать замечания. Наша задача - стать лучше благодаря сообществу.

Оставайтесь с нами в Telegram - мы используем его для общения с русским сообществом, следите за обновлениями в GitHub. Мы продолжаем!

Предыдущие публикации

• IMPulse — наш взгляд на менеджмент инцидентов

• Интеграция с Telegram

• Интеграция с Google Calendar, вложенные цепочки эскалации

Новогодняя задача: помогите Тирексу поздравить коллег

Условие

Программист Тирекс написал праздничное веб-приложение с обратным отсчетом до Нового года и хочет поздравить им всех коллег. Приложение уже собрано: в директории web находятся готовые статические артефакты (HTML, JavaScript и изображения). У Тирекса есть TLS-сертификат и приватный ключ, и он хочет, чтобы приложение работало по HTTPS.

Задача

Нужно упаковать приложение в Docker-контейнер, чтобы его можно было легко запускать на любом сервере, и сделать доступным из интернета. Времени у Тирекса осталось совсем немного!

Создайте конфигурацию nginx, которая:

• слушает порт 80 и выполняет 301-редирект на HTTPS (https://$host$request_uri);

• слушает порт 443 с включенным SSL;

• использует сертификат /etc/nginx/ssl/cert.pem и ключ /etc/nginx/ssl/key.pem;

• отдает статические файлы из /usr/share/nginx/html по пути /.

Напишите Dockerfile, который:

• копирует в  контейнер конфигурацию nginx и артефакты приложения

• создает пустую директорию /etc/nginx/ssl (для монтирования сертификатов при запуске);

• использует легкий образ (например, nginx:alpine).

При запуске контейнера должны быть опубликованы порты 80 и 443.

Бонусная задача

Добавьте docker-compose.yml файл, чтобы запускать приложение одной короткой командой из папки с сертификатами.

Предлагайте варианты решения в комментариях. А посмотреть правильный ответ можно в Академии Selectel.

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

Описываю позитивные практики, с которыми сталкивался, практики за которые я уважаю потенциальных работодателей и команды. Это парадигма, в которой я вёл деятельность с начала карьеры.

1. Диалог на равных.
   Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

2. Проверка логики, а не памяти.
   Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

3. Ценность универсальных знаний.
   Универсальные знания долгое время позволяли быстро находить решение практически любой проблемы от хардверной, до нарушения самых элементарных паттернов проектирования в коде и эффективно их устранять. Мне нравятся задачи, где проблема может быть скрыта на любом уровне и нравятся клиенты, понимающие, как я могу снять их головную боль обеспечив работоспособность ПО в любой среде и условиях.

А теперь я хочу описать то, от чего меня бомбит. Это факторы которые будут отпугивать меня вплоть до момента, когда будет нечего кушать и я буду вынужден прогнуться под выгодное предложение.

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

2. Вакансии-обманки.
   Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

4. Отсутствие пунктуальности.
   Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

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

Запуск GitLab Runner в Yandex Cloud Serverless Containers

Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.

GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.

Раннер работает в разных окружениях:

• на общих серверах GitLab (shared runners);

• на выделенных VM;

• в K8s‑кластере.

В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.

Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.

Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:

• оплата за время

• масштабирование за секунды

• изоляция выполнения

• отсутствие инфраструктурной рутины

Архитектура

GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.

Пришла задача — раннер выбирает executor:

• shell — job выполняется в текущем окружении

• docker — под job создаётся отдельный контейнер со всеми зависимостями

Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.

Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:

• запускает раннер;

• получает информацию о задаче;

• выполняет её и возвращает результат в GitLab.

Так, выполнение задачи инициируется событием, а не постоянным опросом API.

GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:

1. GitLab отправляет вебхук.

2. Платформа проверяет авторизацию и сразу отвечает 202 Accepted.

3. Обработка выполняется асинхронно в фоне.

Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.

GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.

Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.

Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.

Используемые возможности Serverless Containers

1. Эфемерные диски до 10 ГБ на контейнер

2. Асинхронный запуск контейнеров

3. Таймаут выполнения до 1 часа

4. Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.

Важные особенности serverless‑подхода

• Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.

• Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.

• Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.

• Ограничение по диску: до 10 ГБ.

Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.

• Руководство

• Исходный код

Друзья, классная новость! Мы с коллегами из GitVerse закончили разработку интеграции! 

Теперь в Gramax можно подключить GitVerse в качестве хранилища. Работает в лучшем виде: клонирование, синхронизация, коммит, пуш — все как и должно быть ✨

Это была масштабная и интересная работа: мы вместе анализировали API, чтобы получилось максимально удобно. Потому будем очень рады увидеть ваши плюсики!

Gramax — Open Source-платформа для работы с документацией в подходе Docs as Code. GitVerse — AI-first платформа для работы с кодом.

Небольшое дополнение к статье про Raspberry Pi

Недавно я написал статью про небольшой домашний стенд на Raspberry Pi и Orange Pi: Tailscale, Ansible, Nginx и базовую автоматизацию.
В процессе чтения комментариев решил сделать несколько улучшений. Особенно благодарен комментариям от @Tony-Sol

Первое, что сделал — убрал root из inventory.

ansible_user=root Не надо так, лучше создать отдельного пользователя

На обеих машинах завёл отдельного пользователя ansible и команды на хосте:

sudo adduser ansible

sudo usermod -aG sudo ansible

echo 'ansible ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/ansible

sudo chmod 440 /etc/sudoers.d/ansible

2. Создание роли

Такие штуки как установка и конфигурация сервисов, лучше размещать в отдельные роли, а в плейбуке уже собственно подключать нужные роли

Теперь создал роль и подключил ее в основной плейбук:

• tasks / handlers / templates разнесены по каталогам;

• apt заменён на package;

• state: latest → present;

• become используется только там, где реально нужен;

• проверка конфига вынесена в handler через nginx -t.

Отдельно напишу вещь, на которой споткнулся:
host_vars/<имя>.yml работает только если имя совпадает с inventory_hostname.
У меня хост назывался orange, а файл был pi2.yml — из-за этого Jinja-шаблоны молча брали дефолты.

3. ansible.cfg — мелкие, но полезные настройки

Добавил минимальный ansible.cfg в проект:

• roles_path=./roles;

• gathering=explicit (факты включаю только там, где нужны);

• небольшие SSH-настройки для стабильности.

vault_password_file имеет смысл добавлять только когда реально используется vault, иначе Ansible начинает ругаться.

4. Добавил на Raspberry Pi Мониторинг: VictoriaMetrics + Grafana

Мониторинг вынес на более мощную Raspberry Pi, а Orange Pi оставил агентом:

• VictoriaMetrics + Grafana в Docker Compose;

• node_exporter на обоих устройствах;

• сбор метрик через static targets.

В итоге стенд стал аккуратнее.

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

Привет, Хабр! Тем, кому регулярно приходится заглядывать в etcd — будь то QA, поддержка или разработчики — хорошо знакома ситуация, когда нужно разобраться с неожиданным состоянием сервиса, проверить конфиги или найти застрявший лок. И каждый раз всё сводится к одному: копировать ключ, запускать etcdctl get, читать многострочный JSON в терминале, ошибаться в пути… и в какой-то момент понимаешь, что это однообразие выматывает больше, чем сама проблема.

Поэтому наш коллега из Хайстекс сделал небольшой TUI-инструмент, который заметно упрощает работу с etcd и делает её куда дружелюбнее для тех, кто каждый день копается в окружениях. Он снимает рутину etcdctl, даёт привычную “каталожную” навигацию, подсвечивает скрытые _-ключи, позволяет комфортно открывать большие конфиги и помогает разбираться с локами, которые любят появляться в самых неожиданных местах.

Если вы в QA, поддержке или просто часто работаете с etcd, этот инструмент легко сэкономит вам время и нервы.

Статью можно прочитать здесь.

Уровень загрузки ресурсов (Percentage Resource Utilization)

Уровень загрузки ресурсов помогает быстро понять, насколько действительно используются выделенные мощности. Это один из самых простых и при этом самых рабочих способов найти неоптимальности в инфраструктуре. Компании начинают применять его ещё до формального внедрения FinOps, просто потому что здравый смысл подсказывает: если сервис использует 5% ресурсов, есть повод что-то менять.

Мы смотрим на три базовых показателя. Это CPU, память и диск. Этого достаточно, чтобы увидеть общую картину. Да, в инфраструктуре есть и другие ресурсы, например трафик, но для первичной диагностики хватает именно этих трёх.

Как считается

➖  CPU: использованные ядро-часы / количество выделенных ядер

➖  Память: фактическое потребление в гигабайтах / выделенный объём

➖  Хранилище: используемые GB / выделенное пространство

Что даёт этот анализ

Когда компания оценивает уровень загрузки, она перестаёт работать на предположениях и начинает принимать решения на фактах. На практике это чаще всего приводит к трём сценариям.

1. Команда отказывается от ресурсных объектов, если загрузка держится на уровне нескольких %.

2. Команда объединяет инфраструктуру. Например, три виртуальные машины загружены по 20% каждая, их сводят в одну, а две отключают.

3. Команда корректирует конфигурацию. Это классический rightsizing, когда сервису просто уменьшают объём ресурсов, потому что реальная нагрузка намного ниже.

Это базовый навык, с которого начинается оптимизация в любой компании. Он одинаково полезен и в публичных облаках и в частных инфраструктурах. И независимо от уровня зрелости, компании, которые работают с фактической загрузкой, быстрее находят резервы, снижают расходы и точнее планируют будущие потребности. (Источник: FinOps Foundation).

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Уже в следующий вторник — развернем Kubernetes-кластер за 15 минут

2 декабря в 11:00 по мск подключайтесь к next-next-next инсталляции кластера из GUI.

После нее пройдемся и по другим обновлениям релиза «Штурвал 2.12»:

• Изменение UI создания кластера: статусная модель и контроллер управления кластерами.

• Развертывание на OpenStack с использованием нативных балансеров и сертификатов Let's Encrypt.

• Поддержка Cinder CSI и Ubuntu 24.04.

Вебинар будет интересен DevOps-инженерам и архитекторам, разработчикам, специалистам служб эксплуатации.

Регистрация

Яндекс.Облако легло вместе с половиной интернета

Если во вторник утром сервисы Яндекса работали у вас через раз, знайте, что вы такой не один. Мы в Практиках FinOps тоже смотрели на ошибку 504 и думали, что это у нас что-то сломалось. А оказалось, это ru-central-1b упал. Поэтому полетело все, что там крутилось: Аптека.ру, КИОН, ФНС и много кто еще.

К обеду все починили. Только вот Яндекс такой не один. Последние недели облачные провайдеры падают один за другим как доминошки. То AWS накроется, то Azure, то Cloudlfare. То есть, по сути, даже неважно, где вы хоститесь: cloud-native компании накрывает независимо от географии.

На бумаге аптайм в 99,95%, обещанный провайдерами, выглядит очень привлекательно, но на практике оказывается так, что даже одна упавшая зона может положить десятки сервисов. Причем происходит это, как правило, именно в самый неудобный момент как у Яндекса: утро понедельника, пиковая нагрузка, куча клиентов. И тут бац — лежим. Тут волей-неволей задумаешься о том, чтобы уйти в гибрид.

Да и почему бы, собственно, нет? Гибридная инфраструктура сейчас – это отнюдь не перестраховка параноиков, а более чем здравый подход, который позволяет разместить все самые критичные сервисы на собственных серверах. Упала зона — половина продолжает работать. А если FinOps применим к гибриду не хуже, чем к облаку, оснований отказываться от него фактически и не остается.

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.

Как настроить очереди задач в Redis

Автоматизация очередей задач — типовая задача для IT-разработчиков и DevOps-инженеров, которые работают с распределенными системами.

Подготовили пошаговую инструкцию, как реализовать очереди в Redis тремя способами: Pub/Sub для событий «здесь и сейчас», List для классического FIFO и Streams — с историей сообщений и группами потребителей. Внутри инструкции — как подготовить окружение, написать издателя и подписчика на Python, работать с last_id и блокирующим чтением.

Подробности — в базе знаний Рег.облака.

⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки

Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.

🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.

💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.

Наталья Романова, директор по развитию ITFB Group:
«Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».

📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.

Подробнее о KODA — на сайте ITFB Group.

Вебинар про мониторинг в Deckhouse Kubernetes Platform: от архитектуры до расследования инцидентов

В эту пятницу, 28 ноября в 12:00, разберём мониторинг в DKP на реальных кейсах. 

Внутри вебинара:

• концепции мониторинга DKP и чем они отличаются от стандартных подходов;

• как мультитенантность и веб-интерфейс делают работу проще;

• практические примеры расследования и локализации инцидентов с готовыми инструментами.

Спикер — Владимир Гурьянов, технический директор продуктового направления Observability. 

Регистрируйтесь и подключайтесь к эфиру. Будет интересно тем, кто уже использует DKP или только присматривается к ней. Покажем, что платформа умеет больше, чем вы думаете. Особенно в части мониторинга.

4 раунда за 2 недели собеседований → оффер в пятницу → отказ в понедельник.
Причина?
Мой чертов LinkedIn, который я не обновлял пару лет.

Все любят истории успеха 🙃
Но вот вам история НЕ-успеха - и при этом моя собственная.

За последние 2 недели прошёл:
🟢 HR-интервью
🟢 Техническое интервью (жёсткое, но честное)
🟢 Интервью с командой
🟢 Интервью с CPO
🟢 Получил оффер. Подтвердили, что всё ок.

В пятницу вечером в почте лежал «Welcome aboard».
Я, честно - обрадовался. Уже mentally onboarded. И самое !главное! крутая команда, крутые задачи впереди, возможность строить инфраструктуру с нуля и возможность топить в ИБ (реальную а не бумажную) - ну восторг жеж. Да я уже запланировал фаст-вины на первые 30 дней!

А в понедельник приходит письмо:
«СТО принял решение не двигаться дальше. Ваш опыт в резюме не соответствует тому, что в LinkedIn».

Что?! Какого?!
LinkedIn, который я не вёл несколько лет?
Площадка, которую большинство инженеров обновляет раз в эпоху?

Я объяснил, что могу подтвердить опыт трудовой, рекомендациями, стеками проектов, GitLab’ами, CI/CD пайплайнами - чем угодно.
Ответ:
«Решение финальное».

И вот честно - я не злюсь. (да что уж там, бесился первые пол часа)
Но вся эта ситуация подсветила кое-что важное:
Нужно делать то, что приведет напрямую к приему на работу, я повторил всю теорию, прошелся по практике - а надо было резюме пилить.

*Мой личный инсайт* В эпоху, когда DevOps пишет IAC, придумал собственный термин, что карьера тоже - Career As a Code, и её надо поддерживать.

Так что да: обновляю LinkedIn.
Да: выкладываю эту историю.
Да: остаюсь мотивирован строить системы, усиливать DevOps и DevSecOps, выстраивать безопасность, SRE, процессы, документирование, хаос-устойчивость - всё то, в чём я реально силён.

Может я единственный, кто еще живет по старому, а все остальные давно проснулись в матрице?

Как часто вы обновляете ЛН?

Как научить команды экономить IT-бюджет: 3 рабочих совета

Хотите довести финдира до нервного срыва? Просто не отключайте на выходные тестовые инстансы, а еще лучше – разверните staging на том же железе, что продакшен. А когда счет за облако придет на 800 тысяч вместо 300, спросите: "А при чем тут я?".

Нет, это не вредные советы Г. Остера, это жизнеописание большинства компаний, которые не в курсе культуры разумного потребления ресурсов.

Вот как все исправить (подробности – тут):

Метрики затрат в Grafana. Если стоимость работы кластера отображается рядом с загрузкой CPU и потреблением памяти, разработчик реально видит, что во что обходится. Случился скачок расходов на графике — значит, надо разбираться. Только на этом можно сэкономить 20-30%.

Калькулятор стоимости в PR. Штуки типа Infracost смотрят на изменения в инфраструктурном коде и прямо в Pull Request пишут, во что это выльется. Так можно отсекать слишком дорогие вещи еще на этапе ревью.

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

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.

В июле я писал о том, что Gaunt Sloth Assistant дошёл до версии 0.9.2. Сегодня мы наконец можем сказать, что вышла версия 1.0.0. В этом релизе мы перевели основную зависимость на LangChain/LangGraph v1, обновили минимальные требования до Node 24/npm 11 и официально объявили CLI готовым к повседневной автоматизации.

Что изменилось с прошлого поста?

• Ревью теперь завершаются вызовом встроенного рейтингового инструмента. По умолчанию шкала 10/10, порог прохождения 6/10, и оценки ниже 6 заставляют команду review возвращать ненулевой код (non-zero exit code). Если нужен только режим предупреждений, установите commands.review.rating.enabled (и/или commands.pr.rating.enabled) в false в .gsloth.config.*.

• Профили идентичности стали частью базового сценария: один флаг -i profile-name, и вы переключаете промпты, модели и провайдеры на уровень нужной папки.

• Middleware теперь сущность первого класса. Можно комбинировать встроенные варианты вроде anthropic-prompt-caching или summarization, подключать собственные объекты на JS, а CLI показывает, что именно выполняется при каждой команде.

• Глубокое слияние конфигов команд устранило проблему, когда переопределение источника контента стирало настройки рейтинга. Теперь значения по умолчанию сохраняются даже при частичных правках.

• Мы освежили кеш OAuth, документацию и README, чтобы новичкам было проще стартовать, и параллельно усилили безопасность зависимостей.

Профили идентичности — главный QoL‑апгрейд 1.0.0. Они позволяют мгновенно переключаться между системными промптами, пресетами моделей и наборами инструментов под конкретную задачу. gth pr 555 PP-4242 по‑прежнему читает .gsloth/.gsloth-settings, а gth -i devops pr 555 PP-4242 автоматически берёт конфиг из .gsloth/.gsloth-settings/devops/ со своими промптами и провайдерами.

Нужно поговорить с Jira через MCP? Создайте профиль вроде jira-mcp со своим конфигом и запустите gth -i jira-mcp chat. Укороченный пример:

{
  "llm": {
    "type": "vertexai",
    "model": "gemini-2.5-pro"
  },
  "mcpServers": {
    "jira": {
      "url": "https://mcp.atlassian.com/v1/sse",
      "authProvider": "OAuth",
      "transport": "sse"
    }
  },
  "requirementsProviderConfig": {
    "jira": {
      "cloudId": "YOUR-JIRA-CLOUD-ID-UUID",
      "displayUrl": "https://YOUR-BUSINESS.atlassian.net/browse/"
    }
  },
  "commands": {
    "pr": {
      "contentProvider": "github",
      "requirementsProvider": "jira"
    }
  }
}

Переключение между такими папками теперь — один флаг, поэтому удобно держать отдельные персоны для DevOps, документации или любого удалённого MCP.

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

Наконец, реестр middleware и хранилище артефактов дают аккуратные точки расширения на будущее. Можно оборачивать вызовы моделей и инструментов, логировать каждую операцию и при этом оставлять Gaunt Sloth вести те же chat/code/pr/init команды. CLI как и раньше — небольшой TypeScript‑бинарь, который устанавливается через npm или запускается npx gth, но теперь у него архитектура, позволяющая развиваться без костылей.

Хотите попробовать релиз — быстрый путь всё ещё
npm install -g gaunt-sloth-assistant

репозиторий https://github.com/Galvanized-Pukeko/gaunt-sloth-assistant пригодится как справочник и место для issues. Заводите issue, оставляйте фидбек в Discussions или подключайте rater к своему CI и расскажите, как он себя ведёт — буду рад помощи в движении к 1.1.

Спасибо всем, кто помог тестами и несколькими PR.

Минималистичные healthcheck-утилиты для Docker-контейнеров

Однажды я был маленький, и задавался вопросом - вот собираешь ты свое приложение, нежно помещаешь его в Docker-образ, заботишься о том чтоб и зависимостей было поменьше, и скомпилируешь его так чтоб итоговая каша из байт было погуще, но покомпактее; используешь scratch, статическую линковку, но чтоб "из коробки" был еще и healthcheck - приходится или писать свой мальний чекер каждый раз, или тянуть статичкски слинкованный curl/wget, если приложение работает как http сервер.

Потому что без healthcheck жизнь ну совсем не торт, даже при локальной разработке, когда запускаешь уже готовые образы, ставишь их в зависимость для других (в том же docker compose) - без него это все работать не будет так, как тебе хочется - демоны будут стучаться друг к другу без уважения и учета, готово оно в этому или нет.

Так родился microcheck - набор крошечных статически скомпилированных бинарников, созданных специально для healthcheck-ов. Они не имеют зависимостей от динамических библиотек, написаны на C, и работают даже в scratch и distroless образах, да умеют корректно возвращать exit-коды, понятные Docker’у (0 - здоров, 1 - приходи завтра).

В комплекте:

• httpcheck — проверка HTTP-эндпоинтов (~75 KB)

• httpscheck — то же самое, но с TLS и автоопределением протокола (~500 KB)

• portcheck — проверка TCP/UDP-портов (~70 KB)

У вас в продакшене наверняка Kubernetes, и все проверки делает kubelet - скорее всего, вам не нужно ничего менять. Но если вы запускаете контейнеры в «голом» Docker’е или других рантаймах без встроенных healthcheck-ов - такие инструменты могут здорово упростить жизнь.

Как выглядит в деле:

# Было (+~10MB)
RUN apt update && apt install -y curl && rm -r /var/lib/apt/lists/*
HEALTHCHECK --interval=10s CMD curl -f http://localhost:8080/ || exit 1

# Стало (+~75KB)
COPY --from=ghcr.io/tarampampam/microcheck /bin/httpcheck /bin/httpcheck
HEALTHCHECK --interval=10s CMD ["httpcheck", "http://localhost:8080/"]

Разница по размеру в десяток мегабайт против семи десятков килобайт, а в качестве бонуса - не нужен shell-процесс, всё работает напрямую и быстро (а еще и в переменные окружения умет).

Поддерживаются все популярные архитектуры (x86_64, ARM, ppc64le, s390x и др.), есть готовые образы в GitHub Container Registry и Docker Hub.

Посмотреть исходники, примеры Dockerfile и prebuilt-бинарники можно тут: github.com/tarampampam/microcheck

Фишки FinOps Radar: бесплатная платформа, которая помогает экономить в Yandex Cloud

Как говорили в старину, с FinOps Radar и облако милее

Облако – вещь удобная, но непредсказуемая. Особенно, если вести учет расходов по-старинке, в Excel. Таблички, конечно, работают неплохо, но только в железной инфраструктуре. А в облаке без специальных инструментов никак.

FinOps Radar — это первый бесплатный сервис для оптимизации расходов в Yandex Cloud.

Что он умеет:

Обнаружение аномалий. Сервис сравнивает текущие расходы с расходами за последнюю неделю. Если траты выросли больше чем на 5% от среднего, система помечает это цветом. Желтый — рост 5-10%, все что выше – красный. Можно сразу открыть детализацию и понять, какой сервис съел бюджет.

Поиск зомби-ресурсов. Это все то, за что вы платите впустую: забытые инстансы, неприсоединенные диски и т.д. Платформа показывает сумму потенциальной экономии по каждой позиции. 

Автоалерты. Письма об аномалиях приходят в 05:00, о новых рекомендациях — в 09:00. Можно даже выгрузить отчет в Excel и в конце месяца показать начальству, сколько денег сэкономили.

Главное — сервис ничего не трогает в вашей инфраструктуре. Только смотрит и советует. У него даже прав таких нет. Вы даете доступ только для чтения, он собирает данные и показывает проблемы. А как на них реагировать — решаете сами. 

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Присоединяйтесь к вебинару про виртуализацию, контейнеризацию и системы резервного копирования

Завтра, 12 ноября, в 11:00 менеджер продукта и архитектор инфраструктурных решений Deckhouse проводят совместный вебинар с командой «Мобиус Технологии». Со своей стороны представим Deckhouse Virtualization Platform. Расскажем, как платформа помогает решать задачи миграции с монолитов на микросервисы и запускать кластеры Kubernetes как сервис. А ещё проведём демо возможностей DVP в реальной инфраструктуре и разыграем подарки.

Также в программе:

• обзор последних новостей рынка виртуализации и систем резервного копирования;

• знакомство с наиболее зрелыми российскими альтернативами западным платформам;

• кейсы по внедрению серверной виртуализации и виртуализации рабочих мест пользователей.

В конце вебинара будет Q&A-сессия, чтобы ничьи вопросы по теме не остались без ответов. Регистрируйтесь и подключайтесь!

Ссылка на пост в телеграм