שגרת תחזוקה שגם אתר תוכן עצמאי יכול לעמוד בה

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

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

לשמור תיעוד תפעולי קצר

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

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

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

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

מדי שבוע: לבדוק שהמסלולים החיוניים עדיין עובדים

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

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

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

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

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

מדי חודש: לבדוק שחזור, הרשאות גישה ושחיקה הדרגתית

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

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

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

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

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

לפני כל העלאת גרסה ואחריה: לוודא שאפשר לחזור לאחור

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

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

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

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

להתאים את השגרה לאתרים סטטיים ולאתרי מערכת ניהול תוכן

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

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

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