البنية التحتية كرمز: كيفية التغلب على مشاكل XP

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



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

من نحن ، أين نحن وما المشاكل التي لدينا

نحن الآن في فريق Sre Onboarding ، الذي يتكون من ستة مبرمجين وثلاثة مهندسين في البنية التحتية. نحاول جميعًا كتابة البنية التحتية كرمز (IaC). نقوم بذلك لأننا ، من حيث المبدأ ، قادرون على كتابة الكود وفي التاريخ نحن مطورون للمستوى "فوق المتوسط".

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

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

نحن نكافح الآن مع مشكلات IaC هذه:

• عيوب الأدوات وأدوات تطوير الكود.
• نشر بطيء. البنية التحتية جزء من العالم الحقيقي ، ويمكن أن تكون بطيئة.
• عدم وجود أساليب وممارسات.
• نحن جدد ولا نعرف الكثير.

البرمجة المتطرفة (XP) للإنقاذ

جميع المطورين معتادون على البرمجة المتطرفة (XP) والممارسات التي تقف وراءها. الكثير منا عمل على هذا النهج ، وكان ناجحا. فلماذا لا تستفيد من المبادئ والممارسات الموضوعة هناك للتغلب على صعوبات البنية التحتية؟ قررنا تطبيق هذا النهج ومعرفة ما يحدث.


دعونا نلقي نظرة على بعض الممارسات من XP وكيفية تأثيرها على سرعة وجودة التعليقات.

XP مبدأ حلقة ردود الفعل

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



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

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

هام: يمكن أن تكون التعليقات هي الحل لجميع المشاكل المذكورة أعلاه. جنبا إلى جنب مع ممارسات XP ، فإنه يمكن سحب اليأس من الهاوية.

كيف تخرج نفسك من هاوية اليأس: ثلاث ممارسات

اختبارات

يتم ذكر الاختبارات مرتين في حلقة ملاحظات XP. الأمر ليس كذلك. أنها مهمة للغاية لجميع تقنيات البرمجة المتطرفة.

من المفترض أن لديك اختبارات الوحدة والقبول. يعطيك البعض ملاحظات في بضع دقائق ، والبعض الآخر في غضون أيام قليلة ، لأنها مكتوبة لفترة أطول ، وتعمل بشكل متكرر.

هناك هرم اختبار كلاسيكي ، مما يدل على أنه ينبغي أن يكون هناك المزيد من الاختبارات.



كيف ينطبق هذا المخطط علينا في مشروع IaC؟ في الواقع ... لا شيء.

• اختبارات الوحدة ، على الرغم من حقيقة أنه يجب أن يكون هناك الكثير منها ، لا يمكن أن يكون الكثير. أو أنهم يختبرون شيئًا ما بشكل غير مباشر. في الواقع ، يمكننا أن نقول أننا لا نكتبها على الإطلاق. ولكن فيما يلي بعض التطبيقات لهذه الاختبارات ، والتي ما زلنا قادرين على القيام بها:
  
  
  1. رمز الاختبار على jsonnet. هذا ، على سبيل المثال ، هو تجميع خط أنابيب لدينا في طائرة بدون طيار ، وهو أمر معقد للغاية. رمز jsonnet مغطى جيدًا بالاختبارات.
     نحن نستخدم إطار اختبار الوحدة هذا من أجل Jsonnet .
  2. اختبارات البرامج النصية التي يتم تنفيذها عند بدء تشغيل المورد. يمكن كتابة البرامج النصية في بيثون ، وبالتالي اختبارات لهم.
