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

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

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

רמות 1-3 (ושאר רמות) הן דרך מצוינת "לחלוב" מעסקים כספים. ככל שהרמה עולה, אתה משלם יותר. בעולם הלינוקס לדוגמא, רמות לא קיימות. כשאתה קונה לדוגמא SLES או RHEL, אז אתה מקבל תמיכה על גירסת הלינוקס שרכשת (בהמשך אכנס ליתרונות ולחסרונות). אם התמיכה בחבילה שרכשת אינה מספקת לסיטואציה שלך, אז אתה יכול לרכוש שרותי Incident או Consulting (כל חברה והמושגים שלה) שבה אתה תשלם כמה מאות דולרים לשעה, ויצרן ההפצה יקדיש לך מישהו שישב על המערכת שלה למצוא מה התקלה ואיך לפתור אותה. היכן יש רמות בעולם הלינוקס? ברמת הדחיפות. אם ניקח לדוגמא את רמות התמיכה של Red Hat, נוכל לראות שיש רמות ב-SLA. רוצה שרות טלפוני? שלם 800$ פר עותק הפצה. רוצה שרות מהיר? המחיר קופץ ל-1500$ פר עותק (שוב, המחירים אינם כוללים מצבים שבהם מהנדס מוצמד לעסק שלך לפתור את הבעיה, שם התשלום ליצרן ההפצה הוא בנפרד ממה ששילמת על ההפצה).

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

כשזה מגיע לעסקים וחברות שמריצים עשרות/מאות/אלפי מכונות לינוקס לעומת זאת, אין יתרון ברכישת מנוי שנתי לתמיכה של יצרן ההפצה. בעסקים וחברות, ברוב המקרים התוכנות שמריצים על הלינוקס – הן יותר חדשות ממה שמגיעים עם ההפצה. לדוגמא, גירסת PHP שמגיעה בהפצת RHEL 7.4 היא גירסה 5.4.16 כאשר הגירסה היציבה היום לפי אתר PHP היא 7.1.10. אם תתקין את 7.1.10 על ה-RHEL ויהיו לך בעיות שה-PHP לא מצליח לרוץ, רד-האט לא תתן לך שרות הואיל והם נותנים אך ורק שרות לחבילות שהגיעו עם ההפצה עצמה, לא מ-REPO נוספים. דוגמא נוספת: רוצה להשתמש ב-NodeJS? הגירסה שקיימת היום ב-EPEL REPO היא אכן גירסת ה-LTS האחרונה, אבל שוב – מכיוון שזה REPO חיצוני, אין תמיכה רשמית מצד רד-האט.

לכן אני ממליץ לחברות לחשוב על כמה נקודות:

  • אם יש בחברתכם IT שנותן תמיכת לינוקס, ואתם חושבים במהלך השנה להכניס טכנולוגיה/פלטפורמה חדשה – קחו יעוץ חיצוני (גם אם זה לשעות בודדות) שמכיר את הטכנולוגיה החדשה. חבל שתשרפו עשרות שעות על תקלות שהיועץ החיצוני כבר מכיר.
  • אם בחברתכם יש חובה להשתמש בהפצה מקורית (RHEL או SLES) ואתם רוצים עדכונים, אז מומלץ לחשוב על רשיונות SuSE Linux Enterprise עם Expanded Support – זה יתן לכם עדכונים גם ל-RHEL וגם ל-SUSE וזה גם יותר זול מ-RHEL מבחינת רישוי שנתי.
  • כיום כמעט בכל פרויקט לינוקס, החבילות מגיעות מבחוץ (Github או REPO חיצוניים) אינן נתמכות ע"י יצרן ההפצה ולכן אם אין לכם צוות לינוקס בחברה שיכול לבצע אינטגרציה במסגרת הזמן שאתם רוצים – קחו יעוץ חיצוני (כדאי לסכם שיכתבו עבורכם תיעוד).
  • אם אתם משתמשים (או חושבים לעבור) לאובונטו, עדיף לרכוש בנק שעות חודשי ליעוץ מומחה.

קונים/מטמיעים שרתים? כדאי שתקראו

ברוב החברות, עד שהם רוכשים שרתים אפשר לפתוח בקבוק שמפניה. רוב החברות רוכשות שרתים אחת לכמה שנים ועם כניסת טכנולוגיות הוירטואליזציה השונות, כמות השרתים הנרכשת – קטנה. אחרי הכל, הרבה יותר קל וזול לדחוף עוד כמה עשרות ג'יגהבייט זכרון לשרת ואולי להוסיף/לשדרג מעבדים מאשר לרכוש ברזל חדש (האמת שיש לי בנושא ויכוח עם כמה אנשי IT. אחרי הכל, שרתים בסיסיים שכוללים 2 מעבדים 4 או 8 ליבות ו-16 ג'יגה זכרון + 2 דיסקים SATA – לעיתים יותר זולים משדרוג שרת קיים, תלוי בגודל השדרוג) – בתחום הזה כל חברה מחליטה לעצמה איך ולאן מתקדמים.

