منذ أربع سنوات ، تم الاحتفاظ بقاعدة عملاء بشكل منفصل في كل متجر ، بالإضافة إلى موقع آخر على الموقع.
في السلسلة السابقة: قبل ثلاث سنوات ، قررنا أننا بحاجة إلى القيام بتطويرنا في روسيا. قبل عامين ، بدأوا في كتابة التعليمات البرمجية الخاصة بهم بدلاً من تعديل رمز الشوكة للشركة الأم. ستكون قصة اليوم حول كيفية تحولنا من متراصة واحدة كبيرة Legacy إلى مجموعة من الخدمات الصغيرة الصغيرة المتصلة بواسطة نوع من الحافلات (أوركسترا).
أسهل حالة للمستخدم: قم بإجراء طلب عبر الموقع الإلكتروني واستلمه من متجر Leroy Merlin الحقيقي في روسيا. في السابق ، تمت معالجة طلبات المتجر عبر الإنترنت في تطبيق آخر بشكل عام ووفقًا لمخطط مختلف. نحتاج الآن إلى عرض شامل لكل المواقع بحيث تم تقسيم أي طلب إلى واجهة: أمين الصندوق في أحد المتاجر ، وتطبيقات الهاتف المحمول ، ومحطة في متجر ، وموقع ويب - أيًا كان. إذا وضعت Linux على الميكروويف ، فليكن الميكروويف. الشيء الرئيسي هو أن بعض الواجهات يمكن أن تدق واجهة برمجة التطبيقات (API) في الخلف وتقول إنك تحتاج إلى وضع مثل هذا الطلب. وتلقوا إجابة واضحة على هذا. وكانت القصة الثانية مع طلبات لتوافر وخصائص البضائع من بطاقته.
في المقدمة (سنكتب عن هذا قريبًا) ، لدينا وحش - AEM ، وخلفه في الخلف تطبيقان كبيران: OPUS و MoVe. الأول هو قاعدة بيانات لخصائص كل منتج (من الأبعاد إلى الأوصاف) ، والثاني هو المسؤول عن الخروج ، أي متراصة مكتب النقد. إذا تبسيطها إلى حد كبير.
ما الخطأ في أوبوس؟
OPUS هي قاعدة موزعة كبيرة. بتعبير أدق ، هو البرنامج الذي يوفر واجهة للوصول إلى قاعدة البيانات ، أي أنه يصل إلى قاعدة البيانات ، على سبيل المثال ، يبحث أو ببساطة يكشف واجهة برمجة التطبيقات (API) بحيث لا يذهب العملاء مباشرة إلى قاعدة البيانات. هذا البرنامج يعمل ويدعم في فرنسا. الميزة الثانية ،
كما قلنا من قبل ، هي أن خط التحسينات عليها طويل للغاية ، ونحن لسنا في قمة أولوياتنا مقارنة بوحدة الأعمال في فرنسا.
بصعوبة كبيرة ، يمكننا أن نفهم كيف يمكن للمطورين إجراء تغييرات دون وجود فريق من فرنسا ؛ لقد حصلت الموافقات الطويلة جدًا. ميزة صدر لمدة ستة أشهر. في الواقع ، في البداية أردنا القيام بتطويرنا ومراجعتهما ، ثم توصلنا إلى تطويرنا وبنيتنا التحتية واختباراتنا وبشكل عام تطويرنا. وفي الوقت نفسه ، طرد ما يقرب من ثلث رمز Legacy.
لكن العودة إلى OPUS. نظرًا لأن النظام يخزن المعلومات ذات الصلة حول مدى توفرها وخصائصها ومعاملاتها وأشياء أخرى ، فقد طرقناها لأي سبب. على وجه التحديد للموقع ، هذا يعني أنه إذا كان لدى المستخدم ثلاثة منتجات في السلة ، فأنت بحاجة إلى طرق قاعدة البيانات من كل صفحة ، لأنه يتم التحقق من مدى ملاءمتها. حتى إذا قمت بالطرق مرة واحدة للتخزين المؤقت ، ثم قمت بتحديثه بذكاء ، فلا تزال هناك ميزات. عند فتح صفحة الكتالوج بشكل عام ، تم أخذ جميع مواصفات المنتج من OPUS.
والخطوة المنطقية التالية هي أننا بدأنا في سحب OPUS بشكل متكرر وجعلنا قاعدتنا (بتعبير أدق ، خدمات micros مع قواعد). كان النظام ككل يسمى PUB الروسي.
ثم قاموا بإنشاء أوركسترا ، والتي يمكنها بالفعل تخزين المجاميع ، أي في الواقع - البيانات التي تم جمعها لبناء الصفحات. بمعنى أنه عندما يحوّل المستخدم عرض الصفحة من البطاقات إلى القوائم ، فإنه لا يزال هو نفسه الإجمالي ، فإن الواجهة الأمامية مختلفة فقط.
هذا هو ، تركنا OPUS الأصلي (لا يزال في فرنسا) ، لكن المرآة الكاملة تقريبًا "تمتص" ، والتي تقسم القاعدة إلى قطع ، جاهزة للتجميع في الأوركسترا. ويقوم أوركسترا بجمع وتخزين المجاميع (أو يستقبلها بسرعة ويبدأ في تخزينها) ، وهو ما تحتاجه الأنظمة الأخرى. نتيجة لذلك ، يعمل هذا الجزء كما ينبغي. من الوظائف الأصلية لـ OPUS الفرنسية ، تبقى حوالي خمسة بالمائة. قريبا سوف نستبدلها بالكامل.
ما هو الخطأ في فيلم؟
لا شيء خاص ، باستثناء حقيقة أننا قررنا التخلص من الشفرة بالكامل ، لأنها:
- كان قديمًا على كومة قديمة.
- أخذ في الاعتبار خصائص كل منطقة "Leroy Merlin" في سلسلة IFs.
- كان من الصعب للغاية القراءة والمحافظة على أن أفضل طريقة لإعادة التخزين هي "الكتابة مرة أخرى وعلى الفور توثيق بشكل طبيعي."
الذي فعلناه. فقط أعدنا كتابتها ليس كمتراصة ، ولكننا بدأنا في تقديم خدمات ميكروية لكل وظيفة فردية. وبعد ذلك تم نقل جزء من وظيفة MoVe مع التحول إلى خدمات microservice بسلاسة. وهكذا - واحدة تلو الأخرى ، حتى انتهت وظيفة MoVe بالكامل. أي أنه لا يزال يعمل ، ولكن في مكان ما في فراغ ودون تدفقات البيانات.
منذ أن بنينا المنصة من القطع ، تم تسمية المشروع ليغو.
ليغو تغير تماما هذا الوسط. نعم ، دعنا نوضح: الخلفية الحقيقية هي الحافلة القديمة ، وأنظمة الملفات ، وقواعد البيانات ، ومستوى البنية التحتية الأخرى تقريبًا. تطبيقات كبيرة حول هذا و microservices المنطق الأوسط. العرض هو بالفعل الجبهة.
لماذا تحتاج إلى إعادة كتابة كل هذا؟
لأننا عشنا مع العملاء قواعد منفصلة لكل مثيل 15 سنة من الافتتاح في روسيا ، وهذا لم يناسب أي شخص. لم يكن هناك التزامن أيضا. في بلدان أخرى ، ما زالوا يعيشون هكذا.
قامت الشركة الأم من فرنسا بصنع اللوجيستيات العامة ، قمنا بإعادة استخدام نظام Pixis - هذا هو مخزن واحد من الإيصالات ، أي طلبات العملاء: أحد المتاجر يرى أوامر متجر آخر. ولكن هذا لم يحل مشكلة ترتيب omnichannel بالكامل. لذلك ، كان من الضروري توحيد القاعدة والقيام بالمعالجة العامة. هذا هو الشيء الرئيسي.
السبب الثاني كان قانون شباك التذاكر الفيدرالي: مع وجود الجداول الزمنية لتطوير نظام مشترك (واختبار) لجميع البلدان ، لكان قد فرضنا عليه غرامة.
تم طرح خيار مماثل تقريبًا في البرازيل: لقد بدأوا تشغيل Leroy Merlin هناك بدون أي برنامج من الشركة الأم ، ونجحوا في ذلك. كان ذلك قبل قرار الانقسام. بالمناسبة ، يلتزمون كثيرًا
بالداخلين ، لديهم تطور سريع جدًا.
Pixis يسمح لتقديم طلب فقط من تسجيل النقدية ، في الواقع. لقد غيرنا الموقف على ثلاث مراحل:
- أولاً ، قمنا بعمل تطبيق للهاتف المحمول للموظف ، مما يبسط حياته إلى حد كبير. على أساس هذا ، بدأوا في بناء نظام بيئي حيث يتم فصل واجهات مع المنطق.
- بينما تم إعداد كل شيء ، تم توجيه طلبات الإنترنت إلى مكتب النقد باليد.
- وضعوا خدمات micros في بدورها ، والتي استبدلت كل شيء في الوسط.
لماذا كنت بحاجة للبدء في تطبيق المتجر؟ لأن لدينا مرة أخرى عمليات فريدة بالمقارنة مع فرنسا. على سبيل المثال ، قرر الشخص شراء ستة أمتار عشرة سنتيمترات من سلسلة في متجر. قام البائع بقطعه ، وقدم مستندًا عن المدة الزمنية التي يتكلفها وكم يكلفها. تذهب إلى أمين الصندوق بهذه القطعة من الورق ، وتدفعه هناك. من وجهة نظر المنطق ، لا ينبغي أن يكون البيع في شباك التذاكر ، ولكن يجب أن يكون لدى البائع ، ولكن في الواقع ، يبدأ الشيء الأكثر إثارة للاهتمام في شباك التذاكر: يجب أن يكون لديك كل من البضائع والورقة.
في النهاية ، سنكون منصة لتقديم الطلبات: الآن ، على سبيل المثال ، على نظامنا الرئيسي ، تمت إضافة خدمات شراء خدمات الماجستير (اشتريت مطبخًا - طلبت التثبيت من رئيسي خارجي ، لكننا وجدناه وأعطيني ضمانًا منا) ،
السوق ( الشراء المباشر من مورد عبر نطاق أوسع) ، وسرعان ما يجب أن يكون هناك شركة تابعة حتى يمكن وضع كتلنا في أي مكان. شيء مثل تضمين متاجر أمازون في المدونات ، فقط أكثر تنوعًا.
كيف تم اتخاذ قرار الاستبدال؟
أنا خطوة. صقل نموذج العمل.لقد فحصنا ، بل بالفعل: النموذج ، كما هو الحال في روسيا - الأسعار المنخفضة كل يوم - ناجح. يعد Leroy Merlin في أوروبا أغلى بكثير ، لكن في روسيا هذا المكان المناسب لنا: متجر للبناء حيث يمكنك بالتأكيد العثور على البضائع بأفضل سعر.
الخطوة الثانية. إنشاء برنامج نصي عميل.أي لبناء عمليات كما نريدهم أن يتفاعلوا معنا من وجهة نظر العميل. وهذا هو ، رؤية واحدة لمن نريد أن نكون في غضون سنوات قليلة وكيف تبدو من وجهة نظر الهندسة المعمارية.
الخطوة الثالثة. بناء العمارة.قم بتقسيم هذه الرؤية إلى المعارف التقليدية والهندسة المعمارية بتفاصيل أعلى. اتضح 110 مشاريع ، والتي قسمناها إلى خمس فئات لمدة خمس سنوات.
ثم شكلوا فرق متخصصة. في معظم الأحيان هؤلاء هم شعبهم بالإضافة إلى المقاول. في البداية ، عانوا كثيراً من هذا: عندما ذهبوا إلى الزناد ، لم يفهموا حقًا كيفية هضم هذا الحجم الكبير من التغييرات. ثم بدأوا في اتخاذ نهج مشترك للمهام وزيادة حصة تنميتها تدريجيا.
في تلك الأماكن التي كان فيها الخطأ حرجًا ، عملوا وفقًا لمخططات ناسا ، حيث الخطأ غير مقبول ، وليس خيارًا على الإطلاق. هذا هو كل شيء عن المعاملات المالية.
وحيث كان من الممكن السقوط ، كان الشيء الرئيسي هو الاستيقاظ بسرعة ، استخدمنا مقاربة قريبة من SRE من Google. تكرارا ، مع عضادات ، ولكن يمكن تنفيذ المشاريع في أقرب وقت ممكن. والآن نحن نقوم بالكثير ، وهو رائع جدًا للتطوير.
النهج الثالث هو الابتكار. لقد طورنا مجموعة من الأفكار للقيام بسرعة بأول MVPs من خلال مواردنا الداخلية ، والتي تتيح لنا الاختبار بسرعة وبتكلفة منخفضة. هذا هو الحقيقي "حاول بسرعة ، تفشل بسرعة". هذا سمح لك بالحصول على ميزانية وسلطة لأولئك الذين توصلوا إلى مشروع رائع.
وكان التركيز المهم الثاني في التنمية الجغرافية. ثم افتتح 20 متجرا سنويا (الآن أبطأ قليلا). ستة آلاف موظف. العديد من المناطق. كان من الضروري إعادة كتابة سلسلة التوريد بأكملها ، لتطوير عمليات بسرعة لرفع البنية التحتية للمتاجر.
في عام 2017 ، قررنا أن نصبح منصة لأوامر البناء: هذه إستراتيجية واعدة لعدة سنوات قادمة.
بالنسبة للجغرافيا ، كنا بحاجة إلى مكتب خلفي كبير لتكنولوجيا المعلومات لنمو الشركة ونمو سلسلة التوريد. من أجل omnichannel (ترتيب عام) - مستوى مختلف من SLA للأنظمة الداخلية ، في الوقت الفعلي ، والخدمات المصغرة والتزامن بين مئات الأنظمة الفرعية. هذا هو عادة مستوى مختلف من نضج تكنولوجيا المعلومات. بالنسبة للمنصة ، تعد سرعة التغيير مهمة أيضًا.
عندما كان قد بدأ للتو ، اعتقد الجميع أن خفة الحركة من شأنها إنقاذ العالم. مع المقاولين ، قد لا تكون رشيقة فعالة. ومن هنا الرغبة في
توظيف 200 شخص في قسم تكنولوجيا المعلومات.
شاهدنا مدى سرعة تنفيذ كل شيء دون خسارة للعلامة التجارية. يمكن كتابة شيء بسرعة ، لكن لم يتح له الوقت لإعداد الخدمة. على سبيل المثال ، إذا لم تكن هناك معلومات عن المخزون ، فلا توجد طريقة للدفع عبر الإنترنت دون ضمان حجز البضائع. نحن متحللة سلسلة من الاعتمادات المتبادلة إلى عدة. الآن نحن نعرف بالفعل أننا بحاجة إلى جعل الدورات أقصر ، لأن كفاءات الفريق لا تزال مهمة. الآن نحن نشهد ميزات في قطع صغيرة ، نقوم بجمع اتصال ، والآن فقط العام الحالي هو في الخطط. تعد الإستراتيجية طويلة الأجل ، ولكن حسب الميزات ، بحد أقصى لمدة عام واحد ، والعديد من فرق المنتجات المنفصلة.