Uptime отчеттор жана аудит SLA

1) Эмне үчүн расмий uptime-отчеттуулук жараяны керек

Кардарлардын ишеними жана контракттык ачык-айкындуулук - өлчөөнүн бирдиктүү ыкмасы, кайталануучу эсептөөлөр.
SLO жана бюджетти башкаруу каталар - релиздер жана окуялар менен жеткиликтүүлүк фактысынын байланышы.
Туура SLA кредиттер - объективдүү формулалар, болжолдуу төлөмдөр/эсептер.
Юридикалык туруктуулук - далилдер базасы, көз карандысыз аудит, Legal Hold.

2) Терминдер жана чек

SLI Availability - мезгил ичинде ийгиликтүү текшерүү/бүтүмдөрдүн үлүшү.
SLO - ички максаты (мисалы, 99. 28 күндүн ичинде 95%).
SLA - тышкы милдеттенме (мисалы, 99. 9 %/ай + тейлөө кредиттери).
Өлчөө терезеси - календардык ай (SLA) жана роллинг терезелери (SLO).
Scope - кайсы компоненттер эсептөөгө кирет (edge, API, төлөмдөр), ал эми кайсынысы жок (админ-портал, non-prod).

3) Чындык булактары (жана качан башкы)

1. Синтетика (blackbox/headless) - "колдонуучунун көзү менен жеткиликтүүлүк" үчүн негизги SLI.
2. Логи/метриктер - баш тартуунун масштабын жана мүнөзүн тастыктайт.
3. Бизнес-окуялар - "операциянын ийгилиги" (мисалы, төлөм авторизацияланган).
4. Статус-бет - коомдук байланыш; № 1-3 фактылар менен салыштырылат.

айырмачылыктар менен: ≥ 2 региондордо туура quorum менен синтетикалык артыкчылык.

4) Жеткиликтүүлүктү эсептөө ыкмасы

4. 1 Негизги формула

Availability = Успешные проверки / Все проверки
ErrorBudget = 1 − SLO
Downtime(m) = (1 − Availability) × Длительность_периода(в мин)

4. 2 Көп региондук quorum

Эгерде көз карандысыз аймактардын/ASN ≥ бир эле учурда баш тартууну каттаса, окуя эсепке алынат.
Сунушталган: N = 2 3 (EU/NA/APAC).

4. 3 түрлөрү SLI

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
Бизнес SLI: ийгиликтүү бүтүмдөр/бардык аракеттер (кардарлардын баш кошпогондо).

4. 4 өзгөчөлүктөр (documented)

Пландаштырылган maintenance терезелер алдын ала жарыяланган N саат жана сакталган.
SLAдан Force majeure (мисалы, IX-кырсык провайдери) - далилдер жана ачык билдирүү болгондо гана.
Кардар каталар/чектөөлөр (quota exceeded, 4xx).

5) maintenance терезелер саясаты

Келишимде макулдашылган убактылуу слоттор (мисалы, UTC + 0 боюнча саат 02: 00-04: 00).
'maintenance = true' маркерлери alerts/панелдер → SLI чыгаруу.
Билдирүүнүн босогосу: кеминде 5 жумушчу күн (же келишимдегидей).
терезеден тышкары - SLA таасири болуп эсептелет.

6) Edge учурларда жана тегеректөө эрежелери

Brownout (жарым-жартылай начарлашы): "0/1" эмес, баш тартуулардын үлүшүн (weighted downtime) эсептөө.
Flapping: минималдуу эсептөө бирдиги - сыноо аралыгы (мисалы, 30-60 сек) + hysteresis (for: 2-5 мин).
Clock drift: UTC жана ISO-8601 бардык жолу; NTP синхрондоштуруу.

7) PromQL мисалдар (синтетика → аптайм)

promql probe_success{job="blackbox-http"} == 1

promql histogram_quantile(0.95, sum by (le, target) (rate(probe_http_duration_seconds_bucket[5m])))

promql sum_over_time((probe_success==1)[30d]) / (30246060)

promql sum by (target) (max_over_time((probe_success==0)[3m])) >= 2

8) SQL мисалдар (отчет топтоо)

sql with checks as (
select target, ts, success -- success: 1/0 from synthetic_checks where ts >=:from and ts <:to
),
agg as (
select date_trunc('month', ts) m, target,
sum(success)::float / count() as availability from checks group by 1,2
)
select m, target, availability,
(1-availability) extract(epoch from (date_trunc('month', m) + interval '1 month' - date_trunc('month', m))) / 60 as downtime_minutes from agg;

sql select a.m, a.target, a.downtime_minutes, s.incident_id, s.start_utc, s.end_utc from monthly_downtime a left join statuspage_incidents s on a.m = date_trunc('month', s.start_utc)
and tstzrange(s.start_utc, s.end_utc) && daterange(a.m, a.m + interval '1 month');

9) Айлык отчет үлгүсү (Customer-friendly)

yaml period: "2025-10-01..2025-10-31 (UTC)"
services:
- name: "API Edge"
sla: "99.90%"
measured_availability: "99.93%"
downtime:
total: "30m 14s"
windows:
- start: "2025-10-12T03:12Z"
end:  "2025-10-12T03:38Z"
impact: "EU+NA, HTTP 5xx spike, p95>2s"
root_cause: "DB connection pool exhaustion"
rca_link: "INC-20251012-0312"
slo_budget:
period_target: "0.10%"
consumed: "0.07%"
- name: "Payments API"
sla: "99.95%"
measured_availability: "99.97%"
summary:
sla_breaches: 0 service_credits: 0 maintenance:
announced: 2 total_duration: "48m"
signatures:
generated_at: "2025-11-01T10:00Z"
report_id: "SLA-2025-10-API"

