בחירה והתקנה של מהדורת 1C-Bitrix Standard

מדוע «1С-Битрикс Стандарт» אינו עומד בעומס שיא

מהדורת «Стандарт» מיועדת לאתר אחד ולזרימה מתונה, ולכן בחודשים הראשונים הכול נראה תקין: העמודים נטענים מהר, ממשק הניהול מגיב. צוואר הבקבוק באתר מתגלה לא בהתחלה, אלא בשיא האמיתי הראשון — מבצע מכירות, עלייה עונתית או קמפיין פרסומי שהביא תנועה לפני שהספקתם למדוד אותה.

תקרת העומס מובנית במהדורה מלכתחילה. אין מטמון מרוכב, ולכן כל מבקר מזוהה בונה את העמוד מחדש, ומסנני הקטלוג והבלוקים האישיים פונים למסד הנתונים בשאילתות נפרדות בכל הצגה.

ברגע שמספר העגלות במקביל עובר את העשר, זמן התגובה גדל באופן לא ליניארי: המעבד עדיין לא בתקרה, אבל תור השאילתות כבר מחזיק את הקונה על מסך לבן.

לכך מתווספות מגבלות המהדורה שלא ניתן להסיר באמצעות הגדרה. אין הפרדת תפקידים בין מנהל לעורך תוכן לפי מודולים — ההרשאות ניתנות בגסות רבה מהנדרש. עדכון הליבה והמודולים מתבצע ישירות על האתר הפעיל, בלי מסלול בדיקות, ולכן כל שינוי נבדק מיד על גבי מבקרים אמיתיים. גם שחזור לנקודה בזמן וגם תצורה עמידה לתקלות מכמה שרתי אפליקציה אינם כלולים כברירת מחדל.

המחיר של סכמה כזו צפוי מראש: ירידת ביצועים בשעות שיא הופכת לעגלות נטושות ולפניות לתמיכה, עדכונים — לחלונות אי-זמינות, והשחזור לאחר תקלה תלוי במי ומתי עשה גיבוי ידני.

בהמשך נבחן כיצד סוגרים זאת — מה נפתר במעבר למהדורה בכירה יותר, ומה נפתר ארכיטקטונית: באמצעות מטמון, הוצאת מסד הנתונים והפרדת תפקידים.

מה משתנה לאחר בנייה נכונה של הסביבה

סביבה שנבנתה כראוי משנה לא את «מהירות האתר», אלא את סוג התקלות שהצוות מתמודד איתן. כאשר הגדרות השרת, ענף סביבת ההרצה, מגבלות הזיכרון והמטמון מותאמים בהרמוניה, חלק מהבעיות פשוט לא מתרחשות: שגיאות בשיא התנועה אחרי דיוור, קריסות בעת ייצוא הקטלוג, עמודים ריקים ברגע העדכון.

זמן השחרור של שינוי מתקצר, כי הבנייה והפריסה מפסיקות להיות פעולה ידנית על אתר חי. זמן ההתאוששות הופך לצפוי מראש: העתקה של מסד הנתונים והקבצים נלקחת לפי לוח זמנים, והחזרה לגרסה הקודמת היא הליך של כמה דקות במקום חיפוש הסיבה בלוגים.

הפרדת התפקידים מסלקת מקור יקר של שגיאות — מצב שבו אדם אחד גם עורך תוכן, גם משנה תצורה, וגם מקצה הרשאות. הרשאות המנהל, העורך והמפתח מופרדות, והשינויים עוברים דרך מסלול בדיקה ברור.

בקרת העדכונים מתבצעת במסלול נפרד: ענף ליבה חדש של 1С-Битрикс אינו נפרס מיד על האתר הפעיל, אלא נבדק על העתקה עם המודולים וההתאמות האמיתיים. כך העדכון מפסיק להיות אירוע עם תוצאה לא ברורה.

היציבות תחת עומס ניכרת בכך שתנועת שיא לא מביאה לירידת ביצועים: מטמון, מגבלות נכונות ומשימות רקע שהוצאו החוצה מנטרלים את השיאים. התפעול הופך לניהולי — ברור היכן צוואר הבקבוק, מה להחזיר אחורה ובכמה זמן.

מהדורת «1С-Битрикс Стандарт»: אפשרויות פריסה

