خارطة CTO لشركة SaaS ناشئة من اليوم الأول إلى خمسين موظفاً

عندما تبدأ شركة SaaS جديدة وتكون أنت المدير التقني CTO، فسوف تجد أن الأسئلة تصلك كلها في الأسبوع الأول وبالترتيب الخطأ، فمطور يسأل أين ينشر النسخة الأولى، وآخر يسأل هل نحتاج إلى بيئة staging أم يكفي الإنتاج Production، والمؤسس الآخر يسأل لماذا لا نستخدم Kubernetes مثل الشركات الكبيرة، ثم يأتي أول عميل مؤسسي بقائمة أسئلة أمنية عن مكان البيانات ومن يصل إليها، وفي الوقت نفسه يحتاج الموظفون إلى بريد ومحادثات ومكان للكود وكلمات المرور. وكل سؤال من هذه الأسئلة له مقال مفصل على الموقع، ولكن المشكلة ليست في إجابة كل سؤال وحده، وإنما في معرفة أي سؤال تجيب عنه الآن، وأيها تؤجله، وكيف ترتبط الإجابات ببعضها.

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

وسوف نناقش في هذا المقال ما يلي:

• خمس قواعد نقترح أن تحكم كل قرار تقني في السنتين الأوليين.
• المراحل الثلاث للشركة، وما تبنيه في كل مرحلة وما تؤجله عمداً.
• الفصل بين عالمين: المنتج الذي يستخدمه العملاء Product، والأدوات الداخلية Internal Tools التي يعمل بها الموظفون.
• البيئات Environments من جهاز المطور إلى الإنتاج، وقواعد البيانات والأسرار في كل منها.
• شكل السيرفرات في كل مرحلة، والشبكة الخاصة Private Network، والوصول الإداري عبر VPN.
• طريقة عمل الفريق من commit إلى الإنتاج، والأمن والامتثال بالحد الأدنى المناسب لكل مرحلة.
• بنية الفريق Team Structure والتوظيف، ثم التوثيق Documentation مع قائمة تحقق وقالب ADR جاهزين للنسخ.
• الأدوات في كل مرحلة، والخارطة في صفحة واحدة، وقائمة أول ثلاثين يوماً.

خمس قواعد قبل أي قرار تقني

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

1. ابدأ بأبسط بنية تعمل، وقس قبل أن تغير: تطبيق واحد Monolith منظم جيداً على سيرفر واحد أو اثنين يتحمل أكثر مما يتوقع أغلب الناس، والسبب أن كل خدمة إضافية أو عنقود Cluster يضيف عملاً تشغيلياً يدفعه فريق صغير من وقت المنتج، وقد شرحنا كيف يكبر النظام خطوة خطوة في مدخل إلى تصميم الأنظمة، ومثالاً حقيقياً على ذلك في كيف بنى Stack Overflow موقعه بسيرفرات قليلة.
2. افصل ما يراه العملاء عما يستخدمه الموظفون: حسابات وسيرفرات وشبكات مختلفة، والسبب أن الخطأ أو الاختراق في جهة يجب ألا يصل إلى الجهة الأخرى، وهذا موضوع القسم الخاص بالعالمين.
3. كل شيء قابل لإعادة البناء من Git: الكود والإعدادات وملفات Docker Compose ثم البنية نفسها لاحقاً، والسبب أن السيرفر الذي لا يعرف أحد كيف بني لا يمكن استبداله يوم يتعطل.
4. لا شيء على الإنترنت إلا المنفذان 80 و443: قواعد البيانات ولوحات الإدارة وال SSH خلف شبكة خاصة، والسبب أن ما لا يراه المخترق لا يستطيع أن يجرب عليه كلمات المرور.
5. اكتب القرار يوم تتخذه: سطر في سجل القرارات أفضل من اجتماع بعد سنة يسأل فيه الجميع «لماذا اخترنا هذا؟»، وقد خصصنا لذلك قسماً كاملاً في التوثيق.

المراحل الثلاث: ماذا تبني في كل مرحلة وماذا تؤجل

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

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

وفي المقابل لا تؤجل ما يصعب إصلاحه لاحقاً، وهي ثلاثة أشياء: طريقة عزل بيانات العملاء Tenant Isolation، لأن تغييرها بعد أن تمتلئ قاعدة البيانات عمل شهور، وقد شرحنا الخيارات ودليل القرار في تعدد المستأجرين في SaaS والتطبيق العملي في بناء تطبيق متعدد المستأجرين، ثم النسخ الاحتياطي، لأن البيانات التي ضاعت لا تعود، ثم الهوية، أي أن يكون لكل موظف حساب واحد باسمه، لأن تنظيف الحسابات المشتركة بعد سنة أصعب بكثير من منعها من البداية.

عالمان منفصلان: المنتج وأدوات الموظفين

في كل شركة SaaS نظامان مختلفان تماماً وإن كتبهما الفريق نفسه، الأول المنتج Product الذي يستخدمه العملاء ويحمل بياناتهم ويعمل على مدار الساعة، والثاني الأدوات الداخلية Internal Tools التي يعمل بها الموظفون، مثل Git والمحادثات والتوثيق ومدير كلمات المرور وأنظمة الموارد البشرية وإدارة علاقات العملاء CRM. والخطأ الشائع في البداية أن يوضع الاثنان على السيرفر نفسه وبالحساب نفسه عند المزود، لأن ذلك أسرع في الأسبوع الأول، والصورة التالية تبين الشكل الذي نقترحه بدلاً من ذلك:

والفرق بين العالمين ليس في الأدوات فقط، وإنما في كل صفة تؤثر على القرار:

وعلى هذا الأساس يكون الفصل في أربعة مستويات، والسبب في كل واحد منها هو تقليل نطاق الضرر Blast Radius، أي أن يبقى أثر أي خطأ أو اختراق داخل العالم الذي وقع فيه:

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

