מדוע עדכון הליבה של 1С-Битрикс שובר אתר פעיל
עדכון הליבה של 1С-Битрикс נדיר שנכשל מעצמו — האשף מדווח על הצלחה. מה שנשבר הוא חוסר הסנכרון: הליבה עוברת לענף חדש, ואילו חלק מהמודולים נשארים בענף הקודם, כי העדכון עבורם טרם שוחרר או אינו מכוסה ברישיון. מכאן נובע קונפליקט מודולים לאחר העדכון — אזור הניהול נפתח, אך דפים ציבוריים מחזירים שגיאה.
המקור השני — שינויים בקוד המקור. כל עוד האתר פעיל, מעדכנים תבניות, קומפוננטות ומטפלים ישירות, כולל בתוך הליבה. העדכון דורס את הקבצים האלה: ההתאמות נעלמות, ואם הקובץ שרד אך נשען על ממשק פנימי שהשתנה, האתר לא נפתח לאחר העדכון — מסך לבן או 500 על הכול, כולל ביצוע הזמנה.
אי-התאמה בין גרסאות מתגלה בשקט ולכן עולה יותר. מודול צד שלישי מיושן, תבנית קומפוננטה מותאמת אישית, סנכרון עם 1С — כל אלה עשויים לשרוד את העדכון, אך להישבר נקודתית: הודעות דואר מפסיקות להישלח, פריטים בסל מוכפלים, והסנכרון לא קולט הזמנות חדשות. כך שמים לב רק כעבור יממה, כשחלק מהפניות כבר אבוד.
המחיר של שבירה אינו שעות השבתה, אלא הזמנות שלא התקבלו באותן שעות, ודפים שנפלו מהחיפוש בזמן שהאתר החזיר שגיאה. חזרה לאחור ללא עותק שמור וסט גרסאות תואמות כבר בלתי אפשרית: מסד הנתונים כבר עבד על הליבה החדשה. בהמשך נפרט איך מכסים זאת — ממיפוי מודולים וסביבת בדיקות ועד תוכנית חזרה לאחור.
מה נותנת תחזוקה מתוכננת של הפלטפורמה
תחזוקה מתוכננת היא לוח זמנים של עבודות במקום תגובה לתקלה. עדכוני הליבה של 1С-Битрикс והמודולים מתבצעים בחבילות, כל חבילה עוברת סביבת בדיקות על עותק של מסד הנתונים הפעיל, ולכן האתר נשאר זמין ללקוחות. להלן מה משתנה בנתונים מדידים.
משך השבתה: דקות במקום יממה
את העבודות מתכננים לחלון של תעבורה נמוכה, עם בדיקה מוקדמת של גיבוי ותרחיש חזרה לאחור. עדכון בסביבת הייצור מסתכם ב-15–30 דקות, בעוד ששיקום חירום לאחר עדכון ידני כושל נמשך בדרך כלל שעות ויממה. חלון עבודה מתואם מבטל עבודות לילה בהולות והשבתות בשעות מכירה.
סוג כשלים שנעלם
עיקר התקלות לאחר עדכון — אי-התאמה של מטפלים שנכתבו ידנית, קריאות מיושנות בתבניות, קונפליקטים של מטמון והרשאות גישה. מקרים אלה נתפסים בסביבת הבדיקות: קודם מריצים את החבילה על עותק, משווים יומני שגיאות, ורק אחר כך מעבירים לאתר הפעיל. לפרודקשן עולה גרסה שכבר עבדה תחת עומס ועברה בדיקה של דפים קריטיים.
יציבות המכירות
בנפרד בודקים את מסלול הקונה: קטלוג, סל, ביצוע הזמנה, תשלום, אזור אישי. שגיאה כאן עולה לא במוניטין אלא בהכנסות, ולכן לאחר כל חבילה תרחישים אלה עוברים את אותו מערך בדיקות. שיעור ההזמנות שהושלמו ללא תקלה מפסיק להיות תלוי בגרסה הבאה.
לוחות זמנים צפויים וחזרה לאחור הפיכה
העבודות מתנהלות לפי תוכנית רבעונית: ידוע מה ומתי מעדכנים, כמה זמן זה אורך ומי תורן. כל שלב הפיך — חזרה למצב הקודם אורכת דקות, ואינה דורשת לפרק את ההשלכות ידנית. בסיום הלקוח מקבל דוח עם רשימת שינויים ויומן בדיקות.
השוואת גישות: אשף, התקנה ידנית, עותק
ניתן לבצע עדכון ליבה של 1С-Битрикс בארבע דרכים, והבחירה ביניהן קובעת לא את מהירות העבודה אלא את סוג הסיכון.
אשף העדכון המובנה מתאים לפרויקטים ללא שינויים בליבה, התקנה ידנית של פאצ'ים — לתיקונים נקודתיים, עותק בדיקות — לאתרים עם אינטגרציות ותעבורה, ומעבר מדורג — לגרסאות גדולות שאי אפשר להעלות בחלון אחד.
| אפשרות | מתי מתאימה | מגבלות השיטה |
|---|---|---|
| אשף העדכון המובנה | השינויים הוצאו מחוץ לליבה, הפלטפורמה בענף עדכני | אינו פותר קונפליקטים בקבצים שהשתנו: בעת אי-התאמה הוא נעצר וממתין לפתרון ידני, וחזרה לאחור בפעולה אחת אינה מובנית |
| התקנה ידנית של פאצ'ים | נדרש תיקון נקודתי של שגיאה או סגירת חולשה ללא הרצה מלאה | מאמץ עבודה גבוה, תלויות בין מודולים נבדקות ידנית, יכולת שחזור נמוכה יותר |
| עותק בדיקות של האתר | פרויקט עם סנכרון נתונים, שירותים חיצוניים ותעבורה פעילה | דורש סנכרון של מסד הנתונים והסביבה, העותק מתרחק מהר מסביבת הייצור |
| מעבר מדורג של הליבה | גרסה גדולה, מפוצלת לפי מודולים ותת-מערכות | ארוך יותר בלוח השנה: חלק מהזמן המערכת חיה במצב ליבה מעורב |
לפי מה בוחרים
בודקים את שיעור הקבצים שהשתנו בליבה, קיום בדיקות אוטומטיות וחלון ההשבתה המותר. אם אין שינויים בליבה, די באשף המובנה לאחר הרצה על עותק. אם הפרויקט עמוס באינטגרציות וסנכרון עם מערכת הנהלת חשבונות, המסלול הבטוח הוא אחד — עותק בדיקות עם מעבר מדורג ותיעוד מצב לפני ואחרי כל שלב.
כיצד הליבה עוברת לעותק: שלבי העבודה
עדכון הליבה של 1С-Битрикс נדיר שעובר "בקליק אחד" בפרויקט פעיל: שינויים בתבנית, מודולי צד שלישי וסנכרון עם מערכת הנהלת חשבונות נאחזים בקריאות פנימיות שאולי כבר אינן קיימות בענף החדש. לכן המעבר מתבצע בשלבים, ובכל שלב יש נקודת חזרה למצב פעיל.
- ביקורת שינויים ומודולים. משווים את קבצי הליבה להתקנה התקנית, מתעדים קומפוננטות שהשתנו, תבניות משנה ותלויות מודולים — ומקבלים מפה של מה שהעדכון ישפיע עליו.
- תרשים מעבר. קובעים סדר: מה מתעדכן יחד עם הליבה, מה בנפרד, היכן נדרשת התערבות ידנית. כאן גם נקבעות נקודות חזרה לאחור.
- הרכבת עותק. פורסים את הפרויקט על שרת נפרד — מסד נתונים, קבצים, הגדרות, משימות מתזמן. דיוורים ואינטגרציות מושבתות כדי שהבדיקות לא יגיעו ללקוחות אמיתיים.
- התקנה על העותק. מעדכנים ליבה ומודולים, מעבירים שינויים לקוד החדש, מטפלים בקונפליקטים.
- בדיקה על העותק. מריצים תרחישים קריטיים: הזמנה, התחברות, תשלום, סנכרון עם מערכת הנהלת חשבונות, אזור ניהול. משווים יומני שגיאות וזמן תגובה לפני ואחרי.
- מעבר לסביבת הייצור. עובדים בחלון תחזוקה: תמונת מצב של מסד הנתונים והקבצים לפני ההתחלה, עדכון באותו סדר, בקרת יומנים בשעות הראשונות.
- נוהל חזרה לאחור. מתארים חזרה למצב הקודם, מוסרים מפת שינויים והוראות לעדכונים הבאים.
כך העדכון מפסיק להיות הגרלה: השינויים נבדקו על עותק, וההחלטה לחזור לאחור מתקבלת לפי מסמך.
מה נשאר אצלכם: קונפיגורציה, תרשימים, נוהל
לאחר העדכון לצוות נשאר לא רק אתר פעיל, אלא גם סט ארטיפקטים שלפיו העדכון הבא עובר בצפוי — בלי לנתח לוגים ולתשאל את מי ש"משהו תיקן ידנית". הכול נמסר במאגר שלכם ובמסמכים קריאים, וההרשאות נשארות אצלכם.
- מפת גרסאות ליבה — מה מותקן בסביבת הייצור ובסביבת הבדיקות, אילו מודולים עודכנו, אילו הוקפאו ומדוע.
- רשימת שינויים — שינויים בליבה, בתבניות ובמטפלים עם קישור למשימות: בעדכון הבא מיד רואים מה צריך להעביר מחדש.
- נקודות שחזור — תמונות מצב של מסד הנתונים והקבצים לפני כל שלב, עם ציון מה בדיוק חוזר לאחור ובאיזה סדר.
- תיעוד עדכון — סדר השלבים, בדיקות לאחר כל שלב, מגבלות ידועות ופתרונות עוקפים.
- נוהל תחזוקה — תדירות העדכונים, תיאום חלון העבודה, מה נבדק לפני ואחרי, ובאילו מקרים העדכון נדחה.
- צ'ק-ליסט קבלה — תרחישים שלפיהם מאשרים תפקוד תקין: הזמנות, תשלום, טפסים, סנכרון עם מערכת הנהלת חשבונות.
- יומן שינויי קונפיגורציה — הגדרות שנגעו בהן, הרשאות גישה ותבניות דואר.
מקרה בוחן: מעבר לענף חדש בלי לעצור מכירות
מה היה לפני
אתר עם קטלוג של כמה אלפי פריטים, אזור אישי ללקוחות B2B וייצוא הזמנות ל-1С עדכנו פעם בשנה עד שנה וחצי, והליבה של 1С-Битрикс פיגרה בכמה ענפים. כל התקנה תפסה חלון לילה מ-23:00 עד 5:00 — שש שעות שבהן חזית החנות, הסל והסנכרון עם מערכת הנהלת חשבונות לא היו זמינים.
מתוך תשעה עדכונים קודמים, ארבעה הסתיימו בחזרה לאחור: נשברו תבניות של קומפוננטת הקטלוג, מטפלי אירועים מותאמים אישית והסנכרון עם 1С.
מה שינינו
את אתר הייצור ואת סביבת הבדיקות הבאנו למצב אחד: תמונת מצב של מסד הנתונים והקבצים מועברת לעותק בשלמותה, יחד עם הזמנות והגדרות סנכרון.
העדכון מורץ על העותק — מתעדים קונפליקטים בשינויים מותאמים אישית בקטלוג, ומרכיבים מערך רגרסיה מהמסלולים שנשברו בשכיחות הגבוהה ביותר: ביצוע הזמנה, ייצוא ל-1С, אינטגרציית תשלומים, אזור אישי. את העבודה פיצלנו לשני מעברים — קודם הליבה, כעבור שבוע מודולים ותבניות.
מה השתנה
חלון העבודה הצטמצם ל-40 דקות במקום שש שעות, וההשבתה של חזית החנות — ל-10 דקות להעברת התעבורה: את השאר בודקים על העותק. בעדכונים האחרונים, ארבעה במספר, אין כשלים לאחר ההתקנה, בעוד שלפני כן כמעט כל מעבר שני נפל.
אם בכל זאת נדרשת חזרה לאחור, היא מחזירה את הגרסה הקודמת ותמונת מצב של מסד הנתונים בהחלפה, ולא משחזרת את האתר בחלקים.
מה לעשות אם השינויים בוצעו ישירות בקוד המקור
שינויים שבוצעו ישירות בקבצי הליבה הם המקור השכיח ביותר לכשלים בעדכון. הליבה דורסת את הקובץ שהשתנה בגרסה התקנית, וההתאמה נעלמת בשקט: העדכון עובר, וכעבור כמה ימים טופס ההזמנה מפסיק לעבוד או שהייצוא למערכת הנהלת החשבונות נשבר.
ככל שהשינויים חיו בליבה זמן רב יותר, כך יקר יותר לשחזר את הלוגיקה — לפי הקוד כבר איש לא זוכר למה הוא שונה.
תחילה משרטטים תמונה מלאה: משווים גרסאות של קבצי האתר הפעיל לליבה התקנית של הענף העדכני — שורה אחר שורה, לא לפי תאריך שינוי. כך מפרידים קוד תקני מקוד מותאם, ומתקבלת רשימה של מקומות שבהם הלוגיקה סוטה מהליבה. כל אי-התאמה מתארים: מה היא עושה, איזה תהליך היא מכסה, ומה יקרה בחזרה לתקן.
לאחר מכן מעבירים את השינויים מחוץ לליבה — למקום שבו העדכון לא יגע בהם. רוב ההתאמות מצטמצמות למטפלי אירועים, מודול משלנו, תבניות קומפוננטות במרחב שמות נפרד ודריסת תבניות פלט. מה שאי אפשר להוציא מעצבים כפאצ' מודע: עם תיאור, הצמדה לגרסה וסימון ביומן.
ההגנה על ההתאמות היא נוהל בתוספת אוטומציה: בקרת שלמות של קבצי הליבה בסביבת הבדיקות ובאתר הפעיל, איסור שינויים בספריית הליבה למפתחים, ומיפוי פאצ'ים לפני כל עדכון. עדכון הליבה מפסיק להיות סיכון: או שהשינויים כבר הוצאו, או שידוע עליהם מראש.
חששות לגבי תאימות, חזרה לאחור וחלון עבודה
לפני עדכון הליבה הלקוח מחזיק בראש שלושה סיכונים: מודולי צד שלישי, היעדר דרך חזרה והשבתה. החששות אינם מופשטים — הם עומדים בבסיס רוב האירועים בעת העדכון. נפרט כיצד כל אחד מהם נסגר עוד לפני תחילת העבודה.
הפרדת סביבות מסירה מראש את רוב הסיכון: עותק מלא של סביבת הייצור עם אותם מודולים, הרשאות וסנכרון עם 1С מתעדכן ראשון ועובר מחזור בדיקות מלא.
מודול אינו תואם לענף הליבה החדש — מה אז?
תאימות מודולים בודקים לפני העבודה: משווים דרישות ספקים מול ענף הליבה המיועד, ובנפרד — מודולים שהותאמו לפרויקט. אם אין בילד לענף החדש, יש שלושה מסלולים: לעדכן לגרסה תואמת, להחליף בפתרון מקביל או להעביר את הפונקציונליות לקוד משלנו. את הבחירה מקבעים לפני ההתחלה, לא ברגע העלאה.
איך בנויה תוכנית חזרה לאחור?
היא נכתבת מראש: נקודת בקרה של מסד הנתונים והקבצים, סדר החזרת הליבה והמודולים, תנאים להפעלת חזרה לאחור, ואחראי על ההחלטה. זהו נוהל ממוספר שמחזיר את הסביבה למצב ההתחלתי בדקות, ולא בשעות של חיפוש סיבה.
איזה חלון עבודה יידרש?
החלק העיקרי הוא הכנה, והוא מתבצע בלי לעצור את האתר. השבתה נדרשת רק להעלאה: את החלון מתאמים לשפל תעבורה, והוא נמשך עשרות דקות. בפרויקטים מסביב לשעון מפצלים את ההעלאה לשלבים תוך שמירה על זמינות.
איך בודקים את התוצאה לאחר העדכון?
בדיקה חוזרת מתבצעת לפי צ'ק-ליסט: תרחישי משתמש, אזור ניהול, סנכרון עם 1С, הרשאות גישה, יומן שגיאות וזמן תגובה. משווים לנקודות הבקרה שנלקחו לפני העבודה, וכעבור כמה ימים עוברים על הלוגים פעם שנייה — כך נתפסים תרחישים נדירים.
נדון במשימה: הערכה, תוכנית עבודה, אחריות על שינויים
כדי לדון במשימה לעניין אין צורך בביקורת מלאה — די במה שכבר יש לכם. ככל שהנתונים הראשוניים קונקרטיים יותר, כך הערכת העבודה מדויקת יותר: בעדכון הליבה של 1С-Битрикс אנחנו מסתכלים לא על משאלות אלא על הקונפיגורציה בפועל של הפרויקט, מודולי צד שלישי והיסטוריית השינויים.
בהתחלה שלחו:
- ארכיון האתר או גישה לסביבת הבדיקות: ליבה, תבנית, מודולים מותאמים אישית, דאמפ של מסד הנתונים;
- רשימת התאמות שתיקנו ישירות ליבה, קומפוננטות או תבניות;
- לוגים של שגיאות ושאילתות איטיות מהשבועות האחרונים — מהם רואים מה יצוץ לאחר העדכון;
- תיאור אינטגרציות: 1С, CRM, מחסן, תשלומים, שירותים חיצוניים;
- מגבלות חלון העבודה: השבתה מותרת, שעות עומס שיא, מי מאשר את הגרסה.
בתגובה נחזור עם הערכה ותוכנית עבודה: מפת תלויות מודולים, סדר עדכון עם נקודות חזרה לאחור, פילוח לפי שלבים ומאמץ עבודה. סדר העברת ההרשאות נדון בנפרד — דרך ערוץ מאובטח, עם תיעוד של מי ומה יש לו גישה וממתי היא נשללת.
את העבודות מלווה אחריות על שינויים: אם לאחר עדכון הליבה התגלה פגם בגלל השינויים שלנו, אנו מתקנים אותו בתוך פרק זמן מוסכם, בלי סבב אישורים נפרד. תארו את המשימה — נחזור עם הערכה ותוכנית.