تست آمادگی عملیاتی؛ Capability تا Recovery

پاسخ کوتاه: تست آمادگی عملیاتی یا Operational Readiness Testing یک «آخرین تست» و مهر تضمین برای Production نیست. شکل قابل دفاع آن یک Operational Readiness Review Record است که برای یک Workload، Release، محیط و تغییر مشخص نشان می‌دهد قابلیت‌های deploy، observe، detect، respond، recover، rollback و support با Evidence تازه و تمرین‌شده چه وضعی دارند؛ چه چیزی هنوز Unknown است؛ کدام Exception با چه مالک و انقضایی پذیرفته شده؛ و چه کسی واقعاً اختیار تصمیم Rollout را دارد.

در این راهنما ORT و ORR را از UAT، تست عملکرد، تاب‌آوری و تصمیم انتشار جدا می‌کنیم؛ Scope و Critical Journey می‌سازیم؛ Evidence حضور را از Evidence اجرا تفکیک می‌کنیم؛ Deployment، Observability، On-call، Runbook، Backup/Restore، DR، rollback و Incident را تمرین می‌دهیم؛ و با یک آزمایش آفلاین فارسی نشان می‌دهیم چرا Dashboard سبز، Runbook موجود، Backup job موفق و نام On-call هنوز آمادگی تولید را اثبات نمی‌کنند.

ORT و ORR دقیقاً چیستند؟

ORT معمولاً به اجرای آزمون‌ها و تمرین‌های عملیاتی اشاره می‌کند؛ ORR فرایند بازبینی Scope، Capability، Evidence، Finding، Residual Risk و Action است. سازمان‌ها این واژه‌ها را یکسان به کار نمی‌برند، پس اصطلاح محلی را در Charter تعریف کنید. در این مقاله «آمادگی» یک Claim محدود است، نه وضعیت دائمی کل سازمان.

آماده برای کدام Production و کدام تغییر؟

Production یک محیط واحد و ثابت نیست. Region، tenant، segment، traffic policy، data class، dependency، feature flag و deployment mode می‌توانند متفاوت باشند. Launch محصول جدید، migration داده، تغییر schema، major dependency upgrade، افزایش traffic و hotfix یک Readiness profile ندارند. Claim باید Release/Build، Change class، target environment، rollout step و decision deadline را نام ببرد.

چرا «آخرین مرحله بعد از UAT» مدل غلطی است؟

Operational concern باید از Design و Planning وارد شود، چون برخی Gapها—نبود isolation، telemetry، rollback-compatible schema یا ownership—در شب انتشار ارزان حل نمی‌شوند. ORR می‌تواند در چند Gate تکرار شود: design readiness، pre-production rehearsal، rollout readiness و post-launch learning. UAT نیز مالک Business acceptance است، نه پیش‌شرط زمانی ثابت ORR؛ مرز آن در راهنمای تست پذیرش کاربر آمده است.

مرز ORR با تست‌ها و تصمیم‌های نزدیک

Artifact/Activity	پرسش مالک	چیزی که ORR تصاحب نمی‌کند
UAT	Journey کسب‌وکار برای Participantهای تعریف‌شده پذیرفتنی است؟	توان عملیات و Recovery
Performance/Capacity	Workload و Resource curve چه می‌گوید؟	On-call، Runbook و Incident command
Resilience test	در Failure mode تعریف‌شده چه رفتار/Recovery رخ می‌دهد؟	کل تصمیم عملیاتی
Security review	Threat/Control/Evidence و Finding امنیتی چیست؟	صدور نظر امنیتی توسط ORR
Test Summary	Evidence snapshot و ریسک تست چیست؟	مالکیت deployment/operations
Release decision	با فایده، ریسک و شواهد چه گزینه‌ای انتخاب می‌شود؟	اجرای capabilityهای عملیات
ORR	آیا قابلیت‌های لازم برای operate کردن Scope شواهد تازه دارند؟	تضمین Production بدون Incident

برای تصمیم نهایی Go/No-Go یا Rollout محدود، چارچوب کیفیت به‌اندازهٔ کافی خوب مالک trade-off و اختیار انتشار است. ORR یک ورودی تصمیم است؛ Reviewer لزوماً Release authority نیست.

