עוד על סביבות פיתוח ובדיקה Testing enviroments

ישנם מספר מופעים של כל סביבה (פיתוח למפתחים, סביבת פיתוח אינטגרטיבית למפתחים, סביבות בדיקה, סביבת pre-prod וסביבות ייצור) בייחוד למפתחים. נניח שבארגון מסויים המערכת שנמצאת בייצור היא בגרסה 200. המערכת שנמצאת בבדיקות היא בגרסה 201. המערכת עליה עובדים המפתחים היא כבר גרסה 202. אבל מובן שלמפתחים צריך שיהיו עותקים גם של 200 (למקרה של תקלות בייצור) וגם של 201 (למקרה של תקלות בגרסה שנמצאת ב- QA).
ל- QA שעובדים על גרסה 201 יש גם עותק של גרסה 200 וזאת בכדי שיוכלו לאשר תיקונים בייצור.

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



סוגי הפעולות של צוות סביבות
1. Setup – בניה של סביבה חדשה. מתבצע לפי Check list. דברים כגון שרתים, אחסון DBA, middleware. אבטחת מידע ופיתוח.
2. שדרוגים :
a. שדרוגים תשתיתיים על פי checklists או scripts ידועים של אוטומציה
b. שדרוגי תוכנה- כלים או ידנית
3. Data Refresh –
a. Full - דרך clone, ומיסוך (משכורות, סיסמאות)
b. SUBSET או שיש הפצה מרובת סביבות. בונים master (כלומר מייצרים מדגם) , מרעננים ומפיצים לכולם (העתקה ממש ולא SNAPS) .בד"כ מבצעים העתקות בפועל – לא משתמשים ב- SNAPS
c. Direct – לוקחים נתונים מייצור בפועל. בכדי לבדוק בעיה.

הכלים לביצוע משימות ה- Refresh הם: ETL, refresh scripts - ובכלים – כמו Optim (כיום של IBM ) או Brilix שמבצעים גזירות ו- SUBSET.

מדיניות הפצת patches בארגונים

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

כמובן שגיליתי שונות גדולה. ישנם ארגונים שבהם אין מדיניות לבין ארגונים שבהם יש מדיניות וכללים ברורים.

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

הדבר המרכזי הוא שלא נוגעים בשרתים ללא מעבר ב"פורום שינויים" שמתקיים ביום ה'. בפורום שותפים גם נציגים של היישומים השונים.

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

אחת לשבועיים עושים פורום אבטחת מידע ומחליטים אם להפיץ מייד או לחכות.

על שרתים חשובים מבצעים זאת:

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

באחריות חדר התפעול לוודא שהאחראי האפליקטיבי ביצע את הבדיקה (לעיתים מהבית).  

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

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

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

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

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

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

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

תמונת המצב של ניהול שינויים

להלן תמונת המצב של ניהול שינויים בישראל אצל ארגונים מובילים. בעקרון, מי שאחראי על השינוי ועל הפצת התוכנה שנגזרת ממנו הוא מנהל הפרוייקט. מעבר לכך בארגון נמצא בדרך כלל גם מנהל השינויים שהוא גוף שאחראי על כל השינויים גם יחד (לעיתים הוא גם מנהל התפעול). מנהל הפרוייקט דואג לביצוע כל הבדיקות הנדרשות (QA כולל load test אם נדרש) ודואג לכל האישורים הנדרשים (אבטחת מידע...). ישנו טופס של השינוי שכולל את הדרישות מכל מי שמעורב בשינוי. לדוגמה, להחליף את ה- DLL אצל המשתמשים מסוג X ולפתוח את הפורט הספציפי ב- FW וכד'. לעיתים הטופס הוא ידני ולעיתים ממוחשב ברמה כזו או אחרת. לדוגמה, לעיתים הצהרה על "דרגת סיכון" של השינוי. ואז ה- flow של הטופס משתנה. אחד הנושאים שמטופלים בטופס הוא סיטואציה של roll-back במידה והשינוי לא מצליח. יש לציין שחלק אינטגרלי מהטיפול בשינוי הוא צוות השליטה והבקרה שצריך לדאוג לכך שה- agents יותקנו עם ספים מתאימים ושהתמונה העסקית שמתקבלת בקונסול רלוונטית.
כמו כן מתבצעת בארגון ישיבת שינויים שבועית או פעמיים בשבוע שבה דנים בשינויים שאמורים להתבצע וגם דנים בשינויים שהתבצע קודם ומסיקים מסקנות.
כל השינויים בייצור חייבים לעבור תהליך מסוג זה. זאת תמונת מצב קיימת אצל ארגונים רבים בישראל – אנחנו בטוחים שגם בבנק הפועלים.
סוגיה לא פשוטה שקשורה לסיטואציה זו היא טיפול בתקלות חומרה. תקלות חומרה מחייבות טיפול מיידי ולעיתים מתבצעים שינויים בייצור ללא מילוי של הנוהל וגם לעיתים קשר חומרה מתקלקלת ומחליפים אותה בחומרה זה, ישנה גישה שטוענת ששום דבר לא השתנה ולכן אין מה לדווח מבחינת ניהול שינויים.

טכנולוגיה היא לא תחליף לתהליך

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

ציוד צבאי - ציוד אזרחי

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

קונסולידציה בתחום ה- CMDB

Novell Acquires Managed Objects

WALTHAM, Mass.— 14 Oct 2008— Novell today announced a definitive agreement to acquire the business service management leader Managed Objects. The acquisition will extend Novell's portfolio of data center solutions by adding tools to provide a unified view of all information and workloads. As a result, both IT and business managers will have improved visibility into how their information systems deliver business services across physical and virtual environments, so managers can make better decisions to ensure availability and quality of service while improving agility and lowering the total cost of data center management.

"The acquisition of Managed Objects by Novell illustrates Novell's commitment to an expanded management strategy and makes them a strong competitor in the service management market," said Tim Grieser, program vice president, enterprise system management Software, IDC. "Managed Objects is a recognized player in BSM and has a proven track record with some of the largest companies in the world. With Managed Objects, Novell can more easily have business conversations in the data center with CIO's, line of business managers, and key business stakeholders. This new service management focus represents a step in the right direction for Novell and adds significant credibility to Managed Objects customers that may have had concern about a smaller company."

The Managed Objects products complement and extend Novell's existing workload management and virtualization solutions by adding flexible service modeling, leading Configuration Management Data Base (CMDB) technology, advanced analytics and unique Web 2.0-based visualization technology. Customers can extract IT configuration and workload information in near real-time into a robust CMDB, model how the IT configuration provides business services, and then generate visualizations and dashboards that dynamically show how IT aligns to business services. By providing a single view of data center workloads across any physical or virtual environment, system administrators can understand and respond to issues in a business context reactively, pro-actively, or automatically.

"This acquisition extends Novell's strategy of making IT work as one in the data center," said Joe Wagner, senior vice president of systems and resource management at Novell. "The Managed Objects products are very complementary to our existing management and virtualization capabilities. By adding the Managed Objects toolset to the Novell® portfolio of data center solutions, we are unique in providing technology-agnostic and proven cross-platform solutions that span both the physical and virtual worlds - all in one unified view."

"Novell and Managed Objects are a natural fit because they share a common ideology for openness and vendor neutrality," said Siki Giunta, president and CEO of Managed Objects. "There is very little product overlap and tremendous synergy between the two companies and our respective technology, which is great news for our customers and the market at large."

Acquisition Overview
Novell will acquire Managed Objects for an undisclosed sum using current cash. The acquisition is expected to close during Novell's first fiscal quarter 2009 subject to the satisfaction of closing conditions. Managed Objects will be fully integrated into Novell's Systems and Resource Management business unit.

דוגמה לתהליך ניהול שינויים אצל לקוח מהמגזר הפיננסי

