پایش uptime سایت؛ چطور در دسترس بودن را درست بسنجیم؟

مسیر پس از خطا را مقالهٔ آموزش گام‌به‌گام بازگردانی سایت پس از خطا؛ از تشخیص تا راه‌اندازی دوباره کامل گشوده است؛ آن مقاله از تشخیص تا راه‌اندازی دوباره می‌رود، این مقاله لایهٔ قبل از آن را می‌گیرد: چطور با پایش uptime سایت، پیش از آنکه مشتری بفهمد، خودتان بفهمید و با تصمیم آماده وارد رویداد شوید نه با استرس.

این بحث به دو دلیل عملی جدی است: اول، در دسترس بودن یک تجربهٔ مشتری است نه یک عدد سرور؛ مشتری فرقی بین خرابی دیتابیس و خرابی افزونه نمی‌گذارد، هر دو «سایت شما خراب است». دوم، اکثر قطعی‌ها بی‌سروصدا شروع می‌شوند: صفحه برای مدیر که همیشه لاگین است باز می‌شود اما برای مشتری جدید نه؛ بدون پایش بیرونی، آخرین نفر مطلع‌شده صاحب سایت است.

پایش uptime سایت یعنی چه؛ سه عدد پایه

سه عدد پایه را با یک حساب ساده کنار هم بگذارید. در ماه سی‌روزه، در دسترس بودن ۹۹٪ یعنی حدود هفت ساعت قطعی مجاز؛ ۹۹٫۹٪ یعنی حدود ۴۳ دقیقه؛ ۹۹٫۹۹٪ یعنی حدود چهار دقیقه. هر پله، فشار روی زیرساخت و هزینهٔ رسیدن به آن را تقریباً ده برابر می‌کند؛ برای همین شروع برنامهٔ پایش را با عدد واقع‌بینانه ببندید، نه با بزرگ‌ترین عدد تبلیغاتی.

نکتهٔ دوم، تفاوت سنجش از داخل و از بیرون است. از داخل سرور یعنی «منابع بالا هستند»؛ از بیرون یعنی «کاربر واقعی از شبکهٔ واقعی صفحه را می‌گیرد». به تجربهٔ ما اتفاق‌های بدتر میان همین فاصله می‌افتند: سرور سالم است، اما DNS گیر می‌کند یا گواهی منقضی شده و کاربر صفحهٔ هشدار مرورگر می‌بیند؛ سنجش بیرونی فقط همین‌ها را می‌بیند.

سوم، درصد به‌تنهایی گمراه‌کننده است. دو سایت با آپتایم یکسان، تجربه‌های متفاوتی می‌سازند: یکی ده قطعی دو دقیقه‌ای داشته، دیگری یک قطعی بیست‌دقیقه‌ای در ساعات اوج فروش. پایش درست، زمان و مدت و ساعت رخداد را ثبت می‌کند تا بتوانید دربارهٔ ریسک واقعی تصمیم بگیرید، نه دربارهٔ میانگین خوش‌خیال.

چرا برای وردپرس جدی‌تر است؛ دو دلیل ساختاری

وردپرس سهم غیرقابل‌انکاری از وب دارد: بر پایهٔ داده‌های W3Techs حدود ۴۳٪ همهٔ وب‌سایت‌های جهان با وردپرس ساخته شده‌اند (تاریخ گردآوری: آبان ۱۴۰۵). این سهم بزرگ یک پیامد مستقیم برای پایش دارد: خطاهای شناخته‌شده — تعارض افزونه، به‌روزرسانی ناقص، محدودیت منابع هاست اشتراکی — الگوهای تکرارشونده‌اند و قابل پیش‌بینی؛ یعنی پایش می‌تواند روی همین الگوها تنظیم شود.

دلیل دوم ساختاری است: در وردپرس، لحظه‌های تغییر زیادند. هر به‌روزرسانی افزونه یا قالب، هر تغییر تنظیمات و هر استقرار تازه، یک لحظهٔ ریسک است. به تجربهٔ ما بیشتر قطعی‌های سایت‌های وردپرسی نه از خرابی ناگهانی هاست، که از همین تغییرهای بی‌پایش می‌آیند؛ پایشی که لحظهٔ تغییر را ثبت کند، هم ریشه‌یابی را ساده می‌کند هم مسئولیت را روشن.

