HighLoad ++ ، Evgeny Kuzovlev (EcommPay IT): ماذا تفعل عندما تكلف دقيقة توقف 100000 دولار

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

سيعقد مؤتمر HighLoad ++ القادم في 6 و 7 أبريل 2020 في سان بطرسبرج. التفاصيل والتذاكر صلة. 9 نوفمبر ، 18:00. HighLoad ++ موسكو 2018 ، دلهي + قاعة كولكاتا. الملخصات و عرض.

Evgeny Kuzovlev (المشار إليه فيما يلي باسم EC): - أيها الأصدقاء ، مرحبًا! اسمي يفغيني كوزوفليف. أنا من EcommPay ، قسم محدد هو EcommPay IT ، قسم تكنولوجيا المعلومات في مجموعة الشركات. واليوم سنتحدث عن أوقات التعطل - عن كيفية تجنبها ، وكيفية تقليل عواقبها إذا لم يكن بإمكانك تجنبها. تم ذكر الموضوع على النحو التالي: "ماذا تفعل عندما تكلف دقيقة توقف 100 دولار"؟ بالنظر إلى المستقبل ، فإن أرقامنا قابلة للمقارنة.

ماذا تفعل EcommPay IT؟

من نحن؟ لماذا أقف هنا أمامك؟ لماذا يحق لي إخبارك بشيء هنا؟ وماذا سنتحدث هنا بمزيد من التفصيل؟

مجموعة شركات EcommPay هي مستحوذ دولي. نقوم بمعالجة المدفوعات في جميع أنحاء العالم - في روسيا وأوروبا وجنوب شرق آسيا (في جميع أنحاء العالم). لدينا 9 مكاتب ، إجمالي 500 موظف ، وأقل من نصفهم بقليل متخصصون في تكنولوجيا المعلومات. كل ما نقوم به ، كل ما نربح منه المال ، فعلناه بأنفسنا.

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

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

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

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

أعطال. أوامر التشغيل.

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

عندما بدأنا في تغيير نهجنا ، شكلنا 4 وصايا. يتم تقديمها على الشرائح:

هذه الوصايا بسيطة للغاية:

• حدد المشكلة بسرعة.
• تخلص منه بشكل أسرع.
• ساعد في فهم السبب (لاحقًا ، للمطورين).
• وتوحيد المناهج.

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

استكشاف الأخطاء وإصلاحها: متى تحدث وماذا تفعل حيالها؟

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

من أجل صياغة هذه المتطلبات ، قررنا أن نسأل أنفسنا السؤال: "متى لدينا مشاكل"؟ والمشكلات كما اتضح تحدث في أربع حالات:

• فشل في الأجهزة.
• فشل الخدمات الخارجية.
• تغيير إصدار البرنامج (نفس النشر).
• عبء العمل المتفجر.

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

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

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

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

من بين هذه المشكلات الأربع ، يتم حل العديد منها على الفور إذا كان لديك سحابة. إذا كنت في Microsoft Azhur ، أو سحابات Ozone ، فاستخدم سحاباتنا ، من Yandex أو Mail ، فعندئذٍ على الأقل يصبح عطل في الأجهزة مشكلتهم ويصبح كل شيء على ما يرام على الفور في سياق عطل في الأجهزة.

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

تغيير إصدار البرنامج. القواعد

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

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

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

متطلبات ترقية البرامج

