مجاز بودن به معنای قصد داشتن نیست
یک موتور سیاست به پرسشی محدود پاسخ می‌دهد: آیا این فراخوانی ابزار مجاز است؟ یک فهرست مجاز، ابزارها، دامنه‌ها و نقاط پایانی قابل‌دسترس را برمی‌شمارد. اما هیچ نمی‌گوید که آیا یک فراخوانی خاص، در یک گام خاص، در خدمت همان وظیفه‌ای بوده که کاربر واقعاً مجاز کرده است. یک عامل ممکن است اعتبارنامه معتبری برای یک API پرداخت، یک فایل‌سیستم، یک دروازه ایمیل و یک مفسر کد داشته باشد، و هر فراخوانی به‌تنهایی از سیاست عبور کند در حالی که کل توالی کاری را انجام دهد که کاربر هرگز نخواسته است. دسترس‌پذیری، خاصیتی از پیکربندی است. توجیه، خاصیتی از اجرا است.
این تمایز مهم است زیرا حالت‌های شکستی که اپراتورها را نگران می‌کند، به‌ندرت یک فراخوانی ممنوعه واحد است. آن‌ها ترکیب‌ها هستند: یک خواندن که سندی را به بافت می‌کشد، یک گام خلاصه‌سازی که بی‌صدا یک قید را حذف می‌کند، یک نوشتن که نسخه بریده‌شده را منتشر می‌کند. هر گام مجاز است. پرسشی که یک بازبین نیاز دارد به آن پاسخ داده شود این است که آیا آن گام قصد شده بود — آیا از وظیفه، مشاهده و سیاست حاکم در آن لحظه ناشی می‌شد.
یک رکورد قصد باید چه چیزی داشته باشد
یک رکورد قصد، رویدادی ساختاریافته است که یک بار به ازای هر گام اجراشده منتشر می‌شود. این یک خط لاگ نیست که برای انسان نوشته شده و بعداً با regex تجزیه شود؛ یک schema با یک قرارداد است. کمینه فیلدهای قابل‌قبول:
- شناسه وظیفه. یک شناسه پایدار برای هدف مجازشده توسط کاربر، که پیش از نخستین گام ساخته و در تمام گام‌های بعدی حمل می‌شود.
- شماره گام. یکنوا در طول اجرا، تا شکاف‌ها قابل‌مشاهده باشند.
- ابزار فراخوانی‌شده. توانایی مشخص، نه یک برچسب عمومی.
- آرگومان‌ها به‌شکل ارسالی. payload پیش از نرمال‌سازی، زیرا نرمال‌سازی همان جایی است که قصد از دست می‌رود.
- قاعده سیاست پذیرنده. کدام قاعده فراخوانی را مجاز کرده، و تحت کدام نسخه از مجموعه سیاست.
- خلاصه مشاهده. یک هش از مشاهده‌ای که گام را برانگیخته، تا رکورد نتواند بی‌صدا برای هماهنگی با روایت بعدی بازنویسی شود.
- دلیل پایان. چرا اجرا پایان یافت — تکمیل، اتمام بودجه، رد سیاست، خطا، timeout — شامل اجراهای موفق.
فیلد پایان، همان است که بیشتر از همه حذف می‌شود و همان است که بقیه را قابل‌حسابرسی می‌کند. اگر انتظار می‌رود هر اجرا با یک رکورد پایانی بسته شود، آنگاه نبود آن خودش یک سیگنال است: یک executor ازکارافتاده، یک container کشته‌شده، یک فرایندی که هرگز گزارش نداد. بدون آن، رکوردهای گم‌شده از اجراهایی که هرگز رخ نداده‌اند قابل‌تفکیک نیستند.
یک سازوکار مشخص: executor بلافاصله پیش از dispatch مقدار observation_digest = H(canonical_json(observation)) را محاسبه می‌کند و هش را در کنار مشاهده خام فقط در صورتی ذخیره می‌کند که سیاست نگهداری اجازه دهد. هش ارزان است، در عمل تغییرناپذیر است، و برای اثبات اینکه مشاهده ارائه‌شده به مدل در گام N همانی بوده که رکورد ادعا می‌کند کافی است. اگر بررسی بعدی به مشاهده کامل نیاز داشته باشد، می‌توان آن را از مخزن محتوا با هش بازیابی کرد، مشروط به همان قواعد نگهداری که برای هر محتوای کاربری دیگر اعمال می‌شود.
executor منتشر می‌کند، نه مدل
اگر رکوردهای قصد توسط مدل تولید شوند — یک فراخوانی خلاصه‌سازی در پایان اجرا، یا یک دلیل خودگزارش‌شده — به چیز دیگری تبدیل می‌شوند که مدل می‌تواند روایت کند، و بنابراین سطح دیگری که یک مهاجم می‌تواند بر آن اثر بگذارد. رکورد باید توسط همان مؤلفه‌ای منتشر شود که واقعاً فراخوانی ابزار را dispatch می‌کند، پس از پذیرش سیاست و پیش از اجرا، با تصمیم موتور سیاست پیوست‌شده. مدل می‌تواند پیشنهاد دهد؛ executor تصدیق می‌کند. این تفاوت میان یک اظهار ش
ثبت یک رکورد قصد ارزان است. نگهداری محتوای درون آن ارزان نیست. رکوردی که تنها شامل شناسه وظیفه، شماره گام، نام ابزار، قاعده سیاست و هش‌ها است، کوچک، کم‌حساسیت و قابل‌نگهداری برای دوره‌های طولانی است. رکوردی که آرگومان‌ها و مشاهدات خام را در خود جای می‌دهد، حساسیت هر چیزی را که کاربر روی آن کار می‌کرده به ارث می‌برد. معامله صادقانه این است: نگهداری تهاجمی به پاسخ‌دهندگان به رخداد موادی می‌دهد که نیاز دارند، و همزمان مخزنی از محتوای کاربری با تعهدات خودش در زمینه کنترل دسترسی، حذف و نقض ایجاد می‌کند. تفکیک عملی این است که رکوردهای ساختاری بلندمدت نگه داشته شوند و محتوا با هش، با پنجره نگهداری جداگانه و کوتاه‌تر برای مخزن محتوا. آن تصمیم متعلق به مالک حاکمیت داده است، نه تیم پلتفرم عامل، و باید به‌عنوان یک سیاست مستند شود نه اینکه به‌عنوان پیش‌فرض رها شود.
یک schema، سه مصرف‌کننده
همان رکورد باید بدون یک pipeline دوم به graders، پاسخ‌دهندگان به رخداد و حسابداری هزینه خدمت کند. این schema را به روش‌های مفیدی محدود می‌کند. graders به توالی گام و قاعده پذیرنده نیاز دارند تا ارزیابی کنند آیا یک مسیر موجه بوده است. پاسخ‌دهندگان به رخداد به هش مشاهده و نسخه سیاست نیاز دارند تا بازسازی کنند عامل چه دیده و کدام قواعد فعال بوده‌اند. حسابداری هزینه به هویت ابزار، اندازه آرگومان و دلیل پایان نیاز دارد تا هزینه را به ازای هر وظیفه نسبت دهد. schemaای که شناسه وظیفه، شماره گام، ابزار، هش و اندازه آرگومان، قاعده و نسخه سیاست، هش مشاهده و دلیل پایان را حمل می‌کند، به هر سه خدمت می‌کند. schemaای که تنها برای یک مصرف‌کننده طراحی شده باشد، توسط دو مصرف‌کننده دیگر از لاگ‌های خام بازاستخراج می‌شود، و اینگونه است که سازمان‌ها به سه نسخه ناسازگار از همان رویداد می‌رسند.
امضا و ترتیب
رکوردها باید زنجیره‌ای شوند: هر رکورد هش پیشین خود را شامل می‌شود، و اجرا با یک ریشه امضاشده پایان می‌یابد. این حذف بی‌صدا را قابل‌تشخیص می‌کند و به پاسخ‌دهندگان یک توالی قابل‌راستی‌آزمایی می‌دهد. هزینه‌اش عملیاتی است: مدیریت کلید، چرخش و یک گام راستی‌آزمایی در مسیر حسابرسی. این هزینه واقعی است، و دلیل آن است که بسیاری از تیم‌ها با رکوردهای بدون امضا و یک شماره گام یکنوا شروع می‌کنند، سپس پس از تثبیت schema امضا را اضافه می‌کنند. شروع بدون امضا قابل‌دفاع است؛ شروع بدون شماره گام نیست، زیرا ترتیب همان خاصیتی است که هر افزوده بعدی را ممکن می‌کند.
مصنوعی که شکاف را می‌بندد
یک سیاست، فضای کنش‌های مجاز را تعریف می‌کند. یک رکورد قصد نشان می‌دهد کدام‌یک از آن کنش‌ها انجام شده، به چه ترتیب، تحت کدام قاعده، به دنبال کدام مشاهده، و چرا اجرا متوقف شده است. اولی یک پیکربندی است؛ دومی یک شاهد. تیم‌هایی که عامل‌ها را به محیط‌هایی با پیامدهای واقعی می‌فرستند به هر دو نیاز خواهند داشت، و دومی باید توسط runtime در لحظه تصمیم تولید شود — نه اینکه بعداً از رونوشتی بازسازی شود که دیگر بافت مهم را در خود ندارد.