Midi-Post – a podcast recommendation

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

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

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

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

ברנדון, שמראיין כאן את טוד, שואל שאלות בסגנון לקוח פוטנציאלי והדיון מתחיל בהאם צריך להקים אפליקציה יעודית או להשתמש רק בממשק וובי ובאילו פריימוורקס כדאי להשתמש בפיתוח ובדקה 51:40 מתחיל דיון על הבחירה בין בסיסי נתונים רלציוניים לעומת לא רלציוניים (SQL vs NoSQL) ובקצרה מה שטוד מתאר לנו כאן זה כי הרבה פעמים מתחילים על בסיס של NoSQL אבך בסופו של דבר אילוצי המידע מכריחים אותנו ליצור את הקשרים סביב המידע ככה שאנחנו בעצם מייצרים קשרים רלציוניים על בסיס הנתונים שלא רלציוני שלנו. הדיון ממשיך לשאלת הענן מול שרתים ב Colocation. זה נשמע כמו שיחה סביב המדורה בין חברים באותו מידה שזה נשמע כמו דיון שצריך להתנהל בכל חדר ישיבות, האם הטרנדים בעולם שלנו רלוונטיים לנו? האם ההחלטות שלנו מדודות לפי הצרכים האמיתיים של הביזנס שלנו ולא לפי מה שסקסי וטרנדי היום? אני לא מפתח בג'אווה ולכן חלק מהדיון קצת עובר לי מעל הראש אבל אני אוהב את הגישה הפרגמטית שטוד מייצג כאן שאומרת שאין פתרון אחד שמתאים לכולם ולפני שאנחנו בוחרים את כלי העבודה, אנחנו צריכים להבין את הבעיה שאנחנו מנסים לפתור.

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

זה הכל להפעם,

שמח לשמוע מה דעתכם ולקבל מכם המלצות לפודקסטים טובים,

שלכם,

ניר מליק

Got Silk?!

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

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

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

אפשר לראות שיש קשר ישיר בין גודל הדיסק ב GB וכמות ביצועי ה IOPS העומדת לרשותו. אפשר לראות בהערות גם שיש כמות ה CPU וכמות ה IOPS בגלל ששרתים עם יותר CPU יכולים לגבל הקצאת תקשורת נדיבה יותר, Network egress caps. משמעות הדברים היא שיתכנו מצבים בהם לקוחות צריכים לשלם על נפח דיסק ריק כדי לקבל יותר משאבי ביצועים ועל מעבדים מיותרים כדי לקבל יותר משאבי תקשורת אל הדיסקים.

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

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

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

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

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

כלי שימושי נוסף שאנחנו מאפשרים ללקוחות הוא סנפשוטים רזים. תהליך יצירת סנפשוט בענן הוא תהליך ארוך ויקר. ב AWS למשל, בתהליך יצירת הסנפשוט מועתק המידע אל S3 ובכל סנפשוט נוסף יש להעתיק מידע נוסף, את המידע החדש. אנחנו מאפשרים ליצור סנפשוטים מידיים, מבוססי הצבעות בלבד, כך שאין צורך להזיז מידע או לשלם על נפח מידע נוסף ולכל סנפשוט ניתן לייצר View כלומר להשתמש בסנפשוט כהעתק עצמאי של המידע לשרתים אחרים, test/dev או אנליטיקה וכו'.

אנחנו רואים בבמוצע חסכון של 3:1 בשימוש ביכולות חסכון בנפח ולפחות עוד 30% חסכון על ידי שימוש בThin Provisioning וזה אומר שרק על ידי זה שריכזנו את המידע של הלקוח והכלנו עליו את היכולות האלו, הלקוח צורך עכשיו פחות מרבע מהנפח שהוא צרך קודם ובגלל שאנחנו לא נסנכים על ביצועי הדיסקים של תשתית הענן הרבע הזה הוא בדיסקים זולים יותר מהדיסקים הקודמים!

בפעם הבאה נדבר קצת על ביצועים, בתקווה ועד אז אבין את זה מספיק טוב בעצמי 😊

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

עדכון לפוסט!

כמו מהשמים שלחו לי לינק לסרטון הזה היום, החל מדקה 16:54 בערך אפשר לראות בדיוק כמה מורכבות האופציות לבחירת דיסקים ב AWS והתאמת ה EC2 instance לבחירה שלכם.