תחום השרתים עצמו די מתפתח. היו לנו שרתי Blade (זוכרים?) וכיום יש מחברות כמו SuperMicro שרתים שהם Twin שהם 2 או 4 שרתים במארז 2U או 4U (בהתאמה) וחברות אחרות גם העתיקו את הטכנולוגיה. היום גם ניתן להכניס דיסקים SSD PCI שעברו דיאטה רצחנית והם בעובי 7 מ"מ וניתן להכניס בין 10-15 דיסקים כאלו במארז 1U (תלוי ביצרן). מבחינה פנימית – כל יצרן בנה לעצמו פתרונות (שחלקם הגדול די קנייני) על מנת לבדל את מוצריו מהמתחרים. חלק מהפתרונות לדעתי תמוהים, חלק מעניינים – אבל ברוב המקרים הטכנולוגיה סגורה. קחו לדוגמא את HP – תכניסו דיסקים שאינם של HP (שבעצמם כלל לא מייצרים דיסקים) ותקבלו הודעה מעצבנת שהדיסקים אמנם יעבדו אבל אם תהיה תקלה – לא תקבלו LED אדום על אותו דיסק. בשבילי כאחד שעוקב כמעט מדי יום לגבי טכנולוגיות חדשות כמעט בכל סוג חומרה – זה מעצבן, כי תמיד יש פתרונות חדשים במחירים מעניינים. בשביל חברות – זה כלל אינו ISSUE, הם פשוט יקנו את הדיסקים מיצרן השרת וישלמו עוד כמה אלפי דולרים. בגלל זה אני מעדיף שרתים "לבנים" מיצרנים כמו TYAN, SuperMicro, ASRockRack, Gigabyte ו-ASUS (האחרונים יותר מייצרים לוחות אם מאשר שרתים מוכנים ללקוח).

ישנה נקודה חשובה שלצערי אינה ידועה רבות כשרוכשים שרתים חדשים: לא מומלץ להכניס אותם ל-DMZ שלכם. מדוע? אסביר.

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

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

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

ישנם לעיתים חורי אבטחה ממש גדולים. קחו לדוגמא את ה-Management Engine של אינטל שנמצא בכל שרת ובכל תחנת עבודה (שכוללים את הדרייברים של אינטל). משנת 2010 ישנו חור אבטחה רציני שתוקף יכול להגיע אל ה-Management Engine (שנמצא כחומרה בתוך המכונה), להשתלט עליו ולעקוב אחרי מה שקורה במכונה במקרה הקל או להזיק לדברים שרצים במכונה במקרה היותר גרוע. שום פירמוט או החלפת דיסקים לא יעזרו. תצטרכו להשתלט על ה-Management Engine מחדש על מנת לפתור את הבעיה. לאינטל לקח 7 שנים עד שבחודש מאי הם שחררו עדכון. החור קיים ב- Intel's Active Management Technology (AMT), Standard Manageability (ISM) ,Small Business Technology (SBT) מגירסאות 6 עד 11.6. האם עדכנתם אצלכם את השרתים לחסום את הפירצה הזו? (אפשר לקרוא עוד על כך כאן)

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

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

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

על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

