Tegenwoordig heeft de Bitrix24-service geen honderden gigabits aan verkeer, noch beschikt deze over een enorme vloot servers (hoewel er natuurlijk nogal wat bestaande zijn). Maar voor veel klanten is het het belangrijkste hulpmiddel bij het werken in het bedrijf; het is een echte bedrijfskritische applicatie. Daarom is er geen manier om te vallen. Wat als de crash wel zou plaatsvinden, maar de service zo snel ‘herstelde’ dat niemand iets merkte? En hoe is het mogelijk om failover te implementeren zonder dat de kwaliteit van het werk en het aantal klanten verloren gaat? Alexander Demidov, directeur clouddiensten bij Bitrix24, sprak voor onze blog over hoe het reserveringssysteem is geëvolueerd in de zeven jaar dat het product bestaat.
“We hebben Bitrix24 7 jaar geleden gelanceerd als SaaS. De grootste moeilijkheid was waarschijnlijk het volgende: voordat het publiekelijk als SaaS werd gelanceerd, bestond dit product eenvoudigweg in de vorm van een boxed-oplossing. Klanten kochten het bij ons, hostten het op hun servers, zetten een bedrijfsportaal op - een algemene oplossing voor communicatie met medewerkers, bestandsopslag, taakbeheer, CRM, dat is alles. En tegen 2012 besloten we dat we het als SaaS wilden lanceren, waarbij we het zelf wilden beheren, zodat we fouttolerantie en betrouwbaarheid konden garanderen. Gaandeweg hebben we ervaring opgedaan, omdat we die tot dan toe eenvoudigweg niet hadden: we waren slechts softwarefabrikanten, geen dienstverleners.
Toen we de dienst lanceerden, begrepen we dat het allerbelangrijkste is om fouttolerantie, betrouwbaarheid en constante beschikbaarheid van de dienst te garanderen, want als je een eenvoudige, gewone website hebt, een winkel bijvoorbeeld, en deze op jou valt en daar blijft zitten een uur, alleen jij lijdt, je verliest orders, je verliest klanten, maar voor je klant zelf is dit niet erg kritisch voor hem. Hij was natuurlijk boos, maar hij ging het op een andere site kopen. En als dit een applicatie is waaraan al het werk binnen het bedrijf, communicatie en beslissingen is gekoppeld, dan is het belangrijkste om het vertrouwen van gebruikers te winnen, dat wil zeggen om ze niet in de steek te laten en niet te vallen. Omdat al het werk kan stoppen als iets binnenin niet werkt.
Bitrix.24 als SaaS
We hebben het eerste prototype een jaar vóór de publieke lancering, in 2011, in elkaar gezet. We hebben het in ongeveer een week in elkaar gezet, bekeken, rondgedraaid - het werkte zelfs. Dat wil zeggen, u zou naar het formulier kunnen gaan, daar de naam van het portaal invoeren, een nieuw portaal zou openen en er zou een gebruikersbestand worden aangemaakt. We hebben ernaar gekeken, het product in principe beoordeeld, gesloopt en een jaar lang verder verfijnd. Omdat we een grote taak hadden: we wilden niet twee verschillende codebases maken, we wilden geen afzonderlijk verpakt product of afzonderlijke cloudoplossingen ondersteunen - we wilden het allemaal binnen één code doen.
Een typische webapplicatie in die tijd was één server waarop wat PHP-code draait, een mysql-database, bestanden worden geüpload, documenten, afbeeldingen worden in de uploadmap geplaatst - nou ja, het werkt allemaal. Helaas is het onmogelijk om hiermee een kritisch stabiele webservice te lanceren. Daar wordt gedistribueerde cache niet ondersteund en wordt databasereplicatie niet ondersteund.
We hebben de vereisten geformuleerd: dit is de mogelijkheid om zich op verschillende locaties te bevinden, replicatie te ondersteunen en idealiter gevestigd te zijn in verschillende geografisch verspreide datacenters. Scheid de productlogica en feitelijk de gegevensopslag. In staat zijn om dynamisch te schalen op basis van de belasting en de statische elektriciteit volledig te tolereren. Uit deze overwegingen kwamen feitelijk de eisen aan het product voort, die we in de loop van het jaar verfijnden. Gedurende deze tijd hebben we op het platform, dat verenigd bleek te zijn - voor boxed-oplossingen, voor onze eigen service - ondersteuning geboden voor de dingen die we nodig hadden. Ondersteuning voor mysql-replicatie op het niveau van het product zelf: dat wil zeggen dat de ontwikkelaar die de code schrijft niet nadenkt over hoe zijn verzoeken zullen worden gedistribueerd, hij gebruikt onze API en we weten hoe we schrijf- en leesverzoeken correct tussen masters moeten verdelen en slaven.
We hebben ondersteuning op productniveau geboden voor verschillende cloud-objectopslag: Google Storage, Amazon S3, plus ondersteuning voor open stack Swift. Daarom was dit zowel handig voor ons als service als voor ontwikkelaars die met een pakketoplossing werken: als ze onze API alleen voor hun werk gebruiken, denken ze niet na over waar het bestand uiteindelijk zal worden opgeslagen, lokaal op het bestandssysteem of in de opslag van objectbestanden.
Daarom hebben we meteen besloten dat we zouden reserveren op het niveau van het gehele datacenter. In 2012 zijn we volledig op Amazon AWS gelanceerd omdat we al ervaring hadden met dit platform; onze eigen website werd daar gehost. We werden aangetrokken door het feit dat Amazon in elke regio verschillende beschikbaarheidszones heeft - in feite (in hun terminologie) verschillende datacenters die min of meer onafhankelijk van elkaar zijn en ons in staat stellen om te reserveren op het niveau van een heel datacenter: als het plotseling uitvalt, worden de databases master-master gerepliceerd, wordt er een back-up gemaakt van de webapplicatieservers en worden de statische gegevens verplaatst naar de s3-objectopslag. De belasting wordt gebalanceerd - destijds door Amazon elb, maar even later kwamen we bij onze eigen load balancers, omdat we complexere logica nodig hadden.
Wat ze wilden is wat ze kregen...
Alle basiszaken die we wilden garanderen – fouttolerantie van de servers zelf, webapplicaties, databases – alles werkte goed. Het eenvoudigste scenario: als een van onze webapplicaties uitvalt, is alles eenvoudig: ze zijn uitgeschakeld voor balancering.
De balancer (destijds was het Amazon's elb) markeerde machines die buiten gebruik waren als ongezond en schakelde de belastingverdeling daarop uit. De automatische schaling van Amazon werkte: toen de belasting groeide, werden nieuwe machines toegevoegd aan de autoschalingsgroep, de belasting werd verdeeld over nieuwe machines - alles was in orde. Bij onze balancers is de logica ongeveer hetzelfde: als er iets met de applicatieserver gebeurt, verwijderen we verzoeken ervan, gooien deze machines weg, starten nieuwe en gaan door met werken. Het schema is in de loop der jaren een beetje veranderd, maar blijft werken: het is eenvoudig, begrijpelijk en er zijn geen problemen mee.
We werken over de hele wereld, de belastingspieken van klanten zijn compleet verschillend en op een minnelijke manier zouden we op elk moment bepaalde servicewerkzaamheden aan alle componenten van ons systeem moeten kunnen uitvoeren - onopgemerkt door de klanten. Daarom hebben we de mogelijkheid om de database uit te schakelen en de belasting te herverdelen naar een tweede datacenter.
Hoe werkt het allemaal? — We schakelen het verkeer om naar een werkend datacenter - als er een ongeluk gebeurt in het datacenter, dan volledig, als dit ons geplande werk met één database is, dan schakelen we een deel van het verkeer dat deze klanten bedient naar een tweede datacenter, waarbij we het verkeer opschorten het repliceert. Als er nieuwe machines nodig zijn voor webapplicaties omdat de belasting op het tweede datacenter is toegenomen, zullen deze automatisch opstarten. We maken het werk af, de replicatie wordt hersteld en we sturen de volledige lading terug. Als we wat werk in de tweede DC moeten spiegelen, bijvoorbeeld systeemupdates moeten installeren of instellingen in de tweede database moeten wijzigen, herhalen we over het algemeen hetzelfde, alleen in de andere richting. En als dit een ongeluk is, doen we alles triviaal: we gebruiken het event-handlers-mechanisme in het monitoringsysteem. Als er meerdere controles worden geactiveerd en de status kritiek wordt, voeren we deze handler uit, een handler die deze of gene logica kan uitvoeren. Voor elke database specificeren we welke server de failover is en waar het verkeer naartoe moet worden geschakeld als het niet beschikbaar is. Historisch gezien gebruiken we nagios of sommige van zijn vorken in een of andere vorm. In principe bestaan soortgelijke mechanismen in vrijwel elk monitoringsysteem; we gebruiken nog niets complexers, maar misschien zal dat ooit wel gebeuren. Nu wordt monitoring geactiveerd door onbeschikbaarheid en heeft het de mogelijkheid om iets te veranderen.
Hebben we alles gereserveerd?
We hebben veel klanten uit de VS, veel klanten uit Europa, veel klanten die dichter bij het Oosten liggen - Japan, Singapore enzovoort. Natuurlijk bevindt een groot deel van de klanten zich in Rusland. Dat wil zeggen, het werk bevindt zich niet in één regio. Gebruikers willen snel antwoord, er zijn vereisten om te voldoen aan verschillende lokale wetten, en binnen elke regio reserveren we twee datacenters, plus een aantal aanvullende diensten, die wederom handig zijn om binnen één regio te plaatsen - voor klanten die zich in deze regio werkt. REST-handlers, autorisatieservers, ze zijn minder kritisch voor de werking van de client als geheel, je kunt er met een kleine acceptabele vertraging doorheen schakelen, maar je wilt het wiel niet opnieuw uitvinden over hoe je ze moet monitoren en wat je moet doen met hen. Daarom proberen we bestaande oplossingen maximaal te gebruiken, in plaats van een soort competentie in aanvullende producten te ontwikkelen. En ergens gebruiken we triviaal schakelen op DNS-niveau, en bepalen we de levendigheid van de dienst aan de hand van dezelfde DNS. Amazon heeft een Route 53-service, maar het is niet alleen een DNS waarin je gegevens kunt invoeren en dat is alles: het is veel flexibeler en handiger. Hiermee kunt u geogedistribueerde services bouwen met geolocaties, wanneer u deze gebruikt om te bepalen waar de klant vandaan komt en hem bepaalde records te geven - met zijn hulp kunt u failover-architecturen bouwen. Dezelfde gezondheidscontroles worden geconfigureerd in Route 53 zelf, u stelt de eindpunten in die worden gemonitord, stelt statistieken in, stelt in welke protocollen de “levendigheid” van de service bepalen - tcp, http, https; stel de frequentie in van de controles die bepalen of de dienst actief is of niet. En in de DNS zelf specificeer je wat primair zal zijn, wat secundair zal zijn, waar moet worden overgeschakeld als de gezondheidscontrole wordt geactiveerd binnen route 53. Dit alles kan worden gedaan met een aantal andere tools, maar waarom is het handig - we stellen het in een keer op en denk er dan helemaal niet meer over na hoe we controles doen, hoe we schakelen: alles werkt vanzelf.
De eerste ‘maar’: hoe en waarmee route 53 zelf reserveren? Wie weet, wat als er iets met hem gebeurt? Gelukkig zijn we nooit op deze hark gestapt, maar nogmaals, ik zal wel een verhaal voor de boeg hebben waarom we dachten dat we toch moesten reserveren. Hier hebben we van tevoren rietjes voor onszelf neergelegd. Meerdere keren per dag lossen we alle zones die we in route 53 hebben volledig uit. Met de API van Amazon kun je ze eenvoudig in JSON verzenden, en we hebben verschillende back-upservers waar we het converteren, uploaden in de vorm van configuraties en grofweg een back-upconfiguratie hebben. Als er iets gebeurt, kunnen we dit snel handmatig implementeren zonder de DNS-instellingengegevens te verliezen.
Tweede "maar": Wat op deze foto is nog niet gereserveerd? De balancer zelf! Onze verdeling van klanten per regio is heel eenvoudig gemaakt. We hebben de domeinen bitrix24.ru, bitrix24.com, .de - nu zijn er 13 verschillende, die in verschillende zones actief zijn. We kwamen tot het volgende: elke regio heeft zijn eigen balancers. Dit maakt het handiger om over regio’s te verdelen, afhankelijk van waar de piekbelasting op het netwerk is. Mocht dit een storing zijn op het niveau van één balancer, dan wordt deze simpelweg buiten dienst gesteld en uit de dns verwijderd. Als er een probleem is met een groep balancers, dan worden deze op andere sites geback-upt en wordt er via dezelfde route geschakeld53, omdat er vanwege de korte TTL binnen maximaal 2, 3, 5 minuten wordt geschakeld .
Derde "maar": Wat is nog niet gereserveerd? S3, juist. Toen we de bestanden die we voor gebruikers opslaan in s3 plaatsten, geloofden we oprecht dat het pantserdoordringend was en dat het niet nodig was om daar iets te reserveren. Maar de geschiedenis laat zien dat dingen anders gebeuren. Over het algemeen beschrijft Amazon S3 als een fundamentele dienst, omdat Amazon zelf S3 gebruikt om machine-images, configuraties, AMI-images, snapshots op te slaan... En als s3 crasht, zoals één keer in deze zeven jaar is gebeurd, zolang we het hebben gebruikt bitrix7, het volgt het als een fan. Er komen een heleboel dingen naar voren: onvermogen om virtuele machines te starten, API-fouten, enzovoort.
En S3 kan vallen - het is één keer gebeurd. Daarom kwamen we tot het volgende plan: een paar jaar geleden waren er in Rusland geen serieuze openbare opslagfaciliteiten voor objecten, en we overwogen de mogelijkheid om zelf iets te doen... Gelukkig zijn we hier niet mee begonnen, omdat we dat zouden doen We hebben ons verdiept in de expertise die we niet hebben, en die zouden waarschijnlijk een puinhoop worden. Nu heeft Mail.ru s3-compatibele opslag, Yandex heeft het en een aantal andere providers hebben het. Uiteindelijk kwamen we op het idee dat we ten eerste een back-up wilden hebben en ten tweede de mogelijkheid om met lokale kopieën te werken. Specifiek voor de Russische regio gebruiken we de Mail.ru Hotbox-service, die API-compatibel is met s3. We hadden geen grote wijzigingen nodig aan de code in de applicatie en we hebben het volgende mechanisme gemaakt: in s3 zijn er triggers die het maken/verwijderen van objecten activeren, Amazon heeft een service genaamd Lambda - dit is een serverloze lancering van code die wordt uitgevoerd op het moment dat bepaalde triggers worden geactiveerd.
We hebben het heel eenvoudig gedaan: als onze trigger wordt geactiveerd, voeren we code uit die het object naar de Mail.ru-opslag kopieert. Om het werken met lokale kopieën van gegevens volledig te kunnen lanceren, hebben we ook omgekeerde synchronisatie nodig, zodat klanten in het Russische segment kunnen werken met opslag die dichter bij hen staat. Mail staat op het punt de triggers in zijn opslag te voltooien - het zal mogelijk zijn om omgekeerde synchronisatie uit te voeren op infrastructuurniveau, maar voorlopig doen we dit op het niveau van onze eigen code. Als we zien dat een klant een bestand heeft gepost, plaatsen we de gebeurtenis op codeniveau in een wachtrij, verwerken deze en voeren omgekeerde replicatie uit. Waarom het slecht is: als we op de een of andere manier met onze objecten werken buiten ons product, dat wil zeggen op een externe manier, houden we daar geen rekening mee. Daarom wachten we tot het einde, wanneer triggers op opslagniveau verschijnen, zodat het object dat naar ons toe kwam, ongeacht waar we de code uitvoeren, in de andere richting wordt gekopieerd.
Op codeniveau registreren we beide opslagplaatsen voor elke client: de ene wordt als de belangrijkste beschouwd, de andere als back-up. Als alles in orde is, werken we met de opslag die dichter bij ons staat: dat wil zeggen, onze klanten die bij Amazon werken, werken met S3, en degenen die in Rusland werken, werken met Hotbox. Als de vlag wordt geactiveerd, moet de failover worden verbonden en schakelen we clients over naar een andere opslag. Wij kunnen dit vakje onafhankelijk per regio aanvinken en heen en weer schakelen. We hebben dit nog niet in de praktijk gebruikt, maar we hebben wel in dit mechanisme voorzien en we denken dat we deze omschakeling op een dag nodig zullen hebben en van pas zullen komen. Dit is al een keer gebeurd.
Oh, en Amazon rende weg...
In april is het de verjaardag van het begin van de blokkering van Telegram in Rusland. De meest getroffen aanbieder die hieronder viel is Amazon. En helaas leden Russische bedrijven die voor de hele wereld werkten meer.
Als het bedrijf mondiaal is en Rusland er een heel klein segment voor is, 3-5%, dan kun je ze op de een of andere manier opofferen.
Als dit een puur Russisch bedrijf is - ik ben er zeker van dat het lokaal gevestigd moet zijn - dan zal het gewoon handig zijn voor de gebruikers zelf, comfortabel en zullen er minder risico's zijn.
Wat als dit een bedrijf is dat wereldwijd opereert en ongeveer evenveel klanten heeft uit Rusland als ergens anders in de wereld? De connectiviteit van de segmenten is belangrijk en ze moeten op de een of andere manier met elkaar samenwerken.
Eind maart 2018 stuurde Roskomnadzor een brief naar de grootste operators waarin hij verklaarde dat ze van plan waren enkele miljoenen Amazon-IP's te blokkeren om... de Zello-messenger te blokkeren. Dankzij dezelfde providers lekten ze de brief met succes naar iedereen, en er was begrip dat de verbinding met Amazon uiteen zou kunnen vallen. Het was vrijdag, we renden in paniek naar onze collega's van servers.ru met de woorden: "Vrienden, we hebben verschillende servers nodig die zich niet in Rusland, niet in Amazon, maar bijvoorbeeld ergens in Amsterdam zullen bevinden", om daar op zijn minst op de een of andere manier onze eigen VPN en proxy te kunnen installeren voor sommige eindpunten die we op geen enkele manier kunnen beïnvloeden, bijvoorbeeld eindpunten van dezelfde s3 - we kunnen niet proberen een nieuwe dienst op te zetten en een andere te krijgen ip, we moeten er nog komen. In slechts een paar dagen hebben we deze servers opgezet, operationeel gemaakt en ons in het algemeen voorbereid op het moment dat de blokkering begon. Het is merkwaardig dat RKN, kijkend naar de ophef en paniek, zei: “Nee, we gaan nu niets blokkeren.” (Maar dit is precies tot het moment waarop Telegram begon te worden geblokkeerd.) Nadat we de bypass-mogelijkheden hadden opgezet en beseften dat de blokkering niet was ingevoerd, begonnen we echter niet de hele zaak op te lossen. Ja, voor het geval dat.
En anno 2019 leven we nog steeds in omstandigheden van blokkering. Ik keek gisteravond: ongeveer een miljoen IP's worden nog steeds geblokkeerd. Het is waar dat Amazon bijna volledig werd gedeblokkeerd, op zijn hoogtepunt bereikte het 20 miljoen adressen... Over het algemeen is de realiteit dat er misschien geen sprake is van coherentie, maar van goede coherentie. Plotseling. Het kan zijn dat het om technische redenen niet bestaat: branden, graafmachines, dat soort dingen. Of, zoals we hebben gezien, niet geheel technisch. Daarom kan iemand die groot en groot is, met zijn eigen AS, dit waarschijnlijk op andere manieren regelen - directe verbindingen en andere dingen bevinden zich al op het l2-niveau. Maar in een eenvoudige versie, zoals de onze of zelfs kleiner, kun je, voor het geval dat, redundantie hebben op het niveau van servers die ergens anders zijn geplaatst, vooraf geconfigureerd vpn, proxy, met de mogelijkheid om de configuratie snel naar hen over te schakelen in die segmenten die cruciaal zijn voor uw connectiviteit. Dit kwam ons meer dan eens van pas, toen de blokkering van Amazon begon; in het ergste geval lieten we alleen S3-verkeer door, maar geleidelijk werd dit allemaal opgelost.
Hoe reserveert u... een hele aanbieder?
Op dit moment hebben we geen scenario voor het geval de hele Amazone ten onder gaat. We hebben een soortgelijk scenario voor Rusland. In Rusland werden we gehost door één provider, van wie we ervoor kozen om meerdere sites te hebben. En een jaar geleden stonden we voor een probleem: ook al zijn het twee datacenters, het kan zijn dat er al problemen zijn op het niveau van de netwerkconfiguratie van de provider die nog steeds gevolgen zullen hebben voor beide datacenters. En het kan zijn dat we op beide sites niet beschikbaar zijn. Natuurlijk is dat wat er gebeurde. Uiteindelijk hebben we de architectuur binnenin heroverwogen. Het is niet veel veranderd, maar voor Rusland hebben we nu twee sites, die niet van dezelfde provider zijn, maar van twee verschillende. Als het een niet lukt, kunnen we overstappen op het andere.
Hypothetisch gezien overwegen we voor Amazon de mogelijkheid om te reserveren op het niveau van een andere aanbieder; misschien Google, misschien iemand anders... Maar tot nu toe hebben we in de praktijk vastgesteld dat hoewel Amazon ongelukken heeft op het niveau van één beschikbaarheidszone, ongelukken op het niveau van een hele regio vrij zeldzaam zijn. We hebben daarom theoretisch het idee dat we misschien wel een “Amazon is not Amazon” reservering zouden maken, maar in de praktijk is dit nog niet het geval.
Een paar woorden over automatisering
Is automatisering altijd nodig? Hier is het passend om het Dunning-Kruger-effect in herinnering te brengen. Op de “x”-as staat onze kennis en ervaring die we opdoen, en op de “y”-as staat het vertrouwen in ons handelen. In eerste instantie weten we niets en zijn we er helemaal niet zeker van. Dan weten we een beetje en worden we mega zelfverzekerd - dit is de zogenaamde “piek van domheid”, goed geïllustreerd door het plaatje “dementie en moed”. Dan hebben we een beetje geleerd en zijn we klaar om de strijd aan te gaan. Dan maken we een aantal mega-ernstige fouten en komen we in een vallei van wanhoop terecht, terwijl we iets lijken te weten, maar in feite niet veel weten. Naarmate we meer ervaring opdoen, krijgen we meer zelfvertrouwen.
Onze logica over de verschillende automatische omschakelingen op bepaalde ongelukken wordt heel goed beschreven in deze grafiek. We zijn begonnen - we wisten niet hoe we iets moesten doen, bijna al het werk werd met de hand gedaan. Toen beseften we dat we aan alles automatisering konden koppelen en rustig konden slapen. En plotseling stappen we op een mega-hark: er wordt een false positive geactiveerd en we schakelen het verkeer heen en weer terwijl we dit op een goede manier niet hadden moeten doen. Het gevolg is dat de replicatie mislukt of iets anders – dit is precies het dal van de wanhoop. En dan komen we tot het inzicht dat we alles verstandig moeten benaderen. Dat wil zeggen, het is logisch om te vertrouwen op automatisering, die de mogelijkheid van vals alarm biedt. Maar! als de gevolgen verwoestend kunnen zijn, dan is het beter om het over te laten aan de dienstploeg, aan de dienstdoende ingenieurs, die ervoor zullen zorgen en monitoren dat er werkelijk een ongeval plaatsvindt, en de nodige acties handmatig zullen uitvoeren...
Conclusie
In de loop van zeven jaar zijn we van het feit dat er iets viel, er sprake was van paniek-paniek, gegaan naar het inzicht dat problemen niet bestaan, er zijn alleen maar taken, die moeten – en kunnen – worden opgelost. Wanneer u een dienst bouwt, bekijk deze dan van bovenaf en beoordeel alle risico's die kunnen optreden. Als je ze meteen ziet, zorg dan vooraf voor redundantie en de mogelijkheid om een fouttolerante infrastructuur op te bouwen, want elk punt dat kan falen en tot de inoperabiliteit van de dienst kan leiden, zal dit zeker doen. En zelfs als het je lijkt dat sommige elementen van de infrastructuur zeker niet zullen falen - zoals dezelfde s7, houd er dan rekening mee dat ze dat wel kunnen. En heb in ieder geval in theorie een idee van wat je ermee gaat doen als er toch iets gebeurt. Zorg voor een risicobeheerplan. Wanneer u overweegt om alles automatisch of handmatig te doen, beoordeel dan de risico’s: wat zal er gebeuren als de automatisering alles gaat schakelen – zal dit niet leiden tot een nog ergere situatie vergeleken met een ongeval? Misschien is het ergens nodig om een redelijk compromis te sluiten tussen het gebruik van automatisering en de reactie van de dienstdoende ingenieur, die het werkelijke beeld zal beoordelen en zal begrijpen of er ter plekke iets moet worden geschakeld of ‘ja, maar niet nu’.
Een redelijk compromis tussen perfectionisme en echte inspanning, tijd en geld dat u kunt besteden aan het plan dat u uiteindelijk zult hebben.
Deze tekst is een bijgewerkte en uitgebreide versie van het rapport van Alexander Demidov op de conferentie .
Bron: www.habr.com