גיבויים ותוכנית התאוששות מאסון: מה עושים כשהשרת נופל בשלוש בלילה

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

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

מה בעצם ההבדל בין גיבוי לתוכנית התאוששות

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

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

שני מדדים שכל בעל עסק חייב להכיר

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

• RTO (Recovery Time Objective) - כמה זמן מותר למערכת להיות לא זמינה עד שהיא חוזרת לפעול. אם החנות הדיגיטלית שלכם עוצרת ל-6 שעות, כמה הפסד הכנסות זה?
• RPO (Recovery Point Objective) - כמה מידע מותר לכם לאבד. אם הגיבוי האחרון נעשה לפני 24 שעות, כל הפעולות שהתבצעו מאז יאבדו.

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

כלל 3-2-1 שממש שווה לאמץ

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

• עותק אחד חי, שרץ כרגע בפרודקשן
• עותק שני בגיבוי אוטומטי על ידי הספק (למשל snapshot יומי ב-AWS או GCP)
• עותק שלישי בענן אחר או בחשבון נפרד לגמרי, כדי שאם חשבון הענן שלכם ננעל או נפרץ, יש לכם גם לאן לברוח

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

בדיקות שחזור, לא רק גיבויים

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

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

מה זה אומר בפועל, לפי גודל העסק

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

• סטארטאפ בשלב MVP: גיבוי אוטומטי יומי של מסד הנתונים, שמור בענן נפרד, ותיעוד קצר של איך משחזרים
• עסק עם לקוחות משלמים: גיבויים אוטומטיים כל כמה שעות, סביבת Staging שאפשר להעלות עליה מהר, ובעל תפקיד מוגדר שאחראי על תגובה לאירועי חירום
• מוצר בסקאלה עם SLA ללקוחות עסקיים: אזורי גיבוי גיאוגרפיים נפרדים (Multi-Region), ניטור אוטומטי שמתריע על כשל, ותוכנית תגובה כתובה שכל הצוות מכיר

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

מסמך אחד שיחסוך לכם הרבה כאב ראש

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

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