תוכנית היא מסמך, לא מוצר
זו נקודת הפתיחה, והיא זו שנופלת הכי הרבה. אפשר לרכוש שכפול לאתר שני, לשלם עליו כל חודש, ועדיין לא להיות מסוגלים לחזור לעבוד, פשוט כי איש לא הגדיר מראש מי מכריז על אירוע, באיזה סדר מעלים את המערכות ומאיפה מביאים את הסיסמאות. התשתית היא היכולת. התוכנית היא ההחלטה איך משתמשים בה תחת לחץ.
המדריך הזה מניח שכבר ברור מה זה Disaster Recovery ומה המשמעות של RTO ו-RPO. כאן אנחנו עוסקים בשלב הבא: איך הופכים את זה למסמך שמישהו יכול לפתוח ולבצע.
המשכיות עסקית מול התאוששות מאסון
שני המונחים משמשים בערבוביה, וההבדל ביניהם מעשי ולא סמנטי: הם עונים על שתי שאלות שונות, ובדרך כלל צריך את שתיהן.
השאלה
- המשכיות עסקית (BCP)
- איך העסק ממשיך לתפקד בזמן האירוע
- התאוששות מאסון (DRP)
- איך המערכות חוזרות לפעול
ההיקף
- המשכיות עסקית (BCP)
- אנשים, מקום עבודה, ספקים, לקוחות, תזרים
- התאוששות מאסון (DRP)
- שרתים, נתונים, אפליקציות, רשת
מי הבעלים
- המשכיות עסקית (BCP)
- ההנהלה
- התאוששות מאסון (DRP)
- המחשוב, בשיתוף בעלי המערכות
דוגמה לתוכן
- המשכיות עסקית (BCP)
- מאיפה הצוות עובד כשהמשרד לא זמין
- התאוששות מאסון (DRP)
- באיזה סדר מעלים את מסד הנתונים והשרתים
מה קורה בלעדיה
- המשכיות עסקית (BCP)
- המערכות חזרו, אבל איש אינו יודע לתפעל אותן
- התאוששות מאסון (DRP)
- יש נהלים, אבל אין למה לחזור
| המשכיות עסקית (BCP) | התאוששות מאסון (DRP) | |
|---|---|---|
| השאלה | איך העסק ממשיך לתפקד בזמן האירוע | איך המערכות חוזרות לפעול |
| ההיקף | אנשים, מקום עבודה, ספקים, לקוחות, תזרים | שרתים, נתונים, אפליקציות, רשת |
| מי הבעלים | ההנהלה | המחשוב, בשיתוף בעלי המערכות |
| דוגמה לתוכן | מאיפה הצוות עובד כשהמשרד לא זמין | באיזה סדר מעלים את מסד הנתונים והשרתים |
| מה קורה בלעדיה | המערכות חזרו, אבל איש אינו יודע לתפעל אותן | יש נהלים, אבל אין למה לחזור |
שישה שלבים לבניית התוכנית
- 1
ניתוח השפעה עסקית (BIA)
עוברים תהליך אחד אחד ושואלים כמה עולה שעה, יום ושבוע של השבתה: בכסף, בלקוחות ובחשיפה משפטית. זה השלב שקובע כל מה שבא אחריו, והוא שיחה עם בעלי התפקידים ולא משימה טכנית.
- 2
קביעת RTO ו-RPO לכל מערכת
לכל מערכת נקבעים שני מספרים: כמה זמן מותר שהיא תהיה מושבתת, וכמה עבודה מותר לאבד. לא לכל המערכות אותם מספרים, וזו בדיוק הנקודה. מערכת הגבייה ומערכת ניהול הידע אינן צריכות לחזור באותו קצב.
- 3
מיפוי תלויות
כמעט כל תוכנית שנכשלת נכשלת כאן. מערכת שחוזרת ראשונה ותלויה בשירות אימות, ב-DNS או בשרת רישוי שעדיין למטה, לא באמת חזרה. ממפים לכל מערכת ליבה במה היא תלויה, וקובעים את סדר ההעלאה מהתלות כלפי מעלה.
- 4
בחירת אסטרטגיית התאוששות
רק עכשיו, כשהמספרים ידועים, בוחרים ארכיטקטורה: שחזור מגיבוי, סביבה שממתינה בצד, או סביבה שנייה פעילה. הסדר הזה חשוב, כי מי שבוחר ארכיטקטורה לפני שיש לו RTO בדרך כלל קונה יותר או פחות ממה שצריך.
- 5
כתיבת נהלים ובעלי תפקידים
מי מוסמך להכריז על אירוע, מי מבצע כל שלב, מי מחליף אותו כשאינו זמין, ואיך מודיעים ללקוחות ולעובדים. כאן גם נקבע איפה התוכנית עצמה שמורה, כך שתהיה נגישה גם כשהמערכות למטה.
- 6
תרגול ועדכון
מתרגלים לפחות פעם בשנה ומעדכנים בכל שינוי משמעותי. תרגיל שולחני הוא התחלה לגיטימית לחלוטין, והוא חושף את רוב הפערים לפני שנגעו במערכת אחת.
מה נכנס למסמך עצמו
הפרקים שבלעדיהם זה מסמך כוונות
- רשימת מערכות מדורגת לפי סדר החזרה, עם RTO ו-RPO מספריים לכל אחת
- מפת תלויות: מה חייב לעלות לפני מה
- הגדרה מפורשת מה נחשב אירוע, ומי מוסמך להכריז עליו
- בעלי תפקידים בשמות, עם מחליף לכל תפקיד
- פרטי קשר של הצוות, הספקים ונותני השירות, זמינים גם בלי הרשת הארגונית
- מאיפה מביאים את הגיבוי, ומי מחזיק את הגישה אליו
- נוסחי הודעה מוכנים מראש ללקוחות, לעובדים ולגורמים חיצוניים
- יומן תרגולים ותאריך העדכון האחרון
ה-RTO שבחרתם הוא המחיר שתשלמו
המסמך עצמו עולה זמן עבודה בלבד. מה שקובע את התקציב הוא היעד שהצבתם, וההפרש בין היעדים גדול בהרבה ממה שנהוג להניח.
- ניתוח השפעה עסקית
- RTO ו-RPO לכל מערכת
- הארכיטקטורה
- העלות
בסדר הזה ולא הפוך.
יממה
- מה זה דורש בפועל
- שחזור מגיבוי לתשתית שמוקצית בעת הצורך
- מתי זה מוצדק
- פעילות שיכולה לספוג יום עבודה אבוד
שעות בודדות
- מה זה דורש בפועל
- תשתית שממתינה בצד, עם נתונים שמסונכרנים בתדירות גבוהה
- מתי זה מוצדק
- מערכות ליבה שבלעדיהן העסק עומד
דקות
- מה זה דורש בפועל
- סביבה שנייה פעילה עם שכפול רציף
- מתי זה מוצדק
- פעילות שכל שעת השבתה בה עולה כסף ישיר או לקוחות
| יעד חזרה | מה זה דורש בפועל | מתי זה מוצדק |
|---|---|---|
| יממה | שחזור מגיבוי לתשתית שמוקצית בעת הצורך | פעילות שיכולה לספוג יום עבודה אבוד |
| שעות בודדות | תשתית שממתינה בצד, עם נתונים שמסונכרנים בתדירות גבוהה | מערכות ליבה שבלעדיהן העסק עומד |
| דקות | סביבה שנייה פעילה עם שכפול רציף | פעילות שכל שעת השבתה בה עולה כסף ישיר או לקוחות |
תוכנית שלא תורגלה היא הנחה
זו השורה שהכי כדאי לקחת מהמדריך הזה. תוכנית שנכתבה ונשמרה היא הערכה של מה שיקרה, ולא ידיעה. התרגול הוא מה שהופך אותה לידיעה, והוא כמעט תמיד מגלה שניים או שלושה דברים שאיש לא חשב עליהם.
- תרגיל שולחני
- יושבים סביב שולחן ועוברים על התרחיש שלב אחר שלב, בלי לגעת במערכות. זול, מהיר, ומגלה את רוב פערי האחריות והנהלים.
- שחזור מדגמי
- משחזרים מערכת אחת או קבוצת קבצים לסביבה מבודדת ומוודאים שהם נפתחים ותקינים. זו גם הדרך היחידה לדעת שהגיבוי באמת עובד.
- תרגיל מלא
- מפעילים את סביבת ההתאוששות ומריצים ממנה עבודה אמיתית. היקר והחושפני מכולם, ומקובל בעיקר בארגונים עם דרישות רגולטוריות.
הטעויות שחוזרות
מה לבדוק לפני שסוגרים את המסמך
- יעד חזרה אחיד לכל המערכות, שמנפח את העלות בלי צורך
- התוכנית מסתמכת על אדם אחד שיודע הכל, בלי מחליף
- תלויות שלא מופו, ולכן סדר ההעלאה לא באמת עובד
- גיבוי שמעולם לא שוחזר, ולכן איש אינו יודע אם הוא תקין
- התוכנית מעודכנת לארכיטקטורה שהוחלפה לפני שנתיים
- אין נוסח מוכן ללקוחות, ואת ההודעה מנסחים תחת לחץ
למי זה דחוף, ולמי פחות
מתאים ל
- עסקים שכל הפעילות שלהם עוברת דרך מערכת אחת מרכזית, כגון ERP או מערכת גבייה
- מי שמחזיק נתוני לקוחות שאובדנם הוא גם אירוע משפטי ולא רק תפעולי
- ארגונים בענפים מפוקחים שנדרשים להציג תוכנית
- עסקים שכבר חטפו השבתה ממושכת ויודעים מה זה עלה
פחות מתאים ל
- פעילות שיכולה להיעצר לכמה ימים בלי נזק ממשי
- מי שעדיין אין לו גיבוי מסודר ובדוק, שם זו המשימה הראשונה
- צוות של אדם או שניים בלי מערכות ליבה משלו
מי שנמצא בקטגוריה השנייה או השלישית אינו צריך תוכנית מלאה, אבל כן צריך גיבוי שנבדק. הנושא מפורק במדריך גיבוי שרת וירטואלי, ובפרט החלק שמסביר למה סנפשוט אינו גיבוי.
מה לשאול ספק שמציע פתרון DR
שאלות שכדאי לשאול ספק
- איזה RTO ו-RPO ההצעה הזאת נותנת בפועל, במספרים
- מי מפעיל את ההתאוששות, אתם או אנחנו, ובאיזה אופן מודיעים
- כמה זמן לוקח להעלות את הסביבה החלופית, ומתי נמדד הזמן הזה לאחרונה
- האם אפשר לתרגל, כמה פעמים בשנה זה כלול, ומה עולה תרגיל נוסף
- איפה יושבת הסביבה השנייה, ומה המרחק שלה מהראשונה
- מה קורה לחיובים בזמן שהסביבה החלופית פעילה
- מה בדיוק אינו מכוסה בהצעה הזאת
שורה תחתונה
תוכנית התאוששות מאסון אינה פריט שקונים אלא החלטה שמתעדים: מה חוזר ראשון, תוך כמה זמן, ומי עושה את זה. הבסיס נבנה מניתוח השפעה עסקית שממנו נגזרים RTO ו-RPO לכל מערכת בנפרד, ומשם נגזרות גם הארכיטקטורה וגם העלות, בסדר הזה ולא הפוך.
אם יש לכם היום גיבוי ואין מסמך, הצעד הראשון אינו רכישה אלא שעה אחת עם דף: לרשום את שלוש המערכות שבלעדיהן העסק עומד, לקבוע לכל אחת כמה השבתה היא סובלת, ולבדוק אם התשתית הקיימת עומדת בזה. אצלנו התשתית יושבת בדאטה סנטר בישראל, ואם מהתרגיל הזה יתברר שגיבוי מסודר מספיק לכם, זה מה שנגיד.
שאלות נפוצות
מסמך שמגדיר מראש איך הארגון חוזר לפעולה אחרי אירוע שמשבית את המערכות: אילו מערכות קמות ראשונות ובאיזה סדר, תוך כמה זמן כל אחת אמורה לחזור, מי מוסמך להכריז שמדובר באירוע, מי מבצע כל שלב, ואיך מודיעים ללקוחות ולעובדים. היא מבוססת על תשתית, אבל היא עצמה אינה תשתית. אפשר לרכוש שכפול מלא לאתר שני ועדיין לא לדעת מי מפעיל אותו בשלוש לפנות בוקר.
המשכיות עסקית (BCP) שואלת איך העסק ממשיך לתפקד בזמן האירוע: איפה העובדים יושבים, איך עונים ללקוחות, איך ממשיכים לגבות כסף. התאוששות מאסון (DRP) היא תת-קבוצה שלה שעוסקת ספציפית במערכות המחשוב: איך מחזירים את השרתים, הנתונים והאפליקציות. DRP הוא הפרק הטכני, ו-BCP הוא הספר כולו. עסקים קטנים בדרך כלל מתחילים מה-DRP, כי שם נמצא רוב הסיכון בפועל.
ארבעה דברים שבלעדיהם זה מסמך כוונות: רשימת מערכות מדורגת לפי סדר החזרה, RTO ו-RPO מספריים לכל מערכת, שמות ותפקידים של מי שמבצע כל שלב כולל מחליף, ופרטי קשר וגישה שזמינים גם כשהרשת הארגונית למטה. אם התוכנית שמורה רק בשרת הקבצים שנפל, היא לא קיימת.
לעסק קטן או בינוני עם מספר מצומצם של מערכות ליבה, הליבה של התוכנית נכתבת בדרך כלל תוך שבועות בודדים, ורוב הזמן הולך לניתוח ההשפעה העסקית ולא לכתיבה עצמה. הקושי אינו טכני אלא ארגוני: לקבל מכל בעל תפקיד תשובה מספרית לשאלה כמה זמן הוא יכול לעבוד בלי המערכת שלו, ואז להכריע בין תשובות סותרות. בארגונים גדולים או מפוקחים זה תהליך של חודשים.
תרגול לפחות פעם בשנה, ועדכון בכל שינוי משמעותי: מערכת חדשה, מעבר ספק, שינוי בכוח אדם או שינוי מבני בעסק. תרגול אינו חייב להיות הפלה מלאה של הסביבה. אפשר להתחיל בתרגיל שולחני שבו יושבים סביב שולחן ועוברים על התרחיש שלב אחר שלב, ורוב הפערים מתגלים כבר שם, לפני שנגעו במערכת אחת.
צריך תוכנית, לא בהכרח מסמך של ארבעים עמודים. שלושה עמודים שמפרטים אילו שתיים או שלוש מערכות מחזירים ראשונות, תוך כמה זמן, מי מבצע ומאיפה מביאים את הגיבוי, שווים יותר מכל מסמך תאורטי. המבחן פשוט: אם איש המחשוב היחיד שלכם בחוץ לארץ ואינו זמין, האם מישהו אחר יודע מה לעשות? אם התשובה שלילית, יש פער, וגודל העסק אינו מצדיק אותו.
המסמך עצמו עולה זמן עבודה. מה שעולה כסף הוא ה-RTO שהחלטתם עליו: חזרה תוך יממה נשענת בדרך כלל על שחזור מגיבוי ועלותה נמוכה, חזרה תוך שעות דורשת תשתית שממתינה בצד, וחזרה כמעט מיידית דורשת סביבה שנייה פעילה שמשכפלת בזמן אמת. בגלל זה קובעים את ה-RTO לפי הנזק העסקי בפועל ולא לפי תחושה, אחרת משלמים על דקות שאיש לא היה מרגיש בהן.
כן, התקן הבינלאומי הוא ISO 22301, והוא מגדיר מערכת ניהול להמשכיות עסקית. רוב העסקים אינם נדרשים להסמכה, אבל מבנה התקן שימושי גם בלעדיה כרשימת נושאים שלא כדאי לפספס. בענפים מפוקחים, כגון פיננסים, ביטוח ובריאות, חלות לעיתים דרישות ייעודיות משלהן, ושם צריך לבנות את התוכנית מול הדרישה הספציפית שחלה עליכם ולא מול מדריך כללי.
גיבוי הוא עותק של הנתונים. התוכנית היא ההוראות שמסבירות מה עושים איתו. עסק עם גיבוי ובלי תוכנית יגלה בדרך כלל שהנתונים אמנם קיימים, אבל איש אינו יודע לאיזה שרת משחזרים אותם, מי מחזיק את הסיסמאות, ובאיזה סדר צריך להעלות את המערכות כדי שהן בכלל ידברו זו עם זו. זה ההבדל בין להחזיק נתונים לבין לחזור לעבוד.