فرض کن صاحب یک بانک هستی. مشتری فقط نمیخواهد «پول جابهجا شود». میخواهد باجه شلوغ نباشد، سیستم وسط روز نخوابد، و اگر خوابید، کمتر از چند دقیقه برگردد. طراحی از همینجا شروع میشود: اول بفهم سیستم چه میکند، بعد بفهم آن کار چقدر خوب باید انجام شود.
بیشتر معماری را دومی تعیین میکند. «پیام بفرست» یک قابلیت است. «۹۹٪ پیامها زیر ۲۰۰ میلیثانیه برسند» یک کیفیت است. اگر کیفیت را نپرسی، جعبه و فلش میکشی برای مسئلهای که هنوز اندازه ندارد.
دو جور سؤال
در جلسه طراحی، سؤالها دو خانوادهاند. اگر قاطیشان کنی، یا محصولی میسازی که کار میکند ولی غیرقابلاستفاده است، یا عددی میگذاری که به هیچ قابلیت واقعی وصل نیست.
سه اسم برای اندازهگیری کیفیت
برگرد به بانک. یک نفر با کرونومتر زمان انتظار را مینویسد. تیم یک هدف داخلی میگذارد: «۹۹٪ مشتریها زیر پنج دقیقه». بعد در قرارداد با شرکت بزرگ مینویسند اگر این قول شکست، جریمه. این سه نقش اسم دارند.
به p99 دقت کن. میانگین دروغ میگوید. اگر میانگین 80ms باشد ولی p99 برابر 2s، یعنی از هر ۱۰۰ درخواست یکی دو ثانیه طول میکشد — و کاربر پرمصرف تو دقیقاً همان را میبیند.
Availability: هر ۹ چقدر میارزد؟
وقتی میگویند سیستم «سه تا ۹» دارد، یعنی چند ساعت در سال اجازه خوابیدن دارد. اسم این خوابیدن Downtime است. هر ۹ اضافه، هزینه را چند برابر میکند — Failover خودکار، ماشین اضافه، تیم کشیک.
| سطح | Downtime در سال | واقعیت |
|---|---|---|
| 99% | ~۳.۷ روز | برای اغلب محصولات قابل قبول نیست |
| 99.9% | ~۸.۸ ساعت | استاندارد رایج سرویسهای وب |
| 99.99% | ~۵۳ دقیقه | نیازمند Failover خودکار و Redundancy جدی |
| 99.999% | ~۵.۳ دقیقه | بسیار گران؛ فقط زیرساختهای حیاتی |
به زبان ساده
اول بفهم سیستم چه میکند، بعد بفهم آن کار چقدر خوب باید انجام شود. SLI عدد است، SLO هدف تیم، SLA قول قراردادی.
مثال واقعی
در بانک یک نفر با کرونومتر زمان باجه را مینویسد. تیم میگوید ۹۹٪ زیر پنج دقیقه؛ قرارداد همان را با جریمه مینویسد.