تحافظ البرمجيات المؤسسية القابلة للتوسع على أداء العمل المتفق عليه مع زيادة الطلب والبيانات وتعقيد التشغيل. لا يقتصر ذلك على إضافة مستخدمين؛ فقد يحتاج النظام إلى استيراد ملفات أكبر، أو خدمة فروع إضافية، أو عزل حسابات العملاء، أو الاستمرار عند توقف خدمة مرتبطة به.
عند التخطيط لنظام خاص للشركة، ينبغي أن تبدأ المخرجات بوصف لحجم العمل ومعايير القبول. قائمة التقنيات وحدها لا تثبت القدرة على التوسع. يوضح هذا الدليل القرارات والأدلة التي يجب طلبها قبل اعتماد البنية ونطاق التنفيذ.
حدّد حجم العمل قبل اختيار البنية
صِف العمليات المهمة: البحث في السجلات، واعتماد الطلبات، واستيراد المبيعات، وإصدار التقارير، ومزامنة ERP. افصل الحمل المعتاد عن فترات الذروة. عدد الحسابات المسجلة لا يوضح وحده عدد المستخدمين المتزامنين أو تكلفة الإجراءات التي ينفذونها.
أضف أعداد السجلات وأحجام الملفات وفترات الاحتفاظ والمهام الخلفية المتزامنة. حدد الذروة المتوقعة أثناء الحملات أو تغيير الورديات أو إقفال التقارير الشهرية. اكتب افتراضات النمو لتراجعها إذا اختلف الاستخدام الفعلي عنها.
قد ينص معيار افتراضي على إتمام 95% من عملية بحث محددة خلال ثانية واحدة، باستخدام مجموعة بيانات متفق عليها و50 موظفًا متزامنًا. هذا مثال لمتطلب قابل للاختبار، وليس وعد أداء من تراود. يجب تحديد بيئة الاختبار ومدته ونسبة الأخطاء المقبولة والعمليات الأخرى التي تعمل أثناءه.
تميز إرشادات Google SRE بين مؤشرات الخدمة المقاسة والأهداف المطلوبة، وتربط اختيار المؤشرات بما يحتاج إليه المستخدم. قد تختلف أهمية زمن الاستجابة ونجاح العمليات وإنجاز الأعمال الخلفية بحسب طبيعة النظام. مرجع أهداف مستوى الخدمة.
ابدأ بحدود واضحة لمسؤوليات النظام
حدد المجالات الرئيسية، مثل العملاء والمخزون والطلبات والفوترة والاعتمادات والتقارير. عيّن مصدر كل سجل والقواعد التي تسمح بتغييره. اربط التحقق من الصلاحيات وقواعد العمل بالإجراءات التي تحميها.
يمكن لتطبيق مقسّم إلى وحدات واضحة أن يحتفظ بهذه الحدود داخل نظام واحد قابل للنشر. وقد تناسب الخدمات المنفصلة أجزاء تحتاج إلى إصدارات مستقلة أو أحمال مختلفة أو فرق تشغيل منفصلة، لكنها تضيف مسؤوليات تنسيق الأعطال والبيانات والتشغيل. اطلب سببًا محددًا لكل فصل ومن سيتولى دعمه.
لا تختَر الخدمات المصغرة لمجرد أن الشركة تتوقع نموًا كبيرًا. قارن التصميم الأبسط بالتصميم الموزع وفق الحمل وقدرة الفريق ومتطلبات التشغيل. يكون تقييم البنية أوضح عندما يشرح العرض أسباب القرارات بدل الاكتفاء برسم للمكونات.
افحص عمل قاعدة البيانات قبل زيادة الخوادم
قد ينتج بطء الشاشة عن استعلامات متكررة، أو نتائج غير محدودة، أو تقارير تنافس المعاملات على الموارد. راجع العمليات خلف الشاشة باستخدام كمية وتوزيع بيانات يمثلان الاستخدام المتوقع.
في PostgreSQL، توضح الوثائق كيف يعرض EXPLAIN خطة تنفيذ الاستعلام، وكيف يضيف EXPLAIN ANALYZE قياسات التنفيذ الفعلي. الأمر الثاني يشغّل الاستعلام، لذلك استخدم بيئة اختبار مناسبة وتعامل بعناية مع الأوامر التي تغيّر البيانات. وثائق تحليل الاستعلامات في PostgreSQL.
اطلب دليلًا على موضع البطء قبل اعتماد فهرس أو تخزين مؤقت أو فصل قاعدة البيانات. للفهرس تكلفة في التخزين والكتابة، وللتخزين المؤقت قواعد تحدد متى تصبح البيانات قديمة. اختبر الصلاحيات في النتائج المخزنة حتى لا تظهر معلومات شركة داخل حساب شركة أخرى.
حدد ما إذا كانت أرقام لوحة المعلومات يجب أن تكون فورية أو يمكن تحديثها دوريًا. قد يكون إنشاء تقرير في الخلفية أنسب من إبقاء طلب المتصفح مفتوحًا أثناء معالجة مجموعة كبيرة من البيانات.
اجعل المهام الخلفية قابلة للمتابعة والاستعادة
يمكن تنفيذ تجهيز الرسائل والتصدير ومعالجة الملفات والمزامنة خارج الطلب التفاعلي. يحتاج المستخدم إلى حالة مفهومة وطريقة للحصول على النتيجة. نقل العمل إلى قائمة انتظار لا يلغي الحاجة إلى إدارته.
حدد أقصى مدة انتظار وحدود المحاولات والتعامل مع التكرار وما يحدث بعد الفشل المتكرر. قِس إنجاز العمل نفسه، وليس مجرد قبول المهام. قد تعني قائمة تتزايد دون أخطاء ظاهرة أن المستخدمين ينتظرون بلا نتيجة.
اتفق عند إعادة محاولة إجراء خارجي على كيفية تمييز الطلب نفسه لدى النظام المستقبل. انتهاء مهلة الاتصال لا يثبت فشل الإجراء الأصلي؛ يشرح دليل AWS للطلبات القابلة للتكرار بأمان هذا الفرق. احتفظ بمرجع يستطيع فريق الدعم استخدامه لمطابقة النتيجة.
وثّق ربط ERP وعزل بيانات العملاء
في تكامل ERP، حدد معرّفات المنتجات والعملاء وملكية الحقول وتكرار التحديث وإجراءات التصحيح. اختبر الفشل الجزئي؛ فقد يُقبل الطلب بينما يفشل مرفقه أو تحديث المخزون. اتفق على الحالة التي يراها المستخدم والوقت الذي تُعتبر فيه العملية مكتملة.
إذا كان النظام يخدم عدة مؤسسات، فحدد العزل في استعلامات البيانات والملفات والتصدير والمهام الخلفية والإدارة. اختبر محاولات الوصول إلى سجلات مؤسسة تجريبية أخرى عبر المسارات المعنية. إخفاء عنصر من القائمة لا يعوّض التحقق من الصلاحية على الخادم.
يشمل النطاق أيضًا تغيير الأدوار وإغلاق الحسابات وسجل التعديلات واستعادة البيانات المعدلة بالخطأ. هذه معايير قبول للتطبيق نفسه؛ وجود ميزة لدى مزود الاستضافة لا يثبت تطبيقها في النظام.
خطط للنشر والترحيل والتعافي معًا
وضّح كيف يغيّر الإصدار الكود والبيانات. اختبر ترحيل قاعدة البيانات بسجلات ممثلة وقدّر مدته. حدد التغييرات القابلة للتراجع وتلك التي تحتاج إلى ترحيل تصحيحي أو استعادة.
قبل انتقال المستخدمين، طابق أعداد السجلات المستوردة وعينات مهمة مع المصدر. اتفق على إمكانية تعديل البيانات خلال الانتقال وكيفية معالجة التغييرات التي تحدث في هذه الفترة. احتفظ بالبيئة السابقة خلال مدة التعافي المتفق عليها عندما يناسب ذلك خطة المشروع.
تحتاج النسخ الاحتياطية إلى اختبار استعادة. حدد مقدار فقد البيانات المقبول ومدة استعادة الخدمة بحسب العملية، ثم اختبر قدرة الإعداد المقترح على تحقيقهما. نجاح مهمة النسخ وحده لا يثبت إمكانية استعادة التطبيق والعمل عليه.
ما الأدلة المطلوبة في عرض التطوير؟
اطلب افتراضات الحمل وقرارات البنية وملكية البيانات ومتطلبات الصلاحيات وعقود التكامل وسيناريوهات اختبار الضغط ومسؤوليات النشر. افصل تكاليف الاستضافة والخدمات الخارجية عن التطوير والدعم، ولا تقارن العروض بعدد الشاشات فقط.
يمكن أن تبدأ المرحلة الأولى بعملية أعمال مكتملة تشمل حالات الفشل، ثم تتوسع المراحل التالية في المستخدمين والتكاملات والقدرة وفق الطلب المقاس. راجع الافتراضات في كل مرحلة بدل اعتبار تقدير السعة الأول حقيقة دائمة.
يساعدك دليل أتمتة عمليات الشركات على تحديد العملية الأولى. راجع تطوير البرمجيات الخاصة، وربط ERP، وخدمات البنية السحابية وDevOps، أو تواصل مع تراود باسم النظام الحالي وحجم التشغيل المتوقع والقيد الأهم. يتيح ذلك تقييم ما إذا كانت الحاجة تحسينًا محددًا أو إعادة بناء أوسع.
إذا كان المشروع يستبدل تطبيقًا قائمًا، فراجع دليل تحديث الأنظمة القديمة لمقارنة بدائل الانتقال وتحديد شروط إيقاف النظام السابق.