منبع سؤال‌های ORR باید ریسک خود شما باشد

راهنمای رسمی AWS درباره Operational Readiness Reviews توضیح می‌دهد ORR آن‌ها از آموخته‌های Incident ساخته شده و باید با فرهنگ، ابزار و قواعد حاکمیتی سازمان تکمیل شود. پس Checklist ابری آماده فقط seed است. Incident، Near Miss، failure mode، support ticket، audit finding، migration history و dependency contract محلی باید Question و Guidance بسازند.

هر Question باید Intent، applicability، risk mechanism، acceptable evidence، owner و action در صورت Gap داشته باشد. سؤال مبهم «آیا Monitoring دارید؟» معمولاً پاسخ بله می‌گیرد؛ سؤال بهتر می‌پرسد: «کدام symptom برای Critical Journey CJ-۰۳، در چه window و threshold، از کدام telemetry، با چه data-quality guard و به کدام route صفحه می‌دهد و آخرین synthetic trigger چه زمانی Ack/Escalation شد؟»

قالب Operational Readiness Claim

ClaimID: ORC-021
Workload/Service/Release/Build/Config: pinned identities
Change: type, artifact, migration and feature flags
Target: environment/region/tenant/traffic/data scope
Critical journeys and harm floor: ...
Required capabilities: deploy/observe/respond/recover/rollback/support
Evidence profile and freshness: ...
Acceptance / exception policy: ...
Decision need, owner, authority and deadline: ...
Explicit exclusions / unknowns / expiry triggers: ...

هویت Workload و Release را Pin کنید

Service name کافی نیست. Repository/commit/artifact digest، container/image، infrastructure/config revision، schema/migration، dependency lock، secret/config reference، feature flags، routing policy و runbook version را ثبت کنید. اگر ORR روی Build A و Rollout روی Build B است، Evidence باید revalidation policy داشته باشد. Latest یا screenshot بی‌زمان هویت نیست.

Architecture و Dependency Map عملیاتی بسازید

Request/event/data flow را از ingress تا state و side effect ترسیم کنید. برای هر dependency، owner، contract/version، timeout، retry، idempotency، rate limit، quota، failure behavior، degradation، data classification، support route و maintenance window را نگه دارید. Dependency غیرقابل مشاهده یا بدون owner یک Unknown است، نه تیک سبز.

Critical Journey و Harm Floor

Operational readiness را به Journeyها وصل کنید: login، browse، checkout، callback، reconciliation، refund، support یا admin action. Start/end، actor/system role، precondition، state transition، success/partial/duplicate/timeout outcome و forbidden harm را تعریف کنید. Average dashboard ممکن است failure یک segment یا side effect مالی را پنهان کند.

Capability Matrix؛ Presence کافی نیست

Capability	Evidence ضعیف	Evidence قوی‌تر و محدود
Deploy	Pipeline وجود دارد	Artifact pinned در محیط نماینده deploy و verify شد
Observe	Dashboard سبز است	Signal مصنوعی از source تا query/alert ردیابی شد
Respond	On-call نام دارد	Page→Ack→Triage→Escalation در تمرین ثبت شد
Recover	Backup job موفق است	Restore، integrity و reconciliation تا RTO/RPO آزموده شد
Rollback	دکمه rollback هست	نسخه/Config/schema سازگار برگشت و صحت سنجیده شد
Support	Runbook موجود است	اپراتور هدف با دسترسی واقعیِ مجاز آن را اجرا کرد

قالب Capability Evidence Row

CapabilityID / version / applicability
Risk and critical journey
Owner / operator / escalation authority
Procedure or automation artifact digest
ExerciseID / environment / fixture / permissions
Expected observable outcome and oracle
Observed event/timestamps/evidence references
Verdict: PASS | FAIL | INCONCLUSIVE | BLOCKED | STALE
Finding / residual risk / action / due date
Freshness / expiry / retrigger conditions

Deployment evidence؛ از Artifact تا Verification

Source→Build→sign/scan→registry→promotion→deploy→runtime را با digest و actor/service identity ردیابی کنید. Precondition، approval/authorization، concurrency lock، config drift، migration order، timeout، partial failure، retry و idempotency لازم‌اند. «Pipeline سبز» بدون دانستن artifact، target و post-deploy oracle، آماده‌بودن deployment را ثابت نمی‌کند.