ويبقى بين العالمين جسر واحد لا بد منه، وهو خط النشر، فالكود يعيش في Gitea أو GitHub في عالم الأدوات، والتطبيق يعمل في عالم المنتج، ولذلك اجعل هذا الجسر ضيقاً قدر الإمكان: مفتاح نشر Deploy Key أو توكن خاص بالإنتاج لا يستطيع إلا نشر تطبيق واحد، ومحفوظ في أسرار خط CI الخاصة ببيئة الإنتاج فقط، وإذا استطعت فاجعل الاتجاه معكوساً، أي أن تسحب بيئة الإنتاج الإصدار الجديد من مستودع إعداد بدلاً من أن يدفعه خط CI إليها، وهذا ما يسمى GitOps وقد شرحناه في GitOps ببساطة. ولاحظ أن كل الأدوات الداخلية من اختيار Gitea إلى Mattermost وOutline وترتيب تثبيتها مشروحة في الأدوات المقترحة بالترتيب، فلن نعيدها هنا.

البيئات: من جهاز المطور إلى الإنتاج Production

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

في الصورة أعلاه لاحظ التالي:

• ابن ال Docker Image مرة واحدة في خط CI ثم انقلها كما هي إلى staging والإنتاج، والسبب أن البناء من جديد لكل بيئة يعني أن ما اختبرته ليس هو ما نشرته، وقد شرحنا ذلك بتجربة كاملة في ابن ال Docker Image مرة واحدة.
• الإعداد يختلف والكود لا يختلف، فعناوين قواعد البيانات والمفاتيح ومستوى السجلات تأتي من متغيرات البيئة Environment Variables، كما يقترح مبدأ Twelve-Factor للإعداد، والتفاصيل في الإعداد يختلف بين البيئات.
• النشر إلى staging تلقائي بعد الدمج، وإلى الإنتاج بموافقة، والموافقة تكون من شخص ثان عبر طلب دمج في مستودع الإعداد أو زر موافقة في منصة النشر، والسبب أن الإنتاج هو المكان الوحيد الذي يصل فيه الخطأ إلى العميل.

أما البيانات فلها قاعدة واحدة لا استثناء لها: بيانات العملاء الحقيقية لا تخرج من الإنتاج، فجهاز المطور وخط CI وبيئات المعاينة تعمل ببيانات أولية Seed Data يكتبها الفريق في سكربت داخل المستودع، وبيئة staging تعمل ببيانات مصطنعة Synthetic Data بحجم قريب من الإنتاج. وقد يتساءل البعض: وماذا عن الخطأ الذي لا يظهر إلا مع بيانات العميل الحقيقية؟ والإجابة على ذلك أن الحل هو أن تأخذ من الإنتاج نسخة مجهلة Anonymised، تستبدل فيها الأسماء والبريد والهواتف والعناوين بقيم مصطنعة قبل أن تخرج من بيئة الإنتاج، وليس أن تنسخ قاعدة البيانات كما هي، والسبب أن نسخة الإنتاج على جهاز مطور هي تسريب ينتظر أن يحدث، وأن أنظمة حماية البيانات الشخصية تعامل هذا النسخ معاملة المعالجة نفسها.

والأسرار Secrets تتبع القاعدة نفسها، فلكل بيئة أسرارها، وسر staging لا يفتح شيئاً في الإنتاج، وأسرار الإنتاج لا يعرفها إلا خط النشر وشخصان على الأكثر، ولا تكتب في Git ولا في المحادثات. وفي المرحلة الأولى تكفيك أسرار Gitea Actions أو منصة النشر مع مدير كلمات مرور للفريق، ثم عندما يكبر عدد الخدمات انتقل إلى مدير أسرار Secrets Manager مثل OpenBao، وهو نسخة مفتوحة من Vault تديرها مؤسسة OpenSSF التابعة لـ Linux Foundation، أو إلى ملفات مشفرة داخل Git بأداة مثل SOPS. وإذا تسرب سر رغم ذلك فسوف يكشفه فحص الأسرار الذي شرحناه في اكتشاف الأسرار المسربة مع Gitleaks وTruffleHog.

وتفاصيل بيئات المعاينة في Coolify وDokploy أو بـ Docker Compose وTraefik، وترحيل قاعدة البيانات Migrations دون أن يكسر الإصدار السابق، كلها في البيئات ومعاينة الميزات وGitOps للفرق، فهو المقال المرجعي لهذا القسم.

السيرفرات في كل مرحلة

الصورة التالية تبين شكل البنية في المراحل الثلاث، ولاحظ أن كل مرحلة تضيف إلى ما قبلها ولا تهدمه:

المرحلة الأولى: ثلاثة سيرفرات صغيرة أو منصة مدارة

أمامك في البداية طريقان، وكلاهما صحيح بحسب فريقك:

• منصة مدارة Managed PaaS مع قاعدة بيانات مدارة: إذا لم يكن في الفريق من شغل سيرفرات Linux في الإنتاج من قبل، فهذا الطريق يعطيك وقتاً أنت في أشد الحاجة إليه، والثمن فاتورة أعلى واعتماد على مزود، فاعرف قبل أن تبدأ كيف تخرج بياناتك منه وكم يكلف نقلها، وقد فصلنا التكاليف التي لا تظهر في صفحة الأسعار في التكاليف الخفية في السحابة.
• ثلاثة سيرفرات افتراضية VPS صغيرة: سيرفر للإنتاج يحمل التطبيق وقاعدة البيانات، وسيرفر ل staging وبيئات المعاينة، وسيرفر للأدوات الداخلية في حساب منفصل كما ذكرنا، وعلى سيرفري المنتج منصة نشر مثل Coolify أو Dokploy، وقد قارنا بينها في مقارنة Portainer وCoolify وDokploy.

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

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

المرحلة الثانية: فصل قاعدة البيانات والملفات والمراقبة

عندما يصبح لديك عملاء يعتمدون على المنتج يومياً، أضف ما يلي بهذا الترتيب تقريباً:

