Пятничный деплой
Open in Telegram
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest
Show more4 751
Subscribers
+324 hours
-17 days
+1030 days
Data loading in progress...
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+31
in 0 channels
August '26
+55
in 0 channels
Get PRO
July '26
+57
in 0 channels
Get PRO
June '26
+78
in 0 channels
Get PRO
May '26
+86
in 0 channels
Get PRO
April '26
+114
in 0 channels
Get PRO
March '26
+127
in 8 channels
Get PRO
February '26
+67
in 0 channels
Get PRO
January '26
+46
in 0 channels
Get PRO
December '25
+46
in 0 channels
Get PRO
November '25
+56
in 1 channels
Get PRO
October '25
+49
in 0 channels
Get PRO
September '25
+44
in 1 channels
Get PRO
August '25
+55
in 0 channels
Get PRO
July '25
+58
in 0 channels
Get PRO
June '25
+53
in 0 channels
Get PRO
May '25
+48
in 0 channels
Get PRO
April '25
+62
in 1 channels
Get PRO
March '25
+82
in 0 channels
Get PRO
February '25
+50
in 0 channels
Get PRO
January '25
+88
in 1 channels
Get PRO
December '24
+82
in 0 channels
Get PRO
November '24
+126
in 4 channels
Get PRO
October '24
+110
in 1 channels
Get PRO
September '24
+74
in 0 channels
Get PRO
August '24
+73
in 0 channels
Get PRO
July '24
+87
in 0 channels
Get PRO
June '24
+87
in 1 channels
Get PRO
May '24
+94
in 0 channels
Get PRO
April '24
+112
in 0 channels
Get PRO
March '24
+113
in 0 channels
Get PRO
February '24
+106
in 1 channels
Get PRO
January '24
+131
in 0 channels
Get PRO
December '23
+101
in 1 channels
Get PRO
November '23
+177
in 1 channels
Get PRO
October '23
+21
in 0 channels
Get PRO
September '23
+45
in 0 channels
Get PRO
August '23
+42
in 0 channels
Get PRO
July '23
+50
in 0 channels
Get PRO
June '23
+44
in 0 channels
Get PRO
May '23
+32
in 0 channels
Get PRO
April '23
+24
in 0 channels
Get PRO
March '23
+32
in 0 channels
Get PRO
February '23
+29
in 0 channels
Get PRO
January '23
+27
in 0 channels
Get PRO
December '22
+31
in 0 channels
Get PRO
November '22
+30
in 0 channels
Get PRO
October '22
+32
in 0 channels
Get PRO
September '22
+42
in 0 channels
Get PRO
August '22
+53
in 0 channels
Get PRO
July '22
+39
in 0 channels
Get PRO
June '22
+46
in 0 channels
Get PRO
May '22
+37
in 0 channels
Get PRO
April '22
+35
in 0 channels
Get PRO
March '22
+24
in 0 channels
Get PRO
February '22
+32
in 0 channels
Get PRO
January '22
+55
in 0 channels
Get PRO
December '21
+55
in 0 channels
Get PRO
November '21
+71
in 0 channels
Get PRO
October '21
+59
in 0 channels
Get PRO
September '21
+71
in 0 channels
Get PRO
August '21
+75
in 0 channels
Get PRO
July '21
+44
in 0 channels
Get PRO
June '21
+78
in 0 channels
Get PRO
May '21
+32
in 0 channels
Get PRO
April '21
+91
in 0 channels
Get PRO
March '21
+66
in 0 channels
Get PRO
February '21
+82
in 0 channels
Get PRO
January '21
+67
in 0 channels
Get PRO
December '20
+2 821
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 19 September | +1 | |||
| 18 September | +4 | |||
| 17 September | +2 | |||
| 16 September | +1 | |||
| 15 September | +2 | |||
| 14 September | +4 | |||
| 13 September | +5 | |||
| 12 September | 0 | |||
| 11 September | 0 | |||
| 10 September | +2 | |||
| 09 September | +1 | |||
| 08 September | +2 | |||
| 07 September | +2 | |||
| 06 September | +1 | |||
| 05 September | +1 | |||
| 04 September | 0 | |||
| 03 September | +1 | |||
| 02 September | +1 | |||
| 01 September | +1 |
Channel Posts
Repost from Мониторим ИТ
От firing до postmortem: рабочее место дежурного поверх Grafana и Mattermost
Алертинг у нас построен на правилах Grafana. Сами правила описаны в Terraform, хранятся в Git и применяются через CI/CD-пайплайн. Такой подход даёт review, историю изменений и воспроизводимую конфигурацию вместо ручного редактирования правил в интерфейсе. Дальше Grafana Alertmanager маршрутизирует уведомления по labels в несколько каналов внутреннего Mattermost. За этими каналами следит дежурная смена. В Grafana также есть отдельная доска, которая выводит активные алерты списком. Она помогла видеть общую картину, но не решила вопрос, что происходит с каждым алертом после доставки. Во время всплеска нужное сообщение иногда теряется среди десятков похожих. Некоторые алерты горят неделю, а обновления по ним появляются раз в несколько дней и каждый раз начинаются почти с нуля, как будто сигнал пришёл только что. Дежурные меняются и не всегда помнят, разбирали ли этот алерт раньше, занимается ли им другой инженер и кто сейчас ведёт исправление — инфраструктура или команда разработки. Получается своеобразная карусель: алерт продолжает гореть, люди меняются, а контекст приходится восстанавливать заново.В статье описан подход, при котором вокруг Grafana построен операционный слой: единая карточка алерта, назначение владельца, история повторных срабатываний, автогруппировка связанных алертов, метрики MTTA/MTTR и автоматическая подготовка postmortem с использованием LLM. При этом AI не принимает решений, а только помогает анализировать уже собранные данные — вся логика жизненного цикла алерта остается детерминированной. Очередное напоминание о том, что наблюдаемость — это не только сбор метрик, но и грамотно организованный процесс реагирования на инциденты. Читать на Хабре. 📱 Telegram | 📲 MAX
| 2 | Я долгое время считал, что подход/термин “Shift Down Security” появился в материале SIG Security Kubernetes в 2025 году. Но на самом деле корректнее считать 2023 год и статью ребят из Google Cloud под названием "The Modernization Imperative: Shifting left is for suckers. Shift down instead"!
Автор статьи критикует чрезмерное «shift left» — перенос на разработчиков всё большего числа задач: тестирования, безопасности, эксплуатации, релизов и т. п. Хотя раннее подключение QA и security полезно, но на практике это нередко превращает инженеров в перегруженных «универсалов».
Вместо этого он предлагает «shift down» подход : передавать сложность вниз, на управляемые платформы и абстракции. | 473 |
| 3 |  ⚡️ Поды здоровы, а запросы в Kubernetes случайно отваливаются? Проверьте conntrack.
Linux хранит состояния отслеживаемых соединений в таблице conntrack. Она используется в том числе при NAT для Kubernetes Services. Если таблица переполняется, новые соединения могут терять пакеты.
Симптомы: периодические тайм-ауты, сбои DNS и ошибки API при нормальных показателях приложений.
Как проверить на проблемном узле:
# Текущее число записей и лимит
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
# Сообщения ядра
sudo journalctl -k | grep -i conntrack
Характерная запись:
nf_conntrack: table full, dropping packet
Что делать:
• Увеличить лимит с учётом доступной памяти. Универсального значения для всех узлов нет.
• Проверить настройки conntrack.maxPerCore и conntrack.min в kube-proxy: он может управлять лимитом. Одного изменения через sysctl недостаточно для устойчивой настройки.
• Сократить создание новых соединений: использовать пулы, HTTP keep-alive, проверить лавину повторных запросов.
• Пересматривать тайм-ауты по состояниям соединений после диагностики. Слишком короткие значения могут нарушить работу долгоживущих подключений.
Следите за заполнением таблицы на каждом узле. Свободные ресурсы соседних нод не спасают таблицу перегруженной.
https://kubernetes.io/docs/reference/config-api/kube-proxy-config.v1alpha1/ | 685 |
| 4 | Toil в работе SRE. Измерять, или "мы и так знаем что работы дофига“?
Привет, киты 🐳. Поразмышляем.
Коротко про базу, чтобы синхронизировать понятия.
Что такое Toil?
По определению Google SRE, toil - это операционная работа, которая:
- ручная и повторяющаяся
- автоматизируемая
- реактивная, а не стратегическая
- не создает долгосрочной ценности
- масштабируется линейно с ростом сервиса
Toil и технический долг - одно и то же? Нет. Технический долг - это компромиссы в архитектуре/коде, которые усложняют будущие изменения. Toil - это операционные затраты на поддержку системы. Часто техдолг генерирует toil, но это разные категории. Погашение долга - engineering work, ручное обслуживание последствий - toil.
Плановые задачи vs задачи дежурства. Что из этого toil?
Не инструмент и не источник задачи определяют суть, а её характер:
- "Раз в неделю вручную чистить логи на 50 нодах" из беклога - toil.
- "Написать оператор для авто-очистки" - engineering.
- "Дайте доступ", "Почему не деплоится", "Перезапустите под" из дежурства - классический toil, особенно если повторяется.
Как понять, что пора автоматизировать?
1. Замерить. Без цифр всё субъективно.
2. Оценить ROI: время на разработку автоматизации vs время, которое она сэкономит.
3. Начать с простого: структурированный запрос -> бот -> подсказка или маршрутизация.
Именно так мы сейчас делаем: бот отвечает на частые вопросы разработчиков и зовет нужного специалиста (DevOps/SRE/DBA) в зависимости от контекста. Это классический первый шаг который предлагает Google.
Целевой toil ratio для SRE-команды по гайдлайнам Google - не более 50%. Остальное инженерная работа - проекты, которые уменьшают будущую рутину и повышают надежность.
🥸 Измеряете toil ratio у себя? Если нет - что мешает начать: отсутствие метрик, времени или просто неочевидна ценность?
#SRE #Toil #Автоматизация #ИнцидентМенеджмент #ЛетитКит #SLO | 834 |
| 5 | Ваши разрабы не хотят разгребать легаси и рефакторить кронтаски в отдельный scheduler с очередью?
У вас есть сотни кронтасок в проде, которые вы хотите таки контролировать в контейнерах?
У вас айсикью выше 70, раз вы все еще не описали каждую строку crontab в отдельном Kubernetes ресурсе (Job/Cronjob)?
тут уже говорили про недостатки крона
Supercronic пытается решить некоторые из них: кронтаски наследуют переменные окружения, выводит логи в stderr, логирует запуски результат выполнения и ошибки, посылает SIGTERM/SIGINT и что-то там еще.
Supercronic is a crontab-compatible job runner, designed specifically to run in containers.
Legacy не убить! | 853 |
| 6 | https://github.com/mezmo/aura смотрите какая штуковина | 918 |
| 7 |  OWASP выпустили Agent Memory Guard, защиту от одной из самых неприятных атак на AI-агентов: отравления памяти.
Проблема в том, что агент может сохранить вредоносную инструкцию в долгосрочную память, а потом продолжить выполнять её даже после очистки контекста. Обычные prompt injection-фильтры здесь уже не особо помогают.
Agent Memory Guard ставится между агентом и хранилищем памяти и проверяет каждую запись. Он умеет ловить prompt injection, утечки секретов и PII, попытки изменить защищённые ключи, аномально большие записи и циклы, когда агент начинает сам усиливать уже записанную вредоносную инструкцию.
Политики задаются через YAML, а подозрительную запись можно пропустить, замаскировать, отправить в карантин или полностью заблокировать. Есть снапшоты и rollback для восстановления памяти после атаки.
В опубликованном бенчмарке на 55 вредоносных payload'ах проект показывает 92,5% detection rate, 100% precision и медианную задержку всего 59 мкс.
GitHub: https://github.com/OWASP/www-project-agent-memory-guard | 1 060 |
| 8 | Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь????
В ноябре я писал про SRE Agent от PagerDuty: начинайте с read-only. Прошло десять месяцев, и спор сместился: уже не «заменит ли AI дежурного», а «где проходит граница». 24 августа в r/sre инженер после полугода on-call заметил одно и то же во всех обзорах AI SRE-инструментов: расследовать агенту дают одному, чинить - никто. Это навсегда?
Что говорят цифры
ORCA-bench, 30 июля, Cornell Tech, Columbia и Traversal (последние продают AI SRE-агента, держите в уме). Стенд: 19 микросервисов на OpenTelemetry, шесть дней телеметрии в Prometheus, Jaeger и OpenSearch, доступ к коду, 1 079 задач на root cause, пять фронтирных моделей. Лучшая точность RCA на задачах средней сложности (реалистичный ввод) - 25,3%, на сложных - 10,0%, разрыв сохраняется даже с Claude Fable 5. Слабейшая модель выдумывает неправдоподобную причину в 40% отчётов. Типичная ошибка: хватается за заметный симптом ниже по потоку вместо причины выше. Авторы называют это нижней границей: прод больше и грязнее стенда.
Комментатор в треде сформулировал точно: плохой анализ в худшем случае тратит ваше время, запись в прод без человека - катастрофа. Граница проходит по цене ошибки.
NeatContext в июле выключили автономного агента с доступом к логам: таймаут платёжного шлюза он связал со всплеском коннектов к БД двенадцатью часами раньше, через RAG унаследовал устаревший runbook и не умел сказать «не знаю». «Получили уверенный генератор галлюцинаций». Они продают свой инструмент, но симптомы знакомые.
Как границу строят руками
1. Read-only, который действительно read-only. HyperProbe (Launch HN, 5 августа) даёт агентам ставить виртуальные пробы в работающий процесс. Главный вопрос треда: чем «только чтение» гарантия, а не договорённость? В Python чтение атрибута может дёрнуть @property с ленивой загрузкой из БД, в Java геттер - взять лок.
Ответ: условия без вызовов методов и доступа к свойствам (order.total > 5 нельзя, total > 50 можно) плюс бюджеты.
2. Вето вне агента. В r/kubernetes: LLM предлагает scale, rollback, cordon, drain, а детерминированный Safety Engine без LLM проверяет действие по живому состоянию API.
Комментарии: вето должно жить там, где агент не может исполнять код (отдельный процесс, admission webhook), иначе «вы построили второе мнение, а не вето»; оно должно быть stateful (бюджет blast radius, cooldown, проверка результата) и перепроверять состояние прямо перед мутацией.
3. Обратимость как критерий. Security patching автоматизировали, потому что у каждого действия известен откат. Rollback, scale, restart - митигации, а не фиксы. Команды на GitOps уже пускают агентов открывать PR («большинство RCA были верными»), но мержить и катить - человек. Mezmo выложили в open source AURA : их SRE-команда упёрлась в переполнение контекста, галлюцинации и approval fatigue и «провела жёсткую черту: права в проде не ослабляем».
Инструменты проверяются вне контекста агента, approval через webhook, по таймауту - fail-closed.
Другой полюс
Boris Tane (ex-Baselime и Cloudflare, теперь строит Polylane: «никто не должен дежурить в 2026») 21 августа опубликовал On-Call Is Now Theatre: дежурство - признание поражения, если пейджить агента бесплатно, алертов нужно радикально больше, а единственный валидный результат расследования - diff.
Он продаёт это будущее. Но даже его рецепт на первую неделю - дать агенту read-доступ к телеметрии на самом шумном алерте и две недели сравнивать его triage с людьми. То есть read-only.
Что я из этого я бы точно себе забрал?
Граница - не вопрос доверия, а отсутствие того, что в треде назвали bounded authority: система должна знать, что ей можно, при каких доказательствах и когда нужен второй approve. Без базы из ноябрьского поста (SLO, связная телеметрия, живые runbook'и) агент просто быстрее ошибается. И измеряйте: прогоните агента по своим постмортемам и посчитайте долю неверных вердиктов.
Вопрос к вам: что вашему агенту уже разрешено делать в проде без человека? И кто это разрешил - policy или привычка?
#sre #oncall #ai #incidentresponse #observability | 854 |
| 9 |  Забираем локальную память для ИИ-агентов - myc не даст Claude Code забыть, что вы с ним решили, даже когда контекст уже сжали.
Работает без сети и без ключей, в одном файле рядом с проектом:
• пакет контекста собирается за 0,6 мс;
• поиск по 100 000 записей - за 8 мс;
• решения из переписки не считаются фактами, пока вы их не подтвердите.
Подхватывает Claude Code, Codex, opencode и Kimi одной командой, а между машинами переезжает через обычный git. Только Bun, автор из Питера, проекту неделя.
Забираем - лежит тут. | 1 076 |
| 10 | Спасибо подписчикам за то что приносите интересные проекты! | 975 |
| 11 |  🐳 Docker выпустила Sandboxes - изолированные среды специально для AI coding agents.
Идея простая: дать агентам вроде Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode и Kiro больше свободы, но не давать им свободно ломать хост-систему.
Каждый агент запускается в отдельной microVM и получает только рабочую директорию проекта. Внутри он может:
- устанавливать пакеты;
- менять конфиги;
- запускать сервисы;
- поднимать собственные Docker-контейнеры;
- выполнять долгие задачи без постоянного подтверждения действий.
При этом Docker позволяет отдельно контролировать filesystem, network и credentials, а сам sandbox после работы можно просто удалить.
Это инфраструктурный слой для эпохи автономных coding agents: агенту дают почти полный контроль внутри песочницы, но хост остаётся изолированным.
https://www.docker.com/products/docker-sandboxes/
#Docker #AI #AIAgents #DevOps #Programming | 1 045 |
| 12 | Как AWS у опенсорсера пакеты отжимал
Нерегулярная рубрика "посмотрите, что творится!". Данная история была в оригинале рассказана Кареном в нашем чате (там регулярно происходит интересное), публикую в своем канале с его разрешения.
Новый SDK для AWS от Карена (автора zapros, автора httpx-aiohttp, топ-3 контрибьютора httpx): https://github.com/kap-sh/capo
Как-то я решил написать нормальный SDK для AWS. Их текущий SDK — boto3 — это суперлегаси с кучей костылей: без нормальной типизации, без поддержки асинхронности, почему-то с PascalCase и ещё кучей странных решений.
У меня уже был хороший опыт работы с SDK: до этого я работал над SDK для OpenAI и Anthropic на Python и TypeScript, так что успел накопить некоторое понимание того, как делать SDK хорошо.
С AWS всё немного сложнее: у них около 450 сервисов и примерно 17 миллионов строк сгенерированного кода. Конечно, я не собирался писать всё это вручную. Вместо этого я пишу кодогенератор, который генерирует SDK из спецификаций Smithy (язык и тулинг для спецификаций). Примерно такой же подход я использовал, работая над SDK для OpenAI и Anthropic.
И, конечно, я не стал делать это одним пакетом на PyPI. Прикиньте, устанавливать 17 миллионов строк кода только для того, чтобы создать S3-бакет.
Поэтому я делаю отдельный пакет для каждого сервиса.
Для всех пакетов я выбрал префикс aws-sdk: aws-sdk-s3, aws-sdk-ecs и так далее. Успешно опубликовал около 60 сервисов на PyPI.
А на следующий день до меня достучались ребята из AWS.
Они заметили мою работу, пореспектовали, но сказали, что именно эти имена они сами давно хотели использовать для своего нового SDK — замены boto3. И попросили вернуть им эти имена.
И тут есть ещё одно интересное совпадение: в тот же день PyPI заморозил мой аккаунт. В заморозке он продержался больше месяца. Причины мне так и не объяснили, но, думаю, каждый может сделать свои выводы 🙂
Я не стал с ними бороться и согласился вернуть имена.
Что интересно в данном контексте?
1. Существует PEP, который определяет разрешение конфликтов в пакетах: https://peps.python.org/pep-0541 Там есть пункт о том, что если пакет "нарушает торговую марку", то он может быть отозван как "некорректный". Но там есть важная оговорка, что "честное использование" (например для создания SDK) - разрешено
2. AWS являются спонсорами PyPI: https://aws.amazon.com/ru/blogs/opensource/securing-pypi-for-the-future
Кстати, история про left-pad начиналась так же.
Техническая часть
Что удивительно, так то, что сами AWS не могу сделать нормальный SDK для питона. А один человек в опенсорсе - может. Сделать и синхронную, и асинхронные версии - довольно сложно. Вот так оно выглядит у capo:
from capo_s3 import AsyncS3Client
async def main():
async with AsyncS3Client() as s3:
response = await s3.create_bucket("capo")
print(response)
и
from capo_s3 import S3Client
with S3Client() as s3:
response = s3.create_bucket("capo")
print(response)
Внутри, конечно же, zapros, как HTTP фреймворк для запросов.
Что прикольно: все модели данных построены на TypedDict, все ответы типизированы, но с 0 дополнительных кастов. Но типизация все еще помогает понять, какие ответы от каких сервисов можно использовать как входные данные для других, а где - так сделать будет нельзя.
Развязка
Карену поступило предложение работы в AWS с релокацией в США (да, после опенсорс проекта), он отказался по личным причинам.
Они созвонились с разработчиками оттуда, выразили друг другу уважение (как капо и делают 🌚), обсудили технические решения.
Кажется, никто не остался в обиде.
Хорошо, что история хорошо закончилась: у нас есть и контент для канала, и новая библиотека, и счастливый финал.
Обсуждение: Как вы думаете, что на самом деле там произошло? Почему аккаунт заморозили? Как вы думаете, найм через такой опенсорс - реальность или супер-редкая уникальная история? Насколько сильно вы страдали от boto3?
| Поддержать | YouTube | GitHub | Чат | | 954 |
| 13 | Вот страшилка на выходных | 1 009 |
| 14 |  OpsKnight
Центр управления инцидентами с открытым исходным кодом. Весь жизненный цикл инцидента, графики дежурств и страницы состояния — на одной мощной платформе.
OpsKnight — это альтернатива с открытым исходным кодом PagerDuty и OpsGenie, разработанная для команд, которые хотят получить полный контроль над своей системой управления инцидентами без затрат на SaaS-сервисы.
Репыч на Гитхаб
Страница проекта
📱 Telegram | 📲 MAX | 1 167 |
| 15 | argo9s
A K9s-inspired terminal UI for monitoring Argo CD resources in real-time
https://github.com/vvrnv/argo9s | 1 302 |
| 16 |  Сколько незаконченных Git-репозиториев лежит у вас на диске?
drydock показывает их все в одном терминальном интерфейсе:
- где остались незакоммиченные изменения;
- какие коммиты ещё не отправлены;
- где забыты stash, конфликт или незавершённый rebase;
- какие проекты изменились после последнего тега и готовы к новому релизу.
Инструмент проверяет не только текущую ветку, поэтому забытая работа в локальной feature-ветке тоже попадёт в список.
brew install yetidevworks/drydock/drydock
# или
cargo install drydock
После установки достаточно запустить:
drydock
Есть фильтры, fuzzy-поиск, JSON-вывод, открытие проекта в редакторе и массовый fetch. Состояние репозиториев обновляется автоматически через файловый watcher.
drydock написан на Rust с использованием Ratatui и работает на macOS и Linux.
Полезная утилита для разработчиков, у которых папка Projects давно превратилась в кладбище почти законченных идей.
GitHub:
https://github.com/yetidevworks/drydock | 1 978 |
| 17 |  🎙️ На волне DevOps FM!
Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.
В прошлых подборках нас просили больше русскоязычного контента, поэтому собрали три выпуска, которые стоит добавить в список для прослушивания.
🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.
🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.
🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.
Желаем приятного прослушивания и дежурств без алертов!🛡
#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering | 1 382 |
| 18 | No text... | 1 191 |
| 19 |  ⚡️ KubeGUI - open-source десктопный клиент для Kubernetes с нормальным современным интерфейсом.
Позволяет управлять ресурсами кластера без постоянной работы через kubectl:
- Deployments, DaemonSets, Pods и CRD
- live-обновления ресурсов
- встроенный YAML-редактор с валидацией
- работа сразу с несколькими кластерами
- просмотр логов
- shell прямо внутрь workload
- port-forwarding
- графы NetworkPolicy и RBAC
- просмотр Helm-чартов и релизов
- on-demand сканирование уязвимостей через Trivy
Отдельный плюс - kubectl вообще не обязателен: приложение само работает с Kubernetes API.
Под капотом Go + Wails, а интерфейс собран на React, TypeScript и Vite.
https://github.com/gerbil/kubegui | 1 217 |
| 20 |  Announcing vmestimator: Real-time Cardinality Estimations for VictoriaMetrics and Prometheus
А вот и подоспела статья о vmestimator в блоге VM. vmestimator запускается в точке сбора данных, вычисляя кардинальность на основе входящего потока и предоставляя их в виде метрик через /metrics, совместимых с Prometheus, для сбора данных и оповещений.
📱 Telegram | 📲 MAX | 1 400 |
