Advertise on warmetal.nl!
Click for more information
about advertising here.

Did you find this website useful? Did I save you a lot of time?
Please consider donating to support this site:

 
Table of Contents

IT Fouten

40 fouten die een IT-er niet moet maken

Bron: Infoworld: http://www.infoworld.nl/web/Artikel/10-fouten-die-een-IT-er-niet-moet-maken-4.htm Waar gehakt wordt vallen spaanders en fouten maken is menselijk. Dat neemt niet weg dat lang niet iedereen zich fouten kan permitteren. Een vakkenvuller die een zak basterdsuiker in het verkeerde vak plaatst, komt daar waarschijnlijk beter mee weg dan een plastisch chirurg die u het verkeerde oor aan naait. Hetzelfde geldt voor de IT industrie, waarin fouten vaak grotere gevolgen hebben voor anderen dan voor uzelf. Niemand is perfect, maar het kan geen kwaad de meest gemaakte blunders op een rij te zetten, zodat u daar uw neus niet aan hoeft te stoten.

1. Verkeerd uitbesteden

Het uitbesteden van zaken op IT gebied kan u een hoop tijd en geld besparen, maar alleen als u dit efficiënt doet. Niet elke taak is geschikt om uit te besteden en een veelgemaakte fout is dan ook dat er taken worden uitbesteed om geen tijd te hoeven investeren in het leren begrijpen van die taken. Door dit soort taken uit te besteden kan het moeilijk worden kleine handelingen uit te voeren, omdat alles via een extern kanaal verloopt. Daarbij is er bij problemen niemand aanwezig binnen het bedrijf die daadwerkelijk een oplossing kan aandragen. Een andere grote fout is het niet uitbesteden van zaken die juist eenvoudig buiten het bedrijf kunnen worden uitgevoerd, waardoor er veel tijd en geld verloren gaat aan zaken die eenvoudig door een ander kunnen worden gedaan omdat dit hun specialisme is.

2. Te veel/ te weinig vertrouwen in open source

In de IT wereld heerst er vaak een zwart/wit cultuur, waarbij een bepaalde technologie of platform bijna heilig wordt verklaard, waarbij alles dat niet tot deze technologie of platform behoort wordt verguisd. Dit is met open source niet anders. Veel IT afdelingen zien open source als de grote nieuwe waarheid, die in alle opzichten beter is dan het traditionele systeem van commerciële software. Conservatieve IT afdelingen willen juist niets weten van open source, en richten zich volledig op betaalde software, omdat dat in hun ogen kwalitatief beter is, want, voor niets gaat de zon op. De waarheid ligt in het midden. Open source is niet per definitie beter dan commercieel en de afweging om voor één van de twee te kiezen moet per project worden gemaakt. Kiezen voor louter commercieel betekent het mislopen van kansen op het gebied van goedkope software als Linux, Apache, ~MySQL en PHP, en het focussen op alleen open source kan een project waar haast bij geboden is vertragen.

3. Offshoring met oogkleppen op

Bepaalde taken overdragen aan een bedrijf dat zich aan de andere kant van de Oceaan bevindt kan een goed idee zijn. Maar offshoring is niet altijd goedkoper; het succes hangt af van een groot aantal factoren. Zo is er het voorbeeld van een vice president bij een bedrijf dat een vestiging opende in India voor het ontwikkelen van software. De werkmentaliteit van de bevolking in India, waar tijd doorbrengen met familie erg belangrijk is, bleek echter aanzienlijk anders dan die in de Verenigde Staten. Werknemers waren niet bereid om nachten door te werken bij het naderen van een releasedatum en er waren voortdurend tripjes naar India noodzakelijk om alles goed te laten verlopen. Uiteindelijk bleek de hele operatie slechts 20 procent goedkoper dan wanneer het werk in de Verenigde Staten had plaatsgevonden, om nog maar niet te spreken over de energie die er in gestoken moest worden.

4. Interne beveiliging onderschatten

Als het gaat om beveiliging wordt er vaak gedacht aan beveiliging tegen gevaren van buitenaf. Maar in werkelijkheid blijkt uit onderzoek van Gartner dat maar liefst 70 procent van alle beveiligslekken die leiden tot winstverlies, een interne oorzaak hebben. Hoewel een groot deel van deze problemen niet op basis van kwade intenties geschiedt, is het uiteraard wel belangrijk om dit te voorkomen. Een ander onderzoek, van CERT, heeft aangetoond dat 87 procent van alle interne beveiligingsproblemen zijn ontstaan door het uitvoeren van simpele gebruikerscommando's, oftewel, zonder het installeren van geavanceerde software. Systeembeheerders dienen er op toe te zien dat gebruikers niet meer rechten krijgen dan zij nodig hebben en dat er voor speciale taken toestemming moet worden verleend.

