DevOps *

Я пользуюсь Hermes Agent уже месяц. Всё это время работал через командную строку (WSL) потому что на windows версии не было, Конечно, уже это довольно ощутимое ограничение, так как Hermes не имел полный выход к файлам в Windows, за это время свыкся с терминалом запускал через hermes chat. недавно вышла версия v0.15.2, и вместе с ней десктопный установщик на Electron. Windows, macOS, Linux.

Скачал, поставил, пошёл по настройкам. Оказалось, что в GUI тринадцать разделов, и каждый из них что-то решает. Ниже — гайд по тому, как можно оптимизировать настройки под себя.

Большинство проблем с SSL-сертификатами возникает не при настройке TLS, а на этапе создания CSR: забытые SAN-домены, неправильные ожидания от wildcard, ручные ошибки в openssl.cnf. Разбираем, почему с сокращением срока действия сертификатов до 47 дней к 2029 году ручной выпуск перестаёт быть жизнеспособным, и какие инструменты приходят ему на замену.

Часть своих сервисов я держал в облаке, но когда счёт за AWS начал превышать ожидания, стало понятно: пора переносить их домой. Несколько месяцев назад я купил мини-ПК, но всё никак не находил времени его задействовать. Так я занялся решением проблемы локального деплоя.

Сегодняшний инцидент войдет в историю как интересный кейс «ошибки начисления». Чтобы спасти пользователей от некорректных списаний, облако просто заблокировало ресурсы (в моем случае, так как списалось слишком много).

Важный ворнинг: ваши виртуалки сами не поднимутся. Надо запустить после инцидента вручную. 

Привет, я Сергей Истомин, DevOps-инженер в KTS. А ниже моя история про построение мультитенантного скоупа кластеров VictoriaMetrics с разными периодами хранения метрик.

Статья будет о том, как собрать систему одновременно и простую, и сложную. Простую потому, что каждый поток данных в ней лаконичный и линейный, и сложную потому, что совокупности этих потоков комбинируются и интегрируются в общие компоненты. Система будет построена на редакции Community Edition.

Надеюсь, что я вас хорошенько запутал и при этом заинтриговал.

Привет, Хабр! На связи Даниэль из InfoWatch, разработчик решений класса информационной безопасности. В предыдущей статье мы рассматривали задачу контроля целостности в среде Linux с помощью системного интерфейса inotify. Поговорили о ключевых недостатках, с которыми приходится сталкиваться в ходе работы с самим инструментом напрямую.

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

Введение

Начнём с краткой сводки по fanotify. fanotify представляет собой kernel-интерфейс, позволяющий мониторить события файловой системы в режиме реального времени. Определение такое же, как и для inotify. Почти. Существенная разница в том, что список обрабатываемых событий у fanotify гораздо шире, а также есть возможность принимать решение kernel-характера в user space. Простыми словами: вы можете разрешать/запрещать запуск программ без написания драйверов (модулей ядра), так как fanotify позволяет разрешить/запретить создание процесса в пользовательском пространстве.

Привет, Хабр! Меня зовут Виктор Лучиц, я архитектурный лид в отделе инфраструктурной разработки рекламных технологий VK. Я расскажу, как наша команда осуществила конвергенцию двух наших core-технологий, как справлялись с инцидентами и что в итоге получили.

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

Привет, Habr!

Мы разрабатываем IncidentRelay - self-hosted систему для on-call scheduling, маршрутизации алертов и доставки уведомлений. Идея простая: дать командам SRE, DevOps, platform и operations понятный инструмент, который можно развернуть у себя, подключить к мониторингу и использовать без зависимости от внешней incident-management платформы.

В статье — разбор основ Ansible: как писать идемпотентные плейбуки, не класть продакшен сухими прогонами и встроить Ansible в CI/CD.

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

Когда я начал пользоваться Claude Code, у меня было ощущение, что я дал умному человеку доступ только к одной папке на компьютере. Он видит код, помогает с задачами — но не знает, что происходит снаружи. Нет доступа к чатам, к базе данных, к GitHub issues. Всё это приходилось копировать руками и вставлять в контекст.

Потом я узнал про MCP.

Вчера pypi.org несколько часов был недоступен из российских сетей. Для кого-то это «подождём», а для CI/CD, прода и просто рабочего дня — это вставший pip install и красные сборки.

Причина системная: pypi.org и хранилище пакетов files.pythonhosted.org живут на CDN Fastly, у которого нет точек присутствия в России и доступ к которому уже не раз ограничивался. Вчерашняя недоступность — не первая и почти наверняка не последняя.

