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

من هذه المقالة سوف تتعلم كيفية تنظيم عملية بناء تطور فعال في شركة رقمية موزعة ، وكيفية القيام بذلك من خلال التواصل مع الخبراء ، وكيف يحدث هذا مع مثال MTS.

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

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

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



أقل بيروقراطية - تطور أسهل


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

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

هناك العديد من الأمثلة التي يكون من المفيد فيها ضمان الجودة والاتساق في تصميم وتطوير أنظمة تكنولوجيا المعلومات.

خبراء منطو


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

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • تنظيم التناوب في فريق من "المراجعين" بحيث تتاح الفرصة لأكبر عدد ممكن من ممثلي الفريق لتبادل المعرفة والخبرة.

لبدء العملية ، قمنا بتجميع فريق من المتحمسين ، ووضعنا قائمة بمواضيع المناقشة لكل من الأدوار ، وقمنا بتدريب فريق المراجعين المرتجلين. بالمناسبة ، كان التدريب هو أصعب مرحلة ، لأن المتخصصين الجيدين في مجالنا غالبًا ما يكونون انطوائيين جيدين جدًا :-)

ما هي النتيجة؟




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

على سبيل المثال ، دعنا نلقي نظرة على نتائج دراسة في اتجاه "العمارة".
 
ماذا فعلنا:

  • تم التواصل مع 20 فريقًا ؛
  • قضى كل منهما 31 يومًا في المتوسط. بالنظر إلى حقيقة أننا تفاعلنا في وقت واحد مع عدة فرق ، استغرقت العملية بأكملها ستة أشهر ؛
  • كشفت 180 المخاطر المرتبطة بالهندسة المعمارية.

 تم تقسيم المخاطر داخل فرقنا على النحو التالي:


الخطر 1: التصميم من

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

لفهم ما نعتبره مخاطر ، دعنا نلقي نظرة على TOP-3 بالأمثلة.

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

على سبيل المثال ، قررنا صنع منتج رقمي للتطبيب عن بعد. ما هو المطلوب لهذا؟

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

إلخ.

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

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

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

لذلك ، قبل التعمق في مشروع جديد ، اسأل نفسك السؤال: ما هو النوع الذي ينتمي إليه؟
 

الخطر 2: الأمن

يبدو أن الأمن يتم التفكير فيه بجدية شديدة هذه الأيام. الجميع يتذكر مثل هذه الأمور مثل الضرورة:

  • مصادقة المستخدمين
  • يأذن لهم بتنفيذ الإجراءات ؛
  • الامتثال لمبدأ الامتيازات الأقل ؛
  • الحفاظ على سرية البيانات ؛
  • الاحتفاظ بسجل لتدقيق إجراءات المستخدم.

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

  • قد يسمح لك التطبيق بإدخال كلمات مرور بسيطة للغاية ، ومن ثم يسهل التقاطها ؛
  • قد لا يكون التطبيق محميًا من كلمات مرور القوة الغاشمة نفسها (لا توجد كلمة التحقق أو أي شيء من هذا القبيل) ؛
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


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


الخطر 3: الأداء
 

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

التوصيات هنا بسيطة: أداء التطبيق يتناسب عكسيا مع عدد الطلبات من الموارد البطيئة. وبناءً على ذلك ، تهدف جميع التكتيكات إما إلى تقليل عدد الطلبات أو إلى تسريع الموارد نفسها. في هذه الحالة ، يتم فهم الموارد على أنها معالج ، ذاكرة ، شبكة ، أقراص ؛ كما أنه من الملائم أحيانًا اعتبار قاعدة بيانات أو خادم تطبيق كمورد.
 
  • أولاً ، ننظر في ما إذا كان من الممكن إنشاء ذاكرة تخزين مؤقت للعميل في تطبيق موزع بحيث لا نطلب / نحسب البيانات التي نحتاجها في كل مرة. إذا كان ذلك ممكنًا ، فإننا نحفظ في طلبات الشبكة ، وتحميل موارد الخادم وكل ما يفعله هناك.
  • لكن هذا نادر جدًا ، لذا نتطلع لمعرفة ما إذا كان بإمكاننا إنشاء ذاكرة تخزين مؤقت للخادم. مع ذلك ، فإن المبدأ هو نفسه كما هو الحال مع العميل ، ولكن مكاسب الأداء أقل قليلاً ، لأن طلبات الشبكة ستستمر ؛
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

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

وبالتالي ، فإن الخطر هنا هو أنه بدون التفكير أولاً في استراتيجية كيفية "زيادة سرعة" تطبيقنا ، فقد ينتهي بنا الأمر بتكاليف عالية جدًا لإعادة كتابة التطبيق في المستقبل.

تلخيص


في هذا المقال حاولت التحدث عن كيفية تنظيم عملية بناء تطور فعال في شركة رقمية موزعة من خلال التواصل مع الخبراء. في عصرنا من التطوير البعيد ، تصبح هذه العمليات ذات صلة خاصة. تسمح لك بتدمير قانون كونواي ، أو على الأقل تقليله.
 
إذا قررت إنشاء قوائم المراجعة الخاصة بك ، فإنني أوصي بعدم القيام بكل شيء من البداية ، ولكن أخذ شيء من الأدبيات الموجودة. على سبيل المثال ، فيما يتعلق بالهندسة المعمارية ، فإن كتاب مراجعة مادة Software Software's Architects بواسطة جوزيف إنجينو ISBN مفيد للغاية: 9781788624060

يمكن العثور على تقريري هنا

مؤلف المقالة: ديمتري دزيوبا ​​، رئيس مركز البحث والتطوير

 

All Articles