5. Onvoldoende beveiliging op locatie

Ooit was het voldoende om beveiliging te bieden binnen een kantoor, maar tegenwoordig is dat allang niet meer zo. Met het groeiende aantal werknemers dat werkt vanaf locatie en het eveneens groeiende aantal draadloze hotspots, worden systeembeheerders verantwoordelijk voor het beveiligen van computers op netwerken waar zij niet zelf controle over hebben. Het inrichten van een firewall is dan niet meer voldoende. Een betere optie is het versleutelen van verkeer dat binnen het LAN plaatsvindt, om het netwerk te beschermen tegen indringers die het netwerk hebben weten te betreden via een onveilig draadloos access point.

6. Geen beveiliging voor draagbare apparaten

Waar bij desktops en laptops veel aandacht wordt besteed aan authenticatie via gebruikersnamen en wachtwoorden, wordt dit aspect bij draagbare apparaten nog wel eens overgeslagen. Een voorbeeld van het gevaar hiervan blijkt uit de ervaring van een durfinvesteerder die zijn Blackberry verloor op een zakenreis, terwijl hij bezig was met het sluiten van een belangrijke deal. De Blackberry was niet beveiligd met een wachtwoord, waardoor iedereen die het toestel vond de e-mails daarop kon lezen en informatie kon bemachtigen over de te sluiten deal, iets dat potentieel grote gevolgen zou kunnen hebben.

7. Verkeerde mensen promoveren

Het lijkt de gewoonste zaak van de wereld om mensen die goed functioneren op den duur in een hogere functie te plaatsen. Dit wil echter niet zeggen dat het altijd de juiste stap is om te nemen. Wanneer een techneut goed werk levert, en wordt gepromoveerd tot een managementfunctie, kan dit leiden tot onprettige situaties wanneer de persoon in kwestie het technische werk niet los kan laten en zich niet kan richten op het managen van mensen. Vaak is zo'n situatie niet terug te draaien omdat de oude vacature inmiddels vervuld is door een nieuwe werknemer, wat op den duur het verlies van een goede kracht kan betekenen.

8. Veranderingenbeleid negeren

Wanneer er aanpassingen moeten worden gedaan aan de systemen of de infrastructuur van een bedrijf, dan moet dit eerst goed in kaart worden gebracht en worden gecommuniceerd. Een kleine fout kan al snel leiden tot een miljoenenverlies, zoals de systeembeheerder van een computerfabrikant aan den lijven ondervond. Er moest een aantal dingen worden aangepast aan een reeks systemen tijdens routineonderhoud, hetgeen was besproken en akkoord was. De systeembeheerder, die te boek stond als vakkundig en secuur, besloot echter om ondertussen zonder overleg een upgrade uit te voeren van BIND (Berkeley Internet Name Domain). Uren later lag het hele bedrijf stil omdat de DNS niet functioneerde, hetgeen snel teruggedraaid kon worden, maar pas na uren weer leidde tot een werkende situaties. De fout kostte het bedrijf miljoenen. De conclusie die hieruit kan worden getrokken is dat zelfs een getalenteerde systeembeheerder nooit op eigen houtje mag opereren.

9. Verkeerd personeelsbeleid bij softwareontwikkeling

Vele handen maken licht werk, dat is een spreekwoord dat voor bijna iedere industrie opgaat. In de IT industrie is dit echter niet het geval. Onderzoek heeft uitgewezen dat één goede programmeur effectiever werkt dan een paar programmeurs die minder goed zijn in hun werk. Veel managers delen hun team echter nog steeds in op basis van het aantal mankrachten dat nodig lijkt te zijn om de klus te klaren. In werkelijkheid blijkt het echter veel functioneler om meer tijd en geld te steken in het zoeken van minder mensen met meer capaciteiten, omdat zij betere software zullen ontwikkelen in minder tijd.

10. Ontwikkelaars hun eigen kwaliteitscontroles laten doen

Het lijkt een logische conclusie dat het niet verstandig is wanneer ontwikkelaars van software hun eigen werk controleren op fouten. In de realiteit blijkt echter dat wanneer de tijd begint te dringen voor een project, toch snel wordt besloten dat ontwikkelaars hun eigen QA (quality Assurance) moeten uitvoeren. Dat dit rampzalige gevolgen kan hebben blijkt uit een voorbeeld waarbij een project vertraging had opgelopen. De programmeur moest zijn eigen QA doen om tijd te besparen, en een dag voor zijn vakantie liet hij weten dat alle bugs verholpen waren. Tijdens zijn reis ging echter alles mis en toen de programmeur op locatie arriveerde was het volledige systeem al onbruikbaar geworden. De bugs bleken grotendeels niet verholpen omdat de programmeur veel dingen over het hoofd had gezien tijdens zijn eigen QA.

