Single-person Dependency

1. خرابی پنهان: سیستم تا وقتی فرد کلیدی حاضر است سبز می‌ماند

Single-person dependency وقتی شکل می‌گیرد که یک workflow حیاتی فقط با حضور یک نفر قابل انجام باشد: deployment، rollback، migration، credential operation، incident escalation یا final approval. این failure معمولاً در dashboard دیده نمی‌شود، چون سرویس تا وقتی primary در دسترس است عادی کار می‌کند. آزمون واقعی زمانی است که primary عمداً از تمرین حذف شود و ببینیم آیا workflow بدون او کامل می‌شود، safely escalate می‌شود یا متوقف می‌ماند.

2. مالکیت تخصصی با single point of failure یکی نیست

داشتن یک subject-matter expert بد نیست. مشکل وقتی است که دانش، authority، credential، runbook یا تجربه اجرایی طوری متمرکز شده باشد که نبود یک نفر recovery را متوقف کند. بنابراین سؤال درست «چند نفر اسمشان owner است؟» نیست؛ سؤال این است که «چند نفر می‌توانند با مجوز مستقل و evidence فعلی، workflow را واقعاً اجرا یا به مسیر امن دیگری escalate کنند؟»

3. Critical workflow را قبل از شمارش افراد تعریف کنید

ریسک را روی workflowهای مبهم مثل «backend» یا «production» نسنجید. واحد سنجش باید عملیاتی باشد: deploy service A، rotate rollback credential، restore database from failed migration یا approve critical module change. ممکن است یک تیم برای deploy پوشش خوب داشته باشد اما برای data repair هنوز فقط یک نفر داشته باشد. Record باید این مرز را صریح نگه دارد.

4. Backup اسمی با qualified backup متفاوت است

Backup فقط وقتی برای این درس «qualified» است که knowledge لازم، authorization مستقل، access فعلی، procedure قابل استفاده و evidence rehearsal داشته باشد. اگر همکار procedure را می‌داند ولی production access ندارد، qualified نیست. اگر access دارد اما rollback را هرگز اجرا نکرده و هیچ rehearsal یا safe-escalation evidence ندارد، qualification هنوز OPEN است. اسم در rota یا CODEOWNERS فقط routing evidence است، نه capability proof.

5. Independent access یک بعد جدا از دانش است

دانش و دسترسی را در یک ستون ادغام نکنید. کسی ممکن است migration playbook را خوب بفهمد ولی MFA device، break-glass path یا role لازم را نداشته باشد. برعکس، داشتن permission بدون دانش عملیاتی هم closure نیست. Record باید knowledge, independent_access و authority_boundary را مستقل نگه دارد تا repair دقیقاً روی gap واقعی انجام شود.

6. Runbook باید current و executable باشد

وجود فایل runbook کافی نیست. procedure باید با state فعلی سیستم هم‌خوان باشد، dependencyها و safety checks را نشان دهد و مسیر escalation را مشخص کند. Counterexample این درس runbookی است که هنوز به deployment step بازنشسته‌شده اشاره می‌کند؛ backup access دارد اما rehearsal به‌درستی fail می‌شود. این failure evidence ارزشمندتر از یک document checklist سبز است.

7. CODEOWNERS و rota فقط بخشی از evidence هستند

GitHub اجازه می‌دهد برای یک مسیر چند code owner تعریف شود و در صورت required review، approval یکی از ownerهای فهرست‌شده requirement را برآورده کند. این برای routing و reviewer redundancy مفید است، اما نشان نمی‌دهد هر owner production access، incident knowledge یا credential custody لازم را دارد. پس این سیگنال را به‌عنوان authority/configuration evidence ثبت کنید، نه closure proof.

8. Rotation، shadowing و backup escalation قابلیت را منتقل می‌کنند

راهنمای Google SRE on-call از rotation، documentation، shadow shift و backup escalation برای انتقال مسئولیت استفاده می‌کند. الگوی مهم این است که backup ابتدا کنار فرد باتجربه تمرین می‌کند، سپس primary می‌شود و مسیر escalation هنوز وجود دارد. این یک practice example است، نه نسبت اجباری نیروی انسانی. در Record، shadow/rotation evidence باید به workflow مشخص و تاریخ تمرین bind شود.

