אסטרטגיית האוטומציה של מיקרוסופט ולמה כל איש IT צריך לדעת עליה

18 באוגוסט 2013

תגיות: , , , ,
אין תגובות

במסגרת סיבוב ההתעדכנות האחרון שלי בכנסי ה TechEd וה BUILD לפני כמה שבועות, נתקלתי שוב בנושא הניהול האוטומטי של מערכות גדולות. מערכות גדולות זה כמובן עניין יחסי אבל אם אתם מנהלים מערכות מחשוב יש מדד קל מאד להגדיר מה זה מערכת גדולה, מספר הפעמים שאתם צריכים לחזור על תהליך כלשהו בכל אחד מהמחשבים. אני עוד זוכר את התקופה שבה להכין כיתה לקורס היה לוקח לילה, שבו הייתי רץ בין 24 מחשבים ולוחץ על OK או Enter כל פעם שאחד מהם היה דורש התערבות אנושית. לכן אולי אצלי, לנהל יותר ממחשב אחד, זה נחשב למערכת גדולה. אני מניח שיהיו כמה מקצועני IT שימשכו את הגבול הזה קצת יותר, אולי עד 10. אבל מי שטוען שמערכת גדולה זה רק מעל 50 או 100 מחשבים, כנראה שלא רץ מספיק זמן בין מחשבים בשטח.

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

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

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

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

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

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

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

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

בדיוק בנקודה שבה איש ה IT, זה שעושה בסוף את כל העבודה, כשהוא מתרגם את הדרישות לפעולות, נכנסת לתמונה תשתית ההרחבה והניהול האוטומטי של מיקרוסופט, ששמה הרשמי הוא windows management framework, והיא מוכרת יותר לקהל הרחב בשם PowerShell (למרות ש PowerShell זה רק חלק ממנה). התשתית הזו היא הרבה יותר משפת Script ו/או Shell אינטראקטיבי. זו התשתית הבסיסית שבאמצעותה ניתן לבצע את ההתאמה של כלל כלי הניהול, של מיקרוסופט (ולא רק של מיקרוסופט) לדרישות הספציפיות המשתנות של הארגונים בשטח. זו התשובה לפער, הקיים תמיד, בין מה שמספקים הכלים הקיימים למה שנדרש בפועל.

תשתית הwindows management framework היא הבסיס לכל אסטרטגית הניהול האוטומטי של מיקרוסופט ולא רק של מיקרוסופט. התשתית הזו תומכת (ונתמכת) גם בכלי הניהול של יצרני תוכנות הניהול האחרים. כל כלי הניהול מספקים יכולת להפעלת PowerShell Scripts מתוכם, ושילוב התשובות שהם מקבלים בתהליך העבודה שלהם, ובכך מאפשרים לשלב את PowerShell כחלק אינטגרלי בתהליך ההתאמה לצרכי הלקוח של התהליכים המובנים שלהם.

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

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

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

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

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

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

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

לסיום, כמה נקודות מעניינות נוספות בהקשר הזה. כל תשתית ה FixIt הדינמית של מיקרוסופט וכל תשתית ה Windows troubleshooting platform מבוססות על PowerShell. מבחינת אבטחה, שימוש ב PowerShell משפר את האבטחה (בין השאר בגלל שכל התקשורת בין המחשבים מוצפנת עם קרברוס ובגלל שניתן לכוון יותר טוב את ההרשאות).

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

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