استقرار تدریجی و Blast Radius

Rollout unit، cohort/tenant/region/percentage، step duration، promotion authority، health/quality/business guardrail، stop trigger و maximum blast radius را تعریف کنید. Canary صرفاً ۵٪ traffic نیست؛ باید assignment، comparability، contamination، sample sufficiency و decision window روشن باشد. Testing in Production و Feature Flag در راهنمای Shift-Right امن مالک مستقل دارند.

راهنمای رسمی Azure برای Safe Deployment بر تغییرهای کوچک، تدریجی، quality-gated و progressive exposure برای routine و emergency change تأکید می‌کند. این guidance مخصوص چارچوب Azure است؛ نوع rollout، threshold و مجوز release شما باید از Workload و risk محلی بیاید.

Rollback را از Roll-forward جدا کنید

Rollback ممکن است برای code ممکن ولی برای schema/data/side effect ناممکن یا زیان‌بار باشد. Compatibility window، expand/contract migration، old/new reader-writer، config revert، cache، queue، irreversible action و reconciliation را مشخص کنید. گزینه‌ها می‌توانند stop، disable flag، traffic shift، compensate یا roll-forward باشند. «یک دکمه داریم» evidence نیست.

قالب Deployment/Rollback Rehearsal

ExerciseID / release / target / topology
Artifact/config/schema before→after identities
Rollout steps, cohorts, dwell and promotion gates
Injected stop condition and authorized trigger
Rollback/disable/traffic-shift procedure
Data and side-effect compatibility checks
Detection / decision / action / recovery timestamps
Post-action behavior, state and reconciliation oracle
Unexpected effects / evidence gaps / correction

Observability یعنی پاسخ‌گویی به سؤال عملیاتی

Metric/log/trace فقط داده‌اند. برای هر critical symptom مشخص کنید کدام signal، source، producer version، dimensions، unit، aggregation، window، missing/late policy، retention و access وجود دارد. Dashboard باید service/region/version/cohort را تفکیک و از high-cardinality/PII leakage جلوگیری کند. Telemetry gap باید Verdict خود را خراب کند، نه اینکه به «no issue» تعبیر شود.

Alert را از source تا انسان تمرین دهید

یک synthetic condition امن ایجاد کنید و Signal→Evaluation→Alert→Route→Page→Ack→Triage→Escalation→Resolution را ردیابی کنید. threshold، duration، dedup/grouping، silence/inhibition، maintenance mode، notification provider، fallback route و timezone coverage را ثبت کنید. Test notification که business condition را فعال نمی‌کند فقط بخشی از مسیر را می‌سنجد.

SLI/SLO و Error Budget را با ORR خلط نکنید

SLI باید event population، good/valid events، denominator، window، source و missing-data policy داشته باشد. SLO ورودی risk/rollout است، اما SLO سبز آمادگی Runbook، Restore یا On-call را ثابت نمی‌کند. Error budget نیز مجوز خودکار انتشار نیست؛ policy و decision authority جدا لازم‌اند.

Runbook را اجرا کنید، نه فقط باز کنید

Runbook باید Trigger، scope، prerequisites، access، safe commands، expected output، stop/escalation، rollback/compensation، evidence capture، owner، version و last exercise داشته باشد. اپراتور هدف در محیط مجاز باید بدون دانش پنهان نویسنده آن را اجرا کند. لینک سالم و متن تازه هنوز command safety یا outcome را اثبات نمی‌کند.

On-call یک نام در فایل نیست

Schedule coverage، timezone، handoff، primary/secondary، contact route، acknowledgment objective، escalation، decision rights، access، fatigue guardrail و backup capacity را تعریف کنید. Readiness نباید بر فداکاری فردی یا پاسخ همیشگی تضمین‌نشده بنا شود. تمرین باید سیستم را بسنجد، نه افراد را امتیازدهی کند؛ دادهٔ شخصی و performance management مسیر جدا دارند.

Incident roles و اختیار تصمیم

Incident commander، operations lead، communications، subject expert، scribe و business authority می‌توانند نقش‌های جدا باشند. Severity declaration، traffic stop، data freeze، rollback، customer communication و closure چه کسی را لازم دارد؟ Role باید با person mapping و alternate همراه باشد؛ عنوان شغلی به‌تنهایی اختیار قابل استفاده نمی‌سازد.

