هاستینگ سبز چیست؟ راهنمای سنجش کربن و انتخاب میزبان

چرا پایداری میزبانی اکنون مسئله است؟

اثر دیجیتال نامرئی است، اما زیرساخت آن فیزیکی است: Server، Storage، Network، UPS، Cooling، ساختمان، آب و برق. افزایش AI و خدمات دیجیتال این بار را بالا می‌برد. طبق گزارش رسمی Energy and AI آژانس بین‌المللی انرژی، مراکز داده در سال ۲۰۲۴ حدود ۴۱۵ تراوات‌ساعت، معادل نزدیک ۱٫۵٪ برق جهان، مصرف کردند؛ سناریوی پایهٔ IEA این عدد را برای ۲۰۳۰ حدود ۹۴۵ تراوات‌ساعت برآورد می‌کند.

این برآورد جهانی را نباید مستقیم به «هر بازدید سایت» تبدیل کرد. سهم یک سرویس به معماری، Utilization، نوع Hardware، Location، زمان اجرا، شبکه، Cache و روش تخصیص بستگی دارد. مقایسهٔ کلی اینترنت با صنعت هوانوردی نیز بدون سال، مرز و روش مشترک گمراه‌کننده است.

هدف معقول سه بخش دارد: تقاضای غیرضروری را حذف کنیم، کار لازم را با منابع کم‌تر انجام دهیم و برای انرژی و انتشار باقی‌مانده شواهد باکیفیت بخواهیم.

هاستینگ سبز چیست؟ تعریف عملی به‌جای برچسب

هاستینگ سبز یا میزبانی وب پایدار، سرویسی است که اثر محیط‌زیستی چرخهٔ میزبانی را با روش شفاف اندازه می‌گیرد و کاهش می‌دهد. یک تعریف کامل فقط منبع برق را نمی‌بیند؛ Facility، Hardware، Software، Network، آب، عمر تجهیزات و پایان عمر نیز بخشی از سیستم‌اند.

اگر Provider فقط خرید Offset را نشان دهد، «کربنِ جبران‌شده» ممکن است ادعای مناسب‌تری از «زیرساخت سبز» باشد. اگر فقط PUE پایین دارد، دربارهٔ بهره‌وری Facility حرف می‌زند، نه کل اثر محیطی.

مرز اندازه‌گیری را قبل از عدد مشخص کنید

هر عدد بدون این پنج جزء ناقص است: Boundary، Period، Unit، Allocation و Source. برای نمونه، PUE یک Building در یک روز سرد با PUE کل Campus در ۱۲ ماه قابل مقایسه نیست؛ انتشار یک VM مشترک نیز بدون روش Allocation از انتشار Facility به‌دست نمی‌آید.

عدد Estimate می‌تواند برای تصمیم داخلی مفید باشد، به شرط آنکه از Metered data جدا، فرض‌ها ثبت و عدم‌قطعیت اعلام شود.

تفاوت Renewable، Carbon-free، Carbon neutral و Net zero

در راهنمای Scope ۲ پروتکل گازهای گلخانه‌ای، گزارش برق خریداری‌شده به دو نمای Location-based و Market-based تفکیک می‌شود. Location-based ترکیب متوسط شبکهٔ محل مصرف را بازتاب می‌دهد؛ Market-based ابزارهای قراردادی و Attributeها را، مشروط به معیارهای کیفیت، لحاظ می‌کند. برای تصمیم شفاف، هر دو نما را کنار هم بخواهید.

انرژی تجدیدپذیر، Certificate و Offset یک چیز نیستند

تأمین در محل یا خط مستقیم

ارتباط فیزیکی و Attribute باید روشن باشد. وجود پنل خورشیدی روی ساختمان لزوماً کل بار سالانه یا شبانهٔ مرکز داده را پوشش نمی‌دهد؛ نسبت تولید، مصرف، فروش Attribute و برق شبکه را بخواهید.

قرارداد خرید و Energy Attribute Certificate

