Xidmət pəncərələri
1) «xidmət pəncərəsi» nədir və niyə lazımdır
Xidmət pəncərəsi - potensial olaraq əlçatanlığa/məhsuldarlığa təsir edən işlər üçün əvvəlcədən razılaşdırılmış müddət. Məqsəd - proqnozlaşdırıla bilən risk, şəffaf ünsiyyət və sübut hesabatı ilə nəzarət edilən dəyişikliklər.
Növləri:- Planned (planlı): buraxılışlar, miqrasiya, sertifikatların/açarların rotasiyası, DB/brokerlərin yenilənməsi.
- Təcili (təcili): təcili təhlükəsizlik fiksləri/insident geri dönüşləri.
- Silent/Zero-impact: istifadəçi təsiri olmadan (gizli kanaryalar, replikalar, paralel giriş).
- Provider-led: xarici provayderlərin pəncərələri (PSP/KYC/CDN/Cloud).
2) Prinsiplər
SLO-first: Pəncərənin vaxtı/formatı barədə qərar SLI və səhv büdcələrinə təsir göstərir.
Minimum partlayış radiusu: kanarya → pilləli → tam qoşulma.
Geri dönüş: Hər bir əməliyyatın backout planı və yoxlanılmış geri dönüşü var.
Vahid həqiqət mənbəyi: tam məlumat paketi ilə pəncərə təqvimi + bilet/RFC.
Sübut: evidence toplanması (qeydlər, qrafiklər, ekran şəkilləri, artefaktların heşləri).
SLA üzrə kommunikasiyalar: əvvəlcədən, iş zamanı, başa çatdıqdan sonra.
3) Planlaşdırma: vaxt və əhatə seçimi
Pəncərə seçimi: aşağı trafik, əsas kohortlar üçün minimum təsir (regionlar/VIP/partnyorlar).
Saat qurşaqları: UTC + yerli vaxt (məsələn, Avropa/Kiyev).
Blacklaut dövrləri: pik mövsümlərdə/hadisələrdə işləməyə qadağa (matçlar, satışlar, buraxılış «ölüm pəncərələri»).
Blast radius: kimə təsir edəcəyini dəqiq müəyyənləşdirin (xidmətlər, regionlar, provayderlər).
4) Koordinasiya prosesi (RFC/CAB lite)
1. Təşəbbüskar risk analizi və planı olan bir bilet/RFC yaradır (aşağıdakı şablona baxın).
2. Risklərin qiymətləndirilməsi (Low/Med/High) və xidmət sahibinin təsdiqi + SRE/təhlükəsizlik.
3. Təqvim: slot rezervasiyası; konfliktlərin yoxlanılması (digər pəncərələr/provayderlər).
4. Comm-plan: əvvəlcədən razılaşdırılmış bildirişlər və status-səhifə.
5. High-risk dəyişikliklər üçün Go/No-Go-görüş (24-48 saat).
5) Hazırlıq: təhlükəsizlik geytaları
Başlamazdan əvvəl yoxlamalar: steyjada uğurlu testlər, imzalı artefaktlar, ümumi risklər ≤ icazə verilir.
Kanarya: 1% → 5% → 25% kogorta/region; avtomatik SLO-gardrails və avtomatik geri.
Deqradasiya fiça bayraqları və limitlər hazırdır.
Rollback/backout planı qum qutusunda yoxlanılır; geri qaytarma komandaları sənədləşdirilmişdir.
Suppression alerts: yalnız gözlənilən səs-küy üçün, SLO siqnalları səssiz deyil.
Accessories: JIT/JEA əməliyyatları üçün qeydlər, mandat audit.
6) Rabitə (tayminq və məzmun)
T-14/7/2 gün (planlı): müştərilər/daxili komandalar üçün başlıq (nə/nə zaman/təsir/əlaqə).
T-60/30/15 dəqiqə: daxili və status səhifəsində xatırlatmalar.
İş zamanı: Hər 15-30 dəqiqədən bir yeniləmə (SEV-asılıdır) şablona görə: Impact → Mərhələ → Növbəti yeniləmə.
Sonra: final «Completed/Partially completed/Rolled back», dəyişikliklər siyahısı, SLO yoxlama.
7) İşlərin aparılması (referens-ssenari)
1. Freeze əlaqəsiz buraxılışlar.
2. canary keçid (məhdud kohorta) → SLI/metrik p95/p99 müşahidə.
3. Yaşıl qartreyllərdə payın addım-addım artması.
4. Biznes SLI yoxlaması (dönüşüm, ödənişlərin/qeydiyyatların müvəffəqiyyəti).
5. Check-list funksionallığının yoxlanılması (happy path + kritik ssenarilər).
6. Release/No-release həll (IC/SRE/xidmət sahibi).
7. suppression aradan qaldırılması, alert siyasətçi geri.
8) Pəncərədən sonra: yoxlama və hesabat
Observation window (məsələn, 1-24 saat): SLO və səhvləri izləmək.
Pəncərə hesabatı: nə etdi, metriklər, sapmalar, evidence, nəticə.
Əgər problem varsa: AAR → RCA → CAPA (qaydaların fiksi, testlər, sənədlər).
Arxiv: bilet, artefaktlar, imzalar, nəzarət məbləğləri.
9) Xarici provayderlərlə koordinasiya
Təsdiq edilmiş slots və əlaqə provayder; onların status sistemində pəncərə.
İş müddəti üçün alternativ provayderə folbek/marşrut.
Bir provayder ilə vahid war-room (chat/bridge) və SLA yeniləmələr.
10) Yetkinlik prosesinin metrikası
On-time rate: vaxtında başlayan/tamamlanan pəncərələrin%.
Change failure rate: SLO-ya təsir edən pəncərələrin% -i.
Incident-during-MW: pəncərə zamanı baş verən hadisələr.
Communication SLA: vaxtında yeniləmələrin payı.
Evidence completeness:% tam sübut paketi ilə pəncərələr.
Customer impact: 1 pəncərə şikayət/biletlər, trend.
7/30 gün sonra: SLO sabitliyi və təkrarlanma yoxdur.
11) Çek vərəqləri
Pəncərənin qarşısında
- RFC/bilet dolu; risk qiymətləndirilməsi yerinə yetirilib; sahibi təyin edilmişdir.
- Kanarya və backout planı yoxlanılır; Geri qaytarma komandaları sınaqdan keçirilir.
- JIT Access verilir; (SLO susmur).
- Təqvim/status-səhifə və bildirişlər hazırlanmışdır.
- Buraxılışlar/rəqib pəncərələr - dondurulmuş/köçürülmüşdür.
- Provayderlər təsdiq; əlaqə və SLA qeydə alınır.
Zaman
- Update cədvəli; war-room aktiv.
- SLO/səhvlərin zirvəsində Gardrails müşahidə olunur; pozulduqda - avtomatik geri çəkilmə.
- Evidence toplanır (ekran görüntüləri, əvvəl/sonra cədvəllər, fəaliyyət log).
Sonra
- observation window ərzində yaşıl zonada SLO.
- evidence ilə son hesabat; status-səhifə yenilənib.
- CAPA rəsmiləşdirilmiş (sapmalar varsa); sənədləşmə yenilənib.
12) Şablonlar
Xidmət pəncərəsinə RFC şablonu
RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB
Müştəri bildiriş şablonu (qısa)
Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com support@example. com
Suppression qaydaları (ideya)
yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]
13) Tənzimlənən domenlər üçün xüsusiyyətlər
Audit-log dəyişməzdir: kim təsdiq etdi, kim yerinə yetirdi, hansı əmrlər, artefaktların heşləri.
PII/maliyyə: evidence maskalama, hesabatlara məhdud giriş.
Müştərilərə və tərəfdaşlara bildiriş müddəti - müqavilələrə uyğun olaraq.
Provayder pəncərələri - xarici SLA və kontaktlarla sənədləşdirilmişdir.
14) Anti-nümunələr
Backout planı və yoxlanılmış geri dönüş olmadan pəncərə.
SLO siqnallarının «hər ehtimala qarşı» səssizləşdirilməsi.
Eyni domen/bölgədə rəqib pəncərələr.
Comm-sükut: heç bir yeniləmə «əvvəl/zamanı/sonra».
Audit və skript olmadan bir prod əl düzəlişləri.
Uğurun qeyri-müəyyən meyarlarına görə «sonsuz» pəncərələr.
Evidence olmaması - keyfiyyəti təsdiq edəcək bir şey yoxdur.
15) Yol xəritəsi (4-6 həftə)
1. Ned. 1: vahid təqvim və RFC şablon daxil edin; blacklaut dövrləri müəyyən.
2. Ned. 2: geytləri standartlaşdırın (kanarya, SLO-gardrails, backout).
3. Ned. 3: suppression/relizlər və status səhifə izahatları avtomatlaşdırmaq.
4. Ned. 4: hesabat və yetkinlik metrikası; həftəlik MW-review.
5. Ned. 5-6: provayderlər və audit arxivi ilə inteqrasiya; Yüksək riskli pəncərə simulyasiyası.
16) Yekun
Düzgün təşkil edilmiş xidmət pəncərələri idarə edilə bilən, geri çevrilə bilən və sübut edilə bilən təhlükəsiz dəyişikliklərdir. SLO-gardrails, kanarya yayılması, sərt kommunikasiyalar və tam evidence dəsti ilə pəncərə istifadəçilər və tərəfdaşlar üçün sürprizsiz gündəlik təkmilləşdirmə mexanizminə çevrilir.