העברת אתר 1C-Bitrix לשרת חדש ללא זמן השבתה

העברת אתר Bitrix: מה נשבר בזמן המעבר

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

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

סוג התקלות השני — הרשאות גישה וסביבת ההרצה. בשרת הישן הבעלים של הספריות היה משתמש אחד, בחדש — אחר; /bitrix/php_interface/dbconn.php,‏ upload/,‏ bitrix/cache/ מקבלים מסכות שגויות, והאתר או מחזיר 500, או כותב ללוג «Access denied» על כל בקשה ל-cache.

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

המקור השלישי — אינטגרציות חיצוניות וקשרים שחיים מחוץ למערכת הקבצים: כתובת IP ברשימות הלבנות של שערי תשלום, webhooks שמקושרים לדומיין הישן, מפתח רישיון שתלוי בסביבה, תעודת SSL ורשומות DNS.

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

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

כיצד מתבצעת ההעברה ללא הפסקת פעילות האתר

שכפול בסיס הנתונים

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

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

סנכרון קבצים

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

עד لح момент ההחלפה הפער בקבצים הוא אפס, והמטמון בשרת החדש מחומם מראש — המבקרים הראשונים אינם ממתינים ליצירה קרה של דפים.

החלפת התעבורה

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

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

שלבי ההעברה: מביקורת ועד מסירת הרשאות

העברת אתר ל-Bitrix אינה "העתקת קבצים ומסד נתונים", אלא רצף מבוקר של צעדים, שבו כל צעד נשען על תוצאת קודמו. תחילה מיפוי מלאי: אילו מודולים מעורבים, היכן מאוחסנים הקבצים שהועלו, כיצד בנויות משימות cron, החלפה עם 1C ואינטגרציות חיצוניות.

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

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

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

במה שונה העברה לשרת חדש מהעברה לענן?

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

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

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

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

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

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

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

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

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

מקרה בוחן: העברת חנות אינטרנט ל-Bitrix ללא השבתה

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

מה שינו

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

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

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

מדדים לפני ואחרי

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

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

תאימות, הרשאות גישה וחזרה לאחור: מה יש לדון לפני ההתחלה

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

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

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

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

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

הלקוח מקבל לידיו:

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

תארו את המשימה שלכם — נחזור עם הערכה ותוכנית העברה מותאמת לסביבה שלכם.