כבונוס, יש שם הדגמה של יכולות של blktrace. ביחד עם blkparse, btt ועוד סקריפט פייטון קטן (כן כן הרבה חלקים זזים) אפשר ממש להציג באופן קריא ונוח עד כמה ה IO שהשרת שלכם עושה הוא Sequential או Random, נתון שהרבה פעמים חסר לנו כשאנחנו באים לעשות סייזינג מסודר למערכות סטורג', אם אתם מאלו שעוד עושים כאלו דברים 🙂

credit AWS: https://youtu.be/wsMWANWNoqQ
credit AWS: https://youtu.be/wsMWANWNoqQ

כמו תמיד אשמח מאד לשמוע מכם!

שלכם,

ניר מליק

מפריז הביתה

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

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

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

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

https://www.cloudshare.com/blog/the-big-share-a-qa-with-technical-sales-leader-and-remote-veteran-nir-malik

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

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

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

SAS זה בעצם ראשי תיבות של Serial Attached SCSI והפרוטוקול הזו הוא המקשר בקשר point to point בין יחידות המחשוב שלנו לדיסקים. אחד הדברים המתאפשרים לנו עם זה להציג את אותה המדיה לכמה יחידות מחשוב ובכך לנתק את הקשר הישיר ביניהם. עכשיו ניתן לנתק את הקשר הגורדי הזה ובכך לאפשר הרבה יותר גמישות במבנה מערכת האחסון, ניתן להגדיל את המערכת בנפח אחסון (scale up) או בכוח מחשוב (scale out) באופן הרבה יותר גמיש מאי פעם. אם מערכות scale out קלאסיות מחייבות להגדיל גם את נפח האחסון לצד כוח המחשוב ויחידות האחסון מקושרות פיזית ליחידות מחשוב ספציפיות, עכשיו אפשר נגיד לחבר שמונה יחידות מחשוב לאותה יחידת אחסון.

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

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

שלכם כמו תמיד,

ניר מליק

הלמה מתה?

זה היה פוסט שמאד אהבתי, בעיקר בגלל הכותרת המתחכמת שלו שהבטיחה למות ובמקום לדבר על בהמת משא דרום אמריקאית שיורקת, עסקה בכלי לשוני פופולרי לביצוע תחקירי RCA או Root Cause Analysis ובכן לא מזמן נתקלתי בציוץ הזה:

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

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

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

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

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

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

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

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

זה מתגלגל לי בראש מאז שראיתי את הציוץ הזה של ג'אסטין וורן:

והניסוח הזה שלו, Always Be Falling מסקרן אותי אבל אני לא מצליח לשים את האצבע על המקור של הניסוח הזה ועל הכוונה המלאה שלו. בתשובה לשאלה שלי, הוא מפנה לחומר קריאה, גם לזה של סידני דקר, ובשורה תחתונה מפנה לחפש חומר על Resilient Design ולכאן ננסה לחזור לדעתי בפוסט הבא כי כאן אני חושב נמצאת הפואנטה, כאן עוברים מהרוח לחומר וכאן יורדים מהפילוסופיה של תכנון שריד חדש אל הארכיטקטורה של MS SQL שמוגדר עם Always ON מעל שרתים של VMware שמוגדרים עם HA מעל מערכות אחסון יתירות עם רפליקציה והכל ארוז בפתרון סטייל Continuity שיודע לוודא עבורנו את הקונפיגורציה של כל ה Stack ארוז ביחד ומוגדר נכון.

מחכה לשמוע מה דעתכם,

תשטפו ידיים ואם לצטט את דניאל פאר באמירה קלאסית שנשארה רלוונטית גם בימי קורונה, שמרו מרחק, שנוכל להיפגש!

ניר מליק

תקשורת אפקטיבית בימי קורונה

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

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

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

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

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

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

תיראו כאן את מושל מדינת ניו-יורק, המושל קומו:

