في 25 أبريل، عقدنا في مجموعة Mail.ru مؤتمرًا حول السحب وما حولها - . بعض النقاط البارزة:
- الرئيسي - تحدثت Mail.ru Cloud Solutions و#CloudMTS وSberCloud وSelectel وRostelecom Data Center وYandex.Cloud عن تفاصيل السوق السحابية لدينا وخدماتها؛
- أخبر زملاء Bitrix24 كيف فعلوا ذلك ;
- قدمت شركات Leroy Merlin وOtkritie وBurger King وSchneider Electric اهتمامًا كبيرًا - ما هي المهام التي تحددها أعمالهم لتكنولوجيا المعلومات وما هي التقنيات، بما في ذلك التقنيات السحابية، التي يرون أنها الأكثر واعدة.
يمكنك مشاهدة جميع مقاطع الفيديو من مؤتمر mailto:CLOUD ، وهنا يمكنك أن تقرأ كيف سارت المناقشة حول الخدمات المصغرة. شارك ألكسندر ديولين، رئيس مركز أبحاث وتطوير أنظمة الأعمال MegaFon، وسيرجي سيرجيف، مدير تكنولوجيا المعلومات في مجموعة M.Video-Eldorado، حالاتهما الناجحة في التخلص من الكتل المتراصة. ناقشنا أيضًا القضايا ذات الصلة باستراتيجية تكنولوجيا المعلومات والعمليات وحتى الموارد البشرية.
أعضاء اللجنة
- سيرجي سيرجيف، رئيس قسم تكنولوجيا المعلومات للمجموعة "M.Video-الدورادو";
- ألكسندر ديولين، رئيس مركز أبحاث وتطوير نظم الأعمال ميجافون;
- المشرف — ديمتري لازارينكو، رئيس اتجاه PaaS حلول سحابة Mail.ru.
بعد خطاب الكسندر ديولين انضم إليه للمناقشة سيرجي سيرجيف من M.Video-Eldorado ومدير المناقشة ديمتري لازارينكو، Mail.ru Cloud Solutions.
أدناه قمنا بإعداد نص المناقشة لك، ولكن يمكنك أيضًا مشاهدة الفيديو:
يعد الانتقال إلى الخدمات الصغيرة بمثابة استجابة لاحتياجات السوق
ديمتري:
هل كانت لديك أي تجربة ناجحة في الانتقال إلى الخدمات المصغرة؟ وبشكل عام: أين ترى أكبر استفادة تجارية من استخدام الخدمات المصغرة أو الانتقال من الوحدات المتراصة إلى الخدمات الصغيرة؟
سيرجي:
لقد قطعنا شوطًا بالفعل في التحول إلى الخدمات الصغيرة ونستخدم هذا النهج منذ أكثر من ثلاث سنوات. كانت الحاجة الأولى التي بررت الحاجة إلى الخدمات الصغيرة هي التكامل اللامتناهي لمختلف المنتجات الأمامية مع المكتب الخلفي. وفي كل مرة اضطررنا إلى إجراء المزيد من التكامل والتطوير، وتنفيذ قواعدنا الخاصة لتشغيل هذه الخدمة أو تلك.
في مرحلة ما، أدركنا أننا بحاجة إلى تسريع تشغيل أنظمتنا وإخراج الوظائف. في تلك اللحظة، كانت مفاهيم مثل الخدمات الصغيرة ونهج الخدمات الصغيرة موجودة بالفعل في السوق، وقررنا تجربتها. بدأ هذا في عام 2016. ثم تم وضع المنصة وتنفيذ أول 10 خدمات من قبل فريق منفصل.
إحدى الخدمات الأولى، والأكثر تحميلًا، كانت خدمة حساب الأسعار. في كل مرة تأتي فيها إلى أي قناة، إلى مجموعة شركات M.Video-Eldorado، سواء كان موقعًا إلكترونيًا أو متجر بيع بالتجزئة، حدد منتجًا هناك، واطلع على السعر على موقع الويب أو في "السلة"، يتم تحديد التكلفة تلقائيًا تحسب بواسطة خدمة واحدة. لماذا هذا ضروري: قبل ذلك، كان لكل نظام مبادئه الخاصة للعمل مع العروض الترويجية - مع الخصومات وما إلى ذلك. يتولى مكتبنا الخلفي عملية التسعير، ويتم تنفيذ وظيفة الخصم في نظام آخر. يجب أن يكون هذا مركزيًا وأن يتم إنشاء خدمة فريدة وقابلة للفصل في شكل عملية تجارية تسمح لنا بتنفيذ ذلك. هذا إلى حد كبير كيف بدأنا.
وكانت قيمة النتائج الأولى كبيرة جدًا. أولاً، تمكنا من إنشاء كيانات قابلة للفصل تسمح لنا بالعمل بشكل منفصل وبطريقة مجمعة. ثانياً، قمنا بتخفيض تكلفة الملكية من حيث التكامل مع المزيد من الأنظمة.
على مدى السنوات الثلاث الماضية، أضفنا ثلاثة أنظمة للخطوط الأمامية. وكان من الصعب الحفاظ عليها بنفس القدر من الموارد التي تستطيع الشركة تحملها. ولذلك نشأت مهمة البحث عن منافذ جديدة تستجيب للسوق من حيث السرعة ومن حيث التكاليف الداخلية والكفاءة.
كيفية قياس نجاح الانتقال إلى الخدمات المصغرة
ديمتري:
كيف يتم تحديد النجاح في الانتقال إلى الخدمات المصغرة؟ ماذا كان "قبل" في كل شركة؟ ما هو المقياس الذي استخدمته لتحديد نجاح عملية النقل، ومن الذي حددها فعليًا؟
سيرجي:
أولا وقبل كل شيء، فقد وُلدت في مجال تكنولوجيا المعلومات كعامل تمكين - "فتح" قدرات جديدة. لقد كنا بحاجة إلى القيام بكل شيء بشكل أسرع وبنفس الأموال نسبيًا، والاستجابة لتحديات السوق. يتم الآن التعبير عن النجاح في عدد الخدمات التي يتم إعادة استخدامها بواسطة أنظمة مختلفة، وتوحيد العمليات فيما بينها. الآن هو كذلك، ولكن في تلك اللحظة كانت فرصة لإنشاء منصة وتأكيد الفرضية القائلة بأننا نستطيع القيام بذلك، وسوف يعطي تأثيرًا ويحسب دراسة الجدوى.
الكسندر:
النجاح هو بالأحرى شعور داخلي. الأعمال التجارية تريد دائمًا المزيد، وعمق الأعمال المتراكمة لدينا هو دليل على النجاح. يبدو لي ذلك.
سيرجي:
نعم اوافق. في ثلاث سنوات، لدينا بالفعل أكثر من مائتي خدمة ومتراكمة. تتزايد الحاجة إلى الموارد داخل الفريق بنسبة 30% سنويًا. يحدث هذا لأن الناس شعروا: إنه أسرع، وهو مختلف، وهناك تقنيات مختلفة، وكل هذا يتطور.
ستأتي الخدمات الصغيرة، لكن الجوهر سيبقى
ديمتري:
إنها بمثابة عملية لا تنتهي أبدًا حيث تستثمر في التنمية. هل انتهى التحول إلى الخدمات الصغيرة للأعمال بالفعل أم لا؟
سيرجي:
من السهل جدًا الإجابة. ما رأيك: استبدال الهواتف عملية لا نهاية لها؟ نحن أنفسنا نشتري الهواتف كل عام. وهنا هو: طالما أن هناك حاجة للسرعة، للتكيف مع السوق، ستكون هناك حاجة لبعض التغييرات. هذا لا يعني أننا نتخلى عن الأشياء القياسية.
لكن لا يمكننا تغطية وإعادة كل شيء مرة واحدة. لدينا خدمات تكامل قياسية قديمة كانت موجودة من قبل: حافلات المؤسسات وما إلى ذلك. ولكن هناك تراكم، وهناك أيضا حاجة. عدد تطبيقات الهاتف المحمول ووظائفها آخذ في الازدياد. وفي الوقت نفسه، لا أحد يقول أنك ستحصل على أموال إضافية بنسبة 30٪. أي أن هناك دائمًا احتياجات من جهة، وبحثًا عن الكفاءة من جهة أخرى.
ديمتري:
الحياة في حالة جيدة. (يضحك)
الكسندر:
بشكل عام، نعم. ليس لدينا أساليب ثورية لإزالة الجزء الأساسي من المشهد الطبيعي. يجري العمل بشكل منهجي لتحليل الأنظمة بحيث تكون أكثر اتساقًا مع بنية الخدمات المصغرة، لتقليل تأثير الأنظمة على بعضها البعض.
لكننا نخطط للاحتفاظ بالجزء الأساسي، لأنه سيكون هناك دائمًا في مشهد المشغل بعض المنصات التي نشتريها. ومرة أخرى، نحن في احتياج إلى توازن صحي: ولا ينبغي لنا أن نتسرع في التخلص من جوهر المشكلة. لقد وضعنا الأنظمة جنبًا إلى جنب، والآن اتضح أننا بالفعل فوق العديد من الأجزاء الأساسية. علاوة على ذلك، من خلال تطوير الوظيفة، نقوم بإنشاء التمثيلات اللازمة لجميع القنوات التي تعمل مع خدمات الاتصال الخاصة بنا.
كيفية بيع الخدمات الصغيرة للشركات
ديمتري:
أنا مهتم أيضًا - بالنسبة لأولئك الذين لم يتحولوا بعد، ولكنهم يخططون لذلك: ما مدى سهولة بيع هذه الفكرة للشركات وهل كانت مغامرة أم مشروعًا استثماريًا؟ أم أنها كانت استراتيجية واعية: الآن نحن نتجه إلى الخدمات المصغرة وهذا كل شيء، لن يوقفنا شيء. كيف كان ذلك بالنسبة لك؟
سيرجي:
لم نكن نبيع نهجًا، بل منفعة تجارية. كانت هناك مشكلة في العمل وحاولنا حلها. في تلك اللحظة، تم التعبير عن ذلك في حقيقة أن القنوات المختلفة تستخدم مبادئ مختلفة لحساب الأسعار - بشكل منفصل للترقيات، للترقيات، وما إلى ذلك. كان من الصعب صيانته، وحدثت أخطاء، واستمعنا إلى شكاوى العملاء. أي أننا كنا نبيع حلاً لمشكلة ما، لكننا أتينا بحقيقة أننا بحاجة إلى المال لإنشاء منصة. وقد أظهروا حالة تجارية باستخدام مثال المرحلة الأولى من الاستثمار: كيف سنستمر في استردادها وما الذي سيسمح لنا القيام به.
ديمتري:
هل قمت بطريقة ما بتسجيل وقت المرحلة الأولى؟
سيرجي:
نعم بالتأكيد. لقد خصصنا 6 أشهر لإنشاء النواة كمنصة واختبار الإصدار التجريبي. خلال هذا الوقت، حاولنا إنشاء منصة يمكن للطيار أن يتزلج عليها. ومن ثم تم تأكيد الفرضية، وبما أنها ناجحة فهذا يعني أنه يمكننا الاستمرار. لقد بدأوا في تكرار الفريق وتعزيزه - ونقلوه إلى قسم منفصل يقوم بذلك بالضبط.
بعد ذلك يأتي العمل المنهجي بناءً على احتياجات العمل والفرص وتوافر الموارد وكل ما هو قيد التنفيذ حاليًا.
ديمتري:
نعم. ألكسندر ماذا تقول؟
الكسندر:
ولدت خدماتنا الصغيرة من "زبد البحر" - بسبب توفير الموارد، بسبب بعض بقايا الطعام في شكل سعة الخادم وإعادة توزيع القوى داخل الفريق. في البداية، لم نبيع هذا المشروع للشركات. لقد كان هذا مشروعًا قمنا بالبحث فيه وتطويره وفقًا لذلك. لقد بدأنا في بداية عام 2018 وقمنا ببساطة بتطوير هذا الاتجاه بحماس. لقد بدأت المبيعات للتو ونحن في هذه العملية.
ديمتري:
هل يحدث أن يسمح لك العمل التجاري بالقيام بأشياء مثل Google - في يوم واحد مجاني في الأسبوع؟ هل لديك مثل هذا الاتجاه؟
الكسندر:
في نفس الوقت الذي نقوم فيه بالبحث، نتعامل أيضًا مع مشاكل العمل، لذا فإن جميع خدماتنا الصغيرة هي حلول لمشاكل العمل. في البداية فقط قمنا ببناء خدمات صغيرة تغطي جزءًا صغيرًا من قاعدة المشتركين، والآن نحن موجودون في جميع المنتجات الرئيسية تقريبًا.
والأثر المادي واضح بالفعل - يمكننا بالفعل إحصاء سرعة إطلاق المنتجات والإيرادات المفقودة إذا اتبعنا المسار القديم. وهذا هو ما نبني عليه القضية.
الخدمات المصغرة: ضجيج أم ضرورة؟
ديمتري:
الأرقام هي أرقام. والإيرادات أو الأموال التي يتم توفيرها مهمة جدًا. ماذا لو نظرت إلى الجانب الآخر؟ يبدو أن الخدمات المصغرة هي اتجاه وضجيج والعديد من الشركات تسيء استخدامها؟ ما مدى وضوح التمييز بين ما تفعله وما لا تترجمه إلى خدمات صغيرة؟ إذا كان الإرث الآن، فهل سيظل لديك إرث بعد 5 سنوات؟ ما هو عمر أنظمة المعلومات التي تعمل في M.Video-Eldorado و MegaFon خلال 5 سنوات؟ هل سيكون هناك أنظمة معلومات عمرها عشر سنوات أو خمسة عشر عاما أم سيكون هناك جيل جديد؟ كيف ترى هذا؟
سيرجي:
يبدو لي أنه من الصعب التفكير بعيدًا جدًا. إذا نظرنا إلى الوراء، من كان يتخيل أن سوق التكنولوجيا سيتطور بهذه الطريقة، بما في ذلك التعلم الآلي وتحديد المستخدم عن طريق الوجه؟ ولكن إذا نظرت إلى السنوات القادمة، يبدو لي أن الأنظمة الأساسية، وأنظمة فئة ERP للمؤسسات في الشركات - كانت تعمل لفترة طويلة.
يبلغ عمر شركاتنا مجتمعة 25 عامًا، مع وجود نظام تخطيط موارد المؤسسات (ERP) الكلاسيكي عميقًا جدًا في مشهد الأنظمة. من الواضح أننا نأخذ بعض القطع من هناك ونحاول تجميعها في خدمات صغيرة، لكن الجوهر سيبقى. من الصعب بالنسبة لي الآن أن أتخيل أننا سنستبدل جميع الأنظمة الأساسية هناك وننتقل بسرعة إلى الجانب الآخر المشرق من الأنظمة الجديدة.
أنا أؤيد حقيقة أن كل ما هو أقرب إلى العميل والمستهلك هو المكان الذي تكون فيه أعظم فائدة وقيمة للأعمال، حيث تكون القدرة على التكيف والتركيز على السرعة، وعلى التغيير، وعلى "المحاولة، والإلغاء، وإعادة الاستخدام، والقيام بشيء مختلف" مطلوب "- هذا هو المكان الذي سيتغير فيه المشهد. والمنتجات المعبأة لا تتناسب بشكل جيد مع هذه المنتجات. على الأقل لا نراها. هناك حاجة إلى الحلول الأسهل والأبسط.
ونرى هذا التطور:
- أنظمة المعلومات الأساسية (في الغالب المكتب الخلفي)؛
- تقوم الطبقات الوسطى في شكل خدمات صغيرة بتوصيل النواة وتجميعها وإنشاء ذاكرة تخزين مؤقت وما إلى ذلك؛
- أنظمة الخطوط الأمامية تستهدف المستهلك.
- طبقة تكامل يتم دمجها بشكل عام في الأسواق والأنظمة والأنظمة البيئية الأخرى. هذه الطبقة خفيفة قدر الإمكان وبسيطة وتحتوي على الحد الأدنى من منطق الأعمال.
لكن في الوقت نفسه، أنا أؤيد الاستمرار في استخدام المبادئ القديمة إذا تم استخدامها بشكل مناسب.
لنفترض أن لديك نظام مؤسسي كلاسيكي. إنه يقع في مشهد بائع واحد ويتكون من وحدتين تعملان مع بعضهما البعض. هناك أيضًا واجهة تكامل قياسية. لماذا إعادة ذلك وتقديم خدمة صغيرة هناك؟
ولكن عندما يكون هناك 5 وحدات في المكتب الخلفي، يتم من خلالها جمع أجزاء من المعلومات في عملية تجارية، والتي يتم استخدامها بعد ذلك بواسطة 8-10 أنظمة في الخطوط الأمامية، تكون الفائدة ملحوظة على الفور. أنت تأخذ من خمسة أنظمة للمكاتب الخلفية وتنشئ خدمة، خدمة معزولة، تركز على عملية الأعمال. جعل الخدمة متقدمة تقنيًا - بحيث تقوم بتخزين المعلومات مؤقتًا وتتحمل الأخطاء، وتعمل أيضًا مع المستندات أو الكيانات التجارية. ويمكنك دمجها وفقًا لمبدأ واحد مع جميع منتجات الخطوط الأمامية. لقد ألغوا منتج الخط الأمامي - لقد قاموا ببساطة بإيقاف التكامل. ستحتاج غدًا إلى كتابة تطبيق جوال أو إنشاء موقع ويب صغير ووضع جزء واحد فقط في الوظيفة - كل شيء بسيط: لقد قمت بتجميعه مثل المنشئ. أرى المزيد من التطور في هذا الاتجاه - على الأقل في بلدنا.
الكسندر:
لقد وصف سيرجي نهجنا بالكامل، شكرًا لك. سأقول فقط أين لن نذهب بالتأكيد - إلى الجزء الأساسي، إلى موضوع الفواتير عبر الإنترنت. وهذا يعني أن التصنيف والشحن سيظلان في الواقع دراسًا "كبيرًا" سيشطب الأموال بشكل موثوق. وسيستمر اعتماد هذا النظام من قبل السلطات التنظيمية لدينا. كل شيء آخر يتطلع إليه العملاء، بالطبع، هو خدمات صغيرة.
ديمتري:
هنا الشهادة قصة واحدة. ربما المزيد من الدعم. إذا كنت تنفق القليل على الدعم أو كان النظام لا يحتاج إلى الدعم والتعديل، فمن الأفضل عدم لمسه. حل وسط معقول.
كيفية تطوير خدمات صغيرة موثوقة
ديمتري:
بخير. ولكن ما زلت مهتما. أنت الآن تحكي قصة نجاح: كان كل شيء على ما يرام، وتحولنا إلى الخدمات الصغيرة، ودافعنا عن الفكرة أمام الشركة، ونجح كل شيء. لكني سمعت قصصًا أخرى.
قبل عامين، قامت شركة سويسرية استثمرت عامين في تطوير منصة جديدة للخدمات الصغيرة للبنوك بإغلاق المشروع في نهاية المطاف. انهارت تماما. تم إنفاق عدة ملايين من الفرنكات السويسرية، وفي النهاية تم تفريق الفريق - لم ينجح الأمر.
هل كان لديك قصص مماثلة؟ هل كانت أو هناك أي صعوبات؟ على سبيل المثال، يعد الحفاظ على الخدمات الصغيرة والمراقبة بمثابة صداع في الأنشطة التشغيلية للشركة. بعد كل شيء، يزيد عدد المكونات عشرات المرات. كيف ترى الأمر، هل كانت هناك أمثلة غير ناجحة للاستثمارات هنا؟ وبماذا يمكنك أن تنصح الناس حتى لا يواجهوا مثل هذه المشاكل؟
الكسندر:
وشملت الأمثلة غير الناجحة الشركات التي غيرت أولوياتها وإلغاء المشاريع. عندما تكون الشركة في مرحلة جيدة من الاستعداد (في الواقع، يكون MVP جاهزًا)، قالت الشركة: "لدينا أولويات جديدة، ونحن ننتقل إلى مشروع آخر، ونحن نغلق هذا المشروع".
لم يكن لدينا أي فشل عالمي في الخدمات الصغيرة. نحن ننام بسلام، ولدينا مناوبة عمل على مدار الساعة طوال أيام الأسبوع لخدمة نظام دعم الأعمال (BSS) بأكمله.
وهناك شيء آخر - نقوم بتأجير الخدمات الصغيرة وفقًا للقواعد التي تنطبق على المنتجات المعبأة. مفتاح النجاح هو أنك تحتاج أولاً إلى تجميع فريق يقوم بإعداد الخدمة الصغيرة بشكل كامل للإنتاج. التطوير نفسه مشروط بنسبة 40٪. والباقي عبارة عن التحليلات ومنهجية DevSecOps وعمليات التكامل الصحيحة والبنية الصحيحة. نحن نولي اهتمامًا خاصًا لمبادئ بناء التطبيقات الآمنة. يشارك ممثلو أمن المعلومات في كل مشروع سواء في مرحلة التخطيط المعماري أو أثناء عملية التنفيذ. كما يقومون أيضًا بإدارة أنظمة لتحليل التعليمات البرمجية بحثًا عن نقاط الضعف.
لنفترض أننا ننشر خدماتنا عديمة الجنسية - لدينا هذه الخدمات في Kubernetes. يتيح ذلك للجميع النوم بسلام بسبب التوسع التلقائي في الخدمات والرفع التلقائي لها، كما أن نوبة العمل تلتقط الحوادث.
طوال فترة وجود خدماتنا الصغيرة، لم يكن هناك سوى حادث واحد أو حادثين وصلا إلى خطنا. الآن لا توجد مشاكل في التشغيل. نحن، بالطبع، ليس لدينا 200، ولكن حوالي 50 خدمة صغيرة، لكنها تستخدم في المنتجات الرئيسية. وإذا فشلوا، فسنكون أول من يعلم بذلك.
الخدمات المصغرة والموارد البشرية
سيرجي:
أتفق مع زميلي بشأن النقل إلى الدعم - على ضرورة تنظيم العمل بشكل صحيح. لكنني سأخبرك عن المشاكل الموجودة بالطبع.
أولاً، التكنولوجيا جديدة. يعد هذا ضجيجًا بطريقة جيدة، كما أن العثور على متخصص يفهم هذا الأمر ويستطيع خلقه يمثل تحديًا كبيرًا. إن التنافس على الموارد أمر جنوني، لذا فإن الخبراء يستحقون وزنهم ذهباً.
ثانيا، مع إنشاء بعض المناظر الطبيعية وعدد متزايد من الخدمات، يجب حل مشكلة إعادة الاستخدام باستمرار. كما يحب المطورون أن يفعلوا: "دعونا نكتب الكثير من الأشياء المثيرة للاهتمام هنا الآن..." ولهذا السبب، ينمو النظام ويفقد فعاليته من حيث المال وتكلفة الملكية وما إلى ذلك. وهذا يعني أنه من الضروري إدراج إعادة الاستخدام في بنية النظام، وإدراجها في خريطة الطريق لتقديم الخدمات ونقل التراث إلى بنية جديدة.
هناك مشكلة أخرى - رغم أن هذا أمر جيد بطريقته الخاصة - وهي المنافسة الداخلية. "أوه، لقد ظهر هنا شباب عصريون جدد، ويتحدثون لغة جديدة." الناس، بطبيعة الحال، مختلفة. هناك من اعتاد على الكتابة بلغة Java، ومن يكتب ويستخدم Docker وKubernetes. هؤلاء أشخاص مختلفون تمامًا، ويتحدثون بشكل مختلف، ويستخدمون مصطلحات مختلفة وأحيانًا لا يفهمون بعضهم البعض. كما أن القدرة أو عدم القدرة على تبادل الممارسات وتقاسم المعرفة بهذا المعنى تمثل مشكلة أيضًا.
حسنًا، توسيع نطاق الموارد. "رائع، دعنا نذهب! والآن نريد أسرع وأكثر. ماذا، لا تستطيع؟ أليس من الممكن تقديم ضعف ما في السنة؟ و لماذا؟" من المحتمل أن تكون آلام النمو هذه معيارًا للعديد من الأشياء، والعديد من الأساليب، ويمكنك أن تشعر بها.
فيما يتعلق بالمراقبة. يبدو لي أن الخدمات أو أدوات المراقبة الصناعية تتعلم بالفعل أو يمكنها العمل مع كل من Docker وKubernetes في وضع مختلف وغير قياسي. لذلك، على سبيل المثال، لن ينتهي بك الأمر مع 500 جهاز جافا يتم تشغيل كل هذا ضمنها، أي يتم تجميعها. لكن هذه المنتجات لا تزال تفتقر إلى النضج، وعليها أن تمر بهذه المرحلة. الموضوع جديد حقًا، وسيستمر في التطور.
ديمتري:
نعم، مثيرة جدا للاهتمام. وهذا ينطبق على الموارد البشرية. ربما تغيرت عملية الموارد البشرية لديك والعلامة التجارية للموارد البشرية قليلاً خلال هذه السنوات الثلاث. لقد بدأت في توظيف أشخاص آخرين ذوي كفاءات مختلفة. وربما يكون هناك إيجابيات وسلبيات. في السابق، كانت تقنية blockchain وعلوم البيانات هي الضجيج، وكان المتخصصون فيها يستحقون الملايين. الآن تنخفض التكلفة، ويصبح السوق مشبعًا، وهناك اتجاه مماثل في الخدمات الصغيرة.
سيرجي:
نعم بالتاكيد.
الكسندر:
يطرح قسم الموارد البشرية السؤال التالي: "أين يوجد وحيد القرن الوردي الخاص بك بين الواجهة الخلفية والواجهة الأمامية؟" لا يفهم قسم الموارد البشرية ما هي الخدمة الصغيرة. أخبرناهم بالسر وأخبرناهم أن الواجهة الخلفية فعلت كل شيء، ولا يوجد وحيد القرن. لكن الموارد البشرية تتغير، وتتعلم بسرعة وتوظف الأشخاص الذين لديهم المعرفة الأساسية بتكنولوجيا المعلومات.
تطور الخدمات المصغرة
ديمتري:
إذا نظرت إلى البنية المستهدفة، فإن الخدمات الصغيرة تبدو وكأنها وحش. رحلتك استغرقت عدة سنوات. والبعض الآخر لديه سنة، والبعض الآخر ثلاث سنوات. هل توقعت كل المشاكل، والبنية المستهدفة، هل تغير أي شيء؟ على سبيل المثال، في حالة الخدمات الصغيرة، تظهر الآن البوابات وشبكات الخدمة مرة أخرى. هل استخدمتها في البداية أم قمت بتغيير البنية نفسها؟ هل لديك مثل هذه التحديات؟
سيرجي:
لقد قمنا بالفعل بإعادة كتابة العديد من بروتوكولات الاتصال. في البداية كان هناك بروتوكول واحد، والآن انتقلنا إلى بروتوكول آخر. نحن نزيد السلامة والموثوقية. لقد بدأنا بتقنيات المؤسسات - Oracle وWeb Logic. نحن الآن نبتعد عن منتجات المؤسسات التكنولوجية في الخدمات الصغيرة وننتقل إلى التقنيات مفتوحة المصدر أو المفتوحة تمامًا. نحن نتخلى عن قواعد البيانات وننتقل إلى ما يناسبنا بشكل أكثر فعالية في هذا النموذج. لم نعد بحاجة إلى تقنيات أوراكل.
لقد بدأنا ببساطة كخدمة، دون التفكير في مدى احتياجنا إلى ذاكرة التخزين المؤقت، وما سنفعله عندما لا يكون هناك اتصال بخدمة صغيرة، ولكن هناك حاجة إلى البيانات، وما إلى ذلك. والآن نقوم بتطوير منصة بحيث يمكن وصف البنية ليس بلغة الخدمات، بل بلغة الأعمال، خذ منطق الأعمال إلى المستوى التالي عندما نبدأ التحدث بالكلمات. لقد تعلمنا الآن التحدث بالأحرف، والمستوى التالي هو عندما سيتم جمع الخدمات في بعض التجميع، عندما تكون هذه كلمة بالفعل - على سبيل المثال، بطاقة المنتج بأكملها. يتم تجميعه من خدمات صغيرة، ولكنه عبارة عن واجهة برمجة تطبيقات (API) مبنية فوق ذلك.
السلامة مهمة جدا. بمجرد أن تبدأ في الوصول إليك ولديك خدمة يمكنك من خلالها الحصول على الكثير من الأشياء المثيرة للاهتمام، وبسرعة كبيرة، في جزء من الثانية، فهناك رغبة في الحصول عليها بطريقة ليست أكثر أمانًا. وللابتعاد عن هذا، كان علينا تغيير أساليب الاختبار والمراقبة. كان علينا تغيير الفريق، وهيكل إدارة التسليم، وCI/CD.
هذا تطور - كما هو الحال مع الهواتف، ولكن بشكل أسرع بكثير: في البداية ظهرت هواتف تعمل بالضغط على الزر، ثم ظهرت الهواتف الذكية. لقد أعادوا كتابة المنتج وإعادة تصميمه لأن السوق كان لديه حاجة مختلفة. هذه هي الطريقة التي نتطور بها: الصف الأول، الصف العاشر، العمل.
وبشكل متكرر، يتم وضع شيء ما سنويًا من وجهة نظر التكنولوجيا، وشيء آخر من وجهة نظر الأعمال المتراكمة والاحتياجات. نحن نربط شيئًا ببعضه البعض. ينفق الفريق 20% على الدين الفني والدعم الفني للفريق، و80% على الكيان التجاري. ونحن نتحرك مع فهم سبب قيامنا بذلك، ولماذا نقوم بهذه التحسينات التكنولوجية، وما الذي ستؤدي إليه. مثل هذا.
ديمتري:
رائع. ماذا يوجد في ميجافون؟
الكسندر:
كان التحدي الرئيسي عندما وصلنا إلى الخدمات الصغيرة هو عدم الوقوع في الفوضى. انضم إلينا على الفور المكتب المعماري لشركة MegaFon، حتى أنه أصبح البادئ والسائق - والآن لدينا بنية قوية جدًا. كانت مهمته هي فهم النموذج المستهدف الذي سنتبعه وما هي التقنيات التي يجب تجربتها. مع الهندسة المعمارية، قمنا بإجراء هذه الطيارين بأنفسنا.
وكان السؤال التالي: "إذن كيف نستغل كل هذا؟" وسؤال آخر: "كيف نضمن التفاعل الشفاف بين الخدمات الصغيرة؟" ساعدتنا شبكة الخدمة في الإجابة على السؤال الأخير. لقد قمنا بتجربة Istio وأعجبنا بالنتائج. نحن الآن في مرحلة الانتشار في المناطق الإنتاجية. لدينا موقف إيجابي تجاه جميع التحديات - حقيقة أننا بحاجة إلى تغيير المكدس باستمرار، وتعلم شيء جديد. نحن مهتمون بتطوير الحلول القديمة وليس استغلالها.
ديمتري:
كلمات من ذهب! مثل هذه التحديات تبقي الفريق والأعمال في حالة تأهب وتخلق المستقبل. أنشأت اللائحة العامة لحماية البيانات (GDPR) كبار مسؤولي حماية البيانات، كما أدت التحديات الحالية إلى إنشاء كبار مسؤولي الخدمات المصغرة والهندسة المعمارية. ويرضي.
ناقشنا الكثير. الشيء الرئيسي هو أن التصميم الجيد للخدمات الصغيرة والهندسة المعمارية نفسها تسمح لك بتجنب العديد من الأخطاء. وبطبيعة الحال، هذه العملية تكرارية وتطورية، ولكنها المستقبل.
شكرا لجميع المشاركين، وذلك بفضل سيرجي والكسندر!
أسئلة من الجمهور
سؤال من الجمهور (1):
سيرجي، كيف تغيرت إدارة تكنولوجيا المعلومات في شركتك؟ أفهم أنه عندما يكون هناك مجموعة كبيرة من الأنظمة المتعددة، فإن كيفية إدارتها تكون عملية واضحة ومنطقية إلى حد ما. كيف قمت بإعادة بناء إدارة مكون تكنولوجيا المعلومات بعد أن تم دمج عدد كبير جدًا من الخدمات الصغيرة في مثل هذا الوقت القصير؟
سيرجي:
وأنا أتفق مع زميلي على أن الهندسة المعمارية مهمة جدًا كمحرك للتغيير. لقد بدأنا بوجود قسم معماري. المهندسون المعماريون هم في نفس الوقت أصحاب توزيع الوظائف ومتطلبات كيفية ظهورها في المناظر الطبيعية. لذا فهم يعملون أيضًا كمنسقين لهذه التغييرات. ونتيجة لذلك، كانت هناك تغييرات محددة في عملية تسليم معينة عندما أنشأنا منصة CI/CD.
لكن لم يتم إلغاء المعايير والمبادئ الأساسية للتطوير وتحليل الأعمال والاختبار والتطوير. لقد أضفنا السرعة للتو. في السابق، كانت الدورة تستغرق الكثير، وكان التثبيت في بيئات الاختبار يستغرق أكثر من ذلك بكثير. والآن ترى الشركات الفوائد وتقول: "لماذا لا نستطيع أن نفعل الشيء نفسه في أماكن أخرى؟"
إنه يشبه، بطريقة جيدة، حقنة على شكل لقاح أظهرت: يمكنك القيام بذلك بهذه الطريقة، ولكن يمكنك القيام بذلك بطريقة أخرى. بالطبع، هناك مشكلة في الموظفين، في الكفاءات، في المعرفة، في المقاومة.
سؤال من الجمهور (2):
يقول منتقدو هندسة الخدمات الصغيرة أن الاختبار والتطوير أمران صعبان. وهذا أمر منطقي عندما تتعقد الأمور. ما هي التحديات التي واجهت فريقك وكيف تغلبت عليها؟ سؤال للجميع.
الكسندر:
هناك صعوبات عند الانتقال من الخدمات المصغرة إلى النظام الأساسي، ولكن يمكن حلها.
على سبيل المثال، نحن نصنع منتجًا يتكون من 5-7 خدمات صغيرة. نحن بحاجة إلى توفير اختبارات التكامل عبر مجموعة الخدمات الصغيرة بأكملها لإعطاء الضوء الأخضر للانتقال إلى الفرع الرئيسي. لم تكن هذه المهمة جديدة بالنسبة لنا: لقد كنا نقوم بذلك لفترة طويلة في BSS، عندما زودنا البائع بالحلول التي تم شحنها بالفعل.
ومشكلتنا فقط في الفريق الصغير. مطلوب مهندس ضمان الجودة لمنتج مشروط واحد. وهكذا، نقوم بشحن منتج يتكون من 5-7 خدمات صغيرة، منها 2-3 يمكن تطويرها بواسطة أطراف ثالثة. على سبيل المثال، لدينا منتج يشارك في تطويره بائع نظام الفوترة لدينا، Mail.ru Group وMegaFon R&D. نحن بحاجة إلى تغطية هذا بالاختبارات قبل شحنه إلى الإنتاج. يعمل مهندس ضمان الجودة على هذا المنتج لمدة شهر ونصف، ويُترك باقي الفريق بدون دعمه.
هذا التعقيد ناتج فقط عن القياس. نحن ندرك أن الخدمات الصغيرة لا يمكن أن توجد في الفراغ، ولا توجد عزلة مطلقة. عند تغيير خدمة واحدة، نحاول دائمًا الحفاظ على عقد API. إذا تغير شيء ما تحت غطاء محرك السيارة، فستظل الخدمة الأمامية. إذا كانت التغييرات قاتلة، يحدث نوع من التحول المعماري وننتقل إلى نموذج بيانات مختلف تمامًا، وهو غير متوافق تمامًا - عندها فقط نتحدث عن ظهور مواصفات واجهة برمجة تطبيقات خدمة v2. نحن ندعم الإصدارين الأول والثاني في وقت واحد، وبعد أن يتحول جميع المستهلكين إلى الإصدار الثاني، نقوم ببساطة بإغلاق الإصدار الأول.
سيرجي:
اريد الاضافة. أنا أتفق تمامًا مع المضاعفات - فهي تحدث. أصبح المشهد أكثر تعقيدًا، والتكاليف العامة تتزايد، خاصة بالنسبة للاختبار. كيفية التعامل مع هذا: التحول إلى الاختبار الآلي. نعم، سيتعين عليك الاستثمار بشكل إضافي في كتابة الاختبارات التلقائية واختبارات الوحدات. بحيث لا يتمكن المطورون من الالتزام دون اجتياز الاختبار، فلا يمكنهم تغيير الكود. بحيث حتى زر الضغط لا يعمل بدون اختبار تلقائي، اختبار الوحدة.
من المهم الحفاظ على الوظيفة السابقة، وهذا يمثل حملًا إضافيًا. إذا قمت بإعادة كتابة تقنية إلى بروتوكول آخر، فإنك تعيد كتابتها حتى تغلق كل شيء تمامًا.
في بعض الأحيان، لا نجري اختبارات شاملة عن قصد، لأننا لا نريد إيقاف التطوير، على الرغم من أننا نواجه أيضًا شيئًا تلو الآخر. المناظر الطبيعية كبيرة جدًا ومعقدة وهناك العديد من الأنظمة. في بعض الأحيان يكون الأمر مجرد بذرة - نعم، إذا خفضت هامش الأمان، تظهر المزيد من المخاطر. ولكن في نفس الوقت تقوم بتحرير العرض.
الكسندر:
نعم، تسمح لك الاختبارات التلقائية واختبارات الوحدات بإنشاء خدمة عالية الجودة. نحن ندعم خط أنابيب لا يمكن تمريره بدون اختبارات الوحدة والتكامل. غالبًا ما يتعين علينا سحب المحاكيات والأنظمة التجارية إلى مناطق الاختبار وبيئات التطوير، لأنه لا يمكن وضع جميع الأنظمة في مناطق الاختبار. علاوة على ذلك، فهي لا تتبلل فحسب، بل نولد استجابة كاملة من النظام. يعد هذا جزءًا مهمًا من العمل مع الخدمات الصغيرة، ونحن نستثمر فيه أيضًا. ومن دون هذا ستعم الفوضى.
سؤال من الجمهور (3):
بقدر ما أفهم، نمت الخدمات المصغرة في البداية من فريق منفصل وهي موجودة الآن في هذا النموذج. ما هي إيجابياته وسلبياته؟
لدينا قصة مماثلة: نشأ نوع من مصنع الخدمات الصغيرة. لقد وصلنا الآن من الناحية المفاهيمية إلى النقطة التي نقوم فيها بتوسيع هذا النهج ليشمل الإنتاج عن طريق التدفقات والأنظمة. بمعنى آخر، نحن نبتعد عن التطوير المركزي للخدمات الصغيرة، ونماذج الخدمات الصغيرة، ونصبح أقرب إلى الأنظمة.
وبناء على ذلك، فإن عمليتنا تذهب أيضا إلى الأنظمة، أي أننا نقوم بإضفاء اللامركزية على هذا الموضوع. ما هو نهجك وما هي قصتك المستهدفة؟
الكسندر:
لقد أسقطت اسم "مصنع الخدمات الصغيرة" من فمك مباشرة - ونريد أيضًا التوسع. أولاً، لدينا بالفعل فريق واحد الآن. نريد أن نوفر لجميع فرق التطوير التي تمتلكها MegaFon الفرصة للعمل في نظام بيئي مشترك. لا نريد أن نتولى بالكامل جميع وظائف التطوير المتوفرة لدينا الآن. المهمة المحلية هي التوسع، والمهمة العالمية هي قيادة التطوير لجميع الفرق في طبقة الخدمات الصغيرة.
سيرجي:
سأخبرك بالطريق الذي سلكناه. لقد بدأنا بالفعل العمل كفريق واحد، لكننا الآن لسنا وحدنا. أنا أؤيد ما يلي: يجب أن يكون هناك مالك للعملية. يحتاج شخص ما إلى فهم عملية تطوير الخدمات الصغيرة وإدارتها والتحكم فيها وبناءها. يجب عليه امتلاك الموارد والمشاركة في إدارة الموارد.
يمكن العثور على هذه الموارد، التي تعرف التقنيات والتفاصيل وتفهم كيفية إنشاء الخدمات الصغيرة، في فرق المنتج. لدينا مزيج حيث يتواجد الأشخاص من منصة الخدمات الصغيرة في فريق المنتج الذي يقوم بإنشاء تطبيق الهاتف المحمول. إنهم موجودون، لكنهم يعملون وفقًا لعملية قسم إدارة منصة الخدمات الصغيرة مع مدير التطوير الخاص بهم. يوجد ضمن هذا القسم فريق منفصل يتعامل مع التكنولوجيا. أي أننا نمزج مجموعة مشتركة من الموارد فيما بيننا ونقسمها ونعطيها للفرق.
في الوقت نفسه، تظل العملية عامة، خاضعة للرقابة، وتستمر وفقا للمبادئ التكنولوجية العامة، مع اختبار الوحدة وما إلى ذلك - كل ما تم بناؤه في الأعلى. قد تكون هناك أعمدة في شكل موارد تم جمعها من أقسام مختلفة لنهج المنتج.
الكسندر:
سيرجي، أنت في الواقع مالك العملية، أليس كذلك؟ هل يتم مشاركة المهام المتراكمة؟ ومن المسؤول عن توزيعها؟
سيرجي:
انظر: هذا هو المزيج مرة أخرى. هناك تراكم يتم تشكيله بناءً على التحسينات التكنولوجية - وهذه قصة واحدة. هناك تراكم يتم صياغته من المشاريع، وهناك تراكم من المنتجات. لكن تسلسل التقديم في كل منتج من منتجات الخدمة أو إنشاء هذه الخدمة يتم تطويره بواسطة متخصص في المنتج. وهو ليس في مديرية تكنولوجيا المعلومات، وقد تم عزله منها خصيصا. لكن أفراد فريقي يعملون بالتأكيد وفقًا لنفس العملية.
سيكون صاحب العمل المتراكم في اتجاهات مختلفة - تراكم التغييرات - أشخاصًا مختلفين. ربط الخدمات التكنولوجية ومبدأها التنظيمي - كل هذا سيكون في مجال تكنولوجيا المعلومات. أنا أملك المنصة والموارد أيضًا. في الأعلى ما يتعلق بالتراكم والتغييرات الوظيفية والهندسة المعمارية بهذا المعنى.
لنفترض أن إحدى الشركات تقول: "نريد هذه الوظيفة، ونريد إنشاء منتج جديد - إعادة تقديم القرض". نجيب: "نعم، سنعيده". يقول المهندسون المعماريون: "دعونا نفكر: أين سنكتب الخدمات الصغيرة في القرض وكيف سنفعل ذلك؟" ثم نقوم بتقسيمها إلى مشاريع أو منتجات أو مجموعة تكنولوجية، ونضعها في فرق وننفذها. هل قمت بإنشاء منتج داخليًا وقررت استخدام الخدمات المصغرة في هذا المنتج؟ نقول: "الآن يجب على الأنظمة القديمة التي كانت لدينا، أو أنظمة الخطوط الأمامية، أن تتحول إلى هذه الخدمات الصغيرة". يقول المهندسون المعماريون: "لذلك: في التراكم التكنولوجي داخل منتجات الخطوط الأمامية - الانتقال إلى الخدمات الصغيرة. يذهب". ويفهم متخصصو المنتجات أو أصحاب الأعمال مقدار السعة المخصصة ومتى سيتم ذلك ولماذا.
نهاية المناقشة، ولكن ليس كلها
تم تنظيم مؤتمر mailto:CLOUD .
نقوم أيضًا بفعاليات أخرى - على سبيل المثال. @Kubernetes لقاءحيث نبحث دائمًا عن متحدثين رائعين:
- تابع @Kubernetes وأخبار @Meetup الأخرى على قناة Telegram الخاصة بنا
- هل أنت مهتم بالتحدث في أحد @Meetups؟ ترك طلب ل
المصدر: www.habr.com