SRE.
Корпоративный RAG как MCP-сервис: подключаем кодовую базу к IDE
В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.
Kubernetes 1.29 → 1.33 за 30 минут: реальный апгрейд кластера с помощью ИИ под контролем инженера
Кратко о сути экспериментаМы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.
Как мы случайно сделали стартап, пока учили ИИ работать с реальной инфраструктурой
Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.Это было хорошо. Но довольно быстро стало понятно главное:Для реальной работы этого недостаточно.ИИ умеет говорить, но не видит, что происходит в системе
AIOps — как воображаемый strartup внедрил ИИ
Предисловие Давайте будем честны, современные подходы к выстраиванию алертинга и реагированию на инциденты в большинстве современных компаний оставляют желать лучшего:Тысячи алертов сыпятся в чаты, которые никто не читает;Постоянно создаются десятки разрозненных дашбордов, половина из которых устарела, а половина задезайнена так, что разобраться способен только их создатель;А если происходит сбой, то для выявления причины зачастую приходится собирать консилиум из DBA, сетивиков и инженеров всех смежных команд.
Как я перестал бояться алертов и полюбил дежурства
Привет! Меня зовут Егор, я DevOps/SRE-инженер с небольшим (2+ года) стажем. Ещё пару лет назад мои ночи были полны ужаса: телефон разрывался от PagerDuty, любое уведомление в чате заставляло подскакивать среди ночи, а кофе на 3 часа утра стал обычным делом. В прошлой статье – «Как я перестал тушить пожары и начал говорить с бизнесом на языке SLO» – я рассказывал, как мы внедрили SRE-подход: ввели SLO/SLI, настроили мониторинг по «золотым сигналам» и умные алерты
Как не потерять миллионы на SLA: архитектурный подход к управлению ожиданиями
Нарушение SLA — это условность, которую придумали поверх технических проблем. В IT-инфраструктуре любая техническая проблема быстро превращается в убытки, особенно если не умеешь правильно управлять доступностью. В этой статье расскажу, как на практике связаны инциденты и деньги, почему формальное соблюдение SLA — это ещё не успех, и как выстроить процессы так, чтобы бизнес не терял миллионы из-за минут простоя.Под капотом этой статьи — связь техники, архитектуры и менеджмента
SRE в инженерии данных: профессия и ее перспективы
Всем привет! Меня зовут Александр Андреев, я SRE дата-инженер. Сегодня я хочу рассказать о необычной, но набирающей обороты роли в области обработки данных - SRE Data Engineer: кто это такой, чем занимается, как им стать, куда развиваться и какие перспективы у этой профессии. ВведениеПредставьте ситуацию: пайплайн данных, который должен готовить критически важные отчеты, внезапно сломался. Есть всего несколько часов (в самом лучшем случае - дней), чтобы понять, что произошло, исправить проблему и убедиться, что данные будут готовы вовремя. А затем нужно автоматизировать процесс так, чтобы эта проблема больше не повторялась.
