שרידוּת ואמינות מעל לכל: כך מפתחים מערכת תקשורת לעולם החירום

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

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

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

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

'חמש תשיעיות' ואתגרי שרידוּת בענן

המונח המוכר 'חמש תשיעיות' (Five Nines) מדרג את הזמינוּת של מערכות תוכנה. מערכות בעלות דירוג של חמש תשיעיות הן כאלה שנמצאות 'למעלה' 99.999% מהזמן, או 'למטה' רק 0.001% מהזמן (כלומר 5.25 דקות בלבד של חוסר זמינות בשנה). זהו סטנדרט נכסף עבור מערכות תקשורת במגזר העסקי, וכשבונים מערכת תקשורת ייעודית לשירותי חירום, מדובר בסטנדרט שלא ניתן להתפשר עליו.

כשאנו נדרשים לפתח מערכת תקשורת סקלבילית בפריסה רחבה, בפרט כזאת המיועדת לעולם החירום, אין ברירה אלא להשתמש בדאטה סנטר שנמצא בענן. כל תשתית שקיימת בשוק – בין אם AWS, מיקרוסופט אז'ור (Microsoft Azure), גוגל קלאוד (Google Cloud), או אחרות – משיגה את המטרות הללו: היכולת לפריסה מהירה וגדילה הדרגתית לפי הצורך. יחד עם זאת, כשעובדים בענן, בלתי אפשרי להימנע לחלוטין מנפילות של המערכת, דבר שלא מסתדר עם ההכרח של מערכות חירום לספק זמינות תמידית.

חייב שרידות גבוה ויציבות. מוקד חירום. צילום: אילוסטרציה. שאטרסטוק

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

קודם כל – QA

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

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

תקלות קורות

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

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

מחיר ששווה לשלם

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

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

הכותב הוא סמנכ"ל פיתוח בחברת Carbyne