4SODEEP TECH
FAENAR
اختر منتجًا
تدفّق 4SO Enterprise WordPress: التجهيز، النشر، التوسّع، الحماية، الاستعادة.

MANAGED WORDPRESS PLATFORM

4SO Enterprise WordPressSelf-contained WordPress PaaS

يحوّل WordPress من تثبيت منفرد إلى Platform Resource؛ إذ تندرج Identity وInfrastructure وStorage وMySQL وValkey وEdge وObservability وCapacity والاستعادة وSecurity تحت Product Control Plane واحدة.

Self-containedAPI-firstMulti-tenantجاهز للاستعادة
PDFتنزيل الكتيب التقنينسخة فارسية Deep Tech من 12 صفحة↓

مكوّنات 4SO Enterprise WordPress: مواقع فوق خدمات منصّة مُدارة

  1. 1النطاق وTLSربط النطاق وHTTPS وسياسة الحافة العامة كجزء من دورة حياة المنتج.
  2. 2تشغيل المواقعكل موقع مورد له مالك وGeneration وصحة مرصودة، فوق أساس RKE2.
  3. 3Product API وRBACيوفّر Keycloak/OIDC الهوية، ويملك RBAC المنتج صلاحيات المؤسسة والمشروع والموقع.
  4. 4MySQLخدمة بيانات أساسية في المنصّة لمحتوى المواقع.
  5. 5Valkeyذاكرة تخزين مؤقت مُدارة بدورة حياة خاصة.
  6. 6تخزين دائمدورة حياة التخزين وسياسته لبيانات المواقع.
  7. 7Backup وPITRBackup وPITR والاستنساخ وStaging مسارات عمل في المنتج، لا إجراءات طوارئ.
  8. 8المراقبةVictoriaMetrics وLoki وAlloy وGrafana لصحة المواقع والمنصّة.
01PROBLEM & OUTCOME

مشكلة المنتج

WordPress المؤسسي ليس CMS؛ بل دورة حياة منصّة.

عندما تُدار Site وDomain وStorage وDatabase وCache وUpdate وSecurity وBackup بأدوات منفصلة، يصبح كل موقع جزيرة تشغيلية. ويحوّل هذا المنتج هذه العناصر إلى موارد قابلة للإدارة ضمن PaaS ذاتي الاستضافة.

01MULTI-TENANCY

يجب أن يمتلك Site سياقاً مؤسسياً (Context)

تحدّد Organization وProject وRole وSite منذ البداية حدود الوصول وOwnership.

02PLATFORM SERVICES

البنية التحتية لـ Site جزء من المنتج

تُدار Storage وMySQL وValkey وEdge وObservability بوصفها خدمات Platform.

03RECOVERY

لا ينبغي أن تكون الاستعادة إجراءً تشغيلياً طارئاً

Backup وPITR وClone وStaging وResume مسارات يملكها المنتج ويمكن تتبّعها.

04SAFE CHANGE

يحتاج Update إلى Preflight وVerification

يجري تغيير المحتوى أو بيئة التشغيل مع Impact وGeneration وResult واضحة.

02CAPABILITY SNAPSHOT

لمحة عن القدرات

كل طبقات WordPress Platform في نموذج منتج واحد.

التركيز على دورة حياة الموقع: الإنشاء، وربط Domain، والسعة، وUpdate، والاستعادة، وSecurity، والعمليات اليومية.

01SITE LIFECYCLE

Site Management

الإنشاء وSuspend/Resume وClone وStaging ودورة حياة كل Site.

02IDENTITY

Organization وProject وRBAC

وصول User وOperator ضمن حدود يملكها المنتج.

03STORAGE

Storage Platform

دورة حياة Storage وPolicy لبيانات الموقع (Data) ونسخه الاحتياطية.

04MYSQL / VALKEY

Database وCache

Data services ضمن دورة حياة Platform وسعتها.

05EDGE

Domain وTLS وEdge

Domain Binding وHTTPS وEdge policy ضمن مسار إدارة Site.

06OBSERVABILITY

Observability وAPM-lite

Health وMetrics وLogs والعمليات من منظور Site.

07CAPACITY

Capacity وScaling

Policy للسعة وقرارات Scale بما يتناسب مع workload.

08RECOVERY & SECURITY

الاستعادة وAccess وSecurity

Backup/PITR وAccess grant وSecurity policy وSafe Update.

4SO

ليست Panel وAPI وAI/MCP ثلاثة مسارات منفصلة لمرجعية القرار؛ فجميعها تعمل على Product RBAC وDurable Operations نفسها، فلا تستطيع أي واجهة الالتفاف على دورة الحياة.

03PLATFORM DEPLOYMENT MODEL

نموذج النشر

تبدأ نواة Production من ثلاث عقد وتنمو بوصفها Platform.

