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

استمرار سلسلة من المقالات بناءً على الخطب في حدث DevForum الداخلي الخاص بنا :
1. القط شرودنجر دون مربع: مشكلة التوافق في النظم الموزعة.
2. البنية التحتية كرمز. (انت هنا)
3. جيل من عقود Typescript لنماذج ج #. (قيد التقدم ...)
4. كيف تتوافق الخوادم مع بعضها: وزعت خوارزمية توافق الآراء.
5. البنية التحتية كرمز: كيفية التغلب على مشاكل XP.
...
قررنا جعل فريق SRE يقوم بتنفيذ أفكار
google sre . لقد جندنا المبرمجين من مطوريهم وأرسلناهم للدراسة لعدة أشهر.
واجه الفريق المهام التدريبية التالية:
- صف البنية التحتية الخاصة بنا ، والتي توجد في الغالب في Microsoft Azure في شكل كود (Terraform وكل ما هو موجود)
- تعليم المطورين كيفية العمل مع البنية التحتية.
- إعداد المطورين للواجب.
تقديم مفهوم البنية التحتية كرمز
في النموذج المعتاد للعالم (الإدارة الكلاسيكية) ، تكون المعرفة بالبنية التحتية في مكانين:
- أو في شكل المعرفة في عقول الخبراء.

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

في كلتا الحالتين ، نحن محاصرون ، نعتمد:
- أو من شخص مميت ، عرضة للمرض ، الوقوع في الحب ، وتقلب المزاج وبكل بساطة الطرد.
- أو من جهاز يعمل فعليًا يسقط ، ويسرق ، ويعرض عدم الإزعاج والإزعاج.
وغني عن القول إنه من الأفضل ترجمة كل شيء إلى رمز مكتوب عالي الجودة يمكن قراءته من قبل الإنسان.
وبالتالي ، فإن البنية التحتية كرمز (Incfastructure as Code - IaC) هي وصف للبنية التحتية المتاحة بالكامل في شكل كود ، وكذلك الأدوات ذات الصلة للعمل معها وتحقيق البنية التحتية الحقيقية منها.
لماذا تترجم كل شيء إلى رمزالناس ليسوا سيارات. لا يمكنهم تذكر كل شيء. رد فعل شخص وآلة مختلفة. كل شيء تلقائي يحتمل أن يعمل بشكل أسرع من كل شيء يفعله أي شخص. الشيء الأكثر أهمية هو مصدر واحد للحقيقة.
من أين أتى مهندسو SRE الجدد؟لذلك ، قررنا توصيل مهندسين جدد من SRE ، ولكن من أين نحصل عليهم؟ الكتاب الذي يحتوي على الإجابات الصحيحة (
Google SRE Book ) يخبرنا: من المطورين. بعد كل شيء ، فإنها تعمل مع رمز ، ويمكنك تحقيق حالة ممتازة.
بحثنا عنهم كثيرًا وطويلًا في سوق الموظفين خارج شركتنا. لكننا مضطرون للاعتراف بأننا لم نجد واحدة تحت طلباتنا. كان علي الصوف بيني.
البنية التحتية كقضايا الكود
الآن ، دعونا نرى أمثلة على كيفية ربط البنية التحتية بالكود. رمز مكتوب بشكل جيد ، وذات جودة عالية ، مع تعليقات والمسافات البادئة.
نموذج التعليمة البرمجية من Terraforma.

رمز عينة من Ansible.

