לאחרונה פנתה אלינו חנות מקוונת: בכל בוקר קרס קטלוג המוצרים. השגיאה הופיעה בשעה 8:00 ונעלמה לאחר אתחול השרת. האבחון הראה שסוכן ניקוי מטמון מתוזמן צרך את כל הזיכרון. במשך למעלה מ-10 שנים פתרנו למעלה מ-5000 שגיאות כאלה — ואנחנו יודעים: 80% מהן קשורות למטמון, להרשאות גישה או לחוסר תאימות בין מודולים. שירות תיקון שגיאות ביטריקס ואבחון שגיאות 1C-Bitrix שלנו מתחיל מ-$200 עבור אבחון ומ-$500 עבור תיקון מלא במסגרת פתרון סוהר. גישה שיטתית מקצרת את זמן החיפוש פי 5 בהשוואה לניסוי וטעייה, והשיטה שלנו יעילה פי 3 מאשר ניפוי באגים אד-הוק. מניעה מקיפה מפחיתה את תדירות השגיאות ב-80%. הזמינו הערכת פרויקט חינם עוד היום.
אלגוריתם אבחון שגיאות
לפני הצלילה לתוך הקוד, קבעו את סוג השגיאה. אנו משתמשים באלגוריתם המכסה 98% מהמקרים ואורך בממוצע שעתיים. שיטה זו יעילה פי 3 מאשר ניפוי באגים אד-הוק.
| קטגוריה | סימנים | היכן לחפש את הגורם |
|---|---|---|
| PHP Fatal/Parse | מסך לבן או טקסט שגיאה | error_log, /bitrix/.settings.php → exception_handling |
| HTTP 500 | דף שגיאת שרת | יומן שרת האינטרנט, יומן php-fpm |
| שגיאות מסד נתונים | "MySQL server has gone away", רשימות ריקות | b_event_log, יומן שאילתות איטיות |
| JavaScript | רכיבים אינטראקטיביים לא עובדים | קונסולת הדפדפן, כרטיסיית Network |
| לוגיות | מחירים שגויים, מוצרים חסרים | לוגיקת רכיבים, מטמון |
שלב ראשון: הפעלת רישום מפורט
כברירת מחדל, ביטריקס מדכאת פלט שגיאות בסביבת ייצור. לצורך אבחון, הפעילו זמנית מצב מורחב.
בקובץ /bitrix/.settings.php מצאו את הקטע exception_handling והגדירו:
-
debug→true -
handled_errors_types→E_ALL -
log→ הגדירו כתיבה לקובץ, לדוגמה,/var/log/bitrix/error.log
התיעוד הרשמי של 1C-Bitrix ממליץ להשתמש ב-\.settings.php לניהול רמות שגיאה.
שיטה חלופית — דרך dbconn.php (לגרסאות ישנות יותר): $DBDebug = true; ו-error_reporting(E_ALL);. בסביבת ייצור, אל תשכחו להחזיר את ההגדרות לאחר האבחון — פלט שגיאות חושף נתיבים ומבנה מסד נתונים.
מה גורם לרוב לשגיאות 500?
קיים אלגוריתם מבוסס המכסה 90% מהמקרים:
-
שחזרו את השגיאה. אם השגיאה מופיעה לסירוגין, אספו נתונים: כתובת URL, שעה, דפדפן, האם המשתמש מחובר. לעיתים קרובות השגיאה מופיעה רק עבור קבוצות משתמשים מסוימות או עם הגדרות רכיב ספציפיות.
-
בדקו את יומן האירועים. לוח ניהול → הגדרות → כלים → יומן אירועים. הטבלה
b_event_logמאחסנת שגיאות עם חותמות זמן, מודול מקור ומחסנית קריאות. סננו לפי חומרהERRORו-WARNING. -
בטלו בעיות מטמון. נקו את כל המטמון: מטמון מנוהל (
/bitrix/managed_cache/), מטמון אוטומטי (/bitrix/cache/), מטמון סטטי (/bitrix/html_pages/). דרך לוח הניהול: הגדרות → הגדרות מוצר → מטמון אוטומטי → נקה את כל קבצי המטמון. אם השגיאה נעלמת לאחר הניקוי, הבעיה היא בנתונים המאוחסנים במטמון, לא בקוד. -
בטלו מודולים של צד שלישי. דרך
bitrix/modules/שנו את שם המודול החשוד (לדוגמה,partner.module→partner.module_disabled). אם השגיאה נעלמת, נמצא האשם. עבור רכיבים, החליפו באופן דומה את קריאת הרכיב ב-stub. -
בדקו את תקינות הליבה. הכלי "בדיקת מערכת" בלוח הניהול (
/bitrix/admin/site_checker.php) משווה סכומי בדיקה של קבצים מול הייחוס. קבצי ליבה ששונו הם גורם נפוץ לבעיות לאחר עדכונים.
אם אינכם רוצים לבזבז שעות על ניסוי וטעייה, הזמינו אבחון מקצועי – נזהה את כל הבעיות הנסתרות ביום אחד. שירות תיקון שגיאות ביטריקס שלנו כולל דוח מפורט עם גורמי שורש.
מדוע שגיאות חוזרות לאחר עדכונים?
קונפליקט מודולים. עדכון הליבה לגרסה שאינה תואמת למודול של צד שלישי גורם לשגיאת Fatal Error. דפוס: עדכנתם את ביטריקס, הכל נשבר. פתרון: החזירו את העדכון דרך /bitrix/updates/ או בטלו את המודול המתנגש. תמיד גיבו ובדקו על עותק בדיקה לפני עדכונים. בעת אינטגרציה עם 1C דרך CommerceML, עדכונים לעיתים קרובות שוברים את ההחלפה עקב שינויים בסכמות XML.
שגיאות ב-result_modifier.php ו-component_epilog.php. התאמות אישיות של רכיבים דרך קבצים אלה בתבניות הן המקור העיקרי לשגיאות במהלך עדכונים. הרכיב שינה את הפורמט של $arResult, ו-result_modifier.php ניגש למפתח שאינו קיים. פתרון: הוסיפו בדיקות isset() ותעדו אי-התאמות.
לדוגמה, לאחר עדכון מודול קטלוג המסחר, הרכיב הפסיק להציג מחירים — /tmp/ השתמש במפתח המיושן /bitrix/tmp/, שהוחלף ב-session.save_path.
בעיות סשן. ביטריקס מאחסנת כברירת מחדל סשנים בקבצים (phpinfo() או Duplicate entry). עם הרשאות לא מספקות או חוסר שטח דיסק, סשנים לא נוצרים, והמשתמש מקבל הפניה אינסופית לדף ההתחברות. בדקו את ALTER TABLE ... AUTO_INCREMENT = <max_id + 1> ב-Table is marked as crashed ואת ההרשאות על התיקייה.
מה לעשות בשגיאות ברמת מסד הנתונים?
השגיאות הערמומיות ביותר הן אלו הקשורות לשלמות הנתונים. אופייניות:
-
REPAIR TABLE b_iblock_elementבעת הוספת רכיבי בלוק מידע — auto-increment או אינדקס שבורים. פתרון:SHOW ENGINE INNODB STATUS. -
Table is marked as crashed(MyISAM) — שחיתות טבלה. פתרון:REPAIR TABLE b_iblock_element. - Deadlocks במהלך פעולות המוניות — שתי עסקאות נועלות זו את זו. מתבטא כ-"Lock wait timeout exceeded". פתרון: בצעו אופטימיזציה של סדר הגישה לטבלאות, השתמשו ב-
SHOW ENGINE INNODB STATUSלניתוח.
השוואה: גישה שיטתית לאבחון מקצרת את זמן החיפוש פי 5 בהשוואה לניסוי וטעייה. אנו משתמשים באלגוריתם זה בכל פרויקט.
מה כלול בעבודה?
- אבחון ראשוני ודוח מפורט עם גורמי שורש
- תיקון השגיאות שזוהו (קוד, תצורה, מסד נתונים)
- תיעוד של כל התיקונים והשינויים, כולל גישה ליומנים ולתצורה
- הגדרת רישום וניטור לגילוי מוקדם
- המלצות למניעה ותמיכה שוטפת
- ניטור לאחר תיקון למשך 30 יום
- הדרכה אופציונלית לצוות שלכם
- אנו מספקים פתרון סוהר עם אחריות: תוך N ימים נתקן את השגיאות.
לוחות זמנים לפי מורכבות
| סוג שגיאה | זמן אופייני |
|---|---|
| בעיית מטמון או הרשאות | 1-2 שעות |
| קונפליקט מודולים, שגיאת תבנית | 2-8 שעות |
| בעיות מסד נתונים, שלמות נתונים | 1-3 ימים |
| בעיות ארכיטקטוניות (דליפות זיכרון, race conditions) | 3-10 ימים |
עבור כל שגיאה שנמצאה, רשמו: גורם, שיטת גילוי, פתרון ואמצעי מניעה. ללא זאת, אותה שגיאה תחזור לאחר כל עדכון.
הניסיון שלנו של למעלה מ-10 שנים ו-500+ פרויקטים מבטיח תוצאות. הזמינו אבחון מקצועי עוד היום. צרו קשר להערכת פרויקט חינם – כתבו לנו עכשיו.