Пятничный деплой

Public

Не можете присоединиться? @count0_digest

4.7k Участники

Обновлено: May 15, 2026 at 4:55 PM

Пятничный деплой

Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest

Follow @count0_digest to stay updated with the latest count0ru and httpstmescount0_digest trends and news

Рейтинг

Глобальный рейтинг

#456

Рейтинг по языку

#45

Рейтинг по категории

#23

-1

Рост участников (Последние 7 дней)

Всего: 4.7K

Рост за 24ч: +0 0%

Последние посты

Пятничный деплой

22 мая 2026 г., 18:36

https://github.com/isovalent/isopolicy — CLI инструмент от разработчиков Cilium для упрощения управления, проверки и тестирования Network Policy от Cilium в Kubernetes.

Основные функции:
- Статический анализ и проверка синтаксиса: Выполняет статический анализ политик для выявления распространенных ошибок конфигурации, таких как отсутствующие labels или непреднамеренные наложения.
- Моделирование политик: Включает команду моделирования, которая создает среду «что если». Это позволяет операторам предварительно оценить, как новые, измененные или удаленные политики повлияют на доступ к сети для разных идентификаторов или namespaces, не затрагивая работающий кластер.
- Историческая проверка: При подключении к Hubble Timescape может воспроизводить исторические потоки трафика, чтобы показать, как различные политики обрабатывали бы прошлый трафик, повышая общую «чистоту политик».
- Интеграция с GitOps: Может быть интегрирован в конвейеры CI/CD для автоматической проверки синтаксиса политик во время PR, блокируя мерджи, содержащие неподдерживаемые конструкции или очевидные ошибки.

Примеры использование можно посмотреть https://www.youtube.com/watch?v=zz2j2f5HbQk и https://isovalent.com/blog/post/safely-managing-cilium-network-policies-in-kubernetes-testing-and-simulation-techniques/#solution-2b-introducing-isopolicy-for-network-policy-simulations.

1,330

Пятничный деплой

22 мая 2026 г., 18:36

otel-cardinality-processor

An OpenTelemetry Collector processor that catches metric cardinality explosions before they reach your TSDB.

https://github.com/YElayyat/otel-cardinality-processor

1,280

Пятничный деплой

22 мая 2026 г., 18:36

📷 Photo

Fail2Ban больше не нужен? Разбираем PerSourcePenalties в OpenSSH на Ubuntu 26.04

Начиная с OpenSSH 9.7, sshd умеет автоматически ограничивать на время подозрительные IP без Fail2Ban и iptables. В Ubuntu 26.04 эта функция уже включена по умолчанию — даже если в sshd_config про неё ничего не написано. https://habr.com/ru/articles/1032648/ разобраться с тем, как это работает.

https://t.me/usr_bin_linux

1,290

Пятничный деплой

22 мая 2026 г., 18:36

Ubuntu 26.04 LTS: на что смотреть перед миграцией с 24.04

23 апреля Canonical выпустил Ubuntu 26.04 LTS — Resolute Raccoon. Про сам релиз уже написали все, поэтому не будем повторяться — и посмотрим на релиз с другой стороны.

26.04 — это не косметическое обновление. cgroup v1 удален, DSA-ключи в OpenSSH больше не работают, apt-key окончательно убран, классический sudo заменен на Rust-реализацию, формат конфигов Dovecot изменился, Postfix больше не работает в chroot по умолчанию. Запустить do-release-upgrade и уйти на обед уже не получится: часть систем после такого обновления просто не поднимется.

https://habr.com/ru/companies/runity/articles/1028402/ того, на что обратить внимание при миграции, и краткий обзор изменений, которые на эту миграцию влияют.

https://t.me/usr_bin_linux

1,780

Пятничный деплой

22 мая 2026 г., 18:36

📷 Photo

Grafana 13 release

А вот и он. Что нового:

🚀 встроенные pre-built дашборды. На основе выбранного датасорса, графана предложит подходящие дашборды.

🚀 выдача предложений по выбору панелей дашбордов

🚀 улучшен дизайн поля для ввода запроса для визулизации в панели

🚀 появилась возможность переиспользования запросов при помощи функционала Saved queries

🚀 появилась возможность копирования стиля панели

🚀 Git Sync теперь доступен для всех редакций Grafana (импорт дашбордов и других объектов напрямую из репо)

