Навыки observability-engineer
📊

observability-engineer

Безопасно

Проектирование систем наблюдаемости для продакшена

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

Поддерживает: Claude Codex Code(CC)
📊 71 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «observability-engineer». Спроектируйте стратегию мониторинга для нашего сервиса оформления заказов, обрабатывающего 100K заказов ежедневно

Ожидаемый результат:

  • Сбор метрик: Разверните Prometheus с правилами записи для пропускной способности заказов, перцентилей задержки (p50, p95, p99) и коэффициентов ошибок по типам
  • Ключевые дашборды: Создайте обзор для руководителей, оперативный реального времени и детализированные виды для устранения неполадок в Grafana
  • Оповещение: Настройте оповещения для p99 задержки > 2с, коэффициента ошибок > 1% и успешности оформления заказов < 99%
  • Трассировка: Внедрите авто-инструментирование OpenTelemetry с выборкой трассировки на уровне 10% и полной трассировкой для ошибок
  • Логирование: Структурированные JSON-логи с ID заказа, ID пользователя и задержкой для корреляции с трассировками

Использование «observability-engineer». Определите SLO для нашего платёжного API с целевой доступностью 99.9%

Ожидаемый результат:

  • Определение SLI: Успешные платёжные запросы / общие платёжные запросы, измеряемые в 5-минутных окнах
  • SLO: 99.9% успешности за 30-дневное скользящее окно = 43.8 минут разрешённого бюджета ошибок
  • Оповещения бюджета ошибок: Оповещения о скорости выгорания на порогах 2x (87.6 мин/день) и 10x (438 мин/день)
  • Отслеживание потребления: Дашборд, показывающий оставшийся бюджет ошибок, дневную скорость выгорания и прогнозируемую дату нарушения

Аудит безопасности

Безопасно
v1 • 2/24/2026

Prompt-only skill with no executable code. Static analysis scanned 0 files (0 lines) and detected 0 security issues. The skill provides observability engineering guidance through text prompts only. No dangerous patterns, no network requests, no file system access, and no external commands detected. Content describes legitimate monitoring, logging, and tracing system design.

0
Просканировано файлов
0
Проанализировано строк
0
находки
1
Всего аудитов
Проблем безопасности не найдено
Проверено: claude

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
31
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Проектирование архитектуры мониторинга микросервисов

Создание комплексной стратегии мониторинга для системы микросервисов с 50+ сервисами, включая сбор метрик, распределённую трассировку и оповещение.

Установка фреймворка SLI/SLO

Определение индикаторов уровня сервиса, целей и бюджетов ошибок для API-сервисов с целевой доступностью 99.9% и мониторингом скорости выгорания.

Внедрение распределённой трассировки

Настройка распределённой трассировки для e-commerce платформы для выявления узких мест задержки и выполнения анализа первопричин across service boundaries.

Попробуйте эти промпты

Базовое проектирование мониторинга 
Спроектируйте стратегию мониторинга для [service type], обрабатывающего [traffic volume] запросов в день. Включите сбор метрик, подход к логированию и рекомендации по оповещению.
Определение SLI/SLO 
Помогите определить SLI и SLO для нашего API [service name] с целевой доступностью [availability target]%. Включите расчёт бюджета ошибок и оповещения о скорости выгорания.
Настройка реагирования на инциденты 
Создайте рабочий процесс реагирования на инциденты типа [incident type], включая маршрутизацию оповещений, процедуры эскалации, рекомендации по runbook и процесс пост-инцидентного анализа.
Оптимизация затрат 
Проанализируйте нашу текущую настройку наблюдаемости и порекомендуйте стратегии оптимизации затрат. В настоящее время мы используем [tools] и генерируем [volume] телеметрических данных ежедневно.

Лучшие практики

  • Начинайте с бизнес-результатов — определите, что означает надёжный сервис для пользователей, прежде чем выбирать метрики
  • Внедряйте прогрессивное инструментирование: сначала метрики для видимости, затем трассировки для отладки, затем логи для детализации
  • Оповещайте о симптомах, а не о причинах — уведомляйте, когда пользователи затронуты, а не когда внутренние компоненты выходят из строя

Избегать

  • Создание оповещений для каждой возможной неудачи — приводит к усталости от оповещений и игнорируемым уведомлениям
  • Мониторинг всего без цели — увеличивает затраты и снижает качество сигнала
  • Установка слишком жёстких SLO — вызывает ненужный стресс и выгорание бюджета

Часто задаваемые вопросы

Какие инструменты поддерживает этот навык?
Навык охватывает основные инструменты наблюдаемости, включая Prometheus, Grafana, Jaeger, Zipkin, ELK Stack, Loki, DataDog, New Relic, CloudWatch, OpenTelemetry, PagerDuty и облачный нативный мониторинг в AWS, Azure и GCP.
Может ли этот навык развёртывать инфраструктуру мониторинга?
Нет. Этот навык предоставляет рекомендации по проектированию, конфигурации и планы внедрения. Фактическое развёртывание требует отдельных инструментов инфраструктуры, таких как Terraform или Kubernetes.
Как мне начать работу с наблюдаемостью?
Начните с определения критических пользовательских путей и того, что означает надёжный сервис. Затем инструментируйте для золотых сигналов: задержка, трафик, ошибки и насыщенность. Добавляйте трассировки и логи постепенно.
В чём разница между мониторингом и наблюдаемостью?
Мониторинг сообщает, когда что-то не так. Наблюдаемость помогает понять, почему. Используйте метрики и дашборды для мониторинга, трассировки для отладки и логи для глубокого исследования.
Как мне уменьшить шум оповещений?
Используйте группировку оповещений, дедупликацию и правила подавления. Оповещайте о симптомах, влияющих на пользователей, а не о сбоях внутренних компонентов. Внедрите runbooks для каждого оповещения для быстрой триажа.
Что такое SLI, SLO и бюджеты ошибок?
SLI измеряют поведение вашего сервиса (например, успешность запросов). SLO — это ваши целевые значения SLI (например, 99.9% успешности). Бюджеты ошибок — это оставшееся разрешённое время простоя. Вместе они обеспечивают принятие решений о надёжности на основе данных.

Сведения для разработчиков

Автор

sickn33

Лицензия

MIT

Репозиторий

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-engineer

Ссылка

main

Структура файлов

📄 SKILL.md