10) SLA кредиттер: эсептөө жана колдонуу

Кредиттердин жадыбалы: мисалы, 99. 0–99. 5% → 5% MRR; 98. 0–99. 0% → 10% ж.б.
True-up: кредит кийинки эсепке кредит note катары колдонулат.
Автоматташтыруу: эреже "эгер 'measured _ availability <SLA' → 'credit _ note. create()`».
Кардар үчүн витрина: "SLA credits balance" порталдык картасы.

11) Аудит, далилдер жана юридикалык Hold

Аудит-трек: ким/эмне/качан эсептелген, ыкма нускасы, контролдук суммалар.
Raw-маалыматтар өзгөрүлбөйт (append-only); түзөтүүлөр - өзүнчө жазуулар менен.
Legal Hold: маалымат диапазонун тоңдуруу (үлгүлөр, логи, окуя-карталар, алерта).
Архив репликасы: көз карандысыз сактоо (WORM/S3 Object Lock).

12) Коомдук статус-бет менен салыштыруу

Статус-беттеги окуя таймлайн жана компоненттерге ээ болууга милдеттүү.
Убакыт/масштаб дал келбегендиги → discrepancy-record түзүлгөн жана RCA тарабынан жүзөгө ашырылат.
Отчеттун жыйынтыгы "Reconciliation Notes" бөлүмүн камтыйт.

13) Инциденттер жана отчеттуулук

Ар бир даунтаймдын терезеси INC картасына (ID, SEV, ээси, RCA, CAPA) туура келет.
Докладда: INCке шилтеме, кыскача root cause, CAPA статусу.
Үчүн SEV-1: темаларды Postmore ≤ жабылгандан 48 саат.

14) Маалымат сапатын көзөмөлдөө

Үлгүлөрдүн гигиенасы:> 99% ийгиликтүү тырмоо агенттери, өткөрмөлөрдүн жоктугу> 5 мүнөт.
Анти-ызы: quorum + көп терезе, debounce.
Жолдорду/логдорду самплирлөө катталат жана документтештирилет.
Методологиянын тесттери: эсептөөлөрдүн бирдиктик тесттери, тарыхый маалыматтар боюнча алтын файлдар.

15) Коопсуздук жана купуялык

TLS/mTLS ingest, кол топтомдору (HMAC).
Логдордогу/отчеттордогу PII-редакция; SLA-отчет жеке маалыматтарды ачыкка чыгарбашы керек.
RBAC/ABAC отчетторго; кирүү издери аудит-журналга жазылат.

16) Dashboard жана SLO виджеттер (эмне көрсөтүү керек)

Overall availability ай/чейрек үчүн кызмат.
Downtime Windows менен severity жана канал детекторунун.
Error budget burn (fast/slow) жана тренддер.
Releases overlay - түшүндүрмөлөр.
SLA кредиттер forecast - учурдагы тренд менен.

17) Ишке ашыруу планы (3 итерация)

1. Модель жана маалыматтар (2 жума): SLI/SLO/SLA бекитүү, quorum-синтетиканы киргизүү, DWHде "чийки затты" чогултуу.
2. Эсептөө жана отчет (2-3 жума): формулалар, SQL/PromQL, YAML/PDF үлгүлөрү, кардар порталы, авто кредиттер.
3. Аудит жана автоматташтыруу (3-4 жума): Legal Hold, статус-бет менен reconciliation, кол коюлган вебхактар, талаш-тартыш регламенттери.

18) Отчет сапатынын чек-тизмеси

• Scope аныкталган, SLI, ыкмасы жана өлчөө терезе.
• quorum жана multi-window бар; flapping басылат.
• Өзгөчөлүктөр (maintenance/force majeure) документтештирилген.
• Ар бир downtime терезе INC жана RCA менен байланышкан.
• SLA кредиттер эсептелген жана биллингде чагылдырылган.
• Отчет ойнотулат (формула/маалыматтар).
• Аудит-Trail жана Юридикалык Hold кирет.
• Коомдук статус-бет макулдашылган (reconciliation notes).

19) Mini-FAQ

Эмне үчүн синтетика негизги булагы болуп саналат?
Бул колдонуучунун жолуна жакын жана периметрин камтыйт (DNS/CDN/WAF). Метрика/логи - себебин тактайт.

Жарым-жартылай деградацияны кантип эсептөөгө болот?
салмактуу downtime: катачылыктардын үлүшү × терезенин узактыгы эмес, "баары же эч нерсе".

"Чийки" текшерүүлөрдү сактоо керекпи?
Ооба. талаш-тартыш учурунда аудит жана кайра эсептөө үчүн - raw зарыл.

Жыйынтык

Uptime-отчеттор жана аудит SLA - бул "айдын акырына карата саны" эмес, ошондой эле өлчөө, эрежелер жана далилдер: туура SLI, quorum-текшерүүлөр, ачык-айкын формулалар, инциденттер жана биллинг менен байламта, өзгөчөлүктөрдү көзөмөлдөө жана мыйзамдуу Hold. Методиканы оңдоп, эсептөөнү жана кредиттерди автоматташтырып, аудит-трейлерди кармап туруңуз - ошондо сиздин SLAларыңыз башкарылуучу, түшүнүктүү жана корголот.