מה הדרך המומלצת לשחזר אתר אחרי הגירה שנתקעה באמצע?
הגירה תקועה נראית תמיד אותו דבר. יש שרת ישן שעדיין עונה, יש שרת חדש שכבר עונה, ואף אחד לא יודע בוודאות איזה מהם הגולשים רואים ברגע נתון. בינתיים מישהו בצוות מתקן טעות כתיב בעותק אחד, לקוח שולח טופס שנוחת בעותק השני, והפער בין השניים גדל בשקט. הרוב המכריע של הנזק בהגירות שנתקעו לא נגרם מהתקלה הטכנית המקורית, אלא מהשעות שבהן שני עותקים חיים במקביל ואף אחד לא הכריז מי המקור. לכן הצעד הראשון בשחזור הוא לא טכני בכלל, הוא החלטה. במאמר הזה תמצאו איך קובעים איזה עותק הוא מקור האמת ולפי אילו נתונים, למה DNS באמצע מעבר מייצר את המצב הזה מלכתחילה, מה התיקון הטכני שהכי הרבה אנשים עושים לא נכון, ואיך מחליטים אם לתקן את העותק התקוע או פשוט להתחיל את ההגירה מחדש מבסיס נקי.
תוכן העניינים 8 פרקים
הצעד הראשון: להקפיא את שני העותקים
לפני אבחון, לפני שאילתות, לפני שנוגעים בקובץ אחד: להפסיק לכתוב. זה אומר שני דברים מעשיים. ראשית, להודיע לכל מי שיש לו גישה לניהול שהוא לא נוגע בתוכן עד להודעה חדשה, כולל תיקוני ניסוח קטנים. שנית, לקחת עותק מלא של שני הצדדים כמות שהם, קבצים ומסד נתונים בנפרד לכל אחד, ולשמור אותם בשם עם תאריך ושעה. גם אם אחד מהם שבור. עותק של מצב שבור שווה הרבה, כי הוא מאפשר לחזור אחורה אם התיקון מחמיר.
אנשים מדלגים על הצעד הזה כי הוא מרגיש כמו בזבוז זמן כשהאתר לא עובד. הוא לא. ברגע שהתחלתם לתקן מסד נתונים בלי גיבוי של מצב הפתיחה, איבדתם את היכולת להשוות, וכל ניסיון כושל הופך למצב חדש שאתם לא יודעים לתאר.
אם החנות פעילה והזמנות ממשיכות להיכנס, הקפאה מלאה לא תמיד אפשרית. במקרה כזה מצמצמים: מכבים את הכתיבה בעותק שאינו מקור האמת, ומשאירים רק אחד פתוח להזמנות. איזה מהשניים, זו בדיוק השאלה של הפרק הבא.
איך קובעים איזה עותק הוא מקור האמת
לא לפי תחושה ולא לפי איזה שרת נראה תקין יותר. לפי נתונים. השאלה היחידה שחשובה היא איפה נחתו הפעולות האמיתיות של אנשים אמיתיים מאז שההגירה התחילה, כי תוכן אפשר להעתיק ופעולת לקוח אי אפשר להמציא.
עברו על החמישה האלה בכל אחד משני העותקים, ורשמו את התוצאות זו מול זו:
| מה בודקים | איפה זה נמצא | למה זה מכריע |
|---|---|---|
| ההזמנה האחרונה ומספרה | מסך ההזמנות בחנות | הזמנה היא כסף שנכנס, ואי אפשר לשחזר אותה מהעותק השני בלי לאבד היסטוריה |
| הפנייה האחרונה מטופס יצירת קשר | תוסף הטפסים או תיבת הדואר שאליה נשלח | ליד שאבד הוא לקוח שלא ידעתם שקיים |
| הפוסט או העמוד האחרון שנערך | רשימת התכנים, ממוינת לפי תאריך שינוי | מזהה אם מישהו המשיך לעבוד בעותק הלא נכון |
| ההרשמה האחרונה של משתמש | מסך המשתמשים | רלוונטי בעיקר באתרי חברים ובאזורי לקוחות |
| הקובץ החדש ביותר בתיקיית ההעלאות | תיקיית uploads דרך FTP או מנהל הקבצים | מגלה העלאות שנעשו אחרי ההגירה ולא הועתקו |
ברוב המקרים תגלו שהתשובה מפוצלת: התוכן העדכני נמצא בעותק אחד וההזמנות בשני. זה בדיוק המצב שדורש החלטה מודעת. הכלל המעשי שלי הוא לבחור כמקור את העותק שמחזיק את הנתונים שאי אפשר לייצר מחדש, כלומר עסקאות ופניות, ולהעביר אליו ידנית את התוכן העריכתי מהעותק השני. תוכן אפשר להדביק. הזמנה של לקוח לא.
ברגע שהוחלט, כתבו את זה במקום שכולם רואים, כולל שעה מדויקת. מהרגע הזה העותק השני הוא ארכיון לקריאה בלבד.
למה DNS באמצע מעבר יוצר שני אתרים חיים
כדאי להבין את המנגנון, כי הוא מסביר גם איך למנוע את זה בפעם הבאה. כשמשנים את הרשומה שמפנה את הדומיין לשרת, השינוי לא מגיע לכולם באותו רגע. לכל רשומה יש ערך TTL, זמן שבו שרתי הביניים ברשת רשאים להמשיך להשתמש בתשובה הישנה ששמורה אצלם. אם הערך היה שעה או יותר, יש חלון ארוך שבו חלק מהעולם מגיע לשרת החדש וחלק ממשיך לשרת הישן, בלי שאף אחד יודע לאיזה הוא הגיע.
מכאן נובעות כל תופעות הפיצול המוכרות: הזמנה שהלקוח מדווח עליה ואתם לא רואים, תיקון תוכן שנעלם, טופס שהגיע פעמיים. זה לא באג באתר, זו התנהגות תקינה של רשת שנמצאת באמצע מעבר.
מה שכן אפשר לעשות: להוריד את ערך ה-TTL לכמה דקות יום-יומיים לפני ההגירה, ולהחזיר אותו אחריה. אם כבר אתם באמצע האירוע, אין דרך לזרז את מה שכבר נשמר במטמון, ולכן הפתרון היחיד הוא לצמצם נזק: לסגור כתיבה בעותק שאינו המקור, ולהפנות ממנו את המבקרים למקור.
ולפני הכול, בדקו שהאתר החדש עונה בכתובת ה-IP שלו לפני שנוגעים ב-DNS בכלל. הגירה שנתקעת אחרי שינוי DNS היא אירוע חמור בהרבה מהגירה שנתקעת לפניו. גם כאן, שינוי ברשומות הדומיין מחייב כניסה לחשבון הרשם, כלומר גישה שרק הבעלים הרשום מחזיק, וזו הסיבה שאני מבקש מלקוח לבצע את השינוי עצמו או להעניק גישה מסודרת מראש.
התיקון שהכי הרבה אנשים עושים לא נכון
אחרי שהוחלט מהו המקור, מגיע החלק הטכני. וכאן יש מוקש אחד שאחראי לרוב ההגירות ההרוסות שאני מקבל: החלפה של כתובות במסד הנתונים בשאילתת החלפה רגילה.
הסיבה פשוטה. חלק ניכר מההגדרות בוורדפרס, בעיקר של תבניות, בוני עמודים ורכיבי צד, נשמרות במבנה מסודר שבו לפני כל מחרוזת רשום אורכה בתווים. כשמחליפים כתובת ארוכה בכתובת קצרה יותר, האורך הרשום כבר לא תואם למחרוזת בפועל, והמבנה כולו הופך לבלתי קריא. התוצאה מוכרת: ההגדרות של התבנית מתאפסות, רכיבים נעלמים מהעמודים, ובונה העמודים פותח עמוד ריק. שימו לב שהנזק הזה לא מתגלה מיד, אלא רק כשמישהו נכנס לערוך עמוד ישן.
הדרך הנכונה היא כלי החלפה שמודע למבנה הזה ומעדכן את האורכים תוך כדי. שורת הפקודה של וורדפרס כוללת פקודה כזאת, ויש גם כלים ייעודיים שרצים מהדפדפן. שני כללים שמלווים אותה תמיד: גיבוי של מסד הנתונים לפני, והרצה יבשה קודם כדי לראות כמה שורות ישתנו ובאילו טבלאות.
נקודה נוספת באותו הקשר: אל תשכתבו את שדה המזהה הייחודי של הפוסטים. הוא נראה כמו כתובת אבל הוא לא כתובת, הוא מזהה. שינוי שלו גורם לקוראי הזנות RSS ולחלק ממערכות הדיוור להציג פוסטים ישנים כאילו פורסמו עכשיו.
תמונות שנעלמו: קובץ חסר או רשומה שגויה
זה הסימפטום הכי נפוץ אחרי הגירה, והוא נובע משתי בעיות שונות לגמרי שמטופלות אחרת. הבדיקה שמפרידה ביניהן לוקחת שלושים שניות: לחצו לפתיחת התמונה בכרטיסייה חדשה והסתכלו על הכתובת שקיבלתם.
- הכתובת מכילה את הדומיין הישן או את כתובת שרת הביניים: הקובץ כנראה קיים, והבעיה היא במסד הנתונים. זה מטופל בהחלפה מודעת מבנה, כמו בפרק הקודם.
- הכתובת נכונה לגמרי ובכל זאת מוחזרת שגיאה 404: הקובץ עצמו לא הגיע. תיקיית ההעלאות היא בדרך כלל הכבדה ביותר, והעברות מתנתקות באמצע בלי להודיע.
- התמונה הראשית מוצגת אבל התמונות הקטנות שבורות: הקבצים בגדלים הנגזרים לא הועתקו, וצריך לייצר אותם מחדש.
- התמונות קיימות בשרת אבל מוחזרת שגיאת הרשאה: הקבצים הועתקו תחת בעלות משתמש שגויה, וצריך לתקן בעלות והרשאות ברמת השרת.
הרביעי ברשימה הוא זה שגורם גם לתופעה המבלבלת שבה אי אפשר להעלות קובץ חדש, אף שהאתר נראה תקין לחלוטין. אם גיליתם שאתם מסתובבים בין ארבע האפשרויות בלי להתקדם, זה בדיוק סוג המקרה שבו שחזור הגירת אתר שנכשלה חוסך יום עבודה שלם.
הנזקים השקטים שמתגלים רק אחרי שבועיים
הדברים שמפילים הגירות הם לא אלה שצועקים. אלה ארבעת החשודים שאני בודק תמיד, כי כולם שקטים:
חסימת מנועי חיפוש שנשארה דלוקה. בעותק הפיתוח מסמנים בדרך כלל את האפשרות שמבקשת ממנועי החיפוש לא לסרוק. אם היא עברה לשרת החי, האתר יורד מהאינדקס בהדרגה, וזה מתגלה כשהתנועה כבר צנחה. זו הבדיקה הראשונה שאני עושה בכל אתר שעבר שרת.
קידוד עברית שהתקלקל. ייצוא וייבוא של מסד נתונים בקידוד לא תואם הופך טקסט בעברית לסימנים חסרי פשר. זה בולט בכותרות אבל מתחבא בשדות פנימיים, בתיאורי מוצר ובהודעות מערכת. אם ראיתם ג׳יבריש ולו במקום אחד, עצרו את הייבוא ותקנו את הקידוד במקור, אל תתקנו טקסט ידנית.
דואר יוצא שהפסיק לצאת. שרת חדש הוא כתובת IP חדשה, והרשומות שמאשרות למי מותר לשלוח בשם הדומיין לא תמיד עודכנו. אישורי הזמנה וטפסים ממשיכים להישלח מבחינת האתר, ופשוט לא מגיעים.
קישורים קבועים ששבורים. עמוד הבית עולה, כל עמוד פנימי מחזיר 404. כמעט תמיד זה קובץ הגדרות השרת שלא עבר או שכללי ההפניה בו לא נטענים, ולא בעיה בתוכן.
רשימת בדיקה לפני שמכריזים שההגירה הסתיימה
- עמוד הבית, עמוד קטגוריה, עמוד מוצר או שירות, פוסט ישן ועמוד יצירת קשר, כולם נטענים במחשב ובנייד.
- שליחת טופס אחת מקצה לקצה, כולל בדיקה שהמייל הגיע לתיבה ולא לספאם.
- הזמנת בדיקה בסכום נמוך, כולל אישור בדואר ושינוי מצב ההזמנה.
- העלאת קובץ חדש למדיה, כדי לאמת הרשאות כתיבה.
- כניסת ניהול ושמירת עמוד קיים, כדי לאמת שנתוני בונה העמודים תקינים.
- האפשרות של חסימת מנועי חיפוש כבויה, וקובץ ה-robots לא חוסם.
- חיפוש פנימי בתוכן אחר הדומיין הישן, כדי לאתר שאריות.
- בדיקת תעודת האבטחה בדומיין ובתת-הדומיינים אחרי המעבר.
- גיבוי ראשון בשרת החדש, ואימות שהוא באמת נשמר מחוץ לשרת.
רק אחרי שכל התשעה עברו, אפשר לפתוח מחדש את הכתיבה לכל מי שהיה מוקפא.
לתקן את העותק התקוע או להתחיל מחדש, וכמה זה עולה
יש נקודה שבה תיקון נהיה יקר יותר מהתחלה מחדש. כלל האצבע שאני עובד לפיו: אם אחרי שעה של אבחון אתם עדיין לא יכולים לנסח במשפט אחד מה בדיוק שבור, אל תמשיכו לתקן. חזרו למקור האמת, קחו ממנו ייצוא נקי, והריצו את ההגירה מההתחלה בסביבה מבוקרת. תיקון שנמשך בלי הגדרה ברורה של התקלה הוא סדרת ניחושים, וכל ניחוש מוסיף שכבה שקשה לפרק.
מנגד, אם התסמין ממוקד וניתן לנסח אותו, למשל התמונות מצביעות על הדומיין הישן או העמודים הפנימיים מחזירים 404, תיקון ממוקד הוא הדרך הנכונה והוא בדרך כלל קצר.
אצלי שחזור הגירה שנכשלה מתומחר מ-₪1,500 לפרויקט, לפני מע״מ, והוא מכסה את כל הסדרה: קביעת מקור האמת, החלפת כתובות מודעת מבנה, החזרת קישורים קבועים, טיפול בקבצים ובהרשאות ובדיקת מסירת דואר. לתקלה בודדת ומוגדרת היטב, שלא נובעת מהגירה, המסגרת המתאימה היא פתרון תקלות WordPress בטווח ₪350-₪1,500 לתקלה.
ומילה על הכיוון ההפוך. אם הגעתם לכאן אחרי הגירה שנייה או שלישית שנתקעה, ייתכן שהשאלה האמיתית היא לא איך מזיזים את האתר אלא על מה הוא בנוי. הגירת אתר מ-WordPress ל-Astro היא פרויקט מתוכנן ולא פעולת חילוץ, עם מיפוי כתובות והפניות מראש, והיא מתומחרת ₪8,000-₪35,000 חד-פעמי לפני מע״מ. זו לא התשובה לכל אתר, והיא בהחלט לא התשובה כשאתם באמצע אירוע.
אם אתם עכשיו בתוך הגירה תקועה, אל תתקנו כלום עד שהקפאתם את שני העותקים וגיביתם אותם. אחר כך שלחו לי את שתי הכתובות ותיאור קצר של מה שאתם רואים, ואומר לכם איזה עותק נראה לי מקור האמת ומה סדר הפעולות. אני מנהל את התהליך הזה מקצה לקצה, כולל התיאום מול חברת האחסון. הכי מהיר להשיג אותי בWhatsApp, ואם המצב דחוף כתבו לי את זה בשורה הראשונה. דברו איתי בוואטסאפ ←
