-->

יום חמישי, 31 במרץ 2016

למה scheduler בצד-שרת - מפחיד אותי? (כתב אורח)

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

איך מתחילה שרשרת פרוצדורלית שכזו? ישנן כמה אפשרויות:
  1. פונקציית ה main והדומות לה - כלומר: קוד שיתחיל להתבצע מיד בעליית האפליקציה.
    אם מדובר בשגרת אתחול של תהליכים אחרים, או עצם ה business logic ש"יחיה" לאורך כל חיי האפליקציה.
  2. טיפול ב HTTP request (או פרוטוקול אחר כלשהו) - קריאה מבחוץ, ביצוע משימה כל שהיא, עם או בלי ערך מוחזר.
  3. האזנה לשירות כלשהו ותגובה למידע שמגיע ממנו - לדוגמה: אפליקציה שמאזינה על עסקאות מט"ח ומבצעת לוגיקה מוגדרת מראש על כל קבלת עסקה שכזו.
  4. שימוש ב scheduler, פנימי או חיצוני לאפליקציה - למשל: cron job שבשעה מסוימת, או ביום מסוים בשבוע או כל פרק זמן מוגדר מראש יתחיל תהליך כלשהו.

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

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

לפני שנסקור את הבעיות האפשריות, בואו נזכר לאילו צרכים אנו לרוב משתמשים ב Scheduler.
הנה תיאור של כמה משימות שהוכנסו ל scheduler שנתקלתי בהן בשנים האחרונות (בחברות שונות ובצוותים שונים):
  1. תחזוקת ה DB (מחיקה של רשומות שפג תוקפן וכד').
  2. שליחת דוחות יומיים.
  3. פנייה לשירות חיצוני כדי לעדכן מידע סטטי של המערכת פעם ביום.
  4. ביצוע סיכום של מסגרת זמן מסוימת מתוך דאגה לביצועים.
    לדוגמה: להתעורר כל דקה ועל סמך מינימום ומקסימום של שער היורו-דולר לבצע פעולה מסוימת (במקום להגיב לכל שינוי ברמת השנייה ואף פחות מזה).
  5. הפעלת לוגיקה עסקית שקשורה לשעה מסוימת - לדוגמה (מומצאת לחלוטין) כל יום ראשון בשעה 9:00 פג תוקפן של אופציות מסוימות ויש צורך לעדכן זאת במערכת.


אז מה רע כל כך בשימוש ב- scheduler? לכאורה מדובר בכלי חשוב והכרחי שמספק פתרון קל ונוח לבעיות מסוימות.

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

  1. בעיית איזור הזמן - במידה והגדרתם שעה מסוימת ביממה להתחלת התהליך, לאיזה איזור זמן התכוונתם? מן הסתם לזמן המכונה. אבל אולי ה Production שלכם רץ באמזון ב EST לעומת שרתי ה release candidate שנבדקים לוקאלית ב GMT + 2? מה קורה במעבר משעון קיץ לחורף? בקיצור - לא פשוט.

    GMT או BST? - זו השאלה! מקור: fotografiaslubnakielce.wordpress.com

  2. בעיית הגמישות - מישהו חכם פעם אמר "כשיש לך פטיש כל בעיה נראית לך כמו מסמר", ולפעמים נדמה שבגלל קלות השימוש ב-scheduler אנו נוטים להשתמש בו למגוון רחב מדי של משימות. בשונה מבקשה מהרשת לקבל webpage, בה מדובר על תהליך מוגדר היטב וסגור שבדרך כלל מסתיים בזמן קצר - אנחנו נוטים להשתמש ב scheduler לבצע משימות שיכולות להיות גם ארוכות ומורכבות.
  3. בעיית concurrency (או לחילופין:latency) - איך המערכת תתנהג כאשר הגיע כבר הזמן לביצוע הבא של ה scheduler והביצוע הקודם עוד לא סיים את עבודתו? במקרה כזה ישנן שתי גישות (המגובות בפ'יצרים מתאימים בכל מימוש של scheduler שתבחרו):
    1. האחת: לא מתחילים את הפעולה המתוזמנת הבאה עד שהסתיימה הפעולה הקודמת.
      לדוגמה: אין טעם להריץ שוב את תהליך הניקוי של ה DB כאשר התהליך המתוזמן הקודם עוד לא הסתיים.
      גישה זו היא בטוחה יותר, אך לא תמיד היא אפשרית: לפעמים צריך לבצע פעולות מסוימות מיד בתחילת כל דקה-שעה-יום. בנוסף במקרה שהמערכת נכנסת למצב של latency יהיה קשה לפעמים להבין עד כמה המערכת בפיגור וכמה פספסנו.
      אנו עלולים להניח שמכיון שתהליך מסויים מתחיל בשבע ואחר בשמונה - אזי הראשון מן הסתם יסיים קודם. במקרה של מערכת שנכנסת לפיגורים - כל ההנחות הללו קורסות.
    2. הגישה השניה: הפעלת הפעולה המתוזמנת בלי קשר למה קרה לפעולה (או פעולות) מתוזמנת קודמת.
      כאן הסכנה ברורה יותר: במקרה קיצון המערכת תתנפח ותקרוס (בגלל בעיית זיכרון או מיצוי כמות ה - threads הזמינים), אבל גם לא במקרה הקיצוני ביותר, אנחנו נכנסים לבעיית concurrency קלאסית ועכשיו כל התהליך צריך להיות מותאם לביצוע מקבילי (concurrent).
      זהו לא אתגר יוצא דופן, אבל מניסיוני לא תמיד זוכרים זאת בשלב הדיזיין.
  4. בעיית ה"פספוס" - תזמונים שעשויים להתפספס
    למשל: "כל יום בשבע בערב נשלח דוח יומי ללקוחות", רק שיום אחד הסרבר נכנס למצב של out of memory בשעה 18:58. למרות שזיהינו זאת בזמן והריסטרט עבד חלק - פספסנו את חלון הזמנים של הדו"ח! מה קורה עכשיו? מי אחראי להשלים את החור הזה? לא טרוויאלי בכלל!
    מה קורה כאשר התהליך המתוזמן נקטע באמצע? מן הסתם עדיף כבר לממש מערכת של משימות שיש לבצע והיא persistent.
  5. בעיית "איבוד השליטה" - כמה schedulers אפשר להגדיר למערכת אחת? כמה שרוצים!
    האם יש מקום אחד בו הכל מנוהל? אם לא אז כנראה שויהיה לכם קשה מאד להחליט האם תהליך אחד עלול להשפיע על תהליך אחר במידה וירוצו במקרה במקביל.
    כמה threads הוספנו למערכת בעקבות כל ה schedulers שהגדרנו? שוב יהיה קשה מאד לדעת.
    היבט נוסף שקשור לשליטה על המערכת הוא שתכנון של Scheduler שמתעורר כל שעה לבצע משימה מסוימת, עלול להתבסס על ההנחה שה Scheduler ביצע את אותה המשימה בעבר ויבצע אותה בעתיד. מניסיוני, ההנחות הללו אינן תמיד תקפות (תרגיל חשיבה: איך ניתן לדעת ש scheduler לא הופעל בזמן? איך מנטרים דבר כזה?) ועלולות לגרום לכשלים במקרי קצה שקשה לצפותם מראש.
  6. בעיית ה - Testing - מכיוון שהתזמון מתבסס על "זמן מכונה אמיתי", בין אם זו נקודה ספציפית על לוח השנה ובין אם מדובר על טיימר כלשהו - קשה לסמלץ בסביבת הבדיקות תזמון מדויק כמו זה שיהיה בפועל ב production. התוצאה: או ש"מלכלכים" את סביבת הבדיקות בכדי לשחזר את ההתנהגות של סביבת הproduction- או שמוותרים על סימלוץ מדויק של סביבת ה-production.
    אני מודה שבעיה זו היא פחות חמורה, ויש לה פתרונות יפים - אך עדיין דרושה כאן קצת אקסטרה מחשבה.

טוב אז מה אני מציע? לא להשתמש ב Schedulers בכלל?

האינסטינקט שלי הוא קודם כל לנסות ולהימנע מ scheduling במידת שאפשר: גם בגלל הבעיות שמניתי לעיל וגם בגלל התחושה הכללית כלפי הכלי הזה - משהו ב-scheduler מרגיש לי לא טבעי לסגנון ה java server side שאני מכיר.

הניסיון להימנע משימוש ב scheduler בדרך כלל הוליד פתרונות טובים יותר: כך שהגעתי למסקנה שהרבה פעמים ה scheduler הוא רק כלי להימנעות מדיזיין נכון של המערכת. לדוגמה:
  1. במקום להשתמש ב-scheduler כדי לשפר ביצועים גילינו שאין בכלל בעיית ביצועים. למה ניסינו מראש ללכת לכיון של שימוש ב-scheduler? אולי כדי להימנע מהצורך להתחייב על תוצאות ניתוח הביצועים של המערכת. בפועל הקדשנו לנושא עוד מעט מחשבה והגענו לפתרון נקי ובטוח הרבה יותר.
  2. במקום לנקות את ה DB פעם בדקה\שעה\יום - לבצע את הניקיון Lazily, רק כשניגשים ל DB. לפעמים זה מספיק טוב וגם חוסך עבודה מיותרת.
לפעמים אין ברירה וצריך להשתמש ב-scheduler. במקרה כזה אני תמיד מעדיף שה scheduler רק יכניס את ה"משימה" לתור. רצוי שתור זה יהיה Persistent, ותהליך אחר (יחיד או thread pool) ישלוף משם משימה אחר משימה. כך גם יש תיעוד, וגם חמקנו מרוב הבעיות שצוינו לעיל.
במידה וגם זה לא מספיק טוב וחייבים להשתמש ב scheduler ויהי מה - אז פוסט זה יכול להוות תזכורת לרשימה של דברים שיש לקחת בחשבון ושכדאי להיזהר מהם.


יניב חדד
Software Engineer at Citi TLV Innovation Lab


יום שבת, 19 במרץ 2016

על החומרה שמריצה את התוכנה שלנו

אני עושה כאן קצת ניסוי.

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

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

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

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

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

אז אתה, כמתכנת, מבין במחשבים, או לא?

ואז בעבודה (את/) אתה שומע כל מיני הערות על SSD או ECC ואולי Blades - ואין לך מושג (אני מנחש - אני דווקא מכיר) על מה מדברים ואיך זה קשור לתוכנה שאתה כותב. אז אני יודע מה זה ALU ומה הם שערים לוגים - אבל מעולם לא נתקלתי בשיחה במסגרת העבודה שהגיעה לאיזורים הללו בכלל.


מקור: hdwallpapershoot



אז למה הפוסט הזה הוא "ניסוי"?
  1. קשה לי לטעון שהידע שאכסה הוא ידע שימושי למתכנת. הבנת החומרה תרמה לכמה דיונים ספקולטיביים (אך אינטלגנטיים) בקריירה שלי - אך קשה לי לומר בבירור שהיא עזרה לי לפתור בעיות שלא הייתי יכול לפתור בדרך אחרת.
  2. אני לא מומחה אמיתי בתחום. הידע שלי מגיע יותר מפירוק והרכבה של מחשבים (שעשיתי יותר כשהייתי צעיר), ומהתעניינות כללית באתרים כגון TomsHardware או AnnandTech, והרבה התעניינות אישית בהזדמנויות שכן היה מגע עם החומרה.
  3. אני לא הולך "לדקדק" כפי שאני עושה בד"כ. כלומר: אני הולך לצמצם את תהליכי האימות שאני עושה בד"כ - ולכן סביר שהפוסט הזה יהיה פחות מדויק ומקיף ממה שבד"כ אני מפרסם.
אני כותב אותו בעיקר בשביל הפאן.

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

אז עם כל ההסתייגויות וההבהרות - נצא לדרך.

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


מקור: Rainbow Communication - computer and internet 101


הקופסה


אני אניח שאתם מבינים לעומק את ההבדל בין ה case ("המחשב") למסך וה Peripherals השונים. הנה וידאו קצר בו מפגישים חבר'ה צעירים עם מחשב משנות ה 90 עליו מותקנת "חלונות 95" ("את יכולה לנחש מה זה?" שואל המראיין - "המחשב הראשון שנוצר??" עונה הצעירה בפליאה) - אם אתם רוצים קצת להשתעשע.



בגדול יש 3 סוגי cases למחשבים (כלומר: שרתים, לא מחשב ביתי):
  • Tower - הזול ביותר, המשמש גם מחשבים ביתיים. קל להזיז אותו ולאחסן אותו בכל מקום - אך אינו יעיל בתפוסת המקום. מכיל הרבה אוויר ;-). לא ניתן להניח אותם זה על זה (בבטחה), ואין דרך טובה לארגן כבלים / את האוורור.
    • בסאפ היה לנו חדש שרתים עם Tower cases (עבור הפיתוח). שמו אותם על מן מדפים כאלו. 3 או 4 קומות. 
  • Rack Mount - הוא סטנדרט אחיד ל Cases של שרתים כל שיוכלו להתאים באותו הארון ולהיות מאוחסנים ביעילות של מיקום ואוורור (לדוגמה הסטנדרט אומר שזרימת האוויר צריכה להיות מקדימה לאחור).
    • את השרתים מאחסנים בתוך ארון שנקרא Rack או Cabinet (בציור נראה כמו שלד - אך מדובר לרוב בארון מאסיבי). ה Rack מגיע עם קיטים של מסילות (Rail kit) שמבריגים על השרתים הפיסיים וכך ניתן לחבר אותם ל Rack.
    • המסילות מסייעות לגשת בקלות לכל יחידה. יש לרוב התקנים לסידור הכבלים כך שישבו יפה בתעלות משלהן.
    • הסטנדרט המקובל שאני מכיר הוא זה: בשרתים - הכבלים הם מאחור, בציוד תקשורת - הכבלים הם מלפנים. (יש הרבה יותר מה לחבר). אם אתם נכנסים לחדר שרתים (חוויה שהולכת והופכת לנדירה בימנו) ורואים בלאגן של כבלים - אתם כנראה רואים ציוד רשת.
    • בעוד הרוחב והעומק של ה cases של השרתים הוא זהה - הגובה יכול להשתנות ביחידות קבועות, הנקראות Rack Unit. בקיצור RU או רק U. ציוד תקשורת יהיה בד"כ 1U, ושרתים יהיו לרוב 2-4U גבוה. שרת של 4U תופס מקום של שני שרתי 2U. בארון יש בד"כ 42 או 48 U בסך הכל. 
    • השרתים הם עדיין עצמאים (יש לכם ספקי כח ומאווררים משלהם), ויכולים להגיע מספקים שונים.
  • Blade - בכדי לחסוך עוד מקום, וגם לייעל כמה תהליכים (למשל: צריכת חשמל, חיבורי רשת) יצרו פורמט שנקרא Blade ("להבים"). שרתי ה Blade מורכבים בתוך שאסי (chassis = שלדה) שהיא בעצמה מורכבת בתוך Rack (והיא תתפוס משהו כמו 8-15U). השאסי מספק לשרתים חשמל, קירור וחיבורים (במקום כבלים) מה שמאפשר לכל אלו להיות יעילים ומאורגנים יותר.
    • אם תזדמנו לחדר שרתים, תוכלו לזהות Blade unit בכך שהיחידות הן אנכיות (כמו "להבים") ולא אופקיות כמו Rack units.
    • החיסכון הגדול במקום הוא במידה רבה בגלל היכולת לשתף Redundancy: בכל שרת Rack יהיו באופן טבעי שני ספקי כח (ספקי כח ודיסקים הם הרכיבים שמתקלקלים הכי הרבה), ואמצעי קירור (מאווררים, לרוב) יתירים. לא נרצה שהשרת יפסיק לפעול אם "נדפק" ספק הכח או נתקע מאוורר. מצד שני - היתירות בכל יחידה גוזלת הרבה מקום. ה Blade חוסך את היתירות לכל שרת ב Rack ומספק יתירות שיתופית לכל השאסי.
    • עד כמה שידוע לי, אין שום תקן אחיד לחיבור בין השאסי ל Blades עצמם. אם יש לכם שאסי של IBM - תוכלו לחבר אליו רק יחידות (שונות) מתוצרת IBM.
    • ה Blade נשמע כמובן הפתרון המועדף, אך יש לו גם חסרונות. המחיר - הוא לרוב החיסרון העיקרי, חוסר הגמישות לשלב בין יחידות של ספקים שונים או "להשתחרר" מספק - ללא השקעה כספית ניכרת. היחידות עצמן לרוב הן קבועות ולא ניתנות להרחבה (אין חריצי PCI ולעתים לא ניתן להוסיף דיסק או זכרון). ה Blade מתאים בעיקר ל Data Centers גדולים.

אני רוצה לציין משהו על צריכת חשמל: צריכת החשמל, עד כמה שידוע לי, היא כיום האתגר העיקרי בבניית Data Center. יותר כח מחשוב => יותר צריכת חשמל => יותר דרישת קירור.

לרוע המזל יש גבול לכמה קירור ניתן לספק לנפח מסוים, ועל כן לא ניתן לדחוס שרתים ללא גבול. דרישות הקירור הופכות לדרישות נדל"ן - שזו הוצאה גדולה בפני עצמה. כלומר: חשמל (של המחשבים + הקירור שלהם) והנדל"ן שמאחסן אותם הוא מרכיב העלות המרכזי של ה Data Center המודרני. כיצד מצמצמים עלויות?
  • רכישה של שרתים עם נצילות חשמל טובה יותר (הדורות החדשים של המעבדים לגמרי שם).
  • אופטימיזציות שונות. ספק כח (PSU) עם יעילות של 90%+ (platinum class) הוא דיי יקר - מאות דולרים ליחידה עבור שרת רגיל. עבור יחידות ב Rack לעתים קשה להצדיק את ההוצאה: שתי יחידות לכל שרת (עבור יתירות).
    ב Blade - אין בעיה להשקיע ב PSU יעיל הרבה יותר. להזכיר: ה PSU בעצם ממיר את המתח 110/240v לסדרת מתחים נמוכה (6/12/24v) לה רכיבי המחשבים בעצם זקוקים. תוך כדי ההמרה - אנרגיה מתבזבזת וממורת לחום. PSU זולים (מה שיש לנו בבית) לרוב מבזבזים כ 20-30% מהאנרגיה בהמרה - וייתכן שיהיה כלכלי יותר לקנות PSU יעיל מעט יותר (במידה ואנו משתמשים במחשב שעות רבות - כמוני).
    • יחידות Blade לרוב דורשות זרם תלת-פאזי, ושמעתי טענה ש PSU תלת פאזי יהיה בהגדרה יעיל יותר. אולי בגלל היכולת לנצל בכל פעם פאזה אחרת שהיא חיובית בכיוון הזרם שלנו ?!?! (ניחוש).



כך נראה Rack במציאות. Rack מסודר להפליא - עלי לציין. בחלק התחתון שלו ניתן לזהות יחידות Blade.
הערה: אם אתם מזהים יחידות אנכיות ממש קטנות (10-15 ס"מ) אלו אינם blades אלא דיסקים נשלפים ב Hot swap. אל תעשו לעצמכם פאדיחות :)


בתוך הקופסה


בתוך ה Case של המחשב לוח האם (motherboard) הוא זה שמחבר פיסית את כל הרכיבים השונים: הוא מקבל חשמל מספק הכח (PSU = Power Supply Unit) ומעביר מתחים לרכיבים השונים. הוא כולל גם את קווי החשמל עליהם עוברים נתונים בין הרכיבים השונים, מה שנקרא Bus, את החיבורים החיצוניים (USB, SATA), וכו'.

רכיבי המחשב השונים. מקור: How to know your computer hardware components

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

כמרכיבים מחשב אנו קודם לכן בוחרים מעבד - ומשם את שאר הרכיבים.
ארכיטקטורות נפוצות הן:
  • x86 (ידועה גם כ x86-64, x64, או AMD64) - הארכיטקטורה הנפוצה ביותר (כ 90% משוק השרתים). מריצה "חלונות", לינוקס, ומק. מיוצרת על ידי אינטל אבל גם ע"י מתחרתה AMD.
    • מעבדי AMD ואינטל דורשים לוחות אם שונים, אבל שאר הרכיבים (זיכרונות, חריצי הרחבה) - הם משותפים.
  • PowerArchitecture (לשעבר PowerPC) - ארכיטקטורה שמשמשת בעיקר את IBM בשרתי ה High-End שלה (Power 8, Power 7, ובקרוב Power 9), השנייה הנפוצה לאחר x86. מריצה בעיקר AIX (יוניקס של IBM).
  • Sparc של שרתי אורקל (לשעבר Sun Microsystems) - שולטת על אחוז או שניים משוק השרתים העולמי (לפני עשור או שניים - נתח השוק שלה היה גבוה משמעותית). מריצה בעיקר Solaris (יוניקס של Sun).
  • ARM - הארכיטקטורה שנפוצה מאוד במכשירי מובייל בשל חסכנותה בחשמל. ישנם גם יישומים שלה בצד השרת (עדיין לא נפוצה).



לאורך השנים המעבדים הגבירו את מהירות העבודה שלהם: על לוח האם ישנו שעון שמספק קצב למעבד: זה התחיל ב 4KHz (קילו-הרץ) והסתיים בערך ב 4.3GHz (ג'יגה-הרץ). חוקי הפיסיקה לא מאפשרים להעלות את מהירות המעבד מעל כ 4300~ מגה-הרץ בצורה יעילה (קירור בחנקן נוזלי יכול לאפשר 6GHz בערך - אך זו לא גישה כלכלית). לכאורה: יצרני המעבדים לא יכלו לייצר מעבדים מהירים יותר.
בפועל שיטות הייצור אפשרו למזער עוד ועוד את המעבדים והפתרון היה לייצר כמה cores בכל מעבד. כלומר: המעבד הוא "אריזה" שבתוכה ארוזים 2, 4 או יותר מעבדים "cores" כמעט-עצמאים שמבצעים את החישוב.

חשוב לציין שמהירות השעון (GHz) ומספר ה Cores הם לא מדד מוצלח להערכת כח-מחשוב. לדוגמה המעבד של אפל למובייל (A9) מכיל רק 2 cores במהירות 1.85GHz - אך הוא מהיר משמעותית ממעבדים בעלי "8 cores במהירות שעון של 2GHz" (להלן SnapDragon 810 של חברת Qualcomm).

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

את לוח האם מתאימים למעבד ע"פ דגם ה Socket (למשל LGA 1151 של אינטל) ו Firmware מתאים (כלומר: לוח האם צריך לציין שהוא תומך במעבדים מסדרת Skylake של אינטל - אחרת ייתכן ולא יידע להפעיל חלק מהיכולות שלהם).
Firmware היא התוכנה של רכיב אלקטרוני, במקרה שלנו ה Chipset של לוח האם - סדרת רכיבים אלקטרוניים שתומכים בארכיטקטורת המעבד. ה Chipset הוא "המוח" של לוח האם, והוא נקרא כך כי הוא בעצם סדרה של רכיבים אלקטוניים שמרכיבים במקומות שונים על לוח האם.

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


מעבד Sandy-Bridge של אינטל. מקור: www.bit-tech.net


בתוך "אריזת" המעבד כוללים 3 רמות שונות של זיכרונות Cache המסומנים כ L2, L1, ו L3. אתם בוודאי מכירים את העניין הזה, אך אני אחזור עליו בקצרה. מדוע 3 רמות שונות?
  • כאשר ה Cache הוא גדול יותר, ניתן לאחסן בו יותר נתונים אך החיפוש אחר ערכים (latency) - מתארך. יש פה Tradeoff מובנה בין מהירות תגובה לנפח אכסון.
  • בעבר למדתי ש L1 (הזיכרון הקטן והמהיר ביותר) נמצא קרוב יותר לליבת ה Core - מה שמקצר את ה Latency שלו, ו L2 הוא יותר רחוק. לא מצאתי אימות למידע הזה.
  • בסופו של דבר מחלקים את ה cache לשלוש רמות (בד"כ!): 
    • L1 הכי קטן והכי מהיר - נמצא בתוך ה Core. ב Skylake לכל core יש 64KB של L1.
    • L2 קצת יותר גדול ופחות מהיר - גם נמצא בתוך ה core. ב Skylake לכל core יש 256KB של L2.
    • L3 הוא לרוב משותף בין כל ה cores (חבל להביא ולאחסן אותם נתונים בצורה כפולה בין ה cores). הגודל שלו הוא בין 2MB במעבדים הבסיסיים עד עשרות MBs במעבדי השרת.
    • ב Skylake הציגו גם לראשונה זכרון L4 (בחלק מהדגמים) - אך הוא נועד למעבד הגרפי (GPU).
  • ה Cache מחזיקים שני סוגי מידע:
    • קוד להרצה (שגם אותו צריך לטעון לזיכרון)
    • נתונים של התוכנה.
  • כל פעם שאתם קוראים בקוד התוכנה אפילו לביט אחד של נתונים מהזיכרון שאינו נמצא ב Cache, יש לבקש העתקה של בלוק (אם כבר מבצעים העתקה, מעתיקים לפחות כמה עשרות או מאות Bytes) מהזיכרון הראשי ל L3 ואז ל L2 ואז (אולי) ל L1.
    • ה RAM הוא לא באמת "Random Access" - מהירות התגובה שלו כלפי המעבד תלויה מאוד באילו נתונים נמצאים כבר ב Cache.



צלילה קצרה למעבדי אינטל (x86) השונים


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


Sandy Bridge הוא גאווה ישראלית: הוא פותח בסניף אינטל בחיפה. הוא הציג יכולות עיבוד וידאו שהיוו ממש קפיצת-מדרגה, וכלל עוד כמה חידושים מרשימים (Turbo Boost?). מאז לאינטל אין כמעט תחרות מצד AMD (המתחרה המשמעותי היחידי בעולם ה Desktop) והדורות הבאים כמעט ולא הציגו ביכולת העיבוד שלהם - רק השתפרו בצריכת החשמל. בצד השרתים דווקא יש התקדמות מתמדת - מכיוון שיש תחרות מצד יבמ, אורקל, וחשש לתחרות מצד מעבדי ARM.

מילה לגבי תהליך הייצור: בכל שנה בערך אינטל מוציאה דור חדש של ארכיטקטורת המעבד שלה (שהיא תואמת לאחור). דור אחד משפר את הליטוגרפיה (טכניקת הדפסת המעגלים, הנמדד במרחק המינימלי בין 2 קווים - בננומטר) - מה שנקרא "Tick". דור עוקב משפר את הארכיטקטורה וה Layout של המעבד - מה שנקרא "Tock". 

כל קפיצה בתהליך הייצור מאפשרת לדחוס בערך פי 2 טרנזיסטורים בנפח נתון: "22 בריבוע" (שטח המעבד) הוא בערך חצי מ "32 בריבוע". כלומר: ניתן ליצור מעבדים עם יותר cores, או מעבדים קטנים יותר וחסכניים יותר בחשמל.

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

במעבדים השולחניים של אינטל יש כ 4 cores (בשל מחסור בתחרות?), במעבדים עבור מחשבים ניידים - 2 (עבור צריכת חשמל נמוכה, בכדי להאריך את חיי הסוללה), ובשרתים - עד 22 cores (עבור ביצועים).

ההערכה היא שלא ניתן יהיה ליצור תהליך קטן מ 7nm או 5nm - ובעתיד קצב השיפור של מעבדים ייעצר (או שיימצא טריק אחר על מנת לשפר אותם).

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


בדוגמה הזו לקחתי את Ivy Bridge, אך לכל דור יש את גרסאות ה M, EP, E וה EX שלהם.
לרוב גרסאות ה EX וה E משוחררות מאוחר יותר, לעתים שנה או יותר לאחר שחרור גרסת ה Desktop / Mobile.

i3/5/7 ו E3/5/7 הן תתי סדרות בתוך הארכיטקטורות ומשמשים לעתים כשמות מרקטיאליים. למשל: המשמעות של i7 עבור מעבדים שולחניים ועבור מעבדי מובייל - היא שונה.
אינטל גם מוציאה מעבדים הממותגים תחת השמות Pentium ו Celeron - שהם המעבדים הזולים ביותר.

הנה דוגמה להבדלים בין הסדרות השונות במחשבים שולחניים (מבוסס על סדרת Skylake):
  • Celeron/Pentium - מעבדים בעלי 2 cores.
  • i3 - מעבדים בעלי 2 cores ויכולת HyperThreading (בקיצור HT). יכולת שמאפשרת הדמייה של פי-2 cores נוספים לצורך עיבוד מקבילי - ומקובל להעריך אותה כב 20% שיפור בכח החישוב. כלומר: כ 2.4 cores בהערכה פשוטה.
  • i5 - מעבדים בעלי 4 cores + יכולת Turbo Boost (בקיצור: TB) המאפשרת למעבד להגביר את קצב השעון אם חלק מה cores לא פעילים (עבור קוד שאינו concurrent). השיפור הוא כ 10% יכולת חישוב במצבים ספציפיים שכאלו.
  • i7 - מעבדים בעלי 4 cores ויכולות TB + HT.
  • i7 Extreme - מעבדים בעלי 4 או 6 cores, עם כל היכולות האפשריות ו Bus משופר (שזה השיפור העיקרי - בעיקר עבור gamers כבדים). אינטל אגב, היא גם היצרנית של ה Chipsets עבור המעבדים שלה.

והנה דוגמה להבדלים בין הסדרות השונות במעבדים עבור מחשבים ניידים (מבוסס על סדרת Skylake):
  • Celeron/Pentium - מעבדים בעלי 2 cores.
  • i3/m3/m5/m7 - מעבדים בעלי 2 cores ויכולות TB + HT.
  • i5/i7 - מעבדים בעלי 2 cores ויכולות TB + HT + זכרון L4 ייעודי עבור המאיץ הגרפי (לא בכל הדגמים).
  • i5 Extreme (מסומנים כ HQ) - מעבדים בעלי 4 Cores + יכולת TB + זכרון L4 ייעודי עבור המאיץ הגרפי.
  • i7 Extreme (מסומנים כ HQ או HK) - כמו מעבדי i5 Extreme + יכולת HT.

ישנם עוד הבדלים שונים (לרוב פחות משמעותיים) בין הדגמים השונים בתוך כל סדרה. בקיצור: כדאי לעקוב אחרי הפרטים!
במשך שנים מכרו מעבדי i7 לעולם המובייל שהיו מהירים בכ 30% בלבד ממעבדי i3 למובייל - למרות שעלו כפול ויותר מהמעבדים הפשוטים יותר. הרבה אנשים שילמו ומשלמים פרמיה על המדבקה עליה מתנוסס הלוגו "i7" ("זה הכי טוב!") - ללא ערך משמעותי להשקעה.



הזיכרון

זכרון פעם היה רכיב יקר למדי (אני זוכר שקניתי בתיכון 4MB זכרון ב 300$), אך הוא הפך ונהיה זול למדי, גם אבסולוטית וגם יחסית לשאר חלקי המחשב. מחשב אישי לרוב יכול להכיל עד כ 32GB זכרון (מחשב נייד: בד"כ חצי מזה), אך שרת יכול בקלות להכיל 256GB זכרון ואפילו ניתן למצוא שרתים עם 2TB זכרון. למה כ"כ הרבה זכרון? בד"כ עבור יישומים ייחודיים (למשל: In-Memory Databases).
הזיכרונות בארכיטקטורת אינטל הם מסוג DDR-SDRAM ומסומנים כ DDR3 או DDR4.

מרגע שאינטל עברה לארכיטקטורה של 64-ביט, הכמות התאורטית של זכרון אליו המעבד יכול לגשת היא איננה מגבלה (המעבדים הנוכחיים משתמשים ב 48 ביט לייצוג זכרון, מה שמאפשר גישה תיאורטית ל 256TB זכרון). לרוב מה שמגביל את כמות הזיכרון שניתן להתקין הוא לוח האם, או מגבלות מלאכותיות של מערכת ההפעלה / התוכנה בה אתם משתמשים (Windows 7 Home Premium לא תאפשר להשתמש ביותר מ 16GB זכרון מבלי לשדרג לגרסה יקרה יותר של מערכת ההפעלה). אם בעבר (לפני עשור) ההמלצה הייתה תמיד לרכוש כמה זכרון שהתקציב שלכם מאפשר, כיום לרוב היישומים לא יהיה שימוש ליותר מ 8GB זכרון (בהנחה שמערכת ההפעלה צורכת כ 1GB זכרון).

הרבה אנשים מסיקים מכך שהם יכולים לקנות כמות מוגבלת של זכרון (נאמר: 4GB למחשב ביתי, או 16GB לשרת) - ולהוסיף עוד DIMMS (יחידות זכרון, מגיעים כיחידות מאורכות נקראות גם sticks) במידת הצורך. זה לא כ"כ פשוט!

לזיכרון יש תזמונים (CAS - ניגע בזה בהמשך) מעט שונים, ושני יחידות DIMM שלא מתואמות לחלוטין - יגרמו לחוסר יציבות של המחשב, ולעתים בכלל לא יעברו את שלב ה Boot של המחשב. יותר גרוע: אתם יכולים לקנות 2 יחידות מאותו מודל של אותו יצרן - והן עדיין לא יעבדו זו עם זו. כיצד זה ייתכן? כי היצרן לעתים משנה תזמונים בין אצוות ייצור של אותו מודל. עליו להתאים לתנאים (חומרים ורכיבים שזמינים לו) - מה שגם מכתיב את התזמונים של האצווה. כמה ניסיונות להגדיר סטנדרטים בתחום הזה - לא ממש צלחו.

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

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

The Most Common DDR DRAM Myths Debunked
DDR DRAM FAQs And Troubleshooting Guide



סוגי הזיכרון השונים

בחלוקה ראשונה אפשר לחלק את הזיכרונות ל2 קטגוריות בסיסיות:
  • זכרון סטטי (SRAM) - מהיר יותר, יקר מאוד, צורך הרבה חשמל, ותופס יותר מקום (6 טרנזיסטורים נדרשים לשמירת ביט אחד של זכרון) - ולכן משתמשים בו עבור זכרון מטמון L1 עד L3.
  • זכרון דינאמי (DRAM) - צפוף, פחות מהיר, פחות יקר, ודורש פחות חשמל - ולכן משמש לזיכרון הראשי של המחשב (גם שרתים).

הבנו מדוע אנו קוראים לזיכרון DRAM, אך מהיכן ה S ב SDRAM?

ה S היא עבור Synchronous מכיוון שהזיכרון מסנכרן את המהירות שלו מול ה BUS של לוח האם. לא 1:1 אלא בכפולות : פי 6 או פי 6.5 -למשל. בעבר הרחוק המעבד והזיכרון רצו באותה מהירות השעון: 33Mhz למשל, אך לא ניתן היה באותה תקופה להעלות את מהירות השעון של הזיכרונות מעבר לכך. הפתרון היה להריץ את המעבד ב 66Mhz ואת הזיכרונות ע"פ קצב של 33Mhz וליצור ביניהם פער של פי 2 במהירות השעון (להלן מעבד 486X2)

הזמנים השתנו ומעבדים רצים במהירות של בערך 3-4GHz, אך הזיכרונות עדיין לא מסוגלים לעבוד עם BUS מהיר בהרבה מ 1GHz.


נשארנו עם ה DDR (קיצור של Double Data Rate).
DDR  הוא תקן לזיכרונות שמעבירים נתונים פעמיים בכל פעולת שעון של ה BUS: פעם בנקודת השיא של השעון ופעם בנקודת המינימום (דמיינו גל סינוס). DDR3-1600 הוא זכרון שעובד עם ה BUS בקצב של 800Mhz, אך כיוון שהוא מבצע שתי העברות נתונים בכל אות של שעון - הוא מסוגל לבצע 1600 מיליון (מגה) העברות נתונים בשנייה, כאילו שהוא עובד עם שעון של 1600Mhz. רכיב הזיכרון עצמו, אגב, עובד רק במהירות של 200Mhz - אבל זה סיפור אחר.
אותו רכיב DDR3-1600 נקרא לעתים גם PC3-12800 בגלל שהוא מסוגל להעביר (תאורטית) כ 12.8GB נתונים בשנייה. כל העברת נתונים מעבירה את מלוא רוחב ה bus (כלומר: 64-ביט) כך שבכל העברת נתונים מעברים שמונה Bytes (שהם 64-ביט).



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

התקנים השונים של DDR מגדירים אגב מיקום שונה בכל גירסה לאיזה חריץ פיסי שנמצא על ה stick - כך שלא יהיה ניתן "בטעות" להכניס ל slot זכרון מדגם שלא נתמך. בכל גרסה של DDR עולה הצפיפות של הזיכרון (יותר נפח על Stick), עולה מהירות העברת הנתונים, ויורד המתח החשמלי הנדרש (פחות התחממות). התקן העדכני DDR4 (תקן מ 2014, החל להיות נפוץ לשימוש רק בחודשים האחרונים) תומך בנפח של עד 128GB ל stick, ובמהירות העברה (תאורטית) של עד 25.6 GB בשנייה.

עד כמה באמת משנה המהירות של הזיכרונות? לא כ"כ. ע"פ בדיקה שעשה האתר Hardware Canucks המעבר מ DDR3 ל DDR4 מקביל שיפרה בממוצע כ 2.5% בביצועי הקריאה של הזיכרון, 7% בביצועי הכתיבה, וכ 4% בביצועי ההעתקה בתוך הזיכרון. חשוב לציין שההשפעה של הזיכרון על הביצועים תלויה מאוד באפליקציה (והדרך שבה היא משתמשת בזיכרון), אך גם בדגם המעבד הספציפי (וה memory controller שלו) ובלוח האם. לא ניתן באמת להעריך רכיב זכרון מול רכיב זכרון ללא ההקשר המלא.

השפעה של DDR3 מול DDR4 במהירויות שונות על אפליקציית WinRar. במבחנים, זו האפליקציה שהושפעה הכי לטובה (ובבירור) מזיכרון מהיר יותר.
מקור: hardwarecanucks


למחשבים ניידים אגב, יש DIMMs (כלומר: Sticks) שהם קטנים יותר פיסית ונקראים SO-DIMM.
זיכרונות DDR (ואולי גם אחרים) מותקנים בזוגות על לוח האם בגלל טכנולוגיה שנקראת Dual Channel שאמורה לנצל את הזיכרונות בצורה יעילה יותר (אין קשר ל DDR). בדיקה שנעשתה (ב 2007 אמנם) מצאה שיפור מירבי של 5% בביצועים. כלומר: אפשר לשים זיכרונות בזוגות - אך ממש לא חייבים. היום פשוט מאוד לא מוכרים sticks של זיכרונות בבודדים (בגלל בעיות התזמונים שציינתי קודם לכן).
כאשר יש לוח-אם שתומך במספר מעבדים (לא cores) - יש חובה לשים כמה זיכרונות כי כל קבוצת DIMMs (מה שנקרא NUMA node) משרתת מעבד אחר (NUMA הוא שם הארכיטקטורה לתמיכה בכמה מעבדים). אלו לוחות אם ייעודיים לשרתים או תחנות עבודה "Workstation" והם עולים משמעותית יותר מלוחות אם התומכים במעבד אחד.

לוח אם התומך ב-2 מעבדים. ה slots לזכרונות מאורגנים בצורה שמבהירה בקלות אלו זכרונות משרתים כל מעבד. הזכרונות הם Quad Channel  (המקבילה הכפולה של dual channel) ולכן צבועים ברביעיות. מקור: Newegg




תזמוני זכרון (ידוע כ "CAS")

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

Latency של זכרון DDR מתואר ע"י 4 מספרים: tCAS, tRCD, tRP ו tRAS, למשל 9-9-9-28. ההסבר המדויק מה כל תזמון פחות חשוב. בסופו של דבר גישה לנתונים בזיכרון דורשת שרכיב הזיכרון ייבחר / "יתחבר" לשורה הנכונה ולטור הנכון בו נמצאים הנתונים ברכיבי הזיכרון. המדד tCAS, למשל, מתאר כמה cycles של שעון לוקח לבחור טור בזיכרון. גם לאחר שבחרנו את הטור והשורה הנכונים (בהנחה שהם לא היו selected קודם לכן) - יש להמתין זמן מה עד שאפשר להתחיל בהעברת הנתונים בפועל.
התיאור של זכרון כ "Random Access" או "גישה ב (O(1" היא הפשטה על המציאות המורכבת יותר. גם אם מתעלמים מה Caches שבאמצע.

כאשר המדדים הנ"ל נמוכים יותר - הזיכרון הוא בעל latency נמוך יותר. יש לזכור שהמספרים תלויים ב cycles של השעון, אז לא נכון להשוות מספרים של שני זיכרונות שרצים במהירות שעון גבוהה יותר. מהירות שעון גבוהה יותר = יותר cycles בשנייה. כלומר: tCAS של 9 בזכרון DDR4-2400 הוא טוב מעט יותר מ tCAS של 7 בזיכרון DDR4-1800.


אמינות של זיכרונות

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

ישנם זיכרונות מסוג ECC (קיצור של Error Correction Code). לזיכרונות הללו יהיה רכיב זכרון נוסף (תשעה במקום שמונה) על ה stick שמשמש כסוג של parity (שכפול נתונים). בתוספת של 1/8 מהזיכרון לא רק שניתן לדעת אם הייתה תקלה בזכרון - אלא גם להשלים את הנתון בתא שלא ידע לענות.

זיכרונות ECC הם יקרים יותר. יש שאומרים שאטיים מעט יותר (אני לא יכול לאשר) ונמצאים בד"כ רק בשרתים.

כשהארכיטקטורה שלנו מתבססת על ההנחה שיש הרבה nodes והם כושלים כל הזמן, האם יש עדיין הצדקה כלכלית לשימוש בזיכרונות ECC? האם אמזון AWS, למשל, משתמשים ב ECC?
בדקתי, והתשובה הייתה שכן - כל המכונות באמזון (שהן בהגדרה "commodity hardware") מצוידות בזיכרונות ECC. מעניין!

למערכות Ultra Mission Critical משתמשים במנגנונים של Memory Mirroring (קיצור שלי: MM).
MM עובד ממש כמו RAID 1: כל נתון שנכתב לזיכרון נכתב פעמיים, כך שאנו בעצם משתמשים בחצי מכמות הזיכרון הפנויה, ואנו צורכים פי-2 מה BUS - לכתיבה כפולה לזיכרון. אם רכיב זכרון (ביט או stick שלם) כושל - השרת ממשיך לעבוד כרגיל כאילו שום דבר לא קרה. איש operations יחליף את ה stick המקולקל - והכל יחזור להיות כפי שהיה. אם לוח האם תומך גם ביכולת בשם Memory Sparing, אז ניתן להתקין על לוח-האם כמה sticks של זכרון שלא יהיו בשימוש שוטף - אך יכנסו לשימוש אוטומטית ויחליפו sticks של זכרון שכשלו, וכך יאריכו את הזמנים ביניהם יש לעשות maintenance לשרת, כלומר: החלפה של sticks זיכרון תקולים. יכולות ה MM וה Memory Sparing הן יכולות של לוח האם, והן זמינות רק בעולם ה High-End של השרתים.

האם אמזון משתמשים גם ב MM? מה אתם אומרים?
בדקתי - ולא. אמזון לא משתמשים ב MM. אתם מוזמנים לבדוק לגבי Memory Sparing ולהגיב :)


סיכום


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

נכון: יש עוד הרבה עניינים: אחסון (דיסקים, ממשקים, וכו'), יציאות (USB למשל), לוח האם עצמו, ועוד רכיבים. (מישהו יודע מה זה G-Sync? בפירוש לא טכנולוגיה של שרתים.... חחח).

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

שיהיה בהצלחה!





לינקים רלוונטיים

ניתח הארכיטקטורה של Skylake באתר AnandTech

אם אתם רוצים המלצות על רכיבי חומרה ספציפיים, באתר Tomshardware, יש בעמוד הראשי section של Best Picks של רכיבים שנבחנו ע"י האתר ונמצאו כטובים במיוחד. הרשימות מתעדכנות כמעט על בסיס חודשי, אם כי לא תמיד יהיה קל למצוא כל את הדגמים שהם ממליצים עליהם בחנויות בארץ.



יום שישי, 11 במרץ 2016

איך לגייס את אנשי-התוכנה הטובים ביותר?

הנה שני נתונים מעניינים:
  • מחיר גיוס כושל של עובד מוערך בכ 15 משכורות של העובד: משכורת ל 6-9 חודשים (הזמן שלוקח בממוצע לארגון / לעובד להודות בכישלון הגיוס), אי עמידה ביעדים בתקופת ההעסקה, ועלויות של הארגון (הדרכה - בעיקר זמן של עובדים אחרים, תשלום לחברת השמה, ועלויות קליטה אחרות).
  • כחצי מהגיוסים בתעשייה אינם "גיוסים מוצלחים", איפשהו בסקאלה בין "גיוס בינוני" ל "גיוס כושל".

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

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


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

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

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


נקודת שבירה שכזו הייתה כשגוגל (הארגון הנערץ והעשיר ב IQ) הודה שלשאול מהנדסים שאלות הגיון / פיסיקה היפוטתיות (למשל: "אם היית מכווץ ל 1/20 מגודלך, והיית נזרק לתוך בלנדר - איך היית יוצא משם?") - זו דרך לא יעילה לברור עובדים.

רבים חיקו את גוגל או הושפעו ממנה ("כי גוגל לא יכולה לטעות") - ורגע ההכרה בטעות היה מביך לרבים.

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


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

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

הגישה מבוססת על רב-מכר בשם "Who - The A Method for Hiring", שהוא ככל הנראה הספר המוערך / המקובל ביותר בתחום כיום, וכן על ספר ההמשך שלו "Power Score" שמשכלל מעט את הגישה, ומקשר אותה לבעיות ניהוליות אחרות כמו קביעת יעדים וניהול יחסים בארגון.







אז איך אנחנו מגייסים עובדים?


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

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

טעויות שכאלו עשויות [ב] להעלות ספקות ביכולת החיזוי שלנו לגבי נושא כ"כ מורכב. מורכב?
אנשים הם מורכבים x ארגונים הם מורכבים = ההתאמה בין אנשים לארגונים היא מורכבות גדולה אף יותר.


מתוך כך צמחו שתי גישות הפוכות:

גישה אחת אומרת שיש לשכלל את תהליך הגיוס:
  • יש להפוך אותו למדעי יותר (יותר פרמטרים אובייקטיבים ופחות  "תחושות בטן" / "התרשמות אישית")
  • מקיף יותר (יש גישה שאומרת שהזמן "הנכון" להשקיע בראיונות של מועמד הוא כ-10 שעות, ולא 2-4 שעות כפי שמקובל)
  • יסודי יותר (לעבוד ע"פ מתודולוגיה מסודרת, למשל: לא לוותר למועמד על סט שאלות יסודי וסטנדרטי).
אפשר לסכם גישה זו באמירה ש"הבעיה היא סבוכה, אך ניתן לפצח אותה".



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

  • "טעויות בהערכת עובדים" הן נפוצות.
  • אנשים הם שונים מטבעם. קשה להשליך מהצלחה / אי-הצלחה של אדם בסביבה א' על הצלחה / אי-הצלחה של אדם בסביבה ב' (הסביבה אליה אנו מגייסים) - במיוחד כשאין לנו היכרות אינטימית ומעמיקה עם סביבה א'.
    • למשל: העובדה שעבדתי ב SAP במשך כ 8 שנים, עדיין לא מספיקה בכדי להבין בצורה טובה מחלקה שונה בחברה. השוני בין קבוצות שונות, אפילו מקבילות - יכול להיות דיי גדול.
    • שאלה מאתגרת: כיצד אנשים (לפחות חלקים) שאנו פוסלים מכל וכל מוצאים עבודה זמן קצר לאחר מכן בחברה מוערכת אחרת? האם החברה האחרת פספסה את הסימנים שאנו ראינו - או שאולי קבלה למקום עבודה הוא עניין פסודו-אקראי?
  • טענה: תהליך הגיוס הפורמלי בעיקר מצליח לסנן בעיקר מקרי-קיצון (אנשים שממש לא מתאימים, או ממש כוכבים). אך עבור הרוב שבאמצע הוא מצליח בעיקר לסנן החוצה אנשים שלא דומים לנו בסגנון / תפיסות עולם / רקע. כלומר: תהליך למציאת "Mini-me".
  • ולכן: במקום להתאמץ לראיין - עשו סינון בסיסי ומהיר וקבלו את האנשים לתקופת ניסיון. השקיעו את המאמצים ביצירת מנגנון שיפחית את העלויות של גיוס כושל, למשל: תכנית ניסיון קבועה של 3 חודשים שהארגון ערוך אליה - ורק לאור הניסיון בתקופה זו - בצעו החלטת גיוס. מנגנון שכזה הוא לא פשוט מהרבה סיבות, אבל לפחות מהסיבה שרוב האנשים שעוזבים מקום עבודה לא רוצים לגלות לאחר 3 חודשים שכעת הם חסרי-מקום עבודה, וצריכים לחפש שוב.
אפשר לסכם גישה זו באמירה "הבעיה היא קשה מדי בכדי לפצח. יש להשתמש בניסוי וטעיה".



איך זה נראה? הנה עדות לדוגמה:



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




על שתי תפיסות ניהול ברומו של עולם


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



התמונה הראשונה של גוגל תמונות לחיפוש "mcKinsey employees"



גישת מקינזי

הערה על השם: מקינזי היא חברת ייעוץ ענקית וגלובלאית - וזו המזוהה ביותר עם "ייעוץ להנהלה הבכירה".

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

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

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

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

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

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

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

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

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



התמונה הראשונה של גוגל תמונות לחיפוש "Toyota employees"



גישת טויוטה 

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

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

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

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

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

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


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




Tho Who - לא "מה", אלא "מי"?


הספרים "Who" ו "Power Score" באים לענות אל השאלה "כיצד מגייסים את האנשים הנכונים, עבור המשימות הנכונות".

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

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

שני הספרים, "Who" ו "Power Score" לא נקיים מהטיות (או: ניסיונות הטיה של הקורא). בהקמה לספר "Who" מפרטים באריכות את כמות חברות הענק, המנהיגים הגדולים והמיליארדרים שנהנו ותרמו פידבקים לשיטה. כאילו העורך דרש במפורש מהכותבים: "הבא נשתמש באפקט ההילה על מנת לקנות את אמון הקוראים - צאו לדרך!".
הספר "Power Score" הולך צעד אחד קדימה ומדגיש שהשיטה "מבוססת" על כך וכך אלפי שעות רעיונות שנעשו, עם כ15,000 "מנהיגים" ושהיא מבוססת על "9 מיליון data points"!

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

"If you think listening to the advice of one leader is helpful, imagine having fifteen thousand leaders giving your their best advice!" 
נכתב בספר (ההדגשות במקור).

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

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

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



שגיאות נפוצות בגיוס עובדים


גיוס עובדים "בסגנון חופשי" עשוי להיות מאוד לא יעיל. הנה כמה התנהגויות שגויות של מגייסים:
  • מבקר האומנות - מבקר אומנות מוכשר מסוגל להתבונן בציור כמה דקות, ולעריך אותו מקצה-לקצה. אנשים שחושבים שהם מסוגלים "לקרוא" אנשים זרים בכמה דקות של שיחה - טועים בגדול.
    אנשים יכולים בהחלט לספר בראיון את מה שהמראיין רוצה לשמוע - מבלי לשקף את המצב האמיתי. זה לא חייב להיות "שקר", אלא מן הסתם זהו מבחן שהם רוצים לעבור אותו ולכן אנושי להשמיט פרטים, לגרור את השיחה למקומות נוחים, להגזים, וכו'.
  • הקהילה - מנהלים עסוקים עלולים לבקש מעובדים ועמיתים לראיין את המועמד ו"לשמוע עוד דעה". הבעיה היא כאשר כמה אנשים שונים מראיינים את העובד ללא סדר, שיטה, או תיאום ביניהם. החפיפה בין השאלות שהמרואיין נשאל - עשויה להיות גבוהה (בזבוז זמן לכל הצדדים), והפידבק בין המראיינים השונים - כמעט ולא קיים. עצם זה שחמישה אנשים מחבבים מישהו והוא נראה להם בסדר - זו לא דרך טובה לגייס עובדים.
  • ועדת החקירה - התמקדות בשאלות קשות ונוקבות, עד שהמועמד לא מצליח לענות או "נשבר" ומודה בחולשתו. מועמד עלול לוותר על החברה בגלל הגישה בראיון. מה התכלית מאחורי השאלות הללו? האם לא ידוע וברור שכל מועמד הוא בסך הכל בנאדם עם גבולות ושאינו יודע הכל?
  • פסיכולוגיה בגרוש - ניסיונות לבחון את המועמד בדקויות של ההתנהגויות. האם הוא פינה את כוס השתייה אחריו? האם הוא ניגש ללוח ומוחק רק איזור קטן ("עצל!") או מנקה את כל הלוח ("פדאנט!"). כנראה שלקריאה בקלפים יש רקע עובדתי משמעותי יותר מאשר השיטות הללו - אז אל תשלו את עצמכם.
  • הדייט - כאשר נגררים לשיחות חולין חברתיות במקים לנהל ראיון אפקטיבי. "כימיה טובה" היא חשובה בין מנהל ועובד, אבל זכרו שהיא גם יכולה להתפתח עם הזמן. 
  • מינה צמח - ראיון שמתמקד בשאלות היפותטיות עתידיות: "אם היה לך עובד בעייתי... איך היית מתמודד איתו?"... "אם יש בעיית איכות - כיצד אתה חושב שהיית ניגש לפתור אותה?", "אם אורן חזן היה מתמודד לראשות מפלגת העבודה... למי היית מצביע?". זכרו: לשאלות היפוטתיות אתם תקבלו תשובות היפוטתיות.
    הכלל המומלץ אגב הוא להתמקד באחד מ-2 סוגי שאלות:
    • "ספר לנו כיצד התמודדת בפועל עם מצב xyz." - התבססות על מקרים שקרו בפעול, ולא מקרים היפותטיים.
    • "בהינתן מצב X, אילו אפשרויות עיקריות עומדות לפניך ומה התנאים בהם היית בוחר בכל גישה?" - לבחור את יכולת ניתוח המצב של המרואיין, והידע המקצועי שלו בכלל.






את מי אנחנו מחפשים?


שיטת ה "Who" מגדירה 3 סוגי של עובדים:
  • A Players או A Employees - הם בעלי הכישורים (skills) וההתאמה הטובה ביותר לתפקיד הנתון - העשירון העליון.
  • B Players - הם ה 25% הבאים אחריהם. טובים אך לא "הטובים ביותר".
  • C Players - הם כל השאר (66% הפחות טובים).

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

מטרת השיטה היא לעזור לגייס עובדי A.

ארגונים שמשאירים C Players מדרדרים את הארגון ולעתים גורמים ל A Players לעזוב את הארגון - מה שרק מחמיר את המצב.

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

הנה טכניקה לאיתור העובדים בארגון שלכם: רשמו את רשימת המשימות של עובד בתפקיד לשנה הקרובה. עבור מתכנת זה עשוי להיות: "להתמודד עם מורכבויות טכנולוגיות כאלו וכאלו, להגיע ליעדי איכות כאלו וכאלו, ולעמוד בתהליכים כאלו וכאלו". עכשיו הניחו ש 50% מהעובדים מוקצים למשימה ארגונית אחרת (שלא מעניינת אתכם). מיהם העובדים שתשאירו אצלכם? אח"כ הרחיבו את מספר העובדים שנשאר אצלכם ל 70% - מי התווסף? ואח"כ ל 85% - מי עכשיו?
יש סיכוי טוב שאלו שלא הצטרפו ל 85% הנחוצים - הם עובדים שלא יעילים בתפקיד הנוכחי שלהם.

שיטה אחרת הוא לבחון מיהם העובדים בעלי היכולת לבצע את המשימות, ורצון אישי לבצע את המשימות. עובדי A - הם לרוב אלו שיש להם גם את היכולת, וגם את הרצון האישי.

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

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



"עובד A הם יחסיים לארגון ולצרכים שלכם" - הוא חידוד שנוסף בעיקר בספר "Power Score". כלומר: עובד A במשרה אחת עשוי להיות עובד C במשרה אחרת.

הערה: הקטלוג של עובדים ע"פ קבוצות B, A, ו C - ובכלל שיטת הראיונות של הספרים מבוססת על הספר Topgrading שכתב אביו של אחד המחברים של הספרים הנ"ל. גם הספר Topgrading נחשב כמקור השראה בתקופה שיצא (שנת 2005).


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

על מנת לגייס עובדי A, השיטה מחולקת ל-4 שלבים עיקריים:
  1. Scorecard - קבעו תוצאות-צפויות (outcomes) מכל תפקיד שאתם מגייסים ומהן הגדירו כרטיס ניקוד שיעזור לכם להתמקד בשאלות הנכונות ולהעריך מי מהמועמדים צפוי להתאים יותר.
  2. Source - חיפוש אחר עובדים טובים לא מתחיל כאשר אתם פותחים משרה. עליו להתבצע כל הזמן, גם כאשר אין לכם משרה פתוחה. רק כך, כאשר תהיה משרה פתוחה - יהיה לכם "בנק" מועמדים מספיק איכותי בכדי לגייס את עובדי ה A שלכם.
    1. כמובן שזו גישה מאוד סבירה למי שכל תפקידו היא גיוס עובדים (כמו מחברי הספרים), ופרקטיקה שהרבה יותר קשה ליישם - כאשר אתם עסוקים במיליון דברים אחרים. האם אנשי ה HR בארגון יכולים לעזור לכם להשקיע בנושא הזה בצורה עקבית?
  3. Select - כאשר יש לכם כמה מועמדים סופיים, קבעו מי המועמד המבטיח ביותר בעזרת Topgrade interview (להלן הספר Topgrading). ההנחה של השיטה היא שהמנבא המוצלח ביותר לחיזוי ביצועים עתידיים - הם ביצועי העבר. לבדיקה מקיפה עם ממליצים יש משקל מיוחד בשלב זה.
  4. Sell - לעובדי A יש הרבה אופציות פתוחות. על מנת שיבואו דווקא אליכם - יהיה עליכם למכור את הארגון והתפקיד. במילים אחרות: כיצד אתם מצמצמים את אחוז האנשים שמקבל מכם הצעת עבודה - אך מסרב.

הרצון לגייס עובדי A הוא גדול כ"כ שההמלצה היא שעדיף לפספס עובד A פה ושם - על פני גיוס עובד B (או חס וחלילה: C). ישנה הנחה שלמרות ההנחיות - בפועל ארגונים לא מצליחים להיפרד מעובדי C, ולכן חשוב מאוד להחמיר בסינון.

מקור נוסף שמזדהה עם הגישה

הגישה הזו לא שייכת ל "Who" בלבד. ג'ואל ספולסקי ("Joel on Software", ה co-founder של StackOverflow) אומר דברים דומים:



דווקא ג'ף אטווד ("Coding Horrors", ה co-founder השני של StackOverflow) מבקר את הגישה. הוא מביא כמה דוגמאות (לכאורה - קשה לשפוט) של עובדים מעולים שסוננו ע"י תהליך גיוס מחמיר מדי - והתפספסו:


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

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

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

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

זה נראה כמו יחס חד כיווני כאילו המנהל תמיד צודק, וכולנו אולי נתקלנו בכמה מנהלים לא-טובים בחיינו.

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

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

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

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



צוות פיתוח חזק/ה? חחח. המשרה בעייתית מכל בחינה - הרבה מעבר לטעות הזו.


Scorecard


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

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

ל Scorecard המתמקד בתוצאות יש כמה יתרונות ברורים:
  • הוא מצמצם אי-הבנות אפשריות בתוך הארגון לגבי מהות התפקיד ומשמעותו.
  • הוא מצמצם אי-הבנות עם המועמד לגבי התפקיד ומשמעותו.
  • הוא לרוב הרבה יותר אטרקטיבי למועמד: הוא מתאר את התפקיד הגדול ואת הדינאמיות בתפקיד, והוא מוחשי וברור (בניגוד לתיאורי משרה המתארים סט כישורים נדרש - אך לא מספקים שום הצצה על מהות התפקיד בפועל).
    • גם כאשר הוא פחות "אטרקטיבי" למועמד - יש בכך ייתרון. למשל: הרבה משרות של מעצבים גרפיים מבטיחים "חופש יצירתי, חזון, וחשיבה מחוץ לקופסה" בעוד המשרה בפועל היא "ליצור corporate UI שאמור להיות זול לבנייה וסביר לשימוש". התיאור השני הוא פחות מרשים, אבל אם נמצא אנשים שזה מה שהם אוהבים לעשות - הם יוכלו לעשות את זה ככל הנראה הרבה יותר טוב מג'וני אייב (המעצב הראשי של אפל).
  • הוא ממוקד במטרה, ולכן יותר אפקטיבי: "5 שנות ניסיון ב x" הן לא מה שאנו מחפשים. אנו מחפשים מישהו שיוכל לפתח את ה web app שלנו בצורה כזו וכזו. אם נתמקד במטרה הנכונה - יהיה לנו קל יותר להשיג אותה.
  • הוא יעזור לנו בשלב הראיונות, וישמש כבסיס השוואה עקבי בין מועמדי.






ה Scorecard מורכב מ-3 חלקים:
  • משימה 
  • תוצאות-צפויות (outcomes)
  • ויכולות (competencies)

בואו נצלול לת'כלס. הנה לדוגמה תיאור משרה שהגדרנו (כמיטב יכולתנו) ללא הדרכת ה "Who", וגרסה (ראשונית) שהגדרנו לאחריה.

לפני:


Security Expert Job Description

Responsibilities
  • Build and maintain the Security Perception of Gett's systems according to the existing  threats and business needs.
    • By reviewing the design of new features / key changes to the system - and contributing to the Security Aspects of it.
    • By educating the R&D about the Security Perception and best practices.
    • By being parts of the Architecture team, and co-working with Product Management to better understand the business needs.
  • Secure the system from cyber attacks
  • Manage security incidents (with the team) when occur and implement deep learning from it.
  • Peer the Anti-Fraud team and Gett's Global (non-R&D) Security Expert to share knowledge and efforts.

Requirements
  • Development Background at Hands-On level: Read code, help others with code, be able to write some code.
  • Minimum of two years of experience in a similar role.
  • Passion for Security and the everlasting fighting against security threats and attacks.
  • Ability to aim for "good enough security" and well balance between security and business needs.
  • A Good technological understanding: AWS, Databases, Web, and Networks.
  • A Good communicator, being able to work with people at different levels of expertise / seniority and communicate technical knowledge clearly.




ואחרי:

Security Architect Job Description


Mission: Due to the rapid growth of Gett business, and due of Gett's being an attractive target for malicious attacks - we need a person to raise the bar of our overall R&D Security, and create, maintain, and evolve an end-to-end security plan, processes, and practices within the R&D department.


Outcomes


  • Build a security plan for Gett's R&D:
    • Identify major security gaps - and prioritize / maintain a plan of addressing it.
    • Communicate the plan across R&D - and create tangible guidelines R&D staff can follow.
    • Constantly adjust the plans according to architecture evolution, new insights, or new businesses being introduced.
    • Do all the above while aligning with the (anti-) Fraud team and the global (non-R&D) Security expert.
  • Manage security incidents (with the team) when occur and implement deep learning from it / implement it back into the Security plan.
  • Take responsibility for existing Security Controls of the production system.
    • WAF, IPS, AWS settings, monitoring tools, etc.
    • (non-production controls, such as physical controls or development environments are under responsibility of the IT / Global Security Expert)
    • (the controls are operated by devOps / developers - your responsibility is to have an overall strategic and holistic responsibility over it)
    • Measure the effectiveness of existing controls and improve / evolve them in order to improve Gett's security.
  • Implement Security Supporting processes in R&D
    • E.g. implement static code analysis for defending against OWASP Top 10 attacks, mapping and handling personal data, review 3rd Parties, etc.
    • (according to needs / security plan)
    • (With the assistance of the rest of the architecture team / managers)


Competencies

  • A Professional - who is able to drill down into the complexities of our system, and that is fact/data-driven.
  • A Humble Person - who puts "doing the right thing" before his ego.
  • Getting things done - as the accountable for the security: be proactive, initialize, and not stopping until tasks are completed.
  • Positive - Looking for solutions rather than being stopped at the problems.



הערה: מדוע תיאור המשרה באנגלית? הרי היא בבירור פונה למועמדים דוברי עברית!
שאלה טובה...

ה Scorecard הוא קודם כל פנימי: על מנת לפקס את המנהל המגייס והמגייסים האחרים על מה בדיוק אנחנו מחפשים. תיאור המשרה שמתפרסם / נשלח למועמדים יכול להיות ה Scorecard עצמו, או יכול להיות גרסה "מכירתית" יותר. בכל זאת (כפי שנראה בהמשך) - תיאור משרה הוא מסמך marketing והוא משרת צרכים מעט שונים מה Scorecard הפנימי.
  • מבנה: outcomes, mission, ו competencies הממקדים אותנו במה שאנו זקוקים לו, במקום רשימה של יכולות שאנו מניחים שלאדם שאנו מחפשים גם יהיה אותן. רשימת היכולות עדיין לא מבטיחות התאמה לתפקיד - ולכן היא סוג של הסחת דעת / מיקוד לא יעיל במטרה.
    • המשימה - עוזרת לנו להתמקד במומחיות הנדרשת (ולסנן Generalists).
    • רשימת ה outcomes הם אשכרה הגדרות התפקיד כפי שיונחו על שולחנו של העובד שיגויס - ויידרשו ממנו בשנה הראשונה.
    • מדדי הכשירות (Competencies) מגדירים כיצד צפוי המומעד להשיג המועמד את התוצאות הצפויות (outcomes) ועוזרים למצוא התאמה תרבותית בין המועמד והארגון.
איך בוחרים / מתארים מדדי כשירות?
הספר מציג רשימה של כ 24 מדדי כשירות לדוגמה (יכולת ארגון ותכנון, אסרטיביות, אינטליגנציה גבוהה, תשומת-לב לפרטים, וכו') שעשויים לעזור כ reference. ברור שהכל הן תכונות טובות (ממש כמו Quality Attributes בתוכנה) - אך חשוב מאוד לא לשקוע לפנטזיות ולהבין באמת אלו תכונות הן חשובות. ההמלצה הברורה של השיטה היא לא להגדיר יותר מ 5 competencies שהם החשובים ביותר.
אצלנו ב Gett עוד ממזמן אנו נוהגים להעריך עובדים ע"פ ביצועים + 4 אמות מידה התנהגותיות. אמות המידה הללו (Getting things done, Stay Humble, Professionalism, ו Positive) עולות בכל הערכת-עובדים חצי-שנתית - ועל כן היה לי מאוד טבעי להכניס אותם כ Competencies.


הנחיות נוספות:
  • הימנעו מ "Generalists" שנראה שיודעים לעשות הכל, ויש להם היסטוריה בתפקידים מגוונים. אלו הרבה פעמים אנשים מרשימים, שמדברים יפה, שיודעים לשכנע שהם "לומדים מהר" ויכולים להסתגל לכל סביבה. (אופס: זה אני!). התפקיד שלכם הוא ספציפי (עכשיו ברור לכם מה Scorecard) ולכן העדיפו מתמחים שעשו את תפקידים דומים והצליחו במסגרות ואתגרים דומים לשלכם.
  • ה outcomes הם גם אמת מידה פנימית להצלחות הגיוסים - בהנחה שיש לכם תהליך כזה בארגון.
  • מומלץ לאתגר את ה Scorecards שאתם מגדירים מול היעדים העסקיים של היחידה שלכם: האם ה Scorecard באמת מתאר את מה שאתם זקוקים לו על מנת לעמוד ביעדים? שתפו את העמיתים שלכם לעבודה ב Scorecards ושמעו את דעתם.




Sourcing


חברה שמפרסמת מודעות דרושים, ובמודעות הדרושים יש דגש על "must have skills", ניסיון שנדרש, ותכונות כמו "עבודת צוות", "חשיבה מחוץ לקופסא", "או נכונות לעבודה מאומצת" (מכירים כאלו?) - כנראה מניחה שיש שפע של עובדים פנויים שיחפשו את המודעות הללו וינסו להתאים את עצמם אליהן.

חברה שמנהל הגיוס שלה לא נמדד ע"פ היכולת שלו למשוך עובדים כשרוניים - גם כנראה מניחה שיש שפע של עובדים כאלו.

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

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


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

במקום לתאר "עוד מקום עבודה", על תיאור המשרה לתאר "שינוי בקריירה" (a career move) - משהו שמושך יותר להתחבר אליו!

עדיף לומר: "להוביל את קבוצת הפיתוח של אפליקציית המשתמש שלנו" על פני "דרושים חמש שנות ניסיון בפיתוח Front-End וניהול של לפחות עשרה מתכנתים".

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

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







כיצד מתארים את המשרה?

יש סבירות טובה שעובדים מוכשרים - מוערכים ומתוגמלים במקום העבודה הנוכחי שלהם.

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

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

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

אל תניחו שאם אתם משתמשים בשפת תכנות מסוימת Y אזי כיסיתם את הדרישה: "עובד בעל ניסיון בשפת X יהנה מ 30% שיפור מקצועי מכך שיתמחה גם בשפה נוספת Y...". השאלה היא לא איזה טיעון אתם יכולים להעלות - אלא כיצד המומעד תופס את הדברים.

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

טיעון שאני יכול להרכיב מכמה מקורות (חלקם שיטת ה "Who", חלקם נוגעים ספציפית לתוכנה) הוא שניסיון הוא איננו מרכיב חשוב לבחינה. נכון יותר להסתכל על יכולת: יש אנשים שמגיעים ליכולת z לאחר שנתיים - ויש כאלו שגם לאחר עשר שנים לא יגיעו אליה.

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

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

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


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

הדרך הנפוצה ביותר המתוארת בספר לגיוס עובדי A היא המלצות. המלצות של עמיתים שלכם, של עובדים, של מגייסים, וכו'. שווה להזכיר שהספר מדבר יותר על בכירים, ויש בו case study: "אז איך לגייס מנכ"ל?"

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


דרך נוספת לעשות Sourcing היא לפנות לעובדים פוטנציאלים. למשל ב LinkedIn.

אל תציעו למישהו שהוא ראש צוות כבר כמה שנים - תפקיד של מתכנת [ג]. ע"פ "המדרג המקובל בשוק" - זו לא התקדמות.

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

דרכים נוספות בעולם התוכנה למצוא talent הוא לראות קוד ב Github או תשובות ב StackOverflow שמרשימות אתכם - ולחפש את האדם מאחוריהן. היכולת לקרוא קוד (ע"פ commits) או תשובות ב Github הן כלי נהדר שיכול לשקף הרבה על הצד המקצועי של המועמד.

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


אחרית דבר


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


שיהיה בהצלחה!




--

לינקים מעניינים

We are hiring the best - like everyone else של ג'ף אטווד, ממנו לקחתי הרבה מהציטטות לאורך הפוסט.


----

[א] תיאדור סטרג'ן הוא סופר מדע בדיוני שניסח כלל שאומר (בסלנג:) "90% מכל דבר זה שטויות", או בצורה היותר מנוסחת שלו: "בני-אדם יודעים לבנות ציפיות הרבה יותר טוב ממה שהם יודעים לספק ציפיות. ב 90% מהמקרים אנו צפויים להתאכזב ממה שציפינו - כי בניית הציפיות הייתה טובה יותר מסיפוקן".

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

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

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

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