كيف تشرح لمديري غير تكنولوجيا المعلومات مبادئ بناء بنية تحتية لتكنولوجيا المعلومات تتحمل الأخطاء

قبل عام تقريبًا ، كانت مهمة خطيرة جدًا أمامي: وضع محاضرة لمدة ساعتين للمدراء حول قصة كل من Agile و DevOps.

وهكذا بدأت عودتي من الطائرة softskill من Agile للتدريب على تكنولوجيا المعلومات. وفقًا للمنظمين ، مر أكثر من 1000 مدير منتج عبر هذه المحاضرة ، حيث استمع حوالي 48/50 شخصًا إلى "Load Balancer" لأول مرة في صفي.

حتى أنني حصلت على إله هزلي "موازن رائع ، سيد التحديثات دون توقف ، ورخيصة لتنفيذ اختبارات A / B بدون برمجة ، وعمومًا استمتع بليلة نوم جيدة للمدير."

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

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

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

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

لماذا؟

السؤال الأول الذي يطرح نفسه عند تحديد أي مهمة ، بالطبع: لماذا؟

هناك مثل هذا الإطار:

لماذا نحتاجها؟ | لماذا يحتاجونها؟

لماذا نحتاجها؟

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

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

لماذا يحتاجونها؟

لماذا يعرف المدراء الذين هم بعيدون حقًا عن تقنية المعلومات؟

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

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

كيف يمكنني شرح الصور المعقدة البسيطة

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

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

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



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



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

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

ما التالي؟

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

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

كان لدينا مرة واحدة انخفاض بنسبة 20 ٪ في RPS 600 ، وتم القضاء عليه بسرعة ، ويبدو حتى من دون مشاركة الناس. بعد ذلك ، كنت ، بصفتي رئيسًا تقنيًا ، مسؤولًا عن كل اتجاهات الاتجاه ، بدأت عمليًا في تكرار كلمة "الموازن" بشكل مدافع إلى المديرين الآخرين.

كما توضح تجربتي ، فإن هذه المعرفة مفيدة للغاية على وجه التحديد حتى يتمكن المديرون من فهم كيفية تقليل المخاطر الناتجة عن الإصدار ويصبحوا مهتمين بـ CI / CD والتجارب التكنولوجية المختلفة.

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

في رأيي ، من المهم الآن زيادة المعرفة التقنية للمديرين غير التقنيين. بالتأكيد ليس بالضرورة بهذه الطريقة ، بالطبع.