אימות פרוד, אסטרטגיות שחרור וזרימת AI מקצה לקצה

רווחים:

• הבנת אסטרטגיות שחרור להפחתת סיכונים (כחול-ירוק, כנרית, דגל תכונה) ומשמעת אימות המוצר (בדיקת בריאות, בדיקת עשן, ניטור אות זהב)
• יכולת ליישם את ההרגל של הכנת תוכנית החזרה ברורה לפני הפריסה ואימות נתיבים עסקיים קריטיים לאחר הפריסה
• יכולת לשלב את כל החלקים שנלמדו לאורך המודול בזרימת עבודה הנתמכת בינה מלאכותית מקצה לקצה וליישם את העיקרון של 'AI מייצר, בני אדם מאמתים ומתחייבים' בכל שלב

כל המודול הזה זרם לעבר נקודה אחת: אספקה ​​בטוחה של קוד ותשתית לייצור (הסביבה החיה המשמשת לקוחות אמיתיים). כעת אנו נמצאים בחוליה הכי קריטית ומלחיצה בשרשרת: קבלת שינוי בשידור חי ומוודא שהוא אכן עובד שם. טעות כאן אינה מופשטת - היא פוגעת ישירות בלקוח, בהכנסות ובמוניטין. זו הסיבה שצוותים בוגרים הולכים לייצור לא על ידי "תקווה" אלא עם אסטרטגיות שחרור מבוקרות ואימות שיטתי.

ביחידה הסופית הזו אנו משלבים שני דברים: (1) שיטות שחרור המפחיתות סיכון (כנרית, כחול-ירוק, דגל תכונה) והמשמעת של אימות פרוד; (2) איך כל חלק שלמדנו במהלך המודול - CI/CD, IaC, קונטיינר, ניטור, תקרית, עלות, סקריפט, אבטחה - מתחבר לזרימת עבודה אחת מקצה לקצה המופעלת על ידי AI. בואו נחזור על הציטוט הראשוני פעם אחרונה: AI מייצר ומאיץ טיוטות בכל שלב; אבל אתה זה שלוחץ על כפתור "אני לוקח את זה בשידור חי" ומבטיח את התוצאה.

שחרור אסטרטגיות המפחיתות סיכון

דחיפת שינוי לכל המשתמשים בו זמנית היא הדרך המסוכנת ביותר. שיטות בוגרות:

• פריסה כחול-ירוק: נשמרות שתי סביבות זהות - "כחול" (חי) ו"ירוק" (גרסה חדשה). הגרסה החדשה מוכנה ונבדקת בירוק, ואז התנועה עוברת לפתע לירוק. אם יש בעיה, התנועה חוזרת מיד לכחול. החזרה מהירה היא היתרון הגדול ביותר שלו.
• פריסה קנרית: הגרסה החדשה משוחררת לראשונה לאחוז קטן מהמשתמשים (למשל 5%); אם המדדים טובים, הגדל בהדרגה ל-100%. בעיה משפיעה על חלק קטן מהמשתמש, לא על כל המשתמש.
• דגל תכונה: התכונה החדשה מכניסה את הקוד אך נחסמת על ידי דגל; הוא נפתח למשתמשים מסוימים כאשר הם מתבקשים. יש הבחנה בין פריסה ל"שחרור"; אם יש בעיה, הדגל כבוי מבלי להחזיר את הקוד לאחור.

טיפ: רשת הביטחון המהירה ביותר היא להיות מוכן להחזרה לאחור לפני כל פריסה. "אם משהו משתבש, איך אוכל לחזור לגרסה הישנה תוך 60 שניות?" אם אין תשובה ברורה לשאלה, אינך מוכן לבצע את הפריסה הזו.

אימות פרוד: העבודה לא מסתיימת כשהפריסה מסתיימת

זה שהפריסה נראית "ירוקה" לא אומר שהיא עובדת. אימות שיטתי:

