RPO מתאר את חלון אובדן הנתונים שאתם מוכנים לקבל; RTO מתאר את ההפרעה שאתם שואפים לשמור בתוכו. הגדירו את שניהם עבור פונקציה עסקית שימושית, ואז הוכיחו את רצף השחזור בתרגיל. לוח זמני גיבוי או מפרט שרת בלבד אינם קובעים אף אחד מהיעדים.
התחילו בשירות שאנשים יכולים להשתמש בו
יעדי שחזור הופכים שימושיים כשהם מתארים פונקציה עסקית ולא מכונה מבודדת. שרת יכול לעלות בעוד לקוחות עדיין אינם יכולים להיכנס, לאחזר קבצים או להשלים בקשה. כתבו את תנאי הסיום בשפה רגילה: משתמשים מורשים יכולים לגשת ליישום והנתונים הנדרשים עקביים. זה הופך את היעד לניתן לבדיקה על ידי מישהו מחוץ לצוות התשתית.
שאלו את בעל היישום מה הפרעה תמנע ומה יעלה מידע חסר. לפרסום שבועי וליישום לעיבוד עסקאות עשויות להיות תשובות שונות. התייחסו ליעדים הנובעים מכך כיעדי תכנון, לא כהבטחות שהומצאו מקטלוג החומרה. תעדו מי אישר אותם ואילו תרחישי כשל התוכנית מכסה.
הפרידו בין שני השעונים
RPO נוגע לכמה אחורה הנתונים המשוחזרים יכולים להיות ביחס להפרעה. RTO נוגע לכמה זמן הפונקציה יכולה להישאר לא זמינה. גיבוי עדכני יכול לשפר את חלון אובדן הנתונים בעוד שחזור איטי עדיין מחמיץ את יעד זמן השחזור. לעומת זאת, אתחול מהיר יכול להחזיר גישה ליישום שהנתונים החדשים ביותר שלו לא שרדו.
פרטו את נקודות הייחוס. החליטו מתי מתחיל שעון התקרית, מה נחשב לפעולה משוחזרת וכיצד תזוהה נקודת הנתונים השמישה. שמרו על היעדים נפרדים מתוצאות מדודות: יעד הוא מה שאתם שואפים אליו; תרגיל מראה מה התהליך הנוכחי השיג. חזרו על כל אחד מהם כשהאפליקציה או מערך הנתונים משתנים.
תקצבו כל שלב בשחזור
תקציב RTO מעשי כולל זיהוי, הערכה, אישור, גישה לסביבת השחזור, שחזור, אימות יישום ופתיחה מחדש. זמן העתקת הקבצים הוא רק רכיב אחד. אם האדם המחזיק במפתח השחזור אינו זמין, גיבוי מהיר תיאורטית עדיין יכול להיות בלתי שמיש. פרטו את התלויות והבטיחו שצוות השחזור יכול להגיע אליהן במהלך הכשל הנשקל.
הקצו זמן זמני לכל שלב, ואז החליפו הערכות בתצפיות. בתקציב להמחשה של שעתיים זה, השחזור מקבל את ההקצאה הגדולה ביותר אך לאימות עדיין יש זמן מוגן. המספרים מתארים דוגמת תכנון, לא אספקת שירות SwissOctet. אם לסך אין מרווח, העיצוב זקוק לשיפור לפני שהיעד אמין.
| שלב שחזור | הקצאה להמחשה | ראיות לאיסוף |
|---|---|---|
| זיהוי והערכה | 15 דקות | הגעת התראה והחלטת תקרית |
| הכנת סביבת שחזור | 20 דקות | גישה ותצורה זמינות |
| שחזור נתונים ושירות | 50 דקות | שחזור שהושלם עם נתונים עקביים |
| אימות ופתיחה מחדש | 25 דקות | מסלול המשתמש מצליח |
| מרווח מגירה | 10 דקות | עבודה בלתי צפויה תועדה |
בדקו את חלון אובדן הנתונים האמיתי
משימה המתוזמנת מדי שעה אינה מספקת אוטומטית RPO של שעה. משימה שנכשלה, העלאה מעוכבת או עותק בלתי שמיש יכולים להפוך את נקודת השחזור העדכנית לישנה בהרבה. צפו בהשלמה מוצלחת ובמצב שאכן ניתן לשחזר. עבור יישום עם כמה מאגרי נתונים, אשרו שנקודות השחזור שלהם תואמות במקום לקרוא כל חתימת זמן בנפרד.
בחרו אירוע ייחוס במהלך תרגיל, כגון רשומת בדיקה מורשית שנוצרה בזמן ידוע. לאחר השחזור, זהו את הרשומה התקפה החדשה ביותר ומדדו את הפער. השתמשו בנתוני בדיקה לא מזיקים. זה נותן תוצאה מעשית וחושף הנחות שלוח בקרה המראה רק הצלחת משימה עשוי להשאיר מוסתרות.
בחרו אסטרטגיה בתוך התקציב
גיבוי ושחזור, סביבות standby מוכנות ועיצובי יישום משוכפלים מחליפים עלות ומורכבות במהירות שחזור. שכפול יכול להפחית עיכובים מסוימים אך עשוי גם לשחזר מחיקה בשוגג או טעות יישום. standby שסטה מהתצורה העובדת יוצר סיכון משל עצמו. בחרו אסטרטגיה לפי תרחישי הכשל והיעדים שתיעדתם.
שקלו שירות קטן עם יעד של ארבע שעות ומערך נתונים גדול יותר ששחזורו לבדו אורך שש שעות בתרגיל. קניית יציאת רשת מהירה יותר היא רק השערה: קריאות אחסון, כתיבות קולטות ושחזור יישום עשויים לשלוט. שפרו את השלב המגביל הנמדד, הפחיתו את מערך השחזור או שנו את האסטרטגיה, ואז התאמנו שוב.
התאמנו בלי לסכן את סביבת הייצור
השתמשו בסביבת שחזור מבודדת ובחלון תרגיל מוגדר. ודאו שמשימות משוחזרות אינן יכולות לשלוח התראות אמיתיות, לקבל תשלומים ציבוריים או לכתוב לאינטגרציות ייצור. בדקו גישה, שלמות נתונים ומסלולי משתמש מייצגים לפני שאתם מחשיבים את התרגיל להשלמה. כללו אדם שלא כתב את ההליך המקורי כדי לחשוף הוראות חסרות.
שמרו ציר זמן של התרגיל, נקודת השחזור שהושגה וכל הפרעה שנגרמה ממידע לא זמין. דוח שימושי מציין את התוצאה הנמדדת, את הפער ליעד ופעולה מתקנת ספציפית. חזרו על כך לאחר שינויים משמעותיים ובמרווח המתאים לחשיבות הפרויקט.
שמרו על התוכנית שמישה במהלך תקלה
אחסנו את הליך השחזור במקום שהצוות יכול לגשת אליו בלי להסתמך רק על היישום שנכשל. שמרו אישורים ומפתחות הצפנה במקום מוגן עם תהליך גישה נבדק. עדכנו אנשי קשר, גדלי מערכי נתונים ותלויות ככל שהפרויקט מתפתח. תוכנית מיושנת יכולה לצרוך את מרווח הזמן עוד לפני שהשחזור מתחיל.
בעת השוואת תצורות SwissOctet, הפרידו בין ארכיטקטורת השחזור שלכם לבין אפשרויות הגיבוי האופציונליות של הקטלוג. אשרו מה אפשרות מכסה, היכן מוחזקים נתוני השחזור ומי מבצע את השחזור. הקטלוג אינו קובע RPO או RTO של יישום. התהליך הנמדד שלכם ותנאי השירות בפועל מספקים את הבסיס להחלטה זו.
רשימת הבדיקה המעשית שלך.
- הגדירו את הפונקציה העסקית המשוחזרת.
- אשרו יעדי RPO ו-RTO נפרדים.
- תקצבו זיהוי, גישה, שחזור ואימות.
- מדדו את נקודת הנתונים השמישה העדכנית.
- התאמנו בסביבה מבודדת.
- תעדו פערים וחזרו על כך לאחר שינויים רלוונטיים.
הפרטים שחשובים.
האם RTO זהה לזמן פעילות?+
לא. RTO הוא יעד שחזור לתרחיש הפרעה. זמן פעילות מודד זמינות לאורך תקופה; אחד אינו קובע את האחר.
האם גיבוי מדי שעה מבטיח RPO של שעה?+
לא. בדקו עותקים שהושלמו ושמישים ואת דרישות העקביות של היישום. משימות שנכשלו והעברות מעוכבות יכולות להרחיב את פער הנתונים הניתנים לשחזור.
האם כל פרויקט חייב להשתמש בשרת standby?+
בחרו אסטרטגיה לפי יעדי השחזור של הפרויקט ותהליך השחזור הנמדד. standby מוסיף עלות ומורכבות תפעולית ואינו הכרחי אוטומטית.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- NIST SP 800-34 Rev. 1: מדריך תכנון מגירה nvlpubs.nist.gov
- AWS Well-Architected: הגדירו יעדי שחזור docs.aws.amazon.com
- Microsoft Learn: המשכיות עסקית, זמינות גבוהה ושחזור מאסון learn.microsoft.com
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.