PPA، REC، GO یا ابزار مشابه می‌تواند تقاضای بازار برای برق کم‌کربن را پشتیبانی کند، اما کیفیت به یکتایی Attribute، Registry، Retirement، Vintage، Geography و نبود Double counting وابسته است. خرید ۱۰۰ واحد Attribute سالانه لزوماً به معنای مصرف فیزیکی ۱۰۰٪ پاک در هر ساعت نیست.

Carbon credit یا Offset

Credit باید پس از اندازه‌گیری و کاهش مستقیم بررسی شود. Additionality، Permanence، Leakage، Verification و Retirement را بسنجید. Offset ضعیف نباید برق پرکربن یا Waste قابل حذف را پنهان کند.

Scope ۱، ۲ و ۳ در میزبانی وب

برای مشتری Hosting، انتشار سرویس خریداری‌شده معمولاً در زنجیرهٔ ارزش خود او قرار می‌گیرد، اما Category دقیق به Inventory سازمان و راهنمای حسابداری آن بستگی دارد. عدد Provider را بدون بررسی Boundary و Allocation مستقیماً در گزارش شرکتی کپی نکنید.

شاخص‌های کلیدی: PUE، WUE، CUE، REF و SCI

ISO/IEC 30134-2:2026، PUE را نسبت انرژی کل مرکز داده در دورهٔ پیوستهٔ ۱۲ماهه به انرژی تجهیزات IT در همان دوره تعریف می‌کند. خود خانوادهٔ استاندارد نیز Target عمومی مانند «هر PUE زیر ۱٫۲ سبز است» تعیین نمی‌کند؛ Climate، Load، Boundary و Measurement category بر مقایسه اثر دارند.

برای آب، راهنمای وزارت انرژی آمریکا WUE سایت را با واحد لیتر بر kWh انرژی IT توضیح می‌دهد. PUE پایین می‌تواند در بعضی طراحی‌ها با مصرف آب بیش‌تر همراه شود؛ بنابراین آب و انرژی را هم‌زمان ببینید، به‌خصوص در منطقهٔ دچار تنش آبی.

چرا PUE پایین به‌تنهایی هاست را سبز نمی‌کند؟

• منبع برق: دو Facility با PUE یکسان می‌توانند شدت کربن شبکهٔ متفاوت داشته باشند.
• Utilization: PUE دربارهٔ مفید بودن محاسبه نمی‌گوید؛ سرور Idle هم انرژی IT حساب می‌شود.
• آب: Cooling کم‌برق ممکن است آب بیش‌تری مصرف کند.
• سخت‌افزار: جایگزینی زودهنگام برای PUE بهتر می‌تواند انتشار ساخت را بالا ببرد.
• مرز: عدد Design یا بهترین ماه با Average واقعی ۱۲ماهه قابل قیاس نیست.
• بار مشتری: PUE Facility سهم VM یا Request شما را بدون Allocation مشخص نمی‌کند.

به‌جای رتبه‌بندی تک‌عددی، یک Dashboard چندشاخصی بسازید: انرژی، Location/Market emissions، آب، Renewable matching، Hardware lifecycle، Service output و SLO.

SCI؛ سنجش کربن به‌ازای کار مفید

مشخصات Software Carbon Intensity بنیاد Green Software، انرژی مصرفی E، شدت کربن منطقه I، انتشار نهفتهٔ سخت‌افزار M و واحد عملکردی R را کنار هم می‌گذارد. ارزش اصلی روش، وادارکردن تیم به تعریف «کار مفید» است.

اگر R را «هر Request» بگیرید، شکستن یک کار به Requestهای بیش‌تر ممکن است ظاهراً عدد را بهتر یا بدتر کند. واحد باید Outcome پایدار و قابل مقایسه باشد.

هر ادعای هاستینگ سبز چه شواهدی لازم دارد؟

رتبه یا گواهی را نیز از صادرکننده و Registry اصلی راستی‌آزمایی کنید. لوگوی قابل دانلود یا PDF بدون شماره، دامنه و تاریخ، Verification نیست.

پرسش‌نامه انتخاب میزبان سبز

Facility و انرژی