1. בדיקות בריאות: האם השירות פעיל, האם /healthz מגיב?
2. מבחני עשן: האם מעט נתיבי המשתמש הקריטיים ביותר (כניסה, תשלום, חיפוש) אכן עובדים? אוטומטי ומהיר.
3. צפו לאותות מוזהבים: שיעור שגיאות לאחר פריסה, זמן אחזור, האם התעבורה תקינה? (ארבעה אותות ביחידה 6.)
4. הרחב בהדרגה: הסתכל על מדדים בכל שלב כשאתה מגדיל את האחוז הקנרי.
5. חלון תצפית: מעקב מקרוב למשך פרק זמן (למשל 30 דקות) לאחר הפריסה; בעיות ערמומיות אינן נראות מיד.

זהירות: ה-AI עשוי להפיק רשימה של בדיקות עשן או אימותים, אך תפקידך לקבוע אילו נתיבי משתמש הם "קריטיים". AI נותן רשימה כללית; רק אתה יודע שצריך לבדוק את תזרים התשלומים שלך, הנתיב המניב ביותר שלך.

השוואת אסטרטגיות שחרור

אסטרטגיה

יתרון עיקרי

עלות/מורכבות

הכי מתאים

כחול-ירוק

החזרה מיידית

שתי סביבות = פי 2 משאבים

אם שליפה מהירה היא קריטית

כנרית

מגביל את ההשפעה לפרוסה קטנה

נדרש ניהול תנועה

בסיס משתמשים עצום

FeatureFlag

מפריד בין פריסה לשחרור

חוב ניהול דגל

פתיחה הדרגתית/ממוקדת

עדכון מתגלגל

פשוט, ידידותי למשאבים

החזרה איטית

שירותים פשוטים

זרימת עבודה מבוססת AI מקצה לקצה

עכשיו בואו נשלב את כל המודול לזרימה אחת. נניח שאתה מפרסם מיקרו-שירות חדש. AI מייצר טיוטות בכל שלב; אתה מאמת בכל שלב:

1. קוד ומכל (יחידה 4): AI מייצר קובץ Dockerfile אופטימלי ומאובטח; אתה מאמת את האי-סוד ואת הגודל.
2. CI/CD (יחידה 2): כותב את צינור הניסוי-בנה-פריסה של AI; אתה מצמצם את ההרשאות ובודק את ההפניות הסודיות.
3. תשתית (יחידה 3): מגדיר את המשאבים הנדרשים עם AI Terraform; אתה קורא את פלט התוכנית ולא מחפש מחיקות בלתי צפויות.
4. תזמור (יחידה 5): AI מייצר מניפסטים של Kubernetes; אתה מאמת את מגבלת המשאבים, הבדיקה וה-RBAC.
5. אבטחה (יחידה 10): מתן עדיפות לפלטי סריקת בינה מלאכותית; אתה תופס קודם את הניתנים לניצול.
6. ניטור (יחידה 6): AI מייצר כללי אזעקה ולוח מחוונים; אתה בודק את הספים עם נתוני העבר שלך.
7. שחרור ואימות (יחידה זו): מתאר את מבחן העשן בינה מלאכותית ותוכנית החזרה לאחור; אתה מתחיל קנרי, צפה במדדים, לחץ על הכפתור.
8. אם מתרחש תקרית (יחידה 7): בינה מלאכותית מייצרת השערה וסקיצה שלאחר המוות; אתה מאמת ולומד את הלקחים.
9. עלות (יחידה 8): AI עוקב אחר בזבוז משאבים חדשים; אתה מקבל את ההחלטות בגודל הנכון.

בכל שלב, הכלל המשותף נשאר קבוע: בינה מלאכותית מייצרת ומאיצה, אנושי מאמת ומבטיח. זו המהות של המודול.

שלושה מיני תיקים

