유지 보수 창
1) "유지 보수 창" 이란 무엇이며 필요한 이유
유지 보수 창-가용성/성능에 영향을 줄 수있는 활동에 대한 사전 합의 된 기간. 목표는 예측 가능한 위험, 투명한 의사 소통 및 증거 기반보고로 통제 된 변화입니다.
유형:- 계획된: 릴리스, 마이그레이션, 인증서/키 로테이션, 데이터베이스/브로커 업그레이드.
- 긴급 상황: 긴급한 안전 수정/사고 롤백.
- 사일런트/제로 임팩트: 사용자 영향 없음 (숨겨진 카나리아, 복제본, 병렬 입력).
- 공급자 주도: 외부 공급자의 창 (PSP/KYC/CNC/Cloud).
2) 원칙
SLO 우선: 창의 시간/형식에 대한 결정은 SLI 및 오류 예산에 대한 영향에 따라 이루어집니다.
최소 폭발 반경: 카나리아 → 단계별 → 전체 포함.
가역성: 각 작업에는 백아웃 계획과 입증 된 롤백이 있습니다.
진실의 단일 소스: 전체 데이터 패키지가있는 창 달력 + 티켓/RFC.
증거: 증거 수집 (로그, 그래프, 스크린 샷, 아티팩트 해시).
SLA 커뮤니케이션: 사전, 작업 중, 완료시.
3) 계획: 타이밍 및 적용 범위
창 선택: 트래픽이 적고 주요 코호트 (지역/VIP/파트너) 에 미치는 영향을 최소화합니다.
시간대: UTC + 현지 시간 (예: 유럽/키예프) 으로 기록됩니다.
정전 기간: 성수기/이벤트 (일치, 판매, "죽음의 창" 출시) 동안 작업 금지.
폭발 반경: 영향을받을 사람 (서비스, 지역, 공급자) 을 명확하게 정의하십시오.
4) 협상 프로세스 (RFC/CAB 라이트)
1. 발신자는 위험 분석 및 계획을 갖춘 티켓/RFC를 작성합니다 (아래 템플릿 참조).
2. 위험 평가 (Low/Med/High) 및 서비스 소유자의 승인 + SRE/보안.
3. 일정: 슬롯 예약; 충돌 점검 (다른 창/공급자)
4. Comm 계획: 사전 합의 된 알림 및 상태 페이지.
5. 고위험 변경을 위해 Go/No-Go 회의 (24-48 시간).
5) 준비: 보안 게이트
사전 출시 점검: 성공적인 스테이지 테스트, 서명 된 아티팩트, 총 위험
카나리아: 코호트/지역별 1% → 5% → 25%; 자동 SLO 가드 레일 및 자동 롤백.
분해 플래그와 한계가 준비되었습니다.
샌드 박스에서 롤백/백 아웃 계획 체크; 롤백 명령이 문서화되어 있습니다.
경고 억제: 예상 노이즈에 대해서만 SLO 신호가 흐려지지 않습니다.
액세스: JIT/JEA는 운영, 필수 감사를 설명합니다.
6) 커뮤니케이션 (타이밍 및 컨텐츠)
T-14/7/2 일 (계획): 고객/내부 팀 (무엇/언제/충격/연락처) 을위한 헤드 업.
T-60/30/15 분: 상태 페이지 내부 및 상태 페이지에 알림.
작업 중: 템플릿에 따라 15-30 분마다 업데이트 (SEV 종속): Impact → Stage → Next 업데이트.
이후: 최종 "완료/부분 완료/롤백", 변경 사항 목록, SLO 확인.
7) 작품 성능 (참조 시나리오)
1. 관련없는 릴리스를 동결하십시오.
2. 카나리아로의 전환 (제한된 코호트) → SLI/p95/p99 메트릭을 관찰합니다.
3. 녹색 가드 레일과의 점유율이 단계적으로 증가합니다.
4. 비즈니스 SLI 검증 (전환, 결제/등록 성공).
5. 목록 기능 검증 (행복한 경로 + 중요한 시나리오) 을 확인하십시오.
6. 릴리스/릴리스 없음 솔루션 (IC/SRE/서비스 소유자).
7. 억제 제거, 경보 정책 반환.
8) 창 뒤에: 검증 및보고
관찰 창 (예: 1-24 시간): SLO 및 오류 추적.
창 보고서: 수행 된 작업, 측정, 편차, 증거, 총계.
문제가있는 경우: AAR → RCA → CAPA (수정 규칙, 테스트, 문서).
아카이브: 티켓, 아티팩트, 서명, 체크섬.
9) 외부 제공 업체와의 조정
확인 된 슬롯 및 공급자 연락처; 상태 시스템의 창.
작업 기간 동안 대체 공급자에게 폴백/라우팅.
공급자 (채팅/브리지) 및 SLA 업데이트가있는 단일 전쟁 실.
10) 프로세스 성숙도 지표
정시 요금: 창의% 가 정시에 시작/완료되었습니다.
실패율 변경: SLO에 롤백/충격이있는 창의%.
MW 사건: 창문 중에 발생한 사건.
커뮤니케이션 SLA: 적시 업데이트 공유.
증거 완전성: 전체 증거 패키지가있는 창의%.
고객 영향: 1 개의 창 불만/티켓, 추세.
7/30 일 후: SLO 안정성 및 재발 없음.
11) 점검표
창 앞에
- RFC/티켓이 가득 찼습니다. 위험 평가 완료; 소유자가 할당했습니다
- 카나리아 및 백 아웃 계획 확인; 테스트 된 롤백 명령.
- JIT 액세스 발행; 경고가 구성됩니다 (SLO가 걸리지 않음).
- 달력/상태 페이지 및 알림이 준비됩니다.
- 윈도우 출시/경쟁-냉동/시프트.
- 서비스 제공 업체 확인; 연락처 및 SLA가 기록됩니다.
동안
- 일정에 따라 업데이트; 전쟁 실이 활성화되어 있습니다.
- SLO/피크 오류에 대한 Gardrails가 존중됩니다. 위반의 경우-자동 롤백.
- 증거가 수집됩니다 (스크린 샷, 그래프 전/후, 액션 로그).
후
- 관측 창 동안 녹색 영역의 SLO.
- 증거가있는 최종 보고서; 상태 페이지가 업데이트되었습니다.
- 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억제 규칙 (아이디어)
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/금융: 증거로 마스킹, 보고서에 대한 액세스 제한.
계약에 따라 고객 및 파트너에게 알리는 알림 약관.
공급자 창 - 외부 SLA 및 연락처로 문서화되어 있습니다.
14) 반 패턴
백아웃 계획이없고 롤백이 확인되지 않은 창.
SLO 신호의 걸림은 "경우에 따라" 입니다.
동일한 도메인/지역에서 경쟁하는 창.
통신 침묵: 업데이트 전/도중/후에 없음.
감사 및 스크립트없이 제품의 수동 편집.
불확실한 성공 기준으로 인한 "무한한" 창.
증거 부족-품질을 확인할 수있는 것은 없습니다.
15) 구현 로드맵 (4-6 주)
1. 네드. 1-단일 캘린더를 입력하고 RFC 템플릿은 정전 기간을 정의합니다.
2. 네드. 2: 표준화 게이트 (카나리아, SLO- 가드 레일, 백 아웃).
3. 네드. 3: 억제/릴리스 주석 및 상태 페이지를 자동화하십시오.
4. 네드. 4: 보고 및 성숙 지표; 매주 MW 검토.
5. 네드. 5-6: 공급자 및 감사 아카이브와의 통합; 고위험 창 시뮬레이션.
16) 결론
올바르게 구성된 서비스 창은 관리 가능하고 가역적이며 확실하게 변경 될 수 있습니다. SLO-gardrails, 카나리아 강간, 엄격한 통신 및 전체 증거를 통해 창은 "끔찍한 다운 타임" 에서 사용자와 파트너에게 놀라지 않고 일상적인 개선 메커니즘으로 바뀝니다.