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

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

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

ביום ראשון האחרון, חבר שלנו, יול, כתב שהצליח בפעם הראשונה לבנות בעצמו "ברווזון גומי" וזה עלה לו רק 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.

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

זה הכל לפעם,

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

שלכם,

ניר מליק

נגמר לי המוג'ו, מזל שאינפינידט מחפה עלי!

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

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

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

https://www.crowdchat.net/chat/c3BvdF9vYmpfMjk3Mg==

אחד הדברים המגניבים שכלולים בהכרזה הנוכחית הוא פתרון Active/Active אמיתי שמאפשר להתקין שתי מערכות אחסון בשני מיקומים גיאוגרפיים שונים ולבצע קריאה וכתיבה של מידע באותו ה Volume בשני האתרים בו זמנית. כמו כל דבר באינפינידט, לא צריך לרכוש רישוי נוסף עבור הפיצ'ר הזה והיות ומדובר ברפליקציה מובססת IP לא צריך לרכוש חומרה נוספת על מנת ליישם את הפתרון, רק שתי מערכות אחסון וקו IP  ביניהן. אם קו התקשורת שלכם בין המערכות מהיר מספיק, ושני האתרים קרובים מספיק בשביל לא לייצר Latency נוסף, נניח שתי קומות של אותו בניין או שני בניינים באותו הקמפוס, אפשר לבצע Sub ms IOps על גבי פתרון Active/Active אמיתי, הרפליקציה עצמה לא מוסיפה Latency מורגש!

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

בנוסף, לטווח הארוך יותר, הכרזנו על תפיסת ה Elastic Data Fabric שלנו שתאפשר לכל לקוח לנהל ולשלוט במידע שלו על פני מערכת אחסון אחת או יותר, בחדר השרתים שלו, באתר אירוח חיצוני ועל גבי שירותי הענן הציבוריים הגדולים. כתבתי כאן הרבה על יכולות ה Hybrid של נטאפ ופיור מצד יצרניות האחסון ושל אמזון מצד ספקיות הענן על מנת לגשר על הפערים בין מערכות On Prem ופתרונות ענן וההכרזה הזו שלנו היא חלק מהמענה שלנו לאתגר הזה. סיפרתי לכם בעבר על פתרון ה Neutrix שלנו כאן וכאן שהיה בעצם הצעד הראשון שלנו בתחום, צפו לעוד בקרוב!

בנוסף לאקטיב-אקטיב ול Elastic Data Fabric הכרזנו גם על שיפור ביצועים משמעותי מאד, אנחנו מסוגלים היום לספק 2M IOps בזמני תגובה של sub ms, קפיצה גדולה מאד מ 1.4M רק בסוף השנה הקודמת ובנוסף הגדלנו את ה Throughput שלנו מ 15GB ל 25GB וכאילו כל זה לא מספיק, השקנו גם שירות חדש שנקרא InfiniVerse שהוא שירות ניטור וניתוח מבוסס AI שאוסף מידע על מערכות האחסון של הלקוח ומסוגל לתת לו התראות בזמן אמת על נפחים, ביצועים, בריאות החומרה שלו, שדרוגי תוכנה מומלצים וכל מני דברים כאלו אבל הדבר המגניב באמת הוא התראות ממוקדות על שינויים בזמן אמת במצב המערכת שלו כמו למשל, אם אנחנו רואים ירידה חדה ומהירה ביחס הדחיסה על מערכת מסויימת, אנחנו מסוגלים להראות את זה ללקוח בזמן אמת, במקרה הטוב זה אומר שהלקוח שינה באופן יזום את סוג המידע שהוא מאחסן, נגיד עבר מקבצי טקסט לקבצי תמונה שכמובן נדחסים פחות, במקרה הרע זה אומר שהלקוח נמצא כרגע תחת מתקפת קריפטו כל שהוא שמצפינה לו את המידע וכדאי לפעול מהר לטפל בזה. לא רע הא?!

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

