מחשבון זמינות (Uptime)
הזינו אחוז זמינות כדי לראות בדיוק כמה השבתה הוא מתיר, או הזינו תקלה שכבר קרתה כדי לראות לאיזו רמת SLA היא עדיין עומדת.
זמינות ← השבתה מותרת
- לשנה
- 8 שעות 45 דק' 36 שנ'
- לחודש
- 43 דק' 12 שנ'
- לשבוע
- 10 דק' 5 שנ'
- ליום
- 1 דק' 26 שנ'
תקלה ← זמינות בפועל
זמינות בפועל
99.444%
זה עדיין עומד בהתחייבות של 99%.
התקלה הזו חרגה מרמת SLA מקובלת
התאוששות איטית אחת יכולה לבלוע את כל תקציב ההשבתה של התקופה, לא משנה כמה חלק עבר שאר הזמן. אם זו מגמה ולא מקרה חד-פעמי, הפתרון בדרך כלל ארכיטקטוני — וזה בדיוק מה שאנחנו עושים.
מה בעצם אומר אחוז זמינות?
אחוז זמינות הוא הבטחה לגבי החלק מתוך חלון המדידה שבו השירות יהיה זמין. זמינות של 99.9% פירושה שהשירות רשאי להיות לא זמין עשירית האחוז מהחלון — מה שנשמע זניח עד שממירים אותו לזמן אמיתי ומגלים שהוא מתיר 43 דקות השבתה בכל חודש.
האחוז לבדו כמעט חסר משמעות בלי שלושה פרטים נוספים: אורך חלון המדידה, מה נחשב תקלה, ומי מודד אותה. התחייבות ל-99.9% הנמדדת שנתית סופגת תקלה בודדת של שמונה שעות; אותם 99.9% הנמדדים חודשית — לא. זה הפרט שסביבו מתנהלות רוב המחלוקות על SLA, והוא כמעט תמיד קבור בסעיף ההגדרות במקום להופיע לצד המספר.
איך מחושב זמן ההשבתה המותר
החשבון פשוט, וכדאי לראות אותו ולא רק לסמוך עליו — זמן ההשבתה המותר הוא בדיוק החלק מהחלון שההתחייבות משאירה פתוח.
-
מחסרים את אחוז הזמינות מ-100 כדי לקבל את אי-הזמינות המותרת. עבור 99.9% מתקבל 0.1%.
-
מבטאים זאת כשבר: 0.1% הופך ל-0.001.
-
מכפילים באורך חלון המדידה בשניות. חודש של 30 יום הוא 2,592,000 שניות, ולכן 0.001 × 2,592,000 = 2,592 שניות.
-
ממירים בחזרה ליחידות קריאות: 2,592 שניות הן 43 דקות ו-12 שניות.
המחשבון הזה משתמש בשנה של 365 יום ובחודש של 30 יום — המוסכמה שכל ספקי הענן הגדולים נוקטים ב-SLA שלהם. זה משנה יותר משנדמה: שנה של 365.25 יום הייתה משנה את התוצאה ב-99.999% בכשמונה שניות, וכל מי שישווה את הדף הזה לטבלת SLA של AWS או Azure היה מוצא פער ומאבד אמון בשניהם.
טבלת ייחוס: זמינות מול השבתה
הרמות המקובלות, מומרות. רוב ה-SLA המסחריים נמצאים בין 99.5% ל-99.99%; שורת חמש התשיעיות מופיעה כאן בעיקר משום שמצטטים אותה הרבה יותר מכפי שמתחייבים אליה בחוזה.
| זמינות | לשנה | לחודש | לשבוע | ליום |
|---|---|---|---|---|
| 90% | 36d 12h | 3d | 16h 48m | 2h 24m |
| 95% | 18d 6h | 1d 12h | 8h 24m | 1h 12m |
| 99% | 3d 15h 36m | 7h 12m | 1h 40m 48s | 14m 24s |
| 99.5% | 1d 19h 48m | 3h 36m | 50m 24s | 7m 12s |
| 99.9% | 8h 45m 36s | 43m 12s | 10m 5s | 1m 26s |
| 99.95% | 4h 22m 48s | 21m 36s | 5m 2s | 43s |
| 99.99% | 52m 34s | 4m 19s | 1m | 9s |
| 99.999% | 5m 15s | 26s | 6s | 1s |
מבוסס על שנה של 365 יום וחודש של 30 יום, בהתאם למוסכמה בהסכמי ה-SLA המפורסמים של ספקי הענן.
למה כל תשיעית נוספת עולה כל כך הרבה יותר
כל תשיעית נוספת מקטינה את ההשבתה המותרת פי עשרה, והעלות של השגתה לא יורדת באותו קצב — רחוק מכך. הפער בין 99% ל-99.9% הוא בעיקר עניין של תפעול מיומן. הפער בין 99.9% ל-99.99% הוא בדרך כלל שינוי ארכיטקטוני: יתירות בין אזורי זמינות, מעבר אוטומטי לגיבוי, וסילוק כל נקודת כשל יחידה שהסכמתם לחיות איתה עד היום.
התשיעית האחרונה היא זו שדורשת זהירות. מעבר מ-99.99% ל-99.999% משאיר כחמש דקות השבתה בשנה — פחות מאתחול לא מתוכנן יחיד, ופחות ממה שרוב תהליכי הפריסה צורכים. התחייבות לרמה כזו פירושה שכל פעולת תחזוקה שגרתית חייבת להתבצע בלי הפסקת שירות, וזו תכונה של הארכיטקטורה ולא משהו שצוות תפעול יכול להבטיח בעזרת קפדנות.
איזה אחוז זמינות נכון להתחייב אליו?
הרמה הנכונה היא זו שבה עלות התשיעית הבאה עולה על עלות ההשבתה שהיא מונעת. עבור מערכת דיווח פנימית שמשמשת בשעות העבודה, 99% היא לרוב סבירה לחלוטין ואיש לא מבחין בהבדל. עבור מסלול תשלום או תהליך רכישה, שעת השבתה אחת עשויה לעלות יותר משנה שלמה של התשתית שנדרשת כדי למנוע אותה.
גישה מעשית היא לעבוד לאחור מהתוצאה ולא קדימה מהשאיפה. אמדו כמה שעה של אי-זמינות באמת עולה — עסקאות שאבדו, עובדים מושבתים, עומס תמיכה, קנסות חוזיים — והשוו זאת להשקעה ההנדסית שכל תשיעית נוספת דורשת. התחייבות פומבית לרמה שלא בניתם עבורה ארכיטקטורה גרועה מהתחייבות כנה לרמה נמוכה יותר, כי התקלה הראשונה הופכת בעיה הנדסית לבעיה חוזית.
איך משפרים זמינות
שיפור זמינות עוסק בעיקר בסילוק נקודות כשל יחידות ובקיצור הזמן שלוקח לזהות תקלות שנותרו ולהתאושש מהן. בערך לפי סדר התשואה למאמץ:
- קודם כול, מדדו בכנות. אם אינכם יכולים לומר מה הייתה הזמינות שלכם ברבעון האחרון, כל יעד הוא משאלה. בדיקות סינתטיות מחוץ לרשת שלכם הן המינימום; הן תופסות את התקלות שהניטור הפנימי לא רואה משום שהוא נמצא בתוך הכשל.
- סלקו את נקודות הכשל היחידות שכבר ידועות לכם. רוב הצוותים יכולים לנקוב בהן בשמן — שרת מסד הנתונים היחיד, שלב המעבר הידני לגיבוי, התעודה שמישהו מחדש בעצמו.
- קצרו את זמן הזיהוי. זמן ההתאוששות נשלט בדרך כלל על ידי הזמן עד ההבחנה, לא הזמן עד התיקון, והתרעה על תסמינים שמשתמשים חווים עדיפה על התרעה על מדדי שרתים.
- הפכו את התחזוקה השגרתית ללא-משביתה. ברגע שפריסות, מיגרציות ועדכוני אבטחה כולם דורשים השבתה, התחזוקה המתוכננת שלכם מתחרה ב-SLA על אותו תקציב דקות.
יתירות שווה להוסיף אחרי כל אלה, לא לפניהם. תשתית מיותרת שהמעבר אליה איטי, או שמעולם לא נבדקה תחת כשל אמיתי, נוטה להפוך תקלות קצרות לארוכות במקום למנוע אותן.
דוגמה מעשית: SLA חודשי של 99.9%
נניח שהתחייבתם לזמינות של 99.9% הנמדדת חודשית, ומעבר לגיבוי של מסד הנתונים ארך ארבע שעות ביום שלישי אחר הצהריים.
43m 12s
לחודש
התחייבות חודשית של 99.9% מתירה 43m 12s של השבתה. תקלה של ארבע שעות היא בערך פי חמש וחצי מהתקציב הזה, ומעמידה את החודש על כ-99.44% — עומד ב-99%, אך חורג מ-99.9%.
שימו לב למשמעות עבור שאר החלון: תקלה בודדת של ארבע שעות ממצה את התקציב החודשי כולו, ולכן ה-SLA מופר ללא קשר לכמה מושלמים היו 27 הימים הנותרים. חוסר הסימטריה הזה הוא הסיבה שעבודת הזמינות מתרכזת בזמן ההתאוששות ולא בתדירות הכשלים — התאוששות איטית אחת עולה יותר מכמה מהירות.
שאלות נפוצות
מה בעצם אומר אחוז זמינות?
אחוז זמינות הוא הבטחה לגבי החלק מתוך חלון המדידה שבו השירות יהיה זמין. זמינות של 99.9% פירושה שהשירות רשאי להיות לא זמין עשירית האחוז מהחלון — מה שנשמע זניח עד שממירים אותו לזמן אמיתי ומגלים שהוא מתיר 43 דקות השבתה בכל חודש.
איך מחושב זמן ההשבתה המותר
החשבון פשוט, וכדאי לראות אותו ולא רק לסמוך עליו — זמן ההשבתה המותר הוא בדיוק החלק מהחלון שההתחייבות משאירה פתוח.
איזה אחוז זמינות נכון להתחייב אליו?
הרמה הנכונה היא זו שבה עלות התשיעית הבאה עולה על עלות ההשבתה שהיא מונעת. עבור מערכת דיווח פנימית שמשמשת בשעות העבודה, 99% היא לרוב סבירה לחלוטין ואיש לא מבחין בהבדל. עבור מסלול תשלום או תהליך רכישה, שעת השבתה אחת עשויה לעלות יותר משנה שלמה של התשתית שנדרשת כדי למנוע אותה.
איך משפרים זמינות
שיפור זמינות עוסק בעיקר בסילוק נקודות כשל יחידות ובקיצור הזמן שלוקח לזהות תקלות שנותרו ולהתאושש מהן. בערך לפי סדר התשואה למאמץ:
קריאה נוספת
Cloud Cost Optimization Strategies: 10 Actionable Tactics
Explore 10 actionable cloud cost optimization strategies for mid-market and enterprise teams, covering rightsizing, autoscaling, FinOps, and observability.
What Is Infrastructure as Code: A Complete Guide for 2026
Learn what is infrastructure as code, how declarative and imperative approaches differ, and how to adopt IaC without losing control in 2026.
Business Continuity Best Practices: A 2026 Guide
Explore 10 business continuity best practices for software platforms. Learn to build resilient systems with tips on RTO/RPO, IaC, DR testing, and SRE.
התחייבתם למספר שלא בניתם עבורו ארכיטקטורה?
Ryware מתכננת ומתפעלת מערכות בזמינות גבוהה לארגונים שבהם השבתה נמדדת בהכנסה שאבדה ולא באי-נוחות — יתירות שנבדקה תחת כשל אמיתי, מעבר לגיבוי שמושלם בלי אדם בלולאה, וניטור שמבחין לפני הלקוחות שלכם.