"Data Observability относится к data engineering, и является его неотъемлемой частью, согласно best practices, конечно. У меня давно в закладках лежит статья - SLA vs SLO. В больших компаниях мы часто можем слышать про SLA и SLO, и даже SLI. Очень часто их путают. Поэтому статья помогает понять, что для чего и как использовать. __📌 Зачем вообще всё это нужно? SLA, SLO и SLI — это инструменты управления надёжностью сервисов. Они помогают установить понятные и измеримые ожидания между теми, кто предоставляет сервис (разработчики, команды, компании), и теми, кто его использует (внутренние или внешние клиенты).__ __💡 Основные термины: SLI (Service Level Indicator) — Показатель уровня сервиса: метрика, которая показывает, насколько хорошо работает сервис с точки зрения пользователя (например, доступность, время отклика, процент ошибок). __ __SLO (Service Level Objective) — Целевой уровень сервиса: цель по метрике (например, “доступность 99.9% за 30 дней”). Если сервис ниже цели — это тревожный сигнал, может остановиться деплой, пойдут расследования. __ __SLA (Service Level Agreement) — Юридическое соглашение об уровне сервиса: официальный контракт, в котором закреплены SLO и последствия их невыполнения (штрафы, компенсации). Обычно используется во внешних отношениях с клиентами.__ __🤝 Зачем это нужно: Командам — чтобы знать, когда сервис работает плохо и нести ответственность. Бизнесу — чтобы договариваться с клиентами на чётких условиях. Пользователям — чтобы понимать, на что можно рассчитывать (и требовать компенсацию при сбоях). 🧭 Простая аналогия: SLI — это стрелка на спидометре. SLO — это знак ""не ехать быстрее 100 км/ч"". SLA — это штраф за превышение.__ Практически на всех проектах по инжинирингу данных обсуждается тема мониторинга, но очень редко мы действительно устанавливаем метрики, ведь в большинстве случаев аналитика и хранилище данных это не business critical приложение, и если что-то сломалось, то мы можем починить в течения дня. Хотя было бы неплохо установить SLO для бизнеса, что хранилище данных и отчетность будет доступна 99% в течение рабочего времени. И даже если это не соответствует действительности, мы можем установить начальную точку и двигаться в сторону улучшения. Как правило у нас SLA не будет, да и SLI тоже не обязателен. А есть совсем другой пример, когда компания продает данные американских клиентов (их обезличенные гео данные на млн долларов) в другую компанию, которая находится за пределами США. Эта компания, использует данные для классической аналитики трафика людей в разных городах. Так как компания платит большие деньги они установили SLO и SLA. И в случае сбоев выставляют штрафы. Из недостатков такого проекта для дата инженеров - on-call. SLI (Service Level Indicators) — метрики, которые мы измеряем: `unique_user_count` - Кол-во уникальных пользователей в часовой выгрузке `event_volume_total` - Общее кол-во событий в часовой выгрузке SLO (Service Level Objectives) — цели по этим метрикам `unique_user_count` - > 90% от среднего значения за 4 недели `event_volume_total` - > 90% от среднего значения за 4 недели `data_delivery_lag_minutes` - < 10 минут задержки 99% времени `data_integrity_flag` - 100% данных доставлены без ошибок 98% времени SLA (Service Level Agreement) — договор с клиентом, в котором - Фиксируете SLO (например, 98% своевременных поставок в течение месяца) - Описываете последствия (например, штрафы, перерасчет, SLA-кредит) - Уточняете исключения (форс-мажор, проблемы на стороне клиента) - Описываете процесс эскалации и ответственности Пример SLA-формулировки: __Мы гарантируем доставку данных каждый час в течение 10 минут после окончания часа. Минимально допустимый объем — не менее 90% от среднего за предыдущие 4 недели. Если в течение календарного месяца нарушены более 2 SLA-интервала, предоставляется SLA-кредит 10% от месячного счета.__ Цифры SLA у нас в договоре другие, метрики такие как я указал."