ملخص

  • Hostifox ليست مجرد علامة استضافة فارغة. موقعها العام يقدم خدمات VDS، خوادم مخصصة، استضافة ويب، استضافة مشتركة (كولوكيشن)، خزانات، خدمات ASN وشبكات فرعية، بينما تسجل RIPE RDAP أن AS205733 نشط لصالح HOSTIFOX INTERNET VE BILISIM HIZMETLERI TICARET SANAYI LIMITED SIRKETI.
  • أقوى الحقائق التقنية ضيقة: رصدت RIPE Stat تسعة بادئات IPv4 /24 نشأت بواسطة AS205733 للفترة من أواخر يونيو إلى 13 يوليو 2026، وصفر مساحة IPv6 نشأت، ورؤية كاملة لـ RIS في الوقت المستعلم، وحالة مسار-أصل صالحة للبادئات المفحوصة.
  • تلك السجلات لا تثبت جودة الخدمة. فهي لا تؤسس لوقت التشغيل، أو الإنتاجية، أو عزل العملاء، أو ملكية الميل الأخير، أو أداء الاسترداد، أو عدد طاقم الدعم، أو ضوابط تغيير الحساب، أو ممارسة موقع البيانات، أو موثوقية كل حمل عمل مستضاف.
  • يجب تقييم الشركة من خلال سجلات متزامنة للخدمة والحساب والدعم والتوجيه والاسترداد: ما الذي تم طلبه، وأين يعمل، وما هي العناوين والمسارات ضمن النطاق، ومن يمكنه تغييرها، وكيف يتم الاعتراف بالحوادث، وكيف يخرج العميل دون عناوين أو نسخ احتياطية أو بيانات اعتماد عالقة.

اسم الاستضافة ليس سوى الباب الأمامي

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

الكيان المسجل هو الشركة التركية HOSTIFOX Internet ve Bilisim Hizmetleri Ticaret Sanayi Limited Sirketi. تقدمالصفحة الرئيسية العامةHostifox كمزود استضافة وخدمات خوادم وترتبط بعروض الاستضافة المشتركة، والخادم الافتراضي المخصص، والخادم المخصص، والاستضافة المشتركة، واستئجار الخزانات، وخدمة ASN، واستئجار الشبكات الفرعية. تقولصفحة من نحنإن الشركة تأسست في 2022 وتقدم الاسم الكامل للشركة وقنوات الاتصال والعنوان ومعلومات مكتب الضرائب. تشيرصفحة الاتصالالعملاء إلى البريد الإلكتروني وWhatsApp والهاتف وبوابة العملاء، مع توجيه الطلبات الفنية إلى البوابة.

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

لهذا السبب، فإن أدلة التوجيه مهمة، ولكن فقط في مسارها.سجل AS205733في RIPE RDAP يحدد تسجيل النظام الذاتي كنشط ويحدد اسم AS باسمAS-HOSTIFOX. نفس السجل يحمل المنظمة المسجلة وأدوار الاتصال/الإساءة، ويتضمن ملاحظات تصف الشركة كمزود استضافة بموجب قانون الاستضافة التركي، مع محتوى يتحكم فيه العميل على الخوادم المستضافة.سجل المنظمةيحدد المنظمة باسم HOSTIFOX INTERNET VE BILISIM HIZMETLERI TICARET SANAYI LIMITED SIRKETI ويعطي عنوانًا في بورصة وبريدًا إلكترونيًا للاتصال.

طبقة التوجيه مرئية أيضًا.عرض البادئات المعلنةفي RIPE Stat أعاد تسعة بادئات IPv4 /24 تم رصدها تحت AS205733 للفترة التي انتهت في 13 يوليو 2026.عرض حالة التوجيهأبلغ عن تسعة بادئات IPv4 نشأت، و2,304 عنوان IPv4، ولا بادئات IPv6 نشأت، ورؤية IPv4 عبر 325 من 325 من أقران RIS، وأول مسار شوهد في مارس 2018 وآخر مسار شوهد في 13 يوليو 2026. هذا دليل مادي على بصمة مستوى تحكم حية.

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

