امنیت، هویت، استقرار و تاب‌آوری · فصل ۹ — Resource، Provider، Cost و Organizational Failure · 129
Approval Bottleneck
failure را بعد از وقوع و به‌صورت موردی تحلیل می‌کند و هنوز detection، containment و repair path از قبل طراحی نشده است. موضوع جاری: «Approval Bottleneck». می‌تواند failure family «Approval Bottleneck» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
خلاصهٔ درس
failure را بعد از وقوع و به‌صورت موردی تحلیل می‌کند و هنوز detection، containment و repair path از قبل طراحی نشده است. موضوع جاری: «Approval Bottleneck».
می‌تواند failure family «Approval Bottleneck» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
خروجی این درس
می‌تواند failure family «Approval Bottleneck» را بازتولید/تشخیص دهد و detection، containment و recovery مناسب را تعیین کند.
1. صف تأیید را با خودِ کنترل اشتباه نگیرید
وجود review اجباری یا Code Owner به‌خودی‌خود failure نیست. Approval Bottleneck وقتی شکل می‌گیرد که change از نظر فنی آماده است اما topology تأیید، ظرفیت reviewer، ترتیب سری یا چرخه re-review بخش غالب lead time را می‌سازد. ابتدا باید ثابت کنیم تأخیر از approval flow می‌آید، نه از test ناقص، requirement مبهم یا risk hold موجه.
2. Policy topology را قبل از اندازه‌گیری سرعت رسم کنید
برای هر change سه چیز را جدا ثبت کنید: risk tier، gate واقعاً لازم و reviewerهای مجاز. اگر همه تغییرها—از dependency update کم‌ریسک تا access-control پرریسک—به یک specialist واحد بروند، مسئله ممکن است topology باشد نه «کند بودن آدم‌ها». policy authority باید از رفتار اتفاقی تیم جدا بماند.
3. Queue age و review latency دو متریک متفاوت‌اند
queue_age زمان انتظار change پیش از شروع review است؛ review_latency زمان از شروع review تا پاسخ معتبر است. صف طولانی با review سریع می‌تواند کمبود ظرفیت را نشان دهد. صف کوتاه با چند دور طولانی می‌تواند rework یا re-review churn باشد. ترکیب این دو از برچسب‌گذاری عجولانه جلوگیری می‌کند.
4. Blocked lead time را از total lead time جدا کنید
Total lead time شامل coding، CI، انتظار محصول، review و deploy است. برای این failure باید سهم approval-related wait را جدا کنیم. اگر change بیشتر زمانش را به‌خاطر test failure یا evidence ناقص متوقف بوده، حتی یک reviewer کم‌ظرفیت هم علت غالب نیست. record باید contribution هر blocker را قابل ممیزی نگه دارد.
5. Reviewer capacity فقط تعداد اسم‌ها نیست
eligible_reviewer_count، availability واقعی، skill boundary و authorized substitution باید با هم دیده شوند. پنج نفر در تیم اگر فقط یک نفر مجاز به review access-control باشد، ظرفیت high-risk هنوز یک است. برعکس، یک pool مجاز برای low/medium risk می‌تواند specialist را برای مواردی که واقعاً به او نیاز دارند آزاد کند.
6. Serial approval هزینه صف را ضرب می‌کند
اگر چند gate مستقل به‌صورت سری اجرا شوند، زمان انتظار جمع می‌شود حتی وقتی هر reviewer جداگانه سریع است. قبل از حذف gate بپرسید آیا می‌توان reviewهای مستقل را موازی کرد، evidence خودکار را زودتر تولید کرد، یا risk tier را به مسیر مناسب فرستاد. هدف حفظ control outcome با topology کم‌انتظارتر است.
7. Stale approval یک failure mode مستقل در همین مرز است
GitHub می‌تواند approval را پس از commit جدید stale کند. این رفتار ممکن است برای حفظ کنترل لازم باشد، اما اگر developer بعد از هر review تغییر کوچک بدهد و approval دوباره باطل شود، delay از scarcity به re_review_loop منتقل می‌شود. اضافه‌کردن reviewer دوم بدون کاهش churn ممکن است تقریباً هیچ اثری نداشته باشد.
8. Technical evidence ناقص را approval bottleneck صدا نزنید
اگر change test evidence، threat model، rollout plan یا acceptance evidence لازم را ندارد، reviewer حق دارد آن را نگه دارد. در fixture سوم، queue ظاهراً بلند است اما چند change با reviewer فوری هم merge-ready نیستند. classification باید TECHNICAL_EVIDENCE_GAP یا OPEN بماند، نه approval bottleneck.
9. Risk-tiered review یک bypass نیست
برای low-risk change می‌توان pool بزرگ‌تر، automation یا approval policy متفاوت داشت، به‌شرط اینکه authority آن را مجاز کرده باشد. این کار حذف governance نیست؛ mapping ریسک به control متناسب است. high-risk specialist gate می‌تواند دست‌نخورده بماند در حالی که routine changes از صف او خارج می‌شوند.
10. Authorized alternative باید صریح باشد
هر recovery گزینه باید یکی از این پشتوانه‌ها را داشته باشد: reviewer pool مجاز، substitute مجاز، automation eligibility، escalation path یا policy exception ثبت‌شده. «فعلاً merge کنیم» recovery نیست. اگر authority برای alternative مشخص نیست، تصمیم DEFER یا ESCALATE است و UNKNOWN باید حفظ شود.
11. Containment، recovery و closure سه مرحله جدا هستند
متوقف‌کردن intake کم‌ریسک به صف specialist می‌تواند containment باشد. اضافه‌کردن pool مجاز یا موازی‌سازی review recovery است. closure فقط وقتی قوی است که queue age و blocked lead time کم شوند، re-review loop کنترل شود و همان control outcome همچنان برقرار بماند. یک merge موفق به‌تنهایی closure نیست.
12. Approval Flow Bottleneck Diagnosis & Recovery Record v1
Record حداقل change_risk، required_gate، eligible_reviewer_count، queue_age، review_latency، blocked_lead_time، reviewer_availability، serial_steps، re_review_count، technical_evidence_complete، authorized_substitute، automation_eligibility، escalation_path، control_preserved، closure_probe و residual_governance_risk را ثبت می‌کند. هر claim باید OBSERVED، AUTHORITY، INFERRED یا UNKNOWN باشد.
13. Classification را از evidence بسازید
HEALTHY_CONTROL_FLOW یعنی control لازم است و queue/rework متناسب است. APPROVAL_CAPACITY_BOTTLENECK یعنی technical evidence کامل است ولی ظرفیت/topology approval عامل غالب wait است. RE_REVIEW_CHURN یعنی reviewer capacity کافی است اما stale invalidation و تغییرهای تکراری delay را می‌سازند. TECHNICAL_EVIDENCE_GAP یعنی approval symptom است نه علت. اگر policy یا capacity معلوم نیست، OPEN بمانید.
14. Lab: هشت fixture و 64 assertion
Lab هشت حالت دارد: specialist serial overload، high-risk hold موجه، technical evidence ناقص، reviewer pool سالم، stale-approval churn، reviewer unavailable با substitute مجاز، low-risk automation candidate، و policy topology نامعلوم. برای هر case هشت خروجی قطعی سنجیده می‌شود: gate state، capacity state، queue state، re-review state، technical-evidence state، dominant blocker، recovery path و decision؛ در مجموع 64 assertion.
15. Exit checklist و انتقال
قبل از خروج، policy-required gate را از عادت تیم جدا کنید؛ queue age و review latency را مستقل اندازه بگیرید؛ blocked lead time را به blockerها نسبت دهید؛ reviewer eligibility و availability را ثبت کنید؛ technical evidence را قبل از blame کردن approval بررسی کنید؛ alternative فقط با authority معتبر انتخاب کنید؛ و closure را با lead-time improvement همراه با control_preserved=true اثبات کنید. سپس transfer fixture را از صفر بازسازی کنید: reviewer دوم برای medium-risk اضافه شده، اما هر commit جدید approval قبلی را stale می‌کند. تشخیص دهید scarcity هنوز علت غالب است یا re-review churn جای آن را گرفته است.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
Why is a required approval not automatically an Approval Bottleneck?
Q2 application
All technical checks are green, eight low-risk changes and three medium-risk changes wait behind the same specialist needed for one high-risk change. What should be tested first?
Q3 diagnosis
Reviewer capacity is sufficient, but each code-modifying commit invalidates prior approval. What is the likely dominant blocker?
Q4 decision
When is automation a valid recovery path for approval delay?
Q5 transfer
A second reviewer is added but lead time barely improves because approvals repeatedly become stale. What should the record conclude?
ملاک‌های ارزیابی (rubric)
A sufficient response identifies the required approval topology, separates queue age from review latency, attributes blocked lead time to approval versus technical-evidence gaps, records authorized reviewer capacity and re-review behavior, preserves UNKNOWN state, and selects only authorized recovery paths. Closure requires lower approval-related blocked time while the declared control remains preserved. Transfer must be rebuilt from the changed stale-approval evidence rather than copying the original scarcity diagnosis.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Implement the bounded evaluator in starter.py for the eight supplied synthetic approval-flow cases. No network calls are needed. Keep required policy gate, technical readiness, reviewer eligibility/availability, queue age, review latency, serial steps, re-review count, and authorized alternatives as separate evidence dimensions. A long queue alone is never enough to classify an approval bottleneck. Preserve OPEN state when policy authority is unknown, and do not treat a faster path as closure unless the required control is preserved.
Run python run_checks.py to verify fixture shape before implementing the evaluator.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)