1. سرویس ما دقیقاً در کدام کشور، Region و Facility اجرا می‌شود؟ Operator چه شرکتی است؟
2. انرژی کل و IT در ۱۲ ماه گذشته چقدر بوده و PUE با کدام Category/Boundary محاسبه شده است؟
3. WUE و منبع آب چیست؟ آیا آب مصرف برق نیز جدا گزارش می‌شود؟
4. عامل انتشار شبکه، سال و منبع Location-based چیست؟
5. نتیجهٔ Market-based و ابزار قراردادی آن چیست؟
6. Certificateها در کدام Registry، برای چه Vintage/Geography و به نام چه موجودیتی Retire شده‌اند؟
7. Backup generator و Refrigerant در کدام Scope حساب می‌شوند؟

سخت‌افزار و سرویس

8. Utilization، سیاست Right-sizing و چرخهٔ Refresh سخت‌افزار چیست؟
9. انتشار Embodied چگونه بر عمر و مشتریان تخصیص می‌یابد؟
10. محصول شما برای VM-hour، GB-hour یا Request دادهٔ انرژی/کربن می‌دهد؟
11. آیا داده از Meter است یا Model؟ عدم‌قطعیت و نسخهٔ Methodology چیست؟
12. Storage replica، Backup، Snapshot و Egress داخل عدد محصول هستند؟
13. سرنوشت Server و Disk در پایان عمر و روش حذف امن داده چیست؟

قرارداد و عملیات

14. آیا Claim پایداری در Order form/SLA الزام‌آور است یا فقط Marketing؟
15. تغییر Facility، Energy procurement یا Methodology چگونه اطلاع داده می‌شود؟
16. گزارش ماهانه یا سالانه تا چه مدت قابل دریافت است؟
17. مالک داده، Domain، Backup و Export کیست و Exit چگونه انجام می‌شود؟
18. SLO، Incident، Security، Support و Disaster recovery چیست؟
19. اگر دسترسی یا پرداخت برون‌مرزی مختل شد، Grace period و مسیر بازیابی چیست؟
20. کدام نهاد مستقل کدام Scope، دوره و Facility را Assurance کرده است؟

ماتریس امتیازدهی؛ پایداری را از کیفیت میزبانی جدا نکنید

وزن را با Risk سازمان تنظیم کنید. یک فروشگاه پرتراکنش نمی‌تواند Security یا Recovery را با PUE بهتر معاوضه کند. برای ارزیابی Isolation و مهاجرت راهنمای امنیت هاست اشتراکی را نیز اجرا کنید.

ردپای کربن وب‌سایت را چگونه اندازه بگیریم؟

ماشین‌حساب‌های عمومی Page weight برای مقایسهٔ اولیه مفیدند، اما Meter برق مرکز داده نیستند. عدد قابل دفاع را پله‌ای بسازید.

1. Functional unit: مثلاً ۱٬۰۰۰ Page view واقعی، سفارش موفق یا Job پردازش‌شده.
2. System boundary: Origin، Database، Storage، CDN، Network و در صورت نیاز Device.
3. Activity data: vCPU/instance-hour، Utilization، GB-hour، Request، Query، Transfer و Cache hit.
4. Energy allocation: دادهٔ Provider یا Model ثبت‌شده، جدا برای Estimate و Meter.
5. Carbon intensity: عامل Location و زمان متناسب؛ اگر Hourly data ندارید، ادعای Carbon-aware دقیق نکنید.
6. Embodied allocation: سهم Hardware بر اساس ظرفیت/زمان/عمر با فرض شفاف.
7. Uncertainty: Range و حساسیت به Traffic، Cache، Region و Emission factor.

Baseline نمونه

برای آنکه کاهش Byte به آسیب UX تبدیل نشود، Outcome و Guardrail را کنار انرژی بسنجید.

پیش از تعویض هاست، تقاضای محاسباتی را کم کنید

انتقال یک سایت پراتلاف به Facility کم‌کربن بخشی از مسئله را حل می‌کند؛ حذف Waste معمولاً کنترل‌پذیرتر و قابل سنجش‌تر است. Web Sustainability Guidelines از W3C توصیه‌های میان‌رشته‌ای برای طراحی و عملیات پایدار ارائه می‌کند و هم‌زمان هشدار می‌دهد که این سند Draft و در حال تکامل است و نباید به‌تنهایی شاهد «پایداری کامل» یا Claim بازاریابی باشد.

