هناك أكثر من 600 بيتزا في دودو بيتزا في 13 دولة حول العالم ، ويتم التحكم في معظم العمليات في بيتزا من خلال نظام معلومات دودو آي إس ، الذي نكتبه ونحافظ عليه. لذلك ، فإن موثوقية واستقرار النظام مهم من أجل البقاء.
الآن يتم دعم استقرار وموثوقية نظام المعلومات في الشركة من قبل فريق SRE ( هندسة موثوقية الموقع ) ، ولكن لم يكن هذا هو الحال دائمًا.
الخلفية: عوالم موازية للمطورين والبنى التحتية
لسنوات عديدة ، تطورت كمطور نموذجي كامل (وقليلاً من الخريجين) ، تعلمت كتابة كود جيد ، وطبقت الممارسات من البرمجة المتطرفة وقللت بعناية مقدار WTF في المشاريع التي لمستها. ولكن كلما زادت الخبرة في تطوير البرمجيات ، أدركت أهمية أنظمة المراقبة الموثوقة وتطبيقات التتبع ، والسجلات عالية الجودة ، والاختبار التلقائي الكلي والآليات التي توفر موثوقية عالية للخدمات. وفي كثير من الأحيان بدأ في التظاهر "فوق السياج" لفريق البنية التحتية.
كلما فهمت البيئة التي يعمل بها الكود الخاص بي بشكل أفضل ، فوجئت أكثر: كانت الاختبارات المؤتمتة لكل شيء وكل شخص ، CI ، والإصدارات المتكررة ، وإعادة البناء الآمنة والملكية الجماعية للكود في عالم البرمجيات شائعة ومألوفة منذ فترة طويلة. في الوقت نفسه ، في عالم "البنية التحتية" ، لا يزال من الطبيعي أن تفتقر إلى الاختبارات التلقائية ، وإجراء تغييرات على أنظمة الإنتاج في الوضع شبه اليدوي ، وغالبًا ما تكون الوثائق في رؤوس الأفراد فقط ، ولكن ليس في التعليمات البرمجية.
هذا الانقسام الثقافي والتكنولوجي لا يسبب الارتباك فحسب ، بل يسبب أيضًا المشاكل: عند تقاطع التنمية والبنية التحتية والأعمال. من الصعب التعامل مع بعض مشاكل البنية التحتية بسبب القرب من الأجهزة والأدوات سيئة التطوير نسبيًا. ولكن يمكن هزيمة الباقي إذا بدأت في النظر إلى جميع كتب Ansible الخاصة بك ونصوص Bash كمنتج برمجي كامل وتطبيق نفس المتطلبات عليهم.
مثلث برمودا من المشاكل
ومع ذلك ، سأبدأ من بعيد - مع المشاكل التي تحتاج إلى كل هذه الرقصات.
مشاكل المطور
قبل عامين ، أدركنا أن سلسلة بيتزا كبيرة لا يمكن أن تعيش بدون تطبيقات الهاتف المحمول الخاصة بها وقررنا كتابتها:
- تشكيل فريق عظيم.
- لمدة ستة أشهر كتبوا طلبًا مناسبًا وجميلًا ؛
- عززت الانطلاق الرسمي مع الترقيات "اللذيذة" ؛
- وفي اليوم الأول سقط بأمان تحت الحمل.
كان هناك الكثير من الدعامات في البداية ، بالطبع ، لكن الأهم من ذلك كله أتذكر واحدة. في وقت التطوير ، تم نشر خادم ضعيف عند الإنتاج ، تقريبًا آلة حاسبة عالجت الطلبات من التطبيق. قبل الإعلان العام عن التطبيق ، كان يجب زيادته - نحن نعيش في Azure ، وقد تم حل ذلك بنقرة زر واحدة.
ولكن لم يضغط أحد على هذا الزر: لم يعرف فريق البنية التحتية حتى أنه سيتم إصدار نوع من التطبيق اليوم. وقرروا أن مسؤولية الإشراف على إنتاج الخدمة "غير الحرجة" تقع على عاتق فريق التطبيق. وقرر المطور الخلفي (كان هذا أول مشروع له في دودو) أن الرجال من البنية التحتية يفعلون ذلك في الشركات الكبيرة.
هذا المطور كان أنا. ثم استنتجت لنفسي قاعدة واضحة ولكنها مهمة:
, , , . .
ليس من الصعب الآن. في السنوات الأخيرة ، ظهر عدد كبير من الأدوات التي تسمح للمبرمجين بالنظر إلى عالم الاستغلال وعدم كسر أي شيء: Prometheus ، Zipkin ، Jaeger ، ELK stack ، Kusto.
ومع ذلك ، لا يزال العديد من المطورين يواجهون مشاكل خطيرة مع تلك التي تسمى البنية التحتية / DevOps / SRE. نتيجة لذلك ، المبرمجين:
يعتمدون على فريق البنية التحتية. يسبب الألم وسوء الفهم والكراهية المتبادلة في بعض الأحيان.
إنهم يصممون أنظمتهم بمعزل عن الواقع ولا يأخذون في الاعتبار أين وكيف سيتم تنفيذ التعليمات البرمجية الخاصة بهم. على سبيل المثال ، ستختلف بنية وتصميم نظام يتم تطويره مدى الحياة في السحابة عن تصميم نظام يتم استضافته في المؤسسة.
إنهم لا يفهمون طبيعة الأخطاء والمشاكل المرتبطة برموزهم.يمكن ملاحظة ذلك بشكل خاص عندما تتعلق المشاكل بالحمل أو موازنة الاستعلام أو أداء الشبكة أو محرك الأقراص الثابتة. لا يمتلك المطورون هذه المعرفة دائمًا.
لا يمكن تحسين الأموال وموارد الشركة الأخرى المستخدمة للحفاظ على التعليمات البرمجية الخاصة بهم. في تجربتنا ، يحدث أن فريق البنية التحتية ببساطة يغمر المشكلة بالمال ، على سبيل المثال ، زيادة حجم خادم قاعدة البيانات في الإنتاج. لذلك ، غالبًا ما لا تصل مشكلات التعليمات البرمجية إلى المبرمجين. إنه فقط لسبب ما تبدأ البنية التحتية في تكلفتها أكثر.
قضايا البنية التحتية
هناك أيضا صعوبات على "الجانب الآخر".
من الصعب إدارة العشرات من الخدمات والبيئات بدون رمز جودة. لدينا حاليًا أكثر من 450 مستودعات على GitHub. البعض منهم لا يحتاج إلى دعم تشغيلي ، وبعضهم مات وحفظه للتاريخ ، ولكن جزء كبير يحتوي على الخدمات التي تحتاج إلى دعم. إنهم بحاجة إلى الاستضافة في مكان ما ، ويحتاجون إلى المراقبة وجمع السجلات وخطوط الأنابيب CI / CD الموحدة.
لإدارة كل هذا ، استخدمنا مؤخرًا Ansible بنشاط. يحتوي مستودعنا Ansible على:
- 60 أدوار ؛
- 102 كتاب لعب.
- ملزم في بيثون وباش.
- الاختبارات اليدوية في Vagrant.
كل هذا كتبه شخص ذكي وكتب جيداً. ولكن بمجرد أن بدأ المطورون الآخرون من البنية التحتية والمبرمجين في العمل بنشاط مع هذا الرمز ، اتضح أن الكتب الإلكترونية تنكسر ، وتتكرر الأدوار و "تتضخم مع الطحلب".
والسبب هو أن هذا الرمز لم يستخدم العديد من الممارسات القياسية في عالم تطوير البرمجيات. لم يكن لديها خط أنابيب CI / CD ، وكانت الاختبارات معقدة وبطيئة ، لذلك كان الجميع كسالى للغاية أو "لم يكن لديهم وقت" لتشغيلها يدويًا ، ناهيك عن كتابة اختبارات جديدة. مثل هذا الرمز محكوم عليه بالفشل إذا كان هناك أكثر من شخص يعمل عليه.
بدون معرفة الشفرة ، من الصعب الاستجابة بشكل فعال للحوادث.عندما يأتي تنبيه إلى PagerDuty في الساعة 3 صباحًا ، يجب أن تبحث عن مبرمج يشرح ماذا وكيف. على سبيل المثال ، أن هذه الأخطاء الـ 500 تؤثر على المستخدم ، بينما يرتبط الآخرون بخدمة ثانوية ، ولا يراها العملاء النهائيون ويمكنك ترك كل شيء من هذا القبيل حتى الصباح. ولكن في الثالثة صباحًا ، من الصعب إيقاظ المبرمجين ، لذا يُنصح بفهم كيفية عمل الشفرة التي تدعمها.
تتطلب العديد من الأدوات التضمين في رمز التطبيق. يعرف الأشخاص من البنية التحتية ما يجب مراقبته ، وكيفية تسجيل الدخول والأشياء التي يجب الانتباه إليها للبحث عن المفقودين. لكنهم غالبًا ما يكونون غير قادرين على تضمين كل هذا في رمز التطبيق. وأولئك الذين لا يستطيعون معرفة ما وكيفية تضمينه.
"هاتف مكسور".إن تفسير ما وكيفية مراقبته للمرة المائة أمر غير سار. من الأسهل كتابة مكتبة مشتركة لتمريرها إلى المبرمجين لإعادة استخدامها في تطبيقاتهم. ولكن للقيام بذلك ، تحتاج إلى أن تكون قادرًا على كتابة التعليمات البرمجية بنفس اللغة وبنفس النمط وبنفس النهج التي يستخدمها مطورو التطبيقات.
مشاكل العمل
لدى الشركة أيضًا مشكلتان كبيرتان يجب معالجتهما.
الخسائر المباشرة من عدم استقرار النظام المرتبط بالموثوقية والتوافر.
في عام 2018 ، كان لدينا 51 حادثة خطيرة ، ولم تعمل العناصر الحرجة في النظام لأكثر من 20 ساعة. من الناحية النقدية ، هذا هو 25 مليون روبل من الخسائر المباشرة بسبب الطلبات غير المسلمة وغير المسلمة. وكم خسرنا من ثقة الموظفين والعملاء وأصحاب الامتياز من المستحيل حسابه ، ولا يتم تقييمه بالمال.
تكاليف دعم البنية التحتية الحالية. في الوقت نفسه ، حددت الشركة هدفًا لعام 2018: تخفيض تكلفة البنية التحتية لكل بيتزا بمقدار 3 مرات. ولكن لا المبرمجين ولا مهندسي DevOps داخل فرقهم يمكن أن يقتربوا من حل هذه المشكلة. هناك أسباب لذلك:
- , ;
- , operations ( DevOps), ;
- , .
?
كيف تحل كل هذه المشاكل؟ لقد وجدنا الحل في كتاب "هندسة موثوقية الموقع" من Google. عندما قرأنا ، فهمنا - هذا ما نحتاجه.
ولكن هناك تحذير - من أجل تنفيذ كل هذا ، يستغرق الأمر سنوات ، وعليك أن تبدأ في مكان ما. ضع في اعتبارك بيانات المصدر التي كانت لدينا في الأصل.
تعيش بنيتنا التحتية بالكامل تقريبًا في Microsoft Azure. هناك العديد من مجموعات المبيعات المستقلة المنتشرة عبر قارات مختلفة: أوروبا وأمريكا والصين. هناك منصات تحميل تكرر الإنتاج ، ولكنها تعيش في بيئة معزولة ، بالإضافة إلى العشرات من بيئات DEV لفرق التطوير.
من ممارسات SRE الجيدة التي كانت لدينا بالفعل:
- آليات مراقبة التطبيقات والبنية التحتية (المفسد: في 2018 اعتقدنا أنها كانت جيدة ، لكننا الآن قد قمنا بالفعل بإعادة كتابة كل شيء) ؛
- 24/7 on-call;
- ;
- ;
- CI/CD- ;
- , ;
- SRE .
ولكن كانت هناك أيضًا مشاكل كنت أريد حلها في المقام الأول:
كان فريق البنية التحتية مثقلًا. لم يكن هناك ما يكفي من الوقت والجهد للتحسينات العالمية بسبب نظام التشغيل الحالي. على سبيل المثال ، أردنا لفترة طويلة جدًا ، لكننا لم نتمكن من التخلص من Elasticsearch في مجموعتنا ، أو تكرار البنية التحتية من مزود سحابة آخر لتجنب المخاطر (هنا قد يضحك أولئك الذين حاولوا بالفعل في السحابة المتعددة).
فوضى في الكود. كان رمز البنية التحتية فوضويًا ، منتشرًا عبر مستودعات مختلفة ، ولم يتم توثيقه في أي مكان. كل شيء يرتكز على معرفة الأفراد ولا شيء آخر. كانت هذه مشكلة ضخمة في إدارة المعرفة.
"هناك مبرمجون ، ولكن هناك مهندسون البنية التحتية."على الرغم من حقيقة أن لدينا ثقافة DevOps متطورة إلى حد ما ، لا يزال هناك هذا الفصل. فئتين من الأشخاص ذوي تجارب مختلفة تمامًا ، يتحدثون لغات مختلفة ويستخدمون أدوات مختلفة. إنهم بالطبع أصدقاء ويتواصلون ، لكنهم غالبًا لا يفهمون بعضهم البعض بسبب تجارب مختلفة تمامًا.
فرق إعداد SRE
لحل هذه المشاكل والبدء في التحرك نحو SRE بطريقة أو بأخرى ، أطلقنا مشروع تأهيل. فقط لم يكن الأمر تدريبًا كلاسيكيًا - تدريب الموظفين الجدد (الوافدين الجدد) على إضافة أشخاص إلى الفريق الحالي. لقد كان إنشاء فريق جديد من مهندسي ومبرمجي البنية التحتية - الخطوة الأولى نحو هيكل SRE كامل.
خصصنا 4 أشهر للمشروع وحددنا ثلاثة أهداف:
- تدريب المبرمجين على المعرفة والمهارات اللازمة للقيام بالواجبات والأنشطة التشغيلية في فريق البنية التحتية.
- اكتب IaC - وصف للبنية التحتية بالكامل في الشفرة. علاوة على ذلك ، يجب أن يكون منتج برمجي متكامل مع اختبارات CI / CD.
- أعد إنشاء بنيتنا الأساسية بالكامل من هذا الرمز ونسيان النقر يدويًا على الأجهزة الافتراضية باستخدام الماوس في Azure.
المشاركون: 9 أشخاص ، 6 منهم من فريق التطوير ، 3 من البنية التحتية. لمدة 4 أشهر ، اضطروا إلى ترك وظائفهم العادية والانغماس في المهام المعينة. للحفاظ على "الحياة" في الأعمال التجارية ، ظل 3 أشخاص آخرين من البنية التحتية في الخدمة ، والتعامل مع أنظمة التشغيل والتغطية الخلفية. ونتيجة لذلك ، امتد المشروع بشكل ملحوظ واستغرق أكثر من خمسة أشهر (من مايو إلى أكتوبر 2019).
ركيزتان للتربية: التعلم والممارسة
يتكون الإعداد من جزأين: التعلم والعمل على البنية التحتية في التعليمات البرمجية.
تدريب. تم تخصيص ما لا يقل عن 3 ساعات في اليوم للتدريب:
- لقراءة المقالات والكتب من قائمة المراجع: Linux ، والشبكات ، و SRE ؛
- في محاضرات حول أدوات وتقنيات محددة ؛
- إلى أندية التكنولوجيا ، مثل Linux ، حيث حللنا الحالات والحالات المعقدة.
أداة تعليمية أخرى هي عرض داخلي. هذا اجتماع أسبوعي تحدث فيه كل شخص (لديه ما يقوله) في 10 دقائق عن تقنية أو مفهوم قاموا بتطبيقه في الكود الخاص بنا في غضون أسبوع. على سبيل المثال ، قام Vasya بتغيير خط الأنابيب للعمل مع وحدات Terraform ، وأعاد Petya كتابة تجميع الصور باستخدام Packer.
بعد العرض التوضيحي ، بدأنا المناقشات تحت كل موضوع في Slack ، حيث يمكن للمشاركين المهتمين مناقشة كل شيء بمزيد من التفصيل بشكل غير متزامن. لذلك تجنبنا عقد اجتماعات طويلة لعشرة أشخاص ، ولكن في نفس الوقت فهم الجميع في الفريق جيدًا ما كان يحدث مع بنيتنا التحتية وأين نتجه.
ممارسة. الجزء الثاني من الإعداد هو إنشاء / وصف البنية التحتية في التعليمات البرمجية . تم تقسيم هذا الجزء إلى عدة مراحل.
الهندسة العكسية للبنية التحتية.هذه هي المرحلة الأولى التي اكتشفنا فيها مكان إصلاحها ، وكيف تعمل ، وأين تعمل الخدمات ، وأين الآلات وأحجامها. كل شيء موثق بالكامل.
مفاهيم. لقد جربنا تقنيات ولغات ومناهج مختلفة واكتشفنا كيف يمكننا وصف بنيتنا التحتية وما هي الأدوات التي يجب استخدامها لهذا الغرض.
كود الكتابة. وشمل ذلك كتابة الكود نفسه ، وإنشاء خطوط أنابيب CI / CD ، والاختبارات ، وعمليات البناء حولها كلها. كتبنا الشفرة التي وصفت وعرفت كيفية إنشاء البنية التحتية للمطور من الصفر.
إعادة بناء منصات لاختبار الحمل والإنتاج.هذه هي المرحلة الرابعة التي كان من المفترض أن تستمر بعد الإلحاق ، ولكن تم تأجيلها حتى الآن ، حيث أن الربح منها ، الغريب بما فيه الكفاية ، هو أقل بكثير من تلك التي يتم إنشاؤها / إعادة إنشائها في كثير من الأحيان.
بدلاً من ذلك ، تحولنا إلى أنشطة المشروع: لقد انقسمنا إلى أوامر فرعية صغيرة وتناولنا مشاريع البنية التحتية العالمية التي لم يتم الوصول إليها من قبل. وبالطبع ، كانوا في الخدمة.
أدوات IaC الخاصة بنا
- Terraform .
- Packer Ansible .
- Jsonnet Python .
- Azure, .
- VS Code — IDE, , , , .
- — , .
ممارسات البرمجة المتطرفة في البنية التحتية
الشيء الرئيسي الذي جلبناه معنا كمبرمجين هو ممارسات البرمجة المتطرفة التي نستخدمها في عملنا. XP هو منهجية تطوير برمجية رشيقة تجمع بين ضغط أفضل مناهج التطوير والممارسات والقيم.
لا يوجد مبرمج واحد لم يستخدم على الأقل بعض ممارسات البرمجة المتطرفة ، حتى لو لم يكن يعرف عنها. في الوقت نفسه ، يتم تجاوز هذه الممارسات في عالم البنية التحتية ، على الرغم من حقيقة أنها تتداخل كثيرًا مع الممارسات من Google SRE.
هناك مقال منفصل عن كيفية تكييف XP للبنية التحتية .... ولكن بإيجاز: ممارسات XP تعمل من أجل كود البنية التحتية ، وإن كان ذلك مع قيود ، وتكييف ، لكنها تعمل. إذا كنت ترغب في تطبيقها في المنزل ، قم بدعوة الأشخاص ذوي الخبرة في تطبيق هذه الممارسات. يتم وصف معظم هذه الممارسات بطريقة أو بأخرى في نفس الكتاب على SRE .
كان يمكن أن تسير على ما يرام ، لكنها لا تعمل بهذه الطريقة.
المشاكل التقنية والتي من صنع الإنسان على الطريق
كان للمشروع نوعان من المشاكل:
- التقنية : قيود عالم "الحديد" ، ونقص المعرفة والأدوات الخام التي كان يجب استخدامها لعدم وجود الآخرين. هذه مشاكل شائعة لأي مبرمج.
- الإنسان : تفاعل الناس في الفريق. التواصل وصنع القرار والتدريب. مع هذا كان الأمر أسوأ ، لذلك نحن بحاجة إلى الخوض في مزيد من التفاصيل.
بدأنا في تطوير فريق الإعداد بالطريقة التي سنفعلها مع أي فريق آخر من المبرمجين. كنا نتوقع أن تكون هناك المراحل المعتادة لبناء فريق تاكمان : العاصفة والتطبيع ، وفي النهاية سنذهب إلى الإنتاجية والعمل المنتج. لذلك ، لم نقلق في البداية أنه كانت هناك بعض الصعوبات في الاتصال وصنع القرار والصعوبات من أجل التوصل إلى اتفاق.
مر شهرين ، لكن مرحلة العاصفة استمرت. فقط في نهاية المشروع ، أدركنا أن جميع المشاكل التي كنا نواجهها ولم ندرك أنها مرتبطة ببعضها البعض كانت نتيجة لمشكلة جذر مشتركة - اجتمعت مجموعتان من أشخاص مختلفين تمامًا في الفريق:
- المبرمجين ذوي الخبرة مع سنوات من الخبرة ، والتي طوروا من أجلها نهجهم وعاداتهم وقيمهم في العمل.
- مجموعة أخرى من عالم البنية التحتية بخبرتهم الخاصة. لديهم نتوءات مختلفة ، وعادات مختلفة ، ويعتقدون أيضًا أنهم يعرفون كيف يعيشون بشكل صحيح.
كان هناك صدام بين رأيين حول الحياة في فريق واحد. لم نرها على الفور ولم نبدأ العمل معها ، ونتيجة لذلك فقدنا الكثير من الوقت والطاقة والأعصاب.
لكن هذا التصادم لا يمكن تجنبه. إذا قمت بدعوة مبرمجين أقوياء ومهندسي بنية تحتية ضعيفة إلى المشروع ، فسيكون لديك تبادل للمعرفة في اتجاه واحد. على العكس من ذلك ، لا يعمل أيضًا - البعض يبتلع البعض الآخر وهذا كل شيء. وتحتاج إلى الحصول على نوع ما من المزيج ، لذلك عليك أن تكون مستعدًا لحقيقة أن "الطحن" يمكن أن يكون طويلًا جدًا (في حالتنا ، تمكنا من تثبيت الفريق بعد عام واحد فقط ، بينما نقول وداعًا لأحد أقوى المهندسين تقنيًا).
إذا كنت ترغب في تجميع مثل هذا الفريق فقط ، فلا تنس أن تتصل بمدرب قوي رشيق ، أو خبير سكروم ، أو معالج نفسي - وهو أشبه به. ربما سيساعدون.
نتائج التأهيل
بناءً على نتائج مشروع الإعداد (انتهى في أكتوبر 2019) ، قمنا بما يلي:
- لقد أنشأنا منتجًا برمجيًا كاملًا يدير البنية التحتية DEV الخاصة بنا ، مع خط أنابيب CI الخاص به ، والاختبارات والسمات الأخرى لمنتج برنامج عالي الجودة.
- لقد ضاعفنا عدد الأشخاص المستعدين للخدمة وأخرجنا العبء عن الفريق الحالي. بعد ستة أشهر ، أصبح هؤلاء الناس SREs كاملة. الآن يمكنهم أن يطفئوا النار في العارضة ، أو يستشيروا فريقًا من مبرمجي NFT ، أو كتابة مكتبتهم الخاصة للمطورين.
- SRE. , , .
- : , , , .
: ,
بعض الأفكار من المطور. لا تخطو على أشعل النار ، وأنقذ نفسك وأعصاب الآخرين والوقت.
البنية التحتية في الماضي. عندما كنت في سنتي الأولى (منذ 15 عامًا) وبدأت في تعلم جافا سكريبت ، كان لدي NotePad ++ و Firebug لتصحيح الأخطاء. حتى ذلك الحين ، كان من الضروري القيام ببعض الأشياء المعقدة والجميلة باستخدام هذه الأدوات.
بنفس الطريقة التي أشعر بها الآن عندما أعمل مع البنية التحتية. يتم تشكيل الأدوات الحالية فقط ، والعديد منها لم يتم إصداره حتى الآن ولديه الإصدار 0.12 (hi ، Terraform) ، والعديد من الميزات بانتظام يكسر التوافق مع الإصدارات السابقة.
بالنسبة لي ، كمطور للمؤسسات ، فإن استخدام مثل هذه الأشياء في همز هو أمر سخيف. ولكن ببساطة لا يوجد آخرون.
اقرأ الوثائق.كمبرمج ، نادرا ما وصلت إلى أرصفة. كنت أعرف أدواتي بعمق كافٍ: لغة البرمجة المفضلة وإطار العمل وقواعد البيانات المفضلة لدي. عادةً ما تتم كتابة جميع الأدوات الإضافية ، مثل المكتبات ، بنفس اللغة ، مما يعني أنه يمكنك دائمًا الاطلاع على شفرة المصدر. سيخبرك IDE دائمًا بالمعلمات المطلوبة وأين. حتى إذا كنت مخطئًا ، فسأكتشف ذلك بسرعة عن طريق إجراء اختبارات سريعة.
لن يعمل هذا في البنية التحتية ، فهناك عدد كبير من التقنيات المختلفة التي تحتاج إلى معرفتها. لكن من المستحيل معرفة كل شيء بعمق ، والكثير مكتوب بلغات غير معروفة. لذلك ، اقرأ بعناية (واكتب) الوثائق - بدون هذه العادة لا يعيشون طويلا هنا.
تعليقات رمز البنية التحتية أمر لا مفر منه.في عالم التنمية ، التعليقات هي علامة على كود سيئ. سرعان ما أصبحوا عتيقين ويبدأون في الكذب. هذه علامة على أن المطور لم يتمكن من التعبير عن أفكاره بطريقة أخرى. عند العمل مع البنية التحتية ، تعتبر التعليقات أيضًا علامة على رمز سيئ ، ولكن لا يمكنك الاستغناء عنها. بالنسبة للأدوات المتباينة التي ترتبط ببعضها البعض بشكل فضفاض ولا تعرف شيئًا عن بعضها البعض ، لا غنى عن التعليق.
غالبًا ما تكون الإعدادات المعتادة و DSL مخفية تحت الرمز. في هذه الحالة ، يحدث كل منطق في مكان أعمق ، حيث لا يوجد وصول. هذا يغير إلى حد كبير نهج التعليمات البرمجية والاختبار والعمل معها.
لا تخف من السماح للمطورين بالدخول إلى البنية التحتية.يمكنهم جلب ممارسات ومناهج مفيدة (وجديدة) من عالم تطوير البرمجيات. استخدم الممارسات والأساليب من Google ، الموصوفة في كتاب SRE ، واستفد وكن سعيدًا.
PS: , , , .
PPS: DevOpsConf 2019 . , , : , , DevOps-, .
PPPS: , DevOps-, DevOps Live 2020. : , - . , DevOps-. — « » .
, DevOps Live , , CTO, .