Gaur egun, Bitrix24 zerbitzuak ez du ehunka gigabit trafikorik, ezta zerbitzari-flota handirik ere (nahiz eta, jakina, dezente dauden). Baina bezero askorentzat enpresan lan egiteko tresna nagusia da; negoziorako benetako aplikazio kritikoa da. Beraz, ez dago erortzeko modurik. Zer gertatuko litzateke istripua gertatuko balitz, baina zerbitzua hain azkar "berreskuratu" ez zen inork ezer nabaritu ez zuen? Eta nola da posible hutsegitea ezartzea lanaren kalitatea eta bezero kopurua galdu gabe? Alexander Demidov, Bitrix24-ko hodeiko zerbitzuen zuzendariak, gure blogerako hitz egin zuen erreserba-sistemak produktuaren existentziako 7 urteetan nola eboluzionatu duen.
"Bitrix24 SaaS gisa abiarazi genuen duela 7 urte. Zailtasun nagusia honako hau izan zen ziurrenik: SaaS gisa publikoki abian jarri aurretik, produktu hau kutxako soluzio formatuan zegoen. Bezeroek guri erosi zizkiguten, zerbitzarietan ostatatu zuten, atari korporatiboa ezarri zuten - langileen komunikaziorako, fitxategiak biltegiratzeko, zereginen kudeaketarako, CRM, hori da guztia. Eta 2012rako, SaaS gisa abiarazi nahi genuela erabaki genuen, geuk administratuz, akatsen tolerantzia eta fidagarritasuna bermatuz. Bidean esperientzia lortu genuen, ordura arte ez baikenuen besterik gabe - software fabrikatzaileak baino ez ginen, ez zerbitzu hornitzaileak.
Zerbitzua martxan jartzean, ulertu genuen garrantzitsuena akatsen tolerantzia, fidagarritasuna eta zerbitzuaren etengabeko erabilgarritasuna bermatzea dela, izan ere, webgune arrunt soil bat baduzu, denda bat, adibidez, eta zure gainean erortzen zaizu eta bertan esertzen da. ordubete, zuk bakarrik sufritzen duzu, eskariak galtzen dituzu, bezeroak galtzen dituzu, baina zure bezeroarentzat berarentzat, hau ez da oso kritikoa berarentzat. Haserre zegoen, noski, baina joan eta beste gune batean erosi zuen. Eta hau enpresaren lan guztiak, komunikazioak, erabakiak lotzen dituen aplikazioa bada, erabiltzaileen konfiantza lortzea da garrantzitsuena, hau da, ez uztea eta ez erortzea. Lan guztiak gelditu daitezkeelako barruan zerbait funtzionatzen ez badu.
Bitrix.24 SaaS gisa
Jendaurrean jarri baino urtebete lehenago muntatu genuen lehen prototipoa, 2011n. Astebete gutxi gorabehera muntatu genuen, begiratu, biraka egin genuen - funtzionatzen ari zen. Hau da, formulariora sartu, atariaren izena bertan sartu, atari berri bat irekiko litzateke eta erabiltzaile base bat sortuko litzateke. Begiratu, produktua printzipioz baloratu, hondatu egin genuen eta urte osoz fintzen jarraitu genuen. Zeregin handia geneukalako: ez genituen bi kode-oinarri ezberdin egin nahi, ez genuen ontziratutako produktu bereizirik onartu nahi, hodeiko soluzio bereiziak - kode bakarrean egin nahi genuen dena.
Garai hartan web-aplikazio tipiko bat PHP kode batzuk exekutatzen ziren zerbitzari bat zen, mysql datu-base bat, fitxategiak kargatzen ziren, dokumentuak, argazkiak kargatzeko karpetan jartzen ziren - tira, dena funtzionatzen du. Ala ere, ezinezkoa da hau erabiliz web-zerbitzu kritikoki egonkorra abian jartzea. Bertan, banatutako cachea ez da onartzen, datu-basearen erreplikazioa ez da onartzen.
Baldintzak formulatu genituen: hau da, kokapen desberdinetan kokatzea, erreplikazioa onartzen duena eta, egokiena, geografikoki banatutako datu-zentro desberdinetan kokatzea. Bereizi produktuaren logika eta, hain zuzen ere, datuen biltegiratzea. Kargaren arabera dinamikoki eskalatzeko gai izan, eta estatikoak guztiz onartzen ditu. Gogoeta horietatik, hain zuzen ere, produktuaren eskakizunak sortu ziren, eta urtean zehar findu genituen. Denbora horretan, plataforman, bateratua suertatu zen -kutxako soluzioetarako, gure zerbitzurako- behar genituen gauza horietarako laguntza egin genuen. Mysql erreplikatzeko euskarria produktuaren beraren mailan: hau da, kodea idazten duen garatzaileak ez du pentsatzen nola banatuko diren bere eskaerak, gure APIa erabiltzen du eta badakigu maisuen artean idazteko eta irakurtzeko eskaerak behar bezala banatzen. eta esklaboak.
Produktu mailan hodeiko objektuen biltegiratze ezberdinetarako laguntza egin dugu: google biltegiratzea, amazon s3 eta open stack swift-erako laguntza. Hori dela eta, hau komenigarria izan zen bai zerbitzu gisa, bai paketaturiko soluzio batekin lan egiten duten garatzaileentzat: gure APIa lanerako besterik ez badute erabiltzen, ez dute pentsatzen fitxategia non gordeko den azkenean, lokalean fitxategi sisteman edo. objektu fitxategien biltegian.
Ondorioz, berehala erabaki genuen datu-zentro osoaren mailan erreserbatuko genuela. 2012an, guztiz abiarazi genuen Amazon AWS-n, jada plataforma honekin esperientzia geneukalako - gure webgunea bertan zegoen. Eskualde bakoitzean Amazon-ek hainbat erabilgarritasun-eremu dituela erakarri gintuen, hain zuzen ere (haien terminologian) bata bestearengandik gutxi gorabehera independenteak diren eta datu-zentro oso baten mailan erreserbatzeko aukera ematen diguten hainbat datu-zentro: bat-batean huts egiten badu, datu-baseak master-master errepikatzen dira, web aplikazioen zerbitzarien babeskopia egiten da eta datu estatikoak s3 objektuen biltegira eramaten dira. Karga orekatua da - garai hartan Amazon elb-ek, baina pixka bat geroago gure karga-orekatzaileetara iritsi ginen, logika konplexuagoa behar genuelako.
Nahi zutena lortu zutena da...
Bermatu nahi genituen oinarrizko gauza guztiak - zerbitzarien akatsen tolerantzia, web aplikazioak, datu-baseak - dena ondo funtzionatu zuen. Eszenatokirik errazena: gure web-aplikazioren batek huts egiten badu, dena erraza da: orekatzetik desaktibatuta daude.
Balantzatzaileak (garai hartan Amazonen elb zen) funtzionamendurik gabe zeuden makinak osasungaitz gisa markatu zituen eta haien karga banaketa desaktibatu zuen. Amazon autoscaling funtzionatu zuen: karga hazi zenean, makina berriak gehitu ziren autoescaling taldean, karga makina berrietara banatu zen - dena ondo zegoen. Gure orekatzaileekin, logika berdina da gutxi gorabehera: aplikazioen zerbitzariari zerbait gertatzen bazaio, eskaerak kendu, makina hauek bota, berriak hasi eta lanean jarraitzen dugu. Eskema pixka bat aldatu da urteetan zehar, baina lanean jarraitzen du: sinplea, ulergarria da, eta ez dago zailtasunik.
Mundu osoan egiten dugu lan, bezeroen karga-gailurrak guztiz desberdinak dira, eta, modu adiskidetsuan, gure sistemaren edozein osagaitan zerbitzu-lan jakin batzuk egin ahal izan beharko genituzke edozein unetan, bezeroek ohartu gabe. Hori dela eta, datu-basea funtzionamendutik itzaltzeko aukera dugu, karga bigarren datu-zentro batera birbanatuz.
Nola funtzionatzen du dena? β Trafikoa laneko datu-zentro batera aldatzen dugu - datu-zentroan istripu bat gertatzen bada, guztiz, datu-base batekin aurreikusitako lana bada, bezero hauei zerbitzatzen dien trafikoaren zati bat bigarren datu-zentro batera aldatzen dugu, bertan behera utziz. erreplikatzea da. Web aplikazioetarako makina berriak behar badira bigarren datu-zentroko karga handitu delako, automatikoki abiaraziko dira. Lana amaitzen dugu, erreplikazioa berreskuratzen da eta karga osoa itzuliko dugu. Bigarren DCan lan batzuk islatu behar baditugu, adibidez, sistemaren eguneraketak instalatu edo bigarren datu-basean ezarpenak aldatu, orduan, oro har, gauza bera errepikatuko dugu, beste norabidean. Eta hori istripua bada, dena hutsalki egiten dugu: gertakarien kudeatzaileen mekanismoa erabiltzen dugu monitorizazio sisteman. Hainbat egiaztapen abiarazten badira eta egoera kritikoa bihurtzen bada, orduan kudeatzaile hau exekutatzen dugu, hau edo beste logika egin dezakeen kudeatzailea. Datu-base bakoitzerako, zein zerbitzari den haren hutsegitea eta non aldatu behar den trafikoa erabilgarri ez badago. Historikoki, nagios edo bere sardexka batzuk era batera edo bestera erabiltzen ditugu. Printzipioz, ia edozein monitorizazio sistematan antzeko mekanismoak daude; oraindik ez dugu ezer konplexuagorik erabiltzen, baina agian noizbait egingo dugu. Orain monitorizazioa erabilgarritasunik eza abiarazten da eta zerbait aldatzeko gaitasuna du.
Dena erreserbatu al dugu?
AEBetako bezero asko ditugu, Europako bezero asko, Ekialdetik gertuago dauden bezero asko - Japonia, Singapur eta abar. Jakina, bezeroen zati handi bat Errusian dago. Hau da, lana ez dago eskualde batean. Erabiltzaileek erantzun azkarra nahi dute, tokiko hainbat lege betetzeko eskakizunak daude, eta eskualde bakoitzean bi datu-zentro erreserbatzen ditugu, eta zerbitzu gehigarri batzuk ere badaude, eta, berriro ere, erosoak dira eskualde bakarrean kokatzeko --n dauden bezeroentzat. eskualde hau lanean ari da. REST kudeatzaileak, baimen-zerbitzariak, ez dira hain kritikoak bezeroaren funtzionamendurako, atzerapen onargarri txiki batekin alda ditzakezu, baina ez duzu gurpila berrasmatu nahi nola kontrolatu eta zer egin Haiekin. Hori dela eta, lehendik dauden irtenbideak ahalik eta gehien erabiltzen saiatzen ari gara, produktu osagarrietan nolabaiteko konpetentzia garatu beharrean. Eta nonbait, hutsalki erabiltzen dugu aldaketa DNS mailan, eta zerbitzuaren bizitasuna DNS beraren arabera zehazten dugu. Amazon-ek Route 53 zerbitzu bat du, baina ez da sarrerak egin ditzakezun DNS bat bakarrik eta kitto, askoz malguagoa eta erosoagoa da. Haren bidez geo-banatutako zerbitzuak geolokalizazioekin eraiki ditzakezu, bezeroa nondik datorren zehazteko eta erregistro jakin batzuk emateko erabiltzen duzunean - bere laguntzarekin hutsegite-arkitekturak eraiki ditzakezu. Osasun-egiaztapen berberak Route 53-n bertan konfiguratzen dira, kontrolatzen diren amaiera-puntuak ezartzen dituzu, metrikak ezartzen dituzu, zerbitzuaren "bizitasuna" zehazteko protokoloak ezartzen dituzu - tcp, http, https; zerbitzua bizirik dagoen edo ez zehazten duten kontrolen maiztasuna ezarri. Eta DNSn bertan zehazten duzu zer izango den primarioa, zer izango den bigarren mailakoa, non aldatu osasun-egiaztapena 53 bidearen barruan abiarazten bada. Hori guztia beste tresna batzuekin egin daiteke, baina zergatik da komenigarria - guk ezartzen dugu. behin igo eta gero ez pentsa batere nola egiten ditugun egiaztapenak, nola aldatzen garen: denak bere kabuz funtzionatzen du.
Lehenengo "baina": nola eta zerrekin erreserbatu 53 ibilbidea bera? Nork daki, zerbait gertatuko balitzaio? Zorionez, ez dugu sekula zapaldu arrastel hau, baina berriro ere, erreserba bat egin behar genuela uste genuen istorio bat izango dut aurretik. Hemen lastoak jarri genizkion aldez aurretik. Egunean hainbat aldiz deskarga osoa egiten dugu 53. ibilbidean ditugun zonalde guztiak. Amazon-en API-k JSON-n erraz bidaltzeko aukera ematen du, eta hainbat backup zerbitzari ditugu, non konfigurazio moduan kargatu eta, gutxi gorabehera, babeskopia-konfigurazioa dugu. Zerbait gertatzen bada, azkar zabaldu ahal izango dugu eskuz DNS ezarpenen datuak galdu gabe.
Bigarren "baina": Irudi honetan zer ez da oraindik erreserbatuta? Balantzailea bera! Gure bezeroen banaketa eskualdeka oso erraza da. Bitrix24.ru, bitrix24.com, .de domeinuak ditugu - orain 13 desberdin daude, hainbat zonatan funtzionatzen dutenak. Hona heldu gara: eskualde bakoitzak bere orekatzaileak ditu. Horri esker, erosoagoa da eskualdeen artean banatzea, sareko karga gailurra dagoenaren arabera. Baldintzatzaile bakar baten mailan hutsegitea bada, zerbitzutik kanpo utzi eta dns-etik kenduko da. Orekatzaile talde batekin arazoren bat badago, beste gune batzuetan egiten dira babeskopiak, eta haien artean aldatzea bide bera erabiliz egiten da53, izan ere, TTL laburra dela eta, aldaketa 2, 3, 5 minututan gertatzen da gehienez. .
Hirugarren "baina": Zer ez dago oraindik erreserbatuta? S3, zuzena. Erabiltzaileentzako gordetzen ditugun fitxategiak s3-n jarri genituenean, zinez uste genuen armadura-zulatzailea zela eta ez zegoela ezer erreserbatzeko beharrik bertan. Baina historiak erakusten du gauzak bestela gertatzen direla. Oro har, Amazonek S3 oinarrizko zerbitzu gisa deskribatzen du, Amazonek berak S3 erabiltzen duelako makinen irudiak, konfigurazioak, AMI irudiak, instantΓ‘neak... Eta s3 huts egiten badu, 7 urte hauetan behin gertatu den bezala, erabiltzen ari garen bitartean. bitrix24-k, zale bat bezala jarraitzen du. Gauza asko sortzen dira: makina birtualak abiarazteko ezintasuna, api porrota eta abar.
Eta S3 erori daiteke - behin gertatu zen. Hori dela eta, eskema honetara iritsi ginen: duela urte batzuk ez zegoen Errusian objektu publikoak biltegiratzeko instalazio seriorik, eta gure zerbait egiteko aukera aztertzen genuen... Zorionez, ez ginen horretan hasi, egingo genukeelako. ez daukagun espezializazioan sakondu dute, eta seguruenik nahastuko lukete. Orain Mail.ru-k s3-rekin bateragarria den biltegiratzea du, Yandex-ek badu eta beste hornitzaile batzuek dute. Azkenean, lehenik eta behin, babeskopia eta, bestetik, tokiko kopiekin lan egiteko gaitasuna izan nahi genuela bururatu zitzaigun. Errusiako eskualderako zehazki, Mail.ru Hotbox zerbitzua erabiltzen dugu, API bateragarria dena s3-rekin. Ez genuen aldaketa handirik behar aplikazioaren barruan kodean, eta honako mekanismo hau egin genuen: s3-n objektuak sortzea/ezabatzea abiarazten duten abiarazleak daude, Amazonek Lambda izeneko zerbitzu bat du - hau zerbitzaririk gabeko kodea abiarazte bat da. abiarazle jakin batzuk abiarazten direnean exekutatuko da.
Oso sinplea egin dugu: gure abiarazleak su egiten badu, objektua Mail.ru biltegian kopiatuko duen kodea exekutatuko dugu. Datuen kopia lokalekin lana guztiz abiarazteko, alderantzizko sinkronizazioa ere behar dugu, Errusiako segmentuan dauden bezeroek haiengandik gertuago dagoen biltegiarekin lan egin dezaten. Maila bere biltegian abiarazleak amaitzear dago - alderantzizko sinkronizazioa egin ahal izango da azpiegitura mailan, baina oraingoz gure kodearen mailan egiten ari gara. Bezero batek fitxategi bat argitaratu duela ikusten badugu, kode mailan gertaera ilara batean jartzen dugu, prozesatu eta alderantzizko erreplikazioa egiten dugu. Zergatik den txarra: gure objektuekin gure produktutik kanpo lan bat egiten badugu, hau da, kanpoko bitarteko batzuen bidez, ez dugu kontuan hartuko. Hori dela eta, amaierara arte itxarongo dugu, biltegiratze mailan abiarazleak agertzen direnean, kodea nondik exekutatu gabe, heldu zaigun objektua beste noranzkoan kopiatu dadin.
Kode mailan, bezero bakoitzarentzat bi biltegiratze erregistratzen ditugu: bata nagusitzat hartzen da, bestea babeskopiatzat. Dena ondo badago, hurbilago dagoen biltegiarekin lan egiten dugu: hau da, Amazonen dauden gure bezeroak S3rekin lan egiten dute, eta Errusian lan egiten dutenek Hotboxekin lan egiten dute. Bandera abiarazten bada, hutsegitea konektatu beharko litzateke eta bezeroak beste biltegiratze batera aldatzen ditugu. Lauki hau modu independentean markatu dezakegu eskualdeka eta alde batera eta bestera alda ditzakegu. Praktikan oraindik ez dugu erabili, baina mekanismo hori aurreikusi dugu eta noizbait etengailu hau beharko dugula eta ondo etorriko zaigula uste dugu. Hau jadanik behin gertatu da.
Ah, eta Amazonek ihes egin zuen...
Apiril honetan Telegramen blokeoa Errusian hasi zeneko urteurrena ospatzen da. Honen menpe geratu den hornitzaile kaltetuena Amazon da. Eta, zoritxarrez, mundu osorako lan egiten zuten Errusiako enpresek gehiago sufritu zuten.
Konpainia globala bada eta Errusia oso segmentu txikia bada, % 3-5 - tira, nola edo hala, sakrifikatu ditzakezu.
Errusiako enpresa hutsa bada - ziur nago lokalean kokatu behar dela - tira, erabiltzaileentzat erosoa izango da, erosoa, eta arrisku gutxiago egongo da.
Zer gertatzen da hau mundu mailan jarduten duen enpresa bat bada eta gutxi gorabehera Errusiatik eta mundu osoko bezero kopuru berdina badu? Segmentuen konektibitatea garrantzitsua da, eta elkarrekin lan egin behar dute nola edo hala.
2018ko martxoaren amaieran, Roskomnadzorrek eskutitz bat bidali zien operadore handienei, Amazon milioika hainbat IP blokeatzeko asmoa zutela adieraziz... Zello mezularia blokeatzeko. Hornitzaile horiei esker, guztiontzat gutuna arrakastaz filtratu zuten, eta Amazonekiko konexioa hautsi zitekeela ulertzen zen. Ostirala zen, izututa korrika egin genuen servers.ru-ko gure lankideengana, esanez: "Lagunak, Errusian ez, Amazonen ez, baina, adibidez, Amsterdamen nonbait egongo diren hainbat zerbitzari behar ditugu", ordenatzeko. inola ere eragin ezin ditugun amaiera-puntu batzuetarako, adibidez, s3 bereko endpontetarako, gure VPN eta proxy-a nolabait instalatu ahal izateko, ezin dugu saiatu zerbitzu berri bat sortzen eta beste ip bat lortzen, oraindik iritsi behar dugu. Egun gutxitan, zerbitzari hauek konfiguratu, martxan jarri eta, oro har, blokeoa hasi zen momenturako prestatu genuen. Bitxia da RKNk, zalapartari eta izuari begira, esan izana: "Ez, ez dugu ezer blokeatuko orain". (Baina hau Telegram blokeatzen hasi zen unera arte da.) Saihesbide-gaitasunak konfiguratu eta blokeoa sartu ez zela konturatuta, ez ginen, ordea, kontu guztia konpontzen hasi. Bai, badaezpada.
Eta 2019an oraindik blokeo baldintzetan bizi gara. Bart begiratu nuen: milioi bat IP inguru blokeatuta jarraitzen dute. Egia esan, Amazon ia erabat desblokeatu zen, bere gailurrean 20 milioi helbidera iritsi zen... Oro har, errealitatea da agian ez dagoela koherentziarik, koherentzia ona. Bat-batean. Baliteke arrazoi teknikoengatik ez egotea: suteak, hondeamakinak, hori guztia. Edo, ikusi dugunez, ez guztiz teknikoa. Hori dela eta, norbait handi eta handiek, bere AS-ekin, ziurrenik hori beste modu batera kudeatu dezake - konektatu zuzena eta beste gauza batzuk dagoeneko l2 mailan daude. Baina bertsio sinple batean, gurea bezalakoa edo are txikiagoan, badaezpada, erredundantzia izan dezakezu beste nonbait altxatutako zerbitzarien mailan, aldez aurretik vpn, proxy konfiguratuta, segmentu horietan konfigurazioa azkar aldatzeko gaitasunarekin. zure konektibitaterako funtsezkoak direnak. Hau behin baino gehiagotan ondo etorri zitzaigun, Amazonen blokeoa hasi zenean; kasurik txarrenean, S3 trafikoa bakarrik uzten genuen haietatik, baina pixkanaka hori guztia konpondu zen.
Nola erreserbatu... hornitzaile oso bat?
Oraintxe bertan ez dugu eszenatokirik Amazon osoa jaisten bada. Antzeko eszenatokia dugu Errusiarentzat. Errusian, hornitzaile batek ostatu gintuen, eta bertatik hainbat gune izatea aukeratu genuen. Eta duela urtebete arazo bati aurre egin genion: bi datu-zentro izan arren, hornitzailearen sare-konfigurazioaren mailan arazoak egon daitezke oraindik, bi datu-zentroetan eragina izango dutenak. Eta baliteke bi guneetan erabilgarri ez egotea. Hori gertatu zen noski. Barruko arkitektura birplanteatzen amaitu genuen. Ez da asko aldatu, baina Errusiarentzat orain bi gune ditugu, hornitzaile berekoak ez direnak, bi ezberdinetakoak baizik. Batek huts egiten badu, bestera alda gaitezke.
Hipotetikoki, Amazonentzat beste hornitzaile baten mailan erreserba egiteko aukera aztertzen ari gara; agian Google, agian beste norbait... Baina orain arte praktikan ikusi dugu Amazonek erabilgarritasun-eremu baten mailan istripuak dituen arren, eskualde oso baten mailan istripuak nahiko arraroak direla. Hori dela eta, teorikoki βAmazon ez da Amazonβ erreserba egin genezakeen ideia dugu, baina praktikan oraindik ez da horrela gertatzen.
Automatizazioari buruzko hitz batzuk
Automatizazioa beti beharrezkoa da? Hemen egokia da Dunning-Kruger efektua gogoratzea. βxβ ardatzean gure ezagutza eta esperientzia dago, eta βyβ ardatzean gure ekintzetan konfiantza. Hasieran ez dakigu ezer eta ez gaude batere ziur. Orduan pixka bat ezagutzen dugu eta mega-konfiantza bihurtzen dugu - "ergelkeriaren gailurra" deritzona da, "dementzia eta ausardia" irudiak ondo ilustratuta. Gero pixka bat ikasi dugu eta borrokara joateko prest gaude. Gero akats mega-larri batzuk zapaltzen ditugu eta etsipenaren haran batean aurkitzen gara, zerbait dakigula dirudigunean, baina egia esan ez dakigu asko. Gero, esperientzia hartzen doazen heinean, konfiantza gehiago hartzen dugu.
Grafiko honek oso ondo deskribatzen du istripu jakin batzuetarako etengailu automatiko ezberdinei buruzko gure logika. Hasi ginen - ez genekien ezer egiten, ia lan guztia eskuz egiten zen. Orduan konturatu ginen dena automatizazioa lotu genezakeela eta lasai lo egin. Eta bat-batean mega-rake bat zapaltzen dugu: positibo faltsu bat abiarazten da, eta trafikoa aurrera eta atzera aldatzen dugu, modu onean, hau egin behar ez genuenean. Ondorioz, erreplikazioa hautsi egiten da edo beste zerbait, hau da etsipenaren harana bera. Eta orduan ulertzen dugu dena zentzuz heldu behar dugula. Hau da, zentzuzkoa da automatizazioan fidatzea, alarma faltsuak izateko aukera emanez. Baina! ondorioak suntsigarriak izan badaitezke, orduan hobe da betebeharrari uztea, guardiako ingeniariei, istripua benetan egon dela ziurtatu eta kontrolatuko duten, eta eskuz egin beharreko ekintzak egingo dituztela...
Ondorioa
7 urtean zehar, zerbait erortzean, izu-izua sortzen zenetik, arazoak ez direla existitzen, zereginak baino ez daudela ulertzera pasatu ginen, konpondu behar -eta konpondu daitezkeela. Zerbitzu bat eraikitzen ari zarenean, begiratu goitik, baloratu gerta daitezkeen arrisku guztiak. Berehala ikusten badituzu, eman erredundantzia aldez aurretik eta akatsak jasan ditzakeen azpiegitura bat eraikitzeko aukera, huts egin dezakeen eta zerbitzuaren funtzionamendu ezina ekar dezakeen edozein puntuk behin betiko egingo baitu. Eta azpiegituraren elementu batzuek zalantzarik gabe huts egingo ez dutela iruditzen bazaizu ere, s3 bera bezala, kontuan izan dezaketela. Eta teorian behintzat, izan zerbait gertatuko balitz haiekin zer egingo duzun. Arriskuak kudeatzeko plan bat edukitzea. Dena automatikoki edo eskuz egitea pentsatzen ari zarenean, ebaluatu arriskuak: zer gertatuko da automatizazioa dena aldatzen hasten bada - ez al du horrek egoera okerragoa ekarriko istripu batekin alderatuta? Agian, nonbait, beharrezkoa da arrazoizko konpromisoa erabiltzea automatizazioaren erabileraren eta guardiako ingeniariaren erreakzioaren artean, zeinak benetako irudia ebaluatuko duen eta ulertuko du zerbait aldatu behar den lekuan bertan edo "bai, baina orain ez".
Perfekzionismoaren eta benetako ahaleginaren, denboraren eta diruaren arteko arrazoizko konpromisoa, azkenean izango duzun eskeman gastatu dezakezuna.
Testu hau Alexander Demidov-en hitzaldiaren txostenaren bertsio eguneratua eta zabaldua da .
Iturria: www.habr.com