محتوا و دارایی

• تصویر را در ابعاد نمایش، Format مناسب، Quality بودجه‌بندی‌شده و Responsive delivery ارائه کنید.
• ویدئو را Autoplay نکنید؛ Poster، Transcript و Adaptive bitrate بدهید.
• Font فارسی را Subset و Self-host یا با Cache مناسب تحویل دهید؛ تعداد Weightها را کم کنید.
• صفحه و Media بدون مالک یا بدون مصرف را با سیاست Retention حذف/Archive کنید.

Front-end و Third-party

• JavaScript غیرضروری، Polyfill قدیمی، Tracker تکراری و Widget کم‌ارزش را حذف کنید.
• Code splitting، Lazy load کنترل‌شده و Server rendering را با اندازه‌گیری واقعی به‌کار ببرید.
• Performance budget را در CI برای JS، CSS، Image، Request و CPU time اعمال کنید.
• Consent و Privacy را قربانی حذف چند Request نکنید؛ پایداری، حریم خصوصی و Accessibility هم‌هدف‌اند.

Back-end و Database

• N+۱ Query، Polling، Cron بی‌مصرف، Retry storm و Log پرحجم را پیدا کنید.
• Cache را بر اساس Freshness و Invalidation طراحی کنید؛ «همه‌چیز Forever» درست نیست.
• Instance را Right-size و محیط Dev/Staging بلااستفاده را زمان‌بندی یا خاموش کنید.
• Storage tier و Retention را با نیاز حقوقی/عملیاتی تنظیم و Backup تکراری را کنترل کنید.

برای طراحی Header و Cache چندلایه، راهنمای معماری Cache سایت را ببینید.

CDN همیشه انتشار را کم نمی‌کند؛ با Hit ratio تصمیم بگیرید

CDN می‌تواند فاصله، Latency و بار Origin را کم کند، اما Replica، Purge، Miss و انتقال اضافی نیز دارد. اثر را با Cache hit ratio، Bytes از Origin، Region واقعی مخاطب و انرژی/کربن Provider بسنجید.

برای مخاطب ایران، راهنمای انتخاب CDN و PoC چنداپراتوری کمک می‌کند Latency، Route، Cache و Failover را واقعی بسنجید.

رابطه هاستینگ سبز با سرعت و سئو چیست؟

سبز بودن میزبان یک Ranking factor اعلام‌شده نیست و از خرید سرویس سبز نمی‌توان بهبود رتبه را نتیجه گرفت. SSD، NVMe یا PUE پایین نیز تضمین TTFB و Core Web Vitals نیستند. Software stack، Cache، Database، فاصلهٔ شبکه، بار همسایه و کیفیت Front-end تعیین‌کننده‌اند.

بهینه‌سازی‌هایی مانند کاهش JS، فشرده‌سازی تصویر و Cache می‌توانند هم Resource use و هم تجربهٔ کاربر را بهتر کنند؛ این یک هم‌راستایی عملی است، نه اثر مستقیم Badge سبز بر SEO. LCP، INP و CLS را با دادهٔ میدانی و Template واقعی بسنجید؛ راهنمای Core Web Vitals و RUM روش کامل را توضیح می‌دهد.

Carbon-aware computing؛ فقط با داده و Guardrail

اگر Workload انعطاف‌پذیر و دادهٔ معتبر شدت کربن زمانی/مکانی دارید، Job غیر فوری می‌تواند به زمان یا Region کم‌کربن‌تر منتقل شود. اما جابه‌جایی بدون مرز درست ممکن است Latency، Data residency، Egress، Replica و Recovery را بدتر کند.

در نبود عامل ساعتی معتبر برای Region، از Average و Range با برچسب Estimate استفاده کنید و ادعای «اجرای کم‌کربن لحظه‌ای» نسازید.

پایداری بدون Resilience پایدار نیست

حذف Replica یا Backup برای کم‌کردن Storage ممکن است Incident و بازسازی پرهزینه ایجاد کند. هدف، حذف افزونگی بی‌هدف است، نه کنترل حیاتی. Availability tier را بر اساس Business impact انتخاب کنید.

