Pure-in-the-middle attack, Vast data and tools for VMware admins

Pure-in-the-middle attack

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

לפני שבוע וקצת, חברת Pure הכריזה על פתרון חדש שהוצג כפתרון פורץ דרך ומאפשר ביצוע הצפנת נתונים מקצה לקצה ללא נטרול טכנולוגית ביטול הכפילויות המובנית במערכות היצרן.  האמת היא די רחוקה מזה, למעשה מה שמוצע כאן בפתרון הוא שילוב של שני כלים, הראשון הצפנה ברמת Host והשני הצפנה ברמת מערך האחסון, הבעיה היא שאלו שני כלים נפרדים והתהליך כולל פתיחה של ההצפנה והצפנה מחדש בעת כתיבה ושוב בעת קריאה, מתבצעת כאן החלפה של ההצפנה ובאמצע שלב של clear text כלומר, מי שיטמיע את הפתרון, יטמיע לעצמו מתקפה של men in the middle קלאסית.

image credit to blocksandfiles.com

Vast storage to the rescue?

במסגרת storage field day האחרון, נחשפה באופן מסודר חברת Vast storage. הם הציגו סוג חדש של טכנולוגית חסכון בנפח והיו לי ציפיות גדולות מהם ספציפית בעניין של חסכון בנפח עבור מידע מוצפן כי כריס מלור האהוב על כולנו כתב שהם מסוגלים לייצר חסכון של 1:5 גם על מידע שכבר עבר חסכון של 5:1 על ידי קומוולט. במקום לבצע דחיסה וביטול כפילויות, הם מציגים חישוב חדש שמתבסס על בלוקים לא זהים אלא דומים. כשהמערכת הכי קטנה שהם מתכוונים למכור היא פטה שלם של מידע ויכולה לגדול לפטות רבות, הסיכוי למצוא בלוקים דומים, עולה. הם מבצעים Hash על כל הבלוקים ולכל האש כזה נותנים מספר מזהה לפי אלגוריתם חיפוש הדמיון שלהם. אם יש בלוקים שחולקים את המספר המזהה, הם מקובצים ביחד ואז נשמר רק אחד מהם כבלוק ייחוס ונוצרות דלתות כדי לייצג את שאר הבלוקים במקבץ. נשמע ממש מגניב אבל כמו שרנן אומר, גם הם לא יכולים לספק חסכון משמעותי במידה והמידע מוצפן, אולי אם הצפנתם מידע דומה באלגוריתם הצפנה דומה עם מפתח הצפנה דומה.

אגב רנן חלק שמעביר כאן את ההדרכה, מייסד ומנכ"ל החברה ולשעבר VP R&D של ExtremeIO מדליק את הקבוצה בסביבות דקה 6:05 עם ההערה שלא צריך יותר לגבות, סנפשוטים זה מספיק. אני כמובן חולק עליו אבל אני לא איש R&D כמוהו ומה שעובד במחקר לא תמיד עובד בשטח.

תראו למשל את מה שקרה בשבוע שעבר לענקית הפלדה Norsk Hydro, חברה שמעסיקה 35,000 איש שעברה לעבוד עם דפים וכלי כתיבה אחרי שמערך המחשוב שלה הושבת כליל אחרי מתקפת Ransom והיום מודיע ש"רבית" השירותים שלה חזרו לתפקוד, רק חלק ואחרי שבוע!

נקודה נוספת ששווה התייחסות בקליפ זה ה shout out של כריס אוונס עלינו, אינפינידט, תודה כריס! (דקה 7:35)


Renen Hallak, CEO introducing Vast at #SFD18

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

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

screenshot from the #SFD18 video above

כלים שימושיים בסביבות VMware

השנה התקבלתי שוב לתכנית vExpert לשמחתי הרבה והיה לי כיף לגלות שעדיין יש לי מה ללמוד גם ברמת הבסיס. באחד הפרקים האחרונים של Virtually speaking סקרו את עשרת הכלים הכי שימושיים לאדמינים של סביבות ESXi ואלו שלושה כלים שלא הכרתי ונראים לי מאד שימושיים:

ONYX – אוניקס הוא תוסף שמתרגם פעולות מהממשק הוובי של vCenter לקוד powercli. נראה לי כמו כלי סופר יעיל לגשר בין כלי GUI אינטואיטיבי ובין עולמות ה API בהם אנחנו אשכרה צריכים לדעת מה אנחנו רוצים לעשות. הפלט כמובן ניתן לעריכה והתאמה ולכן יכול לשמש אותנו כטמפלט מעכשיו הלאה

HCIBench – אם אתם זוכרים, כבר כתבתי כאן פעם על VDBench, הכלי המועדף עלינו לבדיקות ביצועים. מסתבר שיש פלינג נחמד שמבצע auto deployment לסביבה מבוססת VDBench להרצת בדיקות ביצועים של HCI, ממש מגניב!

שני הכלים האלו הם פלינגים, כלים ותוכנות שלא נתמכים רשמית על ידי VMware אבל כן מפותחים ונתמכים על ידי הקהילה ועובדי VMware, משהו כמו code.infinidat.com שלנו רק, מה לעשות, גדול עשיר ומרשים יותר.

הכלי השלישי הוא הכלי האהוב עלי ברשימה, או יותר נכון הכלי שהכי הרשים אותי.

As-Built-Report – יא וורדי איזה כלי, ממש התביישתי שלא הכרתי אותו עדיין, כלי קהילה, open source, שמאפשר לייצר דוחות מותאמים אישית על כלל סביבת ה IT הקיימת כולל vSphere, NSX, Cisco UCS, Nutanix, Pure, ממש שווה להעיף מבט על הכלי.

שויין, זה מה שיש לי להפעם,

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

אה, ואגב, אני מחפש חבר לצוות שלי לתפקיד Technical Advisor שדומה קצת לתפקידי TAM/TAC  בחברות אחרות או  תפקידי Success בסטארט-אפים מגניבים אז אם אתה מתאימים או מכירים מישהי\מישהו, תהיו חברים!

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

ניר מליק

מודעות פרסומת

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 דולר לזוג. מביך, מעצבן ומתסכל.

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

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

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

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

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

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

שלכם,

ניר מליק

נגרי כדורגל ותיאום ציפיות

Yes I'm a vExpert!

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

צחוק בצד, זה נעים לקבל הכרה וכבוד להשתייך לרשימה מכובדת של מקצוענים. הצטרפו אלי גם אתם! ליצרנים רבים יש תוכניות דומות ואתם יכולים לבחור מי היצרן\טכנולוגיה הקרובים ללבכם, Veeam Vanguard, VMware vExpert, Cisco Champion, NetApp United  וכו'.

אגב, כל התוכניות האלו נקראות בלעז advocacy programs ואני לא בטוח איך לתרגם את זה לעברית, יש לכם רעיונות?

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

vexpert

נגרי כדורגל

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

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

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

Maradona_1986_vs_italy

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

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

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

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

תיאום ציפיות

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

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

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

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

ספרו לי מה דעתכם אני צמא למשוב!

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

ניר מליק