המושל מתחיל בפירוט על כמה בדיקות בוצעו ואיפה, כמה נדבקים, כמה מחלימים, מה המגמות. בדקה 5:02  הוא משתף את הציבור באופן מאד מסודר וברור, את השיקולים השונים וההבדל בין המודלים ומשתף את הציבור בקושי לתכנן קדימה והצורך לעדכן את התכנון כל יום בהתאם למידע החדש שמגיע ובדקה 7:57 הוא מדבר על תחזית המתים בארצות הברית ובמדינת ניו-יורק. בדקה 11:26 המושל מדבר על 21,000 מתנדבים מחוץ למדינת ניו-יורק שבאים לעזרת המדינה, עשרים ואחת אלף איש ומתחייב להחזיר טובה תחת טובה, בשמו, בשם הניו-יורקרים והרוח של ניו-יורק המושל מדבר על זה שניו-יורק בעצם הראשונה לחטוף ואיך הוא לא ישכח שאנשים באו לעזור ויהיה הראשון ברכב לצאת לעזור לאחרים כשהם יהיו בצרה. זו אמריקאיות וזה קצת שמאלצי כמובן אבל זה מסר מאחד שנותן טיפה אופטימיות אחרי הנתונים הלא פשוטים שהציג.

בדקה 15:11 המושל מדבר ישירות אל היצרנים הגדולים במדינה, אין לו את הסמכות להורות להם מה לייצר והנשיא טרמפ לא מוציא את הצו הנדרש ולכן המושל מבקש ממי שיכול להסב את קווי הייצור שלו ומודיע שמדינת ניו-יורק תשלם ביד נדיבה לא רק על התוצרים אלא גם על ההסבה עצמה.

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

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

בתקווה ונוכל להיפגש בקרוב פנים אל פנים ולא בלשכת התעסוקה,

חג שמח!

ניר מליק

vExpert, HDDs and Lyve Labs

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

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

דבר שני, בשבוע שעבר, כריס מלור סיפק לנו reality check מאד מעניין על עולם האחסון. דבר ראשון, אנריקו סיניורטי ניסה לא מזמן לחזק את הטענה שדיסקים הולך להיעלם מחדר השרתים הארגוני וכל נפח האחסון בעולם יהיה או בענן או בחדר השרתים על גבי SSD. ובכן, המספרים מראים שאנחנו עוד מאד רחוקים משם, בפועל, מה שקרה ב 2019 זה ההיפך, מכירות דיסקי SSD ירדו. אם ב 2018 דיסקי SSD היוו 12 אחוז מסך הדיסקים שנכרו בעולם, ב 2019 הם היוו סה"כ 10.4 אחוז. המספרים האלו כמובן מתיישרים עם מה שאנחנו באינפינידט מספרים לכם כבר כמה זמן, השבוע פרסמנו באופן פומבי שחצינו את סף ה 6EB בעולם והמערכות שלנו מבוססות כמובן על דיסקים מסוג NL-SAS כאשר דיסקי SSD משמשים רק כ Cache ולא כנפח האחסון העיקרי.

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

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

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

טוב, אז זהו להפעם, אשמח לשמוע מה חשבתם!

שלכם,

ניר מליק

ברווזון סייבר סייבר סייבר

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

ברווזון סייבר

ביום ראשון האחרון, חבר שלנו, יול, כתב שהצליח בפעם הראשונה לבנות בעצמו "ברווזון גומי" וזה עלה לו רק 5$ במקום 50$ שהיה עולה לו לרכוש ברווזון אחד מקורי.

אז לא היתה לי ברירה אלא ללכת לברר מה זה בכלל "ברווזון גומי" ולמה שאיש אבטחת מידע רציני כמו יול ירצה לבנות אחד.

ובכן, ברווזון גומי, או בשמו הנפוץ Rubber Ducky, הוא כלי תקיפה שמתחזה פעמיים. מבחינה חזותית, חיצונית, מדובר בכלי שנראה כמו דיסק-און-קי פשוט. מבחינה לוגית, פנימית, ברגע שהכלי מחובר למחשב, הוא מתחזה למקלדת. ההתחזות הכפולה הזו מנצלת תמימות כפולה, הראשונה של המשתמש התמים שסתם מחבר כזה התקן USB למחשב שלו והשנייה של מערכת ההפעלה של המחשב שבדרך כלל מאפשרת חיבור של התקני קלט מסוג HID או Human Interface Device כמו מקלדות.

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

הפער בין IT ל OT

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

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

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

הגנה על שרשרת האספקה

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

