לסמינר האינטרנט יש אודיו גרוע, אז תמללנו אותו.
שמי מדבדב אדוארד. היום אדבר על מה זה SRE, איך SRE הופיע, אילו קריטריונים לעבודה יש למהנדסי SRE, קצת על קריטריוני אמינות, קצת על הניטור שלו. נלך על הצמרות, כי אתה לא יכול לספר הרבה בשעה, אבל אני אתן חומרים לסקירה נוספת, וכולנו מחכים לך ב . במוסקבה בסוף ינואר.
ראשית, בואו נדבר על מה זה SRE - הנדסת אמינות אתרים. ואיך זה הופיע כעמדה נפרדת, ככיוון נפרד. הכל התחיל מזה שבמעגלי הפיתוח המסורתיים, Dev ו-Ops הם שני צוותים שונים לחלוטין, לרוב עם שתי מטרות שונות לחלוטין. המטרה של צוות הפיתוח היא להפיץ תכונות חדשות ולענות על הצרכים של העסק. המטרה של צוות Ops היא לוודא שהכל עובד ושום דבר לא נשבר. ברור שהמטרות הללו סותרות זו את זו באופן ישיר: כדי שהכל יעבוד ושום דבר לא ישבר, שחרר כמה שפחות תכונות חדשות. בגלל זה, ישנם קונפליקטים פנימיים רבים שהמתודולוגיה שנקראת כיום DevOps מנסה לפתור.
הבעיה היא שאין לנו הגדרה ברורה של DevOps ויישום ברור של DevOps. דיברתי בכנס ביקטרינבורג לפני שנתיים, ועד עכשיו התחיל מדור DevOps בדו"ח "מה זה DevOps". ב-2, Devops כבר כמעט בן 2017, אבל אנחנו עדיין מתווכחים מה זה. וזה מצב מאוד מוזר שגוגל ניסתה לפתור לפני כמה שנים.
בשנת 2016, גוגל הוציאה ספר בשם הנדסת אמינות אתרים. ולמעשה, עם הספר הזה התחילה תנועת SRE. SRE הוא יישום ספציפי של פרדיגמת DevOps בחברה ספציפית. מהנדסי SRE מחויבים להבטיח שמערכות פועלות בצורה אמינה. הם מגיעים בעיקר ממפתחים, לפעמים ממנהלים עם רקע פיתוח חזק. והם עושים מה שמנהלי מערכת נהגו לעשות, אבל רקע חזק בפיתוח והכרת המערכת מבחינת קוד מביא לכך שאנשים אלו לא נוטים לעבודה אדמיניסטרטיבית שגרתית, אלא נוטים לאוטומציה.
מסתבר שפרדיגמת ה-DevOps בצוותי SRE מיושמת על ידי העובדה שיש מהנדסי SRE שפותרים בעיות מבניות. הנה, אותו חיבור בין Dev ל-Ops שאנשים מדברים עליו כבר 8 שנים. תפקידו של SRE דומה לזה של אדריכל בכך שעולים חדשים אינם הופכים ל-SREs. לאנשים בתחילת דרכם אין עדיין ניסיון, אין להם את רוחב הידע הדרוש. מכיוון ש-SRE דורש ידע עדין מאוד על מה בדיוק ומתי בדיוק יכול להשתבש. לכן יש צורך כאן בניסיון מסוים, ככלל, גם בתוך החברה וגם מחוצה לה.
הם שואלים אם יתואר ההבדל בין SRE ל-devops. זה עתה תוארה. אפשר לדבר על מקומו של ה-SRE בארגון. שלא כמו גישת DevOps הקלאסית הזו, שבה Ops היא עדיין מחלקה נפרדת, SRE הוא חלק מצוות הפיתוח. הם מעורבים בפיתוח מוצרים. יש אפילו גישה שבה SRE הוא תפקיד שעובר ממפתח אחד למשנהו. הם משתתפים בביקורות קוד באותו אופן כמו, למשל, מעצבי UX, מפתחים עצמם, לפעמים מנהלי מוצר. SREs עובדים באותה רמה. אנחנו צריכים לאשר אותם, אנחנו צריכים לבדוק אותם, כך שלכל פריסה SRE אומר: "אוקיי, הפריסה הזו, המוצר הזה לא ישפיע לרעה על האמינות. ואם כן, אז בכמה גבולות מקובלים. גם על זה נדבר.
בהתאם, ל-SRE יש וטו לשנות את הקוד. ובאופן כללי, זה גם מוביל לאיזשהו קונפליקט קטן אם ה-SRE מיושם בצורה לא נכונה. באותו ספר על הנדסת אמינות אתרים, חלקים רבים, אפילו לא אחד, מספרים כיצד להימנע מהקונפליקטים הללו.
הם שואלים איך SRE קשור לאבטחת מידע. SRE אינו מעורב ישירות באבטחת מידע. בעיקרון, בחברות גדולות, זה נעשה על ידי אנשים, בודקים, אנליסטים. אבל SRE גם מקיים איתם אינטראקציה במובן שחלק מהפעולות, חלק מהתחייבויות, כמה פריסות שמשפיעות על האבטחה יכולות גם להשפיע על זמינות המוצר. לכן, ל-SRE בכללותו יש אינטראקציה עם כל צוות, כולל צוותי אבטחה, כולל אנליסטים. לכן, SRE נחוצים בעיקר כאשר הם מנסים ליישם DevOps, אך במקביל, העומס על המפתחים הופך גדול מדי. כלומר, צוות הפיתוח עצמו כבר לא יכול להתמודד עם העובדה שעכשיו הם צריכים להיות אחראים גם על Ops. ויש תפקיד נפרד. תפקיד זה מתוכנן בתקציב. לפעמים התפקיד הזה נקבע בגודל הצוות, מופיע אדם נפרד, לפעמים אחד המפתחים הופך לזה. כך מופיע ה-SRE הראשון בצוות.
מורכבות המערכת המושפעת מ-SRE, המורכבות המשפיעה על אמינות הפעולה, היא הכרחית ומקרית. מורכבות הכרחית היא כאשר המורכבות של מוצר גדלה במידה הנדרשת מתכונות מוצר חדשות. מורכבות אקראית היא כאשר מורכבות המערכת עולה, אך תכונת המוצר והדרישות העסקיות אינן משפיעות ישירות על כך. מסתבר שאו שהמפתח עשה טעות איפשהו, או שהאלגוריתם לא אופטימלי, או שמכניסים כמה תחומי עניין נוספים שמגבירים את מורכבות המוצר ללא צורך מיוחד. SRE טוב צריך תמיד לחתוך את המצב הזה. כלומר, יש לחסום כל commit, כל פריסה, כל בקשת משיכה, שבה הקושי גדל עקב תוספת אקראית.
השאלה היא למה לא פשוט להעסיק מהנדס, מנהל מערכת עם הרבה ידע לצוות. מפתח בתפקיד מהנדס, אומרים לנו, אינו פתרון האיוש הטוב ביותר. מפתח בתפקיד מהנדס הוא לא תמיד פתרון האיוש הטוב ביותר, אבל הנקודה כאן היא שלמפתח שעוסק ב-Ops יש קצת יותר חשק לאוטומציה, יש לו קצת יותר ידע ומערך מיומנות על מנת ליישם האוטומציה הזו. ובהתאם לכך, אנו מצמצמים לא רק את הזמן לכמה פעולות ספציפיות, לא רק את השגרה, אלא גם פרמטרים עסקיים חשובים כמו MTTR (Mean Time To Recovery, זמן התאוששות). כך, וגם על כך נדבר מעט בהמשך, אנו חוסכים כסף לארגון.
עכשיו בואו נדבר על הקריטריונים להפעלת SRE. וקודם כל לגבי אמינות. בחברות קטנות, סטארטאפים, קורה לא פעם שאנשים מניחים שאם השירות כתוב טוב, אם המוצר כתוב טוב ונכון, הוא יעבוד, הוא לא יישבר. זהו, אנחנו כותבים קוד טוב, אז אין מה לשבור. הקוד מאוד פשוט, אין מה לשבור. אלה בערך אותם אנשים שאומרים שאנחנו לא צריכים בדיקות, כי, תראה, אלו שלוש שיטות ה-VPI, למה להישבר כאן.
כל זה שגוי, כמובן. והאנשים האלה ננשכים לעתים קרובות מקוד כזה בפועל, כי דברים נשברים. דברים נשברים לפעמים בדרכים הכי לא צפויות. לפעמים אנשים אומרים לא, זה לעולם לא יקרה. וזה קורה כל הזמן. זה קורה לעתים קרובות מספיק. וזו הסיבה שאף אחד אף פעם לא שואף לזמינות של 100%, כי 100% זמינות אף פעם לא קורה. זו הנורמה. ולכן, כשאנחנו מדברים על זמינות של שירות, אנחנו תמיד מדברים על תשע. 2 תשיעיות, 3 תשיעיות, 4 תשיעיות, 5 תשיעיות. אם נתרגם את זה לזמן השבתה, אז למשל, 5 תשע, אז זה קצת יותר מ-5 דקות של השבתה בשנה, 2 תשע זה 3,5 ימים של השבתה.
אבל ברור שבשלב מסוים יש ירידה ב-POI, החזר על ההשקעה. מעבר משתי תשע לשלוש תשע אומר פחות זמן השבתה ביותר מ-3 ימים. מעבר מארבע תשע לחמש מפחית את זמן ההשבתה ב-47 דקות בשנה. ומסתבר שעבור עסקים זה אולי לא קריטי. ובכלל, האמינות הנדרשת היא לא עניין טכני, קודם כל, זה עניין עסקי, זה עניין מוצר. איזו רמת השבתה מקובלת על המשתמשים במוצר, מה הם מצפים, כמה הם משלמים, למשל, כמה כסף הם מפסידים, כמה כסף המערכת מפסידה.
שאלה חשובה כאן היא מהי האמינות של הרכיבים הנותרים. כי ההבדל בין 4 ל-5 תשיעיות לא יהיה גלוי בסמארטפון עם 2 תשיעיות של אמינות. באופן גס, אם משהו מתקלקל בסמארטפון בשירות שלך 10 פעמים בשנה, ככל הנראה פי 8 התקלה התרחשה בצד מערכת ההפעלה. המשתמש רגיל לכך, ולא ישים לב לפעם נוספת בשנה. יש צורך לתאם את המחיר של הגדלת האמינות והגדלת הרווחים.
רק בספר על SRE יש דוגמה טובה להגדלה ל-4 תשע מ-3 תשע. מסתבר שהעלייה בזמינות היא קצת פחות מ-0,1%. ואם הכנסות השירות עומדות על מיליון דולר בשנה, הרי שהגידול בהכנסות הוא 1 דולר. אם זה עולה לנו פחות מ-900 דולר לשנה להגדיל את הסבירות ב-900, העלייה הגיונית כלכלית. אם זה עולה יותר מ-900 דולר בשנה, זה כבר לא הגיוני, כי הגידול בהכנסות פשוט לא מפצה על עלויות העבודה, על עלויות המשאבים. ו-3 תשע יספיקו לנו.
זו כמובן דוגמה פשוטה שבה כל הבקשות שוות. ולעבור מ-3 תשיעיות ל-4 תשיעיות זה די קל, אבל במקביל, למשל, לעבור מ-2 תשיעיות ל-3, זה כבר חיסכון של 9 אלף דולר, זה יכול להיות הגיוני כלכלי. מטבע הדברים, במציאות, כישלון בקשת הרישום חמור יותר מאי הצגת העמוד, לבקשות משקל שונה. יכול להיות שיש להם קריטריון שונה לחלוטין מנקודת מבט עסקית, אבל בכל מקרה, ככלל, אם אנחנו לא מדברים על כמה שירותים ספציפיים, זהו קירוב אמין למדי.
קיבלנו שאלה האם SRE הוא אחד הרכזים בבחירת פתרון אדריכלי לשירות. נניח מבחינת השתלבות בתשתית הקיימת, כך שלא יאבד יציבות שלה. כן, SREs, באותו אופן שבו בקשות משיכה, מחויבות, שחרורים משפיעים על הארכיטקטורה, הכנסת שירותים חדשים, מיקרו-שירותים, הטמעת פתרונות חדשים. למה אמרתי לפני שצריך ניסיון, צריך כישורים. למעשה, SRE הוא אחד הקולות החוסמים בכל פתרון ארכיטקטוני ותוכנה. בהתאם לכך, SRE כמהנדס חייב, קודם כל, לא רק להבין, אלא גם להבין כיצד כמה החלטות ספציפיות ישפיעו על האמינות, היציבות, ולהבין כיצד זה קשור לצרכים העסקיים, ומאיזו נקודת מבט זה יכול להיות מקובל. אשר לא.
לכן, עכשיו אנחנו יכולים רק לדבר על קריטריונים של אמינות, המוגדרים באופן מסורתי ב-SRE כ-SLA (הסכם רמת שירות). סביר להניח מונח מוכר. SLI (אינדיקטור רמת שירות). SLO (מטרת רמת שירות). הסכם רמת שירות הוא אולי מונח סמלי, במיוחד אם עבדת עם רשתות, עם ספקים, עם אירוח. זהו הסכם כללי המתאר את הביצועים של כל השירות שלך, קנסות, כמה עונשים על שגיאות, מדדים, קריטריונים. ו-SLI הוא מדד הזמינות עצמו. כלומר, מה SLI יכול להיות: זמן תגובה מהשירות, מספר השגיאות באחוזים. זה יכול להיות רוחב פס אם זה סוג של אירוח קבצים. כשמדובר באלגוריתמי זיהוי, המחוון יכול להיות, למשל, אפילו נכונות התשובה. SLO (Service Level Objective) הוא, בהתאמה, שילוב של מחוון SLI, ערכו ותקופתו.
נניח שה-SLA יכול להיות ככה. השירות זמין 99,95% מהזמן לאורך כל השנה. או 99 כרטיסי תמיכה קריטיים ייסגרו תוך 3 שעות לרבעון. או 85% מהשאילתות יקבלו תגובות תוך 1,5 שניות בכל חודש. כלומר, בהדרגה אנו מבינים ששגיאות וכשלים הם נורמליים למדי. זה מצב מקובל, אנחנו מתכננים אותו, אפילו סומכים עליו במידה מסוימת. כלומר, SRE בונה מערכות שיכולות לעשות טעויות, שצריכות להגיב כרגיל לטעויות, שחייבות לקחת אותן בחשבון. ובמידת האפשר, הם צריכים לטפל בשגיאות בצורה כזו שהמשתמש או לא יבחין בהן, או ישים לב, אבל יש איזשהו פתרון, שבזכותו הכל לא ייפול לגמרי.
לדוגמה, אם אתה מעלה סרטון ליוטיוב, ויוטיוב לא יכול להמיר אותו מיד, אם הסרטון גדול מדי, אם הפורמט לא אופטימלי, אז כמובן שהבקשה לא תיכשל עם פסק זמן, יוטיוב לא ייתן שגיאה 502 , יוטיוב יגיד: "יצרנו הכל, הסרטון שלך בעיבוד. זה יהיה מוכן בעוד כ-10 דקות". זהו העיקרון של השפלה חיננית, המוכר, למשל, מפיתוח חזיתי, אם אי פעם עשית זאת.
המונחים הבאים עליהם נדבר, שחשובים מאוד לעבודה עם אמינות, עם שגיאות, עם ציפיות, הם MTBF ו-MTTR. MTBF הוא הזמן הממוצע בין כישלונות. MTTR Mean Time To Recovery, זמן ממוצע להתאוששות. כלומר, כמה זמן חלף מרגע גילוי השגיאה, מרגע הופעת השגיאה ועד לרגע שחזר השירות לפעולה תקינה מלאה. MTBF קבוע בעיקר על ידי עבודה על איכות קוד. כלומר, העובדה ש-SREs יכולים לומר "לא". ואתה צריך הבנה של כל הצוות שכאשר SRE אומר "לא", הוא אומר את זה לא כי הוא מזיק, לא כי הוא רע, אלא כי אחרת כולם יסבלו.
שוב, יש הרבה מאמרים, הרבה שיטות, הרבה דרכים אפילו בספר שאני מתייחס אליו לעתים קרובות כל כך, איך לוודא שמפתחים אחרים לא יתחילו לשנוא SRE. MTTR, לעומת זאת, עוסק בעבודה על ה-SLOs שלך (Service Level Objective). וזה בעיקר אוטומציה. כי, למשל, ה-SLO שלנו הוא זמן פעולה של 4 תשע לרבעון. המשמעות היא שבתוך 3 חודשים נוכל לאפשר 13 דקות של השבתה. ומסתבר ש-MTTR לא יכול להיות יותר מ-13 דקות. אם נגיב להשבתה אחת לפחות ב-13 דקות, זה אומר שכבר מיצינו את כל התקציב לרבעון. אנחנו שוברים את ה-SLO. 1 דקות להגיב ולתקן התרסקות זה הרבה עבור מכונה, אבל קצר מאוד עבור אדם. כי עד שאדם מקבל התראה, עד שהוא מגיב, עד שהוא מבין את השגיאה, זה כבר כמה דקות. עד שאדם יבין איך לתקן את זה, מה בדיוק לתקן, מה לעשות, אז זה עוד כמה דקות. ולמעשה, גם אם אתה רק צריך להפעיל מחדש את השרת, כפי שמתברר, או להעלות צומת חדש, אז באופן ידני MTTR הוא כבר בערך 13-7 דקות. בעת אוטומציה של התהליך, MTTR מגיע לרוב לשניה, לפעמים אלפיות שניות. גוגל בדרך כלל מדברת על אלפיות שניות, אבל במציאות, כמובן, הכל לא כל כך טוב.
באופן אידיאלי, ה-SRE צריך להפוך את עבודתו לאוטומטית כמעט לחלוטין, מכיוון שהדבר משפיע ישירות על ה-MTTR, המדדים שלו, ה-SLO של השירות כולו, ובהתאם לכך, הרווח העסקי. אם חורגת מהזמן, נשאל אם SRE אשם. למרבה המזל, אף אחד לא אשם. וזוהי תרבות נפרדת שנקראת לאחר המוות ללא מזור, עליה לא נדבר היום, אלא ננתח אותה ב-Slurm. זה נושא מאוד מעניין שאפשר לדבר עליו הרבה. באופן גס, אם חריגה מהזמן המוקצב לרבעון אז קצת מכולם אשמים, מה שאומר שלהאשים את כולם זה לא פרודוקטיבי, בוא במקום, אולי לא נאשים אף אחד, אלא נתקן את המצב ונעבוד עם מה שיש לנו. מניסיוני, הגישה הזו קצת זרה לרוב הקבוצות, במיוחד ברוסיה, אבל היא הגיונית ועובדת טוב מאוד. לכן, אמליץ בסוף המאמר והספרות שתוכלו לקרוא בנושא זה. או בואו ל-Slurm SRE.
הרשה לי להסביר. אם חריגה מזמן ה-SLO לרבעון, אם זמן ההשבתה לא היה 13 דקות, אלא 15, מי יכול להיות אשם בכך? כמובן ש-SRE עשוי להיות אשם, כי ברור שהוא ביצע איזושהי התחייבות או פריסה גרועה. ייתכן שמנהל מרכז הנתונים אשם בכך, כי ייתכן שביצע איזושהי תחזוקה לא מתוכננת. אם מנהל ה-Data Center אשם בכך, אז אשם בכך מי מ-Ops, שלא חישב את התחזוקה כשתיאם את ה-SLO. המנהל, המנהל הטכני או מי שחתם על חוזה הדטה סנטר ולא שם לב לכך שה-SLA של הדאטה סנטר אינו מיועד לזמן ההשבתה הנדרש אשם בכך. בהתאם, כל לאט לאט במצב זה אשמים. וזה אומר שאין טעם להטיל את האשמה על מישהו במצב הזה. אבל כמובן שצריך לתקן את זה. בגלל זה יש נתיחה שלאחר המוות. ואם אתה קורא, למשל, GitHub שלאחר המוות, וזה תמיד סיפור מאוד מעניין, קטן ובלתי צפוי בכל מקרה ספציפי, אתה יכול להחליף שאף אחד אף פעם לא אומר שהאדם המסוים הזה היה אשם. האשמה תמיד מוטלת על תהליכים לא מושלמים ספציפיים.
נעבור לשאלה הבאה. אוטומציה. כשאני מדבר על אוטומציה בהקשרים אחרים, אני מרבה להתייחס לטבלה שאומרת לך כמה זמן אתה יכול לעבוד על אוטומציה של משימה מבלי לקחת יותר זמן לאוטומציה ממה שאתה באמת חוסך. יש תקלה. הקאץ' הוא שכאשר SREs עושים משימה אוטומטית, הם לא רק חוסכים זמן, הם חוסכים כסף, כי האוטומציה משפיעה ישירות על MTTR. הם חוסכים, כביכול, את המורל של העובדים והמפתחים, שהוא גם משאב מתכלה. הם מצמצמים את השגרה. ולכל זה יש השפעה חיובית על העבודה וכתוצאה מכך על העסקים, גם אם נראה שאוטומציה לא הגיונית מבחינת עלויות זמן.
למעשה, זה קרה כמעט תמיד, ויש מעט מאוד מקרים שבהם משהו לא צריך להיות אוטומטי בתפקיד SRE. בהמשך נדבר על מה שנקרא תקציב השגיאות, התקציב לטעויות. למעשה, מסתבר שאם הכל הרבה יותר טוב בשבילך מה-SLO שהגדרת לעצמך, זה גם לא טוב במיוחד. זה די גרוע, כי SLO עובד לא רק כגבול תחתון, אלא גם כגבול עליון משוער. כשאתה מציב לעצמך SLO של 99% זמינות, ולמעשה יש לך 99,99%, מסתבר שיש לך קצת מקום לניסויים שלא יפגעו בכלל בעסק, כי אתה בעצמך קבעת את זה הכל ביחד, ואתה את החלל הזה אין להשתמש. יש לך תקציב לטעויות, שבמקרה שלך לא מנוצל.
מה עושים עם זה. אנחנו משתמשים בו ממש לכל דבר. לבדיקות בתנאי ייצור, להפעלת פיצ'רים חדשים שעשויים להשפיע על הביצועים, לשחרורים, לתחזוקה, להשבתות מתוכננות. גם הכלל ההפוך חל: אם התקציב ימוצה, לא נוכל לשחרר שום דבר חדש, כי אחרת נחרוג מה-SLO. התקציב כבר מוצה, שחררנו משהו אם זה משפיע לרעה על הביצועים, כלומר, אם זה לא סוג של תיקון שבעצמו מגדיל ישירות את ה-SLO, אז אנחנו חורגים מהתקציב, וזה מצב רע. , יש לנתח אותו, נתיחה שלאחר המוות, ואולי כמה תיקוני תהליכים.
כלומר, מסתבר שאם השירות עצמו לא עובד טוב, ו-SLO מבוזבז והתקציב מוקדש לא על ניסויים, לא על כמה מהדורות, אלא בפני עצמו, אז במקום כמה תיקונים מעניינים, במקום פיצ'רים מעניינים, במקום מהדורות מעניינות. במקום כל עבודה יצירתית, תצטרכו להתמודד עם תיקונים מטופשים כדי להחזיר את התקציב לסדר, או לערוך את ה-SLO, וגם זה תהליך שאסור לקרות לעתים קרובות מדי.
לכן, מסתבר שבמצב שבו יש לנו יותר תקציב לטעויות, כולם מתעניינים: גם SRE וגם מפתחים. עבור מפתחים, תקציב גדול לבאגים אומר שאתה יכול להתמודד עם מהדורות, בדיקות, ניסויים. עבור SREs, תקציב לשגיאות והזנת תקציב זה אומר שהם מבצעים את עבודתם בצורה ישירה. וזה משפיע על המוטיבציה של איזושהי עבודה משותפת. אם תקשיבו ל-SREs שלכם כמפתחים, יהיה לכם יותר מקום לעבודה טובה והרבה פחות שגרה.
מסתבר שניסויים בייצור הם חלק די חשוב וכמעט אינטגרלי מ-SRE בצוותים גדולים. וזה נקרא בדרך כלל הנדסת כאוס, שמגיע מהצוות בנטפליקס שהוציא כלי עזר בשם Chaos Monkey.
Chaos Monkey מתחבר לצינור ה-CI/CD ומתרסק באופן אקראי את השרת בייצור. שוב, במבנה SRE, אנחנו מדברים על זה ששרת שהופל הוא לא רע בפני עצמו, זה צפוי. ואם זה במסגרת התקציב, זה מקובל ולא פוגע בעסק. כמובן שלנטפליקס יש מספיק שרתים מיותרים, מספיק שכפול, כדי שאפשר יהיה לתקן את כל זה, וכדי שהמשתמש בכללותו לא ישים לב, ועוד יותר מכך שאף אחד לא משאיר שרת אחד בשום תקציב.
לנטפליקס הייתה חבילה שלמה של כלי עזר כאלה במשך זמן מה, אחד מהם, Chaos Gorilla, מכבה לחלוטין את אחד מאזורי הזמינות של אמזון. ודברים כאלה עוזרים לחשוף, ראשית, תלות נסתרת, כשלא ברור לגמרי מה משפיע על מה, מה תלוי במה. וזה, אם אתה עובד עם שירות מיקרו, והתיעוד לא ממש מושלם, זה אולי מוכר לך. ושוב, זה עוזר מאוד לתפוס שגיאות בקוד שלא ניתן לתפוס בהגשה, כי כל בימוי הוא לא בדיוק סימולציה מדויקת, בשל העובדה שסולם העומס שונה, דפוס העומס שונה, הציוד הוא גם, קרוב לוודאי, אחר. עומסי שיא יכולים להיות גם בלתי צפויים ובלתי צפויים. ובדיקות כאלה, ששוב אינן חורגות מהתקציב, עוזרות מאוד לתפוס שגיאות בתשתית ש-Staging, Autotests, CI/CD pipeline לעולם לא יתפסו. וכל עוד הכל כלול בתקציב שלך, זה לא משנה שהשירות שלך ירד לשם, למרות שזה היה נראה מאוד מפחיד, השרת נפל, איזה סיוט. לא, זה נורמלי, זה טוב, זה עוזר לתפוס באגים. אם יש לך תקציב, אז אתה יכול לבזבז אותו.
ש: על איזו ספרות אני יכול להמליץ? רשימה בסוף. יש הרבה ספרות, אני אמליץ כמה דוחות. איך זה עובד, והאם SRE עובד בחברות ללא מוצר תוכנה משלהן או עם פיתוח מינימלי. למשל, בארגון שבו עיקר הפעילות אינה תוכנה. בארגון, שבו עיקר הפעילות היא לא תוכנה, SRE עובד בדיוק כמו בכל מקום אחר, כי בארגון צריך גם להשתמש, גם אם לא מפותחים, במוצרי תוכנה, צריך לגלגל עדכונים, צריך לשנות התשתית, אתה צריך לגדול, אתה צריך להגדיל. ו-SREs עוזרים לזהות ולחזות בעיות אפשריות בתהליכים אלה ולשלוט בהן לאחר תחילת צמיחה מסוימת והצרכים העסקיים משתנים. כי זה ממש לא הכרחי להיות מעורב בפיתוח תוכנה כדי שיהיה לך SRE אם יש לך לפחות כמה שרתים וצפויה לך לפחות קצת צמיחה.
כך גם לגבי פרויקטים קטנים, ארגונים קטנים, כי לחברות גדולות יש את התקציב והמרחב להתנסות. אבל יחד עם זאת, כל פירות הניסויים האלה יכולים לשמש בכל מקום, כלומר, SRE, כמובן, הופיע בגוגל, בנטפליקס, בדרופבוקס. אבל במקביל, חברות קטנות וסטארטאפים כבר יכולים לקרוא חומר מרוכז, לקרוא ספרים, לצפות בדיווחים. הם מתחילים לשמוע על זה לעתים קרובות יותר, הם מסתכלים על דוגמאות ספציפיות, אני חושב שזה בסדר, זה באמת יכול להיות שימושי, אנחנו צריכים גם את זה, זה נהדר.
כלומר, כל העבודה העיקרית על סטנדרטיזציה של תהליכים אלו כבר נעשתה עבורכם. נותר לך לקבוע את התפקיד של SRE ספציפית בחברה שלך ולהתחיל ליישם בפועל את כל הפרקטיקות הללו, אשר, שוב, כבר תוארו. כלומר, מעקרונות שימושיים לחברות קטנות, זו תמיד ההגדרה של SLA, SLI, SLO. אם אינך מעורב בתוכנה, אז אלו יהיו SLAs פנימיים ו-SLOs פנימיים, תקציב פנימי לטעויות. זה כמעט תמיד מוביל לכמה דיונים מעניינים בצוות ובתוך העסק, כי אולי יתברר שאתה מוציא על תשתית, על איזשהו ארגון של תהליכים אידיאליים, הצינור האידיאלי הוא הרבה יותר ממה שצריך. ואת 4 התשעים האלה שיש לך במחלקת ה-IT, אתה לא באמת צריך אותם עכשיו. אבל באותו זמן, אתה יכול לבזבז זמן, לבזבז את התקציב לטעויות במשהו אחר.
בהתאם לכך, ניטור וארגון הניטור שימושיים עבור חברה בכל סדר גודל. ובכלל, צורת החשיבה הזו, שבה טעויות זה משהו מקובל, איפה שיש תקציב, איפה יש Objectives, היא שוב שימושית לחברה בכל סדר גודל, החל מסטארטאפים ל-3 אנשים.
אחרון הניואנסים הטכניים לדבר עליהם הוא ניטור. כי אם אנחנו מדברים על SLA, SLI, SLO, אנחנו לא יכולים להבין בלי לפקח אם אנחנו מתאימים לתקציב, האם אנחנו עומדים ביעדים שלנו ואיך אנחנו משפיעים על ה-SLA הסופי. ראיתי כל כך הרבה פעמים שהניטור קורה ככה: יש ערך כלשהו, למשל, זמן הבקשה לשרת, הזמן הממוצע או מספר הבקשות למסד הנתונים. יש לו תקן שנקבע על ידי מהנדס. אם המדד חורג מהנורמה, אז מגיע מייל. כל זה חסר תועלת לחלוטין, ככלל, כי זה מוביל לשפע כזה של התראות, לשפע של הודעות מהניטור, כאשר אדם, ראשית, חייב לפרש אותן בכל פעם, כלומר לקבוע אם הערך של המדד אומר הצורך בפעולה כלשהי. ושנית, הוא פשוט מפסיק לשים לב לכל ההתראות האלה, כשבעצם לא נדרשת ממנו שום פעולה. זהו כלל ניטור טוב והכלל הראשון בעת יישום SRE הוא שהודעה צריכה להגיע רק כאשר נדרשת פעולה.
במקרה הסטנדרטי, ישנן 3 רמות של אירועים. יש התראות, יש כרטיסים, יש יומנים. התראות הן כל דבר שדורש ממך לנקוט בפעולה מיידית. כלומר, הכל שבור, אתה צריך לתקן את זה עכשיו. כרטיסים הם מה שדורש פעולה מאוחרת. כן, אתה צריך לעשות משהו, אתה צריך לעשות משהו ידני, האוטומציה נכשלה, אבל אתה לא צריך לעשות את זה במשך הדקות הקרובות. יומנים הם כל דבר שלא דורש פעולה, ובאופן כללי, אם דברים הולכים כשורה, אף אחד לא יקרא אותם לעולם. תצטרכו לקרוא את היומנים רק כאשר בדיעבד התברר שמשהו נשבר לזמן מה, לא ידענו על כך. או שאתה צריך לעשות קצת מחקר. אבל באופן כללי, כל מה שלא דורש שום פעולה עובר ליומנים.
כתופעת לוואי של כל זה, אם הגדרנו אילו אירועים דורשים פעולות ותארנו היטב מה צריכות להיות הפעולות הללו, זה אומר שניתן לבצע אוטומטית את הפעולה. כלומר, מה קורה. אנחנו יוצאים מכוננות. בואו נלך לפעולה. נעבור לתיאור הפעולה הזו. ואז נעבור לאוטומציה. כלומר, כל אוטומציה מתחילה בתגובה לאירוע.
מהניטור, אנחנו עוברים למונח שנקרא Observability. היה גם קצת הייפ סביב המילה הזו בשנים האחרונות. ומעטים האנשים שמבינים מה זה אומר מחוץ להקשר. אבל הנקודה העיקרית היא שצפייה היא מדד לשקיפות מערכת. אם משהו השתבש, באיזו מהירות תוכל לקבוע מה בדיוק השתבש ומה היה מצב המערכת באותו רגע. מבחינת קוד: איזו פונקציה נכשלה, איזה שירות נכשל. מה היה המצב של, למשל, משתנים פנימיים, תצורה. מבחינת תשתית, זה באיזה אזור זמינות התרחש הכשל, ואם יש לך Kubernetes, אז באיזה פוד התרחש הכשל, מה היה מצב הפוד. ובהתאם, ל- Observability יש קשר ישיר עם MTTR. ככל שה- Observability של השירות גבוה יותר, כך קל יותר לזהות את השגיאה, קל יותר לתקן את השגיאה, כך קל יותר להפוך את השגיאה לאוטומטי, כך ה-MTTR נמוך יותר.
אם עוברים שוב לחברות קטנות, נפוץ מאוד לשאול, גם עכשיו, איך מתמודדים עם גודל הצוות, והאם צוות קטן צריך לשכור SRE נפרד. כבר דיברנו על זה קצת קודם. בשלבים הראשונים של הפיתוח של סטארטאפ או, למשל, צוות, זה כלל לא הכרחי, כי SRE יכול להפוך לתפקיד מעבר. וזה יחיה קצת את הקבוצה, כי יש לפחות גיוון. ובנוסף זה יכין אנשים לעובדה שעם צמיחה, באופן כללי, האחריות של SRE תשתנה באופן משמעותי מאוד. אם אתה שוכר אדם, אז, כמובן, יש לו כמה ציפיות. והציפיות הללו לא ישתנו עם הזמן, אבל הדרישות ישתנו מאוד. לכן, איך לשכור SRE הוא די קשה בשלבים המוקדמים. לגדל בעצמך זה הרבה יותר קל. אבל כדאי לחשוב על זה.
היוצא מן הכלל היחיד, אולי, הוא כאשר יש דרישות צמיחה מאוד קפדניות ומוגדרות היטב. כלומר, במקרה של סטארטאפ, זה עשוי להיות סוג של לחץ מצד משקיעים, איזושהי תחזית לצמיחה מספר פעמים בבת אחת. אז העסקת SRE היא בעצם מוצדקת כי היא יכולה להיות מוצדקת. יש לנו דרישות לצמיחה, אנחנו צריכים אדם שיהיה אחראי לכך שעם צמיחה כזו שום דבר לא ישבר.
עוד שאלה אחת. מה לעשות כשכמה פעמים המפתחים חותכים פיצ'ר שעובר את הבדיקות, אבל שובר את הייצור, טוען את הבסיס, שובר פיצ'רים אחרים, איזה תהליך ליישם. בהתאם לכך, במקרה זה מוכנס התקציב לטעויות. וחלק מהשירותים, חלק מהפיצ'רים כבר נבדקים בהפקה. זה יכול להיות קנרי, כאשר רק מספר קטן של משתמשים, אבל כבר בהפקה, נפרס פיצ'ר, אבל כבר עם ציפייה שאם משהו נשבר, למשל, עבור חצי אחוז מכלל המשתמשים, הוא עדיין יעמוד ב- תקציב לטעויות. בהתאם לכך, כן, תהיה שגיאה, עבור חלק מהמשתמשים הכל ישבר, אבל כבר אמרנו שזה נורמלי.
הייתה שאלה לגבי כלי SRE. כלומר, האם יש משהו מסוים שבו SREs ישתמשו שכולם לא ישתמשו בו. למעשה, יש כמה כלי עזר מיוחדים מאוד, יש איזושהי תוכנה שמדמה, למשל, עומסים או עוסקת בבדיקת A/B של קנרית. אבל בעצם ערכת הכלים של SRE היא מה שהמפתחים שלך כבר משתמשים. מכיוון ש-SRE מקיים אינטראקציה ישירה עם צוות הפיתוח. ואם יש לכם כלים שונים, יתברר שלוקח זמן לסנכרן. במיוחד אם SRE עובדים בצוותים גדולים, בחברות גדולות שבהן יכולים להיות כמה צוותים, סטנדרטיזציה כלל-חברה היא שתעזור כאן מאוד, כי אם משתמשים ב-50 כלי עזר שונים ב-50 צוותים, זה אומר שה-SRE חייב להכיר אותם את כל. וכמובן שזה לעולם לא יקרה. ואיכות העבודה, איכות הבקרה של לפחות חלק מהצוותים תרד משמעותית.
הוובינר שלנו מגיע לסיומו. הצלחתי לספר כמה דברים בסיסיים. כמובן, שום דבר על SRE לא ניתן לספר ולהבין תוך שעה. אבל אני מקווה שהצלחתי להעביר את צורת החשיבה הזו, את נקודות המפתח העיקריות. ואז יהיה אפשר, אם מעוניינים, להתעמק בנושא, ללמוד לבד, להסתכל איך זה מיושם על ידי אנשים אחרים, בחברות אחרות. ובהתאם לכך, בתחילת פברואר, בואו אלינו ל-Slurm SRE.
ה-Slurm SRE הוא קורס אינטנסיבי בן שלושה ימים שידבר על מה שאני מדבר עליו עכשיו, אבל עם הרבה יותר עומק, עם מקרים אמיתיים, עם תרגול, כל האינטנסיבי מכוון לעבודה מעשית. אנשים יחולקו לצוותים. כולכם תעבדו על מקרים אמיתיים. בהתאם, יש לנו מדריכי Booking.com איבן קרוגלוב ובן טיילר. יש לנו יוג'ין ברבאס נפלא מגוגל מסן פרנסיסקו. וגם אני אגיד לך משהו. אז הקפד לבקר אותנו.
אז, הביבליוגרפיה. יש הפניות על SRE. על אותו ספר, או יותר נכון על 2 ספרים על SRE, שנכתבו על ידי גוגל. עוד אחד , כאשר התנאים ויישומה מעט יותר מפורטים. השלושה הבאים הם דוחות על SRE בחברות שונות. ראשון - , זהו הערה מרכזית של בן טריינר מגוגל. שנית - . השלישי שוב . דו"ח רביעי מ , שיש לה רק 5 עובדי מפתח SRE ב-190 מדינות. זה מאוד מעניין להסתכל על כל זה, כי כמו ש-DevOps אומר דברים שונים מאוד לחברות שונות ואפילו לצוותים שונים, ל-SRE יש אחריות מאוד שונה, אפילו בחברות בגדלים דומים.
2 קישורים נוספים על עקרונות הנדסת כאוס: , . ובסוף יש 3 רשימות מהסדרה Awesome Lists על בערך ולגבי . הרשימה ב-SRE ענקית להפליא, אין צורך לעבור על הכל, יש בערך 200 מאמרים. אני ממליץ בחום על מאמרים משם על תכנון קיבולת ועל נתיחה שלאחר המוות ללא תמים.
כתבה מעניינת:
תודה שהקשבת לי כל הזמן הזה. מקווה שלמדת משהו. מקווה שיש לך מספיק חומר כדי ללמוד עוד יותר. וראיתי אותך. בתקווה בפברואר.
הסמינר המקוון נערך על ידי אדוארד מדבדב.
נ.ב: למי שאוהב לקרוא, אדוארד נתן רשימה של הפניות. מי שמעדיף להבין בפועל מוזמן .
מקור: www.habr.com