רווחים:
- ניהול מקצה לקצה של אירוע עם תמיכה בבינה מלאכותית בשלבי הגילוי, האבחון, ההפחתה, הפתרון הקבוע והלמידה
- יכולת לשמור על משמעת אימות גם בתקופות של פאניקה על ידי הפרדת שלבים שניתן להעביר לבינה מלאכותית לבין אלו הדורשים החלטה אנושית בכל שלב.
- יכולת להפוך את כלל הזהב שלפיו בינה מלאכותית עדיפה על שאלות 'מה קורה, איך כותבים', ולבני אדם יש עדיפות על פני שאלות 'האם אני צריך לעשות את זה, מי הערב', לרפלקס עסקי
אינטגרציה מקצה לקצה: ניהול אירוע מקצה לקצה עם AI
למדת את החלקים בעשר היחידות הקודמות: סקריפטים, ניתוח יומנים, ניטור, תצורה, IaC, תיעוד, תחזוקה חזויה, ניהול שינויים ואבטחה. אבל בעולם האמיתי, החלקים האלה לא מגיעים אחד אחד, אלא שזורים זה בזה בתוך אירוע. ביחידה אחרונה זו, אנו מפגישים את החלקים: תוכלו לראות בשלמותו כיצד לנהל אירוע שהחל באמצע הלילה, מקצה לקצה, מגילוי לגורם השורשי, מתיקון לתיעוד, ושימוש במינון הנכון של AI בכל שלב. המטרה היא לא ללמד טכניקה חדשה; חיבור מה שלמדת כרפלקס של מהנדס, מחזק את האמת האחת שחוזרת על עצמה לאורך המודול: בינה מלאכותית מאיץ, מאיר ומתווה שרטוטים בכל שלב; אבל זה תמיד האדם שמאשר את האבחנה, מפעיל את הפקודה, מאשר את השינוי, ונושא באחריות לתוצאה.
ביחידה זו, תשלב את מחזור החיים של אירוע - זיהוי, אבחון, התערבות, פתרון, למידה - ואת התפקיד והגבולות של AI בכל שלב באמצעות דוגמה.
מחזור חיים של אירוע
כל אירוע רציני עובר שלבים דומים, ול-AI יש תפקיד שונה בכל שלב. זיהוי: נשמעת אזעקה, משתמש מתלונן, מדד חורג מקו הבסיס (יחידה 4). תיקוף והיקף: האם זה באמת נושא, עד כמה הוא רחב? אבחון: הגעה לשורש הסיבה מיומנים ומדדים (יחידה 3). תגובה והפחתה: עצירת נזק, פיתרון. פתרון קבוע: תיקון עם ניהול שינויים (יחידה 9), סקריפט (יחידה 2) או תצורה במידת הצורך (יחידה 5). למידה: עדכון נתיחה שלאחר המוות ו-Runbook (יחידה 7). בינה מלאכותית מסמנת את האנומליה בזיהוי, מייצרת השערות באבחון, מציעה אפשרויות התערבות, כותבת טיוטות בפתרון, מייצרת מסמכים בלמידה - אבל בכל שלב, בני האדם עומדים בנקודת ההחלטה.
טיפ: הרגע המסוכן ביותר של תקרית הוא רגע האבחנה והתגובה בו הלחץ הוא הגבוה ביותר - בדיוק כאשר הדחף לסמוך באופן עיוור על הבינה המלאכותית הוא החזק ביותר. ככל שאתה ממהר יותר, אתה נאחז חזק יותר ברפלקס "קרא, ודא, התכונן להחזרה". אימות בודד שדילג עליו ברגע של פאניקה מכפיל את האירוע.
דוגמא מההתחלה ועד הסוף
בואו נעשה את זה קונקרטי. אזעקה בשעה 02:10: זמן התגובה של שירות התשלום p99 הוא 6 שניות, הרבה מעל קו הבסיס (250–400 אלפיות השנייה). זיהוי נכון: המעקב עבד. אישור: אישור ממספר מקומות, אירוע אמיתי. אבחון: מהנדס נותן יומן רעולי פנים ומדדים של 20 הדקות האחרונות לבינה מלאכותית; הבינה המלאכותית קובעת ציר זמן ומסמנת את ההאטה שמתחילה מיד לאחר פריסה ב-02:08 - מתאם חזק, אבל עדיין השערה. המהנדס מאשר זאת ביומן הפריסה: כן, שחרור שוחרר בשעה 02:08. תגובה: ההפחתה המהירה ביותר היא ביטול הפצה; שלב החזרה לאחור בבקשת השינוי מוכן (יחידה 9). המהנדס מיישם תחילה את ההחזרה לאחור בשרת עם לוגיקה קנרית, זמן התגובה משתפר, ולאחר מכן מפיץ אותו. פתרון קבוע: סיבת השורש האמיתית (שאילתה לא צמודה בגרסה החדשה) יתוקן ברוגע למחרת. למידה: נערך ניסוי שלאחר המוות ללא בינה מלאכותית ושלב "ניטור p99 לאחר פריסה" מתווסף ל-Runbook. בכל שלב, AI הואץ; אנושי מאומת בכל נקודת החלטה.
כלל הזהב של חלוקת העבודה האנושית-AI
ההבחנה שרואים לאורך המודול הופכת כאן לכלל: AI מקדימה בשאלות של "מה קורה, מה יכול לקרות, איך לכתוב"; אנשים מקדימים בכל הנוגע לשאלות כמו "האם עלי לעשות את זה עכשיו, מי יכול להעיד על כך?" בינה מלאכותית היא בלתי נלאית, מהירה, סורקת מידע עצום ויוצרת שרטוטים - אבל היא לא יודעת את ההקשר המלא, יכולה לייצר הזיות, לא יכולה להתמודד עם אחריות ואינה רואה את התלות הנסתרת של הארגון שלך. האדם איטי, אך נושא קונטקסט, אחריות ושיפוט. התוצאה הטובה ביותר היא בחלוקת העבודה הנכונה בין השניים: האצלת עבודה חוזרת, טקסטואלית וניתנת להפקה ל-AI; שמור על אימות, החלטה וביצוע אנושיים.
שלושה מיני תיקים
מקרה 1 - 40 דקות מקצה לקצה. באירוע מלא בדיסק, SRE האיץ את כל השרשרת עם AI: אישר את האזעקה עם קו הבסיס (5 דקות), סיכם את יומן המסכה ל-YZ ומצא את השגיאה הראשונה (5 דקות), אימת את השערת "סיבוב היומן נעצר" של ה-AI על המערכת האמיתית (5 דקות), הרץ והטמיע סקריפט ניקוי מוכן עם התסריט היבש ואימת את ה-10-to mint סקיצה (10-to mint). עובדות (15 דקות). סך הכל 40 דקות; בערך פי שניים ללא AI. אבל היה שלב אימות בכל שלב.
מקרה 2 - דילג על אימות ברגע של פאניקה. קבוצה אחרת מיהרה לחתוך. הוא קיבל את השערת השורש הראשונה של ה-AI (שירות תלות) מבלי לאמת אותה והפעיל מחדש את השירות הזה. הבעיה לא תוקנה כי הסיבה האמיתית הייתה משהו אחר; יתר על כן, האתחול המיותר יצר הפסקה שנייה. לקח: חיפזון אינו הצדקה לדילוג על אימות; לפני אישור השערת הבינה המלאכותית, פעולה מסלימה את האירוע.
מקרה 3 - להיות מודע למגבלה. מהנדס עמד ליישם שינוי תצורה שה-AI דחק בבעיית רשת מורכבת. אבל השינוי נראה בלתי הפיך, וה-AI לא ידע את כללי הניתוב הספציפיים של הסוכנות. המהנדס עצר, התייעץ עם מומחה רשתות בכיר, ולמד שההצעה של ה-AI תיצור לולאת ניתוב בטופולוגיה הספציפית הזו. הכרת הגבול של ה-AI מנעה שיבוש.
ארבע תבניות הניתנות להעתקה
1) סיכום טריגר לאירוע (טריאג'):
תפקידך: SRE בכיר, עוזר מפקד אירוע. יש אירוע פעיל. ההתראה/מדד/יומן המסיכה שאני נותן לך נותן לי בדיקה מהירה: (1) מהו הסימפטום, (2) מהו היקף ההשפעה, (3) 3 אזורים להסתכל עליהם תחילה, (4) פקודת בקרה לקריאה בלבד עבור כל אחד מהם. ההחלטה והביצוע הם שלי; שלח את הדרך. נתונים: [מסוכה]
2) מדריך לניהול אירועים בשלבים:
קח אותי צעד אחר צעד דרך מחזור החיים של האירוע עבור סימפטום [תסמין]: אישור זיהוי, אבחון, הקלה, פתרון קבוע, למידה. בכל שלב, אמור לי (א) מה אני צריך לעשות, (ב) מתי אני יכול להאציל זאת בבטחה ל-AI, (ג) איזו החלטה עלי לקבל בעצמי. סמן את שלבי האימות שאסור לי לדלג עליהם גם אם אני ממהר.
3) בקרת נקודת החלטה:
אני בעיצומו של אירוע ואני עומד לבצע את הפעולה הבאה: [פעולה]. לפני היישום, שאל אותי: (1) האם זה הפיך, (2) איזה אימות עשיתי/לא עשיתי, (3) האם יש לי תוכנית החזרה לאחור, (4) האם יש לי הוכחות לכך שהפעולה הזו אכן פתרה את הגורם השורשי? אם אתה רואה משהו חסר, עצור אותי.
4) למידה משולבת לאחר אירוע:
עבור התקרית שזה עתה נפתרה, [סיכום] נותן לי: (1) טיוטה שלאחר המוות ללא אשמה, (2) 3 שיפורים קבועים (ניטור/אוטומציה/קונפיגורציה) שימנעו את התקרית הזו, (3) שלבי ריצה שיש לעדכן, (4) הצעה לאיתות אזהרה מוקדמת לאירוע דומה. כתיבת סיבת שורש ללא ראיות; מבוסס על עובדות.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה:
המערכת קרסה, מה עלי לעשות?
בפאניקה, ללא הקשר וללא אימות, הנחיה זו מקבלת עצות כלליות ואולי מסוכנות מה-AI. למהר מוביל לטעויות בשלב זה הכי הרבה.
הנחיה עוצמתית:
תפקידך: עוזר מפקד אירוע. אירוע פעיל: זמן תגובה של שירות תשלום IP99 פי 15 מהבסיס (250-400 אלפיות השנייה) מאז 02:10. אני יודע שהייתה חלוקה בשעה 02:08. תן לי: (1) את ההשערה הסבירה ביותר וכיצד לאמת אותה לקריאה בלבד, (2) אפשרות ההפחתה המהירה והניתנת להפיכה, (3) הסיכונים שעלי לשלוט בהם לפני יישום ההפחתה הזו. יש לי את הביצוע והאישור. נתונים נוספים: [מדד/יומן מסיכה]
שלב האירוע
תפקיד של AI
החלטה אנושית קריטית
זיהוי
סמן את האנומליה
האם זה האירוע בפועל, מה ההיקף?
אבחון
יצירת השערות
איזו השערה אוששה?
הפחתה
אל תציע אפשרויות
איזו הפחתה הפיכה?
פתרון קבוע
טיוטה/תסריט
אשר ובצע את השינוי
למידה
סקיצה שלאחר המוות
אימות עובדות ולקחים
טעויות נפוצות
- דילוג על אימות בפאניקה. למהר אינו הצדקה לנטוש את רפלקס "קרא-אמת-הכן החזרה"; ככל שהלחץ גובר, המשמעת חייבת לעלות.
- טעות בהשערה בראיה. נקיטת פעולה מבלי לאשר את הצעת השורש הראשונה של הבינה המלאכותית תגרום להסלמה של התקרית.
- שוכחים את גבול ההקשר של AI. AI אינו מכיר את התלות הנסתרת של הארגון; בשינוי קריטי, השיפוט האנושי מנצח.
- דילוג על שלב הלמידה. האירוע, ללא עדכוני נתיחה שלאחר המוות ו-Runbook, מתחיל שוב באותו לילה.
- הטלת האחריות על AI. "ה-AI אמר זאת" אינו הגנה; האחריות לביצוע מוטלת תמיד על האדם.
זהירות: שימוש בבינה מלאכותית בניהול אירועים אינו מחליף למידה של ניהול אירועים. הרכב עלול להתרסק, להתרסק או להיות בלתי נגיש. המהנדס שיודע את היסודות מהיר יותר עם AI; מהנדס שלא יודע את היסודות יעשה טעויות מהר יותר עם AI. תחילה קבע משמעת, ואז קבל את המהירות מ-AI.
לסיכום
בעולם האמיתי, החלקים לא מגיעים אחד אחד אלא שזורים זה בזה בתוך אירוע. בעת ניהול אירוע מגילוי ועד למידה, AI מאיץ בכל שלב: מסמן את האנומליה, מייצר השערות, מציע אפשרויות, טיוטות, מכין נתיחה שלאחר המוות. אבל בכל נקודת החלטה עוצרים - מאשרים את האבחנה, בוחרים לצמצם, מאשרים את השינוי, הבעלים של התוצאה. כלל הזהב ברור: בינה מלאכותית מקדימה בשאלות של "מה קורה, איך לכתוב", ובני אדם מקדימים בשאלות של "האם עלי לעשות את זה, מי הערב?" בזמנים של פאניקה, הגבירו את המשמעת, הפרידו השערות מהראיות, זכרו את מגבלת ההקשר של AI, והפיקו לקח מכל אירוע. המהות של מודול זה היא משפט אחד: AI הוא עוזר חזק; לא ניתן להאציל אחריות הנדסית.
משימת יישום
קחו בחשבון אירוע שחוויתם (או דמיינתם) בעברכם, מתחילתו ועד סופו. עם התבנית "מדריך ניהול אירועים מדורג" למעלה, בקש מה-AI להנחות את האירוע בשלבים של זיהוי-אבחון-הפחתת-פתרון-למידה; בכל שלב, כתוב בנפרד את השלב שאתה יכול להאציל ל-AI ואת השלב שאתה צריך כדי להחליט בעצמך. אשר לפחות השערת AI אחת עם פקודת אימות במהלך שלב האבחון. לבסוף, הפק טיוטה של ניתוח שלאחר המוות וטיוטה של עדכון רונבוק עם התבנית "למידה משולבת לאחר אירוע". סכמו את חלוקת העבודה האנושית-AI בתהליך כולו ב-7 פריטים.
רשימת בדיקה
- [ ] האם חילקתי את האירוע לשלבי גילוי, אבחון, הפחתה, פתרון ולמידה?
- [ ] האם הבחנתי בין שלבים שניתן להאציל לבינה מלאכותית לבין אלה הדורשים קבלת החלטות אנושית בכל שלב?
- [ ] באבחנה, האם הפרדתי את השערת הבינה המלאכותית מהראיות ואישרתי אותה באמצעות פקודת אימות?
- [ ] האם הערכתי את ההפחתה במונחים של הפיכות והחזרה לאחור?
- [ ] האם שמרתי על רפלקס "קרא-אמת-הכן החזרה" גם בזמנים של פאניקה?
- [ ] האם למדתי לקח של נתיחה שלאחר המוות ו-Runbook מהאירוע?
מבחן מודול
1. איזה מהבאים הוא המיקום המדויק ביותר לבינה מלאכותית בניהול מערכות ורשתות?
- א) בינה מלאכותית היא כלי עזר וכלי תומך החלטות; האחריות והאישור הסופי של החלטות ניהוליות קריטיות מוטלות על בני האדם ✔
- ב) בינה מלאכותית יכולה להפעיל פקודות וליישם שינויים בייצור ללא אישור אנושי
- ג) בינה מלאכותית עובדת רק בכתיבת טקסט, אין לה שום קשר לעבודת מערכת ורשת
- ד) בינה מלאכותית תמיד מקבלת החלטות מדויקות יותר מבני אדם, ולכן אימות מיותר
תיאור: בינה מלאכותית היא כלי עזר וכלי תומך החלטות המייצר טיוטות וניתוח כגון סקריפטים, ניתוח יומנים ומסמכים. אחריות ואישור סופי של החלטות מנהלים המשפיעות על זמן השבתה, אובדן נתונים ואבטחה, כגון ביצוע פקודה או אישור שינוי, שייכים למהנדס המוסמך.
2. מהם ארבעת השלבים של רפלקס האימות שיש ליישם לפני הפעלת פקודה שנוצרת על ידי בינה מלאכותית בייצור?
- א) העתק, הדבק, רץ, מקווה
- ב) לקרוא ולהבין, לתעד, לנסות בסביבה מבודדת, להתכונן למשוב ✔
- ג) לייק, שתף, שמור, ארכיון
- ד) מחק, שכתוב, דחיסה, שלח
תיאור: ארבעה שלבים להחלה על פלט קריטי: (1) קרא והבן את שורת הפקודה אחר שורה, (2) קשר את הדגלים והתחביר לתיעוד הרשמי, (3) נסה זאת בסביבת מבודדת/בדיקה, הרצה יבשה אם אפשר, (4) הכן תוכנית חזרה (גיבוי, תמונת מצב) אם היא משתבשת.
3. מה המשמעות של סקריפט אוטומציה להיות 'אימפוטנטי' ולמה זה חשוב?
- א) הסקריפט מייצר תוצאות שונות בכל הפעלה
- ב) הסקריפט יכול לרוץ פעם אחת בלבד ואז להימחק
- ג) התסריט אינו גורם נזק בהפעלה שניה; ✔ בטוח גם אם מופעל שוב
- ד) הסקריפט אינו מכיל ניהול שגיאות
הסבר: אימפוטנציה פירושה שכאשר אותו סקריפט מופעל פעמיים או יותר, הוא אינו גורם נזק או מייצר שגיאות בריצה השנייה. היגיון כגון 'דלג אם המשתמש כבר קיים', 'צור את הספרייה אם היא לא קיימת, אל תיגע בה אם הוא קיים' נוצר. זה מבטיח שהאוטומציה פועלת בבטחה גם אם מופעלת שוב בטעות.
4. מהי הדרך הבסיסית ביותר לאבטח סקריפט המכיל פעולות הרסניות (מחיקה, הפעלה מחדש)?
- א) הפעל את הסקריפט מהר ככל האפשר
- ב) הסתרת הודעות שגיאה
- ג) בדיקת התסריט ישירות בהפקה
- ד) הצבת פעולות הרסניות מאחורי ברירת המחדל היבשה וקשירת היישום בפועל לדגל סימון מפורש ✔
הסבר: שמירה על תהליכים הרסניים במצב ריצה יבשה כברירת מחדל ורק הפעלת האפליקציה בפועל עם דגל אישור מפורש (למשל --apply) מאפשרת לך לראות תחילה מה יקרה כאשר הסקריפט ירוץ. כמו כן בדיקת משתנה null (VAR:?) מונעת שגיאות נתיב.
5. מה המשמעות של העיקרון של 'מתאם אינו סיבתיות' בניתוח לוג?
- א) שני אירועים המשתנים יחד אינם בהכרח בקשר סיבה-תוצאה; יש לוודא גם סיבתיות ✔
- ב) חיפוש מתאם ביומנים זה בזבוז זמן
- ג) משני אירועים המשתנים יחד, אחד הוא בהחלט הגורם לשני.
- ד) סיבתיות יכולה להיקבע רק על ידי בינה מלאכותית
הסבר: זה ששני אירועים מתרחשים בו-זמנית (קורלציה) לא אומר שאחד גורם לשני (סיבתיות); שניהם עשויים להיות תוצאה של אירוע שלישי. ההצעה של ה-AI ש'X כנראה גרם ל-Y' היא השערה ואינה נחשבת לממצא עד שהיא מאומתת במערכת.
6. מדוע מועדף אחוזון (p95/p99) על פני ממוצע בעת מדידת זמן תגובה בניטור ביצועים?
- א) קל יותר לחשב אחוזון מהממוצע
- ב) הממוצע מסתיר את הניסיון הרע של המיעוט; אחוזון חושף את הבעיות הנסתרות הללו ✔
- ג) הממוצע תמיד שגוי ואין להשתמש בו
- ד) אחוזון חל רק על מדדי מעבד
הסבר: ממוצע מסתיר את החוויה הרעה מאוד שיש לחלק קטן מהמשתמשים. למרות שנראה שהממוצע הוא 200 אלפיות השנייה, p99 עשוי להיות 6 שניות; זה אומר שאחת מכל מאה בקשות היא איטית להחריד. אחוז מראה את כאבו של המיעוט הזה המוסתר על ידי הממוצע.
7. מהו 'דריפט' בניהול תצורה ולמה זה מסוכן?
- א) תעבורת הרשת יורדת בלילה
- ב) העברה פיזית של שרת
- ג) שרתים חורגים זה מזה ומהתקן לאורך זמן; ✔ בלתי נראה עד שמתרחשת בעיה
- ד) גיבוי אוטומטי של קבצי תצורה
תיאור: דריפט היא סטייה של שרתים זה מזה ומהתקן דרך שינויים ידניים לא מתועדים לאורך זמן. הסכנה שלו היא השתיקה שלו: הוא לא נראה עד שהבעיה מתרחשת, אז שרת אחד מתנהג אחרת מהאחרים והאבחון לוקח שעות. AI הופך את הסחף לגלוי בהשוואה; עקרון ריתוך זהב מונע.
8. מדוע שלב ה'תוכנית' הוא מעקה הבטיחות החיוני ביותר בכלי IaC (כמו Terraform)?
- א) התוכנית מריץ את הקוד מהר יותר
- ב) מוחק את קובץ מצב התוכנית
- ג) התוכנית מתקנת רק עיצוב קוד
- ד) התוכנית מראה מה יתווסף, ישונה וימחק לפני היישום; מונע אובדן נתונים ✔
תיאור: תכנית (תכנית terraform / ansible --check) נותנת תצוגה מקדימה של 'מה ישתנה' לפני ביצוע הקוד: כמה משאבים יתווספו, ישתנו, יימחקו. בפרט, הקווים 'השמד' ו'אלץ החלפה' מציינים את הסיכון לאובדן נתונים לפני היישום. הגשת מועמדות מבלי לקרוא את התוכנית היא אחת הטעויות היקרות ביותר.
9. מדוע צריך להגן בקפידה על קובץ המצב של Terraform ולא להדביק אותו ב-AI או במאגרים פתוחים?
- א) סודות טקסט פשוטים עשויים להיכלל בתיק המדינה; אם ידלוף, פרטי זהות ייחשפו ✔
- ב) כי קובץ המצב גדול מדי
- ג) קובץ המצב כבר מוצפן באופן בלתי קריא.
- ד) הקוד פועל מהר יותר כאשר קובץ המצב משותף
תיאור: קובץ המצב שומר על המצב הנוכחי של התשתית המנוהלת ויכול לכלול סודות טקסט רגיל (סיסמאות מסד נתונים, מפתחות). לכן, יש לשמור אותו בקצה אחורי מרוחק מוצפן, מוגבל גישה, נעול; אסור להכניס אותו לרכב ציבורי או למאגר, אחרת הסוד ידלוף.
10. מה מדגישה בתיעוד ההצהרה 'ספר הפעלה שגוי מסוכן יותר מאין פנקס הפעלה'?
- א) כתיבת ספר רצים זה בזבוז זמן
- ב) ספר הפעלה שלא נבדק מיושם באופן עיוור במשבר; צעד שגוי אחד יכול להוביל לאסון ✔
- ג) ספרי הפעלה נכתבים למנהלים בלבד
- ד) אין לעדכן את התיעוד
הסבר: צוות ללא רונבוק זהיר וחשדן במהלך משבר; אבל האדם עם ספר הפעלה 'רשמי' מיישם אותו תחת לחץ ללא חקירה. אם ספר ההפעלה לא נבדק ויש בו צעד אחד שגוי, יישום עיוור יוביל לאסון. זו הסיבה שכל ספר הפעלה חייב להיבדק ביסודיות ולהחתים אותו בסביבה אמיתית.
11. בתחזוקה חזויה, מהי הגישה הנכונה להבין מתי דיסק מתקרב לכשל?
- א) החלף מיד דיסק SMART פגום בודד
- ב) התעלמות מוחלטת מנתוני SMART
- ג) הסתכלות על מגמת הערכים לאורך זמן; ✔ הגדלת ספירת האותות עקבית ומאיצה
- ד) נקיטת פעולה רק לאחר שהדיסק התמוטט לחלוטין
הסבר: קריאת SMART גרועה אחת אינה סיבה לפאניקה; זה נורמלי שלדיסקים יתוקנו שגיאות מדי פעם. האות האמיתי הוא המגמה: עלייה עקבית ומואצת של ערכים כמו מגזר שהוקצה מחדש לאורך זמן. זו הסיבה שה-AI מקבל סדרת זמן, לא קריאה אחת.
12. מהם שני החלקים שהכי מתעלמים מהם אך הקריטיים בשינוי ייצור?
- א) צבע ושם השינוי
- ב) תואר ומחלקה של מבצע השינוי
- ג) הודעה על השינוי ברשתות החברתיות
- ד) תוכנית החזרה וקריטריונים לאימות הצלחה ✔
הסבר: אם אין תשובה כתובה לשאלות 'איך בדיוק אני חוזר לאחור אם זה מתקלקל' (תוכנית החזרה לאחור) ו'איך אני מוכיח שזה מוצלח' (קריטריונים לאימות הצלחה) לפני יישום שינוי, השינוי הזה עדיין לא מוכן. ללא שני אלה, שינוי שבור עשוי להיחשב 'שלם'.
13. מדוע מועדפת גישת ה'קנרית' במקום פריסת אבטחה (גרסה/תיקון חדש) לכל השרתים בו זמנית?
- א) השינוי מוחל תחילה על חלק קטן; באג משפיע על חלק קטן, לא על כל הצי, והוא נתפס מוקדם ✔
- ב) הפצה קנרית צורכת פחות חשמל
- ג) Canary הופך את אימות הפריסה למיותר לחלוטין
- ד) פריסה קנרית חלה רק על מסדי נתונים
תיאור: פריסת קנרי מיישמת את השינוי על חלק קטן (שרת אחד, 5% מהמשתמשים) תחילה ובקרה. בדרך זו, באג משפיע על חלק קטן, לא על כל הצי, והוא נתפס מוקדם. באג שמתפשט בבת אחת פוגע בכל המשתמשים בו זמנית.
14. מהו הכלל האתי והמשפטי הבלתי ניתן לשינוי בעת שימוש בבינה מלאכותית בעבודת אבטחה?
- א) ניתן להשתמש בבינה מלאכותית באופן חופשי כדי לסרוק פגיעויות בכל מערכת
- ב) הקוד האתי חל רק על מוסדות גדולים
- ג) הוא משמש רק במערכות מורשות ולמטרות הגנה; שימוש לגישה לא מורשית או תקיפה הוא פשע ✔
- ד) זה חופשי לחדור למערכת של מישהו אחר כדי ללמוד.
תיאור: מידע מערכת ורשת הוא שימוש כפול. ניתן להשתמש בבינה מלאכותית רק במערכות שעבורן יש לך הרשאה בכתב ולמטרות הגנה (זיהוי איומים ביומן, התקשות, תגובה לאירועים). שימוש בו כדי לסרוק או לחדור למערכת שאינה שייכת לך הוא גישה בלתי מורשית ופשע; יש להשתמש במעבדה מבודדת כדי ללמוד.