ما ساعدنا على التكيف بسرعة مع التداول عبر الإنترنت في الظروف الجديدة

مرحبا!

اسمي ميخائيل، أنا نائب مدير تكنولوجيا المعلومات في Sportmaster. أريد أن أشارك قصة حول كيفية تعاملنا مع الصعوبات التي نشأت أثناء الوباء.

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

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

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

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

تشغيل الخدمات عبر الإنترنت

سيرجي كوليسنيكوف، المسؤول عن تشغيل المتجر الإلكتروني والخدمات الصغيرة

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

عدد الطلبات من 18 إلى 31 مارسعدد الطلبات المقدمة إلى خدمات الدفع الصغيرة عبر الإنترنتعدد الطلبات المقدمة على الموقع

في الرسم البياني الأول نرى أن الزيادة كانت حوالي 14 مرة، في الثانية - 4 مرات. نحن نعتبر أن مقياس وقت الاستجابة لتطبيقاتنا هو الأكثر دلالة. 

على هذا الرسم البياني نرى استجابة الجبهات والتطبيقات، ولأنفسنا قررنا أننا لم نلاحظ النمو على هذا النحو.

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

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

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

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

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

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

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

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

الاختبارات الفنية 

أورلوف سيرجي، رئيس مركز الكفاءة لتطوير الويب والهواتف المحمولة

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

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

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

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

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

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

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

وهنا القائمة المرجعية

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

الحوت الرابع هو المبادئ المعمارية والحلول التقنية. يمكننا أن نتحدث كثيرًا عن الهندسة المعمارية لفترة طويلة، لكني أريد التأكيد على بعض المبادئ التي أود التركيز عليها.

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

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

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

كيشي

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

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

بالإضافة إلى ذلك، فإن تغيير جهاز التسلسل إلى Kryo في Hazelcast أعطانا دفعة جيدة. وقد سمح لنا الانتقال من ReplicatedMap إلى IMap + Near Cache في Hazelcast بتقليل حركة البيانات عبر المجموعة. 

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

مكدس رد الفعل

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

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

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

Elasticsearch

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

لا تستخدم postfilter دون داع. مع وجود بيانات كبيرة في العينة الرئيسية، تقوم هذه العملية بتحميل قاعدة البيانات بشكل كبير جدًا. 

استخدم العمليات المجمعة حيثما أمكن ذلك.

API

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

وأخيرًا، لا تتخلص من كومة البيانات بأكملها، وكن واضحًا بشأن العقد المبرم بين المستهلكين والموردين.

التحول التنظيمي

إروشكينا إيلينا، نائبة مدير تكنولوجيا المعلومات

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

تم نقل جزء من هيكلنا للعمل على مبادئ وممارسات نهج المنتج. تم تشكيل فرق مسؤولة الآن عن تشغيل كل منتج وتطويره. يشارك الموظفون في هذه الفرق بنسبة 100% ويقومون ببناء عملهم على Scrum أو Kanban، اعتمادًا على ما يفضلونه، وإعداد مسار النشر، وتنفيذ الممارسات الفنية، وممارسات ضمان الجودة، وغير ذلك الكثير.

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

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

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

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

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

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

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

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

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

النتائج

خلال هذا الوقت العصيب، قمنا بصياغة المبادئ الأساسية التي يعتمد عليها تطوير البرمجيات، والتي أعتقد أنها ستكون ذات صلة بكل شركة تقوم بذلك.

الناس. هذا هو ما يعتمد عليه كل شيء. يجب أن يستمتع الموظفون بعملهم، وأن يفهموا أهداف الشركة وأهداف المنتجات التي يعملون فيها. وبالطبع يمكنهم التطور مهنيًا. 

Технология. من الضروري أن يكون لدى الشركة نهج ناضج للعمل مع مجموعتها التكنولوجية وبناء الكفاءات حيث تكون هناك حاجة إليها حقًا. يبدو بسيطا جدا وواضحا. وكثيرا ما يتم تجاهلها.

العمليات. من المهم تنظيم عمل فرق المنتج ومراكز الكفاءة بشكل صحيح، لإقامة تفاعل مع الشركة من أجل العمل معها كشريك.

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

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

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

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