فلوی 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آماده‌ی بازیابی

دانلود بروشور فنی۱۲ صفحه · RKE2 · Data/Edge · PITR · Site Lifecycle

اجزای 4SO Enterprise WordPress: سایت‌ها روی سرویس‌های مدیریت‌شده‌ی پلتفرم

۱Domain و TLSاتصال دامنه، HTTPS و سیاست Edge عمومی به‌عنوان چرخه‌ی عمر محصول.
۲Runtime سایت‌هاهر Site منبعی با مالک، Generation و سلامت مشاهده‌شده است؛ روی پایه‌ی RKE2.
۳Product API و RBACKeycloak/OIDC هویت را می‌دهد و Product RBAC مجوز سازمان، پروژه و سایت را مالک است.
۴MySQLسرویس داده‌ی درجه‌یک پلتفرم برای محتوای سایت.
۵ValkeyCache مدیریت‌شده با چرخه‌ی عمر خودش.
۶Storage پایدارچرخه‌ی عمر و سیاست ذخیره‌سازی برای داده‌ی سایت.
۷Backup و PITRBackup، PITR، Clone و Staging گردش‌کارهای محصول‌اند، نه Runbook اضطراری.
۸مشاهده‌پذیریVictoriaMetrics، Loki، Alloy و Grafana برای سلامت سایت و پلتفرم.

۰۱PROBLEM & OUTCOME

مسئله‌ی محصول

WordPress سازمانی یک CMS نیست؛ یک چرخه‌ی عمر پلتفرم است.

وقتی Site، Domain، Storage، Database، Cache، Update، Security و Backup با ابزارهای جدا اداره شوند، هر سایت یک جزیره‌ی عملیاتی می‌شود. این محصول آن‌ها را به منابع قابل‌مدیریت در یک PaaS خودمیزبان تبدیل می‌کند.

۰۱MULTI-TENANCY

Site باید Context سازمانی داشته باشد

Organization، Project، Role و Site از ابتدا مرز دسترسی و Ownership را مشخص می‌کنند.

۰۲PLATFORM SERVICES

زیرساخت Site بخشی از محصول است

Storage، MySQL، Valkey، Edge و Observability به‌صورت سرویس‌های Platform مدیریت می‌شوند.

۰۳RECOVERY

بازیابی نباید یک دستورالعمل عملیاتی اضطراری باشد

Backup، PITR، Clone، Staging و Resume مسیرهای تحت مالکیت محصول و قابل‌پیگیری هستند.

۰۴SAFE CHANGE

Update نیازمند Preflight و Verification است

تغییر محتوا یا محیط اجرا با Impact، Generation و Result روشن انجام می‌شود.

۰۲CAPABILITY SNAPSHOT

نمای قابلیت‌ها

تمام لایه‌های یک WordPress Platform، در یک مدل محصول.

تمرکز روی چرخه‌ی عمر سایت است: ایجاد، اتصال Domain، ظرفیت، Update، بازیابی، Security و عملیات روزمره.

۰۱SITE LIFECYCLE

Site Management

ساخت، Suspend/Resume، Clone، Staging و چرخه‌ی عمر هر Site.

۰۲IDENTITY

Organization، Project و RBAC

دسترسی User و Operator روی مرزهای تحت مالکیت محصول.

۰۳STORAGE

Storage Platform

چرخه‌ی عمر Storage و Policy برای Data و نسخه‌های پشتیبان سایت.

۰۴MYSQL / VALKEY

Database و Cache

Data services تحت چرخه‌ی عمر و ظرفیت Platform.

۰۵EDGE

Domain، TLS و Edge

Domain Binding، HTTPS و Edge policy در مسیر مدیریت Site.

۰۶OBSERVABILITY

Observability و APM-lite

Health، Metrics، Logs و عملیات از دید Site.

۰۷CAPACITY

Capacity و Scaling

Policy ظرفیت و تصمیم‌های Scale متناسب با workload.

۰۸RECOVERY & SECURITY

بازیابی، Access و Security

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

4SO

Panel، API و AI/MCP سه مسیر جدا برای مرجع تصمیم نیستند. همه‌ی آن‌ها روی همان Product RBAC و Durable Operations کار می‌کنند تا هیچ رابطی نتواند چرخه‌ی عمر را دور بزند.

۰۳PLATFORM DEPLOYMENT MODEL

مدل استقرار

هسته‌ی Production از سه نود شروع می‌شود و به‌صورت Platform رشد می‌کند.

محیط اجرای WordPress روی یک Foundation خودمیزبان قرار می‌گیرد؛ سایت‌ها روی همان Platform ساخته می‌شوند و Capacity یا Region بدون تغییر مدل کاربر گسترش پیدا می‌کند.

