صوت الندوة عبر الويب ضعيف، لذلك قمنا بنسخها.
اسمي ميدفيديف إدوارد. سأتحدث اليوم عن ماهية SRE، وكيف ظهرت SRE، وما هي معايير العمل التي يمتلكها مهندسو SRE، والقليل عن معايير الموثوقية، والقليل عن مراقبتها. سنمشي على القمم، لأنه لا يمكنك معرفة الكثير خلال ساعة، لكنني سأقدم مواد لمراجعة إضافية، ونحن جميعًا في انتظارك . في موسكو في نهاية يناير/كانون الثاني.
أولاً، دعونا نتحدث عن ماهية SRE - هندسة موثوقية الموقع. وكيف ظهر كموضع منفصل، كإتجاه منفصل. بدأ كل شيء بحقيقة أنه في دوائر التطوير التقليدية، يعد Dev وOps فريقين مختلفين تمامًا، وعادة ما يكون لهما هدفان مختلفان تمامًا. هدف فريق التطوير هو طرح ميزات جديدة وتلبية احتياجات العمل. هدف فريق العمليات هو التأكد من أن كل شيء يعمل ولا شيء ينكسر. من الواضح أن هذه الأهداف تتعارض بشكل مباشر مع بعضها البعض: لكي يعمل كل شيء ولا يتعطل أي شيء، قم بطرح ميزات جديدة بأقل قدر ممكن. ولهذا السبب، هناك العديد من الصراعات الداخلية التي تحاول المنهجية التي تسمى الآن DevOps حلها.
المشكلة هي أنه ليس لدينا تعريف واضح لـ DevOps وتنفيذ واضح لـ DevOps. لقد تحدثت في مؤتمر في يكاترينبرج منذ عامين، وحتى الآن بدأ قسم DevOps بتقرير "ما هو DevOps". في عام 2، بلغ عمر Devops 2017 سنوات تقريبًا، لكننا ما زلنا نتجادل حول ماهيته. وهذا موقف غريب للغاية حاولت Google حله منذ بضع سنوات.
في عام 2016، أصدرت جوجل كتابًا بعنوان هندسة موثوقية الموقع. وفي الواقع، بدأت حركة SRE بهذا الكتاب. SRE هو تطبيق محدد لنموذج DevOps في شركة معينة. يلتزم مهندسو SRE بضمان عمل الأنظمة بشكل موثوق. ويأتي معظمهم من المطورين، وفي بعض الأحيان من المسؤولين الذين يتمتعون بخلفية تطويرية قوية. وهم يفعلون ما كان يفعله مسؤولو النظام، لكن الخلفية القوية في التطوير ومعرفة النظام من حيث الكود تؤدي إلى حقيقة أن هؤلاء الأشخاص لا يميلون إلى العمل الإداري الروتيني، بل يميلون إلى الأتمتة.
اتضح أن نموذج DevOps في فرق SRE يتم تنفيذه من خلال وجود مهندسي SRE الذين يحلون المشكلات الهيكلية. ها هي نفس العلاقة بين Dev وOps التي تحدث عنها الناس لمدة 8 سنوات. يشبه دور SRE دور المهندس المعماري حيث لا يصبح القادمون الجدد شركات SRE. الأشخاص في بداية حياتهم المهنية ليس لديهم أي خبرة بعد، وليس لديهم اتساع المعرفة اللازمة. لأن SRE يتطلب معرفة دقيقة للغاية بما يمكن أن يحدث بالضبط ومتى يمكن أن يحدث خطأ. لذلك، هناك حاجة إلى بعض الخبرة هنا، كقاعدة عامة، سواء داخل الشركة أو خارجها.
يسألون ما إذا كان سيتم وصف الفرق بين SRE وdevops. لقد تم وصفها للتو. يمكننا التحدث عن مكانة SRE في المنظمة. على عكس نهج DevOps الكلاسيكي هذا، حيث لا تزال العمليات قسمًا منفصلاً، فإن SRE جزء من فريق التطوير. إنهم يشاركون في تطوير المنتج. حتى أن هناك نهجًا يكون فيه SRE دورًا ينتقل من مطور إلى آخر. إنهم يشاركون في مراجعات التعليمات البرمجية بنفس الطريقة التي يشارك بها، على سبيل المثال، مصممو UX والمطورون أنفسهم، وأحيانًا مديرو المنتجات. تعمل SREs على نفس المستوى. نحن بحاجة إلى الموافقة عليها، ونحن بحاجة إلى مراجعتها، بحيث تقول SRE لكل عملية نشر: "حسنًا، هذا النشر، لن يؤثر هذا المنتج سلبًا على الموثوقية. وإذا حدث ذلك، ففي حدود مقبولة. سنتحدث أيضًا عن هذا.
وبناءً على ذلك، تتمتع SRE بحق النقض لتغيير الكود. وبشكل عام، يؤدي هذا أيضًا إلى نوع من الصراع الصغير إذا تم تنفيذ SRE بشكل غير صحيح. في نفس الكتاب عن هندسة موثوقية الموقع، هناك أجزاء كثيرة، ولا حتى جزء واحد، توضح كيفية تجنب هذه التعارضات.
يسألون عن كيفية ارتباط SRE بأمن المعلومات. لا تشارك SRE بشكل مباشر في أمن المعلومات. في الأساس، في الشركات الكبيرة، يتم ذلك من قبل الأفراد والمختبرين والمحللين. لكن SRE تتفاعل معها أيضًا بمعنى أن بعض العمليات وبعض الالتزامات وبعض عمليات النشر التي تؤثر على الأمان يمكن أن تؤثر أيضًا على توفر المنتج. لذلك، تتفاعل SRE ككل مع أي فريق، بما في ذلك فرق الأمن، بما في ذلك المحللين. لذلك، هناك حاجة إلى SREs بشكل أساسي عندما يحاولون تنفيذ DevOps، ولكن في الوقت نفسه، يصبح العبء على المطورين كبيرًا جدًا. وهذا يعني أن فريق التطوير نفسه لم يعد قادرًا على التعامل مع حقيقة أنهم الآن بحاجة أيضًا إلى أن يكونوا مسؤولين عن العمليات. وهناك دور منفصل. تم التخطيط لهذا الدور في الميزانية. في بعض الأحيان يتم تحديد هذا الدور بحجم الفريق، ويظهر شخص منفصل، وأحيانا يصبح أحد المطورين. هكذا يظهر SRE الأول في الفريق.
إن تعقيد النظام الذي يتأثر بـ SRE، والتعقيد الذي يؤثر على موثوقية العملية، أمر ضروري وعرضي. التعقيد الضروري هو عندما يزيد تعقيد المنتج إلى الحد الذي تتطلبه ميزات المنتج الجديدة. التعقيد العشوائي هو عندما يزداد تعقيد النظام، لكن ميزة المنتج ومتطلبات العمل لا تؤثر بشكل مباشر على ذلك. اتضح أن المطور ارتكب خطأ في مكان ما، أو أن الخوارزمية ليست مثالية، أو يتم تقديم بعض الاهتمامات الإضافية التي تزيد من تعقيد المنتج دون حاجة خاصة. يجب على SRE الجيد أن يقطع هذا الموقف دائمًا. وهذا يعني أنه يجب حظر أي التزام، أو أي نشر، أو أي طلب سحب، حيث تزداد الصعوبة بسبب الإضافة العشوائية.
والسؤال هو لماذا لا نقوم فقط بتعيين مهندس ومسؤول نظام يتمتع بقدر كبير من المعرفة في الفريق. قيل لنا إن قيام المطور بدور المهندس ليس هو الحل الأفضل للتوظيف. لا يعد المطور الذي يلعب دور المهندس دائمًا أفضل حل للتوظيف، ولكن النقطة هنا هي أن المطور الذي يشارك في العمليات لديه رغبة أكبر قليلاً في الأتمتة، ولديه المزيد من المعرفة ومجموعة المهارات اللازمة للتنفيذ هذه الأتمتة. وبناء على ذلك، فإننا لا نقوم فقط بتقليل الوقت لبعض العمليات المحددة، وليس فقط الروتين، ولكن أيضًا معلمات الأعمال المهمة مثل MTTR (متوسط وقت الاسترداد، وقت الاسترداد). وهكذا، وسنتحدث أيضًا عن هذا بعد قليل، فإننا نوفر المال للمنظمة.
الآن دعونا نتحدث عن معايير تشغيل SRE. وقبل كل شيء عن الموثوقية. في الشركات الصغيرة، الشركات الناشئة، غالبًا ما يحدث أن يفترض الناس أنه إذا تمت كتابة الخدمة جيدًا، وإذا تمت كتابة المنتج جيدًا وبشكل صحيح، فسوف يعمل، ولن ينكسر. هذا كل شيء، نكتب كودًا جيدًا، لذلك لا يوجد شيء يمكن كسره. الكود بسيط للغاية، لا يوجد شيء يمكن كسره. هؤلاء هم نفس الأشخاص تقريبًا الذين يقولون إننا لا نحتاج إلى اختبارات، لأنه، انظر، هذه هي طرق VPI الثلاثة، لماذا نتوقف هنا.
وهذا كله خطأ بالطبع. وغالبًا ما يتعرض هؤلاء الأشخاص للعض من خلال هذا الرمز في الممارسة العملية، لأن الأشياء تنكسر. تنكسر الأشياء أحيانًا بطرق لا يمكن التنبؤ بها. في بعض الأحيان يقول الناس لا، لن يحدث ذلك أبدًا. ويحدث ذلك في كل وقت. يحدث ذلك في كثير من الأحيان بما فيه الكفاية. ولهذا السبب لا يسعى أحد أبدًا إلى الوصول إلى نسبة 100% من التوفر، لأن التوفر بنسبة 100% لا يحدث أبدًا. هذا هو المعيار. ولذلك، عندما نتحدث عن توفر الخدمة، فإننا نتحدث دائمًا عن التسعات. 2 تسعات، 3 تسعات، 4 تسعات، 5 تسعات. إذا قمنا بترجمة هذا إلى وقت التوقف عن العمل، على سبيل المثال، 5 تسعات، فهذا يزيد قليلاً عن 5 دقائق من التوقف سنويًا، 2 تسعات هي 3,5 يومًا من التوقف.
ولكن من الواضح أنه في مرحلة ما يكون هناك انخفاض في العائد على الاستثمار. الانتقال من تسعتين إلى ثلاث تسعات يعني توقفًا أقل بأكثر من 3 أيام. يؤدي الانتقال من أربع تسعات إلى خمس إلى تقليل وقت التوقف عن العمل بمقدار 47 دقيقة سنويًا. واتضح أن هذا قد لا يكون بالغ الأهمية بالنسبة للأعمال. وبشكل عام، الموثوقية المطلوبة ليست مشكلة فنية، فهي في المقام الأول مشكلة تجارية، إنها مشكلة منتج. ما هو مستوى التوقف المقبول لمستخدمي المنتج، وما يتوقعونه، والمبلغ الذي يدفعونه، على سبيل المثال، مقدار الأموال التي يخسرونها، ومقدار الأموال التي يخسرها النظام.
السؤال المهم هنا هو ما هي موثوقية المكونات المتبقية. لأن الفرق بين 4 و 5 تسعات لن يكون مرئيًا على الهاتف الذكي الذي يتمتع بتسعتين من الموثوقية. بشكل تقريبي، إذا تعطل شيء ما على الهاتف الذكي في خدمتك 2 مرات في السنة، فمن المرجح أن يحدث العطل 10 مرات على جانب نظام التشغيل. لقد اعتاد المستخدم على ذلك، ولن ينتبه لمرة أخرى في السنة. من الضروري ربط سعر زيادة الموثوقية وزيادة الأرباح.
فقط في كتاب SRE يوجد مثال جيد لزيادة العدد إلى 4 تسعات من 3 تسعات. وتبين أن الزيادة في التوافر أقل بقليل من 0,1٪. وإذا كانت إيرادات الخدمة مليون دولار سنويا، فإن الزيادة في الإيرادات هي 1 دولار. إذا كان الأمر يكلفنا أقل من 900 دولار سنويا لزيادة القدرة على تحمل التكاليف بمقدار تسعة، فإن هذه الزيادة منطقية من الناحية المالية. إذا كان الأمر يستحق أكثر من 900 دولار سنويا، فلم يعد من المنطقي، لأن الزيادة في الإيرادات ببساطة لا تعوض تكاليف العمالة، وتكاليف الموارد. وسوف تكون 900 تسعات كافية بالنسبة لنا.
وهذا بالطبع مثال مبسط حيث تكون جميع الطلبات متساوية. والانتقال من 3 تسعات إلى 4 تسعات أمر سهل بما فيه الكفاية، ولكن في الوقت نفسه، على سبيل المثال، الانتقال من 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. من ناحية أخرى، يتعلق MTTR بالعمل على SLOs (هدف مستوى الخدمة). وهي في الغالب أتمتة. لأنه، على سبيل المثال، SLO الخاص بنا هو وقت تشغيل يبلغ 4 تسعات لكل ربع سنة. هذا يعني أنه خلال 3 أشهر يمكننا السماح بـ 13 دقيقة من التوقف. وتبين أن MTTR لا يمكن أن يكون أكثر من 13 دقيقة. إذا استجبنا لتوقف واحد على الأقل خلال 13 دقيقة، فهذا يعني أننا قد استنفدنا بالفعل الميزانية الكاملة لهذا الربع. نحن نكسر SLO. 1 دقيقة للرد وإصلاح العطل هي فترة طويلة بالنسبة للآلة، ولكنها قصيرة جدًا بالنسبة للإنسان. لأنه حتى يتلقى الشخص تنبيهًا، حتى يتفاعل، حتى يفهم الخطأ، فهي بالفعل عدة دقائق. حتى يفهم الشخص كيفية إصلاحه، ما يجب إصلاحه بالضبط، ما يجب القيام به، فهذه بضع دقائق أخرى. وفي الواقع، حتى لو كنت بحاجة فقط إلى إعادة تشغيل الخادم، كما اتضح، أو رفع عقدة جديدة، فإن MTTR يدويًا يستغرق حوالي 13-7 دقائق. عند أتمتة العملية، غالبا ما يصل MTTR إلى ثانية، وأحيانا ميلي ثانية. يتحدث Google عادة عن ميلي ثانية، ولكن في الواقع، بالطبع، كل شيء ليس على ما يرام.
من الناحية المثالية، يجب على SRE أتمتة عملها بالكامل تقريبا، لأن هذا يؤثر بشكل مباشر على MTTR، ومقاييسها، و SLO للخدمة بأكملها، وبالتالي، ربح الأعمال. إذا تم تجاوز الوقت، يتم سؤالنا عما إذا كان SRE على خطأ. ولحسن الحظ، لا أحد هو المسؤول. وهذه ثقافة منفصلة تسمى ما بعد الوفاة عديمة الريح، والتي لن نتحدث عنها اليوم، لكننا سنحللها على Slurm. هذا موضوع مثير للاهتمام للغاية ويمكن التحدث عنه كثيرًا. بشكل تقريبي، إذا تم تجاوز الوقت المخصص لكل ربع سنة، فسيتم إلقاء اللوم على القليل من الجميع، مما يعني أن إلقاء اللوم على الجميع ليس مثمرًا، وبدلاً من ذلك، ربما لا نلوم أي شخص، ولكن نصحح الوضع ونعمل بما لدينا. من خلال تجربتي، يعتبر هذا النهج غريبًا بعض الشيء على معظم الفرق، خاصة في روسيا، لكنه منطقي ويعمل بشكل جيد للغاية. لذلك سأوصي في نهاية المقال والأدب الذي يمكنك قراءته حول هذا الموضوع. أو تعال إلى Slurm SRE.
دعني أشرح. إذا تم تجاوز وقت SLO لكل ربع سنة، إذا لم يكن وقت التوقف عن العمل 13 دقيقة، ولكن 15، فمن يمكن إلقاء اللوم على ذلك؟ بالطبع، قد يقع اللوم على SRE، لأنه ارتكب نوعًا من الالتزام أو النشر السيئ. قد يكون مسؤول مركز البيانات هو المسؤول عن ذلك، لأنه ربما قام بنوع من الصيانة غير المجدولة. إذا كان مسؤول مركز البيانات هو المسؤول عن ذلك، فإن الشخص من العمليات هو المسؤول عن ذلك، والذي لم يحسب الصيانة عندما قام بتنسيق SLO. يقع اللوم على المدير أو المدير الفني أو الشخص الذي وقع عقد مركز البيانات ولم ينتبه إلى حقيقة أن اتفاقية مستوى الخدمة الخاصة بمركز البيانات غير مصممة لفترة التوقف المطلوبة. وبناء على ذلك، يقع اللوم على كل شيء شيئا فشيئا في هذه الحالة. وهذا يعني أنه لا فائدة من إلقاء اللوم على أي شخص في هذه الحالة. لكن بالطبع يحتاج إلى تصحيح. لهذا السبب هناك تشريح للجثث. وإذا قرأت، على سبيل المثال، GitHub بعد الوفاة، وهذه دائمًا قصة مثيرة للاهتمام وصغيرة وغير متوقعة في كل حالة، فيمكنك استبدال ذلك بأنه لم يقل أحد على الإطلاق أن هذا الشخص بالذات هو المسؤول. يتم إلقاء اللوم دائمًا على عمليات محددة غير كاملة.
دعنا ننتقل إلى السؤال التالي. أتمتة. عندما أتحدث عن التشغيل الآلي في سياقات أخرى، غالبًا ما أشير إلى جدول يخبرك بالمدة التي يمكنك العمل فيها على التشغيل الآلي لمهمة ما دون أن تستغرق وقتًا أطول في التشغيل الآلي مما توفره فعليًا. هناك عقبة. المشكلة هي أنه عندما تقوم SREs بأتمتة مهمة ما، فإنها لا توفر الوقت فحسب، بل توفر المال أيضًا، لأن الأتمتة تؤثر بشكل مباشر على MTTR. إنهم يحفظون، إذا جاز التعبير، معنويات الموظفين والمطورين، وهو أيضًا مورد لا ينضب. أنها تقلل من الروتين. وكل هذا له تأثير إيجابي على العمل، ونتيجة لذلك، على الأعمال التجارية، حتى لو بدا أن الأتمتة لا معنى لها من حيث تكاليف الوقت.
في الواقع، هذا هو الحال دائمًا تقريبًا، وهناك حالات قليلة جدًا لا ينبغي فيها أتمتة شيء ما في دور SRE. بعد ذلك سنتحدث عما يسمى بميزانية الأخطاء، ميزانية الأخطاء. في الواقع، اتضح أنه إذا كان كل شيء أفضل بكثير بالنسبة لك من SLO الذي حددته لنفسك، فهذا أيضًا ليس جيدًا جدًا. وهذا أمر سيء إلى حد ما، لأن SLO لا يعمل فقط كحد أدنى، ولكن أيضًا كحد أعلى تقريبي. عندما تحدد لنفسك مستوى توفر يصل إلى 99%، وفي الواقع لديك 99,99%، يتبين أن لديك بعض المساحة للتجارب التي لن تضر العمل على الإطلاق، لأنك وحددت كل هذا معًا بنفسك، وأنت لا تستخدم هذه المساحة. لديك ميزانية للأخطاء، والتي في حالتك لا يتم استخدامها.
ماذا نفعل معها. نحن نستخدمها في كل شيء حرفيا. للاختبار في ظروف الإنتاج، ولطرح الميزات الجديدة التي قد تؤثر على الأداء، وللإصدارات، وللصيانة، ولفترات التوقف المخطط لها. وتنطبق القاعدة العكسية أيضًا: إذا تم استنفاد الميزانية، فلن نتمكن من إصدار أي شيء جديد، وإلا فإننا سنتجاوز مستوى التعلم المحدد. لقد تم استنفاد الميزانية بالفعل، لقد أصدرنا شيئًا ما إذا كان يؤثر سلبًا على الأداء، أي إذا لم يكن هذا نوعًا من الإصلاح الذي يؤدي في حد ذاته إلى زيادة SLO بشكل مباشر، فإننا نتجاوز الميزانية، وهذا وضع سيئ ، فإنه يحتاج إلى تحليل، بعد الوفاة، وربما بعض إصلاحات العملية.
وهذا هو، اتضح أنه إذا كانت الخدمة نفسها لا تعمل بشكل جيد، وتم إنفاق SLO وتم إنفاق الميزانية ليس على التجارب، وليس على بعض الإصدارات، ولكن في حد ذاته، فبدلاً من بعض الإصلاحات المثيرة للاهتمام، بدلاً من الميزات المثيرة للاهتمام، بدلاً من الإصدارات المثيرة للاهتمام. بدلاً من أي عمل إبداعي، سيتعين عليك التعامل مع إصلاحات غبية لإعادة ترتيب الميزانية، أو تعديل SLO، وهذه أيضًا عملية لا ينبغي أن تحدث كثيرًا.
لذلك، اتضح أنه في موقف حيث لدينا المزيد من الميزانية للأخطاء، فإن الجميع مهتمون: كل من SRE والمطورين. بالنسبة للمطورين، تعني الميزانية الكبيرة للأخطاء أنه يمكنك التعامل مع الإصدارات والاختبارات والتجارب. بالنسبة إلى SREs، فإن ميزانية الأخطاء وإدخال تلك الميزانية تعني أنهم يقومون بعملهم بشكل جيد. وهذا يؤثر على دوافع نوع ما من العمل المشترك. إذا استمعت إلى SREs الخاصة بك كمطورين، سيكون لديك مساحة أكبر للعمل الجيد وروتين أقل بكثير.
اتضح أن تجارب الإنتاج تعد جزءًا مهمًا جدًا وجزءًا لا يتجزأ تقريبًا من SRE في فرق كبيرة. وعادة ما يطلق عليها هندسة الفوضى، والتي تأتي من فريق Netflix الذي أصدر أداة مساعدة تسمى Chaos Monkey.
يتصل Chaos Monkey بخط أنابيب CI/CD ويعطل الخادم أثناء الإنتاج بشكل عشوائي. مرة أخرى، في بنية SRE، نتحدث عن حقيقة أن الخادم المعطل ليس سيئًا في حد ذاته، فمن المتوقع. وإذا كان في حدود الميزانية فهو مقبول ولا يضر العمل. بالطبع، لدى Netflix ما يكفي من الخوادم الزائدة عن الحاجة، وما يكفي من النسخ المتماثل، بحيث يمكن إصلاح كل هذا، وحتى لا يلاحظ المستخدم ككل، والأكثر من ذلك، لا يترك أحد خادمًا واحدًا مقابل أي ميزانية.
كان لدى Netflix مجموعة كاملة من هذه الأدوات المساعدة لفترة من الوقت، إحداها، Chaos Gorilla، تقوم بإغلاق إحدى مناطق توافر الخدمات في أمازون بالكامل. ومثل هذه الأشياء تساعد في الكشف، أولا، التبعيات المخفية، عندما لا يكون من الواضح تماما ما الذي يؤثر على ما يعتمد على ما. وهذا، إذا كنت تعمل مع خدمة صغيرة، والوثائق ليست مثالية تماما، فقد يكون هذا مألوفا لك. ومرة أخرى، يساعد هذا كثيرًا في اكتشاف الأخطاء في التعليمات البرمجية التي لا يمكنك اكتشافها عند التدريج، لأن أي التدريج ليس محاكاة دقيقة تمامًا، نظرًا لحقيقة أن مقياس التحميل مختلف، ونمط التحميل مختلف، والمعدات أيضا، على الأرجح، أخرى. يمكن أن تكون أحمال الذروة أيضًا غير متوقعة ولا يمكن التنبؤ بها. ومثل هذا الاختبار، الذي لا يتجاوز الميزانية مرة أخرى، يساعد بشكل جيد للغاية في اكتشاف الأخطاء في البنية التحتية التي لن يلتقطها التدريج والاختبار التلقائي وخط أنابيب CI / CD أبدًا. وطالما أن كل هذا مدرج في ميزانيتك، فلا يهم أن تكون خدمتك قد تعطلت هناك، على الرغم من أن الأمر قد يبدو مخيفًا للغاية، إلا أن الخادم قد تعطل، يا له من كابوس. لا، هذا طبيعي، وهذا جيد، ويساعد في اكتشاف الأخطاء. إذا كان لديك ميزانية، فيمكنك إنفاقها.
س: ما هي الأدبيات التي يمكنني أن أوصي بها؟ القائمة في النهاية. هناك الكثير من الأدبيات، وسوف أنصح ببعض التقارير. كيف يعمل، وهل يعمل SRE في الشركات التي ليس لديها منتج برمجي خاص بها أو مع الحد الأدنى من التطوير. على سبيل المثال، في مؤسسة حيث النشاط الرئيسي ليس البرمجيات. في مؤسسة لا يكون النشاط الرئيسي فيها برمجيات، تعمل SRE تمامًا كما هو الحال في أي مكان آخر، لأنه في المؤسسة تحتاج أيضًا إلى استخدام منتجات برمجية، حتى لو لم يتم تطويرها، وتحتاج إلى نشر التحديثات، وتحتاج إلى التغيير البنية التحتية، تحتاج إلى النمو، تحتاج إلى التوسع. وتساعد SREs في تحديد المشكلات المحتملة في هذه العمليات والتنبؤ بها والسيطرة عليها بعد بدء بعض النمو وتغير احتياجات العمل. لأنه ليس من الضروري على الإطلاق المشاركة في تطوير البرامج للحصول على SRE إذا كان لديك عدد قليل من الخوادم على الأقل ومن المتوقع أن يكون لديك بعض النمو على الأقل.
الأمر نفسه ينطبق على المشاريع الصغيرة، والمنظمات الصغيرة، لأن الشركات الكبرى لديها الميزانية والمساحة اللازمة للتجربة. ولكن في الوقت نفسه، يمكن استخدام كل ثمار التجارب هذه في أي مكان، أي أن SRE، بالطبع، ظهرت في Google، في Netflix، في Dropbox. ولكن في الوقت نفسه، يمكن للشركات الصغيرة والشركات الناشئة بالفعل قراءة المواد المكثفة، وقراءة الكتب، ومشاهدة التقارير. لقد بدأوا يسمعون عنها في كثير من الأحيان، وينظرون إلى أمثلة محددة، وأعتقد أنه لا بأس، يمكن أن يكون مفيدًا حقًا، ونحن بحاجة إلى هذا أيضًا، إنه رائع.
أي أن كل العمل الرئيسي لتوحيد هذه العمليات قد تم إنجازه بالفعل من أجلك. يبقى لك تحديد دور SRE على وجه التحديد في شركتك والبدء في التنفيذ الفعلي لكل هذه الممارسات، والتي تم وصفها بالفعل مرة أخرى. وهذا هو، من المبادئ المفيدة للشركات الصغيرة، هذا هو دائمًا تعريف SLA، SLI، SLO. إذا لم تكن مشتركًا في البرامج، فستكون هذه اتفاقيات مستوى الخدمة الداخلية واتفاقيات مستوى الخدمة الداخلية، وهي ميزانية داخلية للأخطاء. يؤدي هذا دائمًا تقريبًا إلى بعض المناقشات المثيرة للاهتمام داخل الفريق وداخل الشركة، لأنه قد يتبين أنك تنفق على البنية التحتية، على نوع ما من تنظيم العمليات المثالية، فإن خط الأنابيب المثالي أكثر من اللازم بكثير. وهذه التسعات الأربعة التي لديك في قسم تكنولوجيا المعلومات، لا تحتاج إليها حقًا الآن. ولكن في الوقت نفسه، يمكنك قضاء بعض الوقت، وإنفاق الميزانية على الأخطاء في شيء آخر.
وبناء على ذلك، فإن المراقبة وتنظيم المراقبة مفيد لأي شركة مهما كان حجمها. وبشكل عام، فإن طريقة التفكير هذه، حيث تكون الأخطاء أمرًا مقبولًا، وحيث توجد ميزانية، وحيث توجد أهداف، فهي مفيدة مرة أخرى لشركة من أي حجم، بدءًا من الشركات الناشئة لثلاثة أشخاص.
آخر الفروق الفنية التي يجب الحديث عنها هي المراقبة. لأنه إذا كنا نتحدث عن SLA، وSLI، وSLO، فلا يمكننا أن نفهم دون مراقبة ما إذا كنا نتوافق مع الميزانية، وما إذا كنا نلتزم بأهدافنا، وكيف نؤثر على SLA النهائي. لقد رأيت مرات عديدة أن المراقبة تتم على النحو التالي: هناك بعض القيمة، على سبيل المثال، وقت الطلب إلى الخادم، أو متوسط الوقت، أو عدد الطلبات إلى قاعدة البيانات. وله معيار يحدده المهندس. إذا انحرف المقياس عن القاعدة، تصل رسالة بريد إلكتروني. كل هذا عديم الفائدة تمامًا، كقاعدة عامة، لأنه يؤدي إلى مثل هذه التخمة من التنبيهات، وفرة من رسائل المراقبة، عندما يجب على الشخص، أولاً، تفسيرها في كل مرة، أي تحديد ما إذا كانت قيمة المقياس تعني الحاجة إلى بعض الإجراءات. وثانيًا، يتوقف ببساطة عن ملاحظة كل هذه التنبيهات، عندما لا يكون هناك أي إجراء مطلوب منه. هذه قاعدة مراقبة جيدة والقاعدة الأولى عند تنفيذ SRE هي أن الإخطار يجب أن يأتي فقط عندما يكون الإجراء مطلوبًا.
في الحالة القياسية، هناك 3 مستويات من الأحداث. هناك تنبيهات، وهناك تذاكر، وهناك سجلات. التنبيهات هي أي شيء يتطلب منك اتخاذ إجراء فوري. وهذا هو، كل شيء مكسور، تحتاج إلى إصلاحه الآن. التذاكر هي ما يتطلب اتخاذ إجراءات متأخرة. نعم، أنت بحاجة إلى القيام بشيء ما، وتحتاج إلى القيام بشيء يدويًا، وفشلت الأتمتة، ولكن ليس عليك القيام بذلك خلال الدقائق القليلة القادمة. السجلات هي أي شيء لا يتطلب اتخاذ إجراء، وبشكل عام، إذا سارت الأمور على ما يرام، فلن يقرأها أحد أبدًا. ستحتاج فقط إلى قراءة السجلات عندما يتبين، في وقت لاحق، أن شيئًا ما قد انكسر لبعض الوقت، ولم نكن نعرف عنه. أو تحتاج إلى القيام ببعض الأبحاث. ولكن بشكل عام، كل ما لا يتطلب أي إجراء يذهب إلى السجلات.
كأثر جانبي لكل هذا، إذا حددنا الأحداث التي تتطلب إجراءات ووصفنا جيدًا ما يجب أن تكون عليه هذه الإجراءات، فهذا يعني أنه يمكن تنفيذ الإجراء تلقائيًا. وهذا هو ما يحدث. نذهب من التنبيه. دعنا نذهب إلى العمل. نذهب إلى وصف هذا الإجراء. وبعد ذلك ننتقل إلى الأتمتة. أي أن أي أتمتة تبدأ برد فعل على حدث ما.
من المراقبة، ننتقل إلى مصطلح يسمى قابلية الملاحظة. كان هناك أيضًا القليل من الضجيج حول هذه الكلمة خلال السنوات القليلة الماضية. وقليل من الناس يفهمون ما يعنيه ذلك خارج السياق. لكن النقطة الأساسية هي أن إمكانية الملاحظة هي مقياس لشفافية النظام. إذا حدث خطأ ما، فما مدى سرعة تحديد الخطأ الذي حدث بالضبط وحالة النظام في تلك اللحظة. من حيث الكود: ما هي الوظيفة التي فشلت، وما هي الخدمة التي فشلت. ما هي حالة، على سبيل المثال، المتغيرات الداخلية، التكوين. فيما يتعلق بالبنية التحتية، هذه هي منطقة التوفر التي حدث الفشل فيها، وإذا كان لديك أي Kubernetes، ففي أي حاوية حدث الفشل، وما هي حالة الحافظة. وبناءً على ذلك، فإن قابلية الملاحظة لها علاقة مباشرة بـ MTTR. كلما زادت إمكانية ملاحظة الخدمة، أصبح من الأسهل تحديد الخطأ، وكلما كان من الأسهل إصلاح الخطأ، وكلما كان من الأسهل أتمتة الخطأ، انخفض MTTR.
بالانتقال إلى الشركات الصغيرة مرة أخرى، من الشائع جدًا أن نتساءل، حتى الآن، عن كيفية التعامل مع حجم الفريق، وما إذا كان الفريق الصغير يحتاج إلى توظيف SRE منفصل. لقد تحدثت بالفعل عن هذا في وقت سابق قليلا. في المراحل الأولى من تطوير الشركة الناشئة أو، على سبيل المثال، الفريق، ليس من الضروري على الإطلاق، لأن SRE يمكن أن يتم دورا انتقاليا. وهذا سوف ينعش الفريق قليلاً، لأن هناك على الأقل بعض التنوع. بالإضافة إلى أنه سيعد الناس لحقيقة أنه مع النمو، بشكل عام، ستتغير مسؤوليات SRE بشكل كبير جدًا. إذا قمت بتعيين شخص ما، فبالطبع، لديه بعض التوقعات. وهذه التوقعات لن تتغير بمرور الوقت، بل ستتغير المتطلبات كثيرًا. لذلك، فإن كيفية توظيف SRE أمر صعب للغاية في المراحل المبكرة. إن النمو بنفسك أسهل بكثير. لكن الأمر يستحق التفكير فيه.
ربما يكون الاستثناء الوحيد هو عندما تكون هناك متطلبات نمو صارمة ومحددة جيدًا. وهذا هو، في حالة بدء التشغيل، قد يكون هناك نوع من الضغط من المستثمرين، وبعض التوقعات للنمو عدة مرات في وقت واحد. إذن فإن توظيف SRE له ما يبرره بشكل أساسي لأنه يمكن تبريره. لدينا متطلبات للنمو، ونحن بحاجة إلى شخص سيكون مسؤولاً عن حقيقة أنه مع هذا النمو لن ينكسر شيء.
سؤال اخر. ما يجب فعله عندما يقوم المطورون عدة مرات بقطع ميزة تجتاز الاختبارات، ولكنها تكسر الإنتاج، وتحميل القاعدة، وتكسر الميزات الأخرى، وما هي العملية التي يجب تنفيذها. وبناء على ذلك، في هذه الحالة، يتم تقديم ميزانية الأخطاء. ويتم بالفعل اختبار بعض الخدمات وبعض الميزات في الإنتاج. يمكن أن يكون كناريًا، عندما يتم نشر ميزة ما فقط لعدد صغير من المستخدمين، ولكن بالفعل في الإنتاج، ولكن بالفعل مع توقع أنه إذا تعطل شيء ما، على سبيل المثال، لنصف بالمائة من جميع المستخدمين، فإنه سيظل يفي بالمتطلبات الميزانية للأخطاء. وبناء على ذلك، نعم، سيكون هناك خطأ، بالنسبة لبعض المستخدمين سوف ينكسر كل شيء، لكننا قلنا بالفعل أن هذا أمر طبيعي.
كان هناك سؤال حول أدوات SRE. وهذا يعني، هل هناك شيء محدد قد تستخدمه شركات SRE ولا يستخدمه أي شخص آخر. في الواقع، هناك بعض الأدوات المساعدة المتخصصة للغاية، وهناك نوع من البرامج، على سبيل المثال، يحاكي الأحمال أو يشارك في اختبار الكناري A / B. لكن مجموعة أدوات SRE هي في الأساس ما يستخدمه المطورون لديك بالفعل. لأن SRE تتفاعل مباشرة مع فريق التطوير. وإذا كان لديك أدوات مختلفة، فسيتبين أن المزامنة تستغرق وقتًا. خاصة إذا كانت SRE تعمل في فرق كبيرة، في الشركات الكبيرة حيث يمكن أن يكون هناك عدة فرق، فإن التوحيد القياسي على مستوى الشركة سيساعد كثيرًا هنا، لأنه إذا تم استخدام 50 أداة مساعدة مختلفة في 50 فريقًا، فهذا يعني أن SRE يجب أن تعرفها الجميع. وبالطبع هذا لن يحدث أبداً. ونوعية العمل وجودة التحكم في بعض الفرق على الأقل ستنخفض بشكل كبير.
ندوتنا عبر الإنترنت تقترب من نهايتها. تمكنت من قول بعض الأشياء الأساسية. بالطبع، لا يمكن قول وفهم أي شيء عن SRE في ساعة واحدة. لكني آمل أن أكون قد تمكنت من نقل طريقة التفكير هذه والنقاط الرئيسية الرئيسية. وبعد ذلك سيكون من الممكن، إذا كنت مهتما، الخوض في الموضوع، والتعلم بنفسك، والنظر في كيفية تنفيذه من قبل أشخاص آخرين، في شركات أخرى. وبناء على ذلك، في أوائل فبراير، تعال إلينا في Slurm SRE.
إن Slurm SRE عبارة عن دورة مكثفة لمدة ثلاثة أيام ستتحدث عما أتحدث عنه الآن، ولكن بمزيد من العمق، مع حالات حقيقية، مع الممارسة، تهدف الدورة المكثفة بأكملها إلى العمل العملي. سيتم تقسيم الناس إلى فرق. ستعملون جميعًا على قضايا حقيقية. وبناءً على ذلك، لدينا مدربي Booking.com إيفان كروغلوف وبن تايلر. لدينا يوجين باراباس الرائع من جوجل، من سان فرانسيسكو. وسأخبرك بشيء أيضًا. لذا تأكد من زيارتنا.
لذلك، الببليوغرافيا. هناك مراجع على SRE. في نفس الكتاب، أو بالأحرى في كتابين عن SRE، من تأليف Google. واحدة أخرى ، حيث تكون الشروط وتطبيقاتها أكثر تفصيلاً قليلاً. الثلاثة التالية هي تقارير عن SRE في شركات مختلفة. أولاً - ، هذه كلمة رئيسية من Ben Trainer من Google. ثانية - . والثالث مرة أخرى . التقرير الرابع من ، والتي تضم 5 موظفين رئيسيين فقط في SRE في 190 دولة. من المثير للاهتمام أن ننظر إلى كل هذا، لأنه مثلما تعني DevOps أشياء مختلفة جدًا لشركات مختلفة وحتى فرق مختلفة، فإن SRE لديها مسؤوليات مختلفة جدًا، حتى في الشركات ذات الأحجام المماثلة.
رابطان إضافيان حول مبادئ هندسة الفوضى: , . وفي النهاية هناك 3 قوائم من سلسلة القوائم الرائعة عنها حول وحول . القائمة الموجودة في SRE ضخمة بشكل لا يصدق، وليس من الضروري الاطلاع عليها كلها، فهناك حوالي 200 مقال. أوصي بشدة بمقالات من هناك حول تخطيط القدرات وعن تشريح الجثة بعد الوفاة.
مقالة مثيرة للاهتمام:
أشكركم على الاستماع لي كل هذا الوقت. آمل أن تكون قد تعلمت شيئا. آمل أن يكون لديك ما يكفي من المواد لمعرفة المزيد. و اراك. نأمل في فبراير.
استضاف الندوة عبر الإنترنت إدوارد ميدفيديف.
ملاحظة: بالنسبة لأولئك الذين يحبون القراءة، قدم إدوارد قائمة من المراجع. أولئك الذين يفضلون الفهم عمليًا مرحب بهم .
المصدر: www.habr.com