یک پست‌مورتم عمومی از یک قطعی

بسیاری از چیزها در زندگی یک رویکرد “محافظه‌کارانه” پذیرفته‌شده و یک رویکرد “پرخطر” پذیرفته‌شده دارند که باید از آن اجتناب کرد، حداقل بر اساس احساس عمومی. در سرمایه‌گذاری، به عنوان مثال، خرید اوراق قرضه دولتی یا شهرداری را اغلب به عنوان کم‌ریسک می‌بینیم و سرمایه‌گذاری در سهام (سهام شرکتی) را پرخطر – اما اعداد آماری به ما می‌گویند که این معکوس است و تقریباً همه روی اوراق قرضه ضرر می‌کنند و روی سهام سود می‌برند. “خرد” رایج، وقتی به آزمون گذاشته می‌شود، معلوم می‌شود که کاملاً بر اساس احساسات است که به نوبه خود بر سوءتصورات مبتنی است و پرخطرترین چیز در سرمایه‌گذاری استفاده از احساسات برای هدایت استراتژی‌های سرمایه‌گذاری است.

به طور مشابه، با ارزیابی ریسک تجاری، رویکرد رایج این است که به خطر واکنش احساسی نشان داده شود و این واکنش وحشت را فعال می‌کند و باعث می‌شود که افراد تمایل قوی به جبران بیش از حد برای ریسک درک‌شده داشته باشند. این را معمولاً در شرکت‌های کوچکی می‌بینیم که زیرساخت IT آن‌ها درآمد بسیار کمی تولید می‌کند یا برای عملیات کوتاه‌مدت چندان کلیدی نیست و مبالغ زیادی خرج می‌کنند تا در برابر ریسکی محافظت کنند که تنها تا حدی درک شده و بسیار ضعیف بیان می‌شود. این اغلب آنقدر دراماتیک می‌شود که فرآیند کاهش ریسک اغلب به جای ذهنی به صورت احساسی مدیریت می‌شود و به طور منظم شرکت‌هایی می‌یابیم که طراحی‌های سیستم بد پیاده می‌کنند که در واقع ریسک را به جای کاهش افزایش می‌دهند، در حالی که مبالغ بسیار زیادی خرج می‌کنند و سپس، از آنجایی که ریسک عمدتاً خیالی بود، پروژه را بر اساس لایه پس از لایه سوءتصور موفق می‌نامند: ریسک خیالی، کاهش ریسک خیالی و موفقیت خیالی.

در گذشته نزدیک، فرصت داشتم در یک بلای تمام عیار برای یک کسب‌وکار کوچک مشارکت داشته باشم. این بلا به آنچه تقریباً یک “بدترین سناریو” بود رسید. نه کاملاً، اما بسیار نزدیک. واکنش احساسی در آن زمان نسبت به بلا قوی بود و زمانی که بلا کاملاً در جریان بود، رایج بود که تقریباً همه بگویند و تکرار کنند که برنامه‌ریزی بلا معیوب بوده و این مشکل باید از قبل جلوگیری می‌شد. این در هر موقعیت بلایی بسیار رایج است؛ انسان‌ها احساس می‌کنند همیشه باید یک مقصر وجود داشته باشد و اینکه اگر کارهایمان را درست انجام دهیم سناریوهای بدون ریسک وجود خواهند داشت، اما این کاملاً غلط است.

خوشبختانه یک پست‌مورتم کامل انجام دادیم، همان‌طور که باید پس از هر بلای واقعی انجام داد، تا تعیین کنیم چه چیزی اشتباه بوده، چه چیزی درست بوده، چگونه می‌توانیم فرآیندها و تصمیماتی را که شکست خورده‌اند اصلاح کنیم و چگونه می‌توانیم مواردی را که از ما محافظت کرده‌اند حفظ کنیم. معمولاً، وقتی یک رویداد بزرگ سیستمی اتفاق می‌افتد، نمی‌توانم درباره آن به صورت عمومی صحبت کنم. اما هر از چند گاهی، می‌توانم. به قطعی واکنش نشان دادن، به هر بلایی، و فکر کردن “آه، کاش فقط...” بسیار رایج است. اما باید بلا را بررسی کنید. چیزهای زیادی درباره فرآیندها و خودمان یاد می‌گیریم.

اول، کمی پس‌زمینه. یک سرور حیاتی که در یک مرکز داده سازمانی اجرا می‌شود چندین بار کاری اصلی را که برای چندین شرکت بسیار مهم هستند نگه می‌دارد. کمی بیش از چهار سال پیش است و سال‌هاست که به صورت مستقل در حال اجراست. سرورهای قدیمی‌تر همیشه کمی نگران‌کننده هستند چون به پایان عمر نزدیک می‌شوند. چهار سال به سختی پایان عمر برای یک سرور کلاس سازمانی است اما قطعاً جوان هم نبود.

این یک سرور واحد بدون هیچ مکانیزم failover بود. پشتیبان‌گیری به صورت خارجی به یک دستگاه پشتیبان‌گیری سازمانی در همان مرکز داده انجام می‌شد. یک طراحی سیستم بسیار ساده.

