בדיקת אחורה של הטיוטה
- Dashboard
- CLI
עורך המדיניות משחק מחדש טיוטה מול קריאות שהצי שלך כבר ביצע, לפני שאתה מפרסם אותה.
- פתח את הטיוטה ב-Admin → policy editor. העורך מאשר שהיא מתאימה כ-JavaScript.
- ב-backtest, בחר את הסוכנים ואת חלון הזמן להשחקה מחדש — כל סוכן ו-30d כברירת מחדל — והשאר את המסנן האחרון ב-everything אלא אם אתה רוצה לצמצם.
-
בחר run backtest.
הרץ אותה מול אירוע שאתה מתאר
fp policies test מריץ קובץ מדיניות על המכונה שלך מול אירוע סינתטי ובודק את ההחלטה. שום דבר לא מפורסם ותום דבר לא מגיע ל-Cloud:
--event, --tool, --command ו---file. מסנן ה-match של המדיניות עצמה עדיין תקף, ולכן מדיניות שלא מכסה את האירוע שתיארת מדווחת skipped ולא החלטה — בדרך כלל סימן שה-match שלה צר יותר ממה שהתכוונת.
הרץ אותה על מכונה אחת
לאחר מכן, אכוף אותה באמת על המכונה שלך, מול הסוכן שלך:בדוק מה שמתקלקל
ההתקנה דוחה קובץ חסר, שגיאת תחביר, ייבוא לא פתור, חריגה ברמה העליונה, או מודול שקופא בעת טעינה — אז הרץ שוב אחרי כל שינוי לקובץ או לכל דבר שהוא מייבא. בזמן אכיפה אותו קובץ שבור מתועד וביצוע מושעה כך שכל מדיניות אחרת ממשיכה לרוץ: התייחס לאזהרת טעינה ביומנים בייצור כאל אכיפה אבודה. קובצי קונבנציה נטענים ללא פקודת ההתקנה, אז שמור על שלבfailproofai policies --install --custom <file> מפורש ב-CI — זה מה שגורם לבנייה להיכשל על מדיניות שבורה.
לאחר מכן הזן לה מה שסוכנים בעצם שולחים, לא רק את הקלט שאתה צופה: שדות חסרים, שמות כלים חלופיים כגון Write ו-Edit, נתיבים של Windows, קלט שגוי. החזר בכוונה allow, instruct או deny בכל נתיב, שמור על הפונקציה דטרמיניסטית, וקשור כל קריאה חיצונית עם timeout קצר.
ואז פרסם אותה ותבחין בה
בדיקת אחורה מראה מה המדיניות הייתה עושה לתנועה שהייתה לך; היא לא יכולה להראות מה תנועה שלא ראית עדיין תעשה. בחר publish version בעורך (או הרץfp policies publish), ואז פרוס אותה ב-observe mode קודם — הפסקיות שלה מתועדות ותום דבר לא חסום — ואכוף ברגע שהתאימות שלה מפרידות בין פעולות לא בטוחות ליעילות בעל כורחך.