אחריות SRE

יש נטייה, בכל יצירה של תפקיד חדש – לשאול מאי נפקא מינה? בהקשר של SRE עולה השאלה האלמותית: מה ההבדל בין SRE ל-devops? גוגל הפיקו את הסרטון הנהדר הבא:

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

פיתוח כלי ניטור

תחת כותרת גדולה זאת – שיכולה להיות האחריות היחידה (והגדולה!) של SRE בארגונים – נמצאים הבאזזורדס/כלים/פיתוחים/מורכבויות הבאים:

תשתית האלרטים

מערכת להגדרת ״הערות אזהרה״ שידווחו לקבוצה הרלוונטית – צוות הפיתוח, או התמיכה בדרך כלל – על בעיה במערכת או בחלק ב-flow (זרימה) שרלוונטי.
תשתית כזאת מאפשרת למפתח להגדיר תנאים שבהם תקפוץ התראה – ומי יקבל אותה, מתי או קריטריונים אחרים. למשל: יש המון exceptions מהחלק שלו ב-flow יותר מחצי שעה.

תשתית העברת מידע על המוצר ב-production

כמו: כמה פעמים המשתמש שהה בחלק בדף, האם היו 404, ואם כן – איזה חלקים בדף נפגעו. באילו חלקים המשתמשים שוהים. כמה זמן לקח לקריאה להישלח, כמה שגיאות yield יש במערכת ועוד. העברת המידע יכולה להיות בעזרת event, metrics, logs או כל מיני תשתיות העברה של סוגים שונים של לוגים. משמעויות הלוגים ואיך מעבירים אותם נכון שווים מאמר בפני עצמו

כלים לשיפור היציבות בזמן אמת

פיתוח אוטומציות

אם במקרים של עומס צריכים להעלות את כמות המכונות והיום ה-on call יעשה את זה – זה לגמרי במסגרת החשיבה של ה-SRE לבצע אוטומציה לתהליך. חשוב לומר שתהליך כזה חייב להתבצע בזהירות ולהיות מבוסס על מידע מלא, ולהיות בדוק מאד. המשמעות של אוטומציה רעה יכולה להיות פגיעה משמעותית יותר ב-production. אם – אוטומציה מהסוג הזה תגדיל את מספר המכונות מהר מדי, העלויות של האוטומציה אולי יהיו רעות יותר מאטיות מאד זמנית. על ה-SRE להבין את הבעיה עד הסוף ולהבין איזה אוטומציה תתאים.

פיתוח כלים לתקשורת מהירה בין הצוותים

זה יכול להיות ברמת קישור מהיר בין האלרט למפתחים הרלוונטיים ב-PagerDuty, או יצירת תהליך מסודר לתחקור תקלה ב-production בזמן אמת

מאמרים נוספים

מהם תפקידי ה-on-call?

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

עלויות מעבר מערכות לוגים ואלרטים

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

אלרט טוב, ואלרט רע

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

יציבות בפרוייקטים? יאן ווגינפירר מסביר

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

לכתוב test-ים של js ב-python

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