Forwarded from Книжный куб (Alexander Polomodov)
How we use GenAI in SRE (Рубрика #SRE)
Я периодически почитываю статьи Google на тему "Distributed Systems and Parallel Computing" на их сайте research.google. Именно там я нашел статью "How we use GenAI in SRE" с абстрактом вида
Эта статья оказалась не статьей, а простенькой презентацией от 20 апреля 2024 года (сама презентация доступна здесь). Из этой презентации можно вытащить не так много нового
1) Тезис про то, как SRE связан с работой AI систем
2) Как SRE помогает AI
- Дизайн распределенных систем - системы, у которых основа завязана на AI, тоже должны хорошо масштабироваться и быть надежными
- Ускорить деплой - новые железные компоненты (GPU, TPU, ...) должны поступать в датацентры и эффективно шедулиться
- Trust & safety - результаты работы систем, основывающихся на AI моделях, должны быть выровнены относительно человеческих стандартов
- Эксплуатация и автоматизация - тренировка моделей и пайлайны для fine-tuning, релизов, откатов и так далее (вообще это можно называть MLOps)
3) Как AI помогает SRE
- Генеративный AI для документации и постмортемов - сохранение документации чистой и актуальной, создание изначальных постмортемов (видимо, рыба с автозаполнением части инфы)
- Автоматизация workflow - агентские процессы служат как workflow runners и выполняют часть функций на проде
- Оценка риска - еще до возникновения инцидента модели могут детектировать проблемы и исправлять часть из них
- Эффективность ресурсов - начиная с температур в датацентрам и до размещения сервисов по доступным машинкам ML модели помогают проду быть более здоровым и эффективным
В итоге, это доклад на хайповую тему, но вот содержание не уходит дальше рассказов о том, что SRE в Google теперь на AI-стероидах и применяется к AI системам:))
#SRE #Management #ML #AI #Processes #SystemDesign #DistributedSystems
Я периодически почитываю статьи Google на тему "Distributed Systems and Parallel Computing" на их сайте research.google. Именно там я нашел статью "How we use GenAI in SRE" с абстрактом вида
Службы Google работают на крупнейшей в мире сети компьютеров. Инженеры по надежности сайтов (SRE) следят за тем, чтобы весь стек был в порядке: центры обработки данных были безопасными, хорошо подготовленными; у нас были резервные механизмы и целостность данных; чтобы убедиться, что мы правильно проектируем наш стек, используя правильные компромиссы в области хранения, репликации и программного обеспечения. Генеративный ИИ — отличный инструмент, который сделает нас сверхэффективными: имея доступ к инструментам для создания наших самых сложных конфигураций, для классификации рисков и событий, для управления большими массивами машин с помощью агентов или для дешевой автоматизации сложных рабочих процессов. В этом докладе будет рассмотрен путь, который SRE начал много лет назад, чтобы стать по-настоящему дисциплиной AI-First, и последние достижения в области инструментов, практик и рабочих процессов.
Эта статья оказалась не статьей, а простенькой презентацией от 20 апреля 2024 года (сама презентация доступна здесь). Из этой презентации можно вытащить не так много нового
1) Тезис про то, как SRE связан с работой AI систем
SRE is crucial component to operate at scale AI systems that are trustworthy, safe and efficient
2) Как SRE помогает AI
- Дизайн распределенных систем - системы, у которых основа завязана на AI, тоже должны хорошо масштабироваться и быть надежными
- Ускорить деплой - новые железные компоненты (GPU, TPU, ...) должны поступать в датацентры и эффективно шедулиться
- Trust & safety - результаты работы систем, основывающихся на AI моделях, должны быть выровнены относительно человеческих стандартов
- Эксплуатация и автоматизация - тренировка моделей и пайлайны для fine-tuning, релизов, откатов и так далее (вообще это можно называть MLOps)
3) Как AI помогает SRE
- Генеративный AI для документации и постмортемов - сохранение документации чистой и актуальной, создание изначальных постмортемов (видимо, рыба с автозаполнением части инфы)
- Автоматизация workflow - агентские процессы служат как workflow runners и выполняют часть функций на проде
- Оценка риска - еще до возникновения инцидента модели могут детектировать проблемы и исправлять часть из них
- Эффективность ресурсов - начиная с температур в датацентрам и до размещения сервисов по доступным машинкам ML модели помогают проду быть более здоровым и эффективным
В итоге, это доклад на хайповую тему, но вот содержание не уходит дальше рассказов о том, что SRE в Google теперь на AI-стероидах и применяется к AI системам:))
#SRE #Management #ML #AI #Processes #SystemDesign #DistributedSystems
Google Docs
[Public] How we #GenAI in SRE (CommitConf '24)
How we #GenAI in SRE @rmedranollamas Madrid, 20/04/2024
Forwarded from Записки админа
🛠 Внезапное открытие сегодняшнего утра - оказывается, с помощью systemd и опций IPAddressDeny/IPAddressAllow в unit файле, можно контролировать сетевой доступ для приложения. Подробнее об этом...
- IP Accounting and Access Lists with systemd;
- Unintentionally troubleshooting a new way to filter traffic;
- systemd application firewalls by example.
#systemd #network #напочитать
- IP Accounting and Access Lists with systemd;
- Unintentionally troubleshooting a new way to filter traffic;
- systemd application firewalls by example.
#systemd #network #напочитать
Forwarded from ceph.expert
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ceph 19.2.0 (squid)
Вышел первый стабильный релиз 19 ветки с кодовым названием squid.
Пользователям iSCSI рекомендуется ознакомиться с трекером перед обновлением т.к. разработчики сталкивались с проблемами при обновлении с 19.1.1 до 19.2.0.
Краткое содержание основных изменений, которые принесла 19 ветка:
-RADOS: BlueStore был оптимизирован для лучше производительности при snapshot-intensive сценариях.
- RADOS: Сжатие LZ4 в BlueStore RocksDB теперь включено по умолчанию для повышения средней производительности и использования пространства на быстрых дисках.
- RADOS: Другие улучшения включают в себя более гибкие конфиги EC, OpTracker для помощи отладки проблем в модулях mgr, и улучшеный планировщик скраба.
- Dashboard: Улучшение в навигационном слое
- CephFS: Поддержка управления снапшотами и клонами CephFS, а также управление расписанием снапшотов.
- CephFS: управление возможностями авторизации для ресурсов CephFS
- CephFS: помощники монтирования cephfs volumes
- RBD: Функция diff-iterate теперь может выполняться локально, что значительно повышает производительность при использовании QEMU для оперативной синхронизации дисков и резервного копирования.
- RBD: Добавлена поддержка клонирования из снапшотов non-user типа.
- RBD: windows драйвер rbd-wnbd получил возможность мультиплексировать мапинг образов.
- RGW: Функция "Учетные записи пользователей" открывает несколько новых AWS совместимых IAM API для самостоятельного управления пользователями, ключами, группами, ролями, политиками и многим другим.
- RADOS: Это первый релиз в котором crimson, в качестве tech preview, доступен для широкого круга пользователей. Пока поддерживается только RBD на реплицируемых пулах. Для получения дополнительной информации про Crimson смотрите https://ceph.io/en/news/crimson
И многое другое.
Как всегда release notes первого стабильного релиза достаточно объемные и там много чего интересного.
Подробнее тут:
https://ceph.com/en/news/blog/2024/v19-2-0-squid-released/
P.S. Как обычно не рекомендую катить в прод с ценными данными первый релиз, даже не смотря на то, что его называли стабильным ;)
#ceph #squid #release #cephexpert
Вышел первый стабильный релиз 19 ветки с кодовым названием squid.
Пользователям iSCSI рекомендуется ознакомиться с трекером перед обновлением т.к. разработчики сталкивались с проблемами при обновлении с 19.1.1 до 19.2.0.
Краткое содержание основных изменений, которые принесла 19 ветка:
-RADOS: BlueStore был оптимизирован для лучше производительности при snapshot-intensive сценариях.
- RADOS: Сжатие LZ4 в BlueStore RocksDB теперь включено по умолчанию для повышения средней производительности и использования пространства на быстрых дисках.
- RADOS: Другие улучшения включают в себя более гибкие конфиги EC, OpTracker для помощи отладки проблем в модулях mgr, и улучшеный планировщик скраба.
- Dashboard: Улучшение в навигационном слое
- CephFS: Поддержка управления снапшотами и клонами CephFS, а также управление расписанием снапшотов.
- CephFS: управление возможностями авторизации для ресурсов CephFS
- CephFS: помощники монтирования cephfs volumes
- RBD: Функция diff-iterate теперь может выполняться локально, что значительно повышает производительность при использовании QEMU для оперативной синхронизации дисков и резервного копирования.
- RBD: Добавлена поддержка клонирования из снапшотов non-user типа.
- RBD: windows драйвер rbd-wnbd получил возможность мультиплексировать мапинг образов.
- RGW: Функция "Учетные записи пользователей" открывает несколько новых AWS совместимых IAM API для самостоятельного управления пользователями, ключами, группами, ролями, политиками и многим другим.
- RADOS: Это первый релиз в котором crimson, в качестве tech preview, доступен для широкого круга пользователей. Пока поддерживается только RBD на реплицируемых пулах. Для получения дополнительной информации про Crimson смотрите https://ceph.io/en/news/crimson
И многое другое.
Как всегда release notes первого стабильного релиза достаточно объемные и там много чего интересного.
Подробнее тут:
https://ceph.com/en/news/blog/2024/v19-2-0-squid-released/
P.S. Как обычно не рекомендую катить в прод с ценными данными первый релиз, даже не смотря на то, что его называли стабильным ;)
#ceph #squid #release #cephexpert
🔥1
Forwarded from Мониторим ИТ
ClickHouse как бэкенд для Prometheus
Вы узнаете про мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье также есть рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics. Читать статью.
Вы узнаете про мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье также есть рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics. Читать статью.
How To Use Proxy Server To Access Internet at Shell Prompt With http_proxy Variable
Как указывать прокси сервер в командной строке. В коментах к статье есть дополнительные примеры.
https://www.cyberciti.biz/faq/linux-unix-set-proxy-environment-variable/
#linux #shell #proxy #env
Как указывать прокси сервер в командной строке. В коментах к статье есть дополнительные примеры.
https://www.cyberciti.biz/faq/linux-unix-set-proxy-environment-variable/
#linux #shell #proxy #env
nixCraft
How To Use Proxy Server To Access Internet at Shell Prompt With http_proxy Variable
If you are behind a proxy server, here is how you can set proxy environment variable to let you access internet via proxy server in Linux/Unix
Forwarded from Владислав Князев
К. Вигерс - Выжимка.pdf
5.9 MB
Карл Вигерс. Краткая выжимка книги "Разработка требований к программному обеспечению".
📘 Репосты в Избранное приготовили?
Нашел классную структурированную версию труда старины Карла. Какой-то герой сократил книгу в 10 (!) раз — с 736 страниц до 72. И сделал это прям качественно!
Забирайте.
@godnolytika
Нашел классную структурированную версию труда старины Карла. Какой-то герой сократил книгу в 10 (!) раз — с 736 страниц до 72. И сделал это прям качественно!
Забирайте.
@godnolytika
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from /usr/bin
Forwarded from Кубертатный период (Pavel Klyuev)
Kubernetes Guru
Очень интересный сервис: выдает достаточно точные ответы с примерами на вопросы про Kubernetes с помощью AI.
Этот сервис работает на основе подхода RAG и по результатам тестирования иногда дает более точные ответы, чем другие популярные AI, например ChatGPT.
Подробнее -- https://medium.com/@PlanB./kubernetes-guru-a-new-ai-tool-for-mastering-k8s-challenges-69bab4e57c84
Очень интересный сервис: выдает достаточно точные ответы с примерами на вопросы про Kubernetes с помощью AI.
Этот сервис работает на основе подхода RAG и по результатам тестирования иногда дает более точные ответы, чем другие популярные AI, например ChatGPT.
Подробнее -- https://medium.com/@PlanB./kubernetes-guru-a-new-ai-tool-for-mastering-k8s-challenges-69bab4e57c84
Forwarded from feedmetoo (Alexey Rybak)
prog_msk_files_are_hard.pdf
3.4 MB
Для надежной записи просто fsync – недостаточно. О подводных камнях записи и гарантий сохранения - в слайдах свежей лекции Дмитрия Родионова (Пикодата). Видео: https://www.youtube.com/watch?v=1V_UfMZdO6Q
Forwarded from Записки админа
💣 Почему бы в пятницу не грохнуть часть инфраструктуры своего прода и посмотреть как пойдут дела?
- Deploy on Friday? How About Destroy on Friday! A Chaos Engineering Experiment - Part 1;
- Destroy on Friday: The Big Day. A Chaos Engineering Experiment - Part 2.
#sre #напочитать
- Deploy on Friday? How About Destroy on Friday! A Chaos Engineering Experiment - Part 1;
- Destroy on Friday: The Big Day. A Chaos Engineering Experiment - Part 2.
#sre #напочитать
Forwarded from DevOps&SRE Library
Understanding DNS in Kubernetes
https://povilasv.me/understanding-dns-in-kubernetes
In this post, we will cover the following:
- Overview of DNS Resolution and CoreDNS, the default DNS provider in Kubernetes.
- Kubernetes DNS policies, such as ClusterFirst, Default, and None, and their effects on pod DNS configurations.
- Differences between The GNU C Library (glibc) and musl libraries.
https://povilasv.me/understanding-dns-in-kubernetes
Forwarded from Maxim Ivanov
Называется где взять время на все
SRE Day новый 2024 Q4 вышел - https://www.youtube.com/@sreday/videos
Observability Day и AI Day Вышли - https://www.youtube.com/@cncf/videos
SRE Unix Linux etc видео вышли - https://www.youtube.com/@UsenixOrg/videos
Я конечно рад, но не от всего сердца =)
SRE Day новый 2024 Q4 вышел - https://www.youtube.com/@sreday/videos
Observability Day и AI Day Вышли - https://www.youtube.com/@cncf/videos
SRE Unix Linux etc видео вышли - https://www.youtube.com/@UsenixOrg/videos
Я конечно рад, но не от всего сердца =)
YouTube
SREday
Share your videos with friends, family, and the world
Forwarded from DevOps Deflope News
Red Hat объявила о передаче набора инструментов для работы с контейнерами, включая Podman, Buildah и Skopeo, под управление Cloud Native Computing Foundation: https://goo.su/nK98BDU
Это обеспечит повышение прозрачности разработки, поддержку открытых стандартов и активное участие сообщества в развитии инструментов.
Это обеспечит повышение прозрачности разработки, поддержку открытых стандартов и активное участие сообщества в развитии инструментов.
Forwarded from Мониторим ИТ
Incident management at major sporting goods e-commerce
В этой статье техническая команда Декатлона рассказывает как у них устроена работа с инцидентами.
«Одним из главных препятствий, с которыми мы столкнулись, было отсутствие классификации инцидентов. Без четкого метода категоризации и квалификации инцидентов было сложно эффективно вовлекать соответствующие команды с правильным приоритетом, когда они не знали уровень серьезности. Каждая проблема казалась уникальной, что усложняло координацию и разрешение.»
Читать статью
❗️Статья в блоге на Medium
В этой статье техническая команда Декатлона рассказывает как у них устроена работа с инцидентами.
«Одним из главных препятствий, с которыми мы столкнулись, было отсутствие классификации инцидентов. Без четкого метода категоризации и квалификации инцидентов было сложно эффективно вовлекать соответствующие команды с правильным приоритетом, когда они не знали уровень серьезности. Каждая проблема казалась уникальной, что усложняло координацию и разрешение.»
Читать статью
❗️Статья в блоге на Medium
Forwarded from Yandex Cloud
Поэтому мы много работаем над тем, чтобы обеспечивать стабильность платформы. А если что-то идет не так, прозрачно и открыто рассказываем о том, что произошло и что мы делаем, чтобы избежать подобных ситуаций в будущем.
29 ноября 2024 года в работе облачной платформы произошел масштабный сбой, который повлиял на сервисы наших клиентов.
Мы приносим искренние извинения каждому, кого затронули перебои в работе платформы. А также благодарим коллег по индустрии, кто написал нам слова поддержки.
#yacloud_news
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1😁1
Forwarded from Sysadmin Tools 🇺🇦
PerformanceAnalysisAndTuningOnModernCPUs_SecondEdition.pdf
21.1 MB
The book "Performance Analysis and Tuning on Modern CPU"
https://github.com/dendibakh/perf-book
#book #perfomance
My book is a 170+ page guide for optimizing the performance of applications that run on modern CPUs. It combines the knowledge of many experts from different industries, to whom I'm very thankful. Engineers from Google, Facebook, leading HFT, and game development firms helped me shape this book
https://github.com/dendibakh/perf-book
#book #perfomance
Forwarded from Geeks (Shpak A.)
Распробовал на днях утилиту sq. Если jq - это инструмент для выборки и красивой визуализации данных из джейсонок, то sq - это все тоже самое (и даже чуть больше), но для баз данных. Выглядит прикольно, использовать (после jq) достаточно интуитивно, есть прикольные плюшки (например, просмотр диффа двух таблиц), умеет импортировать/экспортивароть данные. И, естественно, это опенсорсный проект. В общем, мне понравлось настолько, что не стыдно и вам показать https://sq.io/
sq
sq data wrangler
Forwarded from Enabling.team Insights
В начале 2024 года вышел отчет по состоянию Site Reliability Engineering в индустрии — The SRE Report 2024. Это уже 6-е издание отчета, исследования проводятся с 2018 года рабочей группой, состоящей из сотрудников Catchpoint и приглашенных экспертов. В подготовке текущего отчета участвовали: Niall Murphy (автор книг Site Reliability Engineering и The Site Reliability Workbook), Alex Hidalgo (автор книги Implementing SLO), Alex Elman (Indeed), Sarah Butt (SentinelOne), Kurt Andersen (Clari, SREcon) и др. Про компанию Catchpoint известно, что они разрабатывают SaaS платформу для Digital Experience Monitoring, аналогами которой являются платформы от Datadog, Dynatrace и New Relic. Исследование проводилось в форме опроса, в котором в этом году приняло участие 433 представителя индустрии, большинство из Америки и крупных компаний (больше 1000 сотрудников) из следующих индустрий: Technology, Financial, Healthcare, Government и Professional services.
Что интересного мы отметили в отчете:
1. В небольших компаниях (до 100 инженеров) функция SRE централизована в одной команде, поддерживающей несколько сервисов. С ростом компании происходит разделение на продуктовые и платформенные команды, что приводит к изменению топологий и структуры SRE команды;
2. Основные трудности с которыми сталкиваются SRE команды: планирование бюджета и ресурсов, приоритизация и архитектура. При этом найм, взаимодействие с командами и прозрачность работы отмечают реже;
3. С точки зрения влияния SRE на бизнес (Business Value) отмечают следующие факторы: Операционная эффективность (Operational Efficiencies), Customer Satisfaction и Customer Experience, Repair Times и реже — соблюдение SLA и Velocity;
4. Наиболее сложными аспектами решения инцидентов выделяют диагностику и поиск проблем, эскалацию и координацию между участниками, извлечение уроков и обучение на инцидентах;
5. Основное внимание уделяется решению инцидентов, оказывающим значительное влияние на пользователей, инцидентам высокого уровня (High severity) и тем, которые видны публично;
6. В качестве областей для улучшения процессов надежности выделяют: смену фокуса с исправлений на обучение на инцидентах, установление связей между инцидентами, выполнение action items после разбора инцидентов;
7. Разбор инцидентов, проведение ретроспектив и подготовка постмортемов лидируются в основном представителями SRE команд и руководителями, отдельная выделенная incident team встречается редко и в больших компаниях. При этом половина участников отмечает что уделяют недостаточное время для разбора инцидентов;
8. Вне дежурств SRE команды тратят в среднем 50% времени на инженерную работу, 25% времени на операционную работу (Toil) и 15% на прерывания;
9. Большинство компаний используют от 2 до 5 различных инструментов и систем для мониторинга и наблюдаемости. Не только из-за разного функционала и сценариев использования, но часто в следствии дублирования. Количество инструментов увеличивается с ростом компании;
10. Кроме мониторинга внутренних сервисов подчеркивается важность мониторинга внешних сервисов, таких как BGP, CDN, SASE, SaaS, внешние DNS и API;
11. Наиболее часто используемые метрики для измерений: Uptime/Availability, Performance/Response time, Latency и Error rate. Saturation упоминается гораздо реже, а SLOs разделяют на два типа: Uptime SLOs и Performance SLOs.
Что интересного мы отметили в отчете:
1. В небольших компаниях (до 100 инженеров) функция SRE централизована в одной команде, поддерживающей несколько сервисов. С ростом компании происходит разделение на продуктовые и платформенные команды, что приводит к изменению топологий и структуры SRE команды;
2. Основные трудности с которыми сталкиваются SRE команды: планирование бюджета и ресурсов, приоритизация и архитектура. При этом найм, взаимодействие с командами и прозрачность работы отмечают реже;
3. С точки зрения влияния SRE на бизнес (Business Value) отмечают следующие факторы: Операционная эффективность (Operational Efficiencies), Customer Satisfaction и Customer Experience, Repair Times и реже — соблюдение SLA и Velocity;
4. Наиболее сложными аспектами решения инцидентов выделяют диагностику и поиск проблем, эскалацию и координацию между участниками, извлечение уроков и обучение на инцидентах;
5. Основное внимание уделяется решению инцидентов, оказывающим значительное влияние на пользователей, инцидентам высокого уровня (High severity) и тем, которые видны публично;
6. В качестве областей для улучшения процессов надежности выделяют: смену фокуса с исправлений на обучение на инцидентах, установление связей между инцидентами, выполнение action items после разбора инцидентов;
7. Разбор инцидентов, проведение ретроспектив и подготовка постмортемов лидируются в основном представителями SRE команд и руководителями, отдельная выделенная incident team встречается редко и в больших компаниях. При этом половина участников отмечает что уделяют недостаточное время для разбора инцидентов;
8. Вне дежурств SRE команды тратят в среднем 50% времени на инженерную работу, 25% времени на операционную работу (Toil) и 15% на прерывания;
9. Большинство компаний используют от 2 до 5 различных инструментов и систем для мониторинга и наблюдаемости. Не только из-за разного функционала и сценариев использования, но часто в следствии дублирования. Количество инструментов увеличивается с ростом компании;
10. Кроме мониторинга внутренних сервисов подчеркивается важность мониторинга внешних сервисов, таких как BGP, CDN, SASE, SaaS, внешние DNS и API;
11. Наиболее часто используемые метрики для измерений: Uptime/Availability, Performance/Response time, Latency и Error rate. Saturation упоминается гораздо реже, а SLOs разделяют на два типа: Uptime SLOs и Performance SLOs.