Opprinnelig Publisert i 1991
Mindre oppdateringer i 2000, 2017 og 2021

«Hvor MANGE IT-ansatte trenger en organisasjon?»er et ofte spurt og vanskelig å svare på spørsmål. Det er ingen magisk forhold. Det er ikke noe ideelt bemanningsnivå. Riktig antall ansatte avhenger av HVA IT-organisasjonen er ansvarlig for og servicenivået som forventes i hvert ansvarsområde.

dette innlegget handler først og fremst om klassisk it-bemanning… hva skjer i et selskap eller et universitet hvor IT-løsninger leveres. Mens relatert, kjører en produksjonstjeneste som leverer programvare som tjeneste, er ganske forskjellig fra enterprise computing. DET var en kort artikkel I CIO som viser hva som skjer når du benchmark bedrifter mot tjenesteleverandører. Jeg diskuterer noen av disse problemene i Mine Tips For Drift Av Høy Kvalitet. James Hamilton har bemerket at i mega skala operasjoner, menneskelige ansatte står for mindre enn 10% av de totale kostnadene.

det var en fin graf funnet i slide deck Impliance: Et Informasjonshåndteringsapparat av FOLK fra IBM Research som fanget hvordan bemanningskostnadene har gått opp i forhold til kostnaden for maskinvare for bedriftsberegning. I et produksjonsmiljø er det vanligvis betydelig mer investering i infrastruktur og verktøy, arbeid deles ofte mellom en ingeniørgruppe og en driftsgruppe, og det er ofte stordriftsfordeler som jeg bare hint på i dette papiret.

HVA IT-Ansatte Gjør

det er mange forskjellige typer arbeid SOM IT-team ofte er ansvarlige for å levere.

Brukertjenester (F. Eks. Helpdesk)

hvor mye håndholding forventes? Noen nettsteder har brukere som er ganske selvforsynt; andre nettsteder har brukere som trenger hjelp til alt de gjør. Kan brukerne ta vare på seg selv eller trenger de og vil at administratoren skal utføre selv de enkleste oppgavene for dem? For eksempel har jeg en venn hvis brukere krever at han utfører de mest grunnleggende oppgavene for dem (for eksempel å flytte filene fra en katalog til en annen). Alt som ikke bare påkaller tekstredigeringsprogrammet eller leser e-post, er «UNIX» og dermed en jobb for administratoren. Denne typen støtte krever et forhold som en administrator for hver fire brukere.

vil nettstedet at du skal gjennomføre workshops eller utarbeide omfattende lokal dokumentasjon? I hvilken grad forventes det at du konsulterer i tekniske spørsmål? Bekymrer du deg selv med bare operativsystemet SOM OSX eller Hjelper Helpdesk med applikasjoner, eller til og med utviklingsverktøy? For eksempel, la oss si at nettstedet ditt har tunge brukere Av TeX, Mathematica, C++, Python, X11, R, MySQL og Google G-Suite. Er brukertjenester ment å kunne svare på detaljerte spørsmål om alle disse emnene? Få mennesker er eksperter på alle disse tingene. Utvikling av kompetanse i et gitt emneområde krever tid til å leke, eksperimentere og modne i det området, og det er grenser for antall områder noen kan mestre.

Programvarestøtte

hvor mye offentlig domene programvare eller freeware vil folk ha installert? Hvilket støttenivå forventer de? Installere Rpm er vanligvis ganske enkelt. Bare kompilere og installere programvare tar ikke mye tid. Ofte skjønt, programvare ikke bare kompilere og installere riktig. Ofte er det konflikter mellom pakker som kan være utfordrende å løse. Det er ofte forutsetninger i programvaren som må endres før programvaren kan brukes på et gitt nettsted. I tillegg forventes administratorer ofte (og med rette) å fortsette vedlikehold av programvaren (feilrettinger, sikkerhetsoppdateringer og hva ikke) og å bli ekspert i bruken av programvaren. Kompilering og installasjon (kombinert med hyppige oppdateringer) eller mange maskinvare/programvareplattformer kan gjøre dette utrolig tidkrevende for bare noen få programvarepakker. Tiden dette tar varierer med kvaliteten og kompleksiteten av programvaren. Å holde en nåværende versjon av kermit eller perl er ikke vanskelig (jeg skulle ønske alle gjorde så fin jobb Som Larry Wall har med perl); å holde tritt med g++ er mye mer tidkrevende.

