זמינות ענן של 99.9%: מה זה אומר כשהעסק עוצר?

כמה זמן השבתה מסתתר מאחורי האחוז?

נניח שהצעת השירות מציגה זמינות ענן של 99.9%. קל לקרוא את המספר ולהרגיש שהמערכת כמעט לעולם לא תעצור. אבל בחודש של 30 יום יש 43,200 דקות. עשירית האחוז מהזמן הזה היא 43.2 דקות, כלומר 43 דקות ו־12 שניות. זו המרה חשבונית של יעד זמינות לפי זמן, ולא תחזית למספר התקלות שיקרו אצלכם.

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

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

מה באמת מבטיח הסכם SLA?

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

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

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

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

למה תצורת הענן משנה את ההתחייבות?

אותו מותג ענן יכול להציע תנאים שונים לתצורות שונות. דוגמה מפורשת מופיעה בהסכם השירות של Amazon EC2, שנבדק ב־30 בספטמבר 2026. הוא מציג התחייבות חודשית של 99.99% ברמת האזור לתצורה המתוארת בו עם פריסה מקבילה בשני אזורי זמינות לפחות. לצד זאת, ההתחייבות למופע יחיד היא 99.5%.

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

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

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

הענן תקין, אבל העובדים לא מצליחים לעבוד

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

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

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

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

האם זיכוי מהספק מחזיר את ההפסד?

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

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

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

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

זמינות ענן, גיבוי והתאוששות: שלוש שאלות שונות

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

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

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

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

דוגמה: משרד שמקבל הזמנות בזמן תקלה

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

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

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

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

שבע שאלות שכדאי לשאול על זמינות ענן

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

1. מהי הפעולה העסקית שעליה מודדים זמינות, ומה נחשב כשל?
2. מהי תקופת המדידה, והאם יש החרגות או תנאי סף?
3. איזו תצורה נדרשת כדי לקבל את ההתחייבות שנכתבה בהצעה?
4. מי מקבל התראה ומי מעדכן את הצוות כשהשירות נפגע?
5. מהם יעדי החזרה לעבודה ואובדן המידע לכל מערכת חשובה?
6. מתי בוצע תרגול אחרון, ומה באמת הצליחו העובדים לבצע בו?
7. איך מתעדים תקלה, מבקשים זיכוי ובודקים שהטיפול הושלם?

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

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

מה עושים בדקות הראשונות של ההשבתה?

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

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

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

איך מתרגלים בלי להפריע ללקוחות?

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

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

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

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

שאלות נפוצות על זמינות ענן

האם 99.9% אומר שהתקלה תסתיים בתוך 43 דקות?

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

האם כל עסק צריך לשלם על 99.99%?

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

האם חיבור אינטרנט נוסף פותר נפילה בענן?

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

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

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

מקורות ותאריך בדיקה

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

• Microsoft: הגדרת יעדי אמינות ומדדי זמינות
• Microsoft: כיצד לקרוא הסכם רמת שירות
• AWS: הסכם השירות הרשמי של Amazon EC2
• AWS: מדידת זמינות ותלויות בין מערכות
• Microsoft: המשכיות עסקית, זמינות גבוהה והתאוששות