🎶 میخواستم برای فان و بدون استفاده از AI و یا راهنمایی های موجود یه کلاینت SoundCloud با 🚀 بنویسم. پس Burp Suite عزیز رو باز کردم و شروع کردم به دیدن رکوئست هایی که داره ارسال و دریافت میشه. خبر خوب این بود که همه چیز به صورت api کار میکرد و نیازی به استفاده از چیزی مثل selenium نبود ولی توی تمام درخواست هایی که نیاز به احراز هویت داشت یه چیزی مشترک بود و اون چیزی نبود جز client_id. ولی یه نکته ای وجود داشت. توی هیچ کدوم از درخواست هایی که دریافت میشد چیزی نبود که بره client_id رو بگیره، پس احتمال دادم که client_id توی یکی از فایل های ,js مخفی شده. شروع کردم به باز کردن تک تک لینک های .js ای که توی html لود شده ی صفحه ی soundcloud.com وجود داشتن و بوم :)

چیزی که ما میخواستیم تو یکی از فایل های .js به دو صورت زیر مخفی شده بود.

"client_id=f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5" 
client_id:"f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5"

حالا وقتش بود که این فرایند رو اتوماتیک کنم. عید وقت خوبیه که اگه هنوز regex بلد نیستید، یاد بگیرید (وبسایت https://regexlearn.com/ و ریپو ی https://github.com/ziishaned/learn-regex که ترجمه فارسی هم داره و در نهایت ویدیوی https://www.youtube.com/watch?v=sXQxhojSdZM منابع خوبی برای یادگیری هستن).

سناریو ساده بود یه کد go بنویسم که بره محتوای soundcloud.com رو بگیره لینک های .js رو ازش استخراج کرده و شروع کنه توی فایل های جاوا اسکریپت با regex دنبال پترن client_id بگرده. می تونید کد رو از اینجا ببینید:

https://gist.github.com/mdpe-ir/709c3ca362fa0c2a30fa71e46ddd1f96

ولی بریم برای توضیح بخش های مهمش:

✔️ تابع fetchHTML:

func fetchHTML(url string) (string, error) {
    resp, err := http.Get(url)
    if err != nil {
        return "", fmt.Errorf("error fetching URL %s: %v", url, err)
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)
    return string(body), nil
}

این تابع یه درخواست HTTP GET به آدرس https://soundcloud.com/ می‌فرسته و کل محتوای HTML صفحه رو برمی‌گردونه.

نکته: اینجا defer resp.Body.Close() باعث می‌شه بعد از تموم شدن کار، اتصال بسته بشه تا منابع سیستم آزاد بشه.

✔️ استخراج لینک‌ها و کدهای جاوااسکریپت (extractJSSources)

این تابع HTML رو پارس می‌کنه و همه تگ‌های <noscript> رو پیدا می‌کنه. دو نوع جاوااسکریپت رو جدا می‌کنه: لینک‌های خارجی (با src) و کدهای داخلی (inline).
از پکیج golang.org/x/net/html برای پارس کردن HTML استفاده می‌کنه. لینک‌های نسبی رو با resolveURL به آدرس کامل تبدیل می‌کنه و فقط فایل‌هایی که به .js ختم می‌شن رو نگه می‌داره.

✔️ گرفتن محتوای فایل‌های جاوااسکریپت (fetchJSContent)

برای هر لینک .js که پیدا شده، یه درخواست HTTP می‌فرسته و محتوای فایل رو می‌گیره.

✔️ و در نهایت جستجوی client_id با Regex برای (findClientIDs)

پکیج regexp استفاده می‌کنه. دو الگو رو چک می‌کنه

برای فرمت پارامتری:

client_id=([A-Za-z0-9]{32})

برای فرمت object مانند:

client_id\s*:\s*["']([A-Za-z0-9]{32})["']

نکته: [A-Za-z0-9]{32} یعنی دنبال یه رشته ۳۲ کاراکتری از حروف و اعداد می‌گرده.

جمع‌بندی و نمایش نتیجه (main)

همه مراحل رو اجرا می‌کنه، client_idها رو جمع می‌کنه، تکراری‌ها رو حذف می‌کنه و چاپ می‌کنه.

توی تست هام متوجه شدم که هر client id حدودا ۷ روز معتبره. میشه یه cron job نوشت که طی یه مدت مشخص اجرا بشه و client id رو اپدیت کنه.

بعد از اینکه client_id رو پیدا کردیم، حالا می‌تونیم با استفاده ازش به APIهای SoundCloud درخواست بزنیم. برای این کار، من تصمیم گرفتم یه درخواست به endpoint سرچ بزنم تا یه خواننده پیدا کنم و بعد برم لیست موزیک‌هاش رو بگیرم. بیایم اینو قدم به قدم پیاده کنیم.

یه API داره که می‌تونیم با استفاده ازش یه خواننده رو جستجو کنیم. طبق درخواست‌ها تو Burp Suite یه endpoint سرچ چیزی شبیه اینه:

برای جستو در کاربران:

GET https://api-v2.soundcloud.com/search/users?q={query}&client_id={client_id}

برای جستجوی کلی :

GET https://api-v2.soundcloud.com/search?q={query}&client_id={client_id}

حالا فقط کافی بود برای گرفتن لیست موزیک های خواننده :

GET https://api-v2.soundcloud.com/users/{user_id}/tracks?client_id={client_id}

به عنوان مثال این اندپوینت لیست موزیک های Safir رو بر میگردونه:

https://api-v2.soundcloud.com/users/1016216608/tracks?client_id=f1TFyuaI8LX1Ybd1zvQRX8GpsNYcQ3Y5

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

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

🆔 @MdDaily

سلام سلام 💖

اول از همه 🎆🎆🎆🎆🎆. سالی پر از اتفاقات خوب و پر از Notification's واریزی💸 و از همه مهم تر حال خوب و سلامتی به همراه باگ 🪲 های کمتر براتون آرزو میکنم :)

امیدوارم وقتی آخر سال ۱۴۰۴ رسید به لیست کار هاتون که نگاه می کنید همه ی هدف هاتون رو تیک زده باشید ✅

تقریبا سه سال پیش بود که یه گروهی شیش نفره با دوستام داشتیم و خب هنوزم داریم و توی گروه مقالاتی که میخوندم و برام جالب بود رو مینوشتم بعد گفتم خب چرا براش یه کانال نزنم و عمومی ترش نکنم ؟ روزی که این کانال رو با هدف انتشار چیزایی که بلدم و میخونم زدم (۵ آذر ۱۴۰۱) اولین عضو های کانال بچه های همون گروه بودن و الان به لطف شما عزیزان و در کنارتون خانوادمون روز به روز بزرگتر شده و از همتون ممنونم ❤️

پ ن :
دوستان از چند روز قبل تذکر دادن با ۴۰۴ شوخی نکنم. منم گفتم حله با ۴۰۳ شوخی میکنم. توی ۴۰۳ همه چیز forbidden، پارتنر پیدا نکردم، ۴۰۴ هم که باهاش شوخی نمیکنیم ایشالا همین جمع ۴۰۵ .


ارادتمند شما
ماهان

---

امسال بیشتر از پارسال کنجکاو باشید :)

🆔 @MdDaily

بعد از اینکه از سفر برگشتیم ما بودیم و کلی دنگی که باید حساب میشد، هرکی یه جا را حساب کرده بود، یه سری جاها هزینه ها ریز میشدن و احتمال خطای محسابه ی دستیش زیاد بود، پس سریع copilot رو باز کردم و دنگی رو ساختم .

تقسیم دنگ رو براتون انجام میده، خروجی اکسل ریز هزینه ها رو هم بهتون میده و میگه کی چه قدر باید به کی پرداخت کنه.

با js خام نوشته شده ، کد پروژه پیچیده نیست ولی کار سختیو راحت کرد :)

