Video: How to Join Multiplayer Servers in Minecraft Pocket Edition (November 2024)
Ik heb nog nooit een gedeeld netwerkstation ontmoet in een bedrijf dat op zijn minst een beetje slordig was. Gedeelde servers zijn meestal ontworpen om samenwerking mogelijk te maken en om bestanden en informatie vrij beschikbaar te maken voor onze medewerkers. Ze helpen bedrijven ook bij het gemakkelijk en efficiënt vastleggen en back-uppen van gegevens - in theorie dus.
In werkelijkheid veranderen ze in de plaats waar foto's van het bedrijfsfeest van zes jaar geleden worden opgeslagen. In die laatste zin gebruikte ik de passieve stem opzettelijk omdat niemand de verantwoordelijkheid lijkt te nemen om iets op een gedeelde schijf te zetten die er niet zou moeten zijn. Dingen verschijnen gewoon. Niemand weet hoe of waarom ze daar zijn gekomen. En daarom verwijdert niemand ze uit angst om op de tenen van iemand anders te stappen of iets te verwijderen dat iemand anders nodig heeft.
Gedeelde ruimtes moeten worden ontworpen op een manier die overeenkomt met de workflow of het organigram van een afdeling of bedrijf. Dingen die parallel van aard zijn, zoals twee teams die rapporteren op hetzelfde managementniveau, moeten parallel zijn in de mappenstructuur. Wanneer een nieuwe persoon bij een afdeling komt, moet hij of zij snel kunnen achterhalen waar belangrijke bestanden op een gedeeld netwerk wonen, omdat hun locatie (mapnaam en hoe het in andere mappen is genest) moet weerspiegelen hoe het bedrijf is ontworpen. Een echte rode vlag is wanneer iemand die lange tijd heeft gewerkt, geen dingen kan vinden omdat ze niet weten waar het is, of erger nog, zelfs niet weten waar het zou moeten zijn.
Hier is alles wat we hebben gedaan, stap voor stap, om onze slordige servers op te ruimen. Aan het einde vindt u een samenvatting van de resultaten, evenals opmerkingen over wat goed ging en wat fout ging.
Het serveropruimproject
Stap 1: Communiceer. Eerst hebben we gesproken over het probleem van een slordige server, inclusief waarom het een probleem is (inefficiënties, inconsistenties, onze netwerkruimte belasten), mogelijke oplossingen en procedures voor het implementeren van die oplossingen.
Toen hebben we nog wat gepraat. Toen spraken we over met wie we nog meer moesten praten. Ik kan niet genoeg naar huis rijden het belang van communicatie voor het succes van dit project. We hebben veel gepraat, zowel persoonlijk als via e-mail.
Tijdens die gesprekken realiseerden we ons hoe belangrijk het zou zijn om ook met het IT-personeel te communiceren. Dus hebben we ze opgenomen in ons plan en voorgestelde tijdlijn. Het IT-team gaf ons een cruciaal advies dat uiteindelijk ons echte startpunt voor het project werd. Ze zeiden: probeer niet op te ruimen wat je hebt; begin liever met een leeg canvas en maak de gewenste mapstructuren en kopieer alleen bestanden die u wilt behouden. Al het andere, zeiden ze, zouden ze archiveren.
Stap 2: Controleer bestaande gegevens. Ten tweede gingen alle belanghebbenden - vooral teammanagers - aan tafel zitten met een laptop en een projector. We hebben verbinding gemaakt met de serverruimte in kwestie en hebben samen enkele van de bestaande bestanden bekeken, om er zeker van te zijn dat niemand een aantal bestanden over het hoofd heeft gezien die we moeten bewaren.
We hebben ook nagedacht over de bestaande gegevens in termen van hoe het onze huidige workflows wel of niet weerspiegelde. Gedeelde ruimtes worden meestal gebruikt om samen te werken. De structuur en namen van mappen moeten die workflow nauwkeurig weergeven om nuttig te zijn.
Veel van wat we op de servers hebben gevonden, was verschrikkelijk verouderd. Er waren mappen met namen voor werknemers die al jaren niet bij het bedrijf werkten. We hebben dossiers gevonden die teruggaan tot 2003. Er waren restanten van projecten die nooit van de grond kwamen. Niemand had dit nodig.
Stap 3: Breng de nieuwe structuur in kaart. Terwijl we nog steeds rond die tafel zaten, schetsten we de mappenstructuur waarvan we dachten dat die op zijn plaats zou moeten staan. Alle managers hadden een buy-in met betrekking tot het ontwerp, dat onze teamstructuur en workflow moest weerspiegelen. Dit is wat we hebben ontworpen, hoewel ik de namen generiek heb gemaakt, zodat ze logisch zijn voor iemand die niet vertrouwd is met de innerlijke werking van ons kantoor:
Op het hoogste niveau hebben we mappen voor elk team en speciale projecten of taken, evenals een map voor 'bronnen' die voor alle teams gelden.
Elk team heeft een subset van mappen: een paar die de workflow weergeven, een voor elk teamlid en extra mappen die zinvol zijn voor de behoeften van dat team. De submappen van mijn team zien er bijvoorbeeld als volgt uit:
We hebben onderstrepingstekens en cijfers gebruikt om onze workflowmappen bovenaan de structuur te plaatsen en in dezelfde volgorde te laten verschijnen waarin het werk plaatsvindt. De map met de naam "1_EDITING" is waar bestanden die klaar zijn om te worden bewerkt, blijven staan totdat de bewerking is voltooid. Daarna gaan ze naar "2_RTP" wat "klaar om te produceren" betekent - met andere woorden, het bewerken is voltooid en deze bestanden zijn klaar voor de volgende fase. Nadat een bestand is geproduceerd, moet het worden verplaatst naar "3_PRODUCED", wat in wezen ons levende archief wordt. Alles in die map kan in theorie worden gearchiveerd, dus we zullen altijd een cache van bestanden hebben waarvan we weten dat we die kunnen verwijderen als we ooit wat ruimte terug moeten krijgen.
Stap 4: regels maken. Zoals ik in het vorige gedeelte al heb uitgelegd, heeft elke map enkele regels waaraan moet worden voldaan wat wel en niet kan worden behandeld of hoe ze moeten worden gebruikt. Als iemand bijvoorbeeld foto's wil delen, moet hij deze in zijn of haar eigen map met dezelfde naam zetten. Op die manier is het duidelijk wie verantwoordelijk is voor de gegevens.
We hebben ook besproken of we bestanden hadden die voor meerdere teams toegankelijk moesten zijn (dat deden we en we hebben een map Resources voor hen gemaakt) en of informatie moet worden vergrendeld (ja: alles in de map Management Team).
Stap 5: zorg voor consistentie. Bij het ontwerpen van onze mappen en regels voor het gebruik ervan, zoeken we ook naar gebieden waar we consistent zouden kunnen en moeten zijn. Wanneer mapstructuren en workflows consistent kunnen (en moeten zijn), zorgt dit voor tijden van personeelstransities, zoals wanneer iemand het bedrijf verlaat, met zwangerschapsverlof gaat of onverwacht ziek is. Consistentie op een gedeelde serverruimte helpt iedereen in de organisatie om de staat van lopende projecten te achterhalen, evenals wat belangrijk is, welk werk al is voltooid, enzovoort.
Een vervolgproject (dat we nu net implementeren) is om ook een betere consistentie te creëren in onze conventies voor bestandsnamen. We besloten de implementatie van deze bestandsnaamwijziging uit te stellen totdat iedereen gewend was geraakt aan het gebruik van de nieuwe gedeelde mappen om niemand met teveel nieuwe informatie tegelijk te overbelasten.
Stap 6: Controleer nog een laatste keer bij alle belanghebbenden. Voordat we iets implementeerden, voerden we een laatste controle van het plan uit met elke stakeholder, inclusief een paar mensen die we oorspronkelijk niet dachten op te nemen, maar wiens namen naar voren kwamen in onze beoordeling van de bestaande gegevens. "Is dat niet het vakgebied van Arielle? We kunnen haar beter vragen wat zij denkt dat in dit gedeelte moet worden gedaan."
Stap 7: Voltooi en communiceer de tijdlijn. De laatste stappen waren om de tijdlijn te voltooien en vervolgens het project te starten. Dit waren de laatste puzzelstukjes:
- Beslis wanneer en hoe de informatie moet worden verspreid: stuur alle werknemers halverwege de week een e-mail over de nieuwe serverstructuur, regels en alle gerelateerde informatie, inclusief datums (zie volgende item).
- Stel datums in voor: wanneer mensen moeten kopiëren over de bestanden die ze willen bewaren (einde van de week); wanneer ze de nieuwe structuur moeten gaan gebruiken (in ons geval onmiddellijk na ontvangst van de e-mail); wanneer de oude server wordt afgesloten (we hebben het ze eind van de week verteld, maar in werkelijkheid hebben we deze deadline met een paar extra dagen opgevuld).
- Plan een paar e-mails met herinneringen voordat u de toegang tot de oude server daadwerkelijk afsluit.
- Laat IT de daadwerkelijke cutoff uitvoeren.
Resultaten serveropruiming
De e-mail die halverwege de week alle informatie over het serveropruimproject bevatte, ging op woensdag om 11:27 uur uit. Een paar mensen hadden brandende vragen, maar de antwoord-op-alles-thread werd om 11:57 uur stil. Dat betekent dat alle basisvragen binnen 30 minuten waren beantwoord.
Binnen mijn team bleef aanvullende verduidelijking over onze workflow bestaan, maar de laatste die ik heb is op dezelfde dag om 13.05 uur. Ongetwijfeld stelden enkele mensen aanvullende vragen zonder op alle te antwoorden, maar de meeste vragen werden binnen twee uur beantwoord.
In de loop van de volgende dagen hebben we de tijdlijn zonder problemen voltooid. Het IT-team heeft wat snel een rapport opgesteld waaruit blijkt dat we de totale gegevens met 76 procent hebben gereduceerd. De cijfers spreken voor zich.
Voordat
- Totale ruimte: 250 GB
- Aantal bestanden: 447, 249
- Aantal mappen: 36.773
Na
- Totale ruimte: 59, 2 GB
- Aantal bestanden: 58.624
- Aantal mappen: 2.962
Project Postmortem en Feedback
Een paar weken nadat we de servermigratie en -herstructurering hadden voltooid, vroeg ik de projectleider, managers en IT-netwerkbeheerders of ze feedback of postmortale opmerkingen hadden. Niemand deed dat. Het ging allemaal opmerkelijk soepel. Dit is wat de leidende IT-man te zeggen had:
"In de meer dan 10 jaar dat ik hier ben, is dit de eerste keer dat een afdelingsteam een project als dit uit eigen belang heeft ondernomen en het zo goed heeft uitgevoerd. Dit helpt zowel [de andere IT-netwerkbeheerder] als ik kan het netwerk beter onderhouden, en ik weet zeker dat het uw team helpt bij de workflow en organisatie. We hebben letterlijk verschillende generaties management gevraagd om mandaat te geven aan wat uw team op het basisniveau heeft bereikt, en het wordt zeer op prijs gesteld."
Vanuit mijn perspectief is er een ding dat ik wou dat we iets anders hadden gedaan. Ik wou dat we medewerkers in eerste instantie persoonlijk over het project hadden verteld in een snelle spontane vergadering, in plaats van via e-mail. E-mail is prima, en zeker, niemand houdt van vergaderingen, maar ik had het gevoel dat mensen zich meer betrokken zouden voelen bij het proces als ze dit tijdens een open discussie hadden gehoord dan via een "BELANGRIJK!" e-mail.
We hebben nu een betere, consistentere, efficiëntere en eenvoudiger gedeelde server. De regels voor het gebruik ervan zijn duidelijk, met ingebouwde verantwoordelijkheid. Teammanagers zijn verantwoordelijk voor teammappen en individuen zijn verantwoordelijk voor wat zich in hun naammap bevindt.
Als u overweegt om uw eigen server-opschoonproject bij uw organisatie te initiëren, hoop ik dat u wat advies uit dit artikel kunt krijgen over het belang van advies van uw IT-afdeling, en in elk stadium grondig communiceren is cruciaal voor succes.
