SRE Guild

Приветствую!

Не могу не поделиться ссылкой на отличный курс 5-Day GenAI Challenge, который мне порекомендовал коллега. Много теории и, самое главное, — много практики. Можно быстро получить базовые знания, необходимые для работы с AI. Поймёте, как работает LLM «под капотом» и станете лучше понимать, чего от неё ожидать. Узнаете, что такое векторные базы и RAG. Если весь ваш опыт работы с LLM ограничивался ChatGPT в браузере или Copilot — люто рекомендую. AI инструменты везде, так что можно смело сказать, что это база🗿

Курс расположен на Kaggle. Единственное, что я про него знал — это то, что там обитают ML-специалисты, и сам туда никогда не заходил. А оказалось, это очень удобная платформа, если нужно быстро проверить гипотезу или поиграться с моделями.

У нас тут AI-революция по всем фронтам — пропускать нельзя, я считаю! 🦾

#AI #LLM #полезное

Коллеги привет 👋

На работе подняли эпик по актуализации и оптимизации дашбордов Grafana. Ниже ссылки которые помогли структурировать знания по этой теме:

🔗 Полный гайд по дашбордам Grafana

🔗 Лучшие практики. Разные методы и стратегии построения дашбордов.

🔗 Визуализация данных. Краткий обзор доступных визуализаций в Grafana.

🔗 Каталог шаблонов. Можно найти уже готовый для своего приложения. Либо посмотреть как другие команды это делают.

🔗 Истории успеха. Статьи и видео с конференций про различные кейсы использования Grafana в компаниях.

—
В GrafanaLab есть дашборд с Doom. Зацените. Современное искусство 🤌🏻
—

До связи!

#SRE #grafana #dashboard

Коллеги, привет! 👋

🔍 Проблема традиционного мониторинга БД

Интересный топик вычитал в блоге Grafana. Суть в том что большинство команд следит за производительностью баз данных с помощью внутренних метрик, таких как:
- Время выполнения запросов
 - Количество соединений
 - Загрузка процессора и памяти
 - Количество ошибок

И у нас так же, однако такой подход имеет недостатки. Во-первых, он не отражает самое главное - пользовательский опыт. Внутренние метрики показывают техническое состояние БД, но не всегда коррелируют с тем, как сервис воспринимается конечными пользователями. Во-вторых, не учитывает сетевые задержки. Например, БД может отвечать быстро, но клиент получает данные с задержкой из-за проблем в сети. Ну и плюс к этому накладывается сложность интерпретации. Например, рост времени выполнения запросов может быть вызван как проблемами в самой БД, так и внешними факторами (нагрузка на сеть, изменения в коде приложения).

🚀 Синтетический мониторинг как решение

Синтетический мониторинг помогает устранить эти недостатки. Вместо пассивного сбора внутренних метрик он активно проверяет доступность и производительность БД с точки зрения приложения.

🔹 Как это работает?

Специальный агент имитирует работу реального клиента, выполняя тестовые SQL-запросы (SELECT, INSERT, UPDATE, DELETE). Фиксируются метрики, такие как общая задержка ответа (включая сетевые задержки) и процент успешных запросов. Запросы выполняются из среды, максимально приближенной к реальному окружению приложений, что дает более точные данные. Автор приводит в пример когда БД и приложение находятся в разных кластерах кубера. В таком случае классический подход к мониторингу будет показывать, что всё хорошо даже если сеть сильно деградировала и клиенты базы данных испытывает сильные задержки.

Преимущества синтетического мониторинга:
- Объективная картина доступности БД – измеряются реальные задержки, включая сетевые.
- Раннее обнаружение проблем – можно выявить деградацию еще до того, как пользователи заметят ухудшение.
- Снижение ложных тревог – если БД работает медленно, но клиенты это не ощущают, инцидент можно не эскалировать.
- Подходит для SLO – позволяет определить уровень доступности БД с точки зрения пользователей, что важно при работе с SLO.

