👨‍👩‍👧‍👦 💟 🏑 أعلى Fakapov سماوي ⛹🏽 👨🏻‍🔧 🌹

جيد للجميع!

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

الديباجة

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

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

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

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

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

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

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

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

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

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

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

المركز الخامس - "وضع النظام في DNS"

كان يوم الثلاثاء ممطر. قررنا تنظيف مجموعة DNS.

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

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

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

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

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

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

المركز الرابع - "تنظيف Nginx"

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

هيكل Nginx

├── 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 عقد أخرى بدون تنظيف ، وبعد ذلك بدأوا في الإزالة المنهجية من المجموعة وإعادة إدخالها كعقد فارغة انتهى فيها المكان. قضى الوقت أكثر مما نرغب. كان هناك خطر من عدم إمكانية الوصول الجزئي أو الكامل للكتلة.

الموجودات:

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

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

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

الموجودات:

- . , ES — , , , action.destructive_requires_name: true.
. , ( , python), .

— « »

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

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

كان من المثير للاهتمام والمثير التحقيق في هذا الخطأ).

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

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

أعلى Fakapov سماوي