👩‍💻 سورس کد پروژه:

https://github.com/mdpe-ir/dongy

👩‍💻 نسخه ی دیپلوی شده:

https://dongy.mddaily.ir/

ایده های باحالی میشه روش پیاده کرد و تبدیلش کرد به PWA ولی خب فعلا داره کار میکنه.

🆔 @MdDaily

⭕️ سیزدهمین صبحانه کاری ابرها تهران

🔥 قهوه، صبحانه، ارائه و گفتگوی کاری در کنار متخصصین

🎤 ارائه‌ تجربه محور توسط مصطفی افزونی



👇👇👇
🔗 abrh.ir/enjoy 🔗
👆👆👆


در کانال ابرها عضو شوید: ✌️

📣@abrhacom

گنوم 48 با نام “Bengaluru” عرضه شده و این یکی از بزرگترین آپدیت های این میزکار دوس داشتنی حساب میشه.

تقریبا توی این چندین سالی که گنو لینوکس رو با میزکار گنوم به عنوان os اصلیم داشتم. توی این نسخه ی گنوم علاوه بر کلی فیچر باحالی که اضافه شده مثل:


- اعلان‌های مرتب‌تر: اعلان‌ها حالا به‌صورت گروهی نمایش داده میشن و مدیریتشون ساده‌تر شده.

- عملکرد بهتر: با dynamic triple buffering، انیمیشن‌ها روون و مصرف منابع کمتر شده و شاهد تجربه ی کاربری روون تری توی سیستم های ضعیف تر هستیم و همچنین لود پوشه‌ها توی Files تا ۵ برابر سریع‌تره!

- ویرایشگر تصویر جدید: برش، چرخش و زوم هوشمند به نمایشگر تصاویر اضافه شده.

- فونت‌های تازه: فونت قبلی Cantarell با Adwaita Sans جایگزین شده.

- سلامت باتری: گزینه جدید برای محدود کردن شارژ به ۸۰٪ و افزایش عمر باتری.

- پخش‌کننده جدید صوتی: اپلیکیشن مینیمال برای پخش فایل‌های صوتی با کنترل سرعت.

- تقویم هوشمند: پشتیبانی از منطقه زمانی برای رویدادها.

- و بالاخره پشتیبانی از HDR (High Dynamic Range): شروع پشتیبانی از نمایشگرهای HDR .


✔️ ولی جذاب ترین بخش این آپدیت اضافه شدن سلامت دیجیتال یا همون Digital Wellbeing به تنظیمات هست. (تصویر توی پست)

این قابلیت‌ طراحی شده تا به کاربرا کمک کنه عادت‌های سالمی موقع کار با کامپیوتر داشته باشن. شامل:

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

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

یادآور استراحت: می‌تونید برای خودتون یادآور تنظیم کنید تا طبق توصیه‌های استاندارد بهداشتی، مرتب به چشم‌هاتون استراحت بدید و کمی هم بلند شید و حرکت کنید.

---

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

🆔 @MdDaily

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

🌐 https://mddaily.web.app

به پست های منتشر شده در این وبلاگ دسترسی پیدا کنید.

ولی یه مشکلی وجود داشت و اونم مدیریت وبلاگ استاتیک بود ، برای همین تصمیم گرفتم تا از نسخه ی بعدی وبلاگ کانال رو نمایی کنم و تشکر میکنم از تیم خوب kubarcloud 🟢 که اسپانسر زیر ساخت شدند.

اولین پست وبلاگ با عنوان "یادگیری Big O یک بار برای همیشه" منتشر شده که توی پست بعدی معرفیش میکنم :)

🌐 https://mddaily.ir/
---

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

🆔 @MdDaily

یادگیری Big O یک بار برای همیشه

کاور پست با GPT تولید شده :)

توی این پست حالت های مختلفی از Big O به همراه کد نمونه بررسی شدن. از ساده ترین حالت یعنی O(n) شروع میکنیم و قدم به قدم تا حالت های پیجیده تری مثل O(n log n) رو بررسی میکنیم.

پیچیدگی زمانی Big O چیه؟
توی علم کامپیوتر، از علامت‌گذاری Big O استفاده می‌شه تا الگوریتم‌ها رو بر اساس اینکه زمان اجرا یا میزان حافظه مورد نیازشون با بزرگ‌تر شدن ورودی چطوری زیاد می‌شه، دسته‌بندی کنن. یا به عبارت دیگه، یه راهیه برای اینکه تحلیل کنیم چقدر زمان می‌بره تا الگوریتم ما با بزرگ‌تر شدن ورودی اجرا بشه. منظور از ‘O’ کل عملیاته، و ‘n’ هم ورودی.

بیاین چند تا مثال رو ببینیم تا قضیه روشن‌تر بشه.

حالت O(n)
شاید ساده‌ترین مثالی که بشه فهمید، همون O(n) باشه، جایی که نرخ رشد خطیه.

یه آرایه نامرتب n رو در نظر بگیرین، یه تابعی بنویسین که بزرگترین مقدار رو برگردو...

لینک کامل مقاله در وبلاگ Mddaily:

🔗 https://mddaily.ir/یادگیری-big-o-یک-بار-برای-همیشه/

---

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

🆔 @MdDaily

🤔 شاید جا های مختلفی مثل ویدیو های یوتیوب Vibe Coding رو دیده باشید ولی Vibe Coding چیه؟

این یه روش فکر جدیده برای ساختن نرم‌افزار با کمک هوش مصنوعی. این اصطلاح رو آندری کارپاتی (Andrej Karpathy) ساخته و «وایب کدینگ» رو اینجوری توصیف می‌کنه: «خودت رو بسپر به حس و حالت، پذیرای رشد نمایی باش، و اصلاً یادت بره که کدی هم وجود داره».

اما خود Andrej Karpathy کیه؟

رزومه ی کامل و پروژه هاشو میتونید از وبسایت خودش karpathy.ai ببینید ولی به طور خلاصه جزو موسس ها و بخش تحقیقاتی OpenAI بوده بعد به عنوان مدیر ارشد هوش مصنوعی میره تسلا و بعد از چند سال مجدد بر میگرده به OpenAI.

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

