לייב בלוגינג – Strategic Cloud Migration – CMS, Microsoft & IsraelClouds

ממשיך ברצף הלייבים והפעם כנס של CMS ו IsraelClouds ביחד עם מיקרוסופט

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

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

מה זה Datacenter? חוות שרתים

מה זה region? אתר הבנוי לפחות משני datacenter או יותר נכון להגיד שני availability zones שמייצגים לפחות datacenter אחד

מיקרוסופט מקימה region כאן בארץ בקרוב והיא הראשונה מבין הספקיות הגדולות לעשות את זה

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

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

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

איך בכלל מתחילים מיגרציה לענן?

שלב ראשון לבצע הערכה ואפיון, assessment, כדי להבין מה יש לנו בכלל להעביר אל הענן

עוברים לדוגמאות והדגמות עכשיו על ידי דין עובדיה מ CMS

דמו של תהליך מיגרציה ולאחריו דמו של virtual desktop של מיקרוסופט

Azure migrate מאפשר לנו להוריד מ Azure כלי הגירה אל סביבת ה Hyper-V שלנו

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

לאחר ההתקנה והאוטנטיקציה אנחנו צריכים להוסיף את ה Hyepr-V Host שלנו ואז יבוצע הליך discovery אוטומטי להצגת המכונות הוירטואליות שיש לנו על ה Host

עכשיו ניתן לבצע תהליך Assessment אוטומטי כדי להקל עלינו בבחירה של סוג ה Cloud VM שלנו

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

הרפליקציה מוצפנת כדי להגן על המידע שלנו In Transit.

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

בשלב הזה עוברים להדגים virtual desktop אבל end user זה קצת פחות התחום שלי

סך הכל אירוע נחמד ברמת מבוא לענן, תודה רבה לכל המנחים!

ואפילו יש כיבוד כמו כנס אמיתי:-) מי שנשאר עד סוף האירוע מקבל שובר לפיצה או לוולט, טאצ' נחמד!

SalesForce Live Israel

מצטער אבל לא היה לי זמן להשתתף בצורה פעילה אבל ה Key Note היה מאד מקצועי ומעניין והמוצר של Bonobo שהוצג על ידי אפרת רפופורט נשמע סופר מגניב

כרגע אני מקשיב לסשן SMB שמונחה על ידי מורן שור (גילוי נאות מורן היא חברה טובה)

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

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

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

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

ניר מליק

לייב בלוגינג – Lift and shift an Apache Kafka cluster to Amazon MSK Floor28 Webinar

יאללה פעם שלישית אני צורח!

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

https://www.linkedin.com/posts/strati-georgopoulos_how-to-use-an-old-phone-as-a-home-security-ugcPost-6710808561468923904-M1dg

יאללה מתחילים

MSK הוא שירות לניהול קלאסטרים של קפקא

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

גרסאות נתמכות 1.1.1 2.2.1 2.3.1 2.4.1

השירות מספק תאימות מלאה לקפקא ולשירותים הסטנדרטיים באקו-סיסטם של קפקא כל עוד הם תומכים ב API של קפקא בעצמם

השירות מספק ברוקרים ו Zoo-קיפרים

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

השירות מספק הצפנה at rest ומתממשק לניהול מפתחות ההצפנה על ידי KMS

קיימת תמיכה גם בהצפנה ברמת TLS עבור data in transit

תאימות לרגולציות כמו HIPPA, PCI וכו'

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

הקלסטר תומך בזמינות של 99.9% ומוגדר על 2 או 3 AZ's בהתאם לדרישת הלקוח

AWS טוענים לחסכון של 40% בעלות התחזוקה מול עלות תחזוקה של קלאסטר עצמאי

אין תשלום על התעבורה בין הברוקרים והZOO-קיפרים

עכשיו למיגרציה עצמה –

למעשה כל כלי מיגרציה קיים שאתם מכירים יכול לעבוד עבורכם גם במעבר אל MSK

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

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

בדוגמא השניה יש צורך לשמר את המידע וכאן באה המלצה להשתמש ב Mirror Maker v2

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

kafka Connect משמשת אותנו להזרים מידע בין קלאסטרים ויכולה גם להזרים מידע מקלאסטרים מסוגים שונים כמו קסנדרה וכו'

בשלב הזה נפל לי החשמל בבית, נקווה שיחזור מהר ונוכל להמשיך בוובינר ובעדכון הלייב של הבלוג 🙂

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

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

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

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

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

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

ניר מליק

Mini Post – podcast and community recommendation – PreSales Collective

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

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

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

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

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

זה הכל הפעם,

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

שלכם,

ניר מליק

לייב בלוגינג AWS Pricing Models Floor28 Webinar

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

https://floor28.co.il/

ההדרכה הפעם מתרכזת בשירותי סטורג', איזה כיף!

שירותי האחסון מחולקים ל3 קטגוריות עיקריות, Block, File ו Object, מוקד ההדרכה הפעם הוא שירות הבלוק, EBS וקצת על RDS.