العرض العام واسع بما يكفي ليتطلب قبولًا دقيقًا

صفحات الخدمة في Hostifox تقدم وعدًا فئويًا واضحًا نسبيًا.صفحة الاستضافة المشتركة لنظام Linuxتسرد حزم استضافة مشتركة مع كميات النطاق وحركة المرور والقرص وقاعدة البيانات والبريد الإلكتروني، وSSL مدمج، وإدارة Plesk، والدعم.صفحة VDS المتميزةتسرد حزم خوادم افتراضية مبنية على Ryzen، ولغة التسليم التلقائي، وخيارات أنظمة التشغيل، ومعدلات المنفذ، وتحديد موقع خدمة النسخ الاحتياطي.صفحة الخوادم المخصصةتسرد حزم خوادم مادية مع نقاط السعر لوحدة المعالجة المركزية والذاكرة والقرص والمنفذ، بما في ذلك حالات النفاد لبعض الخطط.

صفحة استضافة الخوادمتنتقل من الحسابات المستضافة إلى البنية التحتية المادية. تصف التدخل عن بعد، وحركة مرور مخصصة، وادعاء شهادة Tier III، وبنية تحتية متكررة من مزودين، ولغة موقع Datacasa في إسطنبول، وخيارات 1U و2U وATX، وأرقام المنفذ وحركة المرور، ولغة التدخل على مدار الساعة.صفحة خدمة ASNتعد بدعم BGP، وإدارة العميل لجداول BGP، وحركة مرور مخصصة، وإعداد مركز بيانات Tier III، وبنية تحتية متكررة من مزودين.

هذا كافٍ لإظهار أن عرض Hostifox ليس منتجًا واحدًا. إنه يمتد عبر الاستضافة المشتركة، والخوادم الافتراضية، والأجهزة المخصصة، والاستضافة المشتركة، وخدمات أرقام الشبكة، وخدمات استئجار العناوين المجاورة. هذا الاتساع يزيد من أهمية انضباط حدود الخدمة. حساب الاستضافة المشتركة له أنماط فشل مختلفة عن VDS. الخادم المخصص له التزامات استرداد وأجهزة مختلفة عن فتحة الخزانة. خدمة ASN لها مخاطر تغيير توجيه مختلفة عن حساب استضافة Plesk. استئجار الشبكات الفرعية يغير المحادثة مرة أخرى، لأن العميل قد يصبح معتمدًا على تعيينات العناوين التي تظهر في جدران الحماية والشبكات الخاصة الافتراضية وقوائم السماح للشركاء والشهادات وأنظمة السمعة.

الصفحات تعطي بعض القابلية للمقارنة التجارية. تنشر أسماء الخطط والكميات ونقاط السعر للاستضافة المشتركة وVDS المتميزة والخوادم المخصصة، وتحدد تسعيرًا من نوع "مطلوب عرض سعر" للاستضافة المشتركة. كما تقدم ادعاءات بالراحة، خاصة التسليم التلقائي لخدمات VDS والاستضافة المشتركة بعد الدفع. يمكن للمشتري استخدام تلك الصفحات لتكوين تقدير أولي للتكلفة والنطاق.

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

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

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

سجلات الحساب والدعم هي جزء من المنتج

المهمة تسأل عما إذا كانت سجلات الخدمة والحساب والدعم والتوجيه والاسترداد تبقى حديثة وخاضعة للحوكمة وقابلة للإسناد والاستعلام والاسترداد تحت الاستخدام المتكرر. المواد العامة لـ Hostifox مفيدة بشكل غير عادي لهذا السؤال لأنها تكشف طبقة الحساب كسطح حقيقي، على الرغم من أنها لا تكشف النظام الداخلي.

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

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

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

