מתי לבצע בדיקות רגרסיה

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

איזה גודל?

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

גיבוי על דיסק ו- VTL

מטרות גיבוי על דיסק כפי שעולה משיחות עם לקוחות הן:
1. גיבוי מהיר יותר. מסתבר שזו מטרה שלא תמיד מסתייעת. הסיבה לכך היא שנכון להיום רובוטים\טייפים מאוד מהירים וגם מאפשרים multiplexing דבר שלא מתבצע בד"כ בסביבת גיבוי לדיסק וכנראה שלא בסביבה של dedup. לקוחות דיברו על כך שהם התפלאו שגיבוי על דיסק היה יותר איטי מגיבוי על קלטות ורק כאשר פירמטו את הדיסק מחדש ב- stripping הכי נרחב – אז קיבלו ביצועים טובים מספיק.
2. שחזור מהיר יותר ואמין יותר – זאת מטרה שמצליחה ראלית. גם מהירות מבחינת השחזור וגם אמינות לעומת קלטות שמתקלקלות.
3. לחסוך שינוע קלטות. לקוחות מרפלקים סביבת VTL אחת לשנייה וכך מכפילים "קלטות" ללא צורך בשינוע פיזי.
4. דחייה של שדרוג\השקעה ברובוטים.
5. תפעול נוח יותר –נראה שזו מטרה ראלית.

כמו כן, לקוחות ציינו שכאשר משתמשים בדיסק בתור VTL הוא "מאבד" את חלק מתכונות שלו – לדוגמה, בזמן שמרפלקים ספרייה אחת לשנייה (דבר די גדול) – הכל נעול ולא ניתן לבצע כלום (כולל המשך גיבוי). כמו כן בזמן שמבצעים העתקה מקלטת על דיסק לקלטת פיזית גם יש נעילה של חלקים נרחבים של המערכת. כמו כן לקוחות דיברו על כל שהיו מקרים שבהם "נגעו" בקלטות וירטואליות בטעות (או לא בטעות) – העבירו "קלטות" מ- LUN אחד לשני או ניתקו LUN ועליו קלטות ולאחר מכן חיברו מחדש והסתבר שתוכנת הגיבוי לא מצליחה לזהות את הקלטות הוירטואלית.
נקודה נוספת היא שלא תמיד חושבים על עלות החשמל\מיזוג של פתרון גיבוי על דיסק לעומת קלטות.
לגבי יחסים של dedup מה שלקוחות מציינים הם יחסים של החל מ- 1 ל- 20 יותר אבל גם פחות. אם מדיניות הגיבוי הראשונית הייתה גיבוי אינקרמנטלי אז מצליחים פחות לדחוס. לקוח שעבר ל- dedup מגיבוי אינקרמנטלי דיבר על דחיסה של 1 ל- 7 בלבד (גם זה מספר לא מבוטל).
נקודה נוספת היא שלא כל האפליקציות נתמכות – לדוגמה לא כל הפתרונות תומכים ב- Exchange .

לסיכום, גיבוי על דיסק, VTL ו- DEDUP הן טכנולוגיות מבטיחות אולם מבחינת בשלות אנו נמצאים בתחילת שלב הבשלות.

טווח קצר - טווח ארוך

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

מה לקוחות רוצים - חלק ה'

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

מה לקוחות רוצים - חלק ד'

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

מה לקוחות רוצים - חלק ג'

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

הלבן של העיניים

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

תרבות ארגונית או לא

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

סטנדרטיזציה היא ביזבוז?!

אחת המגמות הרווחות בתעשייה היא מגמה של סטנדרטיזציה וקומודטיזציה. ממצב שבו פתרונות Proprietary היו הדומיננטיים ביותר בקרב ארגוני ה- IT כיום מדובר על כך שאבני הבניין הפכו להיות "לגו של קומודטי" - הן מבחינת חומרה של והן מבחינת תוכנה. לקוחות מסתמכים על שרתי Intel-AMD, תוכנות מסדי נתונים סטנדרטיות בארגון ( Oracle או MSSQL) , תחנות קצה סטנדרטיות, תוכנות ייעודיות לצרכים שונים שהנן סטנדרטיות ועוד ועוד.
אולם, כפי שציין ד"ר ג'ימי שוורצקופף בהרצאה לפני לקוחות, לקומודטיזציה\סטנדרטיזציה מתווסף גם לעיתים מימד שלילי - ביזבוז ברכש וביזבוז בניהול. עקב העובדה שמוצרי הקומודטי נמצאים בארגון בכמות גדולה, ישנה נטייה לבצע רכש מיותר של פריטים רבים. במקום לרכוש את מספר רשיונות התוכנה שצריך כעת, נוטים רבים לבצע רכש "קצת יותר" גדול כי נוטים לחשוב כי בקרוב יהיה שימוש באותם רשיונות, הספק מנסה להגדיל קצת את העסקה ונותן כמות גדולה יותר וגם כי ישנה התיקווה לחסוך את הלוגיסטיקה של רכש נוסף. כנ"ל לגבי רכיבי חומרה שונים. התוצאה היא שארגונים עלולים ל"התקע" עם ציודים או רשיונות שאינם בשימוש - כל זאת בעקבות הסטנדרטיזציה. אם היה מתבצע רכש של רכיבים שאינם סטנדרטים, הרכש היה שמרני ומדוייק יותר.
אנו ממליצים ללקוחות, בייחוד בימים אלה לבצע רכש מדוייק גם של רכיבים המוגדרים כקומודטי.

