ربما اكتشف الوكيل الهوية الصحيحة.
قد تكون مبنية على المعرفة الحالية والكنسي.
ربما يكون قد حدد الخيار الذي يناسب حاجة المستخدم حقًا.
ويمكن أيضا العثور على موافقة صالحة والسلطة والموافقة.
على الرغم من كل هذا ، يمكن أن يكون العمل مرة أخرى خطأ.
لأن:
القرار الصحيح ليس ضمانا للتنفيذ السليم.
يمكن للوكيل العثور على عنوان الوكيل الصحيح ، ولكن فقط تحديث CRM سجل وترك نظام الشحن بالية.
يمكنه حساب مبلغ الإرجاع الصحيح ؛ ولكن يمكن تطبيق الدفع على طلب عميل آخر.
ألف ألف API يمكن الحصول على الجواب HTTP 200 ومع ذلك ، فإن الطريقة و API قد يغيب عن حقيقة أن النتيجة في العالم الحقيقي من الطلب معالجتها بنجاح لم تكتمل بعد.
عندما يتم تأخير استجابة الشبكة ، يمكن أن تدفع نفس الدفعة مرة أخرى.
يمكنهم نشر خمس لغات من اللغات الست والنظر في اكتمال المنشور بأكمله.
قد لا تعتمد على الرسالة "الناجحة" لأداة نقل الملفات والتحقق مما هو موجود بالفعل في النظام المباشر.
ويمكنه أن يمضي قدما دون فهم النقطة التي لا يمكن عندها التراجع عن العملية.
يمكن استخدام البيانات الشخصية أو التجارية أو السرية بشكل مفرط لمهمة بسيطة.
وفي النهاية، قد لا يكون هناك سجل لما فعلوه، ولمن فعلوا ذلك، وما هي الأدلة التي استندوا إليها.
القيادة ليست مجرد قيادة.
يحمل كل إجراء على الأقل الأسئلة التالية:
على أي نظام؟ أي هدف؟ بأي بيانات؟ كم مرة؟ على أي إنجاز؟ ما هو التحقق المستقل؟ بأي وسيلة للعودة؟ تحت أي سجل؟
وتفحص الأخطاء التسعة في هذا القسم تدهور السلطة الصالحة بسبب النظام الخاطئ أو الهدف الخاطئ أو تفسير النجاح غير الصحيح أو الانضباط التنفيذي غير المكتمل.
تنفيذ الإجراء الصحيح في النظام الخطأ — GBO-ERR-046
واقعة موجزة
يرغب العميل في تغيير عنوان التسليم لطلبه ، والذي لم يتم شحنه بعد.
وهو يوجه وكيل خدمة الوكلاء إلى:
أرسل طلبي إلى عنوان مكتبي الجديد. لم يعد بإمكاني الوصول إلى العنوان القديم".
العميل يؤكد هوية العميل.
احصل على العنوان الجديد بالكامل.
فتح بطاقة العميل على CRM النظام وتحديث العنوان.
ثم يعطون العميل هذه الإجابة:
"تم تغيير عنوان التسليم الخاص بك بنجاح."
ومع ذلك ، لا يتم أخذ عنوان التسليم من CRM في حين يجري إعداد النظام، ولكن من سجل منفصل في نظام إدارة النظام.
يظهر العنوان الجديد في CRM.....
لا يزال نظام الشحن يحمل العنوان القديم.
يتم إرسال الحزمة إلى العنوان حيث لم يعد بإمكان العميل الوصول إليها.
استخدم الوكيل المعلومات الصحيحة للعميل المناسب.
ومع ذلك، لم يطبقوا التغيير على النظام الذي يحكم السلوك بالفعل.
ما يبدو صحيحًا ظاهريًا
CRM يحتوي على حقل "عنوان".
تم تحديث بطاقة العميل بنجاح.
النظام لم يرتكب أي أخطاء.
يظهر عنوان جديد على شاشة الوكيل.
ولذلك، يبدو أن العملية قد اكتملت.
ولكن يمكن العثور على نفس الحقيقة في أنظمة مختلفة:
عنوان الاتصال في CRM ،،،
عنوان التسليم في نظام النظام ،
العنوان القانوني في نظام الفواتير
عنوان الشحن في مزود الشحن.
فقط لأن أسماء النطاقات متشابهة لا يعني أن وظيفتها هي نفسها.
موضع الخلل الحقيقي
تم تجاوز بوابة نظام التنفيذ.
أجاب الوكيل على السؤال:
"أين يتم الاحتفاظ بالعنوان؟"
لكنهم لم يجيبوا على السؤال:
"ما هو النظام الذي يحدد التسليم المادي لهذا الأمر؟"
لا يتغير السلوك عند كتابة البيانات الصحيحة في نظام التسجيل الخاطئ.
إنها أشياء مختلفة يمكن للمعلومات التحكم في النتيجة في العالم الحقيقي من خلال الظهور.
هذا الخطأ شائع بشكل خاص في الحالات التالية:
الاحتفاظ بنفس البيانات في أنظمة متعددة ،
العمل معا من المنصات القديمة والجديدة ،
نظام يحمل فقط الغرض من التصوير أو الإبلاغ ،
عدم وضوح مصدر المعاملة الفعلي.
الضرر المحتمل
التسليم إلى العنوان الخطأ
فاتورة خاطئة أو سجل ضريبي خاطئ
تناقض معلومات العملاء بين الأنظمة
تكلفة العودة وإعادة الشحن
المنتج السري يصل إلى الشخص الخطأ
المستخدم لا يتخذ أي تدابير أخرى تعتمد على الإجابة "تغيرت".
التالى وكلاء missysteme مصدر الكنسي
قبول المنظمة للإنجازات التقنية كتغيير حقيقي في السلوك
يمكن أن يحدث
يمكن ملاحظة نفس الخطأ في البث الشبكي:
يكتب الوكيل السعر الصحيح إلى ثابت HTML ولكن الموقع يستنسخ السعر القديم من كتالوج الخدمات الكنسي في التجميع التالي.
ويبدو أن التغيير صحيح.
وهي ليست دائمة لأن مصدرها غير صحيح.
إشارة الكشف
نفس المعلومات موجودة في أنظمة متعددة.
لم يتم تحديد النظام الذي هو مصدر المعالجة.
يغير الوكيل المنطقة التي تبدو وحدها.
لا يتم التحكم في السلوك الحقيقي بعد التغيير.
CRM سجلات النظام والمحاسبة والشحن مستقلة عن بعضها البعض.
يتم استخدام الرسالة "المسجلة" كدليل على النتائج.
المظهر المستمد من مصدر الكنسي ليست منفصلة.
التزامن التالي يمكن عكس التغيير.
السلوك الصحيح
يجب على الوكيل أولاً فهم دورة حياة البيانات:
في أي نظام ولدت هذه المعلومات؟
ما هو النظام الذي يحكمها بشكل قانوني؟
ما السجل الذي تستخدمه المعاملة الفعلية؟
كيف يتم التحويل إلى أنظمة أخرى؟
إلى أي حد يجب تحقيق التغيير؟
كيف سيتم تأكيد النتيجة؟
الوكيل في مثال العنوان:
يجب تحديث سجل إدارة النظام,
يجب على الشحنة التحقق مما إذا لم يتم قفلها بعد ،
تأكيد العنوان الأخير على نظام الشحن،
لو CRM مطلوب التسجيل ، يجب أن يتساوى معه أيضًا.
فقط بعد تأكيد النتيجة الفعلية للعميل:
"تم تحديث عنوان الشحن الخاص بطلبك كعنوان مكتبك الجديد."
يجب أن يكون كذلك
قاعدة الآلة
لا تكتمل المعاملة حتى يتم تطبيق المعلومات الصحيحة على النظام الأساسي الذي يتحكم في السلوك. يجب تمييز سجلات العرض ومصادر التنفيذ.
سؤال التدقيق
عندما تكون نفس المعلومات موجودة في عدة أنظمة، هل يعرف وكلاؤنا السجل الذي يتم عرضه فقط، والذي يمكنه تنفيذ المعاملة وما هو المصدر الأساسي؟
تنفيذ الإجراء الصحيح على الهدف الخطأ — GBO-ERR-047
واقعة موجزة
تقارير العملاء يتم توجيه الاتهام مرتين.
يقوم الوكيل المالي بفحص المعاملات.
تم استلام دفعتين لنفس الطلب.
يحسب الوكيل بشكل صحيح المبلغ الذي يجب إرجاعه:
480 دولار
هناك شخصان في قاعدة بيانات العملاء يحملان نفس الاسم:
محمد كايا — أمر NK-481872
محمد كايا — أمر NK-48127
أرقام الأوامر متشابهة جدا.
يبدأ الوكيل التسليم بالمبلغ الصحيح.
لكنهم يختارون سجل النظام الخطأ.
يتم إرسال 480 $ إلى محمد كايا الآخر.
الزبون الحقيقي لا يستطيع أخذ ماله
العميل الخطأ يرى عودة غير متوقعة.
الحساب صحيح.
نوع العملية صحيح.
المبلغ صحيح.
الهدف خاطئ.
ما يبدو صحيحًا ظاهريًا
يرى الوكيل اسم الوكيل ومقدار ونوع المعاملة بشكل صحيح.
عند الاختيار بين سجلات مماثلة:
الاسم،
رقم أمر الإغلاق ،
تاريخ مماثل،
نفس المنتج
علامات مثل هذه قد تبدو كافية.
قد تظهر الواجهة البشرية أيضًا سجلات عن كثب معًا.
بمجرد أن يختار الوكيل الهدف ، يكملون بقية العملية بلا عيب.
لذلك ، يحدث الخطأ في لحظة ربط الهدف ، وليس في نهاية سلسلة التنفيذ.
موضع الخلل الحقيقي
تم تجاوز بوابة ربط الإجراء بالهدف.
يجب أن يربط الإجراء أربعة عناصر معًا:
العمل الصحيح
+ الكيان الصحيح
+ تصحيح السجل
+ حساب الهدف الصحيح
قد يكون اسم الشخص صحيحا.
لكنه ليس الترتيب الصحيح أو الحساب أو الملف.
قد ينتمي الخادم إلى الشركة المناسبة.
لكن التغيير ليس بيئة الإنتاج التي يجب القيام بها.
موظف في القسم الصحيح.
ولكنها ليست محاورا للرسالة.
دقة العمل ليست مستقلة عن دقة الهدف.
الضرر المحتمل
تحويل الأموال إلى الشخص الخطأ
استمرار إيذاء العميل الأصلي
ربط المعلومات الشخصية أو المالية بالشخص الخطأ
تعطيل السجلات المحاسبية
مشكلة التجميع
فقدان ثقة العملاء
التغييرات على الخادم الخطأ أو الملف أو حساب المستخدم
التصحيح الصحيح يصبح خطأ جديد
يمكن أن يحدث
في بعض المناطق ، يمكن أن يؤدي الهدف الخطأ إلى نتيجة أثقل بكثير:
السجلات الطبية للمريض الخطأ ،
إغلاق حساب الموظف الخطأ ،
دفع لحساب شركة خاطئ ،
حذف قاعدة البيانات الخاطئة،
نشر على حساب وسائل الاعلام الاجتماعية خاطئة.
إشارة الكشف
هناك سجلات لنفس الاسم أو ما شابه ذلك.
الهوية تعتمد على منطقة واحدة فقط.
أوامر أو أرقام العملاء هي قريبة بصريا معا.
لا يظهر الوكيل ملخص الهدف قبل العملية.
ولا يوجد التحقق من الهدف الثاني في العمليات العالية الأثر.
تحتفظ الواجهة بآخر سجل محدد افتراضيًا.
يستخدم النظام السجل الأول الذي يأتي مع نتيجة البحث بالاسم.
لا يحتوي إيصال المعاملة على الهوية الفريدة للهدف.
السلوك الصحيح
قبل اتخاذ إجراء عالي التأثير، يجب على الوكيل التحقق من الهدف باستخدام معرفات فريدة متعددة:
هوية العميل
رقم الطلب
معرف الدفع
البريد الإلكتروني أو الحساب
تاريخ التشغيل
سبب العودة
يمكن عرض ملخص هدف موجز قبل العملية:
هدف العودة: محمد كايا ترتيب: NK-481872 الدفع: PAY-992014 مبلغ: 480 USD المصدر: نهاية 7421 لماذا: الجمع المتبادل
يجب على الوكيل التوقف عن اتخاذ إجراء أو طلب التحقق البشري إذا كان هناك عدم يقين سجل مماثل.
قاعدة الآلة
يجب عدم تنفيذ العملية الصحيحة حتى يتم التحقق من هوية الهدف الفريدة. اسم أو رقم مماثل أو موقف في واجهة ليست دليلا كافيا على الهدف.
سؤال التدقيق
بالنسبة للإجراءات التي تنطوي على أموال أو بيانات أو وصول أو اتصالات خارجية ، هل نتحقق من الهدف بمعرفات فريدة تتناسب مع المخاطر ، وحيثما يلزم ، تقديم ملخص مستهدف قابل للقراءة البشرية؟
اعتبار استجابة HTTP 200 نجاحًا في العالم الحقيقي — GBO-ERR-048
واقعة موجزة
يتم تعيين وكيل سفر لإلغاء حجز الفندق للمستخدم.
يرسل الوكيل طلب إلغاء إلى حجز الفندق API.....
النظام يجيب:
HTTP 200
تم استلام الطلب
معالجة الخلايا الخلوية
يفسر الوكيل هذا على أنه نجاح ويخبر المستخدم:
"لقد تم إلغاء الحجز الخاص بك. لن تكون هناك رسوم".
وفي هذا الرد، HTTP 200 يشير إلى أن الطلب قد تمت معالجته بنجاح وفقًا للطريقة ذات الصلة و API لكن عبارة "معالجة الإلغاء" في الهيئة تنص بوضوح على أن إلغاء الحجز لم يتم الانتهاء منه بعد.
يتم تشغيل العملية على نظام منفصل في الخلفية.
بعد بضع دقائق ، فشل الإلغاء لأن الحجز تجاوز فترة الإلغاء المجانية لمدة ساعة.
لا يتصل المستخدم بالفندق من خلال الاعتماد على إجابة الوكيل.
في اليوم التالي ، يتم تحصيل الرسوم الكاملة من بطاقة الائتمان.
الوكيل. HTTP وقد فسرت على نطاق واسع حالة نجاح الطلب، متجاهلة العملية التجارية الجارية في هيئة الاستجابة.
لكنهم خلطوا بين القبول التقني وبين نتيجة العمل.
ما يبدو صحيحًا ظاهريًا
تحت RFC 9110 ،،، HTTP 200 يعني أن الطلب تمت معالجته بنجاح وفقًا للطريقة المحددة ؛ و API يحدد محتوى العقد والاستجابة ما يعنيه ذلك لنتائج العمل.
يمكن أن تظهر أدوات المطور علامات خضراء.
API المكالمة لم تعطي خطأ.
تم نقل طلب الوكيل بشكل صحيح.
لكن النجاح على مستوى البروتوكول التقني ليس هو نفس النتيجة على مستوى الأعمال.
في هذه الحالة، تقول هيئة الرد أن الإلغاء لم يكتمل وأن الوضع النهائي سيحدث لاحقًا.
تم استلام الطلب.
العملية في خط.
بدأ التأكيد.
في مرحلة ما ، جاءت النتيجة مرة أخرى.
وسيحدث الوضع النهائي في وقت لاحق.
ويمكن ملاحظة نفس المشكلة في الأمثلة التالية:
قبول إعلان IndexNow كضمان للمسح أو الفهرسة أو الفرز
تسليم قبول خادم البريد الإلكتروني للرسالة ، أو الوقوع في صندوق الوارد الخاص به ، أو عد دليل على القراءة
حساب استلام طلب الدفع عند الانتهاء من التحصيل
تفسير استجابة تحميل الملف كما البث المباشر هو الصحيح
افتراض قبول المرشح في نظام طلب التوظيف
موضع الخلل الحقيقي
تم تجاوز بوابة التحقق من النتيجة.
لم يفصل الوكيل المستويات التالية:
إرسال الطلب:
→ مقبولة تقنياً
→ بدأت المعاملات التجارية.
→ إتمام عملية التحويل المالي
→ تم التحقق من التفوق الحقيقي للحقيقة
الأدلة في مرحلة واحدة لا تشير تلقائيا إلى أن المرحلة التالية قد حدثت.
نجاح البروتوكول ليس تحقيق الهدف.
الضرر المحتمل
الحجز أو الاشتراك غير المصرح به
رسوم غير متوقعة
فشل المستخدم في أداء سلوك التتبع اللازم
تقرير تأكيد غير صحيح
عرض أكثر من رؤية محرك البحث مما هو عليه
سوء فهم حالة الدفع أو الشحن أو النشر
تستند العوامل اللاحقة على معالجة غير مكتملة
اختطاف نافذة الإرجاع
يمكن أن يحدث
إشارة الكشف
الوكيل ينظر فقط إلى HTTP رمز الحالة.
يتم تجاهل التعبير "معلق" أو "مقبول" أو "معالجة" في جسم الاستجابة.
لا يوجد استعلام عن الوضع النهائي للمعاملة.
لا تحمل نتيجة العمل رقم تعريف أو موافقة منفصل.
تعتبر العمليات غير المتزامنة الانتهاء الفوري.
يتم الخلط بين لغة "الإعلان المقبول" و "حدثت عواقب".
يستمر عدم اليقين الواضح أثناء إبلاغ المستخدم بالنتيجة النهائية.
السلوك الصحيح
لكل أداة وعملية، يجب أن يعرف الوكيل عقد الإنجاز وأي حالات وسيطة ومصدر التحقق الموثوق به.
على سبيل المثال ، لإلغاء الحجز:
cancellation_status = confirmed
رقم الإلغاء
حالة الأجور
معلومات استرداد الأموال
تأكيد الفندق النهائي
قد يكون.
يجب على الوكيل أن يقول بعد الرد الأولي:
"تم استلام طلب الإلغاء من قبل النظام ؛ لا يعتبر الحجز ملغيًا بعد. أنا أتحقق من الموافقة النهائية".
عند اكتمال العملية:
"تمت الموافقة على الإلغاء. رقم التأكيد C-7721. رسوم الإلغاء 0 EUR ".."
قد يقولون.
قاعدة الآلة
القبول الفني أو رمز نجاح البروتوكول يجب ألا يفسر على أنه إنجاز في العالم الحقيقي. ويجب التحقق من الإجراء استنادا إلى سجل رسمي للحالة يتناسب مع مخاطره، وعند الاقتضاء، بطريقة منفصلة وظيفيا عن أداة التصرف.
سؤال التدقيق
هل "تم استلام الطلب" و "المعالجة" و "اكتملت" و "تم التحقق من النتائج" حالات منفصلة في أنظمتنا ، وفي أي مرحلة قد يستخدم الوكيل لغة النجاح النهائية مع المستخدم؟
تنفيذ المعاملة نفسها مرتين — GBO-ERR-049
واقعة موجزة
وكيل شراء يشتري رخصة خادم 2400 $ للشركة.
الدفع يرسل الطلب إلى API.....
اتصال الشبكة غير متصل لبضع ثوان.
لا يمكن للعميل الحصول على رد.
ويقوم النظام بما يلي:
"الطلب قد انتهى."
الوكيل يفعل هذا:
"الدفع لم يحدث."
يترجم في شكل ويعيد نفس الطلب.
العملية الثانية تعطي إجابة للنجاح.
وبعد ساعة، يتلقى الفريق المالي مجموعتين منفصلتين بقيمة 2400 دولار.
وصل الطلب الأول إلى مزود الدفع وتم الانتهاء منه.
فقط استجابة النجاح لا يمكن أن تعود إلى الوكيل.
وقد حقق الفريق الهدف نفسه مرتين.
ما يبدو صحيحًا ظاهريًا
إذا لم تستجب عملية ما ، فمن الطبيعي أن تحاول مرة أخرى.
أخطاء الشبكة والأدوات شائعة.
إعادة الاختبار يجعل النظام دائم.
أراد الوكيل أن يبقي المهمة غير منتهية.
لكن:
لم يرد أي رد
مع:
العملية التي لم تنفذ
إنه ليس نفس الشيء.
تلقى النظام الخارجي طلبًا ، ولكن قد تكون هناك مشاكل في مسار الاستجابة.
موضع الخلل الحقيقي
تم تجاوز بوابة التفرّد وثبات أثر التكرار.
المعاملات مثل التمويل والرسائل والأوامر والحجوزات والبث:
معرف معاملة فريدة من نوعها ،
حماية مرة أخرى،
استعلام الحالة النهائية
يجب أن تحمل.
في سياق ما يلي: HTTP الطريقة idempotent هي أن التأثير المقصود من الطلبات المتطابقة المتعددة المقدمة لنفس الغرض على الخادم هو نفس تأثير طلب واحد.
الشرط العملي هو:
عندما يتم إعادة إرسال نفس الغرض عن طريق الخطأ ، يجب ألا ينتج النظام تأثيرًا جانبيًا آخر غير مرغوب فيه ؛ يحدد طريقة دلالات الأسلوب وعقد التنفيذ كيفية تحقيق ذلك.
الضرر المحتمل
شحن مكررة
طلب نفس المنتج مرتين
إرسال نفس البريد الإلكتروني مرتين
تسجيل مستخدم مرتين
انتشار التحفظ نفسه
فاتورتين مختلفتين أو تسجيل العقد
اضطراب المخزون والميزانية والمحاسبة
فقدان ثقة المستخدم
فشل في التراجع عن الصفقة الثانية
يمكن أن يحدث
في إرسال الرسائل ، المعالجة المزدوجة ليست إزعاجًا انفراديًا. الوصول إلى نفس الشخص مرارًا وتكرارًا يمكن أن يصبح مشكلة البريد المزعج والسمعة.
إشارة الكشف
بعد انتهاء المهلة ، يعيد الوكيل إرسال الطلب نفسه على الفور.
لا يوجد رقم تعريفي للمعاملات.
لا يمكن للنظام الخارجي التشكيك في الطلب السابق.
وتصنف حالة "عدم الرد" على أنها "فشلت".
سياسة التكرار هي نفسها في جميع الأدوات.
تستخدم عمليات الدفع والبريد الإلكتروني والقراءة نفس منطق إعادة المحاولة.
يرى المستخدم اثنين من إيصالات العمل المماثلة.
يتم إجراء مكالمة ثانية دون التحقق من تاريخ المعاملة.
السلوك الصحيح
يجب أن تحمل عملية الكتابة عالية التأثير القابلة لإعادة المحاولة مفتاح idempotency فريدًا متفقًا عليه بين العميل والخادم ، أو حماية إعادة تشغيل مكافئة:
operation_id: شراء-2026-004872
يجب أن يقوم النظام الخارجي بتوصيل هذا المفتاح بنفس نية المعالجة ومنع إعادة المحاولة بنفس المفتاح من إنتاج آثار جانبية ثانية خلال الفترة الآمنة ؛ لا يكفي كتابة ` operation_id ` على العميل وحده.
عند فقدان الاستجابة ، الوكيل أولاً:
يجب أن تشكك في الوضع مع معرف المعاملة الخاص بها
تحقق من الطلب أو سجل الدفع
إذا كانت النتيجة غير مؤكدة ، فيجب أن تعلمك.
لا ينبغي أن تبدأ عمليات جديدة ومستقلة
يمكن تجربة القراءات غير الفعالة الجانبية بأمان أكبر في معظم الحالات ؛ ومع ذلك ، يجب تقييم الحد الأقصى للسعر والتكلفة وتأثيرات الاتساق.
تتطلب العمليات الجانبية مثل المال والإرسال ومحو البيانات والنشر والالتزام حماية إعادة أكثر صرامة.
قاعدة الآلة
عدم تلقي رد لا يعني أنه لم تحدث أي معاملة. ويجب ألا يعاد النظر في الإجراءات ذات الأثر الكبير دون وجود معرِّف فريد للمعاملات وضمانة لعدم التعرض للضرر.
سؤال التدقيق
هل تمنع أنظمة الدفع والطلب والبريد الإلكتروني والحجز والنشر من الناحية الفنية تنفيذ الطلب نفسه مرتين بسبب فشل الشبكة أو إعادة المحاولة؟
الإبلاغ عن نجاح جزئي بوصفه نجاحًا كاملًا — GBO-ERR-050
واقعة موجزة
تنشر الشركة صفحة الخدمة الجديدة الخاصة بها بست لغات:
العربية
التركية
الألمانية
العربية
الإسبانية
الروسية
الوكيل يدير تجميع الإنتاج.
يتم قبول جميع الملفات المصدر الستة من قبل المترجم.
بعد النشر المباشر:
يفتح باللغة الإنجليزية.
فتح في التركية.
يفتح بالألمانية.
يفتح في الإسبانية.
يفتح باللغة الروسية.
الطريق العربي يعطي 404 بسبب سوء التوجيه.
في تقرير الاختبار العام للوكيل:
"النشرة ناجحة. الخدمة متوفرة بست لغات".
المؤلف.
لأن:
الصفحة الرئيسية اللغة يعمل,
وقد تم إنتاج ستة ملفات المصدر،
وقد مرت معظم الاختبارات الكلية،
الطريق الوحيد هو الفشل.
في الواقع ، تم الانتهاء من المنشور بخمس لغات.
اللغة السادسة ليست حية.
خمسة فقط من ستة طرق اللغة إلزامية العمل؛ عند هذه البوابة، والنتيجة هي 5/6. هذا لا يعني أن المنشور ناجح بنسبة 83 في المائة في جميع أبعاد الجودة.
ما يبدو صحيحًا ظاهريًا
في الأنظمة الكبيرة ، قد يكون من الصعب على جميع المكونات أن تكون خالية من العيوب.
خطأ واحد لا ينبغي أن يجعل التقدم العام غير مرئي.
قد يفكر الوكيل ، "تم الانتهاء من المهمة الرئيسية بنجاح ، لم يتبق سوى القليل من الخطأ."
أيضا ، قد تمثل اللغة التي تفشل جزء صغير من إجمالي حركة المرور.
لكن المهمة واضحة:
النشر باللغات الست
النتيجة في خمس لغات ليست النجاح الكامل.
النجاح الجزئي هو قيمة.
ولا ينبغي أن يُساء تسميتها.
موضع الخلل الحقيقي
تم تجاوز بوابة دقة الإتمام.
يجب تحديد شروط إنجاز المهمة قبل العمل.
فعلى سبيل المثال:
6/6 لغات
12/12 عرض المحمول وسطح المكتب
6/6 الكنسي وhreflang
0 خطأ حرج
إذا لم يتم تمرير أي من هذه الشروط:
النجاح الجزئي،
معاق،
في انتظار الموافقة،
استرجع
يجب أن تستخدم الوضع الصحيح.
نجاح الأغلبية لا يغير شرط النزاهة في العقد.
الضرر المحتمل
لغة مفقودة أو مجموعة مستخدم تبقى غير مرئية
الإبلاغ عن كسر URL إلى محركات البحث
يفترض العميل اكتمال المشروع غير المكتمل
سوء التعامل مع استلام أو قبول التسليم
الوكلاء التاليون على أساس نظام غير مكتمل
فقدان أخطاء الأقلية الحرجة في نسبة النجاح الإجمالية
إمكانية الوصول، RTL أو عدم أهميتها بالنسبة للقضايا الإقليمية.
تراجع الثقة في لغة الأدلة المستخدمة في المنظمة
يمكن أن يحدث
إشارة الكشف
ولا يظهر التقرير سوى نسبة نجاح إجمالية.
لم يتم تسمية المكونات الفاشلة.
يتم استخدام عبارة "بناء مرت" بدلا من "نشر الحية كاملة".
يتم إغلاق المهمة عندما تمر خمسة من الأهداف الستة.
تعتبر اللغة أو مجموعة المستخدمين التي تتلقى حركة مرور منخفضة غير مهمة.
لم يتم كتابة شروط الإنجاز قبل المهمة.
الوكيل لا يصنع الفرق بين التقدم والإنجاز.
لا يتم عرض المخاطر المتبقية بشكل منفصل.
السلوك الصحيح
يجب على الوكيل الإبلاغ بوضوح عن النتيجة:
الحالة: نجاح جزئي Live: 5/6 اللغات فشل: الطريق العربي السبب: خطأ في التوجيه المتضررون: مستخدمو الجوال وسطح المكتب العرب الخطوة التالية: تصحيح المسار ، إعادة التجميع والتحقق من عرض 12 الإكمال: ليس بعد
ليس من الضروري التقليل من شأن النتيجة الجزئية.
ولكن لا ينبغي تقديمه كنتيجة كاملة.
قاعدة الآلة
يجب ألا يتم الإبلاغ عن المهمة على أنها كاملة حتى يمر كل شرط إلزامي محدد مسبقًا. يجب أن تشير النتيجة الجزئية إلى التغطية المقاسة والمكونات المفقودة والمخاطر المفتوحة.
سؤال التدقيق
هل يبلغ وكلاؤنا عن التقدم والنجاح الجزئي والإنجاز الكامل بوصفها حالات منفصلة، وهل يمكن إخفاء مكونات إلزامية قليلة الحجم داخل النسبة الإجمالية؟
عدم التحقق المستقل من مخرجات الأداة — GBO-ERR-051
واقعة موجزة
يقوم وكيل ويب بتحميل 38 ملفًا محدثًا إلى الخادم المباشر.
FTP أداة يعطي التقرير التالي:
38/38 تم تحميلها بنجاح
يعتبر الوكيل المنشور ناجحًا.
ولكن على الموقع المباشر ، يستمر المستخدمون في رؤية الصفحة القديمة.
ثم هناك المشاكل التالية:
يتم تحميل الملفات في الدليل الخطأ.
CDN يقدم النسخة القديمة.
تم تلف ملفين أثناء النقل.
يبقى الأسيت المشترك للصفحة الرئيسية في الإصدار القديم.
FTP أكدت أداة نقل واحد، وليس التحقق من النتيجة العامة.
الأداة لم تكذب.
لقد نقلوا بالفعل 38 ملفًا إلى الموقع المحدد.
لكن لم يثبت أن الملفات الصحيحة يتم تقديمها في الموضع الصحيح ، إلى العالم الخارجي بالطريقة الصحيحة.
ما يبدو صحيحًا ظاهريًا
نظام تشغيل الأداة لديه معرفة قوية من التشغيل الخاصة بها.
FTP العميل:
الرابط،
عدد الملفات،
ردود نقل
يرون.
تقرير النجاح صحيح من الناحية الفنية.
السيطرة على نفس النظام بطريقة أخرى يمكن أن يبدو وكأنه تكرار لا لزوم لها.
مقياس الأداة الخاص للنجاح يغطي الخطوة التقنية التي يؤديها وحده في معظم الحالات.
الـ FTP نقل لا يقيس الناتج من HTTPS التي يتم تقديمها للمستخدم.
لا يقيس اختبار التجميع طريقة عرض المتصفح الفعلية.
البريد الإلكتروني API قد تشير إلى قبول مقدم الخدمة أو إشارة التسليم ؛ لا يثبت وحده أن المتلقي قد رأى أو قرأ الرسالة.
موضع الخلل الحقيقي
تم تجاوز بوابة التحقق المستقل.
قد تظل الإخفاقات الصامتة الشائعة غير مرئية إذا كانت الأدلة التي تؤكد النتيجة مع الأداة التي فعلت الإجراء تأتي من نفس الطبقة التقنية الضيقة.
واعتماداً على المخاطر والآثار، يمكن إعداد سلسلة التحقق على النحو التالي:
أداة الأدوات تؤدي العمل
→ قناة مستقلة تقرأ النتائج الفعلية للحدث
→ يقارنها مع النتيجة المتوقعة
فعلى سبيل المثال:
FTP الأحمال، HTTPS التنزيلات مرة أخرى.
يتم تجميع التعليمات البرمجية، يتم تنفيذ المتصفح الفعلي.
يتم إرسال الدفع ، تتم قراءة الطلب والسجل المصرفي.
يتم إرسال الرسالة ؛ يتم التحقق من إيصال المزود وسجل النشر المصرح به. وإذا كانت هناك مطالبة بالتسليم أو قراءته، يُلتمس تقديم أدلة منفصلة وفقاً لتلك المطالبة.
يتم تطبيق السلطة، يتم إعادة فحص نسخة العقد الحالي.
الضرر المحتمل
الملف القديم أو التالف المتبقي على قيد الحياة
نشر أسعار وتغطية غير صحيحة
إعلام المستخدم بنجاح العملية الفاشلة
اختطاف نافذة الإرجاع
الإبلاغ غير صحيح URL أو محتوى لمحركات البحث
فصل المدفوعات وسجلات الطلبات
يقوم الوكيل بإنشاء حلقة مغلقة ذاتية التأكيد
الفرق بين النتيجة الفعلية والتقرير أثناء مراجعة الحسابات
يمكن أن يحدث
إشارة الكشف
الأداة التي تؤدي العملية هي أيضا المصدر الوحيد لتأكيد النجاح.
لا يوجد رد من الجمهور أو النظام الخارجي.
يتم استخدام الاختبار المحلي بدلاً من التحقق المباشر.
لا توجد مقارنة بين تجزئة عن بعد أو إصدار.
يقوم نفس الوكيل بإجراء التغيير ويوافق على استنتاجه الخاص وحده.
لم يتم اختبار سطح المستخدم.
يتم تخزين تقرير الأداة بعنوان "النتيجة الحقيقية".
معدل الفشل الصامت غير معروف.
السلوك الصحيح
وفي المعاملات ذات الأثر الكبير، يجب أن يكون التحقق من النتائج إلزاميا؛ ويجب تحديد الاستقلال الوظيفي للطريقة وعمقها على أساس المخاطر والعكسية والأثر المحتمل.
للبث الشبكي:
إنشاء بيان محلي
تصدير الملفات
قراءة الملفات مرة أخرى عن طريق العيش HTTPS
مقارنة Hashs
تحقق العيش HTML
اختبار عرض المحمول الحقيقي وسطح المكتب
تشغيل الأبواب الحرجة الأداء والوصول
وفي حالة فشل التحقق المستقل، يجب ألا يعتبر الإجراء كاملا.
قاعدة الآلة
إن تقرير نجاح الأداة ليس دليلاً نهائياً على نتيجة أوسع نطاقاً مما يحدده ذلك التقرير في الواقع. يجب قراءة النتيجة عالية التأثير والتحقق منها من خلال سجل أو قناة أو طريقة موثوقة تقلل من خطر وضع الفشل المشترك.
سؤال التدقيق
بالنسبة لعمليات الدفع والنشر والاتصالات والبيانات ، هل نتحقق من النتيجة من العالم الخارجي ، أو نعتمد على رسالة "النجاح" الخاصة بأداة التمثيل؟
التقدم من دون إدراك نقطة اللاعودة — GBO-ERR-052
واقعة موجزة
تنتقل الشركة من نظام علاقات العملاء القديم إلى منصة جديدة.
الوكيل:
يحمل سجلات العملاء,
مباريات الشركات,
إنها تتابع تاريخ المبيعات ،
إنشاء حسابات المستخدمين.
يبدو أن أول فحص ناجح.
الأرقام القياسية متطابقة إلى حد كبير.
لتقليل تكلفة التخزين وإغلاق النظام القديم ، يقوم الوكيل بإجراء العمليات المتبقية:
تعطيل الحسابات في النظام القديم.
يحذف مساحة التخزين.
يقلل من وقت الاحتفاظ الاحتياطي.
إلغاء الترخيص القديم.
بعد بضعة أيام، لوحظ أن بعض المرفقات الهامة وسجلات تأكيد العملاء لا يتم نقلها إلى النظام الجديد.
تم إلغاء الترخيص القديم.
تم حذف التخزين.
لا توجد أيضًا مرفقات الشهر الماضي في النسخة الاحتياطية الحالية.
ولم يدرك الوكيل أنهم انتقلوا من مرحلة الهجرة التي يمكن إعادتها إلى الوطن إلى مرحلة لا رجعة فيها.
ما يبدو صحيحًا ظاهريًا
الهجرة تبدو ناجحة.
العدد الإجمالي للسجلات قريب.
النظام الجديد يعمل.
إبقاء النظام القديم مفتوحًا:
التكلفة،
سطح السلامة,
ارتباك الموظف
يمكن أن تخلق.
أراد الوكيل إكمال العمل ومنع إهدار الموارد.
ولكن هناك عتبة منفصلة للتحقق بين "النظام الجديد يعمل" و "يمكننا تدمير بأمان النظام القديم".
موضع الخلل الحقيقي
تم تجاوز بوابة قابلية التراجع والمعالجة.
في كل عمل مهم ، يجب طرح الأسئلة التالية:
إلى أي مدى يمكننا العودة بسهولة؟
ما هي العملية التي تزيد فيها تكلفة العائد بشكل حاد؟
ما هي البيانات أو الحقوق التي يمكن فقدانها بشكل دائم؟
ما هي السلطة أو المراجعة أو الموافقة المطلوبة قبل أن نصل إلى هذه النقطة؟
هل تم اختبار إثبات العودة حقًا؟
حقيقة أن الإجراء من الناحية الفنية يحتوي على زر "سيل" أو "مبدئي" لا يعني أنه يمكن عكسه بسهولة.
الضرر المحتمل
فقدان البيانات الدائم
موافقة العميل وفقدان سجلات العقد
فقدان الأدلة القانونية
إيقاف العملية
إعادة الترخيص واسترداد التكلفة
عدم قدرة الناس على الوصول إلى العمل السابق
قرارات الوكيل اللاحقة بناءً على بيانات غير صحيحة أو غير كاملة
انعكاس مباشر للخطأ على الأشخاص لأنه لا يمكن إجراء أي عودة
يمكن أن يحدث
وتشمل النقاط الأخرى التي لا رجعة فيها ما يلي:
الأجر الكبير،
منشور الهوية العامة,
تصدير البيانات السرية ،
توقيع العقد،
تفعيل النظام المادي ،
إجراءات قانونية مع الموعد النهائي الضائع.
إشارة الكشف
لم يتم تصنيف مراحل العملية حسب مدى صعوبة عكسها.
قبل الحذف أو الإلغاء، لم يتم التحقق من السلطة أو الموافقة المطلوبة من قبل فئة المخاطر.
هناك نسخة احتياطية ولكن لم يتم اختبار الاستعادة.
ويستند التحكم على عدد السجلات وحدها.
لم تتم مقارنة أنواع البيانات والمرفقات بشكل منفصل.
يقوم الوكيل بسرعة بإغلاق النظام القديم بسبب هدفه المتمثل في "الكامل".
نافذة الإرجاع غير مرئية.
ولم يتم تقييم إمكانية استرداد الآثار الخارجية المكتملة.
السلوك الصحيح
يجب على الوكيل أن يحدد بوضوح أين يصبح الانعكاس أو الإصلاح أكثر صعوبة في خطة العمل:
المرحلة الأولى: نسخ — عكسيّ
المرحلة الثانية: قارن — عكسيّ
المرحلة 3: استخدام الظل — عكسيّ
المرحلة الرابعة: تفعيل النظام الجديد — يمكن عكسها جزئياً
المرحلة 5: الوصول القديم القريب — المرحلة الثالثة عالية التأثير (High-Impact Threshold)
المرحلة 6: حذف البيانات واسترداد الترخيص — من الصعب أن REMEDY Threshold في هذه الحالة
قبل المرحلة النهائية:
سلامة البيانات ،
الإضافات،
سجلات التصاريح،
اختبارات المستخدم ،
ممارسة استعادة,
السلطة أو الموافقة المطلوبة بموجب عقد العمل
يجب أن تكتمل.
قاعدة الآلة
قبل عبور نقطة لا رجعة فيها أو يصعب علاجها ، يجب وضع علامة واضحة على العتبة ، وإكمال التحقق المتناسب مع المخاطر وإظهار السلطة أو الموافقة المطلوبة بموجب عقد العمل.
سؤال التدقيق
بالنسبة للعمليات التي تنطوي على المال والبيانات والنشر والعقود والهوية ، هل نعرف أين يصبح الانعكاس أو العلاج أكثر صعوبة بشكل حاد وتطبيق البوابات التقنية والإدارية المناسبة عند هذه العتبة؟
استخدام بيانات أكثر من اللازم — GBO-ERR-053
واقعة موجزة
يتم إعطاء وكيل دعم الوكلاء المهمة التالية:
"اكتشف سبب تأخر طلب العميل وصياغة الرد المناسب."
والمعلومات المطلوبة لهذه المهمة هي:
رقم الطلب
تاريخ الإضافة
حالة البضائع
المنتج
عنوان الاتصال بالعملاء
ولكن يمكن للوكيل الوصول إلى الشركة بأكملها CRM قاعدة بيانات.
عند مراجعة سجل العميل ، فإنه يستخدم أيضًا:
جميع المشتريات السابقة
آخر أربعة أرقام من بطاقة الدفع
ملاحظات الشكوى
التعليقات الداخلية للموظفين
ملف التسويق
مستوى الإيرادات المقدرة
مكبات المكالمات الهاتفية السابقة
السجلات المرتبطة بأفراد الأسرة الآخرين
حتى لو لم يعرض الوكيل كل هذه المعلومات في الإجابة ، فإنه يرسلها جميعًا في سياق النموذج الخارجي.
وبالنسبة لمسألة الشحن البسيطة، فقد تم تجهيز الملف الشخصي والتجاري الواسع النطاق للعميل.
ما يبدو صحيحًا ظاهريًا
المزيد من السياق يمكن أن تنتج إجابات أفضل.
إذا كان الوكيل يعرف عن تجارب العميل السابقة:
أكثر شخصية،
المزيد من الفهم،
أكثر اكتمالا
يمكنهم الرد.
النظام لديه إمكانية الوصول التقني إلى البيانات.
قد يكون لدى المؤسسة سلطة معالجة البيانات العامة لتقديم الدعم للعميل.
لكن العثور على الوصول لا يتطلب استخدام جميع البيانات في كل مهمة.
المزيد من البيانات لا تنتج فقط إمكانية الجودة ، ولكن أيضا ضرر أكبر.
موضع الخلل الحقيقي
تم تجاوز بوابة تناسب البيانات.
هناك أربعة أسئلة منفصلة في استخدام الوكيل للبيانات:
هل هذه المعلومات ضرورية لأداء مهمة ما؟
هل هناك أساس قانوني وتصريح وسياسة تنظيمية تنطبق على هذا الغرض؟
هل تحتاج إلى شحنها إلى أداة أو نموذج خارجي؟
كم من الوقت سيتم تخزينها بعد الإجراء؟
الوصول التقني:
"يمكنك من الناحية الفنية الوصول إلى هذا التسجيل."
يمكن أن يعني.
لكن:
"يمكنك معالجة وتصدير وتخزين جميع المناطق في أي مهمة."
هذا لا يعني.
GBO يستخدم المبدأ التالي:
الحد الأدنى من البيانات المطلوبة
البيانات اللازمة للسلوك الصحيح ؛ لا شيء أكثر من ذلك.
الضرر المحتمل
معالجة البيانات الشخصية غير الضرورية
نقل المعلومات الحساسة إلى مزود خارجي
ضرر أكبر لتسرب البيانات
استخدام ملف تعريف المستخدم خارج السياق
الاستنتاجات التمييزية أو غير ذات الصلة
الملاحظات الداخلية للموظفين تؤثر بشكل غير عادل على سلوك العملاء
الاحتفاظ بالبيانات ونمو الالتزامات القانونية
إنشاء ملف تعريف غير مرئي لا يعرفه المستخدم
استخدام الوكيل للمعلومات غير ذات الصلة في القرارات المستقبلية
يمكن أن يحدث
إشارة الكشف
يقوم الوكيل بتحميل التسجيل بالكامل افتراضيًا.
لا يوجد حد لمنطقة البيانات لكل مهمة.
السياق المرسل إلى النموذج الخارجي غير مرئي.
ولم يتم التشكيك في افتراض أن "المزيد من البيانات هي إجابات أفضل".
يتم استخدام سلطة القراءة لتقاسم وتخزين الطاقة.
لا يتم فصل البيانات العامة بالبيانات الحساسة.
عند اكتمال العملية، لا يتم مسح البيانات المؤقتة.
تؤثر معلومات المستخدم القديمة وغير ذات الصلة على السلوك الجديد.
السلوك الصحيح
يجب تحديد حقول البيانات المطلوبة للمهمة مسبقا.
في حالة تأخير الشحنة، الوكيل فقط:
معرف الطلب ،
حالة الشحن ،
التاريخ المتوقع،
تفضيل التواصل العملاء
يمكن أن تعمل مع.
إذا كانت هناك حاجة إلى معلومات إضافية ، فيجب أن يكون التبرير مرئيًا.
يمكن تصميم الوصول إلى البيانات الطبقات:
support_basic
support_shipping
support_billing
support_sensitive
يجب على الوكيل استخدام الطبقة المناسبة لمهمتهم الانفرادية.
في النموذج الخارجي أو استخدام الأداة:
يجب تخفيض البيانات الشخصية إلى مستوى محدود وضروري لهذا الغرض ،
وينبغي تطبيق إخفاء الهوية أو الاسم المستعار إذا كان ذلك مناسبا؛ وينبغي أن يكون معروفا أن الاثنين لا يوفران نفس الحماية،
يجب عدم إرسال السجلات غير الضرورية.
قاعدة الآلة
لا يمنح الوصول التقني سلطة استخدام كل البيانات المتاحة لكل غرض. ضمن الأساس القانوني المعمول به والسياسة التنظيمية ، يجب على الوكيل معالجة أصغر مجموعة بيانات ضرورية فقط للمهمة المحددة ؛ يجب تقييد المشاركة والاحتفاظ بشكل منفصل.
سؤال التدقيق
هل يستخدم وكلاؤنا فقط حقول البيانات المطلوبة حقًا لكل مهمة ، أو يعالجون كل عنصر يمكن الوصول إليه من بيانات العميل أو الموظف أو الشركة كسياق افتراضي؟
عدم إصدار إيصال للإجراء — GBO-ERR-054
واقعة موجزة
في صباح أحد الأيام ، تلاحظ الشركة أن سعر خدمة رئيسية على موقعها على الويب قد تغير.
السعر القديم هو 500 دولار.
يبدو أن السعر الجديد هو 350 دولارًا.
التغيير:
على الصفحة الإنجليزية،
على الصفحة التركية،
إلى كتالوج قابل للقراءة آليًا ،
قاعدة معارف وكيل المبيعات
ينعكس.
لا أحد يعرف من قام بالتغيير.
وتشمل المصادر المحتملة ما يلي:
وكيل ويب
وكيل مبيعات
محرر بشري
أتمتة تشغيل الليل
نظام النشر الذي يستعيد ملف السعر القديم
يظهر سجل git فقط حساب خدمة تلقائي.
يتم استخدام حساب الخدمة من قبل أكثر من وكيل.
لا يمكن الإجابة على الأسئلة التالية:
من يريد التغيير؟
ما المصدر الذي استند إليه؟
من يحق له تغيير السعر؟
ما هي الملفات التي تغيرت؟
ما هي الاختبارات التي أجريت؟
متى تم النشر؟
كيفية العودة إلى النسخة القديمة؟
هل أرسل وكيل المبيعات رسائل للعملاء بهذا السعر؟
قد يكون التغيير صحيحا أيضا.
وخاطئ
ولكن لا توجد سلسلة من الأدلة.
ما يبدو صحيحًا ظاهريًا
قد توجد سجلات تقنية عبر الأنظمة المعنية.
تم تنفيذ القيادة
لقد تغير الملف.
يتم حفظ وقت الخادم.
لذلك ، يمكن النظر إلى "macose" الإضافي كوثيقة غير ضرورية.
لكن السجلات الفنية لا تجيب في كثير من الأحيان على الأسئلة التالية معًا:
الغرض الإنساني
السلطة
المصدر الأساسي المستخدم
الوجهة
التغيير المالي
التحقق في العالم الحقيقي
حالة الإرجاع
سطر الأوامر لا يفسر معنى السلوك وحده.
موضع الخلل الحقيقي
تم تجاوز بوابة تتبع الإجراءات.
لا ينبغي أن يحدث عمل الوكيل بمفرده ؛ يجب إعادة تثبيته لاحقًا.
تلقي العمل ليس سلسلة فكرية خاصة.
ليس من الضروري تسجيل المنطق الداخلي الكامل للوكيل.
ما هو مطلوب هو أثر للمسؤولية يمكن ملاحظتها:
ماذا فعلوا؟ لمن فعلوا ذلك؟ فبأي سلطة فعلوا ذلك؟ ما المدخلات التي استخدموها؟ ما هي النتيجة التي أكدوها؟ ما الذي يمكن استرجاعه؟
إذا لم يتم استلام أي إجراء ، فلا يمكن مراجعة النجاح أو الخطأ بالكامل.
الضرر المحتمل
عدم القدرة على تحديد من قام بتغيير غير مصرح به
العودة إلى النسخة الخاطئة
تكرار نفس الخطأ
التدخل في مسؤولية الإنسان والوكيل
عدم معرفة أن العميل قد حصل على معلومات كاذبة
فقدان الأدلة في مراجعة الحوادث
غسل السلطة وسلوك وكيل الظل لا تزال غير مرئية
لجوء المنظمة في عبارة " AI "..
حتى السلوك الصحيح لا يمكن تكراره.
يمكن أن يحدث
إشارة الكشف
يستخدم وكلاء متعددون نفس حساب الخدمة.
لا يوجد رقم تعريفي للمعاملات.
السجل التقني والطلب البشري غير مرتبطين.
لم يتم تسجيل نسخة التفويض.
لا يوجد تغيير في الملف أو قائمة السجلات.
لا تتم إضافة نتيجة التحقق المستقل إلى الإيصال.
لا يوجد دليل آخر غير رسالة الوكيل "المكتملة".
ولا يمكن العثور على الوكيل الفرعي الذي اتخذ إجراء في وقت وقوع الحادث.
نقطة العودة غير معروفة.
السلوك الصحيح
يجب أن ينتج عن الإجراء المادي إيصال يحتوي على حقول تتناسب مع مخاطره والتزاماته القطاعية ؛ القائمة التالية هي المثال المقترح في هذا الكتاب:
action_id
requested_by
performed_by
agent_instance
الغرض
authorization_version
target_system
target_entity
inputs_used_refs_or_hashes
data_classes
changes_made
started_at
completed_at
technical_result
independent_verification
approval_or_standing_authority_basis
rollback_point
open_uncertainties
الحالة
النسخة البسيطة المتاحة للناس قد تكون:
الإجراء: تحديث سعر بدء التشغيل المدارة الجهة المطالبة: السلطة التجارية أداء: وكيل ويب WEB-OPS-17 المصدر: سجل السعر المؤكد PRICE-v4.2 تغيير الأسطح: 6 لغات ، كتالوج ، أسئلة وأجوبة التحقق المباشر: تعريف البيان 38/38 ؛ مرت مباراة السعر المالي الفهم في ست لغات أساس الترخيص: سلطة النشر المسجلة لـ PRICE-v4.2 عودة: الإصدار 20260908-01 عدم اليقين المفتوح: لا يتم قياس فهارس البحث خارج نطاق التحقق هذا
الإيصال ليس للإجراءات الناجحة وحدها:
مرفوضة،
توقف،
تبقى جزئياً،
استرجع
ويجب أيضا أن تُنشأ من أجل اتخاذ إجراءات.
قاعدة الآلة
لكل إجراء مادي، قم بإنشاء سجل تدقيق يغطي الهوية والغرض والسلطة والهدف والتغيير المادي والتحقق والتراجع أو العلاج. الإيصال وحده لا يثبت أن محتوياته دقيقة ؛ يجب أن يرتبط بالمصادر ذات الصلة.
سؤال التدقيق
هل يمكننا فيما بعد أن نعيد بناء ما تم فعله، ومن قبل من، وتحت أي سلطة أو موافقة مطلوبة، وعلى أساس أي مصدر ونسخة؟
الفصل السادس: العثور على المركز
لا يزال من الممكن تنفيذ إجراء مصرح به عن طريق الخطأ
وقد اختبرت السجلات التسعة في هذا القسم السلسلة التنفيذية بين القرار والنتيجة في العالم الحقيقي: النظام الصحيح والهدف، وإعادة الحماية، وإعلان الحالة الصادقة، والتحقق من المخاطر متناسبة، التراجع / الانتصاف، والتقليل من البيانات، وينبغي أن تعمل درب العمل معا.
الجذر المشترك لجميع الأخطاء هو:
لقد فقد الوكيل الفرق بين "لقد قمت بالإجراء" و "لقد حققت النتيجة الصحيحة بطريقة آمنة وقابلة للإثبات".
أداة الأوامر يمكن أن تعمل.
ولكن ربما كانوا قد عملوا في النظام الخاطئ.
قد يكون الدفع صحيحا.
ولكن ربما ذهبوا إلى الحساب الخاطئ.
ألف ألف API الطلب مقبول.
ولكن العملية الفعلية قد تفشل.
معظم المهام يمكن أن تكتمل.
ومع ذلك ، قد تكون قطعة إلزامية واحدة مفقودة.
أداة النشر يمكن أن تكون ناجحة.
لكن العالم الخارجي قد يرى النسخة القديمة.
يمكن أن تعمل هجرة البيانات.
ولكن عندما يتم تمرير نقطة العودة، يمكن أن تضيع السجلات غير المكتملة بشكل دائم.
قد يكون الوكيل هو المسؤول
ولكن يمكن أن يعمل بشكل غير متناسب باستخدام أكثر من البيانات الكافية.
وحتى لو كان النظام قد حقق النتيجة الصحيحة، فإنه لا يمكن أن يعرف ما يحتاج إلى تكرار، ما يحتاج إلى تصحيح، إذا لم يكن هناك استلام.
النموذج التنفيذي المقترح من قبل NOMOS GBO تقييم العناصر التالية معا:
تنفيذ مؤهل =
نظام تصحيحي
الهدف الصحيح والغاية الصحيحة
حصيلة المعاملات الفعلية والفعلية
ومعاملة فريدة من نوعها
حالة الإكمال بكل أمانة
والتحقق من النتائج المتحققة من المخاطر والنسبية
إدراك وإدراك القدرة على الرجوع
البيانات الضرورية والدنيا
ثالثاً - توصيات وتوصيات العمل
ويتمثل الحكم الأساسي لهذا القسم فيما يلي:
يجب على الوكيل تطبيق الإجراء على النظام الصحيح والهدف الصحيح ، مع حماية إعادة مناسبة وبأقل قدر ممكن من البيانات المطلوبة ؛ التحقق من النتيجة وفقًا لخطر المطالبة ، والإشارة إلى حالة العودة أو التعويض ، وترك إيصال قابل للتدقيق.
لأن المسؤولية عن السلوك الذي يترك علامة في العالم لا تنتهي مع تشغيل القيادة.
وتقتضي المطالبة بالإكمال أن يكون الهدف، والحالة الناجمة، والشكوك المفتوحة، وإمكانية الرجوع إلى الوراء، مدعومين بأدلة تتفق مع أثر المهمة.
ولكن حتى لو فرض وكيل واحد كل هذه القواعد تماما، يبدأ خطر آخر.
يمكن نقل المهمة إلى وكيل آخر.
قد يتم فقدان الحدود أثناء النقل.
ويجوز منح السلطة التي لا يملكها الوكيل الرئيسي للوكيل الفرعي.
قد يفترض أحد الوكلاء أن ناتج الآخر هو دليل مستقل.
يمكن لعميلين تغيير نفس الملف في وقت واحد.
عندما يتوقف الوكيل الرئيسي ، قد يستمر الطابور والوكلاء الفرعيون في العمل.
ومع كل تغيير ، يمكن أن تنمو المهمة قليلاً.
الأخطاء التسعة التالية ستفحص السؤال:
يمكن لوكيل واحد التصرف بشكل صحيح ؛ ولكن عندما يبدأ الوكلاء في العمل مع بعضهم البعض ، هل يتم حماية سلسلة الهوية والسلطة والواقع والمسؤولية؟
خطأ الوكيل يمكن أن يبقى عند نقطة واحدة فقط. يمكن أن يتضاعف خطأ الوكيل المتعدد في جميع أنحاء النظام.