🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю.

🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами

🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое

🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда

📎 GitHub: https://github.com/GoogleCloudPlatform/khi


@devopsitsec

Во времена, когда ледяные ветра ещё не утихли, а мамонты ходили стадами по земле. Настало время великого сборища тех, кто управляет огнём и током
Слет Системных Администраторов DSA 2025!

📅 Когда?
В пятницу и по день недельный середины лета. (25.07-27.07)

📍 Где?
В землях Ярославских, на поляне технохуторской, где трава густа, а дух свободы кружит над головой. Там, где от Москвы два дня пути верхом на мамонте.

🔥 Что это такое?
20-й Всероссийский слёт мудрецов цифровых племён — событие года!
Огромное племя из разных уголков света соберётся у костра знаний и опыта: из России, СНГ и далёких земель близкого зарубежья!
👥Здесь встретятся сотни хранителей — тех, кто ведает серверами, сетями и прочими тайнами электронного духа. Они поделятся мудростью, научат молодых, обменяются амулетами связи и просто проведут время так, как подобает настоящим героям информационных баталий.

🎯 Что будет?
— Загадки, испытания, ритуальные опросы;
— Обряды передачи знаний (технические сессии);
— Шаманские представления и колдовские шоу;
— Подарки от союзников слёта — от камней до железных оберегов;
— Группы с живым звуком, что заставят душу плясать;
— Новые союзы и старые друзья, которых ты не видел со времён прошлого слёта.

🌐 Регистрация — через портал огня и света: https://itslet.su
🗣 Беседка племени в VK: https://vk.com/itslet
🗣 Беседка племени в Telegram: https://www.tgoop.com/dsa_gate
👣 Увидимся на священной поляне, огонь ждёт тебя! 🔥💻🦣

Прохожу Школу СТО Стратоплана. Часть №2.1. Делегирование.

Обещанный пост с новой порцией конспектов с курса.
———

Самая главная проблема из-за которой нам в принципе сложно что-либо делегировать это отсутствие доверия.

Для того чтобы можно было безопасно делегировать нужно развивать контроллинг - процесс построения инфраструктуры которая позволит нам вместо контроля конкретных задач отслеживать общий статус по процессам департамента / команды.

———

Как реализовывать делегирование? - через процессы (четкие инструкции, четкие критерии результата, возможность контроля, принятие важных решений в наших руках)

Для того чтобы правильно это выстроить полезен подход RACI, его цель — разграничить ответственности участников процесса через четыре ключевые роли:
- кто выполняет (Responsible) — один или несколько сотрудников, которые занимаются непосредственно работой;
- кто утверждает (Accountable) — ответственный за итог, может не только принимать работу, но и исполнять её вместе с R;
- кто консультирует (Consulted) — советчик по процессам;
- кто информирован (Informed) — заинтересованные лица, которые хотят получать информацию по проекту.

Если приводить примеры инструментов руководителя для реализации делегирования то это в основном 4 штуки:
- Правила и инструкции
- Наличие в процессе обязательного финального аппрува от нас.
- Любые необходимые для реализации процесса метрики и KPI.

———

Какой еще вариант делегирование доступен нам? - делегирование через бюджеты.

"Делегирование через бюджет" — это управленческий подход, при котором руководитель не просто поручает задачи, но и передаёт подчинённому (или команде) ответственность за принятие решений в рамках определённого бюджета. Это своего рода делегирование полномочий с финансовыми рамками.

———

Метрики - основной инструмент руководителя. Без них просто невозможно отслеживать изменения и руководить командами отделами и департаментами. Их довольно много и зависят от того какие конкретно инструменты в компании используются (например Kanban или Scrum). Верхнеуровнено важно отслеживать метрики по PMBOK (про бюджеты, сроки, стоимость).

Хороший пример фреймворка который отслеживает удовлетворенность пользователей - HEART Framework

Дополнительные ссылки:
- Kanban Metrics
- Scrum Metrics
- Метрики продукта

Решил сделать перерыв от высоких менеджерских материй и попостить простой годноты, которую встречаю в day by day работе.

