11 טעויות פיתוח BCP המובילות

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

1. RTO ו-RPO באקראי

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

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

כמו כן, לפעמים השעתיים הללו של התאוששות שוות מיליון דולר. והרציונל של משך ה-RTO הוא עניין של כסף, וגדולים מאוד.

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

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

טוב הבנת

2. התרופה לכל דבר

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

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

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

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

- ובואו נוסיף את הסיכון של פריצה ל-BCP?

או

- לאחרונה, בזמן הגשם, הוצפה הקומה האחרונה - בוא נוסיף תרחיש, מה עושים במקרה של הצפה?

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

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

3. פנטזיה ומציאות

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

משמאל נמצאת התשתית התואמת BCP, מימין התשתית האמיתית

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

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

4. עליוניות ושורשים

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

קל באופן כללי

5. קיסר - קיסר, מנעולן - מנעולן

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

• רמה אסטרטגית - להנהלה העליונה;
• רמה טקטית - למנהלי ביניים;
• והרמה התפעולית למיישומים ישירים בשטח.

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

BCP אין תקציב

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

6. משחק תפקידים

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

למה?

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

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

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

7. היעדר גרסאות

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

אף אחד לא יכול להבין את זה

8. את מי לשאול?

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

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

אנו מחפשים את האחראים ל-BCP שנתיים לאחר הקמתו

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

9. יותר מדי מים

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

כאשר אתה מנסה לקרוא עד הרגע, מה לעשות כאשר מרכז הנתונים מוצף

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

10. על חשבון מי המשתה?

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

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

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

כך זה נראה כשרק למחלקת ה-IT יש תוכניות DR

10. אין בדיקה

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

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

לסיכום

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

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

הציוד היחיד שאינו דורש BCP

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

מקור: www.habr.com