1С-Битрикс «Стандарт» מיועד לאתר אחד: ריבוי אתרים, קלאסטרינג וחלק מהכלים לעמידה בתקלות מופיעים רק במהדורות בכירות יותר. זוהי מגבלה של המהדורה, ולא של השרת, והיא בדיוק קובעת כיצד לתכנן את הסביבה עם מרווח לצמיחה.

בפועל בוחרים בין שרת וירטואלי, שרת ייעודי ואחסון מנוהל. הראשון מכסה את ההתחלה, השני — עומס צפוי ושליטה מלאה בהגדרות, והשלישי מסיר מעליכם את הניהול, אך מגביל את הגישה לתצורת הסביבה.

עם הצמיחה משתנה לא המהדורה, אלא הסביבה: מעבירים את מתזמן המשימות, הגדרות המטמון והאינדוקס, כללי הגיבוי, ההרשאות ומגבלות הזיכרון. את המעבר מבצעים דרך סביבת ביניים עם השוואה על תנועה אמיתית והחזרה אחורה — האתר לא נכנס להשבתה.

סדר ההתקנה: מהסקר ועד למסירה

התקנת מהדורת «Стандарт» אינה פריסת ארכיון על האחסון, אלא רצף שלבים שכל אחד מהם נשען על התוצאה של הקודם. תדלגו על סקר הסביבה — ותצטרכו לעצב מחדש אתר שכבר עובד. לכן אנחנו קובעים את הסדר מראש ומקפידים עליו.

1. סקר הסביבה. בודקים גרסאות PHP ומערכת ניהול מסדי נתונים, מגבלות זיכרון וזמן ריצה, הרשאות לספריות, פעולת הדואר והמתזמן, איכות הגיבויים. בפלט — רשימת מגבלות שאנחנו מסירים לפני הפריסה.
2. תרשים הפריסה. קובעים את הרכב המסלולים: פעיל, בדיקות, אחסון סטטי, מטמון. בנפרד מחליטים מה מוציאים אל מחוץ לספריות המתעדכנות, כדי ששחרורים לא ידרסו הגדרות.
3. פריסה והגדרה. מתקינים את הפלטפורמה, מפעילים את הרישיון, מחברים את המודולים הנדרשים, מגדירים את התבנית, הרשאות הגישה ושליחת הדואר.
4. העברת מסד הנתונים והנתונים. מעבירים את המבנה והתוכן, בודקים את שלמות הקישורים והמדורים, בונים מחדש את אינדקס החיפוש, מגדירים הפניות מכתובות ישנות.
5. בדיקת עומס. מריצים את התרחישים המרכזיים תחת עומס, מודדים את זמן התגובה ואת הפגיעה במטמון, מכבים סוכנים מיותרים ושאילתות כבדות.
6. הדרכה ומסירה לתמיכה. קובעים נוהל עדכונים וגיבוי, מגדירים ניטור, מוסרים הרשאות ועוברים על הכול עם הצוות שלכם.

בתוצאה — תרשים סביבה עובד, נוהל תחזוקה ונקודת כניסה ברורה למשימות חדשות, בלי תלות במפתח מסוים.

תצורות, הרשאות ותיעוד בתוצאה

הפרויקט נמסר לא כארכיון שתצטרכו לפענח מהזיכרון, אלא כמערכת שמוכנה למסירה לקבלן אחר או למנהל מערכת פנימי. עבור כל התקנה על 1С-Битрикс החבילה זהה — ההרכב שלה מופיע בהמשך.