تقوم بيئة تشغيل WordPress على Foundation ذاتية الاستضافة؛ وتُبنى المواقع على Platform نفسها، وتتوسّع Capacity أو Region دون تغيير نموذج المستخدم.

الملف التعريفيFoundationبيئة تشغيل Siteالاستخدام
Production Core3 عقدالمواقع على Platform ServicesBaseline مؤسسي مع HA للبنية التحتية
Scale-outCore + عقد إضافيةSite Capacity أوسعزيادة السعة دون بناء Platform منفصلة
Staging / Cloneمرجعية المنتج نفسهابيئات منفصلة لـ Test/الاستعادةاختبار التغيير وClone والنقل المضبوط
Multi-regionمناطق Product-definedPlacement وEdge بما يتناسب مع Regionتوزيع Site والاستعادة عبر عدة نطاقات أعطال
04ARCHITECTURE

المعمارية

يُدار Site فوق مجموعة من Platform Services.

تحتفظ Control Plane بـ Intent وRBAC وOperation؛ وتنفّذ طبقات Infrastructure وStorage وData وEdge والاستعادة التغيير، وتعرض بيئة تشغيل Site النتيجة.

EXPERIENCEUser / Operator / API / MCPواجهات (Interface) متعددة على مرجعية منتج واحدة وPermission Model واحد.
↓
AUTHORITYOrganization / Project / SiteRBAC وDurable Operations وAudit وGeneration.
↓
PLATFORMInfrastructure · Storage · MySQL · Valkey · Edge · Observabilityالخدمات التي يقوم عليها Site ضمن دورة حياة Platform نفسها.
↓
SITE RUNTIMEWordPress Sitesبيئة التشغيل الفعلية لـ Site وDomain وHealth والحالة المرصودة.
الطبقةComponent / Planeالمسؤوليةالسلوك التشغيلي
FoundationRKE2Self-hosted platform runtime وnode lifecycleتُبنى Platform ويُجرى لها verify قبل Site
IdentityKeycloak / OIDC + Product RBACDelegated identity وOrganization/Project/Site authorizationلا يحلّ Identity provider محلّ Product permission model
Data PlaneMySQL + ValkeyPersistent site data وcache/session accelerationتمتلك Data services دورة حياة (lifecycle) وcapacity مستقلّة
Storage / EdgePlatform storage + Domain/TLS/Edge planesPersistent content وpublic binding وrequest edgeDomain وstorage جزء من Site lifecycle
ObservabilityVictoriaMetrics · Loki · Alloy · GrafanaMetrics وlogs وoperator visibilityتُبنى Site health من telemetry وruntime read-back
RecoveryBackup · PITR · Clone · StagingPoint-in-time recovery وisolated verification وpromotionRestore هو workflow للمنتج، لا أمر طوارئ
TECH

Install Authority. يبدأ تثبيت Production من artifact مختوم (sealed) وintent يملكه المشغّل (operator-owned)؛ ويقيّم Remote Doctor كل target قبل bootstrap دون أي mutation.

المرحلةAuthority / Componentالسلوك
Artifact admissionTrusted SHA256 + sealed release preparerيُفحص Hash قبل extraction، ويُتحقَّق من exact archive/tree parity مرة أخرى بعد extraction.
Operator intentNormalized install configNode/IP/role/data-device وURLs وSSH host-key fingerprints صريحة؛ ولا يخمّن installer أيّاً منها.
Remote admissionRead-only Remote Doctorيُتحقَّق من SSH fingerprint المستقل ومن جاهزية target قبل bootstrap/runtime mutation؛ وTOFU غير مقبول.
FoundationRKE2 → Authority/Identity → Storageيُبنى Platform foundation ويُجرى له read-back قبل خدمات Site.
Data / EdgeMySQL → Valkey → Edge → WordPressData وcache وpublic edge جزء من lifecycle المنصّة (Platform) نفسها.
Day-2 planesObservability → Capacity → Recovery → Access → Securityلا يكتمل التثبيت إلا عندما تكون planes التشغيلية متاحة بعد runtime أيضاً.
Operator handoffCredential-free handoff metadataيُسلَّم Panel/Identity URL ومسار credential الخاص بالمالك فقط (owner-only)؛ ولا يُطبع password/token في handoff أو log.
05LIFECYCLE

دورة الحياة

Site هو Resource حيّ من Create حتى الاستعادة.

تشمل دورة الحياة Setup وDomain وCapacity وUpdate وBackup والاستعادة وSecurity، لا التثبيت الأولي لـ WordPress فحسب.

01التهيئةPreflight
02إنشاء SiteCreate
03Domain وTLSBind
04التشغيلOperate
05السعةScale
06Safe UpdateUpdate
07الاستعادةRecover
08المراقبةObserve
06SITE & PLATFORM PROFILES

