Қызмет көрсету терезелері

1) «қызмет көрсету терезесі» дегеніміз не және ол не үшін қажет

Қызмет көрсету терезесі - қолжетімділікке/өнімділікке әлеуетті әсер ететін жұмыстар үшін алдын ала келісілген уақыт аралығы. Мақсаты - болжамды тәуекелмен, ашық коммуникациямен және дәлелді есептілікпен бақыланатын өзгерістер.

• Planned (жоспарлы): релиздер, көші-қон, сертификаттар/кілттер ротациясы, БД/брокерлердің жаңартулары.
• Emergency (авариялық): шұғыл қауіпсіздік фикстері/инциденттік қайтарулар.
• Silent/Zero-impact: пайдаланушы әсері жоқ (жасырын канарейка, реплика, параллель енгізу).
• Provider-led: сыртқы провайдерлердің терезелері (PSP/KYC/CDN/Cloud).

2) Қағидаттар

SLO-first: терезенің уақыты/пішімі туралы шешім SLI және қате бюджеттеріне әсері бойынша қабылданады.
Ең аз жарылыс радиусы: канарейка → сатылы → толық қосылу.
Қайтарымдылық: әрбір операцияның backout-жоспары және тексерілген кері қайтару бар.
Бірыңғай ақиқат көзі: толық деректер жиынтығымен терезе күнтізбесі + тикет/RFC.
Дәлелділігі: evidence жинау (логтар, графиктер, скриншоттар, артефактілердің хэштері).
SLA бойынша коммуникациялар: алдын ала, жұмыс барысында, аяқталғаннан кейін.

3) Жоспарлау: уақыт пен қамтуды таңдау

Терезені таңдау: төмен трафик, негізгі когорттар үшін ең аз импакт (аймақтар/VIP/серіктестер).
Уақыт белдеулері: UTC + жергілікті уақытта белгілеңіз (мысалы, Europe/Kyiv).
Блэклаут-кезеңдер: ең жоғары маусымдағы жұмыстарға/оқиғаларға тыйым салу (матчтар, сату, релиздік «өлім терезелері»).
Blast radius: кімге әсер ететінін нақты анықтау (сервистер, өңірлер, провайдерлер).

4) Келісу процесі (RFC/CAB lite)

1. Бастамашы тәуекел талдауы мен жоспары бар/RFC тикетін жасайды (төмендегі үлгіні қараңыз).
2. Тәуекелдерді бағалау (Low/Med/High) және + SRE/қауіпсіздік сервисі иесінің бекітуі.
3. Күнтізбе: слотты брондау; қайшылықтарды тексеру (басқа терезелер/провайдерлер).
4. Комм-жоспар: алдын ала келісілген хабарламалар және статус-бет.
5. High-risk өзгерістері үшін Go/No-Go-кездесу (24-48 сағат).

5) Дайындау: қауіпсіздік гейттері

Тексерулер басталғанға дейін: стейждегі сәтті тесттер, артефактілерге қол қойылды, жиынтық тәуекелдер рұқсат етілген ≤.
Канарейка: 1% → 5% → 25% когорта/өңір бойынша; автоматты SLO-гардрейл және авто-кері қайту.
Тозу мен лимиттер дайын.
Rollback/backout-жоспары құмсалғышта тексерілді; кері қайтару пәрмені құжатталған.
Suppression ескертпелері: тек күтілетін шу үшін, SLO-сигналдары өшірілмейді.
Қолжетімділік: JIT/JEA операциялары үшін есепке алу, мандаттық аудит.

6) Коммуникация (тайминг және мазмұн)

T-14/7/2 күн (жоспарлы): клиенттер/ішкі командалар үшін heads-up (не/қашан/әсер/байланыстар).
T-60/30/15 минут ішінде және мәртебе бетінде ескертулер.
Жұмыс уақытында: әрбір 15-30 минут сайын (SEV-тәуелді) үлгі бойынша: Импакт → Кезең → Келесі жаңарту.
Кейін: соңғы «Completed/Partially completed/Rolled back», өзгерістер тізімі, SLO тексеру.

7) Жұмыстарды жүргізу (референс-сценарий)

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

8) Терезеден кейін: верификация және есептілік

Observation window (мысалы, 1-24 сағат): SLO және қателерді қадағалау.
Терезе бойынша есеп: не істедіңіз, метрика, ауытқулар, evidence, жиыны.
Егер проблемалар болса: AAR → RCA → CAPA (ережелер, тесттер, құжаттамалар).
Мұрағат: тикет, артефактілер, қолтаңбалар, бақылау сомалары.

9) Сыртқы провайдерлермен үйлестіру

Провайдердің расталған слоттары мен контактілері; олардың мәртебе-жүйесіндегі терезе.
Жұмыс кезеңінде баламалы провайдерге фолбэк/бағыттау.
Провайдермен (чат/бридж) және SLA жаңартуларымен бірыңғай war-room.

10) Процестің жетілу өлшемдері

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

11) Чек парақтары

Терезенің алдында

• RFC/сертификат толтырылды; тәуекел-бағалау орындалды; иесі тағайындалды.
• Канарейка және backout-жоспар тексерілді; кері қайтару пәрмендері сынақтан өткізілді.
• JIT рұқсаттары берілген; тәуекелдер теңшелді (SLO өшірілмейді).
• Күнтізбе/статус-бет және хабарламалар дайындалды.
• Релиздер/бәсекелес терезелер - мұздатылған/жылжытылған.
• Провайдерлер расталды; контактілер мен SLA жазылған.

• Кесте бойынша апдейттер; war-room белсенді.
• SLO/қате шыңы бойынша гардрейл сақталады; бұзылған жағдайда - авто-кері қайтару.
• Evidence жиналады (скриншоттар, графиктер дейін/кейін, әрекеттер).

• SLO жасыл аймақта observation window бойы.
• 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-сигналдарды өшіру.
Бір домен/аймақтағы бәсекелес терезелер.
Комм-тыныштық: «дейін/кезінде/кейін» деген жаңартулар жоқ.
Аудитсіз және сценарийсіз өнімдегі қолмен түзетулер.
Табыстың белгісіз өлшемдеріне байланысты «шексіз» терезелер.
evidence болмауы - сапаны растайтын ештеңе жоқ.

15) Енгізудің жол картасы (4-6 апта)

1. Нед. 1: бірыңғай күнтізбені және RFC үлгісін енгізу; блэклаут-кезеңдерін анықтау.
2. Нед. 2: гейттерді стандарттау (канарейка, SLO-гардрейл, backout).
3. Нед. 3: suppression/аннотация релиздерін және мәртебе бетін автоматтандыру.
4. Нед. 4: есептілік және жетілу метрикасы; апта сайынғы MW-review.
5. Нед. 5-6: провайдерлермен және аудит-мұрағатпен интеграция; High-risk терезесінің симуляциясы.

16) Жиынтық

Дұрыс ұйымдастырылған қызмет көрсету терезелері - бұл басқарылатын, қайтарылатын және дәлелденетін қауіпсіз өзгерістер. SLO-гардрейлдері, канареялық өрістері, қатаң коммуникациялары және evidence толық жиынтығы бар терезе «қорқынышты тұрып қалу уақытынан» пайдаланушылар мен серіктестер үшін күтпеген жағдайларсыз күнделікті жақсарту механизміне айналады.