فكر SRE: نظرة على المشاريع من خلال عيون مهندس SRE

في مراجعات Slurm ، بدا Kubernetes عبارة: "تبين أن Kubernetes كان أسهل مما كنت أعتقد". الآن لم يعد يبدو ، أسطورة تعقيد k8s لم يعد. انتقل إلى فئة الأدوات سهلة التعلم ، من الصعب السيطرة عليها.

نريد أن نكرر نفس الشيء مع SRE. أظهر أن SRE أسهل وأكثر قابلية للفهم مما يبدو. قم بتغيير النموذج: دع الناس يرون المشروع من خلال عيون مهندس SRE.

كما هو الحال دائمًا في البداية ، هناك العديد من المجهولين في المعادلة. وكما هو الحال دائمًا في البداية ، سيذهب الأكثر إثارة للاهتمام أولاً.

في 3-5 فبراير ، سنستضيف Slurm SRE في موسكو. تكلفة تذكرة مكثفة لمدة ثلاثة أيام 60 ألف. ما الذي سيحصل عليه المشارك مقابل ماله؟

عندما أخبر الأصدقاء والزملاء عن SRE ، واجهت شكوكًا صحية:

• لأول مرة أسمع عن SRE ، إنه نوع من الخيمياء.
• يعد تطبيق SRE أمرًا صعبًا بالنسبة للعمالقة مثل Google.
• أنها مكلفة وطويلة ، وأنها لن تعطي الوقت ، وأنها لن تخصص ميزانية.
• ما تصفه جيد جدًا بحيث لا يكون صحيحًا.

أريد أن أطرح هذه الأسئلة.

حان الوقت لمعرفة ما هو SRE.

على مستوى الشعار: SRE هي واحدة من تطبيقات DevOps. لقد ظهر قبل 10 سنوات على Google ، ولكن في الآونة الأخيرة فقط اخترقت السوق "العادية" ، ويرجع ذلك في المقام الأول إلى كتاب Engine Reliability Site ، الذي أصدرته Google في عام 2016.

تم توضيح العلاقة بين SRE و DevOps جيدًا في هذا الفيديو:

الشيء السيئ هو أن الشعارات لا تعني شيئًا. حسنا DevOps ، حسنا ، التنفيذ ، القادم "للجميع الخير مقابل كل سيئة".

يمكنك قراءة الكتاب (وهو يستحق كل هذا العناء). لكن القارئ سوف يجد نفسه في موقف شخص يدرس الكاراتيه من الرسومات. يصف الكتاب المفهوم بدون تطبيق على الواقع. يقود المعلم اليد على طول مسار محدد ويشير إلى وجود أخطاء في العملية.

يشتمل السعر على مراجعة سريعة ومتعمقة لمنهج وأدوات SRE.

تطبيق SRE أسهل مما يبدو

على Slurm ، سوف نلمس SRE بأيدينا: سنختار المقاييس ، وننشئ قياساتها ، والتنبيهات ، ونواجه الحوادث ، ونحلها ونحللها ، ونعيد بناء المشروع وفقًا لجميع شرائع SRE.

أي أننا سنقدم تعليمات خطوة بخطوة يمكنك تنفيذها بمفردك عند العودة من مكثف.

انا اكذب في الواقع ، لن نقدم تعليمات ، ولكن عينة يمكنك من خلالها استنباط مجموعة من الأفكار والحلول.

السعر يشمل عينة للتنفيذ.

المشكلة الرئيسية هي أنه يجب عليك إقناع أولئك الذين لم يزوروا Slurm. لذلك ، من الناحية المثالية ، يستحق الأمر أن نتوصل كفريق كامل. لذلك ، نحن نقدم خصومات كبيرة للمجموعات.

سيكون من الجميل أن تأتي إلى سليرم بقيادة محطة الخدمة. والمدير التنفيذي مفيد أيضًا ، وحول هذا القسم ...

... كيف تقنع الإدارة العليا أن SRE مفيدة وضرورية.

عادة ما يكون هناك تعارض في المهام بين الرئيس التنفيذي (الإدارة العليا) ، STO (إدارة تكنولوجيا المعلومات) ، المطورين والتشغيل.

عمدا لا أقول "تضارب المصالح" ، إنه بالضبط تعارض في المهام.

الرئيس التنفيذي يحتاج إلى الأداء المالي. STO - موقف مفهومة وسهلة الإدارة ومريحة قدر الإمكان. وهذا هو ، مهام مفهومة مع قيمة الأعمال مفهومة ، الوفاء بالمواعيد النهائية ، كومة العادية ، المزيد من الميزات و fakaps أقل. يحتاج المطورون إلى طرح المزيد من الميزات والاستغلال - لضمان إمكانية الوصول (التي تتعارض بوضوح مع "المزيد من الميزات").