هناك ثلاثة من هذه المتطلبات:

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

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

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

  انتشار أزرق / أخضر. التوجيه

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

  • هذه واجهة أمامية (صفحات الدفع التي يراها عملاؤنا) ؛
  • جوهر المعالجة
  • محول للعمل مع أنظمة الدفع (بنوك ، ماستر كارد ، فيزا ...).

  وهنا يوجد فارق بسيط - يكمن فارق بسيط في التوجيه بين السطور. إذا قمت فقط بتبديل 100٪ من حركة المرور ، فلن تواجه هذه المشكلات. ولكن إذا كنت تريد تبديل 2٪ ، تبدأ في طرح الأسئلة: "كيف تفعل ذلك؟" الأبسط ، في الجبهة: يمكنك ، عن طريق الاختيار العشوائي ، إعداد Round Robin في nginx ، ولديك 2٪ إلى اليسار ، و 98٪ إلى اليمين. لكن هذا لا يعمل دائمًا.

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

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

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

  لم يناسبنا ، لأنه كان لدينا بالفعل nginx منتظم. التحول إلى nginx + ليس باهظ التكلفة ، لقد كان مؤلمًا قليلاً بالنسبة لنا وليس صحيحًا تمامًا. "جلسات Sticks" ، على سبيل المثال ، لم تنجح معنا لسبب بسيط وهو أن "جلسات Sticks" لا تسمح بالتوجيه على أساس "إما - أو". هناك يمكنك تحديد ما نقوم به "جلسات التثبيت" ، على سبيل المثال ، عن طريق عنوان IP أو عنوان IP وعن طريق ملفات تعريف الارتباط أو عن طريق المعلمة اللاحقة ، ولكن "إما - أو" أصعب بالفعل هناك.

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

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

  انتشار أزرق / أخضر. المميزات والعيوب

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

  
  
  لذلك ، لم يناسبنا - لقد اتخذنا الصراحة. وفقًا لذلك ، مع التوجيه ، حصلنا عليه على النحو التالي:

  يحتوي Blue / Green Deploy ، على التوالي ، على المزايا التي ذكرتها ، والعيوب.

  العيب الثاني:

  • عليك أن تهتم بالتوجيه ؛
  • العيب الرئيسي الثاني هو التكلفة.

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

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

  كيف أقوم بنشر سريع؟

  تحدثنا عن كيفية حل مشكلة التقليل والتراجع السريع ، لكن يبقى السؤال: "كيف يتم النشر بسرعة"؟

  
  
  هذا قصير وبسيط.

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

    ما هي القطع الأثرية؟ القطعة الأثرية عبارة عن بناء مُجمَّع تم فيه إكمال جزء التجميع بالكامل بالفعل. نقوم بتخزين هذه القطعة الأثرية في مستودع القطع الأثرية. استخدمنا مستودعين من هذا القبيل في وقت واحد - كان Nexus والآن jFrog Artifactory). استخدمنا في البداية Nexus لأننا بدأنا ممارسة هذا النهج في تطبيقات جافا (كان مناسبًا تمامًا لذلك). ثم تم وضع بعض التطبيقات المكتوبة بلغة PHP هناك ؛ ولم يعد Nexus مناسبًا ، ولذلك اخترنا jFrog Artefactory ، والذي يمكنه صناعة كل شيء تقريبًا. حتى أننا توصلنا إلى استنتاج مفاده أننا نقوم بتخزين حزمنا الثنائية الخاصة بنا في مستودع القطع الأثرية هذا ، والذي نجمعه للخوادم.

  نمو الحمولة المتفجرة

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

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

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

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

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

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

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

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

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

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

  يراقب. كيف تحدد المشكلة بسرعة؟

  الآن النقطة الأولى - "كيف تحدد المشكلة بسرعة؟" يراقب! علينا أن نفهم بسرعة أشياء معينة. ما هي الأشياء التي نحتاج لفهمها بسرعة؟

  
  
  ثلاثة أشياء!

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

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

  
  
  نستخدم Zabbix لمراقبة الأجهزة ومراقبة المؤشرات الرئيسية للخوادم. "Okmeter" نستخدمها لقواعد البيانات. نستخدم "جرافانا" و "بروميثيوس" لجميع المؤشرات الأخرى التي لا تتناسب مع أول مؤشرين ، وبعضها - مع "جرافانا" و "بروميثيوس" ، والبعض الآخر - "جرافانا" مع "إنفلوكس" وتليجراف.

  قبل عام كنا نريد استخدام New Relic. شيء رائع ، يمكنها فعل كل شيء. لكن بقدر ما تعرف كل شيء ، فهي باهظة الثمن. عندما زاد حجمنا إلى 1,5 ألف خادم ، جاء إلينا بائع وقال: "لنبرم اتفاقية للعام المقبل". نظرنا إلى السعر ، لا ، لن نفعل ذلك. الآن نتخلى عن New Relic ، لدينا حوالي 15 خادمًا متبقيًا تحت مراقبة New Relic. كان السعر باهظًا للغاية.

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

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

  ما هي المقاييس المهمة التي يجب مراقبتها؟

  ما الذي نرصده بشكل أساسي؟ ما هي المقاييس المهمة بالنسبة لنا؟

  
  

  • وقت الاستجابة / RPS على الجبهات هو مؤشر مهم للغاية. يرد على الفور أن هناك شيئًا ما خطأ فيك.
  • عدد الرسائل التي تمت معالجتها في كافة قوائم الانتظار.
  • عدد العمال.
  • مقاييس الصحة الأساسية.

  النقطة الأخيرة هي مقياس "عمل" و "عمل". إذا كنت ترغب في مراقبة نفس الشيء ، فأنت بحاجة إلى تحديد مقياس أو مقياسين يمثلان المؤشرات الرئيسية بالنسبة لك. لدينا مثل هذا المقياس - هذا هو الإنتاجية (هذه هي نسبة عدد المعاملات الناجحة إلى التدفق الإجمالي للمعاملات). إذا تغير شيء ما في فترة 5-10-15 دقيقة ، فإننا نواجه مشاكل (إذا تغيرت بشكل كبير).

  كيف تبدو بالنسبة لنا - مثال على أحد لوحاتنا:

  
  
  على الجانب الأيسر - 6 رسوم بيانية ، على التوالي ، على طول الخطوط - عدد العمال وعدد الرسائل في قوائم الانتظار. على الجانب الأيمن - RPS ، RTS. يوجد أدناه نفس مقياس "النشاط التجاري". وفي مقياس "الأعمال" ، يمكننا أن نرى على الفور حدوث خطأ ما في المخططين الأوسطين ... هذا مجرد نظام آخر تخلف عن الركب.

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

  
  
  يوضح الرسم البياني أن أحد أنظمة الدفع بدأ في الاستجابة خلال 3 ثوانٍ - لدينا مشاكل. في نفس الوقت ، هذا الشيء سوف يتفاعل عندما تبدأ المشاكل ، بفاصل 20-30 ثانية.

  والفئة الثالثة من أخطاء المراقبة الموجودة هي المراقبة المنطقية.

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

  
  
  ماذا أعني بالمراقبة المنطقية؟ حسنًا ، تخيل: أنت تجعل من نفسك نظامًا (على سبيل المثال ، نسخة من Tinder) ؛ قمت بإنجازه ، أطلقه. قام المدير الناجح Vasya Pupkin بوضعه على هاتفه ، ورأى فتاة هناك ، وأحبها ... وما شابه ذلك لا يذهب إلى الفتاة - مثل يذهب إلى حارس الأمن Mikhalych من نفس المركز التجاري. نزل المدير إلى الطابق السفلي ، ثم يتساءل: "لماذا يبتسم له حارس الأمن ميخاليش بسرور شديد"؟

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

  كان هذا يتعلق بمسألة كيفية تحديد المشكلة بسرعة.

  كيفية تحديد أسباب النشر

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

  
  
  إذا كنا نتحدث عن السجلات (السبب الرئيسي هو السجلات) ، فإن الجزء الرئيسي من السجلات التي لدينا في ELK Stack - يمتلكها الجميع تقريبًا. قد لا يكون لدى البعض ELK ، ولكن إذا كتبت سجلات بالجيجابايت ، فستأتي عاجلاً أم آجلاً إلى ELK. نكتبها بالتيرابايت.

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

  فكرنا في الأمر قبل عام ، ووجهنا أعيننا نحو السوق ، وتبين أن هناك أداتين - Zipkin و Jaeger. "هانتسمان" هو في الحقيقة وريث أيديولوجي ، الخليفة الأيديولوجي لـ "زيبكين". في "Zipkin" كل شيء على ما يرام ، باستثناء أنه لا يعرف كيفية التجميع ، لا يعرف كيفية تضمين السجلات في التتبع ، فقط تتبع الوقت. وأيدها جايجر.

  نظرنا إلى Jaeger: يمكنك استخدام الأدوات ، ويمكنك الكتابة في Api (ومع ذلك ، لم تتم الموافقة على معيار Api لـ PHP في ذلك الوقت - كان قبل عام ، ولكن تمت الموافقة عليه الآن بالفعل) ، ولكن كان هناك بالتأكيد لا يوجد عميل. اعتقدنا ، "حسنًا" ، وكتبنا عميلنا. ماذا حصلنا؟ هذه عن كيفية الشبه:

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

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

  تبعا لذلك ، لقد عملنا بشكل جيد. كتبنا امتدادنا الخاص ، وفتحناه. إذا كنت ترغب في العمل مع التتبع ، إذا كنت تريد العمل مع "Huntsman" في PHP ، فهناك امتدادنا ، مرحبًا بك في الاستخدام ، كما يقولون:

  
  
  لدينا هذا الامتداد - هذا عميل لـ OpenTracing Api ، تم إنشاؤه كامتداد php ، أي أنك ستحتاج إلى تجميعه ووضعه في النظام. قبل عام لم يكن هناك شيء آخر. الآن هناك عملاء آخرين يشبهون المكونات. الأمر متروك لك هنا: إما أن تقوم بتنزيل المكونات كمؤلف ، أو تستخدم الامتداد الخاص بك.

  معايير الشركة

  تحدثنا عن الوصايا الثلاث. الوصية الرابعة هي توحيد المناهج. عن ماذا يتكلم؟ يتعلق الأمر بهذا:

  
  
  لماذا كلمة "شركة" هنا؟ ليس لأننا شركة كبيرة أو بيروقراطية ، لا! أود استخدام كلمة "شركة" هنا في سياق حقيقة أن كل شركة وكل منتج يجب أن يكون له معاييره الخاصة ، بما في ذلك معاييرك. ما هي المعايير التي لدينا؟

  
  

  • لدينا جدول زمني للنشر. لا يمكننا التحرك في أي مكان بدونه ، لا يمكننا ذلك. ننشر حوالي 60 مرة في الأسبوع ، أي أننا ننشر بشكل شبه دائم. في الوقت نفسه ، لدينا ، على سبيل المثال ، في لوائح النشر ، من المحرمات لعمليات النشر يوم الجمعة - من حيث المبدأ ، نحن لا ننشر.
  • نحن بحاجة إلى وثائق. لا يدخل أي مكون جديد في الإنتاج إذا لم يكن هناك توثيق له ، حتى لو وُلد تحت قلم RnD-shnikov الخاص بنا. نطلب منهم تعليمات للنشر ، وخريطة مراقبة ووصف تقريبي (حسنًا ، كيف يمكن للمبرمجين الكتابة) لكيفية عمل هذا المكون ، وكيفية استكشاف الأخطاء وإصلاحها.
  • نحن لا نحل سبب المشكلة ، ولكن المشكلة - ما قلته بالفعل. من المهم بالنسبة لنا حماية المستخدم من المشاكل.
  • لدينا تصاريح. على سبيل المثال ، لا نعتبرها فترة تعطل إذا فقدنا 2٪ من حركة المرور في غضون دقيقتين. هذا ، من حيث المبدأ ، لا يقع في إحصائياتنا. إذا كانت أكثر كنسبة مئوية أو مؤقتة ، فإننا نعتبرها بالفعل.
  • ونحن دائما نكتب تشريح الجثة. أيا كان ما يحدث لنا ، أي موقف عندما تصرف بشكل غير طبيعي في الإنتاج ، سوف ينعكس في موت الجراثيم. تشريح الجثة هو مستند تكتب فيه ما حدث لك ، والتوقيت التفصيلي ، وما فعلته لإصلاحه و (هذه كتلة إلزامية!) ما الذي ستفعله لمنع حدوث ذلك في المستقبل. هذا ضروري لمزيد من التحليل.

  ما الذي يعتبر تعطل؟

  
  
  إلى ماذا أدى كل هذا؟

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

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

  هذا كل شئ! أسئلتك.

  
  

  حول الموازنات وترحيل قاعدة البيانات

  سؤال من الحضور (فيما بعد - ب): - مساء الخير. شكرا جزيلا لتقرير المشرف لك! سؤال قصير حول الموازين الخاصة بك. لقد ذكرت أن لديك WAF ، أي ، كما أفهمها ، تستخدم بعضًا خارجيًا كموازن ...

  EC: - لا ، نحن نستخدم خدماتنا الخاصة كموازن. في هذه الحالة ، WAF هي أداة حماية DDoS حصريًا لنا.

  В: - هل يمكنني قول بضع كلمات عن الموازين؟

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

  В: - أيضا سؤال بسيط. هنا هو نشر الأزرق / الأخضر. وماذا تفعل ، على سبيل المثال ، بترحيل قاعدة البيانات؟

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

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

  В: - مرحبًا. شكرا على التقرير. السؤال هو. أنت تراقب المدفوعات ، تراقب الخدمات التي تتواصل معها ... لكن كيف تراقب حتى يأتي شخص بطريقة ما إلى صفحة الدفع الخاصة بك ، ويقوم بالدفع ، ويضيف له المشروع أموالاً؟ أي كيف تراقب أن السوق متاح وقبول رد الاتصال الخاص بك؟

  EC: - "التاجر" بالنسبة لنا في هذه الحالة هو بالضبط نفس الخدمة الخارجية مثل نظام الدفع. نحن نراقب سرعة استجابة التاجر.

  حول تشفير قاعدة البيانات

  В: - مرحبًا. لدي القليل من السؤال. لديك بيانات حساسة لـ PCI DSS. أردت أن أعرف كيف تقوم بتخزين PANs في قوائم الانتظار ، والتي تحتاج إلى المرور إليها؟ ما نوع التشفير الذي تستخدمه؟ ومن هنا السؤال الثاني التالي: وفقًا لـ PCI DSS ، من الضروري إعادة تشفير قاعدة البيانات بشكل دوري في حالة حدوث تغييرات (إقالة المسؤولين ، وما إلى ذلك) - كيف تحدث إمكانية الوصول في هذه الحالة؟

  
  
  EC: - سؤال رائع! أولاً ، لا نقوم بتخزين PANs في قوائم الانتظار. ليس لدينا الحق في تخزين PAN في أي مكان بشكل واضح ، من حيث المبدأ ، لذلك نستخدم خدمة خاصة (نسميها "Kademon") - هذه خدمة لا تفعل سوى شيئًا واحدًا: تأخذ الرسالة كمدخل وتعطي رسالة مشفرة. ونخزن كل شيء بهذه الرسالة المشفرة. وفقًا لذلك ، لدينا طول مفتاح أقل من كيلوبايت ، بحيث يكون جادًا وموثوقًا بشكل مباشر.

  В: - هل تحتاج 2 كيلو بايت الآن؟

  EC: - يبدو أن بالأمس كان هناك 256 ... حسنًا ، أين غير ذلك ؟!

  وفقًا لذلك ، هذا هو الأول. وثانيًا ، الحل الموجود ، فهو يدعم إجراء إعادة التشفير - هناك زوجان من "keks" (المفاتيح) التي توفر "مجموعات" تُشفَّر (المفتاح عبارة عن مفاتيح ، أما dek فهي مشتقات من المفاتيح التي تُشفَّر). وفي حالة بدء الإجراء (يتم إجراؤه بانتظام ، من 3 أشهر إلى ± البعض) ، نقوم بتحميل زوج جديد من "keks" ، ويتم إعادة تشفير البيانات. لدينا خدمات منفصلة تقوم بنزع جميع البيانات وتشفيرها بطريقة جديدة ؛ بجانب البيانات يتم تخزين معرف المفتاح الذي يتم تشفيره به. وفقًا لذلك ، بمجرد تشفير البيانات بمفاتيح جديدة ، نحذف المفتاح القديم.

  في بعض الأحيان ، يلزم إجراء الدفعات يدويًا ...

  В: - هذا هو ، إذا جاءت عودة لبعض العمليات ، فهل فك تشفيرها بالمفتاح القديم في الوقت الحالي؟

  EC: - نعم.

  В: "ثم سؤال واحد صغير. عند حدوث نوع من الفشل والسقوط والحادث ، من الضروري دفع المعاملة في الوضع اليدوي. هناك مثل هذا الوضع.

  EC: - نعم احيانا.

  В: - من أين تحصل على هذه البيانات؟ أو هل أنت نفسك تمشي مع أقلام في هذا القبو؟

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

  
  
  В: - لدي بضعة أسئلة. أحدها هو استمرار منطقة PCI DSS: كيف يمكنك إخراج سجلات دائرتهم؟ مثل هذا السؤال لأن المطور يمكنه وضع أي شيء في السجلات! السؤال الثاني: كيف تطرح الإصلاحات العاجلة؟ المقابض في قاعدة البيانات - هذا خيار واحد ، ولكن قد تكون هناك إصلاحات فورية مجانية - ما هو الإجراء هناك؟ والسؤال الثالث ربما يتعلق بـ RTO ، RPO. كان توفرك 99,97 ، أي ما يقرب من أربعة تسعات ، ولكن كما أفهمها ، لديك مركز بيانات ثانٍ ومركز بيانات ثالث ومركز بيانات خامس ... كيف يمكنك مزامنتها وتكرارها وكل شيء آخر؟

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

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

  В: - إذا كان لديك واحد ثان ، فلماذا لم يظهر ثالث؟ لأن انقسام الدماغ لا يزال لا أحد ...

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

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

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

  В: - أين قطعته؟ تم إرسال الأساسية ...

  EC: - نحن وراء "Kor" في هذه الحالة للمعاملات الاختبارية ... لدينا شيء مثل التوجيه: يعرف "Kor" نظام الدفع الذي يجب الإرسال إليه - نرسله إلى نظام دفع مزيف يعطي فقط إيقاع http وهذا هو - هي.

  В: - أخبرني ، من فضلك ، هل طلبك مكتوب في قطعة واحدة ضخمة ، أم أنك قطعته إلى بعض الخدمات أو حتى الخدمات المصغرة؟

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

  إذا تم اختراق خدمة على الخادم ...

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

  
  
  EC: - نعم بالتأكيد. المتطلبات الأمنية خطيرة للغاية. أولاً ، لدينا حركة مرور بيانات مفتوحة ، وفقط تلك المنافذ التي نفترض من خلالها حركة مرور البيانات. إذا كان المكون يتصل بقاعدة البيانات (على سبيل المثال ، Muskul) عبر 5-4-3-2 ، فسيتم فتح 5-4-3-2 فقط عليه ، والمنافذ الأخرى ، لن تكون اتجاهات حركة المرور الأخرى متاحة. بالإضافة إلى ذلك ، يجب أن تفهم أنه يوجد في إنتاجنا حوالي 10 حلقات أمان مختلفة. وحتى لو تم اختراق التطبيق بطريقة ما ، لا سمح الله ، فلن يتمكن المهاجم من الوصول إلى وحدة تحكم إدارة الخادم ، لأن هذه منطقة أمان شبكة مختلفة.

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

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

  كيف تعمل Visa و MasterCard و Sberbank

  В: - أريد توضيح النقطة المتعلقة بتحويل مستخدم من مركز بيانات إلى آخر. بقدر ما أعلم ، تعمل "Visa" و "MasterCard" على البروتوكول المتزامن الثنائي 8583 ، فهناك مزيج هناك. وأردت أن أعرف ، الآن أعني التحويل - هل هي "فيزا" و "ماستر كارد" مباشرة أم إلى أنظمة الدفع ، إلى المعالجة؟

  EC: - الأمر متروك للخلطات. لدينا مزيج في مركز بيانات واحد.

  В: - بشكل تقريبي ، هل لديك نقطة اتصال واحدة؟

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

  В: كيف يمكن حجزها؟ أعلم أن "Visa" تسمح باتصال واحد فقط من حيث المبدأ!

  EC: "إنهم يزودون المعدات بأنفسهم. على أي حال ، تلقينا معدات محجوزة في الداخل.

  В: - إذن الموقف من Connects Orange ...؟

  EC: - نعم.

  В: - لكن كيف في هذه الحالة: إذا اختفى مركز البيانات الخاص بك ، كيف يمكنك الاستمرار في استخدامه؟ أم أن حركة المرور توقفت للتو؟

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

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

  
  
  

  بعض الاعلانات 🙂

  أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، Cloud VPS للمطورين يبدأ من 4.99 دولارًا, تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: الحقيقة الكاملة حول VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps من 19 دولارًا أو كيفية مشاركة الخادم؟ (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).

  Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 جيجا هرتز 14C 64 جيجا بايت DDR4 4x960 جيجا بايت SSD 1 جيجابت في الثانية 100 تلفزيون من 199 دولارًا في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن كيفية بناء شركة البنية التحتية. فئة مع استخدام خوادم Dell R730xd E5-2650 v4 بقيمة 9000 يورو مقابل فلس واحد؟

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