# چرا نوبت آن‌کال بیشتر از معماری اولیه به سیستم شکل می‌دهد

- Published: 2026-09-30
- Reading time: 8 min
- Tags: Operations, Architecture, On-call

هر سیستمی که «برای مقیاس طراحی شده» با سیستمی که «برای بیدار شدن نیمه‌شب طراحی شده» یکی نیست. تفاوت را کسی می‌فهمد که خودش گوشی را برمی‌دارد.

### دو جور طراحی که شبیه هم به نظر می‌رسند

هر سند معماری‌ای که دیده‌ایم دربارهٔ مقیاس حرف می‌زند: چند تا سرویس، چه پایگاه‌داده‌ای، صف پیام کجا. کمتر سندی هست که دربارهٔ ساعت دو نیمه‌شب حرف بزند. این دو سؤال جواب یکسانی ندارند. سیستمی که برای مقیاس خوب طراحی شده ممکن است زیر یک خرابی جزئی، ساعت‌ها بی‌سروصدا کج‌رفتار کند و هیچ‌کس نفهمد — دقیقاً چون طراحش هیچ‌وقت از خودش نپرسیده «وقتی این بخش بمیرد، کسی که نصفه‌شب جواب می‌دهد چه چیزی جلوی چشمش دارد؟» سؤال دوم تنها زمانی به معماری راه پیدا می‌کند که تیمی که سیستم را می‌سازد، همان تیمی باشد که نوبت آن‌کال را هم می‌گیرد. وقتی این دو تیم جدا هستند — یکی می‌سازد، یکی دیگر صبح‌ها تماس دریافت می‌کند — انگیزهٔ طراحی برای قابل‌عیب‌یابی‌بودن به آرامی از بین می‌رود، چون هزینهٔ نبودنش را کسی می‌دهد که در جلسهٔ طراحی حضور نداشته.

### چه چیزی سزاوار یک صفحه است، چه چیزی سزاوار یک داشبورد

هر متریکی که جمع می‌کنید ارزش نمایش دارد، اما هر متریکی ارزش بیدار کردن کسی را ندارد. تفکیک این دو یکی از مهم‌ترین تصمیم‌های معماری است که معمولاً بعد از ساخت سیستم و نه قبلش گرفته می‌شود — و این خودش نشانهٔ یک اشتباه است. قاعدهٔ ساده‌ای که به کار می‌آید این است: یک هشدار (صفحه/پیج) فقط برای چیزی صادر می‌شود که (۱) کاربر واقعی همین الان دارد اثرش را حس می‌کند، (۲) اقدام انسانی همین الان تفاوتی ایجاد می‌کند، و (۳) صبح‌شدن آن را حل نمی‌کند. هرچیزی که این سه شرط را ندارد باید برود روی یک داشبورد، نه توی جیب کسی که خواب است. یک عدد که «بد به نظر می‌رسد» ولی هیچ اقدامی برایش وجود ندارد، فقط خستگیِ هشدار می‌سازد — و خستگیِ هشدار دقیقاً همان چیزی است که هشدارِ واقعی را هم بی‌اثر می‌کند. نتیجهٔ عملی این است که فهرست هشدارهایی که واقعاً کسی را بیدار می‌کنند باید کوتاه باشد و مرتب مرور شود. هر هشداری که سه بار پشت سر هم بدون اقدام واقعی بسته شده، یا باید حذف شود یا باید تبدیل به یک تیکت روز کاری بعد شود، نه یک زنگ نیمه‌شب.

### ران‌بوک بخشی از معماری است، نه یک ضمیمه

یک تصمیم معماری که هیچ مسیر بازیابی مستندی ندارد، تصمیمی ناتمام است. ران‌بوک را معمولاً بعد از ساخت سیستم و اغلب بعد از اولین حادثه می‌نویسند — که یعنی درست همان زمانی که کمترین فایده را دارد. اگر معماری از اول با این پرسش نوشته شود که «وقتی این بخش خراب شود، مرحلهٔ اول تشخیص چیست، و مرحلهٔ اول اقدام چیست؟»، خودِ سیستم ساده‌تر می‌شود؛ چون بخشی که توضیح‌دادنش سخت است معمولاً همان بخشی است که طراحی‌اش هم ضعیف بوده. ران‌بوک خوب دستورالعمل گام‌به‌گام نیست، فهرست تصمیم است: این علامت یعنی این احتمال، این احتمال یعنی این بررسی، این بررسی یعنی این اقدام. اگر ران‌بوک به شکل یک درخت تصمیم نوشته نشود، کسی که ساعت دو نیمه‌شب و بدون زمینه آن را می‌خواند فقط یک متن طولانی جلوی خودش می‌بیند.