Cloud Services Support

i økende grad bruker organisasjoner skytjenester til å løse sine forretningsproblemer. Ansatte tid For Skytjenester er ofte undervurdert fordi de pleier å bli distribuert. Først er kostnaden for ombordstigning. Ofte er dette så snart noen bruker et kredittkort for å registrere seg for en tjeneste, men det er ikke bærekraftig. Først må faktureringen virkelig gå til organisasjonen, ikke en person. Viktigere skjønt er å forsikre de riktige personene har tilgang, og enn når folks roller endres, eller de forlater selskapet, skjer det rette.

I beste fall kan SaaS utnytte et eksisterende kontoadministrasjonssystem som Google Apps, enterprise single sign-on-system som Okta, eller en intern ANNONSETJENESTE hvis Den gir Et Eksternt Tilgjengelig SaML-endepunkt. Kan må gjøres for å sikre at deaktivering av en enkelt påloggingskonto blokkerer tilgang (noen systemer tillater også tilgang mot en tjenestespesifikk legitimasjon). Vanligvis på boarding apps er rundt 1 mann uke / app som du faktor i å lære om tjenesten, arrangere integrasjoner, produsere riktig dokumentasjon.

Utover å få En SaaS plumbed i, det er et bredt spekter av mulige kostnader avhengig av kompleksiteten i integrasjoner, hvor mye tilpasning er nødvendig, og om DET vil være behov FOR IT-teamet for å gi kundestøtte.

ERP-System

i vår stadig mer komplekse og regulerte verden må organisasjoner spore og administrere et bredt spekter av prosesser. Som tempoet i arbeidet har økt er det oppfatningen at data må være tilgjengelig i sanntid, men har ført til innføringen Av Enterprise resource planning (Erp) systemer. DE beste kjente systemene i dette rommet ER SAP og Oracles pakke med applikasjoner. I midten er det selskaper som Netsuite og Workday. For små bedrifter Er Quickbooks ofte brukt.

I mindre orginiztions BLIR ERP-systemer ofte administrert av teamet som er ansvarlig for funksjonen. Finans tar seg av regnskapsprogramvaren. Menneskelige Ressurser tar ofte vare på hva verktøyene brukes til å administrere headcount, og bruker hva system finance har valgt for å gjøre lønn. I disse tilfellene er it-bemanning ganske minimal og er vanligvis fokusert på å gi en server og forsikre seg om at dataene regelmessig sikkerhetskopieres.

som et selskap vokser og størrelse og kompleksitet, kan kravene til disse systemene vokse massivt. Det er utenfor omfanget av dette innlegget for å diskutere estimering av bemanningskravene til ERP-systemer, men jeg vil gjøre en observasjon. I nesten alle tilfeller er det en dårlig ide å tilpasse ERP-systemer slik at de samsvarer nøyaktig med dine eksisterende forretningsprosesser. Når det er mulig, bør du bruke et system så nær ut av boksen som mulig, og hvis valget er å endre prosessen eller tilpasse programvaren, endre prosessen.

Tilpasset Programvare

Mange organisasjoner har ikke en dedikert programvareteknisk avdeling,SÅ IT-personalet blir bedt om ikke bare å administrere programvare levert av leverandører, men også å lage — on demand — verktøy for brukerfellesskapet. Dette er forståelig, spesielt i små områder HVOR IT-ansatte kan være de eneste profesjonelle programmerere. Hvis det er denne forventningen, må tiden tildeles for denne utviklingsprosessen.

