Announcing HAProxy 3.0

https://www.haproxy.com/blog/announcing-haproxy-3-0

#release #haproxy #loadbalancer

Началась infa.conf 24, на главной доступна online трансляция

https://infraevents.yandex.ru/event/infraconf2024

#event #yandex #infra #2024

Меня долгое время занимало почему у btrfs есть конфигурируемый параметр flushonocommit — какие последствия могут быть от его включения/выключения и почему вообще пользователю этот параметр дали конфигурировать — из документации это мне было не очевидно.

Сегодня я нашёл, что его переключение это выбор между возможностью наступления двух маловероятных событий:

1. В значении по умолчанию (noflushoncommit) возможно появление дырок в файлах, если пользовательский процесс что-то писал в файл, когда система или диск вдруг аварийно остановились.

2. При установке flushoncommit, возможна другая ситуация — если у вас есть процесс который записывает данные быстрее, чем они успевают быть перенесены на диск из очереди в памяти, то fsync никогда не завершится, а диск заполнится на 100%. При этом, набор данных, с точки зрения пользовательских программ, может быть и небольшим (просто постоянно обновляемым) — диск же заполнят, созданные в рамках работы CoW, метаданные и копии данных.

https://www.spinics.net/lists/linux-btrfs/msg109823.html
https://github.com/Zygo/bees/issues/68

​gatus

Утилита мониторинга состояния, ориентированная на разработчиков, которая дает вам возможность отслеживать службы с помощью HTTP, ICMP, TCP и DNS-запросов, а также анализировать результат запросов, используя список условий для значений, таких как код и время ответа, срок действия сертификата, тело ответа и многие другие. Каждую из этих проверок работоспособности можно сочетать с оповещениями через Slack, Teams, PagerDuty, Discord, Twilio и другие.

Репыч на гитхабе

CNCF Platforms White Paper - I

Ну и в продолжение поста про Kubecon я решил рассказать про whitepaper от CNCF на тему платформ. Документ состоит из 7 пунктов

1. Why platforms?
Собственно документ начинается со списка преимуществ платформ и того, какие проблемы они решают:
- уменьшают когнитивную нагрузку на продуктовые команды
- улучшают надежность и устойчивость продуктов, развернутых поверх платформ
- ускоряют разработку и доставку продуктов за счет переиспользования платформенных инструментов
- уменьшают риски: безопасности, регуляторные, функциональных багов
- помогают использовать эффективно сервисы и мощности публичных облаков

2. What is a platform
Здесь дается определение платформы в виде коллекции возможностей, что определены и представлены в соотоветствии с потребностями пользователей платформы. Здесь важно, что все эти возможности интегрированы вместе и предоставляют возможность выполнять типичные сценарии пользователей платформы. Критически важно, что не все возможности платформенные команды должны реализовывать сами (их могут предоставлять облачные провайдеры или внутренние команды в организации). Так как эти платформе направлены на внутренних разработчиков, то их называют internal developer platform. Дальше авторы отдельно разбирают уровни зрелости платформ
Platform maturity
- продуктовые разработчики могут получать возможности платформы on-demand и сразу использовать их для запуска своих приложений
- продуктовые разработчики могут получать пространство для сервисов и сразу использовать их для запуска пайплайнов и задач для хранения артефактов, конфигурации и сбора телеметрии
- администраторы стороннего софта могут получать свои зависимости по требованию, например, баззы данных, а дальше использовать их в своих решениях
- продуктовые разработчики могут получать полное окружение с темплейтами вместе с run-time и development-time сервисами для специфичных сценарием (Web, ML, ...)
- продуктовые разработчики и менеджеры могут наблюдать за функциональностью, производительностью и костами развернутых сервисов через стандартные инструменты и дашборды

3. Attributes of successful platforms
В этом пункте авторы рассказывают про свойства платформ, которые
- platform as a product - к созданию платформ надо подходит как к созданию продукта
- user experience - надо ориентироваться на опыт разработчиков (DexEx, про него я недавно разбирал white paper)
- documentation and onboarding - здесь приводится пример того что могут предлагать платформы "the platform could offer a reusable supply chain workflow for building, scanning, testing, deploying, and observing a web application on Kubernetes. Such a workflow could be offered with an initial project template and documentation, a bundle often described as a golden path"
- self-service - возможность самостоятельно использовать сервисы
- reduced cognitive load for users - платформа должна уменьшать нагрузку
- optional and composable - продукты должны иметь возможность использовать нужные части платформ, а нехватающие части закрывать самостоятельно
- secure by default - безопасность должна быть встроена в платформы по умолчанию

4. Attributes of successful platform teams
Платформенные команды отвечают за следующие зоны
- исследование требований пользователей и создание роадмапа фичей
- маркетинг, евангелирование и адвокатство ценностей, которые предлагает платформы
- управление и разработка интерфейсов для использования и изучение возможностей и сервисов, включая портал, API, документацию, шаблоны и CI инструменты
Самое важное в том, что платформенные команды должны изучать потребности платформенных пользователей и дальше информировать и постоянно улучшать возможности и интерфейсы, что предоставляют платформы. Для этого можно использовать стандартные продуктовые инструменты, например, описанные в книге Мартина Кагана "Inspired", про которую я писал раньше.

Продолжение в постах 2 и 3.

#Kubernetes #SRE #DistributedSystems #PlatformEngineering #SoftwareDevelopment #Software #ProductManagement

Инструмент для проведения собесов

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

Главные фишки документа - решить следующие задачи:
1) получить одинаковый результат оценивания кандидатов, при проведении собеседования разными людьми. вопросы унифицированы, разбиты на ключевые точки, которые показывают глубину знаний человека.
2) наличие артифакта, который уменьшает субъективное мнение рекрутёра, ведь при наличии ключевых точек видно что именно кандидат знает про тот или иной вопрос. т.е. можно после собеса посоветоваться с коллегами
3) приведение субъективного мнения к математическому. Документ автоматически рассчитывает баллы и говорит какой уровень у кандидата - жун\мид\сеньёр. Чаще всего математически подсчитанный результат совпадает с моим субъективным мнением.
4) Разные вопросы под разные вакансии. Можно сформировать вопросы под конкретную вакансию в зависимости от необходимостей конкретного отдела. Так, вы можете определить core технологии, без которых существование инженера невозможно в команде. Добавить опциональные знания и знания расширенного кругозора.
5) Добавление баллов на лету. если человек раскрывает вопрос очень круто можно накинуть баллов на каждый вопрос в отдельности (или отнять)

Более подробно - в ридми документа. (Точка входа - где собес проводить - страничка Sheet1 - исторически сложилось, лень переименовывать)

Предполагаемый флоу работы - вы копируете документ-шаблон, именуете его фио кандидата, натыкиваете ответы, получившийся документ прикрепляете с комментарием в хантфлоу или что-то иное.

З.Ы. Вопросы и ключевые точки - моё субъективное мнение. Вы можете писать в доку свои вопросы, если хотите использовать док для себя. Но холиварить о вопросах и ключевых точках я не очень готов. Документ не идеален, некоторые ключевые точки плохо прописаны, я уже это не меняю - в любом случае и вопросы и ключевые точки - помогаторы при оценке человека, а не идеальный "тест"
З.З.Ы. "математика" сделана немного кривовато, т.к. не все можно сделать "чисто" с функционалом гугл таблиц. Если будете что-то менять в своей копии -делайте аккуратно.
З.З.З.Ы - дополнения и улучшения принимаются. лучше через ЛС.

https://docs.google.com/spreadsheets/d/1D2B6Xzse3fYtrTD0RcbNAeK9N7ORPHzhMGTOvaEtbCA/edit?usp=sharing

Логическая репликация в PostgreSQL. Репликационные идентификаторы и популярные ошибки

https://habr.com/ru/companies/postgrespro/articles/489308/

#postgresql #replication

"Advanced Linux Detection and Forensics Cheatsheet" - полезный систематизирующий документ по моментам связанным с обнаружением и расследованием инцидентов в Linux. Вы определенно можете отметить как много всего есть и как много куда надо смотреть в Linux (и от этого даже может заболеть голова). В документе упоминается и ряд моментов связанных с контейнерами и K8s. Но если прям специализироваться и затачиваться под последнее, то на их специфике можно сделать много всего интересного и очень полезного. Об этом мы как раз расскажем и покажем на будущем вебинаре «Ловим злоумышленников и собираем улики в контейнерах Kubernetes».

​Alerts Are Fundamentally Messy

Хорошая подход к гигиене алертинга состоит из нескольких компонентов: контроль за условиями срабатывания оповещения, постмортем и ​​размышления о том, что делает алертинг хорошим или плохим. Задача состоит в доведении алертинга до стадии, когда уведомления улетят, когда они должны отправиться, и не будут разосланы, когда это не требуется. Вообще говоря, это недостижимый идеал.

Реальность такова, что достижение идеала это процесс, а сам идеал недостижим. В этой статье разобран подобный итеративный процесс. Читать статью.

We need to talk: Can we standardize NO_PROXY?

https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/

#linux #env #proxy #no_proxy #curl #gitlab

​Grafana Loki: Оптимизация показателей на основе журналов

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

👉 Фильтр меток
👉 Анализ данных
👉 Разделение запроса
👉 Параллелизм/Параллелизм и Очередь
👉 Индекс
👉 Кэш
👉 Распределение ресурсов

Читать статью
.

​SLO formulas implementation in PromQL step by step

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

Читать статью
.

​OpenTelemetry Collector Anti-Patterns

OpenTelemetry Collector — гибкий и мощный конвейер данных, который позволяет принимать данные OTel из одного или нескольких источников, преобразовывать их и экспортировать в один или несколько бэкэндов для наблюдения для анализа.

К сожалению, как это случается со многими инструментами, очень легко поддаться плохим привычкам.В этой статье разобраны 5 антипаттернов OpenTelemetry Collector и рассказано как их избежать.

👉 Неправильное использование режимов деплоя коллектора
👉 Отсутствие контроля коллекторов
👉 Использование неправильного дистрибутива коллектора
👉 Нерегулярное обновление коллекторов
👉 Использование OpenTelemetry Collector не там, где это уместно

Читать статью
.

Proxmox vs FreeBSD: Which Virtualization Host Performs Better?

Сравнение производительности виртуализации на базе прокса с bhyve

https://it-notes.dragas.net/2024/06/10/proxmox-vs-freebsd-which-virtualization-host-performs-better/

#virtualization #proxmox #freebsd #performance #bhyve #zfs

📧 Neverest CLI - неплохо выглядящая альтернатива imapsync. Оба инструмента используются для синхронизации, переноса и резервного копирования писем в почтовых ящиках...

https://git.sr.ht/~soywod/neverest-cli

#email #mail #imap

😈 Let's Try BSD - неплохая серия статей получается у автора. Берём BSD систему, и разворачиваем на ней Wordpress:

1. Introduction (FreeBSD, OpenBSD, NetBSD, DragonFlyBSD);
2. How I Setup for FreeBSD, OpenBSD, NetBSD, and DragonFlyBSD (тут базово про заказ виртуалки в vultr, можно пропустить);
3. FreeBSD, the Power to Serve;
4. NetBSD, the BSD That Runs on Your Grandfather's Pocket Watch;
5. Setting Up Nginx + WordPress on OpenBSD! Almost!
6. Jump Into the Unknown With Me As I Install DragonFlyBSD!
7. Conclusions About FreeBSD, OpenBSD, NetBSD, and DragonFlyBSD.

#фидбечат #bsd #webserber

🗜 Linux Network Performance Ultimate Guide - очень обстоятельно о работе сети в Linux...

https://ntk148v.github.io/posts/linux-network-performance-ultimate-guide/

#linux #network #performance

Вышел ceph 18.2.4 (reef)

Вышел четвёртый бекпорт релиз в ветке reef.

Ранняя сборка этого релиза была случайно упакована и опубликована как 18.2.3 проектом Debian в апреле. Этот релиз 18.2.3 не должен использоваться, поэтому официальный релиз был переименован в v18.2.4, чтобы избежать дальнейшей путаницы.

Образы контейнеров v18.2.4 основанны на CentOS 9 и могут быть несовместимы с более старыми ядрами (например, Ubuntu 18.04) из-за различий в методах создания потоков. Пользователи, обновляющиеся до контейнеров v18.2.4 на более старых версиях ОС, могут столкнуться со сбоями во время выполнения pthread_create. Для обходных путей обратитесь к связанному трекеру https://tracker.ceph.com/issues/66989. Однако разработчики рекомендуют обновить вашу ОС, чтобы избежать этой неподдерживаемой комбинации.

Разработчики отметили следующие изменеия:

* RBD: При сравнении с началом времени (fromsnapname == NULL) в режиме fast-diff (whole_object == true с включенной и допустимой функцией fast-diff образа), diff-iterate теперь гарантированно выполняется локально, если доступна эксклюзивная блокировка. Это приводит к значительному улучшению производительности для синхронизации live дисков QEMU и резервного копирования.
* RADOS: C++ API get_pool_is_selfmanaged_snaps_mode был объявлен устаревшим из-за возможности ложноотрицательных результатов. Его безопасной заменой является pool_is_in_selfmanaged_snaps_mode.
* RBD: Добавлена опция --image-id для командной строки rbd children, чтобы она могла работать с образами в корзине.

Еще больше подробностей тут:

https://ceph.io/en/news/blog/2024/v18-2-4-reef-released/

#ceph #reef #release #cephexpert