در تاریخ 1 آگوست 2012، شرکت Knight Capital Group به دلیل یک خطای نرم‌افزاری، دچار ضرر سنگین مالی شد. به‌روزرسانی نکردن یکی از هشت سرور توسط یک تکنسین، باعث فعال شدن غیرمنتظره یک قابلیت قدیمی به نام ‘Power Peg’ شد که اختلالات بزرگی در بازار ایجاد کرد. این موضوع باعث شد قیمت 148 سهم فهرست شده در بورس NYSE به صورت نامنظم تغییر کند و طی 45 دقیقه، 4 میلیون معامله انجام شود که منجر به زیان پیش از کسر مالیات 440 میلیون دلاری شد. سهام Knight Capital بیش از 70% سقوط کرد و نیاز به سرمایه‌گذاری اضطراری 400 میلیون دلاری پیدا کرد.
یا مثلاً در سال 1990، شرکت AT&T با یک خرابی فاجعه‌بار شبکه مواجه شد که علت آن یک خط کد اشتباه در یک به‌روزرسانی نرم‌افزاری بود. این اتفاق باعث ضرر 60 میلیون دلاری و اختلال گسترده شد. شبکه AT&T، که به‌عنوان الگویی از کارایی شناخته می‌شد، به‌خاطر یک اشتباه کوچک در یک خط کد دچار بحران شد. یک عبارت ‘break’ نادرست در یک برنامه C باعث بازنویسی داده‌ها و ریست شدن سیستم در کل شبکه شد. نتیجه؟ بیش از 60 هزار آمریکایی خدمات تلفن خود را از دست دادند، 500 پرواز به تعویق افتاد که روی 85 هزار نفر تأثیر گذاشت، و 60 میلیون دلار از جیب AT&T رفت.
این‌ها می‌توانستند کالبدشکافی‌های جالبی برای مطالعه باشند، ولی متأسفانه چیزی درباره آن‌ها در اینترنت پیدا نکردم. اما مطمئنم که ماه‌ها برای بررسی دلایل این شکست‌ها وقت گذاشته‌اند و راه‌حل‌هایی برای پیشگیری از آن‌ها پیاده‌سازی کرده‌اند.
حقیقت را قبول کنیم؛ اگر شما مدیر ارشد فناوری (CTO) یا هر نوع رهبر دیگری در حوزه فناوری باشید، با بحران روبه‌رو خواهید شد — شاید نه در ابعاد Knight Capital Group یا AT&T — اما بحران قطعاً اتفاق خواهد افتاد. مسئله این نیست که آیا بحران پیش خواهد آمد یا نه، بلکه این است که چه زمانی رخ خواهد داد. من شخصاً با چندین بحران دست‌وپنجه نرم کرده‌ام — از پروژه‌ای که از کنترل خارج شده بود گرفته تا یک قطعی چندساعته دیتاسنتر که تأثیر بزرگی روی مشتریان داشت. این شبیه دیدن تصادف یک ماشین در حالت اسلوموشن است — ماشین را می‌بینید که به سمت شما می‌آید، ولی هیچ کاری نمی‌توانید برای متوقف کردنش انجام دهید. فقط منتظر برخورد باشید.
یک بار به یاد دارم که قرار بود یک محصول مهم را عرضه کنیم. ارائه بزرگ، زمان اجرای زنده مشخص شده، شرکا هم‌سو، تیم بازاریابی درگیر، مشتریان مطلع. فکر می‌کردیم همه چیز درست است. اما هنگام عرضه، همه چیز خراب شد. پرداخت‌ها کار نمی‌کردند. گواهی‌های امضای دیجیتال همخوانی نداشتند. دقیقاً همان سناریوی کابوس‌واری که می‌خوانید و می‌گویید: “خدا را شکر که این برای من نیست.”
خب، این برای من بود. و بگذارید بگویم، مسئولیت آن سنگینی عجیبی دارد. مشتری‌ها به شما اعتماد کرده‌اند که چیزی تحویل دهید، و اوضاع طبق برنامه پیش نمی‌رود. خلاصه داستان — یک تماس اضطراری برقرار کردیم، بهترین افراد تیم را برای ارزیابی مسئله، بررسی لاگ‌ها و پیدا کردن علت فراخواندیم. این یک رقابت با زمان بود، اما شکر خدا تیم عالی بود. به مشتری‌هایمان کاملاً شفاف توضیح دادیم چه اتفاقی افتاده است، ولی همچنان عصبانی بودند. یک بررسی داخلی انجام دادیم و از اشتباهات خود درس گرفتیم و فرآیندهایی پیاده‌سازی کردیم تا دیگر چنین اتفاقی نیفتد.
🏄 به همین دلیل است که فکر می‌کنم کالبدشکافی‌ها چیزهای فوق‌العاده‌ای هستند. آن‌ها، در واقع، کالبدشکافی شکست هستند. بررسی دقیق آنچه اشتباه پیش رفته، چرا و چگونه. به نظر من، باید بیشتر انجام شوند.
به صنعت هواپیمایی یا مهندسی سازه نگاه کنید. در این حوزه‌ها، کالبدشکافی‌ها با نوعی تعصب مذهبی انجام می‌شوند. وقتی هواپیمایی سقوط می‌کند یا پلی فرو می‌ریزد، کارشناسان با دقت هر جزئیات را بررسی می‌کنند، از خرابی‌های مکانیکی گرفته تا خطاهای انسانی. این فرآیندی بی‌رحمانه و اغلب تلخ است، اما همین‌طور است که این صنایع به استانداردهای ایمنی قابل‌توجهی رسیده‌اند. آن‌ها این حقیقت سخت را می‌پذیرند که بهترین درس‌ها اغلب در پی شکست‌ها نوشته می‌شوند.
در مهندسی نرم‌افزار، شاید خطر همیشه مثل صنعت هواپیمایی مرگ و زندگی نباشد، اما باز هم خیلی بالا است. یک خطای کدنویسی می‌تواند میلیون‌ها دلار هزینه داشته باشد، یک نقص امنیتی می‌تواند داده‌های شخصی هزاران نفر را به خطر بیندازد، و یک خرابی سیستم می‌تواند یک کسب‌وکار را فلج کند.
ما باید همان نگرش بی‌پرده‌ای را اتخاذ کنیم که در هواپیمایی و مهندسی سازه وجود دارد. کالبدشکافی‌ها نباید فقط یک مراسم فرمالیته یا بازی مقصر پیدا کردن باشند. آن‌ها باید بخشی از هر فرآیندی باشند. چیزی اشتباه پیش رفته؟ بلافاصله، تحلیل کامل، گزارش شفاف، چک‌لیست به فرآیند اضافه شود تا دیگر تکرار نشود. مشکلات پیش خواهند آمد. مطمئناً باید آماده باشید و برنامه‌ریزی کنید، اما هیچ مقدار برنامه‌ریزی شما را برای لحظه‌ای که برنامه از پنجره بیرون می‌رود آماده نمی‌کند. اما این شغل شماست. این چیزی است که برای آن ثبت‌نام کرده‌اید. خوش آمدید به دنیای حرفه‌ای‌ها.
همچنین بحران‌ها نسبی هستند؛ به این معنا که برداشت افراد دخیل و کسانی که از دور نظاره‌گر هستند متفاوت است. بعد از اینکه حادثه‌ای تمام شد و از آنچه اتفاق افتاده آگاهی پیدا کردید، گفتن “باید این کار یا آن کار را می‌کردید” آسان است. اما در لحظه، داستان کاملاً متفاوت است. اما هرگز به تصمیماتی که با اطلاعات موجود در آن زمان گرفتید شک نکنید. فکر نکنید اتفاقاتی که افتاد، بیشتر از چیزی که واقعاً بود، قابل پیش‌بینی بوده است.
در نهایت، تنها شکست واقعی، شکست در یادگیری از اشتباهات است. این همان اصل کالبدشکافی است – تبدیل اشتباهات به موفقیت‌های آینده.
بیایید بیشتر درباره آماده شدن و کاری که باید در زمان وقوع اشتباه انجام دهیم صحبت کنیم.
تیم خود را آماده کنید
یک اصطلاح شیک که اساساً به این معنی است که تیم شما در مواجهه با مشکلات جدی، کنترل خود را از دست ندهد. برای اینکه این اتفاق بیفتد، باید محیطی ایجاد کنید که افراد بتوانند اشتباه کنند، مسئولیت آن را بپذیرند، از آن یاد بگیرند و بدون ترس از اخراج شدن، به کار خود ادامه دهند.
دوباره می‌گویم: اشتباهات اتفاق خواهند افتاد. حتی باید برای رشد اتفاق بیفتند. اما نکته این است که چطور با آن‌ها برخورد می‌کنید. باید افراد را مسئول نگه دارید، بله، اما اینجا دادگاه تفتیش عقاید نیست. کالبدشکافی حیاتی است، اما نباید به بازی سرزنش تبدیل شود؛ بلکه باید فرصتی برای یادگیری باشد. احساسات را کنار بگذارید.
کتاب SRE گوگل مثال خوبی در مورد مقابله با فرهنگ سرزنش ارائه داده است:
مواجهه با زبان سرزنش‌آمیز از سوی یک مدیر اجرایی ارشد می‌تواند چالش‌برانگیز باشد. مثلاً این جمله را که در یک جلسه درباره خرابی گفته شده در نظر بگیرید:
VP اش: می‌دانم که باید بدون سرزنش باشیم، اما اینجا فضای امنی است. کسی باید از قبل می‌دانست که این ایده بدی است، پس چرا به آن شخص گوش نکردید؟
با حرکت دادن بحث به سمت یک مسیر سازنده‌تر، آسیب را کاهش دهید. مثلاً:
SRE دانا: هوممم، مطمئنم که همه بهترین نیت را داشتند. پس شاید بهتر باشد به‌جای مقصر دانستن، به طور کلی بپرسیم آیا نشانه‌های هشداردهنده‌ای وجود داشت که می‌توانستیم به آن‌ها توجه کنیم و چرا ممکن است آن‌ها را نادیده گرفته باشیم؟
تأثیر واقعی ایمنی روانی زمانی مشخص می‌شود که شرایط بحرانی می‌شود. اگر تیم شما خونسرد و متمرکز با ذهنیت حل مسئله عمل کند، در وضعیت طلایی قرار دارید. اما اگر از ترس اشتباه کردن یا اخراج شدن، مضطرب باشند، عملاً دارید تلاش می‌کنید یک بمب را در حالی خنثی کنید که کسی دارد نردبان شما را تکان می‌دهد. خیلی لذت‌بخش نیست.
چگونه می‌توانید ایمنی روانی تیم خود را ارزیابی کنید؟ ابتدا با ارائه یک مثال شروع کنید. به عنوان یک رهبر، واکنش شما به مسائل، لحن کلی را تعیین می‌کند. به تیم خود نشان دهید که اشکالی ندارد اگر فوراً تمام پاسخ‌ها را نداشته باشید، و آن‌ها را تشویق کنید که با یکدیگر ارتباط باز داشته باشند تا راه‌حل‌ها را پیدا کنند.
سپس رفتار تیم خود را مشاهده کنید؛ دقت کنید که آن‌ها چگونه با مشکلات جزئی برخورد می‌کنند. در ادامه، به گفت‌وگوها بپردازید و به‌طور مستقیم بپرسید: آیا آن‌ها می‌توانند بدون از هم پاشیدن با یک بحران جدی (code red) مواجه شوند؟ چه اتفاقی می‌افتد اگر اوضاع کاملاً به هم بریزد؟ این مسائل را با تیم و در جلسات فردی (1:1) مطرح کنید. درک این موضوع به شما نشان می‌دهد که تیم شما با چه نوع بحرانی می‌تواند مقابله کند و چگونه در شرایط سخت واکنش نشان می‌دهد. چون باور کنید، آن شرایط پیش خواهد آمد.
خطاها را شبیه‌سازی کنید. سناریوهایی را با تیم خود بررسی کنید که در آن‌ها مشکلات بزرگی رخ داده است، مثلاً قطع گسترده سیستم، نشت اطلاعات شخصی، یا دسترسی غیرمجاز. این سناریوها را اجرا کنید و مراحلی را که برای مدیریت بحران ضروری هستند، مورد بحث قرار دهید.
قبل از وقوع مشکلات
قبل از اینکه هر چیزی خراب شود، باید یک برنامه داشته باشید. و منظورم برنامه‌ای جدی است، نه یک برنامه نیم‌بند از نوع «وقتی به آن پل رسیدیم، از روی آن عبور می‌کنیم». منظورم یک برنامه محکم از نوع «این کاری است که وقتی دنیا به پایان می‌رسد، انجام می‌دهیم» است.
این یعنی دقیقاً بدانید در صورت نقض امنیت، از کار افتادن دیتاسنتر، یا هر سناریوی فناورانه آخرالزمانی دیگری چه کاری باید انجام دهید. اگر دارای گواهینامه ISO 27001 هستید، احتمالاً از قبل لیستی از محتمل‌ترین سناریوها و یک برنامه واکنش مرحله‌به‌مرحله برای هر یک دارید.
یک برنامه ساده مدیریت بحران شامل موارد زیر است:
- فهرستی از کارهایی که باید انجام شود.
- ترتیب انجام این کارها.
- افراد مسئول برای انجام این کارها.
- نتایجی که باید حاصل شوند.
به نظر ساده می‌رسد، درست است؟ عالی. مطمئن شوید که تیم شما نقش‌های خود را می‌دانند. مثلاً چه کسی مسئول ارتباطات است؟ چه کسی مسئولیت فنی را به عهده دارد؟ در حالت بحران، نمی‌خواهید از صفر شروع به نوشتن ایمیل کنید. پروتکل‌های ارتباطی برای تیم‌های داخلی، ذی‌نفعان، و مشتریان تنظیم کنید. این فقط در مورد آمادگی نیست؛ بلکه در مورد هوشمندی است. زیرا وقتی طوفان می‌آید، زمان ساختن پناهگاه ندارید. باید از ابتدا آماده باشید.
من شخصاً از خواندن گزارش‌های پسا-بحران لذت می‌برم. این مجموعه عالی را پیشنهاد می‌کنم. مطالعه آن‌ها که نشان می‌دهد دیگران چگونه اشتباه کرده‌اند (لیست عالی!) و چطور با آن‌ها برخورد کرده‌اند، بسیار آموزنده است.
صداقت تنها سیاست شماست. اگر نقض امنیت رخ داده و وقت تماس با مقامات است، این کار را انجام دهید. بدون هیچ تردیدی. اعتبار شما و شرکت‌تان به یک تار مو بسته است. این همان جایی است که به‌عنوان یک رهبر خود را اثبات می‌کنید. بدون تعارف، بدون دور زدن موضوع. فقط صحبت صادقانه، قبول مسئولیت، و یک مسیر روشن برای کنترل خسارت.
پس از وقوع بحران
نفس عمیق بکشید. روز سختی بود، اما اکنون اوضاع تحت کنترل است. بحران ممکن است تمام شده باشد، اما به‌عنوان یک CTO، کار شما تازه شروع شده است. حالا وقت آن است که مقابل هیئت مدیره یا حتی مدیرعامل بایستید و همه‌چیز را توضیح دهید. این فقط ارائه یک گزارش نیست؛ بلکه پذیرش اشتباهات است.
بهترین تیم فنی خود را برای بررسی دقیق مشکل جمع کنید. تمام جزئیات را بررسی کنید: از هر تغییر کد گرفته تا هر پیغام خطا، هر لاگ، هر استقرار، و هر بسته شبکه. یافته‌ها را خلاصه کنید و آن‌ها را قابل درک کنید.
بهترین حالت این است که گزارش را به صورت مشترک با تمام افرادی که درگیر بوده‌اند، تهیه کنید. آن را ارائه دهید، بحث کنید، و گام‌هایی را برای جلوگیری از تکرار این فاجعه تعیین کنید. احساسات را کنار بگذارید. این فقط در مورد حقایق سخت است، حتی اگر به معنای بلعیدن غرور و پذیرش اشتباه باشد.
در اینجا یک نمونه از نحوه نوشتن یک گزارش پسابحران آورده شده است:
عنوان و مالکیت: یک عنوان واضح برای گزارش و شناسایی مالک یا مالکین سند.
تاریخ و زمان حادثه: زمان وقوع حادثه را مشخص کنید.
نویسندگان و مشارکت‌کنندگان: نام افرادی که گزارش را نوشته‌اند و کسانی که در حادثه درگیر بوده‌اند.
وضعیت: مشخص کنید که آیا گزارش در حالت پیش‌نویس، تحت بازبینی، یا نهایی است.
خلاصه اجرایی: مرور کلی از حادثه شامل تأثیرات و علت اصلی.
تحلیل تأثیر: اطلاعات دقیق در مورد آنچه در طول حادثه تحت تأثیر قرار گرفته است.
تحلیل علت ریشه‌ای: بررسی عمیق دلایل حادثه.
جدول زمانی رویدادها: شرح زمانی وقایعی که حادثه را رقم زدند.
موارد عملی و اصلاحات: گام‌های مشخص و قابل اجرا برای جلوگیری از تکرار، به همراه تعیین مسئولان و مهلت‌های زمانی.
درس‌های آموخته‌شده: نکات کلیدی و بینش‌هایی که از حادثه به دست آمده‌اند.
چه کسی مقصر است؟ گفتم نه! این مقاله در مورد کالبدشکافی بدون مقصر را بررسی کنید.
نکات کلیدی برای گزارش‌های پسا-بحران:
- به جزئیات بپردازید: هنگام مواجهه با خطای بک‌اند، به توضیحات سطحی بسنده نکنید. خطا و دلایل اصلی آن را به‌طور کامل بررسی کنید. آیا QA بهتر، بررسی‌های همکارانه بیشتر، یا مدیریت استثناهای بهتر می‌توانست از وقوع آن جلوگیری کند؟ آیا CI خودکار شکست خورد؟ چه تست‌هایی از قلم افتاد؟ چه ابزارهایی نداشتیم؟ چرا نداشتیم؟
- گام‌های حل مسئله مشخص: از راه‌حل‌های کلی و مبهم مانند «نیاز به استقرار بهتر داریم» یا «مستندسازی را بهبود دهیم» اجتناب کنید. در عوض، گام‌های مشخص و عملی برای رفع مستقیم مشکل تعریف کنید. به عنوان مثال: «X آزمایش‌های fuzzy را به خط لوله استقرار اضافه می‌کند. Y بررسی متغیرهای پیکربندی را قبل از استقرار اضافه خواهد کرد.»
- بر راه‌حل‌های فوری تمرکز کنید، سپس به راه‌حل‌های بلندمدت بپردازید: ابتدا اصلاحاتی را اولویت‌بندی کنید که می‌توانند به‌سرعت از تکرار مشکل جلوگیری کنند. در حالی که تحلیل گزارش به تغییرات بلندمدت منجر می‌شود، هدف فوری شما رفع سریع است.
- چالش وضعیت موجود: از گزارش برای پرسش و آزمایش فرضیات تیم استفاده کنید. صرفاً به این دلیل که یک باور به‌طور گسترده پذیرفته شده، به معنای درست بودن آن نیست. آماده باشید تا باورهای نادرست را کشف و اصلاح کنید.
اشتباهات رایج
اگر اشتباهی رخ داده است، چندین کار وجود دارد که باید در هر شرایطی از آن‌ها اجتناب کنید:
- سرزنش و انگشت‌نما کردن.
- ارتباطات مبهم با مشتریان.
- قبول نکردن اشتباه.
- پنهان کردن مسئله زیر فرش.
هر یک از این موارد نه تنها مدیریت بد است؛ بلکه مثل ریختن بنزین روی آتش است.
به عنوان مثال، گزارشی را در Hacker News خواندم که درباره قطعی بزرگی بود. در زمان نوشتن این متن سعی کردم لینک آن را پیدا کنم، اما نام شرکت یادم نیامد. گزارش به قدری نامفهوم بود که پر از اصطلاحات فنی بود که کسی خارج از حوزه IT نمی‌توانست آن را بفهمد. ارتباطات بسیار مبهم و بدون اشاره‌ای به «ما متأسفیم» بود. حتی صفحه وضعیت به سادگی نوشته بود: «ما در حال رفع مشکلات فنی هستیم.» بله، واضح است!
مشتریان زمان‌هایی را که آن‌ها را در تاریکی رها کردید یا داده‌هایشان به دلیل اشتباه تیم شما در معرض خطر قرار گرفت، فراموش نمی‌کنند. مشتریان حافظه‌ای طولانی و حساب‌های توییتری دارند. آن‌ها به خاطر خواهند آورد که چگونه یک بحران را مدیریت (یا بد مدیریت) کردید، و مطمئن باشید که این موضوع را به شما یادآوری خواهند کرد.
مثال بالا چیزی است که باید به هر قیمتی از آن اجتناب کنید. شاید گزارش‌های شما به Hacker News نرسند، اما آن‌ها را طوری بنویسید که انگار قرار است و تا حد ممکن شفاف باشید.
«فرهنگ کالبدشکافی» را خوانده‌ام و لذت برده‌ام، شدیداً توصیه می‌کنم.
نتیجه‌گیری
خُب، جمع‌بندی کنیم. نکات اصلی:
- حادثه‌ها رخ می‌دهند. سیستم‌ها خراب می‌شوند، کدها دچار مشکل می‌شوند، و گاهی اوقات، با وجود تمام تلاش‌های شما، اوضاع خراب می‌شود.
- نحوه برخورد شما اهمیت دارد.
- ارتباطات اهمیت دارد.
- یادگیری از حادثه‌ها اهمیت دارد.
- وقتی اوضاع به هم می‌ریزد، خونسردی خود را حفظ کنید، تیم خود را هماهنگ کنید و آن‌ها را در جریان نگه دارید.