Сегодняшний лот - статья с подробнейшим разбором такого понятия как CPU Throttling.

Под катом:
- Что такое CPU Throttling, какое влияние оказывает на сервис под нагрузкой?
- Как в K8s работают CPU limits?
- Как можно столкнуться с CPU Throttling на примере Golang?
- K8s limits, requests + GOMAXPROCS
- Milliseconds vs Cores, что будет если установить программе в K8s лимиты < 1?

Очень советую к прочтению, если не сталкивались, это важная и полезная база. И, конечно, проверьте дашборды сервисов на наличие панелек с индикаторами троттлинга, нужная штука при разборе инцидентов.


https://kanishk.io/posts/cpu-throttling-in-containerized-go-apps/

-----

Делитесь в комментариях своим опытом связанным с CPU нагрузками, где и чего оптимизировали, как избавлялись от троттлинга сервисов?😊

Prometheus: How We Slashed Memory Usage

https://devoriales.com/post/384/prometheus-how-we-slashed-memory-usage

#prometheus #monitoring #observability

​Prometheus Monitoring: Functions, Subqueries, Operators, and Modifiers

Статья из блога VictoriaMetrics о функциях, подзапросах, операторах и модификаторах.

⚡️ Composerize — мгновенное преобразование docker run в docker-compose. Composerize решает проблему нечитаемых строк с десятками флагов одним движением — конвертирует запуск контейнера через CLI в аккуратный compose.yaml.

Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.

🤖 GitHub

@DevopsDocker

Исследование состояния DevOps в России 2025

Дорогие друзья, мы рады сообщить, что «Экспресс 42» при поддержке генеральных партнеров запустила ежегодное исследование состояния DevOps 2025! Мы планируем опросить больше 4000 представителей индустрии, связанных с DevOps: инженеров, разработчиков, администраторов, тестировщиков, техлидов и тимлидов, CIO и CTO.

Если тема DevOps вам не безразлична — пройдите опрос и внесите свой вклад в развитие индустрии. Важно мнение каждого респондента!

📊 Ключевой темой исследования в 2025 году становится Developer Experience (DX) — то, насколько опыт разработчиков влияет на эффективность команд и успех компании.

🎁 По завершении опроса вы сможете поучаствовать в лотерее с розыгрышем классных призов от организатора исследования и генеральных партнёров.

Заполнить анкету 👉 по ссылке

#машины_разное

Рассказал на Tech Internals Conf, он же англоязычная вариация Highload++, про миграции API.

Рекомендуется к просмотру аудитории любой степени подготовки.

​The Lost Fourth Pillar of Observability - Config Data Monitoring

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

Гугл опубликовал пост-мортем по позавчерашнему падению. Обычные ошибки, только на инфраструктуре планетарного масштаба.

У них есть внутренний сервис, который проверяет доступы (бабки, квоты и т. д.) перед тем, как API запрос доходит до любого продукта.

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

В эту программу добавили поддержку нового типа квот. Программист допустил небрежность в новом коде и не проверял, насколько корректно записано это правило в базе, перед тем, как пытаться положить его в память. Обращение к несуществующей памяти — смертный грех, за такое программа мгновенно завершается (если программист не предусмотрел, что такое может случиться, а это не наш случай). При этом я бы не назвал это ошибкой, все мы люди, мы не идеальны и поэтому придумываем механизмы защиты от своей природы. В этом суть инженерного подхода.

Экземпляр этой программы работает в каждом регионе Гугла. Так как это серьезный, ключевой сервис, его выкатывают не во все регионы сразу, а по одному, внимательно отслеживая, не внесли ли программисты новые ошибки.

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

К сожалению, программист забыл настроить фича-флаги для этого кода. Кусочек программы с ошибкой запустился на всех пользователей сразу. Удивительно, что это не заметили на этапе code review!

Итак, проходит время, и вот программа с ошибкой запущена во всех регионах для всех пользователей. Кто-то добавляет в базу данных новое правило с новым типом квот, с пустым полем. Эта запись в течение десятков миллисекунд копируется во все регионы, и в каждом регионе программа проверки считывает новое правило, пытается обратиться к несуществующей памяти, падает, перезапускается и снова падает.

