הנדסת אמינות אתר - קורס 65,000 רובל. מ-Slurm, הדרכה, תאריך 1 בינואר 2024.

instagram viewer

יום 1: מפגש הפתיחה של AMA

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

פתיחה של 2 נושאים תיאורטיים:

נושא 1: ניטור

• מדוע יש צורך במעקב?
• אחוזים
• מתריע
• יכולת תצפית

נושא 2: תורת SRE

• SLO, SLI, SLA
• עֲמִידוּת
• תקציב שגיאה

יום 2: ניתוח פרקטיקות ומקרים

תרגול: יצירת לוח מחוונים בסיסי והגדרת ההתראות הדרושות

תרגול: הוספת התראות SLO/SLI + ללוח המחוונים

תרגול: טעינת מערכת ראשונה

פתרון מקרה 1: תלות במורד הזרם.

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

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

יום 3: מפגש AMA, תשובות לשאלות

הגישה למודול התיאורטי השני נפתחת:

פתרון בעיות בסביבה ובארכיטקטורה

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

נושא 3: ניהול תקריות

• הנדסת חוסן
• איך מתגבשים מכבי אש
• עד כמה הצוות שלך יעיל בתקרית?
• 7 כללים למנהיג אירוע
• 5 כללים לכבאי
• HiPPO - חוות דעתו של האדם בעל השכר הגבוה ביותר. מנהיג תקשורת

טנושא 4: כלי Varrum וניהול התראות.

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

יום 4: ניתוח פרקטיקות ומקרים

פתרון למקרה 2: תלות במעלה הזרם.

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

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

פתרון למקרה 3: בעיות במסד הנתונים.

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

דרך התיק, תרגישו את כל הכאב של איתור באגים ותלמדו איך למנוע בעיות כאלה.

תרגול: אנו כותבים נתיחה שלאחר המוות על המקרה הקודם ודנים בו עם הדוברים.

יום 5: מפגש AMA, תשובות לשאלות

מפגש AMA ותשובות לשאלות בנושאים קודמים.

הגישה למודול התיאורטי השלישי נפתחת:

מיגון תנועה ושחרור קנריות

במודול השלישי ננתח מקרה המוקדש לבעיה עם הסביבה (יהיה ניתוח מפורט של בריאות בודקים), וגם ננתח שלב אחר שלב כיצד ליישם SRE בחברות וללמוד את הניסיון של החברות בהן עובדים הדוברים אִינטֶנסִיבִי

נושא 5: בדיקת בריאות

• בדיקת בריאות ב-Kubernetes
• האם השירות שלנו עדיין חי?
• בדיקות Exec
• InitialDelaySeconds
• נמל בריאות משני
• Sidecar Health Server
• בדיקה ללא ראש
• בדיקת חומרה

נושא 6: שיטות פריסה

נושא 7: הצטרפות לפרויקט SRE

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

יום 6: ניתוח פרקטיקות ומקרים

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

המשימה של Healthcheck היא לזהות שירות מקולקל ולחסום תנועה אליו. ואם אתה חושב שבשביל זה מספיק לפנות לשירות עם שורש ולקבל מענה, אז אתה אתה טועה: גם אם השירות מגיב, זה לא מבטיח את פעולתו - עלולות להתעורר בעיות ב הסביבה.

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

תִמצוּת