זה תלוי בגודל התקלה ובמורכבות המערכת, אבל כשיש תהליך מסודר וניטור פעיל, רוב התקלות נפתרות תוך דקות ולא שעות.
אתר שקורס בדיוק באמצע מבצע או בשעת שיא מכירות הוא סיוט שכל בעל עסק מכיר..המדריך הזה מסביר איך לפעול בדקות הראשונות של התקלה ולמה כיבוי שריפות בלבד לא מספיק כדי למנוע את הקריסה הבאה..
שירותי DevOps
השעה שתיים בצהריים, מבצע ענק רץ באתר ואז פתאום הכל נעצר.דף לבן, שגיאת שרת או גרוע מזה: האתר פשוט לא נטען.הלקוחות מרעננים את הדף, מתייאשים ועוברים למתחרה.ברגעים כאלה כל דקה עולה כסף ועוד יותר מזה עולה באמון של הלקוחות.
הבעיה האמיתית היא לא רק התקלה עצמה, אלא מה שקורה אחריה.הרבה עסקים מתקנים את הסימפטום, נושמים לרווחה וממשיכים הלאה - עד שהתקלה חוזרת כעבור חודש או שבוע.במדריך הזה נדבר על מה עושים בדקות הראשונות של קריסה ולמה ההבדל בין פתרון זמני לטיפול בשורש הבעיה הוא בדיוק מה שמפריד בין עסק שחווה תקלה אחת לבין עסק שחי עם תקלות אתר כחלק קבוע מהשגרה.
ברגע שמתגלה שהאתר לא עובד, הדחף הטבעי הוא לרוץ ולבדוק קוד, להתקשר לכולם בבת אחת או לנסות לתקן דברים בלי לדעת בדיוק מה נשבר.זה בדיוק הרגע שבו כדאי לעצור לשנייה ולפעול בסדר נכון.קודם כל צריך לוודא שהתקלה אכן באתר עצמו ולא אצל הגולש, לדוגמה על ידי בדיקה ממספר מכשירים ורשתות שונות.
אחר כך חשוב לבדוק אם מדובר בתקלה בשרת, בבסיס הנתונים, בקוד שעלה לאחרונה או בספק חיצוני כמו שירות תשלומים או CDN.ברוב המקרים יש כבר כלי ניטור שמראים בדיוק היכן נדלקה נורה אדומה ואם אין כאלה, זה בדיוק הסימן הראשון לכך שחסר לכם שכבת ניהול שרתי Web מסודרת.בזמן הזה כדאי גם לעדכן את הלקוחות בעמוד או בהודעה קצרה, כדי שלא ירגישו שהעסק פשוט נעלם.
אפילו תקלה שנפתרה תוך דקות שווה לרשום: מתי קרתה, מה הפתרון ומה היה הגורם.זה הבסיס לזיהוי דפוסים חוזרים.
רוב בעלי העסקים ובצדק, רק רוצים שהאתר יחזור לעבוד כמה שיותר מהר.אז מפעילים מחדש את השרת, מוחקים קובץ בעייתי או פשוט מחכים שהתקלה תעבור מעצמה.זה עובד, אבל זה פתרון זמני בלבד - כמו לשים פלסטר על צינור שדולף במקום לתקן את הצנרת.
הטיפול האמיתי מתחיל רק אחרי שהאתר כבר עובד, כשבודקים לעומק למה זה קרה מלכתחילה.האם השרת פשוט לא מספיק חזק לעומס הנוכחי של העסק.האם יש קוד שגורם לדליפת זיכרון לאורך זמן.האם חסרה מערכת גיבוי ושחזור שמאפשרת לחזור אחורה בלחיצת כפתור.זה בדיוק התפקיד של גישת DevOps - לא רק לכבות שריפות, אלא לבנות תהליך שמונע אותן מראש.
ניטור רציף הוא ההבדל בין עסק שמגלה תקלה מהלקוחות הכועסים, לבין עסק שמקבל התראה לפני שהלקוח בכלל הבחין שמשהו השתנה.כלי ניטור טובים בודקים זמינות, זמני תגובה ועומס על השרת באופן קבוע ומתריעים ברגע שמשהו חורג מהנורמה.
זה לא אומר שאף פעם לא תהיה תקלה, אבל זה אומר שיש לכם זמן תגובה הרבה יותר קצר ולרוב אפשר לפתור את הבעיה לפני שהיא בכלל משפיעה על חוויית הגולשים באתר.
זה תלוי בגודל התקלה ובמורכבות המערכת, אבל כשיש תהליך מסודר וניטור פעיל, רוב התקלות נפתרות תוך דקות ולא שעות.
אי אפשר להבטיח אפס תקלות, אבל אפשר לצמצם דרמטית את התדירות והחומרה שלהן באמצעות ניהול שרתים מקצועי ובדיקות סדירות.
לא בהכרח.הרבה עסקים בוחרים בליווי חיצוני של שירותי DevOps במקום להחזיק צוות שלם וכך מקבלים זמינות וניסיון בלי העלות של מחלקת IT פנימית.
תקלת אתר אף פעם לא קורית בזמן נוח, אבל איך שמגיבים אליה ומה עושים אחריה הוא מה שבאמת קובע את ההבדל בין עסק שסופג מכה נקודתית לבין עסק שחי בפחד מהקריסה הבאה.אם זיהיתם את עצמכם במדריך הזה או שאתם פשוט רוצים לדעת שהאתר שלכם נמצא בידיים טובות, אצלנו ב-FerNet מלווים עסקים בדיוק בנקודה הזו, מאבחון מדויק של מקור התקלה ועד בניית תהליכי DevOps וניהול שרתים שמונעים ממנה לחזור.השאירו פרטים בטופס שמופיע מתחת למאמר ונשמח לבדוק יחד איך להפוך את האתר שלכם ליציב יותר.
קרדיט תמונות: Kampus Production, Atlantic Ambience, Tima Miroshnichenko / Pexels