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