• קבצי תצורה וייצוא. תבנית הפתרון, מבנה בלוקי המידע, מאפיינים מותאמים אישית וכללי הכתובות: את הסביבה מרימים מאפס בדרך ניתנת לשחזור, בלי «השלמות» ידניות.
• תרשים הסביבה. חלוקה לפיתוח, תצוגה מקדימה ומסלול פעיל — מה נמצא היכן, כיצד מועברים שינויים, אילו צמתים חשופים החוצה.
• מדיניות גישה לפי תפקידים. הרשאות העורך, המנהל והאדמין מופרדות לפי מדורים ומודולים: העורך אינו עורך תבניות, והגישה לגיבויים ולעדכונים נשארת בידי התפקיד הטכני.
• נוהל עדכון. מצוין על איזה מסלול נבדק תחילה עדכון הליבה והמודולים, מי מאשר את השחרור וכיצד מחזירים גרסה אחורה אם אחריו נשברה הפריסה.
• גיבוי ותוכנית שחזור. מה מגבים (קבצים, מסד נתונים, תצורה), באיזו תדירות, היכן נמצאת העתקה מחוץ לשרת הראשי ובכמה זמן מתרומם המסלול הפעיל.
• הוראות לעורכים. חומרים שלב-אחר-שלב עם דוגמאות: כיצד ליצור עמוד, להחליף באנר, להעלות מסמך ומה אסור לעשות.
• פרטי גישה ומטריצת אחריות. מי הבעלים של ההרשאות, כיצד הן מועברות בעת החלפת עובד ומבוטלות בעת עזיבה.

הקבלה מתבצעת לפי הסעיפים הללו: פורסים את הסביבה על שרת נקי, משחזרים את המערכת מהעתקה ונותנים לעורך לפרסם עמוד בלי עזרתנו.

ניתוח מקרה: כיצד חנות מקוונת עברה את שיא העונה

חנות עם מבחר של כמה אלפי פריטים פעלה על המהדורה הצעירה של המוצר ועל אחסון משותף. הקטלוג התעדכן בייצוא ממערכת החשבונאות, שאותו המפעיל הריץ ידנית ותיקן בנפרד את המלאי — זה גזל שעתיים-שלוש ביום. בשיא העונתי זמן התגובה של הקטלוג עבר את 5 השניות, ושיעור הנטישות בשעות המבצע הגיע ל-40%.

בשלב הראשון העברנו את החנות לשרת ייעודי, הפרדנו קריאה וכתיבה דרך רפליקה של מסד הנתונים, והעברנו את הסטטי בנפרד מהאפליקציה. לאחר מכן עברנו למהדורה בכירה של 1С-Битрикс והפעלנו מטמון מרוכב על רשימות ועמודי מוצר, שבהם הרכב המידע זהה לכל המבקרים.

את הסנכרון עם מערכת החשבונאות העברנו ללוח זמנים עם ייצוא דלתא: לייצוא נכנסים רק פריטים שהשתנו, ולא הקטלוג כולו.

וכך נהיה: זמן התגובה של הקטלוג — 0.7–1.2 שניות באותם תרחישי שיא, שיעור הנטישות בשעות המבצע — 6–9%, מספר הפעולות הידניות בעדכון הקטלוג ירד מעשרים לשלוש, ופרסום שינויי המחירים והמלאי התקצר משלוש שעות ל-15 דקות.

את שיא העומסים עברה החנות בלי אף קריסה של העגלה ושל תהליך ביצוע ההזמנה — קודם לכן, במבצע, כשהחיפוש נפל אז העגלה.

בנפרד הרצנו תרחיש חזרה: המדידות נלקחו על העתקה של מסד הנתונים הפעיל, ותצורת השרת ופרמטרי המטמון מקובעים במאגר הקוד. המשמעות היא שבצמיחת התנועה העונתית הבאה יש לאן להתרחב, והחזרה למצב הקודם אורכת דקות ולא יממה של חיפוש הסיבה.

מה לעשות אם מגבלות המהדורה אינן מספיקות

המחסור במכסות המהדורה של 1С-Битрикс לא מתבטא בהודעת חריגה, אלא בכשל של תרחיש מסוים: אתר שני אינו נוצר כי ריבוי אתרים אינו זמין, המטמון המרוכב אינו נדלק בלי המודול הנדרש, והסנכרון עם 1С מפסיק להיכנס לחלון הלילה.

סוג אחר של סימנים הוא משאבי: הקטלוג נטען לאט מהמותר, החיפוש נופל באינדוקס מחדש מלא, ופניות הולכות לאיבוד בשיא. שדרוג המהדורה לא יעזור כאן — קודם מסירים פרופיל עומס ובודקים לאן הולך הזמן.

הצעד נבחר לפי תוכנית הפיתוח של הפרויקט, ולא לפי הסימפטום הנוכחי. אם בתוכנית יש אתר שני, סניף או אזור אישי של סוחר — מכסת הרישיון תיפגע שוב, ומעבר למהדורה בכירה משתלם יותר מבחינת לוחות זמנים מעיצוב מחדש של הארכיטקטורה.

