מאמר זה מספק מסגרת העברה מובנית בשירות עצמי עבור שותפים ול קוחות המעבירים סביבות שיחות אל Webex Calling - מופע ייעודי (DI).

שיטות ההעברה ואבני הדרך המתוארים במאמר זה מבוססים על מתודולוגיית תוכנית Webex Setup Assist ומשקפים את הניסיון הרחב בעולם האמיתי של צוותי אספקה, הנדסה ופיתוח של סיסקו. שיטות אלה שופצו באמצעות מאות אלפי פריסות ייחודיות של מיקום לקוחות בשבע השנים האחרונות, כולל העברות מברודקלאוד, BroadWorks, Spark Calling, Unified CM (UCM), פתרון שיתוף פעולה באירוח (HCS) ופלטפורמות מרכזיות של צד שלישי. ההנחיה חלה על מגוון רחב של סביבות לקוחות, החל מפריסות של מושב יחיד ועד ליישומים בקנה מידה גדול העולים על 100,000 מושבים ומאות מיקומים, והיא עוקבת אחר תהליכים מבוססים ומוכחים של Cisco כדי להבטיח עקביות, איכות ויעילות תפעולית לאורך מחזור החיים של ההעברה.

המאמר מניח שהקוראים כבר מכירים Webex Calling - רישוי מופעים ייעודיים, מודל הניהול של Webex Control Hub ואת התוכנה והתכונות הבסיסיות של מנהל התקשורת המאוחד .

בואו נהיה כנים - המילה הגירה לעיתים רחוקות מעוררת התרגשות בצוות IT. זה מעורר שאלות. "מה נשבר?" "מי עושה את העבודה?" "על מה אנחנו מאבדים שליטה?" "האם זה בכלל מציאותי בזמן שאנחנו כבר נמתחים כשאנחנו שומרים על האורות דולקים?" אלה אינם סימנים להת נגדות להתקדמות; הם האינסטינקטים של אנשי מקצוע מנוסים שמבינים כי העברת פלטפורמת קריאה קריטית למשימה אינה פרויקט בסוף השבוע. Voice הוא השירות היחיד שבו משתמשים מבחינים בתקלה של שתי שניות לפני שהם מבחינים במאמץ תכנון הפסקות של שבועיים - והמציאות הזו גורמת לכל שינוי להרגיש כבד יותר ממה שהוא צריך.

החדשות הטובות? המספרים מספרים סיפור שונה מאוד מהפחד. בהגירות ענן מובנות היטב, כ - 95% מהמאמץ ההנדסי מושקעים בהכנה, ורק 5% בשינוי בפועל. אפילו יותר טוב, רוב 95% אלה מורכבים מפעילויות שהצוות שלך כבר מבצע כחלק מפעולות רגילות ביום 2 - היגיינת מלאי, ניהול תעודות, סקירות תוכניות חיוג, מעקב אחר מחזור חיי המכשיר ותיעוד. במילים אחרות, עי קר "עבודת ההגירה" היא עבודה שאתה כבר עושה. גישה מובנית זו פשוט מנתלת אותה לתוצאה מוגדרת, בקצב שמתאים לקצב התפעולי הקיים שלך ולא מעליו.

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

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

מה שאתה מקבל בתמורה הוא פלטפורמה המשולבת היטב עם תיק השיחות, הפ גישות והמרכז המתקדם ביותר בשוק, המגובה בעומק ההנדסי של סיסקו ו במערכת אקולוגית של שותפים מעודנת באמצעות מאות אלפי פריסות. אתה שומר על מלוא העוצמה של Unified CM המערכת האקולוגית המוכרת - אותן תכונות, אותה אמינות, אותו מודל ניהולי שהצוות שלך כבר מכיר - כעת בשילוב עם Control Hub, מטריית ניהול וניתוח מודרנית ומכוונת משתמש שקל ללמוד באמת. שדרוגים, עדכונים ותיקוני פגיעות קריטיות בתוכנה העדכנית ביותר מנו הלים על ידי Cisco, במחשבים מאושרים על ידי Cisco, באותה אמינות (או טובה יותר) שאתה מצפה מהסביבה המקומית שלך.

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

מביטחון לתוכנית: כיצד מאורגן מדריך זה

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

• ייזום פרויקט
• גילוי והערכה
• תכנון
• יישום
• להקפיא
• צא לשידור חי
• העברה ליום 2

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

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

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

לאורך כל המדריך, אנו מתייחסים למשאבי המידע העיקריים שעליהם תסתמך במהלך ההעברה ועד היום השני:

• סיסקו להתקשר למכירות - קישור להתקשרות למכירות של סי סקו
• Help.webex.com — תיעוד מוצר ותצורה סמכותי
• Webex Spaces — גישה ישירה למומחי סיסקו ולקהילות עמיתים לשאלות בזמן אמת

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

השפעה על הייצור: אין השפעה

• זיהוי בעלי עניין מרכזיים

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

• ניהול IT
• ניהול עסקי
• צוות שירותי קול
• צוות מרכזי קשר
• צוות נטוורקינג
• צוות DNS/DHCP
• צוות אבטחה
• צוות IAM (למשל אנטרה, AD, SSO)
• החלף לוח
• שותף MACD
• שותף לשירותים מנוהלים
• ספקי שילוב צד תלת מימד (פיג'ינג, פקס, הקלטה וכו ')
• תמיכה מקומית, מקומית
• רדסקי/צוות בטיחות הציבור.

• בחירה של מנהל פרויקט או מנהל פרויקט.

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

• סנכרן בכניסות שאיתם אתה מתחיל פרויקט

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

האם יש שינויים כמו איחוד אשכולות, תוכנית חיוג, תכונות חדשות מתוכננות?

האם אתה מעביר נקודות קצה של תוכנה "כפי שהן" או העברה מניחה מעבר לאפליקציית Webex?

מה הקשר של משתמשים למרכזי קשר?

• התעדכן במהירות עם מופע ייעודי

מבוא למופע ייעודי: מבוא למופע ייעודי

BDM (שקופיות מקבלי החלטות עסקיות) BDM

TDM (שקופיות מקבלי החלטות טכניות) T DM.

השפעה על הייצור: אין השפעה

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

• הגדרת אשכול קיימת

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

• יישומים וגודל,
• מיקומים,
• כתובת IP,
• כיצד משתמשים מסונכר/סיפקו (מקומי, ldap),
• אימות מוגדר (SSO),
• CA לעומת אישורים בחתימה עצמית,
• מצב אבטחה,
• שימוש ב- ILS/GDPR,
• תכונות,
• התמקדות מיוחדת בתכונות חוצות אתרים כמו, Extension Mobility
• שילוב CER/911,
• שימוש ב- MRA,
• CDR,
• הודעות קוליות ואינטגרציה עם O365,
• ג'אבר לעומת WebExApp
  • במקרה של העברת Jabber, יש להתמקד באופן שבו נקבעו נקודות קצה קיימות של Jabber (למשל תצורת xml, תחום שירות קולי) ומהן האפשרויות להגדרה מחדש כמו שימוש ב- SCCM. להלן תרחישים סטנדרטיים שצוינו: הגדר את Jabber
• רשימת התקנים עם מיקוד לבדיקה
  • מכשירים מיושנים (לא נוספו מכשירים חדשים ברשימת ההשמדה מאז Rel12.0x) טלפונים מיושנים
  • סיום התקני תמיכה (התקנים עדיין יכולים להיות רשומים בכל מהדורת תוכנה, אך אינם נתמכים מנקודת מבט של יום 2)
  • CSR-Compatibility-Matrix-Interactive.html
  • התקני הגבלה מיוחדים 7925, 7940, 7960 רשום דגמי טלפון ישנים למו פע ייעודי
    • כלים בעזרה:

      עוזר טרום העברה למופע ייעודי: צור דוחות הערכה

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

      כדי להפעיל את Assistant, האשכול המקומי שלך חייב להיות מחובר לסביבת UC המחוברת לענן של We bex. תיאור כולל ותנאים מוקדמים תוכלו למצוא כאן: We bexCloud-ConnectedUC

      תהליך העלייה למטוס עבור UCM: הגדרת Webex Cloud Connected -UC

      רשימת תובנות חשובות שתוכלו לקבל כפלט מעוזר טרום ההגירה בפורמט xls שניתן לקרוא בקלות:

      • צמתים ותוכנות הפעלה
      • פרמטרים ארגוניים
      • רשימת גזעי SIP
      • רשימת משתמשי יישום, תפקידים
      • מספר המכשירים (ורשימת המכשירים המלאה), קבוצות מסלול ומחיצות, מי קומים, משתמשי קצה
      • קבוצות CM, מאגרי מכשירים
      • מצב בריאותי של שכפול DB
      • קופ מותקנים
      • תוכניות מספור
      • שירותי טלפון
      • יעדים מרוחקים
    • Webex Spaces לתמיכה בשאלות הספציפיות שלך:

      שאל את הענן של UCM ומו פע ייעודי: webexteams: //im? מרחב = 5db6bb40-d3c7-11e9-a319-df8a35abe85a

      שאל את RedSky External - הצטרפות לשותף פתרונות E911 פלוס: https://eurl.io/#fWfT1SnOz

      שאל את סיוע ההתקנה של Webex - ו Webex Calling - DI: webexteams: //im? מרחב = 76ביאבא50-084ב-11א-אבק8-אב581010ב1דה.

השפעה על הייצור: השפעה מינימלית על סביבת הייצור הקיימת

שיטות עבודה מומלצות של Cisco במונחים של תהליך העברת מופעים ייעודיים המוצ גים להלן:

הצטרפות/קישוריות

ארכיטקט ורת רשת עם תיאורים מפורטים של תרחישי חיבור Edge עבור Webex Calling מופע יי עודי ופגישות. PA_Edge_Connect_Design.pdf

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

Webex Edgeהתחבר

Webex Edgeהתחבר השאלות הנפוצות ביותר, הערות:

• קישורים ייעודיים למופע 2 הם "חובה"
• 4 קישורים הם אפשרות אך "מעבר" אסור, אלה משמשים ב "זוגות"
• כל תעדוף תעבורת DI כלפי אחד הקישורים אינו נתמך ובדרך כלל אינו ישים, מכיוון שכל צד/DC מפרסם את מיקומי מרכז הנתונים הייחודיים שלו /25 מופעים יי עו דיים.

זה מוסבר גם במסמך ארכיטקטורת הרשת שהוזכר להלן:

השפעה על הייצור: עם השפעה מוגבלת לתהליכי תפעול

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

במקרה שיש צורך ב- MACD בשלב ההקפאה, יש להשלים את השינויים הנדרשים בשתי המע רכות.

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

UCM:

ייצוא@@ /ייבוא BAT ותסריטים נ לווים

מדריך לניהול בתפזורת עבורCisco Unified Communications Manager, מהדורה 15 ו- SU: CUCM_b_bulk-administration-guide-15.html.

כלים חיצוניים להעברות UCM כמו Yarnlab.

אחדות:

• Cisco Unityכלים. אוסף כלים חינ Cisco Unity מיים Cisco Unity Connection וקשורים.

https://www.ciscounitytools.com/index.html

אנו ממליצים להשתמש בקובראס להגירות אחדות.

CER:

ידני, ייצוא/יבוא בתפזורת

לאחר העברת נתוני התצורה, שקול את הפריטים/הפעולות החשובות הבאות:

• ידני או באמצעות אפשרות 150 ב- DHCP ביחס להצבעה מחדש של קבוצת בדיקה של דג מי טלפון שונים ל- DI TFTP חדש. לאחר איחוד האישורים תוכלו לבדוק את שניהם: תרחיש העברה והחזרה
• תצורה מחדש של שער הבדיקה, אם זמין
• הכנת תבניות תצורת Gateways לקיצוץ ייצור בפועל. תסריט, במידת הצורך.
• העברת משתמש WebExApp באמצעות שינוי התנהגות שיחות ב- CH
• העברת Jabber באמצעות שיטת התחברות שהוגדרה בעבר ושינוי אשכול ביתי
• בדיקת זרימות שיחות ופונקציונליות בסיסיות עד ליכולות הסביבה:
  • בדיקת עקביות ההתנהגות ברשת או מחוברת באמצעות VPN
  • בדיקת MRA עם נקודת קצה של טלפון ותוכנה
  • PSTN
  • בדיקת שירות 911

• תמיכה ברמה 1 של מופעים ייעודיים ברמה 1 (TAC) של מופ עים ייעודיים

• בקשות שירות הקשורות לנושאים המפורטים: כיצד להעלות בקשת שירות
  • כניסת DNS
  • עדכוני חומת אש
  • העלאת קושחה
  • קישוריות ענן
  • הגדרות יומן ביקורת
  • ניהול יישומי UC
  • גזעי SIP בין תפקודים DI-MT
  • מחזור חיים של יישומי UC
  • תשתיות כשירות
    • מדריך תפעול של שותפים

• מדריך תפעול של שותפים

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

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

• מטריצת אחריות

המסמך מסביר את התפלגות RACI בין שותף, סיסקו וללקוח במהלך מטריצת הקצאת אחריות התפעול ואחריות תפ עול

• שאל את RedSky Webex Space צוותי webex: //im? מרחב = 7074fce0-489א-11אה-89פ3-8f977dd07aa0.