יש נטייה, בכל יצירה של תפקיד חדש – לשאול מאי נפקא מינה? בהקשר של SRE עולה השאלה האלמותית: מה ההבדל בין SRE ל-devops? גוגל הפיקו את הסרטון הנהדר הבא:
אני חושב שזה קצת סמנטי, והשאלה האמתית שנכון להקשות על תפקידים עם אחריות רוחבית על המוצר – מה האחריות. ברשומה זאת כמה פעולות ותחומי אחריות שונים של SRE – וכמובן, גם זה – משתנה בין ארגון לארגון, כי אצל כל חברה הדרך שלה לדאוג שהיא יציבה.
פיתוח כלי ניטור
תחת כותרת גדולה זאת – שיכולה להיות האחריות היחידה (והגדולה!) של SRE בארגונים – נמצאים הבאזזורדס/כלים/פיתוחים/מורכבויות הבאים:
תשתית האלרטים
מערכת להגדרת ״הערות אזהרה״ שידווחו לקבוצה הרלוונטית – צוות הפיתוח, או התמיכה בדרך כלל – על בעיה במערכת או בחלק ב-flow (זרימה) שרלוונטי.
תשתית כזאת מאפשרת למפתח להגדיר תנאים שבהם תקפוץ התראה – ומי יקבל אותה, מתי או קריטריונים אחרים. למשל: יש המון exceptions מהחלק שלו ב-flow יותר מחצי שעה.
תשתית העברת מידע על המוצר ב-production
כמו: כמה פעמים המשתמש שהה בחלק בדף, האם היו 404, ואם כן – איזה חלקים בדף נפגעו. באילו חלקים המשתמשים שוהים. כמה זמן לקח לקריאה להישלח, כמה שגיאות yield יש במערכת ועוד. העברת המידע יכולה להיות בעזרת event, metrics, logs או כל מיני תשתיות העברה של סוגים שונים של לוגים. משמעויות הלוגים ואיך מעבירים אותם נכון שווים מאמר בפני עצמו
כלים לשיפור היציבות בזמן אמת
פיתוח אוטומציות
אם במקרים של עומס צריכים להעלות את כמות המכונות והיום ה-on call יעשה את זה – זה לגמרי במסגרת החשיבה של ה-SRE לבצע אוטומציה לתהליך. חשוב לומר שתהליך כזה חייב להתבצע בזהירות ולהיות מבוסס על מידע מלא, ולהיות בדוק מאד. המשמעות של אוטומציה רעה יכולה להיות פגיעה משמעותית יותר ב-production. אם – אוטומציה מהסוג הזה תגדיל את מספר המכונות מהר מדי, העלויות של האוטומציה אולי יהיו רעות יותר מאטיות מאד זמנית. על ה-SRE להבין את הבעיה עד הסוף ולהבין איזה אוטומציה תתאים.
פיתוח כלים לתקשורת מהירה בין הצוותים
זה יכול להיות ברמת קישור מהיר בין האלרט למפתחים הרלוונטיים ב-PagerDuty, או יצירת תהליך מסודר לתחקור תקלה ב-production בזמן אמת