Gastpost: Continuïteit(svraagstuk) in de praktijk

| AE 5774 | Informatiemaatschappij | 9 reacties

webshop-closed-gesloten-geschlossen.pngDeze en volgende week ben ik met vakantie. Daarom vandaag een gastpost van Dennis Wijnberg, reageerder alhier en New Business Manager bij Fundaments B.V.

Ik werk voor een IaaS provider in het oosten van het land. Vroeger, toen servers nog op kantoor stonden, was het duidelijk (tenzij lease, koop op afstand of koop op afbetaling – welke variant hebben we eigenlijk?) van wie de data is. Maar dat is nu lastiger geworden. Daarbij hoop ik een kijkje te geven in onze dagelijkse praktijk. Onze business case bestaat uit bedrijven (eindklanten) die hun data buiten de deur willen plaatsen. Omdat wij IaaS leveren en veel van die klanten zelf geen (of te beperkte) IT-afdeling hebben zit daar vaak een systeembeheerclub tussen. Functioneel heel mooi, want zij hebben één aanspreekpunt en krijgen de factuur ook van één partij. Op de achtergrond neemt die systeembeheerclub het fundament weer bij ons af. Maar steeds vaker stelt de eindklant ‘wat als’-vragen. “Wat als de systeembeheerclub failliet gaat of er een bedreiging van de continuïteit optreedt?”

Allereerst: hulde. Het feit dat je ermee bezig bent is lovenswaardig, dat straalt een bepaalde professionaliteit uit. Of je er nu uiteindelijk voor kiest om er een oplossing voor te treffen (en wélke) hangt van veel factoren af: kans, impact, uitstraling, doorverkoopbaarheid, etc.

De eerste vraag die beantwoord moet worden is “Is er een probleem?” direct gevolgd door “Is het een probleem voor mij?”. De eerste vraag verdient een duidelijk bevestigend antwoord hoewel ik benieuwd ben naar de toetsing van deze constructie aan aan deze uitspraak van de rechter.

Over de tweede vraag kunnen we het hebben. Mijn antwoord is: Ja, omdat:

  • Wij de doorlevering kunnen (laten) doen als de systeembeheerder failliet gaat
  • <li>Wij ervoor kunnen zorgen dat die systeembeheerders (partners) hun diensten beter kunnen verkopen</li>
    
    <li>Wij hierin (samen met de partners) een stap extra kunnen zetten t.o.v. de concurrentie</li>
    
    <li>Wij ook ons geld krijgen als de systeembeheerder failliet gaat</li>
    
    <li>Aanvullingen?</li>
    

In de eerste zin komt gelijk doorlevering aan de orde. Als je dat wil doen, moet je ten eerste weten wát je door moet leveren en ten tweede zeker weten dat je het door mág leveren. Zoals genoemd leveren wij IaaS – computercapaciteit (gevirtualiseerd RAM, CPU, storage en netwerk) te beheren via het internet. Hoe weten wij dan wat er draait, voor welke klant? En dan hebben we het alleen nog maar over praktische zaken. Heeft de systeembeheerderclub zelf diensten toegevoegd? Zelfgebouwde software/scripts? Rusten daar rechten op? Is er documentatie? Waar? Van wie is die documentatie? Wie heeft die? Of, misschien nog praktischer: wanneer is er sprake van bedreiging van de continuïteit? Wie beslist dat?

Inderdaad; de jurist komt aan zet. Er moeten gesprekken gevoerd worden met alle drie de partijen. Er moet namelijk veel vragen worden beantwoord en dat moet worden verankerd in een overeenkomst. Daarbij gaat het niet alleen over dat het “zwart op wit staat”, maar ook dat het praktisch uitvoerbaar is. Je kan heel mooi met een papiertje staan te wapperen, maar als de curator een wanprestatie besluit te leveren, dan kun je zomaar alsnog hangen.

En dan komt het onvermijdelijke punt: de kosten van zo’n oplossing. Dat meten we natuurlijk deels aan de kant van kosten versus risico (kans * impact). Anderzijds; hoe erg zijn kosten als er inkomsten tegenover staan? Recentelijk had ik te maken met een eindklant met honderdduizenden betalende gebruikers. Dan je heb je ten eerste een bepaalde zorgplicht om dit sowieso goed te doen, maar ten tweede ook een verdienmodel. Als je nu elke gebruiker een cent per maand laat betalen. Een cent. Da’s heul weinig, toch? Dan verdien je bij 200.000 gebruikers € 2000,- per maand. Met een terugverdientijd van één jaar (je gaat immers voor de lange termijn, toch?) mogen je kosten dus op € 24.000 liggen, en dan ben je al een heel eind volgens mij.

Zelf doen met beperkte kennis van zaken (want dat is lekker goedkoop)? Dat verwijt jij jouw klanten toch ook?

Dennis Wijnberg is New Business Manager bij Fundaments B.V. In 2007 behaalde hij de trofee voor actiefste reageerder alhier.