Incident Exercise را قابل مشاهده طراحی کنید

Scenario، hypothesis، injected fault/symptom، safety boundary، abort authority، expected detection، communication inject، evidence capture و cleanup را تعریف کنید. Detection، acknowledgment، diagnosis، decision، mitigation، recovery و verification زمان‌های جدا هستند. GameDay بدون Oracle یا با جواب لو‌رفته بیشتر walkthrough است؛ باز هم مفید، اما Verdict متفاوت دارد.

Backup Success با Recovery فرق دارد

Backup job=SUCCESS فقط می‌گوید job طبق status خودش پایان یافته است. Restore point، object count، checksum، encryption/key access، retention/immutability، dependency order، schema/app compatibility، restore environment، integrity، business invariants و reconciliation باید آزموده شوند. RPO مربوط به میزان data loss تحمل‌پذیر و RTO مربوط به زمان بازیابی است؛ هیچ‌کدام از یک job سبز استخراج نمی‌شوند.

قالب Restore and Reconciliation Exercise

RestoreExerciseID / backup-set digest / cutoff
Source/data/schema/key/config identities
Target isolation and authorization
RPO/RTO objective and measurement boundaries
Restore order, commands, owner and stop rules
Counts/checksums/invariants/relationship oracles
Late/duplicate/missing/reordered event handling
Application compatibility and critical journeys
Reconciliation / discrepancy / disposition
Actual RPO/RTO / verdict / residual risk / expiry

DR، HA و Failover یک چیز نیستند

High Availability کاهش disruption در failureهای مشخص است؛ Failover تغییر active path یا role؛ Disaster Recovery بازگرداندن capability پس از disruption شدید با site/data/processهای تعریف‌شده. خودکاربودن failover، بدون split-brain، consistency، dependency، capacity، failback و reconciliation evidence، «بدون اختلال» را ثابت نمی‌کند. تست عمیق Failure mode و Recovery در راهنمای تست تاب‌آوری مالک مستقل دارد.

Capacity evidence را به Workload متصل کنید

Traffic forecast، journey mix، payload/data volume، burst، retry amplification، dependency quota و headroom را ثبت کنید. Average CPU یا concurrent users به‌تنهایی capacity نیست. Workload×Resource curve، Goodput، saturation و Capacity Frontier در راهنمای تست مقیاس‌پذیری مالک مستقل‌اند؛ ORR فقط Evidence تازه و تناسب آن با rollout را ارجاع می‌دهد.

Data migration و Cutover مسیر جدا دارند

Source snapshot، mapping، transform، batch/CDC boundary، dual-write، freeze، reconciliation، exception queue، cutover و rollback باید plan/evidence خود را داشته باشند. ORR بررسی می‌کند owner، trigger، status visibility و operational procedure آماده‌اند؛ صحت عمیق migration در راهنمای تست مهاجرت داده پوشش داده شده است.

Security و دسترسی عملیاتی

Operator/automation identity، least privilege، break-glass، approval، credential rotation، audit trail، session timeout و revocation را تمرین کنید. دسترسی بیش از حد readiness نیست؛ دسترسی ناکافی در Incident نیز Gap است. ORR وضعیت و Evidence review امنیتی را حمل می‌کند، اما vulnerability scan یا checkbox نمی‌تواند Security approval عمومی صادر کند.

Support، Ticket و Customer Communication

Support intake، categorization، severity، known issue، escalation، status-page authority، message template، language/accessibility، privacy review و correction را تعریف کنید. Customer-facing ETA را از technical estimate جدا کنید و fact/unknown/action را مخلوط نکنید. Channel موجود به معنی route آزموده‌شده یا تیم آموزش‌دیده نیست.

Evidence freshness و Change impact

Evidence باید observed_at، valid_for، source، artifact/config، environment و expiry داشته باشد. تغییر code/config/schema/dependency/traffic/topology/owner/tool/runbook یا policy می‌تواند آن را Stale کند. هر Capability یک change-trigger map می‌خواهد؛ «ماه قبل پاس شد» بدون comparability جواب نیست.

