גם אם זה שיטפון, 1C אמור לעבוד! אנחנו מסכימים עם העסק ב-DR

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

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

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

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

• על מה אנחנו מגנים?
• ממה אנחנו מגנים?
• כמה אנחנו מגנים? 

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

על מה אנחנו מגנים: זיהוי פונקציות עסקיות קריטיות 

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

מומחה IT עשוי להתקשות במשא ומתן כזה מכמה סיבות:

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

הייתי בונה את השיחה כך: 

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

   תשובה פשוטה נדרשת מהעסק, למשל: המוקד צריך להמשיך ברישום פניות 24/7.

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

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

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

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

ממה אנחנו מגנים: סיכונים

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

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

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

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

לאחר הדיון נבין כיצד לתעדף נקודות כשל. 

כמה אנחנו מגנים: RPO ו-RTO 

כאשר נקודות הכשל הקריטיות ברורות, אנו מחשבים את מחווני ה-RTO וה-RPO. 

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

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

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

בואו נסתכל על דוגמה ספציפית. המשתמש מתחבר ל-1C, המערכת נפתחת עם שגיאת מסד נתונים. הוא יוצר קשר עם מנהל המערכת. מסד הנתונים ממוקם בענן, מנהל המערכת מדווח על הבעיה לספק השירות. נניח שכל התקשורת נמשכת 15 דקות. בענן, מסד נתונים בגודל זה ישוחזר מגיבוי תוך שעה, לכן, ה-RTO בצד ספק השירות הוא שעה. אבל זה לא המועד האחרון; עבור המשתמש נוספו לו 15 דקות כדי לזהות את הבעיה. 
 
לאחר מכן, מנהל המערכת צריך לבדוק שמסד הנתונים תקין, לחבר אותו ל-1C ולהפעיל את השירותים. זה דורש עוד שעה, מה שאומר שה-RTO בצד של המנהל הוא כבר שעתיים ו-2 דקות. המשתמש צריך עוד 15 דקות: היכנס, בדוק שהעסקאות הדרושות הופיעו. 15 שעות 2 דקות הוא זמן שחזור השירות הכולל בדוגמה זו.

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

איך אנחנו מגנים: בחירת כלים לסיכונים שונים

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

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

1. מארח את האפליקציה בענן 

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

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

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

2. אשכול את האפליקציה  

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

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

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

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

3. עבור לענן חסין אסונות

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

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

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

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

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

4. ארגן שכפול לאתר אחר 

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

   RPO ו-RTO: מ-5 דקות. 

   עלות: יקר יותר מהאפשרות הראשונה, אבל זול יותר משכפול חומרה בענן חסין אסונות. המחיר מורכב מעלות רישיון vCAV, דמי ניהול, עלות משאבי ענן ומשאבי רזרבה לפי מודל PAYG (10% מעלות משאבי העבודה עבור מכשירי VM כבויים).

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

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

5. אל תשכח את הגיבוי

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

באופן קפדני, גיבוי אינו DR. וזה למה: 

• כבר זמן רב ש. אם הנתונים נמדדים בטרה-בייט, השחזור ייקח יותר משעה. צריך לשחזר, להקצות רשת, לבדוק שהיא נדלקת, לראות שהנתונים מסודרים. אז אתה יכול לספק RTO טוב רק אם יש מעט נתונים. 
• ייתכן שהנתונים לא ישוחזרו בפעם הראשונה, ואתה צריך לתת זמן לחזור על הפעולה. לדוגמה, ישנם מקרים בהם איננו יודעים בדיוק מתי אבדו הנתונים. נניח שהאובדן הובחן בשעה 15.00, ונעשים עותקים כל שעה. מהשעה 15.00 אנו מסתכלים על כל נקודות ההתאוששות: 14:00, 13:00 וכן הלאה. אם המערכת חשובה, אנו מנסים למזער את גיל נקודת ההחלמה. אבל אם הגיבוי הטרי לא הכיל את הנתונים הדרושים, ניקח את הנקודה הבאה - זה זמן נוסף. 

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

תוכנית ההתאוששות הסופית מאסון צריכה להכיל לפחות 2 כלים:  

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

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

מקור: www.habr.com