1. قاعدة بيانات على سيرفر خاص بها أو خدمة مدارة، والسبب أن التطبيق يمكن إعادة تشغيله ونسخه في دقائق أما قاعدة البيانات فلا، فلا تجعلهما يتنافسان على الذاكرة نفسها، وقبل أن تضيف نسخاً من التطبيق ضع مجمع اتصالات Connection Pool أمامها.
2. تخزين كائنات Object Storage لملفات المستخدمين بدلاً من قرص السيرفر، حتى يصبح سيرفر التطبيق بلا حالة Stateless يمكن استبداله، والفرق بين الأنواع في أنواع التخزين Block وFile وObject.
3. CDN للملفات الثابتة إذا كان عملاؤك في أكثر من منطقة، وما تضعه فيه وما لا تضعه في شبكة توصيل المحتوى CDN.
4. المراقبة Monitoring والسجلات المركزية Centralized Logging والتنبيهات، فقبل هذه المرحلة كان العميل يخبرك أن التطبيق توقف، وبعدها يجب أن تعرف أنت أولاً، وقد شرحنا ما تسجله وأين يذهب في السجلات للمطورين ومديري السيرفرات، وطريقة التحقيق عندما يبطئ شيء في استكشاف الأخطاء وتحليل الأداء.
5. أن تشبه staging الإنتاج في شكلها، أي قاعدة بيانات منفصلة وتخزين كائنات أيضاً، ولو بأحجام أصغر، والسبب أن الخطأ الذي يظهر بسبب الشبكة بين التطبيق وقاعدة البيانات لن تراه إذا كانا على السيرفر نفسه في staging.

المرحلة الثالثة: التوافرية العالية حيث تبررها العقود

التوافرية العالية High Availability تعني أن يبقى المنتج يعمل إذا توقف أي سيرفر واحد، وتحتاج إلى نسختين على الأقل من التطبيق خلف موزع حمل Load Balancer، وقاعدة بيانات بنسخة احتياطية حية Replica مع انتقال Failover مختبر. ولكن اسأل قبل أن تبنيها: هل وقعت عقداً يلتزم بنسبة توفر لا تحققها البنية الحالية؟ وهل يكلفك توقف ساعة أكثر مما تكلفك البنية الجديدة وتشغيلها؟ فإذا كانت الإجابة «لا» فالأفضل أن تستثمر في نسخ احتياطي أسرع استعادة وفي تقليل زمن الإصلاح. وقد فصلنا في عناقيد قواعد البيانات متى تحتاج عنقوداً أصلاً، ونبهنا في ما لا يعطيك إياه العنقود إلى أن النسخة الحية تنسخ الحذف الخاطئ أيضاً فهي ليست نسخة احتياطية.

وفي هذه المرحلة يصبح بناء السيرفرات يدوياً مصدر الأخطاء، فانقل البنية إلى الكود Infrastructure as Code كما شرحنا في البنية كشيفرة IaC للمبتدئين، واختيار الأداة وقصة الترخيص في Terraform أم OpenTofu. أما Kubernetes فارجع فيه إلى هل تحتاج Kubernetes فعلاً؟، وإذا قررت أنك تحتاجه فالمفاهيم بالرسم في مصطلحات Kubernetes بالرسم.

الشبكة: ما الذي يراه الإنترنت وما الذي لا يراه

الصورة التالية تبين شبكة المنتج كما نقترحها من المرحلة الثانية، وأغلبها ممكن من المرحلة الأولى أيضاً:

في الصورة أعلاه لاحظ التالي:

• شبكة خاصة Private Network بين السيرفرات: أغلب مزودي السيرفرات يقدمون شبكة داخلية بين سيرفرات الحساب الواحد، باسم VPC أو Private Network أو vSwitch، فاجعل التطبيق يتصل بقاعدة البيانات عبر العنوان الداخلي، واجعل قاعدة البيانات تستمع على هذا العنوان فقط، والسبب أن منفذ قاعدة بيانات على عنوان عام سوف تصله محاولات تخمين كلمات المرور في اليوم نفسه.
• جدار حماية Firewall على مستويين: جدار المزود أمام السيرفر، وجدار السيرفر نفسه، ولا تنس أن Docker يتجاوز قواعد ufw عند نشر المنافذ كما شرحنا في شبكات Docker وأفضل الممارسات.
• الإدارة عبر VPN فقط: ال SSH ولوحات منصة النشر وGrafana وأدوات إدارة قاعدة البيانات لا تفتح للإنترنت، وإنما عبر بوابة VPN، وقد شرحنا الفكرة وأنواعها في ما هو VPN؟ وتثبيت بوابة WireGuard بواجهة رسومية في شبكة خاصة مع WireGuard وwg-easy.

وأمامك لهذا الباب الإداري أربعة خيارات، ولا يوجد منها خيار صحيح لكل فريق:

وقد يتساءل البعض: هل يحتاج كل الموظفين إلى VPN حتى يصلوا إلى الأدوات الداخلية؟ والإجابة في أغلب الحالات لا، فالأدوات الداخلية مثل المحادثات والتوثيق تعمل عبر HTTPS خلف الدخول الموحد SSO مع المصادقة متعددة العوامل MFA، وهذا يحميها بشكل جيد دون أن تجبر موظف المبيعات على تشغيل VPN، أما الVPN فهو للأنظمة الإدارية التي يملك من يصل إليها السيرفرات نفسها. وهذا الاتجاه الذي يتحقق من هوية المستخدم وجهازه عند كل طلب بدلاً من الثقة بكل من دخل الشبكة يسمى Zero Trust، وقد شرحناه في Zero Trust وZTNA.

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

• الدخول الموحد SSO مع MFA لكل أداة داخلية عبر مزود هوية مثل authentik، والبروتوكولات التي يستخدمها مشروحة في OAuth وOpenID Connect، وإضافة الحسابات وإغلاقها تلقائياً في SCIM، والمصادقة المقاومة للتصيد في Passkeys وFIDO2.
• حساب إداري منفصل لكل من يملك صلاحيات إدارية، فحسابه اليومي للبريد والمحادثات، وحسابه الإداري للسيرفرات ولوحات المزود فقط، والسبب أن رسالة تصيد تسرق الحساب اليومي يجب ألا تعطي المخترق السيرفرات.
• أقل صلاحية Least Privilege، ومراجعة الصلاحيات Access Review كل ثلاثة أشهر في المرحلة الثالثة، وشهادات SSH قصيرة العمر بدلاً من المفاتيح الدائمة، وكل ذلك في إدارة الهوية والوصول IAM والوصول المميز PAM، وخطة تطبيقه تدريجياً في خطة تدريجية لمؤسسة صغيرة.

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

