Provider "bedriegt", maar ik wil niet onthullen hoe ik erachter kwam dat

Wat je moet doen is onafhankelijk verifiëren wat je verteld is door deze junior ontwikkelaar. Ten eerste, je weet eigenlijk niet dat wat hij gezegd heeft accuraat is. Er kan ergens een miscommunicatie zijn geweest, hij kan een misverstand hebben, misschien heeft hij niet het hele plaatje vanuit een technisch standpunt en geeft hij onvolledige gegevens door, enz. Zoals ze zeggen, “trust, maar verifieer.”

Om een andere reden beschermt het verifiëren van wat je verteld werd je bron. Niemand hoeft te weten dat hij u iets verteld heeft, want u kunt de gegevens vasthouden als bewijs van wat er gebeurd is, en het feit dat u door iemand getipt bent, volledig weglaten. Je hebt niet genoeg technische details gegeven om te adviseren hoe je dit zou kunnen verifiëren, maar het klinkt niet alsof het moeilijk zou zijn voor een fatsoenlijke sysadmin of systeemengineer om dit te doen.

Natuurlijk is er altijd de mogelijkheid om eenvoudigweg te vermelden wat je bron je heeft verteld, en te zeggen dat je, om vergelding te voorkomen, liever je bron niet wil/kan benoemen. Maar jezelf controleren, zodat zelfs het hebben van een bron naast het punt staat, is de betere aanpak.

Hoewel uw zorg voor de junior-programmeur in dit geval bewonderenswaardig is, moet u er rekening mee houden dat dit een situatie is waarin u wettelijk verplicht bent tegenover uw klant. Dat gezegd hebbende…

Mijn klant zou geen rechtszaak aanspannen, maar zeker die provider dumpen. Wij zijn een van hun belangrijkste klanten.

Aangezien uw klant de aanbieder zou dumpen en aangezien de aanbieder oneerlijk is, waarom zou u dan iets anders doen dan de aanbieder te dumpen?

U hoeft uw bron waarschijnlijk niet prijs te geven. In feite zou je je klant gewoon kunnen vertellen dat sinds de provider zijn prestaties niet hebben voldaan aan wat ze betalen, dan is het tijd om weg te lopen. Als u op de knop drukt, kunt u zeggen dat aangezien de dienstverlener van tevoren wist van de test dat u vermoedt dat ze extra middelen hebben toegewezen voor de test die ze niet normaal leveren.

Als u echt de junior-programmeur wilt beschermen en een slot wilt hebben dat hij kan vullen, kunt u hem zelf inhuren, of uw klant kan hem inhuren. Op deze manier wordt hij zeker niet ontslagen door de service provider. Ook, in het geval dat de service provider probeert uw klant aan te klagen voor contractbreuk, bent u er zeker van dat u hem in de buurt heeft als getuige.

Een beetje naar deze

Van wat je weet heeft de provider servers aan de farm toegevoegd tijdens de testen. Als uw klant een enorm bedrag betaalde voor de benchmark dan had u moeten hopen dat het bedrijf dat ingehuurd was om de benchmark uit te voeren dat zou hebben opgepikt.

Overschrijdt de benchmark de theoretische output van de boerderij? Kun je laten zien dat de resultaten gewoon niet realistisch zijn?

Kun je op een of andere manier een aantal onafhankelijke benchmarks uitvoeren die de doctored benchmark in twijfel trekken?

Heeft de provider niet wat real-time monitoring van basis prestatiemetingen zoals CPU, IO, bandbreedte …? U had een aantal daarvan moeten uitvoeren tijdens de onthulde benchmark. Ik weet dat hindsight 20/20 is, maar toch.

U bent niet op zoek naar het probleem. Je kent het probleem en nu moet je het gewoon bewijzen. Je bron heeft je een grote dienst bewezen door het probleem bloot te leggen. Kan je het probleem bewijzen zonder de bron bloot te leggen?

Misschien ga je gewoon met:

Deze benchmarks komen gewoon niet overeen met de prestaties van de applicatie. Ofwel is de app een grotere belasting dan ik verwacht, de servers brengen die prestaties niet uit, ofwel mis ik gewoon iets. Hier zijn items om te verkennen… En in de lijst van items om te verkennen hebben een verrassing benchmark.

Outing de persoon die de informatie heeft verstrekt is een moeilijke. Hij zou waarschijnlijk ontslagen worden. En waarschijnlijk ontslagen op een zeer slechte manier in die moeilijk te vinden andere baan. Ik zou moeilijk zoeken naar een manier om dit aan de kaak te stellen zonder de persoon te ontmaskeren. Persoonlijk zou ik ze niet uit de kast halen. Zonder een onafhankelijke verificatie zou het waarschijnlijk toch niet standhouden.

Als de prestaties in de praktijk niet overeenkomen met de prestaties tijdens de test (en je hebt de gegevens om het te bewijzen), moet de oplossing gemakkelijk zijn: informeer de provider, en als de prestaties niet verbeteren, annuleer het contract.

Je hoeft niet te vertellen hoe je vond dat de test werd gemanipuleerd, alleen dat dagelijkse prestaties niet overeenkomen met de test benchmark (je kunt zelfs “onschuldig” vragen: is er een hardware/software configuratie veranderd sinds de benchmark?). Maar uw advocaten zijn misschien wel geïnteresseerd in een gesprek met het bedrijf dat u heeft betaald voor de dure benchmark - was het hetzelfde als de dienstverlener, of anders?

