قسمت دوم (پایانی)

بعد از تلاش برای باز تولید مشکل هیچ پیغام خطا یا کرش واضحی وجود نداشته. stack trace مشخصی هم روی صفحه دیده نمی‌شده. فقط سکوت محض تا لحظه پیدا شدن یه خطای runtime error که از لایه‌های عمیق اون SDK آپدیت‌شده‌ی Apple Pay سرچشمه می‌گرفت.داشته سعی می‌کرده از یه method خاص استفاده کنه که توی محیط بعضی از مرورگرهای قدیمی‌تر اصلاً پشتیبانی نمی‌شده. نکتش اینجاس که Apple Pay فقط روی سافاری کار می‌کنه پس این خطا فقط روی نسخه های قدیمی سافاری خودشو نشون میداده. SDK موقع بالا اومدن و مقداردهی اولیه از یه تابع استفاده می کرده که باعث کرش می‌شده. نه فقط برای خود Apple Pay، بلکه برای همه چی! از همون باگ‌های موذی که موقع توسعه از زیر دست در میره و دیده نمی‌شه.

فقط درست کردن باگ مهم نیست؛ بحث سرِ قبول مسئولیت کاره

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

- این خرابی و قطعی، واقعاً چه معنی و تجربه‌ای برای کاربر داشت؟

- این قطعی چقدر برای کل کسب‌وکار هزینه برداشت؟

- آیا می‌شد این مشکل رو زودتر تشخیصش داد؟

- ممکنه دوباره همچین اتفاقی بیفته؟

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

پس برای مستند کردن چه چیز هایی رو میتونیم بنویسیم؟

- چی رو تغییر داده بودیم

- اصلاً چرا تغییرش داده بودیم

- چی و کجا خراب شد

- چطور شد که این مشکل از زیر دست تیم QA در رفت و دیده نشد

- چه چیزهایی توی monitoring ما از قلم افتاده بود که زودتر نفهمیدیم

این کار رو نه به خاطر اینکه کسی خواسته انجام بدیم، بلکه به این دلیل انجام بدیم که شاید خودِ آینده (یا یکی از هم‌تیمی‌های آینده‌) به مشکل مشابهی بر بخوره و اون‌ها بتونن خیلی سریع‌تر به جواب و راه حل برسن.

این قطعی و اوت‌ایج ها فقط بهمون یاد نمیده که چی اشتباه شده بود یا کجای کار می‌لنگید. باعث میشه از خودمون بپرسیم: اگه دوباره همچین اتفاقی بیفته، این بار چه کارهایی رو متفاوت انجام می‌دیم؟

جمع‌بندی و حرف آخر

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

ولی خب، آدم یاد می‌گیره.

یاد می‌گیری که «قبول کردن کامل مسئولیت» واقعاً یعنی چی.

یاد می‌گیری که چطور یه قدم بری عقب‌تر و دید وسیع‌تری پیدا کنی (zoom out کنی)؛ دیگه فقط به این فکر نکنی که «چی خراب شد؟»، بلکه بری سراغ اینکه «این خرابی روی چه کسایی تأثیر گذاشت؟».

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

یه چک‌لیست برای وقتی که این اتفاق برای شما میفته:

- سریع نپرین سراغ دیباگ کردن: اگه مشکل جدیه و روی کاربرها تأثیر مستقیم گذاشته، اولین قدم اینه که کد رو برگردونین به نسخه‌ی قبلی. بعدش با خیال راحت‌تر برین دنبال دلیل مشکل بگردین.

- زود و شفاف اطلاع‌رسانی کنین: حتی یه پیام کوتاه مثل «دوستان دارم بررسی می‌کنم» توی کانال‌های ارتباطی خیلی تأثیر مثبتی داره و به آروم شدن فضا کمک می‌کنه.

- سعی کنین مشکل رو توی محیط‌های کنترل‌شده و ایزوله باز تولید کنین: یعنی دقیقاً با همون شرایطی که مشکل پیش اومده (مثلاً همون مرورگر، همون نسخه و ...).

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

- آستانه‌ی هشدارهای سیستم پایش و مانیتورینگ رو دوباره یه نگاهی بندازین: آیا واقعاً جوری تنظیم شدن که خرابی‌های کوچیک، نامحسوس یا تدریجی رو هم زود تشخیص بدن؟

- اتفاقی که افتاده رو با زبون ساده و واضح مستند کنین: این کار رو فقط برای بقیه اعضای تیم انجام ندین، بلکه برای خودتون در آینده هم انجام بدین. حافظه یاری نمی‌کنه!

- به تأثیر مشکل روی کسب‌وکار (business impact) فکر کنین: حدوداً چند تا کاربر تحت تأثیر قرار گرفتن؟ و این مشکل برای چه مدت زمانی ادامه داشت؟

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

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

🧱 5 Core Pillars of System Design


✔️ Designing systems is one thing, but mastering the principles that guide their creation is where the real magic happens.


1️⃣ Availability Ensures systems are up and running.
⚠️ Trade-off: Complexity vs. uptime.


2️⃣ Scalability Handles growing loads efficiently.
⚠️ Trade-off: Cost vs. performance.


3️⃣ Reliability Guarantees consistent performance.
⚠️ Trade-off: Redundancy vs. simplicity.


4️⃣ Maintainability Eases updates and debugging.
⚠️ Trade-off: Initial effort vs. long-term gains.


5️⃣ Performance Optimizes speed and responsiveness.
⚠️ Trade-off: Resources vs. user experience.



➖➖➖➖➖➖
📚 Article: [here]
➖➖➖➖➖➖
#systemDesign #softwareEngineering


🖥 Follow @devDastan for more content.

یه ماراتن تو پکن برگزار کردن که توش ۲۱ ربات انسان‌نما با ۱۲ هزار دونده رقابت کردن، هدف این بود نشون بدن ربات‌ها چقدر توی دویدن مسافت‌های طولانی پیشرفت کردن.

اوضاع خیلی خوب پیش نرفت، مثلا بیشتر ربات‌ها توی مسیر از کار افتادن یا باتریشون تموم شد و بعضی از ربات‌ها به دلیل جدا شدن سر از بدن خراب شدن. با این حال یکی از ربات‌ها تونست مسیر رو با زمان ۲ ساعت و ۴۰ دقیقه تمام کنه که از زمان تعیین شده برای انسان‌ها بهتر بود.

🔗 interestingengineering
🤓 @geekalerts