Cost Ledger و Cost Allocation

1) مسئلهٔ واقعی: عدد ماهانه، Ledger نیست

داشتن یک عدد مثل «هزینهٔ پلتفرم این ماه ۱۶۵۰ واحد بود» برای تصمیم‌گیری کافی نیست. اگر ندانیم هر مبلغ از کدام خط منبع آمده، مربوط به چه دوره‌ای است، مستقیم است یا مشترک، چه کسی مالک آن است و با چه Driverی توزیع شده، عدد نهایی قابل بازتولید نیست. هدف این درس تبدیل «جمع هزینه» به یک Cost Ledger & Allocation Contract v1 است؛ یعنی هر تخصیص بتواند تا منبع و قاعدهٔ خودش عقب‌گرد کند.

2) مرز درس و خروجی قابل تحویل

خروجی این درس یک Ledger قابل ممیزی است، نه Pricing Floor، نه Invoice و نه قانون حسابداری. درس بعد، ARC-017، روی Markup/Margin و کف قیمت کار می‌کند. اینجا فقط می‌پرسیم: «این هزینه از کجا آمده، به چه دوره‌ای تعلق دارد، آیا مستقیم یا مشترک است، با چه قاعده‌ای تخصیص داده شده و چه Residueای باقی مانده؟»

3) Fact: Allocation فقط تقسیم یک Total نیست

FinOps Allocation تخصیص هزینه و مصرف را با Account، Tag، Label و Metadata توضیح می‌دهد تا گروه‌های مسئول هزینهٔ خود را بفهمند. همین منبع همچنین Direct Allocation را از Shared Cost جدا می‌کند. این Fact به ما اجازه نمی‌دهد هر هزینه‌ای را دلخواه تقسیم کنیم؛ فقط نشان می‌دهد Allocation باید به ساختار مسئولیت و Metadata متصل باشد.

4) Fact: Shared Cost چند Strategy دارد

هزینهٔ مشترک می‌تواند با روش‌های Fixed، Proportional یا Proxy Metric توزیع شود. انتخاب روش به خودی خود «عادلانه» بودن آن را ثابت نمی‌کند. Driver باید برای همان Pool، همان Period و همان Version قابل دفاع باشد. اگر Observability بر اساس Request Volume تخصیص داده شده، جایگزینی ناگهانی آن با Equal Split بدون Approval یک تغییر Policy است، نه یک محاسبهٔ ساده.

5) Ledger Grain را قبل از Allocation قفل کن

حداقل Grain این درس یک Source Line در یک Cost Period است. هر Entry باید شناسه، دوره، Source Line، Category، Effective Cost، Currency و Evidence Ref داشته باشد. بعد از آن، Direct/Shared بودن، Owner، Target، Driver و Adjustment اضافه می‌شوند. اگر Grain مبهم باشد، Reconciliation هم مبهم می‌شود؛ چون معلوم نیست جمع نهایی باید به کدام مجموعهٔ خطوط منبع برگردد.

6) Direct Cost را فقط با Ownership واقعی تخصیص بده

Direct Cost زمانی قابل تخصیص است که Owner و Allocation Target معلوم باشند. مثلاً یک GPU inference charge که صریحاً برای Product-A ثبت شده می‌تواند مستقیم به همان Target برود. اگر همان خط هزینه Owner نداشته باشد، نباید با حدس به نزدیک‌ترین تیم چسبانده شود. در این درس، نبود Ownership برای Direct Cost حالت HOLD می‌سازد.

7) Shared Pool به Driver هم‌نسخه نیاز دارد

برای Shared Cost، مقدار کل Pool و Driver Quantity باید متعلق به یک Context باشند. فرمول پایهٔ تخصیص تناسبی چنین است: allocated_target = shared_effective_cost × target_driver_quantity / total_driver_quantity. اگر Pool از ۳۰۰ به ۶۰۰ تغییر کند اما Driver Evidence مربوط به Version قبلی باشد، عدد حاصل ظاهراً دقیق است اما قابل دفاع نیست؛ State باید DISPUTED بماند.

8) Unallocated Residue یک خطا نیست؛ پنهان‌کردنش خطاست

بعضی هزینه‌ها در لحظهٔ Reconciliation واقعاً قابل Attribution نیستند: Resource بدون Tag، Adjustment بدون Owner یا هزینه‌ای که Source Line آن ناقص است. این مبلغ باید در unallocated_amount بماند. هدف، ساختن Ledger صادقانه است، نه رسیدن مصنوعی به ۱۰۰٪ Allocation. وجود Residue می‌تواند نتیجه را PARTIAL کند بدون اینکه تخصیص‌های معتبر دیگر را خراب کند.

