اگر سایت شما بعد از انتشار فقط زمانی بررسی میشود که فرم تماس از کار بیفتد، سرعت افت کند یا یک خطای جدی دیده شود، عملاً پشتیبانی سایت ندارید و صرفاً به مشکلات واکنش نشان میدهید. پشتیبانی سایت مجموعهای از فعالیتهای مستمر فنی، امنیتی، محتوایی و کنترلی است که کمک میکند وبسایت فعال، قابل دسترس، بهروز، امن و قابل توسعه بماند. دامنه این خدمات میتواند از بروزرسانی CMS و افزونهها، بکاپ و مانیتورینگ Uptime تا رفع خطا، بررسی فرمها، کنترل سرعت، تغییرات کوچک محتوا و گزارش دورهای را پوشش دهد. در این راهنما دقیقاً بررسی میکنیم پشتیبانی سایت چیست، چه خدماتی معمولاً داخل قرارداد قرار میگیرد، چه مواردی باید جداگانه تعریف شود، تفاوت پشتیبانی با هاست و توسعه چیست و کسبوکار چگونه میتواند یک پلن مناسب و قابلاندازهگیری انتخاب کند.
خلاصه کاربردی: پشتیبانی خوب فقط «رفع خرابی» نیست. ترکیبی از پیشگیری، پایش، بکاپ قابل بازیابی، بروزرسانی کنترلشده، امنیت، رفع خطا و پاسخگویی با دامنه مسئولیت روشن است.
پشتیبانی سایت چیست؟
پشتیبانی سایت یا Website Support به فرایند مستمر نگهداری و مراقبت از یک وبسایت پس از راهاندازی گفته میشود. هدف این فرایند این است که سایت در طول زمان از نظر عملکرد فنی، امنیت، دسترسپذیری، سرعت، سازگاری اجزا و محتوای ضروری در وضعیت قابل اتکا باقی بماند. در یک سایت وردپرسی این موضوع معمولاً شامل هسته وردپرس، قالب، افزونهها، پایگاه داده و فایلهاست. در سایتهای اختصاصی نیز وابستگیهای نرمافزاری، Backend، Frontend، APIها، سرویسهای جانبی، سرور و فرایند استقرار بخشی از تصویر هستند.
بنابراین پشتیبانی سایت یک کار واحد نیست. ممکن است یک درخواست روزمره مثل اصلاح شماره تماس فقط چند دقیقه زمان ببرد، اما در همان قرارداد مسئولیتهای مهمتری مثل بررسی نسخه پشتیبان، کنترل خطاهای ۵xx، بروزرسانی امنیتی یا واکنش به اختلال هم تعریف شده باشد.
معیار کیفیت پشتیبانی این نیست که «چند تیکت بسته شد»، بلکه این است که سایت تا چه حد قابل پیشبینی، قابل بازیابی و قابل اتکا باقی میماند.
پشتیبانی سایت چه تفاوتی با هاست، طراحی و توسعه دارد؟
یکی از رایجترین ابهامها این است که پشتیبانی با هاستینگ یا توسعه سایت یکسان در نظر گرفته میشود. این سه حوزه به هم مرتبطاند، اما مسئولیت متفاوتی دارند.
| حوزه | مسئولیت اصلی | نمونه کارها |
|---|---|---|
| هاست و زیرساخت | فراهمکردن محیط اجرا | منابع سرور، شبکه، SSL، تنظیمات زیرساخت و دسترسپذیری سرویس |
| پشتیبانی و نگهداری | سالم نگهداشتن سایت فعال | بروزرسانی، بکاپ، مانیتورینگ، رفع خطا، امنیت، کنترل عملکرد |
| توسعه | افزودن یا تغییر قابلیت | ساخت ماژول جدید، بازطراحی، اتصال API جدید، تغییر معماری |
برای مثال اگر درگاه پرداخت موجود ناگهان خطا دهد، بررسی و رفع خطای آن میتواند در دامنه پشتیبانی باشد. اما اگر کسبوکار تصمیم بگیرد یک روش پرداخت جدید با منطق سفارشی اضافه کند، این معمولاً پروژه توسعه محسوب میشود. مرز دقیق باید در قرارداد روشن باشد تا درخواستهای روزمره به اختلاف درباره دامنه کار تبدیل نشوند.
خدمات پشتیبانی سایت معمولاً شامل چه مواردی میشود؟
۱. بروزرسانی CMS، افزونهها، قالب و وابستگیها
سامانه مدیریت محتوا، افزونهها، قالب و کتابخانههای نرمافزاری در طول زمان نسخههای جدید دریافت میکنند. بخشی از این بروزرسانیها امکانات تازه میآورند و بخشی برای رفع باگ یا آسیبپذیری امنیتی منتشر میشوند. مستندات WordPress توصیه میکند افزونهها و قالبها بهروز نگه داشته شوند و پیش از اتکا به بروزرسانی خودکار، امکان بازگشت به نسخه قبلی از طریق بکاپ در نظر گرفته شود.
در یک فرایند حرفهای، بروزرسانی حساس بهتر است ابتدا روی محیط Staging یا نسخه آزمایشی بررسی شود. سپس صفحات کلیدی، فرمها، ورود کاربر، سبد خرید و مسیر پرداخت تست شوند. نصب بیبرنامه هر نسخه جدید روی سایت Production ممکن است تضاد افزونه، خطای ظاهری یا مشکل عملکرد ایجاد کند.
۲. بکاپگیری و امکان بازیابی
وجود یک فایل بکاپ بهتنهایی کافی نیست. نسخه پشتیبان باید منظم، دارای سیاست نگهداری مشخص، ترجیحاً خارج از همان سرور اصلی و قابل Restore باشد. مستندات WordPress نیز بر نگهداری نسخه پشتیبان از فایلها و پایگاه داده تأکید میکند. اگر بکاپ فقط روی همان فضایی باشد که سایت روی آن قرار دارد، خرابی یا دسترسی غیرمجاز به سرور میتواند هم سایت و هم نسخههای پشتیبان را تحت تأثیر قرار دهد.
- تناوب بکاپ باید با نرخ تغییر اطلاعات متناسب باشد.
- فروشگاه یا سامانه پرتراکنش به نسخههای مکررتر از یک سایت معرفی ساده نیاز دارد.
- دوره نگهداری بکاپ باید روشن باشد.
- تست بازیابی دورهای ارزش بیشتری از صرفاً مشاهده پیام «Backup Successful» دارد.
۳. امنیت، کنترل آسیبپذیری و مدیریت دسترسی
امنیت سایت یک محصول یکباره نیست. پشتیبانی امنیتی میتواند شامل بررسی نسخههای آسیبپذیر، بروزرسانی اصلاحیهها، پایش فایلهای مشکوک، کنترل تلاشهای ورود، محدودکردن سطح دسترسی، بازبینی حسابهای مدیر، تنظیم Firewall یا WAF و واکنش به هشدارها باشد. OWASP نیز مدیریت مداوم وابستگیهای نرمافزاری و رصد آسیبپذیریهای اجزای ثالث را بخشی مهم از کاهش ریسک زنجیره تأمین نرمافزار میداند.
نکته مهم این است که هیچ قرارداد پشتیبانی نمیتواند «امنیت صددرصدی» وعده دهد. چیزی که باید سنجیده شود کیفیت کنترلها، سرعت واکنش، امکان بازیابی، حداقلسازی سطح دسترسی و فرایند رسیدگی به رخداد است.
۴. مانیتورینگ Uptime و خطاهای عملیاتی
اگر اولین کسی که متوجه قطعی سایت میشود مشتری باشد، مانیتورینگ کافی نیست. پایش Uptime میتواند در فاصلههای مشخص سایت را بررسی و در صورت اختلال هشدار ایجاد کند. برای سایتهای پیچیدهتر، مانیتورینگ فقط صفحه اصلی کافی نیست و باید سرویسهای کلیدی مانند API، Jobهای پسزمینه، صفها، دیتابیس یا Endpointهای حساس نیز تحت نظر باشند.
ثبت Log و خطاهای Application هم اهمیت دارد. بعضی مشکلات بدون قطعی کامل رخ میدهند، مانند خطای فرم تماس، شکست ارسال ایمیل، خطای پرداخت یا افزایش خطاهای ۵xx. پشتیبانی مناسب باید مکانیزمی برای مشاهده و اولویتبندی این سیگنالها داشته باشد.
۵. بهینهسازی سرعت و سلامت عملکرد
سرعت سایت تحت تأثیر رشد محتوا، تصاویر، اسکریپتهای جانبی، تغییرات قالب، Queryهای دیتابیس و تنظیمات Cache قرار میگیرد. به همین دلیل عملکرد یک موضوع دورهای است. Google برای ارزیابی تجربه واقعی کاربر روی معیارهای Core Web Vitals شامل LCP، INP و CLS تأکید دارد و توصیه میکند صاحبان سایت این شاخصها را در طول زمان بررسی کنند.
در قرارداد پشتیبانی باید مشخص شود «پایش عملکرد» صرفاً گزارشگیری است یا رفع مشکلات کوچک نیز در پلن قرار دارد. بازطراحی معماری یا بهینهسازی عمیق Backend معمولاً پروژه توسعه جداگانه است.
۶. رفع خطا و پشتیبانی فنی روزمره
بخش قابل مشاهده پشتیبانی برای مدیر کسبوکار معمولاً همین قسمت است. خطای نمایش یک صفحه، مشکل فرم، ناسازگاری مرورگر، ایراد Responsive، خطای پنل مدیریت یا مشکل یک اتصال خارجی نمونههایی هستند که ممکن است از طریق تیکت ثبت شوند. کیفیت این بخش به دو عامل وابسته است: زمان پاسخ و توان تشخیص ریشه مشکل.
رفع موقت یک خطا با اصلاح ریشهای آن تفاوت دارد. گاهی راهحل فوری برای کاهش اختلال لازم است و بعد از آن باید Root Cause Analysis انجام شود تا مشکل دوباره تکرار نشود.
۷. تغییرات کوچک محتوایی و اجرایی
بسیاری از پلنهای پشتیبانی ساعتی یا ماهانه بخشی از زمان را برای تغییرات سبک در نظر میگیرند: اصلاح متن، جایگزینی تصویر، افزودن محصول، تغییر بنر، ساخت صفحه ساده یا تنظیم فرم. اما تولید محتوای مستمر، طراحی کمپین، سئو محتوایی یا بازطراحی رابط کاربری لزوماً جزو پشتیبانی فنی نیست.
برای جلوگیری از ابهام بهتر است قرارداد مشخص کند چند ساعت تغییرات کوچک در ماه شامل میشود و چه نوع درخواستهایی به برآورد جداگانه نیاز دارند.
۸. پایش سئو فنی و وضعیت ایندکس
پشتیبانی سایت با خدمات کامل SEO یکی نیست، اما برخی کنترلهای فنی سئو منطقی است که در نگهداری دورهای قرار گیرد. Google Search Console اطلاعات مربوط به Crawl، Indexing، مشکلات امنیتی و Core Web Vitals را در اختیار مدیر سایت میگذارد. بررسی هشدارهای مهم، خطاهای ایندکس، وضعیت Sitemap، 404های غیرعادی و مشکلات دسترسپذیری برای Googlebot میتواند بخشی از Health Check سایت باشد.
تحقیق کلمه کلیدی، استراتژی محتوا، لینکسازی و رشد رتبهها حوزهای مستقل از نگهداری فنی است و بهتر است بهعنوان خدمت SEO تعریف شود.
۹. گزارش دورهای و مستندسازی
پشتیبانی بدون گزارش شفاف بهمرور به یک هزینه مبهم تبدیل میشود. گزارش ماهانه لازم نیست طولانی باشد، اما بهتر است نشان دهد چه بروزرسانیهایی انجام شده، چه مشکلاتی پیدا یا رفع شده، وضعیت بکاپ و Uptime چگونه بوده، چه تغییرات کوچکی ثبت شده و چه مواردی برای ماه بعد پیشنهاد میشود.
برای سایتهای تجاری مهم، مستندات دسترسی، معماری کلیدی، سرویسهای ثالث، روش Deploy و فرایند Recovery نیز باید بهروز بمانند تا دانش فنی فقط در ذهن یک نفر نباشد.
پشتیبانی پیشگیرانه و پشتیبانی واکنشی چه تفاوتی دارند؟
| مدل | رویکرد | مزیت | محدودیت |
|---|---|---|---|
| واکنشی | اقدام پس از ثبت مشکل | برای سایتهای بسیار ساده ممکن است هزینه اولیه کمتری داشته باشد | مشکل ممکن است دیر شناسایی شود و زمان قطعی افزایش پیدا کند |
| پیشگیرانه | پایش، بروزرسانی، بکاپ و Health Check دورهای | ریسک مشکلات قابل پیشگیری را کاهش میدهد | نیازمند فرایند، ابزار و مسئولیت مستمر است |
| ترکیبی | پیشگیری دورهای بهعلاوه پاسخ به تیکت | برای بیشتر کسبوکارها متعادل و قابل کنترل است | دامنه و SLA باید شفاف تعریف شود |
برای وبسایتهای سازمانی، فروشگاهی یا سایتهایی که Lead و فروش به آنها وابسته است، مدل صرفاً واکنشی معمولاً ریسک بیشتری دارد. در مقابل، یک سایت معرفی کمتغییر ممکن است به پلن سبکتری نیاز داشته باشد.
پلن پشتیبانی برای انواع سایتها باید چگونه تغییر کند؟
| نوع سایت | اولویتهای پشتیبانی | سطح حساسیت |
|---|---|---|
| سایت شرکتی | Uptime، فرمها، امنیت، بروزرسانی، سرعت، تغییرات محتوایی سبک | متوسط |
| فروشگاه اینترنتی | پرداخت، سفارش، موجودی، ایمیلها، بکاپ مکرر، امنیت و مانیتورینگ | زیاد |
| وباپلیکیشن اختصاصی | Log، API، دیتابیس، Jobها، استقرار، امنیت وابستگیها، Incident Response | زیاد تا بسیار زیاد |
| سایت محتوایی پرترافیک | Performance، Cache، CDN، Crawl، خطاهای سرور و مدیریت انتشار | متوسط تا زیاد |
همین تفاوتها نشان میدهد یک پکیج ثابت برای همه سایتها منطقی نیست. دامنه پشتیبانی باید از روی پیچیدگی فنی، ارزش کسبوکاری، حجم تغییرات و حساسیت Downtime تعیین شود.
چه خدماتی معمولاً خارج از قرارداد پشتیبانی هستند؟
مرز مهم: «نگهداری قابلیت موجود» با «ساخت قابلیت جدید» یکسان نیست. اگر این مرز در قرارداد نوشته نشود، پشتیبانی بهتدریج به پروژه توسعه نامحدود تبدیل میشود.
- بازطراحی کامل UI/UX یا تغییر هویت بصری
- پیادهسازی ماژول یا قابلیت جدید و پیچیده
- مهاجرت بزرگ بین فناوریها یا بازنویسی معماری
- کمپین تبلیغاتی و مدیریت شبکههای اجتماعی
- تولید محتوای مستمر و استراتژی کامل SEO
- خرید لایسنس سرویسها، دامنه یا افزونههای تجاری مگر آنکه صریحاً توافق شده باشد
- پشتیبانی از سرویس ثالثی که دسترسی یا قرارداد آن در اختیار تیم پشتیبان نیست
SLA در پشتیبانی سایت یعنی چه؟
SLA یا Service Level Agreement مشخص میکند تیم پشتیبانی در برابر انواع رخداد چه تعهدی دارد. مهم است بین «زمان پاسخ» و «زمان حل» تفاوت گذاشته شود. پاسخ یعنی تیکت دیده و دستهبندی شده است. حل ممکن است به علت پیچیدگی فنی، وابستگی به شرکت ثالث یا نیاز به Deploy زمان بیشتری بخواهد.
یک SLA کاربردی میتواند رخدادها را سطحبندی کند. مثلاً قطعی کامل فروشگاه یا اختلال پرداخت Critical در نظر گرفته شود، اما تغییر یک تصویر یا متن Normal باشد. عددهای دقیق نباید از یک الگوی عمومی کپی شوند و باید با منابع تیم، ساعت کاری، اهمیت سایت و هزینه قرارداد هماهنگ باشند.
چکلیست انتخاب شرکت یا تیم پشتیبانی سایت
- دامنه مسئولیت را مکتوب کنید. دقیقاً مشخص باشد چه اجزایی تحت پشتیبانی هستند.
- مالکیت دسترسیها را حفظ کنید. دامنه، هاست، مخزن کد، Analytics و حسابهای اصلی باید تحت کنترل کسبوکار بمانند.
- بکاپ و Restore را سؤال کنید. فقط تعداد بکاپ مهم نیست، محل نگهداری و روش بازیابی هم مهم است.
- فرایند بروزرسانی را بررسی کنید. برای سایت حساس، تست روی Staging و امکان Rollback اهمیت دارد.
- کانال درخواست و SLA را روشن کنید. تیکت، ایمیل یا ابزار مدیریت کار باید مشخص باشد.
- گزارش دورهای بخواهید. خروجی کار باید قابل مشاهده باشد.
- مرز توسعه و پشتیبانی را مشخص کنید. بدانید درخواست جدید چگونه برآورد میشود.
- سناریوی خروج از همکاری را در نظر بگیرید. مستندات، دسترسیها و بکاپ باید قابل تحویل باشند.
Workflow پیشنهادی برای پشتیبانی ماهانه سایت
- بررسی هشدارهای Uptime، امنیت و Logها
- کنترل وضعیت بکاپ و نمونهگیری از قابلیت بازیابی
- بررسی بروزرسانی CMS، افزونهها و وابستگیها
- اجرای تغییرات روی Staging در صورت نیاز
- تست صفحات و مسیرهای کلیدی پس از تغییر
- بررسی Performance، Search Console و خطاهای مهم
- ثبت تغییرات، تیکتهای حلشده و ریسکهای باز در گزارش
این Workflow یک استاندارد اجباری برای همه سایتها نیست، بلکه یک الگوی اجرایی است. سایت اختصاصی ممکن است به CI/CD، APM، تست خودکار و Incident Management پیشرفتهتری نیاز داشته باشد.
از کجا بفهمیم سایت به پشتیبانی حرفهای نیاز دارد؟
- نسخههای CMS یا افزونهها مدتهاست بروزرسانی نشدهاند.
- نمیدانید آخرین بکاپ قابل بازیابی چه زمانی تهیه شده است.
- فرم، پرداخت یا ایمیلهای سایت گاهی بدون اطلاع شما از کار میافتند.
- هیچکس مسئول مشخص مانیتورینگ، امنیت یا رفع خطا نیست.
- تغییر کوچک محتوا به پیدا کردن یک توسعهدهنده جدید وابسته است.
- هنگام اختلال مشخص نیست با چه کسی و از چه کانالی باید تماس گرفت.
- دانش فنی سایت فقط نزد یک فرد یا پیمانکار قبلی مانده است.
اگر چند مورد از این نشانهها وجود دارد، بهتر است ابتدا یک Audit فنی انجام شود و سپس بر اساس ریسک و حجم کار پلن پشتیبانی تعریف شود، نه اینکه یک پکیج عمومی بدون شناخت سایت خریداری شود.
هزینه پشتیبانی سایت به چه عواملی بستگی دارد؟
هزینه را نمیتوان فقط با تعداد صفحات سایت تعیین کرد. عواملی مانند نوع فناوری، فروشگاهی یا تراکنشی بودن سایت، تعداد سرویسهای متصل، سطح دسترسی به کد، کیفیت مستندات، وضعیت فعلی امنیت، تعداد درخواستهای ماهانه، ساعت پوشش، SLA، نیاز به حضور خارج از ساعت کاری و حجم تغییرات روی هزینه اثر دارند.
برای مثال یک سایت شرکتی کمتغییر با وردپرس سالم میتواند پلن سبکتری داشته باشد. یک فروشگاه با سفارش روزانه، اتصال حسابداری و درگاههای متعدد به نظارت و بکاپ بیشتری نیاز دارد. وباپلیکیشن اختصاصی نیز ممکن است پشتیبانی Backend، DevOps و دیتابیس را همزمان لازم داشته باشد.
پشتیبانی مناسب را چگونه تعریف کنیم؟ یک ماتریس تصمیم ساده
| پرسش | اگر پاسخ «کم» است | اگر پاسخ «زیاد» است |
|---|---|---|
| اهمیت سایت برای درآمد چقدر است؟ | پلن پایه قابل بررسی است | مانیتورینگ و SLA قویتر لازم است |
| اطلاعات سایت چقدر سریع تغییر میکند؟ | بکاپ با فاصله بیشتر ممکن است کافی باشد | بکاپ مکرر و Recovery دقیقتر لازم است |
| پیچیدگی فنی چقدر است؟ | پشتیبانی عمومی ممکن است کافی باشد | نیاز به تخصص فناوری و DevOps بیشتر میشود |
| تحمل Downtime چقدر است؟ | پاسخ در ساعت کاری ممکن است کافی باشد | هشدار و پاسخ سریعتر ارزش بیشتری دارد |
| تعداد تغییرات ماهانه چقدر است؟ | سهم کوچک تغییرات کافی است | Retainer با ظرفیت مشخص مناسبتر است |
پشتیبانی سایت در چرخه عمر محصول دیجیتال
پشتیبانی بهتر است از همان زمان طراحی و توسعه سایت در نظر گرفته شود. انتخاب معماری قابل نگهداری، ثبت دسترسیها، داشتن محیط Staging، مستندسازی Deploy و طراحی Recovery باعث میشود هزینه و ریسک نگهداری بعد از انتشار کمتر شود. در صفحه فرایند همکاری نیز مرحله «پشتیبانی و توسعه آینده» بهعنوان ادامه مسیر پس از استقرار تعریف شده است.
اگر سایت شما نیاز به بازنگری فنی، توسعه یا بهبود زیرساخت دارد، صفحه وبسایت و فروشگاه اینترنتی میتواند تصویر روشنتری از دامنه خدمات توسعه وب ارائه دهد. پشتیبانی موثر زمانی سادهتر است که سایت از ابتدا ساختار قابل تست، قابل مشاهده و قابل توسعه داشته باشد.
سؤالات متداول درباره پشتیبانی سایت
آیا پشتیبانی سایت همان مدیریت محتواست؟
خیر. مدیریت محتوا فقط یکی از بخشهای احتمالی پشتیبانی است. پشتیبانی فنی معمولاً بروزرسانی، امنیت، بکاپ، مانیتورینگ و رفع خطا را هم در بر میگیرد.
آیا هاست خوب نیاز به پشتیبانی سایت را از بین میبرد؟
خیر. هاست زیرساخت اجرا را فراهم میکند، اما مشکلات CMS، افزونه، کد، فرم، اتصالهای ثالث، محتوا و بسیاری از مسائل امنیتی در لایه خود سایت رخ میدهند.
هر چند وقت یکبار باید از سایت بکاپ گرفت؟
تناوب مناسب به میزان تغییر داده بستگی دارد. سایت معرفی کمتغییر با فروشگاه پرتراکنش یک نیاز ندارد. مهم است سیاست بکاپ، محل نگهداری و امکان Restore مشخص باشند.
آیا همه بروزرسانیها باید فوری نصب شوند؟
بروزرسانی امنیتی مهم است، اما روش نصب هم اهمیت دارد. در سایت حساس بهتر است امکان بکاپ، Rollback و تست سازگاری وجود داشته باشد. اولویت و زمانبندی باید بر اساس ریسک تعیین شود.
قرارداد پشتیبانی باید چه چیزی را شفاف کند؟
دامنه خدمات، ساعت پوشش، SLA، کانال ثبت درخواست، سهم تغییرات، مسئولیت بکاپ، نحوه رسیدگی به رخداد، موارد خارج از قرارداد و شرایط تحویل دسترسیها باید روشن باشند.
برای سایت فعال خود به یک مسیر فنی روشن نیاز دارید؟ اگر میخواهید وضعیت فعلی سایت، ریسکهای نگهداری و دامنه مناسب پشتیبانی یا توسعه را بررسی کنید، میتوانید از طریق درخواست مشاوره رایگان جزئیات پروژه یا نیازتان را ارسال کنید.
جمعبندی
پشتیبانی سایت یعنی حفظ سلامت یک محصول دیجیتال پس از انتشار. این کار میتواند شامل بروزرسانی، امنیت، بکاپ و بازیابی، Uptime Monitoring، کنترل Performance، رفع خطا، تغییرات محدود محتوا، Health Check سئو فنی و گزارش دورهای باشد. دامنه دقیق برای هر سایت متفاوت است و باید با اهمیت کسبوکاری، پیچیدگی فنی و سطح ریسک هماهنگ شود. برای انتخاب پلن مناسب، بهجای تمرکز روی تعداد خدمات فهرستشده، مسئولیت واقعی، SLA، فرایند بکاپ و Restore، کیفیت مستندسازی و مرز پشتیبانی با توسعه را بررسی کنید.
