چیزهایی که تو دانشگاه نمی‌گن: چجوری روت کاز آنالیز (RCA) تحویل بدیم؟

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

توی دنیای حرفه‌ای، اتفاق بعد می افته و تیم لایه اول ساپورت یا تکنیکال ساپورت لایه دوم و غیره لازمه با تمام سرعت ممکن مشکل رو برطرف کنن. مثلا اگر در سیستم استعلام جریمه رانندگی خراب بشه و درست کار نکنه، بر اساس قرار، مثلا توی چهار ساعت لازمه سرویس کاملا برگرده و درست کار کنه. شما ممکنه در این چهار ساعت سیستم رو ریبوت کنین یا کلا از مدار خارج کنین و سرویس دوم رو بالا بیارین و غیره و مساله از طریق یک workaround حل بشه اما فرداش لازمه مساله به شکل واقعی حل بشه. یعنی نوشتن و ارائه Root Cause Analysis یا همون RCA.

این یک داکیومنت است که توضیح می ده مشکل چرا پیش اومده بود و احیانا چطور می شه جلوی اتفاق مجددش رو گرفت. در واقع شما دارین علت ریشه ای رو تحلیل می کنین. یک مدیر خوب همیشه بعد از هر اتفاق باید از شما RCA بخواد تا ۱) بتونه بفهمه مشکل چرا پیش امده ۲) جلوش رو بگیره و ۳) دفعه بعدی مرجعی داشته باشه برای اینکه باید چیکار کنه.

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

  1. جمع کردن شواهد
  2. تشریح مساله
  3. تحلیل علت و معلول‌ها
  4. پیشنهاد راه حل‌ها
  5. نوشتن RCA

البته مساله همیشه هم به همین راحتی ها نیست و تکنیک هایی هست برای کشف اینکه مشکل کجا بوده. از ترابل شوتینگ سیسمتاتیک تا ۵ بار جواب دادن به این سوال که «چی شد که اینطوری شد؟» و غیره و غیره وجود داره. اما بازم مواردی هست که نمی شه بهش جواب داد. مثلا ممکنه فلان سرویس قطع شده باشه. جواب اول به «چی شد که اینطوری شد؟» اینه که «اپلیکیشن پایین بوده» و جواب بعدی به «چرا؟» این باشه که «چون دیتابیس کرش کرده» و بعد برسین به اینکه «دیتابیس ساعت ۴ کرش کرد» و در جواب به اینکه «چی شد که کرش کرد؟» بعدی جوابی نداشته باشین. حالا شاید بگین:

  1. دیتابیس زاپاس داشته باشیم
  2. لاگ بیشتر اضافه کنیم که ببینیم دیتابیس چرا ممکنه کرش کنه

اولی پر دردسر و گرون است و در واقع فقط فراموش کردن صورت مساله است و دومی یک پینشهاد برای داشتن RCA بهتر در صورت بروز مشکل مجدد.

برای اطلاعات دقیق تر در مورد شیوه نوشتن RCA پیشنهاد می کنم این داکیومنت سریع و راحت با عنوان «رییسم گفته آر سی ای بدم، حالا باید چیکار کنم رو ببینین یا جایی ذخیره کنین چون بدون شک همین که کار حرفه ای تری رو شروع کنین، دائما نیاز به مراجعه بهش خواهید داشت.

فهرست کاملی از چیزهایی که یک برنامه نویس باید بدونه

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

برای اینکار کتاب و غیره هست. یا حتی راهنماهای شروع ولی خب اگر فهرست کاملتری می خواین، پیشنهاد می‌کنم این فهرست با عنوان Every Programmer Should Know رو نگاه کنین. به نظرم خوبه این فهرست رو تگ کنین و هر وقت که بیکار بودین، یکیشون رو بخونین. بخصوص که بعضی‌هاش تازه اشاره‌ای است به فهرست‌های دیگه و البته برای ما متاسفانه بعضی‌هاش هم لینک است به کتاب‌های مختلف.

اگر دوست دارین برنامه نویس بهتری بشین، فهرست چیزهایی که هر برنامه نویس باید بدونه دوست شماست.

امکانات جدید شرکت‌های کامپیوتری برای کار از کافی شاپ

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

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

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

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

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

اگر هم کارمند هستین و شرکت چنین فرصتی داد، این توصیه های کلی رو یادتون باشه:

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

حالا که تا اینجا اومدین، بذارین یک غر هم بزنم که باید با کمک هم حلش کنیم: سرمایه اجتماعی پایین. ما در ایران به هم اعتماد نداریم. اگر من می گم تو خونه کار می کنم احتمالا کمتر کار می کنم. اگر شرکت می گه پول کافی شاپ رو می هد ممکنه کافی شاپی که با دوست پسر/دخترم رفته ام رو هم بزنم به حساب شرکت و غیره و غیره. از این چیزها باید برای بهتر کردن کیفیت زندگی استفاده کرد نه درآمد زایی یا تنبلی. باید کم کم اعتماد رو ایجاد کنیم.

ایستر-اِگ برنامه‌نویسی در سیلیکون ولی سیزن سه، قسمت یک

