לקוחות צריכים גיבוי, ואתם כבר מנהלים את המערכות שלהם. נשמע כמו צעד טבעי להציע גיבוי כשירות, BaaS. חלק מהספקים עדיין משאירים את הגיבוי בידי הלקוח, ואחרים עוד לא הפכו אותו לשירות חוזר. כדי לעשות זאת היטב, צריך יותר מתוכנה שמעתיקה קבצים: צריך שירות שאפשר להקים, לנהל ולספק באופן צפוי.
העקרונות המרכזיים
- מתכננים מהשחזור לאחור
- בוחנים יכולות ואחסון
- מגדירים ניהול ושירות
השירות צריך לתת ערך גם ללקוח וגם לספק. בחירת תוכנה והפעלת גיבויים הן רק חלק מהעבודה. הפרטים הטכניים קובעים מה אפשר להבטיח ומה באמת אפשר לבצע.
נבחן את השיקולים הטכניים לתכנון השירות. ההחלטות על דרך העבודה ישפיעו בהמשך על היקף השירות, הסכם רמת השירות והתמחור. עדיף להחליט מה יודעים לספק לפני שמנסחים הבטחה ללקוח.
למי השירות נותן ערך?
לא כל ספק צריך להשיק BaaS מחר בבוקר. יש שתי שאלות בסיסיות: האם הלקוח צריך את השירות, והאם תוכלו להרוויח ממתן שירות טוב? בלי צורך אמיתי, מקבלים פתרון שמסתובב ומחפש בעיה.
גיבוי מאפשר להגיב לפגיעה שנגרמת מאנשים, מכשל מערכת או ממזג אוויר. נוזקות שמדביקות תחנות וכופרה שמצפינה מידע ומערכות מחייבות יכולת לחזור למצב תקין שנשמר.
הקמה וניטור של גיבויים יכולים ליצור הכנסה חוזרת. בהתאם להגדרת השירות, עשויים להיות גם שירותים נקודתיים בתגובה לאירוע, בטיפול באיומים ובבדיקות גיבוי ושחזור.
לפי המקור, BaaS יכול לענות על צורך עסקי וליצור תחום שירות רווחי. כדי להתחיל יש לבחון אילו שירותים נדרשים ללקוחות ומהן היכולות הטכניות שלכם.
מה בדיוק אתם מתחייבים לספק?
לקנות תוכנת גיבוי ולהוסיף מעט לעלות החודשית שלה זה עדיין לא שירות שלם. צריך להגדיר מה מגבים, לאן, באיזו דרך ואיך מנהלים את הכול. ההחלטות האלה משפיעות על היעילות, על יכולת החיזוי ועל הרווחיות.
המקור מחלק את השיקולים לארבעה תחומים:
- תכונות ויכולות פתרון הגיבוי.
- אחסון הגיבויים.
- ניהול הגיבוי.
- אפשרויות התאוששות.
בודקים שהתוכנה מתאימה לעבודה שלכם
יש מגוון פתרונות, שיטות ויכולות. בחנו לעומק את הפתרונות שאתם שוקלים ביחס להיבטים הבאים.
התקנה והגדרה
מעבר לפשטות בסיסית, הפתרון צריך להתאים לעבודת ספק שירותים: התקנה מהירה, ניהול כמה לקוחות בהפרדה, חיבור נוח ליעדי אחסון וכדומה. אלה מסייעים להקמת השירות.
תמיכה במערכות הפעלה שונות
אם כל הלקוחות עובדים עם Windows, חלק מהבחירה פשוט יותר. בפועל, עובדים עשויים להשתמש ב־Mac ושרתים ב־Linux. בדקו תמיכה ב־Windows, macOS ו־Linux לפי הסביבות שאתם באמת מנהלים.
גיבוי המודע ליישום
כשיישום נכשל עקב מסד פגום או לא עקבי, מאמצי ההתאוששות צריכים להתמקד בנתונים הנדרשים. גיבוי המותאם ליישום יכול לסייע לשמור את המידע בצורה המתאימה לשחזור שלו.
המקור משתמש בדוגמה של בחירת Office 365 ומציין יישומים כגון SQL Server, Exchange, Office 365 ו־Google Apps. שירותים כאלה, במיוחד עבור יישומי ענן, יכולים להיות חלק מההצעה או תוספת לפי הצורך.
כמה סוגי גיבוי
המקור מבחין בין גיבוי קבצים לבין גיבוי Image. גיבוי קבצים מתאים להגנה על קבוצת מידע מסוימת מפני השחתה, מחיקה או הצפנה. גיבוי תמונה מתאים להחזרת מערכת רחבה יותר, לרבות תרחישי שחזור פיזיים ווירטואליים.
בהתאם לפתרון, אפשר גם לפתוח או לחבר תמונה ולחלץ ממנה קבצים בודדים. בחנו אם הלקוחות זקוקים לגיבוי ברמת קובץ בנוסף לתמונה, ואל תניחו שמוצר אחד תומך בכל אפשרות.
טכנולוגיה יעילה
הציפייה אינה רק להעתקת מידע ליעד. פתרונות כוללים גם דרכים לייעל מה מועבר ונשמר: גיבוי מצטבר, מניעת כפילויות, דחיסה והגבלת רוחב פס הן דוגמאות במקור.
הבינו את פרטי המימוש ואת ההתאמה לצורכי הלקוחות, כדי לשפר את יעילות העבודה והשחזור בלי לפגוע בכיסוי.
אבטחה
מידע הלקוח עשוי לכלול מידע הכפוף לדרישות, קניין רוחני, סודות תפעוליים ופרטים אישיים. המקור מדגיש הצפנה בזמן ההעברה ובאחסון.
כל אחד מהשיקולים האלה קובע כיצד השירות יפעל: למשל, אם תוכלו לתת שירות ללקוח שמשתמש רק ב־Mac או ללקוח עם שרתים פיזיים בלבד. החליטו מה נדרש בפתרון, ובדקו שהוא תומך גם בשיטת האחסון שבחרתם.
איפה העותקים יחכו ליום השחזור?
מיקום המידע משפיע על זמינותו, על מהירות השחזור ועל העלות ללקוח. המקור ממליץ לתכנן לפי 3-2-1:
- שלושה עותקי מידע, כולל עותק הייצור.
- שני סוגי מדיה שונים, כגון דיסק וקלטת או יעדים מתאימים אחרים.
- עותק אחד מחוץ לאתר, למשל בענן.
אחסון מקומי
SAN, NAS, שרת אחסון או קלטת באתר הלקוח יכולים לספק עותק מקומי. תצורות מקומיות מאפשרות גישה גם בלי אינטרנט, אבל מהירות ההגעה למידע תלויה במדיה ובמימוש.
אחסון מרוחק וענן
המקור כולל בקטגוריה הזו אחסון של ספק תוכנת הגיבוי, ענן ציבורי או פרטי של צד שלישי, וגם מרכז נתונים מרוחק של הלקוח. ריבוי אפשרויות יכול להרחיב את היכולת לבחור מחיר ותכונות מתאימים.
המטרה היא להחזיק גיבויים מחוץ לאתר, כדי שיהיו זמינים כשצריך לשחזר מרחוק או כאשר האתר המקומי נפגע.
מודל היברידי
שומרים עותק מקומי ועותק בענן. שילוב כזה יכול לתת מענה לסוגי אירוע שונים וגם למצבים שבהם אין גישה לאינטרנט. בעת הבחירה בחנו עלות חודשית, מהירות שליפה והעברה, שכבות אחסון פעילות או ארכיוניות, אבטחה וזמינות.
מה נדרש כדי לנהל את השירות ביום־יום?
כמו בכל שירות, העבודה צריכה להיות יעילה, פשוטה ומועילה. גם פתרון טוב מבחינה טכנית יכול ליצור עלות גבוהה אם חסרות בו יכולות ניהול המתאימות לשירות. המקור מציע לבדוק:
ניהול מרחוק
ניהול מרכזי יכול לאפשר לצוות לעקוב אחר לקוחות שונים בלי לנהל כל אתר בנפרד. הפרדת מידע והרשאות בין לקוחות צריכה להישמר גם במסוף משותף.
ניטור והתראות
כשמנהלים כמה לקוחות ממקום אחד, הצוות צריך לדעת על תקלות בזמן. הגדירו התראות כך שאפשר להבין אצל מי יש בעיה ומה דורש טיפול. מסוף מרכזי מועיל במיוחד כשהוא לא מחכה שמישהו במקרה יפתח אותו.
רישוי וחיוב
אם מודל החיוב מבוסס על נפח, צריך לעקוב ולדווח על האחסון של כל לקוח. יש לעקוב גם אחר עלויות הרישוי של המענה לדרישותיו. שיטת החיוב עצמה יכולה להשתנות לפי ההצעה.
חיבור למערכות נוספות
שירות הגיבוי אינו פועל לבדו. שילוב עם מערכת קריאות, חיוב ואוטומציה מאפשר לו להיות חלק עקבי ממערך השירותים של הספק.
מתכננים גם את הדרך חזרה
לקוח עלול לאבד מידע, לחוות כשל מערכת או להיפגע באסון. כדי שהשירות יעזור אז, צריך להגדיר מראש את דרך ההתאוששות. השאלה החשובה היא לא רק אם יש עותק, אלא איך מחזירים באמצעותו את העבודה.
חשבו כיצד תתמודדו עם אובדן של נתונים, יישום, מערכת, חומרה, אתר, אינטרנט או יכולת עבודה עסקית. כמה אפשרויות שחזור מאפשרות לתת מענה לסוגי אירוע שונים.
שחזור קבצים
כשמדובר במחיקה בטעות או בפגיעה בקבצים מסוימים, אין תמיד צורך להחזיר מערכת שלמה. שחזרו את הקבצים שנפגעו, לאחר בדיקת היקף האירוע.
שחזור Bare Metal
אם צריך לבנות מערכת פיזית מחדש, היכולת לשחזר את מערכת ההפעלה, נתוני האתחול ושאר המערכת יכולה לצמצם עבודה ידנית. נדרשת תמיכה של הפתרון ותאימות ליעד.
שחזור למכונה וירטואלית
כשל חומרה עשוי לחייב יעד חלופי שאינו זמין עדיין. האפשרות להחזיר מערכת למכונה וירטואלית במקום להמתין למחשב פיזי יכולה לקצר התאוששות בתרחיש מתאים.
שחזור לענן
אובדן האתר המקומי עשוי להשאיר אתכם בלי יעד מקומי לשחזור. המקור מציע לכלול אפשרות להפעיל את המערכת בענן, גם כתוספת לשירות. משאבי מחשוב לפי דרישה יכולים להיות פתרון מעשי, אך יש לבדוק עלויות, קישוריות ותאימות.
גיבוי חבילות עבודה בענן
המקור מדגיש שיש לבחון את גבולות התחייבויות ספקי יישומי הענן. יתירות גאוגרפית לא בהכרח מאפשרת שחזור מכל מחיקה או פגיעה. הצעת גיבוי לדואר ולמידע של Microsoft 365 או Google Workspace יכולה להוסיף יכולת התאוששות.
מתחילים מהצורך של הלקוח לשחזר
גיבוי כשירות לא הופך לפשוט רק כי פעולת הגיבוי נראית פשוטה. התחילו מהנתונים הקריטיים שהלקוח צריך להחזיר, ועבדו לאחור אל פתרון שמסוגל לגבות ולשחזר אותם.
עברו על ארבעת התחומים: יכולות, אחסון, ניהול והתאוששות. כך תוכלו להבין מה נדרש באמת ולהגדיר שירות שאפשר לספק. הבטחה שקל לכתוב צריכה להיות גם פעולה שהצוות יודע לבצע.
נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.
מקור: the-msp-s-technical-guide-to-providing-baas.pdf מאת MSP360.