Vdoo מספקת כמה מוצרים אבל מוצר אחד מרכזי שלה נקרא Vision שמבצע באופן אוטומטי סוג של Code review למוצר ה Embedded ויודע לספק המלצות הקשחה והגנה עבורו. ERA הוא מוצר ההגנה המתלבש על מוצר הEmbedded ובהתאם להמלצות Vision מותאם באופן אוטומטי לסגירת פרצות האבטחה האפשריות שהתגלו. CertIO הוא מוצר הסרטיפיקציה שמספק ללקוחות הקצה את הידיעה שמוצר ה Embedded עבר את ההקשחה הנדרשת.

בכל אופן קצת אחסון לסיום

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

שלכם כמו תמיד,

ניר מליק

מהאוקיינוס ההודי לאוקיינוס הפסיפי

השבוע ביקרתי לראשונה בגואה שבהודו, אני מנחש שמרביתכם מכירים את השם גואה ממסיבות הפול-מון המפורסמות אבל, לא, אני ביקרתי שם במסגרת אירוע Gartner Symposium, לא צריך לקנא בי גם אתם יכולים! גואה מאד יפה, האוכל נהדר (דגים ופירות ים בעיקר) והכנס היה מאד מוצלח.

תכננתי ללכת לשמוע הרצאה שנקראת "How to Make a Great Decision, Every Time". נשמע מבטיח לא? לצערי לא הזדמן לי לשמוע אותה כי הלו"ז התנגש עם פגישה אחרת שתואמה לי אבל אני סקרן לדעת אם הם נגעו שם בנקודה המעניינת שגיליתי דרך הציוץ הזה:

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

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

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

אלו אתגרים עצומים והפתרונות לפעמים די מדהימים, וורנר קיימת פחות מ 100 שנים והאחים לומייר הקרינו את סרט הקולנוע הראשון שלהם ב 1895, מדובר בינוקות לעומת הארכיונים של הוותיקן למשל. נכון ל 2018 השתמש הוותיקן ב 4PB של אחסון על גבי פתרון של Isilon ועוד 5PB של אחסון על גבי פתרון של ECS, שניהם של חברת EMC. זה לא החלק המעניין באמת, למרות שהייתי שמח להחליף שם את הפתרונות של EMC בפתרונות שלנו. החלק המעניין הוא שהמידע הזה הוא רק ההעתק הפחות איכותי. ההעתק האיכותי באמת, הסריקה ברזולוציה מלאה, נשמר גם כאן על גבי פילם ונשלך לאתר אחסון שהיה בעבר מכרה מלח (מטורף לא?!) בנורבגיה! במסגרת מה שנקרא Arctic world archive (ברצינות ככה הם קוראים לזה!) .

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

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

VMware Project Pacific

בשבוע שלפני כנס גרטנר בהודו, התקיים כנס VMworld בברצלונה ובו נחשפו עוד קצת פרטים על Project Pacific אז שווה להזכיר כמה מילים על מה בדיוק מדובר כאן. כדאי לזכור שעדיין לא מדובר על מוצר מוגמר אלא כרגע על קונספט בפיתוח, אבל כמות ההשקעה של VMware בשיווק של הדבר הזה רומזת לנו שאולי זה ישתנה בקרוב. פרוייקט פסיפיק הוא בעצם איחוד ממשקי ניהול בין vShpere ו vCenter ובין קוברנטיס ככה שניתן יהיה לנהל קלסטרים של vSphere ושל K8 מאותו המקום, מי שרגיל לעבוד עם vCenter יכול לראות את כלל האובייקטים של K8 מתוך הממשק הרגיל שלו ומי שרגיל להקצות משאבים מתוך K8 יכול להקצות ולראות עכשיו לא רק קונטיינרים אלא גם מכונות וירטואליות "רגילות". למי שמחפש הזדמנות ללמוד קצת על מה זה בכלל קוברנטיס, VMware משיקה גם קורס חינמי שפתוח לכולם, לא רק ללקוחות VMware, שווה להציץ!

Tech Preview נוסף שנחשף באותה הזדמנות ובאותו הקשר הוא פרויקט Tenzu שמהווה למעשה כלי SaaS לניהול K8 ללא תלות במיקום הקלאסטר שלכם, On-Prem או בענן ככה שבעצם VMware מספקת עכשיו כלי אחד לניהול הסביבות שלכם גם אם הן K8 בענן, K8 מקומי, K8 על גבי vSphere או vSphere Native, Single Pane of Glass למישהו?

