تجزیه و تحلیل عملیاتی

1) تجزیه و تحلیل عملیاتی چیست و چرا مورد نیاز است

تجزیه و تحلیل عملیاتی (Ops Analytics) یک سیستم جمع آوری سیگنال از قابلیت مشاهده (معیارها/سیاههها/مسیرها)، ITSM (حوادث/مشکلات/تغییرات)، CI/CD (انتشار/پیکربندی)، ارائه دهندگان (PSP/KYC/CDN/Cloud)، FinOps (هزینه ها) و SLS I کسب و کار (موفقیت پرداخت ها، ثبت نام)، تبدیل به پنجره های تک و داشبورد برای تصمیم گیری.

• کاهش MTTD/MTTR از طریق تشخیص زودهنگام و شناسایی صحیح علل ؛
• نگه داشتن SLO ها و بودجه خطا تحت کنترل ؛
• تغییرات لینک → تاثیر (انتشار/پیکربندی → SLI/SLO/شکایات/هزینه)
• ارائه تجزیه و تحلیل خدمات خود را به تیم ها و مدیریت.

2) منابع و لایه داده کانونی

تله متری: معیارهای (SLI/منابع)، سیاهههای مربوط (نمونه برداری/نسخه PII)، مسیرهای پیاده روی (trace_id/span_id، انتشار برچسب ها).
ماژول های ITSM/حادثه: SEV، زمان بندی T0/Detected/Ack/Declared/Mitigated/Recovered، RCA/CAPA.
CI/CD & Config: نسخه ها، commits، canarics/آبی سبز، وضعیت پرچم، تنظیمات هدف.
ارائه دهندگان: وضعیت/SLA، تاخیر، کدهای خطا، وزن مسیر.
FinOps: هزینه های برچسب ها/حساب ها/مستاجران، $/واحد (1K اپرا.) .
DataOps: طراوت پنجره، خطاهای DQ، اصل و نسب.

اصل کلیدی یک همبستگی واحد از طریق شناسه ها است: 'service'، 'region'، 'tenant'، 'release _ id'، 'change _ id'، 'incident _ id'، 'provider'، 'trace _ id'.

3) مدل داده تک (چارچوب ساده)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO و معیارهای تجاری

Бизнес -SLI: «پرداخت _ موفقیت _ نسبت»، «ثبت نام _ تکمیل»، «سپرده _ تاخیر».
Тех -SLI: 'availability', 'http _ p95', 'error _ rate', 'queue _ depth'.
لایه SLO: اهداف + میزان سوختگی (پنجره کوتاه/بلند)، حاشیه نویسی خودکار نقض.
عادی سازی: شاخص در هر 1k عملیات موفق/کاربران/ترافیک.

5) ارتباط و انتساب علل

انتشار/پیکربندی ↔ SLI/SLO: حاشیه نویسی در نمودار ؛ گزارش علت و معلول (نسبت حوادث تغییر ؛ MTTR حوادث را تغییر می دهد).
ارائه دهندگان SLI ↔ کسب و کار: وزن مسیر در مقابل تاخیر/خطا، سهم هر ارائه دهنده به دست SLO.
ظرفیت/منابع ↔ تاخیر - بیش از حد استخر → p95 رشد → تاثیر تبدیل.

6) ناهنجاری ها و پیش بینی

تشخیص ناهنجاری: فصلی + آستانه صدک + ویژگی های تغییر جستجو (قبل/بعد از انتشار).
پیش بینی: الگوهای بارگیری هفتگی/فصلی، پیش بینی بودجه خطا، پیش بینی هزینه ($/واحد).
Gardrails: هشدار تنها زمانی که منابع حد نصاب (مصنوعی + RUM + SLI کسب و کار).

7) ویترین و داشبورد (مرجع)

1. اجرایی 28d: مخلوط SEV، متوسط MTTR/MTTD، پایبندی SLO، $/واحد، دلایل بالا.
2. SRE Ops: SLI/SLO + نرخ سوختن، طوفان صفحه، قابل اجرا٪، تغییر نرخ شکست.
3. Change Impact: releases/configs ↔ SLI/SLO/commissions, rollbacks and their effect.
4. ارائه دهندگان: خطوط وضعیت PSP/KYC/CDN، تأثیر بر SLI کسب و کار، زمان پاسخ.
5. FinOps: هزینه هر 1k txn، سیاهههای مربوط/خروج، ناهنجاری های هزینه، توصیه ها (نمونه برداری، ذخیره سازی).
6. DataOps: طراوت پنجره، خطاهای DQ، SLA خط لوله، موفقیت backfill.

8) کیفیت داده ها و حکومت

قراردادهای رویداد: طرح های روشن برای حوادث/انتشار/SLI (زمینه های اجباری، مناطق زمانی یکنواخت).
DQ-چکرز: کامل، منحصر به فرد از کلید، ثبات جدول زمانی (t0≤detected≤ack...).
Lineage: داشبورد به منبع (قابل ردیابی).

PII/اسرار: ویرایش/پوشش توسط سیاست ؛ WORM برای شواهد

تازگی SLA: عملیات ویترین ≤ تاخیر 5 دقیقه.

9) معیارهای بلوغ تجزیه و تحلیل عملیاتی

