فك تشفير الويبينار "SRE - الضجيج أم المستقبل؟"

يحتوي الويبينار على صوت سيئ ، لذلك قمنا بفك تشفيره.

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

أولاً ، دعنا نتحدث عن كل ما يتعلق بـ SRE - Engineering Reliability Engineering. وكيف بدا كموقف منفصل ، كإتجاه منفصل. بدأ كل شيء بحقيقة أن Dev and Ops في دوائر التطوير التقليدية هما فريقان مختلفان تمامًا ، وعادة ما يكون لهما هدفان مختلفان تمامًا. هدف فريق التطوير هو طرح ميزات جديدة وتلبية احتياجات العمل. هدف فريق Ops هو أن يعمل كل شيء ولا يكسر أي شيء. من الواضح أن هذه الأهداف تتناقض بشكل مباشر مع بعضها البعض: من أجل أن ينجح كل شيء ولا شيء ينكسر ، فإن طرح ميزات جديدة هو الأفضل بأقل قدر ممكن. لهذا السبب ، هناك العديد من الصراعات الداخلية التي تحاول المنهجية ، والتي تسمى الآن DevOps ، حلها.

المشكلة هي أنه ليس لدينا تعريف واضح لـ DevOps وتطبيق واضح لـ DevOps. لقد تحدثت في مؤتمر عقد في يكاترينبرج منذ عامين ، وحتى الآن بدأ قسم DevOps بعرض "ما هو DevOps". في عام 2017 ، يبلغ عمر devo ما يقرب من 10 سنوات ، لكننا ما زلنا نجادل ما هو عليه. وهذا موقف غريب للغاية حاولت Google حله قبل عدة سنوات.

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

اتضح أن نموذج DevOps في فرق SRE يتم تنفيذه من خلال حقيقة أن هناك مهندسين يعملون على حل المشكلات الهيكلية. هنا هو ، العلاقة بين Dev و Ops التي يتحدث عنها الناس منذ 8 سنوات. يشبه دور SRE دور المهندس المعماري بمعنى أن القادمين الجدد إلى SRE لا يفعلون ذلك. الناس في بداية الحياة المهنية ليس لديهم أي خبرة ، وليس لديهم المعرفة اللازمة. لأن SRE يتطلب معرفة دقيقة جدًا لما يمكن أن يحدث بشكل صحيح ومتى. لذلك ، هناك حاجة إلى بعض الخبرة هنا ، كقاعدة عامة ، سواء داخل الشركة أو خارجها.

يسألون عما إذا كان سيتم وصف الفرق بين SRE و devops. لقد تم وصفها للتو. يمكننا التحدث عن مكان SRE في المنظمة. على عكس نهج DevOps الكلاسيكي ، حيث لا تزال Ops قسمًا منفصلًا ، تعد SRE جزءًا من فريق التطوير. يشاركون في تطوير المنتجات. يوجد أيضًا نهج حيث SRE هو الدور الذي ينتقل من مطور إلى آخر. يشاركون في مراجعات الكود بنفس الطريقة ، على سبيل المثال ، مصممي UX ومطوري البرامج أنفسهم وفي بعض الأحيان مديري المنتجات. يعمل SRE في نفس المستوى. نحتاج إلى تحديثهم ، نحتاج إلى مراجعتهم ، بحيث يقول لكل توزيع SRE: "حسنًا ، لن يؤثر هذا المنتج سلبًا على الموثوقية. وإذا كان الأمر كذلك ، فإلى حد ما ". سوف نتحدث أيضا عن هذا.

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

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

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

والسؤال هو ، لماذا لا توظف مهندسًا أو مسؤولًا عن النظام لديه الكثير من المعرفة في الفريق. يقال لنا أن المطور في دور المهندس ليس هو أفضل حل للتوظيف. المطور في دور المهندس ليس دائمًا أفضل حل للتوظيف ، ولكن النقطة هنا هي أن المطور الذي يتعامل مع Ops لديه رغبة أكثر قليلاً في الأتمتة ، ولديه المزيد من المعرفة والمهارات من أجل تنفيذ هذه الأتمتة. وبناءً على ذلك ، فإننا لا نقوم بتقليل الوقت اللازم لأية عمليات محددة فحسب ، وليس الروتين فحسب ، ولكن أيضًا معايير العمل الهامة مثل MTTR (متوسط ​​وقت الاسترداد ، وقت الاسترداد). وبالتالي ، وسيكون هذا أيضًا بعد ذلك بقليل ، فإننا نوفر المال للمنظمة.

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

هذا كله خطأ ، بالطبع. وهؤلاء الناس في كثير من الأحيان لدغات مثل هذا في الممارسة العملية ، لأن الأشياء تتحطم. الأشياء تنكسر في بعض الأحيان بطرق لا يمكن التنبؤ بها. في بعض الأحيان يقول الناس لا ، هذا لن يحدث أبدا. وهذا كله يحدث بالضبط. يحدث ذلك في كثير من الأحيان. وبالتالي ، لا أحد يسعى جاهداً لتوفير 100٪ ، لأن التوافر 100٪ لا يحدث أبدًا. هذا هو المعيار. وبالتالي ، عندما نتحدث عن توفر الخدمة ، نتحدث دائمًا عن تسعة. 2 تسع ، 3 تسع ، 4 تسع ، 5 تسع. إذا قمت بترجمة هذا إلى وقت تعطل ، فعلى سبيل المثال ، 5 تسع ، ثم هذا أكثر بقليل من 5 دقائق من التعطل في السنة ، 2 تسعين هو 3.5 أيام من التوقف.

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

سؤال مهم في هذه الحالة هو ما مدى موثوقية المكونات المتبقية. نظرًا لأن الفرق بين 4 و 5 تسع لن يكون مرئيًا على الهاتف الذكي مع 2 من الموثوقية. بمعنى تقريبي ، إذا حدث شيء ما على هاتف ذكي في خدمتك 10 مرات في السنة ، فمن المحتمل أن يكون الفشل قد حدث 8 مرات على وجه التحديد في جانب نظام التشغيل. اعتاد المستخدم على ذلك ، ولن ينتبه مرة واحدة في السنة. من الضروري ربط سعر زيادة الموثوقية وزيادة الأرباح.
فقط في كتاب SRE هناك مثال جيد على الزيادة إلى 4 تسع من 3 تسع. اتضح أن الزيادة في توافر أقل قليلا من 0.1 ٪. وإذا كانت إيرادات الخدمة 1 مليون دولار في السنة ، فستكون الزيادة في الإيرادات 900 دولار. إذا كانت زيادة إمكانية الوصول بنسبة تسعة تكلفنا أقل من 900 دولار في السنة ، فإن هذه الزيادة تكون منطقية من الناحية المالية. إذا كانت التكلفة تزيد على 900 دولار في السنة ، فلن يكون ذلك منطقيًا ، لأن نمو الإيرادات لا يعوض ببساطة تكاليف العمالة وتكاليف الموارد. و 3 تسعة ستكون كافية بالنسبة لنا.

هذا بالطبع مثال مبسط حيث تساوي جميع الاستعلامات. من 3 إلى تسعة ، من السهل جدًا التبديل ، ولكن في الوقت نفسه ، على سبيل المثال ، فإن التحول من 2 إلى 3 هو بالفعل وفورات قدرها 9 آلاف دولار ، يمكن أن يكون ذلك منطقيًا. بطبيعة الحال ، في الواقع ، فشل طلب التسجيل أسوأ من الفشل في عرض صفحة ؛ الطلبات لها وزن مختلف. قد يكون لديهم معايير مختلفة تمامًا عن وجهة نظر العمل ، ولكن لا يزال ، كقاعدة عامة ، إذا كنا لا نتحدث عن أي خدمات محددة ، فهذا تقريب يمكن الاعتماد عليه إلى حد ما.
لقد تلقينا سؤالًا عما إذا كان SRE أحد المنسقين عند اختيار حل معماري لخدمة ما. دعنا نفترض فيما يتعلق بالتكامل في البنية التحتية الحالية بحيث لا توجد خسارة في استقرارها. نعم ، SREs لها نفس التأثير على طلبات السحب والتعهدات والإصدارات ، كما أنها تؤثر على الهندسة المعمارية ، وتقديم خدمات جديدة ، وخدمات مصغرة ، وإدخال حلول جديدة. لماذا قلت قبل ذلك أنني بحاجة إلى الخبرة ، أحتاج إلى مؤهلات. في الواقع ، تعد SRE أحد أصوات الحظر في أي حل معماري وبرمجي. وفقًا لذلك ، يجب على SRE كمهندس ، أولاً وقبل كل شيء ، ألا يفهم فقط ، بل يجب أن يفهم أيضًا كيف ستؤثر أي حلول محددة على الموثوقية والاستقرار ، وفهم كيفية ارتباط ذلك باحتياجات العمل ، ومن وجهة نظر ما يمكن أن يكون يجوز ، ومع ما لا.

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

