ابنِ لليوم. خطّط للغد. خطّط للفشل.

🌐 متاح أيضًا بـ28 لغة

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 5 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: المعمارية هي فن المفاضلة · التالي: اعرف أدواتك: الأسئلة التسعة

السؤال الذي تجيب عنه هذه الوحدة: كيف تصمم لمتطلبات اليوم وأنت تخطط للنمو وللفشل؟

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

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

ابنِ لليوم. خطّط للغد. خطّط للفشل.

تحتاج إلى الثلاث كلها.

Click to enlarge

ابنِ لليوم

تبدأ المعمارية بالمشكلة التي لدينا فعلًا. يبدو هذا بديهيًا، لكن المعماريين قد يقعون في الخطأ المعاكس للتفكير قصير المدى: قد نُفرط في التصميم المعماري. ماذا لو استحوذنا على اثنتي عشرة شركة، وأصبح لدينا مليار عميل، وتوسعنا في 40 دولة، واحتاج كل نظام إلى تكامل في الوقت الفعلي؟ ربما. لكن هل هذه احتمالات حقيقية، أم أننا نخترع مشكلات؟ المعمارية لا تعني بناء أعقد نظام يمكننا تخيّله. بل تعني بناء النظام المناسب.

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

ابحث عن المتطلبات الضمنية

المتطلبات التي تُعطى لك ليست بالضرورة كل المتطلبات التي لديك. هناك دائمًا تقريبًا متطلبات ضمنية.

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

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

اعرف أرقامك

أدفع المعماريين باستمرار إلى التقدير الكمي. لا تقل لي إن هناك الكثير من البيانات؛ قل لي كم. عشرة آلاف، عشرة ملايين، مئة مليون، مليار؟ هذه معماريات مختلفة تمامًا. لا تقل لي إن التكامل يعمل كثيرًا: كل ساعة، كل دقيقة، ألف مرة في الثانية؟ لا تقل لي إننا ننمو بسرعة. ما مدى السرعة؟

عندما لا يكون لدي رقم أفضل، يكون خط الأساس عندي نموًا سنويًا بنسبة 30%. ليس تنبؤًا؛ بل أداة تُجبرنا على التفكير. إذا قال لي أحدهم إن لدينا 10 ملايين سجل اليوم، فلا أريد أن يتوقف النقاش عند 10 ملايين. بنسبة 30% سنويًا سنصل إلى نحو 13 مليونًا العام القادم، و17 مليونًا في العام الذي يليه، ونحو 22 مليونًا في العام الذي بعده. الآن لنتحدث عن التصميم. وإذا قال لي فريق الأعمال إن 30% رقم سخيف، فرائع: أعطني الرقم الحقيقي. الهدف هو جعل النمو جزءًا من نقاش المعمارية.

أسمّي هذا «عدد الأصفار» عند Steve (Steve’s Number of Zeros). صفر إضافي واحد قد يغيّر معماريتك تمامًا. عشرة آلاف، مئة ألف، مليون، عشرة ملايين، مئة مليون: الميزة لم تتغير، وربما لم يتغير المتطلب، لكن المعمارية قد تتغير.

أتذكر المواعيد من الوحدة 1؟ لنضع عليها الأرقام الحقيقية. أكثر من 1,200 موقع، و100 موعد لكل موقع في اليوم، وستة أيام في الأسبوع، أي نحو 305 أيام في السنة. هذا أكثر من 36 مليون موعد في السنة الأولى. كل زيارة تُنشئ سجلين، أي أكثر من 73 مليون سجل. والآن احتفظ بخمس سنوات من التاريخ، مع نمو 30% سنويًا، وستتجاوز 650 مليون سجل. الميزة نفسها، والمتطلب نفسه. صفران إضافيان، ومعمارية مختلفة تمامًا.

خطّط للغد

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

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

لا تبنِ الغد اليوم

هناك توازن هنا. التخطيط للغد لا يعني بناء نظام الغد اليوم. إذا كان لدينا 100,000 سجل وقد يصبح لدينا 100 مليون خلال خمس سنوات، فهذا لا يعني أن نبني معمارية الـ100 مليون سجل الآن. فقد تجلب كلفة وتعقيدًا لا نحتاج إليهما بعد.

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

خطّط للفشل

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

اسأل ما الذي يمكن أن يفشل، ثم اسأل ماذا يحدث عندما يفشل. تنتهي مهلة عملية تكامل. ترفض واجهة API طلبًا. يعالج تحميل ليلي 800,000 سجل ويفشل في 200,000. يتعطل نظام مصدر. يُدخل مستخدم بيانات غير صالحة. يظهر معرّف خارجي مرتين. يغيّر نظام في أعلى السلسلة صيغة قيمة دون أن يغيّر اسم الحقل. تنجح عملية في نظام وتفشل في آخر. هذه ليست حالات حدّية غير معتادة. هكذا تبدو بيئة الإنتاج.

النجاح الجزئي يظل فشلًا عليك أن تفهمه

حالات الفشل الجزئي خطيرة بشكل خاص في معمارية البيانات. تخيّل نقل مليون سجل، فتُبلغ العملية بأنها اكتملت. رائع. لكن هل وصل مليون سجل، أم 999,997، وما الثلاثة المفقودة؟ ربما فشل 200,000، أو أُنشئ بعضها مرتين، أو وصل كل شيء لكن بعض الحقول فشل تحويلها.

«اكتملت المهمة» ليست الشيء نفسه مثل البيانات صحيحة. معماري البيانات يفكر في المطابقة والتسوية (reconciliation): كيف نعرف ما الذي كان ينبغي أن يحدث، وما الذي حدث فعلًا، والفرق بينهما؟ وماذا نفعل حيال ذلك؟

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

Click to enlarge

افشل برشاقة

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

والأهم من ذلك كله: هل يمكننا التعافي دون أن نزيد المشكلة سوءًا؟ استراتيجية إعادة المحاولة التي تُنشئ بيانات مكررة ليست استراتيجية تعافٍ تُذكر. المعمارية الجيدة تفترض الفشل وتمنحنا طريقًا للعودة.

راقب ما يهم

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

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

فكّر في الاتجاهات الثلاثة كلها

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

التقنية تتغير من فصل إلى فصل. أما الأسئلة فلا.

المعمارية تعيش عبر الزمن

قد ينظر المطوّر أحيانًا إلى متطلب ويسأل: «هل يعمل هذا؟» أما المعماري فعليه أن يسأل أكثر: هل يعمل اليوم، وهل سيظل يعمل غدًا، وماذا يحدث عندما لا يعمل إطلاقًا؟ هذه الأسئلة الثلاثة تأخذنا إلى ما وراء التنفيذ وإلى حياة النظام.

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

ابنِ لليوم. خطّط للغد. خطّط للفشل. سنستخدم هذه العدسات الثلاث مرة بعد مرة.

ما الذي يقرره المعماري هنا

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