oorspronkelijk gepubliceerd in 1991
kleine updates in 2000, 2017 en 2021
“hoeveel IT-personeel heeft een organisatie nodig?”is een veel gestelde en moeilijk te beantwoorden vraag. Er is geen magische verhouding. Er is geen ideaal personeelsbestand. Het juiste aantal medewerkers hangt af van de verantwoordelijkheid van de IT-organisatie en het niveau van dienstverlening dat op elk verantwoordelijk gebied wordt verwacht.
deze post gaat voornamelijk over het klassieke IT-personeel van ondernemingen… wat er gebeurt binnen een bedrijf of een universiteit waar IS/IT-oplossingen worden geleverd. Hoewel gerelateerd, het runnen van een productiedienst die is het leveren van software als service is heel wat anders dan enterprise computing. Er was een kort artikel in CIO dat laat zien wat er gebeurt als je ondernemingen benchmarken ten opzichte van dienstverleners. Ik bespreek een aantal van deze kwesties in mijn tips voor het bedienen van diensten van hoge kwaliteit. James Hamilton heeft opgemerkt dat in mega schaal operaties, menselijk personeel goed voor minder dan 10% van de totale kosten.
er is een mooie grafiek gevonden in de slide deck Impliance: een Informatiebeheerapparaat van mensen van IBM Research dat de stijging van de personeelskosten in vergelijking met de kosten van hardware voor enterprise computing weergeeft. In een productieomgeving wordt doorgaans aanzienlijk meer geïnvesteerd in infrastructuur en tools, wordt werk vaak gedeeld tussen een engineeringgroep en een operations-groep, en zijn er vaak schaalvoordelen die ik in dit artikel alleen maar aanduid.
wat IT-personeel doet
er zijn een aantal verschillende soorten werk waarvoor IT-teams vaak verantwoordelijk zijn.
Gebruikersdiensten (bijv. Helpdesk)
hoeveel handbediening wordt verwacht? Sommige sites hebben gebruikers die vrij zelfvoorzienend zijn; andere sites hebben gebruikers die hulp nodig hebben voor alles wat ze doen. Kunnen uw gebruikers zorgen voor zichzelf of hebben ze nodig en willen dat de beheerder om zelfs de eenvoudigste taken voor hen uit te voeren? Ik heb bijvoorbeeld een vriend wiens gebruikers eisen dat hij de meest elementaire taken voor hen uitvoert (zoals het verplaatsen van hun bestanden van de ene map naar de andere). Alles wat niet simpelweg de teksteditor aanroept of mail leest is “UNIX” en dus een taak voor de beheerder. Dit soort ondersteuning vereist een verhouding van ongeveer één beheerder voor elke vier gebruikers.
wilt u op de site workshops houden of uitgebreide lokale documentatie opstellen? In welke mate wordt van u verwacht dat u over technische kwesties overleg pleegt? Houdt u zich bezig met alleen het besturingssysteem zoals OSX of helpt de Helpdesk met applicaties, of zelfs ontwikkeltools? Bijvoorbeeld, laten we zeggen dat uw site heeft zware gebruikers van TeX, Mathematica, C++, Python, X11, R, MySQL, en Google G-Suite. Moeten gebruikersdiensten gedetailleerde vragen over al die onderwerpen kunnen beantwoorden? Weinig mensen zijn experts in al deze dingen. Ontwikkeling van expertise in een bepaald onderwerp gebied vereist tijd om te spelen, te experimenteren, en volwassen in dat gebied, en er zijn grenzen aan het aantal gebieden die iemand kan beheersen.
softwareondersteuning
hoeveel software of freeware in het publieke domein willen mensen geïnstalleerd hebben? Welke steun verwachten ze? Het installeren van RPM ‘ s is meestal vrij eenvoudig. Alleen het compileren en installeren van software kost niet veel tijd. Vaak echter, software niet alleen compileren en correct te installeren. Vaak zijn er conflicten tussen pakketten die een uitdaging kunnen zijn om op te lossen. Er zijn vaak veronderstellingen in de software die moeten worden gewijzigd voordat de software kan worden gebruikt op een bepaalde site. Daarnaast wordt van beheerders vaak (en terecht) verwacht dat ze het onderhoud van de software voortzetten (bugfixes, beveiligingspatches, en wat niet) en een expert worden in het gebruik van de software. Compileren en installeren (in combinatie met frequente patches) of veel hardware/software platforms kan dit ongelooflijk tijdrovend maken voor zelfs maar een paar software pakketten. De tijd die dit kost varieert met de kwaliteit en complexiteit van de software. Het bijhouden van een huidige versie van kermit of perl is niet moeilijk (Ik wou dat iedereen zo goed werk deed als Larry Wall heeft met perl); het bijhouden van g++ is veel meer tijdrovend.
cloudservices ondersteunen
tegenwoordig maken organisaties steeds meer gebruik van cloudservices om hun bedrijfsproblemen op te lossen. Personeelstijd voor clouddiensten wordt vaak onderschat, omdat ze meestal worden gedistribueerd. De eerste is de kosten van het instappen. Vaak is dit zodra iemand met behulp van een bedrijf credit card aan te melden voor een dienst, maar dat is niet duurzaam. Ten eerste moet de facturering echt naar de organisatie gaan, niet naar een individu. Belangrijker is echter dat de juiste mensen toegang hebben, en dan wanneer de rollen van mensen veranderen, of ze het bedrijf verlaten, gebeurt het juiste.
in het beste geval kunnen de SaaS gebruikmaken van bestaande accountbeheersystemen zoals Google Apps, enterprise single sign-on-systeem zoals Okta of een interne advertentieservice als het een extern bereikbaar SAML-eindpunt biedt. Kan moet worden gemaakt om ervoor te zorgen dat het uitschakelen van een enkele sign-on account de toegang blokkeert (sommige systemen staan ook toegang toe tegen een service specifieke referenties). Over het algemeen op boarding apps is ongeveer 1 man week / app die u factor in het leren over de service, het regelen van integraties, het produceren van de juiste documentatie.
naast het binnenhalen van een SaaS zijn er een breed scala aan mogelijke kosten, afhankelijk van de complexiteit van de integraties, hoeveel maatwerk vereist is en of het IT-team klantenondersteuning nodig zal hebben.
ERP-systeem
in onze steeds complexere en gereguleerde wereld moeten organisaties een breed scala aan processen volgen en beheren. Naarmate het werktempo is toegenomen, bestaat de perceptie dat gegevens in realtime beschikbaar moeten zijn, maar dat dit heeft geleid tot de invoering van Enterprise resource planning (ERP)-systemen. De meest bekende systemen in deze ruimte zijn SAP en Oracle ‘ s suite van applicaties. In de mid-tier zijn er bedrijven als Netsuite en Workday. Voor kleine bedrijven, Quickbooks wordt vaak gebruikt.
in kleinere organisaties worden ERP-systemen vaak beheerd door het team dat verantwoordelijk is voor de functie. Finance zorgt voor de boekhoudsoftware. Human Resources zorgt vaak voor de tools die worden gebruikt om het personeelsbestand te beheren, en maakt gebruik van wat system finance heeft geselecteerd voor het doen van payroll. In deze gevallen IT-personeel is vrij minimaal en is meestal gericht op het verstrekken van een server en ervoor te zorgen dat het gegevens regelmatig wordt geback-upt.
naarmate een bedrijf groeit en groter en complexer wordt, kunnen de eisen van deze systemen enorm toenemen. Het is buiten het bereik van deze post om het schatten van de personeelsbehoeften voor ERP-systemen te bespreken, maar Ik zal een opmerking maken. In bijna alle gevallen is het een slecht idee om ERP-systemen aan te passen aan uw bestaande bedrijfsprocessen. Waar mogelijk moet u gebruik maken van een systeem zo dicht bij out of the box als je kunt, en als de keuze is uw proces wijzigen of aanpassen van de software, verander uw proces.
aangepaste Software
veel organisaties hebben geen speciale afdeling software engineering, dus het IT-personeel wordt niet alleen opgeroepen om software te beheren die door leveranciers wordt geleverd, maar ook om — op aanvraag — tools te creëren voor de gebruikersgemeenschap. Dit is begrijpelijk, vooral in kleine sites waar de IT-medewerkers de enige professionele programmeurs kunnen zijn. Als deze verwachting bestaat, moet er tijd worden uitgetrokken voor dit ontwikkelingsproces.
Siteplanning / Administratieoverhead
hoeveel siteplanning wordt van de beheerder verwacht? Moet de beheerder weten dat de gemiddelde persoon 115 watt genereert, en hoe dat en warmtebelasting van machines te factureren om de juiste wisselstroom/verwarmingsbelasting en vermogen op te schalen? Hoeveel papierwerk is er?
Hardware / netwerkonderhoud
wie kruipt er door het plafond om draden te trekken? Wie vindt de schilferige transceiver als de Ethernet gek begint te worden? Wanneer een werkstation sterft, Belt een secretaresse gewoon uw leverancier en wacht, of zijn er meer creatieve oplossingen nodig? Doet u board level reparaties? Koopt uw site al haar randapparatuur klaar om te installeren of bespaart u geld door de aankoop van componenten en doe de integratie zelf? IT-personeel al deze dingen laten doen kost tijd.
anticiperen op technologie
moet het IT-personeel anticiperen op nieuwe technologie en het bedrijf adviseren over nieuwe benaderingen? De meeste plaatsen waar ik heb gewerkt verwachten dat de IT-medewerkers een goed gevoel voor de state of the art en nieuwe technologie die ziet er veelbelovend (niet alleen producten, maar onderzoek, te hebben). Anticipatie is vaak noodzakelijk gezien veel sites hebben een drie-tot-zes jaar planning of afschrijving schema. Ons veld bijhouden is niet makkelijk. Er zijn verschillende bronnen waar men veel gebruik van maakt om actueel te blijven. Ik heb een verscheidenheid aan goede bronnen gevonden voor actuele informatie. Trade rags kunt u een beeld van wat wordt verkocht, blog (en andere elektronische media) is geweldig voor vragen met betrekking tot de huidige problemen en problemen. Vaktijdschriften van ACM, IEEE, etc zijn handig om te zien wat er gebeurt op het bijna voltooide onderzoeksfront. Er is echter geen vervanging voor een goed netwerk van professionele contacten. Dit netwerk kan worden onderhouden met telefoongesprekken, e-mail, deelname aan online communities en het bijwonen van conferenties.
mijn ratio ‘ s
de beste manier om het aantal benodigde beheerders in te schatten is om uit te zoeken welk serviceniveau vereist is en hoe verschillende factoren (bijvoorbeeld netwerkinfrastructuur en heterogeniteit van de ondersteunde machines) de vervulling van deze verantwoordelijkheden zullen beïnvloeden. Zelden doen systeembeheerders alleen “administrator” taken. Het eerste deel van dit artikel zal in detail de taken die ik vind mezelf uitvoeren in aanvulling op de normale “beheerder” taken, zoals back-ups, het installeren van nieuwe gebruikers, het besturingssysteem onderhoud, enzovoort. Aanvullende taken worden (voor het grootste deel) gepresenteerd in de vorm van vragen. In het tweede deel worden enkele van de verschillende factoren beschreven die van invloed zullen zijn op het niveau van het personeel. Het derde deel geeft een aantal eenvoudige perspectieven die systeembeheerders kunnen aannemen om hun omgeving gemakkelijker te beheren. Tot slot wil ik nog kort enkele ratio ‘ s onderzoeken die u kunnen helpen om uw personeelsbehoeften te benaderen.
hier volgt een zeer ruwe reeks regels die ik gebruik om de personeelsbehoeften te schatten. Uw kilometerstand zal variëren. Ik moet opmerken dat deze cijfers uitgaan van het behoud van een redelijk stabiele omgeving. Snelle omzet van gebruikers, machines, abnormaal frequente software veranderingen, groei van de omgeving, enz. resulteert in meer werk en effect de verhoudingen.
| soort werk | arbeidseenheden om beste praktijken te leveren prestaties en schaalfactoren |
| Eindgebruikersdienst | 1 eenheid tot 50 gebruikers die goede service krijgen. 1 eenheid voor elke 200 die basisdienst krijgen, en (bijvoorbeeld studenten in een onderwijsfabriek) uitgaande van 8×5 ondersteuning. Niet nodig als u de dienst met een aparte customer care organisatie. Ratio moet omhoog gaan als je wilt dat de helpdesk langere uren draait. |
| 24 x 7 ondersteuning (Partners, klanten, enz.) | het uitvoeren van een 24×7 NOC die proactieve kennisgeving en snelle probleemoplossing vereist schalen tegen de complexiteit van de dienst die wordt beheerd en het aantal high touch clients. Plaatsen die echt de zorg over dit hebben een stap in de kosten van 14 mensen… een manager, een assistent manager, drie ploegen, met elke Dienst met twee mensen, een dienst loopt zondag-woensdag, en de andere loopt woensdag-zaterdag dus er is overlapping tussen teams, schone handoffs, en tijden om groepstraining te doen. Minder dat dit er gemakkelijk toe kan leiden dat ploegen niet worden gedekt. Het hebben van een enkele persoon / ploeg kan bijvoorbeeld mislukken als de persoon in de nachtploeg in slaap valt of als iemand die in een van de weekenddiensten werkt ziek wordt. Dit telt niet mee om naar mensen te escaleren. Het aantal mensen dat per dienst nodig is hangt af van de hoeveelheid normaal werk die er is en van het aantal gelijktijdige Rampen dat het team naar verwachting aankan. |
| besturingssysteem Beheer | 2 eenheden voor elk merk besturingssysteem dat basisondersteuning vereist. Als u het besturingssysteem te duwen voorbij mainstream / getest schaal voeg een toevoeging 4 eenheden. Het doen van zeer complexe dingen die gehackte kernels, niet-standaard apparaatstuurprogramma ‘ s, enz. Als je echt de zorg over veiligheid voeg een extra 12 eenheden. Functionaliteit nodig die op dit moment niet in de kernel zit en/of iets meer dan basic jumpstart of kickstart voor installatie en beheer? Beheer dit als een software development project en krijg goede ingenieurs werken aan het. |
| Hardware Management / host Imaging (OS Deployment) | 1 eenheid voor elke 50 kaders als u het besturingssysteem en de systeemconfiguraties niet kunt beschermen tegen de gebruikers (Windows in veel omgevingen) of als er hoge aanpassingen zijn die door IT-medewerkers moeten worden gedaan. 1 eenheid voor elke 200 dozen als u het besturingssysteem kunt beschermen tegen de gebruikers zonder de gebruiker te hinderen, maar kan niet automatisch worden gebouwd / rebuild / Update OS en software zonder it-toezicht. 1 eenheid voor elke 400 boxen die netwerkgebaseerde software installeren (compute clusters of volledig geautomatiseerde gebruikerswerkstations met Configuratiebeheer). Extreem grootschalige operaties (1.000 s machines die volledig cookiesnijder Draaien) schaal meer als 500 dozen / eenheid en kan schaal tot 2500 dozen/eenheid op een google-schaal waar u kunt veroorloven om volledige rekken / service-eenheden te verliezen zonder onmiddellijk actie te ondernemen. |
| Appliance Support | 1 eenheid voor elke eenvoudige app. 4 units voor elke complexe app waarvan het personeel wordt verwacht dat het power users zijn. De eerste implementatie van apps is meestal tijdrovend. Wanneer groot aantal apps worden ingezet moeten rekening houden met de tijd die het personeel nodig heeft om context switch / “swap in” informatie. |
| eenvoudige netwerkdiensten | 1 eenheid voor elke twee basisdiensten: httpd, DNS, mail, printing, SAMBA, enz. Voeg 2 eenheden toe als u wilt dat ze beter dan 99,8% beschikbaarheid hebben. Voeg 2 eenheden toe als je om beveiliging geeft. Voeg 1 eenheid toe als je groter schaalt dan het gemiddelde. Voeg 4 als je schalen naar mega-grootte en zijn verder dan wat de software is ontworpen voor. Als je volledig buiten de schaal, behandel een ontwikkelingsproject en het personeel dienovereenkomstig met ingenieurs. |
| complexe netwerkdiensten | zeer variabel. Bijvoorbeeld, multi-terabyte database gebruikt voor data mining kan gemakkelijk consumeren meerdere DBA ‘ s + meerdere senior systeembeheerders die gespecialiseerd zijn in de prestaties tuning en grootschalige opslagsysteem. |
| netwerkconnectiviteit | schaalt tegen het aantal netwerkapparaten, het aantal netwerken, beveiligingsproblemen, complexiteit van routering, HA-vereisten. |
| coördinatie en beheer | hoe groter en complexer een organisatie is, des te meer is er behoefte aan coördinatierollen. Mensen die zich richten op human management, systeemarchitectuur, programma management, project management. Dit is nogal complex. Het zou aanmatigend zijn om een ratio voor te stellen. |
een solide Sage II-systeembeheerder kan 4 werkeenheden verwerken. Een sterke Sage III-systeembeheerder kan 8 werkeenheden verwerken. Een superieure Sage IV-systeembeheerder kan 12 werkeenheden verwerken. Er zijn enkele zeldzame individuen die zowel diepe en brede ervaring, zijn uit de doos denkers, hoge EQ, en ongelooflijk gericht en productie. Hoewel ze niet beter schalen ten opzichte van menselijke taken zoals eindgebruikersondersteuning dan een sage IV-persoon, schalen ze aanzienlijk beter op het technische / systeemwerk. Dit is gerelateerd aan de overlevering dat er een aantal ontwikkelaars die zijn 10x beter dan een “normale” Ontwikkelaar. Tijdens mijn carrière heb ik het genoegen gehad om te werken met een aantal van deze uitzonderlijke artiesten. Dit telsysteem is losjes gebaseerd op een vergelijking voorgesteld door Sherwood Botsford en Gevonden in de comp.Unix.admin FAQ. Op een gegeven moment zal ik het tellen bijwerken om mijn SRE Skill Matrix (excel) te gebruiken.
andere problemen
Site met één beheerder zijn niet erg wenselijk.
ze zijn een feit omdat veel kleine sites niet meer dan één systeembeheerder kunnen veroorloven of rechtvaardigen. Het is moeilijk voor één persoon om de breedte van kennis en ervaring te hebben om een echt eersteklas site te runnen, ongeacht hoe weinig machines het heeft. Er zal altijd een gebied zijn dat niet de kracht is van een enige beheerder.
een ander probleem is dat de site met één systeembeheerder één foutpunt heeft: wanneer de beheerder op vakantie is (of overreden wordt door een bus), is de site kwetsbaar. Het dragen van een pieper op vakantie is niet mijn idee van plezier; echter, niemand kan voorspellen wanneer een crisis zou kunnen optreden. Natuurlijk, het is moeilijk om een high-level persoon te interesseren in een baan die ook gaat om het veranderen van de back-up tapes en kruipen door de plafonds.
hoe homogener een site is, hoe gemakkelijker het te ondersteunen is.
het aantal ondersteunde platforms (verschillende machinearchitecturen of verschillende besturingssystemen) verhoogt de complexiteit van de ondersteuningstaak. Het upgraden van het besturingssysteem moet minstens één keer met de hand gebeuren voor elk platform. Elk besturingssysteem heeft zijn eigen eigenaardigheden die moeten worden geleerd en beheerst. De meeste sites willen dat alle platforms identiek lijken, zodat hun gebruikers kunnen gaan zitten op een van de werkstations en werk gedaan krijgen. Dit vereist dat elk platform identieke gereedschappen, venstersystemen, enz. Dit kan de hoeveelheid werk die de beheerder moet doen sterk verhogen. In de beste omstandigheden betekent dit het opnieuw compileren van programma ‘ s voor elk platform. In de ergste omstandigheden gaat het om het overdragen van software, en vechten met door de leverancier geleverde software. My personal nightmare probeert alle X11r4 (van MIT), DECwindows, OSF/Motif en Sun ‘ s OpenWindows op drie verschillende platforms te ondersteunen.
Grotere locaties kunnen schaalvoordelen benutten.
grote sites kunnen hun administratie minder snel uitbreiden dan het aantal gebruikers (of werkstations) groeit. De reden hiervoor is dat naarmate uw personeel groter wordt het mogelijk is voor mensen om zich te specialiseren. Deze specialisatie stelt individuele medewerkers in staat om een diepgaande expertise te ontwikkelen die hen in staat stelt om alle problemen over een bepaald onderwerp te begrijpen en sneller problemen op te lossen.
ten tweede kunnen grotere locaties gebruik maken van eerder werk. De eerste installatie van een machine of software is altijd het moeilijkst. De tweede is makkelijker. Tegen de tijd dat je 50 of 100 installaties hebt gedaan, heb je automatische scripts ontwikkeld en kun je installaties in je slaap doen. Ik heb grote sites gezien op een 1: 100 administrator-to-machine ratio waar de dingen liep vrij goed. Ik moet de lezer echter waarschuwen: dit soort ratio is alleen haalbaar met top-notch mensen die werken in een zorgvuldig ontworpen omgeving met vele honderden gebruikers. De meeste sites kunnen niet productief werk gedaan met dit soort ratio. Dit soort ratio beperkt ook de professionele groei van leden van het systeempersoneel, omdat ze het grootste deel van hun tijd doorbrengen met de dagelijkse problemen en brandbestrijding. Dit is een schande omdat de meest waardevolle hulpbron van een organisatie de mensen zijn.
| Verhoogde SA-Efficiëntie | Daalde SA-Efficiëntie |
| Automatisering Normen (beleid, architectuur) Effectieve monitoring gereedschappen Robuust IS de beveiliging Strakke controle over wat er wordt geplaatst op HW/SW baseline Redundantie van de kritieke diensten Scheiden van diensten (single-service machines) Goede opleiding Gedetailleerde plannen voor disaster recovery, door-systeem Systeem dat niet nodig hebben, back-ups |
Diverse hardware baseline Diverse software baseline Lax IS beveiliging weinig of geen opleiding personeel dat reactief is, niet proactief ad-hoc back-ups of geen back-ups |
locaties met hoge beschikbaarheid vereisen meer personeel.
locaties die in hoge mate beschikbaar moeten zijn (bv. meer dan 99,9% van de dienstverlening) zullen meer personeel nodig hebben. De reden hiervoor is dat je mensen nodig hebt die bijna onmiddellijk kunnen reageren op eventuele serviceproblemen (bijvoorbeeld 24×7 dekking, idealiter ten minste 2 mensen diep die eerste en tweede niveau resolutie kunnen doen, en in staat zijn om te escaleren naar vakgebied experts). U moet ook meerdere mensen hebben voor elk vakgebied die in staat zijn om de diagnose en complexe problemen snel op te lossen.
Hoe Zit Het Met Andere Platforms?
het platform dat wordt ondersteund maakt een groot verschil. Mijn ervaring is dat ondersteuning van Macintosh-en UNIX-gemeenschappen ongeveer dezelfde personeelsbezetting hebben. Historisch ondersteuning van PC ‘ s met een Microsoft OS lijkt te vereisen ten minste het dubbele van de personeelsbezetting en levert een lager niveau van service. Sinds Windows XP hoeft de verhouding niet zo hoog te zijn … maar ik vind nog steeds beheerschalen beter op UNIX dan Windows.
ratio ’s van andere mensen
In de afgelopen jaren hebben veel mensen gesproken over de ratio’ s die zij redelijk vinden. Het is gebruikelijk om mensen te horen praten over personeel/gebruiker ratio ’s van 1:60 waar er enige variatie in de bevolking en veel maatwerk, en personeel / gebruiker ratio’ s van 1:150 (of hoger) op locaties die gebruik kunnen maken van “cookie cutter” oplossingen, bijvoorbeeld universiteiten met hordes van studenten of bedrijven waar mensen gebruik maken van computers als een hulpmiddel in plaats van op zoek naar innovatie op de machines die worden beheerd. Een meer realistische set van Ratio ’s (gebaseerd op best practices in het veld in plaats van vendor white pages op TCO) was de Mega Group’ s verbeteren staffing ratio ‘ s Artikel. Er zijn een aantal andere studies die hebben aangetoond dat in de echte wereld de meeste organisaties niet in staat zijn geweest om ratio ‘ s hoger dan 30:1 te ondersteunen. Een Mijterstudie uit 2000 suggereerde dat de verhouding 47 is:1 +/- 17%. In een video over User to Technician ratio ‘ s door Justin Nguyen was een basisverhouding van 60:1 suggestie, met een aantal factoren die deze ratio beà nvloeden.
een voorbeeld van te hoge aantallen is te vinden in Staffing for Technology Support, een witboek voor onderwijsinstellingen. Helaas proberen deze mensen de personeelsratio ’s van MIT’ s Project Athena toe te passen op de rest van de wereld. Dit is gebrekkig om drie redenen. Ten eerste, de meeste sites hebben niet de geavanceerde tools die Athena had. Ten tweede, Athena had mensen die Athena run die niet gevangen in hun verhoudingen waren: student vrijwilligers die veel werk en hard core systeem programmeur die tools die voldoen aan MIT ‘ s eisen ontwikkeld. Tot slot is de MITs – gebruikerspopulatie geen gemiddelde gebruikerspopulatie.
David Cappuccio van de Gartner Groep suggereerde in zijn artikel ken de Types: Sizing up Support staff dat er twee verhoudingen die u moet overwegen. De eerste verhouding is personeel aan gebruikers, een poging om het menselijke deel van de vergelijking vast te leggen. Deze verhouding kijkt naar hoeveel mensen je nodig hebt om te doen wat vaak wordt genoemd Tier I, helpdesk, of user support. De tweede verhouding is het aantal machines en subsystemen per personeel, dat wil zeggen hoeveel mensen er nodig zijn om de technische infrastructuur te verzorgen. Hoewel ik David ’s framework leuk vind, denk ik dat zijn ratio’ s te hoog zijn voor gebruikersondersteuning, en dat hij er niet in is geslaagd om de diverse set van technologieën vast te leggen die de meeste organisaties inzetten: er is veel meer dan print -, file -, web-en databaseservers. Er zijn directory -, security -, messaging-en samenwerkingsservices. Om de zaken te compliceren, veel sites zijn heterogeen vereisen extra inspanningen om een dienst te laten werken voor alle klanten, of erger, wat resulteert in de behoefte diensten die zijn gebaseerd op het client platform. Een laatste complicerende factor is dat deze diensten vaak complexe interacties en afhankelijkheden waardoor ze moeilijker te implementeren en te onderhouden. Het resultaat is dat David ‘S ratio’ s zal resulteren in personeel dat in staat zal zijn om alleen de meest elementaire diensten op een adequaat niveau te leveren.
de itbenchmark blog heeft een aantal postings over het onderwerp van de grootte van het personeel.
conclusie
het aantal vereiste beheerders varieert sterk van site tot site. De ene constante is dat er zelden genoeg systeembeheerders voor de verantwoordelijkheden die ze hebben. Op het moment dat dit oorspronkelijk werd geschreven, vond ik het mogelijk was voor een enkele persoon om tot 220 machines (met drie verschillende platforms) te onderhouden en adequate gebruikersdiensten te geven aan een vrij geavanceerde gebruikerspopulatie van ongeveer 80 mensen. Mijn tijd is verdeeld tussen gebruikersdiensten( 30 procent), algemene systeembeheertaken (20 procent), het installeren van nieuwe machines en hardware/netwerkondersteuning (10 procent), software-installatie en-onderhoud (30 procent), ontwikkeling van aangepaste software en het volgen van trends (35 procent), en site planning (10 procent). U zult merken dat dit neerkomt op 135 procent.
geschiedenis van deze Post
in 1991 heb ik een brief aan Usenet geplaatst waarin werd geantwoord op een vraag over de personeelsratio. Rob Kostad vroeg me om die korte noot uit te breiden tot een artikel dat liep met de titel “hoeveel beheerders zijn genoeg?”in het tijdschrift Unix Review, April 1991. In de loop der jaren heb ik een aantal, meestal kleine updates van het oorspronkelijke artikel. Een dezer dagen zal ik het volledig herschrijven. Hoewel dit artikel is geschreven een lange tijd geleden, Ik vind dat de verhoudingen zijn nog steeds vrij nauwkeurig. Als je denkt dat ik het mis heb, stuur me dan een mail met je ervaringen.