• RTO و RPO را تعریف و Restore را تمرین کنید.
• Backup immutable و Retention را متناسب با Risk نگه دارید.
• Health check، Synthetic monitoring و Alert actionable داشته باشید.
• ظرفیت Headroom را با Load test تعیین کنید، نه حدس یا صفرکردن.
• Incident، Retry storm و Failover را در Energy/Carbon review لحاظ کنید.

راهنمای مانیتورینگ آپتایم برای طراحی Check، هشدار، SLO و Runbook کاربردی است.

انتخاب هاست سبز در ایران؛ محدودیت‌ها را داخل مدل تصمیم ببرید

برای کسب‌وکار ایرانی، دسترسی به دادهٔ Facility و عامل انتشار ساعتی ممکن است محدود باشد. نبود داده را با Badge پر نکنید؛ آن را Risk و Data gap ثبت و سطح Claim را کاهش دهید.

میزبان داخل کشور

از فروشنده بخواهید نام یا حداقل Location و Operator مرکز داده، مصرف و PUE دوره‌ای، منبع برق، Backup generator، روش Cooling و WUE را ارائه کند. اگر فقط «دیتاسنتر سبز» گفته می‌شود، Claim قابل ممیزی ندارید. برای مخاطب عمدتاً داخلی، Latency و مسیر شبکه می‌تواند هم تجربه و هم Transfer اضافی را کم کند، اما باید با تست چنداپراتوری ثابت شود.

میزبان یا Cloud خارجی

Region-level carbon data، Contract و گزارش محصول ممکن است بهتر باشد، ولی دسترسی، پرداخت، نرخ ارز، Data governance، Support، تحریم/سیاست Vendor و Latency ریسک‌اند. از روش غیررسمی برای حساب حیاتی به‌عنوان معماری پایدار استفاده نکنید؛ Exit و Grace period لازم است.

معماری Hybrid

تقسیم Origin، CDN، Media و Backup میان چند محل می‌تواند Performance و Resilience را بهتر کند، اما Transfer، Replica و Boundary حسابداری را پیچیده می‌کند. Data flow و Inventory واحد بسازید تا انتشار دوبار شمرده یا فراموش نشود.

مثال فرضی؛ فروشگاه ایرانی پرترافیک

فروشگاهی با ۲ میلیون Page view ماهانه، تصاویر بزرگ، Cache hit برابر ۴۵٪ و Origin با CPU متوسط ۲۵٪ می‌خواهد به «هاست سبز» مهاجرت کند. تیم به‌جای انتخاب با Badge، چهار مرحله اجرا می‌کند:

1. Baseline: Byte/view، Request/view، vCPU-hour، Storage، Transfer، سفارش موفق، LCP و Incident ثبت می‌شوند.
2. کاهش: تصویر Responsive، حذف Script ثالث، TTL برای Asset نسخه‌دار و Full-page cache برای صفحهٔ غیرشخصی؛ Hit ratio به‌عنوان KPI تعیین می‌شود.
3. Right-size: پس از کاهش Peak و CPU، Instance با Headroom مبتنی بر Load test کوچک می‌شود.
4. Procurement: دو میزبان با Location-based/Market-based، PUE/WUE، SLA، Security، Restore و TCO مقایسه می‌شوند.

اگر Byte/view نصف شود ولی Conversion به‌دلیل تصویر بی‌کیفیت افت کند، پروژه موفق نیست. اگر Provider سبز Latency پرداخت را بالا ببرد، Origin فروشگاه می‌تواند نزدیک کاربر بماند و Jobهای انعطاف‌پذیر در Region دیگر اجرا شوند—فقط پس از آزمون Egress، داده و Recovery.

عددهای هدف نمونه‌اند؛ تیم باید آن‌ها را با Baseline و Risk خودش تصویب کند.

PoC و مهاجرت به هاست سبز بدون قطعی

۱. Inventory و معیار پذیرش

