قائمة فحص البنية التقنية

1. كيفية استخدام قائمة الفحص

1. راجع كل فئة مع قائد الهندسة أو المهندس المعماري.
2. لكل عنصر، حدّد:
   • مكتمل / كافٍ
   • مكتمل جزئياً / يحتاج مراجعة
   • غير مكتمل / يشكل خطراً
3. في النهاية، قيّم كل فئة من 1 إلى 5 ووثّق الفجوات في بطاقة التقييم.
4. راجع هذه الوثيقة:
   • قبل إطلاق النموذج الأولي
   • قبل وبعد جولات التمويل الكبيرة
   • عند تعيين قيادة تقنية جديدة
   • قبل تغييرات البنية التحتية أو المنتج الجوهرية

2. تصميم البنية الأساسية

قبل البناء، اسأل: هل قراراتك التقنية قادرة على تحمّل النمو؟

2.1 استراتيجية البنية

• تصميم النظام يستوعب التوسع المستقبلي (التوسع الأفقي مقابل العمودي محدد وموثّق بوضوح)
• خيار البنية الموحدة (Monolith) مقابل الخدمات المصغرة (Microservices) موثّق ومبرر
• فصل واضح للمسؤوليات عبر الطبقات (واجهة المستخدم، منطق العمل، البيانات، البنية التحتية)
• المسارات الحرجة والاعتماديات معروفة (مخططات التسلسل، مخططات البنية)
• الأنماط المدفوعة بالأحداث (Event-Driven) معتبرة حيث تناسب
• قرارات التصميم المتزامن مقابل غير المتزامن متخذة بوعي وموثّقة

اسأل نفسك: هل يستطيع شخص من خارج فريقك فهم مخطط النظام خلال 30 دقيقة؟

3. البنية التحتية والاستضافة

مكان تشغيل الكود أهم مما تتصور.

3.1 المنصة والتجهيز

• مزوّد السحابة المختار يتوافق مع أهداف المنتج ومتطلبات الامتثال (AWS، GCP، Azure، إلخ.)
• البنية التحتية ككود (Terraform، Pulumi، CloudFormation) موجودة لجميع البيئات
• البيئات (dev / stage / prod) قابلة للإعادة من الكود

3.2 الموثوقية والتوسع

• التوسع التلقائي مُعَد للخدمات الحرجة
• موازنة الأحمال موجودة للتعامل مع ذروات الزيارات
• استراتيجية التعافي من الفشل موجودة (multi-AZ / multi-region حيث يلزم)
• تماثل البيئات: بيئات dev/stage/prod متطابقة قدر الإمكان (التكوين، الاعتماديات، الإصدارات)
• النشر المعبّأ (Docker، Kubernetes، ECS) مستخدم بشكل ملائم

اسأل نفسك: إذا غادر المسؤول الرئيسي عن البنية التحتية، هل تستطيع تشغيل بيئة كاملة في أقل من 30 دقيقة؟

4. هندسة قاعدة البيانات

ليس فقط أين تُخزَّن البيانات — بل كيف تتدفق.

4.1 نمذجة البيانات والهيكل

• قرارات التطبيع مقابل إلغاء التطبيع متخذة بوعي وموثّقة
• علاقات المفاتيح الأساسية والأجنبية محددة بوضوح
• سلوك الحذف الناعم مقابل الصلب موحّد ومتسق

4.2 التوسع والمرونة

• استراتيجيات توسع القراءة/الكتابة موجودة (التكرار، نسخ القراءة، التقسيم)
• خطط النسخ الاحتياطي والتعافي من الكوارث موجودة ومُختبرة مع تمارين الاستعادة
• ترحيلات قاعدة البيانات مؤتمتة، خاضعة لمراقبة الإصدار، وآمنة للتراجع
• استراتيجية الفهرسة محسّنة لأنماط الاستعلام الحالية والمتوقعة
• الاستعلامات طويلة الأمد مُراقَبة وتُراجَع بانتظام

اسأل نفسك: هل قاعدة البيانات عنق زجاجة مخفي ينتظر الحدوث؟

5. الواجهات البرمجية والتكاملات

منتجك لا يعمل بمعزل عن العالم.

5.1 تصميم الواجهة البرمجية ودورة حياتها

• استراتيجية الإصدارات موجودة (مثل /v1، /v2 أو عبر الترويسات)
• حدود الواجهات الداخلية مقابل الخارجية محددة وموثّقة جيداً
• عقود ومخططات الواجهات واضحة (OpenAPI/Swagger، ملفات gRPC proto)

5.2 الاستقرار وتحمل الأخطاء

• تحديد المعدل والضبط مفروضان حيث يلزم
• المصادقة والتفويض الآمنان (OAuth2، JWT، رموز الجلسة) مطبّقان بشكل صحيح
• المهلات الزمنية وإعادة المحاولة وكاسرات الدائرة مطبّقة للتكاملات الخارجية
• Webhooks مُتحقَّق منها، متساوية القوة (Idempotent)، وآمنة لإعادة المحاولة

اسأل نفسك: إذا توقفت واجهة شريك ليوم واحد، هل ينهار منتجك أم يتدهور بشكل مقبول؟

6. الأمان (التطبيق والبنية التحتية)

الأمان ليس ميزة إضافية — إنه الحد الأدنى.

6.1 أمان التطبيق

• تدفقات المصادقة محصّنة (MFA، سياسات كلمات مرور قوية، إدارة الجلسات)
• نموذج التفويض محدد بوضوح (RBAC/ABAC) ومفروض من جانب الخادم
• التحقق من المدخلات وترميز المخرجات موجودان للتخفيف من الهجمات الشائعة (XSS، SQLi، CSRF)
• الأسرار (مفاتيح API، بيانات الاعتماد، الرموز) مخزنة في مدير أسرار آمن، لا في الكود أو ملفات التكوين

