Web-Consultant-Log

Normaliter houd ik mij als web consultant bezig met websites, FTP en andere webdiensten. Omdat ik vóór mijn functie als web consultant bij hetzelfde bedrijf als business analyst werkte, word ik af en toe ook nog wel gevraagd om een uitstapje naar een ander onderwerp te maken. Een paar weken geleden werd ik op dezelfde manier gevraagd om "Supply beheerder" voor narrowcasting te worden. Dit houdt min of meer in dat ik een paar uur per week mezelf ga bezig houden met het oplossen van problemen om ons narrowcasting systeem. (narrowcasting is het tonen van berichten op beeldschermen, zoals nieuwsberichten bij ons bedrijf, maar ook reisinformatie op luchthavens etc).

Er is ruim een jaar geleden een systeem voor narrowcasting aangeschaft door onze communicatie afdeling en geïmplementeerd door een facilitaire partner. Er zijn dus drie partijen betrokken: de leverancier van de soft-en hardware, de facilitaire partner die alle configuratie en installatie doet, en ons bedrijf; de klant.In het begin waren er ogenschijnlijk geen problemen met het systeem, totdat het aantal locaties en het aantal beeldschermen enorm ging toenemen. Pas toen werd de afdeling ICT geïnformeerd en om hulp gevraagd. Nu is door de bomen het bos nauwelijks meer te zien en staat ons een grote klus te wachten. Het grootste gedeelte van de schermen zenden namelijk niet betrouwbaar uit. Soms geeft een scherm helemaal geen beeld en af en toe staat er een error melding op display. Ook klagen gebruikers over ongebruiksvriendelijke software voor het maken van de presentaties die op de schermen moet komen en zeer trage verbindingen. Er is bij de start geen goede training geweest en de facilitair partner lijkt niet genoeg expertise in huis te hebben. Ook is er zeer weinig gedocumenteerd tijdens de implementatie en is er dus niet veel bekend over hoe het hele systeem in elkaar zit.

Wat bekend is, is dat er één centrale server is waar alle presentaties op worden gezet via een software-pakket op de PC van de gebruiker. Deze server staat in verbinding met 14 subservers op de verschillende bedrijfslocaties. Elke subserver staat in verbinding met één of meerdere viewer-PC's. De schermen die de presentatie tonen, halen die van één van deze viewer-PC's. Op 4 locaties zitten er echter geen subservers tussen de centrale server en de viewer-PC's.
Een presentatie wordt dus gemaakt op de PC van een gebruiker, verzonden naar de centrale server (of via verbinding direct op de server gemaakt; is niet zeker), dan naar de subserver gestuurd en de viewer-PC's streamen die presentatie dan weer van die subservers op de verschillende beeldschermen.

Dit betekent dat alle presentaties die gemaakt worden dus op de centrale server terecht komen. Voor de meeste locaties is het echter niet nodig om alle presentaties van alle locaties ook op de subserver te hebben staan, omdat die helemaal niet getoond hoeven te worden. Nu worden ze wel telkens over de lijn gepompt, wat niet alle verbindingen even goed aan kunnen. Dan zijn er nog meer verbindingsproblemen mbt afbeeldingen en video's in presentaties. Deze worden namelijk in een map op de centrale server geplaatst, maar niet altijd overgeplaatst naar de subserver, waardoor die onderdelen van de presentatie dus gestreamd moeten worden zodra deze in beeld komen. Hierdoor gaat er telkens data over de lijn van de centrale server, waardoor het synchroniseren van nieuwe presentaties af en toe mis gaat.

Zo zijn er nog wat grotere en kleinere problemen en vast nog een heleboel die we nu nog niet in beeld hebben (want geen goede documentatie). Aan mij en het project team nu de taak om alle problemen in beeld te krijgen en deze goed aan te pakken. Ik ga overmorgen naar de ISE beurs in Amsterdam waar onze leverancier (en heel wat andere leveranciers) aanwezig is, om even "hallo" te zeggen en kijken hoe ze ervoor staan. Ook leuk om even te kijken wat er allemaal nog meer op de markt is natuurlijk. Volgende week hebben we onze eerste vergadering met de leverancier en de facilitaire partner om de problemen te bespreken.