11. Alleen ontwikkelen voor Internet Explorer

Ondanks het feit dat belangrijke applicaties steeds vaker worden uitgevoerd vanuit de internetbrowser en het feit dat Windows de zakelijke desktop nog altijd domineert, is het geen verstandige beslissing om alleen applicaties te ontwikkelen voor Internet Explorer. Los van de vraag of Internet Explorer een goede browser is of niet, is het simpelweg niet verstandig een applicatie te ontwikkelen die afhankelijk is van één andere applicatie. Wanneer er een situatie ontstaat waarin blijkt dat er op een bepaald moment of om een bepaalde reden beveiligingsrisico's ontstaan bij het gebruik van Internet Explorer in combinatie met jouw applicatie, betekent dit dat je met je rug tegen de muur staat als alleen IE ondersteund wordt. Bouw voor zo veel mogelijk verschillende browsers, zodat er altijd een alternatief is.

12. Vertrouwen op single netwerk performance

Met betrekking tot netwerkperformance kan worden gezegd dat er niet één graadmeter is waaraan de staat van het netwerk goed kan worden afgelezen. Volgens Douglas Smith, directeur van netwerkanalysebedrijf Network Instruments, is het fout te denken dat de staat waarin een netwerk verkeert kan worden bepaald met behulp van slechts één criterium. Er moet altijd gekeken worden naar meer aspecten, zoals port utilization, link utilization en client utilization. De enige correcte manier om een analyse van een netwerk te maken, is door overzicht te hebben, een stapje terug te doen en de gegevens te bekijken in de context van het bedrijf.

13. Meer bandbreedte bij netwerkproblemen

Een traag netwerk is één van de meest gehoorde klachten binnen de IT. Er wordt vaak op gereageerd door meer capaciteit toe te voegen en op die manier de bandbreedte te vergroten. In sommige gevallen een prima oplossing, maar in andere gevallen juist niet. Zonder een grondige analyse van het probleem, kan het vergroten van de capaciteit een dure en onverstandige beslissing zijn. Douglas Smith (uit punt 12) gebruikt dan ook vaak een motto om aan te tonen hoe onzinnig zo'n stap kan zijn: “Ik heb te weinig ruimte in mijn kast, dus ik koop een nieuw huis!”

De oorzaak van een traag netwerk ligt vaak niet in het gebrek aan capaciteit, maar aan ongewenst verkeer op het netwerk, bijvoorbeeld afkomstig van oude systemen of applicaties. Ook is het mogelijk dat applicaties verkeerd geconfigureerd zijn, waardoor er voortdurend pakketjes met gegevens over het netwerk gaan, die totaal geen functie hebben. Als voorbeeld haalt Smith het verhaal aan van een klant die een upgrade wilde uitvoeren omdat het systeem te traag was. Een network analyzer toonde echter aan dat de traagheid werd veroorzaakt door een beveiligingsapplicatie die elke dag om 3 uur een update draaide. Toen deze applicatie zo werd ingesteld dat de updates 's nachts werden gedraaid in plaats van 's middags, verbeterden de prestaties van het netwerk onmiddellijk.

14. Zwakke wachtwoorden toestaan

Als er wordt gesproken over veiligheidsrisico's, denken de meeste mensen meteen aan internetwormen en phishing als grote bedreigingen. Onderzoek heeft uitgewezen dat het grootste risico schuilt in de slordige omgang met wachtwoorden, of zelfs een totaal gebrek aan wachtwoorden. Administrator accounts worden te vaak voorzien van een zwak wachtwoord of van een wachtwoord dat vervolgens is opgeschreven op een Post-it die aan het beeldscherm hangt. Ook worden vaak wachtwoorden gebruikt die zijn gegenereerd met behulp van bekende algoritmen, waardoor ze eenvoudig te hacken zijn. De enige oplossing hiervoor is het invoeren van een strak beleid op het gebied van wachtwoorden, met documentatie waarin duidelijk wordt uitgelegd wat precies zwakke wachtwoorden zijn en wat een goede manier is om een wachtwoord te kiezen.

15. Wie het kleine niet eert…

Wie de leiding heeft over de IT afdeling van een bedrijf, heeft vaak te maken met grote en belangrijke beslissingen, waarmee veel geld gemoeid is. In zulke gevallen ontstaat vaak de situatie waarin schijnbaar minder belangrijke zaken blijven liggen. Dit kan een dure grap zijn, zoals The Washington Post ooit ontdekte. Er werd een domeinbetaling van 30 dollar over het hoofd gezien, waardoor het emailsysteem van de werknemers er uren uit lag. Pas toen de rekening was betaald, kon er verder worden gewerkt. Een domein is uiteraard maar een voorbeeld, maar u kunt zich voorstellen dat ook de grootste processen zo goed werken als de zwakste schakel en dat, wanneer deze schakel door achteloosheid wegvalt, de hele machine tot stilstand komt.

16. In het verleden behaalde resultaten…

…bieden geen garantie voor de toekomst. Dat een bepaalde oplossing op een bepaald moment bij een bepaald bedrijf leidde tot prima resultaten, wil niet zeggen dat diezelfde oplossing zal leiden tot dezelfde resultaten op een ander moment bij een ander bedrijf. Het is een veelgemaakte fout van IT managers: een nieuwe functie bij een nieuw bedrijf, en het forceren van een oplossing omdat die zich in het verleden elders heeft bewezen. Een voorbeeld hiervan komt van een VP of operations bij een groot bedrijf, die moest zorgen voor een nieuwe, goedkope open-source omgeving. De man had goede ervaringen met een LAMP architectuur (Linux, Apache, MySQL, PHP) en besloot dit opnieuw toe te passen. De oplossing bleek al snel totaal ongeschikt voor het bedrijf in kwestie, waarna er een geheel nieuw systeem moest worden geïnstalleerd dat wel bij het bedrijf paste.

Ervaringen uit het verleden zijn waardeloos in de IT, als het gaat om de toepasbaarheid in andere situaties. Ieder bedrijf werkt anders, iedere infrastructuur zit anders in elkaar, en dat betekent dat iedere situatie een eigen oplossing vereist.

17. Niet bijblijven

Op de hoogte blijven van nieuwe ontwikkelingen is natuurlijk van groot belang voor iedere industrie. Maar nergens is gebrek aan kennis zo riskant als in de IT, waarbij verzuimen bij te blijven kan leiden tot ernstige bedrijfsrisico's. Een klant van Network Instruments kreeg hier mee te maken. Het bedrijf installeerde een WLAN om te zorgen dat medewerkers in het magazijn hun werk beter konden doen. Het management van het bedrijf zag de toegang tot dat WLAN echter ook wel zitten en installeerde buiten systeembeheeer om extra draadloze toegangspunten. Omdat systeembeheer gebruik maakte van network analyzers, werden de ongeautoriseerde toegangspunten al snel ontdekt en konden er maatregelen worden genomen om het op een goede manier te regelen. Maar als de systeembeheerders niet zo alert waren geweest, of simpelweg niet op de hoogte van het feit dat de werknemers zichzelf toegang konden verschaffen, dan was er een levensgroot bedrijfsrisico ontstaan.

18. PHP onderschatten

IT managers die alleen maar kijken naar J2EE en .Net, voor de ontwikkeling van schaalbare internetapplicaties, maken een grote fout door niet ook andere programmeertalen te overwegen, met nadruk op PHP. PHP bestaat alweer bijna vijftien jaar en wordt op grote schaal ingezet voor zwaarbelaste sites en internetapplicaties. In 2004 wist de sociale netwerksite Friendster een enorme winst te boeken op het gebied van prestaties en snelheid, door over te stappen van J2EE naar PHP. Rasmus Lerdorf, de bedenker van PHP, plaatste naar aanleiding van de overstap van Friendster een bericht over het geheim achter de schaalbaarheid van PHP: “Schaalbaarheid wordt verkegen door een shared-nothing-architectuur te gebruiken, waarin je horizontaal oneindig kunt schalen. Een shared-nothing-architectuur houdt in dat ieder verzoek los van alle andere verzoeken in behandeling wordt genomen. Horizontaal schalen betekent simpelweg dat er meer plekken worden toegevoegd om verzoeken te verwerken.”

19. Het KISS principe negeren

IT gerelateerde zaken moeten als het even kan zo eenvoudig en overzichtelijk mogelijk worden gehouden. Oftewel, het KISS principe, dat staat voor Keep It Simple, Stupid. Volgens Douglas Pierce, technisch architect bij Datavantage, is het negeren van het KISS principe een terugkerend symptoon bij veel IT managers. Pierce heeft naar eigen zeggen honderden miljoen dollars verloren zien gaan bij de implementatie, het mislukken van de implementatie, en het trachten te onderhouden van onwerkbare systemen die te complex waren voor het probleem in kwestie. Volgens Pierce zijn complexe oplossingen wel degelijk nodig van tijd tot tijd, maar voor de meeste organisaties kunnen oplossingen veel simpeler. De architect zegt dan ook dat het negeren van het KISS principe verantwoordelijk is voor het mislukken van vele projecten en het onnodig opdrijven van de IT kosten. Ter illustratie parafraseert Pierce de Franse schrijver Antoine de Saint-Exupery: “Perfectie in ontwerp betekent niet dat je niets meer kunt toevoegen, maar dat je niets meer kunt wegnemen.”

20. Laten leiden door marketing

Bij IT producten als netwerkapparaten, databases, servers etc wordt vaak gebruik gemaakt van termen als 'enterprise' en 'workgroup', om aan te geven voor wat voor organisaties de betreffende producten bedoeld zijn. Dit is meer een kwestie van marketing dan een daadwerkelijke graadmeter voor de prestaties van dergelijke producten. Een product dat het etiket 'workgroup' draagt heeft doorgaans meer dan genoeg capaciteit om te functioneren in een 'enterprise' omgeving. Laat u niet misleiden door termen die een marketingafdeling koppelt aan bepaalde producten. Voer een uitgebreide analyse uit van wat u precies nodig hebt en welk product u dat kan bieden. In de meeste gevallen bent u dan veel goedkoper uit dan wanneer u zich laat leiden door het marketingperspectief.

21. Te streng wachtwoordbeleid

In de eerdere delen van deze artikelen hebben we al aangegeven hoe belangrijk het is er een strikt wachtwoordbeleid op na te houden. Dit heeft ook een keerzijde; er bestaat ook zoiets als een te streng wachtwoordbeleid. Als de vereisten voor het bedenken van een wachtwoord te ingewikkeld zijn en gebruikers deze wachtwoorden zo vaak moeten veranderen dat ze het niet kunnen onthouden, dan is de kans groot dat het wachtwoord wordt opgeschreven, waarmee het hele principe van het wachtwoord ongedaan wordt gemaakt. Houd het beleid met betrekking tot wachtwoorden strikt, maar reëel. Daarbij is het anno 2008 sowieso niet meer verstandig alleen te bouwen op wachtwoorden. Er zijn veel meer manieren voor authenticatie, die u prima met elkaar kunt combineren.

22. Het datacenter verkeerd beheren

Het mag geen geheim zijn dat de meeste systeembeheerders niet bekend staan om hun netheid en geordendheid. Het probleem is dat juist een systeembeheerder dat wel zou moeten zijn, zeker wanneer zo'n beheerder een datacenter onder zijn hoede heeft. Kabels die door de war liggen, racks die verkeerd gelabeld zijn en apparaten die totaal geen functie meer hebben, maar nog wel zijn aangesloten, kunnen leiden tot veel verwarring. Het kan de oorzaak zijn van het herconfigureren van de verkeerde server of het formatteren van de verkeerde schijf. Opgeruimd staat netjes en dat geldt dus met nadruk voor het datacenter.

23. Belangrijke IT zaken uit handen geven

Verantwoordelijke zaken die belangrijk zijn voor de voortgang van het bedrijf, zijn zaken die u niet uit handen moet geven, ook als u liever die verantwoordelijkheid niet draagt. Als het gaat om een auto, geeft u ook niet de sleutels aan uw bijrijder als u niet weet wat zijn of haar rijvaardigheden zijn. Hetzelfde geldt voor belangrijke IT zaken binnen het bedrijf. Management van het IT personeel is minstens zo belangrijk als het management van de IT infrastructuur en alle beslissingen moeten goed worden overwogen. Dat is een verantwoordelijkheid die u beter bij uzelf kunt houden – al was het maar omdat u uiteindelijk toch de persoon bent die de rommel op mag ruimen.

24. Legacy als een vies woord zien

We leven in een wereld waarin we altijd de beste, snelste en nieuwste systemen willen hebben. Oudere systemen beschouwen we al snel als afgedaan. Veel jonge techneuten ergeren zich dan ook aan het feit dat veel IT processen draaien op (in hun ogen) volledig verouderde systemen. Maar er is vaak een reden om oude vertrouwde systemen te gebruiken. Een oud systeem dat stabiel draait is veel minder riskant dan een nieuw en relatief onbekend systeem dat veel sneller is. Legacy is geen vies woord en zelfs als een van uw computers nog voor Willem van Oranje heeft gewerkt, is het goed twee keer na te denken voordat u hem vervangt. U hebt niets aan een snel en nieuw systeem dat onderuit gaat omdat het niet zo functioneert als u gewend bent.

25. De menselijke factor vergeten bij beveiliging

Systeembeheerders krijgen tegenwoordig te maken met een gigantisch aantal programma's, technologieën en protocollen, maar vergeten daarbij soms de menselijke factor. Zelfs het strengst beveiligde systeem is kwetsbaar als de gebruikers van het systeem deze beveiliging kunnen ondermijnen, bijvoorbeeld door wachtwoorden over de telefoon te noemen. Om precies die reden moet de educatie van gebruikers een belangrijk onderdeel zijn van het beveiligingsbeleid. Zorg ervoor dat gebruikers op de hoogte zijn van gevaren en risico's, en vooral hoe zij moeten reageren als zo'n dreiging zich openbaart.