با اینکه این روش کدنویسی خیلی وسوسه‌انگیزه، ولی آیا با توجه به محدودیت‌های فعلی مدل‌های زبانی بزرگ (LLM) و این اوضاعی که همه‌چیز داره تغییر می‌کنه، نتیجه‌اش به اندازه کافی دقیق هست؟ می‌شه با وایب کدینگ یه اپلیکیشن کامل رو بدون مشکل بالا آورد؟ می‌شه ازش خواست که تست‌ها رو هم بنویسه؟ با ناهماهنگی‌ها توی طراحی چیکار می‌کنه؟ این فقط یه چیز زودگذره (فَد fad) یا یه استراتژی بلندمدت واقعیه که برنامه‌نویس‌ها باید یاد بگیرن و ازش استفاده کنن؟

اکه علاقه داشتید:

📱 پست Andrej در X:

https://x.com/karpathy/status/1886192184808149383

📱 ویدیوی یوتیوب Fireship:

https://www.youtube.com/watch?v=Tw18-4U7mts

🌐 مقاله What I Learned from Vibe Coding:

https://dev.to/erikch/what-i-learned-vibe-coding-30em


---

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

🆔 @MdDaily

قسمت اول

داشتم رایتاپ I Thought It Was a Safe Deploy… Until Checkout Disappeared رو میخوندم نکات جالبی توش داشت. طرف مسئول بخش payments بوده. شروع میکنه به استقرار نسخه ی جدید. تست ها گرفته شده بوده و روی محیط Dev همه چی اوکی به نظر می‌رسید. همه چیز آروم بوده تا اینکه Slack اشون پر شده بود از پیام های: «صفحه چک‌اوت لود نمی‌شه.»، «صفحه سفیده هیچی نمیاد.» ، «اپل پِی (Apple Pay) کار نمی‌کنه.».

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

دقیقا چیشده بود؟

بخش payments از اون جاهاست که وقتی همه چی مرتب و درست کار می‌کنه، خیلی ساکت و آروم اون پشت‌صحنه به کارش ادامه می‌ده... اما وای به روزی که یه جای کارش بلنگه و یه چیزی خراب بشه؛ اونوقته که تبدیل به یه هرج و مرج می‌شه.
چند وقت پیش SDK مربوط به Apple Pay رو آپدیت کرده بودند چون نسخه‌ای که داشتن استفاده می‌کردن، دیگه توسط خود تیم اپل پشتیبانی نمی‌شد و منسوخ شده بود. نسخه‌ی جدید هم یه سری تغییرات توی API contract داشت—که بیشترش مربوط به این بود که موقع شروع کار و مقداردهی اولیه ورودی‌ها چطوری باید بهش داده بشن. اینا هم تغییرات لازم رو انجام داده بودن، همه چی رو روی محیط توسعه تست شده بود و به نظر می‌رسید همه چی ردیفه. یه مدت میگذره و میبینن هشدار های تعداد خطاهای مربوط به Apple Pay یهو خیلی بالا رفته. فهمیدن که اون SDK آپدیت‌شده، به یه تابع خاص وابسته بود که توی بعضی از مرورگرهای قدیمی‌تر پشتیبانی نمی‌شد. نتیجه‌اش این بود که همون اولِ فرآیند پرداخت، یه خطای زمان اجرا اتفاق می‌افتاد؛ یعنی انقدر زود این خطا رخ می‌داد که کلاً کل تجربه‌ی چک‌اوت رو از کار می‌نداخت. نه دیگه خبری از Apple Pay بود. نه هیچ روش پرداخت دیگه‌ای کار می‌کرد. فقط یه صفحه‌ی سفیدِ خالی جلو چشم کاربر بود.

⚠️ اول از همه: با دیباگ کردن شروع نکنید!

قبل از اینکه وارد جزئیات بشیم، یه درس خیلی مهم هست:

وقتی با یه مشکل جدی و قطعی (outage) تو محیط پروداکشن روبرو می‌شین، اولین غریزه‌تون نباید این باشه که بپرین سراغ دیباگ کردن.

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

ولی نکته اینجاست: دیباگ کردن زمان‌بره.

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

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

کامیتی که باعث مشکل شده رو برگردونین عقب (Revert). کد قبلی رو دوباره دیپلوی کنین (Redeploy). اوضاع رو پایدار کنین.

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

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

—-

⬅️ ادامه در قسمت بعدی

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

🆔 @MdDaily

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

—-

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

🆔 @MdDaily