الملفات التشغيلية

لكلٍّ من Site والاستعادة وPlatform عملية محددة.

لا يحتاج المستخدم إلى إدارة تفاصيل Kubernetes والخدمات الأساسية في العمل اليومي.

Site OperationsDAY-2

المهام اليومية لكل Site.

  • Create / suspend / resume
  • Domain / TLS
  • Health / operations summary
Safe UpdateCONTENT & RUNTIME

تغيير مضبوط لـ Managed Content وبيئة التشغيل.

  • Preflight
  • Schedule / campaign
  • Verification / الاستعادة
الاستعادةPITR / CLONE

الاستعادة وإنشاء بيئة منفصلة عن Production.

  • Backup / PITR
  • Clone
  • Staging / promotion workflow
CapacitySCALE

إدارة الموارد استناداً إلى Policy وUsage.

  • Capacity policy
  • Workload profile
  • Scaling decisions
Edge & SecurityPROTECTION

الحدّ العام لـ Site وسياسة الأمن.

  • Domain binding
  • Edge policy
  • Security posture
Access & AIGOVERNED

وصول بشري ووصول Agentic تحت RBAC نفسه.

  • Access grants
  • Delegated MCP
  • No direct shell/SQL authority
07ACTION & WORKFLOW CONTRACT

تدفّق Site وDurable Operation

تشكّل Intent وOperation وOutbox وAudit وObserved Generation سلسلة واحدة.

تُربط Site mutation بـ generation محدد عبر Idempotency-Key وrequest fingerprint؛ ويمكن لدورات حياة DR وPlan Migration وRuntime Transition وRecovery أن تُجري fence على التغيير العام لـ Site.

01IntentREQUESTED
02DispatchOUTBOX PENDING
03ReconcileRUNNING
04ObserveGENERATION READ-BACK
05SuccessCOMPLETED
06FailureFAILED
07ResumeFAILED → RUNNING*
CANARY BRANCH

Safe Update مع Promote / Rollback

يُثبت Staging وCanary مسار التغيير قبل Cutover.

UPDATE INTENT
↓
STAGING + CANARY
↓
HEALTH
PASS?
PROMOTE
↙ ↘
ROLLBACK
لا يصل فشل Canary إلى Cutover، ويجب أن تكون rollback authority صالحة.
RECOVERY FORK

PITR في بيئة معزولة

يبني Restore أولاً Clone/Staging؛ ثم Promote أو Abort.

RECOVERY POINT
↓
RESTORE + REPLAY
↓
CLONE / STAGING
↓
APP
VERIFY
PROMOTE
↙ ↘
ABORT
تُجري Recovery النشطة fence على دورات الحياة المتداخلة.
GENERATION LOOP

Intent ↔ Observed Generation

لا يكون Site في حالة Ready إلا عندما تتقارب generation وdependencies.

TARGET
GENERATION
→
RECONCILE
↓
READ
BACK
↑
OBSERVED
GENERATION
←
DATA · CACHE
EDGE · RUNTIME
يبقى Intent الموقع مرتبطاً بـ Durable Operation وGeneration نفسيهما.
غياب telemetry أو dependency = unknown، لا Ready.
FLOW 01

Create Site

Site هو resource متعدد الطبقات، لا مجرد container.

01Org / Project02Plan / Region03Storage04MySQL / Valkey05WordPress Runtime06Observed Generation
Failure / Recoveryلا تُعدّ generation متقاربة ما لم تكن Data/Cache/Runtime جاهزة.
FLOW 02

Domain + TLS

Public edge جزء من lifecycle الخاص بـ Site نفسه.

01Domain Intent02Ownership / DNS03Certificate04Edge Binding05HTTPS Probe06Activate
Failure / Recoveryيوقف TLS أو DNS غير الصالح عملية activation.
FLOW 03

Safe Update

يُثبَت التغيير في staging/canary قبل cutover.

01Update Intent02Compatibility03Backup Checkpoint04Staging05Canary Verify06Promote
Failure / Recoveryيجعل Generation drift أو rollback fingerprint غير الصالح العملية stale.
FLOW 04

PITR / Clone

يُتحقَّق من Recovery point أولاً في بيئة معزولة.

01Select Point02Recovery Fence03Restore / Replay04Clone / Staging05App Verify06Promote / Abort
Failure / Recoveryلا يصل Restore إلى Promote دون App Verify.
FLOW 05

Capacity / Scale

يمرّ Scale عبر telemetry وplacement authority.

01Observe Load02Policy03Capacity Admit04Place05Scale Runtime06Health Read-back
Failure / Recoveryغياب telemetry لا يعني healthy ولا حاجة مؤكدة إلى scale.
ADDITIONAL OPERATIONAL FLOWS

تدفقات تشغيلية مكمّلة

