Тейлөө терезелери

1) "тейлөө терезеси" деген эмне жана ал эмне үчүн керек

Тейлөө терезеси - жеткиликтүүлүккө/өндүрүмдүүлүккө потенциалдуу таасир этүүчү жумуштар үчүн алдын ала макулдашылган убакыт аралыгы. Максаты - болжолдуу тобокелдик, ачык-айкын байланыш жана далилдүү отчеттуулук менен көзөмөлдөнгөн өзгөрүүлөр.

• Planned (пландаштырылган): релиздер, көчүрүү, сертификаттарды/ачкычтарды айлантуу, DD/брокерлерди жаңыртуу.
• Шашылыш (өзгөчө): шашылыш коопсуздук ficks/окуя rebound.
• Silent/Zero-impact: колдонуучунун таасири жок (жашыруун канарейлер, репликалар, параллелдүү киргизүү).
• Provider-led: терезелер тышкы провайдерлер (PSP/KYC/CDN/Cloud).

2) Принциптер

SLO-биринчи: терезенин убактысы/форматы жөнүндө чечим SLI жана ката бюджеттерине таасир этүү менен кабыл алынат.
Минималдуу жарылуу радиусу: канарейка → баскычтуу → толук күйгүзүү.
Кайтарымдуулугу: ар бир операциянын backout планы жана текшерилген кайтарымы бар.
Бир чындык булагы: терезе календары + толук маалымат топтому менен билети/RFC.
Далил: evidence чогултуу (Логи, сүрөттөр, скриншоттор, хеш экспонаттар).
SLA боюнча байланыш: алдын ала, иштин жүрүшүндө, аяктагандан кийин.

3) пландаштыруу: убакыт жана камтуу тандоо

Терезени тандоо: төмөн жол, негизги жамааттар үчүн минималдуу таасир (региондор/VIP/өнөктөштөр).
Убакыт алкактары: UTC + жергиликтүү убакыт (мисалы, Europe/Kyiv).
Блэклаут мезгилдери: эң жогорку мезгилдерде иштөөгө тыюу салуу/окуялар (матчтар, сатуулар, релиздик "өлүм терезелери").
Blast radius: кимге таасир этээрин так аныктоо (кызматтар, аймактар, провайдерлер).

4) макулдашуу жараяны (RFC/CAB lite)

1. Демилгечи тобокелдик анализи жана план менен/RFC билетин түзөт (төмөндөгү үлгүнү караңыз).
2. Тобокелдиктерди баалоо (Low/Med/High) жана тейлөө + SRE/коопсуздук ээси тарабынан бекитүү.
3. Календарь: Slot брондоо; конфликттерди текшерүү (башка терезелер/провайдерлер).
4. Комм-план: алдын ала макулдашылган билдирүүлөр жана статус-бет.
5. Go/No-Go-жолугушуу (24-48 саат) жогорку-тобокелдик өзгөрүүлөр үчүн.

5) Даярдоо: коопсуздук гейтс

Башталганга чейин текшерүүлөр: стейдждеги ийгиликтүү тесттер, артефакттарга кол коюлду, жалпы тобокелдиктер алгылыктуу ≤.
Канарейка: 1% → 5% → 25% когорта/аймак боюнча; автоматтык SLO-Gardrails жана Auto-Roll.
Деградациянын фича-желектери жана лимиттери даяр.
Rollback/backout планы кум кутучада текшерилген; буйруктары документтештирилген.
Suppression alerts: күтүлгөн ызы-чуу үчүн гана, SLO сигналдары өчпөйт.
Access: JIT/JEA бүтүмдөр үчүн эсептер, мандат аудит.

6) Байланыш (убакыт жана мазмун)

T-14/7/2 күн (пландаштырылган): кардарлар/ички командалар үчүн heads-up (/качан/таасир/байланыштар).
T-60/30/15 мүнөт: ичинде жана статус-беттеги эскертүүлөр.
Иш учурунда: ар бир 15-30 мүнөт сайын (SEV-көз каранды) шаблон боюнча: Impact → Этап → Кийинки жаңыртуу.
Кийин: акыркы "Completed/Partially completed/Rolled back", өзгөртүү тизмеси, SLO текшерүү.

7) Иштерди жүргүзүү (референс-сценарий)

1. Freeze байланышсыз релиздер.
2. canary (чектелген когорта) өтүү → SLI/метрика p95/p99 байкоо.
3. Жашыл Gardrails менен үлүшүн кадам сайын көбөйтүү.
4. Бизнес-SLI текшерүү (конверсия, төлөмдөрдүн/катталуулардын ийгилиги).
5. Чек тизмеси менен функционалдык текшерүү (happy path + критикалык сценарийлер).
6. Release/No-release чечим (IC/SRE/сервистин ээси).
7. Suppression алып салуу, alert-саясат кайтаруу.