Deel dit artikel

  1. Ik mis totaal wat jullie zelf hebben gedaan in het geval jullie in de problemen komen. Zo’n systeembeheerclub is vervangbaar, dat snapt een kind. Maar als jullie stroomrekening niet meer wordt betaald wordt het een ander verhaal.

    Ook kunnen jullie toeleveranciers nog in een zelfde situatie komen.

    Dus de hamvraag is, zijn er door jullie technische en juridische maatregelen genomen voor de situaties wanneer het bij jullie of een toeleverancier fout gaat? Dat is veel interessanter als wanneer je afnemer in de problemen komt, zoals je in bovenstaand stuk beschrijft.

    Is bijvoorbeeld het computercentrum in een stichting ondergebracht? Is een deel van de backbone bij een andere club neergezet? Maak je gebruik van provider-independent IP blocks?

    • Q: Is bijvoorbeeld het computercentrum in een stichting ondergebracht? A: Alle hardware en enkele verbindingen zijn ondergebracht in een separate BV.

      Q: Is een deel van de backbone bij een andere club neergezet? A: Wij spreiden onze productie over twee locaties (Hengelo + Enschede, ook separate aanbieders). Er worden (indien gewenst) replica’s gemaakt (over eigen verbinding) naar een derde locatie (Zwolle).

      Q: Maak je gebruik van provider-independent IP blocks? A: We zijn zelf RIPE-deelnemer. Indien gewenst kan de klant een PI-blok ‘krijgen’ als daar aan de RIPE-voorwaarden wordt voldaan.

  2. Tja, continuiteit… In het verleden heb ik wel eens gebruik gemaakt van de diensten van “shared hosting” om meer ervaring op te doen met web development. (Alweer 12 jaar geleden!) Dit ging twee jaar goed tot mijn experimentele website opeens besmet raakte door een virus. Meteen mijn site hersteld en POEF! De volgende dag weer besmet. Mijn site vervangen door een blanco index.html bestand en dag later? POEF! Besmet… Tja, het probleem was dus dat of de systeembeheerder of de provider van de infrastructuur last had van een besmetting en er eigenlijk geen aandacht aan gaf. Na enkele klachten hierover bij de beheerders kwam wel een bevestiging dat ze het zouden oplossen maar een maand later hadden ze nog steeds hetzelfde probleem. En kennelijk waren veel van hun andere klanten aan het slapen, anders hadden ze vast harder hun best gedaan om het op te lossen. Maar nu het continuiteitsprobleem… Wat indien de beheerders niet failliet gaan maar gewoon hun diensten ernstig verwaarlozen? Natuurlijk kun je als klant je contract ontbinden en elders vergelijkbare diensten gaan gebruiken. (En mijn test-site kon ik prima elders hosten en heb ik nu op mijn eigen Windows 2012 server draaien.) Maar het levert vergelijkbare problemen op, waarbij je eigenlijk maar weinig medewerking kunt verwachten. Tegenwoordig zie je dat veel diensten die worden aangeboden bestaan uit blogs, forums, CRM pakketten, webwinkels en nog veel meer. Stel dat je je webwinkel laat hosten door bedrijf X. Het bedrijf gaat niet failliet maar verwaarloost gewoon hun diensten en je webwinkel raakt besmet met allerlei malware, waar je klanten over gaan klagen en dus ook nog besluiten om weg te blijven. Je moet je webwinkel dan zo snel mogelijk elders onder brengen anders hou je geen klant meer over. (Plus, klanten gaan mogelijk bij jou schade claimen.) Natuurlijk start je allerlei procedures tegen deze slechte host, maar hoe krijg je je data veilig bij een andere webwinkel? Deze situatie blijft bij dit soort discussies vaak onderbelicht, omdat we aannemen dat het bedrijf eerst failliet gaat en dan de problemen ontstaan. Vaak is het juist andersom: er ontstaan eerst problemen waarop het bedrijf slecht presteert, klanten weglopen en inkomsten verdwijnen, waarna het bedrijf failliet gaat. En dan is de rest in problemen…

      • Tja, crap? Ik wilde meer over web development leren en indertijd was thuis hosten geen optie. Shared hosting was betaalbaar, dus een goed alternatief. En nadat deze problemen naar voren kwamen leerde ik ook meteen meer over problemen oplossen en hoe belangrijk beveiliging uiteindelijk is. Mijn test-projectjes hadden geen waardevolle data en sowieso was alle data gewoon in een MS-Access database opgeslagen, zodat ik alle bestanden zo naar een nieuwe host kon kopieren en elders kon doorgaan. Het was even lastig maar ik kon makkelijk elders mijn experimentjes voortzetten. Tegenwoordig is thuishosten wel een optie, dus ik leer ook meer over de administrator-kant van web development. Erg handig voor mij, als web developer! Maar goed, sowieso ben ik voor webhosts een aparte klant omdat mijn data uit mijn projecten bestaat. En de laatste versie daarvan heb ik op mijn ontwikkel-computer, niet op de host.

  3. Ik heb moeite om een deel van de tekst te begrijpen… Bij de vraag “Is het een probleem voor mij?”, wie is daar de “mij”? De eindklanten of Fundaments BV?

    Daarna geef je vier redenen waarom het antwoord “ja” zou moeten zijn, maar uit geen enkele reden blijkt dat het probleem bij de eindklant of Fundaments BV ligt. Het lijken eerder antwoorden op een andere vraag, “Moet Fundaments een rol spelen bij het oplossen/voorkomen van het probleem?”

    Ik snap het vraagstuk dus eigenlijk niet waar dit blog over gaat, kun je dit verduidelijken?

    • Ik maak even een knip in je vraag/opmerking, om hem goed te kunnen beantwoorden. Wie is daar de “mij”? Dat betreft Fundaments inderdaad dit geval.

      Over die vier redenen; dit gaan ook over een andere vraag, namelijk de tweede..

      De eerste vraag die beantwoord moet worden is “Is er een probleem?” direct gevolgd door “Is het een probleem voor mij?”. De eerste vraag verdient een duidelijk bevestigend antwoord [..]

      Over de tweede vraag kunnen we het hebben. Mijn antwoord is: Ja, omdat: [..]

      Excuus voor de onduidelijkheid. Is het zo nog steeds onduidelijk? Dan leg ik het graag uit!

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS