أعلى fakapov سماوي

أتمنى لك كل خير! 

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

مقدمة

منذ وقت طويل، عندما كان Cian يتكون من وحدات متراصة، ولم تكن هناك تلميحات حول الخدمات الصغيرة حتى الآن، قمنا بقياس مدى توفر المورد من خلال التحقق من 3-5 صفحات. 

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

الصفحات الرئيسية للموقع أو كيف نفهم أننا وصلنا إلى القاع

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

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

أعلى أفضل الحوادث سماوي

لذلك، تعلمنا بالتأكيد تحديد حقيقة وقوع حادث ما. 

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

إذا قمت بجمع كل الإخفاقات خلال السنوات القليلة الماضية، فإن القادة هم: 

• الحوادث ذات الصلة بـ Mssql؛
• الحوادث الناجمة عن عوامل خارجية؛
• أخطاء المشرف.

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

المركز الخامس - "ترتيب الأمور في DNS"

كان يوم الثلاثاء عاصفًا. قررنا استعادة النظام في مجموعة DNS. 

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

لقد وضعنا خادم DNS واحدًا في كل موقع من مراكز البيانات لدينا، وحان الوقت لنقل المناطق من الربط إلى powerdns وتحويل البنية التحتية إلى خوادم جديدة. 

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

الاستنتاجات:

إذا أهملنا العوامل الخارجية في وقت سابق أثناء التحضير للعمل، فهي الآن مدرجة أيضًا في قائمة ما نستعد له. والآن نسعى جاهدين للتأكد من أن جميع المكونات محجوزة n-2، وأثناء العمل يمكننا خفض هذا المستوى إلى n-1.

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

المركز الرابع - "ترتيب الأمور في Nginx"

في أحد الأيام، قرر فريقنا أنه "لقد سئمنا من هذا"، وبدأت عملية إعادة هيكلة تكوينات nginx. الهدف الرئيسي هو جلب التكوينات إلى بنية بديهية. في السابق، كان كل شيء «مثبتًا تاريخيًا» ولا يحمل أي منطق. الآن تم نقل كل اسم خادم إلى ملف يحمل نفس الاسم وتم توزيع كافة التكوينات في المجلدات. بالمناسبة، يحتوي التكوين على 253949 سطرًا أو 7836520 حرفًا ويشغل حوالي 7 ميغابايت. المستوى الأعلى للهيكل: 

هيكل نجينكس

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

لقد أصبح الأمر أفضل بكثير، ولكن أثناء عملية إعادة تسمية التكوينات وتوزيعها، كان لدى بعضها امتداد خاطئ ولم يتم تضمينها في توجيه include *.conf. ونتيجة لذلك، أصبح بعض المضيفين غير متاحين وأعادوا 301 إلى الصفحة الرئيسية. نظرًا لأن رمز الاستجابة لم يكن 5xx/4xx، لم يتم ملاحظة ذلك على الفور، ولكن فقط في الصباح. بعد ذلك، بدأنا في كتابة الاختبارات للتحقق من مكونات البنية التحتية.

الاستنتاجات: 

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

المركز الثالث - "نفدت المساحة فجأة في كاساندرا"

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

وفي يوم عاصف كاد العنقود أن يتحول إلى يقطينة، وهي:

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

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

الاستنتاجات:

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

المركز الثاني - "اختفت البيانات من تخزين قيمة مفتاح القنصل"

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

الاستنتاجات:

• يجب ألا تحتوي الخدمات دون أي ترخيص على بيانات مهمة لتشغيل الموقع. على سبيل المثال، إذا لم يكن لديك ترخيص في ES، سيكون من الأفضل رفض الوصول على مستوى الشبكة من كل مكان حيث لا تكون هناك حاجة إليه، وترك فقط ما هو ضروري، وكذلك تعيين action.destructive_requires_name: true.
• تدرب على آلية النسخ الاحتياطي والاسترداد مسبقًا. على سبيل المثال، قم بإنشاء برنامج نصي مسبقًا (على سبيل المثال، في python) يمكنه النسخ الاحتياطي والاستعادة.

المركز الأول - "الكابتن غير الواضح" 

في مرحلة ما، لاحظنا توزيعًا غير متساوٍ للحمل على عمليات تحميل nginx في الحالات التي يوجد فيها أكثر من 10 خوادم في الواجهة الخلفية. نظرًا لأن برنامج round robin أرسل الطلبات من الأول إلى الأخير بالترتيب، وبدأت كل عملية إعادة تحميل لـ nginx من جديد، كانت عمليات التحميل الأولى تتلقى دائمًا طلبات أكثر من البقية، ونتيجة لذلك، عملت بشكل أبطأ وعانى الموقع بأكمله. أصبح هذا ملحوظًا بشكل متزايد مع زيادة حجم حركة المرور. لم ينجح تحديث nginx ببساطة لتمكين العشوائية - نحتاج إلى إعادة مجموعة من أكواد Lua البرمجية التي لم يتم إطلاقها في الإصدار 1 (في تلك اللحظة). كان علينا تصحيح إصدار nginx 1.15، وإدخال دعم عشوائي فيه. هذا حل المشكلة. يفوز هذا الخطأ بفئة "عدم وضوح الكابتن".

الاستنتاجات:

لقد كان استكشاف هذا الخطأ أمرًا مثيرًا للاهتمام ومثيرًا للغاية). 

• قم بتنظيم مراقبتك بحيث تساعدك في العثور على مثل هذه التقلبات بسرعة. على سبيل المثال، يمكنك استخدام ELK لمراقبة rps على كل واجهة خلفية لكل منبع، ومراقبة وقت الاستجابة من وجهة نظر nginx. وفي هذه الحالة، ساعدنا هذا في تحديد المشكلة. 

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

المصدر: www.habr.com