سادتي ، ولكن إذا كان كل شيء بسيطًا جدًا! نحن معكم في العالم الواقعي ، وهو دائمًا على استعداد لمفاجأتكم لتقديم المفاجآت والمشاكل. ليس بدونهم هنا.
1. المشكلة الأولى هي أن IaC في معظم الحالات هو نوع من dsl.و DSL ، بدوره ، هو وصف للهيكل. بتعبير أدق ، ما يجب أن يكون لديك: Json ، Yaml ، تعديلات من بعض الشركات الكبيرة التي جاءت مع dsl الخاصة بها (يتم استخدام HCL في terraform).
تكمن المشكلة في أنه قد لا يكون هناك أي شيء مألوف بالنسبة لنا بسهولة مثل:
- المتغيرات.
- شروط؛
- في مكان ما لا توجد تعليقات ، على سبيل المثال ، في Json ، بشكل افتراضي لا يتم توفيرها ؛
- وظيفة.
- وأنا لا أتحدث عن مثل هذه الأشياء رفيعة المستوى مثل الطبقات والميراث وكل ذلك.
2. المشكلة الثانية في هذا الكود هي في أغلب الأحيان بيئة غير متجانسة . عادة ما تجلس وتعمل مع C # ، أي مع لغة واحدة ، مكدس واحد ، نظام بيئي واحد. وهنا لديك مجموعة كبيرة من التقنيات.
إنه موقف حقيقي للغاية عندما تبدأ سلسلة من الثعبان بعملية ما ينزلق فيها Json. تقوم بتحليلها ، ثم يقوم مولد آخر بإنشاء 30 ملفًا آخر. لهذا كله ، يتم إدخال متغيرات الإدخال من Azure Key Vault ، والتي يتم تجميعها معًا من قِبل البرنامج المساعد لـ drone.io المكتوبة في Go ، وهذه المتغيرات تمر عبر yaml ، والتي تم الحصول عليها نتيجة للتوليد من محرك القالب jsonnet. من الصعب للغاية أن يكون لديك كود جيد الوصف عندما يكون لديك بيئة متنوعة.
التنمية التقليدية في إطار مهمة واحدة تأتي مع لغة واحدة. نحن هنا نعمل مع عدد كبير من اللغات.
3. المشكلة الثالثة هي tuling . لقد اعتدنا على تبريد المحررين (Ms Visual Studio و Jetbrains Rider) الذين يفعلون كل شيء لنا. وحتى لو كنا مملين ، فسيقولون أننا مخطئون. يبدو أن تكون طبيعية وطبيعية.
ولكن في مكان قريب يوجد VSCode ، حيث توجد بعض المكونات الإضافية المثبتة بطريقة أو بأخرى أو مدعومة أو غير مدعومة. تم إصدار إصدارات جديدة ولم يتم دعمها. الانتقال العادي إلى تنفيذ وظيفة (حتى لو كانت موجودة) يصبح مشكلة معقدة وغير تافهة. إعادة تسمية بسيطة لمتغير هو إعادة في مشروع من عشرات الملفات. إنه محظوظ إذا كان هناك شيء يحتاج إلى إصلاح. بالطبع ، هناك إضاءة خلفية في بعض الأماكن ، وهناك تجميع تلقائي ، في مكان ما يوجد تنسيق (على الرغم من أنني لم أبدأ في نظام التشغيل Windows في صيغة terraform).
في وقت كتابة هذا التقرير ، لم يتم إصدار
المكون الإضافي vscode-terraform لدعم الإصدار 0.12 ، على الرغم من أنه تم إصداره بالفعل لمدة 3 أشهر.
حان الوقت لنسيان ...
- التصحيح.
- أداة إعادة البناء.
- إكمال تلقائي.
- كشف أخطاء التجميع.
إنه أمر مضحك ، ولكنه يزيد أيضًا من وقت التطوير ويزيد من عدد الأخطاء التي تحدث حتماً.
أسوأ ما في الأمر هو أننا مضطرون إلى عدم التفكير في كيفية تصميم الملفات أو فكها في مجلدات أو تحليلها أو جعل التعليمات البرمجية مدعومة أو قابلة للقراءة أو ما إلى ذلك ، ولكن حول كيفية كتابة هذا الأمر بشكل صحيح ، لأنني بطريقة ما كتبته بطريقة غير صحيحة .
كمبتدئ ، تحاول أن تتعرف على terraforms ، ولا يساعدك IDE في ذلك على الإطلاق. عندما يكون هناك وثائق - ذهبوا في ، بدا. ولكن إذا كنت تريد إدخال لغة برمجة جديدة ، فإن IDE سيقترح وجود مثل هذا النوع ، لكن لا يوجد. على الأقل في مستوى كثافة العمليات أو السلسلة. هذا مفيد في كثير من الأحيان.
ولكن ماذا عن الاختبارات؟
أنت تسأل: "ماذا عن الاختبارات ، أيها السادة المبرمجون؟" الرجال الجادون يختبرون كل شيء على المنتج ، وهو أمر صعب. فيما يلي مثال على اختبار الوحدة لوحدة terraform من موقع
Microsoft على الويب.

لديهم وثائق جيدة. لطالما أحببت مايكروسوفت لما لها من نهج في التوثيق والتدريب. لكنك لست بحاجة إلى أن تكون العم بوب لفهم أن هذا ليس رمزًا مثاليًا. لاحظ التحقق من الصحة المقدمة إلى اليمين.
المشكلة في اختبار الوحدة هي أنك وأنا أستطيع التحقق من صحة إخراج Json. رميت 5 معلمات ، أعطيت لي موطئ قدم Json عن 2000 خطوط. يمكنني تحليل ما يحدث هنا والتحقق من صحة نتيجة الاختبار ...
من الصعب تحليل Json in Go. وتحتاج إلى الكتابة في Go ، لأن terraforms on Go هي ممارسة جيدة لما تختبره باللغة التي تكتب بها. التنظيم ذاته للرمز ضعيف جدًا. في الوقت نفسه ، إنها أفضل مكتبة للاختبار.
مايكروسوفت نفسها تكتب وحداتها ، تختبرها بهذه الطريقة. بالطبع ، هذا هو المصدر المفتوح. كل ما أتحدث عنه يمكن أن يأتي ويصلح. يمكنني الجلوس وإصلاح كل شيء في الأسبوع ، وفتح الإضافات VS- رمز ، terraforms ، وجعل البرنامج المساعد متسابق. ربما اكتب اثنين من المحللين ، اللولب المسمار ، نسخ المكتبة للاختبار. يمكنني أن أفعل كل شيء. ولكن ليس لدي للقيام بذلك.
أفضل الممارسات البنية التحتية كرمز
نحن نذهب أبعد من ذلك. إذا لم تكن هناك اختبارات في IaC ، سيئة مع IDE وضبط ، ثم يجب أن يكون هناك على الأقل أفضل الممارسات. لقد ذهبت للتو إلى تحليلات google وقمت بمقارنة استعلامات بحث اثنين: Terraform وأفضل الممارسات وأفضل الممارسات.

