פגישות מכירה וראיונות עבודה – טכניקה והכנה הם המפתח!

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

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

be prepared

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

לפעמים אין ברירה, המצגת הוכנה על ידי מישהו אחר בארגון או התקבלה מגורם חיצוני ואז חובה לעבור עליה ולבדוק מראש כל מילה או ראשי תיבות שאנחנו לא מכירים. הסיבה לכך פשוטה מאד, אם אני לא מכיר, חובה להניח שגם הלקוח לא מכיר. והוא ישאל. ואני אגמגם. והוא יתבאס. ואני אתבאס. אם בקורות החיים שהגשת כתוב MPLS  ואתה לא יודע שזה multi-protocol label switching, הורדת לעצמך את הסיכוי להגיע לשלב הבא בו ניתנת לך הזדמנות להסביר מה זה MPLS ומה עושים עם זה. אם אתה לא יודע את ראשי התיבות BGP או OSPF, הורדת לעצמך את הסיכוי להגיע לשלב הבא בו ניתנת לך ההזדמנות להסביר מתי תבחר ב border gateway protocol ומתי עדיף להשתמש ב open shortest path first ולהוכיח שאתה מסוגל לנהל שיחה אינטליגנטית בנושא זה עם לקוח פוטנציאלי.

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

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

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

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

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

  1. "דבקות במשימה לאור המטרה" – פגישה, כמו גם ראיון עבודה, היא משימה כמו כל משימה, צריך להתכונן ולקבוע מטרה לאורה מתכווננים ומתכוננים, אין טעם להכין מצגת על אחסון לפגישה בנושא תקשורת. אפשר וכדאי להתאים את מסמך קורות החיים שלכם למשרה הספציפית עליה אתם מתמודדים ובחו"ל רווח הנוהג להכין cover letter, מסמך מלווה לקורות החיים שנתפר למידותיו של מעסיק פוטנציאלי
  2. "קשה באימונים קל בקרב"- חובה להכין שיעורי בית, אם הפגישה היא בנושא VDI חייבים למשל לדעת מה ההבדל בין persistent ובין non-persistent, שליטה במושגי יסוד וז'רגון היא חובה ולא רשות והרבה יותר קשה "לעקוף" אותם בשיחה בלי להישמע חסרי הבנה בתחום
  3. "סיור מקדים" – חובה לסמן מראש נט"בים (נקודות טורפה בטיחותיות) ולהכין להם מענה- למה אתה עוזב את מקום העבודה הנוכחי? למה אתה לא מועסק כרגע? למה עברת הרבה מקומות עבודה בשנים האחרונות? אלו שאלות שיעלו בראיון, אל תאלתרו עבורן תשובות במקום, הן לא אמורות להפתיע אתכם אם קורות החיים ששלחתם אכן קרו לכם באמת
  4. "מה שעשינו ב48" – נכון, לא בדיוק ז'רגון צבאי אבל תופס כאן בכל אופן, צריך להכין סיפורי הצלחה, לקוחות ומראיינים אוהבים שמספרים להם איך ואיפה הצלחתם בעבר, איפה ביצעתם כבר פרויקט גדול ומרשים בהצלחה? איפה כבר נתקלתם באתגר כמו זה הצפוי ללקוח שלכם? איפה כבר ביצעתם משימה דומה למשימות שצפויות לכם בתפקיד עליו אתם מתמודדים? זה לא חייב להיות 100% מקרה זהה אבל זה צריך להיות משהו מספיק קרוב בשביל להעביר את המסר שאתם יודעים לחשוב תוך כדי תנועה ולהתאים עצמכם לאתגרים חדשים
  5. "עלי קרב" – רוח לחימה או לפחות חיוך קטן וגישה חיובית תמיד עוזרים, גם שיחה קשה יכולה להיות חיובית ואם אתם עוסקים במכירות ככל שהיא יותר קשה ככה יותר צריך להשתדל להשאיר אותה חיובית ועם הפנים קדימה לקראת פתרון

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

חלפון

שלכם,

ניר מליק

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

מיני פוסט – google takeout

מיני פוסט – google takeout

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

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

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

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

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