Про инструментарий советую почитать в оригинальной статье. Ссылка в начале статьи.

--
В общем, буду пробовать.

Всем хороших выходных!

Основные метрики

Одним из стандартов мониторинга являются так называемые "Four golden signals" от Google — Latency, Traffic, Errors, Saturation.

1️⃣ Задержка (Latency) - Измеряет время, необходимое системе для обработки запроса.

Как измерять:
- Разделяйте задержку на успешные и неуспешные запросы. Быстрые ошибки могут искажать показатели общей латентности.
- Используйте перцентили (например, 95-й или 99-й) для оценки реального пользовательского опыта.
- Фиксируйте время ответа на разных уровнях системы (например, frontend, backend, БД).

2️⃣ Трафик (Traffic) - Отражает объем нагрузки на систему.

Как измерять:
- Для веб-сервисов: HTTP-запросы в секунду.
- Для потоковых сервисов: количество активных соединений или объем переданных данных.
- Для баз данных: число транзакций или запросов в секунду.

3️⃣ Ошибки (Errors) - Показывает долю неудачных запросов от общего числа. Ошибки могут быть явными (HTTP 500) или логическими (например, успешный HTTP 200, но с неправильным контентом).

Как измерять:
- Вычисляется по формуле:
Процент ошибок (%) = (Количество ошибочных запросов / Общее количество запросов) * 100
- Классифицируйте ошибки: HTTP-коды, таймауты, ошибки приложений.
- Настраивайте алерты по критическим метрикам (например, резкое увеличение 5xx).

4️⃣ Загруженность (Saturation) - Отражает степень использования ключевых ресурсов системы (CPU, RAM, диск, сеть). Системы часто начинают деградировать задолго до 100% загрузки.

Как измерять:
- CPU utilization, memory usage, disk I/O.
- Использование перцентилей для анализа предельных состояний.
- Анализ трендов, предсказывающих исчерпание ресурсов (например, "жесткий диск заполнится через 4 часа").

--
📖Более детально тут

До связи!

#sre #метрики

Привет, коллеги! 👋

Прочитал пост про горизонтальное масштабирование в блоге Dash0. Автор делает акцент на том, что выбор правильных метрик критически важен. Как раз в догонку к посту о SLI и SLO.

Вот основные тезисы которые я вынес для себя:

1️⃣ Приоритизируем пользовательский опыт над техническими деталями.
Это основа выбора правильного SLI. Юзерам, по сути, всё равно, когда у нас CPU загружен всего на 30%, если у них latency несколько секунд.

2️⃣ Мы должны хорошо знать специфику наших приложений.
Это позволит выбрать наилучшие метрики и даже доработать приложение для оптимизации процесса масштабирования.

3️⃣ Нет универсального решения.
Каждое приложение уникально. Для кого-то важно CPU, для кого-то память. По наблюдениям автора большинство приложений являются I/O-bound.

4️⃣ Золотое правило автомасштабирования:
Метрики которые вы используете для автоматического масштабирования должны гарантировать, что добавление реплики сделают вашей системе лучше.
Если, например, наша база данных работает на пределе, то добавление новых подов только усугубит ситуацию.


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

Хороших выходных! До связи 📡

#sre #slo #масштабирование

Привет, коллеги! 👋

SRE постоянно стремится к надежности и стабильности наших систем. Но чтобы к чему-то стремиться, нужно понимать, к чему. Иначе мы либо приедем не туда, либо будем ездить по кругу. Стремительно. 🚗💨

Чтобы знать, куда двигаться, есть три ключевые концепции, которые помогут в этом: SLI, SLO и SLA.

🔍 Коротко о каждом

SLI (Service Level Indicator)
Индикатор уровня обслуживания. Это метрика, которая измеряет конкретный аспект производительности вашего сервиса. Проще говоря, это то, что можно посчитать и отследить. Например, процент неудачных запросов или 95-й процентиль времени отклика.