ماذا نرى؟ الإحصاءات القاسية ليست في صالحنا. من خلال كمية المواد - نفس الشيء. في تطوير C # ، نستحم فقط في المواد ، ولدينا أفضل الممارسات الفائقة ، وهناك كتب كتبها خبراء ، وأيضًا كتب مكتوبة على كتب من قبل خبراء آخرين ينتقدون تلك الكتب. بحر الوثائق الرسمية والمقالات والدورات التدريبية ، والآن أيضا تطوير المصادر المفتوحة.
بالنسبة لطلب IaC: أنت هنا تحاول تدريجيًا تجميع المعلومات من تقارير الحمل الكبير أو HashiConf ، من الوثائق الرسمية والعديد من الإصدارات على github. كيف يمكنك نشر هذه الوحدات ، ماذا تفعل معهم؟ يبدو أن هذه مشكلة حقيقية ... هناك مجتمع ، أيها السادة ، حيث سيتم منحك 10 تعليقات على github عن أي سؤال. لكن هذا غير دقيق.
لسوء الحظ ، في هذه المرحلة الزمنية ، بدأ الخبراء في الظهور. بينما هناك عدد قليل جدا منهم. والمجتمع نفسه معلق على مستوى البدائية.
أين يذهب كل شيء وماذا تفعل
يمكنك إسقاط كل شيء والعودة إلى C # ، في عالم المتسابق. لكن لا. لماذا تفعل هذا حتى إذا لم تجد حلاً. بعد ذلك ، أقدم استنتاجاتي الشخصية. يمكنك أن تجادل معي في التعليقات ، سيكون من المثير للاهتمام.
أنا شخصياً أضع بعض الأشياء:
- التنمية في هذا المجال سريعة جدا. أعطي الجدول الزمني لطلبات DevOps.

ربما كان الموضوع هو الضجيج ، لكن حقيقة أن الكرة تنمو تمنحنا بعض الأمل.
إذا نما شيء بسرعة كبيرة ، فسيظهر الأشخاص الأذكياء بالتأكيد من سيقول كيفية القيام بذلك ، وكيف لا يفعلون ذلك. تؤدي الزيادة في الشعبية إلى حقيقة أنه ربما يكون لدى شخص ما الوقت الكافي لإضافة مكون jsonnet الإضافي لـ vscode ، مما سيتيح لنا المتابعة في تنفيذ الوظيفة ، بدلاً من البحث عنها من خلال ctrl + shift + f. عندما يتطور كل شيء ، تظهر المزيد من المواد. نفس كتاب جوجل عن SRE هو مثال رائع. - هناك تقنيات وممارسات متطورة في التطوير التقليدي يمكننا تطبيقها هنا بنجاح. نعم ، هناك فروق دقيقة في الاختبار وبيئة غير متجانسة ، وضبط غير كافٍ ، ولكن تم تجميع عدد كبير من الممارسات التي يمكن أن تكون مفيدة ومساعدة.
مثال تافه: التعاون من خلال البرمجة الزوجية. أنها تساعد كثيرا على معرفة ذلك. عندما يكون لديك جار قريب يحاول أيضًا فهم شيء ما ، فستفهم معًا بشكل أفضل.
يساعد فهم كيفية إعادة هيكلة الممتلكات في إنتاجه حتى في مثل هذه الحالة. وهذا يعني أنه لا يمكنك تغيير كل شيء في وقت واحد ، ولكن يمكنك تغيير التسمية ، ثم تغيير الموقع ، ثم يمكنه تسليط الضوء على جزء ما ، ولكن لا توجد تعليقات كافية.
استنتاج
على الرغم من أن تفكيري قد يبدو متشائماً ، إلا أنني أتطلع إلى المستقبل وآمل بإخلاص أننا (وأنت) سننجح.
التالي يأتي الجزء الثاني من المقال . في ذلك ، أتحدث عن كيف استخدمنا ممارسات البرمجة المتطرفة لتحسين عملية التعلم لدينا والعمل مع البنية التحتية.