מקרה 1 - הקנרית הגבילה אסון ל-5%. צוות נתן את הגרסה החדשה ל-5% משתמשים עם קנרית. לוח המחוונים שה-AI ייצר הראה מיד ששיעור השגיאות קפץ ל-8% בנתח זה. הצוות לקח אותו בחזרה מבלי להגדיל אותו ל-100%; הבעיה השפיעה רק על 5% מהמשתמשים, וזה היה לכמה דקות. אם הייתה פריסת מפץ גדול, כל הלקוחות היו מושפעים.

מקרה 2 - בדיקת עשן תפסה את הנתיב החסר. AI הציעה ערכת בדיקת עשן, אך לא הייתה לו זרימת "תשלום". המהנדס הוסיף זאת, בידיעה שזרם ההכנסות הקריטי ביותר הוא תשלום. הבדיקה שלאחר הפריסה נשברה ממש בשלב התשלום - פג תוקף מפתח של צד שלישי. האימות תפס אובדן שקט של הכנסה בתוך דקות.

מקרה 3 - חזרה מוכנה נשמרת תוך 90 שניות. צוות שהתקין כחול-ירוק לקח את הגרסה החדשה לירוק; לאחר 2 דקות העיכוב הוכפל. הם הפכו את התנועה לכחול תוך 90 שניות עם החזרה שהכינו מראש. הם מצאו את הסיבה (שאילתה איטית בגרסה החדשה) לא בלחץ, ואז בשלווה. המסלול המוכן לאחור הפך את ההפרעה לכמעט בלתי נראית.

ארבע תבניות הניתנות להעתקה

1) בחירת אסטרטגיית שחרור:

אני אדרבן את השירות הבא: [SERVICE/CONTEXT: מספר משתמשים, סובלנות להפסקות, תשתית]. על איזה מהם אתה ממליץ בין דגלים כחול-ירוק, קנרי ודגל עליון? השווה את היתרונות, העלויות ומהירות החזרה לאחור של כל אחד בהקשר זה. תן הצעה, אבל ציין שאני אקבל את ההחלטה הסופית.

2) בדיקת עשן / רשימת אימות:

הפק טיוטה של בדיקת עשן ורשימת אימות עבור [SERVICE] שאפעיל לאחר הפריסה: בדיקת תקינות, נתיבי המשתמש הקריטיים ביותר, אילו מדדים עלי לנטר במשך כמה דקות? נניח שאסמן את הנתיבים העסקיים הקריטיים ביותר ואשאיר את השדה הזה ריק.

3) תוכנית החזרה לאחור:

אני משתמש ב-[DEPLOY METHOD]. כתבו לי תוכנית החזרה ברורה: עם איזה פקודה/שלב אני חוזר לגרסה הישנה, ​​כמה זמן זה לוקח, מה הסיכונים של החזרה עצמה (למשל, לא ניתן לבטל העברת מסד נתונים), מה עליי לבדוק לפני החזרה?

4) רשימת בדיקה מקצה לקצה:

הפק רשימת הכנה מקצה לקצה לשחרור לפרויקט [SERVICE] חדש: אבטחת קוד/תמונה, צנרת, תוכנית תשתית, ניטור והזעקה, סריקת אבטחה, אסטרטגיית שחרור, החזרה ואימות. סמן כל פריט בשאלה "האם אני מוכן?" הפוך את זה לשאלה.

הנחיה חלשה / הנחיה חזקה

חלש: "איך אני מכניס את זה לפרוד?"

תוצאה: אין הקשר; בינה מלאכותית מפרטת את שלבי הפריסה הכלליים, היא אינה מתייחסת לסובלנות הסיכון, קנה המידה של המשתמשים והצורך לאחור.

Güçlü: "אני אדרבן שירות תשלומים עם 10 מיליון משתמשים, הסובלנות שלי להשבתה נמוכה מאוד. האם אתה ממליץ על Canary או Blue-Green, למה? אילו נתיבים קריטיים עלי לבדוק לאחר הפריסה, אילו מדדים עלי לנטר במשך כמה דקות, ואיך אמורה להיות תוכנית החזרה של 60 שניות? אני אקבל את ההחלטה הסופית".

הבדל: ההנחיה השנייה נותנת את קנה המידה, הסובלנות והציפיות לחזרה לאחור; זה דורש אסטרטגיה + אימות + ביטול ומשאיר את ההחלטה בידי האדם.

טעויות נפוצות

• פריסה ללא תוכנית החזרה. אם אין דרך חזרה, כל פריסה היא הימור.
• פריסת המפץ הגדול. מתן אותו לכל המשתמש בבת אחת ממקסם את הסיכון.
• בהנחה ש"ירוק = עובד". השירות שעבר את בדיקת הבריאות עלול להישבר בנתיב הקריטי.
• חושב שאתה עוזב נתיבים עסקיים קריטיים לבינה מלאכותית. עליך לסמן את השיטות כגון תשלום.
• אין פיקוח לאחר פריסה. בעיות ערמומיות אינן מופיעות בדקה הראשונה; נדרש חלון תצפית.
• חושב שהגירת מסד נתונים היא הפיכה. חלק מהשינויים אינם חוזרים לאחור; מתוכננים בנפרד.

לסיכום

היציאה לדרבן היא החוליה הקריטית ביותר בשרשרת והיא נעשית לא על ידי "תקווה" אלא באסטרטגיות מבוקרות: כחול-ירוק מספק החזרה מיידית, מגביל את האפקט הקנרי לפרוסה קטנה, מפריד בין פריסת דגל תכונה לשחרור. העבודה לא הסתיימה עם סיום הפריסה; אימות שיטתי באמצעות בדיקות תקינות, בדיקות עשן וניטור אותות זהב הוא חיוני. בינה מלאכותית מייצרת ומאיצה טיוטות בכל שלב לאורך המודול כולו - מ-Dockerfile לצינור, מ-Terraform ועד כלל אזעקה, מהנתיחה שלאחר המוות ועד לניתוח עלויות. אבל נשאר האדם המוסמך שמאמת כל שלב, לוחץ על כפתור המעבר לחיות ומבטיח את התוצאה. זהו כלל הזהב של DevOps המופעלים על ידי AI מקצה לקצה.

משימת יישום

בחר שירות (אמיתי או בדיוני) לפרסום בו. (1) בחר אסטרטגיה שמתאימה להקשר שלך עם התבנית "בחירת אסטרטגיה לשחרור" וכתוב מדוע. (2) צור רשימת אימות עם התבנית "בדיקת עשן / רשימת אימות" והוסף את הנתיבים העסקיים הקריטיים ביותר בעצמך. (3) הכינו תכנית החזרה של 60 שניות עם תבנית "תכנית החזרה לאחור" ובדקו אם יש בה שלבים בלתי הפיכים.

רשימת בדיקה

• [ ] בחרתי באסטרטגיית שחרור (כנרית/כחול-ירוק/דגל) שמתאימה להקשר שלי.
• [ ] יש לי תוכנית החזרה ברורה ומהירה מוכנה לפני הפריסה.
• [ ] הוספתי את הנתיבים העסקיים הקריטיים ביותר (למשל תשלום) למבחני העשן שלי בעצמי.
• [ ] לאחר הפריסה, אני עוקב אחר אותות הזהב דרך חלון תצפית.
• [ ] תכננתי גם שלבים בלתי הפיכים (העברת מסד נתונים וכו').
• [ ] אימתתי את תוכנית הבינה המלאכותית בכל שלב; קיבלתי את ההחלטה לעבור לשידור חי.

מבחן מודול

1. איזה מהבאים הוא המיקום הטוב ביותר עבור DevOps ו-AI בענן?

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

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

2. מהו הביטוי המדויק ביותר לדיסציפלינת האימות לפני יישום פקודת או תצורה של DevOps שהופקה על ידי בינה מלאכותית?

• א) אם הפלט נראה חלק ובטוח ניתן להפעיל אותו ישירות בפרוד
• ב) הפלט בטוח רק אם אין שגיאות תחביר, אין צורך בבדיקות נוספות
• ג) חבר את הפלט למקור, תכנן/הפעל יבש וסנן אותו עם הקשר המערכת שלך; לאחר מכן הגש ✔
• ד) ביצוע הניסיון הראשון ישירות בפרוד וצפייה בתוצאה הוא האימות המהיר ביותר

