June 2009 - Posts
האם אנו בדרך החוצה מהמשבר הגדול?
האם משק כנפי השגשוג נשמע?
האמנם כבר הגענו לתחתית ועכשיו אנחנו בסימן עליה?
האמת – אין לי מושג. מה שאני כן יודע, וכל אחד מוזמן לתת איזו פרשנות שנראית לו מתאימה, הוא שאנחנו מגייסים.
לקבוצת ה- MCS במיקרוסופט דרושים שני ארכיטקטים:
- ארכיטקט תשתיות, להובלת פרוייקטי תשתית נרחבים בארגונים גדולים
- ארכיטקט תוכנה, לגיבוש והובלת ארכיטקטורת תוכנה במערכות גדולות.
אין לי כוונה לפרט את כל דרישות התפקיד, כי הן רבות. אסתפק ב- Highlights:
ארכיטקט תשתיות
10 שנות נסיון בתחום
ידע ונסיון ב- Win2008, IIS6, IIS7
ידע ב- Virtualization
נסיון קודם ביעוץ
ארכיטקט תוכנה
8 שנות נסיון בתחום
ידע ונסיון בתכנון מערכות מבוזרות בטכנולוגיות מיקרוסופט
היכרות טובה עם WebForms / WebServices / WinForms / ADO.NET וכל טכנולוגיה רלוונטית נוספת
היכרות טובה עם תוצרי קבוצת P&P
היכרות עם מוצרי מיקרוסופט: BizTalk, Exchange, MOSS – יתרון
ידע בטכנולוגיות עתידיות – יתרון
נסיון קודם ביעוץ
שניהם
אישיות חביבה אך סמכותית
רצון ללמוד וללמד
נכונות לאתגרים
כמובן שכמו לפני כל החלטה חשובה בחיים יש לבנות רשימה מסודרת עם יתרונות וחסרונות. מכיוון שאנחנו אנשים מסודרים, אז הנה רשימה כזו:
יתרונות בעבודה במיקרוסופט
- אתה יודע בדיוק על מי לצעוק כשה- Office נתקע פתאום
- אף אחד לא יגיד לך “איפה אתה עובד? מיקרו-מה?”
- יש לך גישה למתחם חדרי הישיבות המגניב ביותר בארץ
- לא צריך לעמוד בפקקים של כביש 5 כדי להגיע למשרד (אבל כן צריך לעמוד בפקקים של כביש 531…)
- אפשר לשתות כמויות קולה עד שתקבל הרעלה
חסרונות בעבודה במיקרוסופט
- כולם בטוחים שאתה יודע בדיוק איך לתקן את השגיאה שהם נתקלו בה ב- Sleep של Windows 2003 או משהו
- כולם מתפלאים שעוד לא פגשת אישית (מה פגשת? אירחת אצלך בבית!) את ביל גייטס
- אתה כל הזמן צריך לתקן את כולם: “מייקרוסופט, לא מיקרוסופט!”
- אתה הופך אוטומטית להיות אויב העם מבחינתם של קנאי Linux / Open-Source למיניהם
הצהרה חשובה מאוד: הנ”ל כתוב בלשון זכר אך מתייחס כמובן לכל המינים.
מכיוון שכפי שניתן לראות ישנם יותר יתרונות (5) מחסרונות (4), המסקנה המתבקשת היא שכדאי לעבוד במיקרוסופט.
אם גם אתם חושבים כך, וגם חושבים שאתם מתאימים לתפקיד, אתם מוזמנים מאוד לשלוח את קורות החיים שלכם לתיבת המייל שלי –
memil@microsoft.com. אני מבטיח לעבור על כל הקו”חים שאקבל, ואנסה לענות עליהם כמה שיותר מהר.
אני מניח שלא אפתיע אף אחד בהצהרה שהשוק נמצא כרגע במצב, איך נאמר, לא משהו, ושמעט מאוד אנשים יעזבו את העבודה שלהם מרצונם החופשי.
עם זאת, דווקא בתקופה זו, חשוב לי להדגיש נקודה שקשורה לעניין הבטחון בעבודה ושנתקלתי בה מספר פעמים.
כולכם וודאי מכירים את ה”גורו” הטכנולוגי. בכל מקום עבודה יש לפחות אחד כזה. זהו מישהו שמכיר .NET לפני ולפנים, מעביר את זמנו החופשי בקריאת בלוגים, חי, נושם ואוכל CLR ובאופן כללי מהווה סמכות עליונה בכל דיון טכנולוגי Hard-Core. (ואם במקרה אתם באים מעולם שאינו .NET, דמיינו שיש במשפט הקודם את המונחים הטכנולוגיים הרלוונטים לטכנולוגיה בה אתם עוסקים)
לחברה בה עובד אותו גורו מאוד נוח שיש מישהו כזה. הוא נותן מענה כמעט לכל אתגר טכנולוגי שמתעורר, מסייע באופן רוחבי לכל הפרוייקטים בחברה, מגלה התלהבות, יוזמה ו”ראש גדול” ובהחלט מסייע לפן העסקי. ברור מאליו שכאשר יעלה החשש הקטן ביותר שאותו גורו נושא עיניו למקומות אחרים – החברה תהפוך עולמות כדי להשאירו אצלה. העלאת שכר, שיפור תנאים, תיאור תפקיד בכיר יותר ומה לא – העיקר שנקודת המשען הטכנולוגית תישאר.
במילים אחרות – אותו הגורו נהנה מ-
Job Security מוחלט. חשוב מאוד, בעיקר בתקופה זו.
עד כאן – הכל טוב ויפה. שני הצדדים מרוצים ואין סיבה לשנות משהו.
הבעיה מתעוררת בצד השני של אותו מטבע – אם החברה לא יכולה לשאת את המעבר של הגורו לחברה אחרת, הרי שהיא גם לא תוכל לשאת מעבר שלו לתפקיד אחר.
אם המחלקה בה נמצא הגורו חייבת אותו אצלה, מה הסיכוי שהוא יוכל להתקדם לרמת החטיבה? מה הסיכוי שהוא יוכל לעבור למחלקה אחרת? מה הסיכוי שבכלל יציעו לו משהו כזה? הרי, מבחינת החברה, אין כל הגיון בהצעה כזו.
הגורו שלנו עלול למצוא את עצמו “תקוע” באותו תפקיד שנים רבות כאשר עמיתיו לעבודה מקודמים בקצב רגיל והוא נשאר באותה עמדה. הוא יעבוד עם אנשים חדשים ויכיר טכנולוגיות חדשות, אבל התפקיד ישאר זהה. בשלב מסויים תגיע ההבנה, ואז התסכול, אך זה כבר עלול להיות מאוחר מדי.
אז מה עושים? איך ניתן להימנע מגורל כזה?
הפיתרון הפשוט והמיידי הוא: אל תהיו ריכוזיים. דאגו להעביר את הידע. ארגנו הדרכות. הקימו אתר לשיתוף ידע. אל תיצרו מצב שבו גוף שלם תלוי רק בכם, משום שאז הסיכוי שתוכלו לצאת משם נמוך למדי.
יותר מזה– זיהיתם “יורש פוטנציאלי”? מישהו שמגלה יכולות לימוד והבנה גבוהות, מהיר כמו שד ואוהב את הטכנולוגיה? קחו אותו והכשירו אותו. פרשו עליו את חסותכם. קחו אותו לפגישות, לכנסים, קשרו אותו לאנשי מפתח, תנו לחברה להבין שאפשר לסמוך גם עליו.
ברגע שהמסר יחלחל, תרוויחו פעמיים:
1. תוכלו להיות מקודמים לתפקידים אחרים, בכירים יותר
2. תיצרו תדמית של איש צוות, שיודע לעבוד עם קולגות, ואינו “זאב בודד”. זהו פרמטר חשוב לקידום.
אני יודע, בתקופה זו המסר הזה נראה קצת תלוש, אבל דרכם של משברים לעבור. וכשזה יקרה - כדאי שתהיו בעמדת זינוק טובה לתפקיד הבא.
מדוע להשתמש בזיהוי מסוג Kerberos? ומדוע הוא רצוי בסביבת SharePoint בפרט?
ישנן מספר סיבות טובות להשתמש ב Kerberos, אולם ראשית כל חשוב להבין מהו סוג הזדהות זה? לפירוט ניתן לקרוא בלינק הבא (קראו את פריטים 59-63): http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook.HomePage
בקיצור, עיקר הסיבות לשימוש ב Kerberos בסביבת SharePoint הן: ביצועים טובים יותר בתהליך ההזדהות (בהשוואה לזיהוי מבוסס NTLM), אפשרות להעביר את ה Credentials של המשתמש לשרתים אחרים (כגון: SQL וכד').
במידה והחלטתם להקשיב להמלצותינו ולהגדיר זיהוי מסוג Kerberos - חשוב לעקוב אחרי ההגדרות הנדרשות במאמר הבא: http://support.microsoft.com/kb/929650
חשוב לשים לב לכל הפרטים במאמר (הארוך ....), בפרט לכך ש:
- Kerberos לא יפעל במידה והגדרתם CNAME Record ב DNS עבור הרשומה אליה אתם מעוניינים שמשתמשים יגלשו ב Kerberos! הפתרון: להגדיר את הרשומה כ A Record
- יש לשים לב להרשאות ה User Rights (ב Policy) שיש להעניק למשתמשים המוגדרים ב Application Pools השונים של MOSS (עבורם אתם מעוניינים בזיהוי Kerberos) ועוד
נקודה מעניינת נוספת: במידה ובארגון שלכם השרתים נרשמים ב DNS ב Zone שונה מה Zone של ה Domain אליו משויכים השרתים - הכרחי להוסיף SPN גם לכתובת ה DNS שבה השרת נרשם, לדוגמה:
שם השרת ב DNS: Server1.Location.Com
ה Active Directory Domain DNS Name הוא: Company.Com
כברירת מחדל לשרת יש את ה SPN הבא: HOST/Server1.Company.Com
ועל מנת ש Kerberos יעבוד כיאות, יש להוסיף את ה SPN הבא: HOST/Server1.Location.Com
דגש נוסף בעת שימוש ב Kerberos: רצוי להימנע ממצבים בהם משתמש חבר במספר רב של קבוצות אבטחה ב AD (המגבלה המוגדרת היא 1,015, אולם עלולות להתגלות בעיות כבר בהיקף של חברות ב 120 קבוצות!) – מה שעלול לפגוע בתהליך ה Logon של המשתמש ל Domain וכן עלול לפגוע בעת גישה לשרתי IIS, SharePoint ולשרתים אחרים (במידה ומוגדר מולם זיהוי מסוג Kerberos). לפרטים נוספים: http://support.microsoft.com/kb/328889
ניתן לעקוף את הבעיה זמנית, ע"י הוספת Keys בשרתי ה SharePoint (וכל שרת נוסף שמחייב הזדהות Kerberos), המאפשרים טיפול ב Packets גדולים יותר של ה Ticket.
יש לשים לב כי למעקף הנ"ל עלולות להיות השלכות על נפח התעבורה ברשת וכן על ביצועי המערכת (תהליך Logon ארוך ועוד ...)!
להלן לינק לבעיות ופתרונות בהקשר של Kerberos (חלקן רלוונטיות ל MOSS וחלקן ל IIS ומוצרים אחרים המבוססים עליו):
http://support.microsoft.com/kb/962943
http://www.harbar.net/archive/2009/01/08/sharepoint-kerberos-configuration-utility-last-call-for-feedback-and-suggestions.aspx
http://support.microsoft.com/default.aspx?scid=kb;EN-US;938305
http://support.microsoft.com/default.aspx?scid=kb;EN-US;911149
http://msdn.microsoft.com/en-us/library/aa377874(VS.85).aspx
http://support.microsoft.com/kb/327825
http://support.microsoft.com/kb/896861
במידה ובכל זאת החלטתם להשתמש בזיהוי מסוג NTLM יש לשים לב לבעיה הבאה (ולפתרון המתואר במאמר), בעת גלישה מהשרת עצמו לאתר מקומי המצוי עליו (מתרחש ב Windows 2003 SP2 ועדכון אבטחה או ב Windows 2008): http://support.microsoft.com/kb/896861
לסיום, אמנם תהליך הגדרת Kerberos עלול להתארך ולהיות מייגע, אולם לדעתי הוא שווה את המאמץ ...
שיהיה בהצלחה!
אפי.
הבלוג הנוכחי אינו מיועד ל DBA, הוא מיועד לך, מפתח, איש בדיקות, מנהל מערכת וכל מי שהביצועים יקרים ללבו. הבלוג נכתב לאחר מספר פגישות עם אנשים טובים שלא היו מודעים לקלות מוניטורינג בסיסי.
איך אני יודע מה מצבי – יש שני כלים פשוטים, שהפעלת כל אחד תתן חצי מהניטור הדרוש. כמובן שאם תיישמו את ההנחיות שלי תקבלו במרבית המקרים רק את כיוון הפתרון – אבל – סביר שתדעו לאן להמשיך.
Performance Monitor
הפעילו את הכלי, ונטרו CPU (רצוי נמוך), disk queue length (רצוי עד 2), SQL Dead Locks (אפס), SQL timeout > 0 (אפס), Cache hit Ratio (מעל 90% ).
מה נלמד מהתוצאות:
1. בעיות דיסק יצביעו על צורך בשנוי מארז האחסון או שינוי קוד ואינדקסים (ראו בהמשך)
2. CPU גבוה – נדיר יחסית, תבדקו שאכן הקוד שלכם גורם לעומס – אולי השרת עמוס ממילא...
3. Timeout & Deadlock – פה תצטרכו כנראה עזרה מ DBA מנוסה
4. Cache Hit Ratio נמוך – ייתכן וצריך עוד זכרון למחשב אך גם שינוי קוד ואינדקסים בא בחשבון
SQL Server Profiler
1. הפעילו את הכלי, אם אין לכם הרשאות – סביר שה DBA ייתן לכם אותן לפחות בסביבות שאינן ייצור.
2. נתרו את RPC Completed ואת SQL Statement Completed בזמן עומס או עבור שאלתות איטיות
3. נסו לזהות שאילתות שלוקחות זמן רב ו/או הרבה קריאות
4. נסו לאתר שאלתות שרצות הרבה פעמים – מליון שאילות של 20ms מזיקות יותר (פי 100 לערך) מ 20 שאילות של 10 שניות
5. אם זיהיתם שאילתות "מזיקות" – אתם ממוקדים – יש לטפל בשאלתות שזוהו – אבל זה כבר לא לבלוג הזה
לסיכום:
שימוש פשוט בשני הכלים יביא אותכם למצב בו במקום לומר יש לי בעיית ביצועים, תוכלו לומר השרת סובל מבעיה בתחום ה XXX או סט השאלתות הזה נדרש לשיפור. ברור כי תוכלו לקבל פתרון טוב ומהיר אם תבואו אם בעיה ממוקדת – שלא נדבר על האפשרות שתפתרו אותה לבד.