بناءً على المناقشة في دردشة
AWS Minsk Communityفي الآونة الأخيرة ، كانت المعارك الحقيقية مستعرة لتعريف DevOps و SRE.
على الرغم من حقيقة أن المناقشات حول هذا الموضوع في العديد من النواحي قد اختتمت بالفعل ، بما في ذلك أنا ، قررت أن أحضر إلى مجتمع habr و رأيي في هذا الموضوع. بالنسبة لأولئك المهتمين ، مرحبا بكم في القط. ودع كل شيء يبدأ من جديد!
قبل التاريخ
لذلك ، في العصور القديمة ، كان هناك فريق منفصل من مطوري البرامج ومسؤولي الخادم يعيشون بشكل منفصل. السابق كتب بنجاح الكود ، هذا الأخير ، باستخدام مختلف الكلمات الدافئة ، الحميمة الموجهة إلى السابق ، وإعداد الخوادم ، ويأتي بشكل دوري للمطورين ويتلقى في المقابل "كل شيء يعمل على الجهاز الخاص بي". كان العمل في انتظار البرنامج ، وكان كل شيء خاملاً ، وكسر بشكل دوري ، وكان الجميع متوترين. وخاصة الشخص الذي دفع ثمن هذه الفوضى كلها. عصر المصباح المجيد. حسنًا ، نعم ، أنت تعرف من أين تنمو أرجل DevOps.
ممارسات DevOps الميلاد
ثم جاء أعمام جادون وقالوا أن هذه ليست صناعة ، فمن المستحيل العمل مثل هذا. وسحب نماذج دورة الحياة. على سبيل المثال ، نموذج V.
إذن ماذا نرى؟ العمل يأتي مع مفهوم ، وحلول تصميم المهندسين المعماريين والمطورين كتابة التعليمات البرمجية ، ثم الفشل. يقوم شخص ما باختبار المنتج بطريقة أو بأخرى ، ويقوم شخص ما بتسليمه للمستخدم النهائي بطريقة ما ، وفي مكان ما عند إخراج هذا النموذج المعجزة ، يوجد عميل تجاري وحيد ينتظر الطقس الذي وعد به البحر. لقد توصلنا إلى استنتاج مفاده أننا نحتاج إلى طرق تسمح بإنشاء هذه العملية. وقرروا إنشاء ممارسات من شأنها تنفيذها.
الانحدار الغنائي على ما هي الممارسة
من الناحية العملية ، أعني مجموعة من التكنولوجيا والانضباط. مثال على ذلك هو ممارسة وصف البنية التحتية برمز terraform. الانضباط هو كيفية وصف البنية التحتية باستخدام الكود ، وهي في رأس المطور ، والتكنولوجيا هي نفسها.
وقرروا أن يطلقوا عليها ممارسات DevOps - أعتقد أنها تعني من التطوير إلى العمليات. لقد توصلنا إلى أشياء صعبة مختلفة - ممارسات CI / CD ، وممارسات تستند إلى مبدأ IaC ، الآلاف منهم. وقد بدأ المطورون بكتابة الكود ، ويقوم مهندسو DevOps بتحويل وصف النظام في شكل كود إلى أنظمة عمل (نعم ، الكود هو ، لسوء الحظ ، مجرد وصف ، ولكن ليس تجسيد للنظام) ، والتسليم يدور ، وهكذا دواليك. قام مسؤولو الأمس ، بعد إتقانهم لممارسات جديدة ، بإعادة تدريبهم بفخر كمهندسين من DevOps ، وبدأ كل شيء. وكان هناك مساء ، وكان هناك صباح ... آسف ، وليس من هناك.
كل شيء مرة أخرى لا الحمد لله
بمجرد أن هدأت كل الأمور ، وبدأ "منهجيون" مختلفون في الكتابة في كتابة كتب سميكة حول ممارسات DevOps ، اندلعت النزاعات بهدوء ، وهو مهندس DevOps سيئ السمعة وأن DevOps هي ثقافة إنتاج ، وقد بدأ الاستياء من جديد. فجأة ، كان تسليم البرمجيات مهمة غير تافهة تمامًا. كل بنية تحتية للتطوير لها كومة خاصة بها ، تحتاج إلى تجميعها في مكان ما ، تحتاج إلى نشر البيئة في مكان ما ، هنا تحتاج إلى catcat ، لا تزال بحاجة إلى طريقة صعبة لبدء تشغيلها - بشكل عام ، يتصدع الرأس. والمشكلة ، الغريبة بما فيه الكفاية ، تحولت في المقام الأول إلى تنظيم العمليات - وظيفة التسليم هذه ، مثل عنق الزجاجة ، بدأت في عرقلة العمليات. بالإضافة إلى ذلك ، لم يتم إلغاء العملية (العمليات). غير مرئي في طراز V ، وهناك دورة حياة كاملة على اليمين. نتيجة لذلك ، من الضروري دعم البنية الأساسية بطريقة أو بأخرى ، والنظر إلى المراقبة ، وحل الحوادث ، وحتى التعامل مع التسليم. أي للجلوس مع قدم واحدة في التنمية والتشغيل - وفجأة تحولت هذه التنمية والعمليات. ثم كان هناك ضجة هائلة للخدمات الميكروية. ومعهم ، بدأ التطوير من الأجهزة المحلية في الانتقال إلى Cloud - حاول تصحيح شيء محليًا ، إذا كان هناك العشرات والمئات من الخدمات المجهرية ، يصبح التسليم المستمر هنا وسيلة للبقاء على قيد الحياة. بالنسبة لـ "الشركة الصغيرة المتواضعة" ، لا يزال الأمر مهمًا ، ولكن لا يزال؟ ماذا عن جوجل؟
جوجل SRE
لقد جاءت Google ، وتناولت أكبر صبار وقررت - لا نحتاج إلى ذلك ، نحن بحاجة إلى الموثوقية. ويجب أن تدار الموثوقية. وقررت - نحن بحاجة إلى متخصصين سيديرون الموثوقية. ودعا لهم المهندسين SR وقال ، هنا أنت ، تفعل ذلك كالمعتاد ، حسنا. هنا لديك SLI ، هنا لديك SLO ، هنا لديك المراقبة. وطخت أنفه في العمليات. ودعا له "موثوق DevOps" SRE. يبدو أن كل شيء على ما يرام ، ولكن هناك اختراقًا قذرًا يمكن لشركة Google تحمله - لتوظيف أشخاص لديهم مهارات مطورة
وخياطة أكثر قليلاً في المنزل ، ممن يعرفون طريقة عمل أنظمة العمل ، كمهندسين SR. علاوة على ذلك ، فإن توظيف مثل هؤلاء الأشخاص وجوجل نفسها يواجه مشاكل - لأن السبب هنا ينافس نفسه - من الضروري وصف منطق العمل لشخص ما. تم تعليق عملية التسليم من قِبل مهندسي الإصدار ، حيث يقوم المهندسون الخاصون بإدارة الموثوقية (بالطبع ، ليس بشكل مباشر ، ولكن التأثير على البنية التحتية ، وتغيير البنية ، وتتبع التغييرات والمؤشرات ، والتعامل مع الحوادث). لطيف ، يمكنك
كتابة الكتب . ولكن ماذا لو لم تكن غوغل ، ولكن ما زالت الموثوقية تقلق بطريقة ما؟
تطوير DevOps الأفكار
كان ذلك في الوقت المناسب بالنسبة لـ Docker ، الذي نشأ من lxc ، ومن ثم نظم تزامن مختلفة مثل Docker Swarm و Kubernetes ، ومهندسي DevOps - قام توحيد الممارسات بتسهيل عملية التسليم. المبسطة إلى حد أنه أصبح من الممكن حتى تسليم التسليم للمطورين - وهذا النشر. yaml هناك. حاويات يحل المشكلة. ونضج أنظمة CI / CD مكتوب بالفعل على مستوى ملف واحد وبدأ كل شيء - المطورين سوف يفعلون ذلك بأنفسهم. ثم نبدأ في التحدث كيف يمكننا أن نجعل SRE لدينا ، مع ... نعم ، على الأقل مع شخص ما.
SRE ليس على جوجل
حسنًا ، حسنًا ، لقد قمنا بتسليم التسليم ، ويبدو أننا نتنفس ، ونعود إلى الأيام الخوالي ، عندما شاهد المسؤولون تحميل المعالج ، وضبط الأنظمة ، وقاموا بهدوء بشيء غير مفهوم من الأكواب بسلام وهدوء ... توقف. لم نفعل أي شيء من أجل هذا (آسف!). اتضح فجأة أنه في نهج Google يمكننا أن نتخذ ممارسات ممتازة - ليس تحميل المعالج هو المهم ، وليس عدد المرات التي نغير فيها محركات الأقراص هناك أو في السحابة التي نحسن بها التكلفة ، ومقاييس العمل هي نفس SLx سيئة السمعة. ولم يخرج أحد منهم إدارة البنية التحتية منها ، ومن الضروري حل الحوادث ، وأن يكون في الخدمة بشكل دوري ، وبشكل عام ليكون في موضوع العمليات التجارية. والرجال ، بدء البرمجة قليلاً بمستوى جيد بالفعل ، كانت Google في انتظارك.
في الخلاصة. فجأة ، لكنك تعبت بالفعل من القراءة وأنت حريص على
البصق الكتابة إلى المؤلف في التعليق على المقال. DevOps كممارسة التسليم ، كان وسوف يكون. وهذا لا يحدث في أي مكان. SRE كمجموعة من ممارسات التشغيل يجعل هذا التسليم ناجحًا.