שלכם,

ניר מליק

bikeshedding , ESXi on ARM and keeping the momentum

bikeshedding

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

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

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

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

ESXi on ARM

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

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

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

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

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

Momentum

הבוקר בטוויטר מצאתי נקודה אחת שאולי קושרת את שני החלקים של הפוסט. מישהו שאל את השאלה הבאה:

וג'סי פראזל ענתה:

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

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

ניר מליק

חדר השרתים לא ימות בקרוב

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

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

שימו לב להגדרה של Amazon ל serverless

" Serverless is the native architecture of the cloud that enables you to shift more of your operational responsibilities to AWS"

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

וורדלי מביא כאן הגדרה רחבה יותר:

an event driven, utility based, stateless, code execution environment

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

utility based – אנחנו משלמים רק על מה שאנחנו צורכים

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

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

גרטנר, עננים, פלטפורמות ולמות

דילמה מוסרית

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

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

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

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

גרטנר

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

gartner

Pure מכריזים על פתרון חדש לעולם ה hybrid cloud

לאחרונה קצת ניגחתי את Pure והנה שוב הזדמנות לפרגן במקום. בשבוע שעבר הם הכריזו על פתרון חדש  שמאפשר להריץ את מערכת ההפעלה שלהם גם על גבי תשתיות AWS וככה לספק חוויה דומה (אותם API) באתר הלקוח או בענן. יכולת זו מצטרפת ליכולת הקיימת לבצע טירינג של סנפשוטים לענן (יכולת שנקראת אצלם CloudSnap) שדומה ליכולת של NetApp שנקראתFabric Pool.

כתבתי כבר על החשיבות של hybrid cloud ושל data mobility כמו גם data governance. הסיפור של פיור מצטרף כאן לסיפור ה Data Fabric של NetApp וכמובן לסיפור ה Neutrix שלנו באינפינידט. הפער בין חדר השרתים והענן הוא האתגר הגדול של עולם ה IT כי לפחות בעתיד הנראה לעין גם פתרונות On Premises וגם פתרונות Cloud יחיו זה לצד זה ולכל אופציה יהיו היתרונות והחסרונות שלה.

אמזון סנובול אדג' חדש

גם באמזון, שיצרו למעשה את עולם ה Public Cloud ומובילים אותו בבטחה גם מבחינת הגודל וגם מבחינת החדשנות, רואים את הפער ומספקים פתרונות שונים כדי לצמצם אותו. כתבתי בעבר על שירותי המיגרציה של גוגל והזכרתי שם את ה Snowmobile של אמזון והשבוע במסגרת RE:Invent הם הכריזו על מוצר חדש באותה סדרה או למעשה בסדרה הקטנה יותר שנקראת Snowball Edge. המוצר החדש כולל יכולות מחשוב חזקות יותר ותמיכה בכרטיסי האצה גרפיים GPU. הסדרה הזו למעשה תוקפת את הפער מהכיוון ההפוך ומאפשרת לפתח כלים בענן ואז "להביא" אותם, פיזית, בתוך מארז מוגן ומוקשח, אל חדר השרתים או איפה שצריך אותם כדי שירוצו בפועל.

פלטפורמות ובהמות משא דרום אמריקאיות

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

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

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

יש כאן למשל כלי שכל חברה, או מחלקה בתוך החברה, יכולה לאמץ לעצמה גם בלי לזעזע את כלל המבנה הארגוני או להוציא תקציבים גדולים, הכלי נקרא 5 הלמות. סתם הוא נקראה 5 הלמה, the 5 whys, ובדוגמא שלפנינו, אמזון משתמשת בכלי הזה כדי לבצע תחקיר למציאת שורש הבעיה, Root cause Analysis. מספרים לנו שעובד אחד פצע את האצבע על מסוע.

למה הוא פצע את האצבע? כי היא נתפסה במסוע

