גישה חדשנית לניהול סביבות IT

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

הקרב על יציבות הסביבה 

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

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

בשרתי Database של הספקים המובילים יש בין 400 ל- 2,000 פרמטרים של קונפיגורציה המגדירים את תפקודם.  שרתי האפליקציות הפופולאריים ביותר מכילים מעל 10,000 פרמטרים של קונפיגורציה. בנוסף, ישנן קונפיגורציות למערכות ההפעלה, שכבת המסרים, ממשקים,front-end  והאפליקציה עצמה. הקונפיגורציות של כל השכבות האלו יכולות להיות תלויות זו בזו במספר עולה של קומבינציות, כאשר כל אחת יכולה לסכן את יציבות הסביבה בצורה משמעותית ביותר.
 הגענו למצב ששינוי פרמטר בודד אחד יכול לגרור למהפך דרמטי בהתנהגות הסביבה.  חישבו על פרמטרים כמו הגודל של מאגר הקישורים (connection pool) בשרת אפליקציות או פרמטר keep alive אשר בשרת ה-web. הם בדרך כלל מסתתרים בין מאות תכונות (attributes) דומות, אבל שינוי לערכים שלהם יכול להשפיע גם על זמני הביצוע וגם על הפונקציונאליות של מערכת המשתמשת בשרתים אלו. כתוצאה מכך, אנשי התפעול ואנשי התשתיות עלולים להשקיע ימים רבים בניסיון לזהות את מקור הבעיה בעוד שתיקון הבעיה אורך מספר דקות.

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

סקר שנערך לא מזמן בקרב תריסר ארגוני IT על-ידי Evolven Software זיהה את הנושאים הבאים:

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

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

מגבלות הגישה הקיימת 

בשוק קיימים כיום כלים עזר שונים לניהול IT המתמקדים על ניהול ואופטימיזציה של זמינות וביצועי מערכות.  וכרגיל, "ארבעת הגדולים" הכוללים את BMC, CA, HP ו- IBM שולטים בשוק זה.  בשנים האחרונות, הצטרפו חברות חדשות המספקות פתרונות ניהול ל-IT, בניהן EMC ו- Symantec.  התפיסה השלטת בכל הפתרונות הקיימים מתבססת על מסגרות ITIL . מצד אחד, פעולות יזומות כמו ניהול גרסאות או בקרת שינויים למניעת בעיות בניהול המערכת, ומצד שני יכולת תגובה בנושאים כגון ניהול תקלות וניהול משימות המאפשרים לשלוט בנושאי יעילות העבודה כאשר נדרשים. 

נבחן יותר לעומק את כלי ניהול IT הקיימים:

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

 Configuration Management Database (CMDB) . הפלטפורמה הזו מאפשרת לצפות בארכיטקטורה של מרכז המידע (data center) והתלויות בין רכיבים שונים בסביבת העבודה, פעולה המהווה בסיס לניהול מרכז מידע. אחת מהתכונות החשובות של CMDB היא, שהכלי מאפשר ניתוח השלכות השינויים (change impact analysis) גם באופן יזום וגם כתגובה בפאזל המורכב במיוחד של תלויות בין חומרה ותוכנה. CMDB מזהה באופן אוטומטי רכיבי סביבת עבודה וממפה את הקשרים בניהם. ל- CMDB יש פוטנציאל לאסוף את המאפיינים או הפרמטרים של מרכיבי קונפיגורציה, אבל פעילות זו כרוכה בהשקעת משאבים לצורך פעולות פיתוח קוד. נקודת התורפה העיקרית של CMDB בתחזוקת הפרטים הקטנים של קונפיגורציה היא, איך התפעול של אותם פרטים.  רוב פתרונות CMDB מותאמים לניתוח ההשפעות של רכיבי קונפיגורציה בעוד שמאגר מקיף של מאפיינים יוצר רעשים המעכבים את פעילות CMDB.

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

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

 Monitoring and Diagnostics. ישנם כלים שונים המיועדים לניטור התנהלות סביבות עבודה לצורך זיהוי חריגות, האטה בביצועים ונושאי זמינות.  אותם כלים, או אחרים, מופעלים כאשר מתגלה בעיה, לצורך זיהוי מקורה (פעילות זו נקראת דיאגנוזה – diagnostics). כל הכלים הללו מתבוננים ומנתחים התנהגות פרמטרים של מערכת כמו למשל – שימוש ב-CPU, זמינות הזיכרון, פעילות דיסקים, זמן תגובה של טרנזקציות וכד'. כלי Monitoring and diagnostics אוספים מידע ומתחילים בניתוח המצב בסימפטומים הניתנים לזיהוי מבחוץ או כאשר זוהו בתוך המערכת.  למעשה – זהו תהליך  drilldown בכיוון הפוך. התהליך דורש הבנה עמוקה של טכנולוגיות המערכת, ארכיטקטורה ומבנה פנימי.  מספר התמחויות נדרשות לכך והתהליך כרוך בפעילות אלימינציה מורכבת. התהליך מסתבך עוד יותר בגלל מורכבות המערכות המודרניות והאופי האינטגרטיבי של התהליכים העסקיים החוצים מערכות. כפי שכבר צוין קודם, הגורם לבעיה יכול להיות שינוי פשוט של פרמטרים בקונפיגורציה. אבל תהליך הדיאגנוזה עדיין חייב להתבצע כל הדרך החל מהסימפטום ועד לרכיב הספציפי והקונפיגורציה שלו בכדי לזהות את הגורם לבעיה.
 לאחרונה צמחה גישה חדשה המתבססת על טכנולוגיות הדמיה. ההדמיה מאפשרת להגביר את יעילות העבודה של משאבי מרכז המידע וכן לצמצם באופן משמעותי את מחירי התשתיות וניהולן.  סטנדרטיזציה של הסביבות הוא תוצר לוואי מעניין של ההדמיה: אתה יכול לקחת תצורה של סביבה קיימת וליישם אותה מספר פעמים במקום להתקין שוב ושוב מערכת הפעלה ורכיבי תשתית תואמים למערכות.  זה בהחלט מגדיל את הסיכון של טעויות בקונפיגורציה ברמה של תשתיות תוכנה. בעקבות כל אלה צצה בעיה נוספת:  מספר המכונות הוירטואליות ומספר הבבואות (images) של מכונות וירטואליות גדל עם הזמן, אבל פלטפורמות ההדמיה הקיימות רואות אותם כקופסאות שחורות. הפלטפורמות אינן מודעות למכונות הוירטואליות או לבבואות ולכן לא יכולות להציג אותן למשתמשים.  אבל המכונות הוירטואליות לא נשארות סטטיות. השינויים נכנסים אליהם בדיוק כמו למייצגים הפיזיים שלהן.  ואז, הדינאמיות של תשתיות המכונות הוירטואליות וחוסר השקיפות לתכולת ספריית הבבואות, גוררות החמרה ביציבות הסביבה.

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

 
דרישות לניהול יעיל של סביבת עבודה 

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

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

Time-to-Value

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

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

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

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

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

 כניסה מהירה ובטוחה דרך שירות על בסיס דרישה 

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

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

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

לסיכום 

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

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

כותב המאמר: סאשה גילנסון, סמנכ"ל בכיר ב-EVOLVEN
ליצירת קשר: Omer.Dror@ness.com
עומר דרור, מנהל V-Ness (חברת הבדיקות של נס טכנולוגיות)