Хорошая новость: чтобы застраховаться, не нужно зеркалировать весь PyPI (это терабайты и постоянная синхронизация). Достаточно поднять лёгкий реверс-прокси на nginx. В этом гайде соберём такой с нуля — с кешированием и прозрачным переключением для pip.

Не хотите хостить сами? Есть уже готовое зеркало — pypi.depkit.ru. Оно работает на российских IP, имеет большой объём кеша под пакеты и отдаёт их очень быстро. Можно просто подставить его в index-url (как — в конце статьи) и пропустить всю настройку. Дальше — для тех, кому интересно поднять своё.

На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.

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

Команда VK Cloud перевела статью для тех, кто разбирает инциденты в Kubernetes с помощью kubectl debug. Автор разбирает незаметный пробел в данных: после завершения debug-сессии API Kubernetes не сохраняет контекст ее завершения — код возврата, длительность сессии и целевой контейнер исчезают при первом же изменении состояния пода. В статье как воспроизвести это тремя командами, почему так устроено на уровне спецификации API, чем это грозит при разборе инцидентов и комплаенсе и что можно сделать уже сегодня.

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

Но довольно быстро стало понятно, что с временными и ресурсными ограничениями лучше не пытаться написать маленький PagerDuty. Поэтому я сузил задачу до более реалистичного ядра: локального RAG-сервиса, который ищет по документации, ранбукам и коду, а затем передаёт найденный контекст в LLM.

Так появился llmortem — FastAPI-сервис, который можно подключить к OpenWebUI как OpenAI-compatible backend.

В статье расскажу, как устроена архитектура, почему я начал с BM25, зачем индексировать docstring’и и какие ограничения у такого подхода.

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

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

Привет, Хабр! В этой статье разбираем плюсы и минусы VictoriaLogs как решения для логирования в облачной платформе.

На демо всё красиво: задачки бегают, доски сияют, отчёты рисуются. Через полгода команда уточняет статусы в чате, релизы сверяет в таблице, а тимлид перед стендапом открывает пять вкладок. Разбираем четыре ошибки выбора системы управления разработкой и даём чеклист из 12 вопросов, которые стоит задать до покупки.

1.   Введение

Всем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.

Когда я пришел в компанию около года назад, система мониторинга уже существовала и закрывала базовые задачи. В наборе технологий использовались Prometheus, Thanos, Alertmanager, Grafana, Elasticsearch и различные наборы оповещений. Со временем количество компонентов и инструментов увеличилось, что усложнило их сопровождение и масштабирование.

В этой статье я расскажу, как происходила миграция мониторинга в Kubernetes, почему в качестве основной базой данных временных рядов (Time Series Database, TSDB) была выбрана Victoria Metrics, как мониторинг связали с Gitlab и Argo CD, пересобрали систему оповещений (alerting) и начали постепенно двигаться от инфраструктурного мониторинга к сервисному подходу и практикам обеспечения надёжности сервисов (Site Reliability Engineering, SRE). 

2. С чего все начиналось.

Изначально мониторинг представлял собой связку Prometheus, Thanos, Alertmanager, Grafana и Elasticsearch. Разворачивалось все через Docker Compose на отдельных серверах, а сама система постепенно росла вместе с инфраструктурой.

Docker уже давно перестал быть «модной новинкой» и превратился в минимум для любого бэкендера, DevOps-инженера или QA. Строчка с Docker есть почти в каждом резюме, поэтому на собеседованиях технические специалисты любят копать глубже.

Вызубрить десяток флагов для docker run — недостаточно. Интервьюеры хотят видеть, что вы понимаете саму архитектуру контейнеризации: как работает изоляция процессов, почему данные внезапно исчезают после рестарта, чем слои отличаются от томов и что будет, если PID 1 внутри контейнера завершит работу.

Привет, Хабр! Меня зовут Михаил, я backend-разработчик в команде Managed Kubernetes в VK Cloud. При работе с K8s всем нам приходится сталкиваться с множеством конфигураций, которые мы используем постоянно, и Service не является исключением. И вот тут мне стало любопытно: а может ли с виду безобидный конфиг Service сломать нам весь кластер? Ну или хотя бы подпортить жизнь какому-то сервису?

Зачем мне это? Во-первых, это просто интересно: сломать что-то, понять, как оно работает, узнать, как то, что кажется обыденностью, может стать проблемой. Во-вторых, если удастся что-то накопать, то мы получим список потенциальных ошибок нашего кластера и будем думать над способами защиты и обнаружения. Так что приступим!

Статья будет полезна DevOps, безопасникам, админам и просто юным любителям Kubernetes.