• من الممكن التحقق من التكوين في الاختبارات ، لكننا لا نفعل ذلك. من الممكن أيضًا تكوين التحقق من قواعد تكوين الموارد من خلال tflint . ومع ذلك ، فقط من أجل terraform هناك اختبارات أساسية للغاية ، ولكن تتم كتابة العديد من البرامج النصية للاختبار AWS. ونحن على أزور ، لذلك هذا غير مناسب مرة أخرى.
• اختبارات تكامل المكونات: يعتمد ذلك على كيفية تصنيفها ومكان وضعها. لكنهم يعملون أساسا.
  
  هذا هو ما تبدو اختبارات التكامل.
  
  
  
  هذا مثال عند تجميع الصور في Drone CI. للوصول إليهم ، عليك الانتظار لمدة 30 دقيقة حتى تتجمع صورة Packer ، ثم انتظر 15 دقيقة أخرى حتى تمر. لكنهم!
  
  
  خوارزمية التحقق من صحة الصورة

  1. أولاً ، يجب على Packer إعداد الصورة بالكامل.
  2. يوجد بجانب الاختبار terraform مع حالة محلية ، ننشر بها هذه الصورة.
  3. عند النشر ، يتم استخدام وحدة صغيرة ملقاة بجوارها بحيث يكون من الأسهل التعامل مع الصورة.
  4. عندما يتم نشر VM من الصورة ، يمكنك البدء في التحقق. يتم معظمها الشيكات بالسيارة. إنه يتحقق من كيفية عمل البرامج النصية عند بدء التشغيل ، وكيف تعمل الشياطين. للقيام بذلك ، من خلال ssh أو winrm ، نذهب إلى الجهاز الذي تم رفعه للتو والتحقق من حالة التكوين أو ما إذا كانت الخدمات قد ارتفعت.

  
  
• موقف مماثل مع اختبارات التكامل وفي وحدات ل terraform. فيما يلي جدول موجز يوضح ميزات مثل هذه الاختبارات.
  
  
  
  ردود فعل خط الأنابيب في منطقة 40 دقيقة. كل شيء يستغرق وقتا طويلا جدا. يمكن استخدامه من أجل الانحدار ، ولكن للتطور الجديد يكون غير واقعي بشكل عام. إذا كنت حقًا ، استعد حقًا لهذا الأمر ، وقم بإعداد البرامج النصية قيد التشغيل ، يمكنك تقليله إلى 10 دقائق. ولكن هذا لا يزال غير اختبارات الوحدة ، والتي هي 100 قطعة في 5 ثوان.

إن عدم وجود اختبارات وحدة أثناء تجميع الصور أو الوحدات النمطية من terraform يشجع على تحويل العمل إلى خدمات منفصلة يمكن ببساطة سحبها بواسطة REST أو إلى برامج Python النصية.

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

نظرًا لأن ScaleFT هي خدمة ، فإننا مضطرون للعمل معها من خلال واجهة برمجة التطبيقات. كان هناك غلاف مكتوب يمكنك سحبه ويقول: "تعال وحذف هذا ، ذلك." لأنه يخزن جميع الإعدادات اللازمة والوصول.

يمكننا بالفعل كتابة اختبارات عادية لهذا ، لأنه لا يختلف عن البرامج العادية بأي شكل من الأشكال: بعض apiha يبلل ، وينتج ، ويبحث عما يحدث.

نتائج الاختبار: اختبار وحدة ، والتي ينبغي أن تعطي نظام التشغيل في دقيقة واحدة ، لا يعطيها. وتؤدي الأنواع الأعلى من الاختبارات في الهرم إلى التأثير ، لكن تتم تغطية جزء فقط من المشكلات.

البرمجة الزوجية

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

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

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

فيما يلي أنماط البرمجة الزوجية وإمكانية تطبيقها في العمل على IaC:

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

النظر في توافق مشاكلنا مع النمط:

• المشكلة: عيوب الأدوات ، وأدوات تطوير الشفرة.
  التأثير السلبي: لتطوير أطول ، نحن تبطئ ، وتيرة / إيقاع العمل ضلال.
  كيفية القتال: نستخدم توليفًا آخر ، و IDE شائعًا ومازلنا نتعلم اختصارات.
• المشكلة: النشر البطيء.
  التأثير السلبي: يزيد من الوقت لإنشاء قطعة من التعليمات البرمجية العاملة. نفتقد أثناء الانتظار ، يتم رسم الأيدي للقيام بشيء آخر أثناء الانتظار.
  كيفية القتال: لم تتغلب.
• المشكلة: قلة المناهج والممارسات.
  التأثير السلبي: لا توجد معرفة بكيفية عمل الخير ، ولكن كم هو سيء. يمتد ردود الفعل.
  كيفية القتال: تبادل الآراء والممارسات في الاقتران يحل المشكلة تقريبًا.

المشكلة الرئيسية في تطبيق هذا النمط على IaC بوتيرة متفاوتة. في تطوير البرمجيات التقليدية ، لديك حركة موحدة للغاية. يمكنك قضاء خمس دقائق وكتابة N. قضاء 10 دقائق والكتابة 2N ، 15 دقيقة - 3N. هنا يمكنك قضاء خمس دقائق والكتابة N ، ثم قضاء 30 دقيقة أخرى وكتابة عُشر N. هنا لا تعرف شيئًا ، لديك هفوة ، dumbass. تستغرق التجربة وقتًا وتشتت الانتباه عن البرمجة نفسها.

الخلاصة: في شكله النقي لا يناسبنا.

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

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

الخلاصة: للأسف ، لا تسمح وتيرة العمل باستخدام كرة الطاولة ، كممارسة للبرمجة الزوجية في IaC.

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

مناسب تمامًا للتدريب ، لكنه يتطلب مهارات ناعمة قوية. على هذا نحن تعثرت. كانت التقنية صعبة. والنقطة هنا ليست حتى البنية التحتية.

الخلاصة: يحتمل أنه يمكن تطبيقها ، ونحن لا نتخلى عن المحاولات.

4. لا تعتبر ، مهاجمة ، حشد وجميع الأنماط المعروفة ، ولكن غير المدرجة هنا ، ل لم نحاول أن أقول عن ذلك في سياق عملنا لن ينجح.

النتائج العامة على استخدام البرمجة الزوجية:

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

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

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

التخطيط والاتصالات

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

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



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

مزايا الرؤية البصرية للمهام:

• السببية. كل مهمة تؤدي إلى بعض الأهداف العالمية. يتم تجميع المهام في أهداف أصغر. مجال البنية التحتية في حد ذاته تقنية. ليس من الواضح دائمًا على الفور ما هو التأثير المحدد على النشاط التجاري ، على سبيل المثال ، من خلال كتابة دفتر تصنيف حول الترحيل إلى nginx آخر. وجود بطاقة الهدف القريبة يجعل هذا أكثر وضوحا.
  
  السبب هو خاصية مهمة للمهام. إنه يجيب مباشرة على السؤال: "هل أفعل ذلك؟"
• التوازي. هناك تسعة منا ، ومن المستحيل مهاجمة الجميع بمهمة واحدة جسديًا. المهام من منطقة واحدة أيضا قد لا تكون دائما كافية. نحن مضطرون للعمل الموازي بين مجموعات العمل الصغيرة. في الوقت نفسه ، تجلس المجموعات في مهمتها لبعض الوقت ، ويمكن تعزيزها بواسطة شخص آخر. الناس في بعض الأحيان تسقط هذه المجموعة العاملة. شخص ما يذهب في إجازة ، شخص ما يقدم تقريرًا عن مؤتمر DevOps conf ، يكتب شخص ما مقالًا عن Habr. تصبح معرفة الأهداف والغايات التي يمكن القيام بها بالتوازي مهمة للغاية.

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

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



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

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

في عملية العرض التوضيحي ، من الضروري الكشف عن تفاصيل المهمة والتأكد من إظهار عملها.


بعد الجزء بدوام كامل ، هناك دائما مناقشة في الموضوع. هذا هو المكان الذي تظهر فيه الملاحظات الضرورية حول مهامنا.


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

استنتاجات طويلة وما هو التالي

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

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

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

طرق المستوى الأعلى للتأثير على نظام التشغيل - التخطيط والعمل مع المهام تعطي التأثيرات على وجه التحديد: تبادل عالي الجودة للمعرفة وتحسين جودة التطوير.

استنتاجات قصيرة في سطر واحد

• تعمل ممارسات XP في IaC ، ولكن بكفاءة أقل.
• تعزيز ما يعمل.
• صمم الآليات والممارسات التعويضية الخاصة بك.