אם רק התנועה גדלה — הוצאת שירותים וכיוונון נוסף סוגרים את המשימה בלי החלפת מהדורה. סדר העבודות: ספירת מודולים ומכסות, מדידת צווארי בקבוק, החלטה על הצעד, ורק אחר כך שינויים. כך לא לוקחים הרחבה במקום שבו הגדרה הייתה עוזרת.

שאלות טכניות נפוצות לפני ההתקנה

להתקנת מהדורת Стандарт כמעט תמיד מגיע אותו מערך של ספקות: האם הרישיון יספיק לפיתוח הפרויקט, האם המודול הנוכחי יעבוד, כיצד יסתיים העברת הנתונים שנצברו, האם אפשר להתעדכן בלי לעצור את האתר והאם השרת הנוכחי יעמוד בכל זה.

את השאלות האלה אנחנו מסירים לפני תחילת העבודות — בהן תלויים בחירת המהדורה, תרשים ההגירה וסדר העדכונים. להלן תשובות קצרות לכל סעיף.

מה לעשות עם מודול צד שלישי שאינו נמצא במרקטפלייס?

קודם בודקים אם יש לו בנייה לענף הליבה העדכני ותמיכה מצד המפתח. אם המודול נכתב בעצמנו, מעבירים את הלוגיקה למנגנונים המובנים או כותבים אותו מחדש בהתאמה לאירועים החדשים — כך עדכוני הליבה מפסיקים לשבור את הפונקציונליות.

כיצד מועברים מוצרים, הזמנות ומשתמשים?

את התוכן מייצאים בייצוא המובנה, ואת ההזמנות וחשבונות המשתמשים — ברמת מסד הנתונים תוך שמירת הקישורים והאש של הסיסמאות, כדי שאיש לא יצטרך לאפס גישה. את ההעברה מבצעים על העתקה, משווים את מספר הרשומות, ורק אחר כך מחליפים את המסלול הפעיל.

אפשר להתעדכן בלי השבתה ומה עם השרת?

עדכונים מתקינים תחילה על מסלול הבדיקות, ואחר כך פורסים לפעיל בחלון של עומס נמוך. את השרת מגדירים לפי התנועה בפועל: מטמון, אינדקס מסד הנתונים, מגבלות על שאילתות כבדות — האתר נשאר זמין, והחזרה לנקודה הקודמת אורכת דקות.

נדון במשימה: מה להבהיר לפני ההתחלה

הערכה מדויקת של המעבר למהדורת 1С-Битрикс Стандарт נשענת על נתוני הפתיחה, ולא על ממוצעים בשוק. ככל שנדון במשימה מוקדם יותר, כך נצטרך לבצע פחות שינויים בתוכנית העבודה לאחר ההתחלה — וסדר השלבים יהיה צפוי יותר.

מה מבהירים בשיחה הראשונה:

• המהדורה הנוכחית ואופן ההתקנה: מופע מתעדכן או כזה שהותקן ידנית, אילו מודולים פעילים;
• פרופיל העומס: כמה מבקרים ופניות לקטלוג בשעות השיא, נפח הקטלוג ואחסון הקבצים;
• הרכב האינטגרציות: סנכרון עם מערכת החשבונאות, שערי תשלום, שירותי משלוחים, שירותים חיצוניים — מה כבר עובד ועל מה נשען החיבור;
• מסלול האחסון: שרת ייעודי, מכונה וירטואלית או ענן, מי אחראי על הגיבויים וההרשאות;
• תוכניות הפיתוח: מדורים חדשים, ריבוי שפות, אזור אישי, מעבר ל-Битрикс24;
• מגבלות: חלון לעבודות תחזוקה, דרישות לזמינות, מי מצד המזמין מאשר את השלבים.

מכאן מרכיבים תוכנית עבודה עם נקודות ביקורת: אישור השלבים, העברת נתונים והגדרות, בדיקה על העתקה טרום-ייצורית, והפעלה עם אפשרות להחזיר שינויים. סדר ההתחלה זהה בכל מקום — קודם מקבעים את גבולות המשימה ואת האחראים, ואחר כך מתחילים.