### چرا سازنده باید گوشی را هم بردارد

وقتی همان مهندسی که یک سرویس زمان‌بندی‌شده یا یک ایندکس یا یک صف را طراحی کرده، همان کسی است که ممکن است ساعت سه بامداد دربارهٔ آن تماس بگیرد، رفتارش در زمان طراحی تغییر می‌کند — نه از روی ترس، بلکه چون قابلیت مشاهده و بازیابی برایش تجریدی نیست، شخصی است. تفاوت بین «این کوئری کمی کند است» و «این کوئری من را بیدار می‌کند» تفاوتی است که فقط کسی که هر دو را تجربه کرده حس می‌کند. این همان دلیلی است که تیم کوچک و عمیق بر تیم بزرگ و لایه‌لایه برتری دارد: در تیم بزرگ، مسئولیت پخش می‌شود تا جایی که هیچ‌کس مالک کامل یک تصمیم نیست، و در نتیجه هیچ‌کس هزینهٔ کامل آن تصمیم را هم حس نمی‌کند. مالکیت کامل — از معماری تا استقرار تا نوبت آن‌کال — تنها راهی است که هزینهٔ واقعی یک انتخاب طراحی به‌موقع به گوش کسی برسد که می‌تواند آن را عوض کند.

### طراحی برای تخریب آرام، نه فقط برای در دسترس بودن

بیشتر بحث‌های معماری حول این می‌چرخد که سیستم چگونه «بالا» بماند. سؤال کم‌طرح‌شده‌تر این است که وقتی یک بخش از سیستم واقعاً از کار بیفتد، بقیهٔ سیستم چه شکلی می‌شود. یک سرویس توصیه که قطع می‌شود باید صفحهٔ اصلی را بدون توصیه نشان دهد، نه این‌که کل صفحه خطا بدهد. یک صف پیام که پر می‌شود باید پیام‌های کم‌اهمیت را دراپ کند، نه این‌که نویسندهٔ پیام هم قفل شود. تخریب آرام یک ویژگی نیست که بشود بعداً اضافه کرد؛ باید از روز اول در مرز هر وابستگی خارجی طراحی شود: این وابستگی وقتی جواب نمی‌دهد، رفتار پیش‌فرض چیست؟ اگر جواب این سؤال «نمی‌دانم، فرض بر این است که همیشه جواب می‌دهد» باشد، آن مرز، مرز شکست کامل سیستم است — و هر مرز شکست کامل، به‌معنای یک هشدار نیمه‌شب تضمین‌شده است. هدف این نیست که هیچ‌وقت هشدار نگیرید؛ هدف این است که هشدار فقط برای چیزی برود که واقعاً تخریب آرام برایش ممکن نبوده.

### نوبت آن‌کال خودش یک حلقهٔ بازخورد است

فهرست کسانی که هر هفته زنگ می‌خورند، یکی از صادق‌ترین متریک‌های سلامت معماری است — صادق‌تر از هر داشبورد. اگر یک نفر مشخص، هفته‌به‌هفته، برای یک کلاس مشخص از خرابی بیدار می‌شود، مشکل آن فرد نیست؛ مشکل آن بخش از سیستم است که هنوز طراحی‌اش تمام نشده. راه‌حل رایج و اشتباه این است که نفر دوم را به چرخهٔ آن‌کال اضافه کنیم تا فشار پخش شود. این فقط هزینهٔ انسانی مشکل را پخش می‌کند، خودِ مشکل را حل نمی‌کند. راه‌حل درست این است که با هر تماس تکراری مثل یک بازخورد معماری رفتار کنیم: چرا این اتفاق دوباره افتاد، و چرا رفع دفعهٔ قبل کافی نبود؟ تیمی که نوبت آن‌کال را جدی می‌گیرد، فهرست تماس‌های تکراری را هر چند هفته مرور می‌کند، نه فقط برای اندازه‌گیری «چند بار بیدار شدیم»، بلکه برای پیدا کردن آن یک تصمیم معماری که هنوز عقب افتاده. وقتی این مرور جدی گرفته نشود، چرخهٔ آن‌کال فقط ثبت می‌کند که سیستم چقدر شکننده است، بدون این‌که آن شکنندگی هرگز درمان شود.

### شعاع انفجار: مرزهایی که از قبل باید کشیده شوند

هر تصمیم معماری یک شعاع انفجار دارد: وقتی این بخش خراب شود، چه چیز دیگری با آن پایین می‌آید؟ سؤالی که معمولاً دیر پرسیده می‌شود این است که آیا این شعاع از قبل، عمداً، محدود شده یا فقط اتفاقی کوچک مانده. یک صف پیام مشترک بین چند ویژگی نامرتبط، یک نمونهٔ کلاسیک است: روزی که یکی از آن ویژگی‌ها رفتار غیرعادی نشان دهد و صف را پر کند، بقیهٔ ویژگی‌هایی که هیچ ربطی به مشکل ندارند هم متوقف می‌شوند — نه چون طراحی اشتباه بوده، بلکه چون هیچ‌کس از اول نپرسیده «اگر این یکی خراب شود، چه چیزهای دیگری با آن سقوط می‌کنند؟» کشیدن این مرزها هزینهٔ اولیه دارد: صف‌های جداگانه، پایگاه‌دادهٔ جداگانه یا محدودیت نرخ جداگانه برای هر ویژگی معمولاً کندتر و پیچیده‌تر از یک منبع مشترک است. اما این هزینه یک‌بار پرداخت می‌شود در زمان طراحی؛ هزینهٔ نکشیدن این مرزها بارها پرداخت می‌شود، هر بار که یک خرابی کوچک در یک گوشهٔ سیستم، نیمی از محصول را با خودش می‌برد. سؤال «شعاع انفجار این تصمیم چقدر است؟» باید همان‌قدر جدی از سؤال «این تصمیم چقدر مقیاس‌پذیر است؟» پرسیده شود، و معمولاً پرسیده نمی‌شود چون جوابش لحظهٔ طراحی جذاب نیست — فقط لحظهٔ حادثه جذاب می‌شود.

### یک چک‌لیست قبل از این‌که کد نوشته شود

پیش از تأیید هر معماری جدید، این پرسش‌ها را از خودتان بپرسید، نه بعد از حادثهٔ اول: اگر این بخش شکست بخورد، سیگنالی که به کسی می‌رسد چیست، و آن سیگنال کافی است که مسیر بعدی را نشان دهد؟ آیا این هشدار واقعاً نیاز به اقدام انسانی نیمه‌شب دارد، یا صبح هم قابل حل است؟ ران‌بوکش را می‌شود در سه دقیقه، نیمه‌خواب، خواند و فهمید؟ کسی که این را می‌سازد، همان کسی است که وقتی زنگ بخورد جواب می‌دهد؟ اگر جواب هر کدام «نمی‌دانم» است، معماری هنوز تمام نشده — فقط کدش تمام شده.

### این تصمیم باید در برآورد زمان و دامنه هم دیده شود

وقتی زمان‌بندی یک پروژه را با کارفرما مشخص می‌کنیم، هزینهٔ ران‌بوک‌نویسی، تعریف آستانهٔ هشدار و طراحی تخریب آرام معمولاً در برآورد اولیه دیده نمی‌شود، چون این‌ها «ویژگی» نیستند که کارفرما مستقیم درخواستشان کرده. اما این‌ها همان چیزهایی هستند که فرق بین سیستمی که سال دوم هم قابل‌نگه‌داری است و سیستمی که سال دوم تبدیل به یک منبع دائمی استرس می‌شود را می‌سازند. صادق‌بودن دربارهٔ این هزینه در همان لحظه‌ای که دامنهٔ کار مشخص می‌شود، ارزانتر از پنهان‌کردنش تا روزی است که اولین هشدار نیمه‌شب زنگ بزند.


---

Source: https://larsima.com/insights/on-call-shapes-architecture
Organisation: LARSIMA (شرکت فن‌آوران توسعه لار سیما), registered in Iran, no. 318515, since 2007-12-02.