De planning is nu om binnen 3 maanden de huidige oplossing op een goed werkbaar niveau te krijgen en daarna te kijken of we deze nog verder kunnen/willen verbeteren, of dat we een andere oplossing of partnerconstructie voor onze narrowcasting kiezen. Uiteindelijk hoeft het allemaal niet zo moeilijk te zijn natuurlijk, maar als iets klein is begonnen en daar is zonder echte supervisie vanuit ICT veel op uitgebreid, kan het al snel verkeerd gaan. Ik vind het in ieder geval leuk om me met veel verschillende onderwerpen bezig te houden op mijn werk en neem de uitdaging dus gretig aan

Dit gaat niet over een gesprek over salade, maar over mijn maandelijks Service Level Agreement gesprek met onze web design en hosting partner. Dit gesprek vind ik elke maand heel leuk om te doen, omdat er een goede dynamiek is tussen alle betrokkenen. Met z'n vijven bespreken we de actiepunten en prestaties van de afgelopen maand; mijn manager, onze interne hosting beheerder, service manager van de hosting partij, service manager van web design partij en mijzelf. Normaal is hier ook nog de projectmanager van een grote web-applicatie bij, maar die was deze keer niet aanwezig.

De meeting begint met de actielijst. Zaken die vorige maand zijn afgesproken komen ter sprake, om de voortgang van deze punten te bespreken. Ook lang lopende problemen en acties staan op de lijst incl. de verantwoordelijke partij(en). Voorbeelden van actiepunten zijn:

• De SQL server in de acceptatie-omgeving zit bijna tegen de max van het geheugen. Deze moet opgeschoond worden en/of extra geheugen bijgeplaatst
• De migratie van domeinnamen en DNS loopt, maar hiermee wordt gewacht tot de migratie van het datacenter compleet is
• Uit monitoring blijkt dat twee websites stukken slechter presteren qua bereikbaarheid dan anderen. Oorzaak onderzoeken en evt direct actie ondernemen

Nadat we alle actiepunten hadden besproken (dit waren er een stuk of 12 totaal), konden er 5 op gereed gezet worden. Goed nieuws dus

Na de actielijst komt de SLA rapportage van de hosting partij: er zijn geen bijzonderheden en de servers zijn in de maand december 100% beschikbaar geweest. Ik word nog wel even op mijn vingers getikt omdat ik voor aanvragen van changes (bijv in DNS) direct naar hun helpdesk bel, terwijl het afgesproken proces loopt via de web design partij. Mijn manager reageert nonchalant en als het voor hem geen probleem is, maak ik me er ook niet druk over.

Als laatste onderwerp van de meeting bespreken we de SLA rapportage van de web design partij. Hierin wordt vooral gekeken naar de reactie- en oplostijd voor vragen, changes en bugs. Deze zijn ingedeeld in prioriteiten en per prioriteit gelden andere tijden. Ditmaal hebben ze voor de laagste prioriteit 93% van de keren binnen de afgesproken tijd gehandeld. Voor de hogere prioriteiten is dit 100%. Niet slecht dus. Verder zijn er nog wat langlopende changes die worden besproken. Het is namelijk nog wel eens zo dat ze zaken op 'resolved' zetten wanneer ze het niet binnen de SLA-tijd kunnen oplossen. Op deze manier zie je dat niet in de rapportage, maar dat is dus eigenlijk ook niet de bedoeling. In dit geval gaat het voornamelijk over het implementeren van de Google Analytics code in bestaande websites die lang op zich laat wachten.

Verder waren er in de maand december geen grote problemen met websites, dus we zijn ruim binnen de afgesproken tijd klaar met het gesprek. Aan mij dan nog de taak om de actielijst te updaten en dan zien we elkaar over maand weer in dezelfde opstelling.

Wij hebben binnen ons bedrijf ruim 1.500 domeinnamen (die bij ons bekend zijn) geregistreerd. De meeste van deze domeinen hebben geen website, maar dienen slechts als redirect. Het is verdomd lastig om daar een overzicht van te krijgen, maar meestal is er gelukkig niets aan de hand, want het verandert niet zo heel vaak. Echter, binnenkort gaan wij onze domeinnaam registrar wijzigen én onze hostingomgeving wordt gemigreerd naar een nieuwe partij. Hiervoor willen we graag inzichtelijk krijgen welke sites waarnaartoe verwijzen, want de locatie van de sites waarnaar verwezen wordt wijzigt (andere hosting-partij dus andere servers dus ander IP-adres).

Nu is het nog redelijk gemakkelijk om te achterhalen of een site alleen een redirect is of niet. Het is echter een stuk moeilijk te achterhalen hoe een redirect is geregeld; dat kan namelijk op een paar verschillende plaatsen gedaan worden (bijv. in de zone file op de DNS (A-record of CNAME), in IIS, in het CMS of in de Host File). Om een redirect te kunnen wijzigen, moeten we weten wáár we dat moeten wijzigen. Dat is een redelijke klus, vooral omdat al die zaken niet bij één partij liggen.

Wat we ook graag willen doen voordat we overgaan naar de nieuwe domeinnaam registrar, is de grote hoeveelheid domeinen enigszins opschonen. Dit houdt echter in, dat we aan alle site-eigenaren moet vragen wat ze met hun redirects willen in de nabije toekomst. Er zitten ook redelijk wat redirects tussen die niet meer kloppen of gewoon niet meer werken. Dan willen we wel weten of die domeinnaam mag verlopen of dat die redirect gefixt moet worden, want bij de overstap naar het andere bedrijf, wordt elke domeinnaam met 2 jaar verlengd.

Deze klus bestaat uit het achterhalen van de contactpersonen voor elke website (dat is een stuk moeilijker dan dat het misschien klinkt) en afspraken maken met die site-eigenaren om alle redirects te evalueren. Eigenlijk wil ik dan voor elke individuele redirect weten: "klopt het nog zoals het er nu staat en zo niet, wat moet er mee gebeuren?".

Als start heb ik binnenkort een afspraak met de eigenaar van onze corporate website; hiernaar verwijzen 167 domeinen. Ik zal in de komende weken ook afspraken moeten maken met de kleinere websites om hun redirect-beleid onder de loep te nemen. Op zich een hele leuke klus, maar wel een enorm karwei

Het geeft mij de kans om mezelf binnen de organisatie te profileren, aangezien nog niet elk merk (of afdeling, if you will) bekend is met wat de web consultant doet in het bedrijf. Bovendien kan ik dan ook het centrale platform promoten, want het is natuurlijk veel gemakkelijker om alle sites te managen, als ze allemaal op hetzelfde platform draaien en bij dezelfde partij gehost worden. Dat is nu voor ongeveer 50% het geval en de rest is verdeeld onder allerlei kleine of grote partijen.

Vrienden die me bijstaan bij deze klus zijn o.a. MS Excel, WhoIS lookup en Traceroute via DomainTools of Uptrends.

Er loopt bij mij op werk al een tijdje een interessant project waarbij ik als web consultant los betrokken ben. Het project is zo interessant omdat er veel uitzonderingen in voorkomen die potentieel veel problemen kunnen opleveren.

Het gaat om een nieuwe marketing campagne van een middelgroot consumentenmerk van ons. De marketingmanager van het merk (laten we haar Saartje noemen) heeft een idee bij een ontwikkelbureau neergelegd dat al een soortgelijke actie voor een ander merk van ons heeft gerealiseerd. Het gaat namelijk om een actie die wel wat weg heeft van Groupon (elke dag een unieke, relevante aanbieding) die wordt aangeboden via de website, mobiele website, iPhone app en Android app.

Het ontwikkelbureau kwam met een leuk voorstel dat er goed uit zag en het was bijna go-time. Toen kwam echter onze afdeling Inkoop achter de aanbesteding en zij hadden hier een duidelijke mening over: "dit is te veel geld om bij dat kleine bureau neer te leggen, omdat wij ook al voor een ander merk een groot aandeel hebben in de omzet van dit bureau. Dit is niet verantwoord en jullie zullen dit bij een ander bureau moeten neerleggen". Daar was Saartje (de marketingmanager, weet je nog?) niet zo blij mee, omdat ze daarmee de opgedane expertise zou verliezen die het bureau heeft met de actie die ze al hebben gedaan voor een collegamerk. Na enkele gesprekken met Saartje, Inkoop en mijzelf werd toen maar besloten om een deel van de activiteiten toch maar bij het bekende bureau neer te leggen, maar een ander deel elders te beleggen om de grootte van de aanbesteding te beperken. Deze compromis kwam voort uit het niet willen toegeven van beide partijen: Saartje die toch de expertise wilde behouden en het project niet in zijn geheel elders wilde leggen, en Inkoop die niet wilde zeggen: "okee, we zijn nu al zo ver met dit bureau. Laten we het voor deze keer maar door de vingers zien en ze het hele project gunnen".