8) терезеден кийин: текшерүү жана отчеттуулук

Observation window (мисалы, 1-24 саат): SLO жана каталарды көзөмөлдөө.
Терезе боюнча отчет: эмне кылышты, метриктер, четтөөлөр, evidence, жыйынтык.
көйгөйлөр бар болсо: AAR → RCA → CAPA (эрежелер, тесттер, документтер).
Архив: тикет, экспонаттар, кол тамгалар, контролдук суммалар.

9) Тышкы провайдерлер менен координациялоо

Тастыкталган Slots жана байланыштар; алардын статус-системасындагы терезе.
Иштөө мезгилинде альтернативдик провайдерге фолбэк/маршрутизация.
Бирдиктүү war-room менен провайдер (чат/бридж) жана SLA жаңылануулар.

10) Жетилүү жараянынын метрикасы

On-time rate:% терезелер убагында башталган/аяктаган.
Change failure rate:% SLO менен терезелер/таасири.
Incident-during-MW: терезе учурунда болгон окуялар.
SLA Communication: өз убагында тактоо үлүшү.
Evidence completeness: далилдер толук пакети менен терезелер%.
Customer impact: 1 терезеге даттануулар/билеттер, тренд.
7/30 күндөн кийин: SLO туруктуулугу жана кайталануулар жок.

11) Чек-баракчалар

Терезенин алдында

• RFC/билети толтурулган; тобокелдик-баа берүү аткарылды; ээси дайындалды.
• Канарейка жана backout-план текшерилген; команда сыналган.
• JIT жеткиликтүү берилген; (SLO өчпөйт).
• Календарь/статус-бет жана билдирүүлөр даярдалган.
• Релиздер/атаандаш терезелер - тоңдурулган/жылдырылган.
• Провайдерлер тастыкталган; байланыштар жана SLA жазылган.

Учурунда

• күн тартиби боюнча; war-room активдүү.
• SLO/каталардын чокусу боюнча Гардрейл сакталат; бузулса - авто-артка чегинүү.
• Evidence чогултат (скриншоттор, графиктер чейин/кийин, иш-аракеттер журналы).

Кийин

• observation window үчүн жашыл зонада SLO.
• evidence менен акыркы отчет; статус-бет жаңыланды.
• CAPA берилген (эгерде четтөөлөр болгон болсо); документтери жаңыланды.

12) Үлгүлөр

Тейлөө терезесинде RFC үлгүсү

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

Кардар кабарлоо үлгүсү (кыскача)

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 эрежелери (идея)

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) жөнгө домендер үчүн өзгөчөлүктөрү

Аудит-лог өзгөрүлбөйт: ким жактырды, ким аткарды, кандай буйруктар, экспонаттардын хэштери.
PII/каржы: evidence жашыруу, отчетторго жеткиликтүүлүгү чектелген.
Кардарларга жана өнөктөштөргө билдирүүлөрдүн мөөнөттөрү - келишимдерге ылайык.
Провайдердик терезелер - тышкы SLA жана байланыштар менен документтештирилген.

14) Анти-үлгүлөрү

Backout планы жана текшерилген кайтаруу жок терезе.
SLO сигналдарды өчүрүү ".
бир домен/аймакта атаандаш терезелер.
Comm-унчукпай: эч кандай жаңылоо "чейин/учурунда/кийин".
Аудит жана скрипт жок кол менен түзөтүү.
"Чексиз" терезелер, анткени ийгиликтин белгисиз критерийлери.
evidence жоктугу - сапатын тастыктай турган эч нерсе жок.

15) Жол картасы киргизүү (4-6 жума)

1. Нед. 1: бирдиктүү календары жана RFC-шаблон киргизүү; Блэклаут мезгилдерин аныктоо.
2. Нед. 2: стандарттык Гейтс (канарейка, SLO-Гардрейл, backout).
3. Нед. 3: автоматташтыруу suppression/аннотация релиздер жана статус-бет.
4. Нед. 4: отчеттуулук жана жетилүү метрика; жума сайын MW-review.
5. Нед. 5-6: провайдерлер жана аудит архиви менен интеграция; Жогорку тобокелдик терезе симуляция.

16) Жыйынтык

Туура уюштурулган тейлөө терезелери башкарылуучу, кайтарылуучу жана далилденүүчү коопсуз өзгөрүүлөр болуп саналат. SLO-Gardrails менен, канареа, катуу байланыш жана evidence терезе колдонуучулар жана өнөктөштөр үчүн күтүлбөгөн күнүмдүк жакшыртуу механизми "коркунучтуу убакыт токтоп" айланат.