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

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

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

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

אם האינטרנט נופל, המרכזיה בענן ממשיכה לעבוד?

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

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

איך מבטיחים המשכיות שירות במרכזיה בענן בזמן תקלת רשת או חשמל?

בצד הספק, המשכיות השירות (High Availability) מבוססת על יתירות: שרתים שממוקמים בכמה דאטה-סנטרים, מערכות חשמל וגיבוי (UPS, גנרטורים) ומנגנוני ניתוב שמפנים את התנועה לשרת זמין אחר במקרה של תקלה. ספקי מרכזיה בענן עובדים לרוב על תשתית ענן שמבוזרת במספר אתרים גיאוגרפיים, מה שמקטין מאוד את הסיכון להשבתה מלאה. 

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

איך מבטיחים איכות שיחה גבוהה במרכזיה בענן (Latency, Jitter)?

איכות שיחה ב – VoIP מושפעת בעיקר משלושה פרמטרים ברשת:

• Latency (השהייה): הזמן שלוקח לחבילות קול לעבור מצד אחד לצד השני.
• Jitter: שינוי לא אחיד בזמן ההגעה של החבילות.
• Packet Loss: חבילות שנעלמות בדרך.

כדי להבטיח שיחה חלקה, מקובל לכוון ל – Latency נמוך מ – 150ms ו – Jitter  נמוך מ – 30ms, עם איבוד חבילות מינימלי ככל האפשר. 

בצד המעשי, עושים כמה דברים: מחברים את עמדות הטלפון בחיווט קווי ולא רק ב – Wi-Fi, מגדירים בנתב QoS (Quality of Service) שמעדיף תעבורת קול על פני גלישה רגילה, בוחרים ספק אינטרנט יציב, ומשתמשים בכלי ניטור שיכולים לזהות Latency/Jitter חריגים ולפתור בעיות לפני שהן מורגשות אצל הלקוחות.

איזה רוחב פס נדרש להפעלת מרכזיה בענן בצורה יציבה?

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

• כ – 40-100 ק״ביט לשנייה לכל שיחה פעילה (כולל תקורה של הפרוטוקולים), תלוי בקודק (G.711, Opus וכו’). 

כלומר:

• 5 שיחות במקביל → מומלץ מינימום 0.5-1 Mbps ייעודיים לקול
• 10 שיחות במקביל → סביב 1-2 Mbps לקול
• 20 שיחות במקביל → סביב 2-4 Mbps

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

מה זה SLA במרכזיה בענן ואיך הוא משפיע על אמינות השירות?

SLA (Service Level Agreement) הוא הסכם רמת שירות בין הספק ללקוח. במסגרתו הספק מתחייב על פרמטרים כמו:

• אחוז זמינות (למשל 99.9% Uptime בשנה)
• זמני תגובה לתקלות
• זמני תיקון (MTTR)
• חלונות תחזוקה מתוכננים
• אופן הדיווח והזיכוי במקרה של חריגה מההתחייבות

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

איפה נשמרים השרתים והנתונים של מרכזיה בענן?

בדרך כלל, שרתי מרכזיה בענן נמצאים בדאטה-סנטרים ייעודיים, לעיתים בישראל ולעיתים במספר אתרים בעולם. ספקים רבים משתמשים בתשתיות ענן גלובליות (כמו AWS, Azure וכו’) ומפזרים את השירות על פני כמה אזורים גיאוגרפיים כדי לשפר גם אמינות וגם Latency. 

מבחינת הלקוח, חשוב לשאול:

• האם הנתונים נשמרים בישראל, באירופה או במדינות אחרות?
• האם הדאטה-סנטר עומד בתקנים כמו ISO 27001 או PCI? 
• האם קיימת הפרדה לוגית בין לקוחות שונים (Multi-Tenancy מאובטח)?

חשוב לדעת כי המיקום משפיע גם על עמידה ברגולציה (GDPR/חוק הגנת הפרטיות) וגם על זמני התגובה בשיחה.

איך מתבצע גיבוי ושחזור המידע במרכזיה בענן?

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

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

• RPO – כמה זמן אחורה אפשר לשחזר (יום, שבוע, חודש).
• RTO – כמה זמן לוקח עד שהמערכת חוזרת לפעולה לאחר תקלה.

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

אז, איך מבטיחים שהמרכזיה בענן תעבוד תמיד?

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

• יתירות בשני הצדדים: גיבוי תשתית אצל הספק (דאטה-סנטרים מרובים) וגיבוי מקומי אצלכם (שני חיבורי אינטרנט, ניתוב לניידים)
• תכנון רוחב פס נכון: חישוב לפי שיחות במקביל, לא לפי מספר עובדים, עם מרווח ביטחון
• אופטימיזציה לאיכות: QoS בנתב, חיבור קווי לטלפונים, ניטור Latency ו – Jitter
• SLA ברור: הבנת ההתחייבות של הספק לזמינות, זמני תגובה וזיכוי
• גיבוי ושחזור: וידוא שההקלטות, הלוגים וההגדרות נשמרים ונגישים לשחזור

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

רוצים לוודא שהמרכזיה שלכם תמשיך לעבוד גם במצבי חירום? צרו קשר עם צור יועצים Tzur-com לייעוץ מקצועי והערכת מוכנות ללא התחייבות.

רוצים לדעת יותר ?

אני זמין לייעוץ ,שאלה, הדרכה,
חינם ללא כל תשלום.

03-573-3333
אפשר גם במייל : [email protected]

נכתב ע”י צור לוזון
בעל ניסיון בתחום מרכזיות של מעל ל-4 עשורים .