SRE.
502 на ingress, 302 в приложении: как я учил инфраструктурного LLM-агента не врать
Сначала контекст. Я делаю внутреннего read-only агента для инфраструктурных расследований: он может читать данные, но не изменять production. Инженер пишет ему в Mattermost или резервном web-чате обычный вопрос: «почему сервис отдаёт 502?», «кто выкатил эту версию?» или «что изменилось перед инцидентом?». Агент сам собирает данные из Kubernetes, VictoriaMetrics, Elasticsearch, GitLab, Grafana, GSLB и других эксплуатационных источников, а затем возвращает ответ с доказательствами и явно перечисленными пробелами.
Когда AOL перестал работать (1996)
Представьте, что вы перенеслись в 7 августа 1996 года. Закройте глаза и вообразите мир, где напряжённость в отношениях с Россией, Китаем и Ближним Востоком высока, люди обеспокоены технологическим пузырём, а брюки-клёш снова в моде. Трудно представить, я знаю.
Как я сделал локальный RAG-сервис для SRE: ищем по документации, ранбукам и коду через Ollama
Недавно я делал учебный проект про автоматизацию документирования инцидентов. Поначалу планы были грандиозными: инциденты, таймлайны, интеграции с мониторингами, чатами, постмортемы, подсказки дежурным инженерам.Но довольно быстро стало понятно, что с временными и ресурсными ограничениями лучше не пытаться написать маленький PagerDuty. Поэтому я сузил задачу до более реалистичного ядра: локального RAG-сервиса, который ищет по документации, ранбукам и коду, а затем передаёт найденный контекст в LLM.Так появился llmortem — FastAPI-сервис, который можно подключить к OpenWebUI как OpenAI-compatible backend.
От Prometheus к Victoria Metrics: как мы пересобрали мониторинг в Kubernetes
1. ВведениеВсем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.
62 бесплатных урока июня: Java, Docker, LLM, SRE, DWH и другие темы для роста в IT
Привет, хабровчане. В июньском дайджесте собрали 62 бесплатных открытых урока по ключевым IT‑направлениям: разработке, архитектуре, инфраструктуре, информационной безопасности, тестированию, ML, аналитике и управлению. В программе — Java 21, Docker, Kubernetes, LLM, Kafka, SRE, DWH, Data Mesh, REST API, Linux, DevOps и другие темы, которые сейчас регулярно всплывают в реальных проектах и технических обсуждениях.
От Kubernetes до AI Engineering: 5 главных трендов Технологического радара DevOpsConf 2026
Каждый год индустрия генерирует десятки новых инструментов и практик. Для руководителей команд разработки (Team Leads, CTO) это означает постоянную головную боль при выборе технологического стека. Для практикующих инженеров — необходимость непрерывно обновлять свои навыки, чтобы оставаться востребованными на рынке.На DevOpsConf мы представили свежий техрадар, который позволяет не просто увидеть список популярных утилит, но и разглядеть тектонические сдвиги в индустрии.
Хроники Облачного княжества: как я приручал монолит‑дракона: Орден SLO и игла Кощея
Часть 3.Самая опасная магия в IT — это магия целей. Потому что цель легко обещает, а потом требует процентами отчёта.Есть особый вид страха, который появляется у инженера, когда два календаря совпадают.Первый календарь — релизный.Второй — организационный.И когда в один и тот же день на вас назначают «большую миграцию» и «большую презентацию результатов», реальность начинает пахнуть дымом ещё до того, как загорелся прод.Архимаг OKR стоял у проектора и рисовал стрелки.
Свое или чужое: почему и как мы делаем нашу хаос-платформу
Надежность инфраструктуры обычно существует где-то между красивыми SLO на слайдах и суровой реальностью продакшена. В Райффайзен Банке решили перестать верить в планы на бумаге и начали регулярно «ломать» собственные системы — осознанно и по науке. В этой статье руководитель команды разработки организации расскажет, как они пришли к хаос-инжинирингу, почему не смогли использовать готовые инструменты и как за несколько месяцев собрали собственную платформу для проверки отказоустойчивости и уверенности в том, что сервисы действительно выдержат сбои.