از همین‌جا یک توصیهٔ اجرایی بیرون می‌آید: تقویم به‌روزرسانی و تقویم پایش را یکی کنید. آپدیت‌ها در ساعات کم‌ترافیک، بلافاصله بعد از هر تغییر یک بررسی بیرونی و در پایان هفته یک بازخوانی گزارش. این نظم ساده، بخش بزرگی از رویدادهای «ناگهانی» را از پیش می‌بیند.

سه لایهٔ پایش؛ از سیگنال سبک تا آزمون کاربر

پایش را در سه لایه بچینید. لایهٔ اول، سیگنال سبک است: بررسی دوره‌ای وضعیت HTTP هر چند دقیقه؛ ارزان است و در چند دقیقه راه می‌افتد. لایهٔ دوم، سنجش هم‌زمان از چند نقطهٔ جغرافیایی است تا خطای مسیر شبکه با خطای سایت اشتباه گرفته نشود. لایهٔ سوم، آزمون معنادار است: درخواستی که شبیه کاربر واقعی است — باز کردن صفحهٔ کلیدی، جستجوی محصول، رفتن تا مرحلهٔ پرداخت آزمایشی.

چرا فقط لایهٔ اول کافی نیست؟ چون پاسخ ۲۰۰ لزوماً یعنی «صفحه درست است» نیست؛ صفحه می‌تواند بدون استایل بالا بیاید، دیتابیس خالی برگرداند یا فرم ثبت‌نام خطای پنهان بدهد. به تجربهٔ ما بدترین خرابی‌ها همان‌هایی هستند که چراغ سبز دارند؛ برای همین آزمون معنادار، لایه‌ای است که حس آرامش کاذب را می‌شکند.

ترتیب راه‌اندازی را هم رعایت کنید: از لایهٔ سبک شروع کنید و همان هفته به نتایج برسید؛ بعد لایهٔ چندنقطه‌ای را اضافه کنید؛ آزمون معنادار را وقتی بگذارید که صفحه‌های کلیدی و جریان خریدتان مشخص باشند. این ترتیب از هفتهٔ اول ارزش می‌دهد و هزینهٔ شروع‌اش تقریباً صفر است.

چه چیزی را بسنجیم؛ فراتر از بالا بودن

چهار سیگنال را در گزارش پایش نگه دارید: وضعیت HTTP، زمان پاسخ، سلامت گواهی TLS و صحت محتوای کلیدی صفحه — مثلاً اینکه عنوان اصلی صفحهٔ خانه واقعاً همان چیزی است که باید باشد. زمان پاسخ را با آستانهٔ نسبی بخوانید: افت تدریجی از ۹۰۰ به ۱۶۰۰ میلی‌ثانیه در چند روز، خبری است هرچند هنوز هیچ‌چیز «خراب» نیست.

این سیگنال‌ها به سئو و به اعتماد کاربر هم گره می‌خورند: قطعی طولانی خزش را مختل می‌کند و کاربری که یک بار صفحهٔ خطا دیده، دفعهٔ بعد با تردید کلیک می‌کند. به تجربهٔ ما سایت‌هایی که پایش را با امنیت و نسخهٔ پشتیبان در یک برنامهٔ واحد نگه می‌دارند، کمتر دچار رویدادهای ترکیبی می‌شوند؛ نگاه به این سه به‌عنوان یک لایهٔ حفاظتی واحد، در صفحهٔ امنیت و پشتیبان‌گیری سوئیت باز شده است.

تاریخچه را هم جدی بگیرید: ثبت رویدادها با زمان و مدت، تنها راه دیدن الگو است — «هر یکشنبه بعد از آپدیت زمان پاسخ بالا می‌رود» فقط در تاریخچه دیده می‌شود. گزارش لحظه‌ای آرامش می‌دهد؛ تاریخچه تصمیم می‌سازد.

آستانهٔ هشدار؛ طوری که هشدار معنا داشته باشد

آستانهٔ هشدار را دو مرحله‌ای ببندید: مرحلهٔ توجه برای ناهنجاری کوتاه — دو بررسی پشت‌سرهم ناموفق — و مرحلهٔ بحران برای ادامه یا گسترش، مثلاً پنج دقیقه ناموفقی هم‌زمان از چند نقطه. اگر هر گلی یک زنگ بحران بزند، تیم در هفتهٔ دوم اعلان‌ها را بی‌صدا می‌کند و همان لحظه، پایش بی‌اثر می‌شود.

