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.
Forwarded from Записки админа
Linux_Open_Source_Annual-Vol10_2025.pdf
134.6 MB
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 about:performance
На Hacker News происходит множество обсуждений разной степени интересности и иногда попадаются настоящие самородки, где умные дядьки делятся с общественностью своими знаниями.
Одно из таких - Ask HN: How can I learn about performance optimization?
Народ из разных сфер разработки — обработки видео, геймдева, HFT и классической продуктовой — делится опытом и помогает выработать правильный майндсет: о чем думать и куда смотреть, когда речь заходит о производительности.
Отдельно стоит выделить совет:
Проще некуда, да? 🙂
Интересно, что в книге Systems Performance: Enterprise and the Cloud Брэндан Грегг, формулируя свои "мантры о производительности", начинает именно с этого принципа:
Одно из таких - Ask HN: How can I learn about performance optimization?
Народ из разных сфер разработки — обработки видео, геймдева, HFT и классической продуктовой — делится опытом и помогает выработать правильный майндсет: о чем думать и куда смотреть, когда речь заходит о производительности.
Отдельно стоит выделить совет:
cамый простой способ ускорить работу — делать меньше работы или не делать вовсе
Проще некуда, да? 🙂
Интересно, что в книге Systems Performance: Enterprise and the Cloud Брэндан Грегг, формулируя свои "мантры о производительности", начинает именно с этого принципа:
1. Don’t do it.
2. Do it, but don’t do it again.
3. Do it less.
4. Do it later.
5. Do it when they’re not looking.
6. Do it concurrently.
7. Do it more cheaply
Amazon
Systems Performance: Enterprise and the Cloud (Addison-Wesley Professional Computing Series)
covers concepts, strategy, tools, and tuning for operating systems and applications, using Linux-based operating systems as the primary example. A deep understanding of these tools and techniques is critical for developers today. Implementing the strategies…
Forwarded from Код и Капуста
Forwarded from Yet another senior pomidor (by @gmelikov)
А задумывались ли вы над тем, ĸаĸ появились ĸаталоги . и .. ?
Интересный и краткий экскурс в историю https://habr.com/ru/companies/vk/articles/879456/
Интересный и краткий экскурс в историю https://habr.com/ru/companies/vk/articles/879456/
Хабр
Каталог каталогов
Каĸ часто Вы просматриваете содержимое ĸаталога в Linux, BSD*, MacOS? Возможно ĸаждый день, или даже час. А задумывались ли вы над тем, ĸаĸ появились ĸаталоги . и .. ? Каĸово происхождение их...
👍1
Forwarded from Yet another senior pomidor (by @gmelikov)
Недавно разразился скандал про продажу б/у HDD под видом новых от официального реселлера Seagate https://www.tomshardware.com/pc-components/hdds/seagates-fraudulent-hard-drives-scandal-deepens-as-clues-point-at-chinese-chia-mining-farms
С одной стороны, покупая новое мы, естественно, хотим получать что-то с завода без следов эксплуатации.
А, с другой, HDD в первый год работы имеют повышенный риск смерти, и при покупке HDD с пробегом 5-15 тысяч часов, вы не только можете сэкономить, но и уменьшить процент отказов! Backblaze уже делился статистикой на этот счёт https://www.backblaze.com/blog/how-long-do-disk-drives-last/
Да, гарантия должна покрывать как раз первый год-два жизни диска, но повод на подумать всё равно есть. Да будет битва "гарантия" VS "за цену нового купим 2 б/у"!
С одной стороны, покупая новое мы, естественно, хотим получать что-то с завода без следов эксплуатации.
А, с другой, HDD в первый год работы имеют повышенный риск смерти, и при покупке HDD с пробегом 5-15 тысяч часов, вы не только можете сэкономить, но и уменьшить процент отказов! Backblaze уже делился статистикой на этот счёт https://www.backblaze.com/blog/how-long-do-disk-drives-last/
Да, гарантия должна покрывать как раз первый год-два жизни диска, но повод на подумать всё равно есть. Да будет битва "гарантия" VS "за цену нового купим 2 б/у"!
👍1🤔1😱1
Forwarded from k8s (in)security (r0binak)
Kubernetes Netowrk Policies Done the Right Way by Isovalent.pdf
7.9 MB
Инженеры из
Из этой книги вы узнаете:
- Что такое
- Про разные подходы к использованию сетевых политик, управление ими, и их конфигурацию
- Про принятие принципа
Экземпляр книги прикладываем во вложении к посту.
Cilium опубликовали книгу Kubernetes Network Policies Done the Right Way.Из этой книги вы узнаете:
- Что такое
NetworkPolicy, какова их роль в обеспечении безопасности workloads, и как преодолеть проблемы с их внедрением- Про разные подходы к использованию сетевых политик, управление ими, и их конфигурацию
- Про принятие принципа
Zero Trust, использование Hubble для повышение observabilityЭкземпляр книги прикладываем во вложении к посту.
Forwarded from /usr/bin
TCP Congestion Control in Action
https://www.alebedev.tech/posts/cwnd-retransmit/
#network #perf #iperf
Выводы
1. потери пакетов для распределенных сетевых взаимодействий это ОК, вопрос в их объеме;
2. даже незначительное кол-во дропов (~1%) способно замедлить скорость взаимодействия в несколько раз, при потерях в 10% в сотни раз;
3. после определенного % дропов пакетов скорость настолько замедляется, что число ретрансмитов идет вниз, что чревато ложными интерпретациями;
4. без понимания как чувствует себя Контроль Перегрузки невозможно понять почему скорость в моменте падает/растет. Отслеживания только лишь пропускной способности и ретрансмитов недостаточно.
https://www.alebedev.tech/posts/cwnd-retransmit/
#network #perf #iperf
👍1🤔1
Forwarded from Azalio_tech (Mikhail [azalio] Petrov)
Kubernetes Network Policies Done the Right Way by Isovalent.pdf
7.9 MB
Прочитал новую книжку от #cilium про то как надо делать сетевые политики в #kubernetes.
Сначала дают теорию, рассказывают как с 0 организовать сетевые политики, дают пошаговое руководство, потом переходят к практике, но практике сильно урезанной.
Захватывают все свои фишки типа:
- свое переосмысление на чем надо основываться при выборе эндпоинтов (identities)
- избирательный defaultDeny
- hubble UI и cli
- генерацию политик в редакторе
- L3/L4, L7 политики
В целом если вы давно в этой теме - вам эта книжка ничего не даст, если же вы не работали или работали эпизодически с сетевыми политиками (особенно с сетевыми политиками cilium), то рекомендую эту книжку - отличный старт.
Сначала дают теорию, рассказывают как с 0 организовать сетевые политики, дают пошаговое руководство, потом переходят к практике, но практике сильно урезанной.
Захватывают все свои фишки типа:
- свое переосмысление на чем надо основываться при выборе эндпоинтов (identities)
- избирательный defaultDeny
- hubble UI и cli
- генерацию политик в редакторе
- L3/L4, L7 политики
В целом если вы давно в этой теме - вам эта книжка ничего не даст, если же вы не работали или работали эпизодически с сетевыми политиками (особенно с сетевыми политиками cilium), то рекомендую эту книжку - отличный старт.
Forwarded from /usr/bin
Как NGINX обрабатывает TCP/UDP
В этой статье рассмотрено, как NGINX обрабатывает TCP/UDP‑соединения: от принятия запроса до логирования.
В этой статье рассмотрено, как NGINX обрабатывает TCP/UDP‑соединения: от принятия запроса до логирования.
Forwarded from Timur Tukaev
🎉🎉🎉 Платформа Cozystack стала проектом CNCF Sandbox
28 февраля члены Technical Oversight Committee CNCF завершили голосование и единогласно приняли Cozystack в CNCF Sandbox, сейчас платформа для построения приватных облаков и PaaS проходит процесс онбординга.
Что это значит для пользователей
Передача проекта в CNCF дает гарантии всем пользователям Cozystack, что платформа всегда будет доступна под лицензией Apache 2.0 и ее не постигнет участь таких проектов, как Mongo, Redis, Terraform, Vault, лицензии которых в какой-то момент времени были изменены на закрытые и не соответствующие критериям организации Open Source Initiative. С этого момента права на Cozystack принадлежат отраслевой некоммерческой организации, то есть CNCF.
Кроме того, включение проекта в CNCF дает возможность привлечь к разработке и использованию Cozystack широкое инженерное сообщество, сделать управление проектом более прозрачным. Расширение базы контрибьюторов и пользователей в свою очередь значительно ускорит разработку платформы и проработку максимального количества сценариев использования.
Андрей Квапил, CEO Ænix и создатель Cozystack:
Ænix будет всё так же активно разрабатывать платформу и поддерживать как клиентов, так и пользователей из комьюнити.
Полезные ссылки
- Сайт Cozystack
- GitHub
- Telegram community
- Slack community (необходимо зарегистрироваться в Slack-пространстве Kubernetes)
- Community Meeting Calendar
- Cozystack Community Meetings Recordings
- Cozystack on CNCF Landscape
- Cozystack in CNCF Sandbox
- Cozystack on Devstat
28 февраля члены Technical Oversight Committee CNCF завершили голосование и единогласно приняли Cozystack в CNCF Sandbox, сейчас платформа для построения приватных облаков и PaaS проходит процесс онбординга.
Что это значит для пользователей
Передача проекта в CNCF дает гарантии всем пользователям Cozystack, что платформа всегда будет доступна под лицензией Apache 2.0 и ее не постигнет участь таких проектов, как Mongo, Redis, Terraform, Vault, лицензии которых в какой-то момент времени были изменены на закрытые и не соответствующие критериям организации Open Source Initiative. С этого момента права на Cozystack принадлежат отраслевой некоммерческой организации, то есть CNCF.
Кроме того, включение проекта в CNCF дает возможность привлечь к разработке и использованию Cozystack широкое инженерное сообщество, сделать управление проектом более прозрачным. Расширение базы контрибьюторов и пользователей в свою очередь значительно ускорит разработку платформы и проработку максимального количества сценариев использования.
Андрей Квапил, CEO Ænix и создатель Cozystack:
Я верю в честный и настоящий Open Source, в те инструменты, которые мы используем для построения платформы, и я счастлив, что мы можем быть полезны сообществу. Всего за год мы небольшой командой отличных инженеров при поддержке наших клиентов и open source-сообщества смогли сделать проект, достойный включения в CNCF.
Это действительно большое достижение. Спасибо всем, кто верил в нас и помогал всё это время. Мы продолжим совершенствовать платформу и планируем осенью подать заявку на включение проекта в CNCF Incubating. С инженерной точки зрения мы уже довольно зрелый проект и готовы к этому, сейчас главная задача — усовершенствовать процесс управления проектом и взаимодействие с комьюнити.
Ænix будет всё так же активно разрабатывать платформу и поддерживать как клиентов, так и пользователей из комьюнити.
Полезные ссылки
- Сайт Cozystack
- GitHub
- Telegram community
- Slack community (необходимо зарегистрироваться в Slack-пространстве Kubernetes)
- Community Meeting Calendar
- Cozystack Community Meetings Recordings
- Cozystack on CNCF Landscape
- Cozystack in CNCF Sandbox
- Cozystack on Devstat
Forwarded from /usr/bin
Семь фаз вакуумирования в PostgreSQL
В статье описан алгоритм вакуумирования PostgreSQL и приводится сравнение числа сканирований индексов в 17 версии PostgreSQL и предыдущих версиях.
Есть пять фаз вакуумирования каждой таблицы, mwiew, toast и индексов на них: SCAN_HEAP, VACUUM_INDEX, VACUUM_HEAP, INDEX_CLEANUP, VACUUM TRUNCATE. Помимо них есть подготовительная фаза инициализации и завершающая фаза. Читать дальше.
В статье описан алгоритм вакуумирования PostgreSQL и приводится сравнение числа сканирований индексов в 17 версии PostgreSQL и предыдущих версиях.
Есть пять фаз вакуумирования каждой таблицы, mwiew, toast и индексов на них: SCAN_HEAP, VACUUM_INDEX, VACUUM_HEAP, INDEX_CLEANUP, VACUUM TRUNCATE. Помимо них есть подготовительная фаза инициализации и завершающая фаза. Читать дальше.
Forwarded from about:performance
CPU Isolation: исследование в шести частях о применение техник CPU Isolation для задержкочувствительных нагрузок.
Недостаточно просто выгнать все процессы, кроме целевого, с ядра с помощью cpuset и привязать его к CPU через taskset. Надо не забыть и о фоновых задачах ядра, т.н. housekeeping work.
Оборотной стороной housekeeping work является то, что она привносит непредсказуемые задержки (jitter), прерывая выполнение пользовательских задач.
Борьба с этими задержками и есть центральная тема цикла.
Недостаточно просто выгнать все процессы, кроме целевого, с ядра с помощью cpuset и привязать его к CPU через taskset. Надо не забыть и о фоновых задачах ядра, т.н. housekeeping work.
Housekeeping work – это совокупность фоновых операций, которые ядро Linux выполняет для поддержания своей внутренней инфраструктуры. Эти задачи включают обработку таймеров, обновление системного времени, управление очередями отложенной работы (workqueues), обработку прерываний, очистку ресурсов и прочее. Несмотря на то, что они обычно незаметны для пользователя, именно эти операции обеспечивают стабильность и корректное функционирование всей системы.
Оборотной стороной housekeeping work является то, что она привносит непредсказуемые задержки (jitter), прерывая выполнение пользовательских задач.
Борьба с этими задержками и есть центральная тема цикла.
Suse
CPU Isolation – Introduction – by SUSE Labs (p...
This blog post is the first in a technical series by SUSE Labs team exploring Kernel CPU Isolation along with one of its c...