איך נכנסים לתפקיד SRE בישראל — מדריך 2026

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

מה עושה מהנדס SRE?

SRE לוקח את עקרונות ההנדסה ומחיל אותם על אמינות המערכת. במקום "לכבות שריפות" ידנית, הוא בונה מערכות שמתאוששות מעצמן, מגדיר יעדי אמינות מדידים (SLO/SLI), מנטר את המערכת בזמן אמת, ומוביל תחקירי תקלות (postmortems) כדי שאותה בעיה לא תחזור. זהו תפקיד שדורש חשיבה מערכתית עמוקה ויכולת לכתוב קוד — לא רק להפעיל כלים.

איך נראה יום עבודה טיפוסי של SRE

בניגוד לדימוי של "מכבה אש מסביב לשעון", רוב הזמן של SRE טוב מוקדש דווקא למניעת האש מלכתחילה. יום טיפוסי מתחיל בבדיקת מצב האמינות: האם עמדנו ב-SLO אתמול, האם תקציב השגיאות עדיין בריא, ומה מספרות המטריקות. חלק מהיום מוקדש להנדסה — כתיבת קוד ואוטומציה שמפחיתים עבודה ידנית חוזרת (Toil), שיפור מערך הניטור, או בניית מנגנוני התאוששות אוטומטית. חלק אחר מוקדש לשיתוף פעולה עם צוותי הפיתוח: לעזור להם לבנות מערכות אמינות מלכתחילה, ולהגדיר יחד יעדי אמינות. וכשמתרחשת תקלה אמיתית, ה-SRE מוביל את הטיפול בזמן אמת ואחריו את התחקיר. השילוב הזה של הנדסה, מדידה ותגובה לאירועים הוא לב התפקיד.

הכישורים הנדרשים לתפקיד

• לינוקס ורשתות לעומק: הבנה חזקה של מערכת ההפעלה, תהליכים, זיכרון ורשת.
• Kubernetes: לא רק להפעיל, אלא להבין איך זה עובד מבפנים ולפתור תקלות.
• ניטור ותצפיתיות: Prometheus לאיסוף מטריקות ו-Grafana להצגה והתראות.
• תכנות: Python או Go לכתיבת כלים ואוטומציה — זה מה שמבדיל SRE מ-DevOps.
• SLO/SLI ו-Error Budgets: חשיבה כמותית על אמינות.

מה ללמוד ובאיזה סדר — מפת דרכים

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

שלב	מה לומדים	זמן טיפוסי
1. בסיס תשתית	לינוקס, רשתות, Docker	2 חודשים
2. תזמור	Kubernetes לעומק	2-3 חודשים
3. תצפיתיות	Prometheus + Grafana	1-2 חודשים
4. תכנות	Python או Go לאוטומציה	2 חודשים
5. תרבות אמינות	SLO/SLI, postmortems, on-call	שוטף

לראייה של הביקוש בפועל, עיינו במשרות Kubernetes (110 פתוחות), לצד משרות Prometheus ו-Grafana.

מאיזה רקע מגיעים לתפקיד SRE

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

איך בונים ניסיון ותיק עבודות

ל-SRE קשה להיכנס ישר מהלימודים — הוא דורש בגרות מערכתית. הדרכים המעשיות:

• מעבר מ-DevOps או פיתוח: המסלול הנפוץ ביותר. מתחילים כ-DevOps או מפתח Backend, ומתמחים בהדרגה באמינות וניטור.
• מעבדת ניטור אישית: הקימו אשכול Kubernetes, פרסו עליו אפליקציה, וחברו מערך ניטור מלא של Prometheus ו-Grafana עם התראות אמיתיות.
• סימולציית תקלות: "שברו" את המערכת שלכם בכוונה ותרגלו זיהוי, תיקון וכתיבת postmortem — זו מיומנות ליבה של SRE.
• אוטומציה בקוד: כתבו כלי קטן ב-Python או Go שפותר בעיה תפעולית אמיתית, כדי להראות את הצד ההנדסי.
• חקר תקלות אמיתיות: קראו postmortems פומביים שחברות גדולות מפרסמות. הם מלמדים כיצד מערכות נשברות בעולם האמיתי ואיך חושבים על אמינות.

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

