Kian Profile picture
26 Mar, 7 tweets, 3 min read
از موضوع‌های همیشگی در گپ و گفت با هم‌کاران در بازار ایران، پایداری برای سرویس‌هاست. مطالبی گِرد این موضوع نوشتم که در چند بخش منتشر خواهم کرد. بخش نخست در پایین آمده. اگر در شرکتتان مساله‌های مشابه دارید، پای مطالب بنویسید یا پیغام دهید برای گفتگوی بیشتر. (۱)

#سیستم_همیشه_بالا
سپاس‌گزارِ عزیزانی که لطف کردند و در بازبینی پیش‌نویس‌ها کمک کردند هستم، به ویژه @mehrdd_seno و @reza_sameei.

بخش آغازین: تصویر کلی و گام نخست. از این‌جا بخوانید: vrgl.ir/UKAsU.

چکیده‌ی کوتاهی در زیر آمده. (همین‌ها در نوشتار اصلی هم هست؛ تا دوباره‌خوانی نکنید.) (۲)
مساله‌ی پایداری سرورها در برابر سرریز بار و مساله‌ی کارایی و نیاز به سخت‌افزار کمتر، دو مساله‌ی برادرند با راه حل‌های دوگانه.

فرض کنید سرویسی داریم برساخته از یک یا چند job (مثال: vrgl.ir/frRFK) هر یک مستقر روی تعدادی نمونه (instance). مشخصا در پی موارد زیر هستیم: (۳)
یک (پایداری): چه تک‌سرور و چه مجموع سرویس، اگر برای مثلا ۱۰۰ درخواست بر ثانیه (QPS) با زمان پاسخ‌گویی ۸۰ms تامین شده، اگر زیر بار ۲۵۰qps قرار گرفت باید همچنان به حدود ۱۰۰qps پاسخ ۸۰ms دهد و ۱۵۰تا را پاسخ ندهد، نه این که تلاش کند به همه‌ی ۲۵۰ تا پاسخ دهد و بخوابد. (۴)
دو (پایداری و کارایی): سرورها باید معماری نرم‌افزاری کارا داشته باشند و بتوانند با حداکثر خروجی کار کنند. مشخصا دو مقوله‌ی «کارایی بیشتر در یک سطح ثابت مصرف/بهره‌گیری از CPU» و «بالا بردن بهره‌گیری» را جداگانه تصور خواهیم کرد (بهره‌گیری=utilization). (۵)
سه (کارایی): سرورها باید بتوانند با بهره‌گیری بالا (حتی بالای ۹۰٪) یا اصطلاحا «داغ» کار کنند در عین پایداری و بدون خدشه به زمان پاسخ‌گویی یا نرخ خطا. مقصود از کارایی، کارایی در منابع پردازشی‌ست، نه حافظه و شبکه و غیره که معمولا ساده‌ترند. (۶)
پایداری به کنار. برای کارایی اصلا بهینه‌سازی بکنیم؟ نخستین پرسش پیش از جَوگیری، تخمین هزینه و فایده است: در یک سو نفر-ساعت و در یک سو سخت‌افزار. در شرکت ما اصلا یک فرم وِب برای این مقایسه وجود دارد. گردآوری یک سیستم تخمین سرانگشتی برای نظام‌مند شدن تلاش‌ها بسیار توصیه می‌شود. (۷)

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Kian

Kian Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @kian1024

27 Mar
این که در timeline توییترتون چی ببینید دو گونه داره و شما حق انتخاب دارید: آخرین توییت‌ها یا توییت‌های برتر/top. به نظر می‌آد که تقریبا همه روی گونه‌ی دوم هستن - شمار دنبال‌شوندگان (followingها) در bioها عموما «صدها»ست. آیا با خطرهای این انتخاب آشنا هستید؟ (۱)

