יעד RTO על הנייר
בכל תוכנית המשכיות עסקית (BCP – Business Continuity Plan), המסמך שקובע כיצד הארגון ימשיך לתפקד בעת השבתה או אסון, מופיע המונח RTO (Recovery Time Objective) – יעד זמן ההתאוששות: כמה זמן מותר למערכת להיות מושבתת עד שהיא חוזרת לעבודה. ההנהלה מאשרת ארבע שעות למערכות הליבה, יממה לדואר, יומיים לשרת הקבצים, והמספרים נכנסים למסמך, למצגת ולביקורת השנתית.
השאלה הפשוטה שכמעט אף אחד לא שואל היא: על מה מבוסס המספר הזה?
ברוב המקרים התשובה היא חישוב. נפח הנתונים חלקי רוחב הפס של הקו, או קצב הקריאה שמופיע בדף הנתונים של ציוד האחסון, או הערכה מקצועית של מי שהקים את המערך. כל אלה מספרים סבירים, אבל אף אחד מהם אינו מדידה. ובין חישוב למדידה יכול להיות פער של סדר גודל שלם.
דוגמה מהשטח
בפרויקט המשכיות עסקית שליווינו לאחרונה בארגון רב-אתרי, סביבת השרתים כולה פועלת בענן של ספק, ומגובה להתקן אחסון ייעודי במשרדי הארגון. הערכת התכנון לקצב השחזור עמדה על 120 עד 180 ג'יגה לשעה, מספר שנגזר מרוחב הפס ומנתוני היצרן, ועל בסיסו נקבע יעד של ארבע שעות למערכות הליבה.
במסגרת שחזורים יזומים שאנחנו מבצעים בשגרה, ניצלנו את ההזדמנות למדוד. שחזור מלא של שרת בודד, במסלול האמיתי של שעת אירוע, הניב כשמונה ג'יגה לשעה. הקו היה פנוי כמעט לחלוטין, והכתיבה ליעד לא הייתה הבעיה. צוואר הבקבוק היה הקריאה מאחסון הגיבוי: שרשרת ארוכה של גיבויים מצטברים על דיסקים מכניים, שהתוכנה צריכה להרכיב ממנה את התמונה השלמה, פעולה שמטבעה איטית באחסון מסוג זה. בקצב הזה, יעד ארבע השעות הפך ליעד של ימים.
חשוב להדגיש: זו רק דוגמה אחת. התצורה שם הייתה סבירה לחלוטין לנתונים שהיו זמינים בעת התכנון, והמדידה לא חשפה כשל של מוצר או של הגדרה, אלא תכונה של סוג האחסון. הנקודה היא לא איפה נמצא הפער, אלא שבלי מדידה אף אחד לא ידע שהוא קיים.
הפער יכול להתחבא בכל מקום
באותה מידה בדיוק, המדידה הייתה יכולה לחשוף פער במקום אחר לגמרי. רוחב הפס הוא החשוד הראשון, ולפעמים הוא באמת האשם: קו שנראה רחב על הנייר מתגלה כמשותף לגיבוי, לתעבורה שוטפת ולשחזור בו זמנית. שחזורים מקבילים הם מקור נפוץ אחר: ההנחה שהרצת כמה שחזורים בו זמנית מקצרת את הזמן הכולל נכונה רק כשהתשתית שמתחת יודעת לשרת כמה זרמים, ובמקרים רבים כל זרם נוסף מאט את האחרים. גם כשהנתונים כבר הועברו, השכבה היישומית יכולה להפתיע: בסיס נתונים שדורש שעות של בדיקת עקביות לפני שהוא מוכן לעבודה, אפליקציה שקוראת את הנתונים באיטיות מאחסון חדש, או שרת שעולה בהצלחה אך לא מתפקד בגלל פגם שקט במערכת הקבצים, שהגיבוי העתיק בנאמנות מהמקור.
לכל אחד מהפערים האלה יש פתרון, ורובם זולים יחסית. אבל אין דרך לדעת איזה מהם רלוונטי לארגון שלכם בלי להריץ את השחזור באמת ולמדוד אותו.
איך מודדים נכון?
מדידה טובה של מהירות שחזור אינה תרגיל תיאורטי אלא פעולה שגרתית. הנה מה שלמדנו שעובד.
מודדים במסלול האמיתי: מאחסון הגיבוי, דרך הקו, אל היעד שבו השרת יעלה ביום האירוע. שחזור בתוך אותה רשת מקומית ייתן מספר יפה ולא רלוונטי.
מודדים כמה תרחישים ולא אחד: שחזור של תיקיית קבצים, שחזור מלא של שרת בודד, ושני שרתים במקביל. כל תרחיש חושף צוואר בקבוק אחר, והיחס ביניהם מלמד יותר מכל מספר בודד.
רושמים לא רק את הזמן אלא גם את הסיבה: רוב מערכות הגיבוי המודרניות מציגות היכן התבזבז זמן השחזור, בקריאה מהמקור, בהעברה, בהצפנה או בכתיבה ליעד. הנתון הזה הוא ההבדל בין "איטי" לבין "יודעים מה לתקן".
מוודאים שהשרת עובד, לא רק שהנתונים הגיעו: שרת משוחזר שאינו מאותחל, או אפליקציה שאינה מתחברת לבסיס הנתונים שלה, הם שחזור שנכשל, גם אם המערכת דיווחה על הצלחה.
וחוזרים על זה: אחת לרבעון, לכל שרת קריטי, כחלק מהתחזוקה. סביבות משתנות, שרשראות גיבוי מתארכות, ומספר שנמדד לפני שנה כבר אינו מספר.
מה עושים עם התוצאה?
כשהמדידה מסתיימת יש שלוש אפשרויות, וכולן לגיטימיות. אפשר לקצר את זמן השחזור: לקצר את שרשרת הגיבוי, להוסיף אחסון מהיר, לשמור עותק שני ליד היעד, או להחזיק מכונות מוכנות מראש. אפשר לעדכן את היעד כך שישקף את המציאות, ולבנות סביבו נהלים ידניים שמאפשרים לעסק להמשיך בזמן ההמתנה. ואפשר לשלב, ולהחליט לכל מערכת בנפרד לפי העלות והנזק.
ובכל אחת מהאפשרויות יש המלצת חובה אחת, שאינה נתונה לבחירה: לתכנן את סדר השחזור מראש כך שפעילות הליבה חוזרת קודם. לא כל השרתים שווים, ושחזור לפי מה שנוח לטכנאי הוא הדרך הבטוחה להחזיר ראשונים את השרתים שאיש אינו ממתין להם. סדר השחזור נגזר מניתוח ההשפעה העסקית: קודם המערכות שבלעדיהן אין מכירה, אספקה או ייצור, יחד עם התשתית שהן תלויות בה, כמו שרתי ההזדהות, ורק אחר כך כל השאר. את הסדר הזה כותבים בנוהל, בודקים בתרגיל, ומודדים בנפרד: זמן החזרה של הליבה הוא המספר שמעניין את ההנהלה, גם כשהשחזור המלא עדיין רחוק.
מה שאינו לגיטימי הוא להשאיר במסמך יעד שאיש לא מדד. יעד כזה לא מגן על העסק, הוא רק מרגיע את מי שקורא את המסמך. ההנהלה זכאית לדעת מה זמן החזרה האמיתי, ולקבל את ההחלטה על העלות מול הזמן בעיניים פקוחות.
תוכנית המשכיות עסקית טובה אינה נמדדת באיכות המסמך אלא במה שקורה כשמפעילים אותה. הדרך היחידה לדעת מה יקרה היא להפעיל אותה קודם, בשקט, ביום רגיל, עם שעון ביד.
אם הנושא הזה פתוח אצלכם – נשמח לשמוע איך אתם מטפלים בו. מוזמנים לכתוב לנו.
https://tom-comp.com/צור-קשר