ובכן כאן באה לעזרתנו האפשרות ליצירת קובץ ארכיון שנקראת Takeout.

ניתן לגשת לכלי הנהדר הזה באמצעות הקישור הישיר https://takeout.google.com או דרך הגדרות המשתמש שלנו תחת האפשרות control your data

control

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

choose

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

select

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

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

done

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

שלכם,

ניר מליק

*סנכרון – העתקה חוזרת  המבצעת השוואה בין מקור והעתק

גיבוי – יצירה של העתקים בלתי תלויים במידע המקורי

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

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

bull

דימוי האוטובוס והפרארי משמש את היץ להסביר את ההבדל בין רוחב הפס, Throughput, ובין זמן התגובה, Latency. אני עובד בחברת ווי-אנקור ואנחנו מוכרים מערכות אחסון של 3 יצרנים עם התמקדות מאד ברורה ומובהקת במוצרי NetApp. לחברת NetApp לבדה 3 קווי מוצר עיקריים של מערכות אחסון וסה"כ 5* מוצרי אחסון שונים, FAS, All Flash FAS, E-Series, All Flash E-Series, SolidFire. מדובר במוצרים שפותחו על ידי שלוש חברות שונות, במקומות שונים בעולם, בשלבים שונים באבולוציה של עולם האחסון ובפניה לקהל יעד שונה לחלוטין. לכולן יש "מגבלה" משותפת, עבור כולן אין מספר זהב, אין תשובה חד ערכית לשאלה "כמה IOps המכונה נותנת". אין קסמים בעולם הזה, אופי הפעולה מול מערכת האחסון משפיע על כמות הפעולות שהמערכת תדע לספק בפועל, קריאה וכתיבה אינן פעולות זהות, פעולה קטנה אינה זהה לפעולה גדולה.

כדוגמא לעבודה ש"מגבלה" זו אינה "מגבלה" של מערכות האחסון של יצרן ספציפי אפשר לחשוב פשוט על רשתות תקשורת. קישור יחיד של 10Gb יכול, באופן די ברור, להעביר מקסימום 10Gb. אם משתמשים ב jumbo frames אז כמות הפעולות שנדרשות להעביר 10Gb קטנה יותר ולכן כל הרכיבים "מתאמצים" פחות אבל רוחב הפס לא עולה. כתוצר לוואי, מה שכן יכול לעלות זו נצילות רוחב הפס הידועה בכינוי Goodput, להבדיל מרוחב הפס, Throughput. רוחב הפס מגדיר את כמות המידע המקסימלית שעוברת בקו בכל רגע נתון, הנצילות מגדירה את כמות המידע האפקטיבי העוברת בקו אחרי שהורדנו Error, discard, re-transmit  וכו'.

דוגמא נוספת היא בעבודה של מעבד בודד, CPU. המדד הנפוץ לעוצמת המעבד הוא מהירות השעון הנמדד ב GHz וכמות הליבות כלומר מעבד של 12 ליבות 3Ghz נחשב חזק יותר מאשר מעבד בעל 8 ליבות במהירות 2.5GHz. לפעמים משמיטים את העובדה שגם כאן, לא כל הפעולות זהות, לא כל פעולות החישוב זהות במורכבותן ויש משימות שלוקחות יותר זמן מאחרות ולכן המדד של מהירות השעון מגדיר כמה המעבד חזק אבל כנתון יחד זה נתון לא מספק לגלות כמה פעולת חישוב נקבל.

cpu

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

הדבר נכון גם לכלים בתוך מערכות האחסון, גם לכלי תוכנה יש את אותה "מגבלה", מה שעושים איתם גוזר את התפוקה שלהם בפועל. יחס של ביטול כפילויות למשל, De-duplication, או של דחיסה, Compression, הינו פועל יוצא של סוג המידע המאוחסן. מידע דחוס מראש לא יהיה ניתן לדחיסה ביחס של 1:4 גם בשימוש באלגוריתם דחיסה מאד אגרסיבי, מידע שרובו מכיל תמונות לא יכיל בלוקים כפולים ביחס של 1:6 גם בשימוש באלגוריתם מאד אגרסיבי עם גודל בלוק קבוע או משנה.

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

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

שלכם,

ניר מליק

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