oprindeligt udgivet i 1991
mindre opdateringer i 2000, 2017 og 2021
“hvor mange IT-medarbejdere har en organisation brug for?”er et almindeligt stillet og vanskeligt at besvare spørgsmål. Der er ikke noget magisk forhold. Der er ikke noget ideelt personaleniveau. Det passende antal medarbejdere afhænger af, hvad IT-organisationen er ansvarlig for, og det forventede serviceniveau inden for hvert ansvarsområde.
dette indlæg handler primært om klassisk enterprise IT-personale… Hvad sker der inden for en virksomhed eller et universitet, hvor IS/IT-løsninger leveres. Mens det er relateret, kører en produktionstjeneste, der leverer programmer som service, en hel del anderledes end enterprise computing. Der var en kort artikel i CIO, der viser, hvad der sker, når du benchmark virksomheder mod tjenesteudbydere. Jeg diskuterer nogle af disse spørgsmål i mine tip til drift af tjenester af høj kvalitet. James Hamilton har bemærket, at menneskelige medarbejdere i megaskalaoperationer tegner sig for mindre end 10% af de samlede omkostninger.
der var en flot graf fundet i slide deck Impliance: et Informationsstyringsapparat af folk fra IBM Research, der fangede, hvordan personaleomkostningerne er steget i forhold til omkostningerne ved udstyr til enterprise computing. I et produktionsmiljø, der er typisk betydeligt flere investeringer i infrastruktur og værktøjer, arbejde deles ofte mellem en ingeniørgruppe og en operationsgruppe, og der er ofte stordriftsfordele, som jeg kun antyder i dette papir.
hvad IT-medarbejdere gør
der er mange forskellige slags arbejde, som IT-teams ofte er ansvarlige for at levere.
brugertjenester (f. eks. Helpdesk)
hvor meget håndhold forventes? Nogle steder har brugere, der er temmelig selvforsynende; andre sider har brugere, der har brug for hjælp til alt, hvad de gør. Kan dine brugere tage sig af sig selv, eller har de brug for og ønsker, at administratoren skal udføre selv de enkleste opgaver for dem? For eksempel har jeg en ven, hvis brugere kræver, at han udfører de mest basale opgaver for dem (såsom at flytte deres filer fra et bibliotek til et andet). Alt, der ikke blot påberåber teksteditoren eller læser mail, er “unik” og dermed et job for administratoren. Denne form for support kræver et forhold noget som en administrator for hver fire brugere.
ønsker hjemmesiden, at du gennemfører værksteder eller udarbejder omfattende lokal dokumentation? I hvilket omfang forventes du at konsultere om tekniske spørgsmål? Bekymrer du dig kun om operativsystemet, eller hjælper Helpdesk med applikationer eller endda udviklingsværktøjer? Lad os f.eks. sige, at din hjemmeside har tunge brugere af Google G-Suite, C++, Python, R, R og Google G-Suite. Skal brugertjenester kunne besvare detaljerede spørgsmål om alle disse emner? Få mennesker er eksperter på alle disse ting. Udvikling af ekspertise inden for et givet emneområde kræver tid til at spille, eksperimentere og modne i dette område, og der er grænser for antallet af områder, som nogen kan mestre.
understøttelse af programmer
hvor meget public domain-programmer eller gratis programmer vil folk have installeret? Hvilket niveau af støtte forventer de? Installation af RPMs er typisk ret let. Bare kompilering og installation af programmer tager ikke meget tid. Ofte er det dog ikke kun programmer, der kompilerer og installerer korrekt. Ofte er der konflikter mellem pakker, som kan være udfordrende at løse. Der er ofte antagelser i programmet, som skal ændres, før programmet kan bruges på et givet sted. Derudover forventes administratorer ofte (og med rette) at fortsætte vedligeholdelsen af programmet (fejlrettelser, sikkerhedsrettelser og hvad ikke) og at blive ekspert i brugen af programmet. Kompilering og installation (kombineret med hyppige programrettelser) eller mange maskinplatforme kan gøre dette utroligt tidskrævende for blot nogle få programpakker. Den tid det tager varierer med kvaliteten og kompleksiteten af programmet. At holde en nuværende version af kermit eller perl er ikke svært (jeg ville ønske, at alle gjorde så godt et job som Larry væg har med perl); at holde op med g++ er meget mere tidskrævende.
Cloud Services Support
i stigende grad bruger organisationer cloud-tjenester til at løse deres forretningsproblemer. Personale tid til Cloud-tjenester er ofte under estimeret, fordi de har tendens til at blive distribueret. Først er omkostningerne ved ombordstigning. Ofte er det så snart nogen bruger et firmakreditkort til at tilmelde sig en service, men det er ikke bæredygtigt. For det første skal faktureringen virkelig gå til organisationen, ikke en person. Vigtigere er dog at sikre, at de rigtige mennesker har adgang, og end når folks roller ændres, eller de forlader virksomheden, sker det rigtige.
i bedste fald kan SaaS udnytte et eksisterende kontostyringssystemer som Google Apps, enterprise single sign-On-system som Okta eller en intern ANNONCETJENESTE, hvis det giver et eksternt tilgængeligt SaML-slutpunkt. Can skal gøres for at sikre, at deaktivering af en enkelt login-konto blokerer adgang (nogle systemer tillader også adgang mod en servicespecifik legitimationsoplysninger). Generelt på boarding apps er omkring 1 mand uge / app, som du faktor i at lære om tjenesten, arrangere integrationer, producerer passende dokumentation.
ud over at få en SaaS loddet ind, er der en bred vifte af mulige omkostninger afhængigt af kompleksiteten af integrationerne, hvor meget tilpasning der kræves, og om der er behov for IT-teamet til at yde kundesupport.
ERP-System
i Vores stadig mere komplekse og regulerede verden skal organisationer spore og styre en bred vifte af processer. Efterhånden som arbejdstempoet er steget, er der opfattelsen af, at data skal være tilgængelige i realtid, men har ført til vedtagelse af Enterprise resource planning (ERP)-systemer. De bedst kendte systemer i dette rum er SAP og Oracle ‘ s suite af applikationer. I midten af niveauet er der virksomheder som Netsuite og arbejdsdag. For små virksomheder er Hurtigbøger almindeligt anvendt.
i mindre organisationer administreres ERP-systemer ofte af det team, der er ansvarlig for funktionen. Finans tager sig af regnskabsprogrammet. Human Resources tager sig ofte af de værktøjer, der bruges til at styre antal medarbejdere, og bruger det systemfinansiering har valgt til lønningsliste. I disse tilfælde er IT-bemanding ret minimal og er typisk fokuseret på at levere en server og forsikre, at dens data regelmæssigt sikkerhedskopieres.
som en virksomhed vokser og størrelse og kompleksitet, kravene i disse systemer kan vokse massivt. Det er uden for rammerne af dette indlæg at diskutere estimering af bemandingskravene til ERP-systemer, men jeg vil gøre en observation. I næsten alle tilfælde er det en dårlig ide at tilpasse ERP-systemer, så de passer nøjagtigt til dine eksisterende forretningsprocesser. Når det er muligt, skal du bruge et system så tæt på ud af boksen, som du kan, og hvis valget er ændre din proces eller tilpasse programmet, ændre din proces.
brugerdefineret program
mange organisationer har ikke en dedikeret programteknikafdeling, så IT — personalet opfordres ikke kun til at administrere programmer leveret af leverandører, men også til at oprette — on demand-værktøjer til brugerfællesskabet. Dette er forståeligt, især på små steder, hvor IT-personalet muligvis er de eneste professionelle programmører. Hvis der er denne forventning, skal der afsættes tid til denne udviklingsproces.
Anlægsplanlægning/Administration Overhead
hvor meget anlægsplanlægning forventes administratoren at håndtere? Skal administratoren vide, at den gennemsnitlige person genererer 115 vand, og hvordan man faktorerer det og varmebelastninger fra maskiner for at skalere passende vekselstrøm/varmebelastninger og strøm? Hvor meget papirarbejde er der?
vedligeholdelse af udstyr/netværk
hvem kravler gennem loftet for at trække ledninger? Hvem finder den flaky transceiver, når Ethernet begynder at blive skør? Når en arbejdsstation dør, ringer en sekretær bare til din leverandør og venter, eller kræves der mere kreative løsninger? Gør du bord niveau reparationer? Køber din side alle sine perifere enheder klar til installation, eller sparer du penge ved at købe komponenter og selv gøre integrationen? At have it-personale til at gøre nogen af disse ting tager tid.
forudse teknologi
skal IT-medarbejderne forudse ny teknologi og rådgive virksomheden om nye tilgange? De fleste steder, jeg har arbejdet, forventer, at IT-medarbejderne har en god fornemmelse for den nyeste teknologi og ny teknologi, der ser lovende ud (ikke kun produkter, men også forskning). Forventning er ofte nødvendig, da mange steder har en tre til seks års planlægning eller afskrivningsplan. Det er ikke let at holde trit med vores felt. Der er en række kilder, man meget trækker på for at holde sig opdateret. Jeg har fundet en række gode kilder til aktuelle oplysninger. Trade rags kan give dig et billede af, hvad der sælges, blog (og andre elektroniske medier) er fantastisk til spørgsmål vedrørende aktuelle problemer og problemer. Professionelle tidsskrifter fra ACM, IEEE osv.er nyttige til at se, hvad der sker på den næsten færdige forskningsfront. Der er dog ingen erstatning for et godt netværk af professionelle kontakter. Dette netværk kan vedligeholdes med telefonopkald, elektronisk post, deltagelse i online-samfund og deltagelse i konferencer.
mine Forhold
den bedste måde at estimere antallet af administratorer på er at finde ud af, hvilket serviceniveau der kræves, og hvordan forskellige faktorer (for eksempel netværksinfrastruktur og heterogenitet af de maskiner, der understøttes) vil påvirke opfyldelsen af disse ansvarsområder. Sjældent udfører systemadministratorer kun” administrator ” – opgaver. Den første del af denne artikel beskriver de opgaver, som jeg finder mig selv udfører ud over de normale “administrator”-opgaver, såsom sikkerhedskopier, installation af nye brugere, vedligeholdelse af operativsystemet osv. Yderligere opgaver præsenteres (for det meste) i form af spørgsmål. Den anden del beskriver nogle af de forskellige faktorer, der vil påvirke personaleniveauet. Den tredje del beskriver nogle enkle perspektiver, som systemadministratorer kan vedtage for at gøre deres miljø lettere at administrere. Endelig vil jeg ende med hurtigt at undersøge nogle forhold, som kan hjælpe dig med at tilnærme dine personalebehov.
følgende er et meget groft sæt regler, jeg bruger til at estimere personalekrav. Din kilometertal vil variere. Jeg skal bemærke, at disse tal antager at opretholde et rimeligt stabilt miljø. Hurtig omsætning af brugerbase, maskiner, unormalt hyppige programændringer, miljøvækst osv. resulterer i mere arbejde og påvirker forholdene.
| Type arbejde | arbejdsenheder til at levere bedste praksis ydeevne og skaleringsfaktorer |
| slutbruger Service | 1 enhed til 50 brugere, der får god service. 1 enhed for hver 200, der får grundlæggende service, og (f.eks. studerende i en pædagogisk fabrik) under forudsætning af 8 lig 5 støtte. Ikke nødvendigt, hvis du kører tjenesten med en separat kundeserviceorganisation. Forholdet skal gå op, hvis du vil have helpdesk til at køre udvidede timer. |
| 24 | at lave en 24-liters 7 NOC, der kræver proaktiv anmeldelse og hurtig problemløsning, skaleres mod kompleksiteten af den service, der administreres, og antallet af klienter med høj berøring. Steder, der virkelig bryr sig om dette, har et trin i prisen på 14 personer… en manager, en assisterende manager, tre skift, hvor hvert skift har to personer, et skift kører søndag-onsdag, og den anden kører onsdag-lørdag, så der er overlapning mellem hold, rene afleveringer, og tider til gruppetræning. Mindre, at dette let kan resultere i, at skift ikke dækkes. For eksempel kan det at have en enkelt person / skift mislykkes, hvis natskiftepersonen falder i søvn, eller hvis nogen, der arbejder en af helgeskiftene, bliver syg. Dette tæller ikke folk til at eskalere til. Skift er relateret til, hvor meget normalt arbejde der er, og hvor mange samtidige katastrofer teamet forventes at kunne håndtere. |
| Operativsystemstyring | 2 enheder for hvert operativsystem, der kræver grundlæggende support. Hvis du skubber OS ud over mainstream / testet skala tilføje en tilføjelse 4 enheder. Gør meget komplekse ting, der kræver hackede kerner,ikke-standard enhedsdrivere osv. Hvis du virkelig bekymrer sig om sikkerhed tilføje en ekstra 12 enheder. Brug for funktionalitet, som ikke er i kernen på dette tidspunkt og/eller noget mere end grundlæggende jumpstart eller kickstart til installation og styring? Administrer dette som et programudviklingsprojekt og få gode ingeniører til at arbejde på det. |
| 1 enhed for hver 50 kasser, hvis du ikke kan beskytte OS og systemkonfigurationer fra brugerne (vinduer i mange miljøer), eller hvor der er høj tilpasning, som skal udføres af IT-personale. 1 enhed for hver 200 kasser, hvis du kan beskytte OS fra brugerne uden at hindre brugeren, men kan ikke automatisk bygge / genopbygge / opdatere OS og programmer uden det tilsyn. 1 enhed for hver 400 kasser, der har netværksbaserede programmer (computerklynger eller fuldautomatiske brugerarbejdsstationer med konfigurationsstyring). Ekstremt store operationer (1.000 s af maskiner, der kører helt cookie cutter) skalere mere som 500 kasser / enhed og kan skalere så højt som 2500 kasser/enhed på en google-skala, hvor du har råd til at miste fulde stativer / serviceenheder uden at skulle straks gribe ind. | |
| Appliance Support | 1 enhed for hver simpel app. 4 enheder til enhver kompleks app, som personalet forventes at være strømbrugere. Indledende implementering af apps er typisk tidskrævende. Når et stort antal apps implementeres, skal der tages højde for den tid, det tager personalet at skifte kontekst / “bytte ind” information. |
| enkle netværkstjenester | 1 enhed for hver to grundlæggende tjenester: httpd, DNS, mail, udskrivning, SAMBA osv. Tilføj 2 enheder, hvis du vil have dem til at have bedre end 99,8% tilgængelighed. Tilføj 2 enhed, hvis du er interesseret i sikkerhed. Tilføj 1 enhed, hvis du skalerer større end gennemsnittet. Tilføj 4, hvis du skalerer til mega størrelse og er ud over, hvad programmet er designet til. Hvis du er helt uden for skalaen, skal du behandle et udviklingsprojekt og personale i overensstemmelse hermed med ingeniører. |
| komplekse netværkstjenester | meget variabel. For eksempel kunne multi-terabyte database, der anvendes til data mining nemt forbruge flere DBA ‘ er + flere senior systemadministratorer, der specialiserer sig i performance tuning og storskala lagersystem. |
| netværksforbindelse | skalerer mod antal netværksenheder, antal netværk, sikkerhedsproblemer, kompleksitet af routing, HA-krav. |
| koordinering og Ledelse | jo større og mere kompleks en organisation er, jo mere er der behov for koordineringsroller. Mennesker, der fokuserer på menneskelig ledelse, systemarkitektur, programledelse, Projektledelse. Dette er ret kompliceret. Det ville være formasteligt at foreslå et forhold. |
en solid Sage II systemadministrator kan håndtere 4 arbejdsenheder. En stærk Sage III systemadministrator kan håndtere 8 enheder af arbejde. En overlegen SAGE IV systemadministrator kan håndtere 12 arbejdsenheder. Der er nogle sjældne individer, der har både dyb og bred erfaring, er ude af boksen tænkere, høj kvalitet, og utroligt fokuseret og produktion. Selvom de ikke skalerer mod menneskelige opgaver som slutbrugerstøtte bedre end en SAGE IV-niveau person, skalerer de betydeligt bedre på det tekniske / systemarbejde. Dette er relateret til lore, at der er nogle udviklere, der er 10 gange bedre end en “normal” Udvikler. I løbet af min karriere har jeg haft fornøjelsen af at arbejde med flere af disse ekstraordinære kunstnere. Dette optællingssystem er løst baseret på en ligning foreslået af Shertford Botsford og findes i comp.UNIX.ofte stillede spørgsmål om admin. Et punkt vil jeg opdatere tællingen for at bruge min Sre-Færdighedsmatrice.
andre problemer
Site med en administrator er ikke særlig ønskeligt.
de er en kendsgerning, da mange små steder hverken har råd til eller retfærdiggør mere end en systemadministrator. Det er svært for en person at have bredden af viden og erfaring til at køre et virkelig førsteklasses sted, uanset hvor få maskiner det har. Der vil altid være et område, der ikke er styrken for en eneste administrator.
et andet problem er, at siden med en enkelt systemadministrator har et enkelt fejlpunkt: når administratoren er på ferie (eller bliver kørt over af en bus), er siden sårbar. At bære en personsøger på ferie er ikke min ide om sjov; men ingen kan forudsige, hvornår en krise kan opstå. Selvfølgelig er det svært at interessere en person på højt niveau i et job, der også indebærer at ændre backupbåndene og kravle gennem lofterne.
jo mere homogent et sted er, jo lettere er det at understøtte.
antallet af understøttede platforme (forskellige maskinarkitekturer eller forskellige operativsystemer) øger kompleksiteten af supportopgaven. Opgradering af operativsystemet skal ske mindst en gang for hånd for hver platform. Hvert operativsystem har sine egne idiosynkrasier, der skal læres og mestres. De fleste steder ønsker, at alle platforme skal se identiske ud, så deres brugere kan sætte sig ned på en af arbejdsstationerne og få arbejdet udført. Dette kræver, at hver platform har identiske værktøjer, vinduessystemer osv. Dette kan i høj grad øge mængden af arbejde, som administratoren skal udføre. Under de bedste omstændigheder betyder dette genkompilering af programmer for hver platform. Under de værste omstændigheder involverer det porting af programmer og kamp med leverandørleverede programmer. Mit personlige mareridt forsøger at støtte alle 11R4 (fra MIT), Decvinduer, OSF/Motif og solens åbne vinduer på tre forskellige platforme.
større steder kan udnytte stordriftsfordele.
store sites kan udvide deres administration stabe mindre hurtigt end antallet af brugere (eller arbejdsstationer) vokser. Årsagen til dette er, at når dit personale bliver større, er det muligt for folk at specialisere sig. Denne specialisering tillader individuelle medarbejdere at udvikle en dybde af ekspertise, der gør det muligt for dem at forstå alle spørgsmål om et givet emne og løse hurtigere, uanset hvilke problemer der opstår.
for det andet kan større steder udnytte tidligere arbejde. Den første installation af en maskine eller et stykke program er altid det sværeste. Det andet er lettere. Når du har udført 50 eller 100 installationer, har du udviklet automatiske scripts og kan udføre installationer i din søvn. Jeg har set store steder i et 1: 100 administrator-til-maskine-forhold, hvor tingene løb ret godt. Jeg må dog advare læseren: denne form for forhold er kun mulig med førsteklasses mennesker, der arbejder i et omhyggeligt konstrueret miljø med mange hundrede brugere. De fleste steder kan ikke få produktivt arbejde udført med denne slags forhold. Denne form for forhold begrænser også den professionelle vækst hos medlemmer af systempersonalet, fordi de vil tilbringe det meste af deres tid med de daglige problemer og brandbekæmpelse. Dette er en skam, da en organisations mest værdifulde ressource er dens mennesker.
| øget SA-effektivitet | nedsat Sa-effektivitet |
| automatisering standarder (politik, arkitektur) effektiv overvågning fælles værktøjer Robust er sikkerhed stram kontrol over, hvad der bliver indlæst på HV/SV baseline redundans af kritiske tjenester adskillelse af tjenester (single service machines) godt træningsprogram detaljerede katastrofegendannelsesplaner, efter system System, der ikke kræver sikkerhedskopier |
baseline for forskelligt udstyr baseline for forskelligt program slap is sikkerhed lidt eller ingen træning et personale, der er reaktivt, ikke proaktivt ad hoc-sikkerhedskopier eller ingen sikkerhedskopier |
høj tilgængelighed Sites kræver højere bemanding.
Site, der skal være meget tilgængeligt (f.eks. større end 99,9% servicelevering), kræver et højere bemandingsniveau. Årsagen til dette er, at du har brug for folk, der kan reagere næsten øjeblikkeligt på eventuelle serviceproblemer (f.eks. 24 liter 7 dækning, ideelt mindst 2 personer dybt, der kan gøre første og andet niveau opløsning og være i stand til at eskalere til fagområdeeksperter). Du skal også have flere personer for hvert fagområde, der er i stand til at diagnosticere og løse komplekse problemer hurtigt.
Hvad Med Andre Platforme?
den platform, der understøttes, gør en stor forskel. Min erfaring er, at støtte fra Macintosh og UNIFÆLLESSKABER tager omtrent samme bemandingsniveau. Historisk set synes understøttelse af pc ‘ er, der kører ethvert Microsoft OS, at kræve mindst dobbelt bemanding og leverer et lavere serviceniveau. Siden vinduer behøver forholdet ikke at være så højt… men jeg finder stadig administrationsskalaer bedre på unik end vinduer.
andres forhold
i de sidste par år har der været mange mennesker, der har talt om de forhold, de synes er rimelige. Det er almindeligt at høre folk tale om personale / brugerforhold på 1:60, hvor der er en vis variation i befolkningen og meget brugerdefineret arbejde og personale / brugerforhold på 1:150 (eller højere) på steder, der kan bruge “cookie cutter” – løsninger, f.eks. universiteter med horder af studerende eller virksomheder, hvor folk bruger computing som et værktøj i stedet for at søge at innovere på de maskiner, der administreres. Et mere realistisk sæt nøgletal (baseret på bedste praksis på området snarere end leverandørhvide sider på TCO) var Mega Groups artikel om forbedring af personaleforhold. Der er en række andre undersøgelser, der har vist, at de fleste organisationer i den virkelige verden ikke har været i stand til at understøtte forhold større end 30:1. En Geringsundersøgelse fra 2000 antydede, at forholdet er 47:1 +/- 17%. I en video om bruger til tekniker-forhold af Justin Nguyen var et basisforhold på 60:1 forslag med en række faktorer, der påvirker dette forhold.
et eksempel på over oppustede tal kan findes i Staffing for Technology Support, en hvidbog til uddannelsesinstitutioner. Desværre forsøger disse folk at anvende personaleforhold fra MIT ‘ s projekt Athena til resten af verden. Dette er fejlbehæftet af tre grunde. For det første har de fleste steder ikke de sofistikerede værktøjer, som Athena havde. For det andet havde Athena folk, der får Athena til at køre, som ikke blev fanget i deres forhold: studerende frivillige, der gjorde en masse arbejde og hard core systemprogrammerer, der udviklede værktøjer, der opfyldte MIT ‘ s krav. Endelig er MITs-brugerpopulation ikke en gennemsnitlig brugerpopulation.
David Cappuccio fra Gartner-gruppen foreslog i sin artikel Kend typerne: dimensionering af supportpersonale, at der er to forhold, som du skal overveje. Det første forhold er personale til brugere, et forsøg på at fange den menneskelige del af ligningen. Dette forhold ser på, hvor mange mennesker du har brug for at gøre det, der ofte kaldes Tier i, helpdesk, eller brugersupport. Personale, der fanger, hvor mange mennesker der er nødvendige for at tage sig af den tekniske infrastruktur. Mens jeg kan lide Davids rammer, tror jeg, at hans forhold er for høje til brugersupport, og at han ikke har fanget det forskellige sæt teknologier, som de fleste organisationer implementerer: der er meget mere end print -, fil -, Internet-og databaseservere. Der er bibliotek, sikkerhed, messaging og kollaborative tjenester. At komplicere sager, mange steder er heterogene, der kræver ekstra indsats for at få en service til at fungere for alle klienter, eller værre, hvilket resulterer i behovstjenester, der er baseret på klientplatformen. En sidste komplicerende faktor er, at disse tjenester ofte har komplekse interaktioner og afhængigheder, hvilket gør dem vanskeligere at implementere og vedligeholde. Resultatet er, at Davids forhold vil resultere i bemanding, som kun vil kunne levere de mest basale tjenester på et passende niveau.
itbenchmark-bloggen har en række indlæg om emnet personalestørrelse.
konklusion
antallet af administratorer, der kræves, varierer meget fra sted til sted. Den ene konstant er, at der sjældent er nok systemadministratorer til det ansvar, de har. På det tidspunkt, hvor dette oprindeligt blev skrevet, fandt jeg, at det var muligt for en enkelt person at vedligeholde op til 220 maskiner (med tre forskellige platforme) og give passende brugertjenester til en ret sofistikeret brugerpopulation på omkring 80 personer. Min tid er delt mellem brugertjenester (30 procent), generelle systemadministrationsopgaver (20 procent), installation af nye maskiner og udstyr/netværkssupport (10 procent), installation og vedligeholdelse af programmer (30 procent), udvikling af brugerdefinerede programmer og sporing af tendenser (35 procent) og planlægning af anlæg (10 procent). Du vil bemærke, at dette tilføjer op til 135 procent.
historie af dette indlæg
i 1991 sendte jeg en note til Usenet, der svarede på et spørgsmål om personaleforhold. Rob Kostad bad mig om at udvide den korte note til en artikel, der løb med titlen “Hvor mange administratorer er nok?”i magasinet unik anmeldelse, April 1991. I årenes løb har jeg lavet nogle, for det meste mindre opdateringer til den originale artikel. En af disse dage vil jeg omskrive det fuldstændigt. Mens denne artikel blev skrevet for længe siden, jeg finder ud af, at forholdene stadig er ret nøjagtige. Hvis du tror, jeg tager fejl, send mig mail med dine oplevelser.