ניסיון בשינוי אירוח SAP: כיצד להעביר מערכות מבלי שזה יהיה כואב עד מאוד

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

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

אירוח מערכות SAP

רק לפני חמש שנים, היה קשה לדמיין שלקוחות יתחילו להשתמש באופן מסיבי במשאבי אירוח עבור יישומי SAP. ברוב המקרים הם יושמו ב-premise. אולם עם התפתחות מודלים של מיקור חוץ ושוק שירותי הענן, השקפת העולם של הלקוחות החלה להשתנות. מהם הטיעונים המשפיעים על הבחירה לטובת הענן עבור SAP?

• למתחילים שזה עתה תכננו ליישם את SAP, תשתית ענן היא כמעט בחירה סטנדרטית - מדרגיות של משאבים לצרכים הנוכחיים של המערכת וחוסר רצון להפנות משאבים לפיתוח כישורים שאינם הליבה.
• בחברות עם נוף מערכתי גדול, בעזרת אירוח מערכות SAP, מנהלי ה-CIO מגיעים לרמה שונה מבחינה איכותית של ניהול סיכונים, מכיוון השותף אחראי ל-SLA.
• הטיעון השלישי בשכיחותו הוא העלות הגבוהה של בניית תשתית ליישום זמינות גבוהה ותרחישי DR.
• פקטור 2027 – הספק הודיע ​​על סיום התמיכה במערכות מדור קודם ב-2027. המשמעות היא העברת מסד הנתונים ל-HANA, דבר הכרוך בעלויות עבור מודרניזציה ורכישת כוח מחשוב חדש.

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

מהם הקשיים בשינוי אירוח SAP?

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

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

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

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

ננתח את הקשיים שעלולים להתעורר בכל שלב במקרה של העברת מערכות SAP מאחד מלקוחותינו.

הכנה ועיצוב

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

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

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

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

• שרתים פיזיים ייעודיים עבור SAP HANA;
• פלטפורמת וירטואליזציה של VMware לשרתי יישומים ושירותי תשתית;
• ערוצי תקשורת משוכפלים בין מרכזי נתונים עבור L2 VPN;
• שתי מערכות אחסון עיקריות להפרדה בין המוצר ל"כל השאר";
• SRC מבוסס על Veritas Netbackup עם שרת נפרד, מדף דיסקים וספריית קלטות.

והנה איך יישמנו את כל זה מנקודת מבט טכנית.

SAP

• כדי להשתמש ביעילות באחסון עבור HANA פרודוקטיבי, השתמשנו בדיסקים משותפים ללא שכפול מסד נתונים מערכתי באמצעות SAP. כל זה היה עטוף באשכול SUSE HAE Active-Standby המבוסס על קוצב לב. כן, זמן השחזור מעט ארוך יותר מאשר בשכפול, אבל אנחנו חוסכים שטח אחסון בחצי וכתוצאה מכך, חוסכים את התקציב של הלקוח.
• בסביבות טרום-ייצור, אשכולות HANA ננטשו, אך מבחינה טכנית תצורת הייצור חזרה על עצמה.
• סביבות בדיקה ופיתוח הופצו על פני מספר שרתים נוספים ללא אשכולות בתצורת MCOS.
• כל שרתי היישומים הוירטואליזו והתארחו ב-VMware.

סטים

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

SHD

• העומס הפרודוקטיבי והקדם-פרודוקטיבי של SAP הושאר על מערך ה-all-Flash.
• סביבות בדיקה של מפתחים ושירותי תשתית הוצבו על מערך היברידי נפרד.

IBS

• נעשה באמצעות Veritas Netbackup.
• הוספנו מעט לסקריפטים המובנים לגיבוי תצורות MCOS.
• שמנו עותקים תפעוליים על מדף דיסקים לשחזור מהיר, ואנחנו משתמשים בקלטות לאחסון לטווח ארוך.

ניטור

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

מברק

בריאות כללית של HANA

מצב שרת יישומים של SAP:

שירותי תשתית

• כדי לתת שירות למרחבי שמות פנימיים, הועלה אשכול שרתי DNS, המסונכרן עם שרתי הלקוח.
• יצרנו שרת קבצים נפרד להחלפת נתונים.
• כדי לאחסן תצורות שונות, נוספה Gitlab.
• למידע רגיש שונה לקחנו את HashiCorp Vault.

תהליך הגירה

באופן כללי, תהליך ההגירה מורכב מהשלבים הבאים:

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

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

מה שאתה צריך לשים לב תחילה הוא זמן האספקה ​​של הציוד. בממוצע, אספקת חומרה מאושרת עבור SAP NAHA העומדת בדרישות יצרן התוכנה לפלטפורמות חומרה נמשכת 10-12 שבועות. ובהתחשב בעונתיות (יישום הפרויקט נפל בדיוק בראש השנה), התקופה הזו הייתה יכולה לגדול בעוד חודש. בהתאם, היה צורך לזרז את התהליך ככל שניתן: עבדנו עם המפיץ-ספק וסיכמנו על אספקה ​​מזורזת במטוס (במקום נתיבי יבשה וימי).

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

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

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

סדר ההגירה הכללי נראה כך: ראשית, המערכות הכי פחות קריטיות (נוף פיתוח, נוף בדיקות), אחר כך מערכות פרודוקטיביות. השלב האחרון של ההגירה התרחש בסוף ינואר ובתחילת פברואר.

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

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

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

תפקיד הלקוח בפרויקט

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

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

תוצאות הפרויקט

השלב האחרון של ההגירה היה העברת מערכות לתחזוקה.

כעת אנו מספקים שירות חלון יחיד לבקשות לקוחות ומכסים את כל היקף המשימות הקשורות לתמיכה ברכיבי תשתית ובסיס SAP יחד עם השותף שלנו - itelligence. הלקוח חי בענן פרטי כבר שישה חודשים. להלן הנתונים הסטטיסטיים על מקרי שירות בתקופה זו:

• 90 תקריות (20% נפתרו מבלי לערב את הלקוח)
• נפתר במסגרת SLA - 100%
• כיבוי מערכת לא מתוכנן - 0

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

מקור: www.habr.com