תכנון המשכיות עסקית נכשל לרוב לא במהלך משבר, אלא במהלך ההערכה שקדמה לו. ארגונים מבצעים ניתוחי השפעה עסקית, מתעדים יעדי זמן התאוששות, בונים ספרי הכנה מקיפים לשחזור, ואז מגלים, ברגע הגרוע ביותר, ששירות אימות מדור קודם שנראה לא קריטי הוא נקודת כשל יחידה עבור כל פלטפורמת המסחר האלקטרוני שלהם, שתוכנית האצווה COBOL שכולם הניחו שהיא בעלת עדיפות נמוכה מזינה את שירות אימות התשלומים בזמן אמת, או ששתי אפליקציות המוקציות לאותה רמת התאוששות כוללות תלות לא מתועדת שהופכת התאוששות רציפה לבלתי אפשרית. הניקוד בוצע. התלות לא.
ניקוד קריטיות יישומים הוא תהליך של הקצאת מדד חשיבות כמותי או מדורג לכל יישום בתיק העבודות של הארגון, מדד הקובע את עדיפות ההתאוששות שלו, את רמת ההשקעה ביתירות שלו, את דרישות בקרת השינויים שלו ואת מקומו ברצף ההתאוששות מאסון. כאשר ניקוד זה מבוסס על סקרי השפעה עסקית וראיונות עם בעלי יישומים בלבד, הוא משקף את מה שאנשים מאמינים שהיישומים עושים. כאשר הוא מבוסס על ניתוח מבני של מה שהיישומים עושים בפועל, מי מתקשר למי, אילו נתונים זורמים דרך אילו תוכניות, אילו רכיבים משותפים נמצאים בנתיב הקריטי של מערכות מרובות בעלות עדיפות גבוהה יותר, הוא משקף את המציאות התפעולית.
הפער בין אמונה למציאות הוא המקום שבו תוכניות להמשכיות עסקית נכשלות.
רצפי שחזור המשקפים תלות בפועל
SMART TS XL מזהה כל תוכנית בנתיב הקריטי של יישומי Tier 1 שלך - בכל שפה בתיק העבודות שלך.
גלו עוד…מה ניקוד קריטיות האפליקציה מודד בפועל
קריטיות אינה ממד יחיד. על מנת לקבוע את ציון הקריטיות של יישום ארגוני, ניתן לקחת בחשבון קלט מהמשתמש כדי להעריך את הקריטיות או החשיבות של יישום ארגוני, כולל ההשפעה הגדולה ביותר על צרכי עסק אסטרטגיים, השפעות על שותפים עסקיים, אינטראקציות עם לקוחות והשפעות על יישומי ארגון אחרים. כל אחד מהממדים הללו לוכד היבט שונה של מה המשמעות של "קריטי":
השפעה עסקית , מה שהארגון מפסיד לכל שעת השבתה. אובדן הכנסות הוא הממד הבולט ביותר: מערכת עיבוד תשלומים המטפלת ב-10 מיליון דולר לשעה כולה בעלת עלות ניתנת לכימות לכל דקת הפסקה. אך ההשפעה העסקית משתרעת מעבר להכנסות וחשיפה רגולטורית (אילו התחייבויות ציות מפעילה ההפסקה?), נזק תדמיתי (האם הלקוחות מושפעים ישירות?) וקנסות חוזיים (האם הסכמי רמת שירות מפעילים סעיפי קנס?).
תלות תפעולית , כמה מערכות או תהליכים אחרים תלויים ביישום זה. יישום בעל השפעה עסקית ישירה נמוכה עשוי להיות בעל קריטיות גבוהה מכיוון שהוא נמצא בנתיב התלות של יישומים בעלי השפעה ישירה גבוהה. שירות האימות המאפשר כל יישום אחר הפונה ללקוח הוא קריטי יותר ממה שמרמז הפונקציה שלו עצמו.
מורכבות השחזור , כמה קשה וגוזלת זמן שחזור היישום. יישום בעל השפעה עסקית בינונית וזמן שחזור של 48 שעות עשוי לדרוש השקעה גבוהה יותר ביתירות מאשר יישום בעל השפעה עסקית גבוהה יותר וזמן שחזור של שעתיים, מכיוון שסיכון ההשבתה הכולל גדול יותר.
חובה רגולטורית , אילו יישומים כפופים לדרישות המשכיות רגולטוריות. מוסדות פיננסיים הכפופים לחוק DORA חייבים להוכיח שפונקציות קריטיות או חשובות יכולות לעמוד בתרחישי שיבוש מוגדרים. ארגוני בריאות הכפופים לחוק HIPAA חייבים להגן על זמינותן של מערכות המכילות מידע בריאותי מוגן. המימד הרגולטורי עשוי לגבור על ניקוד ההשפעה העסקית עבור יישומים ספציפיים.
ציון הקריטיות הוא שילוב של כל ארבעת הממדים, המשוקללים לפי סבילות הסיכון הספציפית של הארגון, הסביבה הרגולטורית ומודל העסקי.
רמות הקריטיות הסטנדרטיות
רוב תיקי היישומים הארגוניים משתמשים במודל קריטיות בן ארבע רמות. קטגוריות של קריטיות במטריצת קריטיות יישומים הן קריטיות למשימה, קריטיות לעסקים, תפעוליות עסקיות ומנהליות. ההגדרות שלהלן משקפות את הנוהג הנוכחי בתעשייה בהתאם לתקן ISO 22301 (מערכות ניהול המשכיות עסקית) ולהנחיות לנהלים הטובים של מכון המשכיות עסקית:
Tier 1, יישומים קריטיים למשימה שכשלון שלהם עוצר באופן מיידי את פעילות העסקים המרכזית או יוצר סיכון רגולטורי או בטיחותי בלתי מתקבל על הדעת. יעד זמן התאוששות (RTO): בדרך כלל 0-4 שעות. יעד נקודת התאוששות (RPO): בדרך כלל 0-1 שעה. דוגמאות: עיבוד עסקאות בנקאיות מרכזיות, מערכות מסחר בזמן אמת, מערכות שיגור חירום, ממשקי בקרה תעשייתיים, מערכות אישור תשלומים. יישומים אלה מצדיקים את ההשקעה הגבוהה ביותר בתשתית: יתירות אקטיבית-אקטיבית, שכפול ללא RPO, מעבר לגיבוי אוטומטי לגיבוי ובקרת שינויים קפדנית ביותר.
דרגה 2, יישומים עסקיים קריטיים שכשלון שלהם פוגע באופן משמעותי בפעילות העסקית אך אינו עוצר אותה באופן מיידי. יעד זמן התאוששות: בדרך כלל 4-24 שעות. יעד נקודת התאוששות: בדרך כלל 1-4 שעות. דוגמאות: מערכות CRM, מודולי ERP, ניהול הזמנות, מערכות משאבי אנוש במהלך תקופות שכר, מערכות דיווח במהלך חלונות הגשת הגשות רגולטוריות. יישומים אלה מצדיקים תשתית בעלת זמינות גבוהה, בדיקות קבועות לגיבוי בעת כשל, וסידור התאוששות בעדיפות עליונה.
דרגה 3, יישומים עסקיים תפעוליים התומכים בפעילות עסקית אך ניתן לנהל את חוסר הזמינות הזמני שלהם באמצעות פתרונות ידניים. יעד זמן שחזור: בדרך כלל 24-72 שעות. יעד נקודת שחזור: בדרך כלל 4-24 שעות. דוגמאות: כלי שיתוף פעולה פנימיים, דיווח שאינו פונה ללקוח, פורטלים אדמיניסטרטיביים, פלטפורמות הדרכה. נהלי גיבוי ושחזור סטנדרטיים מתאימים.
דרגה 4, יישומים אדמיניסטרטיביים התומכים בפונקציות אדמיניסטרטיביות ללא השפעה תפעולית ישירה. יעד זמן שחזור: בדרך כלל 72+ שעות. יעד נקודת שחזור: 24+ שעות או הגיבוי האחרון. דוגמאות: ויקי של תיעוד פנימי, כלי פיתוח לא חיוניים, דיווח היסטורי. שחזור מגיבוי על בסיס אופורטוניסטי.
הקצאת השכבות אינה קבועה. יישום שנמצא בשכבה 3 ברוב השנה עשוי להפוך לשכבה 2 במהלך סגירת סוף חודש, תקופות דיווח רגולטוריות או עונות שיא של מסחר. קריטיות דינמית, שבה הקצאת השכבות משתנה בהתאם ללוח השנה התפעולי, היא חידוד שארגונים עם תוכניות BCP בוגרות מיישמים לאחר קביעת מבנה השכבות הבסיסי.
מתודולוגיית הניקוד: תרגום ממדים למספרים
מתודולוגיית ניקוד מובנית ממירה את ארבעת ממדי הקריטיות לציון מספרי שמניע את הקצאת הרמות באופן אובייקטיבי ולא על ידי פוליטיקה ארגונית. הגישה שלהלן מייצרת ציון מורכב של 0-100 באמצעות קריטריונים משוקללים:
ממד 1: השפעה עסקית (משקל: 35%)
| השפעת הכנסות לכל שעת השבתה | ציון |
|---|---|
| מעל מיליון דולר לשעה | 35 |
| 100 אלף דולר עד מיליון דולר לשעה | 28 |
| 10-100 דולר לשעה | 21 |
| 1-10 דולר לשעה | 14 |
| פחות מ-1 דולר לשעה | 7 |
| אין השפעה ישירה על ההכנסות | 0 |
השפעה רגולטורית (חובות תאימות ל-DORA, HIPAA, PCI-DSS, SOX כתוצאה מהפסקת חשמל) מוסיפה עד 10 נקודות נוספות לממד זה.
ממד 2: תלות תפעולית (משקל: 30%)
| Fan-In: יישומים התלויים ביישום זה | ציון |
|---|---|
| > 20 יישומים תלויים | 30 |
| 10-20 יישומים תלויים | 24 |
| 5-9 יישומים תלויים | 18 |
| 2-4 יישומים תלויים | 12 |
| יישום תלוי אחד | 6 |
| ללא תלויים (עצמאי) | 0 |
ספירת התלות המבנית כאן היא ספירת התלות המבנית, מספר היישומים שקוראים ליישום זה, קוראים את הפלט שלו, או תלויים בנתונים שלו, לא מספר המשתמשים או החשיבות הנתפסת. ממד זה הוא זה שמחושב בצורה שגויה בתדירות הגבוהה ביותר בסקרים מכיוון שבעלי יישומים אינם מכירים את כל צרכני ה-downstream שלהם.
מימד 3: מורכבות התאוששות (משקל: 20%)
| זמן התאוששות משוער ללא DR מובנה מראש | ציון |
|---|---|
| > 72 שעות | 20 |
| שעות 24-72 | 16 |
| שעות 8-24 | 12 |
| שעות 2-8 | 8 |
| <2 שעות | 4 |
| גיבוי אוטומטי < 15 דקות | 0 |
ממד 4: רגישות נתונים וחובות רגולטוריות (משקל: 15%)
| סיווג נתונים ודרישות רגולטוריות | ציון |
|---|---|
| מידע אישי / מידע חירום / מידע רפואי מוסדר עם התחייבות מפורשת לזמן התאוששות | 15 |
| נתונים מוסדרים ללא התחייבות ספציפית לזמן שחזור | 12 |
| נתונים פנימיים רגישים (סודות מסחריים, רישומים פיננסיים) | 9 |
| נתונים תפעוליים פנימיים | 6 |
| נתונים פנימיים לא רגישים | 3 |
| אין נתונים מאוחסנים | 0 |
מיפוי ציון מורכב לרמה:
| ציון מורכב | הקצאת שכבות |
|---|---|
| 75-100 | דרגה 1, קריטי למשימה |
| 50-74 | רמה 2, עסקי קריטי |
| 25-49 | רמה 3, תפעול עסקי |
| 0-24 | דרג 4, אדמיניסטרטיבי |
בעיית התלות: מדוע ניקוד מבוסס סקרים טועה
ממד התלות התפעולית הוא זה שסביר להניח שיחושב בצורה שגויה, והוא זה בעל ההשלכות הגדולות ביותר כאשר הוא שגוי. שירות אימות מדור קודם שנראה לא קריטי יכול להיות נקודת כשל יחידה עבור פלטפורמת מסחר אלקטרוני שלמה, וכישלונו עלול לעצור את כל העסקאות המייצרות הכנסות. תהליך זה מתקדם מעבר לאיומים מופשטים להשפעות קונקרטיות ומדידות על הסכמי רמת שירות.
בעלי יישומים מכירים את התלויות הישירות שלהם במעלה הזרם, את המערכות שהם קוראים להן. הם כמעט ולא מכירים את התלויות המלאות שלהם במעלה הזרם, את המערכות שקוראות להן. שירות אימות משתמשים פנימי עשוי להיחשב כבעל חשיבות נמוכה על ידי בעליו (הוא אינו מייצר הכנסות, הוא פשוט, הוא כמעט ולא נכשל) בעוד שהוא תלוי בו שנים עשר יישומים הפונים ללקוחות, כולם ברמה 1. חשיבותה האמיתית של שירות האימות היא ברמה 1, לא בגלל הפונקציה שלו עצמו אלא בגלל מיקומו בגרף התלות של מערכות ברמה גבוהה יותר.
ניקוד קריטיות מבוסס סקר מייצר שגיאה זו באופן שיטתי. סקר של בעלי אפליקציות שואל: "כמה קריטי יישום זה?" בעל שירות האימות עונה "נמוך עד בינוני" בהתבסס על הפונקציה של השירות עצמו. שנים עשר בעלי האפליקציות התלויות אינן עונות על סקר זה בנוגע לשירות האימות, הן עונות על האפליקציות שלהן. קשר התלות לעולם אינו נקלט.
התוצאה מופיעה בריצוף השחזור: נקודת הגישה (BCP) מגדירה סדר שחזור בהתבסס על ציוני הקריטיות הנגזרים מהסקר, ושירות האימות מתוכנן לשחזור ברמה 3. במהלך אירוע בפועל, יישומי ברמה 1 שאמורים להתאושש ראשונים אינם יכולים להתאושש מכיוון ששירות האימות עליו הם תלויים לא שוחזר. רצף השחזור נכשל בנקודת התלות הקריטית ביותר שלו.
שלושה סוגי תלות שסקרים מפספסים באופן עקבי:
רכיבים משותפים נסתרים. תוכנית COBOL פנימית המטפלת בהמרת מטבע עבור שלושה תהליכים עסקיים נפרדים, שאף אחד מהם לא זיהה בסקר כרכיב משותף, היא תלות נסתרת המשפיעה על שחזור שלושתם. אם תוכנית המרת המטבע היא Tier 3 ואחד משלושת התהליכים העסקיים הוא Tier 1, הקריטיות האפקטיבית של תוכנית המרת המטבע היא Tier 1.
תלות בצינור נתונים. יישומים הצורכים נתונים מעובדים באצווה מיישומים אחרים, בעלי תלות זמנית ולא בזמן אמת. הסיכון אינו כשל סימולטני אלא רציף: האפליקציה במורד הזרם מתאוששת, אך מקור הנתונים שלה לא שוחזר לאותה נקודת שחזור, מה שיוצר מראה של פעולה תקינה על נתונים ישנים. סוג תלות זה אינו מופיע במפות טופולוגיית רשת או בניתוח גרף קריאות אלא אם כן זרימת הנתונים עצמה מעקבת.
תלויות משותפות של תצורה וסכימה. יישומים שחולקים סכימות מסד נתונים, שירותי תצורה או ספקי זהויות, משפיעים באופן מרומז גם אם הם לעולם לא קוראים זה לזה ישירות. שינוי סכימה במסד נתונים משותף עשוי להשפיע על מספר יישומים. שחזור יישום אחד לאחר פגיעה בסכימה מבלי לשחזר את כל היישומים שחולקים את הסכימה מייצר מצב לא עקבי בכל תיק היישומים.
שילוב BCP: כיצד ציוני קריטיות מניעים החלטות התאוששות
ציון הקריטיות הוא הקלט לשש החלטות ספציפיות לתכנון BCP:
1. הגדרת רצף שחזור. יישומים מתאוששים לפי סדר קריטיות, שכבה 1 לפני שכבה 2 לפני שכבה 3, אך בתוך שכבה, גרף התלות קובע את הרצף. יישומים ללא תלויות נכנסות (אף יישום אחר אינו תלוי בהן) יכולים להתאושש בכל סדר בתוך השכבה שלהן. יישומים עם fan-in גבוה חייבים להתאושש לפני התלויים בהן, ללא קשר לציונים היחסיים שלהם בתוך השכבה. לכן, רצף השחזור הוא: סידור שכבות מוחל על תת-הרצף המוגבל על ידי תלות בתוך כל שכבה.
2. קביעת יעדי RTO ו-RPO. ציון הקריטיות מכייל את יעדי ה-RTO וה-RPO. זמן ההשבתה המרבי הנסבל (MTD) ונקודת ההתאוששות (RPO) עבור כל יישום ייצור מהווים את הבסיס הטכני של אסטרטגיית ההמשכיות כולה. MTD הוא הזמן המרבי שהעסק יכול לסבול יישום לא זמין. RTO חייב להיות קטן מ-MTD. המרווח בין RTO ל-MTD הוא חיץ הבטיחות. יישומי Tier 1 בעלי השפעה עסקית גבוהה לכל שעת השבתה הם בעלי מרווחי MTD/RTO צרים ודורשים תשתית שתוכננה להתאוששות אוטומטית מהירה.
3. כיול השקעות בתשתיות. ציוני קריטיות מניעים ישירות החלטות השקעה בתשתיות DR. יישומי Tier 1 מצדיקים גיבוי רב-אזורי פעיל-פעיל. יישומי Tier 2 מצדיקים גיבוי פעיל-פסיבי עם גיבוי נבדק. יישומי Tier 3 מצדיקים גיבוי קבוע עם נהלי שחזור מתועדים. יישומי Tier 4 יכולים להסתמך על מדיניות גיבוי סטנדרטית. ללא ציוני קריטיות, החלטות השקעה בתשתיות נובעות כברירת מחדל מהשקעה יתר אחידה (יקרה) או השקעה חסר אחידה (מסוכנת).
4. דרישות בקרת שינויים. יישומים בעלי ציוני קריטיות גבוהים יותר דורשים בקרת שינויים קפדנית יותר: חלונות הקפאת שינויים ארוכים יותר, יותר מאשרים חובה, בדיקות מקיפות יותר לפני שינוי, הליכי החזרה למצב קודם שמרניים יותר. החלת בקרת שינויים Tier 1 על יישומי Tier 4 מבזבזת זמן הנדסי. החלת בקרת שינויים Tier 4 על יישומי Tier 1 יוצרת סיכון בלתי מתקבל על הדעת.
5. תדירות בדיקות ואימות. BCP דורש בדיקות תקופתיות של נהלי התאוששות, תרגילי שולחן, בדיקות גיבוי ברמת הרכיב וסימולציות התאוששות מאסון מלאות. ציוני קריטיות קובעים את תדירות הבדיקות: יישומי Tier 1 מצדיקים בדיקות DR רבעוניות; יישומי Tier 4 מצדיקים בדיקות שנתיות. בדיקת כל יישום באותה תדירות אינה מעשית ואינה הכרחית.
6. דרישות SLA של ספק. עבור יישומים התלויים בשירותי צד שלישי, ציון הקריטיות קובע את דרישות ה-SLA שחייבות להיכלל בחוזי הספק. יישום Tier 1 עם RTO של 4 שעות דורש SLA של צד שלישי המבטיח זמינות בהתאם ל-RTO הזה. יישום Tier 4 לא דורש זאת.
סיבוך מערכת Legacy
מערכות מדור קודם מסבכות את ניקוד הקריטיות בדרכים שמסגרות ניהול תיקי יישומים מודרניות אינן מטפלות בהן כראוי. הערכת הקריטיות הסטנדרטית מניחה שבעלי יישומים יודעים מה היישומים שלהם עושים ומי תלוי בהם. עבור מערכות מדור קודם, תוכניות COBOL שתחזוקה על ידי דורות מרובים של מפתחים, זרמי משימות JCL שתלויותיהם תועדו לאחרונה בשנת 2008, ותוכנות RPG המייצרות קבצי פלט הנצרכים על ידי תהליכים שאף אחד שעובד כרגע בארגון לא כתב, הנחה זו אינה מתקיימת.
מבנה התלות בפועל של מערכת מדור קודם גלוי רק בקוד עצמו. תוכנית COBOL שכותבת למערך נתונים ש-12 תוכניות במורד הזרם קוראות, כוללת 12 תלויות במורד הזרם, אך עובדה זו עשויה לא להיות ידועה לבעל תוכנית COBOL, שרואה רק את פונקציית התוכנית (עיבוד עסקאות יומיות) ולא את תפקידה המבני (יצירת מערך הנתונים המאפשר 12 תהליכים אחרים).
עבור מערכות מדור קודם, ממד התלות של ניקוד קריטיות דורש ניתוח קוד ולא סקרי בעלים. ניתן לגזור את ספירת ה-fan-in עבור תוכנית COBOL רק על ידי בחינת כל תוכנית אחרת בסביבה וקביעת אילו מהן מתייחסות למערכי נתוני הפלט של התוכנית הראשונה, מוסכמות קריאה או ספרי עותקים משותפים. ניתוח זה הוא מה שפלטפורמות ניתוח קוד מבני מספקות, ובלעדיו, ממד התלות של כל ציון קריטיות המוקצה לתוכנית מדור קודם הוא במקרה הטוב ניחוש מושכל.
התוצאה של הערכה שגויה של קריטיות יישומים מדור קודם היא חמורה במיוחד משום שמערכות מדור קודם נוטות להיות גם קריטיות ביותר (לעתים קרובות הן מכילות היגיון עסקי מרכזי שהצטבר במשך עשרות שנים) וגם בעלות ציון נמוך (בעליהן אינם יכולים לבטא מה תלוי בהן, ולכן הם נותנים ציונים שמרניים). התוצאה היא תוכניות מדור קודם שמוקצות להן Tier 3, אך למעשה נמצאות בנתיב הקריטי של תהליכים עסקיים Tier 1, אותו מצב כשל בדיוק שמופיע בכשלים ברצף התאוששות במהלך אירועים ממשיים.
איך SMART TS XL מספק את ראיות התלות לניקוד קריטיות
SMART TS XL מתייחס ישירות למימד התלות של ניקוד קריטיות היישומים, עבור קבוצת היישומים שבהם גישות מבוססות סקר הן הכי פחות אמינות.
יכולת מיפוי התלות של היישומים בונה את גרף התלות המלא בכל שפה בסביבה: כל תוכנית COBOL שקוראת לשפה אחרת, כל שלב בעבודה של JCL שמייצר נתונים הנצרכים על ידי תוכניות במורד הזרם, כל ספר עותקים משותף שיוצר תלות מרומזת בין תוכניות שלעולם לא קוראות זו לזו ישירות, כל מערך נתונים הזורם בין תוכניות יצרן לתוכניות צרכניות. גרף זה הוא בסיס הראיות המבני לממד התלות של ניקוד קריטיות, ספירות המאפיין, זיהוי הרכיבים המשותפים ותלות צינור הנתונים הנסתרות שסקרים אינם יכולים ללכוד באופן מהימן.
יכולת ניתוח ההשפעה הופכת את גרף התלות לניתן לשאילתה עבור תכנון BCP: עבור כל יישום בתיק העבודות, יש למנות כל יישום אחר שתלוי בו, באופן ישיר או טרנזיטיבי, ולכן יורש את דרישת הזמינות שלו. תוכנית COBOL עם שלושה תלויים ישירים ועשרים תלויים טרנזיטיביים (תוכניות שתלויות בתלויים הישירים) בעלת קריטיות אפקטיבית המשקפת את עשרים ושלוש התוכניות שהיא נמצאת בנתיב הקריטי שלהן, ולא רק את הפונקציה שלה.
יכולת ניתוח הקוד הסטטי חושפת את מדדי המורכבות המבנית המעידים על ממד מורכבות השחזור: מורכבות ציקלומטית, מדדי צימוד, אחוז קוד מת ומדדי חוב טכני שחוזים כמה זמן וכמה מסוכן יהיה השחזור של כל יישום. יישום עם מורכבות גבוהה וצימוד צפוף יקר יותר לשחזור, ציון מורכבות השחזור שלו בממד 3 גבוה יותר, מאשר יישום בעל פונקציה מקבילה עם ארכיטקטורה נקייה.
יכולת החיפוש הארגוני הופכת את מלאי התלות המלא לניתן לשאילתה לאורך מחזור החיים של BCP: מצא כל תוכנית שניגשת למערך נתונים ספציפי (זיהוי כל התוכניות התלויות בזמינותו), כל תוכנית שחולקת ספר עותקים ספציפי (זיהוי כל התוכניות המושפעות מזמינותו), כל משימת JCL הפועלת בחלון אצווה ספציפי (זיהוי כל התוכניות שחייבות להתאושש לפני תחילת החלון). יכולת חיפוש זו תומכת בסקירת ציון הקריטיות השנתית, תהליך העדכון ששומר על הציונים מעודכנים ככל שתיק היישומים מתפתח.
עבור ארגונים המבצעים מודרניזציה מורשת תוכניות לצד פיתוח BCP, SMART TS XLהניתוח של משרת את שתי המטרות בו זמנית: מפת התלות שמעודדת את ניקוד הקריטיות קובעת גם את רצף ההגירה, ומדדי המורכבות שמעודדים את ניקוד מורכבות ההתאוששות קובעים גם הם את אומדן מאמצי המודרניזציה.
שמירה על ציונים עדכניים: מחזור הסקירה השנתי
הערכת בגרות של המשכיות עסקית אמורה לעזור לכם לעשות שלושה דברים: להבין את המצב הנוכחי שלכם, לזהות את הפערים החשובים ביותר ולבנות נתיב ריאלי לשיפור. זה מה שהופך את ציון הבגרות לתוכנית טובה יותר.
ציוני קריטיות היישומים חורגים מהמציאות ככל שארגונים משתנים. יישומים חדשים מתווספים. יישומים ישנים יוצאים משימוש אך לא מושבתים לחלוטין. אינטגרציות נבנות בין יישומים שלא הייתה להם תלות בעבר. תהליכים עסקיים משתנים ועמם היישומים עליהם הם מסתמכים. דרישות רגולטוריות מתפתחות ומטילות חובות שחזור חדשות.
מחזור הבדיקה השנתי של ציוני קריטיות צריך לכלול:
ניתוח מבני מחדש. הפעל מחדש את מיפוי התלות כדי לזהות תלויות חדשות שהוצגו מאז הסקירה האחרונה. יישומים שהיו עצמאיים עשויים כעת להיות בעלי תלויות שמגבירות את קריטיותם. יישומים שהיו תלויים בהם במידה רבה עשויים לגרום לצרכנים שלהם לעבור למערכות חדשות יותר, מה שהפחית את קריטיותם.
הערכה מחודשת של ההשפעה העסקית. נתוני ההכנסות וההשפעה התפעולית משתנים ככל שהעסק גדל ומתפתח תיק היישומים שלו. יישום שטיפלה בערך עסקי של 1 דולר לשעה לפני שלוש שנים עשוי להתמודד כעת עם פי עשרה מזה לאחר צמיחת העסק.
שילוב תוצאות מבחן ההתאוששות. מבחני DR חושפים פערים בין מורכבות ההתאוששות המשוערת למורכבות ההתאוששות בפועל. ייתכן שאפליקציה שקיבלה ציון נמוך במורכבות ההתאוששות בהערכה הראשונית ביצעה ביצועים גרועים בתרגיל שולחן, דבר המצביע על עדכון ציון כלפי מעלה.
סקירת שינויים רגולטוריים. תקנות חדשות או שינויים בתקנות קיימות עשויים להטיל התחייבויות חדשות בנוגע לזמן התאוששות על יישומים ספציפיים. דרישות החוסן התפעולי של תקנת DORA עבור מוסדות פיננסיים באיחוד האירופי, לדוגמה, הטילו התחייבויות RTO ספציפיות על "פונקציות קריטיות או חשובות" שייתכן שלא באו לידי ביטוי בציוני הקריטיות שלפני DORA.
ארגונים עם תוכניות BCP בוגרות מתייחסים לניקוד קריטיות לא כתרגיל חד פעמי אלא כתהליך מתמשך: הציונים מתעדכנים כאשר מתרחשים שינויים משמעותיים בתלות היישומים, בהשפעה העסקית או בחובות רגולטוריות, ומאומתים מדי שנה באמצעות סקירה מובנית.
הציון טוב רק כמו ראיות התלות שלו
ניקוד קריטיות יישומים מספק את הערך הרב ביותר כאשר ממד התלות שלו מבוסס על ראיות מבניות ולא על סקרים. ניתן להעריך באופן מהימן את ממדי ההשפעה העסקית ואת ממדי החובה הרגולטורית באמצעות ראיונות וניתוח תהליכים עסקיים. לא ניתן להעריך את ממד התלות התפעולית, משום שהוא דורש לדעת מה תלוי בכל יישום, ובעלי יישומים ממעיטים באופן שיטתי בערך הצרכנים במורד הזרם שלהם.
מצב הכשל צפוי: רצף שחזור שנבנה על ציוני קריטיות שמקורם בסקרים נכשל בתלות הנסתרות. שירות אימות מדור קודם משחזר באיחור. תוכנית המרת מטבעות COBOL אינה מקוונת כאשר היישומים התלויים בה מנסים לשחזר. סכימת מסד נתונים משותף נמצאת בנקודת שחזור שונה מהיישומים שקוראים ממנה. כל אחת מהכשלים הללו ניתנת למניעה בעזרת ראיות התלות שמספק ניתוח מבני, וכל אחת מהן יקרה כאשר היא מתרחשת במהלך אירוע בפועל ולא במהלך תרגיל שולחן.
מתודולוגיית הניקוד מבוססת. המסגרות קיימות. הפער שיש ברוב הארגונים אינו במסגרת הניקוד אלא בבסיס הראיות לגבי הממד המשמעותי ביותר שלה. יש לסגור את הפער הזה באמצעות ניתוח מבני לפני שהאירוע הבא דורש מתוכנית ה-BCP לפעול.
