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

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

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

לתמחר את התקופה שבאמת רוכשים

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

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

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

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

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

לתרגם מגבלות למשימות שהאתר מבצע

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

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

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

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

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

להוכיח שאפשר לשחזר ולשמור על השליטה

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

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

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

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

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

לבנות תוכנית מעבר לפני שמשנים DNS

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

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

מדריך המעבר של WordPress מסביר שהתהליך הנכון תלוי במה שעובר, לרבות השאלה אם הכתובות משתנות. מעבר שרת והחלפת דומיין הם משימות שונות. אין להוסיף שינוי במבנה הכתובות למעבר אחסון בלי סיבה ותוכנית נפרדות.

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

לבטל רק אחרי שכל התלויות טופלו

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

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

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

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