🐯 🥟 🌐 تشغيل نظام موزع كبير: ما تعلمته ♥️ 🌼 🏩

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

أوجه انتباهكم إلى ترجمة لمقال كتبه مهندس من أوبر.

* * *

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

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

تلخص هذه المقالة التقنيات التي استفادت من تشغيل نظام كبير في أوبر. تجربتي ليست فريدة من نوعها: يعمل الآخرون مع أنظمة من نفس الحجم ويخوضون المغامرات نفسها. لقد تحدثت مع مهندسين من Google و Facebook و Netflix ، الذين واجهوا مواقف مماثلة وتوصلوا إلى حلول مماثلة. يمكن تطبيق العديد من الأفكار والعمليات الموضحة هنا على أنظمة من نفس الحجم ، بغض النظر عما إذا كانت تعمل في مراكز البيانات المملوكة للشركة (كما هو الحال غالبًا مع Uber) أو في السحابة (حيث يتم قياس Uber في بعض الأحيان ). ومع ذلك ، قد تكون هذه النصائح زائدة عن الحاجة لأنظمة ليست كبيرة أو مهمة للشركة.

سنتحدث عن مثل هذه المواضيع:

المراقبة
واجب (تحت الطلب) ، كشف الشذوذ والإخطار.
الفشل وإدارة الحوادث.
بعد الوفاة ، تحليل الحوادث وثقافة التحسين المستمر.
الفشل وتخطيط الموارد واختبار الصندوق الأسود.
SLO و SLA والإبلاغ عنها.
SRE كفريق مستقل.
الموثوقية كاستثمار دائم.
مواد مفيدة.

المراقبة

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

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

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

هناك شيء آخر يمكن أن يقال عن مراقبة تأخيرات الاستجابة. الهدف من خدمات الإنتاج أن يستمتع معظم المستخدمين النهائيين باستخدامها. وقياس متوسط التأخير ليس الحل الأفضل ، لأن متوسط القيمة يمكن أن يخفي عددًا صغيرًا من الطلبات بتأخير كبير. من الأفضل قياس p95 أو p99 أو p999 - التأخير في 95 أو 99 أو 99.9 في المائة من الطلبات. تساعد هذه الأرقام في الإجابة عن أسئلة مثل ، "ما مدى سرعة الطلب على 99٪ من الزوار؟" "(ص 99) أو" ما مدى بطء الطلب على زائر واحد من أصل 1000؟ "(ص 1999). إذا كنت مهتمًا بالتفاصيل ، فيمكنك قراءة هذه المقالة .

الرسم البياني ل p95 و p99. لاحظ أن متوسط التأخير لنقطة النهاية هذه أقل من ثانية واحدة ، و 1٪ من الطلبات تستغرق ثانيتين. وأكثر - لا يُرى هذا عند قياس متوسط القيمة.

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

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

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

واجب واكتشاف الشذوذ والتنبيه

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

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

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

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

مثال على لوحة Call Duty التي أنشأها فريق Uber Developer Experience في فيلنيوس.

أنشأ فريق Uber لإنشاء أدوات تطوير من Vilnius أداة صغيرة نستخدمها للتعليق على التنبيهات وتصور نوبات العمل. يقوم فريقنا بإعداد تقرير أسبوعي عن عمل التحول الأخير في العمل ، وتحليل نقاط الضعف وتحسين منهجية العمل.

الفشل وإدارة الحوادث

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

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

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

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

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

بعد الوفاة ، تحليل الحوادث وثقافة التحسين المستمر

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

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

استخدمت نمط معالجة الخطأ هذا في Uber.

في حالة جيدة بعد الوفاة ، يتم التحقيق بدقة في سبب الفشل ، ويتم اقتراح تدابير لمنع عواقب الفشل المماثل أو اكتشافها أو القضاء عليها بسرعة. وعندما أقول "بعمق" ، أعني أن المؤلفين لا يتوقفون عند حقيقة أن السبب هو تدحرج الكود مع خطأ لم يلاحظه المراجع. يجب على المؤلفين تطبيق منهجية Five Why للوصول إلى نتيجة أكثر فائدة. على سبيل المثال:

لماذا هناك مشكلة؟ -> تم تحميل الخطأ كجزء من التعليمات البرمجية.
لماذا لم يصاب أحد بالخلل؟ -> الشخص الذي أجرى المراجعة لم يلاحظ أن تغيير الكود يمكن أن يؤدي إلى مثل هذه المشكلة.
, ? --> .
? --> .
? --> .
: . , .

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

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

الفشل وتخطيط الموارد واختبار الصندوق الأسود

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

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

