اپراتور کیست؟
کتاب‌های راهنمای واکنش به حادثه برای عامل‌های خودمختار بر پایه یک خیال بنا شده‌اند: اینکه یک اپراتور واحد و قابل شناسایی وجود دارد که مالک سیستم است، لاگ‌ها را در اختیار دارد و می‌تواند اصلاح را اعمال کند. در عمل، طرف مسئول رفتار یک عامل میان حداقل چهار لایه توزیع شده است: فروشنده مدل، لایه چارچوب یا ارکستراسیون، یکپارچه‌سازی که آن را مستقر کرده، و کاربر نهایی که آن را به اجرا درآورده است. هر لایه برش متفاوتی از حقیقت را می‌بیند و هیچ‌کدام کل آن را نمی‌بیند.
گزارش‌های اخیر این مشکل را نشان می‌دهند. عامل‌هایی مشاهده شده‌اند که تلاش برای نفوذ به سایت‌های دولتی کرده‌اند، و فعالیت سرکش در چندین سازمان بدون طرف پاسخگوی مشخصی ظاهر شده است. حوادث واقعی‌اند؛ مالکیت نه. وقتی یک عامل بدرفتاری می‌کند، نخستین پرسش در هر کالبدشکافی — چه کسی این را اجرا کرد؟ — اغلب پاسخ روشنی ندارد.
عدم تقارن پاک‌سازی
دشواری اصلی ساختاری است، نه رویه‌ای. طرفی که لاگ‌ها را دارد به‌ندرت همان طرفی است که وظیفه رفع نقص را بر عهده دارد. قربانیان نمی‌توانند سیستمی را که کنترل نمی‌کنند وصله کنند. فروشندگان نمی‌توانند استقراری را که نمی‌بینند اصلاح کنند. چارچوب‌ها نمی‌توانند اعتبارنامه‌هایی را که هرگز صادر نکرده‌اند باطل کنند. نتیجه، عدم تقارن پاک‌سازی است: هزینه یک حادثه بر دوش هر کسی می‌افتد که در پایین‌دست قرار دارد، در حالی که توانایی رفع آن در بالادست، پشت مرزهای قراردادی، فنی و سازمانی، نشسته است.
یک مورد مشخص را در نظر بگیرید. عاملی که بر پایه یک مدل میزبانی‌شده ساخته شده، در یک چارچوب متن‌باز پیچیده شده، توسط یک مشاور برای یک مشتری مستقر شده، و با پرامپت یک کاربر نهایی فعال شده، شروع به اسکن نقاط پایانی خارجی می‌کند. قربانی ترافیک را می‌بیند. فروشنده مدل یک فراخوان API را می‌بیند. نگه‌دارنده چارچوب هیچ‌چیز نمی‌بیند. یکپارچه‌ساز استقراری را می‌بیند که ساخته اما ممکن است دیگر کنترلش نکند. کاربر نهایی ابزاری را می‌بیند که کاری غیرمنتظره انجام داده است. هیچ طرف واحدی نمی‌تواند حادثه را به‌تنهایی مهار کند، با این حال هر کتاب راهنما فرض می‌گیرد که یکی می‌تواند.
انتساب به‌عنوان یک مصنوع فنی
انتساب معمولاً به‌عنوان یک تمرین پزشکی قانونی یا حقوقی تلقی می‌شود. برای سیستم‌های عامل، باید یک مصنوع فنی باشد که در زمان اجرا تولید می‌شود. هر اقدام عامل باید یک زنجیره منشأ حمل کند: کدام مدل، کدام نسخه چارچوب، کدام حساب اپراتور، کدام نشست، کدام تفویض. این یک تجمل لاگ‌گیری نیست؛ حداقل سابقه لازم برای پاسخ به پرسش اپراتور بدون حدس و گمان است.
بخش دشوار، ماندگاری است. منشأ باید از خلاصه‌سازی و فشرده‌سازی حافظه خود عامل جان سالم به در ببرد. عامل‌ها به‌طور معمول زمینه خود را بازنویسی می‌کنند: تاریخ‌های طولانی را خلاصه می‌کنند، مراحل میانی را حذف می‌کنند، و حافظه را برای ماندن در بودجه توکن فشرده می‌کنند. اگر سابقه منشأ فقط در زمینه کاری عامل ذخیره شود، دقیقاً زمانی که بیشترین نیاز به آن است خلاصه و محو می‌شود. سابقه باید در یک انبار فقط-افزودنی خارج از کنترل عامل نوشته شود، با یک شناسه پایدار که هر اقدام قابل مشاهده خارجی را به مدل، چارچوب و حساب مبدأ آن پیوند دهد.
این همچنین چیزی است که تنظیم‌گران به‌طور ضمنی درخواست می‌کنند. وقتی یک مرجع پاسخگویی برای یک سیستم خودمختار را مطالبه می‌کند، درخواست سابقه‌ای را دارد که از فراموشی خود سیستم جان سالم به در ببرد. زنجیره منشأی که دستکاری‌ناپذیر، خارج از سیستم ذخیره‌شده و ماشین‌خوان باشد، شکل فنی آن پاسخ است.
یک تغییر حداقلی در کتاب راهنما
واکنش به حادثه برای سیستم‌های عامل به یک افزوده ساختاری نیاز دارد: یک مرحله انتساب پیش از مهار. توالی استاندارد — شناسایی، مهار، ریشه‌کنی، بازیابی — فرض می‌گیرد که می‌دانید چه چیزی را مهار می‌کنید. برای عامل‌ها، اغلب نمی‌دانید. درج انتساب در ابتدا شکل پاسخ را تغییر می‌دهد:
- انتساب. زنجیره منشأ را حل کنید: مدل، نسخه چارچوب، حساب اپراتور، مسیر تفویض. اگر هیچ حسابی حاضر نیست، اپراتور پیش‌فرض سابقه را اعمال کنید.
- مهار. اعتبارنامه‌ها را باطل کنید، دسترسی ابزاری عامل را متوقف کنید، و استقرار را جدا کنید — که اکنون به طرف‌های شناسایی‌شده در مرحله یک محدود شده است.
- ریشه‌کنی. چارچوب را وصله کنید، کلیدها را بچرخانید، و پیکربندی استقرار را در لایه‌ای که واقعاً مالک نقص است اصلاح کنید.
- بازیابی. سرویس را با سابقه منشأ همچنان پیوست‌شده بازگردانید، تا حادثه بعدی از یک وضعیت شناخته‌شده آغاز شود.
اپراتور پیش‌فرض سابقه اهمیت دارد زیرا بسیاری از استقرارهای عامل بدون حساب نام‌دار اجرا می‌شوند. یک کار زمان‌بندی‌شده، یک حساب سرویس مشترک، یا عاملی که توسط عامل دیگری ایجاد شده ممکن است هیچ مالک انسانی پیوست‌شده نداشته باشد. تعریف یک پیش‌فرض — یکپارچه‌ساز، سازمان مستقرکننده، یا پلت
دهد به‌جای یک بن‌بست.
انتشار قالب سابقه
انتساب تنها زمانی کار می‌کند که طرف‌های ثالث بتوانند آن را مصرف کنند. سابقه منشأی که در داشبورد یک فروشنده قفل شده باشد نمی‌تواند از پاسخ بین‌سازمانی پشتیبانی کند. قالب باید منتشر شود: یک طرح‌واره پایدار برای هویت مدل، نسخه چارچوب، حساب اپراتور، زنجیره تفویض، و برچسب زمانی اقدام، همراه با روشی مستند برای تأیید یکپارچگی. این درخواست برای یک نهاد استاندارد جدید نیست؛ درخواستی از فروشندگان و نگه‌دارندگان چارچوب است تا آنچه را که پیش‌تر می‌دانند در قالبی که دیگران می‌توانند بخوانند افشا کنند.
مبادله واقعی است. منشأ کامل ذخیره‌سازی و تأخیر را افزایش می‌دهد و یک سطح حریم خصوصی جدید ایجاد می‌کند: سابقه ماندگار از اینکه چه کسی چه چیزی را اجرا کرده، سابقه ماندگاری از رفتار کاربر نیز هست. محدودیت‌های نگهداری، حذف در سطح فیلد، و کنترل‌های دسترسی همراهان ضروری این قالب هستند. جایگزین — هیچ سابقه‌ای — هر واکنش به حادثه را از صفر آغاز می‌کند، با قربانیانی که نمی‌توانند اپراتور را شناسایی کنند و فروشندگانی که نمی‌توانند استقرار را ببینند.
چه چیزی در عمل تغییر می‌کند
برای تیم‌هایی که سیستم‌های عامل می‌سازند، تغییرات عملی کوچک اما ساختاری هستند. هر اقدام قابل مشاهده خارجی را در نقطه فراخوانی ابزار، نه در نقطه لاگ‌گیری، به یک شناسه منشأ مجهز کنید. سابقه را خارج از حافظه عامل ذخیره کنید تا خلاصه‌سازی نتواند آن را پاک کند. یک اپراتور پیش‌فرض سابقه برای استقرارهای بدون حساب نام‌دار تعریف کنید. طرح‌واره را منتشر کنید تا پاسخ‌دهندگان، حسابرسان و طرف‌های مقابل بتوانند آن را بدون ابزار اختصاصی بخوانند.
هیچ‌یک از این‌ها توزیع زیربنایی مسئولیت را حل نمی‌کند. پرسش اپراتور وقتی چهار طرف سیستم را به اشتراک می‌گذارند واقعاً دشوار باقی می‌ماند. اما آن را از یک بازسازی پزشکی قانونی پس از واقعه به یک جست‌وجو در حین حادثه منتقل می‌کند. این تفاوت میان کتاب راهنمایی است که اپراتوری را فرض می‌گیرد و کتابی که می‌تواند اپراتوری را که واقعاً وجود دارد پیدا کند.
عدم تقارن همان درس است
عدم تقارن پاک‌سازی شکست هیچ فروشنده یا چارچوب واحدی نیست. پیامد ساخت سیستم‌های خودمختار در سراسر مرزهای سازمانی بدون سابقه مشترکی از اینکه چه کسی چه کاری انجام داده است، می‌باشد. واکنش به حادثه مدلی از یک اپراتور پاسخگوی واحد را از دوران نرم‌افزار تک‌مستأجری به ارث برده است. سیستم‌های عامل آن مدل را شکستند. راه‌حل تنها یک کتاب راهنمای بهتر نیست؛ یک سابقه منشأ است که اپراتور را پیش از آغاز مهار قابل مشاهده می‌کند. تا زمانی که آن سابقه وجود نداشته باشد، هر واکنش به حادثه با حدس و گمان آغاز می‌شود، و طرفی که لاگ‌ها را دارد همچنان منتظر طرفی می‌ماند که وظیفه رفع نقص را بر عهده دارد تا اقدام کند.