Stedsplanlegging / Administrasjon Overhead

hvor mye nettstedsplanlegging forventes administratoren å håndtere? Må administratoren vite at den gjennomsnittlige personen genererer 115 watt, og hvordan å faktorere det og varme laster fra maskiner for å skalere passende AC/oppvarming laster og strøm? Hvor mye papirarbeid er det?

Maskinvare/Nettverksvedlikehold

hvem kryper gjennom taket for å trekke ledninger? Hvem finner den flaky transceiveren når Ethernet begynner å bli gal? Når en arbeidsstasjon dør, ringer en sekretær bare leverandøren og venter, eller er det mer kreative løsninger som kreves? Gjør du styret nivå reparasjoner? Kjøper nettstedet ditt alle eksterne enheter som er klare til å installeres, eller sparer du penger ved å kjøpe komponenter og gjøre integrasjonen selv? Å ha IT-ansatte gjør noen av disse tingene tar tid.

Forutse Teknologi

SKAL IT-personalet forutse ny teknologi og gi råd til selskapet om nye tilnærminger? De fleste steder jeg har jobbet forventer AT IT-ansatte skal ha en god følelse for toppmoderne og ny teknologi som ser lovende ut(ikke bare produkter, men også forskning). Forventning er ofte nødvendig gitt mange nettsteder har en tre-til-seks års planlegging eller avskrivning tidsplan. Å holde tritt med vårt felt er ikke lett. Det finnes en rekke kilder en mye trekke på å holde deg oppdatert. Jeg har funnet en rekke gode kilder for aktuell informasjon. Trade rags kan gi deg et bilde av hva som blir solgt, blogg (og andre elektroniske medier) er flott for spørsmål om aktuelle problemer og problemer. Faglige tidsskrifter FRA ACM, ieee, etc er nyttige for å se hva som skjer på den nesten ferdige forskningsfronten. Det er imidlertid ingen erstatning for et godt nettverk av profesjonelle kontakter. Dette nettverket kan opprettholdes med telefonsamtaler, elektronisk post, delta i nettsamfunn og delta på konferanser.

Mine Forhold

den beste måten å estimere antall administratorer som trengs, er å finne ut hvilket servicenivå som kreves og hvordan ulike faktorer (for eksempel nettverksinfrastruktur og heterogenitet av maskinene som støttes) vil påvirke oppfyllelsen av disse ansvarene. Sjelden gjør systemadministratorer bare» administrator » oppgaver. Den første delen av denne artikkelen vil detaljere oppgavene som jeg finner meg selv å utføre i tillegg til de vanlige» administrator » – oppgavene, for eksempel sikkerhetskopiering, installering av nye brukere, vedlikehold av operativsystemet og så videre. Ytterligere oppgaver presenteres (for det meste) i form av spørsmål. Den andre delen beskriver noen av de ulike faktorene som vil påvirke personalnivået. Den tredje delen beskriver noen enkle perspektiver som systemadministratorer kan vedta for å gjøre miljøet lettere administrerbart. Til slutt vil jeg avslutte med å raskt undersøke noen forhold som kan hjelpe deg med å tilnærme dine bemanningsbehov.

følgende er et veldig grovt sett med regler jeg bruker til å estimere bemanningskrav. Din kjørelengde vil variere. Jeg bør merke seg at disse tallene antar å opprettholde et rimelig stabilt miljø. Rask omsetning av brukerbase, maskiner, unormalt hyppige programvareendringer, miljøvekst osv.

