الخدمات القديمة في البنية التحتية الخاصة بك

مرحبًا! اسمي باشا تشيرنياك، وأنا مطور رائد في QIWI، واليوم أريد أن أتحدث عن الأمر الذي لا مفر منه. حول التراث.

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

قبل الانتقال إلى كيفية عمل QIWI مع خدماتنا القديمة، سأخبرك كيف قمنا بتنظيم الخدمات في Wallet. منذ عامين وأنا مسؤول عن أدائها. إذا كانت هناك أي مشكلة، فإنهم يتصلون بي دائمًا أولاً. عادةً لا أمتلك الجرأة للاتصال بشخص آخر في الساعة 11 مساءً، لذلك كان علي الجلوس والتعرف على جميع الخدمات المتوفرة في نطاقنا.

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

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

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

مع مرور الوقت، بدأ تطبيق ممارسات جديدة، على سبيل المثال، الترحيل إلى Kubernetes، وجميع أنواع checkstyle، وspotbugs، وktlint، ووجود السجلات في Kibana، وخدمات الاكتشاف التلقائي بدلاً من تحديد العناوين مباشرة والأشياء المفيدة الأخرى. وفي كل مكان سمحت لنا طاولتنا بالحفاظ على أهمية خدماتنا. بالنسبة لنا، هذا نوع من القائمة المرجعية التي تقول إن هذه الخدمة يمكنها القيام بذلك، لكنها لم تفعل ذلك بعد، لكننا مضينا قدمًا، مدركين أننا نفتقر إلى معلومات حول خدماتنا، التي نراقبها، وأماكن تواجد مصادر الخدمة، حيث يتم إطلاق مهام التجميع في TeamCity، وكيفية نشرها، ومكان تخزين مصادر اختبارات end2end، وصور من جلسات التهيئة حول البنية، وحول القرارات المتخذة. من الناحية المثالية، أود أن تكون كل هذه المعلومات موجودة في مكان ما وأن تكون في متناول اليد عند الحاجة. لذلك أصبحت علامتنا نقطة البداية للبحث عن المعلومات.

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

كيف يحدث ذلك

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

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

الشيء هو أنه ليس لدينا الآن عميل مسؤول عن هذه الخدمة. ما هي متطلبات العمل لديه، ماذا يجب أن تفعل هذه الخدمة؟ ويتم دمج الخدمة بإحكام في عمليات عملك.

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

مع ما نبدأ؟

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

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

ما يجب القيام به

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

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

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

ونتيجة لذلك، أود أن أضع خطة لما يجب فعله بالخدمات القديمة.

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

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

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

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

ماذا تفعل مع تراثك؟

• 31.5%أنا أعيد الكتابة من الصفر، هذا الأصح 12

• 52.6%تقريبا نفس مثلك20

• 10.5%ليس لدينا إرث، نحن عظماء4

• 5.2%سأكتب في التعليقات2

صوت 38 مستخدمين. امتنع 20 مستخدما عن التصويت.

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