پروفایل	Foundation	محیط اجرای Site	کاربرد
Production Core	۳ نود	سایت‌ها روی Platform Services	Baseline سازمانی با HA زیرساخت
Scale-out	Core + نودهای افزوده	Site Capacity گسترده‌تر	افزایش ظرفیت بدون ساخت Platform جدا
Staging / Clone	همان مرجع محصول	محیط‌های جدا برای Test/بازیابی	آزمون تغییر، Clone و انتقال کنترل‌شده
Multi-region	ناحیه‌ها Product-defined	Placement و Edge متناسب با Region	توزیع Site و بازیابی در چند دامنه‌ی خرابی

۰۴ARCHITECTURE

معماری

Site بالای یک مجموعه Platform Service اداره می‌شود.

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	مسئولیت	رفتار عملیاتی
Foundation	RKE2	Self-hosted platform runtime و node lifecycle	Platform پیش از Site ساخته و verify می‌شود
Identity	Keycloak / OIDC + Product RBAC	Delegated identity و Organization/Project/Site authorization	Identity provider جای Product permission model را نمی‌گیرد
Data Plane	MySQL + Valkey	Persistent site data و cache/session acceleration	Data services lifecycle و capacity مستقل دارند
Storage / Edge	Platform storage + Domain/TLS/Edge planes	Persistent content، public binding و request edge	Domain و storage بخشی از Site lifecycle هستند
Observability	VictoriaMetrics · Loki · Alloy · Grafana	Metrics، logs و operator visibility	Site health از telemetry و runtime read-back ساخته می‌شود
Recovery	Backup · PITR · Clone · Staging	Point-in-time recovery، isolated verification و promotion	Restore یک workflow محصولی است، نه دستور اضطراری

TECH

Install Authority. نصب Production با artifact sealed و operator-owned intent شروع می‌شود؛ Remote Doctor قبل از bootstrap هر target را بدون mutation ارزیابی می‌کند.

مرحله	Authority / Component	رفتار
Artifact admission	Trusted SHA256 + sealed release preparer	Hash پیش از extraction بررسی می‌شود و exact archive/tree parity بعد از extraction دوباره verify می‌شود.
Operator intent	Normalized install config	Node/IP/role/data-device، URLها و SSH host-key fingerprintها صریح‌اند؛ installer هیچ‌کدام را حدس نمی‌زند.
Remote admission	Read-only Remote Doctor	Fingerprint مستقل SSH و آمادگی target قبل از bootstrap/runtime mutation تأیید می‌شوند؛ TOFU پذیرفته نیست.
Foundation	RKE2 → Authority/Identity → Storage	Platform foundation پیش از سرویس‌های Site ساخته و read-back می‌شود.
Data / Edge	MySQL → Valkey → Edge → WordPress	Data، cache و public edge بخشی از lifecycle همان Platform هستند.
Day-2 planes	Observability → Capacity → Recovery → Access → Security	نصب فقط زمانی کامل است که planeهای عملیاتی بعد از runtime هم در دسترس باشند.
Operator handoff	Credential-free handoff metadata	Panel/Identity URL و مسیر credential owner-only تحویل می‌شود؛ password/token در handoff یا log چاپ نمی‌شود.

۰۵LIFECYCLE

چرخه‌ی عمر

Site از Create تا بازیابی یک Resource زنده است.

چرخه‌ی عمر شامل Setup، Domain، Capacity، Update، Backup، بازیابی و Security می‌شود؛ نه فقط نصب اولیه‌ی WordPress.

۰۱آماده‌سازیPreflight

۰۲ساخت SiteCreate

۰۳Domain و TLSBind

۰۴بهره‌برداریOperate

۰۵ظرفیتScale

۰۶Safe UpdateUpdate

۰۷بازیابیRecover

۰۸پایشObserve

۰۶SITE & PLATFORM PROFILES

پروفایل عملیاتی

Site، بازیابی و Platform هرکدام فرایند مشخص دارند.

کاربر لازم نیست جزئیات Kubernetes و سرویس‌های زیرین را برای کار روزمره مدیریت کند.

۰۷ACTION & WORKFLOW CONTRACT

فلو Site و Durable Operation

Intent، Operation، Outbox، Audit و Observed Generation یک زنجیره‌ی واحد می‌سازند.

Site mutation با Idempotency-Key و request fingerprint به generation مشخص bind می‌شود؛ lifecycleهای DR، Plan Migration، Runtime Transition و Recovery می‌توانند تغییر عمومی Site را fence کنند.

۰۱IntentREQUESTED

۰۲DispatchOUTBOX PENDING

۰۳ReconcileRUNNING

۰۴ObserveGENERATION READ-BACK

۰۵SuccessCOMPLETED

۰۶FailureFAILED

۰۷ResumeFAILED → RUNNING*

CANARY BRANCH

Safe Update با Promote / Rollback

Staging و Canary پیش از Cutover، مسیر تغییر را اثبات می‌کنند.

