מה זה SRE? הסבר פשוט + כמה משרות פתוחות בישראל

זמן קריאה: 6 דקות

SRE, ראשי תיבות של Site Reliability Engineering, הוא תפקיד שמטפל באמינות המערכת כבעיה הנדסית: כמה זמן המערכת חייבת לעבוד, איך מודדים זאת, ומה עושים כשהיא לא. בלוח HiTakeJob פתוחות כרגע 110 משרות שמזכירות Kubernetes, 20 Grafana ו-20 Prometheus - הכלים המרכזיים בתחום.

הרעיון המרכזי: אמינות היא מספר, לא תחושה

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

מונח	מה זה	דוגמה
SLI	המדד עצמו - מה מודדים	אחוז הבקשות שהוחזרו בהצלחה תוך 300ms
SLO	היעד הפנימי על אותו מדד	99.9% מהבקשות יעמדו בכך בחודש
SLA	התחייבות חוזית ללקוח, עם פיצוי	99.5%, אחרת זיכוי כספי

הסדר הזה אינו מקרי: ה-SLO תמיד מחמיר מה-SLA, כדי שיהיה מרווח לתקן לפני שמפרים התחייבות ללקוח.

מה זה תקציב שגיאות ולמה הוא הרעיון החשוב בתחום?

אם ה-SLO הוא 99.9% זמינות בחודש, נותרו כ-43 דקות של כשל מותר. זה תקציב השגיאות. הוא לא מטרה שיש למחוק - הוא משאב שמותר לנצל.

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

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

במה SRE שונה מ-DevOps בפועל?

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

מה מודדים: DevOps נמדד על מהירות וקצב שחרור; SRE נמדד על עמידה ב-SLO.
מה בונים: DevOps בונה pipeline ואוטומציה; SRE בונה ניטור, התראות ותהליכי תגובה לתקלות.
מתי נכנסים לתמונה: DevOps לפני הפריסה, SRE בעיקר אחריה.
מבנה ארגוני: תפקיד SRE ייעודי מופיע בעיקר בחברות עם תנועה משמעותית; מתחת לגודל מסוים אין הצדקה כלכלית להפרדה.

ההשוואה המלאה בין שני התפקידים, כולל מסלולי מעבר, נמצאת בDevOps ו-SRE.

איך נראה טיפול בתקלה אצל צוות SRE

זהו התהליך שמגדיר את התפקיד יותר מכל כלי:

זיהוי: התראה מבוססת SLO נדלקת - לא "השרת ב-90% מעבד", אלא "המשתמשים חווים שגיאות".
הכלה: הצעד הראשון הוא לעצור את הדימום - חזרה לגרסה קודמת או ניתוב תנועה - לא למצוא את שורש הבעיה.
תקשורת: מישהו מוגדר כמפקד האירוע, ומישהו אחר מעדכן את מי שצריך לדעת.
שחזור: החזרת השירות לתפקוד מלא.
תחקיר ללא האשמה: מסמך שמתאר מה קרה, מה עיכב את הזיהוי ומה משנים בתשתית. המיקוד הוא במערכת, לא באדם שדחף את הקוד.

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

מה מנטרים בפועל - ארבעת האותות הזהובים

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

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

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

מה צריך לדעת כדי להיכנס ל-SRE

תחום	מה נדרש	משרות פעילות רלוונטיות
מערכות הפעלה ורשת	Linux ברמה מעשית, DNS, TLS, לטנסי	Linux - 91
אורקסטרציה	Kubernetes ברמת תפעול ולא רק שימוש	Kubernetes - 110
ניטור	מדדים, התראות, דשבורדים	Prometheus - 20, Grafana - 20
תכנות	אוטומציה וכלים פנימיים	Python - 365, Bash - 30
ענן	הבנת שירותים מנוהלים ומגבלותיהם	AWS - 127, GCP - 42

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

מה המשמעות המעשית של אחוזי זמינות

המספרים נשמעים דומים אבל ההבדל ביניהם הוא סדרי גודל של מאמץ ועלות:

זמינות	זמן כשל מותר בחודש	מה זה דורש בפועל
99%	כ-7 שעות	ניטור בסיסי ותגובה בשעות העבודה
99.9%	כ-43 דקות	תורנות, פריסה הדרגתית, חזרה אחורה מהירה
99.99%	כ-4 דקות	יתירות מלאה ותגובה אוטומטית - אדם לא מספיק להתערב

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

איך בודקים בראיון אם החברה באמת מריצה SRE

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

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

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

שאלות נפוצות

SRE זה אותו דבר כמו DevOps?

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

האם תפקיד SRE כולל תורנות לילה?

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

כמה משרות SRE יש בישראל?

המאגר אינו מתייג SRE כטכנולוגיה נפרדת, אבל צירוף הכלים שמאפיין את התפקיד מופיע ב-110 משרות Kubernetes, 17 Prometheus ו-20 Grafana מתוך 1,952 משרות פעילות. חלק מהן מפורסמות תחת הכותרת DevOps.

מה ההבדל בין ניטור ל-Observability?

ניטור עונה על שאלות שהוגדרו מראש - "האם ה-CPU גבוה". Observability היא היכולת לחקור תקלה שלא צפיתם, באמצעות מדדים, לוגים וטרייסים מקושרים. ההבדל מתחיל להיות קריטי במערכות עם הרבה שירותים.

האם SRE מתאים למי שמגיע מפיתוח?

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