השעה 10:15, צוות הנהלת החשבונות לא מצליח לפתוח את מערכת הלקוחות, המסמכים המשותפים אינם זמינים והטלפונים מתחילים לצלצל. ברגע כזה השאלה מה עושים כששרת נופל אינה טכנית בלבד. זו שאלה עסקית: כמה זמן הפעילות תיעצר, איזה מידע עלול להיפגע, מי מקבל החלטות ואיך שומרים על אמון הלקוחות והעובדים.
שרת שנפל יכול להיות תוצאה של תקלה בחומרה, הפסקת חשמל, עומס חריג, כשל בתקשורת, עדכון שלא הושלם או אירוע סייבר. הטיפול הנכון תלוי בסיבה, אבל סדר הפעולות הראשוני חייב להיות ברור מראש. פעולות פזיזות, כמו הפעלה חוזרת שוב ושוב או שינוי הגדרות ללא תיעוד, עלולות להאריך את ההשבתה ולסבך את השחזור.
מה עושים כששרת נופל בדקות הראשונות?
העדיפות הראשונה היא לעצור את חוסר הוודאות. יש לוודא אם מדובר בנפילה של שרת בודד, של הרשת כולה, של שירות ענן או של מערכת עסקית מסוימת. אם עובדים יכולים לגלוש לאתרים אך לא מגיעים לתיקיות החברה, למשל, ייתכן שהבעיה ממוקדת בשרת קבצים או בהרשאות. אם גם הטלפוניה, האינטרנט והגישה מרחוק נפגעו, ייתכן שמדובר בכשל רחב יותר בתשתית.
בשלב הזה חשוב להגדיר איש קשר אחד מטעם העסק מול גורם ה-IT. מנהל משרד, מנהל תפעול או מנהל IT צריכים לרכז את המידע: מתי התקלה החלה, אילו מערכות מושפעות, מי כבר ניסה לבצע פעולה ומה השתנה לפני האירוע. מידע פשוט זה חוסך זמן אבחון יקר ומונע מצב שבו כמה עובדים מנסים לפתור את אותה תקלה במקביל.
אין לכבות ולהדליק את השרת אוטומטית, אלא אם יש נוהל ברור ואישור מאיש מקצוע שמכיר את הסביבה. הפעלה מחדש עשויה לפתור תקלה זמנית, אך במקרה של כשל דיסקים, הצפנת כופרה או פגיעה במסד נתונים היא עלולה להחמיר את המצב. גם ניתוק חשמל ללא בדיקה עלול לגרום לנזק למידע שעדיין נכתב לדיסק.
במקביל, יש לבדוק את הבסיס: האם לשרת יש חשמל, האם האל-פסק פעיל, האם נוריות החיווי חריגות, האם ציוד התקשורת פועל והאם יש התראה ממערכת הניטור. בעסק שאין בו צוות IT פנימי, זהו בדיוק הרגע שבו שירות תמיכה זמין 24/7 הופך מתוספת נחמדה להגנה תפעולית של ממש.
קודם מייצבים את העסק, אחר כך מתקנים את התקלה
לא כל שירות מושבת משפיע באותה מידה. משרד עורכי דין שזקוק לתיקים ולמערכת ניהול המסמכים יפעל אחרת מחברת מכירות שהגישה ל-CRM שלה נפגעה. לכן, בזמן אירוע יש לקבוע סדר עדיפויות עסקי: אילו מערכות נדרשות כדי לתת שירות ללקוחות, אילו עובדים חייבים להמשיך לעבוד, ואיזה תהליך ניתן לבצע זמנית בדרך חלופית.
אם מערכת הדואר ממשיכה לפעול דרך Microsoft 365 אך שרת הקבצים המקומי אינו זמין, אפשר להנחות צוותים לעבוד זמנית ממסמכים שכבר נמצאים בענן ולהימנע מיצירת עותקים מקומיים מפוזרים. אם מערכת הנהלת החשבונות נפלה, ייתכן שנכון לתעד פניות ותשלומים באופן מבוקר עד לחזרת המערכת, במקום לאפשר לכל עובד לנהל רשימות פרטיות שעלולות ללכת לאיבוד.
תקשורת פנימית קצרה ומדויקת חשובה לא פחות מהטיפול הטכני. העובדים צריכים לדעת מה לא זמין, מה כן עובד, מי מעדכן אותם ומתי צפוי עדכון נוסף. אין צורך להבטיח זמן חזרה לפעילות לפני שיש אבחנה. עדיף לומר שהצוות הטכני בודק את מקור התקלה ושעדכון יימסר בעוד חצי שעה, מאשר לספק הערכה לא מבוססת שתיצור תסכול.
כאשר יש השפעה על לקוחות, כדאי להכין הודעה עניינית: קיימת תקלה זמנית, הצוות מטפל בה, וערוץ השירות החלופי זמין. שקיפות מבוקרת שומרת על אמון. אין צורך לפרט אבחנות טכניות או לחשוף מידע שעלול להיות רגיש, במיוחד אם עדיין לא נשללה אפשרות של אירוע אבטחה.
מתי לחשוד באירוע סייבר?
שרת שלא מגיב אינו בהכרח קורבן למתקפת סייבר, אך אסור להניח שמדובר בתקלה רגילה בלי לבדוק. סימנים כגון קבצים עם סיומות לא מוכרות, הודעת כופר, חשבונות משתמש שננעלו, פעילות חריגה בשעות לא שגרתיות או הצפנה מהירה של תיקיות משותפות מחייבים התייחסות אחרת.
בחשד לאירוע סייבר, המטרה הראשונית היא בידוד ולא תיקון מהיר. יש לנתק את השרת או העמדה החשודים מהרשת בהתאם להנחיית גורם מקצועי, לשמור לוגים וראיות, ולא למחוק קבצים או לפרמט מערכות. במקביל יש לבדוק אם גיבויי הענן נגישים, אם הם מופרדים מהסביבה הנפגעת, ואם קיימות נקודות שחזור נקיות מלפני האירוע.
זהו גם מבחן אמיתי לתכנון הגיבוי. גיבוי שקיים רק על אותו שרת או באותו אתר אינו מספק הגנה מספקת מפני שריפה, הצפה, גניבה או כופרה. גיבוי יעיל צריך להיות מנוטר, מוצפן, שמור במיקום נפרד ונבדק באמצעות שחזור בפועל. קובץ גיבוי שלא נבדק הוא הנחה, לא תוכנית התאוששות.
אבחון ושחזור: לא תמיד המסלול הקצר הוא הנכון
לאחר ייצוב האירוע, צוות ה-IT צריך להבין את שורש הבעיה. האם מדובר בכשל חומרה? האם שירות מסוים קרס? האם עדכון מערכת או שינוי הרשאות יצרו את התקלה? האם נפח האחסון התמלא? אבחון מסודר מונע חזרה של אותה תקלה בשבוע הבא.
במקרים מסוימים ניתן להחזיר שירות באמצעות תיקון נקודתי או מעבר לשרת חלופי. במקרים אחרים, שחזור מגיבוי הוא הדרך הבטוחה יותר. הבחירה תלויה בנזק, בגילוי האירוע ובזמן ההשבתה שהעסק יכול לספוג. ניסיון לתקן מסד נתונים שנפגע, למשל, עשוי להיראות מהיר יותר משחזור, אבל אם הוא מסכן את שלמות הנתונים – המחיר העסקי עלול להיות גבוה בהרבה.
שחזור איכותי אינו מסתיים כשהשרת נדלק. יש לבדוק שהמשתמשים מצליחים להתחבר, שההרשאות תקינות, שהמערכות העסקיות עובדות, שהדפסות וגישות מרחוק חזרו לפעילות, ושלא נותרו פערים במידע שנוצר בזמן ההשבתה. לאחר מכן כדאי לבצע ניטור מוגבר במשך שעות או ימים, בהתאם לחומרת האירוע.
מה עושים כששרת נופל שוב ושוב?
תקלה חוזרת היא בדרך כלל סימן לבעיה עמוקה יותר: שרת מיושן, קיבולת אחסון לא מספקת, רשת לא מנוהלת, עדכונים ללא בקרה, גיבויים שלא נבדקו או תלות באדם אחד שמכיר את כל הסיסמאות וההגדרות. תיקון נקודתי עשוי להחזיר את המערכת לפעולה, אבל לא בהכרח לפתור את הסיכון.
בשלב זה נדרשת בדיקת מצב רחבה של התשתית. כדאי למפות את השרתים והיישומים, לבדוק גיל חומרה ואחריות יצרן, להגדיר מי אחראי על עדכונים, לבחון את מדיניות הגיבוי והאבטחה, ולתעד את סדרי העדיפויות לשחזור. לעסקים רבים נכון גם לבחון מעבר הדרגתי לענן או למודל היברידי. זה לא פתרון אוטומטי לכל מערכת, אך הוא יכול להפחית תלות בשרת פיזי יחיד ולשפר זמינות לעובדים מרחוק.
Cloud360 מלווה עסקים בגישה של אחריות מלאה לתשתית – מניטור ותחזוקה, דרך גיבוי ואבטחת מידע ועד תמיכה בזמן אמת. הערך אינו רק בכיבוי שריפות, אלא בהיכרות רציפה עם סביבת העבודה, כך שכשמתרחשת תקלה אין צורך להתחיל את האבחון מאפס.
תוכנית התאוששות שמנהלים באמת יכולים להשתמש בה
תוכנית התאוששות מאסון אינה חייבת להיות מסמך ארוך שנשאר בתיקייה. היא צריכה לתת תשובות ברורות בזמן לחץ: מי מדווח על התקלה, למי מתקשרים, מי מוסמך לאשר שחזור, אילו מערכות חוזרות ראשונות, היכן נמצאים הגיבויים ואיך מעדכנים עובדים ולקוחות.
כדאי להגדיר גם יעד זמן התאוששות ריאלי. מערכת קריטית עשויה לדרוש חזרה תוך שעות בודדות, בעוד ארכיון ישן יכול להמתין יותר. ההבחנה הזו משפיעה על סוג הגיבוי, על עלות הפתרון ועל תכנון התשתית. אין טעם לשלם על זמינות מקסימלית לכל קובץ בארגון, אבל מסוכן באותה מידה לגלות שמערכת ליבה יכולה לחזור רק אחרי יומיים.
לפחות פעם בתקופה יש לתרגל תרחיש שחזור. לא כדי לייצר לחץ, אלא כדי לוודא שהאנשים, הגיבויים והנהלים אכן פועלים יחד. עסק שמכיר את רצף הפעולות שלו לא הופך חסין מתקלות, אבל הוא שומר על שליטה גם כשהשרת מפסיק לעבוד.