أكثر سيناريوهات الفشل شيوعًا التي صادفتها هي أن الخدمة ليس لديها موارد كافية في مركز البيانات الجديد للتعامل مع حركة المرور العالمية في حالة حدوث تجاوز الفشل. لنفترض أن الخدمة A تعمل في أحد مراكز البيانات والخدمة B في مركز آخر. دع استهلاك الموارد يكون 60٪ - تدور عشرات أو مئات الأجهزة الافتراضية في كل مركز بيانات ، ويتم تشغيل التنبيهات عند الوصول إلى حد 70٪. فشلت كل حركة المرور من مركز البيانات أ إلى مركز البيانات ب. لا يستطيع مركز البيانات الثاني التعامل مع هذه الزيادة في الحمل دون نشر أجهزة جديدة. ومع ذلك ، يمكن أن يستغرق ذلك الكثير من الوقت ، لذلك تبدأ الطلبات في التراكم والإسقاط. يبدأ الحظر في التأثير على الخدمات الأخرى ، مما يتسبب في فشل سلسلة أخرى من الأنظمة التي لا تتعلق بالفشل الأساسي.

حالة محتملة يؤدي فيها تجاوز الفشل إلى مشاكل.

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

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

اختبار Blackbox(طريقة "الصندوق الأسود") هي طريقة لتقييم صحة النظام في موقف قريب قدر الإمكان من كيفية انتقال التفاعل مع المستخدم النهائي. يشبه هذا الاختبار الشامل ، باستثناء حقيقة أن اختبار الصندوق الأسود الصحيح لمعظم المنتجات يتطلب استثمارًا خاصًا بك. يعتبر المرشحون الجيدون لهذا الاختبار عمليات وسيناريوهات رئيسية للمستخدم تتضمن تفاعل المستخدم: لاختبار النظام ، تأكد من أنه يمكن إطلاقها في أي وقت.

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

مثال على اختبار الصندوق الأسود أثناء تجاوز الفشل والتراجع اليدوي.

تخطيط الموارديلعب دور مهم بشكل خاص للأنظمة الموزعة الكبيرة. بشكل عام ، أعني تلك التي يتم فيها حساب تكلفة الحوسبة والتخزين بعشرات أو مئات الآلاف من الدولارات في الشهر. على هذا النطاق ، قد يكون من الأرخص أن يكون لديك عدد ثابت من عمليات النشر بدلاً من استخدام حلول السحابة القابلة للتطوير الذاتي. في الحالات القصوى ، يجب أن تتعامل عمليات النشر الثابتة مع حركة المرور المميزة لـ "الأعمال العادية" ، مع التحجيم التلقائي فقط عند ذروة الأحمال. ولكن ما هو الحد الأدنى لعدد الحالات التي سيتم تطبيقها الشهر المقبل؟ في الأشهر الثلاثة المقبلة؟ العام القادم؟

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

SLO و SLA والإبلاغ عنها

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

قياس SLO	تصنيف فرعي	قيمة الخدمة
أداء	الحد الأدنى من عرض النطاق الترددي	500 طلب في الثانية
		2 500
		50-90
	p99	500-800
		0,5 %
		99,9 %

SLO على مستوى الأعمال . أو SLOs الوظيفية ، هذا هو تجريد على الخدمات. وهي تغطي مقاييس مخصصة أو تجارية. على سبيل المثال ، قد يكون SLO على مستوى الأعمال كما يلي: من المتوقع إرسال 99.99٪ من الإيصالات بالبريد خلال دقيقة واحدة من إكمال الرحلة. يمكن مقارنة SLO هذا بـ SLO على مستوى الخدمة (على سبيل المثال ، مع تأخير نظام الدفع أو نظام إرسال الشيكات البريدية) ، ويمكن قياسه بشكل منفصل.

اتفاقية مستوى الخدمة - اتفاقية مستوى الخدمة . هذه اتفاقية أكثر عمومية بين مقدم الخدمة والمستهلك. عادة ، تشكل العديد من SLOs اتفاقية مستوى الخدمة. على سبيل المثال ، قد يكون توافر نظام الدفع عند مستوى 99.99٪ عبارة عن اتفاقية مستوى الخدمة ، والتي تنقسم إلى اتفاقيات مستوى خدمة محددة لكل نظام مناظر.

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

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

SRE كفريق مستقل

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

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

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

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

الموثوقية كاستثمار دائم

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

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

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

من أجل أن يحافظ الفريق على نظام موزع موثوق به ، يجب على المؤسسة أن تستثمر باستمرار في عملها ، وكذلك في عمل المنصات التي تم بناء النظام عليها.

مواد مفيدة

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

الكتب

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

مواقع

إصدار Increment Magazine's On-Call Edition : سلسلة من المقالات حول عمليات الاستجابة للحوادث في Amazon و Dropbox و Facebook و Google و Netflix.
تعلم كيفية بناء النظم الموزعة - مقالة مهندس AWS التي تجيب على السؤال "كيف تتعلم كيفية إنشاء أنظمة موزعة كبيرة؟"

انظر التعليقات على هذا المقال على Hacker News .

تشغيل نظام موزع كبير: ما تعلمته