دعنا نقول جيش تحرير السودان يمكن أن يكون مثل هذا. الخدمة متاحة 99.95 ٪ من الوقت على مدار السنة. أو سيتم إغلاق 99 تذكرة دعم حرجة في غضون 3 ساعات في الربع. أو سيتم الرد على 85 ٪ من الطلبات في غضون 1.5 ثانية كل شهر. وهذا يعني أننا نفهم تدريجياً أن الأخطاء والإخفاقات طبيعية تمامًا. هذا وضع مقبول ، نحن نخطط له ، بل نعول عليه إلى حد ما. أي أن SRE تبني أنظمة يمكنها ارتكاب أخطاء ، والتي يجب أن تستجيب بشكل طبيعي للأخطاء التي يجب أن تأخذها في الاعتبار. وإذا كان ذلك ممكنًا ، فيجب عليهم التعامل مع الأخطاء بطريقة إما أن المستخدم لا يلاحظها أو يلاحظها ، ولكن هناك بعض الحلول بسبب أن كل شيء لن يسقط بالكامل.

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

تعتبر المصطلحات التالية التي سنتحدث عنها مهمة جدًا للعمل مع الموثوقية ، مع الأخطاء ، مع التوقعات وهي MTBF و MTTR. MTBF هو الوقت المتوسط ​​بين الفشل. MTTR متوسط ​​وقت الاسترداد ، متوسط ​​وقت الاسترداد. وهذا يعني ، كم من الوقت قد مر من لحظة اكتشاف الخطأ ، من اللحظة التي ظهر فيها الخطأ إلى اللحظة التي تمت فيها استعادة الخدمة بالكامل إلى وضعها الطبيعي. يتم إصلاح MTBF في الغالب من خلال العمل على جودة الرمز. هذا هو ، في أن SRE يمكن أن يقول لا. وتحتاج إلى فهم الفريق بأكمله أنه عندما تقول SRE "لا" ، فإنه يقول هذا ليس لأنه ضار ، ليس لأنه سيء ​​، ولكن لأن الجميع سيعانون.

مرة أخرى ، هناك الكثير من المقالات ، والكثير من الطرق ، والكثير من الطرق ، حتى في الكتاب ذاته الذي أشير إليه كثيرًا ، حول كيفية منع المطورين الآخرين من البدء في كره SRE. MTTR ، من ناحية أخرى ، تعمل على SLO (هدف مستوى الخدمة). وهذا هو الغالب الأتمتة. لأن ، على سبيل المثال ، SLO لدينا هو وقت التشغيل من 4 تسع في الربع. هذا يعني أنه في 3 أشهر يمكننا السماح لمدة 13 دقيقة من التوقف. واتضح أننا لا نستطيع الحصول على MTTR لأكثر من 13 دقيقة. إذا استجبنا لوقت توقف واحد على الأقل لمدة 13 دقيقة ، فهذا يعني أننا استنفدنا بالفعل الميزانية بالكامل للربع. نحن نكسر SLO. 13 دقيقة لرد الفعل وتحديد الفشل هو الكثير للسيارة ، ولكن القليل جدا للشخص. نظرًا لطول مدة التنبيه إلى شخص ما ، أثناء تفاعله ، إلى أن يدرك الخطأ ، فإن هذا يستغرق عدة دقائق بالفعل. إلى أن يفهم الشخص كيفية إصلاحه ، وما الذي يجب إصلاحه بالضبط ، وما يجب القيام به ، فإن هذا يستغرق بضع دقائق أخرى. في الواقع ، حتى لو كنت بحاجة فقط إلى إعادة تشغيل الخادم ، كما اتضح ، أو رفع عقدة جديدة ، فإن MTTR اليدوي يستغرق بالفعل حوالي 7-8 دقائق. عند أتمتة العملية ، يصل MTTR غالبًا إلى الثانية ، وأحيانًا إلى ملي ثانية. غوغل يتحدث عادة عن ميلي ثانية ، ولكن في الواقع ، الأمور ليست جيدة.

من الناحية المثالية ، يجب على SRE أتمتة عملها بالكامل تقريبًا ، لأنه يؤثر بشكل مباشر على MTTR ، ومقاييسه ، و SLO للخدمة بأكملها ، وبالتالي على ربح العمل. إذا تم تجاوز الوقت ، اسألنا إذا كان اللوم يقع على عاتق SRE. للأبد ، لا أحد يلوم. وهذه هي ثقافة منفصلة تسمى بلا تشريح الجثة ، والتي لن نتحدث عنها اليوم ، ولكننا سنحلل في Slurme. هذا موضوع مثير للاهتمام للغاية ويمكن الحديث عنه كثيرًا. بمعنى تقريبي ، إذا تم تجاوز الوقت المخصص لربع السنة ، فعلى الجميع إلقاء اللوم على القليل ، مما يعني أن إلقاء اللوم على الجميع ليس منتجًا ، دعونا بدلاً من ذلك ، ربما لا نلوم أحداً ، ولكن صحح الموقف ونتعامل مع ما لدينا. في تجربتي ، فإن هذا النهج بالنسبة لمعظم الفرق ، وخاصة في روسيا ، غريب بعض الشيء ، لكنه منطقي ويعمل بشكل جيد للغاية. لذلك ، سأوصي في نهاية المقالة والأدبيات التي يمكن قراءتها حول هذا الموضوع. أو تعال إلى Slurm SRE.

ساوضح. إذا تم تجاوز وقت SLO كل ثلاثة أشهر ، إذا لم تكن فترة التوقف 13 دقيقة ، ولكن 15 ، فمن المسؤول عن هذا؟ بالطبع ، يمكن أن يكون SRE هو المسؤول ، لأنه من الواضح أنه ارتكب نوعًا من الالتزام السيئ أو النشر. قد يكون المسؤول عن مركز البيانات مسؤولاً عن هذا ، لأنه ربما ، قد تم إجراء بعض الصيانة غير المجدولة. إذا كان المسؤول عن مركز البيانات هو المسؤول ، فإن الشخص الذي لم يحسب الصيانة عند تنسيق SLO هو المسؤول. المدير أو المدير الفني أو أي شخص قام بالتوقيع على عقد مركز البيانات ولم ينتبه إلى حقيقة أن مركز بيانات SLA غير مصمم للتوقف عن العمل المطلوب هو المسؤول. تبعا لذلك ، شيئا فشيئا الجميع هو المسؤول عن هذا الوضع. وهذا يعني أنه لا معنى لإلقاء اللوم على أي شخص في هذا الموقف. ولكن بالطبع تحتاج إلى إصلاحه. لذلك ، هناك بعد الوفاة. وإذا قرأت ، على سبيل المثال ، جثة "جيثب" بعد الوفاة ، والتي تعتبر دائمًا قصة مثيرة جدًا وصغيرة وغير متوقعة في كل حالة معينة ، فيمكنك أن تحل محل أن لا أحد يقول إن هذا الشخص بالتحديد هو المسؤول. يتم تعيين الذنب دائمًا لعمليات غير كاملة.

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

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

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

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

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

اتضح أن التجريب في الإنتاج هو جزء مهم إلى حد ما ويكاد لا يتجزأ من SRE في فرق كبيرة. وعادة ما يطلق عليها اسم "الفوضى" ، والتي جاءت من فريق Netflix الذي أصدر أداة مساعدة تسمى Chaos Monkey.
يتصل Chaos Monkey بخط أنابيب CI / CD ويقوم بإسقاط الخادم بشكل عشوائي في الإنتاج. مرة أخرى ، في بنية SRE ، نتحدث عن حقيقة أن الخادم الذي تم تعطله ليس سيئًا بحد ذاته ، فمن المتوقع. وإذا تم تضمينها في الميزانية ، فهي مقبولة ولا تضر بالأعمال. , , , , , .

- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .

: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .

, , . , SRE , , . , , . , , , , , , .

, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .

. , - , , Objectives, , 3 .

, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .

3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .

, , , , , . , . . . . . , .

, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.

, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .

, , , . - , - . SRE, -, , . , , , .

. , , , , , , . . , . canary, , , , - , , , . , , , , .

SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .

. - . , SRE . , , . , , , , , , . SRE.

SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .

2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.

: SRE as a life choice

, . , - . , , . . .
.

PS: , , . , , SRE .