מה לקוחות רוצים - חלק ב'

בהמשך לרשימה הקודמת, לקוחות גם הזכירו סוגייה של טיפול בסביבות.
מעבר לסביבת הייצור של כל מערכת ארגוני התשתיות נדרשים לספק סביבות רבות נוספות: סביבת פיתוח, סביבות בדיקות, סביבת אינטגרציה, סביבת trainning ועוד ועוד.
הדבר מורכב יותר ממה שנראה בתחילה וזאת מכיוון שהיום למערכות רבות קשרים מהותיים אחת עם השנייה ואז מסתבר שיש צורך לשכפל מערכות רבות.
אם ישנו פיתוח במערכת א', אך מערכת זו עובדת צמוד למול מערכות ב', ג' ו-ד', אז צוות התשתיות צריך להכין לטובת הפיתוח גם את מערכות ב' עד ד'.
במקביל, אם מתרחש גם פיתוח במערכת ב', הרי גם היא צריכה סביבה את מערכות א', ג' ו-ד' ובצורה נפרדת כי חייבים לשמור על סביבות יציבות (כלומר מערכת ב' לא יכולה לבצע בדיקות מול מה שמפותח כעת במערכת א').
חשבון מראה שמדובר בבעיה אקספוננציאלית. במקרה שהוזכר כאן צריכים 8 מערכות כפול מספר השלבים (פילוח, בדיקות, אינטגרציה, trainning ) כלומר 32 סביבות!
מבחינת האחסון ישנם כבר פתרונות שמאפשרים שימוש בשטחי אחסון קטנים יותר (לצערנו אחד הפתרונות הטובים בשוק נסגר בשבוע זה...) .
חברת VMWARE מספקת פתרון מעבר לאחסון אולם פתרון זה מטפל בסביבות שיכולות להשען על פלטפורמת ה- VMWARE.
בכל מקרה, לקוחות מדברים על כך שמדובר בסוגייה מטרידה שגוזלת זמן רב ומשאבים יקרים.

מה לקוחות רוצים - חלק א'

בתאריך 24 למרץ יתקיים הכנס השנתי של STKI. אנחנו נמצאים בעיצומן של ההכנות לכנס כאשר אחד המימדים החשובים בהכנות הוא ביצוע סקר מקיף אצל מנהלים בארגוני ה- IT. כחלק מהסקר אני מנסה לברר "מה לקוחות רוצים". איזה סוגייה מטרידה אותם או יכולה להקל עליהם משמעותית. אני מגדיר זאת כ- Wish List. ברשימה זו וברשימות נוספות, אתן דגשים בולטים ל- With List שעלו בסקרים.
סוגייה מאוד בולטת שהזכירו לקוחות היא "תמיכה לאחור". לקוחות טוענים שחברות חומרה ותוכנה (לייתר דיוק - בעיקר תוכנה) אינן תומכות לאחור מספיק זמן בפתרונות שלהם. ולכן הארגונים לאחר שהשקיעו זמן רב ומאמצים בפיתוח ידע ותשתיות נדרשים להשקעה כבירה בהסבות לטכנולוגיה חדשה. הדבר הוגדר כ"ביזבוז נוראי" וכ"זילזול בלקוחות". רוב הפידבקים דנים בתוכנה אולם לעיתים ישנה הפסקה בתמיכה גם בחומרה. לדוגמה, באחת מחומרות ה- Legacy הידועות, ישנה הפסקה של תמיכה בחלק מפקודות המכונה. דבר בעייתי ביותר שמחייב עדכון ובעיקר בדיקות של תוכנות רבות (במוסדות פיננסים מדובר על עשרות אלפי תוכניות).

