ursprungligen publicerad 1991
mindre uppdateringar 2000, 2017 och 2021
”hur många IT-Personal behöver en organisation?”är en vanligt frågad och svår att svara på Fråga. Det finns inget magiskt förhållande. Det finns ingen idealisk bemanningsnivå. Det lämpliga antalet anställda beror på vad IT-organisationen ansvarar för och servicenivån som förväntas inom varje ansvarsområde.
det här inlägget handlar främst om klassisk IT-Personal för företag … vad händer inom ett företag eller ett universitet där IS/IT-lösningar levereras. Medan du är relaterad, kör en produktionstjänst som levererar programvara som tjänst är ganska annorlunda än företagsberäkning. Det fanns en kort artikel i CIO som visar vad som händer när du jämför företag mot tjänsteleverantörer. Jag diskuterar några av dessa frågor i mina tips för att driva högkvalitativa tjänster. James Hamilton har noterat att i mega skala verksamhet, mänsklig personal står för mindre än 10% av de totala kostnaderna.
det fanns en fin graf som hittades i slide deck Impliance: en Informationshanteringsapparat av folk från IBM Research som fångade hur personalkostnaderna har stigit i jämförelse med kostnaden för hårdvara för företagsberäkning. I en produktionsmiljö är det vanligtvis betydligt mer investeringar i infrastruktur och verktyg, arbetet delas ofta mellan en ingenjörsgrupp och en verksamhetsgrupp, och det finns ofta stordriftsfördelar som jag bara antyder i detta dokument.
vad IT-Personal gör
det finns många olika typer av arbete som IT-team ofta ansvarar för att leverera.
användartjänster (t. ex. Helpdesk)
hur mycket handhållning förväntas? Vissa webbplatser har användare som är ganska självförsörjande; andra webbplatser har användare som behöver hjälp för allt de gör. Kan dina användare ta hand om sig själva eller behöver de och vill att administratören ska utföra även de enklaste uppgifterna för dem? Till exempel har jag en vän vars användare kräver att han utför de mest grundläggande uppgifterna för dem (som att flytta sina filer från en katalog till en annan). Allt som inte bara åberopar textredigeraren eller läser e-post är ”UNIX” och därmed ett jobb för administratören. Denna typ av stöd kräver ett förhållande ungefär som en administratör för varje fyra användare.
vill Webbplatsen att du ska genomföra workshops eller förbereda omfattande lokal dokumentation? I vilken utsträckning förväntas du konsultera tekniska frågor? Bryr du dig om bara operativsystemet som OSX eller hjälper Helpdesk med applikationer eller till och med utvecklingsverktyg? Låt oss till exempel säga att din webbplats har tunga användare av TeX, Mathematica, C++, Python, X11, R, MySQL och Google G-Suite. Ska användartjänster kunna svara på detaljerade frågor om alla dessa ämnen? Få människor är experter på alla dessa saker. Utveckling av expertis inom ett visst ämnesområde kräver tid att spela, experimentera och mogna i det området, och det finns gränser för antalet områden som någon kan behärska.
programvarusupport
hur mycket public domain-programvara eller freeware vill folk ha installerat? Vilken nivå av stöd förväntar de sig? Att installera RPM är vanligtvis ganska enkelt. Att bara sammanställa och installera programvara tar inte mycket tid. Ofta dock, programvara inte bara kompilera och installera på rätt sätt. Ofta finns det konflikter mellan paket som kan vara utmanande att lösa. Det finns ofta antaganden i programvaran som måste ändras innan programvaran kan användas på en viss plats. Dessutom förväntas administratörer ofta (och med rätta) fortsätta underhållet av programvaran (buggfixar, säkerhetsuppdateringar och vad inte) och bli expert på användningen av programvaran. Kompilering och installation (i kombination med frekventa patchar) eller många hårdvaru – /mjukvaruplattformar kan göra detta otroligt tidskrävande för bara några programvarupaket. Den tid det tar varierar med kvaliteten och komplexiteten i programvaran. Att hålla en aktuell version av kermit eller perl är inte svårt (Jag önskar att alla gjorde så bra jobb som Larry Wall har med perl); att hålla jämna steg med g++ är mycket mer tidskrävande.
molntjänster stöder
allt mer idag använder organisationer molntjänster för att lösa sina affärsproblem. Personalens tid för molntjänster är ofta under beräknad eftersom de tenderar att distribueras. Först är kostnaden för ombordstigning. Ofta är det så snart någon använder ett företag kreditkort för att registrera dig för en tjänst, men det är inte hållbart. För det första måste faktureringen verkligen gå till organisationen, inte en individ. Viktigare är dock att försäkra sig om att rätt personer har tillgång,och än när människors roller förändras, eller de lämnar företaget, händer det rätta.
i bästa fall kan SaaS utnyttja ett befintligt kontohanteringssystem som Google Apps, Enterprise single sign-on-system som Okta eller en intern annonstjänst om den tillhandahåller en externt nåbar SaML-slutpunkt. Can måste göras för att försäkra sig om att inaktivering av ett enda inloggningskonto blockerar åtkomst (vissa system tillåter också åtkomst mot en tjänstespecifik referens). Generellt på boarding apps är runt 1 man vecka / app som du faktor att lära sig om tjänsten, arrangera integrationer, producera lämplig dokumentation.
utöver att få en SaaS plumbed in, finns det ett brett utbud av möjliga kostnader beroende på integrationernas komplexitet, hur mycket anpassning som krävs och om det kommer att behövas för IT-teamet att tillhandahålla kundsupport.
ERP-System
i vår alltmer komplexa och reglerade värld måste organisationer spåra och hantera ett brett spektrum av processer. När arbetstakten har ökat finns uppfattningen att data måste vara tillgängliga i realtid men har lett till antagandet av ERP-System (Enterprise resource planning). De mest kända systemen i detta utrymme är SAP och Oracles applikationssvit. I mitten av nivån finns företag som Netsuite och Workday. För småföretag används Quickbooks ofta.
i mindre orginiztions hanteras ofta ERP-system av det team som ansvarar för funktionen. Finance tar hand om bokföringsprogram. Human Resources tar ofta hand om vilka verktyg som används för att hantera antalet anställda och använder vad systemfinansiering har valt för att göra löner. I dessa fall är IT-bemanningen ganska minimal och är vanligtvis inriktad på att tillhandahålla en server och försäkra sig om att det är data som regelbundet säkerhetskopieras.
när ett företag växer och storlek och komplexitet kan kraven i dessa system växa massivt. Det är utanför ramen för detta inlägg att diskutera uppskatta bemanningskraven för ERP-system, men jag kommer att göra en observation. I nästan alla fall är det dåligt att anpassa ERP-system för att exakt matcha dina befintliga affärsprocesser. När det är möjligt bör du använda ett system så nära ut ur lådan som du kan, och om valet är ändra din process eller anpassa programvaran, ändra din process.
anpassad programvara
många organisationer har inte en dedikerad programvaruteknikavdelning, så IT — personalen uppmanas inte bara att hantera programvara som tillhandahålls av leverantörer utan också att skapa — on demand-verktyg för användargemenskapen. Detta är förståeligt, särskilt på små platser där IT-personalen kan vara de enda professionella programmerarna. Om det finns denna förväntan måste tid tilldelas för denna utvecklingsprocess.
platsplanering / Administration Overhead
hur mycket platsplanering förväntas administratören hantera? Måste administratören veta att den genomsnittliga personen genererar 115 watt, och hur man faktor det och värmebelastningar från maskiner för att skala lämpliga AC/värmebelastningar och kraft? Hur mycket pappersarbete finns det?
hårdvara/Nätverksunderhåll
vem kryper genom taket för att dra ledningar? Vem hittar den flagnande transceivern när Ethernet börjar bli galen? När en arbetsstation dör, ringer en sekreterare bara din leverantör och väntar, eller krävs mer kreativa lösningar? Gör du reparationer på styrelsenivå? Köper din webbplats alla kringutrustning som är färdiga att installera eller sparar du pengar genom att köpa komponenter och göra integrationen själv? Att ha IT-Personal gör något av dessa saker tar tid.
förutse teknik
ska IT-personalen förutse ny teknik och ge företaget råd om nya tillvägagångssätt? De flesta platser jag har arbetat förväntar sig att IT-personalen ska ha en bra känsla för toppmodern och ny teknik som ser lovande ut (inte bara produkter utan också forskning). Förväntan är ofta nödvändigt med tanke på att många webbplatser har en tre till sex års planering eller avskrivningsschema. Att hålla jämna steg med vårt område är inte lätt. Det finns en mängd olika källor som man mycket drar på för att hålla sig uppdaterad. Jag har hittat en mängd bra källor för aktuell information. Handels trasor kan ge dig en bild av vad som säljs, blogg (och andra elektroniska medier) är bra för frågor om aktuella frågor och problem. Professionella tidskrifter från ACM, IEEE, etc är användbara för att se vad som händer på den nästan färdiga forskningsfronten. Det finns dock ingen ersättning för ett bra nätverk av professionella kontakter. Detta nätverk kan upprätthållas med telefonsamtal, elektronisk post, deltagande i onlinemiljöer och deltagande i konferenser.
mina förhållanden
det bästa sättet att uppskatta antalet administratörer som behövs är att ta reda på vilken servicenivå som krävs och hur olika faktorer (till exempel nätverksinfrastruktur och heterogenitet hos de maskiner som stöds) kommer att påverka uppfyllandet av dessa ansvarsområden. Sällan gör systemadministratörer bara” administratör ” – uppgifter. Den första delen av den här artikeln kommer att beskriva de uppgifter som jag befinner mig utföra utöver de normala ”administratör” uppgifter, såsom säkerhetskopior, installera nya användare, operativsystem underhåll, och så vidare. Ytterligare uppgifter presenteras (för det mesta) i form av frågor. Den andra delen beskriver några av de olika faktorer som kommer att påverka personalnivåerna. Den tredje delen beskriver några enkla perspektiv som systemadministratörer kan anta för att göra deras miljö lättare att administrera. Slutligen kommer jag att avsluta med att snabbt undersöka några förhållanden som kan hjälpa dig att approximera dina personalbehov.
följande är en mycket grov uppsättning regler som jag använder för att uppskatta personalkrav. Din körsträcka varierar. Jag bör notera att dessa siffror förutsätter att man upprätthåller en rimligt stabil miljö. Snabb omsättning av användarbas, maskiner, onormalt frekventa programändringar, tillväxt av miljön, etc resulterar i mer arbete och effekt förhållandena.
| typ av arbete | arbetsenheter för att leverera bästa praxis prestanda och skalningsfaktorer |
| Slutanvändartjänst | 1 enhet till 50 användare som får bra service. 1 enhet för varje 200 som får grundläggande service, och (t.ex. studenter i en pedagogisk fabrik) under antagande av 8 6ubbleri stöd. Behövs inte om du kör tjänsten med en separat kundvårdsorganisation. Förhållandet måste gå upp om du vill helpdesk att köra utökade timmar. |
| 24 x 7 Support (Partners, kunder, etc.) | gör en 24 7-noc-noc som kräver proaktiv anmälan och snabba problemlösningsskalor mot komplexiteten hos den tjänst som hanteras och antalet klienter med hög beröring. Platser som verkligen bryr sig om detta har ett steg i kostnaden för 14 personer… en chef, en assistentchef, tre skift, med varje skift som har två personer, ett skift som kör söndag-onsdag och den andra kör onsdag-lördag så det finns överlappning mellan lag, rena handoffs och tider att göra gruppträning. Mindre att detta lätt kan leda till att Skift inte täcks. Till exempel kan en enda person / Skift misslyckas om nattskiftpersonen somnar, eller om någon som arbetar en av helgskiften blir sjuk. Detta räknas inte folk att eskalera till. Antalet personer som behövs per skift är relaterat till hur mycket normalt arbete det finns och hur många samtidiga katastrofer laget förväntas kunna hantera. |
| Operativsystemhantering | 2 enheter för varje operativsystem som kräver grundläggande stöd. Om du trycker på OS bortom mainstream / testad skala Lägg till ett tillägg 4 enheter. Att göra mycket komplexa saker som kräver hackade kärnor, icke-standardiserade drivrutiner, etc, lägg sedan till 4 enheter. Om du verkligen bryr dig om säkerhet Lägg till ytterligare 12 enheter. Behöver funktionalitet som inte finns i kärnan just nu och / eller något mer än grundläggande jumpstart eller kickstart för installation och hantering? Hantera detta som ett mjukvaruutvecklingsprojekt och få bra ingenjörer att arbeta med det. |
| Hardware Management / Host Imaging (OS Deployment) | 1 enhet för varje 50 lådor om du inte kan skydda OS och systemkonfigurationer från användarna (Windows i många miljöer) eller där det finns hög anpassning som måste göras av IT-Personal. 1 enhet för varje 200 lådor om du kan skydda operativsystemet från användarna utan att hindra användaren, men kan inte automatiskt bygga / bygga om / uppdatera OS och programvara utan det övervakning. 1 enhet för varje 400 lådor som har nätverksbaserade programvaruinstallationer (beräkna kluster eller helautomatiska användararbetsstationer med konfigurationshantering). Extremt storskaliga operationer (1000 s maskiner som kör helt cookie cutter) skala mer som 500 lådor / enhet och kan skala så högt som 2500 lådor/enhet på en google-skala där du har råd att förlora hela rack / serviceenheter utan att behöva omedelbart vidta åtgärder. |
| Apparatstöd | 1 enhet för varje enkel app. 4 enheter för alla komplexa app som personalen förväntas vara avancerade användare. Initial distribution av appar är vanligtvis tidskrävande. När ett stort antal program distribueras måste redogöra för den tid det tar personal att sammanhang switch / ”swap I” information. |
| enkla nätverkstjänster | 1 enhet för varje två grundläggande tjänster: httpd, DNS, mail, printing, SAMBA, etc. Lägg till 2 enheter om du vill att de ska ha bättre än 99,8% tillgänglighet. Lägg till 2 enhet om du bryr dig om säkerhet. Lägg till 1 enhet om du skalar större än genomsnittet. Lägg till 4 om du skalar till mega storlek och är bortom vad Programvaran var avsedd för. Om du är helt bortom skalan, behandla ett utvecklingsprojekt och personal i enlighet med ingenjörer. |
| komplexa nätverkstjänster | mycket varierande. Till exempel kan multi-terabyte databas som används för data mining lätt konsumera flera DBA + flera ledande systemadministratörer som är specialiserade på prestanda tuning och storskaliga lagringssystem. |
| nätverksanslutning | skalor mot antal nätverksenheter, antal nätverk, säkerhetsproblem, komplexitet routing, HA krav. |
| samordning och ledning | ju större och mer komplex en organisation är, desto mer behövs samordningsroller. Människor som fokuserar på mänsklig ledning, systemarkitektur, programhantering, Projektledning. Detta är ganska komplicerat. Det skulle vara förmätet att föreslå ett förhållande. |
en solid SAGE II-systemadministratör kan hantera 4 arbetsenheter. En stark SAGE III-systemadministratör kan hantera 8 arbetsenheter. En överlägsen SAGE IV-systemadministratör kan hantera 12 arbetsenheter. Det finns några sällsynta individer som har både djup och bred erfarenhet, är ur lådan tänkare, hög EQ, och otroligt fokuserad och produktion. Medan de inte skalar mot mänskliga uppgifter som slutanvändarstöd bättre än en SAGE IV-nivå, skalar de betydligt bättre på det tekniska / systemarbetet. Detta är relaterat till lore att det finns några utvecklare som är 10x bättre än en ”normal” Utvecklare. Under min karriär har jag haft nöjet att arbeta med flera av dessa exceptionella artister. Detta räkningssystem är löst baserat på en ekvation som föreslagits av Sherwood Botsford och finns i komp.Unix.admin FAQ. En viss punkt kommer jag att uppdatera räkningen för att använda min Sre Skill Matrix (excel).
andra problem
webbplats med en administratör är inte särskilt önskvärda.
de är ett faktum eftersom många små webbplatser varken har råd eller motiverar mer än en systemadministratör. Det är svårt för en person att ha bredden av kunskap och erfarenhet att driva en riktigt förstklassig webbplats, oavsett hur få maskiner den har. Det kommer alltid att finnas något område som inte är styrkan hos en enda administratör.
ett annat problem är att webbplatsen med en enda systemadministratör har en enda felpunkt: när administratören är på semester (eller körs över av en buss) är webbplatsen sårbar. Carrying a pager on vacation är inte det jag tycker är kul; no one can predict when a crisis might occur. Det är självklart svårt att intressera en person på hög nivå i ett jobb som också innebär att man byter backupband och kryper genom taken.
ju mer homogen en webbplats är, desto lättare är det att stödja.
antalet olika plattformar som stöds (olika maskinarkitekturer eller olika operativsystem) ökar komplexiteten i supportuppgiften. Uppgradering av operativsystemet måste göras minst en gång för hand för varje plattform. Varje operativsystem har sina egna egenheter som måste läras och behärskas. De flesta webbplatser vill att alla plattformar ska vara identiska så att deras användare kan sitta ner på någon av arbetsstationerna och få arbete gjort. Detta kräver att varje plattform har identiska verktyg, fönstersystem etc. Detta kan kraftigt öka mängden arbete administratören måste göra. I bästa fall innebär detta att kompilera program för varje plattform. I värsta fall handlar det om att porta programvara och slåss med leverantörslevererad programvara. Min personliga mardröm försöker stödja alla X11R4 (från MIT), DECwindows, OSF/Motif och Suns OpenWindows på tre olika plattformar.
större webbplatser kan utnyttja stordriftsfördelar.
stora webbplatser kan utöka sina administrationspersonal mindre snabbt än antalet användare (eller arbetsstationer) växer. Anledningen till detta är att när din personal blir större är det möjligt för människor att specialisera sig. Denna specialisering gör det möjligt för enskilda anställda att utveckla ett djup av expertis som gör det möjligt för dem att förstå alla problem på ett visst ämne och lösa snabbare vilka problem som uppstår.
för det andra kan större webbplatser utnyttja tidigare arbete. Den första installationen av en maskin eller programvara är alltid den svåraste. Den andra är lättare. När du har gjort 50 eller 100 installationer har du utvecklat automatiska skript och kan göra installationer i sömnen. Jag har sett stora platser på en 1: 100 administratör-till-maskin-förhållande där det gick ganska bra. Jag måste dock varna läsaren: denna typ av förhållande är endast möjlig med förstklassiga människor som arbetar i en noggrant konstruerad miljö med många hundratals användare. De flesta webbplatser kan inte få produktivt arbete med denna typ av förhållande. Denna typ av förhållande begränsar också den professionella tillväxten hos medlemmarna i systempersonalen eftersom de kommer att spendera större delen av sin tid med de dagliga frågorna och brandbekämpningen. Detta är synd eftersom en organisations mest värdefulla resurs är dess människor.
| ökad sa-effektivitet | minskad sa-effektivitet |
| Automation standarder (policy, arkitektur) effektiv övervakning vanliga verktyg Robust är säkerhet stram kontroll över vad som laddas på HW/SW-baslinjen redundans av kritiska tjänster separering av tjänster (single service machines) bra träningsprogram detaljerade katastrofåterställningsplaner, genom system System som inte kräver säkerhetskopior |
Diverse hårdvara baslinje diverse programvara baslinje lax är säkerhet liten eller ingen utbildning en personal som är reaktiv, inte proaktiv ad hoc-säkerhetskopior eller inga säkerhetskopior |
webbplatser med hög tillgänglighet kräver högre bemanning.
webbplats som måste vara mycket tillgänglig (t.ex. större än 99,9% serviceleverans) kommer att kräva en högre personalnivå. Anledningen till detta är att du behöver personer som kan svara nästan omedelbart på eventuella serviceproblem (t.ex. 24 7-täckning i 7, helst minst 2-personer som kan göra första och andra nivåupplösning och kunna eskalera till ämnesexperter). Du måste också ha flera personer för varje ämnesområde som snabbt kan diagnostisera och lösa komplexa problem.
Vad Sägs Om Andra Plattformar?
plattformen som stöds gör stor skillnad. Min erfarenhet är att stöd för Macintosh-och UNIX-samhällen tar ungefär samma bemanningsnivåer. Historiskt stöd för datorer som kör något Microsoft OS verkar kräva minst dubbelt bemanning och ger en lägre servicenivå. Sedan Windows XP behöver förhållandet inte vara så högt… men jag hittar fortfarande administrationsskalor bättre på UNIX än Windows.
andra människors förhållanden
under de senaste åren har det varit många människor som har pratat om de förhållanden som de tycker är rimliga. Det är vanligt att höra folk prata om personal / användarförhållanden på 1: 60 där det finns viss variation i befolkningen och mycket anpassat arbete och personal / användarförhållanden på 1:150 (eller högre) på platser som kan använda ”cookie cutter” – lösningar, t.ex. universitet med horder av studenter eller företag där människor använder datorer som ett verktyg snarare än att leta efter att förnya sig på de maskiner som administreras. En mer realistisk uppsättning förhållanden (baserat på bästa praxis inom området snarare än leverantörsvita sidor på TCO) var Mega Groups förbättra bemanningsförhållandena artikel. Det finns ett antal andra studier som har funnit att i den verkliga världen har de flesta organisationer inte kunnat stödja förhållanden större än 30:1. En Mitre-studie från 2000 föreslog att förhållandet är 47:1 +/- 17%. I en video om användare till tekniker förhållanden av Justin Nguyen ett basförhållande på 60:1 Var förslag, med ett antal faktorer som påverkar detta förhållande.
ett exempel på över uppblåsta siffror finns i bemanning for Technology Support, en vitbok för utbildningsinstitutioner. Tyvärr försöker dessa människor att tillämpa bemanningsförhållanden från MITs projekt Athena till resten av världen. Detta är felaktigt av tre skäl. För det första har de flesta webbplatser inte de sofistikerade verktygen som Athena hade. För det andra hade Athena människor som fick Athena att springa som inte fångades i sina förhållanden: studentvolontärer som gjorde mycket arbete och hård kärna systemprogrammerare som utvecklade verktyg som uppfyllde MIT: s krav. Slutligen är MITs användarpopulation inte en genomsnittlig användarpopulation.
David Cappuccio från Gartner-gruppen föreslog i sin artikel Know the Types: dimensionering av supportpersonal att det finns två förhållanden som du måste överväga. Det första förhållandet är personal till användare, ett försök att fånga den mänskliga delen av ekvationen. Detta förhållande tittar på hur många personer du behöver göra vad som ofta kallas Tier I, helpdesk eller användarsupport. Det andra förhållandet är antalet maskiner och delsystem per Personal, det vill säga att fånga hur många som behövs för att ta hand om den tekniska infrastrukturen. Medan jag gillar Davids ramverk tror jag att hans förhållanden är för höga för användarstöd och att han inte har lyckats fånga de olika teknikerna som de flesta organisationer distribuerar: det finns mycket mer än utskrifts -, fil -, webb-och databasservrar. Det finns katalog, säkerhet, meddelanden och samarbetstjänster. För att komplicera saker, många webbplatser är heterogena kräver extra ansträngningar för att göra en tjänst arbete för alla kunder, eller ännu värre, vilket resulterar i behovet tjänster som är baserade på klientplattformen. En sista komplicerande faktor är att dessa tjänster ofta har komplexa interaktioner och beroenden som gör dem svårare att distribuera och underhålla. Resultatet är att Davids nyckeltal kommer att resultera i bemanning som kommer att kunna leverera endast de mest grundläggande tjänsterna på en adekvat nivå.
itbenchmark-bloggen har ett antal inlägg om ämnet personalstorlek.
slutsats
antalet administratörer som krävs varierar mycket från plats till plats. Den enda konstanten är att det sällan finns tillräckligt med systemadministratörer för det ansvar de har. När detta ursprungligen skrevs fann jag att det var möjligt för en enda person att underhålla upp till 220 maskiner (med tre olika plattformar) och ge adekvata användartjänster till en ganska sofistikerad användarpopulation på cirka 80 personer. Min tid är uppdelad mellan användartjänster (30 procent), allmänna systemadministrationsuppgifter (20 procent), installation av nya maskiner och hårdvara/nätverksstöd (10 procent), installation och underhåll av programvara (30 procent), Anpassad mjukvaruutveckling och spårning av trender (35 procent) och webbplatsplanering (10 procent). Du kommer att notera att detta ger upp till 135 procent.
historik för detta inlägg
1991 skrev jag en anteckning till Usenet som svarade på en fråga om bemanningsförhållanden. Rob Kostad bad mig att utöka den korta noten till en artikel som sprang med titeln ” Hur många administratörer räcker?”i tidningen Unix Review, April 1991. Under åren har jag gjort några, mestadels mindre uppdateringar av den ursprungliga artikeln. En av dessa dagar kommer jag att skriva om det helt. Medan den här artikeln skrevs för länge sedan, tycker jag att förhållandena fortfarande är ganska korrekta. Om du tror att jag har fel, skicka mig mail med dina erfarenheter.