https://grafana.com/blog/grafana-13-release-all-the-latest-features/

📱 https://t.me/monitorim_it | 📲 https://max.ru/id182905929815_biz

1,700

Пятничный деплой

22 мая 2026 г., 18:36

📷 Photo

https://github.com/openkube-hub/KubeUser — это Kubernetes оператор для управления пользователями, доступами и kubeconfig без Keycloak, Dex и других тяжёлых IAM решений. Вместо ручной выдачи сертификатов и RBAC всё описывается декларативно через User CRD, а оператор сам создаёт доступы и готовый kubeconfig.

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

KubeUser использует стандартный Kubernetes CSR API, автоматически создаёт RoleBinding и ClusterRoleBinding, а kubeconfig сохраняет как Secret внутри кластера.

1,770

Пятничный деплой

22 мая 2026 г., 18:36

🚀 Скоро: HashiCorp Vault 2.0!

В открытом доступе появился релиз-кандидат HashiCorp Vault 2.0 — первого крупного обновления за долгое время. Вас ждут автоматическая ротация секретов, передовые протоколы PKI и полная интеграция с Kubernetes.

🔐 Главные нововведения

• Автоматическая http://staticblock.tech/insights/hashicorp-vault-2-0-secrets-management-security секретов: Снижение числа инцидентов на 75% и сокращение разрастания учетных данных на 90% благодаря устранению статических кредов и динамической выдаче секретов.
• Передовые PKI-протоколы: Полная поддержка протоколов SCEP, EST и CMPv2 для автоматизации выдачи сертификатов. Теперь подписывать промежуточные сертификаты стало проще, а в alt_names можно использовать глоб-шаблоны.
• Нативная интеграция с Kubernetes: Динамическая инъекция секретов на уровне подов без изменения кода.
• Доработки и исправления: Обновление Go до версии 1.25.7, улучшение статуса sys/seal-backend-status для лучшего мониторинга и поддержка HashiCorp-плагинов как внешних бинарных файлов.