אגב, מעניין עם תחום ה- Open Source מקבל בצורה משמעותית על סוגייה בעייתית זו.

שנינו ביחד וכל אחד לחוד

ברצוני להבהיר הבהרה לגבי התחום המתפתח במהירות של Cloud Computing ו- SAAS.
למרות שישנם שירותים רבים שניתנים ב- Cloud ישנה אבחנה חדה לגבי צורת מסירת השירות.
ניתן לחלק את השירותים ל- Multi -Tanent לעומת Single-Tanant.
השירותים שניתנים כ- Single-Tananet הנם שירותים אשר כל מקבל שירות נהנה מסביבה מלאה שהינה שלו. שרת אפליקציה, שרת נתונים וכד' כולם ב- instance ייעודי בשבילו (בדרך כלל וירטואלי).
השירותים שניתנים כ-Multi-Tananet הנם שירותים שניתנים תחת תשתית אחידה לכל המשתמשים יחדיו. השירות הידוע מכולם הנו כמובן Salesforce.com .
ישנן משמעויות רבות להבדל בין הצורות השונות. לדוגמה, ב- Multi-Tananet שכאשר ישנו הצורך לשנות את האפליקציה, השינוי מתבצע פעם אחת וכולם נהנים ממנו. זאת לעומת שב- Single-Tananet יש להפיץ את השינוי בין כל הסביבות של כל המשתמשים. מצד שני, Singel-Tanent מאפשר שימוש בגרסאות שונות של השירות בין משתמשים שונים לעומת Multi-Tananet שמחייב אחידות.
אין ספק שלב ליבו של הענן מכוון ל- Multi-Tananet כי רק בתצורה כזו ניתן להגיע גם לחסכון תשתיתי מדהים. אולם נכון להיום ישנם מספר לא קטן של ספקי שירות אשר "שכפלו" מוצרים רגילים לתוך סביבת הענן ולכן הם באים בתצורה של Single-Tanant.

סוגיות רישוי תוכנה בסביבת שרתים וירטואלית

אין ספק שוירטואליזציה של שרתים היא אולי הטכנולוגיה שמשפיעה הכי הרבה על גופי התשתיות בארץ ובעולם. וירטואליקציה של שרתים חוסכת מקום, חשמל-מיזוג, מקילה על תפעול, מעלה זמינות ועוד ועוד. כמובן שהיא גם מעלה מספר סוגיות הן טכנולוגיות והן מבחינת רישוי תוכנה.
לאחרונה פנו מספר לקוחות בנושא רישוי תוכנה כאשר אחת מהשאלות הייתה האם סוגיית הרישוי שונה או זהה בין הפתרונות
השונים - VMWARE לבין HyperV של מיקרוסופט לבין XenServer של Citrix ואחרים.
ובכן באופן בסיסי התשובה היא כן. סוגיית הרישוי היא זהה בין כל הפתרונות שהוזכרו. כלומר מספר הרשיונות שצריך לרכוש לסביבת הGuest השונות -מערכת הפעלה ותוכנות נוספות, הנו זהה בלי קשר לתשתית הוירטואליזציה שבוחרים.
הסוגיות מובאות בהרחבה הן באתר מיקרוסופט שדן ברישוי Win Server 2008 ובאתר נוסף של מיקרוסופט (שאלות ותשובות) והן באתר VMWARE .
אני אמשיך לעקוב ולעדכן אחר סוגייה זו.

פיספוס בהטמעה ושיווק של SOA

כאשר דנים בארגונים על SOA, קהל היעד הטבעי הוא מנהלי פרוייקטי הפיתוח והארכיטקטים הארגוניים. מנהלי הפרוייקטים והארכיטקטים הם שקובעים את מבנה האפליקציות וסוג השירותים הנדרש.
אולם, ישנו קהל יעד אחד שלדעתי מפוספס לגמרי בדיון על SOA - גוף מנהלי הפרוייקטים בארגונים, גוף שנקרא גם Office of the CIO או ה- PMO - Project Management Office.
למרות שגוף זה אינו טכני במהותי, תפקידו הוא לדאוג לכמה שיותר פרוייקטים להתבצע על הצד הטוב ביותר. ולכן Reuse שמתקבל על ידי SOA ו- Composite Applications יתקבל בברכה על ידי מנהלים ב- PMO, מנהלים שאחראים על תקציב, תעדוף וכד' - פונקציה קריטית לכל הדעות בארגון.
לדעתי, ברוב רובם של הארגונים, גופים אלו כלל לא נמצאים ב- SOA loop וחובה על המנהלים הבכירים וגם על הספקים בתחום לפנות גם לגופים אלו.