معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۲ — ICP، Serviceability، Pilot، Workload و Admission · 232
Workload Catalog برای AI/Media/Human Work
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Workload Catalog برای AI/Media/Human Work». می‌تواند برای «Workload Catalog برای AI/Media/Human Work» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «Workload Catalog برای AI/Media/Human Work».
می‌تواند برای «Workload Catalog برای AI/Media/Human Work» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «Workload Catalog برای AI/Media/Human Work» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1) مسئلهٔ واقعی: «۱۰۰۰ کار در روز» واحد ظرفیت نیست
وقتی درخواست AI، تولید تصویر، رندر ویدئو و بازبینی انسانی را با هم جمع می‌کنیم، عدد نهایی ساده است اما چیزی دربارهٔ گلوگاه نمی‌گوید. هرکدام واحد کار، زمان خدمت، همزمانی، هزینه و صف متفاوت دارند. هدف این درس ساخت Cross-Modal Workload Catalog v1 است؛ نه Forecast و نه تصمیم Admission.
2) Workload را با Business Value مرزبندی کن
در AWS Well-Architected، workload مجموعه‌ای از componentهاست که با هم ارزش کسب‌وکاری ایجاد می‌کنند. این تعریف برای مرزبندی مفید است؛ اما taxonomy این درس را AWS تعیین نمی‌کند. ما باید مشخص کنیم هر ردیف دقیقاً چه ارزش و چه مالکیت عملیاتی دارد.
3) Native Work Unit را حفظ کن
درخواست AI با «request»، تصویر با «image»، ویدئو با «rendered_video_minute» و کار انسانی با «review_minute» سنجیده می‌شود. تبدیل همه به «job» پیش از مدل ظرفیت، اطلاعات مهم را از بین می‌برد. اگر normalization لازم شد، باید بعداً و با تعریف شفاف انجام شود.
4) Resource Plane را جدا بنویس
AI inference، GPU/media generation، media rendering و human operations منابع یکسانی نیستند. Catalog باید نشان دهد هر workload روی کدام plane فشار می‌آورد تا یک میانگین مخلوط، bottleneck را پنهان نکند.
5) Arrival Pattern و Burst را از Daily Total جدا کن
دو سامانه ممکن است هر دو ۱۰۰۰ request/day داشته باشند، اما یکی یکنواخت و دیگری در یک ساعت شلوغ ۴ برابر burst کند. Daily volume بدون الگوی ورود، concurrency لازم و queue pressure را توضیح نمی‌دهد.
6) Concurrency، Service Time و Latency Target سه چیز متفاوت‌اند
Concurrency می‌گوید چند کار همزمان می‌خواهیم؛ service time مدت مصرف منبع برای هر واحد است؛ latency target تعهد یا هدف تجربهٔ مصرف‌کننده است. قاطی‌کردن آن‌ها باعث برآورد ظرفیت اشتباه می‌شود.
7) Media Size و Compute/Token Unit را فقط جایی نگه دار که معنا دارند
برای AI، token/call می‌تواند cost driver باشد؛ برای video، rendered minute و compute-minute یا media size مهم است. «n/a» بهتر از عدد ساختگی است. Catalog باید ناهمگونی را آشکار کند، نه پنهان.
8) Human Minutes یک Workload مستقل است
بازبینی انسانی را به‌عنوان درصد مبهمی روی workload فنی پخش نکن. اگر فقط high-risk subset نیاز به review دارد، همان subset و review-minuteهایش را جدا ثبت کن؛ چون staffing window و backlog آن با GPU یا API فرق دارد.
9) Retry و Failure می‌توانند Demand را تکثیر کنند
اگر ۱۰٪ فراخوانی‌ها retry شوند، demand مؤثر همان demand اولیه نیست. Retry policy، failure mode و rework انسانی باید دیده شوند؛ وگرنه downstream forecast روی ورودی کم‌برآوردشده ساخته می‌شود.
10) سناریوی پایه: چهار ردیف، چهار واحد بومی
| workload_id | work_unit | resource_plane | arrival_pattern | concurrency | service_time | human_minutes | cost_driver | queue_class | observability_signal | evidence_ref |
|---|---|---|---|---|---|---|---|---|---|---|
| AI-CHAT | request | AI inference | 1000 requests/day; burst 2x | 20 | 4 s/request | 0 | tokens + inference calls | interactive | requests, tokens, latency, retries | SYN-ARC013-B1 |
| IMG-GEN | image | GPU/media generation | 180 images/day; burst 3x | 8 | 18 s/image | 0 | GPU seconds + generation calls | interactive-batch | images, GPU seconds, retries, rejects | SYN-ARC013-B2 |
| VID-RENDER | rendered_video_minute | media rendering | 120 rendered minutes/day; burst 2.5x | 6 | 3 compute-min/rendered-min | 0 | render compute + storage/egress | batch-priority | rendered minutes, compute minutes, queue age, failures | SYN-ARC013-B3 |
| HUM-REVIEW | review_minute | human operations | 360 review minutes/day; staffed 8h window | 3 reviewers | 6 min/item average | 360/day | reviewer minutes | human-review | review minutes, backlog age, reject/rework rate | SYN-ARC013-B4 |
در این سناریو Catalog فقط وقتی CATALOG_READY است که واحدهای بومی، arrival/burst، concurrency/service، cost، queue، observability و provenance همگی دیده شوند. جمع‌کردن اعداد این جدول در یک total job/day ممنوع است، چون ابعاد آن‌ها هم‌واحد نیست.
11) میان‌بُر غلط: همه‌چیز را Job بنامیم
اگر request، image، rendered_video_minute و review_minute همگی به job تغییر نام دهند، ظاهر جدول یکدست می‌شود اما اطلاعات ظرفیت از بین می‌رود. نتیجهٔ bounded در Lab برابر DISPUTED است، نه موفقیت.
12) Negative cases چه Stateای می‌سازند؟
فیلد بحرانی گمشده → HOLD. شواهد منقضی → STALE. تغییر مادی که هنوز recompute نشده → PARTIAL. generic-job collapse → DISPUTED. این Stateها شکست سیستم نیستند؛ مانع تصمیم قوی‌تر از شواهد می‌شوند.
13) Lab: هشت Fixture و 64 Assertion
Lab آفلاین است و API یا credential نمی‌خواهد. هشت fixture شامل baseline، generic collapse، دوبرابرشدن media بدون recompute، evidence گمشده، burst جدید، retry amplification پنهان، evidence stale و transfer نهایی است. Oracle فقط روی ورودی‌های visible و قواعد صریح کار می‌کند.
14) Transfer: ویدئو دوبرابر، AI بیست درصد کمتر، Review فقط High-Risk
در Transfer، حجم AI از ۱۰۰۰ به ۸۰۰ request/day می‌رسد؛ مدت/تقاضای native ویدئو دوباره محاسبه می‌شود؛ و review فقط برای subset پرریسک به‌صورت workload انسانی جدا می‌ماند. پاسخ صحیح یک total job جدید نیست؛ یک Catalog جدید با ردیف‌های recomputed است.
15) چک‌لیست تحویل
مرز business value روشن است؛ native unit هر workload حفظ شده؛ arrival/burst، concurrency، service/latency، cost/human/retry/failure، queue/observability و evidence_ref دیده می‌شوند؛ هیچ evidence مفقود به success تبدیل نشده؛ Transfer از دادهٔ جدید محاسبه شده؛ و Forecasting به ARC-014 واگذار شده است.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-013-Q1 retrieval
Explain the owned boundary of a workload catalog and name one adjacent non-goal.
ARC-013-Q2 application
Build Cross-Modal Workload Catalog v1 for the baseline AI/media/human fixture using native work units.
ARC-013-Q3 diagnosis
A dashboard renames all work as jobs/day and media size doubles. Identify the invalidated evidence and bounded state.
ARC-013-Q4 transfer
Video duration doubles, AI request volume falls 20%, and human review applies only to a high-risk subset. Rebuild affected demand fields without a generic job count.
ملاک‌های ارزیابی (rubric)
- Boundary: ARC-013 catalog outcome is explicit; ARC-014 forecasting remains out of scope.
- Native units: AI, image, video and human work retain non-collapsed units.
- Evidence: all critical dimensions and provenance are visible.
- Negative case: a generic job collapse or missing evidence produces a typed non-success state.
- Transfer: changed media/AI/human-review conditions are recomputed from changed evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
از همین پوشه اجرا کنید:
python run_checks.pyFixtureها را بررسی کنید. AI، media و human work را در واحدهای بومی نگه دارید، تغییر مادی را دوباره محاسبه کنید و وضعیت‌های HOLD/PARTIAL/DISPUTED/STALE را به موفقیت اجباری تبدیل نکنید.