Finding، Gap و Unknown را جدا کنید

Finding یعنی Evidence با معیار نمی‌خواند؛ Gap یعنی capability/evidence لازم موجود نیست؛ Unknown یعنی پاسخ به‌دلیل داده یا Scope ناکافی معلوم نیست؛ Not-applicable دلیل تأییدشده می‌خواهد. همه را با risk mechanism، affected journey، likelihood/impact rationale، owner، action و due date ثبت کنید. Unknown را سبز یا صفر نکنید.

Exception، Waiver و Risk Acceptance

Exception مجوز دائمی حذف Control نیست. Requirement، gap، rationale، affected scope، risk owner، compensating control، rollout restriction، monitoring، stop condition، expiry، remediation و re-review را ثبت کنید. Reviewer می‌تواند Finding بسازد؛ پذیرش residual risk فقط با authority تعریف‌شده معتبر است.

قالب Exception Record

ExceptionID / requirement / finding
Affected workload/release/environment/journey
Risk mechanism and evidence/unknowns
Requested option and rejected alternatives
Compensating controls and validation
Rollout cap / monitoring / stop / rollback
Risk owner / approving authority / dissent
Effective time / expiry / remediation owner+due
Review trigger / closure evidence / correction

Verdict لایه‌ای؛ یک چراغ سبز کافی نیست

برای WORKLOAD، DEPENDENCY، DEPLOYMENT، OBSERVABILITY، RESPONSE، RECOVERY، DATA، ACCESS، SUPPORT و EVIDENCE verdict مستقل PASS/FAIL/INCONCLUSIVE/BLOCKED/STALE/NOT-APPLICABLE داشته باشید. Claim کلی فقط از rule اعلام‌شده ساخته شود. یک Critical gap ممکن است HOLD بدهد؛ ده مورد Low لزوماً همان معنا را ندارند. Rule را پس از دیدن نتیجه تغییر ندهید.

Decision Record به‌جای امضای مبهم

Optionها می‌توانند full rollout، محدودسازی cohort، shadow/dark launch، delay، feature disable، manual support، roll-forward preparation یا cancel باشند. Decision باید evidence snapshot، residual risk، conditions، guardrail، stop/rollback، owners، time، expiry و review را نگه دارد. گزارش Summary و closure evidence در راهنمای گزارش خلاصه تست مرز مکمل است.

Checklist را زنده و سبک نگه دارید

فصل رسمی Google SRE درباره Launchهای قابل‌اعتماد می‌گوید checklist باید برای launch و زیرساخت سازمان تخصصی شود، سؤال‌ها concrete باشند و فهرست با تغییر سیستم‌ها مرتب curated شود؛ فرایند بیش از حد سنگین دور زده می‌شود. این تجربهٔ Google نه نسخهٔ universal است و نه تضمین launch شما؛ اصل قابل انتقال، intent‌محوری و نگهداری مداوم است.

Question usage، false assurance، action yield، incident/near-miss coverage، time-to-review و bypass reason را بازبینی کنید. سؤال بدون action یا evidence باید اصلاح/ادغام/حذف شود. اما حذف فقط برای کوتاه‌شدن، risk coverage را تضعیف می‌کند. Fast path باید شرط eligibility و sampling/audit داشته باشد.

آزمایش آفلاین فارسی: چهار تیک سبز

Fixture خیالی SYN-OPERATIONAL-READINESS-01 یک Checkout ساختگی دارد. Dashboard سبز، Runbook موجود، آخرین Backup job با status موفق و On-call نام‌گذاری شده است؛ Checker سطحی فوراً READY_FOR_PRODUCTION می‌دهد. اما Release/Build/config، dependency map، critical journey، alert route، deploy/rollback rehearsal، restore/integrity/reconciliation، incident exercise، authority، exception و freshness ثبت نشده‌اند.

داده‌های فارسی/ایرانی Fixture

Fixture از Order/PaymentAttempt/Callback/Ledger/Reconciliation کاملاً ساختگی استفاده می‌کند؛ IRR canonical و «تومان» فقط نمایش برچسب‌خورده است؛ رقم‌های فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ/Bidi، Instant UTC و نمایش Asia/Tehran/جلالی نمایشی دارد. timeout-before/after-fake-commit، retry، duplicate، late، reorder و fake-backup/restore در حافظه شبیه‌سازی می‌شوند. هیچ شبکه، Production، شرکت، اپراتور، مشتری، کاربر، سفارش، پرداخت، PSP، بانک، حساب، پول واقعی، PII، cookie، token یا credential وجود ندارد.