#دالان_پژواک
گونه‌ی دوم (توییت‌های برتر) یعنی کارگردانِ این که من چه‌ها ببینم، مدل‌های یادگیری ماشینی هستند که توییتر ازعلایق من ساخته. در ظاهر اشکالی نداره و خیلی هم خوبه؛ من که وقت ندارم «همه‌ی» توییت‌های ۴۰۰ نفری که دنبال می‌کنم رو بخونم و یکی باید برام انتخاب کنه. ولی بر چه اساسی؟ (۲)
این مدل‌های یادگیری برای چه هدفی بهینه‌سازی شدن؟ افزایش دانش من؟ گسترده شدن دید من؟ نه، برای بیشینه کردن درگیری (engagement) کاربر پای صفحه. روز به روز هم بهتر می‌شن: در هر شرکت از جمله شرکت بنده زیرساخت‌های عریض و طویل تجربه و آزمایش الف/ب (A/B experiment) وجود داره و … (۳)
Read 10 tweets
23 Mar
به بهانه‌ی حادثه‌ی اخیر آروان، کمی از پاسخ به حادثه (incident response) گپ بزنیم. پاسخ به حادثه‌های بزرگ نه تنها از جهت فنی سخت و حساسه---بیشتر حادثه‌های بزرگ جدید و بی‌سابقه‌اند و مهارشون تا چندین شبانه روز می‌کشه---بلکه از جهت مدیریت فرایند و ارتباطات بیرونی هم بَل حساس‌تر. (۱)
نخست، فرایند پاسخ «تیمی» به حادثه نیاز به از پیش فکر شدن و آموزش و مانور آمادگی داره، تا افراد دور خودشون نچرخن یا کارها لابه‌لای ارتباطات گم نشه یا کار تکراری یا (بدتر) کار اشتباهی انجام نشه. نرخ اشتباه در تب و تاب پاسخ به حادثه به شکل تعجب‌آوری بالاست - ادعای آماری نیست ... (۲)
... بلکه صرفا به آن‌چه به تجربه دیدم عرض می‌کنم. کار تیمی بهینه، از اون بدتر. در گوگل، از فرایند پاسخ به حادثه‌ی آتش‌نشان‌ها اقتباس شده با نقش‌ها و وظیفه‌های مشخص. جزییات بیشتر این‌جا: sre.google/workbook/incid…
مسلما به خوندن یک فصل کتاب نیست، نیاز به بحث و تمرین داره. مثلا ... (۳)
Read 7 tweets
16 Mar
دوستی شیرازی داشتم که سر صحبت از دیوان حافظ و لهجه‌ی شیرازی، می‌گفت حافظ را باید «بی‌لهجه‌» خواند و منظورش از «بی‌لهجه»، لهجه‌ی تهرانی بود. افسوس. یعنی نگاه «اصلیش ماییم و فرعیش شما» نه تنها برای طرف غالب نهادینه شده بلکه برای طرف مغلوب هم. (۱)

#فارسی_دوستی
یک: یاد بگیریم بگوییم لهجه‌ی تهرانی، لهجه‌ی شیرازی، لهجه‌ی هراتی، … نگوییم بی‌لهجه و بالهجه. واژه، اندیشه را شکل می‌دهد. بی‌لهجه نداریم. فارسی معیار؟ بی‌خیال! خواهم گفت.

دو: حافظ احتمالا به گوشش هم نخورده بوده که «نَمی‌توان»، «نِمی‌توان» تلفظ شود و «دستُم»، «دستَم». بله ... (۲)
... شیرازیِ سعدی و حافظ، شیرازیِ امروز نیست، ولی تهرانیِ امروز که اصلا هیچ! لهجه‌ی حافظ‌خوانی تنها مثالی برای آغاز سخن بود و موضوع این رشته توییت نیست. همچنین زبان گفتار رایج حافظ و سعدی، چیزی که در نوشتار منظومه‌هایشان می‌بینیم نبوده، ولی آن هم موضوع این رشته نیست. (۳)
Read 9 tweets
10 Mar
این هفته ارائه‌ای در اتکاپذیری بود با عنوان «لامصب رادَسته» (gosh darn convenient) که نکات جالبی داشت، نکات سرراست و بدیهی ولی معمولا مغفول در طراحی‌ها. (۱)

