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