Findings and issues - Failproof AI

title: “ממצאים ובעיות” description: “הפכו ראיות ביקורת לעבודת תיקון בבעלות וניתנת למעקב.” icon: “clipboard-check”

ממצא הוא הצהרה של הביקורת המבוססת על ראיות לגבי כשל. בעיה היא תהליך עבודה עמיד להגיב לכך.

מיון והקצאת העבודה

Dashboard
CLI

פתחו את Analyze → Audits, בחרו הרצה שהושלמה, ובחרו ממצא כדי לבדוק את הניתוח, ההמלצה, הסשנים וקוויות הראיות שלו.
אישרו, הקצו, דחו, השתיקו, פתרו או פתחו מחדש את הממצא לאחר בדיקת הראיות שלו.
עברו אל Analyze → Issues וסננו את תיבת הדואר העמידה לפי סטטוס, חומרה או מקצוע.
פתחו את הבעיה כדי להקצות אותה, להוסיף הערות או מנויים, ופתרו אותה לאחר אימות התיקון.

התחילו בסיכום הממצא. אשרו כי תיאור הכשל, התגובה המומלצת, החומרה וההדירוג מסכימים עם הסשנים שציפיתם שהביקורת תבדוק.

ממצא ביקורת עם חומרה, ספירת התרחשויות, ניתוח עלילה שורש, פעולה מומלצת, גורמי דירוג והוכחות.

לאחר מכן, פתחו סשן מושפע במקום להחליט רק מהסיכום. העקבול המקושר אמור להציג את האירוע והמטען המדויקים התומכים בממצא.

סשן המקושר ממצא ביקורת, פתוח בשגיאה הרלוונטית עם מטא נתונים של אירועים וטעינת גלם.

לאחר אימות הראיות, השתמשו בבעיות כדי לתת בעלות לתגובה ולעקוב אחריה באופן עצמאי מהרצות ביקורת עתידיות.

תיבת הדואר של בעיות המציגה עבודה שיורה, מוכרת ופתורה עם חומרה והיכל.

פתחו את הבעיה כדי להקליט הערות חקירה, להודיע למנויים ולשמור על היסטוריית התגובות. פתרו אותה רק לאחר שתיקון התיקון הוכח ואומת.

תצוגה פירוט בעיה עם המקור שלה, ראיות הפרה, מוקדי משימות, מנויים, ציר הזמן והערות.

fp audits findings --audit checkout-reliability --status open
fp audits finding <finding-id>
fp audits ack <finding-id> --reason "owner assigned"
fp audits assign <finding-id> --to engineer@example.com

fp issues list
fp issues show <issue-id>
fp issues assign <issue-id> --assignee engineer@example.com
fp issues comment-add <issue-id> --body "policy is in observe mode"
fp issues resolve <issue-id> --yes

השתמשו ב-fp issues subscribe <issue-id>, fp issues unsubscribe <issue-id> ו-fp issues subscribers <issue-id> כדי לנהל משקיפים.ראו את הפניה Cloud CLI ביקורת וסוגיה לממצאי ביקורת ו-fp issues לניהול בעיות.

בדוק ממצא

אשרו שהוא מכיל:

מצב כשל יציב, לא רק כותרת חד פעמית
חומרה והשפעה תפעולית
מזהי סשן משופעים או שאילתות תומכות
מספיק הקשר כדי להעתיק את ההתנהגות
תגובה מוצעת התואמת את הראיות

השתמשו בבעיה לניהול התגובה

צרו או קשרו בעיה כאשר הממצא זקוק להקצאה, דיון, שינויי סטטוס, הערות או מנויים. בעיות יכולות גם לייצג תקريות התראה ובעיות שדווח עליהן ידנית, וזו הסיבה שהן חיות תחת תגובת ביקורת ולא בניווט הראשי. פתרו את הבעיה כאשר תיקון הוא פרוס ומאומת. פתור את הממצא כאשר אופן הכשל עודכן לאוכלוסיית הביקורת. הרגעים הללו עשויים להיות שונים.

הפוך בעיה לטיוטת מדיניות

Dashboard
CLI

פתחו את הבעיה ואשרו את הממצא שלה, סשנים מצוטטים, סיבה שורש והמלצה.
בחרו generate policy ובדקו את תוצאת הזכאות וכוונת האכיפה המוצעת. תוצאה no policy פירושה שההתנהגות עשויה לדרוש התראה, שינוי זרימת עבודה או תגובה אנושית במקום זאת.
בחרו write this policy, בדקו ותיסו את המקור שנוצר ב-Admin → policy editor לפני בחירה publish version. השתמשו ב-open the editor anyway כאשר אתם לא מסכימים עם בדיקת הזכאות.
עברו אל Admin → enforcement, פרסמו את הגרסה ב-observe mode, ואמתו את ההחלטות שלה תחת Observe → policy לפני אכיפתה.

כותרת הבעיה, תיאור הממצא, סיבת השורש, ההמלצה וכוונת הזכאות עוזרים בהחברת הטיוטה. שום דבר לא פורסם או פורס באופן אוטומטי.

השתמשו ב-CLI כדי לבדוק את הראיות לפני פתיחת הבעיה בלוח הבקרה:

fp issues show <issue-id>
fp audits finding <finding-id>
fp events --session-id <session-id> --full --all

זכאות מדיניות, פרסום ענן והפרוס בחFleet הם תוך-דשבורד. השתמשו ב-failproofai policies --install --custom <file> כאשר ברצונכם לתקף תחילה מקור מדיניות שווה ערך מקומי.

כתיבת מדיניות

המרת דפוס פעולה מוגדר וחוזר למהדורת מדיניות.

​title: “ממצאים ובעיות” description: “הפכו ראיות ביקורת לעבודת תיקון בבעלות וניתנת למעקב.” icon: “clipboard-check”

​מיון והקצאת העבודה

​בדוק ממצא

​השתמשו בבעיה לניהול התגובה

​הפוך בעיה לטיוטת מדיניות