بدلا من تقديم
لقد مرت عدة أشهر منذ إطلاق الخدمات المصغرة الأولى. والآن حان الوقت ، في رأينا ، للتحدث عن الخبرة المكتسبة.
يجدر إبداء تحفظ على الفور حول ما سيكون في هذه المقالة وما لن يكون في المقالة. لن تصف المقالة الحلول والأوصاف المعمارية مع الأساس المنطقي لهذه القرارات. ولن نركز على مجموعة التكنولوجيا التي بنينا عليها الخدمات المصغرة.
سيكون التركيز الرئيسي للمقال على تلك المشكلات العالمية التي واجهها فريقنا طوال فترة المشروع.
هذه المقالة ستكون الأولى من بين العديد. وهدفه ، أولاً وقبل كل شيء ، هو تقديم مشاكلنا في سياق الانتقال إلى بنية الخدمات المصغرة ، ويؤدي بسلاسة إلى الموضوعات التالية ، والتي تكشف بالتفصيل عن جوانب معينة من الانتقال.
كيف بدأ كل شيء
تم اتخاذ قرار التحول إلى بنية الخدمات المصغرة منذ حوالي عام ونصف. كان التحدي الذي يواجهنا هو الاستعداد للنمو السريع لشركتنا. كان علينا أن نصبح أكثر مرونة فيما يتعلق بالحلول التقنية ، وزيادة سرعة إجراء التغييرات ، وبالطبع زيادة مرونة أنظمتنا.
بعد اتخاذ قرار التحول إلى بنية الخدمات المصغرة ، تم إنشاء وحدة منفصلة من الأشخاص ذوي الخبرة والاستباقية. كان العامل المحدد للنظر في نقل المرشح إلى قسم جديد هو الخبرة العالية في واحد أو أكثر من أنظمة المعلومات الموجودة.
نظرًا لعدم وجود فهم واضح لواجهة العمل في ذلك الوقت ، تم تشكيل الفريق بشكل تلقائي إلى حد ما. ولكن في الوقت نفسه ، تم بالفعل وضع مبدأ الاكتفاء الذاتي - يجب أن يكون للمطورين والمحللين والمختبرين في الفريق مبادئهم الخاصة.
تم اختيار مسارين في وقت واحد كإستراتيجية للتحول إلى الخدمات المصغرة:
- نأخذ في الخدمات المصغرة ما هو أسهل (كما اعتقدنا) في الحصول عليه ؛
- نحن ندخل إلى الخدمات المصغرة التي يؤدي تحويلها إلى الخدمات المصغرة إلى حل معظم المشاكل لكل من الأعمال وتكنولوجيا المعلومات.
كانت الطريقة الأولى جيدة لأن الفريق في هذه العملية سيكتسب الخبرة اللازمة ويملأ أيديهم ، وبالتالي زيادة كفاءتهم للعمل اللاحق. كانت الطريقة الثانية هي تقديم نوع من الفوز السريع للفريق ، وإظهار صحة القرار المختار بالانتقال إلى الخدمات المصغرة للشركة وتحفيز الفريق لتحقيق مآثر جديدة.
كان الفريق في بداية الرحلة. لقد كان وقتًا سعيدًا: بدا المستقبل مشرقًا وخاليًا من الضباب ، وبدا لنا أن لدينا خطة.
الصعوبات الأولى
وبالطبع ، بما أننا نتحدث عن الخدمات المصغرة ، فلا يسعنا إلا التحدث عن monoliths. هذه هي أنظمة المعلومات الرئيسية لدينا.
تتضح بنية أنظمتنا الفردية بشكل أفضل من خلال هذه الصورة المأخوذة من مقال لستيفان تيلكوف "لا تبدأ بمنليث". كما نرى ، ترتبط الكتل الوظيفية في الكتلة الواحدة ارتباطًا وثيقًا ببعضها البعض. هذه عقبة خطيرة أمام عملية نقل وظائف منفصلة إلى خدمة مصغرة.
كمرجع ، يبلغ عمر وحدات monoliths الخاصة بنا حوالي 13 عامًا ، ويبلغ متوسط قاعدة بيانات monolith حوالي 1.2 مليون سطر.
بعبارة أخرى ، واجه الفريق المشكلات التالية مرارًا وتكرارًا:
- عملية تستغرق وقتًا طويلاً لتحليل الوظائف الحالية ؛
- غالبًا ما يكون هناك نقص في فهم ما نقدمه بالضبط للخدمة المصغرة ؛
- تعقيد دمج الوحدة المتراصة مع الخدمة المصغرة الجديدة.
وبالنظر إلى أنه بالإضافة إلى حل هذه المشكلات ، احتاج الفريق أيضًا إلى زيادة الخبرة في مجموعة جديدة ونهج تصميم جديد ، لم يكن التقدم سريعًا.
ومع ذلك ، بعد بضعة أشهر ، بدأ الفريق في إظهار النتائج الأولى - قدمت الخدمات المصغرة الأولى بشكل ودي واجهات برمجة التطبيقات الخاصة بها للجميع. آمن الفريق بأنفسهم وكانوا على يقين من أنهم يفعلون كل شيء بشكل صحيح. حسنًا ، العديد من الأشياء في حياتنا وهمية تمامًا.
النجاحات الأولى والصعوبات الجديدة
على الرغم من الصعوبات الأولى ، تلقى الفريق تجربة جديدة ونتائج أولى. ولكن ظهرت بعض المخاطر غير المحسوبة التي تحول دون إطلاق الخدمات المصغرة.
- اتضح أن الوحدات المتراصة لم تكن جاهزة للعمل مع المكدس الجديد ، وتأخر التكامل.
- - .
- , , , , .
تم حل المشكلتين الأوليين بكل بساطة - عن طريق كتابة عملاء منفصلين لدمج خدمة monolith و microservice وتعديل وظيفة monolith وفقًا لذلك. لكن المشكلة الثالثة لم يتم حلها بالكامل حتى يومنا هذا.
تم حل عدم تناسق الموارد جزئيًا من خلال جدولة الموارد التعاونية. يبدو أن الفريق أخذ في الاعتبار جميع أخطائهم ، وكان هناك فهم لما يجب القيام به وكيفية القيام به بشكل صحيح ، وبحلول بداية عام 2020 ، تمت كتابة حوالي اثني عشر خدمة صغيرة (تبين أن بعضها لم يكن خدمات صغيرة على الإطلاق) في انتظار التكامل والإفراج عنهم في الإنتاج. قاموا بتغطية وظائفهم معظم العمليات الحيوية للأعمال ، مثل حساب التكلفة ووقت التسليم ، واستكمال المناطق والمكاتب الجديدة في موقع البيع ، والبحث عن البضائع واختيارها ، إلخ.
تقدمنا بثقة إلى الأمام ، لدينا خبرة قوية بالفعل وملأنا الكثير من المطبات. يبدو أننا واجهنا جميع المزالق ، والآن يبقى فقط عمدا ، خطوة بخطوة ، لتنفيذ خطتنا.
حسنا…
الحجر الصحي واستغلال العمالة والنجاح في النهاية
بداية العام أدخلت تعديلات كبيرة على خططنا ، ويرجع ذلك إلى عواقب فيروس كورونا المستجد الذي انتشر في ذلك الوقت. من الواضح أنه ليست هناك حاجة لشرح ما هو على المحك: الجميع يعرف الكثير بالفعل عن هذا الموضوع.
أدى تفشي الوباء والأزمة الاقتصادية المصاحبة له إلى إجبار شركتنا على إعادة النظر قليلاً في أولوياتها التنموية. ونتيجة لذلك ، تغيرت أولويات تكنولوجيا المعلومات - تم تعيين مهام جديدة ، وصُممت لإعادة صياغة العمليات التجارية بسرعة لتناسب الحقائق الجديدة.
أثرت التغييرات أيضًا على خطط الخدمات المصغرة. بسبب إعادة تخصيص الموارد ، تم تأجيل تكامل الخدمات المصغرة مع monoliths ، وبالتالي ، إصدار الخدمات المصغرة نفسها مرة أخرى.
هنا ، أخيرًا ، من الضروري الخوض في مزيد من التفاصيل حول ما كان يحدث في الفريق وكيف شعر الفريق.
أولا ، تثبيط الحماسة. نظرًا لعدم وجود نتيجة قوية لفترة طويلة ، وعدم وجود خدمات مصغرة جاهزة ومتكاملة تمامًا في الإنتاج لمدة عام تقريبًا ، كان الفريق منهكًا أخلاقياً (مقابل هذا المصطلح ، ولكن مع ذلك). انخفضت الكفاءة بشكل كبير. لا يخلو من الانهيارات العاطفية النادرة ، ولكنها حية.
ثانياً ، الحجر الصحي والانتقال الكامل إلى جهاز التحكم عن بعد. بالطبع ، لدينا ثروة من الخبرة في العمل عن بُعد: حوالي من المطورين هم عمال عن بعد. لكن كل من عمل على الخدمات المصغرة عملوا معًا في نفس المكتب ، ولم يؤثر الانتقال إلى العمل عن بعد على فعالية الفريق بأفضل طريقة. من ناحية أخرى ، حقيقة أن الأمر استغرق وقتًا لإعادة الهيكلة والانتقال إلى شكل جديد للعمل. من ناحية أخرى ، خلال فترة تناقص دافع الفريق ، كان الأمر يتطلب المزيد من التواصل الشخصي والدعم المتبادل داخل الفريق.
ثالثًا ، كان على الفريق إظهار النتيجة. في الواقع ، الفريق بأكمله ، على الرغم من المشاكل الداخلية والخارجية ، مفهومة بوضوح: المصير الإضافي للمشروع بأكمله يعتمد على مدى السرعة التي يمكننا بها الضغط على أهدافنا للوصول إلى نتيجة قوية. كان العديد في شركتنا على استعداد للاعتراف بتجربة التحول إلى الخدمات المصغرة على أنها جاءت في وقت غير مناسب وغير ناجحة وحل القسم.
لمدة شهرين تقريبًا ، عمل الفريق من 12 إلى 15 ساعة ، غالبًا سبعة أيام في الأسبوع. وقد تمكنت من تحقيق الهدف المنشود - دخلت أربع خدمات صغيرة تعمل بشكل كامل ومتكاملة تمامًا مع الأنظمة المتجانسة ، في الإنتاج الكامل مرة واحدة.
من المهم أن نلاحظ أننا لم نستخدم أي تقنيات صعبة لتحفيز الفريق ، وليس هناك خبرة للمشاركة. لقد فعل الفريق يومًا بعد يوم ما يلي:
- مكالمات Skype المتكررة مع تحديث الوضع الحالي للعمل وحل سريع للقضايا الناشئة ؛
- الحفاظ على موقف إيجابي في الفريق مع التحقق المستمر من حالة الموارد لكل منها.
كنتيجة ل
بدلاً من الاستنتاج ، أود أن أسهب في الاستنتاجات التي توصلنا إليها لأنفسنا ...
- عبر الفرق. لتنفيذ مثل هذه المشاريع الطموحة بنجاح ، يجب أن يكون هناك فريق مكرس بالكامل ومستقل يتمتع بموارد كافية لحل أي مشكلة. في حالتنا ، هذا يعني أن الفريق الذي يقوم بإنشاء خدمات مصغرة على كومة جديدة يجب أن يكون لديه رجال من فرق تطوير monolith. إذا فهمنا هذا مسبقًا وتمكنا من دفع هذه الفكرة إلى النهاية ، لكان هذا قد سمح لنا بتجنب الأخطاء المرتبطة بالخبرة غير الكافية في العمليات التجارية وعدم تناسق الموارد من أجل تكامل الخدمات المصغرة والمتجانسة.
- . , , . . , , , , . .
- . , . .
الآن ، بعد الانتهاء من العمل على الأخطاء ، يمكننا القول بثقة: يمكن اعتبار التجربة ، التي بدأت منذ عام ونصف تقريبًا ، ناجحة. والآن ، من فئة التجربة فقط ، أصبح مشروع الانتقال إلى بنية الخدمات المصغرة أحد استراتيجيات تكنولوجيا المعلومات الرئيسية في شركتنا.
في المستقبل ، سنعود إلى هذا الموضوع ونتحدث بمزيد من التفاصيل حول مجموعة التكنولوجيا والحلول الفردية وغير ذلك الكثير. لقد جمعنا ما يكفي من المواد والخبرة.