למה האצבע נתפסה במסוע? כי העובד ניסה לתפוס את התיק שלו

למה הוא ניסה לתפוס את התיק שלו? כי התיק היה מונח על המסוע והמסוע פתאום התחיל לפעול

למה התיק היה על המסוע? כי העובד השתמש במסוע כשולחן

למה העובד השתמש במסוע כשולחן? כי הוא היה צריך להניח את התיק ולא היה במקום שולחן

פתרון לבעיה – לוודא שיהיו שולחנות במיקומים נחוצים או לפחות שולחנות מתקפלים ניידים זמינים למי שצריך אותם

הגירה של שירותי קבצים בשרת חלונות 2019 החדש

בתחילת הפוסט הזכרתי שהייתי בקוריאה בשבוע שעבר ואחד הדברים שדיברנו עליהם הרבה היה מיגרציות. לקוחות בכל העולם רגילים שפרויקט מיגרציה של סטורג' זה פרויקט גדול מסובל ויקר והרבה פעמים גם מסוכן. עבור רובם זה לא נכון עבור ככה הם רגילים ובשוק מסורתי כמו קוריאה זה נכון כפליים. דיברנו הרבה על העובדה שעם כלים כמו VMware vSphere Storage vMotion או Live Migration המקביל ב Hyper-V, לקוחות בכלל לא צריכים עזרה בשביל להעביר באופן קל וחלק את מרבית חדר השרתים שלהם ממערכת אחסון אחת לשנייה.

כמו מהשמיים גיליתי שאפילו מיגרציה של קבצים משרתי Windows זה לא מה שהיה פעם. מיקרוסופט תומכת היום במיגרציה של קבצים משרתי Windows ישנים, אפילו שרתי 2003 שכבר לא נתמכים רשמית, אל שרתי Windows 2019 פיזיים או וירטואליים או לשירותי הקבצים של Azure באמצעות כלי מובנה שנקרא Storage Migration Service או SMS וכן, השירות הזה מובנה בשרתי 2019 ושרתי WAC (Windows Admin Center).

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

טוב, יצא פוסט עמוס מכל טוב,

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

ניר מליק

סופרמן, אנגלית, דקדקנות מיותרת והצפנות

אני מדבר שתי השפות

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

מחר אני מתחפש לסופרמן

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

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

 

מכירים את הקלישאה של dress for the job you want? ובכן לא בכל מקום זה יתקבל בעין יפה אם תתחילו לבוא למשרד בגלימה של סופרמן אבל ההרחבה של הקלישאה הזו כמו שג'ו אוניסיק מציג בסרטון שלו היא שאתם יכולים להתחיל לעשות את התפקיד שאתם רוצים כבר עכשיו, בלי משא ומתן, בלי הגדרות תפקיד מחדש ובלי תארים מפוצצים, רואים משהו שצריך להיעשות בחברה או שצריך להיעשות טוב יותר? תתחילו לעשות אותו. ברוב המקומות, תחת רוב המנהלים, זה יעבוד ולא רק שזה יעבוד, אנשים מסביבכם יסתגלו מהר מאד ואם תיראו כאילו זה התפקיד שלכם לעשות משהו, אז הם פשוט יקבלו את זה כעובדה, זה התפקיד שלכם לעשות את מה שאתם עושים.

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

גדילה זה לא תמיד חיובי

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

takethemoneyandrun

זמינות חלפים ושאלות מיותרות

