Tsjintwurdich hat de Bitrix24-tsjinst gjin hûnderten gigabits fan ferkear, noch hat it in enoarme float fan servers (hoewol, fansels, d'r binne nochal in pear besteande). Mar foar in protte kliïnten is it it wichtichste ark foar it wurkjen yn it bedriuw; it is in echte saaklike krityske applikaasje. Dêrom is der gjin manier om te fallen. Wat as it ûngelok barde, mar de tsjinst "werhelle" sa fluch dat gjinien wat fernaam? En hoe is it mooglik om failover út te fieren sûnder de kwaliteit fan it wurk en it oantal kliïnten te ferliezen? Alexander Demidov, direkteur fan wolktsjinsten by Bitrix24, spruts foar ús blog oer hoe't it reservaatsysteem evoluearre is oer de 7 jier fan it bestean fan it produkt.
"Wy lansearren Bitrix24 as SaaS 7 jier lyn. De wichtichste muoite wie wierskynlik de folgjende: foardat it iepenbier waard lansearre as SaaS, bestie dit produkt gewoan yn it formaat fan in doaze oplossing. Klanten kochten it fan ús, hosten it op har servers, sette in bedriuwsportaal op - in algemiene oplossing foar wurknimmerskommunikaasje, bestannen opslach, taakbehear, CRM, dat is alles. En yn 2012 hawwe wy besletten dat wy it as SaaS wolle lansearje, it sels beheare, en soargje foar fouttolerânsje en betrouberens. Wy hawwe ûnderweis ûnderfining opdien, want oant dan hienen wy it gewoan net - wy wiene allinich softwarefabrikanten, gjin tsjinstferlieners.
By it lansearjen fan de tsjinst begrepen wy dat it wichtichste is om te soargjen foar fouttolerânsje, betrouberens en konstante beskikberens fan 'e tsjinst, want as jo in ienfâldige gewoane webside hawwe, bygelyks in winkel, en it falt op jo en sit dêr foar in oere, allinne do lije, do ferlieze oarders , do ferlieze kliïnten, mar foar dyn kliïnt sels, dit is net hiel kritysk foar him. Hy wie fansels oerstjoer, mar hy gie en kocht it op in oare side. En as dit in applikaasje is wêryn al it wurk binnen it bedriuw, kommunikaasje, besluten ferbûn is, dan is it wichtichste om it fertrouwen fan brûkers te winnen, dat is, se net te litten en net te fallen. Want alle wurk kin ophâlde as wat binnen net wurket.
Bitrix.24 as SaaS
Wy hawwe it earste prototype gearstald in jier foar de iepenbiere lansearring, yn 2011. Wy sammele it yn sawat in wike, seagen it, draaiden it - it wurke sels. Dat is, jo kinne yn it formulier gean, dêr de namme fan it portaal ynfiere, in nij portaal soe iepenje, en in brûkersbasis soe wurde makke. Wy hawwe it sjoen, it produkt yn prinsipe beoardiele, it skrast en in hiel jier trochgien mei it ferfine. Om't wy in grutte taak hiene: wy woene gjin twa ferskillende koadebases meitsje, wy woene gjin apart ferpakt produkt, aparte wolkoplossingen stypje - wy woenen it allegear binnen ien koade dwaan.
In typyske webapplikaasje op dat stuit wie ien tsjinner wêrop wat PHP-koade rint, in mysql-database, bestannen wurde opladen, dokuminten, foto's wurde yn 'e uploadmap pleatst - goed, it wurket allegear. Och, it is ûnmooglik om in kritysk stabile webtsjinst te lansearjen mei dit. Dêr wurdt ferspraat cache net stipe, databankreplikaasje wurdt net stipe.
Wy formulearre de easken: dit is de mooglikheid om te lizzen op ferskate lokaasjes, stipe replikaasje, en by útstek te finen yn ferskate geografysk ferspraat datasintra. Skied de produktlogika en, yn feite, gegevens opslach. Wês yn steat om dynamysk te skaaljen neffens de lading, en statyk hielendal tolerearje. Ut dizze ôfwagings kamen trouwens de easken foar it produkt nei foaren, dy't wy yn de rin fan it jier ferfine. Yn dizze tiid, yn it platfoarm, dat ienriedich die bliken te wêzen - foar oplossingen yn doazen, foar ús eigen tsjinst - makken wy stipe foar dy dingen dy't wy nedich wiene. Stipe foar mysql-replikaasje op it nivo fan it produkt sels: dat is, de ûntwikkelder dy't de koade skriuwt, tinkt net oer hoe't syn fersiken sille wurde ferdield, hy brûkt ús api, en wy witte hoe't jo skriuw- en lêsfersiken korrekt kinne fersprieden tusken masters en slaven.
Wy hawwe stipe makke op produktnivo foar ferskate wolkobjektopslaggen: google opslach, Amazon s3, plus stipe foar iepen stack swift. Dêrom wie dit handich sawol foar ús as tsjinst as foar ûntwikkelders dy't wurkje mei in ferpakte oplossing: as se gewoan ús API brûke foar wurk, tinke se net oer wêr't it bestân úteinlik bewarre wurdt, lokaal op it bestânsysteem of yn it opslach fan objekttriem.
As gefolch hawwe wy fuortendaliks besletten dat wy reservearje op it nivo fan it folsleine datasintrum. Yn 2012 lansearren wy folslein op Amazon AWS, om't wy al ûnderfining hiene mei dit platfoarm - ús eigen webside waard dêr hosted. Wy waarden oanlutsen troch it feit dat Amazon yn elke regio ferskate beskikbere sônes hat - yn feite, (yn har terminology) ferskate datasintra dy't min of mear ûnôfhinklik fan elkoar binne en ús kinne reservearje op it nivo fan in folslein datasintrum: as it ynienen mislearret, de databases wurde replicated master-master, de web applikaasje tsjinners wurde reservekopy, en de statyske gegevens wurdt ferpleatst nei de s3 objekt opslach. De lading is balansearre - op dat stuit troch Amazon elb, mar in bytsje letter kamen wy ta ús eigen load balancers, om't wy mear komplekse logika nedich wiene.
Wat se woenen is wat se krigen ...
Alle basis dingen dy't wy soargje woene - fouttolerânsje fan 'e servers sels, webapplikaasjes, databases - alles wurke goed. It ienfâldichste senario: as ien fan ús webapplikaasjes mislearret, dan is alles ienfâldich - se wurde útskeakele fan balânsjen.
De balancer (op dat stuit wie it Amazon's elb) markearre masines dy't net yn 'e oarder wiene as ûnsûn en skeakele de ladingferdieling op har út. Amazon autoscaling wurke: doe't de lading groeide, nije masines waarden tafoege oan de autoscaling groep, de lading waard ferdield nei nije masines - alles wie goed. Mei ús balancers is de logika sawat itselde: as der wat bart mei de applikaasje-tsjinner, ferwiderje wy fersiken derfan, smyt dizze masines út, begjinne nije en wurkje troch. It skema is in bytsje feroare yn 'e rin fan' e jierren, mar bliuwt te wurkjen: it is ienfâldich, begryplik, en d'r binne gjin swierrichheden mei.
Wy wurkje oer de hiele wrâld, de pieken fan klantlast binne folslein oars, en, op in freonskiplike manier, soene wy op elk momint beskate tsjinstferliening moatte kinne útfiere oan alle komponinten fan ús systeem - ûngemurken troch klanten. Dêrom hawwe wy de kâns om de databank út te skeakeljen fan operaasje, de lading opnij te ferdielen nei in twadde datasintrum.
Hoe wurket it allegear? - Wy wikselje ferkear nei in wurkjend datasintrum - as d'r in ûngelok is yn it datasintrum, dan folslein, as dit ús plande wurk is mei ien database, dan wikselje wy in diel fan it ferkear dat dizze kliïnten tsjinnet nei in twadde datasintrum, ophâlde it replikaasje. As nije masines nedich binne foar webapplikaasjes om't de lading op it twadde datasintrum ferhege is, sille se automatysk begjinne. Wy meitsje it wurk ôf, replikaasje wurdt restaurearre, en wy jouwe de folsleine lading werom. As wy moatte wjerspegelje wat wurk yn de twadde DC, bygelyks, ynstallearje systeem updates of feroarje ynstellings yn de twadde databank, dan, yn it algemien, wy werhelje itselde ding, krekt yn 'e oare rjochting. En as dit in ûngelok is, dan dogge wy alles triviaal: wy brûke it meganisme fan event-handlers yn it tafersjochsysteem. As ferskate kontrôles wurde aktivearre en de status giet nei kritysk, dan rinne wy dizze handler, in handler dy't dizze of dy logika útfiere kin. Foar eltse databank spesifisearje wy hokker tsjinner is de failover foar it, en wêr't ferkear moat wurde oerskeakele as it is net beskikber. Histoarysk brûke wy nagios of guon fan har foarken yn ien of oare foarm. Yn prinsipe besteane ferlykbere meganismen yn hast elk tafersjochsysteem; wy brûke noch neat komplekser, mar miskien wol ienris. No wurdt tafersjoch trigger troch ûnbeskikberens en hat de mooglikheid om wat te wikseljen.
Hawwe wy alles reservearre?
Wy hawwe in protte kliïnten út 'e FS, in protte kliïnten út Jeropa, in protte kliïnten dy't tichter by it Easten binne - Japan, Singapore ensafuorthinne. Fansels, in grut part fan de kliïnten binne yn Ruslân. Dat is, wurk is net yn ien regio. Brûkers wolle in rappe reaksje, d'r binne easken om te foldwaan oan ferskate pleatslike wetten, en binnen elke regio reservearje wy twa datasintra, plus d'r binne wat ekstra tsjinsten, dy't, wer, handich binne om binnen ien regio te pleatsen - foar kliïnten dy't yn binne dizze regio wurket. REST-hannelers, autorisaasjeservers, se binne minder kritysk foar de wurking fan 'e kliïnt as gehiel, jo kinne troch har wikselje mei in lyts akseptabel fertraging, mar jo wolle it tsjil net opnij útfine oer hoe't jo se kontrolearje en wat te dwaan mei harren. Dêrom besykje wy besteande oplossingen maksimaal te brûken, ynstee fan in soarte fan kompetinsje te ûntwikkeljen yn ekstra produkten. En earne brûke wy triviaal skeakeljen op it DNS-nivo, en wy bepale de libbenens fan 'e tsjinst troch deselde DNS. Amazon hat in Route 53-tsjinst, mar it is net allinich in DNS wêryn jo yngongen kinne meitsje en dat is it - it is folle fleksibeler en handiger. Troch it kinne jo geo-ferspraat tsjinsten bouwe mei geolokaasjes, as jo it brûke om te bepalen wêr't de kliïnt weikomt en him bepaalde records jaan - mei har help kinne jo failover-arsjitektuer bouwe. Deselde sûnenskontrôles binne konfigureare yn Rûte 53 sels, jo sette de einpunten yn dy't wurde kontrolearre, set metriken yn, set hokker protokollen om de "libbens" fan 'e tsjinst te bepalen - tcp, http, https; set de frekwinsje fan kontrôles dy't bepale oft de tsjinst libbet of net. En yn 'e DNS sels spesifisearje jo wat primêr sil wêze, wat sekundêr sil wêze, wêr't jo moatte wikselje as de sûnenskontrôle yn rûte 53 wurdt aktivearre. Dit alles kin dien wurde mei guon oare ark, mar wêrom is it handich - wy sette it yn ien kear op en tink der dan hielendal net oer hoe't wy kontrôles dogge, hoe't wy wikselje: alles wurket op himsels.
De earste "mar": hoe en mei wat te reservearjen rûte 53 sels? Wa wit, wat as him wat oerkomt? Gelokkich binne wy nea op dizze hark trape, mar nochris sil ik in ferhaal foarút hawwe wêrom't wy tochten dat wy noch in reservearje moasten. Hjir leine wy foarôf foar ússels strie út. Ferskate kearen deis dogge wy in folsleine lossing fan alle sônes dy't wy hawwe yn rûte 53. Amazon's API lit jo se maklik yn JSON stjoere, en wy hawwe ferskate reservekopyservers wêr't wy it konvertearje, it uploade yn 'e foarm fan konfiguraasjes en hawwe, rûchwei sprutsen, in backupkonfiguraasje. As der wat bart, kinne wy it fluch manuell ynsette sûnder de DNS-ynstellingsgegevens te ferliezen.
twadde "mar": Wat op dizze foto is noch net reservearre? De balancer sels! Us ferdieling fan kliïnten per regio is heul ienfâldich makke. Wy hawwe de domeinen bitrix24.ru, bitrix24.com, .de - no binne d'r 13 ferskillende, dy't wurkje yn in ferskaat oan sônes. Wy kamen ta it folgjende: elke regio hat syn eigen balancers. Dit makket it handiger om te fersprieden oer regio's, ôfhinklik fan wêr't de pyklast op it netwurk is. As dit in mislearring is op it nivo fan ien balancer, dan wurdt it gewoan út 'e tsjinst nommen en út' e dns fuortsmiten. As d'r wat probleem is mei in groep balancers, dan wurde se op oare siden opslein, en it wikseljen tusken har wurdt dien mei deselde route53, om't troch de koarte TTL, it wikseljen binnen maksimaal 2, 3, 5 minuten bart .
Tredde "mar": Wat is noch net reservearre? s3, krekt. Doe't wy de bestannen pleatsten dy't wy foar brûkers opslaan yn s3, leauden wy oprjocht dat it pânserpiercing wie en d'r gjin need wie om dêr neat te reservearjen. Mar de skiednis lit sjen dat dingen oars barre. Yn 't algemien beskriuwt Amazon S3 as in fûnemintele tsjinst, om't Amazon sels S3 brûkt om masineôfbyldings, konfiguraasjes, AMI-ôfbyldings, snapshots op te slaan ... En as s3 crasht, lykas ienris barde yn dizze 7 jier, sa lang as wy hawwe brûkt bitrix24, it folget it as in fan.
En S3 kin falle - it barde ien kear. Dêrom kamen wy ta it folgjende skema: in pear jier lyn wiene d'r gjin serieuze opslachfoarsjenningen foar iepenbiere objekten yn Ruslân, en wy hawwe de opsje beskôge om wat fan ús eigen te dwaan ... Gelokkich binne wy dit net begon te dwaan, om't wy soene hawwe groeven yn 'e saakkundigens dy't wy net hawwe dy't wy hawwe, en soe wierskynlik fergrieme. No hat Mail.ru s3-kompatibele opslach, Yandex hat it, en in oantal oare providers hawwe it. Wy kamen úteinlik op it idee dat wy as earste reservekopy wolle hawwe, en twadde de mooglikheid om te wurkjen mei lokale kopyen. Foar de Russyske regio spesifyk brûke wy de Mail.ru Hotbox-tsjinst, dy't API-kompatibel is mei s3. Wy hawwe gjin grutte wizigingen nedich oan 'e koade yn' e applikaasje, en wy hawwe it folgjende meganisme makke: yn s3 binne d'r triggers dy't it oanmeitsjen / wiskjen fan objekten triggerje, Amazon hat in tsjinst mei de namme Lambda - dit is in serverless lansearring fan koade dat sil wurde útfierd krekt as bepaalde triggers wurde aktivearre.
Wy diene it heul ienfâldich: as ús trigger brânt, fiere wy koade út dy't it objekt sil kopiearje nei de Mail.ru-opslach. Om folslein wurk te starten mei lokale kopyen fan gegevens, hawwe wy ek reverse syngronisaasje nedich, sadat kliïnten dy't yn it Russyske segmint binne kinne wurkje mei opslach dy't tichter by har is. Mail stiet op it punt om triggers yn har opslach te foltôgjen - it sil mooglik wêze om reverse syngronisaasje út te fieren op it ynfrastruktuernivo, mar foar no dogge wy dit op it nivo fan ús eigen koade. As wy sjogge dat in kliïnt in bestân pleatst hat, dan pleatse wy op it koadenivo it evenemint yn in wachtrige, ferwurkje it en dogge reverse replikaasje. Wêrom is it min: as wy in soarte fan wurk dogge mei ús objekten bûten ús produkt, dat is, troch guon eksterne middels, sille wy it net yn 'e rekken hâlde. Dêrom wachtsje wy oant it ein, as triggers ferskine op it opslachnivo, sadat nettsjinsteande wêr't wy de koade útfiere, it objekt dat by ús kaam wurdt kopiearre yn 'e oare rjochting.
Op it koadenivo registrearje wy beide opslach foar elke kliïnt: ien wurdt beskôge as de wichtichste, de oare wurdt beskôge as in reservekopy. As alles goed is, wurkje wy mei de opslach dy't tichter by ús is: dat is ús kliïnten dy't yn Amazon binne, se wurkje mei S3, en dyjingen dy't wurkje yn Ruslân, se wurkje mei Hotbox. As de flagge wurdt aktivearre, dan failover moatte wurde ferbûn, en wy wikselje kliïnten nei in oare opslach. Wy kinne dit fakje ûnôfhinklik per regio kontrolearje en kinne se hinne en wer wikselje. Wy hawwe dit noch net yn 'e praktyk brûkt, mar wy hawwe foar dit meganisme foarsjoen en wy tinke dat wy ienris dizze skeakel nedich binne en fan pas komme. Dit is al ien kear bard.
Oh, en Amazon rûn fuort ...
Dizze april markearret it jubileum fan it begjin fan Telegram-blokkering yn Ruslân. De meast troffen provider dy't ûnder dit foel is Amazon. En, spitigernôch, hawwe Russyske bedriuwen dy't wurken foar de hiele wrâld mear te lijen.
As it bedriuw wrâldwiid is en Ruslân is in heul lyts segmint dêrfoar, 3-5% - goed, op ien of oare manier kinne jo se opofferje.
As dit in suver Russysk bedriuw is - ik bin der wis fan dat it lokaal lizze moat - goed, it sil gewoan handich wêze foar de brûkers sels, noflik, en d'r sille minder risiko's wêze.
Wat as dit in bedriuw is dat wrâldwiid wurket en sawat likefolle klanten hat út Ruslân en earne om 'e wrâld? De ferbining fan 'e segminten is wichtich, en se moatte op ien of oare manier mei elkoar wurkje.
Oan 'e ein fan maart 2018 stjoerde Roskomnadzor in brief oan' e grutste operators dy't stelde dat se plannen om ferskate miljoen Amazon IP's te blokkearjen om te blokkearjen ... de Zello-messenger. Mei tank oan dizze deselde providers - se lekten mei súkses de brief oan elkenien, en der wie in begryp dat de ferbining mei Amazon koe falle útinoar. It wie freed, wy rûnen yn panyk nei ús kollega's fan servers.ru, sizzende: "Freonen, wy hawwe ferskate servers nedich dy't net yn Ruslân sille lizze, net yn Amazon, mar, bygelyks, earne yn Amsterdam," om om op syn minst op ien of oare manier ús eigen VPN en proxy dêr te ynstallearjen foar guon einpunten dy't wy op gjin inkelde manier kinne beynfloedzje, bygelyks endponts fan deselde s3 - wy kinne net besykje in nije tsjinst op te heljen en in oare ip te krijen, wy moatte der noch komme. Yn mar in pear dagen hawwe wy dizze servers ynsteld, se ynsteld en yn 't algemien taret op it momint dat it blokkearjen begon. It is nijsgjirrich dat RKN, sjoen nei de drokte en panyk, sei: "Nee, wy sille no neat blokkearje." (Mar dit is krekt oant it momint dat Telegram begon te blokkearjen.) Nei't wy de bypass-mooglikheden ynsteld hawwe en realisearre dat de blokkearjen net ynfierd wie, binne wy lykwols net begon om de hiele saak út te sortearjen. Ja, foar it gefal.
En yn 2019 libje wy noch yn betingsten fan blokkearjen. Ik seach fannacht: sawat in miljoen IP's bliuwe blokkearre. Wier, Amazon waard hast folslein deblokkearre, op syn hichtepunt berikte it 20 miljoen adressen ... Yn 't algemien is de realiteit dat d'r miskien gjin gearhing is, goede gearhing. Ynienen. It kin net bestean om technyske redenen - brânen, graafmasines, dat alles. Of, lykas wy hawwe sjoen, net hielendal technysk. Dêrom kin immen grut en grut, mei har eigen AS's, dit wierskynlik op oare manieren beheare - direkte ferbining en oare dingen binne al op it l2-nivo. Mar yn in ienfâldige ferzje, lykas uzes of noch lytser, kinne jo, foar it gefal, oerstalligens hawwe op it nivo fan servers dy't earne oars opwekke binne, foarôf konfigureare vpn, proxy, mei de mooglikheid om de konfiguraasje fluch nei har te wikseljen yn dy segminten dy't kritysk binne foar jo ferbining. Dit kaam ús mear as ien kear fan pas, doe't Amazon's blokkearjen begon; yn it slimste gefal lieten wy allinich S3-ferkear troch har ta, mar stadichoan waard dit alles oplost.
Hoe reservearje ... in hiele provider?
Op it stuit hawwe wy gjin senario foar it gefal dat de heule Amazone ûndergiet. Wy hawwe in ferlykber senario foar Ruslân. Yn Ruslân waarden wy hosted troch ien provider, fan wa't wy keazen hawwe om ferskate siden te hawwen. En in jier lyn stiene wy foar in probleem: ek al binne dit twa datasintra, der kinne al problemen wêze op it nivo fan 'e netwurkkonfiguraasje fan' e provider dy't beide datasintra noch beynfloedzje. En wy kinne einigje net beskikber op beide siden. Dat barde fansels. Wy hawwe úteinlik de arsjitektuer fan binnen besjoen. It is net folle feroare, mar foar Ruslân hawwe wy no twa siden, dy't net fan deselde provider binne, mar fan twa ferskillende. As ien mislearret, kinne wy oerstappe nei de oare.
Hypotetysk, foar Amazon beskôgje wy de mooglikheid fan reservearring op it nivo fan in oare provider; miskien Google, miskien in oar ... Mar oant no ta hawwe wy yn 'e praktyk observearre dat wylst Amazon ûngelokken hat op it nivo fan ien beskikberensône, ûngemakken op it nivo fan in hiele regio frij seldsum binne. Dêrom hawwe wy teoretysk it idee dat wy in "Amazon is net Amazon" reservearje kinne meitsje, mar yn 'e praktyk is dit noch net it gefal.
In pear wurden oer automatisearring
Is automatisearring altyd nedich? Hjir is it passend om it Dunning-Kruger-effekt te ûnthâlden. Op 'e "x"-as is ús kennis en ûnderfining dy't wy krije, en op 'e "y"-as is fertrouwen yn ús aksjes. Wy witte earst neat en binne hielendal net wis. Dan witte wy in bytsje en wurde mega-selsfertrouwen - dit is de saneamde "peak fan dommens", goed yllustrearre troch de foto "demintens en moed". Dan hawwe wy wat leard en binne wy klear om de striid yn te gean. Dan stappe wy op guon mega-serieuze flaters en fine ússels yn in delling fan wanhoop, as wy lykje te witten wat, mar eins witte wy net folle. Dan, as wy ûnderfining opdwaan, wurde wy selsbetrouwen.
Us logika oer ferskate automatyske skeakels nei bepaalde ûngemakken wurdt tige goed beskreaun troch dizze grafyk. Wy begûnen - wy wisten neat te dwaan, hast al it wurk waard mei de hân dien. Doe beseften wy dat wy automatisearring oan alles kinne heakje en, lykas, rêstich sliepe. En ynienen stappe wy op in mega-rake: in falske posityf wurdt trigger, en wy skeakelje ferkear hinne en wer as wy, op in goede manier, dit net moatte dien hawwe. Dêrtroch brekt replikaasje ôf of wat oars - dit is de delling fan wanhoop. En dan komme wy ta it ferstân dat wy alles ferstannich oanpakke moatte. Dat is, it makket sin te fertrouwe op automatisearring, foarsjen foar de mooglikheid fan falske alaarms. Mar! as de gefolgen ferneatigjend wêze kinne, dan is it better om it oer te litten oan 'e plichtferdieling, oan 'e yngenieurs yn tsjinst, dy't soargje en kontrolearje dat der echt in ûngelok is, en de nedige aksjes mei de hân útfiere ...
konklúzje
Yn de rin fan 7 jier gongen wy fan it feit dat as der wat foel, der panyk-panyk wie, nei it begryp dat problemen net bestean, der binne allinnich taken, dy moatte - en kinne - wurde oplost. As jo in tsjinst bouwe, sjoch it dan fan boppen ôf, beoardielje alle risiko's dy't kinne barre. As jo se direkt sjogge, soargje dan foarôfgeand oan oerstalligens en de mooglikheid om in flater-tolerante ynfrastruktuer te bouwen, om't elk punt dat kin mislearje en liede ta de inoperabiliteit fan 'e tsjinst sil dat perfoarst dwaan. En sels as it foar jo liket dat guon eleminten fan 'e ynfrastruktuer perfoarst net sille mislearje - lykas deselde s3, hâld dan noch yn gedachten dat se kinne. En hawwe teminsten yn teory in idee fan wat jo mei har sille dwaan as der wat bart. Hawwe in risikobehearplan. As jo tinke om alles automatysk of mei de hân te dwaan, beoardielje dan de risiko's: wat bart der as de automatisearring alles begjint te wikseljen - sil dit net liede ta in noch slimmer situaasje yn ferliking mei in ûngelok? Miskien is it earne nedich om in ridlik kompromis te brûken tusken it brûken fan automatisearring en de reaksje fan 'e yngenieur op plicht, dy't it echte byld sil evaluearje en begripe oft der wat moat wurde oerskeakele op it plak of "ja, mar net no."
In ridlik kompromis tusken perfeksjonisme en echte ynspanning, tiid, jild dat jo kinne besteegje oan it skema dat jo úteinlik sille hawwe.
Dizze tekst is in aktualisearre en útwreide ferzje fan it rapport fan Alexander Demidov op 'e konferinsje .
Boarne: www.habr.com