هذا شرح موجز في سلسلة المقالات الحالية حول كيفية تجنب تقديم الخدمات لمختلف الكيانات. أدت محادثة مثيرة في العشاء إلى أفكار قررت أن أكتبها.

قانون أمدحل

في عام 1967 ، جادل أمدال ضد الحوسبة المتوازية. وجادل بأن نمو الإنتاجية محدود لأنه لا يمكن موازاة سوى جزء من المهمة. يختلف حجم الجزء المتبقي من "الجزء المتسلسل" في المهام المختلفة ، ولكنه موجود دائمًا. أصبحت هذه الحجة معروفة باسم قانون أمدال.

إذا قمت بإنشاء رسم بياني لـ "تسريع" المهمة اعتمادًا على عدد المعالجات المتوازية المخصصة لها ، فسترى ما يلي:


هذا رسم بياني مقارب لجزء لا يمكن موازته ("الجزء المتسلسل") ، وبالتالي ، هناك حد أعلى للحد الأقصى للتسارع

من Amdal إلى USL

الشيء المثير للاهتمام في قانون أمدال هو أنه في عام 1969 كان هناك في الواقع عدد قليل جدًا من أنظمة المعالجات المتعددة. تعتمد الصيغة على مبدأ آخر: إذا كان الجزء المتسلسل في المهمة يساوي الصفر ، فهذه ليست مهمة واحدة ، بل عدة مهام.

قام Neil Gunther بتوسيع قانون Amdahl على أساس ملاحظات قياسات الأداء للعديد من الأجهزة ووضع قانون قابلية التوسع العالمي (USL). ويستخدم معلمتين: واحدة لـ "المنافسة" (التي تشبه الجزء المتسلسل) ، والثانية لـ "التضارب" (عدم الاتساق). يرتبط التناقض بالوقت الذي يقضيه في استعادة التناسق ، أي نظرة عامة إلى عالم المعالجات المختلفة.

في أحد وحدات المعالجة المركزية ، تحدث النفقات العامة للتفاوض بسبب التخزين المؤقت. عندما يقوم أحد النواة بتعديل خط ذاكرة التخزين المؤقت ، فإنه يخبر النوى الأخرى باسترداد هذا الخط من ذاكرة التخزين المؤقت. إذا كان الجميع بحاجة إلى نفس الخط ، فإنهم يقضون وقتًا في تحميله من الذاكرة الرئيسية. (هذا وصف مبسط قليلاً ... ولكن بصيغة أكثر دقة ، لا تزال هناك تكلفة للتفاوض).

تتحمل جميع عقد قاعدة البيانات تكاليف التنسيق بسبب مطابقة الخوارزميات وحفظ تسلسل البيانات. يتم دفع العقوبة عند تغيير البيانات (كما في حالة قواعد بيانات المعاملات) أو عند قراءة البيانات في حالة المستودعات المتفق عليها في نهاية المطاف.

تأثير USL

إذا قمت بإنشاء مخطط USL اعتمادًا على عدد المعالجات ، فسيظهر خط أخضر:


يشير الخط الأرجواني إلى أن قانون أمدل قد تنبأ

لاحظ أن الخط الأخضر يصل إلى الذروة ثم ينخفض. هذا يعني أن هناك عددًا معينًا من العقد التي يكون فيها الأداء الأقصى. أضف المزيد من المعالجات - ويتم تقليل الأداء . رأيت هذا في اختبار الإجهاد الحقيقي.

غالبًا ما يرغب الأشخاص في زيادة عدد المعالجات وزيادة الإنتاجية. هناك طريقتان للقيام بذلك:

1. اختزل الجزء المتسلسل
2. تقليل تكاليف الموافقة

USL في الجماعات البشرية؟

دعونا نجرب القياس. إذا كانت "المهمة" الحسابية عبارة عن مشروع ، فيمكننا تمثيل عدد الأشخاص في المشروع كعدد "المعالجات" التي تؤدي العمل.

في هذه الحالة ، الجزء المتسلسل هو عمل لا يمكن القيام به إلا بالتتابع ، خطوة بخطوة. قد يكون هذا موضوعًا لمقال مستقبلي ، لكننا الآن لسنا مهتمين بجوهر الجزء المتسلسل.

يبدو أننا نرى تشابهًا مباشرًا مع تكاليف المصالحة. بغض النظر عن الوقت الذي يقضيه أعضاء الفريق في استعادة نظرة مشتركة للعالم ، فإن تكاليف المحاذاة موجودة.

لخمسة أشخاص في الغرفة ، هذه التكاليف هي الحد الأدنى. رسم لمدة خمس دقائق مع علامة على السبورة مرة واحدة في الأسبوع أو نحو ذلك.

بالنسبة لفريق كبير في عدة مناطق زمنية ، يمكن أن تزيد الغرامة وتتحول إلى طابع رسمي. وثائق وجولات. عروض تقديمية للفريق وما إلى ذلك.

في بعض البنيات ، المصالحة ليست مهمة للغاية. تخيل فريقًا يعمل فيه موظفون في ثلاث قارات ، ولكن كل واحدة تعمل على خدمة واحدة تستخدم البيانات بتنسيق محدد بدقة وتنشئ بيانات بتنسيق محدد بدقة. لا يحتاجون إلى الاتساق فيما يتعلق بالتغييرات في العمليات ، لكنهم بحاجة إلى الاتساق فيما يتعلق بأي تغييرات في التنسيقات.

في بعض الأحيان يمكن للأدوات واللغات تغيير تكاليف المصالحة. إحدى الحجج لصالح الكتابة الثابتة هي أنها تساعد على التفاعل في فريق. من حيث الجوهر ، تعد أنواع التعليمات البرمجية آلية لترجمة التغييرات في نموذج للعالم. في لغة مكتوبة ديناميكيًا ، نحتاج إما إلى أدوات ثانوية (اختبارات الوحدة أو رسائل الدردشة) ، أو نحتاج إلى إنشاء حدود حيث نادرًا ما تعيد بعض الأقسام الاتساق مع الآخرين.

كل هذه الأساليب تهدف إلى تقليل تكاليف التنسيق. تذكر أن التحجيم المفرط يتسبب في انخفاض الإنتاجية. لذلك إذا كانت لديك تكاليف تنسيق عالية وعدد كبير جدًا من الأشخاص ، فإن الفريق ككل يعمل بشكل أبطأ. رأيت فرقًا حيث بدا أنه يمكننا قطع نصف الأشخاص والعمل مرتين بسرعة. تساعد تكاليف USL والمصالحة الآن على فهم سبب حدوث ذلك - إنها أكثر من مجرد إزالة القمامة. إنه يتعلق بتقليل النفقات العامة لتبادل النماذج العقلية.

في حلقة الخوف ، أشرت إلى قواعد التعليمات البرمجية حيث عرف المطورون بالحاجة إلى تغييرات واسعة النطاق ، لكنهم كانوا يخشون إلحاق الضرر عن طريق الخطأ. هذا يعني أن الفريق المتضخم لم يصل بعد إلى إجماع. يبدو من الصعب للغاية التوفيق بعد الخسارة. هذا يعني أنه من المستحيل تجاهل تكاليف التنسيق.

USL والخدمات الصغيرة

في رأيي ، يشرح USL الاهتمام بالخدمات الصغيرة. بتقسيم نظام كبير إلى أجزاء أصغر وأصغر يتم نشرها بشكل مستقل عن بعضها البعض ، يمكنك تقليل الجزء المتسلسل من العمل. في نظام كبير به عدد كبير من المشاركين ، يعتمد الجزء المتسلسل على مقدار الجهد المبذول للتكامل والاختبار والنشر. تتمثل ميزة الخدمات الدقيقة في أنها لا تحتاج إلى عمل تكامل أو اختبار تكامل أو تأخير في النشر المتزامن.

لكن تكلفة المطابقة تعني أنك قد لا تحصل على التسارع المطلوب. ربما يكون التشبيه مشدودًا قليلاً هنا ، ولكن أعتقد أنه من الممكن اعتبار تغييرات الواجهة بين الخدمات الدقيقة تتطلب التوفيق بين الفرق. إذا كان هذا كثيرًا ، فلن تحصل على الفوائد المرجوة من الخدمات الدقيقة.

ماذا تفعل حيال ذلك؟

اقتراحي: انظر إلى الهندسة واللغة والأدوات والفريق المستخدم. فكر في المكان الذي يضيع فيه الوقت للمصالحة عندما يقوم الناس بإجراء تغييرات على النموذج النظامي للعالم.

ابحث عن الفجوات . الفجوات بين الحدود الداخلية للنظام والانقسامات داخل الفريق.

استخدم البيئة لإبلاغ التغييرات حتى تتم عملية المصالحة للجميع ، وليس بشكل فردي.

انظر إلى اتصالات فريقك. كم من الوقت والجهد يستغرق لضمان الاتساق؟ ربما إجراء تغييرات صغيرة وتقليل الحاجة إليها؟