استشارات بنية تقنية المعلومات والسحابة
نساعدكم على أن تقرّروا، استنادًا إلى البيانات، هل ينبغي أن تعمل تطبيقاتكم في السحابة العامة، أم في مركز بياناتكم الخاص، أم في بنية هجينة تجمع بين الاثنين. نُعدّ البنية المستهدفة وخارطة الطريق، وننقل أعباء العمل إلى السحابة أو إلى بنية هجينة وفق خطة مدروسة، ونجعل التكاليف قابلة للتتبّع.
- البيئات
- AWS وAzure وGoogle Cloud، ومزوّدو السحابة المحليون، ومركز بياناتكم الخاص
- الاتجاه
- الانتقال إلى السحابة، والعودة من السحابة، والبيئات الهجينة ومتعددة المواقع
- النهج
- تُقارَن الخيارات من حيث التكلفة والمخاطر والمدة
- الخطوة الأولى
- الاجتماع التمهيدي المجاني أو التقييم المجاني
متى تُطرح قرارات البنية والسحابة؟
تؤثّر قرارات البنية في التكلفة والأمن والمرونة لسنوات طويلة. لذلك نقارن الخيارات وفق المعايير نفسها قبل اتخاذ القرار.
- تكاليف السحابة تحتاج إلى متابعة أدق. معرفة الفريق والمنتج اللذين تعود إليهما كل نفقة تسهّل تخطيط الميزانية.
- أعباء العمل المنقولة إلى السحابة لم تحقق الكفاءة المتوقعة. قد تحتاج الخوادم المنقولة كما هي إلى مراجعة باستخدام الخدمات المُدارة والتحجيم المناسب.
- عتاد مركز البيانات يقترب من موعد تجديده. يلزم قرار قائم على المقارنة بين التجديد أو الانتقال إلى السحابة أو إنشاء بنية هجينة.
- الأنظمة الحرجة مرتبطة بموقع واحد. ينبغي التخطيط لكيفية استمرار الخدمة حين يتعطّل خادم أو منطقة أو اتصال.
- متطلبات موقع إقامة البيانات والمتطلبات التنظيمية بحاجة إلى توضيح. تحديد البيانات التي يمكن حفظها في كل موقع شرط مسبق لتقدّم المشاريع.
- شروط ترخيص المحاكاة الافتراضية تغيّرت. ينبغي مقارنة التكلفة الإجمالية والمخاطر للبقاء على المنصة الحالية وللانتقال إلى بدائلها.
ماذا نقدّم في السحابة وبنية تقنية المعلومات؟
التصميم والانتقال وتخطيط التشغيل للبنية التحتية والسحابة.
البنية المستهدفة وخارطة الطريق
خطة بنية مرحلية قابلة لوضع الميزانية، تنطلق من أهداف أعمالكم وتوثّق مبرّرات كل خيار وأولويات تنفيذه.
أساس السحابة (landing zone)
هيكل الحسابات، والهوية والصلاحيات، والشبكة، والسياسات الأمنية، ووسوم التكلفة؛ يُبنى بالرمز قبل نقل أعباء العمل.
نقل أعباء العمل إلى السحابة
نقل أعباء العمل من الخوادم المادية والافتراضية إلى السحابة، مع جرد واستراتيجية نقل وخطة للتوقف عن الخدمة.
العودة من السحابة
نقل مخطط لأعباء العمل إلى مركز بياناتكم أو إلى مزوّد سحابة محلي، لأسباب تتعلق بالتكلفة أو الأداء أو المتطلبات التنظيمية.
البيئات الهجينة ومتعددة السحابات ومتعددة المواقع
تصميم الشبكة والهوية والنسخ الاحتياطي والإدارة كوحدة متكاملة عبر مركز البيانات والفروع والسحابة.
إدارة التكاليف (FinOps)
وضوح التكاليف على مستوى الفريق والمنتج، وتنبيهات الميزانية، والتحجيم المناسب، ومراجعات دورية للتكاليف.
المحاكاة الافتراضية وبدائل VMware
المحاكاة الافتراضية باستخدام VMware أو Hyper-V أو Proxmox أو OpenStack، والانتقال المخطط من المنصات التي تغيّرت شروط ترخيصها.
الاستمرارية والتعافي من الكوارث
التوافر العالي، واستراتيجية النسخ الاحتياطي، وأهداف مدة التوقف وفقدان البيانات (RTO/RPO)، وتمارين استعادة منتظمة.
ليس كل تطبيق بحاجة إلى النقل.
في الانتقال إلى السحابة، تُختار الاستراتيجية المناسبة لكل تطبيق على حدة. وأحيانًا يكون القرار الأصوب إبقاء التطبيق في مكانه أو إيقافه عن الاستخدام.
إعادة الاستضافة
نقل التطبيق كما هو. سريع لكن مكاسبه محدودة؛ وغالبًا ما يكون الخطوة الأولى.
تغيير المنصة
الانتقال إلى خدمات مُدارة بتعديلات طفيفة، كنقل قاعدة البيانات إلى خدمة مُدارة مثلًا.
إعادة التصميم
تحويل التطبيق إلى بنية سحابية أصلية. يتطلّب أكبر جهد ويمنح أكبر قدر من المرونة.
إعادة الشراء
استبدال تطبيق طوّرتموه بأنفسكم بمنتج SaaS جاهز يلبّي الحاجة.
نقل المنصة كاملة
نقل طبقة المحاكاة الافتراضية بأكملها إلى بنية تحتية أخرى، من دون المساس بالتطبيقات.
الإبقاء في المكان
إن لم يكن للنقل مبرّر اليوم، يبقى التطبيق في مكانه ويُعاد النظر فيه لاحقًا.
الإيقاف عن الاستخدام
إيقاف التطبيقات التي لم تعد مستخدمة؛ ما يقلّل نطاق النقل وتكلفته مباشرة.
القرار على مستوى كل تطبيق
تُحدَّد الاستراتيجية لكل تطبيق على حدة، مع تكلفتها ومخاطرها وقيمتها للأعمال.
نقيس قبل أن نقرّر.
تستند كل توصية تتعلق بالبنية إلى بيانات وضعكم الحالي وإلى أهداف أعمالكم. ونقدّم ما نوصي به وأسبابه مع مبرّرات مكتوبة.
ما نراعيه في قرارات البنية
نقارن كل خيار وفق المعايير نفسها:
- التكلفة الإجمالية للملكية
- الأمن والامتثال التنظيمي
- قابلية التوسّع والأداء
- قدرة فريقكم على التشغيل
الجرد والتحليل
نحصر التطبيقات والاعتماديات وتدفقات البيانات والتكاليف الحالية.
المُخرَج: الجرد وخريطة الاعتمادياتالخيارات والبنية المستهدفة
نقارن البدائل من حيث التكلفة والمخاطر والمدة، ونتخذ القرار معًا.
المُخرَج: وثيقة البنية المستهدفةخطة النقل
نحدّد ترتيب النقل على دفعات، وخطة التراجع، ونوافذ التوقف عن الخدمة.
المُخرَج: خطة نقل مرحليةالتنفيذ
نبني البنية التحتية بالرمز، وننقل أعباء العمل على دفعات ونتحقق منها.
المُخرَج: أعباء عمل منقولة وتم التحقق منهاالتحسين والتسليم
نضبط التكلفة والأداء، ونرسّخ متابعة التكاليف لدى فرقكم، ونسلّم مع التوثيق والتدريب. وإن رغبتم نواصل بمراجعات دورية للتكاليف.
المُخرَج: تقرير التحسين، التوثيقمخرجات العمل على البنية والانتقال.
تُحدَّد المخرجات وفق نطاق العمل، وتبقى مبرّرات القرارات وتعريفات البنية المُنشأة موثّقة بين أيديكم.
توثيق البنية
البنية المستهدفة، وتصميم الشبكة والأمن، وسجلات القرارات.
تحليل التكاليف
مقارنة التكاليف الحالية والمستهدفة، وتوصيات التوفير.
رمز البنية التحتية
في مشاريع التنفيذ، تعريفات البيئة الجديدة المكتوبة بـ Terraform وAnsible مع إدارة إصداراتها.
خطط النقل والتراجع والخروج
الخطوات والضوابط ومسار التراجع لكل دفعة، وطريقة تغيير المزوّد عند الحاجة.
خطة التعافي من الكوارث
النسخ الاحتياطي، وإجراءات الاستعادة، ونتائج التمارين.
نقل المعرفة
تدريب تطبيقي لفريقكم على تشغيل البنية الجديدة.
تقنيات تُختار وفق الحاجة.
نقيّم الخيارات وفق متطلباتكم واستثماراتكم القائمة وقدرة فريقكم على التشغيل. ونفضّل المعايير المفتوحة والأدوات القابلة للنقل حيثما أمكن.
السحابة العامة
- AWS
- Microsoft Azure
- Google Cloud
السحابة المحلية والخاصة
- مزوّدو السحابة المحليون
- OpenStack
- VMware vSphere
- Proxmox
- Hyper-V
الشبكة والهوية
- VPN / Direct Connect / ExpressRoute
- Entra ID (Azure AD)
- Keycloak
- Active Directory
النسخ الاحتياطي والاستعادة
- Veeam
- Velero
- خدمات النسخ الاحتياطي السحابية الأصلية
أعمال السحابة والبنية بما يناسب حجمكم.
الشركات الصغيرة والمتوسطة
يبدأ العمل غالبًا بتجديد العتاد أو بأول قرار يخص السحابة؛ والهدف بنية بسيطة بتكاليف يمكن توقّعها.
الشركات النامية
إظهار الإنفاق على السحابة بوضوح، وتنظيم هيكل الحسابات، وربط المواقع الجديدة ببنية مشتركة.
المؤسسات والجهات الخاضعة للتنظيم
دمج متطلبات موقع إقامة البيانات والاستمرارية والتدقيق في البنية منذ البداية.
لجعل الاجتماع الأول مثمرًا.
لا شيء من ذلك شرط مسبق؛ وكل ما يتوفر لديكم يجعل الحديث الأول أكثر تحديدًا.
ما يمكنك تحضيره إن توفّر
- تفصيل فواتير السحابة للأشهر القليلة الماضية، أو تكاليف العتاد والتراخيص
- جرد التطبيقات والخوادم، ومخططات البنية إن وُجدت
- مواعيد تجديد العتاد والتراخيص
- متطلبات موقع إقامة البيانات والاستمرارية والمتطلبات التنظيمية
حول بنية تقنية المعلومات والسحابة
المراجع والمعايير
- AWS Well-Architected (يُفتح في علامة تبويب جديدة)مبادئ البنية في AWS
- Azure Well-Architected Framework (يُفتح في علامة تبويب جديدة)مبادئ البنية في Azure
- Google Cloud Architecture Framework (يُفتح في علامة تبويب جديدة)مبادئ البنية في Google Cloud
- FinOps Foundation (يُفتح في علامة تبويب جديدة)ممارسات إدارة تكاليف السحابة
- NIST SP 800-34 (يُفتح في علامة تبويب جديدة)دليل تخطيط استمرارية تقنية المعلومات
لنحدّد احتياجاتك معًا.
في الاجتماع التمهيدي المجاني نناقش وضعك الحالي وأهدافك، ونشاركك انطباعاتنا الأولية والخطوات التالية الممكنة في الاجتماع نفسه.
- نقاش تقني مع مختصين في مجالك
- انطباعات أولية عن وضعك والأساليب الممكنة
- عند الملاءمة، خطوة تالية: التقييم أو مقترح مشروع أو استشارات
- اتفاقية عدم إفصاح قبل الاجتماع عند الحاجة
- الرد على الطلبات خلال 4 ساعات عمل
أمثلة هندسة تقنية المعلومات والسحابة من التطبيق العملي
نعرض بسيناريوهات توضيحية كيف تسير أعمال الانتقال وتأسيس السحابة واستمرارية الأعمال والتكلفة.
موجة الانتقال إلى السحابة
لا تُنقل أحمال العمل دفعة واحدة، بل على موجات مجمّعة وفق اعتمادياتها. وتُكتب معايير القبول وخطة التراجع لكل موجة مسبقًا.
الجرد
تُحصر الخوادم المادية والافتراضية والتطبيقات والاعتماديات بينها وبيانات الاستخدام.
- 48 virtual servers · 17 applications · 6 databases
- dependency map: 63 connections
الاستراتيجية
يُختار مسار لكل تطبيق: النقل كما هو، أو تغيير المنصة، أو إعادة التصميم، أو الإبقاء في مكانه، أو الإيقاف.
- rehost: 9 · replatform: 4 · refactor: 1
- retain: 2 · retire: 1
أساس السحابة
قبل وصول أي حمل عمل، تُبنى بنية الحسابات والهوية والشبكة وقواعد الأمان بالشيفرة (landing zone).
- $ terraform -chdir=landing-zone apply tfplan
- ✓ Apply complete! Resources: 64 added, 0 changed, 0 destroyed.
الموجات والتحويل
تُنقل كل موجة مع الاختبار ومزامنة البيانات ونافذة تحويل مخطط لها.
- Wave 2 · 4 applications · Saturday 22:00–02:00
- data sync lag: 2 s
- DNS TTL lowered to 300 s
القبول والتراجع
إذا تحققت معايير القبول اكتمل التحويل، وإلا تُعيد الخطوات الموثّقة الخدمة إلى البيئة القديمة.
- health checks ✓ · response time ✓ · business test ✓
- ✓ Wave 2 completed
ضبط الحجم
بعد الانتقال، يُعاد تحديد حجم الموارد بما يتناسب مع الاستخدام الفعلي.
- average CPU 11%
- ✓ 8 virtual machines moved down one size
- Azure Migrate / AWS Application Migration Service
- Terraform
- DNS
أساس السحابة (landing zone)
يُقصد بـ landing zone الأساس المكوّن من بنية الحسابات والهوية والشبكة وقواعد الأمان والتسجيل ووسوم التكلفة. وتُنقل أحمال العمل إلى هذا الأساس.
بنية الحسابات
تُنشأ حسابات أو اشتراكات منفصلة للإنتاج والاختبار والخدمات المشتركة والأمن.
- org/
- ├─ security ├─ shared
- ├─ production └─ test
الهوية
يتم الوصول عبر مزوّد هوية مركزي، بصلاحيات قائمة على الأدوار ومصادقة متعددة العوامل.
- SSO: Entra ID → cloud accounts
- roles: platform-admin · developer · read-only
الشبكة
تُنشأ شبكة بنمط المحور والأطراف (hub-spoke) وخطة عناوين IP واتصال آمن بشبكة الشركة.
- hub 10.0.0.0/16 · production 10.10.0.0/16 · test 10.20.0.0/16
- ✓ site-to-site VPN: connected
قواعد الحماية
تُحظر بالسياسات المناطق غير المسموح بها والتخزين غير المشفّر والموارد المتاحة للعموم.
- allowed-regions · require-encryption · deny-public-storage
- ✓ 3 policies assigned
التسجيل والوسوم
تُجمع سجلات جميع الحسابات في حساب مركزي، ويحمل كل مورد وسوم الفريق والمشروع والبيئة.
- audit logs → log-archive account
- ✓ required tags: team, project, environment
- Terraform
- AWS Organizations / Azure Management Groups
- Entra ID
تمرين التعافي من الكوارث
النسخ الاحتياطي يحمي البيانات؛ والتوافر العالي يُبقي الخدمة قائمة عند تعطل مكوّن واحد؛ أما التعافي من الكوارث فهو تشغيل الخدمة في مكان آخر عند فقدان بيئة كاملة. وتُختبر الخطة بالتمارين.
الأهداف
يُتفق مع وحدات الأعمال لكل نظام على مدة التوقف المقبولة (RTO) وفقدان البيانات المقبول (RPO).
- orders-db RTO 4 h · RPO 15 min
- file-server RTO 24 h · RPO 24 h
النسخ الاحتياطية ونسخها
تُنسخ النسخ الاحتياطية إلى منطقة منفصلة وإلى تخزين غير قابل للتعديل.
- transaction log: every 15 min · full backup: daily
- ✓ second-region copy · immutable for 30 days
التمرين
في تمرين مخطط له، يُشغَّل النظام من النسخة الاحتياطية في المنطقة الثانية.
- 12:00 drill started
- 12:41 database restored
- 13:22 application running in second region
القياس
تُقارن مدة التوقف الفعلية وفقدان البيانات الفعلي بالأهداف.
- ✓ actual RTO 1 h 22 min (target 4 h)
- ✓ actual RPO 9 min (target 15 min)
التحسين
تُضاف الخطوات التي تعثّرت إلى دليل التشغيل، ويُحدَّد موعد التمرين التالي.
- action: automate DNS failover
- next drill: in 6 months
- برنامج النسخ الاحتياطي
- منطقة ثانية
- دليل التشغيل
مراجعة تكاليف السحابة (FinOps)
يجعل FinOps الإنفاق على السحابة مرئيًا لكي تديره الفرق التقنية والمالية معًا. والهدف ليس خفض التكاليف فحسب، بل معرفة ما يحققه الإنفاق.
الوضوح
يُوزَّع الإنفاق على الفرق والمشاريع والبيئات عبر الوسوم.
- tagged spend: 62% → 97%
التحليل
تُدرج الموارد الخاملة أو الأكبر من اللازم أو المنسية في قائمة.
- unattached disks: 23 · stopped servers: 6
- average CPU < 10%: 14 servers
التحسين
تُحدَّد أحجام الموارد وفق الاستخدام الفعلي، وتُطفأ بيئات الاختبار خارج ساعات العمل.
- test environment: weekdays 08:00–20:00
- ✓ 14 servers moved down one size
الالتزامات
تُدرس الحجوزات أو خطط التوفير لأحمال العمل التي تعمل باستمرار.
- recommendation: 1-year commitment · 70% of baseline usage
الميزانيات والمتابعة الدورية
تُحدَّد ميزانيات وتنبيهات لكل فريق، وتُدرج مراجعة شهرية في الجدول الزمني.
- budget: production-team-a · thresholds 80% and 100%
- ✓ monthly cost review scheduled
- الوسم
- أداة تكاليف السحابة
- تنبيهات الميزانية