Type Arbeid	Enheter av arbeidskraft for å levere beste praksis ytelse og skalering faktorer
Sluttbrukertjeneste	1 enhet til 50 brukere som får god service. 1 enhet for hver 200 som får grunnleggende service, og (f. eks studenter i en pedagogisk fabrikk) antar 8×5 støtte. Ikke nødvendig hvis du kjører tjenesten med en egen kundebehandling organisasjon. Forholdet må gå opp hvis du vil at helpdesk skal kjøre utvidede timer.
24 x 7 Support (Partnere, kunder, etc)	Gjør en 24×7 NOC som krever proaktiv varsling og rask problemløsningsskala mot kompleksiteten til tjenesten som administreres og antall high touch-klienter. Steder som virkelig bryr seg om dette har et skritt i pris på 14 personer… en leder, en assisterende leder, tre skift, med hvert skift har to personer, ett skift kjører søndag-onsdag, og den andre kjører onsdag-lørdag, så det er overlapping mellom lag, rene handoffs og tider for å gjøre gruppetrening. Mindre at dette lett kan føre til at skift ikke blir dekket. For eksempel kan det å ha en enkelt person / skift mislykkes hvis nattskiftpersonen sovner, eller hvis noen jobber med en av helgeskiftene blir syk. Dette teller ikke folk å eskalere til. Antall personer som trengs per skift er relatert til hvor mye normalt arbeid det er, og hvor mange samtidige katastrofer teamet forventes å kunne håndtere.
Operativsystemadministrasjon	2 enheter for HVERT merke AV OS som krever grunnleggende støtte. Hvis DU skyver OS utover mainstream / testet skala legge til et tillegg 4 enheter. Å gjøre svært komplekse ting som krever hackede kjerner, ikke-standard enhetsdrivere, etc, legg deretter til 4 enheter. Hvis du virkelig bryr deg om sikkerhet, legg til ytterligere 12 enheter. Trenger funksjonalitet som ikke er i kjernen på dette tidspunktet og/eller noe mer enn grunnleggende jumpstart eller kickstart for installasjon og administrasjon? Behandle dette som et programvareutviklingsprosjekt og få gode ingeniører som jobber med det.
Hardware Management / Host Imaging (OS Deployment)	1 enhet for hver 50 bokser hvis DU ikke kan beskytte OS og systemkonfigurasjoner fra brukerne (Windows i mange miljøer) eller hvor det er høy tilpasning som MÅ gjøres AV IT-ansatte. 1 enhet for hver 200 bokser hvis du kan beskytte OS fra brukerne uten å hindre brukeren, men kan ikke automatisk bygge / gjenoppbygge / oppdatere OS og programvare uten DET tilsyn. 1 enhet for hver 400 bokser som har nettverksbasert programvareinstallasjon (databehandlingsklynger eller helautomatiske brukerarbeidsstasjoner med konfigurasjonsstyring). Ekstremt storskala operasjoner (1000 s maskiner som kjører helt cookie cutter) skalere mer som 500 bokser / enhet og kan skalere så høyt som 2500 bokser / enhet på en google-skala hvor du har råd til å miste fulle stativer / serviceenheter uten å måtte handle umiddelbart.
Apparatstøtte	1 enhet for hver enkel app. 4 enheter for enhver kompleks app som ansatte forventes å være avanserte brukere. Innledende distribusjon av apper er vanligvis tidkrevende. Når et stort antall apper distribueres, må du ta hensyn til tiden det tar ansatte å kontekstbryter / «bytte inn» informasjon.
Enkle Nettverkstjenester	1 enhet for hver to grunnleggende tjenester: httpd, DNS, post, utskrift, SAMBA, etc. Legg til 2 enheter hvis du vil at de skal ha bedre enn 99,8% tilgjengelighet. Legg til 2 enhet hvis du bryr deg om sikkerhet. Legg til 1 enhet hvis du skalerer større enn gjennomsnittet. Legg til 4 hvis du skalerer til mega størrelse og er utenfor hva programvaren ble designet for. Hvis du er helt utenfor skalaen, behandle et utviklingsprosjekt og ansatte tilsvarende med ingeniører.
Komplekse Nettverkstjenester	Svært variabel. For eksempel kan multi-terabyte database som brukes til datautvinning enkelt forbruke flere Dba + flere senior systemadministratorer som spesialiserer seg på ytelsesjustering og storskala lagringssystem.
Nettverkstilkobling	Skalerer mot antall nettverksenheter, antall nettverk, sikkerhetsproblemer, kompleksitet av ruting, HA krav.
Koordinering Og Ledelse	jo større og mer kompleks en organisasjon er, desto mer er det behov for koordineringsroller. Folk som fokuserer på menneskelig ledelse, systemarkitektur, programledelse, prosjektledelse. Dette er ganske komplisert. Det ville være arrogant å foreslå et forhold.

