זמינות אתר 30 יום: תחקור downtime וחזרה ל-99.9%

RankPlus מנטר את הזמינות של האתר מנקודות חיצוניות, דוגם כל כמה דקות, ומחשב אחוז זמינות מצטבר ל-30 יום. אחוז מתחת ל-99.9% נראה קטן - אבל זה אומר 43+ דקות שהאתר לא הגיב, ואלה לרוב הדקות הקריטיות ביותר.

למה זה משנה

99.9% זמינות בחודש = 43 דקות downtime. 99.5% = 3.6 שעות. 99% = 7.2 שעות. הזמן הזה לא מתפזר אקראית - הוא לרוב מצטבר באירועים קצרים אבל קריטיים: השבר באמצע לקוח שעושה checkout, ה-timeout כש-Google bot מנסה לאנדקס, ה-error 500 כשמישהו לחץ על מודעה ברגע שהאתר נפל.

השפעות עסקיות מובהקות: אובדן הכנסה ישיר - כל דקה של downtime באתר מסחר היא הזמנות לא בוצעו. נזק SEO - Google מוריד מהדירוג אתרים עם זמינות נמוכה (signal של trust). אובדן אמון - לקוח שראה "This site can't be reached" לא ינסה שוב מחר. נזק תדמית - בלוגים, חברות SaaS, ואתרי שירות שירדו פעם נראים לא מקצועיים.

איך לזהות

בלוח הבקרה של RankPlus יש דשבורד "Uptime" שמראה את הזמינות של 30 הימים האחרונים, גרף לפי שעות, ויומן (log) של כל אירוע downtime - מתי התחיל, כמה זמן נמשך, ומה הייתה התגובה (timeout / 500 / connection refused). השורה הזו של הלוג היא הנקודה הראשונה לחקור.

איך לתקן

1. עבור על לוג ה-uptime של RankPlus. שאל: יש דפוס בזמן? כל יום באותה שעה (cron job של גיבוי)? כל שלישי בלילה (תחזוקת spec של ספק האחסון)? אחרי עדכון תוסף (regression)?
2. צור קשר עם ספק האחסון. הם רואים את הצד שלהם של התקלה: עליות CPU, kill of PHP-FPM, חריגה ממכסה זיכרון, רפליקציה של DB שכשלה. בקש את ה-server-side logs לזמן downtime ספציפי. רוב הספקים יחזירו תשובה תוך 24-48 שעות.
3. בדוק את לוגי השרת ישירות אם יש לך גישה: /var/log/nginx/error.log, /var/log/php-fpm.log, /var/log/mysql/error.log. שגיאות ברגע ה-downtime הן הסימן הברור ביותר.
4. חפש slow queries ב-MySQL: SHOW VARIABLES LIKE 'slow_query_log'; ובדוק את הקובץ. שאילתה של 30 שניות חוזרת = תוסף עם בעיה.
5. אם הסיבה היא תנועה גבוהה: הפעל page caching (W3 Total Cache, WP Rocket, LiteSpeed Cache) ו-CDN (Cloudflare חינמי, BunnyCDN זול). page caching לבד יורד עומס ב-90% לאתרי בלוג סטטיים.
6. אם הסיבה היא DB: בדוק תוסף שיוצר טבלאות ענקיות (Action Scheduler של WooCommerce, לוגים של plugins אבטחה). הפעל wp action-scheduler clean, מחק לוגים ישנים. שקול Redis Object Cache.
7. אם הסיבה היא תוסף בעייתי: בלוג שגיאות מסומן (debug.log או error.log), השבת אותו, חפש חלופה.
8. אם הבעיה חוזרת ולא מתקנת: שקול החלפת אחסון. shared hosting זול נשבר תחת עומס. עבור ל-managed WordPress hosting (Kinsta, WP Engine, SiteGround), VPS עם cPanel, או Cloudways.

טעויות נפוצות

• הסתמכות על monitoring של הספק: "רק האתר שלי לא הגיב, אבל הספק אומר 99.99%" - הם מודדים את ה-server, לא את האתר. RankPlus מנטר מבחוץ.
• החלפת אחסון בלי לאתר את הסיבה: אם הבעיה היא תוסף בעייתי, גם באחסון חדש זה ימשיך לקרות.
• איגנור של downtime קצר: 5 דקות פעם בשבוע = 4% downtime בחודש. מצטבר.
• השבתת monitoring כדי "להעלים" אזהרות: זה לא משנה את המציאות - גולשים עדיין רואים את הקריסות.
• אין שכבת fallback: אתר ענקי בלי מצב maintenance או error page יפה. שני page caches שונים יכולים לשרת מטמון אם המערכת קורסת.

בדיקה לאחר תיקון

חכה 30 ימים. ב-RankPlus תראה את ה-uptime מטפס. מטרה: 99.9% (פחות מ-43 דקות downtime). אם הגעת לשם, תייצב. אם לא - הסיבה השורש לא תוקנה. שירותי monitoring חיצוניים (UptimeRobot, Better Uptime) יכולים להיות שכבה נוספת לאישור.