26. Onmisbare werknemers creëren

Het heeft natuurlijk iets charmants, zo'n briljante medewerker die onmisbaar is en de hele afdeling op z'n schouders draagt. Maar zodra die onmisbare medewerker wegvalt, zit uw bedrijf met een groot probleem. Daarbij is het ook nog eens een beveiligingsrisico, zoals bleek toen Terry Childs, een werknemer in dienst van de stad San Francisco, het netwerk van de stad 'gijzelde' omdat hij de wachtwoorden niet vrij wilde geven. Daarbij is het voor de werknemer zelf ook nog eens niet wenselijk, omdat de 'goeroes' vaak worden overgeslagen wat promotie betreft, juist omdat ze zo onmisbaar zijn op hun huidige positie. Dat kan voor beide partijen frustrerende situaties opleveren.

27. Problemen aandragen in plaats van oplossingen

Systeembeheerders lopen vaak tegen een muur aan als ze een probleem voorleggen aan het management. Problemen worden vaak weggewuifd of het management reageert defensief. Reden hiervoor is dat u niet alleen problemen moet aandragen, maar ook direct de oplossing die u daarvoor voor ogen hebt. Het management wil zich doorgaans niet bezighouden met nadenken over dit soort problemen - daar hebben ze immers u voor aangenomen. Als u een probleem aandraagt met daarbij één of liever meerdere mogelijke oplossingen die tot in de puntjes zijn uitgewerkt, dan hoeft er alleen maar een keuze gemaakt te worden, waardoor er vaak veel sneller een beslissing valt. Tip: het is vooral erg handig ook aan te geven wat de mogelijke schade is (liefst in euro’s) als het probleem niet wordt verholpen.

28. Inloggen als administrator

Eén van de meest gemaakte fouten – en hij wordt ook in 2008 nog steeds gemaakt. Techneuten hebben vaak het recht in te loggen met het administrator account en doen dit doorgaans voor de meest triviale zaken. Gevaarlijk, want fouten maken is menselijk, en voor wie ingelogd is met een account dat alles kan en alles mag, zijn fouten extra gevaarlijk. In plaats van altijd inloggen als administrator is het veel handiger in te loggen met accounts met lagere privileges, zolang het werk dat toestaat. Mac OS X, Ubuntu en Windows Vista hebben dat al afgevangen door het account met de meeste privileges standaard uit te schakelen. Hierdoor moeten techneuten iedere keer wanneer zij een belangrijke taak uitvoeren, het administrator-wachtwoord invoeren. Dit werkt veel veiliger.

29. Vertrouwen op nieuwe technologieën

Er was een tijdperk waarin mensen zich het liefst verre hielden van de installatie van bèta-versies. Die tijd is veranderd; bèta's worden tegenwoordig massaal uitgebracht en geïnstalleerd. Dat is misschien leuk voor op de thuiscomputer, maar voor systemen waarop productie wordt gedraaid is dat zeer onverstandig. Hoewel systeembeheerders houden van innovatie en nieuwe technologieën, is het noodzaak die vernieuwingsdrang soms te temperen. Het is prima als u een early adopter bent voor uw desktop, maar in het datacenter dient u wat ouderwetser te zijn. Als het gaat om zulke belangrijke systemen, dan is de veilige vertrouwde weg altijd de beste. Houd de laatste ontwikkelingen in de gaten, maar implementeer deze pas wanneer ze uitvoerig en tot in den treure zijn getest. En zorg dat er ondersteuning is!

30. Het wiel opnieuw uitvinden

We zeiden het hierboven al: het is van groot belang dat u de verantwoordelijkheden voor belangrijke zaken bij uzelf houdt. Deze gedachte heeft als bij-effect dat systeembeheerders teveel tussen hun eigen oren doen als het aankomt op het bedenken van oplossingen. Hoewel u zelf verantwoordelijk bent voor handelingen binnen het bedrijf, hoeft u het wiel natuurlijk niet opnieuw uit te vinden. Als u het bedrijf online wilt krijgen, downloadt u een internetbrowser - die gaat u niet zelf programmeren. Dit zou ook moeten gelden voor andere applicaties. Teveel bedrijven besteden nog geld en tijd aan het programmeren van applicaties die allang beschikbaar zijn en vaak ook nog eens veel meer kunnen. Zorg dat zaken die niet uniek zijn voor uw bedrijf, worden afgehandeld door software die speciaal daarvoor geschreven is. Verspil er zelf geen tijd aan. Zo kunt u meer tijd en geld besteden aan zaken die wel uniek zijn en waar u in kunt uitblinken.