היום שאל אותי לקוח קוריאני מה ה MTBF של הדיסקים שלכם? זה הזכיר מקרה מלפני כמעט שמונה שנים כשהייתי יחסית חדש בחברת אנקור, לקוח מכפר נטר גרם למנהל המכירות של אנקור להתקשר אלי באחת עשרה וחצי בלילה, אתם מבינים EMC השתמשו אז בדיסקים מסוג eMLC אבל NetApp שאנחנו ייצגנו השתמשו רק ב MLC ובגלל זה אנחנו עומדים להפסיד את העיסקה. נו בחיאת. מצד אחד, יש ערך לירידה לפרטים ומצד שני יש חובה לדעת את ההבדל בין עיקר לתפל. אנחנו באינפינידט היחידים שמתחייבים בכתב לשבע תשיעיות של זמינות על המערכות שלנו, ואנחנו עושים את זה דווקא עם רכיבי החומרה הכי פשוטים שיש בעולם האנטרפרייז, אנחנו מספקים סדר גודל שלם מעל המתחרים הקרובים שמציגים שש תשיעיות בלי לזרוק כסף על חומרה יקרה ומורכבת מדי, שני סדרי גודל מעל הסטנדרט המקובל בתעשייה של חמש תשיעיות ושלושה סדרי גודל מעל ספקיות הענן הגדולות בלי להיגרר לטרנדים הכי חמים בתעשייה סתם ככה לשם הטרנדיות ועדיין מישהו רוצה לדעת שהדיסק הבודד שאמכור לו בתוך המערכת יכול להחזיק 2,000,000 שעות עבודה רציפות בממוצע. לך תבין. ואם הממוצע הוא רק 1,800,000 שעות עבודה רציפות לדיסק בודד איזה השלכה יש לזה על הביזנס שלך אדוני הלקוח?

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

המשמעות של תלות בחומרה והדרישה להצפנה לגבי מודלים עסקיים

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

כמו תמיד שמח לשמוע פידבק על מה שכתבתי אז אל תהיו ביישנים!

שלכם,

ניר מליק

פוקה-יוקה, קאיזן ומכרזים מחורבנים

סיפרתי לכם פעם כמה אני שונא מכרזים?

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

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

אצלנו, מאד מקובל לבצע תהליך אפיון מאד מפורט כולל שימוש בכלי אפיון כמו למשל VMware Capacity Planner או ניתוח קבצי NAR של מערכות EMC, Perfstat במערכות NetApp וכו'. אנחנו לאחרונה משתמשים קצת ב mitrend כדי לאסוף ולנתח ביצועים של מערכות שונות וליצר גראפים נוחים לשימוש.

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

במזרח נתקלתי לאחרונה בכמה מקרים שבהם אין שום דרישת ביצועים במכרז, כלום. נפח אחסון נדרש וזהו. עכשיו מתחיל החלק האומנותי, בחלק מהמקרים אין שום דבר אחר, ואז אני חושב לעצמי שמי שפרסם את המכרז פשוט לא מבין בסטורג', קורה. במקרים אחרים רואים משהו אחר, והוא מטריד הרבה יותר, מישהו מפרסם מכרז ללא דרישת ביצועים אבל עם מפרט מאד מדויק של מערכת האחסון שהוא דורש, כמו נניח דגם מעבדים ספציפי או יכולת גידול לכמות בקרים גדולה פי 20 ממה שהוא דורש ביום הראשון. במקרים כאלו ברורה כוונת המשורר, הרי אלא אם אתה יצרן מערכות אחסון בעצמך, אין לך דרך ריאלית לבדוק את ההשפעה על הביצועים בשימוש במעבד 3GHz לעומת שימוש במעבד 3.2GHz  וגם בואו נהיה הוגנים, בניגוד למה שמראים לנו במצגות בכנסים, הסיכוי שאנחנו נישאר עם אותה מערכת בדיוק גם בגידול פי 20 לא סביר כל כך, הרי גם אם אתה בר מזל והעסק שלך אכן גדל פי 20 בטווח הנראה לעין, הארכיטקטורה שלך תשתנה עוד מיליון פעמים בדרך כדי לתמוך בכזה גידול, שום דבר שעובד ב1 לא עובד ב 20 as is, אז למה לקשקש?!

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

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

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

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

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

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

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

עלו והפוקה-יוקו כולכם! קאיזן על בתיכם ומשפחותיכם ומועדים לשמחה!

שלכם,

ניר מליק