ארכיטקטורת 1С-Битрикс: היכן נשבר גידול העומס
ארכיטקטורת 1С-Битрикс נדיר שנשברת בבת אחת — היא מדרדרת בהדרגה, והאות הראשון נראה בדרך כלל כמו "הפך איטי יותר אחרי העדכון הבא של הקטלוג".
קטלוג של עשרות אלפי פריטים, סנכרון עם מערכת הנהלת החשבונות ונתח גדל של מבקרים מחוברים מצטברים לצוואר בקבוק: העומס על הקטלוג גדל מהר יותר מיכולות השרתים.
צווארי הבקבוק האופייניים של Bitrix ידועים: צומת אחד משרת גם את הקטלוג, גם את עגלת הקניות וגם את ממשק הניהול; הסנכרון עם מערכת הנהלת החשבונות מתבצע באופן סינכרוני ומחזיק טבלאות בנעילה; משימות מתוזמנות רצות בזו אחר זו ומתחרות על אותם נתונים. בנפרד כל מרכיב נסבל — יחד הם יוצרים גידול לא לינארי בזמן התגובה.
סיפור נפרד — המטמון. הוא לא מספיק להתחמם אם ביטול התוקף מופעל על כל שינוי של מוצר, ועמודי הקטלוג נבנים מחדש עבור כל אורח. מטמון מנוהל ומטמון מורכב עוזרים, אך דורשים תלויות תקינות והפרדה של החימום לפי לוח זמנים — אחרת לאחר איפוס האתר סופג מטח של שאילתות כבדות.
ביקורת ארכיטקטורת האתר מתחילה לא מהקוד, אלא ממפת נקודות הכשל של האתר: כמה צמתים, היכן יושבת מסד הנתונים, מי ומתי כותב לקטלוג, מה קורה כאשר מערכת הנהלת החשבונות אינה זמינה. בהמשך — מדידות: תוכנית הביצוע של שאילתות כבדות, נתח העמודים מהמטמון, זמן החימום. כך רואים מה נפתר בהגדרות ומה דורש הוצאת הסנכרון לתור והפרדה בין קריאה לכתיבה. מפרקים כיצד זה נסגר.
מה נותנת ארכיטקטורה מדויקת על 1С-Битрикс
בנייה מחדש של ארכיטקטורת 1С-Битрикс מתחילה לא בקוסמטיקה, אלא במדידות: כמה מחזיר עמוד המפתח תחת עומס, אילו שאילתות יוצאות למסד הנתונים, מה נשמר במטמון ומה מחושב מחדש בכל פנייה.
לאחר הוצאת השאילתות הכבדות והגדרת המטמון, זמן התגובה של הקטלוג ושל כרטיסי המוצר מפסיק להיות תלוי בגודל מסד הנתונים — העמוד מוחזר בשברירי שנייה ומחזיק שיא תנועה בלי להגדיל את מספר השרתים.
עמידות האתר בפני כשל היא תוצאה של הפרדת תפקידים, ולא של צומת חזק אחד: האפליקציה, מסד הנתונים, הקבצים ותור משימות הרקע חיים בנפרד, המצב משוכפל, ונקודת הכשל היחידה נעלמת מהתרשים.
זמן ההתאוששות נמדד אז בדקות, ולא בשעות של המתנה לגיבוי, משום שהמעבר לצומת הגיבוי מתואר בנוהל ותורגל בתרגילים, ולא מומצא ברגע התקלה.
עלות ההשבתה נמדדת בהזמנות ובפניות שהוחמצו, ולא בסיכונים מופשטים: כל עוד האתר אינו זמין, הלקוח עובר למתחרה ושב רק לעתים רחוקות. לכן השאלה הראשונה בייעוץ היא כמה דקות של אי-זמינות הענף מחשיב כקבילות ומה בדיוק חייב להמשיך לעבוד: קליטת בקשות, אזור אישי, אינטגרציה עם המחסן.
הפצת גרסאות מקבלת גבול מדיד באותה מידה: סט השינויים עובר בנייה ובדיקות אוטומטיות, לשרת מגיע ארטיפקט מוכן, והחזרה לגרסה קודמת היא פעולה אחת. היקף הפעולות הידניות מצטמצם מעשרות שלבים לכמה אישורים, והעדכון מפסיק להיות אירוע שדוחים ללילה.
נקודות ביקורת לאחר הבנייה מחדש — זמן התגובה של עמודי המפתח, שיעור הכשלים, זמן ההתאוששות ומספר הפעולות הידניות בהפצה.
מצבי עבודה: צומת אחד, קלאסטר, הפרדת תפקידים
מצב העבודה קובע מה בדיוק יצטרכו לשנות כשהעומס יגדל פי שניים: להגביר שרת אחד, לפזר את התפקידים בין מכונות או להוסיף צמתים מאחורי מאזן עומסים. הבחירה תלויה לא בגודל הקטלוג, אלא במקום שבו המערכת נתקעת כעת — בדיסק, במסד הנתונים או בעיבוד השאילתות. להלן אפשרויות אמיתיות, שביניהן בוחרים בהתחלה ובמעבר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| צומת אחד | קטלוג של כמה אלפי פריטים, תנועה אחידה, קבצים ומסד הנתונים על אותה מכונה | כל תקלה מפילה את האתר כולו; גיבוי ועדכונים דורשים עצירה |
| הגברת צומת אחד | הגידול צפוי מראש, צוואר הבקבוק — המעבד או הדיסק | נתקע בתקרת התצורה, הכשל נשאר נקודה יחידה |
| הפרדת תפקידים | ייצוא כבד מ-1С, ארכיון קבצים גדול, הרבה משתמשים מחוברים | התפקידים מחוברים ברשת: שכפול מושהה וזמן המתנה קצר יוצרים אי-סנכרון בנתונים |
| קלאסטר שרתים | מבצעי שיא, תנועה עונתית, דרישת עמידות בפני כשל | נדרשים אחסון קבצים משותף והוצאת הסשנים, אחרת המבקר "מועבר" בין הצמתים |
קלאסטר ואיזון עומסים עובדים רק יחד עם אחסון קבצים משותף ורפליקה מדויקת של מסד הנתונים. אם התמונות והמטמון נשארים מקומית בכל צומת, המבקר מקבל גרסאות שונות של העמוד בכל רענון; אם הכתיבה מתבצעת ברפליקה — עגלות הקניות וההזמנות מתפצלות.
לכן את המצב בוחרים לפי דרישות ההתאוששות, ולא לפי מספר השרתים: תחילה קובעים את זמן ההשבתה הקביל, ואחר כך מתאימים לו את התרשים.
שלבי העבודה: מביקורת התרשים ועד מסירת נהלים
העבודה מתנהלת ברצף קבוע: כל שלב נסגר בארטיפקט שאפשר לבדוק לפני המעבר לשלב הבא. כך אנחנו לא מעבירים לסביבת העבודה משהו שלא בדקנו, ולא משנים את הארכיטקטורה בחלקים — אחרת לא ניתן יהיה להפריד בהמשך בין סיבות ההידרדרות לתוצאות התיקונים.
- ביקורת תשתית. אוספים עובדות: גרסאות הליבה והמודולים, תצורת שרת האינטרנט ומסד הנתונים, מתזמן המשימות, התורים, האינטגרציות החיצוניות, השיאים בפועל לפי לוגי התנועה. בתוצר — מפת המצב הנוכחי ורשימת צווארי בקבוק, ולא מסקנות כלליות.
- תרשים הארכיטקטורה. מתכננים את הפרדת התפקידים הרצויה: שכבת הווב, מסד הנתונים, המטמון, החיפוש ומשימות הרקע המוצאות. קובעים את נקודות הכשל, ההתנהגות בעומס יתר ואת סדר הפעולות בעת חזרה לאחור.
- הרכבת סביבת בדיקה. פורסים עותק עם נתונים אנונימיים ואותן גרסאות רכיבים כמו בסביבת העבודה. אחרת תוצאות הבדיקות עליו לא מוכיחות דבר.
- בדיקת עומס. את פרופיל העומס בונים לפי לוגים אמיתיים, ולא לפי ערכים ממוצעים. מעלים את העומס בהדרגה ובודקים את זמן התגובה בתרחישי המפתח, את שיעור השגיאות, את צריכת המשאבים ואת המקום שבו המערכת נשברת ראשונה.
- העברה ללא השבתה. מעבירים את התנועה לתרשים החדש בחלון עבודה מינימלי: סנכרון נתונים, מעבר, מדידות ביקורת. החזרה לאחור מתבצעת לפי נוהל מתואר מראש, ולא לפי החלטה שמתקבלת במקום.
- נראות. מגדירים מדדים וספי התראות לפי צמתים, תורים וזמן תגובה — כדי שההידרדרות תתגלה לפני תלונות המשתמשים.
- מסירת נהלים. מוסרים את התרשים, כללי העדכון, הוראות לאירועים טיפוסיים וניתוח השינויים לצוות הלקוח.
מה נשאר בפרויקט לאחר מסירת העבודה
מסירת הפרויקט היא לא ארכיון ושיחת פרידה. אנחנו מוסרים ערכה שלפיה הצוות שלכם יכול לפרוס סביבה מאפס, להוציא גרסה, להחזיר אותה לאחור ולנתח אירוע בלעדינו. הכול נכתב עבור התשתית הספציפית של הפרויקט, ולא לפי תבנית, ומתעדכן לאורך העבודה.
- תרשים התשתית — סביבות הפיתוח, הקבלה והפרודקשן, תפקידי השרתים, הקשרים עם 1С ושירותים חיצוניים, נקודות הכניסה של התנועה, המטמון ותורי העיבוד; בנפרד מסומנים צווארי בקבוק ותלויות חיצוניות.
- תיעוד הפרויקט — מבנה הפתרון, רכיבים ומודולים מותאמים אישית, קבצי ליבה ששונו, היסטוריית החלטות ארכיטקטוניות עם נימוקים: מדוע נעשה כך ומה נדחה.
- תצורות הסביבות — פרמטרי המטמון והאינדוקס, משימות מתוזמנות וסוכני רקע, ערכים שמשנים את התנהגות האתר, עם סימון מה ניתן לשנות בבטחה.
- מדיניות גישה — תפקידים בפאנל הניהול לפי בלוקי מידע ומדורים, הרשאות על השרת, סדר הענקה ושלילה של גישות, רוטציה של מפתחות וחשבונות.
- נוהל תחזוקה — תדירות הגיבוי ובדיקת השחזור, סדר עדכון הפלטפורמה, חלונות עבודה, ערוצי התראות וקריטריונים להסלמה.
- הוראות תמיכה — פעולות טיפוסיות שלב אחר שלב: פרסום תוכן, הוצאה והחזרה לאחור של גרסה, חיבור אינטגרציה חדשה, אבחון של כשלי מטמון וסנכרון נפוצים.
- מרשם האינטגרציות ופרטי הגישה — מה קשור למה, היכן מאוחסנים המפתחות, איזה צד אחראי על הסנכרון ומה לעשות במקרה של אי-התאמה בנתונים.
הקבלה מתבצעת לפי צ'ק-ליסט: אתם בודקים שלפי ההוראות אכן נפרסת הסביבה ומתבצעת החזרה לאחור, ולא רק שקיימים המסמכים.
מקרה בוחן: כיצד פיזרו את העומס והסירו את נפילות הקטלוג
מה היה
קטלוג על 1С-Битрикс רץ על שרת אחד: האפליקציה, מסד הנתונים והסנכרון עם מערכת הנהלת החשבונות חלקו את אותם משאבים. הסנכרון הופעל לפי לוח זמנים ובמהלך ייצוא המחירים והמלאי תפס את החיבורים למסד הנתונים — הכרטיסים החלו להיות מוחזרים בשניות, וחלק מהשאילתות נכשלו עקב חריגה מזמן ההמתנה. השיא נפל על הבוקר, כשהמנהלים פתחו את פאנל הניהול והמבקרים — את הקטלוג.
מה שינו
פיצלו את התפקידים: צומת נפרד לאפליקציה, צומת נפרד למסד הנתונים עם רפליקה לקריאת הקטלוג, והמטמון הוצא לשירות משותף. את הסנכרון העבירו למצב אסינכרוני דרך תור — מנות הנתונים נצברות באחסון ביניים ומיושמות שלב אחר שלב, בלי לחסום את הוויטרינה.
למדורים שנפתחים לעתים קרובות הוגדר חימום מטמון לאחר הפרסום: העמוד נבנה מראש, ולא על ידי המבקר הראשון.
מה נהיה
הקטלוג הפסיק להיות תלוי בלוח הזמנים של הסנכרון: הייצוא מתבצע במקביל לעבודת הוויטרינה. זמן התגובה של הכרטיסים בשיא הצטמצם פי כמה, והכשלים עקב חריגה מזמן ההמתנה במדור הקטלוג נעלמו.
הסנכרון הפך לנראה — הסטטוס של כל מנה נראה בלוג, מנה לא מלאה מיושמת מחדש ואינה גוררת אחריה את האחרות, בעוד שלפני כן היה צריך להפעיל מחדש את כל הייצוא.
את המדידות ביצעו לפי אותם תרחישים לפני ואחרי: פתיחת הקטלוג, כרטיס מוצר, חיפוש. לכן המספרים בני-השוואה, ואת התרשים — הפרדת תפקידים, סנכרון אסינכרוני, חימום מטמון — ניתן להעביר לפרויקטים אחרים עם ייצוא תכוף.
במה שונה בנייה מחדש על מערכת חיה מהעברה?
אלה שני תרחישים שונים, ובוחרים ביניהם לפי מחיר הטעות. בנייה מחדש על מערכת חיה — התיקונים מוכנסים לסביבה העובדת: תבניות, רכיבים, הגדרות מטמון, מיגרציות ישירות על מסד הנתונים הפעיל. העברת פרויקט — לצד זה מרימים סביבה שנייה, פורסים עותק של מסד הנתונים והקבצים ובודקים את הכול שם.
הבנייה מחדש מנצחת במהירות: אין צורך לסנכרן נתונים ולהמתין לחימום הסביבה החדשה. אבל הסיכונים של השינויים נופלים על המשתמשים — מיגרציית התרשים מתבצעת על נתונים חיים, החזרה לאחור אפשרית רק מעותק שנשמר, ואיפוס המטמון מורגש על שאילתות חיות.
ההעברה יקרה יותר בהכנה: סביבת הבדיקה צריכה לחזור על סביבת הפעילות — אותה גרסה של 1С-Битрикс, אותה תצורת שרת אינטרנט, אותו מנוע חיפוש ואותם כללי סנכרון עם 1С.
לעומת זאת, את המעבר ללא השבתה מבצעים ברמת הניתוב: מחזיקים את שתי הסביבות, מעבירים את השינויים שנצברו במסד הנתונים, מעבירים את הדומיין וסוגרים את הכתיבה לישן.
כלל הבחירה פשוט. אם משתנים מבנה בלוקי המידע, המאפיינים, כללי הסנכרון עם 1С או הלוגיקה של המודולים — זו העברה: מחיר הטעות גבוה ממחיר הסביבה השנייה. קוסמטיקה בתבנית, הגדרות מטמון ותיקונים נקודתיים ברכיבים מותרים על סביבה חיה — כשקיים עותק שמור ותוכנית חזרה לאחור.
אנחנו מפרקים את המשימה לפי שני התרחישים האלה כבר בשלב ההערכה ומראים היכן נקודת האל-חזור — לפני תחילת העבודה.
ספקות טכניים נפוצים לפני תחילת העבודה
הספקות בהתחלה הם כמעט תמיד הנדסיים, ולא ארגוניים: מה יקרה לאתר העובד, למה יהפוך הקוד לאחר העדכון, האם ריאלי לנהל את הפרויקט בכוחות עצמכם. להלן השאלות שנשאלות בתדירות הגבוהה ביותר, והתשובות לגופן.
האם יהיה צורך לעצור את האתר במהלך העבודה?
לא. אנחנו מעבירים ומעדכנים על עמדה נפרדת עם עותק של מסד הנתונים והקבצים, בודקים תרחישים קריטיים — הזמנה, תשלום, אימות, ייצוא למערכת הנהלת החשבונות. הפרסום הוא מעבר לסביבה המוכנה; החזרה לעמדה הקודמת נמשכת דקות.
האם עדכון הליבה ישבור את ההתאמות שלנו?
לא ההתאמות כשלעצמן נשברות, אלא פתרונות שעוקפים את נקודות ההרחבה הסטנדרטיות: תיקונים ישירות בליבה, תבניות מונוליטיות. אנחנו ממפים את המקומות האלה ומעבירים את הלוגיקה למנגנונים הסטנדרטיים — מכאן והלאה העדכונים מותקנים בלי מיזוג קבצים ידני.
האם מספר השגיאות יגדל לאחר העדכון?
תחילה גדלה הנראות שלהן: מפעילים לוגים ומערכת בדיקות רגרסיה על המסלולים הקריטיים. את העדכון מתקינים בשלבים עם בדיקה אחרי כל שלב — סיבת התקלה נראית מיד, והחזרה לאחור נשארת נקודתית.
האם נוכל להמשיך לנהל את הפרויקט בכוחות עצמנו?
כן, וזהו תנאי למסירה תקינה. מוסרים תיעוד ארכיטקטורה, תרשים הסביבות, נוהל עדכונים ויומן שינויים. את המהנדסים שלכם מכניסים לסביבה מראש: ניתוח קוד, גרסאות משותפות וניתוח אירועים בצד שלכם.
אם המקרה שלכם לא נכנס לרשימה — תארו את המשימה, ננתח בנפרד ונחזור עם הערכה ותוכנית.נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהערכת לוח הזמנים תתבסס על עובדות ולא על הנחות, יש צורך בנתוני פתיחה על הפרויקט. ארכיטקטורת הפתרון על 1С-Битрикс נקבעת לפי העומס, הסנכרונים ומצב הנתונים — הרשימה שלהלן מכסה בדיוק את הנקודות שבהן ההערכה נוטה לסטות מהמציאות בהתחלה.
- הסביבה הנוכחית: גרסת המוצר, היכן מתארח האתר, כיצד מופצים השינויים ומי עושה זאת.
- אינטגרציות: עם מה מתבצע הסנכרון (מערכת הנהלת החשבונות, המחסן, תשלומים, משלוחים, שירותי דיוור), לפי איזה לוח זמנים ומה קורה בעת ניתוק הקשר.
- עומס: תנועה יומית, קפיצות שיא, היקף הקטלוג ומספר המשתמשים בו-זמנית בשעות השיא.
- נתונים: היקף הקטלוג וההזמנות, מהיכן מעבירים, האם יש לשמור היסטוריה וקשרים בין הישויות.
- מגבלות: תאריכים קשיחים, נהלים ודרישות לגישות, ומה אסור לשנות בסביבה הנוכחית.
- עדיפויות: מה קריטי בשלב הראשון ומה ניתן להעביר לשלב הבא.
לפי נתוני הפתיחה האלה נחזור עם תוכנית עבודה לפי שלבים, הערכת לוחות זמנים והרכב העבודה — מתכנון ועד העלאה לפרודקשן. אם חלק מהנתונים טרם נאסף, נדון במשימה כפי שהיא ונקבע את ההנחות בכתב, כדי שתחילת הפרויקט לא תהפוך לבנייה מחדש של ההסכמות.