זוכרים שמוקדם יותר השנה סיפרתי לכם על vSphere על מעבדי ARM? אז דבר נוסף שנחשף בכנס הוא היכולת להריץ vSphere על גבי מעבד ARM על כרטיס רשת! כן כן, כרטיס הרשת יכול להיות הוסט בעצמו! עכשיו תחשבו על מה המשמעות של כל זה ביחד, אנחנו יכולים לנהל ממקום מרכזי את כל סביבות ה K8 שלנו ומשם לנהל קונטיינר שרץ באיזה אתר מרוחק שלנו שאולי אין בו אפילו שרת אחד ויחיד אלא רק התקן (Device) שכרטיס התקשורת שלו הוא הוא הPod המארח. זה די מגניב!

שלכם כמו תמיד,

ניר מליק

All Anything and Carpool lanes

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

אז בחודש שעבר, סיגייט סיפרה לנו באמצעות Block and Files, שבין היתר, באמצעות הטכנולוגיות האלו, דיסקים מסובבים יוכלו להישאר זולים יותר מדיסקי SSD גם במבט ל15 שנים קדימה שזה מעניין כי השבוע אותו אתר הציג לנו מאמר של היוברט סמית' שאומר לנו שדיסקים מבוססי NAND הם לא רק זולים יותר מדיסקים מסתובבים, הם אפילו אמינים יותר!

עכשיו, פעם היו לנו דיסקים 5,400 RPM, ואז שדרגנו ל 7,200 RPM  ואז מי שרצה דיסקים מהירים קנה דיסקי FC ואחריהם הוא קנה דיסקי SAS ואז אמרנו לכל הלקוחות שלנו להגדיל את כמות הדיסקים, הספינדלים, כדי לחלק על כמות דיסקים גדולה יותר את הפעולות שהם נדרשים לבצע, את ה IOPS ואז עלה עלינו מהמדבר הפולש המונגולי של מערכות ה All Flash ואמר ללקוחות שלנו שהם משוגעים כי הם קונים נפח שהם לא יכולים לנצל בשביל לקבל ביצועים וכדאי להם לעבור לדיסקי SSD ועכשיו מה מוכרים ללקוחות שלנו אותם כוהני SSD? שהם צריכים לקנות נפח שהם לא יכולים לנצל בשביל שרידות!

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

ועדיין, כולם מתעלמים מהעובדה ש DRAM  מהיר בסדרי גודל מכל מדיה אחרת! איך יצרני ה All Anything מעיזים למכור לכם מדיה איטית בסדרי גודל מהמדיה המהירה ביותר?!

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

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

עכשיו, מה עושים אם פתאום יש עומס חריג במערכת? מה עושים אם פתאום מערכת האחסון שלנו נחנקת  בגלל עומס חריג? אפשר כמובן להכיל מדיניות Quality of Service על כל האובייקטים בסביבה וככה להגביל מראש את כמות המשאבים שכל אובייקט יהיה מסוגל לצרוך אבל גם אם לא עשינו את זה, קיים אצלנו מנגנון מובנה שיודע "להעניש" את מי שמתפרע, להוסיף Latency  לפעולות של מי שחורג כדי לתעדף את מי שמתנהג יפה. בדיוק כמו נתיבי הקארפול הטריק הזה לא יכול לעבוד בסביבה שקורסת תחת הנטל גם ככה וגם מנגנוני QoS מתוכננים לטפל במי שבדרך כלל מתנהג יפה, אם מדיניות ה QoS שלכם כל הזמן בפעולה, אם ה Threshold שלכם כל הזמן פעילים, אז הם פשוט לא מוגדרים נכון והסביבה שלכם חנוקה, אתם לא שולטים במצב אלא דקה מפיצוץ.

ספרו לי מה חשבתם על הפוסט הפעם,

צום קל!

אני במשמרת מג"ב ביום כיפור אז תעשו טובה ותשמרו על עצמכם,

שלכם,

ניר מליק

Mini Post – VMware HCX

זה יהיה פוסט קצר כי לא מצאתי הרבה מידע עדיין אבל חשוב שתכירו שבסוף השבוע VMware חשפה מוצר חדש בשם HCX Enterprise. המוצר הזה אמור להוות פלטפורמה מרכזית המאפשרת יותר בקלות מבעבר ניידות של מכונות וירטואליות.