SLO (Service Level Objective)
Цель уровня обслуживания. Это целевое значение для SLI, которое определяет желаемый уровень производительности. Это своего рода планка, к которой мы стремимся. Например, не более 0,1% запросов с ошибкой или 95-й процентиль времени отклика не превышает 100 мс.

SLA (Service Level Agreement)
Соглашение об уровне обслуживания. Это официальный договор между вами (как поставщиком услуги) и вашими пользователями (клиентами). Он определяет гарантированный уровень сервиса и последствия его нарушения. Внутри компании SLA редко применяется — это больше про работу с внешними клиентами.

🤏 Если совсем коротко:
SLI: Измеряем производительность и доступность.
SLO: Ставим цели для выбранных метрик.
SLA: Договариваемся об обязательствах.

🔄 Связь между ними

SLI играет ключевую роль в определении SLO и, в конечном счете, SLA. SLI предоставляет данные для оценки текущего уровня обслуживания, на основе которых устанавливаются SLO. SLO, в свою очередь, является основной частью SLA, определяя ожидаемый уровень обслуживания, к которому стремится поставщик услуг.

На первый взгляд может показаться, что это просто цифры и графики в Grafana, которые никому не нужны. Но это заблуждение. Приведу цитату из статьи Google:

У каждого сервиса должен быть уровень доступности — без него ваша команда и заинтересованные стороны не смогут принимать принципиальные решения о том, нужно ли сделать ваш сервис более надежным (увеличивая стоимость и замедляя разработку) или менее надежным (обеспечивая большую скорость разработки). Избыточная доступность может стать проблемой, потому что теперь это ожидание. Не делайте свою систему чрезмерно надежной, если вы не намерены делать ее настолько надежной.
Без SLO невозможно принимать обоснованные решения о балансе между надежностью, стоимостью и скоростью разработки. Кроме того, работа над надежностью становится хаотичной и неэффективной.

📖 Что ещё почитать по теме:
- https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos
- https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli

До связи!

P.S. Добавил комменты. Давайте общаться и делиться мыслями 💬

#sre #sla #slo #sli #надежность

Коллеги, привет👋

Наткнулся на небольшую статью с заголовком «Ваша идеальная архитектура возможна не такая уж идеальная».

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

Автор подчёркивает, что чрезмерное стремление к созданию универсальной и масштабируемой системы может привести к излишней сложности и негибкости.

Он пришел к следующем выводам:

1️⃣ Старайтесь сделать просто

Начните с самой простой архитектуры, которая способна удовлетворить ваши текущие потребности. Сложность должна быть заслуженной, а не предположенной. Если ваша архитектурная диаграмма напоминает тарелку спагетти, в которую ударила молния, возможно, вы делаете что-то не так.

2️⃣ Изменения должны быть дешевыми

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

3️⃣ Учитесь действуя

Вместо попыток предсказать будущее создавайте механизмы, которые помогут вам быстро изучать реальные потребности. Это включает фиче-флаги, A/B-тестирование и надёжный мониторинг использования вашей системы. Работайте с реальными данными, а не с тем, что настаивает один громкий человек на этапе планирования.

—

Автор, конечно, никому Америку не открыл, но читая статью мой мозг сразу же начал проводить аналогию с заезженными до дыр практиками разработки. Первый пункт - KISS, YAGNI. Второй - это про CI/CD и DRY. Третий - это в целом про итеративную разработку и Agile.

Вывод: База - наше всё 🗿

🔗 Ссылка на статью https://www.pulumi.com/blog/your-perfect-infrastructure/

P.S. Раз уж про наваливание базы начал. Пишу пост про SLI, SLO и SLA. Скоро будет!

#SRE #архитектура

Привет, коллеги! 👋

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

🔑 7 Ключевых практик SRE:

1️⃣ SLI, SLO и Error Budgets:
Определение метрик успеха (SLI), установка целей (SLO), и выделение "бюджета ошибок" для экспериментов позволяют нам четко понимать, что мы хотим достичь и как измерить успех. Например, это может быть 99.9% доступности, среднее время ответа API менее 200мс и 1 час допустимых
"ошибок" в месяц.

2️⃣ Автоматизация:
Автоматизация рутинных задач, таких как развертывание, тестирование, мониторинг и масштабирование, значительно ускоряет процессы, снижает вероятность ошибок и освобождает время инженеров.

3️⃣ Мониторинг и алерты:
Сбор метрик, построение дашбордов и настройка алертов необходимы для того, чтобы вовремя замечать проблемы и оперативно на них реагировать.

4️⃣ Проактивный подход к инцидентам:
Вместо того чтобы только реагировать на инциденты, нужно их предвидеть и предотвращать. Этого можно достичь, например, с помощью Chaos Engineering, регулярных тренировок по реагированию и детального анализа прошлых инцидентов (post-mortem).

5️⃣ Культура Blameless Post-mortems:
Фокус на анализе причин инцидентов, а не на поиске виноватых, помогает команде учиться на ошибках и не бояться их. Детальные разборы после инцидентов и выявление root causes для их устранения – важная часть этого процесса.

6️⃣ DevOps:
Предоставление разработчикам инструментов для самостоятельного развертывания и мониторинга ускоряет
циклы разработки и уменьшает зависимость от SRE команды. Self-service порталы для развертывания приложений и понятные гайды для разработчиков тут будут кстати.

7️⃣ Управление техническим долгом:
Регулярное выявление и устранение устаревших технологий и архитектурных недочетов предотвращает накопление проблем, которые могут привести к инцидентам. Сюда входит ревью архитектуры и выделение времени на рефакторинг.

В следущих постах я детально разберу каждый из пунктов.

📖 Что ещё почитать по теме:
- https://sre.google/sre-book/service-best-practices/
- https://sre.google/sre-book/part-III-practices/

#sre #devops #автоматизация #мониторинг #инциденты

SRE vs. DevOps: В чем разница? 🤔

Привет, коллеги! Сегодня поговорим о том, чем же SRE отличается от DevOps?

Когда я только начинал разбираться в теме это был один из первых вопросов который я «загуглил». Иногда трудно понять где заканчивается одно и начинается другое. Давайте разберемся!

🔗 Связь SRE и DevOps:

Начнем с того, что SRE – это не замена DevOps, а скорее конкретная реализация принципов DevOps. DevOps — это философия, набор практик, направленных на улучшение взаимодействия между разработкой и эксплуатацией. SRE же предлагает практический подход к достижению этих целей.

🔑 Ключевые различия:

* DevOps: Это образ мышления, ориентированный на культуру сотрудничества, автоматизацию и непрерывную поставку ПО. DevOps говорит нам "что нужно делать".
* SRE: Это конкретный подход, описывающий как именно достичь целей DevOps, с фокусом на надежность и масштабируемость систем. SRE отвечает на вопрос "как это реализовать на практике".

Тут я пишу про DevOps в его изначальном понимании. Истинный смысл DevOps сегодня часто теряется, когда вместо интеграции между разработкой и эксплуатацией создается отдельная команда "DevOps", которая по-прежнему функционирует как изолированная единица. Имеем что имеем. 🤷🏻‍♂️

🤝 Роль SRE в DevOps-команде:

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

🎯 Подходы к работе:

- DevOps-инженер: 
Работает над ускорением процессов, оптимизирует путь от разработки до продакшена.

- SRE-инженер: 
Обеспечивает стабильность и надежность системы, применяя инженерные принципы и автоматизацию.

В то время как DevOps-инженер стремится к скорости поставки, SRE-инженер обеспечивает надежную работу системы. Они работают вместе, чтобы достичь общей цели: быстро и качественно выпускать надежное ПО.

🚀 Пример: Как SRE обеспечивает надежность в рамках DevOps-процесса:

Представьте DevOps-команду, которая разрабатывает новое приложение. SRE в этой команде:

1. Определяет SLO/SLI: устанавливает цели по доступности и производительности.
2. Автоматизирует мониторинг: внедряет системы для отслеживания этих показателей.
3. Автоматизирует реагирование на инциденты: создает плейбуки для автоматического восстановления сервиса в случае сбоя.
4. Анализирует данные: использует метрики для выявления узких мест и оптимизации системы.

Таким образом, SRE помогает команде DevOps не просто быстро разрабатывать и развертывать ПО, но и гарантировать его надежную работу в долгосрочной перспективе.

В заключение:

SRE и DevOps — это не конкуренты, а скорее две стороны одной медали. DevOps задает направление, а SRE дает конкретные инструменты и методы для достижения успеха.

Что почитать:
Статья от Atlassian и от IBM на тему.

До связи!

#SRE #DevOps #база

Привет, друзья! 👋

Давайте поговорим о Site Reliability Engineering. Разберемся, что это такое и почему это важно для современной IT-сферы.

Что такое SRE?

Для начала, посмотрим на определения. Google является одним из пионеров в этой области. Определение которое я нашел на их сайте гласит:

SRE is what you get when you treat operations as if it’s a software problem.

Это лаконично, но требует пояснения. Посмотрим на определение от Amazon:

Инжиниринг надежности сайта (SRE) — это практика использования программных инструментов для автоматизации задач ИТ-инфраструктуры, таких как управление системой и мониторинг приложений. Организации используют SRE, чтобы обеспечить надежность своих программных приложений в условиях частых обновлений от команд разработчиков. SRE особенно повышает надежность масштабируемых программных систем, поскольку управление большой системой с помощью программного обеспечения более устойчиво, чем ручное управление сотнями машин.

Если Google говорит о SRE как о программном решении для операций, то Amazon подчеркивает его роль в автоматизации и управлении инфраструктурой. По сути, SRE — это не про "тушение пожаров", а про их предотвращение. Вместо того, чтобы просто реагировать на проблемы, SRE стремится к проактивной работе, а именно:
- Автоматизации процессов
- Мониторингу состояния системы
- Анализу данных и метрик
- Планированию и предотвращению проблем
- Постоянному улучшению процессов

Зачем нужен SRE?

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

SRE помогает решать множество проблем, повышая надежность и стабильность систем. Вот некоторые сферы которые SRE инженеры помогают улучшить:
- Повышение надежности и времени безотказной работы
- Предсказуемая производительность
- Улучшение масштабируемости
- Улучшение удовлетворенности пользователей за счет более стабильной работы сервисов
- Непрерывное совершенствование системы
- Экономия средств

Все эти преимущества – это результат применения принципов разработки к операциям. Именно поэтому Google говорит, что "SRE это когда вы относитесь к операциям как к программной проблеме".

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

Так SRE это роль или методология?
Это дискуссионный вопрос. Наверно я бы ответил на него так. SRE является и тем, и другим. Можно ли обойтись без отдельного SRE инженера? Да, и тогда его обязанности будут выполнять другие команды.

Представьте себе диспетчера аэропорта. Их работа – это не только реагировать на происшествия, но и предотвращать их, анализировать риски и постоянно совершенствовать свои навыки. Самолеты, конечно, могут летать и без диспетчеров, но тогда пилоты должны будут постоянно следить за всем. В результате, вероятность сбоев и нештатных ситуаций значительно возрастает, а работа становится неэффективной и хаотичной. SRE работает по схожему принципу:
- Наблюдает за "здоровьем" системы
- Устраняет узкие места в системе
- Предотвращает "аварии"

В будущих постах я подробно разберу ключевые принципы SRE, основные термины и с чего начать свой путь в этой области.

До связи!

#SRE #база

Channel created