عقد الخدمة يضيق وعد الدعم بطريقة يجب أن يلاحظها المشترون.PDF اتفاقية الخدمة، المؤرخة في 13 مارس 2024، تقول إن خدمة العملاء متاحة سبعة أيام في الأسبوع لمدة ثماني ساعات لمعظم الخدمات، وتصف نافذة الاستجابة من 11:00 إلى 19:00، وتقول إن التقارير خارج ساعات العمل تتلقى أولوية في فترة العمل التالية. كما تقول إن الفريق الفني قد يصل إلى الخادم بموافقة العميل وتتبعه في بعض الحالات. هذه الأحكام أكثر تحديدًا تشغيليًا من علامة "دعم 7/24" الواسعة، لكنها تظهر أيضًا لماذا تحتاج العلامات العامة إلى قراءة دقيقة.

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

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

AS205733 قابل للإسناد، لكن أدوار البادئات يجب ألا تُسوى

أفضل دليل تقني حول Hostifox هو سطح مستوى التحكم AS205733. سجلات RIPE RDAP الخاصة بالرقم الذاتي والمنظمة تربط AS205733 بالاسم القانوني لـ Hostifox. رصدت RIPE Stat تسعة بادئات IPv4 /24 نشأت بواسطة AS ولا IPv6. قوائم جرد BGP مثلbgp.toolsوIPinfoوأداة BGP من Hurricane Electricتحدد أيضًا AS205733 باعتباره Hostifox وتقدم شبكة تركية صغيرة مع عدة علاقات صاعدة أو نظيرة.

الاستنتاج المفيد ليس ببساطة "Hostifox لديها تسعة بادئات". إنه أكثر دقة: لاحظت مجمعات RIPE أن AS205733 ينشئ تسعة مسارات /24 في الوقت المستعلم، وكل زوج بادئة-أصل تم فحصه من خلال نقطة نهاية أصل المسار في RIPE أعاد حالة صالحة لـ AS205733. هذا دليل على أصل المسار والرؤية. إنه ليس نفسه القول إن كل بادئة مملوكة لـ Hostifox، أو مستخدمة لخدمات Hostifox الخاصة، أو موجودة في نفس المرفق، أو مخصصة لمنتج واحد.

أوصاف البادئات توضح هذه النقطة. في قوائم الجرد الثانوية، يتم وصف بعض البادئات بأنها Hostifox، بينما يتم وصف البعض الآخر بأنها Livaproxy أو Private Customer أو Meric Internet Teknolojileri أو Internet Utilities Europe and Asia. فحوصات RDAP التمهيدية تضيف المزيد من التفاصيل. سجل 31.56.213.0/24 يُسمى HOSTIFOX ويتضمن منظمة Hostifox كمسجل. سجل 45.94.171.0/24 يُسمى Hostifox ويتضمن منظمة Hostifox. سجلات 31.57.134.0/24 و45.8.172.0/24 تُسميان IPXO وتتضمنان Livaproxy كمسجل. سجلات 149.62.40.0/24 و163.5.168.0/24 تتضمنان أيضًا Livaproxy. سجلات 82.152.11.0/24 و96.62.114.0/24 تظهر أدوار عميل خاص. سجل 194.116.228.0/24 يشير إلى Meric Internet Teknolojileri.

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

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

هذا مهم تجاريًا. قابلية نقل العناوين هي واحدة من تكاليف التبديل الصامتة في الاستضافة. إذا قام العميل ببناء شبكات VPN وسجلات DNS وقوائم سماح الشركاء وسمعة البريد واستدعاءات API والمراقبة حول عناوين مخصصة من المزود، فقد تصبح الخدمة الشهرية الرخيصة مكلفة للمغادرة. أدلة البادئات المختلطة حول AS205733 لا تثبت الإغلاق، لكنها تظهر بالضبط أين يمكن أن ينشأ الإغلاق: في استحقاق العنوان، وسياسة الأصل، وDNS العكسي، وتاريخ الإساءة، والسمعة، وسحب المسار. يجب التفاوض على هذه قبل الاستخدام الإنتاجي.

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

