سأكون سعيدًا بأي نقاش في التعليقات تحت المقال: أسئلة ، آراء ، تفنيد!
هناك ما هو معروف
في لامودا ، انضممت إلى الفريق الذي يعمل على دعم وتطوير نظام معالجة الطلبات. لا شيء واضح ، لكنه مثير للاهتمام بشكل رهيب.
بعد استوديو ويب صغير ولكن طموح حيث عملت من قبل ، تأثرت بالجدية داخل شركة كبيرة. بدت عمليات التطوير المرتبة كآلية متقنة تمامًا. تعتبر مراجعات التعليمات البرمجية الصارمة ولكن التدريبية من القائد وأعضاء الفريق ضرورية لمثل هذا النظام المعقد والمفتاح. بالنسبة لي ، طارت مهام النقاط ، مما أثر على ملف واحد أو ملفين ، لا أكثر. معظم قواعد الرموز وسلوك النظام كانت مخفية عني بسبب ضباب الحرب.
بعد حوالي شهر ، أكملت إحدى المهام الأولى المتعلقة بإجراء تغييرات حقيقية على نظام العمل. يتلخص جوهرها في إضافة حقل واحد إلى تقرير إعادة الأموال إلى العميل. مراجعات الكود واختبارات الوحدة ومهندس ضمان الجودة يختبر الإصدار - بدا كل شيء على ما يرام. نظرًا لأن النظام كان كبيرًا ومعقدًا ، فقد تم إطلاق سراحنا مرتين في الأسبوع ، وفقًا للوائح - ويوم الخميس انتقلت مهمتي إلى الإنتاج. في معظم اليوم ، كان مهندس الإصدار منشغلاً في بناء الكود وإصداره ، متبوعًا بالتبديل القهري بين علامات التبويب مع مراقبة الرسوم البيانية والأخطاء وقوائم الانتظار والسجلات - كل ما يمكن أن يشير إلى مشكلة. لكن كل شيء بدا رائعًا. تم دمج الكود في الفرع الرئيسي وتفريقه للتعامل مع المهام الأخرى.
يخفي الصمت في السجلات والمراقبة خطأ فادحًا: أرجع استعلام قاعدة البيانات عددًا غير صحيح من الصفوف. كان المبلغ الإجمالي الذي سيتم إرجاعه أعلى بعدة مرات من المبلغ الحقيقي ... لكننا اكتشفنا ذلك يوم الاثنين فقط. ما زلت أتذكر كيف نظر لي قائد التكنولوجيا متعبًا ومهينًا عندما ركبنا مصعد المكتب في صباح اليوم التالي. اشتعلت الخلل حتى الثالثة صباحًا وأعد إصلاحًا للإفراج. وقد عانت الشركة من بعض التأثير من خطأي. كان هذا أول خطأ حرج لي ، ولكنه بعيد عن الأخير. يرتكب الناس أخطاء ، ويفعلون ذلك طوال الوقت.
الوجبات الجاهزة # 1:العمليات التجارية والبيانات تأتي في المقام الأول. من المهم الانتباه إلى البيانات التي يعمل بها النظام. حدد ما تتعامل معه قبل إجراء التغييرات. افهم السياق الذي يتم فيه إجراء التعديلات. ضع في اعتبارك دائمًا المشكلة التي يتم حلها من منظور السياق فوق المستوى. بمعنى آخر ، افهم بوضوح ما يحدث فيما يتعلق بعملية الأعمال ومن هو المستهلك للنماذج المتأثرة. يمكن أن يحتوي هيكل التطبيق على العديد من طبقات التجريد كما تريد ودرجات متفاوتة من جودة التجريدات نفسها ، ولكن هذا لا يعني شيئًا على الإطلاق في حالة تعطل النموذج أو عملية العمل ككل.
واصلت العمل في نفس الفريق ، واكتسبت الخبرة ، وبعد ستة أشهر ، في فريق الوقوف ، ألقيت عبارة ، بشكل عام ، فهمت كيف يعمل نظام معالجة الطلبات لدينا.
بالطبع كنت مخطئا.
لا ينبغي أبدًا التقليل من تعقيد الأنظمة الكبيرة. قال السياسي الأمريكي دونالد رامسفيلد جيدًا عن هذا:
... كما نعلم ، هناك مشاهير معروفون ؛ هناك أشياء نعرفها ونعرفها. كما نعلم أن هناك مجاهيل معروفة. أي أننا نعلم أن هناك بعض الأشياء التي لا نعرفها. لكن هناك أيضًا مجاهيل غير معروفة - تلك التي لا نعرفها ، ولا نعرفها. وإذا نظرت إلى تاريخ بلدنا والبلدان الحرة الأخرى ، فعادة ما تكون الفئة الأخيرة صعبة.
فائدة # 2: عند العمل مع أنظمة معقدة ، من المهم أن نفهم ما نعرفه عنها ، وما لا نعرفه ، وما الذي لا يخمنه سلوكهم حتى. وهذا لا يتعلق فقط بالأدوات واتباع اتجاه "المراقبة نحو المراقبة" ، ولكن أيضًا حول إدارة التبعية وتقييم المخاطر في التصميم. على سبيل المثال ، قبل أن تقرر استخدام قاعدة بيانات الاتجاهات الرائعة لنظام حساس ، أنصحك بشدة بالالتزام بهذا الموقع boringtechnology.club
يتم تقسيم كل شيء
بعد عامين من العمل بنظام معالجة الطلبات ، يمكنني القول إنني أعرف بثقة حوالي 80٪ من الطلب. أي حول كل وحدة من وحدات النظام أفهم كيف يعمل ، ويمكنني إجراء تغييرات. أعرف العمليات التجارية التي تنعكس في نموذج معين ، وكيف أنها مترابطة وتؤثر على بعضها البعض. لقد أجريت التكامل مع نظام معالجة الدفع صممه فريق مجاور. بالإضافة إلى التكامل ، كان من الضروري التخلص من إرث الكود القديم ، نظرًا لأن المدفوعات كانت جزءًا من نظامنا - كانت هذه المهمة هي آخر وأكبر عملية إعادة بناء لوحدة كبيرة. كل شيء سار بسلاسة حتى أنه لم يكن ممتعًا.
في الوقت نفسه ، كان هناك صراع يختمر بداخلي ، كمطور. بصراحة لم أفهم سبب هشاشة نظام معالجة الطلبات لدينا ، وهو أمر بالغ الأهمية لتشغيل أعمالنا بالكامل. كانت الأنظمة الكبيرة المجاورة هشة بنفس القدر. من كل الخبرة التي اكتسبتها في عامين من العمل ، بدا أن نوعًا من الموثوقية من الأنظمة المعقدة لا يمكن توقعه إلا عند إجراء حالات اختبار قياسية. وعندما تحاول إجراء التغييرات التي يتطلبها عملك ، تنهار الأشياء في أول مناورة جذرية لمطور غير محظوظ.
بالتفكير في كل هذا ، صادفت مقالة كل شيء مكسور ، حيث يكتب المؤلف عن نفس المشكلة ، ولكن على نطاق أوسع (وأيضًا نفس الشيء ، ولكن من زاوية مختلفة - خيبة أمل البرامج). في كل مرة أشعر بالحماس عندما أجد تأكيدًا خارجيًا لمشاعري الداخلية - لذلك في ذلك الوقت ، بعد قراءة المقال ، شعرت أخيرًا كيف تحول استيائي الغامض إلى بصيرة واضحة وواضحة:
البرمجيات سيئة للغاية لأنها معقدة للغاية.
لم يكن علينا أن نذهب بعيدًا للحصول على مثال في عملنا: فقط في تلك اللحظة ، بإضافة بضعة أعمدة ، كسرنا تمامًا إنشاء أمر لفترة من الوقت.
أنظمتنا الكبيرة والمهمة سيئة للغاية لأنها لا تناسب عقولنا! وجميع العمليات التجارية المغلقة داخل الأنظمة لا تتناسب مع رؤساء المديرين والمحللين - وبشكل عام لا يوجد مثل هذا الشخص الذي يفهم كيف يعمل كل شيء معًا.
الخلاصة رقم 3: عند تصميم الأنظمة ، من المهم مراعاة العبء المعرفي. وهو يتألف من تعقيد الحلول التقنية ، فضلاً عن نماذج وعمليات مجال الموضوع. تتمتع الأنظمة جيدة التصميم بعبء معرفي مرتفع على مجال الموضوع ومنخفض في الحلول التقنية.من الناحية المثالية ، يجب أن يكون للنظام الواحد عبء معرفي يمكن لشخص واحد التعامل معه.
حسنًا ، المشكلة واضحة. لكن لنفترض أن لدينا الفرصة لإعادة كتابة نظام شديد التعقيد وبالتالي سيئ ، وتبسيطه. ما الذي يجب الانتباه إليه أيضًا؟ في علم التحكم الآلي ، توجد نظرية كونانت-آشبي:
يجب أن يكون للمنظم الجيد للنظام نموذجًا لذلك النظام. منظم جيد
معنى هذه النظرية هو أننا إذا أردنا التحكم في كائن ما ، فنحن بحاجة إلى نموذج جيد (دقيق ومفهوم) لهذا الكائن. وكلما زاد تعقيد الكائن أو قلة المعلومات عنه ، زادت صعوبة الحصول على نموذج جيد له - وهذا يؤثر سلبًا على الإدارة.
أعتقد أن قلة قليلة من الناس لن يوافقوا على أن جميع خدماتنا نماذج. لكن ما الذي نصممه؟ من المهم جدًا الانتباه إلى العمليات التجارية ، ليس فقط لنمذجة الحالة ، ولكن أيضًا السلوك.
في نهاية عام 2017 ، انتقلت إلى فريق CORE الجديد. ثم تم تشكيل هذا الفريق خصيصًا لتنفيذ مهام إستراتيجية تكنولوجيا المعلومات لتحلل الأنظمة المتجانسة. كان هدفنا الرئيسي هو قطع نظام معالجة الطلبات الضخم ، ولكن الهش (التعليق الصوتي: لم يكن الساموراي يعلم بعد أن هذا المسار له بداية ، ولكن لا نهاية!).
لقد كانت تجربة جديدة بالنسبة لي. فريق بمبادئ وطريقة تفكير مختلفة تمامًا. تم اتخاذ القرارات بسرعة وكانت هناك تجارب والحق في ارتكاب الأخطاء. كان التوازن مثاليًا: لقد حاولنا وتراجعنا حيث كان التأثير ضئيلًا ، لكننا وصفنا كل خطوة بالتفصيل للحظات الحرجة.
كتبنا خدمة جديدة لإنشاء الطلبات من الصفر بلغة أخرى (كوننا مطوري php ، انتقلنا إلى golang). قمنا بتقييم النتيجة الأولى وإعادة كتابتها مرة أخرى. كان التركيز على البساطة والموثوقية. وضعوا نموذج البيانات في المركز ، وقاموا ببناء الهيكل بأكمله حوله. والنتيجة هي خدمة موثوقة ومرنة. تمكنا من تشغيله دون إخفاقات باستخدام الآلية التجريبية. بمرور الوقت ، أظهر النظام المبني قيمته أكثر من مرة.
الوجبات الجاهزة # 4:كل النماذج خاطئة ولكن بعضها مفيد. حالات النمذجة لا تكفي لبناء أنظمة صحيحة ومستقرة. من الضروري النظر إلى السلوك: أنماط الاتصال ، تيارات الأحداث ، من المسؤول عن هذه البيانات أو تلك. يجب عليك البحث عن العلاقات بين البيانات والانتباه إلى أسباب هذه العلاقات.
كل شيء عن دوم دوم دا دا دوم دوم
في جامعتي كانت هناك دورة في التحليل الرياضي ، والتي قام بتدريسها أستاذ مشارك ودكتوراه. ايلينا نيكولايفنا. كانت صارمة للغاية ، لكنها عادلة. في الاختبارات بين الحين والآخر ، واجهت مشاكل ، من أجل حلها كان من الضروري "تحريف" المحاضرات قليلاً - لاتخاذ خطوة مستقلة نحو فهم المادة. وفي الامتحان النهائي ، والذي ، بالمناسبة ، نجحت فيه للمرة الثانية ، كان علي أن أبدي مرونة في التفكير وأستخدم حدسي لحل المشكلة على أنها "جيدة". هذه هي القاعدة التي تقول إن E.N. أخبرتنا عن الدورة كاملة ، والتي سأستخدمها بعد عشر سنوات:
عندما لا تعرف ماذا تفعل ، افعل ما تعرفه.
لهذا السبب كنت فخورة بمعرفة ماتان جيدًا. لأنه وفقًا لمعايير E.N. لا يكفي معرفة المادة ، ولكن من المهم أيضًا فهمها ، لتكون قادرًا على توليف شيء جديد.
الخلاصة رقم 5: كلما تقدمت ، زادت المسؤولية التي عليك تحملها وزادت القرارات التي يتعين عليك اتخاذها. في لحظة معينة ، الثقة المطلقة تختفي كفئة ، ولكن بدلاً من ذلك يأتي فن التوازن بعد الشجاعة لاتخاذ خطوة.
يأتي وقت لا يوجد فيه شخص مناسب من حولك يمكنه إزالة حالة عدم اليقين الحالية. عليك تقييم المخاطر بنفسك وتحمل المسؤولية عن نفسك. اتخذ القرارات في مواجهة عدم اليقين.
في النصف الثاني من عام 2018 ، قاد فريقنا مشروع شهادات الهدايا. في البداية ، كنت مسؤولاً عن التطوير في المعالجة وحولها. في وقت لاحق ، بحلول نهاية العام ، تولت القيادة الفنية للمشروع بأكمله إلى جانب مهمة استعادة توازن القوى بعد مغادرة جزء من الفريق.
كانت القواعد الموجودة في الرأس والنظام العالمي للمطور تنفجر في اللحامات ، ثم انهارت في النهاية. لقد أخرجتني المسؤولية عن مشروع كبير ومعقد الأفكار المثالية حول عالم التنمية بالمفاهيم وقوس قزح. لقد تطلب عالم القيود القاسية والحلول الكافية فهمًا ومراجعة لجميع الأساليب والقواعد التي اتبعتها.
الوجبات الجاهزة # 6:متلازمة المنتحل. ماذا لو تعرضت؟ بالطبع سوف يفضحون إذا لم يتم فعل شيء. إذا فعلت شيئًا مهمًا ، فبعد فترة ستلاحظ أنه لا يوجد أحد لفضحك.
الاختلاف والتقارب
وفقًا للتسلسل الزمني لـ "مسار المطور" الخاص بي ، يجب أن تكون هناك قصة مثيرة للاهتمام من وجهة النظر الفنية حول مشروع السياسات الشخصية. في هذا المشروع ، نفذنا معالجة البيانات في الوقت الفعلي ، وغيّر "سريعًا" المبادئ الأساسية لبنية النظام ، وانتقلنا إلى هندسة الأحداث المدفوعة. لكن حول هذا ، لدي بالفعل تقرير منفصل من مؤتمر Highload '19 ( ومقال هنا عن حبري). لذلك ، أفضل إخبارك عن "الأمور الهامة" المتعلقة بالإدارة الفنية وليس الإدارة ذاتها.
عندما ينمو مطور إلى منصب كبير ، والذي يجب أن يُقرأ على أنه "مستعد لتحمل المسؤولية ومعرفة كيفية اتخاذ القرارات بشكل مستقل" ، فإن الخطوة الكلاسيكية التالية هي قائد الفريق. قائد الفريق هو الشخص المسؤول الأول عن الفريق ، أي للناس وعمليات التنمية. لا يأتي العميل إلى المطور ، بل يأتي إلى قائد الفريق ، ويسأل عن التزامات قائد الفريق أيضًا.
لقد اتضح أنه شيء متناقض - بمجرد أن ينضج المطور ليعمل بشكل مستقل كمهندس ، فإنه يقع في عاصفة تسمى الإدارة.
لا ، ربما يبدو هذا المسار مريحًا جدًا بالنسبة لشخص ما ، ويبدو الانتقال من الخوارزميات والبروتوكولات الواضحة للغاية لتفاعل أنظمة الكمبيوتر إلى التنسيق بين مجموعة من الأشخاص أمرًا منطقيًا. ولكن يبدو لي أنه ليس من قبيل الصدفة أن تدور معظم المحادثات في محادثات الملف الشخصي وفي مؤتمرات قادة الفرق حول مفهوم "الألم".
ما هو ألم قائد الفريق؟ أليس لأن المهندس هو المسؤول عن الإدارة ؟! لا ، لماذا يحدث هذا أمر مفهوم - ليس لدينا مدرسة للإدارة التقنية على هذا النحو ، ومن المفترض أن مهندس تكنولوجيا المعلومات هو رجل خارق يمكنه اكتشاف كل شيء ، بما في ذلك شيء "بسيط" مثل الإدارة.
لكنني قررت أن أذهب في الاتجاه الآخر واخترت منصب قائد تقني كخطوة مهنية تالية. كمهندس معماري ، أعمل مع فرق التطوير ، والآن أسمع من الرجال ما قلته للمديرين قبل عام:
لماذا المتطلبات سيئة التطور؟ حلول العكازات! ما اسبوعين ؟! هنا يعمل لمدة شهر.
لكن يا إلهي ، الآن مهمتي هي حل مثل هذه المشاكل. ولكن بمجرد أن تترجم تفكيرك إلى نموذج التكلفة والفوائد ، فإنك تدرك أنه لا يمكن حل كل هذه المشكلات - فأنت لا تزال تعرف الحياة!
الوجبات الجاهزة # 7: الافتتاح! لا يتعامل المديرون مع حل المشكلات ؛ بل يديرون الفوضى.
كقائد تقني ، وظيفتي هي إزالة عدم اليقين لفريق التطوير. المتطلبات لم تنجح؟ حلول العكازات؟ ألا توفر العمارة؟ هذه كلها إشارات على هشاشة النظام وتباعده.
لنفترض أن إعداد المهمة في خدمة إنشاء الأمر يبدو كالتالي: من
الضروري إضافة الحقل X والحقل Y. مطلوب أن تساوي القيمة في الحقل Y 'عند الإخراج قيمة Z إذا كانت X هي 1.
تكمن المشكلة في بيان المتطلبات ذاته. الخطأ هنا هو أنه من غير الواضح تمامًا ما هي حالة النظام التي تريد تحقيقها. تؤدي الخطوات المحددة بالكامل في البيان إلى عدم اليقين أثناء التنفيذ والتشغيل.
بعد العديد من هذه المهام ، ستكون خدمة إنشاء الطلبات في حالة هشة إلى حد ما - وستبدأ في الحدوث مثل تلك التي حدثت عندما أضفنا حقلين وكل شيء معطل.
الهدف: ضمان تقارب حالات الأنظمة واتساق بيان المهام وتقليل عدم اليقين لتحقيق الاستقرار.
يعمل الأشخاص الذين يعملون على خط التمثيل باستمرار على بناء وتحديث نماذجهم لما يكمن وراءه. هذه الأنشطة ضرورية لمرونة أنظمة الإنترنت وهي مصدر رئيسي للقدرة على التكيف. فوق الخط ، تحت الخط
يجب أن يفهم المهندس المعماري وحدة النظام الاجتماعي والتقني. تكون قادرًا على تنسيق العمليات فوق خط العرض بحيث تلبي الأنظمة الموجودة أسفل خط العرض قيود الصحة والاستقرار والقدرة على التكيف.
الخلاصة رقم 8: إذا توقفت القواعد عن العمل ، تهانينا ، فقد وصلت إلى الشروط الحدودية التي يتوقف فيها النموذج الحالي عن العمل. حان الوقت لمراجعة أفكارك وإيجاد نموذج جديد يلبي القيود الحالية ويسمح لك ببناء عمليات وقواعد مناسبة.
لينة بسيطة ، الناس صعبة!
لا حقا. هذا ما كتب في كتاب واحد عن العمارة. ويبدو أنه كلما تقدمت أكثر ، كلما كررت هذا الكتاب أكثر.
المفاهيم التقنية والخوارزميات والمعايير واضحة - ما عليك سوى أن تأخذها وتكتشفها باستمرار. أنا لا أحاول استبعاد عمل المهندسين - فالخوارزميات للأنظمة الموزعة معقدة للغاية إذا لم تقم ببناء مثل هذه الأنظمة على أساس يومي. ولكن في أغلب الأحيان ، تنشأ الصعوبة الرئيسية التي نواجهها في عملية العمل عندما نحتاج إلى فهم سبب تطلب هذه الخدمة أو تلك مستوى من التجريد للمجال. وغالبًا ما تتفاقم المشكلة بسبب عدم وجود الشخص الذي كتب الخدمة.
تعد الخوارزميات التي يسهل تنفيذها أكثر نجاحًا من الخوارزميات الدقيقة رياضيًا. يعد Paxos دقيقًا رياضيًا ، ولكن فقط مع وصف بروتوكول Raft ، الذي يسهل تنفيذه ، تم تطوير التطبيق العملي لخوارزميات الإجماع.
تم انتقاد لغة جولانج لكونها محدودة للغاية. ولكن تمت كتابة Docker و Kubernetes والعديد من الأنظمة الموزعة الأخرى عليه. يعمل نظام القيود المصمم جيدًا كأساس للأنظمة الناجحة.
سيكون كل شيء أسهل بكثير إذا لم يكن على التكنولوجيا أن تأخذ في الحسبان العامل البشري. لكن عليهم ذلك. يجب أن يأخذ أي نظام في تكنولوجيا المعلومات ، يشترك فيه أكثر من شخص واحد ، العامل البشري في الاعتبار.
وهنا تظهر التقنيات عند تقاطع البرامج والأشخاص ، المصممة لهيكلة الفوضى ووصف التفاعلات المعقدة. التصميم المدفوع بالمجال ، والخدمات المصغرة ، والرشاقة - جميعها تخلق قيودًا تصف مبادئ وقواعد التفاعل. تظهر الهياكل التي من الواضح كيفية العمل بها. لكنها لا تتحسن دائمًا مع ظهور مثل هذه التقنيات. غالبًا ما يتبين العكس - ما لا يمكن للمال شراؤه .
الوجبات الجاهزة # 9: يمكن للبرامج أن تكون بسيطة ويجب أن تكون كذلك. للقيام بذلك ، تحتاج إلى بذل جهود لتشكيل ثقافة هندسية. هي التي تحدد في النهاية أداء الخدمات.
قائمة القراءة
كتب
مسار المدير: دليل لقادة التكنولوجيا الذين يتنقلون بين النمو والتغيير ، كاميل فورنييه - ربط
اللغز الأنيق: أنظمة الإدارة الهندسية ، ويل لارسون - طوبولوجيا فريق الارتباط
: تنظيم فرق الأعمال والتكنولوجيا للتدفق السريع ، ومانويل بايس وماثيو سكيلتون - رابط
تصحيح البرامج، جوفال لووي - رابط
التفكير في أنظمة: وهو أول كتاب، Donella ميدوز - إشارة
المقالات
النماذج العقلية، شارع العام Fernam - رابط
التعقيد التحيز: لماذا نحن أفضل معقدة إلى بسيطة. شارع فيرنام - ربط
ما لا يمكن للمال أن يشتريه ، أقل خطأ - الرابط أن
تصبح غير معتاد على الحقيقة ، وأقل خطأ -ربط
قوانين البرمجة بالواقع: هل نعرف ما نعتقد أننا نعرفه؟ - وصلة
لا الفضة جوهر رصاصة والحوادث هندسة البرمجيات - ارتباط
فن استكشاف الأخطاء وإصلاحها - وصلة
- من الهشة لAntifragile البرامج رابط
يمكن فهم أجهزة الكمبيوتر - رابط
تاكمان مخطئا! (معلومات عن الفرق) - إشارة
كيفية تفشل في كل شيء تقريبا ومازال فوز كبير - رابط
البساطة قبل عمومية، استخدم قبل إعادة استخدام - رابط
البساطة، الرجاء - A بيان لبرنامج التنمية - لينك
برامج التصميم هو العلاقات البشرية - لينك