أرابيكا

هندسة موثوقية الموقع

هندسة موثوقية الموقع (SRE) هي نظام يدمج جوانب هندسة البرمجيات ويطبقها على مشاكل البنية التحتية والعمليات. الأهداف الرئيسية هي إنشاء أنظمة برمجيات قابلة للتوسيع وموثوقة للغاية. وفقًا لبن ترينور، مؤسس فريق موثوقية الموقع من جوجل، فإن هندسة موثوقية الموقع هو «ما يحدث عندما يتم تكليف مهندس برمجيات بما كان يطلق عليه العمليات».[1]

أدوار

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

ديف أوبس مقابل هندسة موثوقية الموقع

المقالة الرئيسية: ديف أوبس

صُنعت ديف أوبس حوالي عام 2008، وهي فلسفة التعاطف بين الفرق والمواءمة بين الأعمال. كما تم ربطه بممارسة تشمل أتمتة المهام اليدوية والتركيب المتواصل والتسليم المستمر. تشترك ديف أوبس وهندسة موثوقية الموقع في نفس المبادئ التأسيسية. ينظر الكثيرون إلى هندسة موثوقية الموقع (كما ورد في كتاب Google SRE) على أنه «تنفيذ محدد لـديف أوبس مع بعض الامتدادات الفردية.» إن هندسة موثوقية الموقع، كونهم مطورين أنفسهم، سيقدمون بطبيعة الحال حلولًا تساعد على إزالة الحواجز بين فرق التطوير وفرق العمليات.

يحدد ديف أوبس 5 ركائز رئيسية للنجاح:

  1. تقليل الصوامع التنظيمية.
  2. تقبل الفشل كالمعتاد.
  3. تنفيذ التغييرات التدريجية.
  4. الاستفادة من الأدوات والأتمتة.
  5. قياس كل شيء.

تلبي هندسة موثوقية الموقع ركائز ديف أوبس على النحو التالي:[2]

  1. تقليل الصوامع التنظيمية.
    • تشارك هندسة موثوقية الموقع الملكية مع المطورين لإنشاء مسؤولية مشتركة.[3]
    • تستخدم هندسة موثوقية الموقع نفس الأدوات التي يستخدمها المطورون، والعكس بالعكس.
  2. تقبل الفشل كالمعتاد.
    • هندسة موثوقية الموقع تحتضن المخاطر.[4]
    • تحدد هندسة موثوقية الموقع الفشل والتوافر بطريقة إرشادية باستخدام مؤشرات مستوى الخدمة (SLIs) وأهداف مستوى الخدمة (SLOs).[5]
    • تفرض هندسة موثوقية الموقع ما بعد الفحص.[6]
  3. تنفيذ التغييرات التدريجية.
    • تشجع هندسة موثوقية الموقع المطورين وأصحاب المنتجات على التحرك بسرعة عن طريق تقليل تكلفة الفشل.[4]
  4. الاستفادة من الأدوات والأتمتة.
    • لدى هندسة موثوقية الموقع ميثاق لأتمتة المهام الوضيعة (تسمى «كدح»).[7]
  5. قياس كل شيء.
    • تحدد هندسة موثوقية الموقع الطرق الإرشادية لقياس القيم.[8]
    • تعتقد هندسة موثوقية الموقع بشكل أساسي أن تشغيل الأنظمة يمثل مشكلة في البرامج.

انظر أيضًا

مراجع

  1. ^ Are SRE the next data scientists?, تك كرانش, Mar 2, 2016, Donald Fischer نسخة محفوظة 2019-08-12 على موقع واي باك مشين.
  2. ^ Google Cloud Platform (1 مارس 2018). "What's the Difference Between DevOps and SRE? (class SRE implements DevOps)". مؤرشف من الأصل في 2019-12-03. {{استشهاد ويب}}: |الأخير= باسم عام (مساعدة) والوسيط غير المعروف |بواسطة= تم تجاهله يقترح استخدام |via= (مساعدة)
  3. ^ "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-09-15.
  4. ^ أ ب "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-10-05.
  5. ^ "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-09-10.
  6. ^ "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-09-10.
  7. ^ "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-10-14.
  8. ^ "Google - Site Reliability Engineering". landing.google.com. مؤرشف من الأصل في 2018-10-17.
عامة
  • Site Reliability Engineering: How Google Runs Production Systems, O'Reilly Media, April 2016, Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, (ردمك 978-1-491-92912-4)
  • The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, Volume 2, Thomas Limoncelli, (ردمك 032194318X)

روابط خارجية

مجلوبة من «https://3rabica.org/index.php?title=هندسة_موثوقية_الموقع&oldid=3259286»