표준 운영 절차
1) SOP이란 무엇이며 왜 필요한가
SOP (Standard Operating Procedure) 는 이해할 수있는 입력/출력, 역할 및 품질 기준을 갖춘 반복 가능한 작업을위한 공식화되고 검증 된 일련의 단계입니다.
SOP의 목표는 다음과 같습니다
실행 변동성과 위험을 줄입니다.
기성품 작업을 통해 MTTA/MTTR을 줄입니다.
준수 및 감사: 재현성, 추적 성.
온보드: 학습 및 섀도우 → 솔로 가속.
SOP § 플레이 북: 특정 시나리오 (또는 플레이 북 브랜치) 에 대한 플레이 북-포크가있는 의사 결정 트리, SOP-선형 규칙.
2) 좋은 SOP 원칙
결과 추진: 단계뿐만 아니라 결과에 중점을 둡니다 (SLO/비즈니스 기준).
명확성: 명령, 매개 변수, 예상 효과 및 제어 지점.
기본적으로 보안: 게이트, 제한, 백아웃/롤백이 등록됩니다.
최소 컨텍스트: 짧은 노트 + 세부 런북/진단에 대한 링크.
관련: 검토 날짜, 소유자, 버전, 만료 날짜.
예외: JIT/JEA 액세스, 전제 조건 검사, 아티팩트 템플릿.
3) SOP 표준 구조 (골격)
ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)4) SOP 디렉토리 및 소유권
'도메인/ops', '서비스/체크 아웃', '위험/높음', '제공자/psp-a' 태그가있는 단일 저장소 (Docs-as-Code).
소유자 카드: 팀, 의무 연락처, 백업 소유자.
SLA 관련성 (예: 90 일마다 또는 사고/릴리스 후에 검토하십시오).
Linter/SOP 유효성 검사기 (CI): 구조, 링크, 소유자, 검토 기간 검증.
5) SOP 수명주기
1. 시작 (사고/드릴/새로운 프로세스 후).
2. 초안 (저자 = 서비스/프로세스 소유자).
3. 검토 (SRE/Security/Legal/Comms-도메인 별).
4. 파일럿 (탁상/게임 일): 측정 시간, → 편집 항목 찾기
5. 출판 (CMDB/서비스 카탈로그의 버전, 날짜, 번호, 템플릿).
6. 운영 응용 프로그램 (티켓/채팅 주석, 증거 수집).
7. 업데이트 (RCA/CAPA, 검토 마감일, 아키텍처 변경).
8. 보관/고갈 (새 SOP/플레이 북으로 대체).
6) 인접 인공물과의 연결
플레이 북: SOP- 플레이 북 내부의 "선형 브랜치"; 단계에서 참조하십시오
런북 '및: 기술 세부 정보/스크립트는 런북에 배치되며 SOP는 참조하십시오.
정책 (코드 정책): 액세스 게이트, 권한, RBAC-필수 링크.
SLO/SLI: 성공 기준 및 가드 레일.
에스컬레이션 매트릭스: SOP 실행 실패시 역할/타이밍.
유지 보수 창: 고위험 SOP에 대한 슬롯/쉼표 요구 사항.
7) SOP 성능 지표
실행 시간 (중간/p95) -절차 시간
성공률-에스컬레이션/롤백이없는 성공률.
증거 완전성-인공물의 충만 함.
SLO Impact-단계 중/후 (연소 분) 성능이 저하됩니다.
결함 밀도-10 SOP의 검토/운동 노트.
신선도는 약 90 일의 리뷰를 가진 SOP의 비율입니다.
채택-실제로 SOP에 얼마나 많은 경고/창이 연결되어 있는지.
8) SOP 저자 점검표
- 목적 및 적용 경계가 정의되었습니다.
- 역할, 액세스 및 창문-설명합니다.
- 품질 게이트와 SLO는 측정 가능하며 신호 소스가 있습니다.
- 실행 가능한 단계: 명령/스크립트, 예상 결과, 검증.
- 백아웃/롤백 및 출시 기준-명확합니다.
- Comm 템플릿이 부착되어 있습니다.
- 증거 목록이 구성되어 있습니다.
- 버전/날짜/소유자/검토 지정.
9) SOP 체크리스트
- JIT/JEA 전제 조건 및 액세스가 확인되었습니다.
- 티켓/전쟁 실이 열려 있으며 주석이 포함되어 있습니다.
- 관찰 가능성: 필요한 대시 보드/경고가 열려 있습니다.
- 나는 순서대로 단계를 따른다. 각각-검증.
- gardrails를 위반하는 경우-즉시 백아웃 및 에스컬레이션.
- 증거가 가득합니다. 최종 SLO/비즈니스 SLI 검사.
- 티켓 폐쇄, 상태 페이지/통신 업데이트.
10) SOP 예 (단편)
10. 1 SOP: 카나리아 릴리스 롤백 (REL-ROLLBACK-01)
The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)10. 2 SOP: 예정된 DB 업그레이드 (MW-DB-UPGRADE-02)
Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)10. 3 SOP: PSP 제공 업체 전환 (PROV-PSP-SWITCH-01)
Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).10. 4 SOP: 백업 복구 검사 (DATA-BACKUP-RESTORE-CHECK-03)
Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.11) SOP 주변 자동화
SOP 템플릿: RACI/gates/comma 블록을 사용한 골격 생성.
봇 출연자: 체크 박스, 타이머, 케이던스 알림, 증거 자동 수집 단계.
CMDB/카탈로그와의 통합 - 서비스에는 관련 SOP 목록이 있습니다.
원격 측정 주석: "SOP-RUN: <ID> 단계 N" → 빠른 구문 분석.
입학 정책: 배포/창은 녹색 SOP 게이트로만 시작됩니다.
12) 반 패턴
소유자/날짜 검토가없는 SOP- "죽은" 문서.
성공 기준 및 백 아웃없이 부풀어 오른 지침.
일관되지 않은 명령/키-오류 및 누출 위험.
위키와 저장소의 다른 버전은 진실의 원천의 차이입니다.
증거가 없습니다-품질/준수를 확인할 것이 없습니다.
"모든 경우에 하나의 SOP" -실행 가능성이 손실됩니다.
13) 구현 로드맵 (4-6 주)
1. 네드. 1: SOP 템플릿, 린터 및 카탈로그 승인; 상위 10 개 시나리오를 선택하십시오.
2. 네드. 2: 릴리스/롤백/제공자/백업에 대한 SOP를 작성하십시오. 탁상 조종사.
3. 네드. 3: ChatOps 봇과 원격 측정 주석을 연결합니다. SOP와 경고를 연결하십시오.
4. 네드. 4: 분기 별 검토 일정; 신선도/성공률 지표를 입력하십시오.
5. 네드. 5-6: 중요한 운영의 90% 를 포함합니다. DR/보안 -SOP; 자동화 증거 수집.
14) 결론
SOP는 균일 한 품질 게이트, 세부 단계, 명시 적 역할 및 가역성 등 작업을 예측할 수 있고 검증 할 수 있습니다. 플레이 북, 정치인, SLO 및 자동화와 함께 운영은 신속한 반응, 최소한의 위험 및 이해할 수있는 책임과 같은 안정적인 생산 라인으로 전환됩니다.