تقول SRE أن جميع المشاركين في العملية لديهم مهمة واحدة: سعادة المستخدم. يسعد المستخدم بتوازن صحي بين الميزات الجديدة وموثوقية الخدمة. سعيد المستخدم يدفع المزيد من المال. لإدارة سعادة المستخدم ، تحتاج إلى أدوات متخصصة.

علاوة على ذلك ، يتيح لك SRE ، استنادًا إلى المقاييس ، ترجمة المؤشرات المالية إلى مؤشرات مستهدفة للقياسات المختلفة ، وهي بدورها تؤدي إلى مهام فرق DevOps.

يسمح لك بالترجمة - لقد بالغت. يتيح لك وجود هذه المقاييس العثور على العلاقة بين حالة المقاييس والمؤشرات المالية. هذه مهمة منفصلة كبيرة ولكنها مفهومة.

هناك مشروع DORA ، DevOps Research & Evaluation ، وهو يُصدر دراسات سنوية حول القيمة بالنسبة للأعمال و ROI DevOps وفئته الفرعية SRE. نحن الآن نترجم التقرير الحالي إلى الروسية. هناك صيغ تقييم يمكن تطبيقها على شركتك بدرجة معينة من الدقة.

ملخص: يوفر SRE للشركات القدرة على إدارة الأداء المالي من خلال تحديد الأهداف المترية ، وفريق DevOps ، بالنظر إلى المقاييس الحالية ، يفهم بوضوح ما يجب القيام به لتحقيق أقصى فائدة للأداء المالي. أي مدير تنفيذي سيرفض مثل هذه الأداة؟

من الممكن الحصول على موارد لتطبيق SRE.

يتضمن سعر الدورة مجموعة من الحجج لصالح التحول إلى SRE و DevOps.

وحتى في الشركات الصغيرة ، يوجد مكان لـ SRE.

SRE ينقسم إلى الأدوات والثقافة والهيكل التنظيمي.

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

الثقافة هي أيضا مفيدة في أي شركة. سيتصرف المسؤول الكلاسيكي ، الذي يعد Prometheus ، وفقًا للمعيار: وسوف يشمل مراقبة استهلاك الذاكرة والقرص ، ومراقبة أخرى مألوفة. سيقوم مهندس SRE أولاً بمناقشة المؤشرات الرئيسية للعمليات التجارية مع الشركة ، ثم إعداد مراقبتها. من الواضح على الفور أن ثقافة هندسة SRE مفيدة حتى في الشركات الناشئة الصغيرة.

لكن الهيكل التنظيمي في الشركات الصغيرة قد لا يكون ضروريًا بل ضارًا. عندما يكون جميع الموظفين عمومية ، ليست هناك حاجة لتخصيص أوامر SRE بالقوة.

كل شيء نصفه يعمل بالفعل

تم إنشاء الدورة من قبل أولئك الذين نفذوا منذ فترة طويلة SRE في فرقهم وعاشوا طويلا في هذا النموذج. إيفان كروغلوف وبن تايلر ، كلاهما مطور رئيسي في Booking.com. يوجين فاراففا ، مطور واسع النطاق في جوجل. إدوارد ميدفيديف ، المدير الفني المساعد في Tungsten Labs ، الذي نشأ من مهندس SRE.

يحمل إدوارد ندوة عبر الإنترنت بعنوان "SRE - HYIP أم المستقبل؟" 12 ديسمبر في تمام الساعة 11:00.

عن البرنامج

أما بالنسبة للبرنامج. لقد تلقيت بالفعل آراء الخبراء بأن البرنامج لا يقاتل: إنه واسع للغاية وغير منطقي في بعض الأحيان. انها حقا.

في الواقع ، لدينا إطار للبرنامج ، مجموعة من الأفكار التي نريد الكشف عنها. أمامنا شهرين من العمل الشاق ، ونحن نستعد ، سيتم توضيح البرنامج: نزيل ما لا لزوم له ونحدد ما تبقى.

ولكن بالفعل في شكله الحالي ، فإن البرنامج يوضح بوضوح الاتجاه الذي نعمل به.

هل كل ما سبق يستحق المال؟

PS. ما علاقة مركز Kubernetes به؟

تتم جميع الممارسات في Kubernetes. أولئك الذين يملكون Kubernetes لديهم طريق مباشر لمهندسي SRE. بالنسبة لأولئك الذين لا يملكون ، انتقل إلى دورات Kubernetes الخاصة بنا.

التسجيل في Slurm SRE