Domain/DNS، Runtime، Database، Cron، Queue، Mail، Media، Secret، Certificate، Backup، Integration، Redirect و حجم/نرخ تغییر داده را فهرست کنید. SLO، RTO/RPO، Performance budget و Sustainability evidence را شرط پذیرش کنید.

۲. PoC با بار واقعیِ غیرحساس

یک Template و مسیر واقعی را با دادهٔ Sanitized Deploy کنید. Load، Latency چند ISP، Cache، Email، Cron، Security، Backup/Restore و Export گزارش پایداری را تست کنید.

۳. همگام‌سازی و Cutover

TTL را با برنامه کم کنید، Backup کامل و Delta sync بگیرید، Freeze window و Rollback trigger مشخص کنید. ابتدا Canary traffic و سپس سهم بیش‌تر را منتقل کنید. Status، Error، Query، Queue و تراکنش را پایش کنید.

۴. پس از انتقال

Redirect/Canonical و Sitemap، Jobها، Email reputation، Backup و دسترسی حساب را بررسی کنید. سرویس قدیمی را تا پایان Window بازیابی حذف نکنید. سپس داده را طبق روش امن پاک و گزارش Baseline/After را ثبت کنید.

هزینه واقعی هاستینگ سبز و TCO

قیمت Plan را با TCO اشتباه نگیرید:

TCO = Compute + Storage + Backup + Transfer/Egress + CDN + Support + Security + Monitoring + Migration + Downtime risk + Exit − صرفه‌جویی Right-sizing

سه سناریوی Base/High traffic/Access disruption بسازید. هزینهٔ Green claim مستقل، گزارش Assurance یا Carbon data ممکن است فقط در Plan سازمانی باشد. از طرف دیگر، کاهش Waste و Right-sizing می‌تواند هزینه را کم کند؛ هیچ‌کدام را بدون Quote و مصرف واقعی قطعی فرض نکنید.

کنترل پایداری باید کنار بودجهٔ ریسک قرار گیرد؛ راهنمای بودجه امنیت سایت نشان می‌دهد چگونه هزینه را با Business impact و Roadmap متصل کنید.

Dashboard و روش گزارش‌دهی بدون Greenwashing

ادعای عمومی را محدود و دقیق بنویسید: «مصرف تخمینی Compute به‌ازای سفارش در Q2 نسبت به Baseline تعریف‌شده ۱۸٪ کم شد» قابل دفاع‌تر از «وب‌سایت ما بدون کربن است». مرز، دوره، روش، داده و محدودیت را همان‌جا لینک کنید. درصد نیز فقط وقتی منتشر شود که Baseline و محاسبهٔ معتبر دارید.

برنامه ۳۰/۶۰/۹۰روزه میزبانی پایدار

هر فصل Measurement و Claim را بازبینی کنید؛ تغییر Region، Plan، Traffic، Grid factor یا Methodology می‌تواند مقایسه را بشکند.

چک‌لیست نهایی انتخاب هاستینگ سبز

• Facility، Region، Operator و Period عددها مشخص‌اند.
• PUE با Boundary و دادهٔ ۱۲ماهه گزارش شده، نه Design/best month.
• WUE و تنش آبی محل کنار انرژی بررسی شده‌اند.
• Scope ۲ به دو روش Location-based و Market-based دیده شده است.
• Certificate/PPA دارای Vintage، Geography، Registry و Retirement است.
• Renewable، Carbon-free، Neutral و Net-zero در Claim خلط نشده‌اند.
• Offset پس از کاهش و با کیفیت/Retirement روشن استفاده می‌شود.
• Utilization، Right-size و انتشار ساخت Hardware بررسی شده‌اند.
• روش Allocation سرویس مشترک و عدم‌قطعیت مستند است.
• Functional unit محصول برای سنجش SCI/شدت تعریف شده است.
• Cache، Asset، Code، Query، Log و Retention پیش از مهاجرت بهینه شده‌اند.
• Performance، Security، Privacy و Accessibility Guardrail دارند.
• SLO، Backup/Restore، Incident و Exit در PoC پاس شده‌اند.
• ریسک دسترسی، ارز، پرداخت و Support برای ایران سناریوسازی شده است.
• ادعای عمومی به Evidence pack، مرز و تاریخ متصل است.