9. Rehearsal باید primary-absent باشد

اگر primary کنار backup نشسته و هر قدم را می‌گوید، ما knowledge transfer را تمرین کرده‌ایم اما independence را ثابت نکرده‌ایم. closure rehearsal باید primary را از execution path حذف کند. backup باید با access مستقل و runbook قابل ممیزی workflow را complete کند یا طبق مسیر تعریف‌شده correctly escalate کند. اگر escalation دوباره به همان primary ختم شود، dependency بسته نشده است.

10. Safe escalation می‌تواند outcome معتبر باشد

همه backupها لازم نیست عمیق‌ترین repair را به‌تنهایی انجام دهند. برای بعضی workflowها، outcome معتبر این است که backup incident را تشخیص دهد، blast radius را محدود کند و به یک تیم مستقل و authorized escalate کند. شرط مهم این است که escalation path خودش single-person dependency جدید نسازد و recovery time با نیاز workflow سازگار باشد. Record باید این distinction را آشکار نگه دارد.

11. Containment با closure فرق دارد

افزودن یک backup name، دادن temporary access یا نوشتن runbook می‌تواند containment باشد. closure فقط وقتی رخ می‌دهد که evidence مستقل نشان دهد critical workflow بدون primary قابل انجام یا safe escalation است. اگر rehearsal هنوز اجرا نشده، classification باید OPEN یا حداکثر REDUCED بماند. یک mitigation سبز، causal proof یا حذف residual risk نیست.

12. Key-person Dependency Resilience & Handoff Record v1

Record این درس حداقل این fieldها را نگه می‌دارد: critical workflow، primary owner، qualified backup count، independent access، credential/authority boundary، runbook current، shadow/rotation evidence، last rehearsal، primary-absent result، escalation path، recovery time، knowledge transfer، role coverage، residual gap و closure status. هر decisive claim باید به observation یا authority evidence trace شود؛ UNKNOWN را به fact تبدیل نکنید.

13. Classification: OPEN، REDUCED یا CLOSED

OPEN یعنی workflow هنوز روی primary متوقف می‌شود یا evidence کافی نداریم. REDUCED یعنی بخشی از gap repair شده اما یک branch، access boundary یا rehearsal gap باقی است. CLOSED یعنی برای همان bounded workflow حداقل یک backup authorized با procedure فعلی در primary-absent rehearsal workflow را کامل کرده یا به escalation مستقل و معتبر رسانده است. این classification جهانی نیست؛ به scope همان workflow محدود است.

14. Lab: هشت fixture و 64 assertion

Lab هشت سناریو دارد: primary-only، backup اسمی بدون access، access بدون knowledge، runbook stale با rehearsal fail، backup با safe escalation مستقل، backup با rehearsal کامل، دو backup qualified، و transfer fixture که در آن همه access و runbook دارند اما rare data-repair فقط نزد primary تجربه شده است. برای هر case هشت خروجی قطعی بررسی می‌شود: qualified backup count، access independence، runbook readiness، rehearsal result، workflow state، dependency classification، closure status و decision. مجموعاً 64 assertion اجرا می‌شود.

15. Exit checklist و انتقال

قبل از خروج، workflow را دقیق نام‌گذاری کنید؛ primary و backupها را از روی evidence ثبت کنید؛ knowledge و access را جدا بسنجید؛ current بودن runbook و آخرین rehearsal را بررسی کنید؛ primary-absent result و escalation path را ثبت کنید؛ containment را closure جا نزنید؛ residual gap را نگه دارید. سپس transfer fixture را از صفر ارزیابی کنید: سه نفر access و runbook فعلی دارند اما فقط primary rare data-repair را انجام داده است. برای همان branch تصمیم بگیرید CLOSED، REDUCED یا OPEN و evidence لازم برای تغییر state را بنویسید.