להלן רשמים לגבי תהליך ניהול השינויים אצל לקוח מהמגזר הפיננסי .
ב- MF "העולם יחסית מסודר" – יש טופס שינויים – כולל מעקב אחורה.
לגבי סביבת ה- OPEN, פתחו בארגון מערכת ספציפית מבוססת .net לניהול השינויים ותזמונם בארגון. זאת עקב העובדה שיש בארגון מערכות שעובדות 24 שעות. אחרי הצהריים יש שידורים גיבויים – עובדים 24 שעות. כלומר יש צורך לתאום ההשבתה מבחינת הלו"ז ומימד נוסף הוא התייחסות לגורמים שמעורבים בהשבתה. המשתמשים השונים מה- IT נגשים למערכת דרך ה- outlook – כלומר workflow שעובד דרך outlook. והכל מתועד בתוך מסד נתונים של המערכת. לדוגמה יש תעוד איזה PORTS ב- FW נפתחו בגלל דרישה לאיזה שינוי. הנוהל בארגון הוא שאם יש שינוי טכני –לדוגמה איש תקשורת סגר PORT – הוא חייב לעדכן את מסד הנתונים. זה הנוהל שתבצע באופן עקרוני אבל ישנם מקרים שהגורמים (בדרך כלל הסיסטם) שוכחים לעדכן בגלל עומס. בזמן תהליך השינוי –גם צוות השו"ב מעורב וגם צוות ה- DRP.
ההגדרות במערכת מתבצעות לפני שמכניסים לייצור. ולאחר השינוי ישנו עדכון שהדברים התבצעו. כל זאת גם בכדי להכין את צוות ההפעלה שמגיע בתחילת הבוקר (השינויים מתבצעים בדרך כלל בלילות). לדעת הלקוח, המערכת משקפת את המצב בפועל (מה מותקן על איזה דיסק ועל איזה שרת, איזה PORTS פתוחים ומדוע, וכד') במידה של כ- 97%.
בארגון קיימת מערכת שליטה ובקרה של IBM-מוצר השליטה והבקרה כאשר מערכת ניהול השינויים ( .net ) מעדכנת את ה- מוצר השליטה והבקרה. מתבצע גם עדכון לרמת ה- DRP. נכון להיום יש אפשרות גם ב- מוצר השליטה והבקרה – לבדוק מה תהייה ההשפעה על שינוי\השבתה של רכיב מסוים. הלקוח העיקרי של מוצר השליטה והבקרה \ שו"ב– הוא service desk כאשר יש דגש על כך שלא רוצים להתיש אותם בהרבה הודעות (לא תמיד מסתכלים על הצבעים).
לדוגמה, אם CONTROL-M – נפל ואז מערכת סניפית לא מעודכנת לגמרי ואז ה- מוצר השליטה והבקרה מקבל חיווי ומודיע על הבעיתיות ל- service desk. כל זאת לפני שמתחיל היום וזה מתבצע בגלל המפה העסקית של התהליך שנמצא בשו"ב – מוצר השליטה והבקרה.
גודל צוות השו"ב הוא 3.5 משרה מלאה שלהם.
בסביבת השו"ב יש אפשרות להכניס את המערכת למצב של תחזוקה. וזאת מכיוון שללא פונקציה זו יש בעיה – כאשר עושים שינוי – מקבלים המון חיווים של תקלות. ולכן יש להם אופציה של הכנסת המערכת למצב תחזוקה- ואז לא מקבלים חיווים (כולל שליחת SMS וכד')

ניהול שינויים

להלן רשמים ראשוניים ממפגש שולחן עגול בנושא ניהול שינויים.

התמונה הכללית שעולה היא שארגונים מקיימים תהליך מסודר של ניהול שינויים – תאום השינוי, בדיקה לגבי השפעות השינוי, דרכים לביצוע failback וכד'. אצל רובם של הארגונים התהליך מתבצע באמצעות מערכת ממוכנת.
אולם, אצל רובם המכריע של הארגונים, כל שינוי מתבצע בצורה פרטנית ללא הסתכלות מערכתית וללא הסתכלות על היסטוריה. לכן ישנם מקרים של תקלות בעייתיות – לדוגמה אחד הלקוחות תאר מצב בו הורד קו גיבוי של תקשורת והסתבר שאחת האפליקציות בייצור הפסיקה לעבוד.
בגדול, לקוחות התייחסו ל-4 סוגים של בעיות (חלקן קשורות) במצב הנוכחי:
1. התייחסות למשאבים – אין התייחסות כוללנית למשאבי ה-IT לדוגמה, אין רישום מרכזי של "באיזה שטחי דיסק משתמשת אפליקציה X" או לחילופין "איזה אפליקציות יושבות על דיסק Y". לעיתים מידע זה נמצא אבל בתור יוזמה פרטית \ שיטת ניהול של מנהל המשאב (בדוגמה שציינתי – מנהל האחסון).
2. כאשר ישנה תקלה, קשה לזהות את מקור התקלה כלומר ישנה בעיה של Problem determination או root cause analyses .
3. בעיה שקשורה לבעיה הקודמת – אם מסתמכים על הזנה ידנית של מהות השינויים והקינפוג, טעות או פיספוס בהזנה יגרום לכך שזיהוי תקלה יהיה כמעט בלתי אפשרי. לדוגמה אם מתקינים switch חדש ברשת אבל טועים בהזנת כתובות ה- IP, המשתמשים יעבדו ללא בעיה אבל ברגע של תקלה לא ידעו כלל כיצד להתחיל לטפל כי לא מכירים כלל את כתובות ה- IP.
4. גם אם יש תיעוד של הפרטים הטכניים אצל (לדוגמא) איש האחסון או איש האבטחה, בזמן תקלה לא ניתן להגיע לתיעוד זה ולהשתמש בו.
5. ישנן גם בעיות נוספות שפחות הוזכרו בסיטואציה של ניהול שינויים - capacity planning , עמידה ברגולציה מבחינת רשיונות תוכנה, DRP וכד'.
תחת תמונה זו רצוי לציין לטובה את ה"ארגון הפיננסי" שמופיע לקראת סוף הסיכום, ואשר פיתח מערכת ייחודית לסביבת ה- OPEN שבה ישנו רישום כולל של כל המאפיינים הנדרשים של "עץ המערכות" בארגון עם workflow מלא לביצוע השינויים האפליקטיביים והתשתיתיים. בארגון מתקדם זה כל השינויים נרשמים ונשמרים במקום אחד.
לקוחות רבים מצפים להטמעה של סביבת CMDB אשר גם תנהל את השינויים בצורה אחודה וגם תוודא את ביצוע השינויים. לדוגמה, אם מחליטים לפתוח PORT ב- FireWall מסוים, השינוי יופיע במערכת ולאחר מכן המערכת תוודא שהשינוי אכן התבצע כאשר התועלת העקרית שלקוחות מצפים מסביבת CMDB היא שבזמן תקלה ניתן יהיה בקלות לאתר את המקור.