صلاحية RPKI هي إشارة قوية بمهمة ضيقة

تفويض أصل المسار هو واحد من أكثر الإشارات الإيجابية وضوحًا في حزمة الأدلة. أعادت نقطة نهاية التحقق من صحة RPKI في RIPE حالة صالحة لـ AS205733 مع كل من البادئات /24 التسعة التي تم فحصها أثناء المرور، بما في ذلك31.56.213.0/24و45.94.171.0/24و82.152.11.0/24و96.62.114.0/24. هذا يعني أن مجموعات البادئة-الأصل المستعلم عنها كانت تحتوي على تفويضات أصل مسار متوافقة في العرض الذي أعادته نقطة النهاية.

الأهمية حقيقية. إذا أنشأ المزود مسار العميل، فإن حالة RPKI الصالحة تقلل من فئة واحدة من أخطاء مستوى التحكم. تعطي الشبكات التي تؤدي التحقق من صحة أصل المسار سببًا آليًا لقبول الأصل كمصرح به. كما تعطي العميل حقل مراقبة حاد: الأصل المتوقع، وطول البادئة المتوقع، وحالة التحقق من صحة أصل المسار الحالية، وآخر وقت فحص.

لكن RPKI تقوم بمهمة واحدة، وليس كل مهمة. يصفRFC 6483التحقق من صحة أصل المسار باستخدام تفويضات أصل المسار. تقارن المقارنة بادئة المسار المعلن و AS الأصلي مع البيانات المصرح بها. لا تتحقق من مسار AS الكامل. لا تقيس إمكانية الوصول أو زمن الوصول أو فقدان الحزمة أو الإنتاجية أو الازدحام أو مقاومة DDoS أو استجابة الدعم. لا تقول إن كل مزود صاعد يفرض التحقق من صحة أصل المسار. لا تثبت أن خادم العميل مهيأ بشكل صحيح.

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

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

بيانات الجار المرصودة هي إشارة محدودة أخرى.عرض جيران ASNفي RIPE Stat أعاد ستة جيران IPv4 لـ AS205733 في 13 يوليو 2026. قوائم جرد BGP تسمي العديد من الشبكات المحيطة، بما في ذلك Radore وStormWall وSatcore وEkiphost وغيرها حسب قائمة الجرد. هذا يدعم وجود علاقات توجيه خارجية أو مجاورة مسار في الملاحظات العامة. لا يحدد الدور التجاري لكل جار، أو سعة أي رابط، أو استقلالية المسارات المادية، أو تنوع الميل الأخير للعميل.

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

المحلية واعدة، لكنها تحتاج إلى إثبات على مستوى الحقل

قصة المحلية العامة لـ Hostifox لها عدة طبقات. السجلات القانونية والاتصالية تشير إلى تركيا. الموقع العام يعطي عنوانًا في بورصة. صفحة الاستضافة المشتركة واتفاقية الخدمة توجهان العملاء نحو إسطنبول وDatacasa لخدمات الخوادم. حافة DNS وTLS للموقع العام وبوابة العملاء تستخدم عناوين مواجهة من Cloudflare في الملاحظة العامة. سطح توجيه AS مسجل تحت اسم تركي ويُرى كـ AS تركي في قوائم جرد الشبكات. تلك الحقائق تدعم سياق تشغيل تركي.

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

اتفاقية الخدمة مفيدة لأنها تقول صراحة إن خدمات الخادم الفعلية والافتراضية يتم توفيرها من خوادم في إسطنبول/Datacasa اعتبارًا من 23 مارس 2024، باستثناء مواقع إضافية محددة، وتحذر من أن الموقع الجغرافي لـ IPv4 المعين قد يختلف عن موقع مركز البيانات. هذا تمييز ناضج. غالبًا ما يضلل الموقع الجغرافي للـ IP العملاء، والبلد الظاهري للمسار ليس هو نفسه المرفق الذي يعمل فيه حمل العمل. يجب على العميل الحفاظ على هذا التمييز بدلاً من استخدام عمليات البحث عن IP كدليل على سيادة البيانات.

الموقع العام يستخدم أيضًا خوادم أسماء Cloudflare لـhostifox.com.trفي ملاحظة DNS المباشرة، واسم مضيف بوابة العميل يحل من خلال بنية تحتية موجهة من Cloudflare. هذا عادي للحماية العامة للويب وتوصيل المحتوى، لكنه يعني أن إمكانية الوصول إلى الصفحة الرئيسية ليست اختبارًا لشبكة الوصول الخاصة بـ Hostifox أو خدمة مركز البيانات. يمكن أن يظل الموقع العام قابلاً للوصول من خلال مزود حافة أثناء حادث في مرفق Hostifox، ويمكن أن يظل المرفق سليمًا بينما يتعرض الموقع العام للتحدي أو يكون غير متاح لفحص سطر الأوامر.

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

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

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

النسخ الاحتياطي والاسترداد هما حيث تلتقي ادعاءات العلامة التجارية بمسؤولية العميل

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

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

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

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

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

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

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

الأتمتة مفيدة فقط إذا حافظت على قابلية التدقيق

صفحات Hostifox تستخدم لغة الأتمتة حول الإعداد السريع والتسليم التلقائي لـ VDS والاستضافة المشتركة وخدمة BGP المدارة من قبل العميل. الأتمتة جذابة تجاريًا لأنها يمكن أن تقلل وقت الانتظار والخطأ اليدوي. مزود صغير يؤتمت التوفير والفوترة وDNS وفحوصات المسار وحالة الدعم يمكن أن يقدم أسرع من مزود أكبر يوجه كل إجراء من خلال قوائم انتظار بطيئة.

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

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

بالنسبة للاستضافة المشتركة، هذا يعني أن عدد النطاقات وحركة المرور والقرص وقاعدة البيانات والبريد الإلكتروني وحالة SSL والوصول إلى لوحة التحكم يجب أن تطابق الخطة المشتراة. بالنسبة لـ VDS، يجب أن تطابق وحدة المعالجة المركزية والذاكرة والقرص والمنفذ ونظام التشغيل وخيار النسخ الاحتياطي والوصول الجذر الطلب وأدلة ما بعد التوفير. بالنسبة للخوادم المخصصة، يجب تسجيل جرد الأجهزة وحالة القرص والمنفذ والمرفق وحدود التدخل عن بعد ووقت التسليم. بالنسبة لخدمة ASN أو الشبكة الفرعية، يجب تسجيل كائنات المسار وRPKI وعوامل التصفية وDNS العكسي وجهة اتصال الإساءة.

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

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

الحالة التجارية تدور حول تكلفة التنسيق

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

السؤال الأفضل هو ما إذا كانت Hostifox تقلل تكلفة التنسيق للعميل لحد معين. بالنسبة لشركة تركية صغيرة تحتاج إلى استضافة مشتركة مع Plesk وقنوات دعم يمكن التنبؤ بها وفوترة محلية، قد يكون المزود المركز أسهل في التعامل من منصة سحابية عالمية. بالنسبة لعميل تقني يريد خوادم VDS أو مخصصة في إسطنبول مع خدمات متعلقة بـ BGP، قد يقدم مزود صغير مع AS205733 ونظافة أصل مسار مرئية أرضية وسطى مفيدة. بالنسبة لمؤسسة عالية الامتثال تحتاج إلى استرداد مدقق وإقامة صارمة للبيانات وتجاوز متعدد المواقع واتفاقيات مستوى خدمة رسمية، فإن المواد العامة ليست كافية.

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

