אחריות על אפליקציה פעילה
אתר המאפייה של אליס באוויר. ואז, בשלוש לפנות בוקר, הטלפון שלה מתחיל לזמזם.
בסיום השיעור תוכלו לזהות אילו תקלות הכי חשובות לאפליקציה שלכם ולהחליט איך תזהו אותן ואיך תגיבו.
מפו סיכונים עם חשבונות בדיקה, נתונים מדומים וסביבת בדיקות (staging). אף פעם אל תריצו תרגילי תקלות מול משתמשים אמיתיים.
אפליקציה פעילה צריכה יותר מדמו שעובד. כמעט כל חירום באמצע הלילה מגיע מאחד משישה גורמים. תנו לכל אחד שם, ראו במה staging (עותק פרטי של האפליקציה לבדיקות) שונה מ־production, והבינו למה גרסה ראשונה קטנה קל יותר להחזיק באוויר.
מה נלמד בשיעור
- 1תנאי סף להשקה: מה חייב להתקיים קודם
תנאי הסף להשקה הם רשימה קצרה וכתובה של בדיקות. כל אחת חייבת לעבור, עם הוכחה, לפני שמשתמשים אמיתיים נכנסים. מישהו אחראי על הרשימה, ובדיקה שנכשלת עוצרת את ההשקה.
- 2מה מעיר אתכם בשלוש לפנות בוקר
כמעט כל חירום בסביבת ייצור מגיע מאחד משישה מקורות: פריסה גרועה, תקלה אצל ספק, טעות בנתונים, דליפת מידע סודי או ניצול לרעה, עלויות שיוצאות משליטה, או משהו שפג תוקפו.
- 3התאמה בין סביבות וסטייה מההתאמה
סביבת בדיקות (staging) היא עותק פרטי של האפליקציה עם נתוני בדיקה משלו, ושם מנסים שינויים לפני שמשתמשים אמיתיים רואים אותם. התאמה בין סביבות אומרת ש־staging זהה ל־production בכל מה שמשפיע על ההתנהגות: גרסאות, שירותים, הגדרות ואופן הפריסה. הנתונים עדיין נפרדים, ובדרך כלל יש פחות קיבולת. סטייה (drift) היא פער שלא תכננתם ושגדל עם הזמן.
- 4ניהול מידע סודי בסביבת ייצור
ניהול מידע סודי זה לא רק להסתיר אותו. לכל מפתח יש אחראי, ערך נפרד לכל סביבה, הרשאות מינימליות, רישום של מי יכול לקרוא אותו ותאריך החלפה.
- 5היקף התכונות כתקציב סיכונים
כל תכונה מביאה איתה קוד לבדוק, נתונים להגן עליהם, חשבון לשלם ועוד משהו שיכול להתקלקל בלילה. תחשבו על ההיקף כעל תקציב: מוסיפים תכונה רק אם אתם יכולים לומר מה הסיכונים שלה ומי אחראי עליהם.