تمام جزئیات داخلی را نخواهم گنجاند زیرا هر موقعیتی مانند این پیچیدگی‌های زیادی در برنامه‌ریزی و عملکرد دارد. اینها به بهترین شکل برای یک فرآیند پست‌مورتم داخلی باقی می‌مانند.

وقتی سرور خراب شد، به طور چشمگیری خراب شد. خرابی آنقدر کامل بود که نتوانستیم از راه دور آن را تشخیص دهیم، حتی با کمک تکنسین‌های موجود در مرکز داده. حتی فروشنده سرور نیز قادر به تشخیص مشکل نبود. این ما را در موقعیت دشواری قرار داد – چطور با یک سرور مرده کنار بیایید وقتی سخت‌افزار را نمی‌توان به طور قابل اطمینان تعمیر کرد. می‌توانستیم درایوها را جایگزین کنیم، منابع تغذیه را جایگزین کنیم، مادربورد را جایگزین کنیم. چه کسی می‌دانست چه چیزی ممکن است راه‌حل باشد.

در نهایت تصمیم گرفته شد که سرور به همراه سیستم پشتیبان‌گیری باید به دفتر اصلی منتقل شوند جایی که می‌توانستند به صورت شخصی و با حداکثر منابع تریاژ شوند. در نهایت سیستم توانست تعمیر شود و هیچ داده‌ای از دست نرفت. تصمیم برای خودداری از رجوع به پشتیبان گرفته شد زیرا بازیابی داده از دسترس‌پذیری سیستم مهم‌تر بود.

وقتی همه چیز گفته و انجام شد، بلا یکی از کامل‌ترین‌هایی بود که می‌توان بدون از دست دادن داده واقعی تصور کرد. قطعی برای روزهای بسیاری ادامه داشت و تجهیزات اضافی، ساعت‌های کاری و تلاش‌های تعمیر زیادی استفاده شدند. فرآیند خسته‌کننده بود اما وقتی تکمیل شد سیستم با موفقیت بازگردانده شد.

قطعی طولانی و حس آشفتگی در حین تشخیص و تلاش‌های تعمیر به یک احساس کلی شکست منجر شد. مردم شروع به گفتن آن کردند و این باعث می‌شود مردم به آن اعتقاد پیدا کنند. در شرایط اضطراری بسیار آسان است که بیش از حد احساساتی شوید، به خصوص وقتی خواب بسیار کمی وجود دارد.

اما وقتی عقب رفتیم و به نتیجه نهایی نگاه کردیم، آنچه یافتیم تقریباً همه را شگفت‌زده کرد: عملیات تریاژ و برنامه‌ریزی اولیه ریسک موفق بودند.

آشفتگی که در طول یک تریاژ اتفاق می‌افتد اغلب همه چیز را بسیار بدتر از آنچه واقعاً هست احساس می‌کند. اما مدیریت تریاژ ما عالی بود. تریاژ به معنای جادو نیست و یک مرحله کشف و یک مرحله واکنش وجود دارد. وقتی ترتیب رویدادها را تحلیل کردیم و آن‌ها را در یک جدول زمانی قرار دادیم، دریافتیم که آنقدر خوب عمل کرده‌ایم که تقریباً هیچ جایی نبود که می‌توانستیم بازه زمانی را کوتاه کنیم. تشخیص‌های خوبی انجام داده بودیم، طرف‌های مناسب را در زمان مناسب درگیر کرده بودیم، قطعات را در اسرع وقت به حرکت لجستیکی درآورده بودیم و بیشتر آنچه به نظر می‌رسید زمان هدر رفته و آشفته بود در واقع “زمان پرکننده” بود که در آن سعی می‌کردیم تعیین کنیم آیا گزینه‌های اضافی وجود دارد یا اشتباهاتی رخ داده در حالی که منتظر قطعات مورد نیاز برای تعمیر بودیم. این باعث می‌شد همه چیز بسیار بدتر از آنچه واقعاً بود احساس شود، اما همه اینها مجموعه اقدامات صحیحی بودند که باید انجام می‌دادیم.

از منظر تریاژ و بازیابی، فرآیند بی‌نقص انجام شده بود حتی اگر قطعی در نهایت روزهای بسیاری طول کشید. یک بار که بلا اتفاق افتاده بود و به اندازه باورنکردنی‌ای که رخ داد، بازیابی در واقع به طور باورنکردنی روان انجام شد. هیچ چیز کاملاً بی‌نقص نیست، اما به طور فوق‌العاده‌ای خوب انجام شد. ماشین همان‌طور که در نظر گرفته شده بود عمل کرد.

