سلام به همه، نام من ایگور تیوکاچف است و من یک مشاور تداوم کسب و کار هستم. در پست امروز ما یک بحث طولانی و خسته کننده در مورد حقایق رایج خواهیم داشت. من می خواهم تجربه خود را به اشتراک بگذارم و در مورد اشتباهات اصلی شرکت ها در هنگام توسعه یک برنامه تداوم کسب و کار صحبت کنم.
1. RTO و RPO به صورت تصادفی
مهمترین اشتباهی که من دیدم این است که زمان ریکاوری (RTO) از هوا خارج شده است. خوب، از هوا - برای مثال، برخی از اعداد دو سال پیش از SLA وجود دارد که شخصی از محل کار قبلی خود آورده است. چرا آن ها این کار را انجام دادند؟ از این گذشته، طبق همه روش ها، ابتدا باید پیامدهای آن را برای فرآیندهای تجاری تجزیه و تحلیل کنید و بر اساس این تحلیل، زمان بازیابی هدف و از دست دادن داده های قابل قبول را محاسبه کنید. اما انجام چنین تحلیلی گاهی زمان زیادی می برد، گاهی اوقات گران است، گاهی اوقات خیلی روشن نیست که چگونه - بر آنچه باید انجام شود تأکید کنید. و اولین چیزی که به ذهن خیلی ها می رسد این است: ما همه بزرگسال هستیم و می دانیم که تجارت چگونه کار می کند. وقت و پول را تلف نکنیم! بیایید مثبت یا منفی را همانطور که باید باشد. با استفاده از نبوغ پرولتری! بگذارید 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 به دنبال کسانی هستیم که مسئول BCP هستند
بنابراین، اغلب چنین اتفاقی می افتد: طرحی تهیه شد و در یک جعبه طولانی قرار داده شد تا با گرد و غبار پوشانده شود. هیچ کس آن را آزمایش نمی کند یا ارتباط آن را حفظ نمی کند. رایج ترین عبارتی که هنگام مراجعه به مشتری می شنوم این است: "طرحی وجود دارد، اما مدت ها پیش توسعه یافته است، آزمایش شده است یا خیر، این ظن وجود دارد که کار نمی کند."
9. آب زیاد
برنامه هایی وجود دارد که در آنها مقدمه پنج صفحه است، شامل شرح پیش نیازها و تشکر از همه شرکت کنندگان در پروژه، با اطلاعاتی در مورد آنچه شرکت انجام می دهد. وقتی به صفحه دهم بروید، جایی که اطلاعات مفیدی در آن وجود دارد، مرکز داده شما قبلاً سیل شده است.
وقتی می‌خواهید تا لحظه مطالعه کنید، اگر مرکز داده‌تان سیل شود چه باید بکنید؟
تمام "آب" شرکت را در یک سند جداگانه قرار دهید. خود طرح باید بسیار خاص باشد: شخصی که این وظیفه را بر عهده دارد این کار را انجام می دهد و غیره.
10. ضیافت با چه کسی است؟
اغلب، سازندگان طرح از حمایت مدیریت ارشد شرکت برخوردار نیستند. اما از سوی مدیریت میانی که مدیریت نمی کنند یا بودجه و منابع لازم برای مدیریت تداوم کسب و کار را ندارند، حمایت می شود. به عنوان مثال، بخش فناوری اطلاعات برنامه BCP خود را در چارچوب بودجه خود ایجاد می کند، اما CIO کل تصویر شرکت را نمی بیند. مثال مورد علاقه من ویدئو کنفرانس است. وقتی ویدئو کنفرانس مدیر عامل کار نمی کند، چه کسی را از بین می برد؟ CIO که "ارائه نکرد." بنابراین، از دیدگاه CIO، مهمترین چیز در شرکت چیست؟ چیزی که مردم همیشه او را به خاطر آن "دوست دارند": کنفرانس ویدئویی، که بلافاصله به یک سیستم مهم تجاری تبدیل می شود. و از نقطه نظر تجاری - خوب، VKS وجود ندارد، فقط فکر کنید، ما مانند زمان برژنف با تلفن صحبت خواهیم کرد ...
علاوه بر این، بخش فناوری اطلاعات معمولاً فکر می کند که وظیفه اصلی آن در صورت بروز فاجعه، بازگرداندن عملکرد سیستم های فناوری اطلاعات شرکت ها است. اما گاهی اوقات نیازی به انجام این کار نیست! اگر فرآیند کاری به شکل چاپ تکه های کاغذ روی یک چاپگر بسیار گران قیمت وجود دارد، نباید چاپگر دومی را به عنوان یدکی خریداری کنید و در صورت خرابی آن را در کنار آن قرار دهید. ممکن است کافی باشد به طور موقت تکه های کاغذ را با دست رنگ کنید.
اگر ما در حال ایجاد حفاظت مستمر در فناوری اطلاعات هستیم، باید از حمایت مدیران ارشد و نمایندگان تجاری استفاده کنیم. در غیر این صورت، با شفیره شدن در بخش فناوری اطلاعات، می توانید طیف خاصی از مشکلات را حل کنید، اما نه همه موارد ضروری.
وقتی فقط بخش فناوری اطلاعات برنامه‌های DR دارد، وضعیت به این صورت است
10. بدون آزمایش
اگر برنامه ای وجود دارد، نیاز به آزمایش دارد. برای کسانی که با استانداردها آشنایی ندارند، این اصلا واضح نیست. به عنوان مثال، شما تابلوهای "خروج اضطراری" را در همه جا آویزان کرده اید. اما به من بگو سطل آتش، قلاب و بیل تو کجاست؟ شیر آتش نشانی کجاست؟ کپسول آتش نشانی در کجا باید قرار گیرد؟ اما همه باید این را بدانند. برای ما اصلا منطقی به نظر نمی رسد که هنگام ورود به دفتر یک کپسول آتش نشانی پیدا کنیم.
شاید نیاز به آزمایش طرح در خود طرح ذکر شود، اما این تصمیم بحث برانگیز است. در هر صورت، تنها زمانی می توان یک طرح را کارآمد دانست که حداقل یک بار آزمایش شده باشد. همانطور که در بالا ذکر شد، من اغلب می شنوم: "یک برنامه وجود دارد، تمام زیرساخت ها آماده شده است، اما این یک واقعیت نیست که همه چیز همانطور که در برنامه نوشته شده است انجام شود. چون تست نکردند هرگز".
در نتیجه
برخی از شرکت ها می توانند تاریخچه خود را تجزیه و تحلیل کنند تا بفهمند چه نوع مشکلاتی ممکن است رخ دهد و چقدر احتمال دارد. تحقیقات و تجربه نشان می دهد که ما نمی توانیم خود را از همه چیز محافظت کنیم. این اتفاق دیر یا زود برای هر شرکتی اتفاق می افتد. نکته دیگر این است که چقدر برای این یا موقعیت مشابه آماده خواهید بود و آیا می توانید به موقع کسب و کار خود را بازیابی کنید.
برخی افراد فکر می کنند که تداوم به این است که چگونه می توان انواع خطرات را از بین برد تا محقق نشود. نه، نکته این است که خطرات تحقق خواهند یافت و ما برای این امر آماده خواهیم بود. سربازان برای فکر کردن در جنگ، بلکه برای عمل تربیت شده اند. طرح BCP نیز به همین صورت است: به شما این امکان را می دهد تا کسب و کار خود را در سریع ترین زمان ممکن بازیابی کنید.
تنها تجهیزاتی که نیازی به BCP ندارد
ایگور تیوکاچف،
مشاور تداوم کسب و کار
مرکز طراحی سیستم های محاسباتی
"جت اینفوسیستمز"
منبع: www.habr.com