שכר כניסה — הערכת שוק

אין ב-HiTakeJob נתוני שכר, והמספרים הם הערכת שוק בלבד. מכיוון ש-SRE הוא לרוב תפקיד שני עם רקע קודם, נקודת הפתיחה גבוהה יחסית — כ-22,000–30,000 ש"ח ברוטו לחודש בהתאם לניסיון הקודם ולחברה. השילוב הנדיר של יכולות פיתוח ותשתית מושך את השכר כלפי מעלה. להעמקה ראו שכר מפתחים בישראל לפי תפקיד.

איך מוצאים משרת SRE

המשרות מופיעות תחת Site Reliability Engineer, SRE, ולעיתים חופפות ל-DevOps או Production Engineer. חפשו גם לפי הכלים — Kubernetes, Prometheus, Grafana. הבליטו בקורות החיים ניסיון עם ניטור, on-call ופתרון תקלות. עיינו בלוח המשרות וסננו לפי הטכנולוגיות שלמדתם.

מושגי הליבה שכל SRE חייב להכיר

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

• SLI (Service Level Indicator): מדד מדיד של בריאות השירות — למשל אחוז הבקשות שהצליחו או זמן התגובה החציוני. זה מה שמודדים בפועל.
• SLO (Service Level Objective): היעד שאליו שואפים — למשל "99.9% מהבקשות ייענו תוך 200 מילי-שניות". ה-SLO מגדיר מה נחשב "מספיק טוב".
• Error Budget (תקציב שגיאות): ההפרש בין 100% ל-SLO הוא כמות התקלות ה"מותרת". אם עדיין יש תקציב, אפשר להשיק פיצ'רים; אם הוא נגמר, עוצרים ומייצבים.
• Toil (עבודה שחוקה): משימות ידניות חוזרות שאפשר וצריך לאוטמט. הפחתת ה-Toil היא מדד להצלחת SRE.
• Postmortem: תחקיר תקלה ללא האשמות (blameless), שמטרתו למנוע הישנות ולא למצוא אשם.

שליטה במושגים אלה בראיון משדרת בגרות מקצועית ומבדילה מועמד SRE ממי שרק "מכיר את הכלים".

תוכנית עבודה מציאותית ל-6-9 חודשים

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

חודשים	מוקד	תוצר מוחשי
1-2	לינוקס, רשתות, Docker לעומק	הבנת מערכת ההפעלה ברמת פתרון תקלות
3-4	Kubernetes — לא רק הפעלה אלא הבנה פנימית	אשכול עם אפליקציה מרובת שירותים
5-6	Prometheus + Grafana ותצפיתיות	מערך ניטור מלא עם התראות אמיתיות
6-7	Python או Go לאוטומציה	כלי שפותר בעיה תפעולית אמיתית
8-9	תרבות אמינות + מעבר פנימי	SLO/SLI, סימולציית תקלות, postmortem

דוגמה מהשטח: המסלול של עומר