9) مثال پایه: ۱۶۵۰ واحد Source Cost

در Fixture پایه ۶۰۰ واحد inference مستقیم به Product-A، ۳۰۰ واحد storage مستقیم به Product-B و ۱۵۰ واحد security به Central اختصاص دارد. ۳۰۰ واحد monitoring بر اساس Request Volume به نسبت ۷۰/۳۰ و ۲۰۰ واحد support به نسبت ۶۰/۴۰ توزیع می‌شود. یک Resource با هزینهٔ ۱۰۰ واحد هنوز Owner ندارد. بنابراین Source Total برابر ۱۶۵۰، Allocated برابر ۱۵۵۰ و Unallocated برابر ۱۰۰ است؛ State درست PARTIAL است، نه «تقریباً Reconciled».

10) Equal Split بدون Approval را رد کن

فرض کن Monitoring قبلاً با Request Volume توزیع می‌شد. اگر کسی برای راحتی Driver را Equal Split کند ولی Approval یا Policy Version جدید وجود نداشته باشد، این تغییر باعث DISPUTED می‌شود. مشکل Arithmetic نیست؛ مشکل Authority و Provenance است. یک تقسیم ۵۰/۵۰ ممکن است مجموع را دقیق ببندد اما Attribution را غیرقابل دفاع کند.

11) Late Adjustment، Reconciliation قبلی را منقضی می‌کند

اگر بعد از بسته‌شدن دوره، ۸۰ واحد Adjustment به Monitoring اضافه شود، Snapshot قبلی دیگر Oracle نیست. Source Total جدید ۱۷۳۰ است و Ledger باید دوباره محاسبه شود. تا زمانی که Allocation و Residue با Source جدید Reconcile نشده، حالت HOLD می‌ماند. برچسب «قبلاً Reconciled» حق عبور از Evidence تازه را ندارد.

12) قرارداد شواهد اصلی

جدول بالا فقط Presentation نیست؛ قرارداد شواهد است. ستون‌های Source، Period، Direct/Shared، Owner، Target، Driver، Driver Qty، Effective Cost، Allocated، Unallocated، Adjustment، Reconciliation، Dispute و Evidence باید به هم بخورند. جمع هر دوره باید از رابطهٔ source_total = allocated_total + unallocated_total عبور کند.

13) Stateهای Typed چه معنی دارند؟

RECONCILED یعنی همهٔ Source Costهای دوره با Evidence معتبر تخصیص یا به Targetهای مجاز ثبت شده‌اند و Delta صفر است. PARTIAL یعنی تخصیص‌های معتبر وجود دارد ولی Residue حل‌نشده هم دیده می‌شود. DISPUTED یعنی Driver، Scope یا Version مورد اختلاف است و عدد نباید به‌عنوان Allocation نهایی مصرف شود. HOLD یعنی Evidence قطعی مثل Owner یا Driver Quantity مفقود است یا Adjustment تازه، Reconciliation قبلی را منقضی کرده است.

14) Transfer: Context عوض شد، درصدها را کپی نکن

اکنون Request Volume مشتری A دو برابر می‌شود ولی Storage او ثابت می‌ماند؛ قرارداد Monitoring از Fixed به Usage-based تغییر می‌کند و Resource صدواحدی قبلی به Product-B قابل ردیابی می‌شود. Driver Monitoring باید با Quantity جدید محاسبه شود، Storage مستقیم نباید فقط به‌خاطر رشد Request جابه‌جا شود و خط قبلاً untagged اکنون می‌تواند Direct شود. در Fixture انتقال، Source Total به ۱۶۹۰ می‌رسد و چون همهٔ Evidence تازه قابل بازتولید است، State به RECONCILED می‌رسد.

15) Lab، ارزیابی و تازگی منابع

Lab کاملاً آفلاین و Synthetic است و هیچ Credential یا Billing واقعی نمی‌خواهد. هشت Fixture شامل baseline، trace کامل، Equal Split بدون Approval، late adjustment، Owner مفقود، Driver Quantity مفقود، Driver stale و Transfer است. منبع بیرونی درس FinOps Framework Allocation در 2026-09-15 دوباره بررسی شده است. Factهای بیرونی از Designهای MAKNOW جدا می‌مانند: FinOps الگوهای Allocation را توضیح می‌دهد؛ Schema، Stateها و Acceptance Ruleهای این درس تصمیم طراحی محلی هستند.