Тут в дело вступает, на мой взгляд, первая ошибка (а не просто человеческая небрежность) инженеров — система контроля доступа настроена так, что при отсутствии ответа от программы проверок она отклоняет запрос. Так называемый fail closed. Хорошо для замков на банковских сейфах, плохо для пожарных выходов.
В нашем случае система не пропускает ни один запрос.

Дежурные инженеры замечают проблему в течение 2 минут, за 10 минут находят причину (дежурная система и дежурные инженеры у Гугла достойны восхищения) и нажимают большую красную кнопку, которая должна выключить эту часть программы (ее программисты сделали). Ее включение занимает еще 30 минут. (Не понятно, почему этот механизм занимает 30 минут, а не 20 миллисекунд, но движемся дальше).

Система заработала, но из-за того, что она лежала 40 минут, накопилось много желающих отправить запрос еще раз, и они создали эффект толпы, которая набежала и перегрузила остальные соседние сервисы через наш сервис проверок. Оказалось, что он не ждет какое-то время, если нужный сервис отказывается ответить на запрос (для этого есть красивая схема exponential back off), а долбит до упаду, тем самым не давая системе возможности восстановиться. Пришлось руками ограничивать число запросов. На постепенную, ручную разгрузку очередей ушло еще 2 часа.

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

Как вывод, Гугл обещает пройтись по всем сервисам и убедиться, что они, во-первых, fail open, то есть пропускают запросы, когда падают, во-вторых, реализуют exponential back off, если на их запрос не отвечают, а не добивают лежачего, и, наконец, в-третьих, что даже глобальные добавления правил должны прилетать во все регионы не сразу, а с некоторыми задержками. Ещё обещают добавить эти проверки в свои статические анализаторы кода, завидую!

Первые два пункта можно и нужно использовать в каждом проекте, даже если ты не Гугл.

Terraforming Your Grafana Alerts for Kubernetes Clusters

Дашборды в Grafana не всегда можно удачно затеррарформить, а вот оповещения вполне себе. В этой статье автор разбирает примеры алертинга для кластера Kubernetes.

❗️Статья на medium.com

Прикрутим персистентность - I

Давайте сделаем упражнение в "системном дизайне". Предположим, мы написали простенькое in-memory хранилище, но нас не устраивает, что данные теряются при рестартах, надо прикрутить "сбоку" персистентность. Строгая консистентность вам не очень нужна, но желательна. Как добавить эту персистентность?

Можно делать снепшотирование: fork(), запись на диск. Можно писать лог обновлений на диск (сразу, или нет - в зависимости от требуемых гарантий). Можно использовать комбинированные методы. Давайте обсудим, мне кажется, хорошее упражнение на понимание архитектурной “внутрянки”.

Допустим мы снепшотируемся через fork(). Что происходит сразу же: copy-on-write. Это такая оптимизационная стратегия управления памятью, при которой копирование объекта откладывается до тех пор, пока одна из сторон не попытается его изменить. Если данные не меняются, читаем одно и то же из “пошеренной” страницы. При изменении создаётся копия. Поэтому после fork() ядро дублирует страницу только в тот момент, когда соотвествующий участок памяти обновляется в родительском процессе нашего kv—хранилища: мы же продолжаем принимать апдейты от клиентов.

Если наше kv-хранилище получает апдейтов много, то в самом плохом случае нам может понадобится в два раза больше памяти: ядро при каждом обновлении страницы начнёт создавать копию, а максимальное количество копий даст удвоение по памяти. Именно поэтому для Redis рекомендуется держать свободными десятки (!) процентов памяти, иначе может быть больно - и это абсолютно смешное требования с точки зрения любой “нормальной” СУБД. Буквально несколько недель назад я вот так угандошил кластер Redis на демо, и даже сходу не разобрался почему 🙂

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

Про остальные методы прикручивания персистентности напишу позже.

——
Учись, пока AI тебя не заменил: Производительность и наблюдаемость бэкенда (3 июня), Redis и Valkey: от основ к хайлоаду (9 июня)