Met betrekking tot uw lekke band: Maak zijn naam niet bekend, dat zou hem onder een bus gooien zonder goede reden en zonder voordeel voor uw eigen bedrijf. Maar u wilt misschien wel in contact blijven en eventueel de gunst teruggeven: waarschuw hem voor de noodzaak om voor de crash een andere baan te zoeken (wanneer opzegging van het contract publieke informatie is, niet eerder). Ik begrijp het dilemma dat je hem geen goede referentie kunt geven (of misschien kun je dat wel - zeggen dat hij behulpzaam was en de extra mijl zou gaan om met de klant te communiceren).

De gemakkelijkste manier om de gunst terug te geven zou zijn om ** hem een keer mee te nemen voor een koffie** (buiten de gebouwen van beide bedrijven, en hem te vertellen dat de vergadering strikt off the record is ). Het zou kort na de annulering van het project openbaar kunnen zijn, niet eerder, en ** hem uitleggen in wat voor soort ondernemingspolitiek** hij verstrikt is geraakt, en welk gecompliceerd ethisch dilemma er vrij is voor het nemen (voor jullie beiden). Dus hij kan er de volgende keer beter mee omgaan. Hij lijkt een eerlijke en behulpzame kerel te zijn, die misschien nog niet op de hoogte is van de fijne kneepjes van het leven - en je hebt een uitstekende kans om hem te helpen om hem in te lichten; hem te helpen de les te leren zonder schade aan zijn carrière te berokkenen.

Niet zeker hoe hij de volgende keer zal reageren: het niet vertellen, of het niet bedriegen van klanten? :-)

De andere antwoorden zijn echt goed, maar ik zag dit niet expliciet vermeld in een van hen -

Waarom zou uw aanbeveling niet gewoon zijn dat hun externe benchmarking leverancier een andere test uit te voeren als hun testmethode was gebrekkig. Als je weet dat de informatie is gepubliceerd en de diensten zijn uitgeschakeld, weet ik zeker dat je een NIST- of ISO-norm kunt vinden waarin de juiste procedure voor dit soort testen staat vermeld. Je zou zelfs best practices informatie van ISACA.

kunnen zoeken. Het maakt niet uit wat je weet, alleen dat door het publiceren van de tijd en de omgeving die wordt gewijzigd, het geen geldige test is. Zelfs dan zou ik naar het externe testbedrijf kunnen gaan en hen vragen wat ze dachten.

Klinkt alsof zowel het benchmarkingbedrijf als de aanbieder betrokken waren bij het creëren van een situatie voor onnauwkeurige resultaten en waren IMO ten minste negligent en ten hoogste * heimelijke **.

Nogmaals, ik weet niet voor welke baan u bent ingehuurd, maar als dit alles binnen het bereik ligt, is het een goede manier om te voorkomen dat er vertrouwelijke informatie wordt onthuld.

Maak alles bekend aan uw klant en vertel hem over de informatie die u hebt. U heeft een professionele verplichting om hem de best mogelijke service te verlenen en u heeft geen professionele verplichting tegenover de junior ontwikkelaar van het datacenter. Uw klant heeft u letterlijk betaald om dit soort dingen te ontdekken.

Nadat u de informatie die u heeft verkregen (waarvoor uw klant u betaalt) openbaar heeft gemaakt. Bespreek wat de junior ontwikkelaar heeft gezegd.

Als het klopt - werk zeker samen met een andere provider.

Als mensen proberen we aardig en eerlijk te zijn en dat is bewonderenswaardig. Als professional heb je de verplichting om de best mogelijke service te verlenen aan je klant.

Het feit dat de eigenlijke toepassing “verschrikkelijke softwareprestaties” heeft, terwijl in de tests “de resultaten waren prima” moet een belletje doen rinkelen voor iedereen en kan worden gebruikt als een startpunt voor discussie, of het uitdagen van de tests. Je zou op de testboerderij argwaan kunnen/moeten wekken bij de klant over deze discrepantie, zeker gezien het feit dat je “verantwoordelijk voor hen” bent.

Daarnaast blijft het oorspronkelijke probleem onopgelost en open voor verdere analyse, met of zonder tussenkomst van het enorm betaalde externe bedrijf. Voor veel technologieën zijn er hulpmiddelen beschikbaar om de productieprestaties te monitoren zonder dat dit echt invloed heeft; je zou dat kunnen gebruiken om “gruwelijk” te kwantificeren. In aanvulling op HopelessN00b’s antwoord zou dit een andere manier zijn om dit te controleren.

Uw bron is een “junior ontwikkelaar in dienst van de serverhost, die erover pratleert”. Met andere woorden, wat jou betreft heb je niets verkeerds gedaan om die informatie te krijgen.

Je plicht is niet aan de ISP, of de junior-ontwikkelaar bij de ISP, maar aan je klant. Ik vind dus dat u uw klant moet informeren. Je zou kunnen vermelden wat voor soort bron je had zonder de eigenlijke bron te vermelden. Wat zal er gebeuren: Je klant zal stoppen met het gebruik van een ISP die vals speelt, de ISP zal de klant die ze bedriegen verliezen, en de junior ontwikkelaar zal hopelijk niet meer praten over dit in gevaar zijn.