Validator مستقل و قابل تکرار

const sizes={identity:22,claim:20,workload:24,change:20,dependency:24,
 environment:20,deployment:30,observability:30,eventResponse:28,recovery:30,
 data:22,securityAccess:20,peopleAuthority:22,evidence:25,
 decisionException:24,lifecycle:22};
const controls=Object.entries(sizes).flatMap(([g,n])=>
 Array.from({length:n},(_,i)=>`${g}.${String(i+1).padStart(2,'0')}`));
if(controls.length!==383||new Set(controls).size!==383) throw Error('CONTROL_SET');

خروجی Validator چه بود؟

CONTROL_COUNT=383
SUPERFICIAL=READY_FOR_PRODUCTION
AUDIT=HOLD-383
INDEPENDENT_TARGET=real-production-organization-operator-or-customer:false:PASS
CORRECTED=READY_FOR_OPERATIONAL_READINESS_REVIEW-0

۳۸۳ کنترل در ۱۶ گروه با نام‌های group-qualified و assertion یکتایی ساخته شدند؛ عدد تکراری یا padding نیست. Pin شدن همهٔ فیلدهای مصنوعی فقط Record را آمادهٔ بازبینی می‌کند؛ آمادگی Production، نبود Incident، reliability/security/performance، صحت Backup واقعی، مهارت اپراتور، رضایت مشتری، انطباق، Go یا موفقیت کسب‌وکار را ثابت نمی‌کند.

Evidence Pack حداقلی ORR

Claim، Scope، Workload/Release/Change identities؛
architecture/dependency/critical-journey maps؛
Capability Matrix و evidence/freshness profile؛
deployment/rollback/alert/incident/restore exercise records؛
artifact/config/schema/tool/runbook digests؛
raw timestamped outputs، Oracle و reconciliation؛
Findings/Unknowns/Exceptions/Residual risks؛
layered verdict، Decision، Actions، Expiry و Correction.

۲۴ Anti-pattern رایج ORR

ORT فقط شب قبل از انتشار؛
UAT پاس مساوی operational readiness؛
Dashboard سبز مساوی سلامت کامل؛
Runbook موجود مساوی قابل اجرا؛
Backup success مساوی recoverability؛
Failover خودکار مساوی بدون disruption؛
On-call named مساوی response capability؛
Pipeline green بدون artifact identity؛
Rollback button بدون schema/data check؛
Canary درصدی بدون cohort/guardrail؛
Test alert به‌جای مسیر end-to-end؛
Unknown به‌عنوان Pass؛
Not-applicable بدون rationale؛
Screenshot بدون source/time/query؛
Evidence قدیمی برای Build جدید؛
Checklist عمومی vendor بدون تطبیق؛
هر Finding با severity بحرانی؛
Exception بی‌انقضا؛
Reviewer به‌عنوان release authority فرضی؛
فقط Go یا No-Go؛
تمرین با جواب از پیش لو‌رفته؛
رتبه‌بندی اپراتور در GameDay؛
پاک‌کردن تاریخچهٔ تصمیم؛
تضمین تجربهٔ بی‌نقص یا Incident صفر.

چک‌لیست ۲۲ موردی مالک ORR

Claim و decision need محدود است؟
Workload/Release/Build/config Pin شده؟
Change و rollout target روشن است؟
Critical Journey و Harm Floor داریم؟
Architecture/dependency owner map تازه است؟
Capabilityها applicability دارند؟
Presence از rehearsal جداست؟
Deployment artifact provenance کامل است؟
Progressive rollout و blast radius تعریف شده؟
Stop/promotion authority مشخص است؟
Rollback/roll-forward با data سازگار است؟
Telemetry source/quality/freshness معلوم است؟
Alert path end-to-end تمرین شده؟
Runbook توسط operator هدف اجرا شده؟
On-call coverage/escalation/access معتبر است؟
Incident roles و communication route روشن‌اند؟
Restore با integrity/reconciliation اجرا شده؟
RTO/RPO مرز اندازه‌گیری دارند؟
Security/support evidence owner دارد؟
Unknown و Exception پنهان نشده‌اند؟
Verdict و Decision authority جدا هستند؟
Expiry/change trigger/correction ثبت شده؟

Pilot سی‌روزه بدون Production واقعی

هفتهٔ اول Scope، role، Critical Journey، Capability Matrix و سه سؤال برگرفته از Near Missهای کاملاً خیالی بسازید. هفتهٔ دوم deployment/rollback و alert-route را در Runner محلی تمرین کنید. هفتهٔ سوم fake backup/restore/reconciliation و tabletop Incident را اجرا کنید. هفتهٔ چهارم Reviewer مستقل Evidence Pack را Replay، Unknown/Exceptionها را challenge و Checklist را version کند. اتصال به Production، account ابری، on-call واقعی، telemetry کارکنان یا customer data مجوز و طراحی ایمنی جدا می‌خواهد و در این Pilot نیست.

پس از Launch حلقه را نبندید

Rollout observation، Guardrail، ticket، incident، near miss، rollback و operator friction ورودی بازنگری ORR هستند. Finding جدید را به سؤال/راهنما/تمرین و مالک تبدیل کنید؛ صرفاً Checklist را طولانی نکنید. برای تبدیل Near Miss به Barrier/Action/Verification، راهنمای کالبدشکافی Near Miss مرز مستقل را پوشش می‌دهد.

جمع‌بندی اجرایی

آمادگی عملیاتی با سندهای موجود و چراغ‌های سبز ساخته نمی‌شود. Scope/Release/Change را Pin کنید، ریسک‌های واقعی را به سؤال تبدیل کنید، Capability را با exercise و Oracle بسنجید، deploy/observe/respond/recover/rollback را end-to-end ببینید، Evidence را تازه و قابل Replay نگه دارید، Unknown و Exception را آشکار کنید و Decision را به اختیار، شرط، stop، expiry و correction متصل کنید. نتیجهٔ حرفه‌ای «Production هرگز شکست نمی‌خورد» نیست؛ یک ادعای محدود و قابل بازبینی دربارهٔ توان عملیات است.

سؤالات متداول تست آمادگی عملیاتی

تست آمادگی عملیاتی چیست؟

مجموعه‌ای از review و exercise برای سنجش قابلیت operate کردن یک Workload/Release مشخص است: deployment، observability، response، recovery، rollback، access و support. خروجی باید Evidence، Gap/Unknown، residual risk و decision reference داشته باشد، نه فقط checklist امضاشده.

ORT چه زمانی انجام می‌شود؟

یک زمان ثابت ندارد. سؤال‌های عملیاتی از design شروع می‌شوند؛ Evidence در pre-production rehearsal و rollout تازه می‌شود؛ post-launch learning آن را اصلاح می‌کند. Risk، change class و capability تعیین می‌کنند کدام Gate و exercise لازم است، نه قاعدهٔ «همیشه بعد از UAT».

آیا Backup موفق یعنی سیستم Recoverable است؟

خیر. Restore point و key/config/schema باید در محیط امن بازیابی شوند؛ integrity، رابطه‌ها، business invariant، app compatibility و reconciliation سنجیده شوند؛ و RPO/RTO واقعی ثبت شود. موفقیت job فقط یک Signal از زنجیره است.

اگر یک مورد ORR پاس نشد، انتشار حتماً متوقف است؟

به rule و risk بستگی دارد. Finding بحرانی ممکن است HOLD بدهد؛ مورد دیگر می‌تواند با rollout محدود، compensating control و Exception زمان‌دار مدیریت شود. Reviewer شواهد را گزارش می‌کند و authority مجاز، با residual risk و شروط ثبت‌شده تصمیم می‌گیرد.

حداقل Operational Readiness Record چه دارد؟

Claim و Scope، Workload/Release/Change identities، Journey/dependency map، Capability Matrix، evidenceهای deploy/alert/incident/restore/rollback، Findings/Unknowns/Exceptions، verdictهای لایه‌ای، Decision reference، Action، owner، freshness، expiry و Correction.

تست پایداری

تست آمادگی عملیاتی؛ از Capability تا Recovery