يجب أن يميز نفس السجل بين التبعيات المباشرة وغير المباشرة. إذا كان الخادم في Datacasa، ما هي المهام التي هي مهام Hostifox وأيها مهام المرفق؟ إذا كان الموقع العام يستخدم Cloudflare، ما الذي تحميه Cloudflare وما الذي لا تحميه؟ إذا تم إنشاء بادئة بواسطة AS205733 لكنها مسجلة لعميل أو منظمة أخرى، من يتعامل مع الإساءة ومن يتحكم في DNS العكسي؟ إذا أدى حادث DDoS إلى تنشيط الثقب الأسود، من يوافق عليه وما هي نتيجة الخدمة المتوقعة؟

التخطيط للخروج ينتمي إلى الشراء، وليس الإلغاء. يجب أن يعرف العميل ما إذا كان يمكنه تصدير الموقع وقاعدة البيانات وصناديق البريد الإلكتروني ومناطق DNS وصورة VM وأرشيف النسخ الاحتياطي والفواتير والتذاكر والتكوين. يجب أن يعرف ما إذا كان يمكن الاحتفاظ بعناوين IP المخصصة من المزود أو توجيهها إلى مكان آخر أو استبدالها تدريجيًا أو سحبها فورًا. يجب أن يعرف كم من الوقت تبقى الخدمات قابلة للوصول بعد الإشعار وكيف تعمل الفوترة النهائية. بدون هذا، تبقى تكلفة التبديل مخفية حتى تكون الرافعة في أدنى مستوياتها.

ليست هناك حاجة لتضخيم المخاطر. السجلات العامة لـ Hostifox تظهر سطح شركة-خدمة-شبكة متماسك. AS نشط. ملاحظات المسار الحالية موجودة. التحقق من صحة أصل المسار إيجابي. الموقع ينشر كتالوجًا حقيقيًا بدلاً من صفحة هبوط فارغة. العقد يكشف الحدود التشغيلية التي يتركها العديد من المزودين غامضة. تلك إيجابيات ذات معنى. إنها ببساطة لا تحدد نتائج العملاء.

قائمة التحقق للقبول يجب أن تكون مدفوعة بالأدلة

يمكن للمشتري العملي تحويل الأدلة العامة إلى قائمة تحقق قبول مدمجة.

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

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

ثالثًا، التوجيه. لأي خدمة تعتمد على العنونة العامة أو BGP، يجب أن يشمل السجل البادئات المقصودة و AS الأصلي وحالة RPKI وعوامل التصفية والتبعيات الصاعدة وDNS العكسي وجهة اتصال الإساءة والمراقبة ومسار التغيير الطارئ. نظافة المسار العام لـ AS205733 مفيدة، لكن سجلات العميل يجب أن تكون محددة لخدمة العميل.

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

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

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

سابعًا، الخروج. يجب على العميل التمرن على ما يحدث إذا غادر: تصدير البيانات، ونقل VM أو الموقع، ونقل DNS، وإعادة ترقيم IP، وسحب المسار، وتنظيف ROA، وتغيير DNS العكسي، والفاتورة النهائية، وتصدير سجل الدعم، وإلغاء بيانات الاعتماد. تكلفة الخروج هي جزء من السعر.

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

الاستنتاج هو ثقة محدودة

يجب معاملة Hostifox كمزود استضافة وخدمات شبكية تركي صغير لكن مرئي مع كتالوج منتجات حي وسطح توجيه AS205733 قابل للإسناد. سجلاتها العامة تدعم خطًا أساسيًا تقنيًا ذا معنى: تسجيل RIPE نشط، ورؤية مسار IPv4 حديثة، ولا أصل IPv6 مرصود في حالة RIPE المفحوصة، وحالات أصل مسار صالحة لأزواج البادئة-الأصل المفحوصة لـ AS205733، وصفحات منتج عامة للاستضافة والخوادم والاستضافة المشتركة والخدمات المتعلقة بـ ASN.

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

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