31. Geen zicht op mobiele gebruikers

Het is tegenwoordig veel makkelijker om updates te installeren via het netwerk dan vroeger, en ook voor het maken van backups van alle computers in het netwerk is dankzij speciale software geen universitaire graad meer nodig. Dat wordt anders wanneer een deel van de gebruikers niet altijd op het bedrijfsnetwerk werkt, maar thuis of op een andere manier mobiel.

De opkomst van thuiswerken heeft de regels van backuppen en beveiliging aanzienlijk veranderd. Verloren bestanden of gehackte computers kunnen uren werk ongedaan maken en veel geld kosten. Het is dus van groot belang het automatiseringsbeleid zo te ontwerpen dat ook de mobiele gebruiker daarin wordt meegenomen, zelfs al is het er maar één. Want ook van één medewerker kunnen bedrijfsgevoelige gegevens worden gestolen.

32. Geld verspillen aan compliance

Wanneer een bedrijf te maken krijgt met richtlijnen, zoals Sarbanes-Oxley, HIPAA enzovoorts, dan wordt er vaak teruggegrepen op de verbandmethode, oftewel gaten dichtlopen. Maar het is ontzettend zonde van het geld om veel te investeren in compliance die misschien voor uw bedrijf helemaal niet relevant is. Dat geld kan beter worden gestoken in zaken waar uw bedrijf wel baat bij heeft. Hoewel strikte regels soms noodzakelijk zijn om compliance fixes snel te kunnen uitvoeren, is een holistische aanpak vaak beter. Wanneer u uw compliance strategie aan het plannen bent, denk dan vooral in globale richtlijnen en procedures en niet enkel in gerichte oplossingen. Probeer het compliance proces te automatiseren, dat zal u veel geld schelen.

33. Schaalbaarheid onderschatten

Veel bedrijven denken dat ze goed ingericht zijn op schaalbaarheid, maar in werkelijkheid is dit vaak niet het geval, waardoor de groei van zo'n bedrijf enorm kan worden geremd. Het belangrijkste dat u in gedachten moet houden is dat ieder systeem zo betrouwbaar is als de zwakste schakel. Wanneer u bijvoorbeeld een automatisch proces hebt draaien, maar dit is afhankelijk van een ander proces waar een menselijke handeling voor nodig is, dan is dat een zwakke schakel en kunt u het systeem niet meer geautomatiseerd noemen.

Daarbij is een veelgemaakte fout dat bedrijven geld proberen te besparen door op een verkeerde manier te proberen efficiënt te zijn. Zo wordt er regelmatig een webserver, die tijdelijk niet wordt gebruikt, ingezet als bedrijfsdatabase, of wordt een actief werkstation ingezet als netwerk-opslagplaats. Dat zijn zaken die u moet proberen te voorkomen. Wanneer u groeit worden dit soort zaken een probleem, en als u eenmaal een groot bedrijf bent, zal het steeds moeilijker zijn dat soort problemen te verhelpen, omdat ze dan inmiddels een geïntegreerd onderdeel zijn van uw architectuur.

34. Verkeerde SaaS-strategie

SaaS (software as a service) wordt door veel bedrijven onderschat, wat zonde is omdat er veel geld kan worden bespaard. Steeds meer softwarebedrijven bieden hun producten aan als hosted services en dat kan u een hoop werk uit handen nemen, en daarmee veel geld besparen.

Aan de andere kant is teveel vertrouwen in SaaS ook weer niet goed voor uw bedrijf. U moet zich realiseren dat SaaS een businessmodel is en niet per definitie een garantie voor goede software. Hosted services zijn niet zo onderling compatibel als desktop software, en ze zijn ook minder goed aan te passen aan uw eigen wensen. Het is, zoals met alles, een kwestie van afwegen wat belangrijk is voor uw bedrijf, waarna u een keuze kunt maken welke software u aanschaft en welke u inzet als SaaS.

35. Code niet analyseren

Wanneer er een programma wordt geschreven dat niet goed werkt, wijzen de programmeurs vaak naar een fout in de onderliggende programmeertaal. Hoewel dat soms daadwerkelijk het geval is, gaat het negen van de tien keer om slecht ontworpen algoritmen, inefficiënte storage calls en andere programmeerfouten.

In plaats van direct een schuldige aan te wijzen, is het veel verstandiger gewoon uit te zoeken waar de problemen zitten, door de code te analyseren. Zo heeft het bijvoorbeeld geen zin bepaalde delen van een code te optimaliseren als u niet weet wat het deel is dat de uitvoering van de code het meest vertraagd. Wederom een kwestie van de zwakste schakel opsporen. Het grote voordeel is: als u ontdekt dat uw code niet optimaal werkt doordat er inderdaad een probleem is met de programmeertaal, dan kunt u dit probleem openbaar maken, waarna u het zelf niet hoeft te verhelpen.

