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

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

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

מאת עידו מגור, מפתח תוכנה ב-Carbyne בצוות ה-Real-Time software communication

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

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

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

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

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

לצמצם זמנים ולהגדיל את הזמינות

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

1. קיצור זמן פריסת גרסה ועדכון גרסה: כשמפתחים מוצר, במקרים רבים מדובר באפליקציה אחת שאפשר להריץ בפקודה פשוטה. אבל כשיש כמה אפליקציות, זה כבר הופך ליותר מסובך. אחד הפרויקטים שלנו, למשל, מורכב מחמש אפליקציות שונות: שלוש אפליקציות שמאפשרות לבצע לקיחת שמע של השיחה שמתנהלת בין הלקוח (טלפון נייד) מול ה-Operator ב-PSAP, ושתי אפליקציות שמאפשרות לבצע ניהול של ה-Data למען מניפולציות, פיענוח השמע ל-Text באמצעות שירותי NLP ב-AWS וכמובן לשימוש של הקלטה.

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

רצינו למצוא דרך יעילה וקצרה לסנכרן בין האפליקציות למערכת ההפעלה שלהן, לצמצם את הזמן שבו המכונות לא פועלות ולעשות את התהליך כולו באופן אוטומטי. לצורך כך בחרנו לעבור לשימוש ב-Docker תוך כדי בניית תהליך CI/CD. השימוש בטכנולוגיית קונטיינרים – ובמקרה שלנו Docker – מאפשר לנו לעטוף את כל סביבת הפרויקט ממערכת ההפעלה, קונפיגורציות, והאפליקציות, בתצורה שמאפשרת לקחת את העטיפה הזו שנקראת Docker Image ולהריצה כ-Container – בסביבות הפיתוח, ב-Production או אפילו על המחשב האישי שלי למטרות בדיקה.

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

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

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

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

למעשה, אנחנו מבינים שבגלל שלא מדובר רק ב-API של HTTP, אנחנו צריכים לנהל State מסוים שיודע להגיד לנו איפה האודיו או הווידאו נמצאים, ואיך אנחנו ניגשים אליהם.

יצרנו פתרון שדוגם את סביבת הענן ויודע אילו מכונות זמינות לשימוש ואם הן תקינות, ובהתאם מנתב אליהן את הדיווחים השונים (בהתאם למוצרים השונים). פיתחנו תהליך שאנחנו קוראים לו Discovery Flow, שבודק מדי X שניות את המכונות של AWS על פי אזורים ספציפיים בעולם, אותם אנחנו מגדירים לפי הצרכים של המוצרים שלנו. ה-Discovery flow דוגם את הענן לפי המכונות ומחפש אילו מהן שמישות. לאחר מכן יצרנו תשתית הגורמת למכונה שאינה פעילה להפיל את עצמה, וכך ה-Discovery flow מסמן אותה כלא תקינה ומוחק אותה.

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

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

האתגרים הבאים

כדי להבטיח רציפות תפקודית מלאה בדיווחים קיימים, עלינו להתמודד עם עוד כמה אתגרים – כולם נמצאים בתהליכי Design וחשיבה על תהליכי המימוש במערכת:

  • להפוך את מערכת הקלטת השיחות לכזו שיכולה להתמודד עם שגיאות או נפילות, ומצליחה להמשיך להקליט את השיחה הקולית בין גוף החירום ללקוח הקצה שמדווח על האירוע. הפתרון יעבוד גם על דיווחים חדשים וגם על דיווחים פעילים, שידעו להמשיך לבצע את ההקלטה בהצלחה.
  • להפוך את לקוחות הקצה שלנו – הגופים המנהלים את מצבי החירום ומי שמדווחים על אירוע – לכאלו שיצליחו לשלוח ולקבל וידאו לשרתים המתאימים גם במקרים של שגיאות ונפילות. התמיכה תתבצע ב-Live ואנחנו נדע להתמודד עם שגיאות ונפילות ל-Reportים פעילים מול PSAP-ים.
  • להפוך את מערכות הקלטות הווידאו והאודיו לכאלו שיודעות להתמודד עם שגיאות מצד שרת המדיה, ויודעות לעבור לשרת מדיה אחר במקרה הצורך.
  • לבצע מעבר ל-Kubernetes. הפתרונות הללו והשימוש ב-Docker הופכים את המעבר לפחות פשוט לביצוע.

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

הכתבה בחסות Carbyne

חברת Carbyne אשר נוסדה בשנת 2015, היא המובילה העולמית בחדשנות טכנולוגית בתחום ביטחון הציבור ושירותי החירום. טכנולוגיית החברה מבוססת ענן מאגדת את המידע החיוני להצלת חיים במוקדי חירום לפלטפורמה אחידה ואינטראקטיבית המאפשרת הורדת זמן התגובה באירוע חירום, הגדלת אפקטיביות המענה וסיפוק ביטחון מירבי לכוחות החילוץ והאזרחים. בעזרת שירותי הליבה שהחברה מספקת כגון מיקום מדויק של המתקשר, וידאו' צ'אט ומסרונים ישירים נוצר לראשונה קשר חי עם האזרח מה שמספק תמונת מצב מהירה ותגובה מידית אשר בסופו של דבר מצילים חיים. לחברה יש 3 משרדים בעולם, והיא מעסיקה מעל 200 עובדים ונותנת שירות למעל ל- 450,000,000 אזרחים בשיתופי פעולה אסטרטגיים עם חברות כמו מיקרוסופט, אמזון, Global Medical Response , GeoComm ו- Central Square , אשר מאפשרות לה לספק ללקוחותיה שירותים נוספים ולהישאר בחזית המענה לשעת חירום.
www.carbyne.com

כתב אורח

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

הגב

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

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
שי א.
Guest

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

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

על זה בדיוק אני מדבר כאן:

humanitec.com/webinars/debugging-kubernetes-in-production

EEE
Guest

בKubernetes אפשר להשתמש בprobes ולנתב תעבורה רק לקונטיינרים בהם השירות זמין ותקין.

wpDiscuz

תגיות לכתבה: