تم إعداد ترجمة المقال خصيصًا لطلاب الدورة التدريبية "ممارسات وأدوات DevOps" .
تتناول هذه المقالة العلاقة بين بنية التعليمات البرمجية وهيكل المؤسسة في تطوير البرامج. أناقش سبب عدم قدرة البرامج والفرق على التوسع بسهولة ، والدروس التي يمكن أن نراها في الطبيعة والإنترنت ، وأظهر كيف يمكننا تقليل اتصال البرامج والفرق للتغلب على مشاكل التوسع.
تستند هذه المقالة إلى خبرتي التي تبلغ 20 عامًا في إنشاء أنظمة برمجية كبيرة وانطباعًا عن كتاب
"تسريع: علم البرمجيات النحيلة و DevOps: بناء وتوسيع منظمات التكنولوجيا عالية الأداء" (نيكول فورسغرن وجيز هامبل وجين كيم) ، دليل البحوث لدعم معظم مطالباتي هنا. ينصح بشدة هذا الكتاب للقراءة.
البرامج والأوامر لا مقياس
غالبًا ما يكون الإصدار الأول ، الذي كتبه شخص أو شخصان ، بسيطًا بشكل مدهش. قد يكون لها وظائف محدودة ، لكنه مكتوب بسرعة ويلبي متطلبات العملاء. التفاعل مع العميل في هذه المرحلة ممتاز ، لأن العميل عادة ما يكون على اتصال مباشر مع المطورين. يتم إصلاح أي أخطاء بسرعة ، ويمكن إضافة ميزات جديدة دون ألم. بعد فترة من الوقت ، تباطأ وتيرة. الإصدار 2.0 يستغرق وقتا أطول قليلا مما كان متوقعا. من الصعب إصلاح الأخطاء ، ويتم توفير ميزات جديدة ، فهي ليست بهذه البساطة. الجواب الطبيعي لهذا هو إضافة مطورين جدد للفريق. على الرغم من أنه يبدو أن كل موظف إضافي يضاف إلى الفريق يقلل الإنتاجية. هناك شعور بأنه مع تنامي تعقيد البرنامج ، فإنه ضمور. في الحالات القصوى ، قد تجد المنظمات أنها تستخدم برامج بدعم مكلف للغاية يكاد يكون من المستحيل إجراء تغييرات. المشكلة هي أنك لست بحاجة إلى ارتكاب أي "أخطاء" لتحقيق ذلك. من الشائع جدًا أن يقال إن هذه خاصية "طبيعية" للبرامج.
لماذا يحدث هذا؟ هناك سببان: تلك المتعلقة بالكود والفريق. كل من الكود والأوامر لا يتم قياسهما جيدًا.
مع نمو قاعدة الشفرة ، يصبح من الصعب بشكل متزايد على شخص واحد فهمها. هناك حدود المعرفية الثابتة للشخص. وعلى الرغم من ذلك ، يمكن لشخص واحد أن يضع في الاعتبار تفاصيل النظام الصغير ، ولكن فقط حتى يصبح أكثر من نطاقه المعرفي. بمجرد أن ينمو الفريق إلى خمسة أشخاص أو أكثر ، يصبح من المستحيل تقريبًا أن يكون شخص واحد على دراية بكيفية عمل جميع أجزاء النظام. وعندما لا يفهم أحد النظام برمته ، يظهر الخوف. في نظام كبير ، مترابط بإحكام ، من الصعب للغاية فهم تأثير أي تغييرات مهمة ، لأن النتيجة غير مترجمة. لتقليل تأثير التغييرات ، يبدأ المطورون في استخدام الحلول البديلة والازدواجية بدلاً من تحديد الميزات الشائعة ، وإنشاء التجريدات والتعميمات. هذا يزيد من تعقيد النظام ، وتعزيز هذه الاتجاهات السلبية. لم يعد المطورون يشعرون بالمسؤولية عن الكود الذي لا يفهمونه ويرفضون القيام بإعادة بيع المباني. الدين الفني ينمو. كما أنه يجعل العمل غير سار وغير مرضٍ ويحفز "هجرة المواهب" عندما يغادر أفضل المطورين الذين يمكنهم العثور على عمل بسهولة في مكان آخر.
الفرق أيضا لا مقياس. مع نمو الفرق ، يصبح التواصل أكثر تعقيدًا. صيغة بسيطة تدخل في الاعتبار:
c = n(n-1)/2(حيث n هو عدد الأشخاص ، و c هو عدد الاتصالات المحتملة بين أعضاء الفريق)مع نمو فريقها ، تزداد احتياجاتها من التواصل والتنسيق بشكل كبير. إذا تم تجاوز فريق معين ، فمن الصعب للغاية أن يظل فريق واحد هيكلاً مكملاً ، والميل الاجتماعي الإنساني الطبيعي للتقسيم إلى مجموعات أصغر سيؤدي إلى تشكيل مجموعات فرعية غير رسمية ، حتى لو لم تشارك الإدارة فيه. يصبح التواصل مع الزملاء أكثر صعوبة وسيتم استبداله بشكل طبيعي بقادة جدد واتصالات من أعلى إلى أسفل. يتم تحويل أعضاء الفريق من أقرانهم في النظام إلى عمال إنتاج منتظمين. الدافع يعاني ، وليس هناك شعور بالملكية بسبب
تأثير نشر المسؤولية .
تتدخل الإدارة غالبًا في هذه المرحلة وتقترب رسميًا من إنشاء فرق وهياكل إدارية جديدة. ولكن ، لا يهم بشكل رسمي أو غير رسمي ، من الصعب على المنظمات الكبيرة الحفاظ على الدافع والاهتمام.
عادةً ما يلقي المطورون الذين يفتقرون إلى الخبرة والإدارة السيئة باللوم على هذه الأمراض. لكن هذا غير عادل. تعد مشكلات القياس خاصية "طبيعية" للبرامج المتطورة والمتطورة. هذا ما يحدث دائمًا إذا لم تجد المشكلة في مرحلة مبكرة ، ولا تفهم نقطة الانحراف ، ولا تبذل أي جهد لحل المشكلة. يتم إنشاء فرق تطوير البرمجيات باستمرار ، ويتزايد حجم البرامج في العالم باستمرار ، ومعظم البرامج صغيرة نسبيًا. لذلك ، في كثير من الأحيان ، يتم إنشاء منتج ناجح ومتطور من قبل فريق ليس لديه خبرة في التطوير على نطاق واسع. ومن غير الواقعي توقع أن يتعرف المطورون على نقطة انعطاف ويفهموا ما يجب عليهم فعله عندما تبدأ مشاكل الحجم في الظهور.
دروس تحجيم الطبيعة
لقد قرأت مؤخرًا كتاب
جيفري ويست الممتاز
"Scale" . يتحدث عن الرياضيات في النظم البيولوجية والاجتماعية والاقتصادية. أطروحته هي أن جميع الأنظمة المعقدة الكبيرة تطيع قوانين الحجم الأساسية. هذه قراءة رائعة وأنا أوصي بها بشدة. في هذا المقال ، أود أن أركز على وجهة نظره القائلة بأن العديد من النظم البيولوجية والاجتماعية يتقاسّم بشكل مدهش. انظر إلى جسم ثديي. جميع الثدييات لها نفس أنواع الخلايا ، وهيكل العظام ، والجهاز العصبي والدورة الدموية. ومع ذلك ، فإن الفرق في الحجم بين الماوس والحوت الأزرق هو حوالي 10 ^ 7. كيف تستخدم الطبيعة نفس المواد والبنية للكائنات ذات الأحجام المختلفة؟ يبدو أن الجواب هو أن التطور قد اكتشف هياكل كسورية متفرعة. انظر إلى الشجرة. كل جزء منه يشبه شجرة صغيرة. وينطبق الشيء نفسه على الدورة الدموية والجهاز العصبي في الثدييات ، فهي شبكات كسورية متفرعة حيث يبدو جزء صغير من رئتيك أو الأوعية الدموية وكأنه نسخة أصغر من الكل.
هل يمكننا أخذ هذه الأفكار من الطبيعة وتطبيقها على البرامج؟ أعتقد أننا يمكن أن نتعلم الدروس المهمة. إذا تمكنا من بناء أنظمة كبيرة تتكون من أجزاء صغيرة تبدو وكأنها أنظمة كاملة ، فسيكون من الممكن احتواء الأمراض التي تؤثر على معظم البرامج أثناء نموها وتطورها.
هل هناك أنظمة برمجية نجحت في زيادة عدد الطلبات الضخمة؟ الجواب واضح - الإنترنت ، وهو نظام برمجي عالمي به ملايين العقد. الشبكات الفرعية تبدو بالفعل وتعمل مثل الإصدارات الأصغر من الإنترنت بالكامل.
علامات البرمجيات المزدوجة
إن القدرة على عزل المكونات المنفصلة والمربوطة بشكل فضفاض في نظام كبير هي الطريقة الرئيسية للتحجيم الناجح. شبكة الإنترنت ، في الواقع ، هي مثال على العمارة المزدوجة. هذا يعني أن كل عقدة أو خدمة أو تطبيق على الشبكة له الخصائص التالية:
- يستخدم بروتوكول الاتصال المشترك.
- يتم نقل البيانات باستخدام عقد واضح مع العقد الأخرى.
- التواصل لا يتطلب معرفة تقنيات التنفيذ المحددة.
- الإصدار والنشر مستقلة.
شبكة الإنترنت قابلة للتطوير لأنها شبكة من العقد تتواصل عبر مجموعة من البروتوكولات المحددة جيدًا. تتفاعل العقد فقط من خلال البروتوكولات ، والتي لا ينبغي أن تكون تفاصيل تنفيذها معروفة للعقد المتفاعلة. لا يتم نشر الإنترنت العالمي كنظام واحد. كل عقدة لها نسختها الخاصة وإجراءات النشر فيها. تظهر العقد الفردية وتختفي بشكل مستقل عن بعضها البعض. التقديم إلى بروتوكولات الإنترنت هو الشيء الوحيد المهم حقًا للنظام بأكمله. من قام بإنشاء كل موقع ، عندما تم إنشاؤه أو حذفه ، وما هو إصداره ، وما هي التقنيات والأنظمة الأساسية التي يستخدمها ، كل هذا لا علاقة له بالإنترنت ككل. هذا هو ما نعنيه بالبرنامج المترابط فضفاضة.
علامات منظمة مقرونة بشكل فضفاض
يمكننا توسيع الفرق باتباع نفس المبادئ:
- يجب أن يبدو كل فريق فرعي بمثابة مؤسسة صغيرة لتطوير البرمجيات.
- يجب ألا تتجاوز العمليات الداخلية وتواصل الفريق مع الفريق.
- لا ينبغي مناقشة التقنيات والعمليات المستخدمة لتنفيذ البرنامج خارج الفريق.
- يجب أن تتواصل الفرق مع بعضها البعض فقط فيما يتعلق بالقضايا الخارجية: البروتوكولات المشتركة والوظائف ومستويات الخدمة والموارد.
فرق التطوير الصغيرة أكثر فاعلية من الفرق الكبيرة ، لذلك تحتاج إلى تقسيم الفرق الكبيرة إلى مجموعات أصغر. الدروس المستفادة من الطبيعة والإنترنت هي أن المجموعات الفرعية يجب أن تبدو كمنظمات تطوير برامج صغيرة واحدة. كم هي صغيرة؟ من الناحية المثالية ، من واحد إلى خمسة أشخاص.
الشيء المهم هو أن كل فريق يبدو وكأنه منظمة صغيرة مستقلة لتطوير البرمجيات. طرق أخرى لتنظيم فرق أقل فعالية. غالبًا ما يكون هناك إغراء لتقسيم فريق كبير إلى وظائف. لذلك ، لدينا فريق من المهندسين المعماريين وفريق تطوير وفريق DBA وفريق اختبار وفريق نشر وفريق دعم ، لكن هذا لا يحل أيًا من مشكلات التوسع التي تحدثنا عنها أعلاه. يجب أن تشارك جميع الفرق في تطوير ميزة وغالبًا ما تكون متكررة إذا كنت تريد تجنب إدارة المشروع بأسلوب الشلال.
أصبحت حواجز الاتصال بين هذه الفرق الوظيفية عقبة رئيسية أمام التسليم الفعال وفي الوقت المناسب. ترتبط الفرق بإحكام لأنها تحتاج إلى مشاركة التفاصيل الداخلية المهمة للعمل معًا. بالإضافة إلى ذلك ، لا تتزامن اهتمامات الفرق المختلفة: عادة ما يحصل المطورون على جائزة عن الميزات الجديدة واختبار الجودة ودعم الاستقرار. هذه المصالح المختلفة يمكن أن تؤدي إلى صراع ونتائج سيئة. لماذا يجب على المطورين القلق بشأن السجلات إذا لم يقرأوها أبدًا؟ لماذا يجب أن يهتم المختبرون بالولادة إذا كانوا مسؤولين عن الجودة؟
بدلاً من ذلك ، يجب أن ننظم فرقًا للخدمات المقترنة بشكل فضفاض والتي تدعم وظائف العمل ، أو لمجموعة الوظائف المنطقية. يجب على كل أمر فرعي تصميم البرامج الخاصة به وترميزها واختبارها ونشرها وصيانتها. على الأرجح ، سيكون أعضاء مثل هذا الفريق متخصصين يتمتعون بسمعة واسعة ، وليسوا اختصاصيين ضيقين ، لأنه في فريق صغير سيكون من الضروري فصل هذه الأدوار. ينبغي أن يركزوا على أقصى قدر ممكن من التشغيل الآلي للعمليات: الاختبار الآلي ، النشر ، المراقبة. يجب أن تختار الفرق الأدوات الخاصة بها وأن تصمم بنية أنظمتها. على الرغم من أنه يجب تحديد البروتوكولات المستخدمة لتفاعل الخدمات على مستوى المؤسسة ، إلا أنه يجب تفويض اختيار الأدوات المستخدمة لتنفيذها إلى الفرق. وهذا يناسب بشكل جيد مع نموذج DevOps.
مستوى الاستقلالية التي يمتلكها الفريق هو انعكاس لمستوى ترابط المنظمة بأكملها. من الناحية المثالية ، يجب أن تهتم المؤسسة بوظيفة البرنامج ، وفي نهاية المطاف ، قيمة الأعمال التي يوفرها الفريق ، وكذلك تكلفة موارد الفريق.
في هذه الحالة ، يلعب مهندس البرمجيات دورًا مهمًا. لا ينبغي أن تركز على الأدوات والتقنيات المحددة التي تستخدمها الفرق أو تتداخل مع تفاصيل البنية الداخلية للخدمات. بدلاً من ذلك ، يجب أن تركز على البروتوكولات والتفاعلات بين الخدمات المختلفة وسلامة النظام ككل.
قانون كونوي المقلوب: يجب أن يكون الهيكل التنظيمي نموذجًا للهندسة المعمارية المستهدفة
كيف يتناسب ضعف تماسك البرامج وضعف تماسك الفريق معًا؟ ينص
قانون كونواي على:
"تقتصر المنظمات التي تصمم الأنظمة على تصميم ينسخ بنية الاتصالات لهذه المؤسسة."
يعتمد ذلك على الملاحظة التي مفادها أن بنية نظام برمجي ستعكس بنية المؤسسة التي تنشئها. يمكننا "اختراق" قانون كونواي عن طريق قلبه. تنظيم فرقنا لتعكس الهندسة المعمارية المطلوبة لدينا. مع وضع ذلك في الاعتبار ، يجب علينا محاذاة الفرق المقترنة بشكل فضفاض مع مكونات البرامج المقترنة بشكل فضفاض. ولكن هل يجب أن تكون علاقة فردية؟ أعتقد ، من الناحية المثالية ، نعم. على الرغم من أنه يبدو أنه من الجيد أن يعمل فريق صغير على العديد من الخدمات المقترنة بشكل فضفاض. أود أن أقول إن نقطة انعطاف التدريج أكبر بالنسبة للفرق منها للبرامج ، لذلك يبدو هذا النمط من التنظيم مقبولاً. من المهم أن تظل مكونات البرنامج منفصلة ، مع إصداراتها ونشرها ، حتى لو تم تطوير بعضها بواسطة فريق واحد. نود أن نكون قادرين على تقسيم الفريق إذا كان حجمه أكبر من اللازم ، مع نقل الخدمات المتقدمة إلى فرق مختلفة. لكن لا يمكننا القيام بذلك إذا كانت الخدمات مقترنة بإحكام أو تشترك في عملية أو إصدار أو نشر.
يجب علينا تجنب عمل العديد من الفرق على نفس المكونات. هذا هو نمط مضاد. وبشكل ما ، أسوأ من عمل فريق كبير ذو قاعدة كود كبيرة واحدة ، لأن حواجز الاتصال بين الفرق تؤدي إلى شعور أقوى بنقص الملكية والسيطرة.
يتم التقليل من التفاعل بين الفرق المزدوجة المقترنة التي تخلق برامج متقاربة فضفاضة. خذ مثال الإنترنت مرة أخرى. غالبًا ما يمكنك استخدام واجهة برمجة التطبيقات التي توفرها شركة أخرى دون أي اتصال مباشر معها (إذا كانت العملية بسيطة وهناك وثائق). عندما تتفاعل الفرق ، لا ينبغي مناقشة عمليات التطوير والتنفيذ الداخلية للفريق. بدلاً من ذلك ، يجب مناقشة الوظائف ومستويات الخدمة والموارد.
يجب أن تكون إدارة الفرق المزدوجة المقترنة التي تقوم بإنشاء برامج متداخلة فضفاضة أسهل من البدائل. يجب أن تركز المؤسسة الكبيرة على تزويد الفرق بأهداف ومتطلبات واضحة فيما يتعلق بالوظائف ومستويات الخدمة. يجب أن تأتي متطلبات الموارد من الفريق ، على الرغم من إمكانية استخدامها من قبل المؤسسة لقياس عائد الاستثمار.
تقوم فرق العمل المزدوجة التطوير بتطوير برنامج مترابط
يعد الاتصال الضعيف في البرامج وبين الفرق هو المفتاح لبناء مؤسسة فعالة للغاية. وتجربتي تؤكد هذه النقطة. عملت في مؤسسات حيث تم تقسيم الفرق حسب الوظيفة أو حسب مستوى البرنامج أو حتى عندما كان هناك فصل بين العملاء. عملت أيضًا في فرق فوضوية كبيرة على قاعدة شفرة واحدة. ولكن في كل هذه الحالات ، كانت هناك مشاكل في التوسع ، والتي تم ذكرها أعلاه. كانت أفضل تجربة ممتعة دائمًا عندما كان فريقي وحدة متكاملة ، حيث شارك بشكل مستقل في إنشاء واختبار ونشر خدمات مستقلة. لكنك لا تحتاج إلى الاعتماد على قصص حياتي. يحتوي تسريع (الموصوف أعلاه) على أدلة بحثية لدعم هذا الرأي.
إذا كنت قد قرأت هذه المواد حتى النهاية ، نوصيك بمشاهدة تسجيل لندوة عبر الإنترنت مفتوحة حول موضوع "يوم واحد في حياة DevOps" .