طراحی مصاحبه‌ی «طراحی سیستم»

مصاحبه‌ی طراحی سیستم، برای سنجش دایره‌ی دید کاندیداست. در نوشتار پیش درباره‌ی مدیریت بار، بخشی به عنوان پرسش مصاحبه‌ی طراحی سیستم رها شد و همان نمونه‌ی خوبی‌ست برای آشنایی بیشتر با این نوع مصاحبه. درباره‌ی تصویر کلی یک مصاحبه‌ی خوب، پیش‌تر نوشته بودم: این مطلب. نوشتار پیشِ رو، درباره‌ی بخش طراحی سیستم آن است. هدف شما در مصاحبه‌ی طراحی سیستم، در کنار سنجش دانش فنی، سنجش دید همه‌جانبه و ذهن تحلیل‌گر و کمّی‌نگر است، مثلا آیا طرف به آن‌چه پیش‌فرض گرفته آگاه است؟ آیا بده‌بستان/tradeoff ها را می‌بیند یا عجله برای شیرجه به عمق دارد؟ آیا سادگی و مقیاس‌پذیری و اتکاپذیری سرلوحه‌ی کارش هست؟ دنبال چنین چیزهایی باشید.کاندیدا برای چه نقشی و چه نوع کارهایی مورد نظر است؟ اصلا مصاحبه‌ی طراحی سیستم برای مهندس تازه‌کار و متوسط نیاز هست یا تنها برای ارشد و رهبر فنی به بالا؟ ما تنها برای دومی می‌کنیم. همین سطح «تازه‌کار» و «ارشد» هم نادقیق است بلکه نوع کار مهم است. اطلاعات بیشتر درباره‌ی نردبان سطح‌بندی: این مطلب.در گوگل، مخزنی غنی از نمونه پرسش برای مصاحبه‌های برنامه‌نویسی و الگوریتمی هست، ولی برای طراحی سیستم نه، چون مصاحبه‌کننده باید دانش عمیق و ملموس از موضوع مصاحبه داشته باشد و خاک صحنه‌اش رو خورده باشد. مصاحبه کنندگان (همیشه ارشد به بالا) تشویق می‌شوند از مساله‌های روزمره‌شان پرسش درآورند.این مشخصا با تصوری که برخی از مصاحبه‌ی طراحی سیستم در ذهن دارند فاصله دارد. نه انتظاری از کاندیدا برای دانستن نام تکنولوژی‌ها وجود دارد و نه مساله‌های بی‌دروپیکر با پاسخ‌های قالبی مانند «یک storage این‌جا می‌گذاریم و یک log service آن‌جا» و نه ریز شدن الکی بر جنبه‌های مدیر محصولی. اگر در اینترنت بگردید، مطلب گِرد نمونه‌هایی از جنس «توییتر را طراحی کنید» و «یوتیوب را طراحی کنید» فراوان است ولی گفتگو روی چنین پرسش‌های زیادی سطح بالایی، داده‌ی خوبی درباره‌ی کاندیدا نمی‌دهد. مشخصا در آموزش‌ها گفته می‌شود که چنین پرسش‌هایی نپرسید و مساله‌ی مشخص‌تر بپرسید. نمونه‌ای که در پایین می‌بینیم اتفاقا در نیمه‌ی سطح پایین‌تر مصاحبه‌های طراحی سیستمی‌ست.این از معرفی. حالا برگردیم سراغ نمونه پرسشی که در آغاز اشاره شد: سرویس‌هایی داریم هر یک برساخته از درختی از jobها، هر یک برساخته از تعدادی سرور (نمونه/instance). در پاسخ به درخواست‌های کاربران به سرویس، jobها یک‌دیگر را فراخوانی می‌کنند تا پاسخ آماده و پس فرستاده شود. یک سیستم توزیع بار برای ارتباط بین job الف و job ب طراحی کنید.نخست، در نوشتار پیش (که این پرسش مصاحبه از آن‌جا آمد) مشخصا گفته شد که هدف، همگن کردن بهره‌گیری (utilization) سرورهای مقصد است و نه لزوما همگن کردن «بار» به شکل درخواست بر ثانیه/qps، ولی فرض کنید این نکته را نگفتیم - بهتر، سوال مصاحبه باید اصغر فرهادی وار در نیمه رها شود. همین مساله باید یکی از نخستین پرسش‌های کاندیدا باشد: توزیع بار برای چه هدفی؟ بار یکسان روی سرورهای مقصد / بهره‌گیری یکسان / کمینه کردن بیشینه‌ی تاخیر / غیر؟ سوال‌های خوب دیگر از سوی کاندیدا: آیا سرورهای ب همسانند، مثلا منابع همسان (مثلا تعداد هسته‌ی CPU برای هر نمونه) / میزبانی شده روی سخت‌افزار همسان / با فاصله‌ی شبکه‌ای یکسان از الف / (کاندیدای خوب احتمالا می‌پرسد) با jobهای همسایه‌ی همسان روی ماشین‌های میزبان؟پس از کمی گفتگو درباره‌ی فضای مساله، فرض کنید به این مورد هم‌گرا شدیم که سرورها شبیه‌اند ولی دقیقا همسان نیستند و هدف ما یکسان کردن بهره‌گیری میان سرورهای ب و در نتیجه بیشینه کردن مجموع ظرفیت job است. (برای دوستانی که به پرسشِ نوشتار پیش فکر کردند یا پاسخ دادند: الان رسیدیم به آن نقطه.)مساله همچنان باز است و قرار است کاندیدا پیش از طراحی پاسخ، جزییات بیشتری گردآوری کند (اتفاقی که در تک و توک پاسخ‌هایی که به سوال پیش بنده آمد، نیفتاد). مثلا بپرسد جنس بار چیست: حول و حوش ۱۰ درخواست بر ثانیه روی هر سرور یا ۱۰هزار / حول و حوش زمان پاسخ ۱۰ میلی‌ثانیه است یا یک دقیقه؟ آیا بار ثابت است یا نوسان دارد؟ آیا درخواست‌ها کم و بیش همگن‌اند یا برخی ۱۰ برابر برخی کار می‌برند؟ تاخیر چه اندازه مهم است؟ شما هم به جای پاسخ عددی، بپرسید چرا می‌پرسی و چه فرقی در طراحی‌ات می‌کند، و انتظار اشاره به بده‌بستان/tradeoffها داشته باشید.کاندیدای خوب، از چسبندگی (affinity) بین درخواست‌ها و سرورها هم خواهد پرسید - آیا هر درخواستی می‌تواند روی هر سرور ب بیفتد یا مثلا ب یک مخزن key-value است و چسبندگی مهم؟رد و بدل شدن این پرسش‌ها خیلی مهم است ولی بخش اصلی مصاحبه این نیست. ۵ تا ۱۰ دقیقه گفتگو روی این بخش کافی‌ست. همچنین دقت کنید کاندیدا قرار نیست «همه‌ی» این‌ها را بپرسد و در جهت مورد انتظار شما و دقیقا تا عمق مورد انتظار شما برود، بلکه اشکالی ندارد اشتباه برود و شما با پرسش‌های هوشمند کمی راهنمایی‌اش کنید.در ادامه، فرض کنید هم‌گرا شدیم به این که قرار است توزیع در سوی فراخواننده/client (و نه توسط یک موجودیت جدا) و به شکل غیرمتمرکز (و بدون یک موجودیت جداگانه‌ی هماهنگ‌کننده) و خودمختار انجام شود - ساده، سریع، مقیاس پذیر و بدون تک‌نقطه‌ی شکست. کاندیدای خوب، خودش با مقایسه به این‌جا می‌رسد. یعنی هر سرور از الف با همه‌ی سرورهای ب ارتباط دارد و درخواست بعدی را به آن سروری از ب می‌فرستد که کمترین بهره‌گیری کنونی را دارد. وارد شدن به جزییات داده‌ساختار لازم (این‌جا: heap) چندان مهم نیست چون هم بدیهی‌ست و هم مصاحبه‌ی طراحی سیستم مصاحبه‌ی الگوریتمی نیست. نوشتن یک API مختصر، مستحب است.کاندیدای خوب در این‌جا خواهد دید که یک چالش اصلی، اطلاع سرورهای الف از بهره‌گیری لحظه‌ای سرورهای ب خواهد بود. یعنی فرض کنید به شکلی (چه شکلی؟ بررسی بد‌بستان‌ها ... ولی بگذریم) فهمیدیم که کدام سرور ب کمترین بهره‌گیری لحظه‌ای را دارد و درخواست کنونی را به آن فرستادیم. خوب بعد؟ تا وقتی بازخورد آن سرور ب برنگشته که ببینیم دیگر دارای کمترین بهره‌گیری نیست، به فرستادن درخواست‌ها به ب ادامه می‌دهیم؟ طبیعتا نه. پس چه؟ احتمالا سخن از ساز و کاری برای تخمین کاری که به آن سرور ب دادیم (و هنوز بازخوردش را نگرفتیم) خواهد شد. کاندیدا باید دریابد که این تخمین باید جداگانه به ازای هر سرور ب دنبال شود - وگرنه اصلا چه نیازی به توزیع بار بر اساس بهره‌گیری و این دردسرها بود و همان توزیع بر اساس qps کافی بود.رفتن تا این جزییات (اواخر مصاحبه) برای تشخیص کاندیدای خوب از کاندیدایی که تنها در سطح بالا حرف می‌زند و تا به حال دست به آچار نبوده، کمک می‌کند. اگر این فرد هم‌کار شما شد، گفتگوهای طراحی سیستمی که در کار با او خواهید داشت از این جنسند، نه از جنس «توییتر را طراحی کنید».کاندیدای خوب احتمالا راه‌های جای‌گزین/alternative هم پیشنهاد خواهد داد. مثلا انتخاب سرور ب نه بر اساس کمترین بهره‌گیری بلکه بر اساس یک عدد تصادفی که وزن هر سرور در این انتخاب برابر با ظرفیت خالی‌اش است، و تفاوت این دو انتخاب را تحلیل خواهد کرد (واکنش سریع‌تر/پرنوسان‌تر در برابر کندتر/پایدارتر). اگر نکرد شما کمکش کنید.کاندیدای داری دیدِ باز، همچنین به این اشاره خواهد کرد که اگر «خطا» گرفتیم چه کنیم (مثلا: سیگنالی‌ست از این که «گند زدیم» و در نتیجه عقب‌نشینی شدید)؛ اگر یک کانال بسته شد چه کنیم؛ و الی آخر.می‌توان این گفتگو را برای ساعت‌ها ادامه داد، چه رو به پایین و جزییات و چه رو به بالا و انتزاع.مصاحبه‌ی طراحی سیستم یعنی تخته سفید و دیاگرام، نه یک متن خالی. ولی امیدوارم پراکنده‌ی بالا، فضا و هدف را منتقل کرده باشد.