יצרני תוכנה מתקשים לשחרר תוכנות וגרסאות יציבות, ונראה שהארגונים שרוכשים אותן מתקשים לאתר את הבעיות מבעוד מועד. כך קורה שיצרן התוכנה מאבד לקוחות בעוד ארגונים רבים משלמים על רישיונות למוצרים שלא מוטמעים. עיקר הבעיה נובע מסביבת הבדיקות הסטרילית, בה משתמש גם יצרן התוכנה וגם הארגון שרוכש אותה. אז איך מעבדת הבדיקות צריכה להראות? הנה תרחיש אפשרי המתואר מהעניים של מנשה, רוכש המוצר, ודני, מפתח המוצר.
מנשה הוא מנהל תשתיות ו- IT בארגון פיננסי שמעוניין להטמיע מוצר אבטחה, סוג של אנטי-וירוס שיהווה שכבת הגנה נוספת נגד תקיפות מתקדמות. הוא בוחן פתרון של חברת הזנק מבטיחה ומוכרת.
דני הוא מנהל המו"פ בחברת הזנק שמפתחת פתרון XDR ("אנטי-וירוס") מבטיח וחדשני - נקרא לו AgenTWO. תהליך ההטמעה של Two כולל הפצת Agent לתחנות הקצה. בשרת ניתן להגדיר Port Mirroring, על מנת לנטר את תעבורת הרשת לצורך זיהוי התנהגויות חשודות.
גם למנשה וגם לדני בעיה דומה: שניהם לא יודעים מהי מידת הבשלות של TWO וכיצד לבחון אותה. כלומר: האם TWO מוצר יציב? כיצד הוא יתנהג ברשת הארגונית של הבנק (סביבת ה- Production)? כתוצאה מכך הם מתמקדים בבדיקת הפונקציונאליות של המוצר שדווקא מצליח להרשים.
TWO באמת מהווה את חוד החנית בכל הקשור לזיהוי וחסימת תקיפות, וכך גם הראו ממצאי בדיקת הבנק במעבדת החדשנות שלו. אבל בכול הקשור ליציבות, בעיות ביצועים ארעיות, מנגנון ההפצה ברשת, עדכוני הגרסאות, התממשקות ל- Active Directory ומעבר לכך, ל- TWO יש עוד דרך ארוכה לעשות. מנשה לא יודע זאת וגם לדני אין כלים כל כך טובים לבחון בעיות שכאלו!
למען האמת, דני יודע שהמוצר שלו רווי תקלות, כמו כל מוצר פחות או יותר, לא? מה גם שכל סביבת Production שונה ואין לדעת בוודאות שיהיו בעיות בהטמעה הספציפית הזאת. את ה- PoC הוא עבר בשלום, וגם למתחרים יש מלא באגים.
?באגים – גורל או מציאות שמזמינים אותה
במציאות של היום זה דיי סטנדרטי שמוצרים מציגים לא רק שלל יכולות מבטיחות אלא גם מכלול באגים "מרשים". כולם נמצאים במרוץ אחרי ה- Feature או ה- Capability הבא, ומדדי היציבות נדחקים אל מעבר לפינה. כך קורה ש- TWO כמו מתחריו, הוא קורבן של המרוץ נגד הזמן ונגד התחרות. המתחרים מתהדרים בסט יכולות פנטסטי שאינו בהכרח בנמצא, ובדומה ל- TWO, בונים סביבות הדגמה מבטיחות, שלא בהכרח מייצגות את סביבות ה- Production בהן המוצר עתיד להיטמע.
הנה, בחודש שעבר מיקרוסופט הסירה מהמדפים מספר משפחות מוצרים שהשיקה רק יומיים לפני כן, לרבות Windows Server 2019 ו- Windows 10 1809 (הכתבה המלאה כאן). זאת בשל באגים קריטיים. אוי לבושה. אז מה כבר אפשר לצפות מחברת סטארטאפ? או שאולי ההיפך הוא הנכון? אולי דווקא חברת סטארטאפ צריכה להצטיין במדדי היציבות, מהסיבה שאין לה את הפריבילגיה לעשות פדיחות כפי שמוביל שוק יכול להרשות לעצמו לעשות?
מדוע דני לא מתקן את המוצר שלו מבעוד מועד? יש לכך מספר סיבות: בין אם בשל מחסור בכוח אדם איכותי, לבין אם מדובר בתעדוף של גוף ה- Product לבין אם לנוכח התרבות הארגונית (הקלוקלת?) שמודדת בעיקר השקת מאפיינים חדשים ופחות יציבות. בסופו של יום, דני לא מצליח להביא את המוצר לבשלות הנדרשת. גרסאות חדשות יוצאות על בסיס שבועי. תיקוני באגים מביאים בצידם באגים חדשים, שלא לדבר על עדכוני גרסה שמספקים Features חדשים, המלווים בשלל קונפליקטים ותקלות.
במציאות התחרותית והאינטנסיבית, אין לדני את הפריבילגיה, המשאבים או הכוח הפוליטי על מנת לעשות את הטרנספורמציה המוצרית והארגונית, שתהפוך את TWO למוצר יציב ובשל. לכאורה מיקוד ביציבות יבוא בסופו של דבר על חשבון משאבים שמוקצים לפיתוחים חדשים, ודני חייב לעמוד ב- Roadmap המוצרי האגרסיבי. שהרי החברה הצהירה שבכנס RSA הקרב ובא, היא תשיק את הגרסה החדשה ובה שלל יכולות חדשות שעדיין אינן קיימות בשוק! הלקוחות האסטרטגיים מצפים לכך וכך גם המשקיעים.
מעבדת הבדיקות – ההצלחה וציר הזמן
הצלחת TWO במעבדת הבדיקות תהפוך את מנשה לקורבן של מוצר שעתיד להביא לתקלות אין-ספור. אמנם TWO עקף את המתחרים ב- Detection Rate, הציג יכולות Remediation, ואפילו ממשק פורנזיקה שמאפשר להתחקות אחר התוקף ופעולותיו על פני ציר זמן ויזואלי מרשים, אך כאן תיגמר ההצלחה. קריסות של TWO או כישלון בחסימת תקיפות (בשל תקלות מוצר) יהוו את החלק הקל. ה- Agent של TWO מקבל הרשאות System ונמצא ב- Kernel, כך שבאופן טבעי, הוא לא רק מגן אלא גם מסכן. מסכים כחולים יקריסו התחנות, בעיות ביצועים ארעיות, וקונפליקטים עם מוצרים קיימים יובילו להתנהגויות תוכנה מורכבות ולקריאות שירות רבות. התסריט הגרוע ביותר כבר קרה בעבר, והוא קריסת רשת ארגונית שלמה, בשל תקלה במנגנון ה- Port Mirroring. אוי.
בחודשים הקרובים מנשה ומחלקת ה- IT/תשתיות של הבנק, ישקיעו משאבים רבים בהתקנת והטמעת TWO, בהפצתו ל- Endpoints, בתמיכה, בעדכוני באגים, ולאחר מכן בהסרת המוצר ובהמשך התשלום עבור License ל- 3 שנים.
מתקינים ומתפללים
האם המציאות הזאת היא גזירה משמים? בעבר מנשה נקט באסטרטגיית "מתקינים ומתפללים". האם זה כי מנשה חובבן? או שמא מדובר ב- Best Practices? האם מונחות אופציות אחרות על השולחן?
כן, מנשה ביצע בדיקות במעבדת החדשנות של הבנק. מדובר בסביבת סימולציה וירטואלית מבוססת VMWare Workstation, שהוקמה במיוחד למטרה זו. סביבה דומה קיימת גם אצל דני, אם כי אצלו המכונות רצות דווקא על שרת Hyper-V. בכול מקרה, הבעיה היא לא ה- hypervisor.
?מדוע סביבת הבדיקות לא מספקת
כיוון שבניגוד לסביבת הבדיקות הסטרילית, בסביבת ה- Production מותקנים אלפי שרתים, ובתחנות השונות מותקנות עשרות תוכנות, סימולטנית. הפער בין המעבדה הסטרילית לסביבת ה- Production מביא לכך שמעבדת החדשנות כושלת במילוי תפקידן, ואינן חושפת את חוסר הבשלות של מוצרים רבים. היבטי ביצועים אינם מנוטרים, תקלות שקשורות בפריסת המוצר לא נחשפות שכן תהליך ההפצה לא נבחן כלל ובטח שלא ב- Scale גדול. גם ה- Port Mirroring שבעבר גרר קריסה של רשת ארגונית שלמה לא נבחן וכנ"ל לגבי מנגנון ה- Update. מסכים כחולים או קונפליקטים קריטיים לא הופיעו בבדיקה, שכן שכיחותם "נמוכה" ובסביבה הסטרילית לא נמצאים הטריגרים הרלוונטיים.
הן מנשה והן דני התכוננו היטב לסט הבדיקות שתואם מראש: לאילו פורטים TWO, פונה, כמה תעבורה הוא מייצר, תכולת התעבורה ש- TWO מוציא מהארגון, האם היא מוצפנת, האם הקוד מאובטח וכמובן – האם המוצר מבצע את מה שהוא מיועד לו? למען האמת, כאשר מנשה פנה ל- TWO, כבר עם תחילת ההתקשרות, הוא קיבל מסמך שמגדיר את תהליך ה- PoC (Proof of Concept), שם הוצגו ה- Best Practices של הבדיקות.
סט בדיקות שלם התפספס
בעיות הפצה ב- Scale גדול שגוררת קריסה של השרת או סתימה של תעבורת הרשת, אינטגרציה לקויה עם Active Directory, מנגנון ה- Update שגורר חור אבטחה חמור, מסכים כחולים, צריכת 100% של CPU Core ללא צורך, ושלל באגים וקונפליקטים עם מוצרים קיימים - יגררו קריאות Support אינספור.
אז איפה נפלו גיבורינו מנשה ודני? מה ניתן לעשות טוב יותר? לדני גוף QA שמבצע בדיקות אוטומטיות וידניות ומנשה בדק את המוצר ביסודיות במעבדת הבדיקות.
מנשה נזכר שבמיקרוסופט הציעו לו להעלות את כלל התחנות של הארגון לענן. לכאורה כך ניתן יהיה לבדוק מוצרים/עדכונים טרם הפצתם בארגון. עד מהרה מנשה למד שמדובר בפתרון לא ריאלי בשל חסמים משפטיים, תשתיתיים, שיקולי אבטחת מידע, שיקולי אי-וודאות וכן העלויות הישירות ועקיפות הגבוהות, והמורכבות שבתהליך. מעבר לכך, Azure מיועד לספק שירותים (כגון "שירותי SQL") ולא כדי לסמלץ תחנות או שרתים פיזיים לצורך בדיקות. מנגד, דני בחן מוצר מעניין של סטארטאפ בשם Minute Lab שגייס כסף מ- Glilot Capital Partners. הפתרון מציע בדיקות בתוך Containers שמספקים סימולציה לסביבות שונות - פתרון שמיועד למפתחי תוכנה ופחות מתאים לסביבה הטרוגנית ולטכנולוגיות הישנות שבבנק. נבחנו גם האופציה לעבוד עם פתרונות ייעודיים לרבות EMC,Prov ו- CloudShare. חלקם קיבלו תג מחיר של מאות אלפי דולרים לשנה, מה שלא עולה בקנה אחד עם היכולות. האם בנסיבות הללו גיבורינו מנשה ודני עומדים בפני בעיה בלתי פתירה?
מעבדת החדשנות כתפיסה
לכול הפחות, ניתן להגיד שהמענה אינו טריוויאלי. מדובר קודם כל בפתרון תפיסתי ואחר כך בפתרון תהליכי: תחילה על ארגונים להכיר בבעיה ואז להקצות לה קשב ומשאבים כדי למזער אותה.
מה ניתן לעשות כעת? כשנצבר הניסיון בשני צידי המתרס, כיצד ניתן למנוע הישנות של מקרים שכאלו בעתיד? כיצד דני יכול להוביל ארגון מו"פ שמחוייב לעמידה ביעדים, ותוך כך לבנות מוצר יציב ובשל יותר? כיצד מנשה יכול לזהות תקלות מבעוד מועד, לפני ההטעמה בסביבת ה- Production? לכאורה מדובר בזהות אינטרסים, אך לא כך הדבר. בעוד ש- TWO כחברה רוצים לצאת לשוק כמה שיותר מהר, עם מאפיינים כמה שיותר מתקדמים, הדבר האחרון שמנשה מעוניין בו הוא התעסקות עם שלל בעיות IT.
בשלב ראשון יש לבחון: האם ניתן להגדיר מנהל פרויקט בתוך הארגון, לצורך הקמת מעבדת חדשנות פנימית? האם הפרויקט ייתמך ע"י ה- IT-תקשורת-ותשתיות? מי יתקצב את הפרויקט? ולא פחות חשוב, האם הארגון מסוגל לתחזק מעבדה שכזאת? הרי ביום הקמתה היא אולי תהיה נפלאה, אך במידה ולא יושקעו משאבים באחזקתה, עד מהרה היא תהפוך לפחות ופחות רלוונטית. אולי השאלה המרכזית שהארגון צריך לשאול את עצמו, היא האם הוא מעדיף פרויקט פנימי, או עבודה עם גוף צד שלישי שיבנה או יתחזק את המעבדה כשירות, על בסיס הה- Use-Case שיגדירו ביחד?
פתרונות אפשריים
מנשה ניסה להוביל פרויקט של בניית מעבדת חדשנות באופן עצמאי: הוא פנה למנהלי התשתיות וה- IT כדי שיספקו את הידע והמשאבים לצורך הקמת רשת נוספת שתכיל שרתים ושירותים כגון SCCM, SIEM, SQL, Exchange, AD/DC, אינטגרציה עם הענן ועוד. באופן טבעי, גוף ה- IT עמוס עד מעל הראש, ולא אפשר את הקצאת משאבי הזמן/ידע הדרושים. מנשה גם התקשה לקבל תקציב לרכישת תחנות, תוכנות, ושירות ייעודי בענן. מה גם שאם המעבדה תתוכנן באופן לא נכון, היא לא תפיק ערך חרף המשאבים שיושקעו בה. מנגד, גם אם תתוכנן נכון, עדיין יישארו אתגרים פתוחים ועל כן רצוי שמומחה בתחום ילווה את התהליך לכול אורכו, כדי לספק מענה לסוגיות פתוחות כגון ניטור תקלות ניטור ביצועים, סימולציית תעבורה בתחנות הקצה וברשת, ועוד.
הקמת מעבדת חדשנות אכן מהווה אתגר ולכן היה אידיאלי לרכוש מעבדה כמוצר. עם זאת, כיוון שסביבות Production שונות האחת מהשנייה, לא ניתן ליצור "One Solution Fits All". מה שכן, ניתן לאפיין מעבדות חדשנות שתתואמנה לצרכי הארגון ולמוקדי הכאב שלו, במטרה לספק מענה אופטימאלי.
אמנם סביבת בדיקות לעולם לא תדמה ב- 100% את סביבת ה- Production, אך מודל היברידי של הקמת מעבדת שירות באמצעות גורם מומחה, אשר מותאמת לצרכי הארגון היא כן פתרון ישים שיקפיץ את הארגון קדימה מבחינת האפשרות לזהות תקלות מבעוד מועד.
אכן מדובר באתגר, והפתרון הוא תפישתי ולאחר מכן תהליכי או מוצרי. תחילה יש לזהות את הצורך, להגדיר את מוקדי הכאב, ובסופו של יום, לבחון רכישת מוצר או שירות צד שלישי שילווה הקמת מעבדה בארגון או יעמיד מעבדה שכזאת עבור הארגון.
כפי שמנשה ישמח להכניס לסביבת ה- Production מוצרים בשלים בלבד, דני ישמח לייצר מוצרים יציבים יותר. בשלב ראשון, דני מעוניין להעביר את בדיקות ה- QA מהסביבה הסטרילית כיום, לסביבה דומה הרבה יותר לסביבות ה- Production של הלקוחות. גם מנשה וגם דני יכולים להשיג את מטרתם על-ידי שימוש בסביבת בדיקות מתקדמת.
?אז מה היה לנו
תחילה הגדרנו את ההבדל בין בחינת ביצועים של מוצר (האם הוא ממלא את הצורך לו הוא יועד) לבין בחינת היבטים תשתיתיים / IT. ראינו שניתן לשפר את סט הבדיקות, מה שכרוך בהשקעה משאבים. פתרונות לסביבת בדיקות נעים מרכישת מוצר צד שלישי, לבניית סביבה מקבילה בענן ועד להקמת מעבדת בדיקות באופן עצמאי או באמצעות בקבלן חיצוני. סימולציה של סביבת Production כחלק מכלי הבדיקות הסטנדרטיים בארגון יאפשרו זיהוי בעיות מוצריות מבעוד מועד, וכן פיתוח מוצרים בשלים יותר. כמובן שלא מדובר בפתרון הרמטי, אבל כן בקפיצת מדרגה. ייתכן שהקמת מעבדת חדשנות מותאמת אישית תוך שימוש בקבלן חיצוני לליווי הפרויקט היא הפתרון הישים והנכון ביותר עבור ארגונים רבים. שכן הוא מאפשר לגשר על פערי הידע מצד אחד, ובו בזמן להרים מעבדה בעלות סבירה, תוך שמירת הידע בארגון.
מאת: חגי ידידיה, מנכ"ל Real Network Labs, מעבדות בדיקות וחדשנות
פורסם במקור ב- Israel defense
יצרני תוכנה מתקשים לשחרר תוכנות וגרסאות יציבות, ונראה שהארגונים שרוכשים אותן מתקשים לאתר את הבעיות מבעוד מועד. כך קורה שיצרן התוכנה מאבד לקוחות בעוד ארגונים רבים משלמים על רישיונות למוצרים שלא מוטמעים. עיקר הבעיה נובע מסביבת הבדיקות הסטרילית, בה משתמש גם יצרן התוכנה וגם הארגון שרוכש אותה. אז איך מעבדת הבדיקות צריכה להראות? הנה תרחיש אפשרי המתואר מהעניים של מנשה, רוכש המוצר, ודני, מפתח המוצר.
מנשה הוא מנהל תשתיות ו- IT בארגון פיננסי שמעוניין להטמיע מוצר אבטחה, סוג של אנטי-וירוס שיהווה שכבת הגנה נוספת נגד תקיפות מתקדמות. הוא בוחן פתרון של חברת הזנק מבטיחה ומוכרת.
דני הוא מנהל המו"פ בחברת הזנק שמפתחת פתרון XDR ("אנטי-וירוס") מבטיח וחדשני - נקרא לו AgenTWO. תהליך ההטמעה של Two כולל הפצת Agent לתחנות הקצה. בשרת ניתן להגדיר Port Mirroring, על מנת לנטר את תעבורת הרשת לצורך זיהוי התנהגויות חשודות.
גם למנשה וגם לדני בעיה דומה: שניהם לא יודעים מהי מידת הבשלות של TWO וכיצד לבחון אותה. כלומר: האם TWO מוצר יציב? כיצד הוא יתנהג ברשת הארגונית של הבנק (סביבת ה- Production)? כתוצאה מכך הם מתמקדים בבדיקת הפונקציונאליות של המוצר שדווקא מצליח להרשים.
TWO באמת מהווה את חוד החנית בכל הקשור לזיהוי וחסימת תקיפות, וכך גם הראו ממצאי בדיקת הבנק במעבדת החדשנות שלו. אבל בכול הקשור ליציבות, בעיות ביצועים ארעיות, מנגנון ההפצה ברשת, עדכוני הגרסאות, התממשקות ל- Active Directory ומעבר לכך, ל- TWO יש עוד דרך ארוכה לעשות. מנשה לא יודע זאת וגם לדני אין כלים כל כך טובים לבחון בעיות שכאלו!
למען האמת, דני יודע שהמוצר שלו רווי תקלות, כמו כל מוצר פחות או יותר, לא? מה גם שכל סביבת Production שונה ואין לדעת בוודאות שיהיו בעיות בהטמעה הספציפית הזאת. את ה- PoC הוא עבר בשלום, וגם למתחרים יש מלא באגים.
?באגים – גורל או מציאות שמזמינים אותה
במציאות של היום זה דיי סטנדרטי שמוצרים מציגים לא רק שלל יכולות מבטיחות אלא גם מכלול באגים "מרשים". כולם נמצאים במרוץ אחרי ה- Feature או ה- Capability הבא, ומדדי היציבות נדחקים אל מעבר לפינה. כך קורה ש- TWO כמו מתחריו, הוא קורבן של המרוץ נגד הזמן ונגד התחרות. המתחרים מתהדרים בסט יכולות פנטסטי שאינו בהכרח בנמצא, ובדומה ל- TWO, בונים סביבות הדגמה מבטיחות, שלא בהכרח מייצגות את סביבות ה- Production בהן המוצר עתיד להיטמע.
הנה, בחודש שעבר מיקרוסופט הסירה מהמדפים מספר משפחות מוצרים שהשיקה רק יומיים לפני כן, לרבות Windows Server 2019 ו- Windows 10 1809 (הכתבה המלאה כאן). זאת בשל באגים קריטיים. אוי לבושה. אז מה כבר אפשר לצפות מחברת סטארטאפ? או שאולי ההיפך הוא הנכון? אולי דווקא חברת סטארטאפ צריכה להצטיין במדדי היציבות, מהסיבה שאין לה את הפריבילגיה לעשות פדיחות כפי שמוביל שוק יכול להרשות לעצמו לעשות?
מדוע דני לא מתקן את המוצר שלו מבעוד מועד? יש לכך מספר סיבות: בין אם בשל מחסור בכוח אדם איכותי, לבין אם מדובר בתעדוף של גוף ה- Product לבין אם לנוכח התרבות הארגונית (הקלוקלת?) שמודדת בעיקר השקת מאפיינים חדשים ופחות יציבות. בסופו של יום, דני לא מצליח להביא את המוצר לבשלות הנדרשת. גרסאות חדשות יוצאות על בסיס שבועי. תיקוני באגים מביאים בצידם באגים חדשים, שלא לדבר על עדכוני גרסה שמספקים Features חדשים, המלווים בשלל קונפליקטים ותקלות.
במציאות התחרותית והאינטנסיבית, אין לדני את הפריבילגיה, המשאבים או הכוח הפוליטי על מנת לעשות את הטרנספורמציה המוצרית והארגונית, שתהפוך את TWO למוצר יציב ובשל. לכאורה מיקוד ביציבות יבוא בסופו של דבר על חשבון משאבים שמוקצים לפיתוחים חדשים, ודני חייב לעמוד ב- Roadmap המוצרי האגרסיבי. שהרי החברה הצהירה שבכנס RSA הקרב ובא, היא תשיק את הגרסה החדשה ובה שלל יכולות חדשות שעדיין אינן קיימות בשוק! הלקוחות האסטרטגיים מצפים לכך וכך גם המשקיעים.
מעבדת הבדיקות – ההצלחה וציר הזמן
הצלחת TWO במעבדת הבדיקות תהפוך את מנשה לקורבן של מוצר שעתיד להביא לתקלות אין-ספור. אמנם TWO עקף את המתחרים ב- Detection Rate, הציג יכולות Remediation, ואפילו ממשק פורנזיקה שמאפשר להתחקות אחר התוקף ופעולותיו על פני ציר זמן ויזואלי מרשים, אך כאן תיגמר ההצלחה. קריסות של TWO או כישלון בחסימת תקיפות (בשל תקלות מוצר) יהוו את החלק הקל. ה- Agent של TWO מקבל הרשאות System ונמצא ב- Kernel, כך שבאופן טבעי, הוא לא רק מגן אלא גם מסכן. מסכים כחולים יקריסו התחנות, בעיות ביצועים ארעיות, וקונפליקטים עם מוצרים קיימים יובילו להתנהגויות תוכנה מורכבות ולקריאות שירות רבות. התסריט הגרוע ביותר כבר קרה בעבר, והוא קריסת רשת ארגונית שלמה, בשל תקלה במנגנון ה- Port Mirroring. אוי.
בחודשים הקרובים מנשה ומחלקת ה- IT/תשתיות של הבנק, ישקיעו משאבים רבים בהתקנת והטמעת TWO, בהפצתו ל- Endpoints, בתמיכה, בעדכוני באגים, ולאחר מכן בהסרת המוצר ובהמשך התשלום עבור License ל- 3 שנים.
מתקינים ומתפללים
האם המציאות הזאת היא גזירה משמים? בעבר מנשה נקט באסטרטגיית "מתקינים ומתפללים". האם זה כי מנשה חובבן? או שמא מדובר ב- Best Practices? האם מונחות אופציות אחרות על השולחן?
כן, מנשה ביצע בדיקות במעבדת החדשנות של הבנק. מדובר בסביבת סימולציה וירטואלית מבוססת VMWare Workstation, שהוקמה במיוחד למטרה זו. סביבה דומה קיימת גם אצל דני, אם כי אצלו המכונות רצות דווקא על שרת Hyper-V. בכול מקרה, הבעיה היא לא ה- hypervisor.
?מדוע סביבת הבדיקות לא מספקת
כיוון שבניגוד לסביבת הבדיקות הסטרילית, בסביבת ה- Production מותקנים אלפי שרתים, ובתחנות השונות מותקנות עשרות תוכנות, סימולטנית. הפער בין המעבדה הסטרילית לסביבת ה- Production מביא לכך שמעבדת החדשנות כושלת במילוי תפקידן, ואינן חושפת את חוסר הבשלות של מוצרים רבים. היבטי ביצועים אינם מנוטרים, תקלות שקשורות בפריסת המוצר לא נחשפות שכן תהליך ההפצה לא נבחן כלל ובטח שלא ב- Scale גדול. גם ה- Port Mirroring שבעבר גרר קריסה של רשת ארגונית שלמה לא נבחן וכנ"ל לגבי מנגנון ה- Update. מסכים כחולים או קונפליקטים קריטיים לא הופיעו בבדיקה, שכן שכיחותם "נמוכה" ובסביבה הסטרילית לא נמצאים הטריגרים הרלוונטיים.
הן מנשה והן דני התכוננו היטב לסט הבדיקות שתואם מראש: לאילו פורטים TWO, פונה, כמה תעבורה הוא מייצר, תכולת התעבורה ש- TWO מוציא מהארגון, האם היא מוצפנת, האם הקוד מאובטח וכמובן – האם המוצר מבצע את מה שהוא מיועד לו? למען האמת, כאשר מנשה פנה ל- TWO, כבר עם תחילת ההתקשרות, הוא קיבל מסמך שמגדיר את תהליך ה- PoC (Proof of Concept), שם הוצגו ה- Best Practices של הבדיקות.
סט בדיקות שלם התפספס
בעיות הפצה ב- Scale גדול שגוררת קריסה של השרת או סתימה של תעבורת הרשת, אינטגרציה לקויה עם Active Directory, מנגנון ה- Update שגורר חור אבטחה חמור, מסכים כחולים, צריכת 100% של CPU Core ללא צורך, ושלל באגים וקונפליקטים עם מוצרים קיימים - יגררו קריאות Support אינספור.
אז איפה נפלו גיבורינו מנשה ודני? מה ניתן לעשות טוב יותר? לדני גוף QA שמבצע בדיקות אוטומטיות וידניות ומנשה בדק את המוצר ביסודיות במעבדת הבדיקות.
מנשה נזכר שבמיקרוסופט הציעו לו להעלות את כלל התחנות של הארגון לענן. לכאורה כך ניתן יהיה לבדוק מוצרים/עדכונים טרם הפצתם בארגון. עד מהרה מנשה למד שמדובר בפתרון לא ריאלי בשל חסמים משפטיים, תשתיתיים, שיקולי אבטחת מידע, שיקולי אי-וודאות וכן העלויות הישירות ועקיפות הגבוהות, והמורכבות שבתהליך. מעבר לכך, Azure מיועד לספק שירותים (כגון "שירותי SQL") ולא כדי לסמלץ תחנות או שרתים פיזיים לצורך בדיקות. מנגד, דני בחן מוצר מעניין של סטארטאפ בשם Minute Lab שגייס כסף מ- Glilot Capital Partners. הפתרון מציע בדיקות בתוך Containers שמספקים סימולציה לסביבות שונות - פתרון שמיועד למפתחי תוכנה ופחות מתאים לסביבה הטרוגנית ולטכנולוגיות הישנות שבבנק. נבחנו גם האופציה לעבוד עם פתרונות ייעודיים לרבות EMC,Prov ו- CloudShare. חלקם קיבלו תג מחיר של מאות אלפי דולרים לשנה, מה שלא עולה בקנה אחד עם היכולות. האם בנסיבות הללו גיבורינו מנשה ודני עומדים בפני בעיה בלתי פתירה?
מעבדת החדשנות כתפיסה
לכול הפחות, ניתן להגיד שהמענה אינו טריוויאלי. מדובר קודם כל בפתרון תפיסתי ואחר כך בפתרון תהליכי: תחילה על ארגונים להכיר בבעיה ואז להקצות לה קשב ומשאבים כדי למזער אותה.
מה ניתן לעשות כעת? כשנצבר הניסיון בשני צידי המתרס, כיצד ניתן למנוע הישנות של מקרים שכאלו בעתיד? כיצד דני יכול להוביל ארגון מו"פ שמחוייב לעמידה ביעדים, ותוך כך לבנות מוצר יציב ובשל יותר? כיצד מנשה יכול לזהות תקלות מבעוד מועד, לפני ההטעמה בסביבת ה- Production? לכאורה מדובר בזהות אינטרסים, אך לא כך הדבר. בעוד ש- TWO כחברה רוצים לצאת לשוק כמה שיותר מהר, עם מאפיינים כמה שיותר מתקדמים, הדבר האחרון שמנשה מעוניין בו הוא התעסקות עם שלל בעיות IT.
בשלב ראשון יש לבחון: האם ניתן להגדיר מנהל פרויקט בתוך הארגון, לצורך הקמת מעבדת חדשנות פנימית? האם הפרויקט ייתמך ע"י ה- IT-תקשורת-ותשתיות? מי יתקצב את הפרויקט? ולא פחות חשוב, האם הארגון מסוגל לתחזק מעבדה שכזאת? הרי ביום הקמתה היא אולי תהיה נפלאה, אך במידה ולא יושקעו משאבים באחזקתה, עד מהרה היא תהפוך לפחות ופחות רלוונטית. אולי השאלה המרכזית שהארגון צריך לשאול את עצמו, היא האם הוא מעדיף פרויקט פנימי, או עבודה עם גוף צד שלישי שיבנה או יתחזק את המעבדה כשירות, על בסיס הה- Use-Case שיגדירו ביחד?
פתרונות אפשריים
מנשה ניסה להוביל פרויקט של בניית מעבדת חדשנות באופן עצמאי: הוא פנה למנהלי התשתיות וה- IT כדי שיספקו את הידע והמשאבים לצורך הקמת רשת נוספת שתכיל שרתים ושירותים כגון SCCM, SIEM, SQL, Exchange, AD/DC, אינטגרציה עם הענן ועוד. באופן טבעי, גוף ה- IT עמוס עד מעל הראש, ולא אפשר את הקצאת משאבי הזמן/ידע הדרושים. מנשה גם התקשה לקבל תקציב לרכישת תחנות, תוכנות, ושירות ייעודי בענן. מה גם שאם המעבדה תתוכנן באופן לא נכון, היא לא תפיק ערך חרף המשאבים שיושקעו בה. מנגד, גם אם תתוכנן נכון, עדיין יישארו אתגרים פתוחים ועל כן רצוי שמומחה בתחום ילווה את התהליך לכול אורכו, כדי לספק מענה לסוגיות פתוחות כגון ניטור תקלות ניטור ביצועים, סימולציית תעבורה בתחנות הקצה וברשת, ועוד.
הקמת מעבדת חדשנות אכן מהווה אתגר ולכן היה אידיאלי לרכוש מעבדה כמוצר. עם זאת, כיוון שסביבות Production שונות האחת מהשנייה, לא ניתן ליצור "One Solution Fits All". מה שכן, ניתן לאפיין מעבדות חדשנות שתתואמנה לצרכי הארגון ולמוקדי הכאב שלו, במטרה לספק מענה אופטימאלי.
אמנם סביבת בדיקות לעולם לא תדמה ב- 100% את סביבת ה- Production, אך מודל היברידי של הקמת מעבדת שירות באמצעות גורם מומחה, אשר מותאמת לצרכי הארגון היא כן פתרון ישים שיקפיץ את הארגון קדימה מבחינת האפשרות לזהות תקלות מבעוד מועד.
אכן מדובר באתגר, והפתרון הוא תפישתי ולאחר מכן תהליכי או מוצרי. תחילה יש לזהות את הצורך, להגדיר את מוקדי הכאב, ובסופו של יום, לבחון רכישת מוצר או שירות צד שלישי שילווה הקמת מעבדה בארגון או יעמיד מעבדה שכזאת עבור הארגון.
כפי שמנשה ישמח להכניס לסביבת ה- Production מוצרים בשלים בלבד, דני ישמח לייצר מוצרים יציבים יותר. בשלב ראשון, דני מעוניין להעביר את בדיקות ה- QA מהסביבה הסטרילית כיום, לסביבה דומה הרבה יותר לסביבות ה- Production של הלקוחות. גם מנשה וגם דני יכולים להשיג את מטרתם על-ידי שימוש בסביבת בדיקות מתקדמת.
?אז מה היה לנו
תחילה הגדרנו את ההבדל בין בחינת ביצועים של מוצר (האם הוא ממלא את הצורך לו הוא יועד) לבין בחינת היבטים תשתיתיים / IT. ראינו שניתן לשפר את סט הבדיקות, מה שכרוך בהשקעה משאבים. פתרונות לסביבת בדיקות נעים מרכישת מוצר צד שלישי, לבניית סביבה מקבילה בענן ועד להקמת מעבדת בדיקות באופן עצמאי או באמצעות בקבלן חיצוני. סימולציה של סביבת Production כחלק מכלי הבדיקות הסטנדרטיים בארגון יאפשרו זיהוי בעיות מוצריות מבעוד מועד, וכן פיתוח מוצרים בשלים יותר. כמובן שלא מדובר בפתרון הרמטי, אבל כן בקפיצת מדרגה. ייתכן שהקמת מעבדת חדשנות מותאמת אישית תוך שימוש בקבלן חיצוני לליווי הפרויקט היא הפתרון הישים והנכון ביותר עבור ארגונים רבים. שכן הוא מאפשר לגשר על פערי הידע מצד אחד, ובו בזמן להרים מעבדה בעלות סבירה, תוך שמירת הידע בארגון.
מאת: חגי ידידיה, מנכ"ל Real Network Labs, מעבדות בדיקות וחדשנות
פורסם במקור ב- Israel defense
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר