התקנת Vendure: מה נשבר בסביבת הייצור של החנות
סביבת הייצור של החנות נשברת לא בהתחלה, אלא בעומס שיא. כשמבצע מכירות חופף לשליחה לתפוצת הקונים, הקטלוג מרכיב כל תצוגת סינון מעשרות פניות למסד הנתונים, מאגר החיבורים מפסיק להספיק, וזמן התגובה גדל באופן לא ליניארי: חלק מהעגלות מאבדות את הפריטים שנבחרו, והקונה מגיע לעמוד שגיאה.
אותו צוואר בקבוק של הקטלוג צף גם בחישוב מחדש של הנחות ומלאי — משימה כבדה מתבצעת באותו תהליך שמגיש את העמוד.
הקרע השני — תשלומים תלויים. השער חייב את האמצעים, האישור לא הגיע או עובד פעמיים, ההזמנה נשארה בסטטוס ביניים: המוצר לא נשמר בהזמנה, ההחזר נעשה ידנית, וההתאמה מול הספק מתבצעת לפי ייצוא אחת ליום, כשהפערים כבר הצטברו לכמה ימים.
השלישי — עריכות ידניות בעת עדכון. מודולים, סכמת הנתונים ותהליך השלמת ההזמנה נערכים ישירות על שרת הייצור, כי כך מהיר יותר; אחרי הריליס הבא השינויים נמחקים או מתפצלים מהמאגר, והעדכון הופך לפעולה לילית עם חזרה ידנית והרצת תרחישים לפי רשימת בדיקה על נייר.
התקנת Vendure על סביבה נפרדת מסירה את שלושת הצמתים.
הקטלוג מוגש ממטמון מחומם, משימות כבדות — אינדוקס, חישוב מחדש של מחירים, מיילים — עוברות ל-Workers נפרדים דרך התור, אישורי תשלום מעובדים באופן אידמפוטנטי, עם ניסיונות חוזרים ויומן פערים, כדי ששליחה חוזרת של Webhook לא תיצור הזמנה שנייה.
העריכות נמצאות במאגר: המיגרציות מנוהלות בגרסאות, הגדרות הסביבה הוצאו מהקוד, והבנייה והסכמה נבדקות לפני העלייה לאוויר.
מפרקים איך זה נסגר: מהכנת השרת והתפקידים ועד תורים, מטמון ובדיקות לפני פרסום.
מה נותנת בנייה נכונה של החנות: מהירות ועמידות בתקלות
בנייה של חנות אונליין על Vendure — סביבה אחת צפויה: הקטלוג, העגלה, השלמת ההזמנה והאדמין עובדים על סט משותף של מודלים וחוזים. לכן זמן התגובה של הקטלוג לא גדל יחד עם גודל התוצאה: סינון וחלוקה לעמודים מחושבים במסד הנתונים, וצבירות כבדות מוגשות ממטמון מחומם. רשימה של מאות פריטים נפתחת באותה מהירות כמו כרטיס של מוצר בודד.
עמידות בתקלות כאן היא סט של פתרונות, לא הבטחה: כמה מופעים של האפליקציה מאחורי מאזן עומסים, מטפלי רקע נפרדים למיילים, לייצוא ולסנכרון מלאי, ומאגרי חיבורים נפרדים למסד הנתונים עבור הוויטרינה והאדמין. כשצומת נופל, התעבורה עוברת למופע חי, וזמן ההתאוששות נמדד בדקות ולא בשעות של השבתה.
יחד עם זה נעלם סוג שלם של תקלות שבדרך כלל צף בשיא: חוסר סנכרון במלאי בין הוויטרינה למחסן, השלמה כפולה של אותה הזמנה בשליחה חוזרת של הטופס, פריטים שאבדו בעגלה אחרי הפעלה מחדש.
זה נסגר בעזרת טרנזקציות ברמת מסד הנתונים ופעולות השלמה חוזרות — סטטוס ההזמנה לא תלוי בכך אם שירות חיצוני הספיק להשיב.
עמידות בעומס נבדקת לא בסינתטיקה, אלא במבצע מכירות: אנחנו מגבילים את מספר הבקשות הכבדות במקביל, שמים במטמון את הקטלוג והקטגוריות, ואת השלמת ההזמנה מחזיקים במאגר נפרד.
הוויטרינה תחת עומס לא מעכבת את התשלום, ולכן שיעור ההזמנות שהושלמו עד תשלום בלי ניסיונות חוזרים ושגיאות נשאר יציב גם בשעות שיא.
אפשרויות פריסה: שרת משלכם, שכירות, תצורה משולבת
מה שקובע את אופן האחסון של חנות על Vendure הוא לא גודל הקטלוג, אלא מי אחראי על עדכוני הליבה, גיבויים והרחבה בשעות שיא. האפליקציה דורשת מנהל תהליכים, מסד נתונים, מטפל למשימות רקע ואחסון מדיה — את זה אפשר להרכיב בעצמכם, למסור לספק או לפצל בין סביבות. להלן שלוש תצורות עבודה והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שרת משלכם | נדרש שליטה מלאה על הסביבה, כללי גישה משלכם ואחסון בתחום שיפוט מסוים | עדכוני מערכת ההפעלה, עדכוני האפליקציה והגיבויים — באחריותכם; טעות בקונפיגורציה גורמת להשבתה בלי תמיכה חיצונית |
| שכירות של שרת מנוהל | אין מהנדס ייעודי, נדרשת הפעלה מהירה ותפעול בסיסי צפוי | תקרת העומס נמוכה יותר, מגבלות על משימות רקע ארוכות וגודל התור, חלונות התחזוקה נקבעים על ידי הספק |
| תצורה משולבת | את הוויטרינה והאדמין מתחזק הספק, ואת המשימות הכבדות — עיבוד מדיה, ייצוא, סנכרון עם מערכת הנהלת החשבונות — מוציאים לסביבה נפרדת | רשת והרשאות גישה מורכבות יותר; חובה כללי בנייה אחידים ומשתני סביבה זהים בכל הסביבות |
את התצורה קובעים לפני העברת הנתונים, ולא אחרי: ממנה תלויים שיטת ה-Deploy, נקודות הגיבוי וסדר החזרות לאחור. בשלב ההערכה אנחנו מצליבים את האפשרות שנבחרה עם פרופיל העומס ובודקים שמשימות הרקע ומסד הנתונים לא יהפכו לצוואר בקבוק עם גדילת הקטלוג.
התקנת Vendure שלב אחר שלב: מהאודיט ועד למסירה
סדר העבודה בנוי כך שכל החלטה נשענת על העובדות של השלב הקודם. קודם כל מתעדים מה כבר עובד בסביבה, אחר כך מתכננים את התצורה — ורק אז נוגעים בסביבת הייצור, כדי שההתקנה לא תהפוך לסדרה של עריכות חירום.
- אודיט הסביבה. מפרקים שרתים, מסד נתונים, מטמון, תורים, DNS ותעודות, מגבלות נוכחיות ונקודות כשל. התוצר — מפה של מה שנעשה בו שימוש חוזר ומה שנחליף.
- תצורת הפריסה. קובעים היכן חיים האפליקציה, מסד הנתונים, המדיה ומשימות הרקע, איך עוברות ביניהם הבקשות והיכן הולך לאיבוד הסשן. את התצורה מתאמים לפני הפקודה הראשונה על השרת.
- הרשאות גישה. משתמש מערכת נפרד, סודות ומשתני סביבה מפוזרים לפי תיקיות, תפקידי מסד נתונים לפי המינימום ההכרחי: האפליקציה לא עובדת כמשתמש-על.
- התקנה והגדרה. פורסים את הענף העדכני של Vendure, מריצים מיגרציות, מחברים תוספים ומעבדי תורים, מגדירים מטמון ואינדוקס של הקטלוג.
- בדיקה תחת עומס. מריצים תרחישי קונה — חיפוש, עגלה, השלמת הזמנה — בפרופיל קרוב לתעבורה אמיתית, ובודקים את זמן התגובה ואת התנהגות מסד הנתונים בשיא.
- גיבויים וחזרה לאחור. מגדירים תמונות מצב קבועות של מסד הנתונים והמדיה ובודקים שחזור בסביבת בדיקה נפרדת, ולא רק את עצם יצירת הגיבוי.
- מסירת הפרויקט. מוסרים תיעוד, נוהל עדכונים, פירוט התצורה והרשאות גישה לצוות שלכם.
בתוצר — סביבה עובדת וסט פעולות ברור למקרה של עדכון או תקלה.
מה נשאר אצלכם: קונפיגורציות, תצורות, נוהלים, הרשאות
אנחנו מוסרים לא רק שרת עובד, אלא גם את כל התשתית שמסביבו: קונפיגורציות פריסה, תצורות תשתית, נוהלים והרשאות. החבילה נבנית כך שכל צוות אחר יוכל לקבל אותה — בלי ההסברים שבעל פה שלנו ובלי לשחזר החלטות מהזיכרון.
- קונפיגורציות פריסה — קובצי סביבה, פרמטרים של בנייה והרצת האפליקציה, הגדרות של הקטלוג, העגלה והשלמת ההזמנה עם הסבר מה כל ערך משפיע עליו.
- תצורות תשתית — מה ואיפה ממוקם: שרת האפליקציה, מסד הנתונים, המטמון, התורים, השירותים החיצוניים, איך הם קשורים זה לזה והיכן נמצאות נקודות הכשל.
- נוהל עדכונים — סדר הוצאת גרסה חדשה, ההליך לחזרה לגרסה הקודמת, רשימת הבדיקות לפני ואחרי העלייה לאוויר.
- גיבויים — לוח זמנים, עומק שמירת הגיבויים, נוהל בדיקת השחזור וההליך עצמו של פריסה מגיבוי בסביבה נקייה.
- הרשאות ותפקידים — רשימת חשבונות, רמות הרשאה, מקום אחסון הסודות והסדר להחלפתם המתוכננת.
- תיעוד — מפת הקוד והתוספים, תיאור של פתרונות לא סטנדרטיים, יומן שינויים ומגבלות ידועות עם ציון מה ולמה נעשה דווקא כך.
- הנחיות לצוות התורנות — איך לקרוא לוגים, אילו מדדים נחשבים תקינים ובאילו סימנים להרים התראה.
בלוק נפרד הוא התיעוד של ההתאמות: מה בדיוק הרחבנו ב-Vendure, איפה נמצא הקוד של התוספים, איך לעדכן אותם יחד עם הליבה ומה יישבר אם מדלגים על גרסת ביניים. חבילה כזו אפשר למסור לקבלן חיצוני או להרכיב צוות משלכם — העבודה תמשיך מאותה נקודה, ולא מלימוד חוזר של המערכת.
מקרה בוחן: החנות הפסיקה לאבד הזמנות בעומסי שיא
לפני ההעברה, חנות עם קטלוג של 12,000 פריטים לא החזיקה שיא: בימי מבצע מכירות עד 4% מההזמנות אבדו. התשלום של הקונה עבר, אבל רשומת ההזמנה לא נוצרה — הבירור נפל על התמיכה. את העדכונים העלו בלילה, ועצרו את קבלת ההזמנות ל-40 דקות.
מה שינו
את הקטלוג העברנו עם הצלבה: ייצאנו דרך ממשק התכנות של הפלטפורמה הישנה, הצלבנו את מספר הפריטים, המלאי והשיוך לקטגוריות, ושמרנו על מזהים ייחודיים — כתובות העמודים והמיקומים בחיפוש לא זזו. את החנות פרסנו על הענף העדכני של Vendure בתצורה עם כמה צמתים של האפליקציה.
ההזמנה והורדת המלאי נכתבות בטרנזקציה אחת, ולניסיון יש מפתח אידמפוטנטיות: שליחה חוזרת לא יוצרת כפילות, ותקלה מחזירה את ההזמנה כולה לאחור. את העגלה והסשנים הוצאנו לאחסון משותף — הפעלה מחדש של התהליך כבר לא מאפסת את הקונה באמצע ההשלמה.
העלייה לאוויר נעשית בזה אחר זה על צמתי גיבוי, והתעבורה חוזרת אחרי בדיקת מוכנות, ולכן העדכון הפסיק להיות חלון השבתה.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| הזמנות שאבדו בשיא | עד 4% | 0 |
| השבתה בעת עדכון | 40 דקות | ללא עצירה |
| זמן תגובה של עמוד קטגוריה | 1.8 שנ' | 0.4 שנ' |
| הזמנות שמגיעות עד אישור | 96% | 99.8% |
בעומס מבצע מכירות דומה לא אבדה אף הזמנה, והתמיכה הפסיקה לטפל בתלונות "שילמתי אבל זה לא הגיע". בהמשך נפרק איך תצורה כזו נבנית מאפס.
מה לעשות אם החנות כבר עובדת על פלטפורמה אחרת?
מעבירים חנות פעילה לשני סביבות: הקודמת ממשיכה לקבל הזמנות, בעוד החדשה על Vendure ו-NestJS מתמלאת בקטלוג ומורצת במצב בדיקה. המכירות לא נעצרות לא בשלב הייבוא ולא בשלב ההצלבה — ההשבתה מצטמצמת לחלון כתיבה קצר ברגע המעבר.
את הקטלוג מייבאים מייצוא של הפלטפורמה הישנה: מצליבים מק"טים, וריאנטים, מאפיינים, קטגוריות, מדיה ותרגומים לפי מפתחות, ולא לפי שמות. הייבוא אידמפוטנטי — הרצה חוזרת מעדכנת רשומות ולא יוצרת כרטיס שני לאותו מוצר, ולכן אפשר לתקן פערים באופן איטרטיבי בלי לשבור את מה שכבר הועבר.
את היסטוריית ההזמנות והלקוחות מעבירים במעבר נפרד ומחזיקים לקריאה בלבד: סטטוסים, סכומים, פריטים ושיוך לקונים. כך הדיווח, הרכישות החוזרות וההחזרים על הזמנות ישנות נשארים עובדים, אבל לא מצטלבים עם החשבונאות החדשה.
בזמן ההעברה, מלאי ומחירים נמשכים מהפלטפורמה הקודמת בדלתאות לפי זמן השינוי — הסביבה החדשה רואה תמונה עדכנית, אבל את המכירות סוגרת החנות הישנה. את המעבר עושים בתעבורה נמוכה: חלון כתיבה קצר, דלתא סופית, העברת התעבורה והצלבת הזמנות לפי מונים. הסביבה הקודמת נשארת רזרבה חמה וצינור חזרה לאחור, עד שהפערים יגיעו לאפס.
בנפרד מכניסים למרשם את מה שלא מועבר אוטומטית: תעודות, קודי קופון ויתרות בונוסים. את ההגירה שלהם מתאמים לפני המעבר — אחרת אחרי ההפעלה יצופו פערים בהנחות שיהיה צריך לטפל בהם ידנית על הזמנות חיות.
ספקות נפוצים לפני ההתחלה: עומס, הרשאות, עדכונים
הספקות לפני ההתחלה בדרך כלל אותם ספקות: האם הפלטפורמה תשתלב בסטאק הנוכחי, האם הקטלוג יעמוד בעומס שיא, מי ומה משנה באדמין, איך עוברים העדכונים ומה יישאר אחרי תקלה.
האם הפלטפורמה תשתלב בסטאק הנוכחי שלנו?
Vendure — אפליקציה על NestJS, וההרחבות נכתבות כמודולים רגילים של הפריימוורק הזה. המפתחים נשארים בשכבות ובסכמת המיגרציות המוכרות, במקום ללמוד שפת תוספים נפרדת. מערכות חיצוניות מחברים דרך ה-API הסטנדרטי של הפלטפורמה.
האם הקטלוג יעמוד בעומס שיא?
הקטלוג לקריאה מוגש דרך מטמון, ולכן תצוגת קטגוריות וכרטיסים לא נתקעת במסד הנתונים בכל בקשה. סינון, מבחרים וחיפוש עוברים לשירות נפרד. לפני ההפעלה מריצים מבחן עומס בפרופיל שיא ובודקים את זמן התגובה של הקטלוג והעגלה בזינוק תעבורה.
איך מופרדות הרשאות הגישה?
את התפקידים מתארים לפי פעולות: מנהל תוכן עורך כרטיסים ומדיה, מנהל מלאי — מחירים ומלאי, תמיכה רואה הזמנות אבל לא משנה את הקטלוג. הכניסה לאדמין — דרך אימות ארגוני, והשינויים נכנסים ליומן: רואים מי ומתי הוריד מוצר מפרסום.
באיזה סדר יוצאים העדכונים?
עדכונים מתוכננים מתקינים בחלון מוסכם: קודם גיבוי של מסד הייצור, הרצת מיגרציות ובדיקות עליו, אחר כך העלייה לאוויר. מעברים מג'וריים עושים בשלב נפרד עם בדיקת ההרחבות. החזרה לאחור מחזירה את הבנייה הקודמת ואת סכמת מסד הנתונים, ולכן החלון לא נמתח על פני הלילה.
מה עם גיבויים?
דאמפ יומי של מסד הנתונים ותמונת מצב של המדיה נשמרים מחוץ לסביבה הראשית, בנפרד מהפרודקשן. פעם ברבעון פורסים גיבוי בסביבת בדיקה: גיבוי שלא שוחזר ולו פעם אחת לא נחשב גיבוי. לכן החזרה למצב עבודה נמדדת בדקות.
נדבר על המשימה: מאיפה נתחיל ומה צריך מצדכם
את השיחה מתחילים בפירוק המשימה: מה כבר עובד, איפה צווארי הבקבוק ואיזה תוצאה נדרשת בסוף. חשוב לנו להבין לא רק "צריך חנות אונליין", אלא איך בנוי הקטלוג שלכם, מי עובד איתו ואיך מדי יום, ואילו תהליכים נשברים עכשיו. בסיכום אנחנו חוזרים עם הערכה ותוכנית — עם שלבים, סדר עלייה לאוויר ונקודות שבהן יידרש ההחלטה שלכם.
כדי שההערכה תהיה עניינית ולא "לפי העין", נדרש מהמזמין מינימום:
- גישה למאגר הקוד או ארכיון עם הקוד הנוכחי והגדרות הסביבות;
- תיאור התשתית: איפה פורסים, האם יש מגבלות ברשת, בהרשאות ובגיבויים;
- רשימת האינטגרציות — קבלת תשלומים, משלוחים, מחסן, מערכת הנהלת החשבונות, דיוור;
- מבנה הקטלוג: קטגוריות, וריאנטים של מוצרים, שפות ומטבעות, כללי הנחות ומבצעים;
- עומס צפוי: כמה פריטים בקטלוג ומהו שיא ההזמנות ביממה;
- אחראי מצדכם — מי מקבל את העבודה ומתאם את הנקודות השנויות במחלוקת.
זה מספיק כדי להרכיב תוכנית: הכנת הסביבה, התקנת Vendure על NestJS, העברת נתונים, חיבור אינטגרציות, בדיקה תחת עומס והפעלה. לוחות הזמנים נאמרים לפי שלבים, ולא במספר אחד — כך רואים מה תלוי במה ואיפה אנחנו ממתינים לנתונים שלכם. תארו את המשימה — נחזור עם הערכה, תוכנית ושאלות שכדאי לסגור לפני ההתחלה.