رسم خوبی در دنیای قدیم نرم‌افزار بود که طبق اون برنامه‌نویس‌ها ایستر-اِگ توی برنامه‌ها می‌ذاشتن: قطعاتی که وقتی کار خاصی می‌کردین، کار خاصی می‌کردن. مثلا ممکن بود یک برنامه حسابداری همیشه طبیعی کار کنه ولی اگر ترکیبی از پنج کلید رو پشت هم بزنین، یک بازی کوچیک توش ظاهر بشه. یا مثلا این روزها اگر عبارت do a barrel roll رو درگوگل سرچ کنین…

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

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

و وقتی سعی می‌کنین بخونین خیلی راحت نیست. حتی مثلا می‌تونین دقیق‌تر نگاه کنین که تابع main وسط خط گذاشته شده تا به راحتی نبینین که عملا یک تابع داریم که ۱۷ بار صدا زده می‌شه که توش یک کد هگز شیفت داده شده … خوندنش سخته.. پس تایپش می کنیم:


➜ /tmp cat sv.c
typedef void enc_cfg_t;
typedef int enc_cfg2_t;
typedef __int128_t dcf_t;
enc_cfg_t _ctx_iface(dcf_t s, enc_cfg2_t i){
int c = (((s & ((dcf_t)0x1FULL << i * 5)) >> i * 5) + 65);
printf("%c", c); }
enc_cfg2_t main() {
for (int i=0; i<17; i++){
_ctx_iface(0x79481E6BBCC01223 + ((dcf_t)0x1222DC << 64), i);
}
}

و واقعا کمپایل می‌شه:

➜  /tmp gcc sv.c
sv.c:7:5: warning: implicitly declaring library function 'printf' with type
      'int (const char *, ...)' [-Wimplicit-function-declaration]
    printf("%c", c); }
    ^
sv.c:7:5: note: include the header  or explicitly provide a declaration for
      'printf'
1 warning generated.

و اجرا:

➜  /tmp ./a.out
DREAM_ON_ASSHOLES

و سریال با این کد مخفی شده توش، بامزه‌تر می‌شه. این در واقع پیامی است که برنامه نویس قبلی برای این دوستان گذاشته ولی احتمالا کمتر از یک هزارم بینندگان ممکنه روزی ببیننش و بخندن. درست مثل کار اپل که اسم سازندگان اولیه رو «توی» بدنه دستگاه حک کرده بود.

در یک سرچ سریع دیدم که افراد دیگه‌ هم اینو تست کردن و خندیدن (: البته هنوزم بامزه‌ترین موجود این سریال اریک باخمن است و نبودنش بدترین تصمیم سازنده‌ها.

در مورد باگ های اسپکتر و ملت‌داون مطالب دست اول بخونین

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

خلاصه باگ های اسپکتر و ملت داون در این سه شکل قابل طبقه بندی است:

  • شکل یک: دور زدن بررسی محدوده (CVE-2017-5753)
  • شکل دو: تزریق شاخه مقصد (CVE-2017-5715)
  • شکل سه: گول زدن کش کننده دیتا (CVE-2017-5754)

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

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

راستی.. کل ماجرا رو گفتم که بگم مقاله گوگل خواندنی است و قابل درک؛ با حوصله و سرچ های جانبی و حالا که خودمونی شدیم این بحث بامزه رو هم بگم که اول گوگل این باگ رو کشف می کنه و به اینتل گزارش می ده، و مدیر عامل اینتل چیکار می کنه؟ تمام سهامی اینتلی که داشت و می تونست بفروشه رو می فروشه! (:

شِت کد: قبرستان کدهای داغون

البته قبرستان رو که از خودم در آوردم (: این سایت شت کد کلکسیونی است از کدهای بد که خب می تونن هم تمرینی مقدماتی برای کد خوندن باشن هم خنده ای بعد از خوندن کد (: چند تاش واقعا بامزه بودن و حیفم اومد شما هم نبینین.

سه ویدئوی جدید از درک برنامه نویسی: یه جوری باشه بتونیم بگیم کار با API بلدیم

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

با ما باشین که حتی از OAauth هم کمی سر دربیاریم.

درک برنامه نویسی قسمت ۰۲۰ تا ۰۲۳ – ای پی آی ها

در سری درک برنامه نویسی چهار قسمت جدید داریم؛ چهار قسمت مهم! اگر مفهوم ای پی آی براتون مبهم بوده، الان وقتشه با اون ابهام خداحافظی کنین!

در قسمت های بعدی، چند ای پی آل در کامند لاین کال می کنیم و بعد می ریم سراغ برنامه نویسی و در نهایت برنامه ای می نویسیم که توش اگر قیمت بیت کوین از قیمت مورد نظر ما کمتر شد، یک اسمس بهمون بده و خبر بده!

آپدیت: در حین ضبط این ویدئوکست بیت کوین هی گرون و گرونتر شد.. الان بیت کوین ۶۱۰۰ دلاره! «الان یا الان؟»

درک برنامه نویسی، API ها در چهار قسمت؛ در یوتوب: ۱، ۲، ۳، ۴ و در آپارات: : ۱، ۲، ۳، ۴

بیست و دو:

https://www.aparat.com/v/XY3AP

بیست و سه:

https://www.aparat.com/v/7BUTz