הכלי כולל בתוכו שלוש תכונות עיקריות:

  1. מיגרציה מסביבות שאינן סביבות ESXi – הכלי יאפשר להסב מכונות מסביבות KVM+ Hyper-V אל סביבות ESXi ובעתיד יאפשר גם להסב מכונות מסביבות נוספות
  2. ניהול של משימות vMotion תוך הוספה של האצה ומקביליות או מה שהם קוראים עכשיו replication assisted vMotion ככה שאפשר לבצע ניוד של מספר רב של מכונות על פני מרחקים גדולים יותר (תחשבו ESXi Over AWS)
  3. התממשקות אל VMware SRM כך ש HCX מהווה שכבת הטרנספורט עבור SRM ומוסיף יכולות של wan optimization, הצפנה וכו'

לקריאה נוספת יש כאן את ה FAQ ואם אתם בעניין אז בקישור מטה תמצאו גם את הפרק הרלוונטי של vSpeaking והפעם עם איימי לואיס הלא היא @CommsNinja

https://www.vspeakingpodcast.com/episodes/125

למתקדמים יש אפילו דמו עם hands On Lab

כמו תמיד, שמח לשמוע מה דעתכם,

ניר מליק

על תקשורת יעילה ושאלת שאלות

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

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

וזה אגב הפוסט המקורי אליו הוא מתייחס:

https://www.linkedin.com/feed/update/urn:li:activity:6559503027663888384

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

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

  1. אם למשימה יש דד-ליין אז כותבים את הדד-ליין באופן ברור בראש המייל כי הרבה החלטות אחרות נגזרות מהדד-ליין
  2. לא שולחים מייל עם נושא כללי כמו "שאלה" או "הצעת מחיר"
  3. לא שולחים מייל עם מיליון אנשים בשורת ה To:, אל מי המייל מיועד? מי לדעתכם צריך להגיב\לפעול?
  4. גם מיליון אנשים בשורת ה Cc: זה לא תמיד חכם, האם באמת כל המכותבים צריכים להיות מכותבים?
  5. בדרך כלל התגובה הנכונה היא לא Reply All
  6. היה כבר פינג-פונג-פינג-פונג? תרימו את הטלפון במקום לענות למייל שוב
  7. אם המיל מכיל יותר מנושא אחד צריך לוודא שההפרדה בין הנושאים ברורה ואולי כדאי מראש לפצל מיילים עם שורת נושא ברורה (בהתאם הערה מספר 1)
  8. אין לצאת מנקודת הנחה שמקבל המייל יהיה סקרן מספיק בשביל לגלול למטה בשרשור
  9. אם נעשה שינוי בתוכנית אז מפיצים תוכנית חדשה כדי שלכולם יהיה את אותו הדבר מול העיניים

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

בזכות טל פפרין בלינקדאין מצאתי את הקטע הבא שמייעץ לנו אף פעם לא לענות לשאלה ששאלו אותנו אלא תמיד לענות בשאלה בחזרה:

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

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

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

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

שלכם תמיד,

ניר מליק

רברסים – לא הכרתי אותם קודם ושווה להכיר

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

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

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

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

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

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

מצאתי גם מקומות ביקורתיים כלפי השיטה, מקומות שטוענים שאכן מדובר באגדה אורבנית ושאין דבר כזה בעצם. פוסט הביקורת הזה מציג עקרונות מקבילים וקורא לזה blame aware כלומר מכיר בזה שזה טבעי לבני האדם לחפש אשמים וקורא לנו להיות מודעים לזה ולקבוע מעין קוד התנהגות לאיך אנחנו מתקשרים ודנים בזה בצורה פרודוקטיבית יותר. אהבתי במיוחד את הקריאה שלו לתת ל post mortem מקום ראוי, הוא קורא לזה to be deliberate, וזאת בניגוד לנורמות נפוצות בהם תחקירי אירוע נדחקים הצידה לטובת כמעט כל דבר אחר שקורה בארגון, הוא קורה לתת לזה עדיפות ולקיים את התחקיר בסמוך למועד האירוע, ככל שחולף הזמן הטעם לבצע תחקיר בכלל יורד.

ההרצאה האחרונה שאני רוצה לספר לכם עליה היא ההרצאה של  שחר קידר מהכנס של 2018 בכלל

שהיא הרצאת תגובה להרצאה של יפתח בר מהכנס של 2017.

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

זה הכל לפעם,

אשמח לשמוע מה דעתכם,

שלכם,

ניר מליק