UPDATE INTENT

↓

STAGING + CANARY

↓

HEALTH
PASS?

PROMOTE

↙ ↘

ROLLBACK

Canary failure به Cutover نمی‌رسد و rollback authority باید معتبر باشد.

RECOVERY FORK

PITR در محیط ایزوله

Restore ابتدا Clone/Staging را می‌سازد؛ سپس Promote یا Abort.

RECOVERY POINT

↓

RESTORE + REPLAY

↓

CLONE / STAGING

↓

APP
VERIFY

PROMOTE

↙ ↘

ABORT

Recovery فعال lifecycleهای متداخل را 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 متصل می‌ماند.

Missing telemetry یا dependency = unknown، نه Ready.

FLOW 01

Create Site

Site یک resource چندلایه است، نه فقط container.

01Org / Project02Plan / Region03Storage04MySQL / Valkey05WordPress Runtime06Observed Generation

Failure / Recoveryتا Data/Cache/Runtime آماده نباشند generation همگرا تلقی نمی‌شود.

FLOW 02

Domain + TLS

Public edge بخشی از lifecycle همان Site است.

01Domain Intent02Ownership / DNS03Certificate04Edge Binding05HTTPS Probe06Activate

Failure / RecoveryTLS یا DNS نامعتبر activation را متوقف می‌کند.

FLOW 03

Safe Update

تغییر قبل از cutover در staging/canary اثبات می‌شود.

01Update Intent02Compatibility03Backup Checkpoint04Staging05Canary Verify06Promote

Failure / RecoveryGeneration drift یا rollback fingerprint نامعتبر عملیات را stale می‌کند.

FLOW 04

PITR / Clone

Recovery point ابتدا در محیط ایزوله verify می‌شود.

01Select Point02Recovery Fence03Restore / Replay04Clone / Staging05App Verify06Promote / Abort

Failure / RecoveryRestore بدون App Verify به Promote نمی‌رسد.

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 / RecoveryGeneration drift یا failure در Canary عملیات را Block/Rollback می‌کند و Cutover بدون Verification انجام نمی‌شود.

FLOW 07

Delete Site

حذف Site یک عمل destructive با Fence و ترتیب آزادسازی dependencyها است.

01Exact Confirmation02Recovery Fence03Deletion Requested04Dependency Order05Release Data / Edge06Observed Deprovision07Audit Close

Failure / RecoveryRecovery یا Migration فعال Delete را Block می‌کند؛ Success فقط پس از مشاهده‌ی Deprovision dependencyها ثبت می‌شود.

Action / Flow	Admission / Preconditions	Execution / Lock	Success Criterion	Failure / Recovery
Create / Reconcile Site	Org/Project/Plan/Region، generation و platform readiness باید معتبر باشند	Site intent + Operation + Outbox + Audit به یک resource/generation bind می‌شوند	ObservedGeneration با TargetGeneration و data/cache/storage/application readiness همگرا شود	Operation failed terminal است؛ فقط runtime familyهای صریحاً resumable می‌توانند Failed→Running شوند
Suspend / Resume	Site حذف نشده و DR/Recovery/Plan Migration/Runtime Transition fence فعال نباشد	Generation جدید + durable Operation + site.reconcile outbox	Observed Site state با suspension intent همگرا شود	Conflict به‌جای overwrite با 409 رد می‌شود؛ idempotent replay همان request را برمی‌گرداند
Safe Update / Runtime Transition	Compatibility، staging canary و rollback checkpoint/fingerprint معتبر	Target PHP/runtime transition به exact staging/backup authority bind می‌شود	Canary/target runtime و generation verification قبل از cutover	Drift در generation یا rollback authority عملیات را stale/blocked می‌کند
Backup / PITR	Recovery point و data-plane compatibility قابل اثبات	Recovery request/operation از همان Product authority عبور می‌کند	Restored Site/Data و runtime health قبل از promotion تأیید شود	Recovery فعال سایر lifecycleهای متداخل را fence می‌کند؛ failure مسیر recovery خودش را دارد
Plan Migration	Source/Target Plan و usage/capacity admission	Requested → Reconciling → Prepared → Completed	Plan 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 released و deprovision observed شود	Delete دوباره یا lifecycle متداخل overwrite نمی‌کند؛ destructive intent صریح و generation-bound است

FLOW

* Resume عمومی نیست. فقط operation typeهایی که durable runtime generation و resume owner مشخص دارند می‌توانند از Failed دوباره Running شوند؛ برای بقیه، terminal state immutable است.

۰۸OPERATIONS 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 را مثل یک Platform اداره کنید، نه مجموعه‌ای از سرورها و افزونه‌ها.

4SO Enterprise WordPress عملیات Site، Data، Edge و بازیابی را زیر یک تجربه‌ی واحد قرار می‌دهد.

بازگشت به محصولات 4SO ←