מבנה ארגוני של גוף תשתיות Infrastructure Organization

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

צורת חלוקה	יתרונות	חסרונות	סיכוי לשיפור time to market
תפעול, בנייה, חזון. (run, build, grow) התפעול אמור לכלול גם בנייה של רכיבים סטנדרטיים. בנייה זה דברים לא סטנדרטיים כמו "שדרוג ל- exchange 2010 או כניסה ל- FCOE"	קל לשים SLA על תחזוקה שוטפת\תקלות.	מתח בין תפעול לבנייה. כאשר בנייה מכניסים לייצור דברים לא בשלים. כפילות מסויימת כי ידע צריך להמצא גם ב- RUN וגם ב- BUILD	סיכוי טוב - במידה וצוות התפעול אחראי לפעולות הסטנדרטיות (הקמת שרת, וכד').
לפי טכנולוגיה – אחסון, win לינוקס, VMWARE	מתאים כאשר הטכנולוגיות מופרדות ושונות. יתרון של התמחות בתחום.	סיכוי לשמוע "זה לא אצלי" - בעיית אינטגרציה	קל להגיע למקצועיות
לפי סוג מערכת\LOB כלומר כל המערכות של תחום X	אחריות מקצה אל קצה. לא נופלים דברים בין הכסאות. היכרות טובה עם המערכת ועם הצרכים העסקיים	סיכוי טוב לחוסר סטנדרטיים ולאחר מכן מאוד קשה לבצע פרוייקטים רוחביים.	מוריד את "זמן התקשורת" בין גוף לגוף.
לפי משימה רוחבית: התקנות, שדרוגים, בדיקות, שיפור ביצועים, DRP	התמקצעות במשימה. ככל שהמשימה דומה בטכנולוגיות השונות (DRP ללינוקס WIN ואחסון)	סיכוי לשמוע "זה לא אצלי" – בעיות אינטגרציה	במידה ויש סוג משימה בעייתי – צורה זו גורמת להתמקצעות מירבית
לפי סביבות – ייצור, בדיקות, פיתוח	התמקצעות בסביבה. פחות שומעים "זה לא אצלי" – סיכוי לאיכות טובה יותר כי כל צוות בודק את מה שהוא מקבל	כפילות מסויימת	מדידה של כל שלב – לכן יש סיכוי לשיפור

מדידת מרכזי שליטה ובקרה NOC metrics

מדידה והערכה של גוף ה- NOC \ מרכז התפעול היא משימה קשה. זאת עקב העובדה שבמובן מסויים לגוף ה- NOC עצמו אין ממש שליטה על פעולותיו.
במונח NOC התכוונה כאן Network Operation Center כלומר ל-"חדר המחשב" או "הפעלה" או "מפעילים" או "הגשר" או "תפעול", כלומר הגוף אשר נמצא 7*24, מקורו בהרבה ארגונים במפעילי ה- MF. תפקיד גוף זה לדאוג לפקח על פעולת ה"ייצור" בארגון ה- IT ובמידה ויש תקלה לטפל בה. במידת האפשר בעצמו ואם לא להפעיל את הגורמים המתאימים.כלומר לא מדובר רק על תחום התקשורת.

כאמור חלק מהמדדים כאן הם מדדים שמתאימים רק ל- NOC וחלק מהמדדים הנם מדדים שמתאימים גם לגופים אחרים ב- IT.


פעולות ה- NOC מתחלקות (באופן גס) ל:
1. טיפול בתקלות – CASES – בד"כ לפי נוהל שהוגדר מראש ב- Run Book - ההוראות למפעילים.
2. ביצוע משימות עזר שוטפות – TASKS - (לדוגמה, מעבר על LOGS לוודא שגיבוי התבצע כשורה, התקנת PATCH של WIN על רשימה של שרתים).
בשני המקרים מי שמגדיר ל- NOC את הפעולות לביצוע הוא גוף התשתיות ולכן גם אם יש NOC נהדר לפעמים מדידת גוף זה תתן תוצאות לא טובות – זאת בגלל שגוף התשתיות לא העביר מספיק משימות\אחריות ל- NOC.

להלן מספר רעיונות\הצעות למדידה והערכה של ה- NOC ועובדיו:

1. מדדי זמינות וביצועים – לווא דווקא קשורים ספציפית ל- NOC

• זמינות המערכות. גם תשתיות וגם שירותים תוך התייחסות ל- SLA (זמינות שהובטחה ללקוחות הסופיים) ו- OLA – operation level agreement (זמינות שהובטחה בתוך הארגון בין הגופים השונים– לדוגמה OLA של סביבת האחסון).
• מדידת ביצועי מערכות (זמני תגובה של האפליקציות)
• כמה זמן עבר עד לתיקון התקלה (אפילו אם טופלה מחוץ ל- NOC ) – time to repair.
• d. Monitoring coverage - כמה מהתקלות התגלו על ידי מערכות השליטה והבקרה וכמה על ידי המשתמשים הסופיים.

2. מדדים לכמות ואיכות הטיפול ב- CASES על ידי ה- NOC

• מתוך הזמן לטיפול בתקלה (MTTR) איזה חלק מהזמן היה בטיפול של ה- NOC.
• % סגירה ב- NOC. כלומר איזה אחוז מהקריאות נסגרו ב- NOC ללא צורך להפעיל גורמים חיצוניים.
• יש ארגונים שבהם ה-NOC לוקח שליטה על עבודת HD בשעות הלילה אז נכלל פה גם מדידות HD. כמו כמות תקלות שלא נפתרו והועברו לצוות PC ללא צורך להגיע ללקוח. (שיפור הידע)
• כמה זמן מאז שהתרחשה התקלה ה- NOC התחיל לטפל (ערנות).
• כמות תקלות שנבעו מטעיות ב-NOC (בד"כ טעויות אנוש)
• איכות ה- follow up של תקלות שנפתחו במשמרת. עד כמה עוקבים אחרי התקלות בתדירות רצוייה.

3. איכות כללית של ה- NOC

• תהליך של incident מול problem. כמה פעמים ה-NOC או התומך מצאו דרך למנוע את התקלה בפעם הבאה (על ידי פעולות פרואקטיביות) או לגלות את התקלה בצורה מהירה יותר.
• עד כמה מבצע את הפעולות השוטפות (TASKS) בצורה טובה.
• איכות התעוד גם מבחינת פרטים וגם בהיבט של מועד עדכון המערכת (הזנת הפרטים בזמן הקריאה ולא בסוף המשמרת).
• איכות ה"אסקלציה" (התקשורת) – עד כמה התקשורת שבצע ה- NOC (בדרך כלל ה- MAIL ששלח או הודעות SMS ) הייתה מתאימה מבחינת בהירות המסר וניסוחו, סוג הנמענים, תוך כמה זמן התבצעה התקשורת וכד'.
• תמיכה בתהליכים חדשים (בתקופה מסויימת) ועד כמה התהליכים נקלטו בצורה טובה על ידי ה- NOC
• עד כמה צוות ה- NOC מעורב בתהליך של capacity planning בארגון והאם בצע מעקב בצורה טובה (לדוגמא התריעה מספיק זמן שהאחסון מתמלא).

4. איכות ה- run book ,ביצועו ואטומציה

• אחוז כיסוי ב- run book. לכמה מהתקלות שהתרחשו בתקופה יש run book
• עד כמה ה- run book מלא (מטפל בכל ההיבטים והאינפוטים של התקלה).
• כמה מה- run books מוטפלים בצורה אוטומטית (מדד נוסף בתחום זה – ניסויים ל- run book האוטומטיים).
• עבודה לפי run book – עד כמה ה- CASE טופל בצורה מלאה לפי מה שמופיע ב- run book.

התחממות המאבק בין HP ל- CISCO

כבר זמן מה שחברת HP וחברת CISCO נמצאות בנתיב התנגשות. אחד הגורמים הראשוניים לתהליך זה הוא העובדה שלפני מספר שנים החלה חברת HP להציע בתוך מארזי ה- BLADES שלה במקביל למתגי CISCO הפופולאריים גם מתגים שלה תחת המותג ProCurve . חברת CISCO לא נשארה חייבת ולפני מספר חודשים יצאה בקו שרתים ייחודי הכולל רכיבי ניהול ותקשורת תחת המותג UCS. כאן כבר מדובר במלחמה חזיתית שכמהלך טקטי רכשה חברת HP את 3COM. וכעת נתבשרנו על כך שחברת CISCO אינה מחדשת את ההסמכה של גוף השירות של HP (בעבר EDS) למרות שהעובדה עלולה לפגוע גם ב- CISCO וזאת מכיוון שיש מספר לקוחות גדול המקבלים שירות של HP.
מצ"ב ציטוט מהלינק הבא:

Cisco divorces HP as a certified systems integrator

Increased competition between the two companies as they enter each other's markets cited as the reason

Cisco Systems today said it will not renew its systems integrator contract with Hewlett-Packard, meaning HP it will no longer be a certified reseller or service partner after April 30.

Keith Goodwin, senior vice president of Cisco's Worldwide Partner Organization, said in a Webcast that the changing IT landscape, the evolving role of the network, and his company's competition with system vendor means it can no longer share partner benefits with HP. "We're taking this action to be transparent to both partners and customers. We will compete with HP for future business," Goodwin said. Cisco recently started competing with systems vendors like HP by coming out with its own blade server offering.

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

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

בשלות VMWARE

שימוש בפתרונות וירטואליזציה להרצת שרתים בייצור כבר הפכה לפני זמן רב ל- best practice בארגוני IT רבים. ספקי תוכנה רבים כבר אישרו את האפליקציות שלהם לעבודה בסביבה וירטואלית. עם זאת ישנם ספקי תוכנה לא מועטים שעדיין לא אישרו את הרצת הפתרונות שלהם בסביבה וירטואלית ובמקרה כזה ישנה דילמה של מנהלי התשתיות בארגון. האם לאשר הפעלה של פתרונות תוכנה בסביבה וירטואלית גם ללא אישור הייצרן? מסתבר שישנם מספר לא מבוטל של ארגונים אשר למרות חוסר האישור - כלומר אי קיום certification לסביבה וירטואלית - בוחרים להריץ את הפתרון בסביבה וירטואלית.
זאת ועוד, לאחרונה ביקרתי בארגון מוביל בישראל אשר ביקש אישור מיצרן תוכנה מוביל להריץ מוצר מסויים בסביבה וירטואלית. יצרן התוכנה ציין שהוא אינו ממליץ להריץ את המוצר בסביבה וירטואלית ולמרות זאת בחר הלקוח להריץ בסביבה וירטואלית. מבחינתי זהו סימן נוסף לכך שלקוחות סומכים יותר ויותר על הפתרונות הוירטואלים ובראשם VMWARE כתשתית בשלה ויציבה.

אין רגע דל! בצעד דרמטי רכשה חברת DELL את חברת PEROT במקום אורקל!

פוסט זה נכתב על ידי ועל ידי גלית פיין- סמנכל"ית ואנליסטית בכירה ב- STKI.


חברת DELL צמחה מתחום המחשבים האישיים והשרתים כאשר מה שאפיין אותה היה מכירות ישירות ללקוחות הסופיים (פחות עבודה עם שותפים). בשנים האחרונות כאשר IBM ו- HP חיקו במידה מסויימת את המודל העסקי של DELL ובמקביל הירידה במחירי הציוד והגברת התחרות (מי היה מאמין שמחשב נייד בסיסי – netbook ימכר ב- 200$!) הביאו את DELL לירידה ברווחיות. ניסיונות של DELL לרכוש חברות טכנולוגיות נוספות כמו EqualLogic – הוכתרו בהצלחה אך לא מספיק דרמטית כך שהמצב ישתנה מהותית.
חברת PEROT הנה אינטגרטור וספק מיקור חוץ גדול בעולם עם דמיון מסויים ל- EDS שנרכשה לא מזמן על ידי HP. נכון להיום, PEROT אינה פעילה ישירות בישראל.
רכישת PEROT על ידי DELL מוכיחה שמכירת חומרה בלבד הנה בעייתית, ולא רווחית דיה לעומת תחומי פעילות כמו אינטגרציה, מיקור חוץ ושירותים. IBM הבינה זאת לפני כעשור כאשר השקיעה בצורה מאסיבית במותג IGS – IBM Global Services. תחום זה מהווה אחד העוגנים של IBM. בדומה, HP רכשה לפני כשנה את EDS - אחד השחקנים החזקים בעולם בתחום השרותים.
חשוב לציין, כי תחום מיקור החוץ נחלש בתקופה האחרונה בישראל. אין אנו רואים כמעט כלל עסקאות גדולות ורב שנתיות חדשות, יותר מזה מספר ארגונים הנמצאים כיום תחת חוזה של מיקור חוץ מחפשים לצמצם את תכולת העבודה החיצונית ואף להחזירה הביתה, דוגמת הבנק הבינ"ל. זה קורה, מכיוון שבראייה לאחור, מיקור חוץ בישראל לא הצליח להכניס שינוי מהותי ללקוחות.
שינוי זה לא קרה כיוון שהעבודה המשיכה להיעשות על ידי אותם העובדים שבין לילה נהפכו לעובדי חברה המספקת שירותי מיקור החוץ. תשומת הלב של הלקוחות הלכה לבירורי סעיפים קטנטנים בחוזה במקום לצמיחה טכנולוגית. גם אם נעשה שיפור קל עקב הכנסת מדדים או SLA, לא ננקטו צעדים דרמטיים, כגון חדשנות טכנולוגית או הכנסת מתודולוגיות הבינלאומיות.
שוק מיקור החוץ רווי שחקנים וותיקים, כגון: HP-EDS, Ness, Malam-Team, IBM, TCS, קשה לראות בו מקום לשחקן בינ"ל חדש. ייתכן ואחד מספקי מיקור החוץ הקיימים, ישמש כנציג של Perot בישראל.
תסריט נוסף – חברת Perot תצליח להכניס לתחום מיקור החוץ בישראל רוח חדשה. מתודולוגיות, אשר הביאו הצלחה בשוק העולמי, יעשו מהפכה בשוק המקומי ויציבו רף חדש בתחום.
תחום רווחי נוסף הוא תחום התוכנה, כאשר חברות תוכנה מצליחות לרכוש חברות חומרה – דוגמה בולטת היא אורקל אשר רכשה את SUN. גם EMC רכשה את Documentum ו- VMWARE בגלל הרווחיות הבעייתית של חומרה. תחום התוכנה נחשב לתחום הרווחי ביותר אולם גם הוא סובל היום מאיום וזאת מכיוון הקוד הפתוח.
תחום רווחי נוסף הנו תחום ה- appliances . מדובר בחיבור יעודי (bundle) בין חומרה לתוכנה. ל- IBM מוצרים בתחום זה (לדוגמה DataPower) וכעת גם אורקל נכנסה לתחום זה עם הפתרון היעוד Exadata.
דבר נוסף לגבי אורקל. אורקל שנכנסת לתחום החומרה ולכן גם היא תצטרך לרכוש חברות בתחום האינטגרציה. כלומר לולא הרכישה הנוכחית של DELL הייתה PEROT על הכוונת של ORACLE. (כפי שציינתי בבלוג בעבר – CSC או אחרות ).
לחילופין אם אורקל תמכור חלקים מעסקי החומרה של SUN (דבר שנכון לעכשיו פחות נראה ודאי), הרי ש- DELL תהיה קנדידטית טובה לביצוע רכש כזה.

אוטומציה של פעולות סיסטם system automation

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


להלן מספר נקודות למחשבה בהגדרת דרישות מכלי בתחום זה:
1. טיפול בהתקנה של תוכנה כולל מערכת הפעלה, PATCHES, ואפליקציות באמצעות
• הגדרה וניהול של IMAGES
• הגדרה וניהול של קבצי התקנה באמצעות סקריפטים
• לאיזה רכיבים יודע להתחבר לדוגמה, אחסון, רשת, שינוי סיסמאות (דוגמה לא טריוויאלית -"דרישה לשינוי סיסמה מ- 6 ל- 7 תווים" כיצד הכלי מאתר את הרכיבים שדורשים שינוי ומבצע זאת).
2. מידת האוטמציה שהכלים מספקים מבחינת השימוש ב- Workflow. עד כמה עשירה אופציית ה- Workflow בכלי והאם היא ממומשת באמצעות SCRIPTS או באמצעות API. לדוגמה, ישנם כלים שמאפשרים ל-device להרשם כ-"מנוי" ל- policy מסויים ואז כאשר מבצעים את ה- policy כל המנויים עוברים את השינוי \ בדיקה. ואז נשאלת השאלה אם ניתן להיות מנויים לכמה policies ומה קורה אם יש התנגשויות. מבחינת האוטומציה צריך לבדוק איך מבצעים בדיקה של הלוגיקה שלא על הציוד עצמו (קל יותר לבצע דרך API). כמובן האם ניתן להשתמש ב"שגרות" בבניית ה- workflow. טיפול בשגיאות וביצוע rollback לכל התהליך.
3. עד כמה יש בכלי מידע על התנהגות של חבילות תוכנה מבחינת כיצד יש לבצע התקנה או PATHES בחבילה עם התייחסות ליחסי התלויות השונים בחבילה זו (לדוגמה, כלי שיודע לגבי חבילת SAP מה וכיצד יש להתקין). ניתן לתאר תכונה זו כ- application logic.
4. אפשרות לבצע משימות AD HOC -(כלומר שלא כ- SCRIPT שמופץ פעם בתקופת זמן) לדוגמה - שינוי משתני מערכת של שרת דרך ה- console של הכלי. בתכונה זו חשוב לשים לב לבחור כלי שמאפשר ביצוע פעולות כאלו ישירות ולא על ידי הגדרה של SCRIPT שמבצע את הפעולה המדוייקת שרוצים ואז הרצתו של אותו SCRIPT בשרת המיועד. מצד שני כן צריכים אפשרות לצור SCRIPTS כאלו.
5. סריקה של הקונפיגורציה של השרת והחלטה האם הקונפיגורציה עונה על הנדרש (מגדירים מראש כיצד נראת חוקים לקונפיגורציה של שרת רצוי). במידה והכלי מגלה שיש סטייה ממצב רצוי יש שתי אפשרויות. אפשרות אחת היא לדווח. אפשרות שנייה היא שהכלי מתקן בעצמו את המצב. (מדובר גם על אפליקציות וגם על סיסטם).
6. עבודה בסביבה וירטואלית- עד כמה הכלי יודע לעבוד בסביבה וירטואלית.
7. טיפול אוטומטי במקרים של עומסים - עד כמה הכלי יודע במידה ויש עומס להתקין שרת נוסף ולהפעיל אותו או לנייד משאבים \ אפליקציה משרת אחר.
8. מטריצת קונפיגורציה ותלויות - כיצד הכלי שומר מידע על התלויות השונות בין רכיבי מערכת המידע - הרכיבים הפיזיים, הרכבים הלוגיים. האם ניתן לקבל את מטריצת התלויות ממקורות אחרים (שכבר קיימים בארגון), האם הכלי מייצר בעצמו מטריצה זו והאם המטרציה משתנה עם הפעולה של הכלי. במחשבה שנייה מדובר על "מיני CMDB" . ונשאלת השאלה האם הכלי ידע להתממשק ל- CMDB אחר.
9. האם המטריצה שהוזכרה קודם מסייעת לארגון (בצורה אוטומטית עד כמה שניתן) לבנות את הסביבה מחדש במקרה של הפעלת מצב של DRP
10. טיפול ב- patches. הכלי אמור לקבל מידע מ(כמה שיותר) ספקים לגבי PATCHES שקיימים למוצרים שלהם ואז על פי המידע שקיים בכלי , הכלי בעצמו מקבל החלטה איפה (אם בכלל) צריך להתקין את ה- PATCHES כולל כל התלויות של אותם PATCHES.
11. עבודה של הכלי על מספר אתרים פיזיים - כולל תאום פעולות בין אתרים.
12. דוחות של הכלי - גם לגבי משאבים, ניצולום ועמידה בתקנים.
13. אבטחת מידע ובדיקות- מי יכול לתת איזה הוראה על איזה שרתים וגם באיזה שלב מבצעים איזה סוג של בדיקה.
14. קשר עם מערכות בארגון - לדוגמה השו"ב.

אלו כאמור נקודות למחשבה כאשר בוחנים כלים בתחום זה.

התפתחות טכנולוגית שגורמת לשינויים ארגוניים ב- IT

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

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

תחום תשתיות - אחראים על התשתיות – תפעול שוטף, התקנה, בחירה של טכנולוגיות חדשות וכד':
1. סיסטם legacy (בארגונים שבהם קיימת פלטפורמה זו).
2. סיטסם Unix Linux
3. סיסטם windows
4. צוות אחסון
5. צוות תקשורת לעיתים גם טלפוניה
6. צוות DBA תשתיתי (לעיתים תחת צוות תשתיות תוכנה).
7. צוות קישוריות (לעיתים תחת צוות תשתיות תוכנה).
8. צוות PC – בנייה של ה- images השונים וטיפול בתקלות שאף אחד לא הצליח לטפל
9. צוות שוב- בניית סביבת השליטה והבקרה המרכזית
10. ועוד...

זה בסיס אבל כל ארגון בונה אחרת את המבנה הארגוני וגם את התפקידים . לדוגמה באחת מחברות התקשורת, צוות אולם המחשב שנמצא 24*7 אחראי גם על בדיקת ה- backup logs כאשר משימה זו נמצאת במקרים רבים אצל צוות האחסון.
במצגת שמופיעה ב- http://www.slideshare.net/pini/stki-summit09-infra-v10 ישנן דוגמאות של מבנים ארגוניים של תחומי התשתיות החל משקף 150.

ישנן טכנולוגיות אשר גורמות לצורך בעדכון הגדרות התפקידים והמבנה הארגוני. לדוגמה – טכנולוגיה ראשונה היא טכנולוגיית הוירטואליזציה של שרתים. רובם של הארגונים משתמשים כבר בטכנולוגיה זו בצורה אינטנסיבית כאשר טכנולוגיה זו (VMWARE מובילים) יכולה לשמש פתרון גם לסביבות Windows וגם לסביבת Linux כלומר לשמש שני צוותים מתחום ה- IT. האם טכנולוגיה זו תשב תחת צוות Windows או תחת צוות Unix – Linux ?
דוגמה נוספת היא טכנולוגיית ה- FCOE – Fiber Channel Over Ethernet – אשר מובלת במידה רבה על ידי CISCO והקונספט החדש של UCS Unified Computing System. תחת קונספט זה יאודחו כבלי התקשורת של האחסון (FIBER ) ושל התקשורת (ETHERNET ) לכבל אחד ויטופלו על ידי נתב (Switch ) אחד. גם כאן עולה השאלה מי יטפל בטכנולוגיה זו האם אנשי התקשורת או אנשי האחסון.

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