en solid SAGE II systemadministrator kan håndtere 4 arbeidsenheter. En sterk SAGE III systemadministrator kan håndtere 8 arbeidsenheter. En overlegen SAGE IV systemadministrator kan håndtere 12 arbeidsenheter. Det er noen sjeldne personer som har både dyp og bred erfaring, er ute av boksen tenkere, høy EQ, og utrolig fokusert og produksjon. Selv om de ikke skalerer mot menneskelige oppgaver som sluttbrukerstøtte bedre enn EN SAGE IV-nivå person, skalerer de betydelig bedre på teknisk / systemarbeid . Dette er relatert til lore at det er noen utviklere som er 10x bedre enn en «normal» utvikler. I løpet av min karriere har jeg hatt gleden av å jobbe med flere av disse eksepsjonelle utøvere. Dette tellesystemet er løst basert på en ligning foreslått Av Sherwood Botsford og funnet i komp.unix.admin FAQ. Et poeng jeg vil oppdatere tellingen for å bruke MIN sre Skill Matrix (excel).

Andre Problemer

Nettsted med en administrator er ikke veldig ønskelig.

De er et faktum i livet siden mange små nettsteder verken har råd til eller rettferdiggjør mer enn en systemadministrator. Det er vanskelig for en person å ha bredden av kunnskap og erfaring for å kjøre et virkelig førsteklasses nettsted, uansett hvor få maskiner det har. Det vil alltid være et område som ikke er styrken til en eneste administrator.

Et annet problem er at nettstedet med en enkelt systemadministrator har et enkelt feilpunkt: når administratoren er på ferie( eller blir kjørt over av en buss), er nettstedet sårbart. Å bære en personsøker på ferie er ikke min ide om moro; men ingen kan forutsi når en krise kan oppstå. Selvfølgelig er det vanskelig å interessere en person på høyt nivå i en jobb som også innebærer å bytte sikkerhetskopier og krype gjennom takene.

jo mer homogen et nettsted er, desto lettere er det å støtte.

antallet ulike plattformer som støttes (ulike maskinarkitekturer eller ulike operativsystemer) øker kompleksiteten i støtteoppgaven. Oppgradering av operativsystemet må gjøres minst en gang for hånd for hver plattform. Hvert operativsystem har sine egne særegenheter som må læres og mestres. De fleste nettsteder vil at alle plattformene skal vises identiske slik at brukerne kan sette seg ned på noen av arbeidsstasjonene og få arbeidet gjort. Dette krever at hver plattform har identiske verktøy, vindussystemer, etc. Dette kan i stor grad øke mengden arbeid administratoren må gjøre. I beste fall betyr dette rekompilering programmer for hver plattform. I verste fall innebærer det porting programvare, og slåss med leverandør levert programvare. Mitt personlige mareritt prøver å støtte ALLE X11R4 (FRA MIT), DECwindows, OSF/Motif og Suns OpenWindows på tre forskjellige plattformer.

Større anlegg kan utnytte stordriftsfordeler.

store områder kan utvide sin administrasjon staber mindre raskt enn antall brukere (eller arbeidsstasjoner) vokser. Grunnen til dette er at som ansatte blir større er det mulig for folk å spesialisere seg. Denne spesialiseringen tillater individuelle medarbeidere å utvikle en dybde av kompetanse som gjør dem i stand til å forstå alle problemene på et gitt emne og løse raskere uansett problemer dukker opp.

