שאלה האם אתה ממשיך להשתמש בציוד השרת / ציוד הרשת שלך?


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

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

20




שאלה טובה מאוד - John T


תשובות:


  • באילו תנאים תמשיכו להשתמש בציוד?

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

  • אילו גורמים אתם מחשיבים כאשר מנסים לקבוע את הסיכונים הכרוכים בהמשך השימוש בציוד?

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

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

  • אם אתה מאמין שהסיכון הוא גדול, איך אתה משכנע את ההנהלה להשתחרר על מיתרי הארנק בכלכלה קשה?

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

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

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


13



+1 לקידום היושר - Jimmie R. Houts


  • באילו תנאים תמשיכו להשתמש בציוד?

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

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

  • אילו גורמים אתם מחשיבים כאשר מנסים לקבוע את הסיכונים הכרוכים בהמשך השימוש בציוד?

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

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

  • אם אתה מאמין שהסיכון הוא גדול, איך אתה משכנע את ההנהלה להשתחרר על מיתרי הארנק בכלכלה קשה?

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

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

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

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

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

בהצלחה.


7



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


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

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

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

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


3





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


2





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

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


1





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


1





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


-1