بخش بسیار شگفت‌آورتر نگاه کردن به تأثیر بلا بود. دو راه برای نگاه کردن به این وجود دارد. یکی عاقلانه‌تر است، رویکرد “بدون مزیت دیدن گذشته به روشن‌بینی آینده”. اینجا به بلا، هزینه تأثیر بلا، هزینه کاهش ریسک نگاه می‌کنیم و احتمال وقوع بلا را اعمال می‌کنیم تا تعیین کنیم آیا تصمیم برنامه‌ریزی صحیح گرفته شده است. محاسبه این سخت است چون عامل ریسک همیشه یک عدد تخمینی است، اما معمولاً می‌توانید به اندازه کافی دقیق باشید تا بدانید برنامه‌ریزی شما چقدر خوب بوده است. راه دوم رویکرد دید ۲۰/۲۰ با مزیت عقب‌نگری است – اگر می‌دانستیم که این بلا قرار است اتفاق بیفتد، چه می‌کردیم تا از آن جلوگیری کنیم؟ کاملاً ناعادلانه است که عامل ریسک را حذف کنید و ببینید هزینه خام بلا چه بوده است چون نمی‌توانیم بدانیم چه چیزی اشتباه پیش خواهد رفت و تنها برای آن یک احتمال برنامه‌ریزی کنیم یا پول نامحدود برای چیزی بخرهیم که نمی‌دانیم آیا اتفاق خواهد افتاد. شرکت‌ها اغلب اشتباه می‌کنند و از محاسبه دوم استفاده می‌کنند و برنامه‌ریزان را به خاطر نداشتن پیش‌بینی کامل سرزنش می‌کنند.

در این مورد، به طور مناسبی مطمئن بودیم که از ابتدا قمار صحیحی زده‌ایم. سیستم برای اکثر یک دهه با صفر خرابی در جای خود بود. هزینه کلی سیستم پایین بود، هزینه تریاژ متوسط بود و رویداد بسیار غیرمحتمل بود. این که با در نظر گرفتن عامل ریسک، برنامه‌ریزی خوبی انجام داده بودیم برای کسی شگفت‌آور نبود.

آنچه شگفت‌آور بود این بود که وقتی محاسبات را بدون عامل ریسک انجام دادیم، حتی اگر می‌دانستیم که سیستم خراب خواهد شد و یک قطعی طولانی رخ خواهد داد، هنوز هم همان تصمیم را می‌گرفتیم! این کاملاً شوکه‌کننده بود. هزینه قطعی طولانی در واقع کمتر از هزینه تجهیزات، هاستینگ و نیروی کار مورد نیاز برای ساختن یک سیستم کاهش ریسک کارکردی بود – در این مورد این به معنای داشتن یک سرور کاملاً اضافی در مرکز داده در کنار آن که در تولید بود می‌شد. در واقع، صرفه‌جویی در هزینه با پذیرفتن این قطعی طولانی نزدیک به ده هزار دلار صرفه‌جویی کرده بود!

این یک مورد افراطی معلوم شد که در آن قطعی به طرز ویران‌کننده‌ای بد بود، پیش‌بینی آن دشوار بود، قادر به تعمیر سریع نبود و با این حال هنوز هم منجر به صرفه‌جویی عظیم هزینه طولانی‌مدت شد، اما درس مهمی است. بار احساسی زیادی با هر بلایی همراه است؛ اگر تحلیل پست‌مورتم مناسب انجام ندهیم و تلاش نکنیم واکنش‌های احساسی را از تصمیم‌گیری‌مان حذف کنیم، اغلب به سمت زیان مالی در مقیاس بزرگ یا سرزنش نادرست خواهیم رفت حتی زمانی که اوضاع خوب پیش رفته است. بسیاری از شرکت‌ها به این بلا نگاه کرده و با صرف زیاد برای جلوگیری از تکرار همان رویداد غیرمحتمل واکنش نشان می‌دادند حتی وقتی ریاضیات در مقابلشان بود که به آن‌ها می‌گفت انجام این کار حتی اگر آن رویداد دوباره اتفاق می‌افتاد هم پول را هدر می‌داد!

درس‌های دیگری هم از این قطعی بود که یاد گرفتیم. یاد گرفتیم که ارتباطات کجا ایده‌آل نبوده، که افراد مناسب همیشه در جایگاه تصمیم‌گیری مناسب نبودند، که ارتباطات مشتری آنطور که باید نبود، مشتری تغییرات را به درستی به ما اطلاع نداده بود و موارد بیشتر. اما به طور کلی، درس‌ها این بود که به درستی برنامه‌ریزی کرده بودیم و عملیات تریاژ ما به درستی کار کرده بود و چندین هزار دلار برای مشتری صرفه‌جویی کرده بودیم نسبت به آنچه رویکرد “محافظه‌کارانه” به نظر می‌رسید و با انجام یک پست‌مورتم خوب توانستیم آن‌ها و خودمان را از واکنش بیش از حد نجات دهیم و یک تصمیم خوب را به تصمیم بد تبدیل نکنیم. بدون پست‌مورتم، ممکن بود فرآیندهای خوبمان را به فکر اینکه بد بوده‌اند تغییر دهیم.

درس‌هایی که می‌خواهم به شما، خواننده، انتقال دهم این است که پست‌مورتم‌ها یک قدم حیاتی در هر بلایی هستند، تفکر محافظه‌کارانه سنتی اغلب بسیار پرخطر است و واکنش‌های احساسی به ریسک اغلب فجایع مالی بزرگتری از فجایع فنی ایجاد می‌کنند که در صدد محافظت در برابر آن‌ها هستند.