for det andre kan større nettsteder utnytte tidligere arbeid. Den første installasjonen av en maskin eller programvare er alltid den vanskeligste. Den andre er lettere. Når du har gjort 50 eller 100 installasjoner, har du utviklet automatiske skript og kan gjøre installasjoner i søvnen. Jeg har sett store nettsteder på et 1: 100 administrator-til-maskin-forhold hvor ting gikk ganske bra. Jeg må advare leseren om: denne typen forholdet er bare mulig med top-notch mennesker som arbeider i en nøye konstruert miljø med mange hundre brukere. De fleste nettsteder kan ikke få produktivt arbeid med denne typen forhold. Denne typen forhold begrenser også den profesjonelle veksten til medlemmer av systempersonalet fordi de vil tilbringe mesteparten av tiden med de daglige problemene og brannslukking. Dette er en skam siden en organisasjons mest verdifulle ressurs er dens folk.

Økt SA-Effektivitet	Redusert Sa-Effektivitet
Automatisering Standarder (policy, arkitektur) Effektiv overvåking Vanlige verktøy Robust IS security Stram kontroll over hva som blir lastet på hw/SW baseline Redundans av kritiske tjenester Separeringstjenester (enkeltstående maskiner) Godt treningsprogram Detaljerte planer for katastrofegjenoppretting, etter system System som ikke krever sikkerhetskopier	Diverse maskinvare baseline diverse programvare baseline lax Er sikkerhet Lite eller ingen opplæring en stab som er reaktiv, ikke proaktiv ad hoc-sikkerhetskopier eller ingen sikkerhetskopier

Høy Tilgjengelighet Nettsteder Krever høyere bemanning.

Nettsted som må være svært tilgjengelig (f.eks større enn 99,9% service levering) vil kreve et høyere nivå av bemanning. Årsaken til dette er at du trenger folk som kan svare nesten umiddelbart på eventuelle serviceproblemer (f.eks. 24×7 dekning, ideelt sett minst 2 personer dypt som kan gjøre første og andre nivå oppløsning, og være i stand til å eskalere til fagområdeeksperter). Du må også ha flere personer for hvert fagområde som er i stand til å diagnostisere og løse komplekse problemer raskt.

Hva Med Andre Plattformer?

plattformen som støttes, gjør en stor forskjell. Min erfaring er at støtte Fra Macintosh og UNIX-fellesskap tar omtrent samme bemanningsnivå. Historisk støtte Av Pcer som kjører Noen Microsoft OS synes å kreve minst dobbelt bemanning og leverer et lavere servicenivå. Siden Windows XP trenger forholdet ikke å være så høyt… men jeg finner fortsatt administrasjonsskalaer bedre PÅ UNIX enn Windows.

Andre Folks Forhold

I de siste årene har det vært mange mennesker som har snakket om forholdene de synes er rimelige. Det er vanlig å høre folk snakke om ansatte/brukerforhold på 1: 60 hvor det er noe variasjon i befolkningen og mye tilpasset arbeid, og ansatte / brukerforhold på 1:150 (eller høyere) på steder som kan bruke «cookie cutter» løsninger, f. eks universiteter med horder av studenter eller bedrifter der folk bruker databehandling som et verktøy i stedet for å se for å innovere på maskinene som blir administrert. Et mer realistisk sett med forholdstall (basert på beste praksis i feltet i stedet for leverandør hvite sider PÅ TCO) Var Mega Groups Forbedre bemanningsforhold artikkel. Det finnes en rekke andre studier som har funnet ut at i den virkelige verden de fleste organisasjoner ikke har vært i stand til å støtte forhold større enn 30: 1. En Mitre studie fra 2000 antydet at forholdet er 47:1 +/- 17%. I en video om Bruker Til Tekniker Forhold Av Justin Nguyen var et baseforhold på 60:1 forslag, med en rekke faktorer som påvirker dette forholdet.