שירותי File כוללים את EFS (שירות NFS) ואת FSX לשירותי קבצים של windows או luster. FSX משתמש ב S3 ב backed ככה שהוא מאד cost effective וכן highly available. ל EFS יש שני טירים של אחסון, סטנדרט (8 סנט לגיגה לחודש) וטיר של infriquent access בעלות של 2.5 סנט לגיגה לחודש. FSX עולה רק 1.3 סנט לחודש ל סינגל AZ או 2.5 לגיגה לחודש ל multi-AZ. אגב FSX תומך באינטגרציה ל Active Directory כיוון שהוא כאמור מכוון לסביבות windows. לא תאמינו אבל השירות הזה, FSX, כולל גם deduplication שאמור לחסוך כ 505 מעלות האחסון בשירות זה. זה די דהים כי זה נוגד את הקונספט של שירותי הענן בדרך כלל שמחייבים על נפח מוקצה בכלל, למה להם לחסוך לנו בנפחים?

עיצה ראשונה לחסכון בעלויות EBS היא למחוק volumes שאינם בשימוש, נשמע טרוויאלי אבל מסתבר שיש הרבה משתמשים שמוחקים את ה EC2 Instance שלהם אבל לא מוחקים את ה EBS שמחובר אליהם. ניתן למנוע טעויות כאלו אם בהקמת הEC2 אנחנו מגדירים גם delete on termination עבור ה EBS שהוגדרו עבורו, יש לישם לב שזה אכן מה שאנחנו רוצים כדי למנוע מצב הפוף של מחיקת מידע בטעות במחיקה של instance.

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

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

לגבי snapshots בגדול הם ממליצים שוב את אותה עיצה ראשונית של למחוק סנפשוטים ישנים שאין בהם צורך יותר ושכדאי ליישם את ה retention policy שלנו על ידי יכולת life cycle management.

עוברים עכשיו ל S3

S3 standard, S3 intelligent tiering, standard IA, One Zone IA, Glacier, Deep Archive, אם בוחרים את השירות הנכון ניתן לחסוך עשרות אחוזים בהאתם לגישה בפועל שלנו אל המידע, ככל שהמידע "קר" יותר ניתן לאחסון אותו על שכבה נמוכה יותר ולחסוך מלא כסף אבל צריך לזכור שיש עלויות למשיכת מידע בטירים הזולים באמת ויש גם מינימום של זמן שמירה ומינים יחידת נפח לחיוב.

יש לשים לב שלכל אובייקט יש 8Kb ועוד 32Kb של overhead לmetadata. ה 8Kb הראשונים מחוייבים לפי Tier יקר גם אם המידע נמצא ב Tier נמוך.

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

שירות storage analysis עולה גם הוא כסף, 10 בסנט למליון אובייקטים לחודש

שירות שמוצג בדמו הוא שירות trusted advisor שיודע להראות לנו under utilized EBS volumes. ניתן להשתמש בלמבדה להריץ בדיקה אוטומטית של ווליומים שאינם בשימוש מעל פרק זמן מוגדר מראש.

כשהדגימו כלים של S3 קצת איבדתי ריכוז אבל הכלים נראים יעילים סך הכל

זה הכל להיום, תודה למי שעקב כאן ותודה לצוות Floor 28

כמו תמיד אשמח לפידבק,

ניר מליק

לייב בלוגינג EC2 Image Builder Floor28 webinar

לייב בלוגינג? למה לא, מזמן לא עשינו את זה

הפעם אני בהדרכה של Floor28 על EC2 Image builder, שירות חדש לבניה של גולדן אימג'ז:

מה זה בכלל גולדן אימג'?

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

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

  1. אנחנו רואים שהרבה לקוחות מתקשים לבנות ולנהל אימג'ים טובים – חוסר בידע ומשאבים
  2. יש חברות שיש להן ידע אבל בוחורות שלא לתחזק מערכות אוטומציה לצרכים כאלו לצד מערכות Ci/CD שכבר יש להן
  3. קושי בבדיקת אימג'ים לפני עליה לאוויר
  4. השפעה קשה על פרודקשן אם מפספסים תקלות לפני שימוש באימג' חדש

מה הלקוחות ביקשו?

  1. לקוחות ביקשו מאמזון שירות אוטומטי לבניה של אימג'ים שלא יידרוש שימוש בקוד
  2. ביקשו להשתמש ביכולות של אמזון לבדיקות אוטומטיות של אימג'ים
  3. אימג'ים בטוחים לפי סטנדרטים מקובלים בתעשיה ויכולת להוסיף סטנדרטים ספיציים ללקוחות לפי תחום העיסוק שלהם
  4. הפצה של אימג'ים בין חשבונות ובין ריג'נים
  5. יכולת לבנות ולהתשמת באימג'ים האלו גם On-Prem

אז מה זה השירות החדש?

  1. שירות אוטומציה מבוסס GUI
  2. יכולת בדיקות
  3. שיפור זמני uptime

השירות תומך גם בווידוז 212R2 ומעלה וגם בלינוקס ובכל הפצה של לינוקס שנתמכת ב AWS

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

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

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

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

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

מן הסתם צריך לתת לשירות עצמו הרשאות IAM כדי שיוכל לרוץ בעצמו

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

צריך להגדיר דיפולט סאבנט וסקיוריטי גרופ (לא חובה)

תהליך בניית האימג' כולל כמובן לוגים כדי שנוכל לנתח במקרה של כשלון בבניה של אימג'

אפשר לקשר את שירות הפצת הרשיונות שלנו לתהליך בנית האימג' אם יש לנו צורך כזה ברקע מי שמבצע את התהליך זה SSM או Systems Manager ככה שאפשר לראות דרכו את תהליך הבניה עצמו

זהו, סיימנו, סה"כ די straight forward וברור

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 עבר את ההקשחה הנדרשת.

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

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

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

ניר מליק