دو پلن میزبانی هر دو «NVMe، پهنای باند نامحدود و آپتایم ۹۹٫۹۹٪» نوشتهاند؛ اما یکی هنگام ثبت سفارش CPU را Throttle میکند و دیگری با منابع اسمی کمتر، Checkout را پایدار نگه میدارد. مسئله این نیست که Shared بهتر است یا VPS یا Cloud. مسئله این است که Workload واقعی شما در Journey حیاتی، با چه SLO، مسئولیت عملیاتی، ریسک و هزینهای قابل خدمت است.
این راهنما انتخاب هاست را از مقایسه برچسب و گیگابایت به فرایندی قابلممیزی تبدیل میکند: Workload را تعریف میکنید، Criticality را به SLI/SLO و RPO/RTO ترجمه میکنید، مدل سرویس و مسئولیتها را میسنجید، محدودیت و قرارداد را میخوانید، با Pilot از ایران راستیآزمایی میکنید و پیش از خرید، مسیر مهاجرت و خروج را میبندید. نتیجه الزاماً «قویترین سرور» نیست؛ کمریسکترین گزینه متناسب با کار شماست.
هاست چیست؟ مرز Hosting، Domain، DNS، CDN و Application
میزبانی وب مجموعهای از Compute، Memory، Storage، Network و عملیات است که Application و داده سایت را در دسترس قرار میدهد. Host ممکن است یک حساب Shared، ماشین مجازی، Platform مدیریتشده، چند سرویس Cloud یا سرور فیزیکی باشد. «سرور» فقط یک جزء از زنجیره خدمت است؛ صفحهای که کاربر میبیند از DNS، TLS، CDN/Edge، شبکه، Web server، Runtime، Application، Cache، Database و Dependencyهای بیرونی عبور میکند.
| جزء | کار | آیا همان هاست است؟ | ریسک مرزی |
|---|---|---|---|
| Domain | نام قراردادی مانند example.ir | خیر | مالکیت، تمدید و انتقال مستقلاند |
| DNS authoritative | نام را به Endpoint و سرویسها وصل میکند | ممکن است جدا باشد | خرابی DNS، Host سالم را هم نامرئی میکند |
| CDN/Edge/WAF | Cache، کاهش Latency، کنترل ترافیک و گاهی Failover محدود | Origin نیست | Cache miss و Dynamic request همچنان به Origin میرسند |
| Hosting/Origin | Application، Runtime، Storage و Database را اجرا میکند | بله | منابع، Failure domain و مسئولیت متفاوتاند |
| Mailbox، ارسال و دریافت پیام دامنه | بهتر است مرزش روشن باشد | مهاجرت وب نباید ناخواسته ایمیل را قطع کند | |
| Application | کد، Plugin، Theme، Rule و داده کسبوکار | روی Host اجرا میشود | Host خوب، کد کند یا آسیبپذیر را درمان نمیکند |
دامنه و DNS را داخل حساب مبهم فروشنده رها نکنید. دسترسی سازمانی، Owner، MFA، Record inventory و Rollback آنها باید مستقل ثبت شود؛ جزئیات در راهنمای مدیریت DNS و مهاجرت دامنه آمده است.
انتخاب هاست با Workload شروع میشود، نه با نام پلن
فروشنده درباره «۴ هسته و ۸ گیگ رم» حرف میزند، ولی خریدار باید درباره کار بگوید: چه Journeyای حیاتی است؟ چند درخواست همزمان دارد؟ کدام درخواست Read و کدام Write است؟ چه دادهای باید Durable بماند؟ چه Batch یا Cronای اجرا میشود؟ بدون Workload profile، مقایسه منابع دقت کاذب است.
| بخش Workload brief | نمونه ورودی | چرا در انتخاب اثر دارد؟ |
|---|---|---|
| Outcome/Journey | خواندن مقاله، ارسال Lead، پرداخت سفارش، ورود پنل | Criticality و SLO یکسان نیستند |
| Stack/Version | WordPress/WooCommerce، PHP، DB، Node، Queue | Compatibility و مسئول Patch را تعیین میکند |
| Traffic shape | درخواست/ثانیه، Concurrent user، Peak و Burst | میانگین ماهانه Peak را پنهان میکند |
| Read/Write mix | ۹۰٪ Cacheable read یا Checkoutهای Write-heavy | Cache و Scaling strategy را تغییر میدهد |
| Data | حجم DB، Growth، Media، PII و Retention | Storage، Backup، Security و Exit را شکل میدهد |
| Background work | Cron، Import، Feed، Email، Report و Image processing | CPU/Memory/Queue و زمان اجرا را مصرف میکند |
| Dependency | درگاه، پیامک، ERP، CRM و API بیرونی | Latency/Failure همیشه تقصیر Host نیست |
| Audience path | ایران/خارج، ISP، Mobile، Device و ساعت اوج | Route، CDN، Latency و آزمون را تعیین میکند |
| Change rate | Release روزانه یا سایت کمتغییر | Staging، Deployment، Rollback و Access لازم را میسازد |
| Operations | تیم ۲۴/۷، توسعهدهنده پارهوقت یا بدون Sysadmin | Managed بودن ممکن است مهمتر از Spec باشد |
از داده فعلی شروع کنید؛ Forecast را از واقعیت جدا نگه دارید
برای سایت موجود، Log، APM، Analytics، Database size، Storage growth، Backup duration، PHP worker saturation، CPU/Memory، I/O و خطاهای 5xx را در بازه عادی و کمپین جمع کنید. برای سایت جدید، سه سناریوی Downside/Base/Upside و فرض هرکدام را ثبت کنید. «انتظار یک میلیون بازدید» بدون بازه زمانی، Page view per session، Cacheability و Concurrency ورودی ظرفیت نیست.
فروشگاه را با Home page نسنجید. Journey نماینده باید Product→Search→Cart→Checkout→Payment callback→Order confirmation را پوشش دهد. یک سایت محتوایی نیز Cache miss، Login editor، Search، Upload و زمان انتشار همزمان دارد. Capacity plan باید ترکیب درخواستها را بازسازی کند.
Criticality را به SLI، SLO، SLA و Recovery objective ترجمه کنید
اول بپرسید خرابی کدام Journey چه زیانی دارد. سپس چیزی را اندازه بگیرید که کاربر تجربه میکند. Google SRE، SLI را سنجه کمی خدمت، SLO را هدف آن و SLA را توافقی با پیامدهای عدم تحقق جدا میکند؛ Availability نیز میتواند سهم درخواستهای معتبر موفق باشد، نه صرفاً روشنبودن ماشین. منبع: Google SRE Service Level Objectives.
| اصطلاح | نمونه قابل آزمون | خطای خرید |
|---|---|---|
| SLI | نسبت Checkoutهای معتبر که در کمتر از ۲ ثانیه موفق میشوند | استفاده از Uptime پنل بهجای Journey کاربر |
| SLO | ۹۹٫۹٪ موفقیت در پنجره ۳۰روزه، از سه Probe مجاز | هدف ۱۰۰٪ بدون هزینه/Trade-off |
| SLA | تعهد قراردادی، روش اندازهگیری، استثنا و Credit | فرض اینکه Credit زیان کسبوکار را جبران میکند |
| Error budget | حد مجاز شکست در پنجره SLO | مصرف بودجه خطا بدون قاعده Release |
| RPO | حداکثر داده قابلقبول برای ازدسترفتن | یکیدانستن با فاصله Backup بدون آزمون |
| RTO | زمان هدف بازگرداندن Journey | یکیدانستن با زمان پاسخ تیکت |
«۹۹٫۹٪ آپتایم» دقیقاً چند دقیقه است؟
جدول زیر فقط تبدیل ریاضی برای یک ماه ۳۰روزه است؛ نه تفسیر SLA. قرارداد ممکن است Maintenance، حمله، Dependency، Force majeure، بازههای کوتاه یا شیوه اندازهگیری خاصی را مستثنا کند.
| Availability اسمی | عدمدسترسی تقریبی در ۳۰ روز | پرسش ضروری |
|---|---|---|
| ۹۹٪ | ۷ ساعت و ۱۲ دقیقه | آیا این سطح برای Journey درآمدی پذیرفتنی است؟ |
| ۹۹٫۹٪ | ۴۳ دقیقه و ۱۲ ثانیه | از کجا و با چه Intervalی اندازهگیری میشود؟ |
| ۹۹٫۹۵٪ | ۲۱ دقیقه و ۳۶ ثانیه | کل سرویس یا فقط Network/VM؟ |
| ۹۹٫۹۹٪ | ۴ دقیقه و ۱۹ ثانیه | کدام Exclusion و چه Claim window دارد؟ |
Status page فروشنده شاهد مستقل نیست. Probe بیرونی از مسیرهای مخاطب، Synthetic transaction، Log و Business outcome را کنار هم بگذارید. برای طراحی Probe، پنجره، Maintenance و Incident evidence از راهنمای مانیتورینگ آپتایم سایت استفاده کنید.
انواع هاست را با Control plane و مسئولیت مقایسه کنید
نامهای بازار استاندارد یکسانی ندارند. «Cloud»، «Managed» و «اختصاصی» ممکن است بین فروشندگان معانی متفاوت داشته باشند. NIST برای Cloud پنج ویژگی از جمله On-demand self-service، Broad network access، Resource pooling، Rapid elasticity و Measured service و مدلهای IaaS/PaaS/SaaS را تعریف میکند. یک VPS روی یک سرور، صرفاً با برچسب Cloud، خودکار High availability نمیشود. منابع: NIST SP 800-145 و NIST SP 800-146.
| مدل | معمولاً چه میخرید؟ | عملیات سمت مشتری | تناسب محتمل | ادعایی که باید اثبات شود |
|---|---|---|---|---|
| Shared hosting | Account محدود روی Stack مشترک | Application، محتوا، Access و بخشی از Backup | سایت کمریسک و تیم بدون Sysadmin | Isolation، limit، Patch، Restore و Escalation |
| Managed WordPress | Stack، Tool و عملیات ویژه WordPress | Plugin/Theme، محتوا، Role و سازگاری Release | WordPress با ارزش عملیات مدیریتشده | معنای دقیق Managed و مرز Support |
| VPS | ماشین مجازی با سطح دسترسی مشخص | در Unmanaged: OS تا Application | نیاز به Control و تیم عملیات | Dedicated/burst CPU، overcommit، snapshot و network |
| Cloud VM/IaaS | منابع API-driven و Metered | Architecture، OS، App، IAM، Cost و Resilience | Automation، نوسان و معماری چندسرویس | Failure domain، quota، egress و مسئولیت |
| PaaS/Application platform | Runtime/Deploy/Scaling مدیریتشده | کد، داده، configuration و service binding | تیم محصول با ظرفیت Ops محدود | Runtime limit، cold start، portability و log access |
| Dedicated/Bare metal | سرور فیزیکی تخصیصیافته | بسته به Managed بودن، بخش بزرگی از Stack | نیاز خاص Hardware/Isolation یا بار پایدار | Single point، spare، repair time و Provisioning |
| Static/Serverless mix | Object/Edge + function/serviceهای مصرفی | Build، dependency، data flow و observability | محتوای Cacheable و Event-driven | Limit، state، cold path، bill shock و Exit |
هاست اشتراکی: ارزانتر میتواند مناسب باشد، اما Boundary را ببینید
Shared لزوماً ناامن یا کند نیست؛ کیفیت Isolation، Resource governance، Patch، Abuse response و Backup تفاوت میسازد. در مقابل، یک VPS بدمدیریت میتواند از Shared مدیریتشده پرریسکتر باشد. تعداد سایتهای روی Host بهتنهایی معیار نیست و از بیرون هم معمولاً تصویر کاملی از Isolation نمیدهد. برای Threat model، Account isolation و نشانه مهاجرت، راهنمای امنیت هاست اشتراکی را ببینید.
Managed WordPress: یک برچسب را به RACI تبدیل کنید
بپرسید چه کسی Core، PHP و OS را Patch میکند؛ Plugin update قبل از اجرا چگونه تست میشود؛ Staging و Rollback وجود دارد؛ Malware response شامل Cleanup است یا فقط Suspension؛ Backup کجا و چند نسخه نگه داشته میشود؛ Cache با WooCommerce/Login چگونه رفتار میکند؛ و Support تا Debug کد پیش میرود یا فقط زیرساخت را بررسی میکند.
صفحه رسمی Requirements وردپرس را در زمان خرید بررسی کنید. در اوت ۲۰۲۶، WordPress.org برای Baseline مدرن PHP ۸.۳+، MariaDB ۱۰.۱۱+ یا MySQL ۸.۰+ و HTTPS را توصیه میکند و درباره اجرای Application هر Account با Username خودش نکته امنیتی دارد. این اعداد تاریخپذیرند؛ مرجع زنده: WordPress Requirements.
VPS: vCPU و Root access معادل Performance تضمینی نیست
مشخص کنید vCPU اختصاصی، Shared یا Burstable است؛ Credit و Throttling چگونهاند؛ RAM قابل Swap یا Overcommit است؛ Storage محلی یا Network-attached؛ Snapshot Crash-consistent یا Application-consistent؛ و Live migration یا Host failure چه اثری دارد. Root access ارزش است فقط اگر Patch، Hardening، Monitoring و Incident owner دارید.
Cloud: Elasticity قابلیت است، نه معماری آماده
یک VM Cloud با یک Database روی همان Failure domain هنوز Single point of failure است. High availability به Load distribution، چند Instance، State/Session strategy، Database replication/failover، Health check، Capacity و آزمون Failure نیاز دارد. Auto scaling نیز اگر Boot کند، DB bottleneck، quota بسته یا deploy ناسازگار باشد، مشکل را حل نمیکند و حتی Cost را جهشی میکند.
Dedicated: Hardware انحصاری، نه خودکار امن یا Highly available
Dedicated noisy neighbor محاسباتی را کم و Control بیشتری میدهد؛ ولی خرابی قطعه، زمان تأمین Spare، Patch و Backup همچنان وجود دارند. یک سرور قوی ممکن است Failure domain بزرگتری بسازد. پیش از خرید، دلیل نیاز به Hardware خاص، License per-core، Data locality یا بار پایدار را مستند کنید.
منابع واقعی، Performance و Capacity plan
برچسب CPU/RAM/SSD فقط ظرفیت اسمی است. چیزی که Journey میبیند Latency توزیعی، Saturation، Queue و Error است. گلوگاه میتواند PHP worker، DB connection، Query کند، Disk IOPS، Lock، API بیرونی یا Cache miss باشد. قبل از ارتقا، مسیر Request را Instrument کنید.
| Resource/Limit | آنچه باید بپرسید | علامت اشباع | آزمون |
|---|---|---|---|
| CPU/vCPU | Dedicated/Shared/Burst، quota و throttle چیست؟ | Run queue، steal/throttle و Latency | Load نماینده با Cache hit/miss |
| RAM | Hard limit، Swap، OOM policy و Cache سهم چیست؟ | OOM kill، restart و swap latency | Peak + background job |
| PHP/App worker | Concurrency، queue و timeout چند است؟ | Worker exhaustion و ۵۰۲/۵۰۴ | Dynamic journey همزمان |
| Database | Connection، CPU، memory، IOPS و slow-log access | Lock، connection saturation و slow query | Checkout/Search/Import |
| Storage | IOPS، throughput، latency، durability و snapshot | I/O wait و کندی DB/Upload | Random read/write و restore |
| Network | Port، transfer، egress، packet limit و DDoS policy | Loss، timeout، bill/limit | چند ISP/Geo و فایل/درخواست کوچک |
| Filesystem | Inode، file count، size و backup exclusion | عدم ساخت فایل با فضای ظاهراً آزاد | Inventory و growth forecast |
| Process/Cron | Runtime، frequency و concurrent job limit | Job ناقص و backlog | Import/feed/report واقعی |
«نامحدود» را به Policy و سقف فنی ترجمه کنید
Unlimited معمولاً به معنی نبود Meter ساده است، نه منابع بینهایت. Acceptable Use، Fair use، inode، CPU seconds، concurrent process، database size، email send، backup و suspension policy را بخوانید. هر محدودیتی که میتواند Journey حیاتی را قطع کند باید در Acceptance و Alert دیده شود.
Benchmark درست، پلن را با Production نماینده میسنجد
- Replica مجاز و داده غیرحساس اما با شکل و حجم مشابه بسازید.
- Journey و نسبت ترافیک را تعریف کنید؛ فقط درخواست Home page نفرستید.
- Warm و Cold cache، Anonymous و Logged-in و Job پسزمینه را جدا بسنجید.
- Load را پلهای بالا ببرید و نقطه Saturation و Recovery را ثبت کنید.
- Latency را با p50/p75/p95/p99، Error و Throughput کنار Resource saturation ببینید.
- از چند مسیر مجاز مخاطب ایرانی در ساعات مختلف Probe بگیرید.
- نتیجه را با Version، Configuration، Dataset و زمان ذخیره کنید تا قابل تکرار باشد.
Core Web Vitals تجربه واقعی مرورگر را میسنجد و فقط Host نیست: LCP، INP و CLS از Server، Frontend، Device و Network اثر میگیرند. Google ارزیابی Field را در صدک ۷۵ گزارش میکند؛ پس یک Lighthouse سبز یا TTFB دیتاسنتر بهتنهایی تصمیم خرید نیست. منابع: Google Search Central: Core Web Vitals. برای تبدیل Performance به تصمیم کسبوکار، راهنمای سرعت سایت، UX و تبدیل را ببینید.
Reliability را معماری کنید؛ از Host معجزه نخواهید
Availability انتهابهانتها از حاصل Dependencyها اثر میگیرد. DNS، CDN، Origin، DB، Storage، Payment و Deploy هرکدام Failure mode دارند. افزودن Replica فقط وقتی مفید است که Traffic بتواند جابهجا شود، State سازگار بماند و Failover واقعاً آزموده شود.
| لایه | Failure mode | کنترل نمونه | Evidence |
|---|---|---|---|
| DNS | Record غلط، account takeover، outage | MFA، change control، secondary/appropriate design | Audit log و probe resolution |
| Edge/CDN | Misconfiguration، purge، false positive | Versioned config، bypass/rollback و origin protection | Hit ratio، edge/origin status و drill |
| Compute | Crash، saturation، host failure | Health check، restart، redundancy و capacity | Failure injection کنترلشده |
| Database | Lock، corruption، failover lag | Replication، backup، transaction و reconciliation | Restore/failover test |
| Deploy | Schema/code mismatch | Staging، progressive release و rollback | Release log و rollback time |
| Dependency | Timeout، rate limit، partial response | Deadline، retry محدود، circuit/degradation | Synthetic transaction و runbook |
CDN جانشین Origin نیست
CDN میتواند محتوای Cacheable را نزدیکتر کند، Load و بخشی از Flood را کاهش دهد و در بعضی حالتها نسخه Static را هنگام خرابی Origin نگه دارد؛ ولی اولین Cache miss و عملیات Dynamic همچنان Origin میخواهند. Google نیز درباره Cold cache و نیاز Origin به پاسخگویی اولین درخواستها توضیح میدهد. منبع: Google Search Central: CDNs and crawling. برای معماری Edge/Origin و آزمون مسیر ایران، راهنمای انتخاب CDN برای سایت ایرانی را بخوانید.
Observability جزو قابلیت هاست است، نه افزونه لوکس
حداقل به Metric منابع و Application، Access/error log، تغییرات، Audit، Trace یا Correlation کافی، Export و Retention نیاز دارید. Dashboard بدون Alert/Owner/Runbook فقط تصویر است. Provider باید Status و Incident communication بدهد، اما تیم شما نیز Outside-in monitor و Business outcome را نگه دارد. راهنمای Observability سایت Telemetry را به SLO و Burn alert وصل میکند.
امنیت و Shared responsibility را در RACI بنویسید
خرید Cloud یا Managed مسئولیت امنیت و حریم خصوصی سازمان را حذف نمیکند. NIST توصیه میکند محیط Provider را بفهمید، تناسب آن با Requirement را ارزیابی و Accountability داده و Application را حفظ کنید. منابع: NIST SP 800-144 و NIST Cybersecurity Framework 2.0.
| Control | Shared/Managed | VPS/IaaS | سؤال Contract/RACI |
|---|---|---|---|
| Facility/Hardware/Hypervisor | عمدتاً Provider | Provider | Scope و Evidence چیست؟ |
| Host OS | معمولاً Provider | در Unmanaged مشتری | Patch SLA و EOL owner کیست؟ |
| Runtime/Web/DB | متغیر | اغلب مشتری | Version، config، backup و hardening با کیست؟ |
| Application/Plugin/Theme | مشتری یا Shared محدود | مشتری | Vulnerability و compatibility چگونه مدیریت میشوند؟ |
| Identity/Access | Shared | Shared | MFA، least privilege، audit و recovery چیست؟ |
| Data/Privacy | Accountability مشتری، کنترل مشترک | Accountability مشتری، کنترل مشترک | Location، encryption، retention، deletion و disclosure؟ |
| Logging/Detection | Provider + مشتری | Provider + مشتری | چه Logای، چند روز، قابل Export و Tamper-resistant؟ |
| Incident | Shared | Shared | Notification، forensics، evidence و escalation چگونه است؟ |
Security checklist خرید باید Isolation tenant، MFA، Role، Patch/EOL، Secret، TLS، WAF/DDoS boundary، Malware response، Log، Vulnerability disclosure، Backup isolation، Incident notification و Secure deletion را پوشش دهد. گواهی SSL رایگان فقط TLS endpoint است؛ سلامت Application یا امنیت Account را تضمین نمیکند.
Backup، Snapshot، Replication و DR را یکی ندانید
Snapshot سریع ممکن است روی همان Account و Failure domain باشد. Replication خرابی یا حذف را سریع تکثیر میکند. Backup وقتی ارزش دارد که نسخهبندی، Retention، Isolation، Encryption، Access control و Restore آزموده داشته باشد. DR نیز People، Dependency، Runbook، Communication و بازگشت خدمت را اضافه میکند.
| سؤال Backup/DR | پاسخ قابل قبول باید چه چیزی داشته باشد؟ |
|---|---|
| چه چیزی Backup میشود؟ | DB، فایل، object، config، secret reference، DNS/config export |
| هر چند وقت و چند نسخه؟ | Schedule متناسب RPO و Retention روشن |
| کجا نگهداری میشود؟ | Failure domain/Account جدا و محدودیت Region مشخص |
| چه کسی میتواند حذف/Restore کند؟ | Least privilege، MFA، audit و break-glass |
| Restore چقدر طول میکشد؟ | آزمون زماندار با Reconciliation، نه وعده |
| اگر Provider suspend/close شد؟ | نسخه قابل خروج، Credential مستقل و Runbook جایگزین |
برای BIA، RPO/RTO، Restore drill و سناریوی باجافزار از راهنمای Backup و بازیابی فاجعه سایت استفاده کنید.
Support، SLA و قرارداد: قول را به شرط قابل آزمون تبدیل کنید
پشتیبانی ۲۴/۷ فقط میگوید کانال باز است؛ نمیگوید متخصص چه زمانی Incident را میپذیرد یا حل میکند. Severity، Time to acknowledge، Update cadence، Escalation، Scope، زبان، Remote access، Root-cause report و Service credit را بررسی کنید. یک سؤال فروش پیش از خرید، توان Incident نیمهشب را ثابت نمیکند؛ سناریوی فنی و Evidence بخواهید.
| بند | ابهام خطرناک | نسخه قابلممیزی |
|---|---|---|
| Availability | ۹۹٫۹٪ تضمینی | Service/Endpoint، window، probe، formula، exclusion و credit |
| Maintenance | در مواقع لازم | Notice، window، emergency rule و سقف |
| Resource | نامحدود یا منصفانه | Hard/soft limit، throttle، alert و suspension route |
| Support | پاسخگویی سریع | Severity، acknowledge/update/escalation و scope |
| Backup | روزانه و امن | Scope، time، retention، isolation، encryption و restore |
| Security incident | همکاری کامل | Notification، artifact، log retention و forensics boundary |
| Data/IP | مالکیت با مشتری | Export format، completeness، deadline، deletion و account ownership |
| Commercial | قیمت مناسب | Renewal، FX/tax، egress، overage، add-on و refund |
| Exit | انتقال رایگان | Deliverable، assistance hours، DNS/email boundary و termination window |
قیمت ماه اول را با TCO اشتباه نگیرید. Setup/migration، renewal، control panel، backup، WAF/CDN، email، support tier، storage/egress، نیروی عملیات، downtime و Exit را در افق یکسان حساب کنید. محاسبه و Procurement در راهنمای هزینه دامنه و هاست و TCO عمیقتر است.
انتخاب هاست برای کاربران ایرانی: «داخل یا خارج» پاسخ صفر و یک ندارد
مکان دیتاسنتر یکی از عوامل مسیر است، نه حکم قطعی سرعت یا سئو. Peering، ISP، Congestion، TLS، Cache، CDN، Route، Application و دسترسی Provider هم اثر دارند. سرور داخل ممکن است برای بخشی از کاربران داخلی Latency یا دسترسی بهتری بدهد؛ سرور خارج ممکن است برای سرویسهای جهانی، تیم یا کاربران بینالمللی مناسبتر باشد. تصمیم را با Probe چندمسیره و Requirement حقوقی/عملیاتی خودتان بگیرید.
| عامل ایران | پرسش | آزمون/کنترل |
|---|---|---|
| Audience distribution | چه سهمی از Journey حیاتی داخل/خارج است؟ | Field + Synthetic از ISP/Geo مجاز |
| Route/Peering | Latency و Loss در ساعت اوج چگونه است؟ | چند Probe، نه Ping یک دفتر |
| Provider access | خرید، Dashboard، API و Support پایدار و مجازند؟ | Eligibility و مسیر جایگزین مستند |
| FX/Payment | ارز مبنا، تمدید و تغییر قیمت چگونهاند؟ | Scenario و هشدار Renewal |
| Data location | داده، Backup، Log و Processor کجا هستند؟ | Data flow و نظر حقوقی متناسب |
| Search/crawler | Firewall/CDN ربات معتبر را اشتباه نمیبندد؟ | Log، URL Inspection و rule test |
| Payment/SMS/API | از Endpoint میزبان قابل دسترس و قابل Monitor است؟ | Synthetic transaction و failure path |
| Persian support | در Incident چه کسی با چه SLA پاسخ میدهد؟ | Scenario ticket و escalation tree |
| Exit feasibility | اگر پرداخت/دسترسی قطع شد، چقدر سریع خارج میشویم؟ | Export + restore روی مقصد دوم |
آیا هاست ایران برای سئو بهتر است؟
مکان Host را بهعنوان میانبر رتبه فرض نکنید. قابلیت Crawl، پاسخ پایدار، Performance کاربران، URL/Content و سیگنالهای هدفگیری را جدا بسنجید. در مهاجرت Hosting بدون تغییر URL، Google توصیه میکند زیرساخت جدید را پیشاپیش تست کنید، دسترسی Googlebot را بررسی، DNS را تغییر، Log و Crawl را پایش و تنها پس از صفرشدن ترافیک قدیمی آن را خاموش کنید. منبع: Google Search Central: Changing your hosting.
از Longlist تا Pilot: فروشنده را با Evidence انتخاب کنید
مرحله ۱: Knockoutها را پیش از امتیازدهی بررسی کنید
| Knockout | شرط نمونه | Evidence |
|---|---|---|
| Compatibility | نسخه Runtime/DB، extension و workload support | Environment واقعی یا مستند رسمی |
| Access/Ownership | Account سازمانی، MFA، Role و Export | Demo کنترل دسترسی |
| Data/Risk | Location، privacy، deletion و incident condition | Contract و data-flow response |
| Recovery | RPO/RTO و Restore قابل آزمون | Restore drill یا Pilot |
| Critical limit | هیچ limit پنهان Journey را قطع نمیکند | Policy + load result |
| Support | Coverage و Escalation متناسب Criticality | SLA و scenario response |
| Exit | Data/Code/DB/Media/Log قابل انتقالاند | Export sample و termination clause |
مرحله ۲: Weight را پیش از دیدن برند و قیمت ثبت کنید
| معیار | وزن نمونه | شاهد معتبر |
|---|---|---|
| Workload fit/Performance | ۲۰٪ | Pilot نماینده، saturation و latency distribution |
| Reliability/Recovery | ۲۰٪ | SLO/SLA، architecture و restore/failure drill |
| Security/Responsibility | ۱۵٪ | RACI، control evidence و incident terms |
| Operations/Observability | ۱۵٪ | log/metric/export، alert و change workflow |
| Support | ۱۰٪ | scenario، escalation و reference مرتبط |
| TCO/Commercial | ۱۰٪ | هزینه سناریویی و renewal/egress/overage |
| Ownership/Exit | ۱۰٪ | export/restore/migration و contract |
وزن نمونه نسخه عمومی نیست؛ برای فروشگاه پرداختمحور Reliability/Recovery و برای سایت آرشیوی Cost/Durability ممکن است متفاوت باشد. Knockout را با امتیاز بالا در بخش دیگری جبران نکنید.
مرحله ۳: Pilot هفت تا چهاردهروزه بسازید
- Configuration و نسخهها را ثبت و IaC/Runbook یا حداقل Build sheet بسازید.
- نسخهای از Workload با داده امن و شکل نماینده مستقر کنید.
- Functional، Payment callback، Email، Cron، Upload و Admin را بسنجید.
- Load/soak/burst را تا Saturation و سپس Recovery اجرا کنید.
- Restart، Disk pressure، Dependency timeout و Backup/Restore را کنترلشده تمرین کنید.
- Probe ایران/خارج، Log access، Alert، Ticket و Escalation را امتحان کنید.
- Cost meter، quota، egress و صورتحساب سناریو را بررسی کنید.
- Export بگیرید و Restore روی مقصد مستقل را اثبات کنید.
مهاجرت هاست بدون تغییر URL: Cutover را قابل برگشت کنید
| مرحله | کار | Acceptance | Rollback |
|---|---|---|---|
| Inventory | Domain/DNS، Web، DB، Media، Email، Cron، cert، secret و third-party | هیچ Dependency بیOwner نیست | توقف قبل از Copy |
| Build | Destination، security، monitoring و backup | Build sheet و access test | حفظ مقصد جدا |
| Copy | Full copy + incremental/CDC plan | Count/checksum/reconciliation | Source read/write policy |
| Preflight | Host override/temp hostname، Journey، crawler و performance | Exit criteria امضا شده | اصلاح بدون اثر عمومی |
| DNS/Cutover | TTL از قبل، change window، record update | Probe چندResolver/ISP | Record قبلی و TTL plan |
| Observe | Traffic، error، latency، order/lead، crawl و old/new log | Guardrail در پنجره تثبیت | Trigger و تصمیمگیر مشخص |
| Decommission | تنها پس از قطع ترافیک قدیمی و backup | Evidence، revoke و secure deletion | Retention محدود پیش از حذف |
اگر URLها تغییر نمیکنند، Redirect عمومی لازم نیست؛ DNS/Endpoint تغییر میکند. اگر همزمان Domain، Protocol یا Path را عوض کنید، آن یک URL migration جدا با Mapping و ۳۰۱ است. Freeze تغییر، Sync نهایی داده تراکنشی، TTL، Queue/Session و Email DNS را از قلم نیندازید.
برنامه ۳۰روزه انتخاب و اثبات هاست
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۳ | Outcome، Journey، Criticality و Owner | Hosting decision charter | مرز تصمیم روشن است |
| روز ۴ تا ۷ | Workload/traffic/data/dependency/ops inventory | Workload profile و سه سناریو | Peak و unknownها دیده شدهاند |
| روز ۸ تا ۱۰ | SLI/SLO، RPO/RTO، Security و Exit requirements | Acceptance pack و Knockout | هر Requirement شاهد دارد |
| روز ۱۱ تا ۱۳ | مدل سرویس، RACI و Longlist | Shared/Managed/VPS/Cloud options | برچسبها به مسئولیت ترجمه شدند |
| روز ۱۴ تا ۱۶ | RFI، Contract، Limit، Support و TCO | Shortlist همسطح | ابهام حیاتی باقی نمانده |
| روز ۱۷ تا ۲۴ | Pilot، load، failure، restore، support و exit | Evidence pack و score | Workload نماینده پاس شده است |
| روز ۲۵ تا ۲۷ | Migration/rollback و communication rehearsal | Runbook زماندار | Go/no-go owner مشخص است |
| روز ۲۸ تا ۳۰ | Cutover یا تصمیم خرید، monitor و review | Baseline، contract و next capacity review | Actual در برابر فرض اندازهگیری میشود |
چکلیست نهایی انتخاب بهترین هاست
- Domain، DNS، CDN، Email، Origin و Application را بهعنوان سرویسهای جدا میشناسیم.
- Workload شامل Journey، Peak/Concurrency، Read/Write، Data، Job، Dependency و Audience path است.
- Stack/Version و Requirementهای فنی با مرجع زنده بررسی شدهاند.
- Criticality به SLI/SLO و RPO/RTO قابل اندازهگیری ترجمه شده است.
- SLA، پنجره، Formula، Exclusion، Maintenance و Credit روشناند.
- مدل Shared/Managed/VPS/Cloud/PaaS/Dedicated بر اساس Control و Ops fit انتخاب شده است.
- vCPU، RAM، worker، DB، IOPS، inode، network، process و quota فقط اسمی نیستند.
- Unlimited، overage، throttle و suspension policy خوانده شدهاند.
- Performance با Journey نماینده، percentile، Error، throughput و saturation سنجیده شده است.
- Single point، Failure domain، failover و dependency در معماری دیده شدهاند.
- Shared responsibility برای Patch، Access، App، Data، Log، Backup و Incident RACI دارد.
- Backup مستقل و Restore آزموده با RPO/RTO وجود دارد.
- Observability، Export log، Alert، Owner و Runbook قابل پذیرشاند.
- Support با Severity، زمان پذیرش، Update، Escalation و Scope آزموده شده است.
- مخاطب ایران با چند ISP/زمان و وابستگی Payment/SMS/API سنجیده شده است.
- FX، Renewal، Egress، نیروی عملیات، Downtime و Exit در TCO آمدهاند.
- Pilot شامل Load، Soak، Failure، Restore، Ticket، Bill و Export بوده است.
- Migration دارای Inventory، Sync، DNS، Guardrail، Rollback و Decommission evidence است.
سؤالات متداول
برای سایت تازهکار، هاست اشتراکی بهتر است یا VPS؟
اگر Workload کمریسک است و تیم Sysadmin ندارید، Shared مدیریتشده با Isolation، Backup و Support اثباتشده میتواند مناسبتر باشد. VPS زمانی ارزش دارد که Control یا Resource boundary مشخص نیاز دارید و مسئول Patch، Monitoring و Recovery را واقعاً پوشش میدهید. با Pilot تصمیم بگیرید، نه عنوان پلن.
هاست ابری بهتر است یا سرور اختصاصی؟
هیچکدام مطلقاً بهتر نیست. Cloud برای Provisioning، Measured service و Elasticity ظرفیت میدهد، اما HA و Cost control باید طراحی شوند. Dedicated برای Hardware/Isolation یا بار پایدار مناسب است، ولی Single point و عملیات دارد. Workload، SLO، Team و TCO تعیینکنندهاند.
چقدر RAM و CPU برای وردپرس یا ووکامرس لازم است؟
از تعداد بازدید نمیتوان عدد عمومی داد. Theme/Plugin، Cache hit، PHP worker، Query، Product/Cart/Checkout mix، Cron، Import و Concurrency اثر دارند. Replica نماینده را Load کنید و نقطه Saturation CPU/Memory/worker/DB را با Latency و Error بسنجید.
آیا آپتایم ۹۹٫۹٪ برای انتخاب هاست کافی است؟
خیر. باید Endpoint، روش و مکان اندازهگیری، پنجره، Maintenance، Exclusion و پیامد نقض روشن باشد. Uptime ماشین ممکن است شکست Checkout را نبیند؛ Outside-in Journey، Error rate، Latency و Business outcome را نیز پایش کنید.
آیا هاست ایران سرعت یا سئوی بهتری میدهد؟
ممکن است برای بخشی از کاربران داخلی مسیر کوتاهتر یا پایدارتر باشد، اما نتیجه به ISP/Peering، CDN، Application و زمان وابسته است. برای SEO نیز مکان Host میانبر رتبه نیست؛ Crawlability، پاسخ پایدار و تجربه واقعی را بسنجید. Probe ایران/خارج و Pilot معتبرتر از حکم کلیاند.
جمعبندی
بهترین هاست نام یک محصول نیست؛ انطباق اثباتشده میان Workload، Criticality، SLO، Responsibility، Capacity، Recovery، Support، TCO و Exit است. مشخصات را از بروشور به Limit و Evidence تبدیل کنید، «Cloud/Managed/Unlimited» را تعریف کنید، با Journey واقعی از ایران Pilot بگیرید و Restore و مهاجرت را پیش از وابستگی تمرین کنید. آنوقت انتخاب شما بر پایه امید به برند یا گیگابایت نیست؛ یک تصمیم عملیاتی قابل بازبینی است.
