DevOps Brain 🧠

DevOps Brain 🧠

Пишу про kubernetes, terraform, linux, сети, автоматизации и полезные тулзы. Без спама и щитпостинга. Хотите пообщаться? @devopsbrain_chat Автор: @itcaat

Юзернейм
@devopsbrain
Категория
Технологии
Страна
РоссияРоссия
Создан
, 2 года
Подписчики1 346+2 за 2 дня
Просмотров на пост, 7 дн.392−48,1% к пред. 7 дн.
ERR29,12 %за 7 дней

Подписчики, 30 дней

2 нояб. – 4 нояб.+2 (+0,1%)

Показать таблицей
ДатаПодписчики
2 нояб. 2026 г.1 344
3 нояб. 2026 г.1 344
4 нояб. 2026 г.1 346

Средние просмотры поста по дням

По дню публикации

Показать таблицей
ДатаПросмотров на пост
28 окт. 2026 г.755
2 нояб. 2026 г.447
3 нояб. 2026 г.337

Самые просматриваемые за месяц

  1. 01

    🔖 Kafka: от первого сообщения до production Наконец-то закончил писать серию статей про Kafka, которую надо читать вечерочком под пледиком и с чашечкой какао. 🙈 Вместе мы пройдем путь на примере классического интернет-магазина. Сначала отправим событие о заказе, потом разберём порядок сообщений, репликацию и производительность. А дальше посмотрим, что будет происходить в случае отказа тех или иных частей нашей архитектуры. Мы постепенно будем усложнять систему и разбираться зачем нужен тот или иной механизм. Мы не просто узнаём, что делает acks, а смотрим, почему Kafka может подтвердить запись, а покупатель всё равно не получить письмо. Не просто включаем retry, а выясняем, когда повтор поможет, а когда нарушит порядок событий или повторно зарезервирует товар. Это не пошаговая лабораторная, а моя попытка дать понятную основу для собственных решений: что выбрать, чем за это заплатить и что произойдёт при сбое. - Kafka: архитектура и базовые принципы — Часть 1 - Kafka: как масштабируются Partitions, Consumer Groups и порядок сообщений — Часть 2 - Kafka: Record, Offset и Append-Only Log — Часть 3 - Kafka: репликация, Leader, Follower и ISR — Часть 4 - Kafka: что делает её производительной — Часть 5 - Kafka: события, команды, Topics и Keys — Часть 6 - Kafka: Retention, Compaction и контракты событий — Часть 7 - Kafka: гарантии доставки, Outbox и идемпотентность — Часть 8 - Kafka: Retry, DLQ и эксплуатация Consumer — Часть 9 И самое классное это то, что вы можете использовать симулятор по ходу прочтения, а после сразу перейти к практике взяв за основу мой url-shortener-demo. И не стесняйтесь оставлять свой фидбек и вопросы после прочтения. ЗЫ Отдельное спасибо за ревью статей @denis_kp — Telegram | Github | YouTube | X

    GIF
    Просмотры755
    Пересылки93
    Реакции29
    Комментарии0
  2. 02

    Интересно, а насколько AI уже успел изменить нашу работу в DevOps и SRE? Мы всё чаще отдаём нейросетям написание конфигов, разбор логов, генерацию Terraform и даже диагностику инцидентов. Но вот дать AI доступ к проду и разрешить ему самостоятельно что-то чинить – тут, думаю, многие уже задумаются 😁 Ребята из DevCrowd запустили исследование про SRE, DevOps и платформенных инженеров. Лично мне любопытно посмотреть на результаты по AI и дежурствам. И больше всего: действительно ли AI снижает нагрузку на инженеров или просто позволяет навешивать на них ещё больше задач 😁 В этом году там довольно разнообразные темы: • Насколько мы вообще доверяем AI и готовы ли пускать его в прод? • Стало ли больше инцидентов из-за сгенерированного кода? • Какие навыки инженера AI пока не способен заменить? • Сколько на самом деле стоят дежурства, переработки и постоянная ответственность за прод? • Как меняются зарплаты, обязанности и требования к инженерам? Опрос анонимный, занимает 10-12 минут. Результаты будут в начале декабря. ➡️ https://survey.devcrowd.ru/sre-2026 Ну и вопрос к вам: вы бы уже доверили AI самостоятельно устранять инциденты в проде или рано? 🤩 — Telegram | Github | YouTube | X

    Текстизменён
    Просмотры447
    Пересылки2
    Реакции8
    Комментарии1
  3. 03

    🔖 Expr для Go: динамические правила вместо цепочек if Сегодня я хочу немного отойти от типичных тем канала и поговорить о разработке на Go, а именно о пакете Expr и задачах, которые она решает. Вы уже наверняка написали какое-то количество сервисов или программ, дополняющих вашу инфраструктуру на GoLang. Почти у каждого такого сервиса есть конфигурация по типу такой: min_replicas: 3 max_error_rate: 0.05 Ну и классическая обработка выглядит примерно так: if readyReplicas >= cfg.MinReplicas && errorRate < cfg.MaxErrorRate { // продолжаем операцию } Пока конфигурация небольшая, этого достаточно. Но затем меняется уже форма правила: в production нужны три реплики, в остальных окружениях достаточно одной; во время maintenance проверку нужно пропустить; error rate учитывается только для части сервисов. В конфигурации появляются новые флаги и через некоторое время вы обнаруживаете кучу вложенных if, что делает код просто нечитабельным. Но что если я вам скажу, что вместо цепочки if и вложенных условий можно хранить в конфигурации само правило. Expr скомпилирует его при загрузке или обновлении конфигурации, а затем приложение будет выполнять готовую программу с актуальными входными данными (вспоминаем alertmanager): rule: >- environment != "production" || maintenanceMode || (readyReplicas >= 3 && errorRate < 0.05) При компиляции Expr проверит правило по Go-типам, а готовую программу затем можно многократно запускать с разными входными данными. Давайте опишем структуру, которая одновременно будет служить входными данными и контрактом. type ServiceState struct { Environment string `expr:"environment"` MaintenanceMode bool `expr:"maintenanceMode"` ReadyReplicas int `expr:"readyReplicas"` ErrorRate float64 `expr:"errorRate"` } Теперь загрузим строку из конфигурации и скомпилируем её: program, err := expr.Compile( config.Rule, expr.Env(ServiceState{}), expr.AsBool(), ) if err != nil { return fmt.Errorf("compile rule: %w", err) } После этого программу можно выполнить с реальными значениями: state := ServiceState{ Environment: "production", MaintenanceMode: false, ReadyReplicas: 3, ErrorRate: 0.02, } result, err := expr.Run(program, state) if err != nil { return err } allowed := result.(bool) // true Приложение ничего не знает о внутреннем устройстве условия. В конфигурации можно изменить порог, добавить исключение или полностью заменить правило – код вокруг expr.Run останется прежним. Внутри expr.Compile строка сначала превращается в abstract syntax tree. Затем checker связывает имена с полями ServiceState, optimizer упрощает дерево, а compiler создаёт инструкции для stack-based virtual machine. При expr.Run VM выполняет эти инструкции с переданными значениями. Главный практический выигрыш Expr довольно простой: меняется правило – обновляется конфигурация; меняется набор доступных данных или поведение самого приложения – тогда уже пересобирается Go-код. Эта граница позволяет убрать растущие цепочки if, не превращая конфигурацию в полноценный язык сценариев. Такое устройство и позволяет крутить правила динамически: дорогостоящую подготовку мы выполняем один раз на reload, а не для каждого запроса. PS Playground и самая полная документация тут: https://expr-lang.org/ — Telegram | Github | YouTube | X

    Фотоизменён
    Просмотры337
    Пересылки6
    Реакции5
    Комментарии0

Новые посты

#253Фотоизменён

🔖 Expr для Go: динамические правила вместо цепочек if Сегодня я хочу немного отойти от типичных тем канала и поговорить о разработке на Go, а именно о пакете Expr и задачах, которые она решает. Вы уже наверняка написали какое-то количество сервисов или программ, дополняющих вашу инфраструктуру на GoLang. Почти у каждого такого сервиса есть конфигурация по типу такой: min_replicas: 3 max_error_rate: 0.05 Ну и классическая обработка выглядит примерно так: if readyReplicas >= cfg.MinReplicas && errorRate < cfg.MaxErrorRate { // продолжаем операцию } Пока конфигурация небольшая, этого достаточно. Но затем меняется уже форма правила: в production нужны три реплики, в остальных окружениях достаточно одной; во время maintenance проверку нужно пропустить; error rate учитывается только для части сервисов. В конфигурации появляются новые флаги и через некоторое время вы обнаруживаете кучу вложенных if, что делает код просто нечитабельным. Но что если я вам скажу, что вместо цепочки if и вложенных условий можно хранить в конфигурации само правило. Expr скомпилирует его при загрузке или обновлении конфигурации, а затем приложение будет выполнять готовую программу с актуальными входными данными (вспоминаем alertmanager): rule: >- environment != "production" || maintenanceMode || (readyReplicas >= 3 && errorRate < 0.05) При компиляции Expr проверит правило по Go-типам, а готовую программу затем можно многократно запускать с разными входными данными. Давайте опишем структуру, которая одновременно будет служить входными данными и контрактом. type ServiceState struct { Environment string `expr:"environment"` MaintenanceMode bool `expr:"maintenanceMode"` ReadyReplicas int `expr:"readyReplicas"` ErrorRate float64 `expr:"errorRate"` } Теперь загрузим строку из конфигурации и скомпилируем её: program, err := expr.Compile( config.Rule, expr.Env(ServiceState{}), expr.AsBool(), ) if err != nil { return fmt.Errorf("compile rule: %w", err) } После этого программу можно выполнить с реальными значениями: state := ServiceState{ Environment: "production", MaintenanceMode: false, ReadyReplicas: 3, ErrorRate: 0.02, } result, err := expr.Run(program, state) if err != nil { return err } allowed := result.(bool) // true Приложение ничего не знает о внутреннем устройстве условия. В конфигурации можно изменить порог, добавить исключение или полностью заменить правило – код вокруг expr.Run останется прежним. Внутри expr.Compile строка сначала превращается в abstract syntax tree. Затем checker связывает имена с полями ServiceState, optimizer упрощает дерево, а compiler создаёт инструкции для stack-based virtual machine. При expr.Run VM выполняет эти инструкции с переданными значениями. Главный практический выигрыш Expr довольно простой: меняется правило – обновляется конфигурация; меняется набор доступных данных или поведение самого приложения – тогда уже пересобирается Go-код. Эта граница позволяет убрать растущие цепочки if, не превращая конфигурацию в полноценный язык сценариев. Такое устройство и позволяет крутить правила динамически: дорогостоящую подготовку мы выполняем один раз на reload, а не для каждого запроса. PS Playground и самая полная документация тут: https://expr-lang.org/ — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры337−34%к среднему
Пересылки6
Реакции5
Комментарии0
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
4 ч210
16 ч293
28 ч337
  1. Через 6 часов210
  2. Через 24 часа337
  3. Всего сейчас337
#252Текстизменён

Интересно, а насколько AI уже успел изменить нашу работу в DevOps и SRE? Мы всё чаще отдаём нейросетям написание конфигов, разбор логов, генерацию Terraform и даже диагностику инцидентов. Но вот дать AI доступ к проду и разрешить ему самостоятельно что-то чинить – тут, думаю, многие уже задумаются 😁 Ребята из DevCrowd запустили исследование про SRE, DevOps и платформенных инженеров. Лично мне любопытно посмотреть на результаты по AI и дежурствам. И больше всего: действительно ли AI снижает нагрузку на инженеров или просто позволяет навешивать на них ещё больше задач 😁 В этом году там довольно разнообразные темы: • Насколько мы вообще доверяем AI и готовы ли пускать его в прод? • Стало ли больше инцидентов из-за сгенерированного кода? • Какие навыки инженера AI пока не способен заменить? • Сколько на самом деле стоят дежурства, переработки и постоянная ответственность за прод? • Как меняются зарплаты, обязанности и требования к инженерам? Опрос анонимный, занимает 10-12 минут. Результаты будут в начале декабря. ➡️ https://survey.devcrowd.ru/sre-2026 Ну и вопрос к вам: вы бы уже доверили AI самостоятельно устранять инциденты в проде или рано? 🤩 — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры447−13%к среднему
Пересылки2
Реакции8
Комментарии1
Динамика просмотровСкрыть динамику

Рост просмотров

Часов после публикации

Показать таблицей
Часов после публикацииПросмотры
0 ч0
8 ч333
33 ч447
  1. Всего сейчас447
#251GIF

🔖 Kafka: от первого сообщения до production Наконец-то закончил писать серию статей про Kafka, которую надо читать вечерочком под пледиком и с чашечкой какао. 🙈 Вместе мы пройдем путь на примере классического интернет-магазина. Сначала отправим событие о заказе, потом разберём порядок сообщений, репликацию и производительность. А дальше посмотрим, что будет происходить в случае отказа тех или иных частей нашей архитектуры. Мы постепенно будем усложнять систему и разбираться зачем нужен тот или иной механизм. Мы не просто узнаём, что делает acks, а смотрим, почему Kafka может подтвердить запись, а покупатель всё равно не получить письмо. Не просто включаем retry, а выясняем, когда повтор поможет, а когда нарушит порядок событий или повторно зарезервирует товар. Это не пошаговая лабораторная, а моя попытка дать понятную основу для собственных решений: что выбрать, чем за это заплатить и что произойдёт при сбое. - Kafka: архитектура и базовые принципы — Часть 1 - Kafka: как масштабируются Partitions, Consumer Groups и порядок сообщений — Часть 2 - Kafka: Record, Offset и Append-Only Log — Часть 3 - Kafka: репликация, Leader, Follower и ISR — Часть 4 - Kafka: что делает её производительной — Часть 5 - Kafka: события, команды, Topics и Keys — Часть 6 - Kafka: Retention, Compaction и контракты событий — Часть 7 - Kafka: гарантии доставки, Outbox и идемпотентность — Часть 8 - Kafka: Retry, DLQ и эксплуатация Consumer — Часть 9 И самое классное это то, что вы можете использовать симулятор по ходу прочтения, а после сразу перейти к практике взяв за основу мой url-shortener-demo. И не стесняйтесь оставлять свой фидбек и вопросы после прочтения. ЗЫ Отдельное спасибо за ревью статей @denis_kp — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры755+47%к среднему
Пересылки93
Реакции29
Комментарии0
#250Текстизменён

🔖 Наконец-то дождались: git branch --delete-merged У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича - отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют. А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток: feature/login feature/login-fix fix/typo topic/auth topic/auth-v2 ... main И ты такой сидишь и думаешь: “Какая из них ещё живая? Какие уже смержены? Можно ли что-то удалить или я что-то потеряю?”. И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на https://ohshitgit.com/. В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete-merged. Самое классное, что команда супер простая и простая как полено (хоспадепрости patch-format с 100500 аргументами). $ git branch --delete-merged 'origin/*' --dry-run Would delete branch feature/login (was abc1234). Would delete branch feature/login-fix (was def5678). Would delete branch fix/typo (was 9876fed). Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run: $ git branch --delete-merged 'origin/*' Deleted branch feature/login (was abc1234). Deleted branch feature/login-fix (was def5678). Deleted branch fix/typo (was 9876fed). Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, - остались. Ветки с deleteMerged = false - остались. Ветки, которые ты вычеканил в другом worktree, - остались. Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/* . В общем, если git branch уже не помещается в терминал - обновляемся на 2.56 и теперь вы знаете что делать. — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры1 715+234%к среднему
Пересылки51
Реакции35
Комментарии1
#249Фото

Ребята, хочу рассказать про конференцию, которую я бы сам с удовольствием посетил. 3 октября пройдет RWB Infra x Security Meetup — про инфраструктуру и безопасность. Темы, судя по программе, подобрали довольно близкие к тому, с чем мы постоянно сталкиваемся в работе. Из Infra особенно интересны: - тюнинг GitLab CE при быстром росте нагрузки - PKI на базе Vault - Kubernetes vs Bare Metal и что там может пойти не так - построение DCIM и компромиссы, которые приходится принимать В Security тоже есть любопытные темы: DevSecOps, управление уязвимостями, защита данных без привычного периметра и автоматизация доступов в большую инфраструктуру. Всего будет 8 докладов в двух треках. 📅 3 октября, начало в 13:00 📍 Москва + онлайн Если работаете с инфраструктурой, DevOps/SRE или безопасностью — я бы как минимум посмотрел программу. Регистрация уже открыта, офлайн-места ограничены. 👉 Подробнее и регистрация: https://linkwb.ru/81BXU

Открыть в Telegram
Просмотры988+93%к среднему
Пересылки3
Реакции8
Комментарии0
#248GIFизменён
Просмотры1 179+130%к среднему
Пересылки29
Реакции27
Комментарии0
#247Фотоизменён

🔖 AI больше не стыдно? Обратили внимание, как быстро мы прошли фазу от “фууу, это нейрослоп” до состояния, когда уже даже лютые AI-нигилисты сдулись? Была забавная промежуточная стадия, когда мы пытались вычленять сгенерированный контент по длинным тире, а блогеры вручную удаляли их из своих слоп-статей, чтобы не спалиться. А потом как-то очень быстро всем резко стало пофиг. Нас приучили к тому, что AI теперь с нами везде, надолго и уходить никуда не собирается. Если ещё полгода назад тебе приносили пуллик со словами “я тут нагенерил нейронкой, можете поревьювить?” – и у тебя от такого полыхало внутри, то теперь зайти с пулликом в вообще незнакомый бизнес-домен не только нормально, но и даже приветствуется. Раньше незнание домена было ограничением. Чтобы полезть что-то менять, надо было сначала разобраться: почитать код, документацию, поговорить с людьми, понять, почему оно вообще устроено именно так. Теперь порог входа почти исчез. Ты можешь утром впервые увидеть сервис, через час обсуждать с AI его архитектуру, ещё через час принести вполне осмысленный пуллик людям, которые живут с этим сервисом несколько лет. И с одной стороны – это офигенно. Количество вещей, в которые ты потенциально способен залезть, выросло на порядок. Границы между “моё” и “я в этом ничего не понимаю” становятся сильно тоньше. Но есть и обратная сторона. AI очень хорошо убирает ощущение собственного незнания. Раньше ты смотрел на незнакомую кодовую базу и был как Ольга Бузова: я ничего не понимаю вообще. И это было полезное состояние. Оно заставляло тебя задавать вопросы, анализировать и искать решение. Теперь через десять минут разговора с AI у тебя уже есть объяснение архитектуры, список проблем, план рефакторинга и даже готовый код. А понимание при этом могло вообще не появиться. Наверное, главный навык ближайшего времени будет не в том, чтобы научиться пользоваться AI. Этому как раз все научатся довольно быстро. А в том, чтобы не принять чужую уверенность нейронки за собственное понимание. Ведь самое главное помнить, что ваш мозг как бюджет – если его не освоить, то в следующий раз он будет меньше. — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры1 022+99%к среднему
Пересылки6
Реакции22
Комментарии0
#246Видеоизменён

Ленту моего твиттера последние 2 дня разрывает от двух вещей - складного айфона и мухи. И если с айфоном всё понятно, то релиз FlyGym 2.0 – действительно интересен. Цифровая модель плодовой мушки моделирует тело, движения, зрение, обоняние и взаимодействие с окружением. Мы уже привыкли создавать виртуальных персонажей: рисуем внешность, синтезируем голос, даём LLM характер и биографию. Но здесь интересен другой принцип: поведение возникает из взаимодействия модели нервной системы, тела и среды. Множество видео с тем как мушка водит автомобиль, играет в Mario и Doom, торгует криптой и ходит на концерты вы можете найти в твиттере. Муха буквально живёт свою лучшую жизнь. Я решил исправить эту несправедливость и заставил ее немного поработать. Представляю вашему вниманию дежурного инженера, который следит за сервисами. А если сервис падает мой мух "бежит" эскалировать в чатик. Правда пока она ходит она как devops после корпората. В общем, пока все спорят, заменит ли ИИ айтишников, у меня дежурит муха. Главное – не прихлопнуть прод 😆 — Telegram | Github | YouTube | X

Открыть в Telegram
Просмотры1 028+100%к среднему
Пересылки9
Реакции15
Комментарии3
#244Фото
Просмотры1 064+107%к среднему
Пересылки24
Реакции13
Комментарии3
#243Фото
Просмотры1 330+159%к среднему
Пересылки42
Реакции36
Комментарии0

Все посты

Связи