ملحوظة. ترجمة.: مؤلفة هذه المادة هي سيندي سريداران، وهي مهندسة في imgix ومتخصصة في تطوير واجهة برمجة التطبيقات (API)، وعلى وجه الخصوص، اختبار الخدمات الصغيرة. في هذه المادة، تشارك رؤيتها التفصيلية للمشاكل الحالية في مجال التتبع الموزع، حيث، في رأيها، هناك نقص في الأدوات الفعالة حقًا لحل المشكلات الملحة.
[الصورة مأخوذة من حول التتبع الموزع.]
ويعتقد أن صعوبة التنفيذ، والعائد عليه . هناك العديد من الأسباب التي تجعل التتبع يمثل مشكلة، وغالبًا ما يتم الاستشهاد بالجهد المبذول في تكوين كل مكون من مكونات النظام لإرسال الرؤوس المناسبة مع كل طلب. وعلى الرغم من وجود هذه المشكلة، إلا أنها ليست مستعصية على الحل بأي حال من الأحوال. بالمناسبة، هذا لا يفسر سبب عدم إعجاب المطورين بالتتبع (حتى عندما يكون يعمل بالفعل).
التحدي الرئيسي في التتبع الموزع لا يتمثل في جمع البيانات، أو توحيد التنسيقات لتوزيع وعرض النتائج، أو تحديد متى وأين وكيف يتم أخذ العينات. أنا لا أحاول أن أتخيل تافه إن "مشكلات الفهم" هذه، في الواقع، ذات أهمية فنية كبيرة جدًا (إذا كنا نفكر حقًا في المصادر المفتوحة) ) التحديات السياسية التي يجب التغلب عليها حتى تعتبر هذه المشاكل محلولة.
ومع ذلك، إذا تخيلنا أن كل هذه المشاكل قد تم حلها، فهناك احتمال كبير بأن لا يتغير شيء بشكل كبير من حيث تجربة المستخدم النهائي. قد لا يكون التتبع ذا فائدة عملية في سيناريوهات تصحيح الأخطاء الأكثر شيوعًا، حتى بعد نشره.
مثل هذا الأثر المختلف
يتضمن التتبع الموزع عدة مكونات متباينة:
- وتجهيز التطبيقات والبرمجيات الوسيطة بأدوات التحكم؛
- نقل السياق الموزع؛
- جمع الآثار
- تخزين التتبع؛
- استخراجها وتصورها.
يميل الكثير من الحديث عن التتبع الموزع إلى التعامل معه كنوع من العملية الأحادية التي يتمثل هدفها الوحيد في المساعدة في تشخيص النظام بشكل كامل. ويرجع ذلك إلى حد كبير إلى كيفية تشكيل الأفكار حول التتبع الموزع تاريخياً. في ، صنع عند فتح مصادر زيبكين، ذكر ذلك إنه [Zipkin] يجعل تويتر أسرع. تم أيضًا الترويج للعروض التجارية الأولى للبحث عن المفقودين .
ملحوظة. ترجمة.: لتسهيل فهم النص، دعونا نحدد مصطلحين أساسيين وفقًا لذلك :
- امتداد — العنصر الأساسي للتتبع الموزع. إنه وصف لسير عمل معين (على سبيل المثال، استعلام قاعدة بيانات) مع اسم وأوقات البدء والانتهاء والعلامات والسجلات والسياق.
- تحتوي الامتدادات عادةً على روابط لامتدادات أخرى، مما يسمح بدمج امتدادات متعددة فيها أثر — تصور لحياة الطلب أثناء تحركه عبر نظام موزع.
تحتوي الآثار على بيانات قيمة بشكل لا يصدق يمكن أن تساعد في مهام مثل اختبار الإنتاج، واختبار التعافي من الكوارث، واختبار حقن الأخطاء، وما إلى ذلك. في الواقع، تستخدم بعض الشركات بالفعل التتبع لأغراض مماثلة. لنبدأ مع له استخدامات أخرى إلى جانب نقل الامتدادات إلى نظام التخزين:
- على سبيل المثال، أوبر تتبع النتائج للتمييز بين حركة الاختبار وحركة الإنتاج.
- فيسبوك بيانات التتبع لتحليل المسار الحرج ولتبديل حركة المرور أثناء الاختبارات المنتظمة للتعافي من الكوارث.
- أيضا الشبكة الاجتماعية دفاتر ملاحظات Jupyter التي تسمح للمطورين بتشغيل استعلامات عشوائية على نتائج التتبع.
- أتباع (حقن الفشل المدفوع بالنسب) آثار موزعة للاختبار مع حقن الخطأ.
لا ينطبق أي من الخيارات المذكورة أعلاه بالكامل على السيناريو تصحيح الأخطاء، حيث يحاول المهندس حل المشكلة من خلال النظر إلى التتبع.
متى سيأتي بعد يصل إلى البرنامج النصي لتصحيح الأخطاء، وتظل الواجهة الأساسية هي الرسم التخطيطي تراكيفيو (على الرغم من أن البعض يسميها أيضًا "مخطط جانت" أو "مخطط الشلال"). تحت تراكيفيو я جميع الامتدادات وبيانات التعريف المصاحبة التي تشكل معًا التتبع. يقدم كل نظام تتبع مفتوح المصدر، بالإضافة إلى كل حلول التتبع التجارية، طريقة تراكيفيو واجهة المستخدم لتصور وتفصيل وتصفية الآثار.
المشكلة في جميع أنظمة التتبع التي رأيتها حتى الآن هي أن النتيجة التصور (تتبع التتبع) يعكس بشكل كامل تقريبًا ميزات عملية إنشاء التتبع. حتى عندما يتم اقتراح تصورات بديلة: الخرائط الحرارية، وطوبولوجيات الخدمة، والرسوم البيانية لزمن الوصول، فإنها لا تزال في نهاية المطاف تصل إلى تراكيفيو.
في الماضي أنا يبدو أن معظم "ابتكارات" تتبع واجهة المستخدم/تجربة المستخدم تقتصر على بيانات وصفية إضافية في التتبع، واستثمار المعلومات فيها بأهمية أساسية عالية (عالية الأهمية) أو توفير القدرة على التعمق في فترات محددة أو تشغيل الاستعلامات بين وداخل التتبع... حيث تراكيفيو تظل أداة التصور الأساسية. وطالما استمر هذا الوضع، فإن التتبع الموزع (في أحسن الأحوال) سيحتل المركز الرابع كأداة لتصحيح الأخطاء، بعد المقاييس والسجلات وتتبعات المكدس، وفي أسوأ الأحوال، سيتبين أنه مضيعة للمال والوقت.
مشكلة في عرض التتبع
مصير تراكيفيو - تقديم صورة كاملة لحركة طلب واحد عبر جميع مكونات النظام الموزع الذي يرتبط به. تسمح لك بعض أنظمة التتبع الأكثر تقدمًا بالتعمق في المسافات الفردية وعرض التفاصيل مع مرور الوقت داخل عملية واحدة (عندما يكون للامتدادات حدود وظيفية).
الفرضية الأساسية لهندسة الخدمات الصغيرة هي فكرة أن الهيكل التنظيمي ينمو مع احتياجات الشركة. يقول مؤيدو الخدمات المصغرة أن توزيع مهام العمل المختلفة على الخدمات الفردية يسمح لفرق التطوير الصغيرة والمستقلة بالتحكم في دورة الحياة الكاملة لهذه الخدمات، مما يمنحهم القدرة على بناء تلك الخدمات واختبارها ونشرها بشكل مستقل. ومع ذلك، فإن عيب هذا التوزيع هو فقدان المعلومات حول كيفية تفاعل كل خدمة مع الآخرين. في مثل هذه الظروف، يدعي التتبع الموزع أنه أداة لا غنى عنها تصحيح الأخطاء التفاعلات المعقدة بين الخدمات.
إذا كنت حقا فلا يستطيع أحد أن يبقيه في رأسه полную صورة. وفي الواقع، فإن تطوير أداة مبنية على افتراض أنها ممكنة هو أمر مخالف للنمط (نهج غير فعال وغير منتج). من الناحية المثالية، يتطلب تصحيح الأخطاء أداة تساعد تضييق منطقة البحث الخاصة بك، حتى يتمكن المهندسون من التركيز على مجموعة فرعية من الأبعاد (الخدمات/المستخدمين/المضيفين، وما إلى ذلك) ذات الصلة بسيناريو المشكلة قيد النظر. عند تحديد سبب الفشل، لا يُطلب من المهندسين فهم ما حدث أثناء المشكلة جميع الخدمات في وقت واحدلأن مثل هذا المطلب يتعارض مع فكرة بنية الخدمات المصغرة.
ومع ذلك، تتبع التتبع هو بالضبط هذا. نعم، تقدم بعض أنظمة التتبع طرق عرض تتبع مضغوطة عندما يكون عدد الامتدادات في التتبع كبيرًا جدًا بحيث لا يمكن عرضها في تصور واحد. ومع ذلك، نظرًا للكمية الكبيرة من المعلومات الواردة حتى في مثل هذا التصور المبسط، لا يزال المهندسون قادرين على ذلك اضطر ل "غربلتها"، مما أدى إلى تضييق نطاق الاختيار يدويًا ليشمل مجموعة من الخدمات التي تمثل مصادر للمشاكل. ولسوء الحظ، فإن الآلات في هذا المجال أسرع بكثير من البشر، وأقل عرضة للأخطاء، ونتائجها أكثر قابلية للتكرار.
سبب آخر يجعلني أعتقد أن طريقة عرض التتبع خاطئة هو أنها ليست جيدة لتصحيح الأخطاء القائم على الفرضيات. في جوهرها، التصحيح هو ترابطي عملية تبدأ بفرضية، يتبعها التحقق من الملاحظات والحقائق المختلفة التي تم الحصول عليها من النظام عبر ناقلات مختلفة واستنتاجات/تعميمات وتقييم إضافي لحقيقة الفرضية.
فرصة سريع ورخيص اختبار الفرضيات وتحسين النموذج العقلي وفقا لذلك حجر الأساس تصحيح الأخطاء وينبغي أن تكون أي أداة التصحيح تفاعلية وتضييق مساحة البحث، أو في حالة وجود دليل كاذب، السماح للمستخدم بالعودة والتركيز على منطقة مختلفة من النظام. الأداة المثالية سوف تفعل هذا بشكل استباقي، يلفت انتباه المستخدم على الفور إلى مناطق المشاكل المحتملة.
للأسف، تراكيفيو لا يمكن أن يسمى أداة ذات واجهة تفاعلية. أفضل ما يمكن أن تتمناه عند استخدامه هو العثور على مصدر لزيادة زمن الاستجابة وإلقاء نظرة على جميع العلامات والسجلات المحتملة المرتبطة به. وهذا لا يساعد المهندس على التعرف أنماط في حركة المرور، مثل تفاصيل توزيع التأخير، أو اكتشاف الارتباطات بين القياسات المختلفة. قد يساعد في التغلب على بعض هذه المشاكل. حقًا، تحليل ناجح باستخدام التعلم الآلي لتحديد النطاقات الشاذة وتحديد مجموعة فرعية من العلامات التي قد تكون مرتبطة بالسلوك الشاذ. ومع ذلك، لا يزال يتعين علي رؤية تصورات مقنعة للتعلم الآلي أو نتائج التنقيب في البيانات مطبقة على مسافات تختلف بشكل كبير عن عرض التتبع أو DAG (الرسم البياني غير الدوري الموجه).
الامتدادات منخفضة المستوى للغاية
المشكلة الأساسية في نظام التتبع هي ذلك يمتد تعتبر عناصر أولية منخفضة المستوى جدًا لكل من تحليل زمن الوصول وتحليل السبب الجذري. إنه يشبه تحليل أوامر المعالج الفردية لمحاولة حل الاستثناء، مع العلم أن هناك أدوات ذات مستوى أعلى مثل التتبع العكسي أكثر ملاءمة للعمل معها.
علاوة على ذلك، سأسمح لنفسي بتأكيد ما يلي: من الناحية المثالية، لا نحتاج إلى ذلك الصورة الكاملة حدثت خلال دورة حياة الطلب، والتي تمثلها أدوات التتبع الحديثة. وبدلاً من ذلك، يلزم وجود شكل من أشكال التجريد عالي المستوى يحتوي على معلومات حول ماذا صار خطا (على غرار backtrace)، إلى جانب بعض السياق. بدلاً من مشاهدة التتبع بأكمله، أفضل رؤيته часть، حيث يحدث شيء مثير للاهتمام أو غير عادي. حاليًا، يتم إجراء البحث يدويًا: يتلقى المهندس التتبع ويقوم بشكل مستقل بتحليل المسافات بحثًا عن شيء مثير للاهتمام. النهج الذي يتبعه الأشخاص الذين يحدقون في المسافات في الآثار الفردية على أمل اكتشاف النشاط المشبوه لا يتسع على الإطلاق (خاصة عندما يتعين عليهم فهم جميع البيانات الوصفية المشفرة في فترات مختلفة، مثل معرف النطاق، واسم طريقة RPC، ومدة النطاق 'أ، السجلات، العلامات، وما إلى ذلك).
بدائل للتتبع
تكون نتائج التتبع مفيدة للغاية عندما يمكن تصورها بطريقة توفر رؤية غير تافهة لما يحدث في الأجزاء المترابطة من النظام. وإلى أن يحدث هذا، تظل عملية تصحيح الأخطاء قائمة إلى حد كبير خامل ويعتمد على قدرة المستخدم على ملاحظة الارتباطات الصحيحة، أو التحقق من الأجزاء الصحيحة من النظام، أو تجميع قطع اللغز معًا - على عكس أداةمما يساعد المستخدم على صياغة هذه الفرضيات.
أنا لست مصممًا مرئيًا أو متخصصًا في تجربة المستخدم، ولكن في القسم التالي أريد مشاركة بعض الأفكار حول الشكل الذي قد تبدو عليه هذه التصورات.
التركيز على خدمات محددة
في الوقت الذي تتوحد فيه الصناعة حول الأفكار ، يبدو من المعقول أن تعطي الفرق الفردية الأولوية لضمان توافق خدماتها مع هذه الأهداف. إنه يتبع هذا موجهة نحو الخدمة التصور هو الأنسب لمثل هذه الفرق.
تعد الآثار، خاصة بدون أخذ العينات، بمثابة كنز من المعلومات حول كل مكون من مكونات النظام الموزع. يمكن تغذية هذه المعلومات إلى معالج ماكر يزود المستخدمين موجهة نحو الخدمة يمكن التعرف عليها مسبقًا - حتى قبل أن ينظر المستخدم إلى الآثار:
- مخططات توزيع زمن الوصول فقط للطلبات البارزة للغاية (الطلبات الخارجية);
- مخططات توزيع التأخير للحالات التي لا تتحقق فيها أهداف SLO للخدمة؛
- العلامات الأكثر "شائعة" و"مثيرة للاهتمام" و"غريبة" في طلبات البحث في أغلب الأحيان تتكرر;
- تفصيل الكمون للحالات التي اعتمادا على الخدمات لا تحقق أهداف SLO الخاصة بها؛
- انهيار الكمون لمختلف الخدمات النهائية.
بعض هذه الأسئلة ببساطة لا يتم الرد عليها من خلال المقاييس المدمجة، مما يجبر المستخدمين على التدقيق في الامتدادات. ونتيجة لذلك، لدينا آلية معادية للغاية للمستخدم.
وهذا يثير السؤال التالي: ماذا عن التفاعلات المعقدة بين الخدمات المتنوعة التي تسيطر عليها فرق مختلفة؟ أليس كذلك تراكيفيو لا تعتبر الأداة الأنسب لتسليط الضوء على مثل هذه الحالة؟
قد يكون مطورو الأجهزة المحمولة وأصحاب الخدمات عديمة الحالة وأصحاب الخدمات ذات الحالة المُدارة (مثل قواعد البيانات) وأصحاب الأنظمة الأساسية مهتمين بشيء آخر عرض تقديمي توزيع منفصل؛ تراكيفيو هو حل عام للغاية لهذه الاحتياجات المختلفة بشكل أساسي. حتى في بنية الخدمات الصغيرة المعقدة للغاية، لا يحتاج مالكو الخدمة إلى معرفة عميقة بأكثر من خدمتين أو ثلاث خدمات من المنبع والمصب. بشكل أساسي، في معظم السيناريوهات، يحتاج المستخدمون فقط إلى الإجابة على الأسئلة المتعلقة مجموعة محدودة من الخدمات.
إنه مثل النظر إلى مجموعة فرعية صغيرة من الخدمات من خلال عدسة مكبرة من أجل التدقيق فيها. سيسمح هذا للمستخدم بطرح أسئلة أكثر إلحاحًا فيما يتعلق بالتفاعلات المعقدة بين هذه الخدمات وتبعياتها المباشرة. وهذا مشابه للتتبع العكسي في عالم الخدمات، حيث يعرف المهندس ذلك أن خطأ، ولديه أيضًا بعض الفهم لما يحدث في الخدمات المحيطة لفهمه لماذا.
النهج الذي أروج له هو العكس تمامًا للنهج القائم على التتبع من أعلى إلى أسفل، حيث يبدأ التحليل بالتتبع بأكمله ثم يعمل تدريجيًا وصولاً إلى النطاقات الفردية. في المقابل، يبدأ النهج التصاعدي بتحليل منطقة صغيرة قريبة من السبب المحتمل للحادث، ثم يوسع مساحة البحث حسب الحاجة (مع إمكانية جلب فرق أخرى لتحليل نطاق أوسع من الخدمات). يعتبر النهج الثاني أكثر ملاءمة لاختبار الفرضيات الأولية بسرعة. وبمجرد الحصول على نتائج ملموسة، سيكون من الممكن الانتقال إلى تحليل أكثر تركيزا وتفصيلا.
بناء طوبولوجيا
يمكن أن تكون طرق العرض الخاصة بالخدمة مفيدة بشكل لا يصدق إذا كان المستخدم يعرف ذلك ما خدمة أو مجموعة من الخدمات هي المسؤولة عن زيادة زمن الوصول أو التسبب في الأخطاء. ومع ذلك، في نظام معقد، قد يكون تحديد الخدمة المخالفة مهمة غير تافهة أثناء الفشل، خاصة إذا لم يتم الإبلاغ عن رسائل خطأ من الخدمات.
يمكن أن يكون بناء هيكل الخدمة بمثابة مساعدة كبيرة في معرفة الخدمة التي تواجه ارتفاعًا كبيرًا في معدلات الخطأ أو زيادة في زمن الاستجابة الذي يتسبب في تدهور الخدمة بشكل ملحوظ. عندما أتحدث عن بناء طوبولوجيا، لا أقصد خريطة الخدمات، عرض كل خدمة متوفرة في النظام والمعروفة بها . هذا العرض ليس أفضل من عرض التتبع استنادًا إلى رسم بياني غير دوري موجه. بدلا من ذلك أود أن أرى طوبولوجيا الخدمة المولدة ديناميكيًا، استنادًا إلى سمات معينة مثل معدل الخطأ أو وقت الاستجابة أو أي معلمة يحددها المستخدم والتي تساعد في توضيح الموقف مع خدمات مشبوهة معينة.
لنأخذ مثالا. لنتخيل موقعًا إخباريًا افتراضيًا. خدمة الصفحة الرئيسية (الصفحة الأمامية) يتبادل البيانات مع Redis، مع خدمة التوصيات، مع خدمة الإعلانات وخدمة الفيديو. تأخذ خدمة الفيديو مقاطع فيديو من S3 وبيانات التعريف من DynamoDB. تتلقى خدمة التوصية البيانات التعريفية من DynamoDB، وتقوم بتحميل البيانات من Redis وMySQL، وتكتب الرسائل إلى Kafka. تتلقى خدمة الإعلانات البيانات من MySQL وتكتب الرسائل إلى كافكا.
يوجد أدناه تمثيل تخطيطي لهذه الهيكلية (العديد من برامج التوجيه التجارية تبني الهيكل). يمكن أن يكون مفيدًا إذا كنت بحاجة إلى فهم تبعيات الخدمة. ومع ذلك، خلال تصحيح الأخطاء، عندما تعرض خدمة معينة (على سبيل المثال، خدمة فيديو) وقت استجابة متزايدًا، فإن مثل هذه الهيكلية ليست مفيدة جدًا.
رسم تخطيطي لخدمة موقع إخباري افتراضي
سيكون الرسم البياني أدناه أكثر ملاءمة. هناك مشكلة في الخدمة (فيديو) يصور الحق في المركز. يلاحظ المستخدم ذلك على الفور. من هذا التصور، يتضح أن خدمة الفيديو تعمل بشكل غير طبيعي بسبب زيادة وقت استجابة S3، مما يؤثر على سرعة تحميل جزء من الصفحة الرئيسية.
الهيكل الديناميكي يعرض فقط الخدمات "المثيرة للاهتمام".
يمكن أن تكون الطبولوجيا المولدة ديناميكيًا أكثر كفاءة من خرائط الخدمة الثابتة، خاصة في البنى التحتية المرنة ذات القياس التلقائي. تتيح القدرة على مقارنة طبولوجيا الخدمة وتباينها للمستخدم طرح المزيد من الأسئلة ذات الصلة. من المرجح أن تؤدي الأسئلة الأكثر دقة حول النظام إلى فهم أفضل لكيفية عمل النظام.
عرض مقارن
التصور المفيد الآخر سيكون العرض المقارن. الآثار الحالية ليست مناسبة جدًا لإجراء المقارنات جنبًا إلى جنب، لذلك تكون المقارنات عادةً يمتد. والفكرة الرئيسية لهذه المقالة هي على وجه التحديد أن الامتدادات منخفضة المستوى للغاية بحيث لا يمكن استخراج المعلومات الأكثر قيمة من نتائج التتبع.
لا تتطلب مقارنة تتبعين تصورات جديدة بشكل أساسي. في الواقع، يعد وجود شيء مثل الرسم البياني الذي يمثل نفس المعلومات التي يمثلها عرض التتبع كافيًا. والمثير للدهشة أنه حتى هذه الطريقة البسيطة يمكن أن تحقق نتائج أكثر بكثير من مجرد دراسة أثرين منفصلين. سيكون الاحتمال أقوى تصور مقارنة الآثار في المجموع. سيكون من المفيد للغاية معرفة كيف يؤثر تغيير تكوين قاعدة البيانات التي تم نشرها مؤخرًا لتمكين GC (جمع البيانات المهملة) على وقت استجابة خدمة المصب على نطاق عدة ساعات. إذا كان ما أصفه هنا يبدو وكأنه تحليل أ/ب لتأثير تغييرات البنية التحتية في العديد من الخدمات باستخدام نتائج التتبع، فأنت لست بعيدًا عن الحقيقة.
اختتام
أنا لا أشكك في فائدة التتبع في حد ذاته. أعتقد بصدق أنه لا توجد طريقة أخرى لجمع البيانات الغنية والسببية والسياقية مثل تلك الموجودة في التتبع. ومع ذلك، أعتقد أيضًا أن جميع حلول التتبع تستخدم هذه البيانات بشكل غير فعال للغاية. وطالما ظلت أدوات التتبع عالقة في تمثيل عرض التتبع، فستكون قدرتها محدودة على تحقيق أقصى استفادة من المعلومات القيمة التي يمكن استخلاصها من البيانات الموجودة في عمليات التتبع. بالإضافة إلى ذلك، هناك خطر مواصلة تطوير واجهة مرئية غير ودية وغير بديهية على الإطلاق، مما سيحد بشدة من قدرة المستخدم على استكشاف أخطاء التطبيق وإصلاحها.
يعد تصحيح أخطاء الأنظمة المعقدة، حتى باستخدام أحدث الأدوات، أمرًا صعبًا للغاية. يجب أن تساعد الأدوات المطور في صياغة الفرضية واختبارها، تقديم بنشاط المعلومات ذات الصلة، وتحديد القيم المتطرفة وملاحظة الميزات في توزيع التأخير. لكي يصبح التتبع الأداة المفضلة للمطورين عند استكشاف أخطاء فشل الإنتاج وإصلاحها أو حل المشكلات التي تشمل خدمات متعددة، يلزم وجود واجهات مستخدم أصلية ومرئيات تكون أكثر اتساقًا مع النموذج العقلي للمطورين الذين يقومون بإنشاء هذه الخدمات وتشغيلها.
سوف يتطلب الأمر جهدًا عقليًا كبيرًا لتصميم نظام يمثل الإشارات المختلفة المتاحة في نتائج التتبع بطريقة مُحسّنة لسهولة التحليل والاستدلال. أنت بحاجة إلى التفكير في كيفية تجريد طوبولوجيا النظام أثناء تصحيح الأخطاء بطريقة تساعد المستخدم على التغلب على النقاط العمياء دون النظر إلى آثار أو امتدادات فردية.
نحن بحاجة إلى قدرات تجريد وطبقات جيدة (خاصة في واجهة المستخدم). تلك التي تتناسب جيدًا مع عملية تصحيح الأخطاء المستندة إلى الفرضيات حيث يمكنك طرح الأسئلة واختبار الفرضيات بشكل متكرر. لن تحل تلقائيًا جميع مشكلات إمكانية الملاحظة، ولكنها ستساعد المستخدمين على صقل حدسهم وصياغة أسئلة أكثر ذكاءً. أدعو إلى اتباع نهج أكثر تفكيرًا وابتكارًا في التصور. هناك احتمال حقيقي هنا لتوسيع الآفاق.
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «".
المصدر: www.habr.com