پوشش:٪ از خدمات مهم در فروشگاه ها و تابلوهای SLO (≥ هدف 95٪).
طراوت: سهم ویدجت با طراوت ≤ 5 دقیقه (≥ هدف 95٪).
عملی بودن:٪ انتقال از داشبورد به عمل (playbook/SOP/ticket) ≥ 90٪.
پوشش تشخیص: ≥ 85٪ از حوادث توسط اتوماسیون تشخیص داده می شود.
Attribution Rate: درصد حوادث با علت و محرک تایید شده ≥ 90٪.
سهم تأثیر تغییر: سهم حوادث مربوط به تغییرات (کنترل روند).
کیفیت داده ها: خطاهای DQ/هفته → ↓ QoQ.

10) فرآیند: از داده تا عمل

1. مجموعه → تمیز کردن → عادی سازی مورد صفحه نمایش → (ETL/ELT، لایه ویژگی برای ML).
2. تشخیص ماتریس/پیش بینی → تشدید (IC/P1/P2/Comms).
3. اقدام: playbook/SOP، دروازه انتشار، پرچم ویژگی، سوئیچ ارائه دهنده.
4. شواهد و AAR/RCA: جدول زمانی، نمودار، لینک به انتشار/سیاهههای مربوط/آهنگ.
5. CAPA و راه حل های محصول: اولویت بندی توسط سوختن دقیقه و تاثیر $.

11) نمونه پرس و جو (ایده)

11. 1 تاثیر انتشار در SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 سهم مشکلات از ارائه دهندگان توسط منطقه

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 هزینه در هر 1k پرداخت موفق

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) الگوهای مصنوعی

12. 1 نمودار رویداد حادثه (JSON، قطعه)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 کاتالوگ متریک (YAML، قطعه)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 کارت گزارش اجرایی (بخش ها)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) ابزار و الگوهای معماری

Data Lake + DWH: لایه «خام» برای تله متری، ویترین برای راه حل ها.
جریان پردازش: SLI نزدیک به زمان واقعی/سوزاندن نرخ، ویژگی های آنلاین برای ناهنجاری.
فروشگاه ویژگی: استفاده مجدد از ویژگی های (قناری، فصلی، سیگنال های ارائه دهنده).
لایه معنایی/فروشگاه متریک: تعاریف متریک یکنواخت (SLO، MTTR...).
کنترل دسترسی: RBAC/ABAC، امنیت سطح ردیف برای مستاجران/مناطق.
کاتالوگ/اصل و نسب: جستجو، شرح، وابستگی، صاحبان.

14) چک لیست

14. 1 راه اندازی تجزیه و تحلیل عملیاتی

• واژه نامه های تایید شده SLI/SLO، SEO، دلایل، انواع تغییر.
• نمودارهای رویداد و زمان بندی یکنواخت.
• اتصالات تله متری، ITSM، CI/CD، ارائه دهندگان، صدور صورت حساب.
• نمایشگاه: SLI/SLO، حوادث، تغییرات، ارائه دهندگان، FinOps.
• داشبورد اجرایی/SRE/تغییر/ارائه دهندگان در دسترس هستند.
• هشدار حد نصاب و سرکوب در پنجره های تعمیر و نگهداری پیکربندی.

14. 2 عملیات هفتگی نقد و بررسی

• روند SEV، MTTR/MTTD، SLO نتواند، دقیقه سوختگی.
• تغییر تاثیر و CFR، وضعیت عقبگرد.
• حوادث ارائه دهنده و زمان واکنش.
• FinOps: $/واحد، ناهنجاری های ورود/خروج.
• وضعیت CAPA، بزهکاری، اولویت ها.

15) ضد الگوهای

«دیوار نمودارها» بدون رفتن به عمل.
تعاریف مختلف معیارها برای دستورات (بدون لایه معنایی).
عدم انتشار/حاشیه نویسی پنجره - تخصیص ضعیف علل.
جهت گیری متوسط به جای p95/p99.
هیچ عادی سازی برای حجم وجود ندارد - خدمات بزرگ «به نظر می رسد بدتر است».
PII در سیاهههای مربوط/storefronts، اختلال retension.
داده ها «راکد» (> 5-10 دقیقه برای ویدجت در زمان واقعی).

16) نقشه راه پیاده سازی (4-8 هفته)

1. «ند». 1: موافقت نامه ها در فرهنگ لغت معیارها، طرح های رویداد، شناسه همبستگی ؛ SLI/SLO و اتصال ITSM.
2. «ند». 2: حوادث/تغییرات/ارائه دهندگان ویترین، حاشیه نویسی انتشار ؛ داشبورد اجرایی و SRE.
3. «ند». 3: لایه FinOps ($/واحد)، رباط با SLI ؛ تشخیص ناهنجاری با حد نصاب.
4. «ند». 4: خود سرویس (لایه معنایی/فروشگاه متریک)، کاتالوگ و خط.
5. «ند». 5-6: پیش بینی بار/هزینه، گزارش به ارائه دهندگان، ویترین CAPA.
6. «ند». 7-8: پوشش ≥95٪ Tier-0/1، طراوت SLA ≤5 دقیقه، بررسی عملیات به طور منظم.

17) خط پایین

تجزیه و تحلیل عملیاتی یک ماشین تصمیم گیری است: تعاریف یکنواخت معیارها، فروشگاه های تازه، تخصیص صحیح علل و انتقال مستقیم به playbooks و SOP ها. در چنین سیستمی، تیم به سرعت انحرافات را شناسایی و توضیح می دهد، تأثیر انتشار و ارائه دهندگان را با دقت ارزیابی می کند، هزینه ها را مدیریت می کند و به طور سیستماتیک خطر را کاهش می دهد - و کاربران یک سرویس پایدار دریافت می کنند.