תוכנית Disaster Recovery: כדי שלא נסבול ממה שקרה למערכת הבריאות באירלנד

מדור הדאטה החדש שלנו נותן את הבמה לצוותי הדאטה הכי מעניינים שפועלים בישראל. והפעם: מה יקרה אם כל הדאטה שלכם, כולל בסיסי הנתונים וכל רכיבי ה-compute, יעלמו? הפתרון הוא בהיערכות מראש, בעזרת Disaster Recovery. מדריך – חלק ראשון

מאת מיקי שרייבר, ר"צ Data Technologies ב-Next Insurance

ביום רביעי, 14 במאי 2021, מערכת הבריאות של אירלנד (HSE) נפלה קורבן למתקפת כופר. עשרות שירותי בריאות הפסיקו לעבוד; חמישה בתי חולים הושפעו קשות ביכולת להעניק טיפול רפואי; מערכות השכר נפלו, מה שעיכב את תשלום המשכורות ל-146 אלף איש; תוצאות בדיקות הקורונה התעכבו והאתר באמצעותו קבעו זימון לחיסוני קורונה לא היה זמין. למערכת הבריאות של אירלנד לקח לא פחות משלושה חודשים לחזור לפעילות מלאה.

תארו לעצמכם את התרחיש הבא: יש לכם מערכת BI מצויינת – ה-ETL עובד מסביב לשעון, הדו"חות מציגים כל מה שצריך והלקוחות מרוצים. גורם עוין מנסה להרוס את פעילות החברה אך לא מצליח לחדור למערכת האופרטיבית עצמה, אז הוא מסתכל ימינה ושמאלה ורואה ב-BI הזדמנות לעשות נזק.
ביום בהיר אחד כל המערכת נעלמת – לא רק המידע עצמו, אלא הכל: בסיסי הנתונים, ה-buckets, ה-pipelines, ה-schedulers, מערכת ה-reporting וכל רכיבי ה-compute. גם הקונפיגורציות של כל אלה נעלמות.

הפתרון לתרחיש המלחיץ הזה טמון בהיערכות מראש, או במילים אחרות – (Disaster Recovery (DR. מדובר בקונספט שבו אנחנו מגבים כל הזמן את המידע במקום אחר, כמה שיותר רחוק מהישג ידם של גורמים עוינים (וגם שלנו – נגיע לזה בהמשך). לפי הרעיון של DR, אנחנו צריכים להגיע למצב שבו אנחנו יכולים להקים את כל התשתית שלנו בלחיצת כפתור במיקום חדש. על מנת להגיע לשם, אנחנו נעזרים בקונספט של Infrastructure as Code (IaaC). הרעיון הוא שהתשתית שלנו מיוצגת על ידי קוד (שפות כגון Chef ,Puppet ,Terraform ועוד) ובשעת משבר נוכל פשוט להריץ את הקוד במיקום חדש ולקבל את התשתית המוכרת לנו.

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

אז איך Disaster Recovery עוזר לנו במקרה של מתקפת כופרה?

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

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

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

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

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

חשוב לציין שישנם גם שירותים חינמיים בענן. לרוב אלו הם שירותי ניהול ובקרת תצורה – לדוגמה, ה-Parameter store בתוך AWS System Manager הוא שירות ללא עלות. גם בשירותים חינמיים אפשר לראות את רכיבי המערכת, אבל לא בפורטל התשלומים (כי לא משלמים עליהם). לכן חשוב להיות מודעים לחיסרון הזה מבעוד מועד.

עוד דבר שחשוב להבין בהקשר הזה הוא שעלות נמוכה לאו דווקא מציינת שהשירות אינו חשוב או מרכזי. לדוגמה, העלות של AWS Secrets Manager היא אפסית (40 סנט לכל secret לחודש), אך זהו המקום שבו (לפחות אצלנו) המפתחות הסודיים נשמרים. ללא השירות הזה יתר השירותים לא יוכלו לתפקד ולתקשר אחד עם השני ועם גורמי צד שלישי.

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

מנסיוני, הדרך הכי טובה להבין את התלויות במערכת היא לשרטט בתרשים (זה יכול להיות whiteboard או כלי כמו Visio ודומיו) את התלויות שאנחנו מכירים. לאחר מכן יהיה נכון לכנס את כל האנשים שמכירים היטב את המערכת ולהבין יחד איתם מהן התלויות הנסתרות שעוד לא חשבנו עליהן.

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

הכתבה בחסות Big Things

קהילת Big Things הוקמה ב 2014 על ידי דמי בן-ארי ושלומי הסן ומונה היום מעל 6500 אנשים גלובלית, ומנוהלת בשיתוף היום על ידי הצוות המדהים: טל סופר, טל ברדה ואיתי יפה, במטרה לקדם את התחומים של Big Data, Data Science, Cloud וגם DevOps.
את הפעילות עושים בהתנדבות בכדי לתת במה לאנשים המובילים בתעשייה מחברות בכל הגדלים, ולאורך כל השנים מתעסקים בקידום תוכן ואירועים בכדי לשתף ידע וליצור סינרגיה ושיתופים פעולה.
הפעילות כוללת שיתוף תוכן ב Social Media, בקבוצות פעולה, מיטאפים פרונטאליים ווירטואליים וגם האקאטונים ושיתופי פעולה רבים.
נמליץ לכם להירשם לקבוצה המיטאפ וגם לקבוצת הפייסבוק הפעילה.







כתב אורח

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

אין תגובות

התגובות לפוסט סגורות.

תגיות לכתבה: