في أوقات فراغي أستمتع بالبناء جاندام النماذج ، التي هي مجموعات النماذج لبناء الميكاس الأيقونية من عالم Gundam. قد تتساءل ما علاقة هذا بهندسة البرمجيات. يمكن اعتبار مهندسي المنتجات المهندسين الذين يأخذون هذه المجموعات ويبنون Gundam نفسها. إنهم قادرون على الاستفادة من جميع القطع وبناء منتج عمل ممتع لجمع أو حتى اللعب!
من ناحية أخرى ، يوفر مهندسو المنصات الأدوات اللازمة لإنشاء هذه المجموعات (مثل كليبرز والملفات) وربما حتى إنشاء شاشة رائعة حتى يتمكن الجميع من رؤية المنتج النهائي. إنهم يضمنون أن كل من يقوم ببناءه لديه جميع الأدوات اللازمة ، حتى لو لم يبنوا جسديًا من Gundam بأنفسهم.
منذ حوالي عام ، انتقل فريقي في Github إلى منظمة البنية التحتية ، ورث أدوارًا جديدة ومجالات المسؤولية (AORS). في السابق ، تعامل الفريق مع مشاكل العملاء الخارجية ، مثل بناء الجديد طرق عرض النشر عبر البيئات. وشمل ذلك التفاعل مع المستخدمين الذين يعتمدون على GitHub لمواجهة التحديات داخل صناعاتهم. عملائنا الجدد كفريق هندسي منصات داخلي، مما يجعل مسؤولياتنا مختلفة عن الأعمال الهندسية التي تركز على المنتجات التي كنا نقوم بها من قبل.
بالعودة إلى مثال Gundam الخاص بي ، بدلاً من بناء مجموعات ، نحن الآن مسؤولون عن بناء مكونات المجموعات. يعني التكيف مع هذا التغيير أنه كان علي إعادة التفكير في نهجتي في اختبار التعليمات البرمجية وحل المشكلات.
سواء كنت تعمل على هندسة المنتجات أو على جانب المنصة ، فإليك بعض الممارسات الأفضل لمعالجة مشاكل النظام الأساسي.
فهم مجالك
واحدة من أكثر الخطوات الأهمية قبل معالجة المشاكل هي فهم المجال. “المجال” هو مجال العمل والموضوع الفني الذي تعمل فيه فريق ومنظمة منصات. وهذا يتطلب الحصول على فهم للمصطلحات التقنية وكيف تتفاعل هذه الأنظمة لتوفير حلول سريعة وموثوقة. إليك كيفية الوصول إلى السرعة:
- تحدث إلى جيرانك: ترتيب اجتماع تسليم مع فريق لديه المزيد من المعرفة والخبرة مع الموضوع. يوفر هذا الاجتماع فرصة لطرح أسئلة حول المصطلحات واكتساب فهم أعمق للمشاكل التي سيتناولها الفريق.
- التحقيق في القضايا القديمة: إذا كان هناك تراكم للمشكلات التي لا معنى لها أو لا تزال مستمرة ، فقد تمنحك فهمًا أفضل للقيود الحالية للنظام والمجالات المحتملة للتحسين.
- اقرأ المستندات: الوثائق هي منجم ذهبي للمعرفة يمكن أن تساعدك على فهم كيفية عمل النظام.
سد المفاهيم للمهارات الخاصة بالمنصة
في حين أن النصيحة السابقة تقدم إرشادات عامة تنطبق على كل من فرق المنتجات والمنصات ، فإن فرق المنصات-التي تعمل كطبقة التأسيسية-تتطلب فهمًا أكثر تعمقًا.
- الشبكات: فهم أساسيات الشبكة أمر بالغ الأهمية لجميع المهندسين ، حتى أولئك الذين لا يشاركون مباشرة في عمليات الشبكة. ويشمل ذلك مفاهيم مثل TCP و UDP و L4 موازنة تحميل ، وكذلك أدوات تصحيح الأخطاء مثل DIG. يعد الفهم القوي لهذه المجالات أمرًا ضروريًا لفهم كيفية تأثير حركة المرور على الشبكة على النظام الأساسي الخاص بك.
- أنظمة التشغيل والأجهزة: يعد اختيار الأجهزة الافتراضية المناسبة (VMS) أو الأجهزة المادية أمرًا حيويًا لكل من قابلية التوسع وإدارة التكلفة. يتطلب اتخاذ خيارات مستنيرة لتطبيقات معينة فهمًا قويًا لكليهما. يرتبط هذا ارتباطًا وثيقًا باختيار نظام التشغيل المناسب لآلاتك ، وهو أمر مهم لتجنب الأنظمة ذات النقاط الضعيفة أو تلك القريبة من نهاية الحياة.
- البنية التحتية كرمز (IAC): أصبحت أدوات التشغيل الآلي مثل Terraform و Ansible و Consul ضرورية بشكل متزايد. أصبحت الكفاءة في هذه الأدوات ضرورة لأنها تقلل بشكل كبير من الخطأ البشري أثناء توفير البنية التحتية وتعديلاتها.
- الأنظمة الموزعة: إن التعامل مع قضايا المنصة ، وخاصة في الأنظمة الموزعة ، يستلزم فهمًا عميقًا بأن الفشل أمر لا مفر منه. وبالتالي ، فإن استخدام حلول استباقية مثل آليات الفشل والاسترداد أمر بالغ الأهمية للحفاظ على موثوقية النظام ومنع تجارب المستخدم السلبية. يعتمد النهج الأمثل لهذا الأمر بالكامل على المشكلة المحددة وسلوك النظام المطلوب.
تبادل المعرفة
من خلال مشاركة الدروس والأفكار ، يمكن للمهندسين تقديم وجهات نظر جديدة تؤدي إلى اختراقات وابتكارات. إن أخذ الوقت الكافي لفهم سبب قيام المشروع أو الحل أو لم ينجح ومشاركة هذه النتائج ، يوفر وجهات نظر جديدة يمكننا استخدامها للمضي قدمًا.
فيما يلي ثلاثة أسباب تجعل مشاركة المعرفة مهمة جدًا:
- العمل الجماعي يجعل الحلم يعمل: غالبًا ما يؤدي التعاون إلى حل مشكلة أسرع ويعزز ابتكار حلول جديدة ، حيث أن المهندسين لديهم فرصة للتعلم من بعضهم البعض والتوسع في الأفكار الحالية.
- منع المعرفة المفقودة: إذا لم نشارك دروسنا المستفادة ، فنحن نمنع نشر المعلومات عبر الفريق أو المنظمة. تصبح هذه مشكلة إذا ترك المهندس الشركة أو لم يكن متاحًا.
- تحسين نجاح العملاء لدينا: كمهندسين ، يجب أن تخدم حلولنا عملائنا بشكل فعال. من خلال مشاركة معرفتنا ودروسنا المستفادة ، يمكننا مساعدة الفريق على بناء منصات موثوقة وقابلة للتطوير وآمنة ، والتي ستمكننا من إنشاء منتجات أفضل تلبي احتياجات العملاء وتوقعاتها!
لكن الاختلافات الكبيرة تبدأ في الظهور بين هندسة المنتجات وهندسة البنية التحتية عندما يتعلق الأمر بنصف قطر التأثير وعملية الاختبار.
تأثير دائرة نصف قطرها
نظرًا لأن المنصات هي لبنات البناء الأساسية للنظام ، يمكن أن يؤثر أي تغيير (صغير أو كبير) على مجموعة واسعة من المنتجات. فريقنا مسؤول عن DNS ، وهي خدمة تأسيسية تؤثر على العديد من المنتجات. حتى التغيير البسيط على هذه الخدمة يمكن أن يكون له تداعيات واسعة النطاق ، مما يحتمل أن يعطل الوصول إلى المحتوى عبر موقعنا ويؤثر على المنتجات التي تتراوح من صفحات الجيش إلى github copilot.
- فهم نصف القطر: أو فهم التبعيات المصب. يوفر التواصل المباشر مع الفرق التي تعتمد على خدمتنا رؤى قيمة حول كيفية تأثير التغييرات المقترحة على الخدمات الأخرى.
- ما بعد الوفاة: من خلال النظر إلى الحوادث السابقة المتعلقة بمنصتنا والسؤال “ما هو تأثير هذا الحادث؟ “، يمكننا تكوين المزيد من السياق حول التغيير أو الفشل ، وكيف لعبت منصتنا دورًا فيه ، وكيف تم إصلاحه.
- المراقبة والقياس عن بعد: تكثف المراقبة المهمة وتسجيل الدخول إلى وسيط صغير ومتسابق بسرعة لإعطائك الصحة العامة للنظام. يمكن أن يكون هذا مقياس توافر واحد (SAM) ، على سبيل المثال. تتيح القدرة على إلقاء نظرة سريعة على لوحة معلومات واحدة للمهندسين تحديد مصدر المشكلة بسرعة وتبسيط عملية تصحيح الأخطاء والتخفيف من الحوادث ، مقارنة بالبحث وتفسير رسائل مراقبة مفصلة أو سجلات.
اختبار التغييرات
يمكن أن يكون اختبار التغييرات في بيئة موزعة أمرًا صعبًا ، خاصة بالنسبة للخدمات مثل DNS. تتمثل الخطوة الحاسمة في حل هذه المشكلة في استخدام موقع اختبار كآلة “حقيقية” حيث يمكنك تنفيذ وتقييم جميع التغييرات الخاصة بك.
- البنية التحتية كرمز (IAC): عند استخدام أدوات مثل Terraform أو Ansible ، من الأهمية بمكان اختبار العمليات الأساسية مثل آلات التزويد و Actrovisioning. هناك ظروف ستحتاج فيها إلى إعادة تقديم الجهاز. في هذه الحالات ، نريد التأكد من عدم حذف الماكينة بطريق الخطأ وأن نحتفظ بالقدرة على إنشاء جهاز جديد إذا لزم الأمر.
- من طرف إلى طرف (E2E): ابدأ في توجيه بعض حركة مرور الشبكة إلى هذه الخوادم. ثم يمكن للفريق مراقبة سلوك المضيف من خلال التفاعل المباشر معه ، أو يمكننا تقييم الوظائف عن طريق تحويل جزء صغير من حركة المرور.
- الشفاء الذاتي: نريد اختبار قدرة النظام الأساسي على التعافي من الأحمال غير المتوقعة وتحديد الاختناقات قبل التأثير على مستخدمينا. يعد التعرف المبكر على الاختناقات أو الأخطاء أمرًا ضروريًا للحفاظ على صحة منصتنا.
من الناحية المثالية ، سيتم تنفيذ التغييرات على أساس مضيف مضيف بمجرد اكتمال الاختبار. يسمح هذا النهج بتراجع الآلة الفردية ويمنع التغييرات من تطبيقها على المضيفين غير المتأثرين.
ماذا تتذكر
يمكن أن تكون هندسة المنصة صعبة. تعمل الأنظمة GitHub معها معقدة وهناك الكثير من الخدمات والأجزاء المتحركة. ومع ذلك ، لا يوجد شيء مثل رؤية كل شيء يجتمع. جميع العمل الشاق الذي تقوم به فرقنا الهندسية وراء الكواليس يؤتي ثماره حقًا عندما تعمل المنصة بسلاسة وتكون الفرق قادرة على الشحن بشكل أسرع وأكثر موثوقية – مما يتيح لـ Github أن تكون موطنًا لجميع المطورين.
تريد الغوص أعمق؟ تحقق من لدينا منشورات المدونة ذات الصلة في البنية التحتية.
كتبه
اترك تعليقاً