הסבר: אימות תלת-שלבי חיוני: חיבור הפלט למקור (האם הפקודה/הדגל נמצא בפועל במסמכים הרשמיים), הפעלתו יבשה (לראות מה קורה עם התוכנית/--dry-run), והעברתו דרך מסנן המערכת (האם זה מתאים להקשר הארכיטקטוני והביטחוני שלו). שטף אינו אומר דיוק.

3. מהי הגישה הנכונה כששואלים בינה מלאכותית על שגיאה או בעיית פריסה בקובץ .env המכיל סיסמת מסד נתונים אמיתית?

• א) מסכה סודות אמיתיים עם <PLACEHOLDER>; שתף רק שגיאה והקשר מוסווה ✔
• ב) הדבקת כל קובץ ה-env כפי שהוא פותר את הבעיה מהר יותר
• ג) מכיוון שהסודות הם כבר base64, זה בטוח להדביק רגיל
• ד) הדבקת הסיסמה בטוחה מכיוון שבינה מלאכותית אף פעם לא מאחסנת אותה

תיאור: לא מודבקים סודות אמיתיים בהנחיית הבינה המלאכותית. ערכים כמו סיסמאות ואסימונים מוסווים עם <PLACEHOLDER>; רק הודעת השגיאה וההקשר הדרוש משותפים. אם הסוד כבר הודלף, יש לבטלו ולסובב אותו מיד.

4. איזה מהבאים הוא הניהול הנכון של סודות (סיסמה, אסימון) בצינור CI/CD?

• א) הוא נשמר במאגר הסודי של הפלטפורמה ונקרא בהפניה (למשל ${{ secrets.X }}), לא כתוב בטקסט רגיל ✔
• ב) נכתב בטקסט פשוט לצינור YAML מטעמי נוחות
• ג) זה מאומת על ידי לחיצה על הד ויומן בתחילת כל עבודה.
• ד) אם מוגדר עם ההרשאה הרחבה ביותר (כתוב הכל), האבטחה עולה

הסבר: סודות אינם נכתבים ל-YAML בטקסט פשוט; הוא נשמר במאגר הסודי של הפלטפורמה ונקרא עם הפניות כגון ${{ secrets.X }}. בנוסף, עם עיקרון הסמכות הקטנה ביותר, הרשאות אסימונים מצטמצמות והיומן הסודי אינו מתועד.

5. בניהול תשתיות עם Terraform, מהו הצעד הקריטי ביותר שיש לעשות לפני יישום שינוי חי?

• א) הפעלת 'terraform application' ישירות; התוכנית היא בזבוז זמן
• ב) גיבוי קובץ המדינה למאגר ציבורי
• ג) הפעל את 'תוכנית terraform' ובדוק את קווי ההרס/החלפה בפלט, ולאחר מכן החל ✔
• ד) הסר את ההתקנה של גרסת הספק וודא שהגרסה החדשה ביותר מגיעה אוטומטית

הסבר: יש להפעיל את 'תוכנית טרפורם' לפני 'יישום טרפורם'. התוכנית מראה מה להוסיף, מה לשנות, ובעיקר מה למחוק (להרוס), מבלי לעשות דבר. אם נראה קו הרס או החלפה בלתי צפוי, אין ליישם את החלה.

6. מה זה אומר ומה צריך לעשות אם שורת '-/+ replace' עבור מסד הנתונים הייצור מופיעה בפלט תוכנית Terraform?

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

