كتاب موثوقية الموقع: تطبيق عملي

مرحبا سكان! أثار كتاب هندسة موثوقية الموقع مناقشة محتدمة. ما هو الاستغلال اليوم ، ولماذا تعتبر قضايا الموثوقية أساسية للغاية؟ الآن يقترح مهندسو Google الذين يقفون وراء هذا الكتاب الأكثر مبيعًا الانتقال من النظرية إلى التطبيق - يوضح دليل موثوقية الموقع كيف تتجسد مبادئ وممارسات SRE في إنتاجك ، حيث يتم استكمال خبرة Google بحالات مستخدمي Google Cloud Platform. يصف ممثلو Evernote و The Home Depot و The New York Times وشركات أخرى خبرتهم القتالية ، ويخبرون عن الممارسات التي اعتمدوها وأيها لم يعتمدوها. سيساعدك هذا الكتاب على تكييف SRE مع واقع ممارستك ، بغض النظر عن حجم شركتك. سوف تتعلم:

• ضمان موثوقية الخدمات في السحابة والبيئات التي لا تتحكم فيها بالكامل ؛
• تطبيق طرق مختلفة لإنشاء الخدمات وإطلاقها ومراقبتها ، مع التركيز على SLO ؛
• تحويل فرق الإدارة إلى مهندسي SRE ؛
• تنفيذ طرق بدء SRE من البداية وبناءً على الأنظمة الموجودة. يشارك كل من Betsy Beyer و Neil Richard Murphy و David Renzin و Kent Kawahara و Stephen Thorne في ضمان موثوقية أنظمة Google.

إدارة نظام المراقبة

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



التعامل مع التكوين الخاص بك كرمز يعتبر التعامل مع تكوين



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



نوصي بشدة أيضًا بمعاملة تكوين المراقبة كرمز (لمزيد من المعلومات حول التكوين ، راجع الفصل 14). نظام مراقبة يدعم التخصيص باستخدام أوصاف جيدة التكوين للأهداف والوظائف ، بدلاً من الأنظمة التي توفر فقط واجهات الويب أو واجهات برمجة التطبيقات على غرار CRUD (http://bit.ly/1G4WdV1). يعتبر أسلوب التكوين هذا قياسيًا للعديد من الثنائيات مفتوحة المصدر التي تقرأ ملف التكوين فقط. تدعم بعض حلول الجهات الخارجية مثل grafanalib (http://bit.ly/2so5Wrx) هذا الأسلوب للمكونات القابلة للتخصيص تقليديًا باستخدام واجهة المستخدم.



شجع الاتساق



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



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



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



تفضل الروابط الضعيفة



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



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



في عالم المصدر المفتوح ، أصبح تقسيم الوظائف إلى مكونات منفصلة أمرًا شائعًا. قبل عشر سنوات ، جمعت أنظمة المراقبة مثل Zabbix (https://www.zabbix.com/) جميع الوظائف في مكون واحد. يتضمن التصميم الحديث عادةً فصل مجموعة القواعد وتنفيذها (باستخدام حلول مثل خادم Prometheus (https://prometheus.io/)) ، وتخزين سلاسل زمنية طويلة المدى (InfluxDB ، www.influxdata.com ) ، وتجميع التنبيهات ( Alertmanager، bit.ly/2soB22b ) وإنشاء لوحات المعلومات (Grafana، grafana.com ).



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

• statsd — , Etsy, ;
• Prometheus — , . Prometheus OpenMetrics (https://openmetrics.io/).

يوفر نظام لوحة معلومات منفصل يستخدم مصادر بيانات متعددة رؤية مركزية وموحدة لخدمتك. اختبرت Google مؤخرًا هذه الميزة عمليًا: لوحات المعلومات المجمعة لنظام المراقبة القديم (Borgmon1) في نفس التكوين مثل قواعد التنبيه. عند التبديل إلى نظام جديد (Monarch ، youtu.be/LlvJdK1xsl4 ) ، قررنا نقل لوحات المعلومات إلى خدمة منفصلة (Viceroy ، bit.ly/2sqRwad ). لم يكن Viceroy مكونًا من Borgmon أو Monarch ، لذلك كان لدى Monarch متطلبات وظيفية أقل. نظرًا لأنه يمكن للمستخدمين استخدام Viceroy لعرض الرسوم البيانية بناءً على البيانات من كلا نظامي المراقبة ، فقد تمكنوا من الانتقال تدريجياً من Borgmon إلى Monarch.







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



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



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



التغييرات المقصودة

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

• مراقبة إصدار الملف الثنائي ؛
• , ;
• , .

إذا لم يتم إصدار أي من هذه المكونات ، فستحتاج إلى تتبع آخر مرة تم فيها تجميع المكون أو حزمه.



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



التبعيات



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



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

يمكنك استخدام تسميات إضافية في المقاييس لفصلها عن طريق رمز الاستجابة واسم طريقة RPC (استدعاء الإجراء البعيد) واسم الخدمة التي يتم استدعاؤها.



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



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

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

مستوى عبء العمل من



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



اعتمادًا على لغة البرمجة التي تستخدمها ، تحتاج إلى تتبع بعض الموارد الإضافية:

• في حجم Java ، heap و metaspace (http://bit.ly/2J9g3Ha) ، بالإضافة إلى مقاييس أكثر تحديدًا اعتمادًا على نوع مجموعة القمامة المستخدمة ؛
• في Go ، عدد goroutines.

توفر لغات البرمجة نفسها دعمًا متنوعًا لتتبع هذه الموارد.



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

• عندما يكون للمورد حد صارم ؛
• عندما يحدث تدهور في الأداء عند تجاوز حد الاستخدام.

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



حالة حركة المرور الصادرة



يوصى بإضافة مقاييس أو تسميات مقاييس على لوحة التحكم تسمح لك بفصل حركة المرور الصادرة حسب رمز الحالة (إذا كانت المقاييس التي تستخدمها خدمتك لأغراض SLI لا تحتوي على هذه المعلومات). فيما يلي بعض الإرشادات.

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

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



تنفيذ المقاييس المستهدفة



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

اختبار منطق التنبيه

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



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



غالبًا ما تكون مراقبة التنبيهات وإصدارها عملية متعددة الخطوات ، لذا يلزم وجود مجموعات متعددة من اختبارات الوحدة.



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

1. الملفات الثنائية. تأكد من أن المتغيرات المترية المصدرة تغير القيم كما هو متوقع في ظل ظروف معينة.
2. مراقبة البنية التحتية. تأكد من اتباع القواعد وأن الشروط المحددة هي التنبيهات المتوقعة.
3. مدير التنبيه. تحقق من أن التنبيهات التي تم إنشاؤها يتم توجيهها إلى وجهة محددة مسبقًا بناءً على قيم التسمية.

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



ملخص الفصل



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



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



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



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



»يمكن العثور على مزيد من التفاصيل حول الكتاب على الموقع الإلكتروني لدار النشر

» جدول المحتويات

» مقتطفات



لـ Habitants خصم 25٪ على القسيمة - Google



عند الدفع مقابل النسخة الورقية من الكتاب ، يتم إرسال كتاب إلكتروني إلى البريد الإلكتروني.