Nu zijn we een paar maanden verder na het maken van deze beslissing en is er een tweede partij aangesloten bij het project. Er is een globale verdeling van werkzaamheden gemaakt, en de offerte is ook verdeeld over de twee partijen. De verdeling is gemaakt zodat 1/3 van het werk bij het nieuwe bureau ligt (voornamelijk de front-end, dus het uiterlijk van de website, apps etc) en 2/3 van het werk ligt bij het originele bureau (dus veelal back-end; databases, koppelingen, partnerbeheer voor de aanbiedingen, hosting etc.). Nu merk je echter dat het project langer gaat duren en meer gaat kosten, omdat er nadrukkelijker moet worden overlegd en gedocumenteerd wat er gaat gebeuren. Ook weet je dat er vrijwel onvermijdelijk problemen komen bij het opleveren van producten van het ene bureau naar het andere. Ik ben zeer benieuwd hoe het gaat lopen bij de ontwikkeling.

Op het moment wacht ik nog op een functioneel ontwerp en ik zou graag ook een technisch ontwerp ontvangen, maar of dit erin zit weet ik niet. Omdat mijn functie Web Consultant is heb ik hier een adviserende rol en er is toch wat meer begeleiding nodig vanuit ICT dan alleen advies. Daarom heb ik de betreffende ICT afdeling vandaag ingelicht (zij wisten nog helemaal niets van het hele project ) in de hoop dat zij er wat dichter bovenop kunnen gaan zitten.

Ik volg het project met spanning en hoge interesse, en hoop nog ergens van betekenis te kunnen zijn. Dat is echter moeilijk als je advies geeft dat inhoud dat het project misschien wel een stuk langer duurt omdat er meer voorbereiding nodig is. Ik zal het project ook hier op mijn blog opvolgen wanneer er nieuwe ontwikkeling zijn.

Ik hoop dat het verhaal nog te volgen was en dat het gematigd interessant is om te lezen . Mocht je geinteresseerd zijn, kun je me altijd vragen stellen!

Om maar gelijk inhoud te geven aan mijn Tweakblog, volgt hieronder een korte beschrijving van mijn huidige werkzaamheden. Ik zal in dit Tweakblog onderwerpen die met bepaalde projecten te maken hebben opschrijven en opvolgen wanneer ik kan. Ik laat echter de details weg, omdat ik betwijfel of mijn baas goedkeuring geeft aan publicatie van deze details.

Als web consultant ben ik voornamelijk bezig met het behandelen van vragen en problemen van gebruikers m.b.t. websites. Binnen ons bedrijf hebben we rond de 1.500 domeinen, 400 websites van zo'n 40 merken.

Op het moment is er een probleem dat een website niet bereikbaar is, omdat het domein is verlopen (facepalm!), waardoor een redirect moet worden ingesteld naar een andere website waar wel content op staat.

Verder is er een verzoek van een ander merk om Google Analytics te implementeren op hun website en heb ik in mijn 'master' analytics account dus hun website toegevoegd en aan de ontwikkelaar gevraagd om de code in de website te plaatsen.

Gisteren heb ik een overzicht gemaakt voor mijn manager, de afdelingsmanager en de CIO over wat er mogelijk is om binnen ons bedrijf IOS devices te gaan ondersteunen. Er is nu namelijk alleen ondersteuning voor Blackberry, maar er is nu eindelijk ook behoefte aan support voor iPad en iPhone. Hopelijk volgen later ook Android en Windows Phone. Deze week en volgende week heb ik gesprekken met partijen die deze support zouden kunnen verzorgen.

Onlangs hebben we website monitoring aangeschaft waardoor een aantal websites wordt gemonitord op beschikbaarheid. Elke 5 minuten wordt er vanuit een verschillende locatie een bezoeker gesimuleerd die de website opvraagt. Hierdoor krijgen we goed inzicht in welke websites goed presteren en waar de problemen liggen. De alerts die ik vanuit die dienst krijg zijn ook van grote waarde, omdat ik zo niet op bericht van de site eigenaar hoef te wachten om te weten dat ik wat moet gaan doen.

Ook zijn we bezig om een groot deel van onze websites naar een nieuw platform te migreren en onze webhosting omgeving wordt vernieuwd. Verder willen we in de nabije toekomst ook onze DNS partij wijzigen en tegelijk een analyse van de domeinnamen maken om te zorgen dat die zo efficient mogelijk worden gebruikt.

Er is dus genoeg werk aan de winkel en het is super om de veranderingen in het bedrijf te zien. Je ziet ook dat de buitenwereld heel snel ontwikkelt en dat een groot bedrijf het moeilijk bijhoudt omdat veranderingen daar nu eenmaal lang duren om door te voeren. Het is dus heel interessant om onderdeel te zijn van dat proces en er als klein radertje in het geheel ook wat invloed op uit te kunnen oefenen.