От себя добавлю, что многие болезни из обзора действительно актуальны и многие компании продолжают тащить за собой все эти болезни год за годом и победить их действительно сложно. От себя отмечу что передача дежурства, если есть объёмный контекст и шифт в пару дней, а то и неделя - отдельный геморрой
❤1
Forwarded from Enabling.team Insights
State of On-call 2025
В начале 2025 года на конференции SREcon25 Americas было представлено исследование состояния практики дежурств в организациях, в рамках которого были изучены десятки академических статей и отраслевых публикаций, а также проведен опрос среди практикующих инженеров.
В исследовании рассматриваются проблемы перегрузки и выгорания на дежурствах, отсутствие стратегии и измерений, слабый онбординг, формальные передачи смен и ограниченные полномочия инженеров. Также даются рекомендации по развитию: проактивная работа с алертами, регулярные измерения и обсуждения, улучшение эскалаций и релизных практик, усиление полномочий и осмысленные передачи смен.
Подробнее про основные выводы из исследования читайте в нашем обзоре.
#insights #report #sre
В начале 2025 года на конференции SREcon25 Americas было представлено исследование состояния практики дежурств в организациях, в рамках которого были изучены десятки академических статей и отраслевых публикаций, а также проведен опрос среди практикующих инженеров.
В исследовании рассматриваются проблемы перегрузки и выгорания на дежурствах, отсутствие стратегии и измерений, слабый онбординг, формальные передачи смен и ограниченные полномочия инженеров. Также даются рекомендации по развитию: проактивная работа с алертами, регулярные измерения и обсуждения, улучшение эскалаций и релизных практик, усиление полномочий и осмысленные передачи смен.
Подробнее про основные выводы из исследования читайте в нашем обзоре.
#insights #report #sre
👍1
☁️ ITENTIS CLOUD: топ-технологии без переплаты за логотип
ITENTIS CLOUD — это тот же класс технологий, что у крупных облаков: VPC, Kubernetes, S3, снимки, автомасштабирование, Tier III дата-центры. Без переплаты за логотип.
📣 Самое главное — вы как разработчик, администратор или сотрудник компании можете зарабатывать сами! Подключаете своего клиента или компанию, в которой работаете, — и с каждой его оплаты регулярно получаете свой процент.
🔥 Никаких странных наценок, скрытых опций и сюрпризов в конце месяца.
📞 Ещё один стальной аргумент — поддержка.
Не бот и не первая линия, которая ничего не решает, а живой инженер 24/7.
Нужно настроить Kubernetes, собрать нетиповую схему? Доведем до результата🦾
💥 Перенесите проекты в ITENTIS CLOUD и убедитесь в стабильности работы в течение бесплатного 14-дневного периода.
sales@itentis.ru
Бот — @itentis_bot
ITENTIS CLOUD — это тот же класс технологий, что у крупных облаков: VPC, Kubernetes, S3, снимки, автомасштабирование, Tier III дата-центры. Без переплаты за логотип.
📣 Самое главное — вы как разработчик, администратор или сотрудник компании можете зарабатывать сами! Подключаете своего клиента или компанию, в которой работаете, — и с каждой его оплаты регулярно получаете свой процент.
🔥 Никаких странных наценок, скрытых опций и сюрпризов в конце месяца.
📞 Ещё один стальной аргумент — поддержка.
Не бот и не первая линия, которая ничего не решает, а живой инженер 24/7.
Нужно настроить Kubernetes, собрать нетиповую схему? Доведем до результата🦾
💥 Перенесите проекты в ITENTIS CLOUD и убедитесь в стабильности работы в течение бесплатного 14-дневного периода.
sales@itentis.ru
Бот — @itentis_bot
👍1👎1
Forwarded from Библиотека Go-разработчика | Golang
Go 1.26, привёз полностью переписанный
go fix. Разбираемся, что изменилось.go fix — это статический анализатор + автоматический рефакторинг. Он находит устаревшие паттерны в коде и заменяет их более современными аналогами. Без ручной правки, без регрессий.
Как запустить:
# Починить всё в проекте
go fix ./...
# Посмотреть что изменится, не применяя
go fix -diff ./...
# Список доступных анализаторов
go tool fix help
# Документация по конкретному
go tool fix help forvar
# Запустить только один анализатор
go fix -minmax ./...
# Запустить все, кроме одного
go fix -any=false ./...
Иногда одно исправление открывает возможность для второго. Например, замена конкатенации строк в цикле на
strings.Builder может затем подсветить, что WriteString(fmt.Sprintf(...)) лучше заменить на fmt.Fprintf. Поэтому рекомендуют запускать go fix ./... дважды.В Go 1.26
go fix и go vet унифицированы: оба работают на одном фреймворке статического анализа. Разница только в критериях: vet ищет ошибки и репортит их, fix генерирует безопасные правки и применяет их.Команда Go строит «самообслуживаемую» модель: авторы библиотек смогут поставлять анализаторы вместе со своим кодом, а пользователи — применять их через
go fix без необходимости ждать обновлений.📍 Навигация: Вакансии • Задачи • Собесы
#GoToProduction
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Forwarded from Мишка на сервере (Mikhail Savin)
Как не сойти с ума, чиня прод – практические заметки SRE
Практические заметки SRE: принципы вместо героизма, DIS и graceful degradation, мониторинг по абсолюту и трендам, нагрузочные тесты и учения, GitOps, фичатогглы, процессы и психология дежурств. Как строить надёжную эксплуатацию и спокойно восстанавливаться из инцидентов.
https://jtprog.ru/sre-recipes-summary/
На написание этой статьи меня сподвигла книга “SRE. Рецепты выживания в продакшне для инженера по надежности” за авторством Натальи Савенковой.
#DevOps #SRE #Postmortem #Observability #incidentManagement #ChaosEngineering #post
Практические заметки SRE: принципы вместо героизма, DIS и graceful degradation, мониторинг по абсолюту и трендам, нагрузочные тесты и учения, GitOps, фичатогглы, процессы и психология дежурств. Как строить надёжную эксплуатацию и спокойно восстанавливаться из инцидентов.
https://jtprog.ru/sre-recipes-summary/
На написание этой статьи меня сподвигла книга “SRE. Рецепты выживания в продакшне для инженера по надежности” за авторством Натальи Савенковой.
#DevOps #SRE #Postmortem #Observability #incidentManagement #ChaosEngineering #post
🔥6
Forwarded from Sysadmin Tools 🇺🇦
Homelab
https://github.com/tograu/homelab
#ansible #vector #grafana #vps #k8s #kubernetes #k3s #traefik #argocd #victoriametrics #victorialogs
A personal Kubernetes homelab built with Ansible (IaC) and Argo CD (GitOps), running on VPS infrastructure.
https://github.com/tograu/homelab
#ansible #vector #grafana #vps #k8s #kubernetes #k3s #traefik #argocd #victoriametrics #victorialogs
Forwarded from linkmeup
Фактически статья о безграничной мощи eBPF в правильных руках. Тут автор очень глубоко, но без заумства, копает постгресовые спинлоки - самый низкоуровневый механизм отслеживания блокировок для защиты структур данных.
https://jnidzwetzki.github.io/2026/02/08/postgresql-spinlocks.html
https://jnidzwetzki.github.io/2026/02/08/postgresql-spinlocks.html
Forwarded from linkmeup
Через несколько минут стартуем разговор про DNS EBPF.
Наливайте чаёк, приносите печеньки, настраивайте ваши приёмники.
Ютуб: https://www.youtube.com/watch?v=NkOkc3NtqYA
Сайт: https://live.linkmeup.ru
Наливайте чаёк, приносите печеньки, настраивайте ваши приёмники.
Ютуб: https://www.youtube.com/watch?v=NkOkc3NtqYA
Сайт: https://live.linkmeup.ru
YouTube
telecom №156. DNS на eBPF
Мы уже рассказывали несколько раз про eBPF. И пришло время к нему вернуться. И обсудим мы его самое что ни на есть практическое применение.. в гиперскейлерах.
Кто:
Олег Горохов — инженер Трафик Тим НОК Яндекс. Фокус: задачи доставки траффика, DNS, NTP.…
Кто:
Олег Горохов — инженер Трафик Тим НОК Яндекс. Фокус: задачи доставки траффика, DNS, NTP.…
Forwarded from Performance matters!
Perf Weekly | №3
(инструменты, системы и производительность)
Linux perf-top basics: understand the %
All Roads Lead to IPC: Rethinking CPU Performance Design
IPC как главная метрика CPU. Архитектура процессора, узкие места, latency vs occupation и как это всё применять, чтобы ускорить код. Дорогу осилит идущий 🙂.
How can I learn about performance optimization?
Большой тред о том, как расти в performance engineering: как учиться, на чем фокусироваться, типичные ловушки и куча полезных ссылок.
А возникшие вопросы можно обсудить в треде;)
(инструменты, системы и производительность)
Linux perf-top basics: understand the %
perf top базовая утилита, которая в три секунды покажет чем же занят процесс. Полезно делать это эффективно!All Roads Lead to IPC: Rethinking CPU Performance Design
IPC как главная метрика CPU. Архитектура процессора, узкие места, latency vs occupation и как это всё применять, чтобы ускорить код. Дорогу осилит идущий 🙂.
How can I learn about performance optimization?
Большой тред о том, как расти в performance engineering: как учиться, на чем фокусироваться, типичные ловушки и куча полезных ссылок.
dbi Blog
Linux perf-top basics: understand the %
By Franck Pachot . Linux kernel has a powerful instrumentation that can be accessed easily. When you want to drill down into your program functions to understand their CPU usage, “perf” is the easiest. It can attach to the processes, sample the CPU cycles…
👍1
Forwarded from Мишка на сервере (Mikhail Savin)
Когда AI ломает облако: кейс AWS и Kiro AI
Привет,
Что произошло по факту?
- В середине декабря один из AI-агентов (Kiro AI для разработчиков) получил доступ на внесение изменений и решил «delete and recreate environment» — фактически снес и пересоздал окружение, от которого зависел клиентский сервис для анализа стоимости использования AWS.
- Это привело к 13-часовому инциденту для клиентов, пользующихся этим сервисом.
- Источники внутри компании говорят, что было как минимум два подобных инцидента за последние месяцы, оба связаны с автономными AI-агентами, которым позволили действовать без человеческой проверки.
- Официальный комментарий AWS: это не «ошибка AI», а «user error» — некорректно настроенные права доступа, которые позволили агенту делать слишком много.
На мой взгляд, тут несколько очень важных уроков для нас с тобой:
- Автономный AI = ещё один супер-сильный и плохо предсказуемый оператор. Если ты даёшь агенту право менять инфраструктуру, он должен проходить те же уровни контроля, что и человек с prod-доступом (RBAC, approvals, change management, audit).
- «Пусть AI сам всё починит» без guardrails быстро превращается в «AI сам всё сломал». Нужны чёткие ограничения: где агент только предлагает actions, а где ему можно выполнять действия автоматически — и при каких SLO/условиях.
- Классические практики SRE никуда не делись: canary/gradual rollout даже для AI-автономии; принцип наименьших привилегий для агентов; чёткие runbook’и и контрольные точки, куда AI не может ступить без человека.
- Коммуникация тоже важна: AWS публично минимизирует масштаб («очень ограниченное событие», один сервис в одном регионе Китая), но 13 часов даунтайма для клиентского сервиса — это совсем не мелочь с точки зрения пострадавших пользователей.
Если смотреть шире — это хороший звоночек для всех, кто сейчас встраивает AI в CI/CD, incident response, remediation и управление инфраструктурой. AI-агенты очень быстро превращаются из «умного помощника» в «root с руками, которые не устают» — и это может быть как благом, так и идеальным источником инцидентов.
Предлагаю обсудить:
- Ходят ли AI-инструменты в твою prod-инфраструктуру сейчас? Что им разрешено: только советовать или уже что-то менять?
- Как бы ты ограничивал агентные системы: отдельные роли, sandbox-окружения, обязательные human approval на destructive actions?
- Считаешь ли ты честным называть такие кейсы «user error, not AI error», или это уже вопрос культуры ответственности и дизайна систем?
Делись опытом и идеями — особенно будет интересно почитать реальные истории, где AI уже помогает (или мешает) в эксплуатации.
@jtprogru_channel
@jtprogru_chat
#SRE #DevOps #AI #AWS #Incidents #Automation #Reliability #OnCall #Observability
Привет,
%username%! Тут всплыла интересная история: у AWS в декабре было как минимум два инцидента, в которых ключевую роль сыграли их же собственные AI-инструменты — агент Kiro и другие dev-инструменты на базе AI.Что произошло по факту?
- В середине декабря один из AI-агентов (Kiro AI для разработчиков) получил доступ на внесение изменений и решил «delete and recreate environment» — фактически снес и пересоздал окружение, от которого зависел клиентский сервис для анализа стоимости использования AWS.
- Это привело к 13-часовому инциденту для клиентов, пользующихся этим сервисом.
- Источники внутри компании говорят, что было как минимум два подобных инцидента за последние месяцы, оба связаны с автономными AI-агентами, которым позволили действовать без человеческой проверки.
- Официальный комментарий AWS: это не «ошибка AI», а «user error» — некорректно настроенные права доступа, которые позволили агенту делать слишком много.
На мой взгляд, тут несколько очень важных уроков для нас с тобой:
- Автономный AI = ещё один супер-сильный и плохо предсказуемый оператор. Если ты даёшь агенту право менять инфраструктуру, он должен проходить те же уровни контроля, что и человек с prod-доступом (RBAC, approvals, change management, audit).
- «Пусть AI сам всё починит» без guardrails быстро превращается в «AI сам всё сломал». Нужны чёткие ограничения: где агент только предлагает actions, а где ему можно выполнять действия автоматически — и при каких SLO/условиях.
- Классические практики SRE никуда не делись: canary/gradual rollout даже для AI-автономии; принцип наименьших привилегий для агентов; чёткие runbook’и и контрольные точки, куда AI не может ступить без человека.
- Коммуникация тоже важна: AWS публично минимизирует масштаб («очень ограниченное событие», один сервис в одном регионе Китая), но 13 часов даунтайма для клиентского сервиса — это совсем не мелочь с точки зрения пострадавших пользователей.
Если смотреть шире — это хороший звоночек для всех, кто сейчас встраивает AI в CI/CD, incident response, remediation и управление инфраструктурой. AI-агенты очень быстро превращаются из «умного помощника» в «root с руками, которые не устают» — и это может быть как благом, так и идеальным источником инцидентов.
Предлагаю обсудить:
- Ходят ли AI-инструменты в твою prod-инфраструктуру сейчас? Что им разрешено: только советовать или уже что-то менять?
- Как бы ты ограничивал агентные системы: отдельные роли, sandbox-окружения, обязательные human approval на destructive actions?
- Считаешь ли ты честным называть такие кейсы «user error, not AI error», или это уже вопрос культуры ответственности и дизайна систем?
Делись опытом и идеями — особенно будет интересно почитать реальные истории, где AI уже помогает (или мешает) в эксплуатации.
@jtprogru_channel
@jtprogru_chat
#SRE #DevOps #AI #AWS #Incidents #Automation #Reliability #OnCall #Observability
Reuters
Amazon's cloud unit hit by outage involving AI tools in December
Amazon's cloud unit AWS had suffered an outage impacting a cost-management feature in December, a spokesperson told Reuters on Friday.
❤3👍2
Forwarded from Админим с Буквой (Aleksandr Kondratev)
Запилил простейшую, "книжную" лабу для обучения разведке (recon). Отличие от всяких HTB в том что она полностью оффлайн - скачать и развернуть можно за 1 команду.
https://github.com/bykvaadm/sirella/blob/master/docs/README-student.md
https://github.com/bykvaadm/sirella/blob/master/docs/README-student.md
GitHub
sirella/docs/README-student.md at master · bykvaadm/sirella
Simple Recon Local Lab. Contribute to bykvaadm/sirella development by creating an account on GitHub.
Forwarded from GitHub Open Sauce
mickamy/sql-tap
Инструмент для просмотра SQL-трафика в реальном времени — прокси-демон с TUI / веб-клиентом
#golang
https://github.com/mickamy/sql-tap
Больше про программирование на https://kodikapusta.ru
Инструмент для просмотра SQL-трафика в реальном времени — прокси-демон с TUI / веб-клиентом
#golang
https://github.com/mickamy/sql-tap
Больше про программирование на https://kodikapusta.ru
🔥4
Приглашаем всех участников сообщества присоединиться к👉Merge Innopolis
17-18 апреля в прекрасном городе Иннополис соберутся профессионалы со всей России. Для вас подготовлены насыщенные два дня активного нетворкинга, интересные доклады и захватывающие мастер-классы.
Вас ждут 30+ тематических направлений и более 200 выступлений от лучших представителей индустрии. В программе есть секции DevOps, Backend, Frontend, QA и многие другие.
Мы подготовили уникальную программу, включающую выступления крутейших спикеров отрасли:
— Александр Крылов: Организуем процесс тестирования на K8s: лайфхаки и антипаттерны
— Евгений Харченко: DevOps Community: от идеи до движения
— Максим Цепков: DDD и современная архитектура: как проектировать модель и отражать ее в код
Специально для нашего сообщества действует эксклюзивная скидка 15% по промокоду MERGE15 🎉
Собирайте команду коллег, друзей или компанию единомышленников и приезжайте отдохнуть, пообщаться и вдохновиться новыми технологиями вместе с нами!
До встречи на конференции! ✈️
17-18 апреля в прекрасном городе Иннополис соберутся профессионалы со всей России. Для вас подготовлены насыщенные два дня активного нетворкинга, интересные доклады и захватывающие мастер-классы.
Вас ждут 30+ тематических направлений и более 200 выступлений от лучших представителей индустрии. В программе есть секции DevOps, Backend, Frontend, QA и многие другие.
Мы подготовили уникальную программу, включающую выступления крутейших спикеров отрасли:
— Александр Крылов: Организуем процесс тестирования на K8s: лайфхаки и антипаттерны
— Евгений Харченко: DevOps Community: от идеи до движения
— Максим Цепков: DDD и современная архитектура: как проектировать модель и отражать ее в код
Специально для нашего сообщества действует эксклюзивная скидка 15% по промокоду MERGE15 🎉
Собирайте команду коллег, друзей или компанию единомышленников и приезжайте отдохнуть, пообщаться и вдохновиться новыми технологиями вместе с нами!
До встречи на конференции! ✈️
❤5🔥4👍3👎1
Forwarded from Performance matters!
Perf Weekly | №3
(инструменты, системы и производительность)
Linux perf-top basics: understand the %
All Roads Lead to IPC: Rethinking CPU Performance Design
IPC как главная метрика CPU. Архитектура процессора, узкие места, latency vs occupation и как это всё применять, чтобы ускорить код. Дорогу осилит идущий 🙂.
How can I learn about performance optimization?
Большой тред о том, как расти в performance engineering: как учиться, на чем фокусироваться, типичные ловушки и куча полезных ссылок.
А возникшие вопросы можно обсудить в треде;)
(инструменты, системы и производительность)
Linux perf-top basics: understand the %
perf top базовая утилита, которая в три секунды покажет чем же занят процесс. Полезно делать это эффективно!All Roads Lead to IPC: Rethinking CPU Performance Design
IPC как главная метрика CPU. Архитектура процессора, узкие места, latency vs occupation и как это всё применять, чтобы ускорить код. Дорогу осилит идущий 🙂.
How can I learn about performance optimization?
Большой тред о том, как расти в performance engineering: как учиться, на чем фокусироваться, типичные ловушки и куча полезных ссылок.
dbi Blog
Linux perf-top basics: understand the %
By Franck Pachot . Linux kernel has a powerful instrumentation that can be accessed easily. When you want to drill down into your program functions to understand their CPU usage, “perf” is the easiest. It can attach to the processes, sample the CPU cycles…
Forwarded from 🚀🐳 Летит Кит: SRE и не только
👁 Увидимся на DevOpsConf 2026 на моем докладе!
Вы уже знаете, что я с 2026 года в ПК DevOpsConf, но еще осенью я подал несколько заявок на доклад. В этот раз оказался интересна тема SLO.
Доклад "Как SLO водят нас за нос" будет не о том, что это, как это реализовать, а про то, как и где можно проколоться в подсчетах, как система может сама обманывать вас, и как неправильное позиционирование и применение SLO приводит лишь к гонке за зелеными бордами, вместо реальной надежности. Конечно, просто пересказать это будет недостаточно - расскажу как можно это обходить.
📆 Встречаемся 3 апреля на
DevOpsConf 2026, Стрим: Наблюдаемость/Мониторинг инфраструктуры, Зал 6
🔖 В это году конференция на ВДНХ! Павильон № 38 Бизнес. Техноград
Вы уже знаете, что я с 2026 года в ПК DevOpsConf, но еще осенью я подал несколько заявок на доклад. В этот раз оказался интересна тема SLO.
Доклад "Как SLO водят нас за нос" будет не о том, что это, как это реализовать, а про то, как и где можно проколоться в подсчетах, как система может сама обманывать вас, и как неправильное позиционирование и применение SLO приводит лишь к гонке за зелеными бордами, вместо реальной надежности. Конечно, просто пересказать это будет недостаточно - расскажу как можно это обходить.
📆 Встречаемся 3 апреля на
DevOpsConf 2026, Стрим: Наблюдаемость/Мониторинг инфраструктуры, Зал 6
🔖 В это году конференция на ВДНХ! Павильон № 38 Бизнес. Техноград
👎2
Forwarded from GitHub'ненько
📖 Runbooks that run
Runbooks that Run. A local-first, executable runbook editor for real terminal workflows. Atuin Desktop looks like a doc, but runs like your terminal.
#kb #documentation #ops
https://github.com/atuinsh/desktop
feat:
✨ Magical shell history
👍 https://github.com/atuinsh/atuin
Runbooks that Run. A local-first, executable runbook editor for real terminal workflows. Atuin Desktop looks like a doc, but runs like your terminal.
#kb #documentation #ops
https://github.com/atuinsh/desktop
feat:
✨ Magical shell history
👍 https://github.com/atuinsh/atuin
❤1