#سیستم_همیشه_بالا
مثلا برای یک سیستم که فلان فایل ورودی/پیکربندی رو می‌گیره (مثلا برای مدیریت ترافیک، برای اِعمال بر درخواست‌ها، برای کنترل سهمیه‌ها، …) اون فایل رو براش کجا بگذاریم که بره برداره؟ چه جایی بهتر و رادَست‌تر از سرویس مدیریت نسخه‌های کُد (مثلا git)؟ هم دم دسته، هم به سادگی ... (۲)
قابل جستجو و مروره، هم بازبینی (code review) داره، هم می‌شه براش تست‌های پیش-از-submit نوشت، هم مدیریت نسخه و تاریخچه داره. از قضا در گوگل زیاد این کارو می‌کنیم (البته git نیست) و از قضا حادثه‌های بزرگی آفریده چون این کار یعنی وابستگی محیط عملیاتی (production) به آن‌چه نباید. (۳)
Read 5 tweets
14 Dec 20
امروز برخی سرویس‌های گوگل برای ۴۵ دقیقه خوابید و رفت در خبرها. بیشتر outageهای بزرگ حاصل تعامل چند اشکال با همه، این بار در file system توزیع‌شده‌ی گوگل (Colossus) برای سرویس‌دهی به سیستم احراز هویت گوگل (GAIA). بهانه‌ایست تا یک رویکرد سازمانی مرتبط و خیلی مهم رو مرور کنیم: (۱)
یک مثال که معمولا در کلاس‌های دوره‌ی معارفه مرور می‌شه اینه که یک بار یک بابایی یک configای در سیستم مدیریت jobها (سیستم ‌Borg که بابای Kubernetes است) push کرد و کلّ گوگل رفت پایین! pagerها شروع کرد به زنگ و SREها این ور اون ور می‌دویدن و این حرفا. (۲)
این بابا، با این pushاش ظاهرا نامرتبط بود و بعید بود کار اون باشه، سریع به همه خبر داد و rollback هم کرد. و قضیه حل شد. این شخص که کل گوگل رو برای چند دقیقه آورده بود پایین، توبیخ شد؟ نه اتفاقا جایزه گرفت (peer bonus که هم‌کار به هم‌کار می‌ده) چون دقیقا کارِ درست رو کرده بود. (۳)
Read 9 tweets
12 Dec 20
#آکادمی_خسته

بخش چهارم: بودجه بر باد

بودجه‌ی استادها، که ازش حقوق دانشجو و خرج سفرها و امکانات و ... رو می‌دن، دادنی نیست بلکه گرفتنی‌ست و باید روزها وقت گذاشت و proposalها نوشت و از فلان شرکت و دولت و شهرداری بودجه گرفت برای پژوهش روی فلان مساله‌ها. خوب عیبیش چیه؟ (۱)
اینه که عمدتا کار به درد بخوری از این همه پول و زحمت درنمی‌آد و همه هم اینو می‌دونن و باز ادامه داره. یعنی بودجه‌ایست که از طرف شرکت/دولت/شهرداری/... باید به اسم «پژوهش» صرف بشه و می‌شه. آورده‌اش؟ چندتا مقاله و البته سفر به نصف دنیا! آورده‌اش برای منبع بودجه؟ آها، اون هیچی. (۲)
مثال: استادِ بنده از چندین شرکت و نهاد معروف بودجه داشت تا براشون پژوهش کنه ولی نامشون یا نیازهاشون برای ما هنگام جهت‌دهی به پژوهش‌هامون اصلا مطرح نبود. تنها در پایان مقاله می‌گفتیم با حمایت اونا بوده.

مثال: گروهی از استادانِ نامی‌ِ دانشگاهِ نامیِ ما، از شهرداری تورنتو ... (۳)
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!