طريقة عمل الفريق: من commit إلى الإنتاج Production

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

مستودع واحد أم مستودعات كثيرة؟

المستودع الواحد Monorepo يجمع الواجهة والخادم والمكتبات المشتركة في مستودع واحد، فيصبح التغيير الذي يلمس الطرفين طلب دمج واحداً، والمستودعات المتعددة Polyrepo تعطي كل خدمة مستودعها وصلاحياتها ودورة إصدارها. وتوصيتنا لشركة في سنتيها الأوليين مستودع واحد للمنتج، ومستودع منفصل للإعداد والبنية Infrastructure and Config إذا استخدمت GitOps، ومستودع لكل أداة داخلية تعدل عليها، والسبب أن فريقاً صغيراً على منتج واحد يدفع ثمن تنسيق المستودعات المتعددة دون أن يستفيد من استقلالها. وإذا وصلت إلى فرق مستقلة لكل منها خدمة بدورة إصدار مختلفة فأعد النظر حينها، وليس قبل ذلك.

الفروع والمراجعة: فرع رئيسي واحد وفروع قصيرة

نقترح التطوير على الفرع الرئيسي Trunk-Based Development، أي فروع تعيش ساعات أو يومين على الأكثر، وطلب دمج Pull Request صغير يراجعه شخص ثان، والفرع main محمي لا يقبل الدفع المباشر، والميزة غير الجاهزة تدمج خلف Feature Flag. والسبب أن الفروع الطويلة تؤجل التعارضات إلى يوم الإصدار، وقد شرحنا ذلك بتجربة حقيقية في التطوير على الفرع الرئيسي Trunk-Based، ومقارنته بـ Git Flow وGitHub Flow في Trunk-Based أم Git Flow أم GitHub Flow؟، وأوامر Git التي يحتاجها الفريق يومياً في Git Merge وRebase وCherry-pick.

ومن اليوم الذي يصبح فيه في الفريق أكثر من خمسة مهندسين أضف ملف المالكين CODEOWNERS، فهو يطلب تلقائياً مراجعة من الشخص أو الفريق المسؤول عن ملفات معينة، مثل ترحيلات قاعدة البيانات والمصادقة والبنية. ولاحظ أن الصيغة تختلف بين المنصات، ف GitHub يستخدم أنماطاً قريبة من ملف .gitignore ويبحث عن الملف في .github/ ثم المجلد الرئيسي للمستودع ثم docs/ بحسب وثائق GitHub، أما Gitea فيستخدم التعبيرات النمطية Regular Expressions بصيغة لغة Go، ويبحث عن الملف في ./CODEOWNERS ثم ./docs/CODEOWNERS ثم ./.gitea/CODEOWNERS بحسب وثائق Gitea، ويمكنك في حماية الفرع أن تشترط موافقة المالك قبل الدمج. والمثال التالي ملف لـ Gitea:

# .gitea/CODEOWNERS  (Gitea: each rule is a Go regular expression)
# Database migrations need a backend lead
db/migrations/.*      @acme/backend-leads
# Login, sessions and permissions need a security champion
src/auth/.*           @acme/security-champions
# Infrastructure and deployment files need the platform engineer
infra/.*              @acme/platform
deploy/.*             @acme/platform
# Architecture decisions need the CTO
docs/adr/.*           @cto

في الملف أعلاه لاحظ التالي:

• كل سطر قاعدة ثم مستخدم أو فريق أو أكثر، والفريق يكتب بصيغة @org/team.
• الأنماط تعبيرات نمطية، فالنقطة تعني أي حرف، ولذلك كتبنا .* وليس * كما في GitHub، وإذا أردت نقطة حرفية فارجع إلى قسم الهروب Escaping في وثائق Gitea، وأساسيات التعبيرات النمطية في التعبيرات النمطية Regex للمبتدئين.
• لا تضع كل المستودع تحت مالك واحد، والسبب أن ذلك يحول المالك إلى عنق زجاجة يمر به كل طلب دمج، فاجعل الملف للمسارات الحساسة فقط، والفكرة الأمنية وراءه في ملف CODEOWNERS.

ما الذي يفحصه CI، وكيف يصل الإصدار إلى الإنتاج Production

خط CI يعمل على كل طلب دمج، ويجب أن يكون سريعاً، فإذا تجاوز عشر دقائق تقريباً بدأ الفريق في تجاهله أو تجميع التغييرات في طلبات كبيرة، والحد الأدنى الذي نقترحه في المرحلة الأولى: التحقق من صيغة الكود Lint، واختبارات الوحدة Unit Tests وبعض اختبارات التكامل Integration Tests، وفحص الأسرار Secrets Scanning، وفحص الاعتماديات SCA. ثم في المرحلة الثانية يضاف الفحص الثابت للكود SAST وفحص ال Docker Image، وفي الثالثة الفحص أثناء التشغيل DAST على staging. وأي اختبارات تكتب وبأي نسبة مشروح في مزيج معقول لفريق صغير، وأين يعمل كل فحص أمني في الخط في DevSecOps للمبتدئين، وخطة إدخال الفحوص على مراحل دون أن تغرق الفريق بالنتائج في خطة الإدخال على مراحل، وتشغيل كل ذلك على سيرفرك في Gitea Actions.

وبعد الدمج يبنى ال Docker Image مرة واحدة بوسم يساوي معرف ال commit، وينشر تلقائياً إلى staging مع اختبار دخان Smoke Test، ثم ينتقل إلى الإنتاج بموافقة. ولترقيم الإصدارات استخدم Semantic Versioning لكل ما يعتمد عليه غيرك، مثل ال API العامة والمكتبات، أما المنتج نفسه فيكفيه وسم بالتاريخ أو بالرقم مع سجل تغييرات Changelog يقرؤه فريق الدعم. والقاعدة الأهم هنا أن يكون التراجع Rollback ممكناً في دقائق، وهذا يعني أن ترحيل قاعدة البيانات لا يكسر الإصدار السابق، وطريقة ذلك في ترحيل قاعدة البيانات دون أن يكسر الإصدار السابق. وقبل أي إطلاق كبير أو حملة تسويقية شغل اختبار الأحمال على staging، والسبب أن نقطة الانكسار تجدها أنت أفضل من أن يجدها العملاء.

ولقياس طريقة العمل نفسها استخدم مقاييس DORA، وهي في نسختها الحالية خمسة: زمن التغيير Change Lead Time من ال commit إلى الإنتاج، وعدد مرات النشر Deployment Frequency، وزمن التعافي من النشر الفاشل Failed Deployment Recovery Time، ونسبة النشر الذي يحتاج إلى تدخل فوري Change Fail Rate، ونسبة النشر غير المخطط الذي يأتي بسبب حادثة Deployment Rework Rate. ولا تجعلها هدفاً للأفراد، وإنما مؤشراً للفريق كل شهر.

المناوبة والحوادث بأخف شكل ممكن

في المرحلة الأولى الكل مناوب On-call بشكل غير رسمي، وهذا مقبول ما دام العملاء قليلين، ولكن من المرحلة الثانية تحتاج إلى أربعة أشياء مكتوبة في صفحة واحدة:

• جدول مناوبة بالأسبوع، مع شخص احتياطي، وتنبيهات تصل إلى المناوب فقط بدلاً من قناة يتجاهلها الجميع.
• مستويات الخطورة Severity، ثلاثة تكفي: المنتج متوقف للجميع، وميزة مهمة متوقفة أو عميل كبير متأثر، ومشكلة لها حل مؤقت.
• إجراء الحادثة: من يقود، وأين تكون القناة، ومتى تبلغ العملاء، ومن يكتب الملاحظات أثناء الحادثة، والنموذج في نموذج ملاحظات الحادثة.
• مراجعة بعد الحادثة Postmortem دون لوم، وهي كما يصفها كتاب Google SRE مراجعة تبحث عن الأسباب التي ساهمت في الحادثة دون أن تتهم شخصاً أو فريقاً، وتفترض أن كل من شارك تصرف بنية حسنة بالمعلومات التي كانت عنده، والسبب أن ثقافة اللوم تجعل الناس يخفون المشكلات، والكتاب نفسه يقترح أن تحدد مسبقاً متى تكتب المراجعة، مثل توقف يراه المستخدمون أو فقد أي بيانات أو تدخل يدوي من المناوب.

الأمن والامتثال في كل مرحلة

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

واختيار مستوى ASVS المناسب لتطبيقك مشروح في كيف تختار المستوى المناسب، وقائمة المراجعة الأمنية لكل طلب دمج جاهزة للنسخ في قائمة المراجعة الأمنية، وأمن سلسلة التوريد البرمجية مع خطة لفريق صغير في أمن سلسلة التوريد. ولا تحتاج إلى مهندس أمن متفرغ في المرحلتين الأوليين، وإنما إلى سفير أمن Security Champion في كل فريق، وهو مطور يخصص جزءاً من وقته لمتابعة النتائج والمراجعة، كما شرحنا في سفير الأمن في كل فريق.

وإذا كان عملاؤك في السعودية، فسوف تصلك غالباً أسئلة عن الضوابط الأساسية للأمن السيبراني ECC الصادرة عن الهيئة الوطنية للأمن السيبراني، خاصة إذا كان العميل جهة حكومية أو تابعة لها، وعن نظام حماية البيانات الشخصية PDPL الذي تشرف عليه سدايا ويمكنك قراءة نصوصه ولوائحه في منصة حماية البيانات الشخصية. وقد شرحنا الضوابط بلغة بسيطة في الضوابط الأساسية للأمن السيبراني NCA ECC، ومصطلحات الحوكمة والمخاطر والامتثال في مصطلحات GRC، واقترحنا ضوابط لأمن التطبيقات مربوطة بـ ECC وASVS في ضوابط أمن التطبيقات. وهذه المقالات للفهم والتخطيط وليست استشارة قانونية، فنطاق ما ينطبق على شركتك يحدده مستشار قانوني أو مختص امتثال بحسب عملائك ونوع البيانات، والمهم من الجانب التقني أن تبدأ بتصنيف البيانات ومعرفة مكان حفظها مبكراً، لأن هذا ما تسألك عنه كل هذه الأطر أولاً.

وإذا كان المنتج سيضيف ميزات بالذكاء الاصطناعي، فاتخذ قراراً مكتوباً قبل أول سطر كود: هل تخرج بيانات العملاء إلى واجهة نموذج خارجية، أم يعمل النموذج على سيرفراتك؟ فهذا القرار يغير عقودك مع العملاء وقائمة المعالجين الفرعيين Sub-processors، وقد شرحنا كيف تعمل النماذج في كيف تعمل نماذج اللغة الكبيرة، والعتاد الذي تحتاجه لتشغيلها عندك في تشغيل نماذج اللغة على جهازك، والبحث في مستندات العميل في RAG للمبتدئين، ومخاطرها الأمنية الخاصة في OWASP Top 10 لتطبيقات نماذج اللغة.

الفريق: من المهندسين المؤسسين إلى فرق المنتج

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

ويصف كتاب Team Topologies هذه الأشكال بأربعة أنواع من الفرق بحسب موقعه الرسمي: الفريق المرتبط بمسار العمل Stream-aligned Team الذي يملك جزءاً من المنتج، وفريق التمكين Enabling Team الذي يساعد الفرق الأخرى على تجاوز ما يعيقها، وفريق النظام الفرعي المعقد Complicated Subsystem Team للأجزاء التي تحتاج إلى خبرة نادرة، وفريق المنصة Platform Team. ولاحظ أن شركة من خمسين شخصاً تحتاج غالباً إلى النوع الأول والأخير فقط، والسبب أن كل فريق إضافي يعني حدوداً جديدة للتنسيق.

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

التوثيق: ما الذي تكتبه، ومتى، وأين

التوثيق في الشركة الناشئة يفشل بطريقتين، إما لا يكتب شيء فتعيش المعرفة في رأس شخصين، وإما تكتب صفحات طويلة لا يحدثها أحد بعد شهر. والحل أن تكتب أنواعاً محددة من الوثائق، لكل منها غرض ومالك ومكان، وأن تبقي ما يتغير مع الكود بجانب الكود. ويقسم إطار Diátaxis التوثيق إلى أربعة أنواع تساعدك على معرفة ما ينقصك: الدروس Tutorials التي يتعلم منها الجديد، وأدلة التنفيذ How-to Guides لمهمة محددة، والمرجع Reference مثل وثائق ال API، والشرح Explanation الذي يجيب عن «لماذا». والجدول التالي يبين الوثائق التي نقترحها:

والقاعدة في مكان الحفظ أن ما يتغير مع الكود يبقى في المستودع ويراجع في طلب الدمج نفسه، مثل README وADR ورسوم C4 وملف OpenAPI، أما ما يقرؤه غير المهندسين أو يتغير بعيداً عن الكود فمكانه قاعدة معرفة مثل Outline يدخل إليها الجميع عبر الدخول الموحد. والفرق بين السياسة والمعيار والإجراء والإرشاد، وهو ما يحتاجه من يكتب السياسات الأمنية، مشروح في مصطلحات GRC.

رسوم المعمارية بنموذج C4

نموذج C4 طريقة لرسم معمارية البرنامج وضعها Simon Brown، تقوم على أربعة مستويات من التجريد، النظام البرمجي Software System، ثم الحاويات Containers، ثم المكونات Components، ثم الكود Code، ولكل مستوى رسم: رسم السياق System Context الذي يبين نظامك ومستخدميه والأنظمة الخارجية التي يتصل بها، ورسم الحاويات الذي يبين التطبيقات ومخازن البيانات داخل النظام، ثم رسم المكونات، ثم رسم الكود. ولاحظ أن كلمة Container في C4 لا تعني Docker Container، وإنما تعني بحسب تعريف الموقع تطبيقاً أو مخزن بيانات يجب أن يعمل حتى يعمل النظام كله، مثل تطبيق الويب أو قاعدة البيانات. وفي الشركة الناشئة يكفيك غالباً المستويان الأولان، والسبب أن رسوم المكونات والكود تتغير مع كل أسبوع فلا يحدثها أحد.

سجل القرارات المعمارية ADR

سجل القرار المعماري Architecture Decision Record ملف قصير يكتب يوم تتخذ قراراً مهماً، وقد اقترحه Michael Nygard في مقال Documenting Architecture Decisions في 15 نوفمبر 2011، وفيه خمسة أقسام: العنوان Title، والحالة Status، والسياق Context، والقرار Decision، والنتائج Consequences. واقترح أن تحفظ في مستودع المشروع بصيغة نصية مثل Markdown، وأن ترقم بالتسلسل ولا يعاد استخدام رقمها، وأن تكون صفحة أو صفحتين، وإذا تغير القرار لاحقاً فلا تحذف القديم وإنما تعلمه بأنه استبدل Superseded وتشير إلى القرار الجديد، والسبب أن معرفة القرار القديم وسببه مهمة بقدر الجديد. وتجد قوالب وأدوات أخرى في موقع ADR. والقالب التالي جاهز للنسخ إلى docs/adr/0001-record-architecture-decisions.md:

# ADR-0007: Use PostgreSQL with a tenant_id column for tenant isolation

- Status: Accepted            (Proposed | Accepted | Superseded by ADR-00NN | Deprecated)
- Date: 2026-10-07
- Deciders: CTO, backend lead
- Related: ADR-0003 (one database server in phase 1)

## Context
What forces are at play? Business needs, customer contracts, team skills,
cost, deadlines. Write facts, not the solution.
Example: 40 small customers expected in year one, no customer has asked
for a dedicated database, two engineers know PostgreSQL well.

## Options considered
1. Database per tenant
2. Schema per tenant
3. Shared tables with tenant_id and Row-Level Security

## Decision
We will use option 3: shared tables with a tenant_id column on every
tenant table, enforced by Row-Level Security policies.

## Consequences
- Good: one migration path, cheap to run, simple backups.
- Bad: a missing tenant filter is a data leak, so RLS is mandatory and
  every new table is reviewed (CODEOWNERS: db/migrations).
- Revisit when: a customer contract requires physical isolation.

في القالب أعلاه لاحظ التالي:

• أضفنا إلى أقسام Nygard الخمسة قسم البدائل Options considered وسطر «متى نعيد النظر» Revisit when، وهي إضافة شائعة وليست من المقال الأصلي، والسبب أن من يقرأ القرار بعد سنة يحتاج إلى أن يعرف ما رفضتموه ومتى يصبح القرار قديماً.
• السياق يكتب حقائق وأرقاماً من يوم القرار، وليس دفاعاً عن الحل، فإذا تغيرت الحقائق عرف القارئ أن القرار يحتاج إلى مراجعة.
• المثال عن عزل المستأجرين، وهو من القرارات التي نصحناك بألا تؤجلها، وخياراته الثلاثة مشروحة في أين تضع بيانات كل مستأجر.

وثائق ال API وأدلة التشغيل

وثائق ال API تكتب بمواصفة OpenAPI، وإصدارها الحالي في الصفحة الرسمية 3.2.1، وأفضل ما تفعله أن يكون ملف المواصفة في المستودع ويفحص في CI، فإذا تغيرت ال API دون أن يتغير الملف فشل الخط، والسبب أن الوثائق المكتوبة يدوياً بعيداً عن الكود تختلف عنه بعد أسابيع. أما دليل التشغيل Runbook فهو صفحة لكل تنبيه، فيها ما يعنيه التنبيه وكيف تتأكد منه وما الخطوات التي تجربها وبمن تتصل، ويربط من رسالة التنبيه نفسها، فالمناوب الذي يستيقظ في الثالثة صباحاً لا يجب أن يبحث عن الصفحة.

قائمة تحقق التوثيق، جاهزة للنسخ

انسخ القائمة التالية إلى قاعدة المعرفة أو إلى ملف في مستودع المعمارية، وراجعها في نهاية كل مرحلة:

## Documentation checklist

### Phase 1 (2 to 5 people)
- [ ] README in every repository: purpose, run locally, test, deploy, owner
- [ ] docs/adr/ with ADR-0001 "Record architecture decisions"
- [ ] ADRs for: hosting choice, database, tenant isolation, auth provider
- [ ] Restore runbook for every system with data, tested this month
- [ ] List of all accounts and services, with owner and MFA status
- [ ] Secrets inventory: what exists, where it lives, who can read it

### Phase 2 (10 to 20 people)
- [ ] C4 system context and container diagrams, reviewed every quarter
- [ ] OpenAPI file in the repository, checked in CI, published docs
- [ ] One runbook per alert, linked from the alert message
- [ ] On-call page: rotation, severities, incident steps, contacts
- [ ] Postmortem template and the first postmortems
- [ ] Onboarding guide: day one accounts, first week, first deploy
- [ ] Offboarding checklist: SSO, shared secrets, devices, same day
- [ ] Policies: acceptable use, access control, incident response, backup
- [ ] Service catalogue: each service, its owner, its dashboards

### Phase 3 (up to 50 people)
- [ ] Data classification: categories, where each lives, who can access
- [ ] Data flow diagram for personal data (needed for privacy reviews)
- [ ] Access review records, every quarter
- [ ] Policy review and approval dates, every year
- [ ] Architecture review notes for every new service

الأدوات والتكلفة في كل مرحلة

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

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

الخارطة في صفحة واحدة

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

أول ثلاثين يوماً: قائمة تحقق

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

الأسبوع الأول: الحسابات والهوية

• حساب منفصل عند المزود للمنتج وآخر للأدوات وثالث للنسخ الاحتياطية، والحساب الرئيسي Root Account لكل منها بمفتاح أمان ومحفوظ عند شخصين.
• MFA على كل حساب: المزود، وGit، والبريد، والدومين، ومدير كلمات المرور.
• مدير كلمات مرور للفريق، ولا توجد كلمة مرور في المحادثات أو في Git.
• قائمة بكل حساب وخدمة تستخدمها الشركة، ومالكها.

الأسبوع الثاني: الكود والخط

• مستودع المنتج مع README، وحماية الفرع main، وطلب دمج إلزامي بمراجعة.
• خط CI بالاختبارات وفحص الأسرار والاعتماديات.
• أول ثلاثة سجلات قرار: مكان الاستضافة، وقاعدة البيانات، وعزل المستأجرين.

الأسبوع الثالث: البيئات والسيرفرات

• staging وإنتاج بأسرار منفصلة، ونشر تلقائي إلى staging وبموافقة إلى الإنتاج.
• كل سيرفر مؤمن، ولا يفتح للإنترنت إلا 80 و443، والإدارة عبر VPN.
• بيانات أولية Seed Data للتطوير، ولا توجد نسخة من بيانات الإنتاج خارجه.

الأسبوع الرابع: ما يحميك يوم يحدث الخطأ

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

أخطاء شائعة

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

مسار القراءة: المقالات التي يجمعها هذا الدليل

هذه المقالات مرتبة بحسب أقسام الدليل، فابدأ بالمجموعة التي تخص قرارك الحالي:

القرار الاستراتيجي والتكلفة

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

السيرفرات والنشر والبيئات

دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.دليلتثبيت Docker Engine وCompose على Ubuntuكيف تثبت Docker على Ubuntu من المستودع الرسمي، وتضبطه من البداية حتى لا يمتلئ القرص أو تنكشف منافذك للإنترنت.مقارنةأي أداة تدير بها تطبيقاتك على السيرفر؟متى تكفيك واجهة تدير بها ال Containers، ومتى تحتاج منصة تنشر تطبيقاتك من Git مباشرة على سيرفرك.دليلمن الفرع إلى الإنتاج: البيئات وGitOps للفرقكيف يختبر فريقك كل ميزة وحدها ويعرضها على العميل دون أن تصل ميزة غير جاهزة إلى الإنتاج.دليلهل تحتاج Kubernetes فعلاً؟ متى يكفي Docker Composeما الذي يحله Kubernetes وما الذي يكلفك، ومتى يكفيك Docker Compose على سيرفر واحد أو بضعة سيرفرات.دليلمصطلحات البنية كشيفرة IaC التي تحتاجها قبل أي أداةما معنى أن تكتب بنيتك في ملفات داخل Git، ولماذا يفشل السكربت العادي عند تشغيله مرة ثانية، وما الذي تحفظه الأداة في ملف الحالة.

تصميم المنتج وبياناته

دليلمدخل إلى تصميم الأنظمة: من سيرفر واحد إلى ملايين المستخدمينكيف يكبر متجر إلكتروني من سيرفر واحد إلى نظام يخدم ملايين المستخدمين، وما الثمن الذي تدفعه في كل خطوة.دليلتعدد المستأجرين Multi-Tenancy في SaaS للمبتدئينكيف يخدم تطبيق SaaS واحد مئات العملاء دون أن يرى أحدهم بيانات غيره، وأي نموذج عزل يناسب تطبيقك.دليلتطبيق SaaS متعدد المستأجرين عملياً مع Row-Level Securityنبني على PostgreSQL تطبيق SaaS يعزل كل مستأجر Tenant عن غيره بسياسات Row-Level Security، ونرى أين تتسرب البيانات رغم ذلك.دليلعناقيد قواعد البيانات Database Clustering ومتى تحتاجهاماذا تعني كلمة Cluster في كل قاعدة بيانات، ومتى تحتاج نسخاً أو انتقالاً تلقائياً، ومتى يكفيك سيرفر واحد مع نسخ احتياطية جيدة.دليلConnection Pooling: لماذا الاتصال بقاعدة البيانات مكلفلماذا تظهر رسالة too many clients عندما تزيد نسخ تطبيقك، وكيف يحل مجمع الاتصالات وPgBouncer هذه المشكلة.دليلأنواع التخزين وواجهة S3: أين تضع بيانات تطبيقك؟أين تضع قاعدة البيانات وملفات المستخدمين والنسخ الاحتياطية، ولماذا يناسب كلاً منها نوع مختلف من التخزين.

الشبكة والهوية

دليلما هو VPN؟ الشبكة الخاصة الافتراضية من المشكلة إلى الأنواعلماذا تحتاج شبكة خاصة افتراضية VPN، وكيف تغلف حزمك وتشفرها داخل نفق، وأي نوع منها يناسب فريقك.دليلشبكة خاصة مع WireGuard وواجهة wg-easyكيف تنشئ شبكة VPN خاصة مع WireGuard وواجهة wg-easy، فلا يصل إلى لوحات الإدارة على سيرفرك إلا أجهزة فريقك.دليلتثبيت authentik للدخول الموحد SSO إلى تطبيقاتككيف تثبت authentik حتى يدخل كل موظف إلى تطبيقات الفريق بحساب واحد، مع فرض المصادقة الثنائية على الجميع.دليلشرح OAuth وOpenID Connect للمبتدئينلماذا لا يجب أن يعرف أي تطبيق كلمة مرورك، وكيف يحل OAuth ذلك بتوكنات محدودة، وكيف يضيف OpenID Connect الدخول الموحد.دليلإدارة الهوية والوصول IAM والوصول المميز PAMمن يملك صلاحية root على سيرفراتك ومنذ متى، وكيف تضبط حسابات المديرين بصلاحيات مؤقتة وجلسات مسجلة.دليلما هو SCIM؟ إدارة حسابات الموظفين تلقائياً في كل تطبيقاتكالدخول الموحد SSO يمنع الموظف المغادر من الدخول لكن حساباته تبقى نشطة، وSCIM ينشئ الحسابات ويعطلها في كل تطبيق تلقائياً.

طريقة عمل الفريق

دليلTrunk-Based Development: فروع قصيرة ودمج يوميلماذا تنفجر الفروع الطويلة يوم الإصدار، وكيف يدمج الفريق عمله في main كل يوم بأمان مع CI وFeature Flags.دليلGit في العمل اليومي: الدمج والتراجع دون أن تخسر عملكمتى تستخدم Merge ومتى تستخدم Rebase، وكيف تنقل إصلاحاً إلى فرع الإصدار أو تسترجع عملاً ظننت أنه ضاع.دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.دليلاختبار الأحمال والضغط Load Testing للمبتدئينلماذا يعمل تطبيقك مع خمسة مستخدمين وينهار مع خمسمئة، وكيف تكتشف ذلك وتصلحه قبل يوم الإطلاق.دليلGitea Actions: تشغيل CI/CD وبناء Docker Images على سيرفركاجعل سيرفرك يختبر الكود ويبني Docker Images تلقائياً مع كل push، دون أن يخرج كودك أو أسرارك إلى خدمة CI خارجية.دليلالسجلات Logging للمطورين: ماذا تسجل وماذا لا تسجلكيف تكتب سجلات Logs تساعدك على فهم ما حدث في الإنتاج، وما الذي لا يدخل السجل أبداً، وكيف تجمعها في مكان واحد.

الأمن والامتثال

دليلDevSecOps للمبتدئين: الأمن داخل خط CI/CD ومتى يعمل كل فحصما الذي يجده كل فحص أمني في خط CI/CD وما الذي يفوته، وكيف ترتب نتائجه حتى تصل إلى قرار بدل قائمة طويلة.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.دليلOWASP ASVS ومراجعة الكود الأمنية لكل Pull Requestكيف تكتب متطلبات أمان يمكن اختبارها مع OWASP ASVS، وتراجع كل طلب دمج أمنياً في عشرين دقيقة بقائمة جاهزة.دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.دليلبرنامج التوعية بالأمن السيبراني بأدوات مفتوحة المصدرالمحاضرة السنوية لا تغير ما يفعله الموظف أمام الرسالة المشبوهة، لذلك تبني هنا برنامج توعية مستمراً وتقيس أثره بأدوات مفتوحة المصدر.

الخلاصة

• ابدأ بأبسط بنية تعمل، ثلاثة سيرفرات صغيرة أو منصة مدارة، وأجل Kubernetes والخدمات المصغرة والتوافرية العالية حتى يبررها القياس وعقود العملاء.
• لا تؤجل ثلاثة أشياء يصعب إصلاحها لاحقاً: طريقة عزل بيانات العملاء، والنسخ الاحتياطي المختبر في حساب آخر، وحساب لكل موظف باسمه مع MFA.
• افصل المنتج عن أدوات الموظفين في الحسابات والسيرفرات والشبكات والمديرين، واجعل الجسر الوحيد بينهما مفتاح نشر محدوداً.
• Docker Image واحدة تنتقل بين البيئات، والبيانات الحقيقية لا تخرج من الإنتاج، ولكل بيئة أسرارها، وstaging تلقائية والإنتاج بموافقة.
• لا شيء على الإنترنت إلا 80 و443، والإدارة عبر VPN أو سيرفر وسيط، والأدوات الداخلية خلف SSO وMFA.
• فروع قصيرة وطلبات دمج صغيرة وCI سريع، والأمن يكبر مع كل مرحلة من MFA وفحص الأسرار إلى ASVS L2 واختبار الاختراق.
• اكتب القرار يوم تتخذه في ADR، واحفظ ما يتغير مع الكود في المستودع، وما عداه في قاعدة المعرفة، وراجع قائمة التوثيق في نهاية كل مرحلة.

وفي مقالات قادمة بإذن الله سوف نفصل بعض ما ذكرناه هنا بالاسم فقط، مثل استراتيجية النسخ الاحتياطي واختبار الاستعادة، والمراقبة بـ Grafana وPrometheus، وهي موجودة ضمن المراحل المخططة في خارطة طريق الاستضافة الذاتية.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة الدليل.