לסיכום: OpenShift היא לא מערכת קלה להקמה (יש צורך בידע ב-Ansible אם רוצים להקים אותה על מספר מכונות, אגב – אפשר להרים אותה על דסקטופ עם 16 ג'יגה זכרון בעזרת MiniShift) ויש צורך בידע רציני על מנת להקים ולהגדיר דברים, אבל אחרי שהכל מוקם, יש צורך בפחות ופחות "התעסקות" עם המערכת. זו מערכת שנבנתה עם מחשבה מראש על מפתחים שלא הולכים לעבור קורס קונטיינרים, יחד עם שמירת כל הרגולציות ו-Lifecycle שחברות דורשות.

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

ב-רד-האט שחררו מסמך ארוך לגבי השינויים ברד-האט 7.4 (וכמובן כל הדברים נמצאים ב-CentOS 7.4) שנמצא כאן ומאוד מומלץ לקריאה לפני שדרוג שרתים. ישנם שינויים כמעט בכל תחום, Kernel עם עדכוני מודולים, תמיכה בדרייברים חדשים, חבילות בגירסאות חדשות (ה-Rebase שהזכרתי לעיל). בלינק לעיל תוכלו למצוא את ה-General Updates שמדבר בכלליות על השינויים ומתחתיו פירוט לגבי השינויים.

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

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

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

הפריצה ב-Equifax והבעיות ב-Enterprise

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

מקור הפריצה גם ידוע: בחברה השתמשו בפלטפורמת פיתוח Apache Struts המאפשרת פיתוח אפליקציות WEB ב-JAVA בקלות. חור האבטחה התגלה וטלאי תיקון שוחרר במרץ, אבל ב-Equifax לא ממש טרחו להטמיע את הטלאי, מה שנוצל בחודש מאי כדי לפרוץ ולגנוב את הררי המידע.

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

וכאן בדיוק מתחילה הבעיה..

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

אבל ישנם 2 בעיות בסיסיות ששום טכנולוגיה כמו FW/IPS/WAF וכו' לא ממש יכולות לפתור.

נתחיל בבעיה היותר קלה לפתרון שרובם כלל לא מיישמים. אני קורא לה "סימוכין עיוור" – שורת שרתי אפליקציה פנימיים מתחברים ל-SQL כלשהו ושולפים מידע. בד"כ אתר מבוסס Web או אפליקצייה וובית או אפליקציית מובייל – יעבירו בקשות מהאפליקציה או מהשרתי Front End לשרתי Back End, שרתי ה-Back End יתשאלו את ה-SQL, יבצעו סינון/סידור פלט ויעבירו את הנתונים בחזרה לשרתי Front End או אפליקציה. עד פה הכל טוב ויפה, וכאן יש לנו "סימוכין עיוור" – מכיוון שכל השרתי Back End ושרת ה-SQL נמצאים בכתובות פנימיות, אין שום מגבלה לכמות השאילתות (ובמקרים מסויימים גם אין סינון שאילתות) ששרתי ה-Back End יכולים לשלוח אל ה-SQL ולהעביר הלאה את המידע. שאילתה אחת או מיליון – זה אותו דבר. ה-IPS או ה-WAF יכולים להגן נגד שאילתות רחבות (ה-*), וכך בדיוק נגנב המידע מ-Equifax (מבלי להיכנס לכל הפרטים הטכניים של הפריצה).

הבה נדגים זאת: חברת תקשורת סלולרית מפעילה מוקד שרות לקוחות. מחשבי פקידי השרות לקוחות מריצים אפליקציות ווביות שמתשאלים ה-SQL נון סטופ לגבי פרטים על הלקוחות והפקידים גם מבצעים שינויים בפרטים (שינוי חבילה, חסימת מספר, שינוי פרטי לקוח ועוד ועוד). האם יש איזו מגבלה של כמות שאילתות פר PC? סביר מאוד להניח שלא וסביר להניח שגם לא נמצא מגבלה כזו גם באפליקציה הסלולרית או באתר החברה, וכך יוצא מצב שאם מאן דהוא פורץ ואני מוצא פריצה בספריה שהחברה משתמשת כדי לבנות את האפליקציית Web – אני יכול להקים מספר מכונות VM אצל ספקי ענן שונים (או יותר גרוע – כמה עשרות קונטיינרים פר VM) – הפורץ יכול לתשאל דרך החור שהוא מוצא את ה-SQL שאלות ובעזרת סקריפט שהוא יכול לבנות – הוא יכול לשאוב את המידע מה-SQL, ועד שהחברה תעלה על כך – הפורץ כבר יעלם לו (אחרי הכל, כשפתוחים חשבון אצל ספקי ענן, ספק הענן אינו מחטט בציציות הלקוח – כל עוד יש ללקוח כרטיס אשראי כלשהו [גם אם מדובר בכרטיס חד פעמי או אפילו קרדיט שהתקבל מביקור בכנס]), אף אחד לא יעצור את אותו פורץ לעשות כרצונו, ואם הוא רוצה – הוא יכול לעשות את הכל דרך VPN או הקמת VPN על ספק הוסטינג נידח כלשהו. בהצלחה במציאת הפורץ.

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

כיום רוב העולם כבר למד לעבוד עם תוכנות/ספריות/פלטפורמות חיצוניות שמדיניות עדכוני האבטחה שלהם לא תמיד ברורה והם אינם כלולים באיזה Repository של הפצת לינוקס. יש כיום את Github שבמקרים רבים יכול להציל מפתחים ואנשי IT עם פרויקטים שאנשים כתבו והעלו ורבים משתמשים בכך כדי לפתור בעיות וכדי לממש דברים שונים, אולם כלי ה-IPS לדוגמא לא ממש מגלים חורי אבטחה וכלי סריקה לא ימצאו את החורים כי לפעמים אין CVE לחור אבטחה לכלי שמישהו פיתח, העלה ל-github ושכח בכלל מהפרויקט לאחר זמן מה. יותר מכך – במקרים רבים ההטמעה עצמה מוטמעת עם הרשאות שגויות (ברמת Administrator או root), עם הרשאות קבצים שגויות, או שפתחו יוזר ב-SQL ברמת "הכל כלול" (רוצים דוגמא? לכו תבדקו בחברה אלו הרשאות ה-Jenkins מותקן ורץ. הוא לא אמור לרוץ כ-root).

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

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

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

החלוקה

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

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

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

התשובה: אני מעריך בין 1 ל-2. להלן הסיבות מדוע המספר נמוך:

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

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

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

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

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

אז מה ניתן לעשות בנידון? איך ניתן להשיג עוד עבודות? להלן מספר נקודות חשובות:

  • פרסם עבודות שאינן מתאימות לך. אתה מומחה בפייתון ומישהו מחפש מתכנת ++C? קח את פרטיו ופרסם את פרטי ההצעה (אתה יכול לפרסם כאן וכאן).
  • עדיין לא הומצאה מכונה לקריאת מחשבות ואיש אינו יודע אם אתה במצב של 0 עבודות או שאתה מחפש עבודות, מחפש עבודה קבועה לחצי משרה, מחפש משרה מלאה לטווח ארוך וכו'. אל תתבייש, תפרסם זאת! (הח"מ מחפש לחצי משרה 🙂 ), זו הדרך הכי מהירה שחברים ישתפו זאת וסיכוייך לקבל משרה כך אינם נמוכים.
  • פרסם תכנים משלך על התחומים שאתה נותן בהם שרות(ים) ומדי פעם תבצע קצת SEO כך שגוגל יעלה את דירוג הבלוג/אתר שלך.. להלן דוגמא על קונטיינרים:

  • הדגם את יכולותיך. קל לדבר ולכתוב על דברים אבל אם יש משהו שמושך אנשים להתעניין בשרותיך – הם הדגמות של הדברים. התקנה של דברים מאפס, הגדרות שונות, הסברים איך מפעילים דברים וכו'. כל מה שאתה צריך זה חשבון בגוגל, מיקרופון ותוסף Nimbus לכרום (ניתן להתקנה מכאן). להלן דוגמא:
  • כרטיסי ביקור – נפגשת עם מישהו? אתה ב-Meetup ומשוחח עם אנשים? חלק כרטיסים, אולי יחזרו אליך. אל תשאיר אנשים עם תהיה "הבחור שפגשתי רציני, חבל שאין לי את הפרטים שלו".
  • הסעיף הבא נתון למחלוקת ביני לבין חבריי אך אני עדיין עומד על שלי: אם אתה טוב בתחומך, שקף זאת במחיר שאתה גובה. הנה כמה דוגמאות למחירים שמהם לא כדאי לרדת (תחום סיסטם/Devops/אינטגרציה/יעוץ). תזכרו שכעצמאים המדינה עושקת אותנו בכל מצב:
    • עבודה חד פעמית חרום לתיקון תקלה (מעכשיו לעכשיו) – לא פחות מ-300 שקל
    • חצי משרה קבועה – לא פחות מ-150 שקל
    • משרה מלאה קבועה (תשלום כנגד חשבונית, לא תלוש משכורת) – לא פחות מ-120 לשעה
    • יעוץ מומחה – פר שעות (בד"כ לוקחים מינימום שעה או שעתיים) – לא פחות מ-200 לשעה
  • "לחפור" קצת. הגעת ללקוח שרוצה ממך עבודה X. בדוק אם יש עוד דברים שאתה יכול לעשות עבורו ובכך להרחיב את העבודה או כמות שעות העבודה.
  • חשוב: דרוש מקדמה כאשר מדובר בעבודה גדולה. שיטות תשלום של ש+60 או ש+30 הן נחמדות אבל אם אין לך כרגע עבודות שאתה עושה בנוסף, אתה יכול להיתקע למצוקת מזומנים. אין כללים לסכום אולם אני לדוגמא נוהג לבקש בין שליש למחצית הסכום כמקדמה (בהתאם לכמות השעות או מחיר הפרויקט) וחשוב לוודא שהמקדמה תשולם לפני שאתה מתחיל לעבוד.

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

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

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

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

Solaris / SPARC – הסוף

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

אז מדוע בעצם Solaris מתה? מדוע צוותי בניית מעבדי ה-Sparc בדרך לארוז את החפצים ולחפש עבודה אחרת? לעניות דעתי, התשובה לכך קשורה ב"שידוך"  בין 2 הצדדים. SUN היתה חברה שעברה שינוי מאוד קיצוני עד למכירתה (כל המוצרים של SUN – הקוד שלהם שוחרר תחת רשיונות שונים) ואילו אורקל הלכה בדיוק בכיוון ההפוך – הם סגרו וזרקו יותר ויותר פרויקטים מבוססי קוד פתוח שהחלו להיכתב באורקל (כמו BTRFS וכו'). אורקל קנתה את SUN כי אורקל חשבה שהיא כך תוכל להתרחב ותוכל למכור ללקוחות פתרונות משולבים חומרה ותוכנה עם רווח נאה מאוד לאורקל.

בהתחלה זה עבד לא רע. בכל זאת, ל-Sun היו שרתים כלל לא רעים, פתרונות סטורג' מבוססי ZFS, פתרונות משולבים כמו Exadata ועוד מוצרים שחברות גדולות רכשו, אך הבעיה הגדולה ביותר היתה – סטגנציה. מערכת ההפעלה Solaris לא קיבלה עדכונים רציניים, מערכת ה-ZFS גם לא קיבלה תכונות חדשות ורציניות מאז סולאריס 10, וגם מעבדי ה-SPARC החדשים לא ממש היוו איום רציני לאינטל (שבסופו של דבר כבשה את שוק השרתים בכל מובן). אינטל פתחה מרכזי לינוקס בתוך החוברה ובסבלנות ועבודה עם יצרני הפצות לינוקס כמו רד-האט ו-SuSE כדי לשפר עוד ועוד את ליבת הלינוקס (ואת המעבדים עצמם) על מנת לתת תוצאות לא-פחות-טובות מהשילוב של סולאריס ו-SPARC וכיום מבחינה טכנית, אין שום הצדקה טכנולוגית להטמיע Solaris. אם אתה מחפש פתרון מבוסס יוניקס, פשוט תתקין לינוקס ותגמור עם זה, שלא לדבר על כך שדברים שנכנסו חזק לטרנד כמו Machine Learning או IOT – אתה צריך לינוקס וסולאריס לא יתן לך פתרון (בהצלחה להפעיל כרטיסי Tesla עם סולאריס. מנסיון – זה לא כיף, גם כשיש דרייברים של nVidia).

כשחברה מפתחת מערכת הפעלה, בין אם מדובר במערכת שהבסיס שלה הוא קוד סגור (מיקרוסופט) או קוד פתוח (יוניקס) או משולב (zOS) – החברה צריכה להיות כמה שיותר "שקופה" ולסייע לכל מי שרוצה בכך, בין אם מדובר בחברות המפתחות תוכנה (ISV) או חומרה (IHV) או אינטגרטורים עצמאיים ולמעט עניין רשיונות למערכת הפעלה – הדבר האחרון שהחברה צריכה לעשות זה לשלוח מכתבי איום לאינטגרטורים שמנסים לתת פתרונות ללקוחות שמשתמשים במערכת ההפעלה של החברה. דבר נוסף הוא פתיחת טכנולוגיות – גם IBM, גם מיקרוסופט ובוודאי רד-האט, סוזה, אובונטו, VMWARE ואחרים – כשהם מפתחים דברים חדשים ורוצים לשתף את זה בציבור, אתה תמצא תוך זמן קצר את הקוד ב-GitHub ומפתחי החברה ישמחו לסייע בבעיות או בקבלת רעיונות ושיפורים לדברים החדשים שהם שחררו. ככה זה היום – חברות פיתוח מערכות הפעלה כבר הפסיקו לפחד מקוד פתוח והן דווקא מאמצות את המהלכים בחום. אתם יכולים להיכנס ל-GitHub ולראות לדוגמא פרויקטים של מיקרוסופט, IBM, VMWARE וגם Oracle (אם כי מה שאורקל מעלה זה סקריפטים וכלי עזר שהמהנדסים פיתחו, לא פרויקטים עצמאיים) כך שאם נמדוד ונדרג חברות מבחינת תרומת קוד ופרויקטים – נקבל את אורקל במקום די עגום שם למטה.

אורקל מנסה גם ללכת בשיטת ה-Me too. פתרון הוירטואליזציה שלהם? העתק של Xen. פתרון הלינוקס שלהם? העתקה ישירה מ-RHEL (של רד-האט) ואפילו הכלים המיוחדים שאורקל העבירו מסולאריס – כיום ב-2017 יש להם חלופות שהן בקוד פתוח לגמרי וכמובן רצות על כל הפצת לינוקס. גם בתחום הענן אורקל התעוררה מאוחר מדי ואם תסתכלו מבחינת דוחות Market Share, תוכלו לראות שאורקל נמצאת בד"כ בגרפים בתוך קטגוריית ה-Others. איך אורקל ישיגו לקוחות לענן שלהם? בכך שהם יעשו כל מאמץ לדחוף את הלקוחות שלהם שמשתמשים ב-Middleware וב-DB של אורקל – לענן תוך מתן הנחות (אני מנחש: זמניות) ולמי שמתעקש לעבוד On Premise – חכו לחשבוניות החידוש רשיון.

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

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

מוגש כחומר למחשבה.

משפחת ה-Xeon W החדשה של אינטל. שווה לרכוש?

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

בשבוע שעבר אינטל הכריזה על משפחת מעבדים חדשה, ה-Xeon W שמיועדת (כפי שהאות W רומזת) לתחנות עבודה. מבחינת דירוג, מעבדים אלו לתחנות עבודה יושבים באמצע, כאשר ברמה הראשונית יש את ה-Xeon E3 (כלומר תקבל משהו שהוא טיפ טיפה יותר מ-i7 לדסקטופ, אבל עם מגבלות של 32 ג'יגהבייט זכרון), לאחר מכן מגיעים דגמי Xeon W ואם אתה צריך יותר מכך, אתה מוזמן לעבוד למשפחת ה-Xeon החדשים תחת שם הקוד Purley. אם נשווה זאת לדגמים קודמים, הרמה ההתחלתית היתה גם אז Xeon E3, אם אתה צריך יותר אז היית רוכש Xeon E5 V4 מסידרה 16XX ואם אתה צריך מערכת עם זוג מעבדים, היית רוכש מערכת עם מעבד (או 2 מעבדים) מסידרה 26XX. בתכל'ס – אף אחד מיצרני תחנות המותג לא היה מוכר מערכות עם 16XX אלא מערכות עם מעבדים 26XX כאשר היית יכול לרכוש מעבד יחיד ולהרחיב יותר מאוחר ל-2 מעבדים מאותה משפחה. אם לעומת זאת היית בונה מערכת, היית יכול לקנות לוח אם לתחנת עבודה ולהרכיב בו מעבד Xeon E5 V4 16XX ואם היית רוצה ביצועים נוספים, היית יכול להחליף אותו למעבד E5 26XX. טריק נוסף נחמד שהיה הוא האפשרות להחליף מעבד Xeon E5 דור 3 (כלומר V3) לדור 4 מבלי להחליף חומרה נוספת, רק עם עדכון BIOS והחלפת מעבד+קירור.

מאז שאינטל הוציאה את דור 4 ואת מעבדי ה-Kaby Lake לדסקטופ, חלו כמה שינויים גדולים בתחומי המעבדים. AMD יצאה עם משפחת ה-Ryzen והראתה שאפשר למכור לציבור מעבדים מכובדים עם יותר ליבות בפחות מהמחיר שאינטל מבקשת על Kaby Lake ולשם שינוי – גם לתת ביצועים מכובדים. בחודש שעבר AMD גם שחררה את משפחת ה-Threadripper שלה שנותנת ללקוחות ה-Prosumer מעבדים עם עד 16 ליבות ו-32 נימים, עם תמיכה של עד 1 טרהבייט זכרון ECC, עם 64 נתיבי PCIE ובלי שום נעילת מעבדים (מבחינת Overclocking) במחירים נמוכים בהרבה ממה שאינטל מציעה.

אינטל בתגובה הוציאה את מעבדי ה-Skylake-X עם Chipset חדש (ה-X299 – כך שאתה חייב להחליף לוח אם) ובמשפחת מעבדי ה-Skylake-X ישנם מעבדים שבקצה הנמוך הם עם 4 ליבות (ללא תצוגה ושמיד מבטלים לך חצי מפונקציונאליות לוח האם) ועם מעבדים די ראויים בסידרת ה-78XX כאשר בקצה העליון יש מעבד כמו 7890XE עם 18 ליבות, 36 נימים, 44 נתיבי PCI ואפילו RAID לדיסקים מבוססי NVME! כמובן שאינטל גובה על המחיר למעבדים אלו מחיר מפולפל. על ה-7890XE היא גובה 2000$ (זה כמובן לא כולל לוח אם די יקר). הפתרון המתחרה של AMD עולה 1000$ (עם פחות 2 ליבות אבל עם יותר פונקציונאליות) – אבל אינטל לא ממש מתעניינת בתחרות ואלו המחירים.

וכרגיל, כשזה מגיע לאינטל, עצם העובדה שהיא מוכנה למכור מעבדים עם יותר ליבות במחיר יותר גבוה – לא אומר שהיא תפתח פונקציונאליות שהיא מייעדת ל-Enterprise – למשתמשי ה-Prosumer! חס ושלום! רוצה זכרון? יופי, נגביל אותך ל-128 ג'יגהבייט. זכרון ECC? לא ולא! אז מה אם אתה תשלם מחיר יקר בהשוואה לפתרונות של AMD?

מה שמביא אותנו למעבדי ה-Xeon W החדשים. המעבדים האלו .. הם בעצם ה-Skylake-X רק שאינטל הפעילה כמה ביטים בתוך המעבד והגבילה את התאימות שלהם. זה שקנית לוח אם עם X299 Chipset לא אומר שתוכל לרכוש Xeon W ולהכניס אותם (למרות שהם בדיוק עם אותם כמות פינים – 2066). בשביל זה אינטל הוציאה Chipset חדש, ה-C422 וכמובן אותו Chipset מקבל רק Xeon W ואתה לא יכול לתחמן בהכנסת מעבד Skylake-X. גם מחירי ה-Xeon W קיבלו "שדרוג" ואתה תשלם בין 400-1000$ יותר על אפס תוספת בביצועים, אבל תוכל להכניס זכרון ECC (בלבד!) עד 512 ג'יגהבייט, ותקבל את שאר הבבל"ט של ה-RAS ושאר ירקות שאינטל דוחפת ללקוחות Enterprise.

עד לשנה האחרונה, לחברות שרצו תחנות עבודה או ביצועים של תחנות עבודה, לא היו הרבה ברירות. או Xeon עם המחירים הגבוהים או מעבדים כמו 6950X שהיה יותר מיועד ל-Enthusiasts עם תג מחיר מאוד גבוה. כיום לעומת זאת – המצב שונה לחלוטין. תחנות קצה רגילות (דסקטופ) לחברות – אפשר לרכוש עבורן Ryzen Pro (שכולל את הפונקציות ל-Enterprise) או Ryzen רגיל ולתחנות דסקטופ רגילות עבור הפקידות ניתן לרכוש מעבדים כמו Ryzen 3 (מגיע עם 4 ליבות ויותר זול מ-i3 שמגיע רק עם 2). לקצה הגבוה של תחנות עבודה אפשר לרכוש תחנות עם Skylake-X או AMD Threadripper (בהתחלת השנה כל יצרני המותג יאפשרו רכישה כזו), ואם מתעקשים על פונקציונאליות של Enterprise אז ניתן לרכוש את ה-Xeon W או לחלופין תחנה עם מעבד כמו EPYC 7401P שעולה $1050 אבל מגיע עם 24 ליבות, 48 נימים, 124 נתיבי PCIE ותמיכת זכרון ECC עד 2 טרהבייט ובעודף שנשאר במקום רכישת Xeon W אפשר לרכוש מספר SSD או כרטיס/ים GPU טוב/ים.

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

אינטל מציגה – הדור השמיני .. בערך

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

אינטל הציגה לפני כשנה (ב-20 לאוגוסט 2016) את משפחת ה-Kaby Lake, מעבדים חדשים לדסקטופ ולמובייל, הדור השביעי החדש. כשמנפים את כל הילולי היח"צ, מבינים אנשי מקצוע רבים שקניה של המעבדים הללו לא תועיל בהרבה. כן, יש שיפור של 10-15% (וגם זה רק במקרים מאוד מסויימים), אבל שינויים ושיפורים משמעותיים – אין ממש כאן. בהמשך הדרך אינטל הציגה את ה-Kaby Lake-X, משפחת מעבדים שצריכה לוח אם חדש עם צ'יפ X299, רק שעד היום רבים וטובים לא הצליחו להבין מה עבר בראש להנהלת אינטל בחיפה. קניה ושימוש במעבד כזה מבטיחה לך מיידית שהלוח אם היקר שקנית – מחצית ממנו מיד תהיה מושבתת ברגע שתכניס מעבד Kaby Lake-X לתושבת, ושלא לדבר על כך שאין אפילו את היחידה הגרפית במעבד. בקיצור – אתה משלם יותר ממחיר מעבד Kaby Lake (ואם תכלול את מחיר הלוח אז המחיר יוצא הרבה יותר), ואתה מקבל .. פחות. מה בדיוק הטעם לרכוש מעבד כזה ממשפחה כזו? אין לי ולאחרים מושג ירוק.

אז שלשום אינטל ניסתה את מזלה בפעם השלישית בהצגת .. Kaby Lake Refresh כלומר "דור שלישי" ל-Kaby Lake (ובקיצור KLR), וגם הפעם אינטל הבטיחה ניסים ונפלאות, רק שהם יותר התרכזו בתוכן וידאו ברזולוציית 4K (ואם מי שקורא את הוידאו חושב שמעבד כזה ללא כרטיס גרפי חיצוני יתן פתרון טוב לעריכה – הוא טועה טעות מרה), וכרגיל גם הפעם אינטל הצהירה שהמעבדים החדשים יהיו מהירים ב-10-15% בהשוואה ל-Kaby Lake (על Kaby Lake-X אף אחד לא דיבר במהלך החשיפה).

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

להלן התשובה של אינטל (לחצו להגדלה):

עד היום בסידרת המעבדים U של אינטל בגירסת ה-15 וואט, היו 2 ליבות ו-4 נימים. אינטל סוף סוף בדגמים i7-8650U, i7-8550U, i5-8350U, i5-8250U מוסיפה 2 ליבות ומאיצה את מהירות השעון כשהמעבד נמצא במצב Turbo (אם כי מהירות הבסיס יותר נמוכה, לא באשמת אינטל, יש גבול למה שאפשר להוסיף במגבלת מעטפת של 15 וואט). בנוסף, אינטל הכפילה את זכרון המטמון בדגמי i7 ל-8 מגהבייט ובדגמי i5 ל-6 מגהבייט. אם נתרגם את זה לביצועים אז אם האפליקציה שאתה מריצה אינה מתפרסת על נימים וליבות נוספים, תקבל עוד 5-15% בביצועים אולם באפליקציות שיודעות לנצל כמות ליבות ונימים, תקבל ביצועים יותר גבוהים עד 40-50%. בכל הקשור לכמות זכרון במחשב, היצרנים יוכלו להציע עד כמות זכרון של 32 ג'יגהבייט (בניגוד למגבלת ה-16 ג'יגהבייט בעבר). שימו לב: המעבדים האלו לא יופיעו בכל המחשבים הניידים אלא יותר במחשבים בסקטור ה-Ultra Book במחירים שמתחילים ב-1000$ ומעלה (מחיר המעבד בלבד הוא בסביבות ה-410$!!)

אינטל בחודשים הקרובים תציג את שאר המעבדים שמיועדים לדסקטופ או למחשבים ניידים כתחנות עבודה (Mobile Workstation – סידרת ה-35 וואט) תחת השם Coffee Lake ובשנה הבאה היא תציג עוד מעבדים באותו דור (אם כי ביצור של 10 ננומטר) תחת שם הקוד Ice Lake. על מעבדי ה-Coffee Lake אפרסם פוסט בקרוב אבל ממה שכבר ידוע, אינטל החליטה להוסיף לכל המעבדים עוד 2 ליבות ולהרחיב את הזכרון מטמון בחלק מהמקרים.

כפי שציינתי לעיל, עניין הליבות הוא מאוד חשוב ואני שמח שאינטל החלה לזוז בעניין. אחד הצעדים המבורכים שאינטל עשתה היא להוציא את סידרת ה-Sky Lake X שסוף סוף מאפשרת לצרכנים לרכוש מעבדים ופתרונות עם 8 עד 18 ליבות מבלי למכור כליה או למשכן את הבית בקניית מעבדי Xeon (הסידרה הזו לא מחליפה את Kaby Lake אלא רק מוסיפה דגמים לשוק היותר מקצועי). אפשר לראות זאת גם בסידרת מעבדי ה-Atom C3000 החדשה שמיועדת לשרתים קטנים (דגש על "קטנים", זה מובנה בתוך לוח אם Mini ITX) ששם אינטל סוף סוף מציעה מעבדים עם 16 ליבות ו-16 מגהבייט זכרון מטמון במחיר זול (יחסית!) של 449$ (הלוח עם המעבד עולה בערך $1000).

מה שעכשיו אינטל צריכה לעשות, זה להפסיק עם ההתנהגות של "בשביל מה לך?". אינטל מדור לדור של מעבדים ו-Chipset מקצצת בכמות ניתובי ה-PCIe. מילא היה מדובר בחסכון מחיר לצרכן אך כפי ש-AMD מוכיחה עם מעבד ה-Threadripper 1900X שלה (ששם AMD מציעים 8 ליבות ו-16 נימים עם 60 ניתובי PCIe זמינים למשתמש! במחיר של 549$ למעבד) – אין כאן שום חסכון. גרוע מכך – בלוחות עם ה-X299 Chipset, כל מקל M.2 SSD עובר דרך ה-Chipset ואם יש לך 2 מקלות או יותר, אתה תקבל ביצועים שמוגבלים ע"י ה-Chipset. ב-AMD אין שום מגבלה כזו במעבדי ה-Threadripper, ואין שום בעיה להכניס אפילו 4 כרטיסים גרפיים ולקבל PCIe X16 על כל כרטיס, דבר שהוא בלתי אפשרי בלוחות המבוססים על X299 וחבל.

עוד נקודה שאינטל צריכה להבין – היא עניין המחירים. כש-AMD יצאו עם מעבדי ה-Ryzen, אינטל חתכה במכה אחת את המעבד עם הכי הרבה ליבות שהיה לה לדסקטופ (ה-6950X) מ-1700$ למחיר של 628$ (כיום באמזון ניתן להשיג אותו במחיר מצחיק של $359!). כיום בסידרת מעבדי ה-Sky Lake-X, מחיר מעבד של 16 ליבות ו-32 נימים שיצא בקרוב יעלה לא פחות מ-1700$ (בשעה שמעבד Threadripper עם 16 ליבות ו-32 נימים עולה $1000). כפי שתיארתי לעיל, גם מעבד כזה יסבול מהגבלות בגלל ה-X299 Chipset אולם עד כה אינטל לא חשבה להוריד מחירים.

לסיכום: לעניות דעתי, אינטל צריכה הרבה יותר להקשיב לצרכנים שהם הלקוחות שלה. מבחינת מכירות, אינטל מוכרת הרבה יותר ללקוחות הדסקטופ והמחשבים הניידים מאשר לשרתים או לסקטורים אחרים. לקוחות רוצים יותר ואם לקוחות מעוניינים, אז כדאי לספק להם את מה שהם רוצים במחיר הוגן. אם לקוח רוצה שהמחשב שלו ירוץ בצורה מעולה ללא תקלות ורוצה להשתמש בזכרון מסוג ECC – אינטל צריכה לאפשר לו במקום לחסום את זה ברמת ה-Chipset. אם לקוח רוצה להכניס 4 מקלות M.2 ולקבל מהירות מקסימלית ב-RAID-5 ולא להיות מוגבל על ידי Chipset – אפשרו לו ותחסכו את הפדיחות ש-AMD מציעה כל מה שלא הצעתם ובמחיר יותר זול.