נניח שעומר עבד כשלוש שנים כמפתח Backend בחברת מוצר. הוא היה זה שתמיד נמשך לשאלות של "מה קורה כשזה נשבר בייצור?", והרבה פעמים מצא את עצמו מדבג תקלות זמינות. הוא הבין שהתשוקה שלו היא אמינות מערכות, ורצה לעבור ל-SRE. היתרון שלו היה משמעותי: הוא כבר ידע לכתוב קוד ברמה גבוהה — בדיוק מה שמבדיל SRE מ-DevOps. הפער היה בצד התשתית העמוקה ובחשיבת האמינות הכמותית. במשך שמונה חודשים, לצד עבודתו, הוא הקים במחשב מעבדת ניטור: אשכול Kubernetes מקומי, אפליקציה פרוסה עליו, ומערך מלא של Prometheus ו-Grafana. הוא לא הסתפק בהקמה — הוא "שבר" את המערכת בכוונה, תרגל זיהוי ותיקון, וכתב postmortems. במקביל למד לעומק את מושגי ה-SLO, SLI ו-Error Budget. את הצעד המכריע עשה בתוך החברה: הוא הציע לצוות לאמץ SLOs לשירות שהוא אחראי עליו, וכך צבר ניסיון SRE אמיתי עוד לפני שהחליף תפקיד. כשעבר, המעבר היה טבעי — הוא כבר "חשב כמו SRE". הלקח: המסלול הטבעי ל-SRE עובר דרך צבירת ניסיון אמיתי בייצור, לרוב מתוך התפקיד הקיים.

פרויקטים לדוגמה שכדאי לבנות

ל-SRE, הפרויקט צריך להוכיח חשיבת אמינות שיטתית, לא רק היכרות עם כלים:

• מעבדת ניטור מלאה: אשכול Kubernetes עם אפליקציה, מנוטרת מקצה לקצה ב-Prometheus ו-Grafana, עם התראות שמופעלות באמת כשמשהו משתבש.
• סימולציית תקלה + postmortem: "שברו" את המערכת בכוונה, תעדו את הזיהוי והתיקון, וכתבו תחקיר blameless. זו מיומנות ליבה של SRE.
• הגדרת SLO/SLI: קחו שירות והגדירו לו יעדי אמינות מדידים, עם dashboard שמראה עמידה בהם ותקציב שגיאות.
• כלי אוטומציה שמפחית Toil: כתבו ב-Python או Go כלי שמבצע משימה תפעולית חוזרת אוטומטית — זה מדגים את הצד ההנדסי.
• מנגנון התאוששות אוטומטית: הגדירו מערכת שמזהה כשל ומתאוששת ממנו בעצמה (למשל self-healing ב-Kubernetes) — זו מהות התפקיד.

צ'קליסט מוכנות למעבר ל-SRE

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

• יש לי כבר ניסיון בפיתוח Backend או ב-DevOps בייצור.
• אני כותב/ת קוד אמיתי (Python או Go), לא רק סקריפטים.
• אני מבין/ה Kubernetes לעומק ויודע/ת לפתור בו תקלות.
• הקמתי מערך ניטור מלא עם Prometheus ו-Grafana והתראות אמיתיות.
• אני מבין/ה ויודע/ת ליישם SLO, SLI ו-Error Budget.
• תרגלתי סימולציית תקלה וכתבתי postmortem מסוג blameless.
• אני חושב/ת על אמינות באופן שיטתי — זיהוי, התאוששות ומניעה.
• אני יודע/ת לזהות Toil ולהפחית אותו באמצעות אוטומציה.

שאלות נפוצות

מה ההבדל בין SRE ל-DevOps?

DevOps מתמקד בצינור מהקוד לייצור ובאוטומציה של אספקה, ואילו SRE מתמקד באמינות ובזמינות של המערכת בייצור, עם דגש כמותי (SLO/SLI) ועל כתיבת קוד. בפועל התפקידים חופפים, אך SRE נוטה לדרוש יותר יכולות תכנות ובגרות מערכתית.

האם אפשר להיכנס ל-SRE ישר מהלימודים?

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

איזה כלי ניטור הכי חשוב ללמוד?

הצמד Prometheus ו-Grafana הוא הסטנדרט התעשייתי: Prometheus אוסף מטריקות ו-Grafana מציג אותן ומגדיר התראות. שליטה בשניהם, יחד עם הבנה של איסוף לוגים, היא הבסיס לתצפיתיות (observability) בתפקיד.

כמה תכנות באמת צריך SRE?

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

האם on-call הוא חלק בלתי נמנע מהתפקיד?

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