Et eksempel på oppblåste tall finnes i Bemanning For Teknologistøtte, en stortingsmelding for utdanningsinstitusjoner. Dessverre prøver disse menneskene å bruke bemanningsforhold fra MITS Prosjekt Athena til resten av verden. Dette er feil av tre grunner. For det første har de fleste nettsteder ikke de sofistikerte verktøyene Som Athena hadde. For Det andre hadde Athena folk som gjør Athena løp som ikke ble fanget i sine forhold: studentfrivillige som gjorde mye arbeid og hardkjerne systemprogrammerer som utviklet verktøy som møtte MITS krav. MITs brukerpopulasjon er ikke en gjennomsnittlig brukerpopulasjon.

David Cappuccio Fra Gartner Group foreslo I sin artikkel Know The Types: Dimensjonering Av Støttestaber at det er to forhold som du må vurdere. Det første forholdet er ansatte til brukere, et forsøk på å fange den menneskelige delen av ligningen. Dette forholdet ser på hvor mange personer du trenger å gjøre det som ofte kalles Tier I, help desk eller user support. Det andre forholdet er antall maskiner og delsystemer per stab, som fanger hvor mange som trengs for å ta vare på den tekniske infrastrukturen. Mens Jeg liker Davids rammeverk, tror jeg at hans forhold er for høye for brukerstøtte, og at han ikke har klart å fange det mangfoldige settet av teknologier de fleste organisasjoner distribuerer: det er mye mer enn utskrift, fil, web og databaseservere. Det er katalog, sikkerhet, meldinger og samarbeidstjenester. For å komplisere saker, er mange nettsteder heterogene som krever ekstra innsats for å få en tjeneste til å fungere for alle klienter, eller verre, noe som resulterer i behovstjenestene som er basert på klientplattformen. En siste kompliserende faktor er at disse tjenestene ofte har komplekse interaksjoner og avhengigheter som gjør dem vanskeligere å distribuere og vedlikeholde. Resultatet er At Davids forholdstall vil resultere bemanning som vil være i stand til å levere bare de mest grunnleggende tjenester på et tilstrekkelig nivå.

itbenchmark-bloggen har en rekke innlegg om temaet personalstørrelse.

Konklusjon

antallet administratorer som kreves, varierer sterkt fra område til område. Den ene konstanten er at det sjelden er nok systemadministratorer for det ansvaret de har. På den tiden dette ble opprinnelig skrevet, fant jeg at det var mulig for en enkelt person å opprettholde opptil 220 maskiner (med tre forskjellige plattformer) og gi tilstrekkelige brukertjenester til en ganske sofistikert brukerbefolkning på rundt 80 personer. Min tid er delt mellom brukertjenester (30 prosent), generelle systemadministrasjonsoppgaver (20 prosent), installasjon av nye maskiner og maskinvare/nettverksstøtte (10 prosent), programvareinstallasjon og vedlikehold (30 prosent), tilpasset programvareutvikling og sporing av trender (35 prosent) og nettstedplanlegging (10 prosent). Du vil merke at dette legger opp til 135 prosent.

Historien Til Dette Innlegget

I 1991 postet Jeg Et notat Til Usenet som svarte på et spørsmål om bemanningsforhold. Rob Kostad ba meg om å utvide det korte notatet til en artikkel som kjørte med tittelen » Hvor Mange Administratorer Er nok?»I Magasinet Unix Review, April 1991. Gjennom årene har jeg gjort noen, for det meste mindre oppdateringer til den opprinnelige artikkelen. En av disse dagene vil jeg omskrive det helt. Selv om denne artikkelen ble skrevet for lenge siden, finner jeg at forholdene fortsatt er ganske nøyaktige. Hvis du tror jeg har feil, send meg mail med dine erfaringer.