John Allspaw, mede-oprichter, Adaptive Capacity Labs

Hoe uw systemen dag na dag blijven werken

Eerst een beetje over John Allspaw, mede-oprichter van Adaptive Capacity Labs, en voormalig Chief Technology Officer van Etsy.

Als technisch leider en onderzoeker met meer dan 20 jaar ervaring in het bouwen en leiden van teams die zich bezighouden met software- en systeemtechniek, heeft Allspaw het laatste decennium overbruggen van inzichten uit Human Factors, Cognitive Systems Engineering en Resilience Engineering op het gebied van software engineering en activiteiten.

Ook de auteur van twee boeken, "The Art of Capacity Planning: Scaling Web Resources" en "Web Operations" (O'Reilly Media), blijft Allspaw bijdragen aan de IT- en DevOps-gemeenschappen door te spreken en samen te werken aan nieuw, opwindend onderzoek.

We hadden het geluk om John te mogen verwelkomen op de DevOps Enterprise Summit in San Francisco, waar hij op het podium stond om te praten over "Hoe systemen dag na dag blijven draaien". Hieronder hebben we de belangrijkste afhaalrestaurants en de belangrijkste hoogtepunten van zijn presentatie getranscribeerd .

John Allspaw op DOES17 San Francisco

John Allspaw

Hoe uw systemen dag na dag blijven werken

Waar ik het over wil hebben is nieuw. Het is anders en ik voel dit heel, heel sterk.

Om dit te helpen was mijn scriptie voor mijn graad in menselijke factoren en systeemveiligheid: 'Afwegingen onder druk: heuristiek en observaties van teams die storingen in internetdiensten oplossen'.

Sommigen van jullie hebben hiervan misschien gehoord, wat het Stella-rapport wordt genoemd.

Op hoog niveau is dit rapport het resultaat van een jaar lang project van een consortium van industriële partners. IBM, Etsy en IEX, handelsmaatschappij, een handelsbeurs in Manhattan. In dit jaar keken mensen van het Ohio State University Cognitive Systems Engineering Lab, David Woods, Richard Cook en een aantal andere mensen diep naar een incident in elk van die organisaties.

Ze vonden deze zes thema's en kwamen allemaal voor.

Zeker, de resultaten zijn behoorlijk belangrijk. Het is hoe dat onderzoek is gedaan waarvan ik wil dat jullie er allemaal naar kijken.

Hier zijn mijn belangrijkste afhaalmaaltijden uit het rapport:

  1. We moeten de menselijke prestaties in deze industrie serieus gaan nemen. Als we dat niet doen, blijven we broze systemen zien met steeds grotere gevolgen voor onze bedrijven en de samenleving.
  2. We kunnen dit doen door te kijken naar incidenten die verder gaan dan wat we momenteel doen in postmortems of post-incident beoordelingen of na-actie beoordelingen.
  3. Er bestaan ​​wel methoden en benaderingen uit de studie van veerkracht in andere domeinen, maar ze vereisen echt commitment om na te streven. Dit doen is zowel noodzakelijk als moeilijk, maar het zal een concurrentievoordeel blijken te zijn voor bedrijven die het goed doen.

Ten eerste wil ik beginnen met een beetje een basislijn, een beetje een vocabulaire dat belangrijk zal zijn, omdat ik je hier een beetje doorheen leid. Ik ga een soort beeld beschrijven, een weergave, zoals een mentaal model van je organisaties, en het zal een boven-de-lijn regio en een onder-de-lijn regio hebben.

Als u zich voorstelt wat we hier hebben afgebeeld, is dit uw product, uw service, uw API of wat uw bedrijf ook waarde oplevert en geeft aan klanten. Oke? Daarbinnen zie je je code. Je ziet je technologiestapel. Je ziet de gegevens en een aantal verschillende manieren om dit te leveren, toch? Vermoedelijk via internet of op een andere manier. Maar als we hier blijven, zal niemand me geloven dat dit het systeem is, want het is prima, maar het is niet echt compleet.

Wat echt verbonden is, en waar veel mensen hier in de DevOps Enterprise Summit-gemeenschap over hebben gesproken, zijn alle dingen die we doen om te manipuleren wat daar gebeurt, en dus hebben we testtools. We hebben monitoringtools. We hebben implementatietools en alle dingen die min of meer vast zitten. Dit zijn de dingen die we gebruiken. Je zou kunnen zeggen dat dit het systeem is, omdat velen van ons onze tijd besteden aan die dingen die daar niet in de kleine bubbel zitten, maar aan alle dingen die er omheen zijn, maar als we hier gewoon bij zouden blijven, zouden we kan niet zien waar echt werk gebeurt.

Wat we hier gaan doen, is dat we een lijn trekken die we de representatielijn noemen, en dan wat dieper graven. Wat we hier zien, ben jij. Alle mensen die dingen klaarmaken om aan het systeem toe te voegen, om het systeem te veranderen. Je doet de architecturale omlijsting. Je doet monitoring. Je houdt bij wat het doet, hoe het doet en wat er met hen aan de hand is.

Nu zul je merken dat elk van deze mensen een soort mentale representatie heeft over wat dat systeem is. Als je er wat beter naar kijkt, zie je dat geen van hen hetzelfde is. Dat is trouwens heel kenmerkend voor dit soort rollen. Niemand heeft dezelfde weergave van wat zich onder de lijn bevindt.

Om samen te vatten, dit is ons wereldmodel, en het omvat niet alleen de dingen die daar draaien, maar jullie allemaal, het soort activiteiten dat je uitvoert, het cognitieve werk dat je doet om die wereld te laten functioneren . Als we hier wat meer mee spelen, eindigen we met dit soort model. Dit model heeft een representatielijn die door het midden loopt en je communiceert met de wereld onder de lijn via een set representaties.

Je interacties zijn nooit met de dingen zelf. Je verandert de systemen niet echt.

Wat je doet is dat je interactie hebt met de weergave en die weergave is iets over wat er hieronder gebeurt. Je kunt die groene dingen beschouwen als de schermen waar je overdag naar kijkt, maar de enige informatie die je over het systeem hebt, is afkomstig van deze weergaven. Het is maar een klein sleutelgat. Rechtsaf?

Wat belangrijk is, is dat alle activiteiten die je doet, al het observeren, afleiden, anticiperen, plannen, corrigeren, al dat soort dingen moeten worden gedaan via die representaties, dus er is een wereld boven de lijn en een wereld onder de lijn, en hoewel jij en wij meestal over de wereld onder de lijn praten alsof het heel echt is, alsof het heel concreet is, alsof het iets is dat dat is, hier is de verrassing.

Hier is het grote probleem - je krijgt het nooit te zien.

Het bestaat niet. In werkelijkheid is er geen lijn die je daadwerkelijk kunt aanraken. Je ziet nooit code draaien. Je zult het systeem nooit echt zien werken. Je raakt die dingen nooit aan.

Wat je doet, is dat je een wereld manipuleert die je niet kunt zien via een set van representaties, en daarom moet je die mentale modellen, die concepties, die inzichten over wat er aan de hand is, bouwen. Dat zijn de dingen die voor die manipulatie zorgen. Het is niet de wereld onder de lijn die het doet. Het is je conceptuele vermogen om de dingen te begrijpen die in het verleden zijn gebeurd, de dingen die je nu doet en waarom je die dingen doet, wat er toe doet en waarom wat er echt toe doet.

Als je eenmaal dit perspectief hebt overgenomen, stap je eenmaal weg dat het idee dat onder de lijn het ding is waar je mee te maken hebt, en begrijpt dat je echt boven de lijn werkt, allerlei dingen veranderen.

Wat je ziet in het Stella-rapport en dat project en andere projecten waar we mee bezig zijn, is die mening hebben en begrijpen wat het echt betekent om de wereld boven de lijn serieus te nemen. Dit is een grote afwijking van veel van wat je in het verleden allemaal hebt gezien, maar ik denk dat het een vruchtbare richting is die we moeten nemen.

Met andere woorden, deze cognitieve activiteiten (zie hieronder) bij zowel individuen als collectief in teams op en neer in de organisatie zijn wat het bedrijf echt laat werken. Nu bestudeer ik dit hier al een tijdje in detail, en ik kan je dit vertellen. Het werkt niet zoals we denken dat het werkt.

Tot slot, om dit kader op te zetten, is het belangrijkste onderdeel van dit idee dat dit allemaal in de loop van de tijd verandert. Het is een dynamisch proces dat gaande is. Dit is de analyse-eenheid. Zodra we dat kader hebben genomen, kunnen we enkele vragen stellen. We kunnen hier enkele vragen over stellen.

“Hoe werkt onze software echt, versus hoe het wordt beschreven in de wiki en in documentatie en in de diagrammen? We weten dat deze niet volledig zijn, ze zijn niet volledig nauwkeurig. "

"Hoe breekt onze software echt, versus hoe we dachten dat het zou breken wanneer we beveiligingen en stroomonderbrekers en vangrails ontwierpen?"

"Wat doen we om het allemaal te laten werken?"

Vraag: Stel je voor je organisatie. Wat zou er gebeuren als vandaag om zes uur al uw bedrijven hun handen van het toetsenbord zouden halen? Ze beantwoorden geen enkele pagina. Ze kijken niet naar waarschuwingen. Ze raken geen enkel deel ervan, applicatiecode of netwerken of iets daarvan aan. Weet u zeker dat uw service na een dag weer beschikbaar is?

De vraag is dan hoe te ontdekken wat er boven de lijn gebeurt. Nou, er zijn een paar dingen. We kunnen leren van de studie van andere domeinen met een hoog tempo en met hoge gevolgen, en als we dat doen, kunnen we zien dat we incidenten kunnen bestuderen. (Opmerking: als ik 'incidenten' zeg, bedoel ik onderbrekingen, degradaties, inbreuken, ongevallen, bijna-ongevallen en glitches - in feite ongewenste of onverwachte gebeurtenissen).

Wat maakt incidenten interessant? Nou, de meest voor de hand liggende is verloren inkomsten en impact op de reputatie van een bepaald bedrijf. Ik wil nog een paar andere redenen aanvoeren waarom incidenten interessant zijn. De ene is dat incidenten vorm geven aan het ontwerp van nieuwe component-subsystemen en architecturen. Met andere woorden, incidenten van gisteren informeren de architecturen van morgen. Dat wil zeggen, incidenten helpen onze verbeeldingskracht aan te wakkeren over hoe we onze systemen beter kunnen maken, en daarom bedoel ik dat incidenten onder de lijn boven de lijn veranderen.

Dat is het hem juist. Dit kan echt geld kosten. Incidenten kunnen soms bijna stilzwijgende of onzichtbare effecten hebben, soms aanzienlijk. Op dit moment splitsen veel mensen een monoliet op in microdiensten. Veel mensen doen dat omdat het een zekere mate van robuustheid biedt die je niet hebt. Waar haal je dat?

U bent op de hoogte van incidenten.

Een andere reden om naar incidenten te kijken, is dat ze de neiging hebben om nieuwe vormen van regelgeving, beleid, normen, compliance, auditing, beperkingen, etc. te geven. Een andere manier om dit te zeggen is dat incidenten van gisteren de regels van morgen informeren, die van invloed zijn op het personeel , budgetten, planning, routekaarten en meer. Ik zal u een voorbeeld geven: bij financiële handel heeft de SEC Verordening SCI ingevoerd. SCI is waarschijnlijk het meest uitgebreide en gedetailleerde stukje compliance in het moderne softwaretijdperk. De SEC is verdwenen en zeer expliciet. We hebben dit als reactie op de flash-crash van 2010 tegen Knight Capital, BATS IPO, Facebook IPO. Het is een reactie op incidenten.

Zelfs als je een beetje verder teruggaat, wordt vaak aangehaald dat PCI DSS tot stand kwam toen MasterCard en Visa biljetten met elkaar vergeleken, beseften dat ze in tien jaar tijd ongeveer $ 750 miljoen hebben verloren, dus incidenten hebben aanzienlijk, en trouwens, ik kan, als een voormalige CTO van een beursgenoteerd bedrijf, ik kan u verzekeren dat dit een zeer dure, afleidende en onvermijdelijk lastige albatros is voor al uw organisaties. Incidenten zijn ook op deze manier belangrijk, maar als we incidenten als kansen beschouwen, als we incidenten als berichten beschouwen, gecodeerde berichten die onder de lijn boven de lijn verzenden, en uw taak is om ze te decoderen, als u aan incidenten denkt als dingen die actief proberen uw aandacht te vestigen op delen van het systeem waarvan u dacht dat u voldoende begrip had, maar dat niet deed, dit zijn herinneringen die u voortdurend moet heroverwegen hoe zeker u bent over hoe het allemaal werkt.

Nu, als u deze opvatting bekijkt, gaat een hele reeks dingen open. Er is een mogelijkheid voor nieuwe training, nieuwe tooling, nieuwe organisatiestructuren, nieuwe financieringsdynamiek en mogelijk inzichten die uw concurrenten niet hebben.

Incidenten helpen ons de delta te bepalen tussen hoe uw systeem werkt en hoe wij denken dat uw systeem werkt, en deze delta is bijna altijd groter dan we ons voorstellen. Ik wil misschien een andere interpretatie beweren die u misschien gewend bent, en dit is dit. Incidenten zijn niet-geplande investeringen in ondernemingen, in het voortbestaan ​​van uw bedrijf. Het zijn enorm waardevolle kansen om te begrijpen hoe uw systeem werkt, welke kwetsbaarheden in aandacht er zijn en welke concurrentievoordelen u niet nastreeft.

Als u denkt aan incidenten, verbranden ze geld, tijd, reputatie, personeel, enz. Dit zijn onvermijdelijke verzonken kosten. Er is echter iets interessants aan dit soort investeringen. U heeft geen controle over de omvang van de investering, dus blijft de vraag hoe u de ROI op die investering kunt maximaliseren?

Als we naar incidenten kijken, zijn dit het soort vragen dat we horen, en het komt redelijk overeen met wat onderzoekers vinden in andere complexe systemen, domeinen. Wat doet het Waarom doet het dat? Wat gaat het hierna doen? Hoe is het in deze toestand gekomen? Wat gebeurt er? Als we Y doen, helpt het ons dan om uit te vinden wat we moeten doen? Wordt het erger? Het lijkt erop dat het is opgelost, maar toch? Als we X doen, zal het dan voorkomen dat het erger wordt of zal het het erger maken? Wie anders moeten we bellen dat ons kan helpen? Is dit onze kwestie, of worden we aangevallen? Dit komt overeen met veel andere velden. Luchtvaart, luchtverkeersleiding, vooral in domeinen met veel automatisering.

Een ander ding dat opvalt, is dat het begin van een incident vaak onzeker of dubbelzinnig is over de vraag of dit degene is die ons doet denken. Aan het begin van een incident weten we het gewoon niet, vooral als het enorme hoeveelheden onzekerheid en grote hoeveelheden dubbelzinnigheid bevat. Als het onzeker en dubbelzinnig is, betekent dit dat we onze mentale modellen hebben uitgeput. Ze passen niet bij wat we zien en die vragen rijzen. Alleen achteraf zal het ons vertellen of dat het evenement was dat het bedrijf ten val bracht of dat het een zware dinsdagmiddag was.

Incidenten bieden kalibratie over hoe beslissingen zijn gericht, over hoe aandacht is gericht, over hoe coördinatie is gericht, over hoe escalatie is gericht. De impact van tijdsdruk, de impact van onzekerheid, de impact van ambiguïteit en de consequenties van consequenties. Onderzoek valideert deze kansen.

"We moeten incidenten diepgaand beschouwen als" niet-routinematige uitdagende gebeurtenissen, omdat deze moeilijke gevallen het grootste potentieel hebben om elementen van expertise en gerelateerde cognitieve fenomenen aan het licht te brengen. "
- Gary Klein, de grondlegger van het naturalistische besluitvormingsonderzoek.

Er is een familie van versleten methoden, benaderingen en technieken. Cognitieve taakanalyse. Traceren van processen. Conversatieanalyse. De kritische beslissingsmethode. Hoe we denken dat postmortems waarde hebben, ziet er een beetje als volgt uit:

Er gebeurt een incident. Misschien stelt iemand een tijdlijn samen. We hebben een beetje een vergadering. Misschien heb je een sjabloon en vul je die in, en dan kan iemand een rapport maken of niet, en dan heb je eindelijk actie-items. We denken dat de grootste waarde, misschien wel de eerste waarde, is waar je in een debriefing bent en mensen door de tijdlijn lopen en je denkt: "Oh, mijn God. We weten dit allemaal. '

Dit is niet wat het onderzoek bevestigt. Het onderzoek bevestigt dat als we subjectieve en objectieve gegevens van meerdere plaatsen verzamelen, gedragsgegevens, wat mensen zeiden, wat mensen deden, waar ze keken, welke wegen in de diagnose ze volgden en niet vruchtbaar waren? Goed gefaciliteerde debriefings laten mensen contrasteren en hun mentale modellen vergelijken die noodzakelijkerwijs gebrekkig zijn. U kunt verschillende resultaten produceren, waaronder dingen als bootcamp, onboarding-materialen, nieuwe huurtrainingen. Je kunt faciliterende feedback krijgen als je een programma bouwt om facilitators te trainen. U kunt wijzigingen aanbrengen in de routekaart, echt belangrijke wijzigingen op basis van wat u leert.

Ik kan je dit uit enige ervaring vertellen. Er is niets meer inzichtelijk voor een nieuwe ingenieur of een ingenieur die net in zijn carrière is begonnen dan in een kamer te zijn met een ervaren ingenieur die alle hoeken en gaten kent die dingen verklaren die ze misschien nooit hardop hebben gezegd. Ze hebben kennis. Ze kunnen afbeeldingen en diagrammen tekenen die ze nog nooit eerder hebben getekend, omdat ze denken dat iedereen het weet. Raad eens? Dat doen ze niet. De grootste waarde is eigenlijk hier, omdat de kwaliteit van deze resultaten afhangt van de kwaliteit daarvan, die herkalibratie. Dit is een opening om mentale modellen opnieuw te kalibreren.

Uit het Stella-rapport “informeert en herijkt het de modellen van mensen over hoe het systeem werkt, hun inzichten in hoe het kwetsbaar is en welke mogelijkheden er zijn voor onderzoek”.

In veel van het onderzoek, in al het onderzoek in het Stella-rapport, en het past ook bij mijn ervaring bij Etsy, een van de, de sterkste weerspiegelingen van mensen die dit op een gefaciliteerde manier doen om dit te doen vergelijken en contrasterende. "Ik wist niet dat het op die manier werkte." Dan is er nog een ander: "Hoe heeft het ooit gewerkt?" Wat grappig is totdat je je realiseert dat het serieus is. Wat dat betekent is, de manier waarop ik niet alleen dacht dat het anders werkte. Nu kan ik me niet eens voorstellen, ik kan zelfs geen beeld in mijn hoofd schetsen van hoe het mogelijk had kunnen werken. Dat zou verontrustender moeten zijn. Ik wil trouwens zeggen dat dit geen afstemming is. Zoals ik al zei, via representaties hebben we noodzakelijkerwijs onvolledige mentale modellen. Het idee is niet om dezelfde mentale modellen te hebben, omdat ze altijd onvolledig zijn, omdat dingen altijd veranderen en omdat ze gebrekkig zullen zijn. We willen niet dat iedereen hetzelfde mentale model heeft, omdat dan iedereen dezelfde blinde vlekken heeft.

Onberispelijk - terug naar de blogpost die ik in 2012 heb geschreven

"Blameless" is tafelinzetten. Het is noodzakelijk, maar het is niet voldoende. Je zou een omgeving, een cultuur, een omhelzing, een soort gastvrije organisatie kunnen bouwen die mensen ondersteunt en in staat stelt om verhalen te vertellen in alle rommelige details, soms beschamende details, zonder angst voor vergelding, zodat je echt vooruitgang kunt boeken, en door te begrijpen wat er gebeurt, kun je die toestand instellen en nog steeds niet veel leren. Het is niet voldoende. Het is noodzakelijk, maar niet voldoende. Waar ik het over heb is veel meer moeite dan typische beoordelingen na incidenten. Rechtsaf? Dit is waar een analist, een facilitator gedragsgegevens kan voorbereiden, verzamelen, organiseren en analyseren. Wat mensen zeggen, wat mensen doen. Er is een hele reeks gegevens die ze kunnen doornemen om zich voor te bereiden op debriefings, een groepsdebriefing of een één-op-één debriefing, die verder gaan ... Postmortems wijzen op de rijkdom van incidenten. Het opvolgen hiervan kost veel werk.

Trouwens, iedereen is over het algemeen zo uitgeput na een echte, stressvolle storing of incident of gebeurtenis dat soms alles kristalhelder wordt. Dat is de kracht van achteraf gezien, en omdat het zo kristalhelder lijkt, lijkt het niet productief om een ​​debriefing te hebben, omdat je denkt dat je alles al weet. Het andere probleem is dat postmortem briefings ook door tijd worden beperkt. U hebt slechts een vergaderruimte van een uur of twee. Iedereen is erg druk en de klok tikt, dus dit is een uitdaging om dit echt goed te doen, zelfs gezien die onderzoeksmethoden.

Het andere probleem, vooral als je een debriefing faciliterende trainingsprogramma bouwt zoals ik deed bij Etsy, zijn er nog steeds uitdagingen die opduiken. Wat ik het graag noem, is: "Iedereen heeft zijn eigen mysterie om op te lossen", of "Verspil mijn tijd niet aan details die ik al ken." Op een cartoonachtige manier kun je er zo over denken:

Omdat je misschien maar een uur hebt, moet je zoveel mogelijk leren extraheren. Al het werk is contextueel. Jouw taak om de ROI te maximaliseren is het ontdekken, verkennen en herbouwen van de context waarin werk wordt gedaan bij een incident, hoe werk en hoe mensen boven de lijn dachten.

Beoordelingen zijn afwegingen en die zijn contextueel.

Tot slot kunnen alle incidenten erger zijn. Een oppervlakkige visie is om te vragen: “Wat is er misgegaan? Hoe is het gebroken? Wat lossen we op? ”Dit zijn zeer redelijke vragen. Als we een dieper niveau zouden nemen, en we zouden kunnen vragen: "Wat zijn de dingen die ertoe hebben geleid om het niet zo erg te maken als het had kunnen zijn?" Omdat we geen aandacht aan die dingen besteden en niet identificeren die dingen, kunnen we stoppen met het ondersteunen van die dingen.

Misschien is de reden waarom het niet erger is geworden omdat iemand Lisa heet en Lisa haar dingen kent. Iets uit onderzoek is dat experts kunnen zien wat er niet is. Als je Lisa niet steunt, en je merkt niet eens dat de reden waarom het niet erger werd, is omdat Lisa er was. Vergeet actie-items om even iets te repareren. Stel je een wereld voor waar Lisa naar een nieuwe baan gaat.

Handig op strategisch niveau is een betere vraag. “Hoe kunnen we het voortdurende proces van begrip in onze systemen ondersteunen, aanmoedigen, bepleiten en financieren? En echt "boven de streep" op een duurzame manier?

Wat gaan we nu doen? Ik heb een aantal uitdagingen voor je:

  1. Verspreid het Stella-rapport in uw bedrijf en start een dialoog. Zelfs als je het te druk hebt of niet in staat bent om het zelf te lezen, geef het aan mensen die dat wel doen. Vraag hen wat resoneert. Vraag hen wat niet logisch is. Vraag het hen, start een dialoog.
  2. Kijk goed naar hoe u omgaat met beoordelingen na het evenement. Belangrijker nog, ga op zoek naar de mensen die het meest vertrouwd zijn met de rommelige details van hoe werk wordt gedaan en vraag hen dit: "Welke waarde denkt u dat onze huidige beoordelingen na incidenten echt hebben?" En luister.
  3. Neem de verantwoordelijkheid om meer en sneller van incidenten te leren dan uw concurrenten. Je bent een leerorganisatie aan het bouwen of je verliest aan iemand die dat is.
  4. We moeten menselijke prestaties serieus nemen. Deze discussie is gaande. Het gebeurt in kernenergie. Het gebeurt in de geneeskunde. Het gebeurt in de luchtvaart, luchtverkeersleiding, bij brandbestrijding.

De toenemende betekenis van onze systemen, het toenemende potentieel voor economische, politieke en menselijke schade als ze niet goed werken, en de proliferatie van afhankelijkheden en bijbehorende onzekerheid maken me allemaal erg bezorgd. Als je naar je eigen systeem en de problemen kijkt, denk ik dat je het ermee eens zult zijn dat we veel meer moeten doen dan dit probleem erkennen. We moeten het omarmen. Waar je me mee kunt helpen, verspreid deze informatie, deze ideeën en mijn presentatie van DevOps Enterprise Summit San Francisco 2017.

Ik wil van je horen. Wat resoneerde hiermee? Wat niet? Voor welke uitdagingen staat u in uw organisatie langs deze lijnen? Kom het me vertellen. Ik ben op Twitter.

Oorspronkelijk gepubliceerd op itrevolution.com op 30 april 2018.