6.2 أمان البنية التحتية والتشغيل

• مبدأ الصلاحيات الأدنى مفروض (أدوار IAM، مجموعات الأمان، قواعد الجدار الناري)
• عملية تحديثات الأمان المنتظمة موجودة لنظام التشغيل والتبعيات
• فحص الثغرات والتحقق من الاعتماديات (SCA) مدمجان في CI/CD
• سجلات تدقيق مركزية موجودة للأحداث الأمنية (تسجيلات الدخول، تغييرات الصلاحيات، الوصول للبيانات الحساسة)

اسأل نفسك: هل تشعر بالراحة لو راجع مدقق نموذج الأمان والأدلة لديك؟

7. الأداء والمراقبة

لا يمكنك إصلاح ما لا تراه.

7.1 المراقبة والتنبيهات

• مراقبة فورية مع تنبيهات موجودة (Prometheus، Datadog، CloudWatch)
• تجميع السجلات مع إمكانية البحث (ELK، Loki، Cloud Logging) مُعَد
• التتبع مُعَد للأنظمة الموزعة (Jaeger، OpenTelemetry، X-Ray)

7.2 إدارة الأداء

• مؤشرات الأداء الأساسية محددة وموثّقة (زمن الاستجابة، الإنتاجية، معدلات الخطأ، SLOs)
• لوحات متابعة موجودة للتدفقات والخدمات الحرجة
• عناق الزجاجة تُحدَّد باختبارات الحمل، لا بعد الحوادث
• تخطيط السعة يُراجَع دورياً

اسأل نفسك: هل ستعرف في أقل من 5 دقائق إذا تعطل تطبيقك أو تدهور بشكل ملحوظ؟

8. DevOps والتكامل المستمر

النشر يجب أن يكون روتينياً — بأفضل معنى.

8.1 أتمتة البناء والاختبار

• الاختبار المؤتمت مدمج في كل طلب سحب (اختبارات الوحدة والتكامل والاختبار الأولي كحد أدنى)
• التحليل الثابت وفحص الأكواد يعملان تلقائياً في CI
• تغطية الاختبار مُتتبَّعة وحدود الهدف متفق عليها

8.2 النشر وإدارة الإصدارات

• النشر بنقرة واحدة (أو أمر واحد) متاح لجميع البيئات
• خطط التراجع موثّقة واختُبرت بانتظام
• بيئة التدريج تشبه الإنتاج (شكل البيانات، البنية التحتية، التكوين)
• استراتيجية النشر التدريجي (Canary) أو الأزرق-الأخضر (Blue-Green) مطبّقة حيث يبرر الخطر التعقيد
• ملاحظات الإصدار أو سجلات التغييرات محفوظة لكل نشر

اسأل نفسك: هل عمليات النشر أحداث مُقلقة تتطلب الجميع، أم عمليات روتينية عادية؟

9. الامتثال والمخاطر

ليس فقط للقطاعات المنظمة — الممارسات السليمة مهمة من اليوم الأول.

9.1 البيانات والخصوصية

• متطلبات إقامة البيانات مُعالَجة (الاتحاد الأوروبي، كندا، التخزين الإقليمي)
• اللوائح المطبقة (GDPR، CCPA، HIPAA، PCI-DSS) محددة والضوابط مخططة
• سياسات الاحتفاظ بالبيانات والحذف محددة ومُنفَّذة
• سياسات التسجيل والخصوصية موجودة ومُبلَّغة داخلياً

9.2 الحوكمة ومخاطر الموردين

• الوصول للبيانات الحساسة قابل للتدقيق ومقصور على الحد الأدنى
• مخاطر الموردين والأطراف الثالثة تُراجَع سنوياً على الأقل
• اتفاقيات مستوى الخدمة مع الموردين الحرجين موثّقة ومُراقَبة
• دليل الاستجابة للحوادث موجود (من يفعل ماذا، بأي ترتيب، وخطة التواصل)

اسأل نفسك: هل ستتحمل ممارساتك دعوى قضائية أو تدقيق أمان أو العناية الواجبة للمستثمرين؟

10. بطاقة التقييم النهائية

قيّم كل قسم من 1 (ضعيف) إلى 5 (ممتاز). كن صادقاً — هذا لك، لا للعروض.

نصيحة: أي فئة تسجل ≤ 3 يجب أن يكون لها إجراءات متابعة واضحة ومسؤولون.

11. وثيقة حية والخطوات التالية

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

راجعها:

• قبل الإطلاقات الكبرى
• قبل وبعد إعداد العملاء الكبار
• أثناء المراجعات التقنية الربع سنوية أو نصف السنوية
• عند إجراء تغييرات معمارية جوهرية (الانتقال للخدمات المصغرة، multi-region، تقنية قاعدة بيانات جديدة)

إذا شعرت بأن شيئاً ما هش أو غير واضح أو غير موثّق — عالجه الآن، لا عند الطوارئ.

الملحق: التغييرات في الإصدار 1.1

• أُضيفت بيانات وصفية منظمة (العنوان، المؤلف، الإصدار، آخر تحديث، الحالة).
• تحويل عناصر القائمة إلى قوائم فحص دلالية لاستخدام أفضل.
• إدراج قسم الأمان مخصص ليتوافق مع فئات بطاقة التقييم.
• أُضيفت أقسام "كيفية الاستخدام" و**"وثيقة حية"** لإرشاد أوضح.
• تحسين هرمية العناوين والمسافات للقراءة والتوافق مع محللات Markdown.
• إعادة صياغة بطاقة التقييم في جدول لتسجيل ومراجعة أسهل.
• توحيد إشارات "اسأل نفسك" لتحفيز التفكير بشكل متسق.