Uptime есептер және SLA аудиті

1) Неге uptime-есептіліктің формальды процесі қажет

Клиенттердің сенімі және келісімшарттық ашықтық - өлшеудің бірыңғай әдістемесі, қайталанатын есептеулер.
SLO және қателер бюджетін басқару - релиздер мен инциденттермен қол жетімділік фактісін байланыстыру.
Дұрыс SLA-кредиттер - объективті формулалар, болжамды төлемдер/есептеулер.
Заңдық тұрақтылық - дәлелдеу базасы, тәуелсіз аудит, Legal Hold.

2) Терминдер мен шекаралар

SLI Availability - кезең ішіндегі табысты тексерулер/транзакциялар үлесі.
SLO - ішкі мақсат (мысалы, 99. 28 күнде 95%).
SLA - сыртқы міндеттеме (мысалы, 99. 9 %/ай + сервис-кредиттер).
Өлшеу терезесі - күнтізбелік ай (SLA) және rolling-терезе (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

Егер тәуелсiз аймақтардың/ASN ≥ бас тартуды бiр мезгiлде тiркесе, тосын оқиға есептеледi.
Ұсынылатын: 3-тен N = 2 (EU/NA/APAC).

4. 3 SLI түрлері

HTTP SLI: код 2xx/3xx, latency ≤ T.
DNS/TLS SLI: NXDOMAIN/SERVFAIL/expiry.
SLI бизнесі: сәтті транзакциялар/барлық әрекеттер (клиенттік бас тартуларды қоспағанда).

4. 4 Ерекшеліктер (documented)

N сағат алдын ала жарияланған және сақталған жоспарлы maintenance терезелері.
SLA-дан Force majeure (мысалы, IX-апат провайдері) - дәлелдемелер мен жария хабарлама болған кезде ғана.
Клиенттік қателер/шектеулер (quota exceeded, 4xx).

5) Терезелердің maintenance саясаты

Келісімшартта келісілген уақытша слоттар (мысалы, UTC + 0 бойынша 02: 00-04: 00).
'maintenance = true' таңбалауыштары алерт/панельдерде → 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: кредит келесі шотқа credit note ретінде қолданылады.
Автоматтандыру: "егер 'measured _ availability <SLA' → 'credit _ note. create()`».
Клиентке арналған витрина: «SLA credits balance» порталдық карточкасы.

11) Аудит, дәлелдемелер және Legal Hold

Аудит-трейл: кім/не/қашан есептеді, әдістеменің нұсқасы, бақылау сомалары.
Raw-деректер өзгермейді (append-only); түзетулер - жеке жазбалармен.
Legal Hold: деректер ауқымын мұздату (сынамалар, логтар, инцидент-карточкалар, алерталар).
Мұрағат репликасы: тәуелсіз сақтау орны (Object Lock WORM/S3).

12) Жария мәртебе-парақпен салыстыру

Статус-парақтағы инциденттің таймлайн мен компоненттері болуы міндетті.
Уақыт/масштаб сәйкессіздігі → discrepancy-record жасалады және RCA жүргізіледі.
Есептің қорытындысы «Reconciliation Notes» бөлімінен тұрады.

13) Инциденттер және есептілік

Даунтаймның әрбір терезесіне INC-карточка (ID, SEV, иесі, RCA, CAPA) сәйкес келеді.
Есепте: INC-ке сілтеме, қысқаша root cause, CAPA мәртебесі.
SEV-1 үшін: тақырыптар жабылғаннан 48 сағат ≤.

14) Деректер сапасын бақылау

Сынамалар гигиенасы:> 99% сәтті агенттер скрейптері, рұқсаттамалардың болмауы> 5 минут.
Анти-шу: quorum + multi-window, debounce.
Трассаларды/логтарды сэмплирлеу белгіленеді және құжатталады.
Әдістеме тестілері: есептеулердің юнит-тестілері, тарихи деректердегі golden-файлдар.

15) Қауіпсіздік және құпиялылық

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

16) Дашбордтар және SLO-виджеттер (не көрсету керек)

Overall availability бір айда/тоқсанда сервистер бойынша.
severity және детектор арнасы бар Downtime windows.
Error budget burn (fast/slow) және трендтер.
Releases overlay - есептер аңдатпалары.
SLA credits 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-кредиттер есептелген және биллингте көрсетілген.
• Есепті қайталаймыз (формулалар/деректер нұсқалары).
• Аудит-трейл және Legal Hold қосылған.
• Көпшілік мәртебе-беті келісілген (reconciliation notes).

19) Шағын FAQ

Неліктен синтетика басты дереккөз?
Ол пайдаланушы жолына ең жақын және периметрді (DNS/CDN/WAF) қамтиды. Метрика/логи - себебін анықтайды.

Ішінара құлдырауды қалай санауға болады?
Өлшенген даунтайм: сәтсіздіктер үлесі × «барлығы немесе ештеңе» емес, терезенің ұзақтығы.

«Шикі» тексерулерді сақтау керек пе?
Иә. Дау кезінде аудит және қайта есептеу үшін raw міндетті түрде қажет.

Жиынтық

Uptime-есептер және SLA аудиті - «айдың аяғындағы сан» емес, өлшеулердің, ережелердің және дәлелдемелердің қайталанатын жүйесі: дұрыс SLI, quorum-тексерулер, мөлдір формулалар, инциденттермен және биллингпен байланысу, ерекшеліктерді бақылау және Legal Hold. Әдістемені бекітіңіз, есеп айырысу мен несиелерді автоматтандырыңыз, аудит-трейлерді ұстаңыз - және сіздің SLA басқарылатын, түсінікті және қорғалған болады.