يجب أن يكون لـ Migration وحذف Site أيضاً lifecycle صريح وقابل للاستعادة.

FLOW 06

Plan Migration

يُنفَّذ تغيير Plan أو Runtime مع checkpoint وcutover مضبوط.

01Source / Target02Compatibility03Capacity Gate04Backup Checkpoint05Stage Target06Sync / Canary07Cutover Verify
Failure / Recoveryيؤدي Generation drift أو الفشل في Canary إلى Block/Rollback للعملية، ولا يتم Cutover دون Verification.
FLOW 07

Delete Site

حذف Site عملية destructive مع Fence وترتيب محدد لتحرير dependencies.

01Exact Confirmation02Recovery Fence03Deletion Requested04Dependency Order05Release Data / Edge06Observed Deprovision07Audit Close
Failure / Recoveryتمنع Recovery أو Migration النشطة عملية Delete (Block)؛ ولا يُسجَّل Success إلا بعد رصد Deprovision لـ dependencies.
Action / FlowAdmission / PreconditionsExecution / LockSuccess CriterionFailure / Recovery
Create / Reconcile Siteيجب أن تكون Org/Project/Plan/Region وgeneration وplatform readiness صالحةتُربط Site intent + Operation + Outbox + Audit بـ resource/generation واحدتتقارب ObservedGeneration مع TargetGeneration ومع جاهزية data/cache/storage/applicationOperation failed حالة terminal؛ ولا يمكن الانتقال Failed→Running إلا لـ runtime families القابلة للاستئناف (resumable) صراحةً
Suspend / Resumeألّا يكون Site محذوفاً وألّا يكون fence الخاص بـ DR/Recovery/Plan Migration/Runtime Transition نشطاًGeneration جديد + durable Operation + site.reconcile outboxتتقارب Observed Site state مع suspension intentيُرفض Conflict بـ 409 بدلاً من overwrite؛ ويعيد idempotent replay الطلب (request) نفسه
Safe Update / Runtime TransitionCompatibility وstaging canary وrollback checkpoint/fingerprint صالحةيُربط Target PHP/runtime transition بـ exact staging/backup authorityCanary/target runtime وgeneration verification قبل cutoverيجعل Drift في generation أو rollback authority العملية stale/blocked
Backup / PITRRecovery point وdata-plane compatibility قابلة للإثباتيمرّ Recovery request/operation عبر Product authority نفسهايُتحقَّق من Restored Site/Data وruntime health قبل promotionتُجري Recovery النشطة fence على دورات الحياة المتداخلة الأخرى؛ وللفشل (failure) مسار recovery خاص به
Plan MigrationSource/Target Plan وusage/capacity admissionRequested → Reconciling → Prepared → CompletedPlan cutover فقط بعد جاهزية project/site dependenciesيمكن لـ Failed الدخول في RollbackRequested → RollingBack → RollbackPrepared → RolledBack
Delete Siteيجب أن يطابق confirmSiteId قيمة Site ID تماماً وأن يكون purgeData=true؛ ولا يُسمح بـ active recoveryيُعلَّق Site (suspend) ويُسجَّل DeletionRequested + durable Operation/Outbox/Auditتحرير Dependencies ورصد deprovisionلا يُجري Delete المتكرر أو lifecycle متداخل أي overwrite؛ وdestructive intent صريح وgeneration-bound
FLOW

* Resume ليس عاماً. لا يمكن العودة من Failed إلى Running إلا لأنواع operation التي تمتلك durable runtime generation وresume owner محدداً؛ أما البقية فـ terminal state فيها immutable.

08OPERATIONS CATALOG

كتالوج العمليات

يعمل المشغّل مع Site وOutcome، لا مع مكوّنات Kubernetes.

بدلاً من عرض كيانات backend، تعرض اللوحة العمليات اللازمة لإدارة WordPress.

Create Siteإنشاء Site ضمن Organization/Project وربطه بـ Plan وPlatform.
Bind Domainربط Domain وVerification وTLS.
Scale Capacityتغيير السعة استناداً إلى Policy والحالة الفعلية.
Safe UpdatePreflight وApply وVerification للتغييرات المُدارة.
Backup / PITRنقطة استعادة وإرجاع Site إلى لحظة زمنية محددة.
Clone / Stagingإنشاء بيئة منفصلة لـ Test أو الاستعادة أو Promotion.
Access Grantوصول محدود وقابل للإلغاء إلى Site.
Inspect & RecoverTimeline العمليات وIncident والاستعادة من Site Cockpit واحد.

أدِر WordPress كمنصة، لا كمجموعة من الخوادم والإضافات.

يجمع 4SO Enterprise WordPress عمليات Site وData وEdge والاستعادة ضمن تجربة واحدة.

كل منتجات 4SO ←