چک‌لیست مواجهه با فاجعه در نرم‌افزار
مهم نیست که با چه زبانی برنامه را نوشته‌اید. مهم نیست که چقدر شما و هم‌تیمی‌هایتان سابقه دارید. مهم نیست که از چه متدولوژی‌ای استفاده کرده‌اید. مهم نیست که چه روزی از سال و یا چه ساعتی است. مهم این است که قطعاً رخ خواهد.
شما باید همیشه آماده باشید که فاجعه‌ای پیش‌بینی نشده در سیستم نرم‌افزاریتان پیش بیاید. فاجعه‌ای که سیستم را به کلّی از کار می‌اندازد، داده‌ها را خراب می‌کند، عملیات‌های مختلف سیستم را مختل می‌کند یا میلیاردها تومان مغایرت مالی ایجاد می‌کند.
حالا که می‌دانیم بالأخره روزی این اتّفاق می‌افتد، بهتر است که برای مواجهه با آن آماده شویم.
من اینجا ده قدم مواجهه با فجایع نرم‌افزاری را نوشته‌ام. ده قدمی که به من کمک کرده در تمام دفعاتی که چنین فجایعی رخ داده آن‌ها را پشت سر بگذارم. بدون اینکه مشتری‌ها با نارضایتی بالایی روبه‌رو شوند، مدیران ناراضی باشند یا ضرر مالی هنگفتی به شرکت وارد شده باشد.
این ده قدم را به عنوان یک چک‌لیست نزد خودتان داشته باشید تا در زمان رویداد فاجعه، مطابق آن عمل کنید و کم‌ترین ضرر را ببینید.
فهرست مطالب
آرامش خودتان را حفظ کنید
بله. کلیشه‌ای است. خیلی هم کلیشه‌ای است. ولی مهم‌ترین قدم است. اگر نتوانید آرامش خودتان را حفظ کنید همه‌چیز تمام است.
فراموش نکنید که شما تمام دانش و توانایی لازم برای حل مشکل را دارید. چند بار نفس عمیق بکشید تا بدنتان را وادار کنید از حالت جنگ و گریز خارج شود.
پس از با خبر شدن از مشکل کمی به خودتان وقت بدهید و بلافاصله سراغ بررسی و حل آن نروید. اجازه بدهید که ذهنتان با شرایط پیش آمده کنار بیاید. معلوم نیست که شما چقدر زود یا دیر مشکل را متوجّه شده‌اید. این چندثانیه تأخیر را بگذارید به حساب اینکه چندثانیه دیرتر متوجّه خطا گشته‌اید.
اگر می‌بینید حفظ آرامش برایتان سخت است کمی قدم بزنید. چیزی بنوشید یا یک چیز شیرین بخورید.
یادتان نرود که باگ و فاجعه هم بخشی از اتّفاقات طبیعی در طول عمر نرم‌افزار اند. شما تنها کسی نیستید که با باگ روبه‌رو شده. محصولات خیلی بزرگ‌تر از محصول شما برای ساعت‌ها قطعی را تجربه کرده‌اند.
هیچ‌کس مقصر نیست و هیچ خطری شما را تهدید نمی‌کند. تنها یک مشکل پیش آمده که شما به عنوان یک مهندس نرم‌افزار وظیفه دارید که آن را حل کنید. درست مثل همیشه.
رفتار و دامنه‌ی اثر مشکل را دقیقاً مشاهده کنید
حالا ببینید که اصلاً مشکل کجا دارد اتّفاق می‌افتد. رفتار بیرونی مشکل را تماشا کنید. آیا سرویسی از کار افتاده؟ جایی داده‌های اشتباه نمایش داده می‌شود؟ حساب‌وکتاب‌های مالی بخشی به هم ریخته؟
در این مرحله فقط سناریوی ایجاد خطا را قرار است ببینید. اینکه چرا مشکل به وجود آمده، چند نفر آن را می‌بینند و… مهم نیست. تمرکزتان را روی پیداکردن رفتار خطا و دامنه‌ی اثر آن بگذارید.
دامنه‌ی اثر یعنی اینکه چه بخش‌هایی از نرم‌افزار درگیر خطا اند؟ چه حجمی از کاربران «ممکن» است که این خطا را مشاهده کنند؟
برای این قدم دانستن همین دو مورد کفایت می‌کند.
مدیران و همکاران را باخبر کنید
سریع، بدون پنهان‌کاری و بدون تلف‌کردن وقت برای توضیحات اضافی مدیران و همکاران را باخبر کنید. به مدیران غیر فنی کافی است که توضیح بدهید فلان خطا در فلان بخش رخ داده و تیم فنّی در حال تلاش برای حل آن است.
ولی شرح کامل مشاهداتتان را به مدیران فنی و همکارانتان بدهید و بلافاصله از آن‌ها درخواست هم‌فکری بکنید. اینطوری هم مشکل زودتر حل می‌شود و هم بخشی از بار روانی حل یک مشکل بزرگ از روی دوش شما برداشته می‌شود.
از اینجا به بعد هر مرحله‌ای که در رفع خطا جلو رفتید آخرین وضعیّت را به مدیران و همکاران گزارش بدهید.
اگر دیدید که مدیران در بازه‌های زیر یک ساعت از شما پیگیری می‌کنند، به آن‌ها توضیح بدهید که مشغول رفع مشکل هستید و به صورت مؤدبانه بخواهید که تمرکزتان را به هم نزنند.
از گسترش خرابکاری جلوگیری کنید
لازم است که دسترسی کاربران به یک بخش گرفته شود؟ لازم است که برای جلوگیری از گسترش خرابی یک یا چند سرویس از دسترس خارج شوند؟ هرکار سریعی که باعث می‌شود خطا گسترش پیدا نکند را انجام بدهید. حتّی اگر این کار به معنی از دسترس خارج کردن کل سیستم باشد.
کاربران خیلی راحت فراموش می‌کنند که شما سال پیش یک ساعت در دسترس نبودید. ولی فراموشی اینکه تمام اطّلاعاتشان درز پیدا کرده یا اینکه پولشان دود شده ناممکن است.
راه حل‌های ممکن را لیست کنید
با کمک تیم لیستی از راه حل‌های ممکن تهیّه کنید. از راه حل‌های دم دستی گرفته تا راه حل‌هایی که نیازمند تغییر ساختار پیچیده هستند. ما در قدم پیش از گسترش خطا جلوگیری کردیم. پس دیگر لازم نیست که اضطراب آن را تحمّل کنیم. پس اینجا ذهنمان برای پیداکردن راه حل بازتر است.
راه حل‌ها را بر اساس سرعت اجرای آن‌ها مرتّب کنید و آن‌ها را با مدیران فنّی بالادستی در میان بگذارید. آن‌ها تجربه‌ی فجایع بیشتری را دارند و می‌توانند درمورد راه حل‌های احتمالی کمکتان کنند.
برای خودتان زمان بخرید
در دنیای واقعی عموماً بهترین راه حل کوتاه‌ترین نیست. به همین خاطر ما فرض می‌کنیم که اینجا شما چند راه حل پیشنهادی دارید. یک راه حل سریع و سرهم‌بندی و یک راه حل طولانی‌تر ولی از نظر فنّی درست.
اینجا نقطه‌ای است که ما باید برای خودمان وقت بخریم. برای همین سریع‌ترین راهی را که باعث می‌شود سیستم مجدداً کارایی خودش را به دست آورد انجام می‌دهیم.
حالا با کم‌ترین تغییرات و کم‌ترین زمان تلف شده ما سیستم را دوباره عملیاتی می‌کنیم. اینجا مدیران نفس راحتی می‌کشند و فشار به کلّی از روی دوش شما برداشته می‌شود.
راه حل را به خوبی آزمایش کنید
پیش از این اینکه راه حل را روی محیط عملیاتی ببرید آن را آزمایش کنید. این راه حل باید خیلی بیشتر از کدهای عادی تست شود. چون شما با عطش رفع سریع مشکل آن را نوشته‌اید و تمرکز و دقّت کم‌تری روی آن داشته‌اید.
اگر اینجا بی‌خیال آزمودن کد شوید ممکن است وسعت فاجعه را ده‌ها بار بزرگ‌تر کنید. اینکه ده دقیقه دیرتر مشکل رفع شود بهتر از این است که یک مشکل تبدیل به دوتا مشکل شود.
گزارش پس از فاجعه را بنویسید
حتماً گزارش پس از فاجعه را به محض عملیاتی شدن سیستم بنویسید. زمان فاجعه، شرح فاجعه، دلایل فنّی رخداد، راه حل‌های پیشنهادی، راه حل موقّتی پیاده‌سازی شده، کاربرانی که مشکل روی آن‌ها اثرگذاشته، مبلغ پول جابه‌جا شده و… را در گزارش بنویسید.
این گزارش بزرگ‌ترین کمک‌کننده به خود شما در آینده‌ی نه چندان دوری خواهد بود که فاجعه‌ی بعدی در آن رخ می‌دهد.
بهترین راه را پیاده‌سازی کنید
حالا که تمام فشارها از بین رفته وقت این است که بهترین راه حل را از لیست راه حل‌هایتان پیاده‌سازی کنید. اگر این کار را پشت گوش بیاندازید یعنی با راه حل موقّت سیستم را مستعد فجایع بیشتری کرده‌اید.
مهم نیست که پیش از این چه قول و قرارهایی داشته‌اید. حالا که این فاجعه رخ داده باید راه حل درستش را انجام بدهید. بقیه‌ی کارهایی که در بک‌لاگ یا روی بورد جیرا هستند در درجه‌ی دوم اهمّیّت قرار دارند.
کارهای باقی‌مانده را با اولویت بالا انجام دهید
پس از پیاده‌سازی بهترین راه حل احتمالاً متوجّه مشکلاتی در روندها یا ساختار نرم‌افزارتان شده‌اید. الان زمان این است که این کارهای باقی‌مانده را برای جلوگیری از ایجاد مجدد مشکل در این قسمت انجام بدهید.
چرا باید این کارها با اولویت بالا انجام شوند؟ چون وقتی چندروز از فاجعه می‌گذرد همه تمام آن استرس‌ها را فراموش می‌کنند و دیگر کسی به سراغ انجام این کارها نمی‌رود.
فاجعه همیشه رخ خواهد داد. ولی این شما هستید که با رفتارتان مشخّص می‌کنید که آن فاجعه چقدر آسیب ایجاد کند.
شما در مقابله با فجایع چه تجربیاتی داشته‌اید؟ در قسمت نظرتان تجربیاتتان را با من و دیگران به اشتراک بگذارید.
یا حرفه‌ای شو یا برنامه‌نویسی را رها کن.
چطور می‌شود در بازار کار خالی از نیروی سنیور ایران، بدون کمک دیگران و وقت تلف‌کردن خودت را تبدیل به یک نیروی باتجربه بکنی؟
پاسخ ساده است. باید حرفه‌ای بشوی. چیزی که من در این کتاب به تو یاد خواهم داد.