36. Niet virtualiseren

Er zijn nog veel bedrijven die (vooral uit angst voor het onbekende) niet profiteren van de voordelen van virtualisatie. Zonde, want virtualisatie levert vaak grote voordelen op, met betrekkelijk weinig of zelfs geen kosten.

Door verschillende virtuele machines op één systeem te installeren, is het systeem breder inzetbaar, waardoor u meer profijt hebt van de investeringen die u doet in uw hardware. Virtualisatie zorgt er ook voor dat u nieuwe systemen eenvoudig kunt configureren en dat u testsituaties kunt creëren voor nieuwe software of instellingen. Er zijn verschillende fabrikanten die aangeven dat hun producten niet gebruikt kunnen worden in een omgeving waarin virtualisatie wordt gebruikt. Breek in zo'n geval met zo'n fabrikant, want het is een belangrijke technologie die steeds meer deel uit zal maken van onze toekomst en het is zaak dat u werkt met partners die dat inzien.

37. Teveel vertrouwen op één aanbieder

Het is heel begrijpelijk dat veel bedrijven graag samenwerken met partners waar ze goede ervaringen mee hebben. Het onderbrengen van producten en diensten bij één partner is ook erg overzichtelijk. Aanbieders van totaaloplossingen spelen hier handig op in door producten en diensten aan te bieden als één oplossing, omdat er dan ook maar één plek is waar het mis kan gaan, waardoor een probleem snel verholpen zou moeten zijn.

In werkelijkheid bieden dit soort bedrijven hierdoor ook diensten aan die buiten hun kennisgebied liggen, waardoor een probleem ineens flink kan escaleren. Verschillende bedrijven hebben verschillende expertises als het om IT gaat. Het is belangrijk dat u producten en diensten afneemt van bedrijven die verstand hebben van wat ze doen. Tien van dat soort partijen zijn in dat opzicht dan veel beter en betrouwbaarder dan één bedrijf.

38. Mislukte projecten voortzetten

Het is een feit dat niet ieder IT initiatief op een succes uitdraait. Het is daarom belangrijk op tijd aan de bel te trekken wanneer er iets dreigt te mislukken en het lef te hebben knopen door te hakken. Veel te vaak wordt er veel te lang gewerkt aan projecten waarvan eigenlijk al lang duidelijk was dat ze zouden mislukken. Hierdoor wordt onnodig veel geld verspild.

Een voorbeeld hiervan is het Virtual Case File (VCF) systeem dat de FBI trachtte te realiseren. Het project heeft minstens 100 miljoen dollar gekost, terwijl deelnemers aan het project al in de beginfase aangaven dat er onoplosbare problemen waren opgetreden. In 2005 werd de stekker uit het project getrokken, waarmee de 100 miljoen in rook is opgegaan.

U kunt niet altijd voorkomen dat projecten mislukken, maar stel wel van tevoren voor uzelf vast wanneer u niet langer bereid bent te investeren.

39. Energieverbruik negeren

As er gesproken wordt over energiezuinige manieren om de IT architectuur van uw bedrijf vorm te geven, dan is dat niet alleen maar bedoeld om het milieu te sparen. Veel bedrijven realiseren zich niet dat energiekosten de pan uit kunnen rijzen wanneer een bedrijf groeit. Wacht niet met het nemen van maatregelen totdat uw datacenter z'n maximale capaciteit heeft bereikt, maar denk nu al na over manieren om uw energieverbruik terug te brengen.

Als het gaat om de aankoop van nieuwe hardware, dan is die energieoverweging bij ieder onderdeel van belang, van processors, tot opslag en geheugen. Probeer ook verder te denken dan hardware. Misschien is SaaS wel de oplossing om uw energieverbruik terug te brengen. Daarmee redt u dus niet alleen de planeet, maar ook uw bedrijf.

40. Onrealistische doelen stellen

Als u een IT project plant, kan het gebeuren dat uw enthousiasme en grenzeloos vertrouwen in uw personeel uiteindelijk een probleem gaan vormen. Wanneer u in alle oprechtheid een te optimistische planning hebt gemaakt, dan kan dat leiden tot een flinke deceptie zodra de deadline niet haalbaar blijkt. Zorg dat er altijd genoeg tijd is om een doel te bereiken, zelfs al lijkt het simpel. U kunt beter teveel tijd inplannen dan te weinig. En plan fouten en vertragingen alvast in, dan kan het alleen maar meevallen.

Discussion

Enter your comment:
 
itfouten.txt · Last modified: 2010/04/02 20:20 (external edit)