לאחרונה אנחנו נתקלים בהתעניינות מחודשת בתחום של automation לפעולות אנשי הסיסטם. ההתעניינות נובעת ככל הנראה מהקפאת התקנים בגופי התשתיות ועקב כך ברצון להקל על הצוותים תוך ביצוע אוטומציה עד כמה שאפשר של פעולותיהם. לפעמים יש התייחסות לכלים של שרתים בלבד ולעיתים מתייחסים גם לתחנות עבודה.
בתחום זה חשוב באופן ספציפי להגדיר "מה רוצים" כשבגדול הקטגוריות של המטרות האפשריות של הכלי הן:
1. גילוי וזיהוי של מה שיש (כולל קשרים) ללא ביצוע פעולות.
2. ביצוע אוטומטי של פעולות הקשורות להפצת תוכנה.
3. כל מה שקשור לביצוע אוטומטי של פעולות - באופן כללי.
להלן מספר נקודות למחשבה בהגדרת דרישות מכלי בתחום זה:
1. טיפול בהתקנה של תוכנה כולל מערכת הפעלה, PATCHES, ואפליקציות באמצעות
• הגדרה וניהול של IMAGES
• הגדרה וניהול של קבצי התקנה באמצעות סקריפטים
• לאיזה רכיבים יודע להתחבר לדוגמה, אחסון, רשת, שינוי סיסמאות (דוגמה לא טריוויאלית -"דרישה לשינוי סיסמה מ- 6 ל- 7 תווים" כיצד הכלי מאתר את הרכיבים שדורשים שינוי ומבצע זאת).
2. מידת האוטמציה שהכלים מספקים מבחינת השימוש ב- Workflow. עד כמה עשירה אופציית ה- Workflow בכלי והאם היא ממומשת באמצעות SCRIPTS או באמצעות API. לדוגמה, ישנם כלים שמאפשרים ל-device להרשם כ-"מנוי" ל- policy מסויים ואז כאשר מבצעים את ה- policy כל המנויים עוברים את השינוי \ בדיקה. ואז נשאלת השאלה אם ניתן להיות מנויים לכמה policies ומה קורה אם יש התנגשויות. מבחינת האוטומציה צריך לבדוק איך מבצעים בדיקה של הלוגיקה שלא על הציוד עצמו (קל יותר לבצע דרך API). כמובן האם ניתן להשתמש ב"שגרות" בבניית ה- workflow. טיפול בשגיאות וביצוע rollback לכל התהליך.
3. עד כמה יש בכלי מידע על התנהגות של חבילות תוכנה מבחינת כיצד יש לבצע התקנה או PATHES בחבילה עם התייחסות ליחסי התלויות השונים בחבילה זו (לדוגמה, כלי שיודע לגבי חבילת SAP מה וכיצד יש להתקין). ניתן לתאר תכונה זו כ- application logic.
4. אפשרות לבצע משימות AD HOC -(כלומר שלא כ- SCRIPT שמופץ פעם בתקופת זמן) לדוגמה - שינוי משתני מערכת של שרת דרך ה- console של הכלי. בתכונה זו חשוב לשים לב לבחור כלי שמאפשר ביצוע פעולות כאלו ישירות ולא על ידי הגדרה של SCRIPT שמבצע את הפעולה המדוייקת שרוצים ואז הרצתו של אותו SCRIPT בשרת המיועד. מצד שני כן צריכים אפשרות לצור SCRIPTS כאלו.
5. סריקה של הקונפיגורציה של השרת והחלטה האם הקונפיגורציה עונה על הנדרש (מגדירים מראש כיצד נראת חוקים לקונפיגורציה של שרת רצוי). במידה והכלי מגלה שיש סטייה ממצב רצוי יש שתי אפשרויות. אפשרות אחת היא לדווח. אפשרות שנייה היא שהכלי מתקן בעצמו את המצב. (מדובר גם על אפליקציות וגם על סיסטם).
6. עבודה בסביבה וירטואלית- עד כמה הכלי יודע לעבוד בסביבה וירטואלית.
7. טיפול אוטומטי במקרים של עומסים - עד כמה הכלי יודע במידה ויש עומס להתקין שרת נוסף ולהפעיל אותו או לנייד משאבים \ אפליקציה משרת אחר.
8. מטריצת קונפיגורציה ותלויות - כיצד הכלי שומר מידע על התלויות השונות בין רכיבי מערכת המידע - הרכיבים הפיזיים, הרכבים הלוגיים. האם ניתן לקבל את מטריצת התלויות ממקורות אחרים (שכבר קיימים בארגון), האם הכלי מייצר בעצמו מטריצה זו והאם המטרציה משתנה עם הפעולה של הכלי. במחשבה שנייה מדובר על "מיני CMDB" . ונשאלת השאלה האם הכלי ידע להתממשק ל- CMDB אחר.
9. האם המטריצה שהוזכרה קודם מסייעת לארגון (בצורה אוטומטית עד כמה שניתן) לבנות את הסביבה מחדש במקרה של הפעלת מצב של DRP
10. טיפול ב- patches. הכלי אמור לקבל מידע מ(כמה שיותר) ספקים לגבי PATCHES שקיימים למוצרים שלהם ואז על פי המידע שקיים בכלי , הכלי בעצמו מקבל החלטה איפה (אם בכלל) צריך להתקין את ה- PATCHES כולל כל התלויות של אותם PATCHES.
11. עבודה של הכלי על מספר אתרים פיזיים - כולל תאום פעולות בין אתרים.
12. דוחות של הכלי - גם לגבי משאבים, ניצולום ועמידה בתקנים.
13. אבטחת מידע ובדיקות- מי יכול לתת איזה הוראה על איזה שרתים וגם באיזה שלב מבצעים איזה סוג של בדיקה.
14. קשר עם מערכות בארגון - לדוגמה השו"ב.
אלו כאמור נקודות למחשבה כאשר בוחנים כלים בתחום זה.
בתחום זה חשוב באופן ספציפי להגדיר "מה רוצים" כשבגדול הקטגוריות של המטרות האפשריות של הכלי הן:
1. גילוי וזיהוי של מה שיש (כולל קשרים) ללא ביצוע פעולות.
2. ביצוע אוטומטי של פעולות הקשורות להפצת תוכנה.
3. כל מה שקשור לביצוע אוטומטי של פעולות - באופן כללי.
להלן מספר נקודות למחשבה בהגדרת דרישות מכלי בתחום זה:
1. טיפול בהתקנה של תוכנה כולל מערכת הפעלה, PATCHES, ואפליקציות באמצעות
• הגדרה וניהול של IMAGES
• הגדרה וניהול של קבצי התקנה באמצעות סקריפטים
• לאיזה רכיבים יודע להתחבר לדוגמה, אחסון, רשת, שינוי סיסמאות (דוגמה לא טריוויאלית -"דרישה לשינוי סיסמה מ- 6 ל- 7 תווים" כיצד הכלי מאתר את הרכיבים שדורשים שינוי ומבצע זאת).
2. מידת האוטמציה שהכלים מספקים מבחינת השימוש ב- Workflow. עד כמה עשירה אופציית ה- Workflow בכלי והאם היא ממומשת באמצעות SCRIPTS או באמצעות API. לדוגמה, ישנם כלים שמאפשרים ל-device להרשם כ-"מנוי" ל- policy מסויים ואז כאשר מבצעים את ה- policy כל המנויים עוברים את השינוי \ בדיקה. ואז נשאלת השאלה אם ניתן להיות מנויים לכמה policies ומה קורה אם יש התנגשויות. מבחינת האוטומציה צריך לבדוק איך מבצעים בדיקה של הלוגיקה שלא על הציוד עצמו (קל יותר לבצע דרך API). כמובן האם ניתן להשתמש ב"שגרות" בבניית ה- workflow. טיפול בשגיאות וביצוע rollback לכל התהליך.
3. עד כמה יש בכלי מידע על התנהגות של חבילות תוכנה מבחינת כיצד יש לבצע התקנה או PATHES בחבילה עם התייחסות ליחסי התלויות השונים בחבילה זו (לדוגמה, כלי שיודע לגבי חבילת SAP מה וכיצד יש להתקין). ניתן לתאר תכונה זו כ- application logic.
4. אפשרות לבצע משימות AD HOC -(כלומר שלא כ- SCRIPT שמופץ פעם בתקופת זמן) לדוגמה - שינוי משתני מערכת של שרת דרך ה- console של הכלי. בתכונה זו חשוב לשים לב לבחור כלי שמאפשר ביצוע פעולות כאלו ישירות ולא על ידי הגדרה של SCRIPT שמבצע את הפעולה המדוייקת שרוצים ואז הרצתו של אותו SCRIPT בשרת המיועד. מצד שני כן צריכים אפשרות לצור SCRIPTS כאלו.
5. סריקה של הקונפיגורציה של השרת והחלטה האם הקונפיגורציה עונה על הנדרש (מגדירים מראש כיצד נראת חוקים לקונפיגורציה של שרת רצוי). במידה והכלי מגלה שיש סטייה ממצב רצוי יש שתי אפשרויות. אפשרות אחת היא לדווח. אפשרות שנייה היא שהכלי מתקן בעצמו את המצב. (מדובר גם על אפליקציות וגם על סיסטם).
6. עבודה בסביבה וירטואלית- עד כמה הכלי יודע לעבוד בסביבה וירטואלית.
7. טיפול אוטומטי במקרים של עומסים - עד כמה הכלי יודע במידה ויש עומס להתקין שרת נוסף ולהפעיל אותו או לנייד משאבים \ אפליקציה משרת אחר.
8. מטריצת קונפיגורציה ותלויות - כיצד הכלי שומר מידע על התלויות השונות בין רכיבי מערכת המידע - הרכיבים הפיזיים, הרכבים הלוגיים. האם ניתן לקבל את מטריצת התלויות ממקורות אחרים (שכבר קיימים בארגון), האם הכלי מייצר בעצמו מטריצה זו והאם המטרציה משתנה עם הפעולה של הכלי. במחשבה שנייה מדובר על "מיני CMDB" . ונשאלת השאלה האם הכלי ידע להתממשק ל- CMDB אחר.
9. האם המטריצה שהוזכרה קודם מסייעת לארגון (בצורה אוטומטית עד כמה שניתן) לבנות את הסביבה מחדש במקרה של הפעלת מצב של DRP
10. טיפול ב- patches. הכלי אמור לקבל מידע מ(כמה שיותר) ספקים לגבי PATCHES שקיימים למוצרים שלהם ואז על פי המידע שקיים בכלי , הכלי בעצמו מקבל החלטה איפה (אם בכלל) צריך להתקין את ה- PATCHES כולל כל התלויות של אותם PATCHES.
11. עבודה של הכלי על מספר אתרים פיזיים - כולל תאום פעולות בין אתרים.
12. דוחות של הכלי - גם לגבי משאבים, ניצולום ועמידה בתקנים.
13. אבטחת מידע ובדיקות- מי יכול לתת איזה הוראה על איזה שרתים וגם באיזה שלב מבצעים איזה סוג של בדיקה.
14. קשר עם מערכות בארגון - לדוגמה השו"ב.
אלו כאמור נקודות למחשבה כאשר בוחנים כלים בתחום זה.
אין תגובות:
הוסף רשומת תגובה