انتقل إلى المحتوى
مُعتز مصطفى

ملف المشروع

Cervello Cloud: منصة IoT

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

وقد كانت موجودة بالفعل كمنتج on-premises، أي مثبّت داخل مركز بيانات العميل نفسه. وعملي كان على النسخة السحابية: المنصة نفسها، متعددة المستأجرين، يُوصل إليها من أي مكان.

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

3 الفصل

دوري

مساهم فردي (Individual Contributor)، من الصفر حتى التسليم. بدأت هذا المشروع وحدي وحملته إلى آخره: البحث، ومعمار المعلومات، ومسارات المستخدم، والوايرفريمز، وتصميم الواجهات، ونظام التصميم، والتسليم للمطورين.

وانضم مصمم ثانٍ لاحقًا وعمل على الواجهات. ولا يُعرض شيء من عمله هنا؛ فكل ما في هذا الملف عملي أنا.

الفصل 01· الفصل الأول · من On-Premises إلى السحابة

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

البرمجيات الـ on-premises تعمل على أجهزة العميل نفسه، داخل مبناه. وهذه الحقيقة الواحدة تقرر تقريبًا كل شيء عن سلوكها. لا يوجد تسجيل، لأنه لا يوجد غريب. فقد اشترى أحدهم البرنامج وثبته، وكل من يستخدمه ينتمي إليه أصلًا. ولا توجد تجربة مجانية، لأنك لا تجرّب شيئًا يجب تثبيته أولًا. ولا توجد فوترة داخل المنتج، لأن المال تولاه عقد قبل أن يفتح أحد شاشة. ولا يوجد سؤال حقيقي عمن يرى ماذا، لأن الجميع في المبنى يعملون في الشركة نفسها. والانتقال إلى السحابة يُزيل هذه الافتراضات جميعًا دفعةً واحدة. فمشكلة التصميم لم تكن يومًا «ضعه على خادم»، بل: من هذا الشخص؟ وماذا يحق له أن يرى؟ ومن يدفع مقابل ما يستهلكه؟ وقيد واحد جعل الأمر أصعب: البنية القائمة كان يجب أن تنجو. فالعملاء الذين يشغلون Cervello محليًا يعرفون كيف نُظّم. ونسخة سحابية تُعيد ترتيب كل شيء كانت ستصبح منتجًا آخر يحمل الاسم نفسه.

القرار

تجربة مجانية، وـ instance تملكه

وحدة المنتج السحابي صارت الـ instance، مساحة العميل الخاصة، يُوصل إليها عبر نطاق فرعي يسميه هو بنفسه، فيدخل مباشرة إلى بيئته لا إلى باب عام. ومعها تجربة مجانية لمدة أربعة عشر يومًا. وهذا القرار وحده هو ما يفتح المنتج لسوق كان مضطرًا للالتزام قبل أن يرى شيئًا. وقاعدة الملكية تحتها متعمدة: يمكنك أن تنضم إلى instances كثيرة، لكنك لا تملك إلا واحدة. وهذه القاعدة هي ما يجعل كل ما عداها قابلًا للحل. فالانضمام هو كيف تعمل داخل مساحات غيرك: مهندس لدى مُدمِج يعمل داخل بيئة عميل. والملكية هي ما تدفع مقابله. وإبقاء الملكية واحدة يجعل الفوترة وحدود الموارد والتجربة المجانية ترتبط كلها بشيء لا لبس فيه. ومن يأتي برابط دعوة يُوجّه ليختار أي ـ instance يدخل، ومن لا دعوة لديه فهو يُنشئ مساحته هو. وأول إعداد يتم تلقائيًا. فإنشاء الـ instance يُنشئ معه أول organisation وأول team، ويجعل المستخدم جاهزًا للعمل في ثوانٍ، بدل أن يُطلب من مستخدم جديد أن يبني هرمًا فارغًا قبل أن يفعل أي شيء. فالبنية موجودة لأن المنتج يحتاجها؛ وليس على المستخدم أن يبنيها بيده ليبدأ.

القرار

تسجيل يرفض أن يؤكد من هو موجود

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

القرار

إعادة البيع، دون إعادة بناء في كل مرة

يبني المُدمِج حل smart parking مرة واحدة، ثم يبيعه لأربع مدن. وعلى الـ on-premises كان ذلك أربع عمليات تركيب. يشتري المنصة، ويثبّتها داخل مبنى العميل، ثم يعيد بناء الحل فوقها. فالحل يبقى حيث رُكّب، كما يصير مشروع مفتوح المصدر تطبيقًا واحدًا على سطح مكتب واحد لا يغادره. والحل الذي أراده الجميع كان marketplace. اقترحه مدير المنتج، وعُرض على فريق التطوير، وعاد أكبر من أن يُبنى في الوقت المتاح. فنزل بدلًا منه ما هو أصغر ويؤدي العمل نفسه. duplicate ثم transfer. وموضع النسخ هو كل الحكاية. العميل نفسه ينشئ حسابه، ويفتح رابط الـ instance، ويأخذ منه نسخة، فتكون النسخة ملكه من اللحظة الأولى. ثم ينضم مهندسو المُدمِج إلى تلك الـ instance ليضيفوا الـ integration وما يحتاجه موقع ذلك العميل. ولا أحد يسلّم ملكية بعد وقوعها، لأنها لم تقع في المكان الخطأ أصلًا. وهذا ما يُبقي القاعدة فوقه سليمة. تملك instance واحدة، وتنضم إلى كثير. فتظل الفوترة وحدود الموارد والتجربة المجانية معلقة بشيء له مالك واحد، وتكفّ إعادة البيع عن أن تكون إعادة بناء. ولم يكن الـ marketplace قد بُني بعد حين تركت الشركة.

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

اقرأ المزيد
الفصل 02· الفصل الثاني · معمار الصلاحيات

بناء بنية تتيح للمُدمِج أن يدير عملاء كثيرين وفرقًا كثيرة ومشاريع كثيرة داخل منصة واحدة، مع ضمان ألا يرى أحد ما لا يحق له، وأن يجد الجميع من يحتاجون العمل معهم.

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

القرار

أربع طبقات متداخلة

ما وجدته كان مسطحًا. أجهزة تقع داخل organisation، وهذا كل ما في الأمر. ولم يكن أحد يسمي أيًا منهما طبقة. والفريق كان يعرف بالفعل ما سيحتاجه المطور الذي يبني فوقهم. جهاز داخل جهاز. جهاز موصول بجهاز آخر. وما لم يكونوا يرونه هو كيف يُعبّر عن ذلك. فمهندس المعمار كان يملك الفكرة ويكتب الكود، لكن كل اسم في مفرداته thing أو sensor، وأي منهما لا يخبرك بما يجوز أن يحتوي ماذا. وهذه ليست مفردات يستطيع رجل أعمال استخدامها، ولا يستطيعها أحد من خارج الـ IoT. أخذت البُعدين وجعلتهما ثلاثة. Instance ← Organisation ← Team ← Project. الـ organisation كانت موجودة. أضفت الـ instance فوقها والـ team داخلها، وتحتها جميعًا طريقة لتجميع الأجهزة لم تكن موجودة إطلاقًا. وكل طبقة تجيب عن سؤال مختلف: ولكل طبقة صفحة رئيسة خاصة بها، تعرض ما هو جارٍ عند ذلك المستوى، أحدث المشاريع والفرق والأعضاء مرتّبين بالنشاط. فالبنية لا تنفع إلا إذا كان كل مستوى يجيب عن سؤال «ماذا يحدث هنا؟» دون أن يضطر أحد للصعود أو النزول ليعرف. وصفحة الـ team تعرض مشاريعه قابلة للترتيب بالاسم أو بالنشاط أو بسعة الأجهزة، وتبويب ثانٍ يعرض أعضاءه، فتُدار الصلاحيات والنشاط في المكان نفسه الذي فيه العمل، لا في لوحة إدارة منفصلة.

القرار

مشكلة الرؤية، مصوغة بوضوح

من أحدّ ما خرج من البحث، وجاء على لسان مسؤول: وهنا الصعوبة الحقيقية في الصلاحيات المتداخلة. فالتقييد سهل البناء وسهل المبالغة فيه. وإذا أقفلت كل شيء، تتحول البنية إلى قفص: يعجز الناس عن أداء العمل الذي وُجدت أدوارهم من أجله. لذلك جُعلت رؤية الأعضاء محدودة بالطبقة التي أنت مسؤول عنها. فقائمة أعضاء الـ instance كاملة لا يراها إلا مالكه أو مسؤوله. @@MOVED@@ وأعضاء الـ organisation يُرون عند مستواها. وأعضاء الـ team داخل الـ team. أي أن كل مسؤول يرى بالضبط الفئة التي يحق له أن يتصرف فيها. لا أكثر، والأهم لا أقل. وملف العضو يعرضه عبر الـ instance كله: الفرق والمشاريع التي يشارك فيها، ونشاطه الأخير. وهذا هو حل مشكلة التصادم. عدة أشخاص يعملون في المساحة نفسها دون معرفة من فعل ماذا. فالنشاط ليس سجلاً مدفونًا في الإعدادات؛ بل مرتبط بالشخص وبالطبقة.

القرار

الأصول، ونوعان من العلاقة

تحت بنية الصلاحيات تقع بنية ثانية، للعالم المادي. وحين وصلت لم يكن هناك سوى أجهزة. والكلمة نفسها كانت أول المشكلة. فهذا Internet of Things، والـ thing ليس دائمًا شيئًا واحدًا. الحساس الذي يرسل ويستقبل بنفسه هو device، وهو نهاية الخط. وكثير من الحساسات لا تتكلم إطلاقًا. تقرأ، أو تسجل، ويحتاج غيرها أن يحملها إلى المنصة. وذلك الغير يحمل تحته غيره، وتسميته device تقول عكس ما هو. فدخل إلى النموذج مفهوم الأصول (assets). الـ device هو الحساس الذي يتكلم عن نفسه. والـ asset هو العقدة التي تحمل من لا يستطيع. واللمبة الذكية تجعلها ملموسة. بعض اللمبات يكون الراديو داخلها. وبعضها يكون الراديو في الدواية، فأي لمبة تركّبها تبدأ في الإبلاغ. والفرق يظهر عند العطل: إن كان الراديو في اللمبة، فاللمبة التالفة تأخذ الإبلاغ معها. وللهرم نوعان من الروابط: belongs وrelates. الـ belongs يورّث. والـ relates أخوّة. وإنارة الشوارع أوضح حالة مرت بي. العمود يحمل إنارة صباحية وإنارة مسائية، وكلتاهما belongs للعمود. والعمود الأول والعمود الثاني ينوران معًا، فهما relates. وقد تقع كل أعمدة الشارع تحت متحكم واحد، وذلك المتحكم asset. والتشجير حر في كل اتجاه: device بجوار asset، وasset بجوار asset، وdevice بجوار device. ونموذج أب-وابن وحيد كان سيجبر المستخدمين على الكذب على بنيتهم التحتية لتناسب الشكل الذي يتوقعه البرنامج، وكان المطور سيذهب ليبني workaround. ومنصة تنوي أن تحمل كل vertical يُبنى فوقها لا يصح أن تجعل ذلك مشكلة المطور. والمبدأ نفسه يمتد إلى المراقبة: الإنذارات والأحداث تُعرض على خريطة حسب الموقع، مع درجة الخطورة، مجمّعة حسب الوحدات، لأن السؤال الذي يطرحه المشغّل ليس أبدًا «أي رقم جهاز أخفق؟» بل «ما الخلل، وأين، وما مداه؟»

النتيجة · البنية أُطلقت، وهي ما تعمل عليه المنصة في الإنتاج اليوم. وبعد خمس سنين ما زالت هي النموذج، وأنا من رسمها. والذي يمكن ادعاؤه هو المعمار نفسه: أربع طبقات متداخلة برؤية محدودة عند كل منها، ونموذج نشاط يجيب عن من-فعل-ماذا داخل مساحة مشتركة، وهرم أصول يعترف بأن البنية التحتية لا تتخذ دائمًا شكل شجرة نظيفة. الفصل التالي: المنهج، والمبادئ، ونظام التصميم، والـ Feature Catalogue.

اقرأ المزيد
Cervello Cloud: منصة IoT