מעבר לענן הוא העברה מסודרת של שרתים, תוכנות ונתונים ממשרד העסק אל ספק ענן, בשלבים: הערכת המצב, בחירת מודל מעבר לכל מערכת, העברה, בדיקות ותוכנית חזרה. עסק קטן מתחיל בדרך כלל במערכות הפשוטות, כמו דואר, קבצים ומרכזיה, ומשאיר לשלב מאוחר את מערכות הליבה. לפני שמתחילים, ממפים מה רץ היום ומה תלוי במה.
לפני שבוחרים מודל מעבר כדאי לקבל הערכה ראשונית של עלות הסביבה בענן. בחרו מספר ליבות, זיכרון, אחסון, מערכת הפעלה וקיבולת רשת וקבלו אומדן חודשי. המחשבון מבוסס על ממוצעי שוק ואינו הצעה מחייבת, ואת המפרט הסופי בונים לפי הצעות על אותו מפרט.
מחשבון מחיר שירותי מחשוב ענן לעסקים
בחרו מפרט שרת וקבלו הערכה חודשית ראשונית לפי ממוצעי שוק
ההערכה מבוססת על מחירי שוק ממוצעים, לפני מע"מ, ואינה הצעה מחייבת. המחיר הסופי נקבע לפי מפרט מדויק.
רוצים הצעה מדויקת למפרט שבחרתם?
מהנדס תקשורת של טלקום אקספרט יבדוק את הצרכים ויחזור עם הצעה, ללא התחייבות.
עיקרי הדברים
- אמזון (AWS) מגדירה שבע אסטרטגיות מעבר, ולעסק קטן בדרך כלל רלוונטיות בעיקר ארבע: העברה כמות שהיא, העברה עם התאמה, מעבר לתוכנה כשירות וסגירה של מה שאין בו שימוש.
- לפי AWS, אפליקציה שמנצלת פחות מחמישה אחוזים מהמעבד והזיכרון, או שלא הייתה אליה פנייה במשך תשעים יום, היא מועמדת לסגירה ולא להעברה.
- מיקרוסופט ממליצה להעביר סביבות פיתוח ובדיקה לפני סביבת הייצור, ולהגדיר תוכנית חזרה לפני תחילת העבודה.
- החיסכון אחרי המעבר מגיע מהתאמת משאבים לעומס, מכיבוי שירותים כשהעסק סגור, ממחיקת נתונים ישנים ומהתחייבות מראש כשהשימוש יציב. אין אחוז חיסכון שאפשר להבטיח מראש.
- לעיתים נדרש גם שדרוג קו האינטרנט, כי עבודה מול שרת בענן מעמיסה על קצב ההעלאה (Upload) ולא רק על ההורדה.
לתמונה רחבה של שירותי הענן שאפשר להעביר, ראו את המדריך שירותי ענן לעסקים.
חמש ההחלטות האפשריות לכל מערכת בעסק, לפי חלוקת אסטרטגיות המעבר המקובלת:
| מודל מעבר | מה עושים | מתי זה מתאים |
|---|---|---|
| העברה כמות שהיא (Rehost) | מעבירים שרת או מערכת כפי שהם, בלי לשנות אותם | כשרוצים מעבר מהיר ואין סיבה לשנות את המערכת |
| העברה עם התאמה (Replatform) | מעבירים עם שינוי מדוד, למשל מסד נתונים שעובר לשירות מנוהל | כשיש שיפור קטן וברור בלי שכתוב המערכת |
| מעבר לתוכנה כשירות (Repurchase) | מחליפים תוכנה מותקנת בגרסת ענן של היצרן | דואר, מערכת ניהול לקוחות ותוכנות משרדיות |
| סגירה (Retire) | מפסיקים להפעיל מערכת שאין בה שימוש | כשאין סיבה להעביר אותה |
| השארה במקום (Retain) | משאירים את המערכת במשרד | תלות בציוד ייעודי, דרישת מיקום נתונים או שדרוג שבוצע לאחרונה |
מהם שלבי המעבר לענן בעסק קטן?
- הערכה ומיפוי. רשימה של שרתים, תוכנות, רישיונות, משתמשים וקו האינטרנט, וגם של התלויות בין המערכות: איזו תוכנה מדברת עם איזה מסד נתונים.
- בחירת מודל מעבר לכל מערכת. לא כל מערכת עוברת באותה דרך. חלק עוברות כמות שהן, חלק מוחלפות בשירות מוכן וחלק נסגרות.
- תכנון. קובעים סדר, מחלקים את המערכות לקבוצות לפי תלות, ובוחרים חלון זמן מחוץ לשעות הפעילות ומחוץ לתקופות עומס כמו סגירת חודש או שנה.
- העברה ושכפול. הנתונים משוכפלים לענן בזמן שהמערכת הישנה ממשיכה לעבוד.
- בדיקות. קבוצת משתמשים קטנה עובדת על המערכת החדשה ומאשרת שההרשאות, המהירות והדוחות תקינים.
- מעבר סופי ותוכנית חזרה. המעבר מתבצע לפי קריטריונים מוגדרים מראש, והמערכת הישנה נשארת זמינה עד שהחדשה הוכחה.
- ייעול ופירוק. אחרי תקופת פעילות בודקים את גודל המשאבים, מכבים מה שמיותר ומפרקים בהדרגה את הציוד הישן.
איך בוחרים מודל מעבר לכל מערכת?
החלוקה בטבלה לעיל נשענת על אסטרטגיות המעבר של AWS. ההנחיה של AWS למעברים גדולים היא להעביר קודם בדרך הפשוטה, כמות שהיא, בהתאמה או במעבר לתוכנה כשירות, ולשדרג את המערכת רק אחרי שהיא פועלת בענן. שכתוב מערכת תוך כדי המעבר היא המורכבת והיקרה מבין האסטרטגיות, ולכן לעסק קטן היא כמעט אף פעם אינה נקודת ההתחלה.
שני המודלים שנשכחים הם סגירה והשארה. סגירה חוסכת עלות של שרת שאיש לא משתמש בו, ובדרך כלל מקטינה גם סיכוני אבטחה, כי מערכות ישנות שאינן מקבלות עדכונים הן נקודת תורפה. השארה במקום מתאימה למערכת שתלויה בציוד ייעודי שאין לו מקבילה בענן, למערכת שיש עליה דרישת מיקום נתונים, או למערכת שהעסק שדרג לאחרונה ועדיין לא הגיע הזמן להחליף. גם החלטה כזו היא חלק מתוכנית מעבר טובה.
באיזה סדר מעבירים מערכות ומה עושים אם משהו נכשל?
לפי המסגרת של מיקרוסופט לתכנון מעבר, מתחילים במערכות פשוטות וברמת סיכון נמוכה, מעבירים סביבות פיתוח ובדיקה לפני ייצור, ומשאירים מערכות קריטיות לגלים מאוחרים, אחרי שהצוות הוכיח שהוא שולט בתהליך. מערכות שתלויות זו בזו, למשל תוכנה ומסד הנתונים שלה, עוברות באותו גל.
למערכת שאפשר להשבית בחלון מתוכנן מתאים מעבר פשוט עם השבתה קצרה. למערכת קריטית, כמו מוקד שירות או מערכת הזמנות, בוחרים מעבר עם שכפול רציף והשבתה כמעט אפסית, ובודקים את זה בסביבת בדיקה לפני המעבר האמיתי.
תוכנית חזרה מוגדרת לפני תחילת העבודה, ולא בזמן תקלה. היא כוללת הגדרה של מה נחשב כישלון, למשל זמן תגובה חריג או נתונים חסרים, את הצעדים להחזרת המערכת הקודמת ואת האדם שמחליט. את תוכנית החזרה כדאי לבדוק בפועל בסביבת בדיקה, ולהשאיר את המערכת הישנה זמינה עד שהחדשה פועלת כסדרה.
כמה עולה מעבר לענן ומה כולל התקציב?
עלות המעבר מורכבת מכמה רכיבים. עבודת המיפוי והתכנון, ההעברה עצמה, תקופת הפעלה כפולה שבה משלמים גם על הישן וגם על החדש, הדרכת משתמשים, רישיונות, ולעיתים שדרוג קו האינטרנט. אחר כך מגיעה העלות השוטפת של הענן, שתלויה בשימוש בפועל. מחירי ענן משתנים לפי תצורה ושימוש, ולכן אין בעמוד מחירון. מחיר מדויק נקבע בהצעה, לפי מפרט של העסק.
דוגמה שאפשר לתמחר ישירות היא הטלפוניה. מרכזיה בענן אצל טלקום אקספרט מתחילה ב-20 ₪ לשלוחה, עם מינימום של 60 ₪ לחודש, וממוצע השוק נע בין 20 ל-80 ₪ לשלוחה בחודש. פרטים נוספים בעמוד מרכזיה בענן.
מהן העלויות הנסתרות של מעבר לענן, ובמיוחד רישוי והתקנה מחדש של תוכנות?
חלק מהעלויות אינו מופיע בהצעת הענן עצמה. הראשונה היא רישוי: תוכנה שנרכשה והותקנה על שרת פיזי לא תמיד מותרת להפעלה בענן באותם תנאים, ויצרנים שונים מגדירים אחרת את הזכות להעביר רישיון לסביבה וירטואלית או לענן של ספק. לכן בשלב המיפוי בודקים מול כל יצרן מה תנאי הרישוי בענן, ובמערכות שרצות על שרת ייעודי בודקים אם נדרש רישיון חדש.
השנייה היא התקנה מחדש. מערכת ישנה שאינה נתמכת במערכת ההפעלה העדכנית, או תוכנה שמחוברת לציוד ייעודי, עשויה לדרוש שדרוג גרסה, התקנה מחדש או החלפה בגרסת ענן של היצרן, והעבודה הזאת נוספת לעלות ההעברה. השלישית היא תקופת הפעלה כפולה, שבה העסק משלם גם על הסביבה הישנה וגם על החדשה עד שהמעבר אושר. הרביעית היא קו האינטרנט, הדרכת המשתמשים ותעבורה יוצאת מהענן. לפני החלטה מבקשים מהספק או מהאינטגרטור תשובה כתובה על ארבע שאלות:
- האם הרישיון הקיים מותר להפעלה בענן, ובאילו תנאים?
- האם נדרשת גרסה חדשה או התקנה מחדש של התוכנה?
- כמה זמן צפויה להימשך ההפעלה הכפולה?
- האם תעבורה יוצאת מהענן מתומחרת, ובאיזה אופן?
כמה זמן לוקח מעבר לענן ומה לוח הזמנים?
אין משך אחד נכון, כי הוא תלוי במספר המערכות, בכמות הנתונים, בתלויות ביניהן ובקצב ההעלאה של הקו. מעבר של דואר ושל קבצים נעשה בדרך כלל בשלבים קצרים, ומעבר של מערכת עסקית עם מסד נתונים דורש תכנון, בדיקות וחלון מעבר מוגדר.
את זמן שכפול הנתונים אפשר להעריך בחישוב פשוט: נפח הנתונים בביטים מחולק בקצב ההעלאה. טרה בייט אחד בקצב העלאה של 100 מגהביט לשנייה לוקח כ-22 שעות בתנאים תיאורטיים, בלי תקורה ובלי עומס אחר על הקו, ובקו אמיתי הזמן ארוך יותר. לכן כשהנתונים רבים בוחנים העברה בשלבים, העלאה בשעות הלילה או חיבור ייעודי.
מי שמבקש לוח זמנים בכתב דורש שיופיעו בו גלי מעבר, תאריך לכל גל, אחראי לכל משימה ונקודת החלטה לחזרה אחורה. לוח זמנים שמורכב רק מתאריך סיום אינו תוכנית.
איך מעבר לענן שומר על המשכיות עסקית?
המשכיות עסקית במעבר נשענת על כך שהמערכת הישנה ממשיכה לעבוד עד שהחדשה הוכחה. לשם כך קובעים מראש שני יעדים. נקודת שחזור (RPO, Recovery Point Objective) היא כמות הנתונים שמותר לאבד, וזמן שחזור (RTO, Recovery Time Objective) הוא משך ההשבתה שהעסק יכול לשאת. היעדים האלה קובעים אם מספיק מעבר פשוט בלילה, או שנדרש שכפול רציף.
- גיבוי עדכני לפני כל גל, ובדיקת שחזור אחת לפחות.
- הורדת זמן התוקף (TTL) של רשומות ה-DNS מראש, כדי שהמעבר של דואר ושל כתובות ייקלט מהר.
- קו אינטרנט וקו גיבוי שנבדקו לפני יום המעבר.
- רשימת אנשי קשר ונוהל פנייה לעובדים ביום הראשון בענן.
איפה אפשר לחסוך אחרי המעבר לענן?
חיסכון בענן אינו אוטומטי. הוא תוצאה של ניהול. מסמך עקרונות העלות (Cost Optimization) של AWS מדגיש מודעות להוצאות ולשימוש, התאמת המשאבים לביקוש ושיפור מתמשך לאורך זמן. בעסק קטן זה מתורגם לארבע פעולות קבועות:
- התאמת גודל. עסקים נוטים להזמין שרת גדול מהנדרש מתוך זהירות. בודקים ניצול מעבד וזיכרון בפועל אחרי חודש, ומקטינים בהתאם.
- כיבוי כשאין צורך. סביבות בדיקה ופיתוח, ושרתים שהעסק משתמש בהם רק בשעות העבודה, אינם חייבים לפעול סביב השעון. לפי תנאי רוב הספקים, כשהם כבויים החיוב על זמן החישוב נעצר ואילו האחסון ממשיך להיות מחויב.
- ניקוי נתונים ישנים. גיבויים ונתונים היסטוריים שאין בהם שימוש יומיומי נשארים לעיתים בשכבת אחסון יקרה. מעבירים אותם לאחסון זול יותר או מוחקים לפי מדיניות שמירה.
- התחייבות מראש כשהשימוש יציב. ספקים גדולים מציעים הנחה תמורת התחייבות לשימוש לתקופה, למשל Savings Plans של AWS. כדאי להתחייב רק על הבסיס שבטוח שיישאר, ולא על כל השימוש.
כדי לעמוד בזה, ממנים אחראי לבדיקת החשבון פעם בחודש, ומבקשים מהספק או מהאינטגרטור דוח צריכה לפי שירות. אי אפשר לדעת מראש כמה יחסוך עסק מסוים, ולכן אין לקבל הבטחה לאחוז חיסכון קבוע. לפני חתימה על התחייבות ארוכה מבקשים הצעה לאותו מפרט מכמה ספקים ובודקים את תנאי היציאה.
אילו סיכונים כדאי לצמצם לפני המעבר?
- תלות בקו האינטרנט. כשהקו נופל, הגישה למערכות בענן נפגעת. שוקלים קו גיבוי, וקו עם התחייבות לעסק שעובד כולו בענן.
- תלויות נסתרות. תוכנה ישנה שמדברת עם מדפסת, עם מערכת שכר או עם תיקייה משותפת עלולה להפסיק לעבוד אחרי המעבר. המיפוי בשלב הראשון נועד למנוע בדיוק את זה.
- הרשאות והגדרות. לפי מודל האחריות המשותפת, הספק מאבטח את התשתית והעסק את הגישה. מעבר טוב כולל מדיניות הרשאות מסודרת ואימות דו-שלבי מהיום הראשון.
- הצעה שנקראת ענן אבל אינה ענן. לעיתים מציעים שרת וירטואלי יחיד בלי גמישות ובלי שרידות. לפני החתימה בודקים מה בדיוק כלול בשירות.
- חזרה למצב קודם. אחרי המעבר, העסק צריך עדיין גיבוי עצמאי ותוכנית יציאה, כדי לא להיות תלוי בספק אחד.
איך מכינים את הרשת וקו האינטרנט לפני המעבר?
עבודה מול שרת בענן משנה את מבנה התעבורה של המשרד. נתונים שהיו עוברים ברשת המקומית עוברים עכשיו דרך האינטרנט, ולכן בודקים שלושה דברים לפני המעבר. הראשון הוא קצב ההעלאה (Upload), שבעסק עם קו רגיל נמוך בהרבה מקצב ההורדה, ובשרת בענן הוא נקבע לפי מספר העובדים שעובדים במקביל. השני הוא יציבות הקו, כלומר האם יש התחייבות של הספק לתקלות. השלישי הוא קו גיבוי, כדי שעובדים לא יישארו בלי גישה למערכות כשהקו הראשי נופל.
אם העובדים מתחברים מהבית או מסניפים, מוסיפים חיבור מאובטח למשרד או לענן, אימות דו-שלבי והרשאות לפי תפקיד. את ההגדרות האלה כדאי להשלים לפני המעבר ולא אחריו, כדי שהיום הראשון בענן לא יהיה גם יום של בעיות גישה.
מה כדאי לעשות בשבוע שלפני יום המעבר?
- לוודא שיש גיבוי עדכני של כל המערכות, ושבדקו לפחות שחזור אחד בפועל.
- להודיע לעובדים מה משתנה, מתי, ולמי פונים בבעיה, כולל הוראות התחברות כתובות.
- לבדוק שמשתמשי המפתח, למשל הנהלת חשבונות ומכירות, ביצעו תרגיל עבודה במערכת החדשה.
- להגדיר מי מחליט על חזרה אחורה ובאילו תנאים, ולוודא שהוא זמין בזמן המעבר.
- לעדכן ספקים חיצוניים שמתחברים למערכת, כמו חברת שכר או תוכנה חיצונית, בשינוי הכתובות והחיבורים.
אחרי המעבר שומרים את המערכת הישנה זמינה לתקופה מוגדרת, ורק אחרי שהמשתמשים אישרו שהכול עובד מכבים אותה ומפרקים את הציוד.
ענן עם טלקום אקספרט
מעבר לענן הוא פרויקט תכנון לפני שהוא פרויקט טכני. במסגרת טלקום אקספרט, מהנדס תקשורת עם מעל 25 שנות ניסיון ממפה את המערכות הקיימות, בוחר עם העסק מודל מעבר לכל מערכת, מתכנן גלים ותוכנית חזרה, מלווה את ההעברה וממשיך ללוות אחריה. טלקום אקספרט פועלת כאינטגרטור, ואינה כבולה לספק אחד, כך שהבחירה בין הספקים היא חלק מהתכנון. השירות מיועד לעסקים ולארגונים בלבד, ואינו מוצע ללקוחות פרטיים.
אילו שירותי מעבר אפשר לקבל בהצעה?
טלקום אקספרט מכינה הצעה לפי המערכות של העסק ולא חבילה קבועה. אלה השירותים שאפשר לבקש:
| שירות | מה כולל |
|---|---|
| הערכה ומיפוי לפני מעבר | מיפוי השרתים, התוכנות, הרישיונות, התלויות בין המערכות וקו האינטרנט הקיים, כבסיס לתוכנית המעבר. |
| תכנון גלי מעבר ותוכנית חזרה | תוכנית מעבר בשלבים עם סדר ההעברה, חלונות זמן שמתואמים עם העסק, יעדי שחזור ותוכנית חזרה אחורה אם צריך. |
| העברת שרתים ונתונים | שכפול של השרתים והנתונים לענן, בדיקות תקינות לכל מערכת, והעברה סופית בחלון הזמן שנקבע מראש. |
| מעבר דואר ותוכנות משרדיות לגרסת ענן | העברת תיבות הדואר, הקבצים והרשאות המשתמשים לגרסת הענן של תוכנות המשרד, עם הדרכה לעובדים על השימוש החדש. |
| התאמת קו האינטרנט לעבודה מול הענן | בדיקת קצב ההעלאה, היציבות וקו הגיבוי של האינטרנט, כדי לוודא שהעבודה מול הענן תהיה תקינה ומהירה. |
| ליווי אחרי המעבר וייעול עלויות | אחרי המעבר: התאמת גודל המשאבים לשימוש בפועל, בקרה חודשית על החשבון ודוח עלויות לעסק. |
| קבלו הצעת מחיר | |
לייעוץ ללא התחייבות: 077-8123111.
שאלות נפוצות על מעבר לענן
נכון לעבור כשתחזוקה, רישיונות ושדרוגים של שרתים מקומיים הופכים להוצאה קבועה שקשה לשלוט בה, וכשהעסק צריך להגדיל או להקטין משאבים מהר. מועד טבעי למעבר הוא כשמגיע הזמן להחליף שרת או מרכזייה ישנה, לפני שמשקיעים שוב בחומרה. לפני ההחלטה כדאי לקבל הצעה ולהשוות אותה לעלות הכוללת של המצב הקיים.
ברוב המקרים כן, אבל ההחלטה תלויה במערכות שהעסק מפעיל ולא בגודלו. עסק קטן מקבל ספק אחד וחוזה אחד במקום כמה ספקים, עדכונים אצל הספק והתאוששות מהירה יותר מתקלה במשרד. עסק שמפעיל ציוד ייעודי שאין לו מקבילה בענן יכול להשאיר אותו במקום. מבקשים הצעה ומשווים אותה לעלות של המצב הקיים.
מעבירים בהדרגה, מערכת אחרי מערכת, ומשאירים את המערכת הישנה פעילה עד שהחדשה נבדקה. קודם ממפים שרתים ותלויות, אחר כך משכפלים נתונים לענן ומריצים בדיקות עם קבוצת משתמשים קטנה. את המעבר הסופי מתזמנים לשעות שבהן העסק סגור, עם תוכנית חזרה מוכנה מראש.
הקושי העיקרי הוא ארגוני ולא טכני: שינוי הרגלי עבודה והעברת תוכנות ונתונים ממערכות ותיקות. צריך למפות מה רץ היום, לבדוק שכל מערכת נתמכת בענן ולתכנן העברה מדורגת עם בדיקות. קושי נוסף הוא קו אינטרנט שלא מותאם לעבודה מול שרת בענן, ולכן בודקים גם את קצב ההעלאה.
כן, ולעסק כזה המעבר מתאים במיוחד. כשאין איש מחשוב, כל תקלה בשרת מחייבת להזמין טכנאי, והגיבויים והעדכונים נעשים רק כשמישהו נזכר בהם. בשירות מנוהל הספק אחראי על התחזוקה, העדכונים והגיבוי. כדאי לוודא מראש מי נותן תמיכה לעובדים ביום יום ואיך פונים אליו.
הבזבוז העיקרי הוא הזמנת משאבים מעבר לצורך, שירותים שפועלים כשהעסק סגור, ונתונים ישנים באחסון יקר. כדי לחסוך מתאימים את הגודל לעומס בפועל, מכבים סביבות שאין בהן שימוש, מנקים נתונים לפי מדיניות שמירה, ושוקלים התחייבות מראש רק על שימוש יציב. אי אפשר להבטיח אחוז חיסכון מראש.
בדרך כלל מתחילים במערכות שהמעבר שלהן פשוט והתועלת מיידית: דואר ואוסף כלי העבודה המשרדיים, אחסון ושיתוף קבצים, גיבוי ומרכזיית הטלפון. בשלב שני עוברות מערכות הליבה, כמו הנהלת חשבונות וניהול לקוחות, שדורשות תכנון ובדיקה מול יצרן התוכנה. מעבר בשלבים מאפשר לעובדים להתרגל ומקטין סיכון.
הטמעה טובה מלווה גורם שמתכנן את כל השלבים ולא רק מוכר שירות. בטלקום אקספרט מהנדס תקשורת ממפה את המערכות הקיימות, מתכנן את המעבר, מתקין ומלווה את העסק גם אחריו. טלקום אקספרט אינה כבולה לספק אחד והיא שותפה עסקית של ספקי התקשורת המובילים, כך שהבחירה בין הספקים היא חלק מהתכנון.
