نبذة عن Hypernyx
Hypernyx، أحد منتجات شركة Hirkania Technologies، هو حل ذكي للإنذار ضد السرقة قائم على إنترنت الأشياء. يتوفر المنتج بثلاثة نماذج تلائم احتياجات مختلفة، ويمكن استخدامه في المنازل والشركات والمؤسسات الكبيرة.
يتيح تطبيق Hypernyx للمستخدمين التحكم في أجهزة الإنذار عن بُعد. وخلف هذه التجربة البسيطة توجد منصة يجب أن تدير اتصالات الأجهزة وواجهات API وتدفقات الرسائل بأمان وموثوقية. وفي منتج مرتبط بالأمن، لا يمثل تعطل البنية التحتية مجرد خطأ تقني؛ بل يؤثر مباشرة في ثقة المستخدم وفي موثوقية المنتج نفسه.
التحدي: بنية تحتية لمنتج يجب أن يظل موثوقًا
لم تتعاقد Hypernyx مع Dropp Tempo لإنقاذ بيئة قديمة متعثرة. بدأت الشراكة منذ انطلاق المشروع، وكان التحدي الحقيقي هو تصميم البنية التحتية بصورة صحيحة قبل تراكم الدين التشغيلي.
شكلت ثلاثة متطلبات القرارات الهندسية منذ البداية: أمن التطبيق والبنية التحتية، والتوافر المستمر للخدمات الحساسة، والقدرة على دعم عدد متزايد من الأجهزة. كان على المنصة تحمل الأعطال المحدودة في أحد المكونات، وتوفير رؤية تشغيلية كافية للتشخيص السريع، وتجنب التكلفة والتعقيد غير الضروريين في الوقت نفسه.
وكان الأثر التجاري لهذه المتطلبات واضحًا أيضًا. فمع انضمام مزيد من الأجهزة إلى المنصة، كان من الممكن أن يؤدي ضعف تخطيط السعة أو المراقبة أو إجراءات التعافي المختبرة إلى إبطاء تطوير المنتج وإشغال فريق التطوير بالاستجابة التفاعلية للمشكلات بدلًا من بناء قدرات جديدة.
Audit: تحويل متطلبات الأعمال إلى قرارات للبنية التحتية
في المشاريع الجديدة بالكامل، لا تعني مرحلة Audit البحث عن أخطاء في بنية سابقة. قبل تقديم العرض، قيّمت Dropp Tempo متطلبات المنتج وحساسية الأمن والسعة المتوقعة واعتماديات الخدمات وسيناريوهات الفشل واحتياجات النسخ الاحتياطي والتعافي من الكوارث ومسار النمو المتوقع، ثم وثقتها.
لم تكن النتيجة قائمة بأسماء أدوات شائعة، بل مجموعة قرارات تتناسب مع مخاطر المشروع وميزانيته. كان لا بد أن يكون لكل مكون سبب تشغيلي واضح، وأن تكون تكلفة صيانته المستمرة مبررة. أتاح ذلك للفريق تطبيق التوافر العالي في الطبقات المهمة دون دفع Hypernyx مبكرًا نحو بنية Active–Active كاملة ومعقدة.
القرار الهندسي: توافر عالٍ دون إفراط في التعقيد
كانت بنية Active–Active واسعة النطاق أحد الخيارات التي دُرست. كان من الممكن أن ترفع مستوى الأتمتة، لكنها كانت ستضيف أيضًا تعقيدًا تشغيليًا أكبر وتكلفة أعلى للبنية التحتية ومخاطر سلوك غير متوقع أثناء حالات عدم الاستقرار. وبالنسبة إلى حجم المشروع وميزانيته الحالية، لم تكن هذه المقايضة مبررة.
توفر البنية المختارة طبقات من الازدواجية في واجهات API ومنصة إنترنت الأشياء ورسائل MQTT وقواعد البيانات. ويحد نسخ البيانات والنسخ الاحتياطي المنتظم من مخاطر فقدان المعلومات. أما التبديل عند الفشل فيتم بصورة خاضعة للتحكم: تصل التنبيهات إلى الفريق، ويقيّم قائد الحادث الوضع قبل اتخاذ قرار التحويل.
لا تعني نقطة القرار اليدوية غياب التوافر العالي؛ بل هي إجراء مقصود لمنع التحويلات المتكررة أثناء الأعطال المتقطعة. لذلك لا نصف النظام بأنه يملك تحويلًا تلقائيًا كاملًا عند الفشل أو انعدامًا مضمونًا للتوقف. ما تم تنفيذه هو ازدواجية متعددة الطبقات مع مسار تعافٍ خاضع للتحكم.
Build: بنية تحتية لواجهات API وإنترنت الأشياء وMQTT
أُنجزت البنية التحتية الأولية خلال نحو شهرين، ثم استمرت في التطور بالتوازي مع المنتج. صممت Dropp Tempo البيئات المطلوبة ومسار النشر وطبقة اتصالات MQTT ونسخ البيانات وضوابط الوصول والمراقبة وإجراءات النسخ الاحتياطي باعتبارها أجزاء من نظام تشغيلي واحد، لا مهامًا منفصلة.
لا ننشر تفاصيل الوسيط أو QoS أو إدارة الجلسات أو الهيكل الداخلي لأسباب أمنية. وعلى المستوى المسموح بالإفصاح عنه، صُممت البنية بحيث لا يؤدي فقدان خدمة مصغرة واحدة أو مكون محدود بالضرورة إلى توقف المنصة بالكامل. وقد بقيت الأحداث التشغيلية عمومًا ضمن نطاق تراجع جزئي في مستوى الخدمة أو تعطل مكون واحد.
تشير الحسابات المبنية على الاستخدام الفعلي للموارد عند الحمل الحالي إلى وجود هامش يدعم استمرار نمو عدد الأجهزة. لكن لعدم تنفيذ اختبار حمل رسمي، لا نقدم هذا التقييم باعتباره معدل معالجة مثبتًا أو سعة مضمونة. والنتيجة التي يمكن الدفاع عنها هي أن البيئة صُممت منذ البداية مع مراعاة النمو المستقبلي، وتخضع للمراقبة المستمرة مع تغير الطلب.
يوضّح هذا المخطط المسار العام لتدفق الرسائل: من الأجهزة المتصلة، عبر مدخل آمن، عبر المراسلة بواسطة MQTT، وصولًا إلى خدمات API وطبقة البيانات. تُطبَّق المراقبة (Observability) والضوابط الأمنية والنسخ الاحتياطي/التعافي من الكوارث كطبقات عرضية على جميع هذه المكونات؛ لم يتم الإفصاح عن تفاصيل البروتوكول والبنية الداخلية لأسباب أمنية.
الأمن من التصميم إلى التشغيل اليومي
لم يكن الأمن في Hypernyx نقطة فحص نهائية قبل الإطلاق. فقد أُدمجت الضوابط الأمنية في تصميم الشبكة والوصول الإداري وخط التسليم والعمليات اليومية.
يُطبق تقسيم الشبكة باستخدام pfSense، وتُقيد المنافذ ومسارات الوصول بما تتطلبه العمليات فقط. ويمر الوصول الإداري إلى الخوادم عبر Teleport مع المصادقة الثنائية. وتحمي TLS الاتصالات الحساسة، فيما تشكل RBAC وإدارة الأسرار وتقوية الأنظمة وإدارة التحديثات وسجلات التدقيق أجزاء من نموذج تشغيل البنية التحتية.
وفي سلسلة تسليم البرمجيات، تُفحص صور الحاويات باستخدام Trivy ويُحلل الكود عبر SonarQube. لا نقدم هذه الضوابط باعتبارها ادعاءً بالأمن المطلق؛ بل تهدف إلى تقليص سطح الهجوم وضبط الوصول ذي الامتيازات واكتشاف المخاطر مبكرًا وجعل تحسين الأمن عملية قابلة للتكرار.
CI/CD والبنية التحتية ككود
يجب ألا تعتمد البنية التحتية ونشر الخدمات على ذاكرة الأفراد أو مجموعة أوامر يدوية. تدير Dropp Tempo البيئة من خلال Infrastructure as Code، وطبقت مسارات CI/CD متكاملة مع نشر آلي لخدمات المشروع.
تُنفذ الإصدارات بصورة منتظمة، ويتوفر للفريق مسار سريع للتراجع عندما لا يعمل أحد الإصدارات كما هو متوقع. ولا نقدم معدل النشر الدقيق أو زمن التراجع كمؤشرات أداء في هذه الدراسة، لأن الأرقام المتاحة تقديرات تشغيلية وليست تقارير مجمعة من مسارات النشر.
كما تتبع إضافة أي خدمة جديدة عملية واضحة: تُراجع المتطلبات، ويُقدر الوقت والتكلفة، وبعد الموافقة تُجهز البنية التحتية باستخدام IaC وتدخل الخدمة إلى البيئة عبر مسار النشر القياسي. يحافظ ذلك على نمو المنتج دون الإخلال بإيقاع العمليات.
قابلية الرصد: من لوحات المتابعة إلى الاستجابة التشغيلية
لا تقتصر قابلية الرصد على تثبيت لوحات متابعة. تراقب بيئة Hypernyx الخوادم والموارد وواجهات API ونقاط النهاية الأساسية وقواعد البيانات وعمليات النسخ وطبقة الرسائل واتصالات الأجهزة والشهادات ونجاح عمليات النسخ الاحتياطي.
يفحص Uptime Kuma توافر نقاط النهاية الأساسية من خارج المنصة. وتصل التنبيهات إلى فريق Dropp Tempo عبر البريد الإلكتروني وRocket.Chat، بينما يتلقى العميل التنبيهات ذات الصلة في Mattermost. يضمن هذا المسار متعدد القنوات ألا يبقى التنبيه داخل لوحة متابعة، بل يصل إلى الأشخاص المسؤولين عن التعامل معه.
في إحدى الحالات، خرجت الخدمة المسؤولة عن إرسال الإشعارات من الخدمة. كشفت المراقبة اللحظية التعطل، وأعاد الفريق تشغيل الخدمة قبل أن يتطور الأمر إلى توقف واسع للمنصة. لا ندعي رقمًا محددًا لمتوسط زمن الإصلاح في هذه الحالة، لكنها توضح كيف رُبطت قابلية الرصد بالاستجابة التشغيلية.
نسخ احتياطي وتعافٍ من الكوارث قابلان للاختبار
لا يثبت وجود ملفات النسخ الاحتياطي وحده أن النظام قابل للاستعادة. وإلى جانب النسخ الاحتياطي المنتظم، تختبر Dropp Tempo دوريًا استعادة البيانات وسيناريو التعافي من الكوارث.
كما أُجريت اختبارات للفشل والاستعادة والتعافي من الكوارث والأمن والتراجع بعد الإطلاق التشغيلي. وحققت الاختبارات الخاضعة للتحكم هدف RTO البالغ ٣٠ دقيقة وهدف RPO البالغ ساعة واحدة. تمثل هذه القيم نتائج اختبارات وليست وعدًا مطلقًا لكل حادث محتمل، لكنها تثبت أن مسار التعافي موجود خارج نطاق الوثائق النظرية.
ما وراء منصة المنتج: البنية التشغيلية لشركة Hirkania Technologies
لا يقتصر نطاق عمل Dropp Tempo على الخدمات التي يستخدمها منتج Hypernyx مباشرة. تعتمد Hirkania Technologies أيضًا على منصات داخلية لعملها اليومي، من بينها GitLab وNextcloud وn8n وBaserow وOutline.
تتولى Dropp Tempo نشر البنية التحتية لهذه الخدمات وصيانتها أيضًا. يمنع هذا النطاق الأوسع منصة المنتج والأدوات المؤسسية من التحول إلى جزر تشغيلية منفصلة، ويوحد الأمن والنسخ الاحتياطي والمراقبة وملكية الاستجابة للحوادث ضمن نموذج تشغيلي متسق.
النتائج التقنية
- تضم المنصة أكثر من ١٬٠٠٠ جهاز نشط واختباري.
- سجلت نقاط النهاية الأساسية معدل توافر يتجاوز ٩٩٫٩٪.
- طُبقت الازدواجية عبر واجهات API ومنصة إنترنت الأشياء ورسائل MQTT وقواعد البيانات.
- تحقق RTO قدره ٣٠ دقيقة وRPO قدره ساعة واحدة في اختبارات ما بعد الإطلاق.
- جعلت CI/CD الآلية والبنية التحتية ككود تجهيز البنية التحتية ونشر الخدمات قابلين للتكرار.
- تغطي المراقبة متعددة الطبقات نقاط النهاية وواجهات API ونسخ البيانات والرسائل واتصالات الأجهزة والنسخ الاحتياطي.
- تمثل اختبارات الاستعادة والتعافي من الكوارث جزءًا من العمليات المستمرة.
- ظلت الأحداث عمومًا محدودة في تراجع جزئي للخدمة، ولم يُسجل حادث كبير شمل المنصة بأكملها.
الأثر التجاري
امتلكت Hypernyx منذ بداية تطوير المنتج فريقًا واضح المسؤولية عن البنية التحتية؛ ليس فريقًا سلم البيئة الأولية ثم انسحب، بل فريقًا احتفظ بمسؤولية المراقبة والأمن والنشر والاستجابة للحوادث والتعافي.
يسمح هذا النموذج التشغيلي لفريق المنتج بإضافة الخدمات والقدرات عبر مسار موحد. كما أن تخطيط السعة للنمو والدعم على مدار الساعة بزمن استجابة يقل عن ٣٠ دقيقة واحتواء الأعطال الجزئية كلها عوامل تقلل المخاطر التشغيلية لمنتج يعتمد مستخدموه على توافره.
لا ننسب إلى هذا المشروع أرقامًا غير مثبتة تتعلق بخفض التكلفة أو زيادة الإيرادات. الأثر التجاري الذي يمكن الدفاع عنه هو إنشاء قاعدة تشغيلية آمنة وقابلة للرصد والدعم لإطلاق المنتج وتنميته.
Retain: خمس سنوات من المسؤولية المستمرة
بدأت الشراكة بين Dropp وHirkania Technologies في عام ٢٠٢١. وانتقلت من تقييم المتطلبات وتصميم البنية التحتية إلى مواكبة تطوير المنتج واختباره، واستمرت بعد دخول المنصة إلى التشغيل الفعلي.
يشارك فريق DevOps في Dropp Tempo اليوم بصورة جماعية في دعم Hypernyx. وتستمر المراقبة وتجميع السجلات والتنبيه والاستجابة للحوادث والنسخ الاحتياطي والتعافي من الكوارث والأمن ونشر الخدمات الجديدة بوصفها مسؤوليات دائمة. يتوفر الدعم على مدار الساعة، بزمن استجابة محدد يقل عن ٣٠ دقيقة.
هذه هي مرحلة Retain في نموذج Dropp Tempo: يظل الفريق الذي يفهم أسباب القرارات المعمارية مسؤولًا عن صحة البنية اليومية وتطورها المستمر. والنتيجة بنية تحتية تنمو مع المنتج دون أن تحول كل إصدار إلى حالة طوارئ؛ وهذا هو المقصود بشعار Dropp Tempo: “ship in rhythm, not in panic.”
يجب أن تكون بنية إنترنت الأشياء جزءًا من الثقة بالمنتج
في المنتجات المتصلة والحساسة أمنيًا، تمثل البنية التحتية طبقة غير مرئية لكنها حاسمة في تجربة المستخدم. يجب أن تتحمل الأعطال المحدودة وتضبط الوصول وتجعل صحة الخدمة قابلة للرؤية وتوفر مسارًا مختبرًا للتعافي.
يبين مشروع Hypernyx أن التوافر العالي لا يتطلب دائمًا أعقد بنية أو أتمتة كاملة. التصميم الصحيح هو ما يتناسب مع مخاطر المؤسسة وميزانيتها وسعتها وقدراتها التشغيلية، وتدعمه جهة تظل مسؤولة عنه باستمرار.
إذا كنتم تبنون أو تعيدون تصميم البنية التحتية لمنصة إنترنت أشياء أو خدمة قائمة على MQTT أو منتج حساس، يمكن لـDropp Tempo أن تبدأ بمراجعة للمعمارية والموثوقية، ثم تواصل معكم خلال التصميم والتنفيذ والتشغيل المستمر.
اطلبوا مراجعة لمعمارية وموثوقية البنية التحتية لإنترنت الأشياء