پیام هشدار هم باید چهار چیز را داشته باشد: چه چیزی، از کجا، از چه ساعتی و مالک بعدی کیست. پیامی که فقط می‌گوید «سایت پایین است»، نیمی از فرایند پاسخ را جا می‌اندازد. کانال را هم با عادت تیم هم‌راستا کنید: پیامی که در کانال شلوغ گم می‌شود، ارسال نشده است.

سه الگوی بی‌فایده را بشناسید و حذفشان کنید: اعلان هر یک دقیقه بدون تفکیک شدت، هشدار روی سنجه‌هایی که کنترلی روی‌شان ندارید، و آستانه‌های یکسان برای همهٔ صفحه‌ها. به تجربهٔ ما کیفیت پایش را نه تعداد هشدارها، که نسبت هشدار به اقدام درست نشان می‌دهد؛ اگر هفته‌ای چند هشدار بی‌اقدام دارید، آستانه‌ها خراب‌اند نه تیم.

وقتی قطعی رخ داد؛ فرایند پاسخ در چهار حرکت

فرایند پاسخ را در چهار حرکت مکتوب کنید. حرکت اول، تشخیص: قطعی واقعی است یا خطای مسیر؛ گزارش چندنقطه‌ای همین‌جا حرف می‌زند. حرکت دوم، ارتباط: اگر بیش از چند دقیقه طول می‌کشد، پیام کوتاه به مشتری‌ها — صداقت در رویداد، اعتماد را بیشتر از بی‌خطایی می‌سازد. حرکت سوم، بازگردانی: آخرین نسخهٔ سالم، محیط آماده و دسترسی مشخص. حرکت چهارم، بررسی پس از رویداد: علت، زمان تشخیص، زمان رفع و یک اصلاح ماندگار.

دو مقالهٔ زوج برای همین مسیر آماده‌اند: جزئیات بازگردانی را در آموزش گام‌به‌گام بازگردانی سایت پس از خطا؛ از تشخیص تا راه‌اندازی دوباره نوشته‌ایم و خطای 404 و لینک‌های شکسته با حلقهٔ پایش تا رفع در آموزش گام‌به‌گام خطای 404 و لینک‌های شکسته؛ حلقهٔ پایش تا رفع پوشش داده شده است؛ هر دو را کنار این بخش نگه دارید تا فهرست راهنمای رویدادتان کامل شود.

یک پیشنهاد هم برای تیم‌های کوچک: هر شش ماه یک تمرین شبیه‌سازی اجرا کنید — یک ساعت، سناریوی فرضی، بدون ترس واقعی. به تجربهٔ ما تیم‌هایی که تمرین کرده‌اند، در رویداد واقعی نصف زمان دیگران را برای تشخیص می‌گیرند؛ فرایند نوشته‌شده اما تمرین‌نشده، در لحظهٔ بحران در ذهن‌ها نیست.

جمع‌بندی؛ پایش یعنی تصمیم آماده

جمع‌بندی در سه خط: پایش یعنی سنجش بیرونیِ مستمر با سه لایه — سیگنال سبک، چندنقطه، آزمون معنادار؛ آستانهٔ دو مرحله‌ای با پیام کامل و مالک مشخص؛ و فرایند پاسخ چهارحرکتی که قبل از رویداد نوشته و تمرین شده است. عدد هدف را واقع‌بینانه ببندید و بیشتر از عدد، روی زمان تشخیص کار کنید؛ خروجی پایش خوب، آرامش شبانه و تصمیم‌های سریع صبح است.

نقشهٔ کامل نگهداری و خطاها در هاب نگهداری، مهاجرت و خطاها جمع شده و اگر می‌خواهید این چارچوب را با اتوماسیون — توقف اضطراری، snapshot و بازگردانی سطح‌بندی‌شده — ببینید، صفحهٔ محصول و دموی سوئیت دموی رایگان دارد و ساختار پلن‌ها در تعرفهٔ پلن‌های سوئیت شفاف است. اگر فقط یک کار از این مقاله باقی می‌ماند، همین باشد: همین هفته لایهٔ سبک پایش را راه بیندازید و برای هر هشدار، یک مالک مشخص تعیین کنید. لایه‌های بعدی، وقتی اولین لایه ثابت نشست، از خودشان راه می‌افتند و تیم هم به این نظم عادت می‌کند.

رصد ما، رشد شما.