Финальный релиз, как ожидается, окончательно сформирует стандарт управления секретами в эпоху zero-trust. Официальной даты выхода пока нет, но ждать, судя по всему, осталось недолго. (час назад вышел билд на github: https://github.com/hashicorp/vault/releases/tag/v2.0.0)

https://discuss.hashicorp.com/t/vault-2-0-0-rc1-released/77296

• SCIM-провижининг: Полная автоматизация жизненного цикла пользователей и групп через синхронизацию с внешними IDP-платформами.
• Нативная поддержка SPIFFE: Аутентификация рабочих нагрузок с помощью JWT-SVID, что позволяет бесшовно вписаться в экосистему SPIFFE.
• Визуальный конструктор политик: Генерация ACL-политик прямо в веб-интерфейсе Vault. Больше не нужно писать сложные правила вручную.
• Workload Identity Federation (WIF) для синхронизации секретов: Теперь для настройки синхронизации с AWS, GCP или Azure не нужны статичные креды — всё работает через федерацию.
• Расширение для публичных центров сертификации (Public CA): Vault теперь умеет оркестрировать выдачу и управление жизненным циклом сертификатов от публичных CA.
• In-Place Encryption SDK: Шифрование и дешифрование данных на стороне клиента без отправки данных в Vault. Ключевой функционал для конфиденциальных сред.
• Ротация паролей локальных учетных записей: Управление учетными данными локальных пользователей Linux с автоматической ротацией.
• Умная ротация для LDAP: Гибкая настройка ротации статических кредов LDAP: начальные пароли, самоуправляемая ротация, расписания и политики повторных попыток при сбоях.
• Мультикластерные уведомления о событиях: Теперь вы не пропустите ни одного важного изменения в вашей распределенной системе.
• Улучшенный онбординг: Новый GUI помогает быстрее освоить ключевые функции, а процесс создания неймспейсов стал интуитивно понятным.

Пятничный деплой

22 мая 2026 г., 18:36

Пополнение среди проектов от подписчиков:
Lynxdb - schema-on-read база данных и аналитическая система для анализа логов.

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

Lynx Flow язык запросов LynxDB,
По сути, это упрощённый и более интуитивный слой (синтаксический сахар) над Splunk SPL2, ориентированный на удобную работу с логами.

Возможности:
- режим конвейера - чтение из стандартного ввода или файлов, работает как grep. Нет сервера, нет конфигурации.
- Lynx Flow - group, let, parse, order by, join, CTE, доменные синтаксисы и многое другое. Частичная совместимость с SPL2.
- полнотекстовый поиск - инвертированный индекс FST + roaring bitmaps, фильтры Блума для пропуска сегментов.
- столбцовое хранение - пользовательский формат .lsg, временные метки с дельта-вариантами, кодирование по словарю, Gorilla XOR, LZ4
- материализованные представления - предварительно вычисленные агрегации с автоматической переадресацией запросов, ускорение до ~400 раз.
- кластерный режим - добавьте --cluster.seeds для распределенной работы; общее хранилище на основе S3.
- загрузка данных без предварительной обработки - Elasticsearch_bulk, OpenTelemetry OTLP, Splunk HEC

https://github.com/lynxbase/lynxdb

1,760

Пятничный деплой

22 мая 2026 г., 18:36

⚡️ 20 kubectl команд, которые экономят часы в проде

Когда что-то падает — не нужен весь kubectl.
Достаточно этих команд 👇

🧪 Быстрый дебаг
• kubectl get pods -A --field-selector=status.phase!=Running
• kubectl get pods -A --sort-by=.status.containerStatuses[*].restartCount
• kubectl describe pod  -n 
• kubectl get pods -A | grep Pending

📜 Логи и ресурсы
• kubectl logs  -n  --previous
• kubectl top pods -A
• kubectl describe node 

🧭 Сеть и размещение
• kubectl get pod  -n  -o wide
• kubectl get pods -A -o wide | grep 
• kubectl get svc -A -o wide
• kubectl run tmp-shell -it --rm --image=busybox -- /bin/sh

🚀 Роллауты и откаты
• kubectl port-forward svc/ 8080:80
• kubectl rollout history deployment/
• kubectl rollout undo deployment/
• kubectl get deployment  -o yaml

🧩 События и конфиг
• kubectl get events -A --sort-by=.metadata.creationTimestamp
• kubectl describe svc 
• kubectl get endpoints 
• kubectl get ingress -A

Освоишь эти команды - будешь закрывать 90% проблем в проде намного быстрее.

Сохрани, чтобы не искать потом 🔖

1,630

Пятничный деплой

22 мая 2026 г., 18:36

📷 Photo

Обновляем кластеры Kubernetes: лучшие практики

Всем DevOps! 🖖Подготовили пошаговые инструкции по обновлению к релизу Kubernetes v1.36 запланированный на 22 апреля.

В https://prodopshub.com/upgrade-kubernetes-cluster-to-v1-36/ TechOps-инженер перечислил лучшие практики, которые помогают избежать случайных ошибок и лишнего дебага. Вы узнаете, какие компоненты обновлять в первую очередь и почему, что изучить подробнее, где тестировать и как откатываться.

Перед установкой v1.36 проверьте:
1. Текущую версию кластера, подов и kubeadm: не «прыгайте» с v1.34 до v1.36, одна минорная версия за раз
2. Бэкапы etcd, чтобы при сбое обновлений не потерять данные
3. Настройки политики соответствия для kubelet

👀 https://prodopshub.com/upgrade-kubernetes-cluster-to-v1-36/ сверяемся и делимся своей подборкой лучших практик в комментариях!

#девопс #kubernetes #лучшие_практики

1,600

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

Правильное Питание для техники с Systeme Electric

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

Для борьбы со всеми проблемами низкого качества электропитания Systeme Electric разработали первые в мире ПП-ИБП — Правильное Питание для техники.

Systeme Electric — это бывшее российское подразделение Schneider Electric, производителя легендарных бесперебойников APC. «Шнайдер» ушел, а технологии, производство и команда лучших инженеров остались.

ПП-ИБП с онлайн-топологией (нулевым временем переключения на батареи) от Systeme Electric — это:

✔️ Тотальный онлайн-ЗОЖ — онлайн Защита от Отключений Железа.
✔️ Повышенная БЖУ — Бесперебойность Жизненно-важных Устройств. Тянут нагрузку в 150% от номинальной.
✔️ Настоящий суперфуд для оборудования — высочайший КПД 95%.
✔️ Самое полное ПП-меню — поддерживают все возможные интерфейсы и протоколы (EPO, SNMP, RS-485, RS-232, USB, RJ45/RJ11, EMBS).

И еще ряд преимуществ ПП-ИБП:

✔️ Монолитный корпус со встроенными аккумуляторами и продвинутый поворотный LCD-дисплей с русским языком — удобство в управлении.
✔️ Горячая замена АКБ на уровне картриджей — замена батарей происходит мгновенно, без отключения ИБП, оборудование продолжает работать.
✔️ Автоматическое определение внешних АКБ — работа без ручных настроек, все работает сразу.
✔️ Подключение до 10 дополнительных внешних батарейных блоков — время автономной работы при необходимости можно увеличить.

Причем все это — в одном устройстве. А то знаете, как оно бывает: у одного производителя одно хорошо, у другого другое. А вот так, чтобы «все и сразу» — только в ПП-ИБП.

Systeme Electric дают официальную гарантию от производителя аж 3 года. Это рекорд среди всех конкурентов. У APC by Schneider было 2 года (именно было — пока «Шнайдер» из РФ не ушел), у «китайцев» в лучшем случае год, а на серозавезенные APC гарантии, конечно же, нет.

А если что-то будет непонятно, техподдержка круглосуточная: днем — звонки, чат и мессенджеры —24/7. Т. е. даже после 6 — можно!

И никакого дешманского электро-фастфуда. На здоровье техники не экономят!

Больше информации о ПП-ИБП Systeme Electric — https://bit.ly/deploysysteme

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

Benchmarking Kubernetes Log Collectors: vlagent, Vector, Fluent Bit, OpenTelemetry Collector, and more

В обойме VictoriaMetrics есть vlagent — высокопроизводительный сборщик логов для VictoriaLogs. Для проверки его производительности и корректности в условиях реальной производственной нагрузки был разработан набор бенчмарков и проведены тесты на 8 популярных сборщиках логов. В https://victoriametrics.com/blog/log-collectors-benchmark-2026/index.html, результаты по производительности, использованию ресурсов и корректности доставки.

https://t.me/monitorim_it

1,090

Пятничный деплой

8 мая 2026 г., 07:24

О чём логи Kubernetes не расскажут вам во время инцидента

Ритуал обработки алерта:

🔴 Срабатывает алерт.
🔴 Вы открываете логи.
🔴 Они выглядят нормально.
🔴 А продакшен всё ещё «горит».

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

https://teletype.in/@monitorim_it/what-kubernetes-logs-wont-tell-you-during-an-incid на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.

https://t.me/monitorim_it

1,180

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

QwenLM/qwen-code

Open-source AI-агент, который живёт в вашем терминале.

#ai

https://github.com/QwenLM/qwen-code

Больше про программирование на https://kodikapusta.ru/

1,370

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

💡McFly - это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.

McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.

• Поддерживает:
- Bash
- Zsh
- Fish

• Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.

• Установка:
Доступен через Homebrew, AUR, Nix и другие.

https://github.com/cantino/mcfly

#devops #девопс

1,480

Пятничный деплой

8 мая 2026 г., 07:24

Изменил формулу SLI — и сломал историю. Почему это ошибка и что делать вместо этого?

Привет, %username%! Пока я нахожусь в активном поиске работы, решил расписать подробно один тезис, который внезапно сформировался на прошедшем DevOpsConf 2026. Знакомая ситуация: измерял сервис одним способом, потом понял, что формула кривая, и просто поправил SLI. Кажется — исправил ошибку. На самом деле — создал новую, куда серьёзнее.

Когда меняется формула расчёта SLI, данные до и после этой точки описывают принципиально разные вещи. В статистике это называется structural break — и именно поэтому статистические агентства при смене методологии никогда не правят исторические ряды задним числом, а ведут два ряда параллельно.

В контексте SLO это особенно больно: error budget считается нарастающим итогом за 28–30 дней. Если SLI резко скакнул из-за смены формулы — error budget либо обнулится, либо станет «бесконечным», хотя реальная надёжность сервиса не изменилась ни на байт.

Что делать правильно:

- Aspirational SLO — запускаешь новый SLO параллельно старому без enforcement. Старый работает, новый наблюдается. Никто не "облажался", просто появился более точный взгляд — это паттерн из Google SRE Workbook;
- Новая метрика вместо изменения старой — именно так устроен мир Prometheus/OpenTelemetry: не переименовывай, а создавай новую и deprecate'ни старую по циклу, как это делает Kubernetes;
- Ретроактивная проверка — если меняешь только порог SLO (не формулу SLI!), можно проверить на исторических данных: поймал бы новый SLO реальные инциденты, нет ли false positives;

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

Кратко: изменение математики SLI — это не fix, это создание нового измерения. Старое не удаляй, запускай новое рядом, переходи через согласованный deprecation-цикл с явной датой и документацией.

Делитесь в комментариях — сталкивался ли ты с ситуацией, когда формулу SLI хотелось «подправить»? Как решал? Что больнее — series break в метриках или объяснение stakeholder'ам, почему error budget внезапно изменился?

PS: Еще у нас разгорелся холивар на тему надежность vs доступность — пиши в комментах, если интересны подробности.

#SRE #SLO #SLI #Reliability #ErrorBudget #Observability #DevOps #Metrics #SiteReliabilityEngineering #OnCall

Пятничный деплой

8 мая 2026 г., 07:24

Securing Production Debugging in Kubernetes

This covers safer Kubernetes debugging with least-privilege RBAC, short-lived identity-bound credentials, and audited SSH-style access paths.

https://kubernetes.io/blog/2026/03/18/securing-production-debugging-in-kubernetes

1,100

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

Провалы в памяти Kubernetes: 90 секунд задержки

👩‍💻 Начинаем понедельник с разбора. На портале Dzone Шамшера Хан объясняет, с чем связана задержка в отчётности Kubernetes. Причины оставили ниже, подробности о решениях на примере лабы – в https://dzone.com/articles/kubernetes-the-90-second-evidence-gap

Задержка в отчетности возникает из-за трёх факторов:
• быстрое удаление событий и метрик
• отсутствие информации об объекте или конфиг в момент сбоя,
• данные из разных систем (метрики, события, логи) не связаны по времени.

Хан приводит 3 предела, в которые упирается диагностика: запрос состояния системы в конкретный момент (состояние пода в 22:32), единый контекст для сравнения метрик и сохранение истории действий контроллеров.

👩‍💻 Примеры на практике – в https://github.com/opscart/kubernetes-diagnostic-primitives

Из очевидных плюсов – Kubernetes быстро восстанавливается, минус – не сохраняет причины падения. Важно фиксировать «следы инцидента», иначе картина сбоя будет неполной и приведет к повторным ошибкам.

Продуктивной недели без инцидентов!

#девопс #k8s

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

rafska/Awesome-local-LLM

Подборка полезных платформ, инструментов, практик и ресурсов, которые помогают запускать LLM локально

#ai

https://github.com/rafska/Awesome-local-LLM

Больше про программирование на https://kodikapusta.ru/

1,430

Пятничный деплой

8 мая 2026 г., 07:24

📷 Photo

Аллокаторы

Автор продолжает цикл статей про рантайм Go. Теперь на очереде разбор аллокаторов.

Аллокатор, по сути, компонента runtime, который эффективно управляет выделением и освобождением памяти в куче. Вместо того чтобы каждый раз обращаться к операционной системе через медленные системные вызовы, runtime заранее запрашивает у ОС крупные блоки памяти, которые затем делятся на страницы по 8 КБ. Для удовлетворения запросов программы страницы группируются в спаны, каждый из которых предназначен для объектов строго одного размера. Для решения проблемы конкурентного доступа "тысяч горутин" используется трехуровневая иерархия: быстрый и неблокирующий mcache на каждом процессоре, централизованное хранилище спанов mcentral для каждого класса с короткими блокировками и глобальный mheap, управляющий страницами.

Подробнее в статье

#golang

https://kodikapusta.ru/news/856-allokatory

Поддержать проект на boosty: https://boosty.to/kodikapusta

1,430

Пятничный деплой

1 мая 2026 г., 20:11

📷 Photo

23 апреля в 18:30 (мск) пройдёт офлайн-митап MWS Cloud Platform «Под капотом: инфраструктура». Также будет онлайн-трансляция. В программе доклады инженеров, которые ежедневно решают нетривиальные задачи при работе над инфраструктурными сервисами облака.

Из докладов вы узнаете:

— какие возможности открывают быстрые объектные хранилища, в том числе для работы с большими языковыми моделями
— как упростить для пользователя работу с управляемыми сервисами в облаке
— как снизить риски ошибок конфигурации и улучшить наблюдаемость с помощью сервисных агентов

После основной части — нетворкинг и угощения. Регистрируйтесь на митап! Это возможность обсудить нюансы, которые всплывают только в продакшене, и будут полезны на практике.

🗓23 апреля, начало в 18:30
📍Москва, Дом Культур, ул. Сретенка, 25

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

https://mws.ru/events/tech-meetupmsk23042026/?utm_source=tg_seeding&utm_medium=cpp&utm_campaign=mws_mitap_v_msk_infrastructure&utm_content=count0_digest_&erid=2VfnxvyTiZG

Пятничный деплой

1 мая 2026 г., 20:11

Перегрузка когнитивной памяти

Смотрел доклад https://www.youtube.com/watch?v=3fiFtyAqBeI и там попалась очень наглядная иллюстрация того, что происходит, если не давать себе передышки и не оставлять место для «полезной» (germane) https://t.me/teamleading.

Идея довольно простая: если не контролировать встроенную (intrinsic) и внешнюю (extraneous) нагрузки, они забивают рабочую память.
А когда она переполняется — вы просто перестаёте учиться и нормально осмыслять происходящее.

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

Советы из книг про эффективность в итоге сводятся к одной вещи — создавать пространство для полезной нагрузки, лимитируя две оставшихся.

Есть куча историй про CEO (вплоть до Джобса, Гейтса и Безоса), у которых в расписании всегда стоит время «на подумать». И это время нельзя занимать никакими, даже очень важными, встречами.

Что они на самом деле делают?
Они не «магически лучше думают», а освобождают рабочую память, ограничивая объём встроенной и внешней нагрузки в течение дня — чтобы оставить ресурс на осмысление и принятие решений.

В общем, поставьте прямо сегодня в своё расписание блок на «подумать». И думайте... это, как ни странно, тоже ваша работа.

Пятничный деплой

21 апр. 2026 г., 17:35

gh-dash — твой GitHub прямо в терминале

Привет, %username%! Если ты проводишь половину рабочего дня в браузере, переключаясь между PR-ами и issues разных репозиториев — есть способ это исправить и не выходить из терминала.

https://github.com/dlvhdr/gh-dash — это расширение для GitHub CLI (gh), которое даёт тебе богатый TUI-интерфейс для работы с GitHub. Вся суть в том, что ты настраиваешь нужные тебе секции с PR-ами и issues, и видишь ровно то, что нужно — без лишнего шума.

Что умеет gh-dash:

- Настраиваемые секции PR-ов и issues — отдельно под каждый репозиторий или запрос;
- Vim-style хоткеи (и возможность их переопределить под себя);
- Кастомные actions — можно вшить свой workflow прямо в интерфейс;
- Полный цикл работы с PR: diff, комментарии, checkout, push, update — всё не выходя из терминала;
- Конфигурация через обычный YAML-файл;

Под капотом — bubbletea и lipgloss от Charm (те самые ребята, которые делают красивые TUI-инструменты на Go), delta для просмотра диффов и нативный gh для GitHub API. Проект активно развивается и это не может не радовать.

Установка — одна команда:

gh extension install dlvhdr/gh-dash

Лично мне кажется, что такие инструменты реально меняют DX: вместо того чтобы прыгать между браузером и терминалом, ты остаёшься в своём привычном рабочем контексте и не теряешь фокус.

А как у тебя выстроена работа с GitHub? Используешь CLI-утилиты или всё через браузер/IDE? Есть ли другие расширения для gh, которые зашли в ежедневный workflow — поделись в комментариях!

#GitHub #CLI #DevTools #Terminal #TUI #DevOps #SRE #DeveloperExperience #gh #OpenSource

1,100

Пятничный деплой

21 апр. 2026 г., 17:35

О чём логи Kubernetes не расскажут вам во время инцидента

Ритуал обработки алерта:

🔴 Срабатывает алерт.
🔴 Вы открываете логи.
🔴 Они выглядят нормально.
🔴 А продакшен всё ещё «горит».

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

https://teletype.in/@monitorim_it/what-kubernetes-logs-wont-tell-you-during-an-incid на уровень выше логов и посмотреть на то, что предшествовало проблеме. Только опыт.

https://t.me/monitorim_it

1,140

Пятничный деплой

21 апр. 2026 г., 17:35

📷 Photo

Чем заняться 9 апреля?

(спойлер: будет 🔥)

В Москве пройдёт Deckhouse Conf 2026. Если для вас импортозамещение — это не просто лозунг, а реально рабочий софт, то намек вам ясен: место встречи — «Главная сцена».

📍Что будет интересного:

—Два трека: о всех кишках Deckhouse и реалистичные кейсы внедрения. Никакой теории из учебников.
—SDN внутри Kubernetes, виртуализация, которая у всех болит, Software-Defined Storage и мониторинг с кастомными дашбордами.
—15 крутых спикеров: не просто текст на слайдах, а настоящие практики, которые знают, что делать, когда все падает.

🎯 Бонусы для любознательных:

——Демозона: можно не только смотреть и слушать, но и трогать. Пощупать стенды и задать вопросы, от которых архитекторам будет весело.
Нетворкинг с людьми, которые тянут K8s на своих плечах в России.
—Участие бесплатное, но есть премодерация заявок. Так что регаемся заранее и занимаем места, пока зал не лопнул.

Надеюсь, вы успеете заглянуть и прокачаться. https://deckhouseconf.ru/?utm_source=telegram&utm_medium=count0_digest&utm_campaign=dhconf_partner

Пятничный деплой

21 апр. 2026 г., 17:35

witr (Why is this running?)

Утилита witr отвечает на один-единственный вопрос:

Почему это запущено?

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

Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.

https://github.com/pranshuparmar/witr

https://t.me/usr_bin_linux

1,110

Пятничный деплой

21 апр. 2026 г., 17:35

linnix

eBPF-powered Linux observability with AI incident detection.

https://github.com/linnix-os/linnix

1,190

Пятничный деплой

6 апр. 2026 г., 08:02

🎥 Video

Nerdlog - быстрый, ориентированный на удаленное взаимодействие, многохостовый TUI-просмотрщик логов с временной гистограммой и без центрального сервера. Он создан по мотивам Graylog/Kibana, но без лишних функций. Практически не требует настройки.

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

Основной сценарий использования: чтение системных журналов (из файлов /var/log/messages или /var/log/syslog, или непосредственно из journalctl) с одного или нескольких удаленных хостов. Очень эффективно даже при работе с большими файлами журналов (например, 1 ГБ и более).

Он поддерживает некоторые другие форматы логов и может использовать любые файлы логов, но именно это и стало основной причиной внедрения: наш бэкэнд веб-сервиса работал как службы systemd на множестве экземпляров Linux, выводя большое количество логов, и мы хотели иметь возможность эффективно читать эти логи и получать гистограмму временной шкалы, как это делают такие инструменты, как Graylog.

https://github.com/dimonomid/nerdlog

Опубликовано в https://t.me/gitgate

#moni #log #graylog #kibana #journalctl #journald

Пятничный деплой

6 апр. 2026 г., 08:02

📷 Photo

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

https://techdialogos.ru/#day2

Начнем с базы эксплуатации - мониторинга. Как построить мониторинг, который будет помогать понять что реально происходит с продом? Что важнее, мониторинг инфраструктуры или бизнес метрики и как долго нужно хранить данные. И это только первая лекция. А всего их семь.

Расписание и билеты по ссылке

https://techdialogos.ru/?utm_source=tg&utm_medium=fridays_rollout&utm_campaign=mk

1,060

Пятничный деплой

6 апр. 2026 г., 08:02

witr (Why is this running?)

Утилита witr отвечает на один-единственный вопрос:

Почему это запущено?

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

Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.

https://github.com/pranshuparmar/witr

https://t.me/usr_bin_linux

912

Showing 30 of 37 posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

Пятничный деплой

Пятничный деплой

Рейтинг

Рост участников (Последние 7 дней)

Последние посты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Виталий о позиции

Записки админа Иришки

Подкофейные камни

Дневник Каролины

Кремлевский шептун 🚀

КАТаю мысли

Петербургский гедонист 🥂

Хардкор, мозг и котики

Похожие каналы Telegram

Виталий о позиции

Записки админа Иришки

Подкофейные камни

Дневник Каролины

Кремлевский шептун 🚀

КАТаю мысли

Петербургский гедонист 🥂

Хардкор, мозг и котики

Отзывы пользователей (0)

Последние посты