Tot op datum het die Bitrix24-diens nie honderde gigabits verkeer nie, daar is geen groot vloot bedieners nie (hoewel daar natuurlik 'n hele paar bestaandes is). Maar vir baie kliënte is dit die belangrikste hulpmiddel om in die maatskappy te werk, dit is 'n regte besigheidskritiese toepassing. Daarom is val, wel, onmoontlik. Maar wat as die sondeval wel gebeur het, maar die diens het so vinnig “opgestaan” dat niemand iets opgemerk het nie? En hoe is dit moontlik om failover te implementeer sonder om die kwaliteit van werk en die aantal kliënte te verloor? Alexander Demidov, direkteur van wolkdienste by Bitrix24, het vir ons blog gepraat oor hoe die besprekingstelsel oor die 7 jaar van die produk se bestaan ontwikkel het.
“In die vorm van SaaS het ons Bitrix24 7 jaar gelede bekendgestel. Die grootste probleem was waarskynlik die volgende: voor die openbare bekendstelling in die vorm van SaaS, het hierdie produk bloot in die formaat van 'n boksoplossing bestaan. Kliënte het dit by ons gekoop, dit op hul bedieners gehuisves, 'n korporatiewe portaal begin - 'n algemene oplossing vir werknemerkommunikasie, lêerberging, taakbestuur, CRM, dis al. En ons het teen 2012 besluit dat ons dit as 'n SaaS wil bekendstel, dit self administreer, wat foutverdraagsaamheid en betroubaarheid bied. Ons het ondervinding in die proses opgedoen, want tot dan het ons dit eenvoudig nie gehad nie – ons was net sagtewarevervaardigers, nie diensverskaffers nie.
Met die bekendstelling van die diens, het ons verstaan dat die belangrikste ding is om foutverdraagsaamheid, betroubaarheid en konstante beskikbaarheid van die diens te verseker, want as jy 'n eenvoudige gereelde webwerf, 'n winkel, byvoorbeeld, en dit crash en lê vir 'n uur, net jy self ly, jy verloor bestellings, jy verloor kliënte, maar vir jou kliënt self is dit nie baie krities vir hom nie. Hy was natuurlik ontsteld, maar het op 'n ander perseel gaan koop. En as dit 'n toepassing is waaraan alle werk binne die maatskappy, kommunikasie, oplossings gekoppel is, dan is die belangrikste ding om die vertroue van gebruikers te wen, dit wil sê om hulle nie in die steek te laat nie en nie te val nie. Want al die werk kan opstaan as iets binne nie werk nie.
Bitrix.24 as SaaS
Ons het die eerste prototipe 'n jaar voor die openbare bekendstelling, in 2011, saamgestel. Hulle het dit in omtrent 'n week aanmekaargesit, daarna gekyk, dit gedraai - dit het selfs gewerk. Dit wil sê, dit was moontlik om in die vorm in te gaan, die naam van die portaal daar in te voer, 'n nuwe portaal is ontplooi, 'n gebruikersbasis is begin. Ons het daarna gekyk, die produk in beginsel geëvalueer, dit afgeskakel en dit vir 'n hele jaar verder verfyn. Omdat ons 'n groot taak gehad het: ons wou nie twee verskillende kodebasisse maak nie, ons wou nie 'n aparte boksproduk, aparte wolkoplossings ondersteun nie, ons wou dit alles binne een kode doen.
'n Tipiese webtoepassing op daardie tydstip is een bediener waarop 'n soort php-kode, mysql-databasis loop, lêers opgelaai word, dokumente, prente in die oplaai-lêergids geplaas word - wel, dit werk alles. Helaas, dit is onmoontlik om 'n krities stabiele webdiens hieroor te bedryf. Verspreide kas word nie daar ondersteun nie, databasisreplikasie word nie ondersteun nie.
Ons het vereistes geformuleer: dit is die vermoë om op verskillende plekke geleë te wees, replikasie te ondersteun, ideaal gesproke, in verskillende geografies verspreide datasentrums geleë te wees. Skei die logika van die produk en, in werklikheid, databerging. Dinamies in staat wees om te skaal volgens die las, neem statika in die algemeen uit. Uit hierdie oorwegings is trouens die vereistes vir die produk gevorm, wat ons net vir 'n jaar besig is om te finaliseer. Gedurende hierdie tyd, in 'n platform wat verenig blyk te wees - vir boksoplossings, vir ons eie diens - het ons ondersteuning gemaak vir die dinge wat ons nodig gehad het. Ondersteuning vir mysql-replikasie op die vlak van die produk self: dit wil sê, die ontwikkelaar wat die kode skryf, dink nie aan hoe sy versoeke versprei sal word nie, hy gebruik ons api, en ons kan skryf- en leesversoeke tussen meesters en slawe korrek versprei .
Ons het ondersteuning op produkvlak gemaak vir verskeie wolkvoorwerpbergings: Google-berging, Amazon s3, - plus, ondersteuning vir oopstapel-swift. Daarom was dit gerieflik vir ons as 'n diens en vir ontwikkelaars wat met 'n doosoplossing werk: as hulle net ons API vir werk gebruik, dink hulle nie aan waar die lêer uiteindelik gestoor sal word nie, plaaslik op die lêerstelsel of gaan in die objeklêerberging in.
Gevolglik het ons dadelik besluit dat ons op die vlak van die hele datasentrum sal rugsteun. In 2012 het ons geheel en al op Amazon AWS bekendgestel, want ons het reeds ondervinding met hierdie platform gehad – ons eie webwerf is daar gehuisves. Ons was aangetrokke deur die feit dat daar in elke streek in Amazon verskeie beskikbaarheidsones is - in werklikheid (in hul terminologie) verskeie datasentrums wat min of meer onafhanklik van mekaar is en ons toelaat om op die vlak van die hele data te reserveer sentrum: as dit skielik misluk, word die databasisse deur meester-meester gerepliseer, die webtoepassingsbedieners word gereserveer, en die statiese word na die s3-objekberging geskuif. Die vrag is gebalanseer - destyds deur Amazon se elb, maar 'n bietjie later het ons by ons eie balanseerders gekom, want ons het meer komplekse logika nodig gehad.
Wat hulle wou hê, het hulle gekry...
Al die basiese dinge wat ons wou verskaf - die fouttoleransie van die bedieners self, webtoepassings, databasisse - alles het goed gewerk. Die eenvoudigste scenario: as een van die webtoepassings misluk, dan is alles eenvoudig - hulle is afgeskakel van balansering.
Die balanseerder (toe was dit Amazon se elb) wat mislukte masjiene self as ongesond gemerk het, het die vragverspreiding op hulle afgeskakel. Amazon-outoskaling het gewerk: toe die vrag gegroei het, is nuwe motors by die outoskaalgroep gevoeg, die vrag is na nuwe motors versprei - alles was reg. Met ons balanseerders is die logika ongeveer dieselfde: as iets met die toepassingsbediener gebeur, verwyder ons versoeke daarvan, gooi hierdie masjiene uit, begin nuwes en werk voort. Die skema het oor die jare 'n bietjie verander, maar werk steeds: dit is eenvoudig, verstaanbaar en daar is geen probleme hiermee nie.
Ons werk oor die hele wêreld, kliënteladingspieke verskil heeltemal, en op 'n goeie manier behoort ons te eniger tyd sekere dienswerk op enige komponente van ons stelsel te kan uitvoer - onmerkbaar vir kliënte. Daarom het ons die geleentheid om die databasis af te sluit deur die las op die tweede datasentrum te herverdeel.
Hoe werk dit alles? - Ons skakel verkeer oor na 'n werkende datasentrum - as dit 'n ongeluk by die datasentrum is, dan heeltemal, as dit ons beplande werk met enige databasis is, dan skakel ons 'n deel van die verkeer wat hierdie kliënte bedien na die tweede datasentrum, dit is opgeskorte replikasie. As nuwe masjiene vir webtoepassings benodig word, aangesien die las op die tweede datasentrum toegeneem het, sal hulle outomaties begin. Ons voltooi die werk, replikasie word herstel en ons gee die hele vrag terug. As ons werk in die tweede DC moet weerspieël, byvoorbeeld, stelselopdaterings installeer of instellings in die tweede databasis verander, dan herhaal ons in die algemeen dieselfde ding, net in die ander rigting. En as dit 'n ongeluk is, doen ons alles eenvoudig: ons gebruik die gebeurtenis-hanteerders-meganisme in die moniteringstelsel. As verskeie kontroles vir ons werk en die status raak krities, dan word hierdie hanteerder geloods, 'n hanteerder wat hierdie of daardie logika kan uitvoer. Vir elke databasis het ons geskryf watter bediener 'n failover daarvoor is, en waar om verkeer te verander as dit nie beskikbaar is nie. Ons - soos dit histories gebeur het - gebruik nagios of enige van sy vurke in een of ander vorm. In beginsel is daar soortgelyke meganismes in byna enige moniteringstelsel, ons gebruik nog nie iets meer kompleks nie, maar miskien sal ons eendag. Nou word monitering veroorsaak deur onbeskikbaarheid en het dit die vermoë om iets te verander.
Het ons alles gereserveer?
Ons het baie klante uit die VSA, baie klante uit Europa, baie klante wat nader aan die Ooste is – Japan, Singapoer ensovoorts. Natuurlik, 'n groot deel van die kliënte in Rusland. Dit wil sê, die werk is ver van een streek af. Gebruikers wil 'n vinnige reaksie hê, daar is vereistes om aan verskeie plaaslike wette te voldoen, en binne elke streek bespreek ons twee datasentrums, plus daar is 'n paar bykomende dienste wat weer gerieflik binne een streek geplaas is - vir kliënte wat in hierdie streek is werk. REST-hanteerders, magtigingsbedieners, hulle is minder krities vir die kliënt se werk in die algemeen, jy kan dit met 'n klein aanvaarbare vertraging oorskakel, maar jy wil nie die wiel heruitvind, hoe om hulle te monitor en wat om daarmee te doen nie. Daarom probeer ons bestaande oplossings maksimaal gebruik en nie 'n soort bevoegdheid in bykomende produkte ontwikkel nie. En iewers gebruik ons omskakeling op die dns-vlak, en die lewendigheid van die diens word deur dieselfde dns bepaal. Amazon het 'n Route 53-diens, maar dit is nie net dns nie, waar jy rekords kan maak en dit is dit - dit is baie meer buigsaam en gerieflik. Daardeur kan jy geo-verspreide dienste met geo-liggings bou, wanneer jy dit gebruik om te bepaal waar die kliënt vandaan kom en vir hom sekere rekords gee – jy kan dit gebruik om failover-argitekture te bou. Dieselfde gesondheidsondersoeke word in Roete 53 self gekonfigureer, jy stel die eindpunt wat gemonitor word, stel die maatstawwe in, stel watter protokolle om die "lewendigheid" van die diens te bepaal - tcp, http, https; stel die frekwensie van tjeks in wat bepaal of die diens lewendig is of nie. En in die dns self skryf jy voor wat primêr sal wees, wat sekondêr sal wees, waar om oor te skakel as gesondheidsondersoek binne roete 53 werk. Dit alles kan met 'n paar ander gereedskap gedoen word, maar wat geriefliker is, is dat ons dit opstel eens en dan glad nie daaraan dink hoe ons tjeks doen, hoe ons oorskakel nie: alles werk vanself.
Die eerste "maar": hoe en hoe om roete 53 self te bespreek? Jy weet nooit, skielik gebeur iets met hom? Gelukkig het ons nog nooit op hierdie hark getrap nie, maar weereens sal ek 'n storie voor my hê hoekom ons gedink het ons moet nog bespreek. Hier maak ons vooraf vir ons strooi. Ons doen 'n paar keer per dag 'n volledige aflaai van alle sones wat ons op roete 53 het. Amazon se API laat jou toe om dit maklik na JSON te stuur, en ons het verskeie rugsteunbedieners waar ons dit omskakel, dit in die vorm van konfigurasies oplaai en, rofweg gesproke, 'n rugsteunkonfigurasie het. In welke geval ons dit vinnig met die hand kan ontplooi sonder om dns-instellingsdata te verloor.
Tweede "maar": Wat is nog nie in hierdie prent gereserveer nie? Die Balanser! Ons verspreiding van kliënte per streek is baie eenvoudig. Ons het bitrix24.ru, bitrix24.com, .de domeine - nou is daar 13 verskillendes wat in 'n verskeidenheid sones werk. Ons het tot die volgende gekom: elke streek het sy eie balanseerders. Dit is dus geriefliker om per streek te versprei, afhangend van waar die pieklas op die netwerk is. As dit 'n mislukking op die vlak van enige balanseerder is, word dit eenvoudig uit diens gestel en van dns verwyder. As daar een of ander probleem met 'n groep balanseerders is, dan word hulle by ander terreine gereserveer, en skakeling tussen hulle word gedoen deur dieselfde roete53 te gebruik, want as gevolg van 'n kort ttl vind oorskakeling binne 'n maksimum van 2, 3, 5 minute plaas.
Derde "maar": wat is nog nie gereserveer nie? S3 is korrek. Ons, wat die lêers wat ons stoor by gebruikers in s3 geplaas het, het opreg geglo dat dit pantserdeurdringend was en dat dit nie nodig was om iets daar te bespreek nie. Maar die geskiedenis wys dat dinge anders is. Oor die algemeen beskryf Amazon S3 as 'n fundamentele diens, want Amazon gebruik self S3 om masjienbeelde, konfigurasies, AMI-beelde, momentopnames te stoor ... En as s3 val, soos dit eens in hierdie 7 jaar gebeur het, hoeveel bitrix24 het ons al gehad werk, sal dit uitwaai trek 'n klomp van alles - die ontoeganklikheid van die begin van virtuele masjiene, die mislukking van die API, ensovoorts.
En S3 kan val - dit het een keer gebeur. Daarom het ons met die volgende skema vorendag gekom: 'n paar jaar gelede was daar geen openbare bewaarplekke vir ernstige voorwerpe in Rusland nie, en ons het die opsie oorweeg om iets van ons eie te doen ... Gelukkig het ons dit nie begin doen nie, want ons sou het gegrawe in die kundigheid wat ons nie het nie, en sou waarskynlik gemors het. Nou het Mail.ru s3-versoenbare berging, Yandex het dit, en 'n aantal ander verskaffers het dit. Ons het uiteindelik tot die gevolgtrekking gekom dat ons eerstens oortolligheid wil hê, en tweedens die vermoë om met plaaslike kopieë te werk. Vir 'n spesifieke Russiese streek gebruik ons die Mail.ru Hotbox-diens, wat API-versoenbaar is met s3. Ons het geen ernstige verbeterings aan die kode binne die toepassing nodig gehad nie, en ons het die volgende meganisme gemaak: s3 het snellers wat werk op die skep / verwydering van voorwerpe, Amazon het 'n diens soos Lambda - dit is 'n bedienerlose kode bekendstelling wat uitgevoer sal word net wanneer sekere snellers geaktiveer word.
Ons het dit baie eenvoudig gemaak: as 'n sneller vir ons werk, voer ons die kode uit wat die voorwerp na die Mail.ru-berging sal kopieer. Om werk met plaaslike kopieë van data volledig te begin, het ons ook omgekeerde sinchronisasie nodig sodat kliënte wat in die Russiese segment is, kan werk met berging wat nader aan hulle is. Mail is op die punt om die snellers in sy bewaarplek te voltooi - dit sal moontlik wees om omgekeerde sinchronisasie op die infrastruktuurvlak uit te voer, maar vir nou doen ons dit op die vlak van ons eie kode. As ons sien dat die kliënt 'n lêer geplaas het, plaas ons die gebeurtenis in die tou op die kodevlak, verwerk dit en doen omgekeerde replikasie. Waarom dit sleg is: as ons 'n soort werk met ons voorwerpe buite ons produk het, dit wil sê deur 'n eksterne middel, sal ons dit nie in ag neem nie. Daarom wag ons tot die einde, wanneer daar snellers op die stoorvlak sal wees, sodat dit nie saak maak waar ons die kode uitgevoer het nie, die voorwerp wat by ons uitgekom het, word na die ander kant gekopieer.
Op die kodevlak het ons albei bergings vir elke kliënt: een word as die hoof beskou, die ander is die rugsteun. As alles goed is, werk ons met die berging wat nader aan ons is: dit wil sê, ons kliënte wat in Amazon is, hulle werk met S3, en diegene wat in Rusland werk, hulle werk met Hotbox. As die vlag geaktiveer word, moet failover aan ons gekoppel word, en ons skakel kliënte oor na 'n ander berging. Ons kan hierdie vlag onafhanklik volgens streek stel en kan hulle heen en weer skakel. In die praktyk is dit nog nie gebruik nie, maar daar is vir hierdie meganisme voorsiening gemaak en ons dink dat ons eendag hierdie einste oorskakeling sal nodig hê en handig te pas sal kom. Dit het al een keer gebeur.
O, en jou Amazon het weggehardloop ...
Hierdie April is die herdenking van die begin van Telegram-blokkering in Rusland. Die verskaffer wat die meeste hierdeur geraak word, is Amazon. En ongelukkig het Russiese maatskappye wat vir die hele wêreld gewerk het, meer gely.
As die maatskappy wêreldwyd is en Rusland is 'n baie klein segment daarvoor, 3-5% - wel, op een of ander manier, kan jy hulle skenk.
As dit 'n suiwer Russiese maatskappy is - ek is seker dat dit plaaslik gehuisves moet word - wel, dit is net dat die gebruikers self gemaklik en gemaklik sal wees, daar sal minder risiko's wees.
Maar wat as dit 'n maatskappy is wat wêreldwyd bedrywig is, en dit het ongeveer dieselfde aantal kliënte van Rusland en iewers regoor die wêreld? Die konnektiwiteit van die segmente is belangrik, en hulle moet op een of ander manier met mekaar saamwerk.
Aan die einde van Maart 2018 het Roskomnadzor 'n brief aan die grootste operateurs gestuur dat hulle beplan om 'n paar miljoen Amazon ips te blokkeer om ... die Zello-boodskapper te blokkeer. Danksy hierdie einste verskaffers - hulle het die brief suksesvol aan almal uitgelek, en daar was 'n begrip dat konnektiwiteit met Amazon kon uitmekaar val. Dit was Vrydag, ons het paniekbevange na kollegas van servers.ru gehardloop en gesê: "Vriende, ons benodig verskeie bedieners wat nie in Rusland sal wees nie, nie in Amazon nie, maar, byvoorbeeld, iewers in Amsterdam", om in om ten minste op een of ander manier ons eie vpn en proxy daar te kan plaas vir sommige eindpunte wat ons op geen manier kan beïnvloed nie, byvoorbeeld eindpunte van dieselfde s3 - jy kan nie probeer om 'n nuwe diens in te samel en 'n ander te kry nie ip, ons moet nog daar kom. Binne 'n paar dae het ons hierdie bedieners opgestel, hulle verhoog, en oor die algemeen was ons voorbereid teen die tyd dat die blokkering begin het. Dit is nuuskierig dat die RKN, wat na die ophef en paniek gekyk het, gesê het: "Nee, ons gaan niks nou blokkeer nie." (Maar dit is presies tot die oomblik toe hulle telegramme begin blokkeer het.) Nadat ons die omseilopsies opgestel het en besef het dat die blokkering nie ingestel is nie, het ons nietemin nie begin om die hele ding te ontleed nie. Ja, net vir ingeval.
En in 2019 leef ons steeds in toestande van blokkering. Ek het gisteraand gekyk: ongeveer 'n miljoen ip word steeds geblokkeer. Dit is waar, Amazon was amper heeltemal gedeblokkeer, op die hoogtepunt het dit 20 miljoen adresse bereik ... Oor die algemeen is die realiteit dat daar dalk nie konnektiwiteit is nie, goeie konnektiwiteit. Skielik. Dit is dalk nie om tegniese redes nie – brande, graafmachines, alles. Of, soos ons gesien het, nie heeltemal tegnies nie. Daarom kan iemand groot en groot, met hul eie AS'e, dit waarskynlik op ander maniere stuur - direkte verbinding en ander dinge is reeds op die l2-vlak. Maar in 'n eenvoudige weergawe, soos ons of selfs kleiner, net vir ingeval, kan jy oortolligheid hê op die vlak van bedieners wat iewers anders opgewek is, vooraf gekonfigureer vpn, proxy, met die vermoë om vinnig konfigurasie na hulle oor te skakel in daardie segmente wat jy kritieke konnektiwiteit hê. Dit het meer as een keer vir ons handig te pas gekom toe Amazon-blokke begin het, ons het S3 in die ergste geval daardeur laat verkeer, maar geleidelik het dit alles uitmekaar geval.
En hoe om 'n hele verskaffer te bespreek?
Op die oomblik het ons nie 'n scenario vir die mislukking van die hele Amasone nie. Ons het 'n soortgelyke scenario vir Rusland. In Rusland is ons deur een verskaffer aangebied, wat ons gekies het om verskeie werwe te hê. En 'n jaar gelede het ons 'n probleem teëgekom: al is dit twee datasentrums, kan daar reeds probleme op die verskaffer se netwerkkonfigurasievlak wees wat in elk geval albei datasentrums sal raak. En ons kan onbeskikbaarheid op beide werwe kry. Dit is natuurlik wat gebeur het. Ons het uiteindelik die argitektuur binne hersien. Dit het nie veel verander nie, maar vir Rusland het ons nou twee werwe, wat nie van een verskaffer af is nie, maar van twee verskillende. As een misluk, kan ons na 'n ander oorskakel.
Hipoteties, vir Amazon, oorweeg ons die moontlikheid om op die vlak van 'n ander verskaffer te bespreek; miskien Google, miskien iemand anders ... Maar tot dusver het ons in die praktyk waargeneem dat as Amazon ineenstortings het op die vlak van een beskikbaarheidsone, dan is ineenstortings op die vlak van 'n hele streek redelik skaars. Daarom het ons teoreties 'n idee dat ons 'n Amazon-nie-Amazon-bespreking kan maak, maar in die praktyk is daar nog nie so iets nie.
'N Paar woorde oor outomatisering
Is outomatisering altyd nodig? Hier is dit gepas om die Dunning-Kruger-effek te herroep. Op die x-as is ons kennis en ervaring wat ons opdoen, en op die y-as is vertroue in ons optrede. Ons weet eers niks en is glad nie seker nie. Dan weet ons 'n bietjie en word mega-selfversekerd - dit is die sogenaamde "piek van domheid", goed geïllustreer deur die prentjie "demensie en moed". Dan het ons al 'n bietjie geleer en is gereed om in die geveg te gaan. Dan trap ons op een of ander mega-ernstige hark, ons val in die vallei van wanhoop, wanneer ons blykbaar iets weet, maar eintlik weet ons nie veel nie. Dan, soos ons ondervinding opdoen, word ons meer selfversekerd.
Ons logika oor verskeie oorskakeling outomaties na sekere ongelukke word baie goed beskryf deur hierdie grafiek. Ons het begin - ons het nie geweet hoe nie, amper al die werk is met die hand gedoen. Toe besef ons dat jy outomaties op alles kan sit en soos rustig kan slaap. En skielik trap ons op 'n megahark: vals positiewe werk vir ons, en ons skakel verkeer heen en weer wanneer ons dit op 'n goeie manier nie moes gedoen het nie. Gevolglik breek replikasie of iets anders - dit is die einste vallei van wanhoop. En dan kom ons tot die insig dat alles verstandig behandel moet word. Dit wil sê, dit maak sin om op outomatisering staat te maak, wat voorsiening maak vir die moontlikheid van vals positiewe. Maar! as die gevolge verwoestend kan wees, dan is dit beter om dit aan die genade van die diensskof te laat, die diensingenieurs, wat sal seker maak dat dit werklik 'n ongeluk is, en die nodige aksies sal met die hand uitgevoer word ...
Gevolgtrekking
Vir 7 jaar het ons gegaan van die feit dat wanneer iets geval het, daar paniek-paniek was, na die begrip dat daar geen probleme is nie, daar is net take, dit moet - en kan - opgelos word. Wanneer jy 'n diens bou, kyk daarna van bo af, evalueer al die risiko's wat kan gebeur. As jy hulle dadelik sien, beplan dan vooraf vir oortolligheid en die moontlikheid om 'n foutverdraagsame infrastruktuur te bou, want enige punt wat kan misluk en lei tot die onwerkbaarheid van die diens sal dit beslis doen. En selfs al lyk dit vir jou dat sommige elemente van die infrastruktuur beslis nie sal misluk nie - soos dieselfde s3, moet jy steeds in gedagte hou dat hulle kan. En ten minste in teorie, het 'n idee van wat jy met hulle sal doen as iets wel gebeur. Het 'n risikobestuursplan. As jy daaraan dink om alles outomaties of met die hand te doen, evalueer die risiko's: wat sal gebeur as die outomatisering alles begin verander - sal dit nie tot 'n nog slegter prentjie lei in vergelyking met 'n ongeluk nie? Miskien moet jy iewers 'n redelike kompromie gebruik tussen die gebruik van outomatisering en die reaksie van die ingenieur aan diens, wat die werklike prentjie sal evalueer en verstaan of iets op die pad aangeskakel moet word of "ja, maar nie nou nie".
'n Redelike kompromie tussen perfeksionisme en werklike kragte, tyd, geld wat jy kan spandeer op die skema wat jy uiteindelik sal hê.
Hierdie teks is 'n aangevulde en uitgebreide weergawe van Alexander Demidov se verslag by die konferensie .
Bron: will.com