هناك الكثير من المشاركات حول شكل مقابلة الترميز النموذجية في Google. ولكن ، على الرغم من عدم وصفها ومناقشتها على نطاق واسع ، إلا أن هناك في كثير من الأحيان مقابلة تصميم النظام. لمنصب SRE ، إنه NALSD: تصميم نظام كبير غير مجردة. الفرق الرئيسي بين مقابلات SWE و SRE يتكون في هاتين الرسالتين: NA.
ما الفرق؟ كيف تكون مستعدًا لهذه المقابلة؟ لنكن غير مجردة ، واستخدم مثالاً. لتكون أكثر تجريدًا ، دعنا نأخذ شيئًا من العالم المادي ، بحيث لن يُطلب منك نفس الشيء بالضبط في المقابلة الحقيقية (على الأقل ، وليس في مقابلة Google) :)
لذلك ، دعونا تصميم نظام مكتبة عامة. بالنسبة للكتب الورقية ، كما رأيت في كل مكان. تمت كتابة النص بأكمله أدناه دفعة واحدة خلال ساعة واحدة تقريبًا ، لتظهر لك تقريبًا المناطق التي يجب أن تكون قادرًا على تغطيتها / اللمس أثناء المقابلة. يرجى عذر بعض الفوضى ، وهذا ما أعتقد (لذلك أنا).
مقابلة NALSD: تصميم نظام مكتبة عامة.
بادئ ذي بدء ، نجمع خصائص الحمل ، إما عن طريق الأسئلة إلى القائم بإجراء المقابلة ، أو عن طريق تخمين معقول (دون أن ننسى أن نقول ذلك بصوت عالٍ). نظرًا لأن المقابلة تتعلق بنظم قابلة للتطوير ، فإننا نتوقع مدينة بها عدد كبير من السكان (على سبيل المثال ، 1M +). لدينا بعض الخيارات: مبنى ضخم واحد ، أو مكتبات محلية بالإضافة إلى التخزين. أعتقد أن الأخير أكثر منطقية ، لأنه يسمح لنا أيضًا بتوسيع النظام ليشمل مدن متعددة.
الآن دعنا نركز على نظام المدينة الواحدة ؛ يجب أن نكون قادرين على تطبيق نفس التصميم (مع تصحيحات بسيطة) مرة أخرى لتوسيعه إلى مستوى البلد. لذلك ، لدينا مدينة يبلغ عدد سكانها مليون نسمة. لتسهيل العمليات الحسابية ، دعنا ننتقل إلى 1 مليون قارئ ممكن. يريد كل قارئ قراءة شيء ما بشكل مستقل عن كل قارئ آخر ، في لحظات عشوائية في الوقت المناسب. لذلك يمكننا نمذجة تدفق القراء كعملية بواسون. يصعب القيام بالرياضيات بعض الشيء خلال الإطار الزمني للمقابلة ، لذلك دعونا نبسط مرة أخرى ونقول فقط أن حوالي 1٪ من القراء المحتملين سيأخذون كتابًا يوميًا. لذلك افترض 10000 طلب كتاب يوميًا.
لذا ، أصبحت مهمتنا الآن: توفير القدرة على توزيع 10000 كتاب يوميًا (وهذا يعني أيضًا ، أننا بحاجة إلى أن نكون قادرين على استعادة هذه الكتب 10000 في وقت لاحق) في مدينة 1M +. يوضح هذا التقدير أن حل المبنى الفردي لن يكون قائماً (لتوفير الكتب للأشخاص الذين يبلغ عددهم مليون شخص ، يجب أن تكون المكتبة الخاصة بنا قابلة للوصول في غضون فترة زمنية معقولة ، وإلا فإن إرادتهم في حجز كتاب ستنتهي في ازدحام المرور). لذلك ، دعونا نحاول تخمين ما هو الحجم المعقول للمكتبات المحلية التي يجب أن نبنيها. قد يتضمن التقدير الصحيح تمامًا الكثافة السكانية ووقت استرجاع إمكانية الوصول وما إلى ذلك ، ولكن نظرًا لأن هذا لن يؤثر على التصميم العام ، يمكننا مرة أخرى أن نجعل الأمر أكثر بساطة من خلال التفكير في توزيع موحد للوحدات المماثلة. ما زلنا لا نعرف حجم هذه الوحدات ؛ على سبيل المثال ، يمكننا نشر 10000 مكتبة مع كتاب واحد في جميع أنحاء المدينة ، ولكن من الواضح أنها لن تنجح. الذهاب مستوى واحد أقل.
وحدة مكتبة محلية واحدة. لكي تكون مفيدة ، يجب أن يكون غالبية الزوار قادرين على العثور على الكتاب الذي يريدون. هذا يعني أننا بحاجة إلى تتبع الاستخدام والتنبؤ بالطلب على الطلبات الأكثر شيوعًا حتى نكون مستعدين لخدمتهم. بالإضافة إلى ذلك ، ينبغي أن يكون لدينا مجموعة واسعة من العناصر الأقل شعبية. تخميني القاسي هو مكتبة بها أقل من 1000 اسم كتاب ، مع عشرات النسخ للأكثر شعبية والأجزاء المفردة للذيول. يتراوح متوسط الوقت اللازم لقراءة كتاب في مكتبتنا من 3 أيام إلى أسبوعين (بالطبع ، يعتمد الوقت الفعلي على الكتاب نفسه ، وهو ما سيتطلب تحليلًا إضافيًا في حالة حقيقية) ؛ دعنا نقدر أسبوع واحد لكل كتاب. هذا يعني أن الكتاب الذي تم توزيعه سيعود في أسبوع واحد ، لذلك يجب أن نوفر لك أفضل الكتب لمدة أسبوع واحد (بعد أسبوع يتم تجديده من خلال العائدات).
افترض أن متوسط عامل التفجير هو 6 ، مما قد يؤدي بنا إلى سعة تخزينية تصل إلى 6000 كتاب. يعني تخزين أقل نقصا في الأسماء الأكثر شعبية (حسنا ، قد لا تزال الوحدات الصغيرة مفيدة - مثل كشك مول صغير مع "الشفق" ، ولكن دعونا نبقيها خارج تصميمنا الآن).
في حالة مستقرة ، تتشابه العائدات والاقتراضات كل يوم تقريبًا (مع بعض التشتيت) ، لكن يجب علينا أيضًا التخطيط لعوائد الذروة (التي قد تكون أحداث مزامنة خارجية: أيام العطل ، والاتجاهات ، إلخ). الطريقة الصحيحة هي إنشاء وتشغيل نموذج إحصائي. ولكن في الوقت الحالي ، دعنا نحتفظ كمنطقة عازلة. هذا يعني أنه يجب علينا الاحتفاظ بـ 6000 كتاب جاهزة للتوزيع بالإضافة إلى مساحة لعام 2000.
لتلخيص: نحن بحاجة إلى وحدة مكتبة مع 8000 تخزين الكتب. من المتوقع أن تكون عملية إعادة تخزينه مكلفة كل يوم ، لذلك يجب أن نتوقع أن يكون هذا كافيًا لمدة أسبوع أو أسبوعين. أسبوعين ، 6000 كتاب ، مع إمكانات إرجاع ، حوالي 300 كتاب في اليوم. في يوم الافتتاح ، يمكننا ملء التخزين بالكامل (8000 كتاب) لبداية عام 2000 من الكتب في مبيعاتها. 2000 في 3 أيام = 600 كتاب يوميًا ، مع وجود مخزن مؤقت = 800 كتاب يوميًا.
دعونا تقدير الإنتاجية وقيود التخزين لدينا. كتاب واحد حوالي 2 سم خطي من الفضاء ، 8000 كتاب = 160 متر. يمكننا طيها عموديا 4 مرات ، لذلك 40 متر خطي. إذا قمنا بتقسيمها إلى 5 أمتار تقريبًا ، فسنحصل على 8 رفوف مع 4 أرفف ، طول كل منها 5 أمتار. يجب أن يكون أمين مكتبة (أو أمين مكتبة روبوت) قادرًا على العمل مع رفين ؛ سيستغرق استخراج كتاب واحد: 5 ثوانٍ للمشي إلى الرفوف ، و 5 ثوانٍ للاستيلاء على / وضع الكتاب في مكانه ، و 5 ثوانٍ للمشي (إجمالي 15 ثانية). سوف يعطينا 4 من أمناء المكتبات ذروة إنتاجية تصل إلى 15 كتابًا في الدقيقة. وبالتالي ، فإن التعامل مع 900 كتاب في الساعة على الأكثر.
إذا قمنا أيضًا بحساب وقت معالجة الطلب (10 ثوانٍ) ووقت البحث (5 ثوانٍ) ووقت التتبع في النظام (2 ثانية) ، فسنحصل على 400 كتاب / ساعة. لذلك ، يجب أن نكون قادرين على التعامل مع تقديرنا البالغ 800 كتاب يوميًا خلال ساعتين.
دعنا نحسب جوانب أخرى: لكي نتمكن من إعطاء 400 كتاب / ساعة بأربع مكتبات ، نحتاج إلى مساحة كافية لـ 100 شخص ينتظرون في الطابور ، ويجب أن تسمح أبواب المدخل لـ 400 شخص / ساعة بالتجول في كلا الاتجاهين . هذا يعني أن اختناقنا الرئيسي سيكون مساحة الانتظار وبناء الأبواب.
هذا يعني أنه يجب أن نكون قادرين على إيجاد توازن مثالي بين مساحة التخزين ومنطقة الانتظار خلال العمليات الحسابية المناسبة للتصميم الحقيقي.
هذا كل شيء لهذا المستوى ، لقد حان الوقت للمضي قدماً. لدينا تقدير لمطالب شبكة المكتبات العامة مثل 10000 كتاب / يوم. وحدة واحدة هي 800 كتاب / يوم ، لذلك نحن بحاجة إلى 12.5 وحدة. إذا قمنا بتوزيع جغرافي موحد ، فيجب أن يكون كل قارئ في حدود 1-2 وحدات (على حدود المدينة) و 3-4 (داخل المدينة). هذا من شأنه أن يعطي القدرة على تهدئة القمم قليلاً و / أو تغطية النقص في أفضل الكتب.
نعلم أيضًا أنه يمكن إغلاق كل مكتبة في أي وقت من الأوقات (الحرائق ، التفتيش ، مقابض أبواب الثلاجة التي تعيد طلاء إلخ) ، وكلما زاد عدد الوحدات الموجودة لدينا ، كلما زاد احتمال تزامن هذه الأحداث. وبالتالي ، نحن بحاجة إلى وحدة واحدة زائدة عن الحاجة لكل 5-6 وحدات. لذلك ، إجمالًا ، نحتاج إلى 15 وحدة لتلبية متطلبات مدينتنا ، إذا كنا سنحافظ على الإمداد المطلوب داخل كل وحدة.
كما اعتقدنا سابقًا ، نحتاج إلى تجديد وحدة التخزين كل أسبوع أو أسبوعين (في وقت سابق خمننا اثنين) - يجب استبدال حوالي نصف مساحة التخزين ، لمتابعة الاتجاهات وما إلى ذلك. حتى 4000 كتاب من التسليم الجديد و 4000 كتاب تمت إزالته منها. في كل عملية إعادة تخزين ، نحتاج إلى استخراج 4000 كتاب وإدراج 4000 إدخال جديد. من خلال إنتاجنا البالغ 400 كتاب / ساعة ، ستكون مدة إعادة التخزين 10 ساعات مكثفة للغاية. حسنًا ، يبدو أنه لا يزال على ما يرام ، خاصة وأن العمليات السائبة عادة ما تكون أرخص ؛ ولكن على أي حال - يجب أن نضع في اعتبارنا أن عملية إعادة التخزين أكثر تكلفة بـ 5 مرات من مجرد تقديمها.
يبلغ متوسط الكتاب (2 سم * 20 سم * 30 سم) 1.5 ليتر من الحجم ، أي 4000 كتاب = 6 أمتار مكعبة. يجب أن يصلح هذا لمركبة بضائع خفيفة متوسطة واحدة. 1 متر مكعب من أوزان الورق 600 كجم ، 6 متر ^ 3 = 3.6 طن. يمكن لمركبة الشحن الخفيفة المتوسطة التعامل مع حوالي 1.5 طن ، لذلك نحن بحاجة إلى 3 منها. زائد واحد للتكرار. لدينا 15 وحدة مكتبة يتم تحديثها مرة واحدة كل أسبوعين ، مما يعني أن هذا سيكون ضيقًا في الموعد المحدد ، لذلك نحن بحاجة إلى سيارة أخرى.
وما زلنا لم نفكر كيف ومن أين ستنقل هذه السيارات الكتب ، لذلك سيحتاج تصميمنا أيضًا إلى مخازن الموردين ونقاط جمع القمامة للكتب التي لم تعد شعبية ...
انتهى الوقت. إذن ، ما هو خاص في سؤال NALSD؟ قابلية التوسع من أي تصميم نظام كبير. ولكن في مقابلة NALSD ، يجب أن يكون المرء
محددًا .
يمكنك أن ترى أعلاه الكثير من التخمينات والافتراضات ، لكن كل الحسابات كانت تستند إلى أرقام تم إعدادها مسبقًا. لقد حاولت أيضًا شرح كيفية الوصول إلى الرقم الصحيح ، لكن من السهل أن تتعب / تشعر بالملل وتبدأ في فعل ذلك. أيضًا ، من السهل الالتزام ببعض الأرقام من ذاكرتك ، دون تقديم توضيح جيد لأسباب ذلك ... ولكن نظرًا لأن التصميم محدد للغاية ، إذا ارتكبت خطأً لأي رقم ، فيمكنك تغيير الرقم وإعادة حساب الباقي فقط.
ما زلت أتذكر كيف تعاملت خلال مقابلة NALSD مع IOPS من محرك أقراص ثابت واحد يساوي 600 ، لمجرد أنني كنت قد عملت مؤخرًا على تحسين بعض صفيف الغارات ، حيث كان لدى المجموعة بأكملها 600 IOPS ... فوجئت الجهة المقابلة قليلاً: 600 IOPS لكل قيادة؟ : دخلال المقابلة ، يمكن تصحيح أي من افتراضاتك وتخميناتك من قِبل القائم بإجراء المقابلة. أيضًا ، يمكن أن يضيف القائم بإجراء المقابلة بعض القيود الإضافية (التي نسيتها أو لم تكن تعرفها أو لم تسأل عنها أو لمجرد ضبط المهمة لأنهم يرغبون أو يعتقدون أن هذه طريقة أفضل للمتابعة). نظرًا لأنك تعمل فقط على أرقام محددة ، فإن ذلك سيتطلب فقط تحديثات صغيرة للأرقام تتبع المعادلات المقدمة بالفعل.
إذا كان تصحيح الافتراض يتطلب إعادة تصميم كاملة للنظام ، فهذا إما خطأ في التصميم أو تصحيح غير صحيح ، أو يتجاوز الافتراض الجديد قابلية تطبيق التصميم (وهو ليس نادرًا جدًا في الحياة الحقيقية). من المهم ألا تفوت هذه الحقيقة: يجب عليك التحقق من صحة الأرقام التي تحصل عليها ، للتأكد من أنها واقعية ، أثناء التصميم وبعد أي تصحيح.
بوصفنا SREs ، علينا أن نفكر في قابلية تطوير الأنظمة الحقيقية ضمن قيود قيود الأجهزة الحقيقية. قد يكون هناك
خوارزمية جميلة تتبادل التعقيد الزمني الهائل إلى حد ما من ذاكرة الوصول العشوائي ... ولكن لا يزال ، 1PiB من ذاكرة الوصول العشوائي لكل وحدة المعالجة المركزية ليست شيئًا يمكننا بناءه اليوم. لذلك إذا كان لدينا 1 PiB من ذاكرة الوصول العشوائي ، فلدينا أيضًا حوالي 10 كيلو من وحدات المعالجة المركزية. أو 20 ك. أو حتى 30K. هذا يعني أنه يجب علينا التركيز على الأمثل (المحلي) الحقيقي ، الذي يمكن الوصول إليه اليوم في الواقع ، وليس الأمثل العالمي الذي يمكن الوصول إليه في ظروف مثالية.
يجب ألا تتذكر الأرقام الدقيقة ، ولكن يجب أن تكون قادرًا على تطبيق قواعد الإبهام للحصول على أوامر من حيث الحجم. مثل ، IOPSes: الأقراص الصلبة حوالي 100s ، SSD حوالي 100s الآلاف. لكن هذه الآلاف من المائة تأتي مع فرق السعر بين الأقراص الصلبة إلى SSD مثل 1: 3 أو 1: 4. إنها تتجاهل أيضًا كل شيء من حوله: مساحة الحامل ، شفرات لمحركات الأقراص ، ومنافذ الشبكة وأشياء أخرى ، لم تعد رخيصة بمجرد العمل على الأجهزة التجريبية والقصيرة.
احصل الآن على مقعد مريح ، واسترخ ، وحاول تصميم نظام نمو وتوصيل بيض الدجاج الطازج عند الاشتراك.