הסבר: '-/+ replace' פירושו שהמשאב יימחק ויווצר מחדש; עבור מסד נתונים, זה אומר אובדן נתונים. אם לא צפוי, יש להפסיק את היישום, להמיר את השינוי לשיטה בטוחה, או להשאיר את השדה הבלתי ניתן לשינוי.

7. מה מהבאים נכון ל-Dockerfile להיות מוכן לייצור מבחינת האבטחה והגודל שלו?

• א) מטעמי נוחות, הטמעת הסוד בתמונה עם ENV והרצה כשורש
• ב) השתמש תמיד בתג ':latest' ושמור על תמונת הבסיס גדולה ככל האפשר
• ג) בנייה חד-שלבית והשארת כל כלי הבנייה בתמונה הסופית
• ד) לא להטביע את הסוד, לעבוד עם משתמש לא מורשה, באמצעות תמונת בסיס קטנה ויציבה ובנייה מרובה שלבים ✔

תיאור: תמונה מוכנה לייצור: אינה מטביעה את הסוד (מזריקה אותו בזמן ריצה), פועלת עם USER לא מורשה במקום שורש, משתמשת בתמונת בסיס קטנה ובעלת גרסה (דקה/אלפינית, לא :לאחרונה), ומוקטנת עם בנייה מרובה שלבים. זה גם נסרק לאיתור פגיעויות לפני הפרסום.

8. מהו הסיכון החשוב ביותר באי הגדרת מגבלות משאבים עבור פריסה ב- Kubernetes?

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

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

9. כיצד להימנע מ'עייפות התראה' במעקב ובהגדרת אזעקה?

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

תיאור: כל אזעקה חייבת להיות ניתנת לפעולה ובדחיפות הנכונה; מידע שאינו מצריך פעולה מוצג על הלוח, הוא לא מעיר אף אחד. ספי אזעקה נבדקים מול הנתונים ההיסטוריים של המערכת ומאוחדות אזעקות מיותרות/חוזרות על עצמן. כך האזעקה האמיתית לא תלך לאיבוד ברעש.

10. מהי הזמנת העדיפות הטובה ביותר במהלך אירוע ייצור?

• א) ראשית יש למצוא את הסיבה המדויקת לשורש ולצמצם אותה רק כאשר הסיבה ברורה.
• ב) תחילה כתוב את דוח הנתיחה שלאחר המוות, ולאחר מכן גע בשירות
• ג) צמצם תחילה (שירות שחזור/שחזור), השארת ניתוח סיבת שורש למועד מאוחר יותר ✔
• ד) ראשית למצוא את האחראי לאירוע ולדווח עליו

הסבר: כלל הזהב הוא 'קודם לצמצם, לחקור אחר כך'. המטרה היא קודם כל לשחזר את השירות או להחזיר אותו לגרסה ידועה-טובה (להפחית); ניתוח סיבת השורש נעשה ברוגע לאחר שהלחץ שוכך. המתנה למציאת סיבת השורש המדויקת מגדילה את זמן ההחלמה (MTTR).

11. מהי המטרה העיקרית של תרבות שלאחר המוות חסרת האשמה?

• א) זיהוי מי שעשה את הטעות והטלת האחריות עליו/ה
• ב) התמקדות במערכות ובתהליכים ועידוד למידה; ✔ הפקת לקחים המונעים חזרה ולא האשמה
• ג) לעולם אל תדווח על האירוע ותוודא שהוא נשכח
• ד) כתיבת פרטים טכניים בלבד ואי הוספת פריטים ברי פעולה

הסבר: נתיחה שלאחר המוות ללא תמים מתמקדת בשאלה 'איזו מערכת ותהליך אפשרו את הטעות הזו', ולא 'מי עשה את זה'. אנשים חולקים את הטעות בגלוי אם הם יודעים שהם לא ייענשו; השגיאה הנסתרת חוזרת על עצמה. הדוח אינו דוח האשמה, אלא מסמך למידה מלא בפריטים מכווני פעולה.

12. באופטימיזציה של עלויות ענן (FinOps), מה הצעד ההגיוני ביותר לעשות לפני המעבר להנחות מחויבות (תוכנית שמורה/חסכון)?

• א) תחילה קחו את ההתחייבות הארוכה ביותר האפשרית, חשבו על בזבוז אחר כך
• ב) ראשית, נקו את הפסולת (סגירת סרק, גודל נכון), ולאחר מכן התחייבו לשימוש מחויב ✔
• ג) העבר את כל המשאבים לקיבולת Spot באופן מיידי
• ד) מחיקת הפריט היקר ביותר מבלי לעיין בנתוני החשבונית

הסבר: יש לנקות תחילה פסולת (סגירת משאבים סרק, צמצום משאבים גדולים מדי). אחרת, תנעל את השימוש המבוזבז במחיר מוזל למשך 1-3 שנים. גודל נכון וניקוי סרק אינם דורשים התחייבות והם קרובים ללא סיכונים.

13. מהו אמצעי האבטחה החשוב ביותר אם לסקריפט המוצע על ידי AI יש את השורה 'rm -rf "$DIR"/'?

• א) הפעלת הסקריפט ישירות בפרוד מבלי לקרוא אותו תאיץ
• ב) הוסף set -euo pipefail ובקרת משתנה ריקה ונסה קודם עם הפעלה יבשה ✔
• ג) די בקיצור שם המשתנה
• ד) שימוש ב-rm -rf --force במקום rm פותר את הבעיה

הסבר: אם $DIR ריק, הצהרה זו עשויה לנסות למחוק את ספריית השורש. עצירה במשתנה הלא מוגדר עם 'set -u' ובדיקה שהמשתנה אינו ריק לפני מחיקתו (למשל [ -n "$DIR" ] || יציאה 1) מונעת אסון. בנוסף, יש לנסות פעולות הרסניות עם ריצה יבשה תחילה.

14. מה הדבר הראשון שצריך לעשות אם מפתח גישה לענן דולף בטעות למאגר ציבורי?

• א) בטל מיד וחדש (סובב) את המפתח; מחיקה לבד לא מספיקה ✔
• ב) פשוט מחק את הקובץ מהאחסון והמפתח בטוח
• ג) לא עושה כלום כי אף אחד לא ראה את זה
• ד) הפיכת האחסון לפרטי מבטלת את הצורך לסובב את המפתח

הסבר: יש לבטל את הסוד שדלף ולסובב מיד. רק מחיקת הקובץ אינה מספיקה כי הסוד נשאר בהיסטוריה של Git ומאגרים ציבוריים נסרקים על ידי בוטים תוך שניות. לאחר ביטול/החזרה, ההשפעה מוערכת ומתווסף סורק סודי למניעת הישנות.

15. איזו מהגישה הבאה ממזערת את הסיכון בעת ​​שחרור גרסה חדשה של Prod?

• א) מתן הגרסה החדשה לכל המשתמשים בו-זמנית (ביג-מפץ) ולא הכנת תוכנית החזרה לאחור
• ב) בהתחשב שהפריסה הסתיימה ברגע שהיא מופיעה 'ירוק', לא לבצע אימות נוסף
• ג) שימוש באסטרטגיה מבוקרת כמו קנרית/כחול-ירוק/דגל תכונה, תוכנית החזרה מוכנה ובדיקת עשן + ניטור מטרי לאחר הפריסה ✔
• ד) השארת בדיקת נתיבים עסקיים קריטיים לחלוטין לבינה מלאכותית ולא קביעתם כלל.

הסבר: אסטרטגיות שחרור מבוקרות (החל מאחוז קטן עם קנרית, החזרה מיידית עם כחול-ירוק, הפרדת פריסה לשחרור עם דגל תכונה) מגבילות את הסיכון. בנוסף, תוכנית החזרה ברורה לפני פריסה וניטור אותות זהב עם בדיקת עשן לאחר פריסה חיוניים; 'נראה ירוק' לא אומר שזה עובד.