Šiandien Bitrix24 paslauga neturi nei šimtų gigabitų srauto, nei didžiulio serverių parko (nors, žinoma, esamų yra nemažai). Tačiau daugeliui klientų tai yra pagrindinis įrankis dirbant įmonėje, tai tikra verslui svarbi programa. Todėl nėra kaip kristi. Ką daryti, jei avarija įvyko, bet paslauga „atsigavo“ taip greitai, kad niekas nieko nepastebėjo? O kaip galima įgyvendinti failoverį neprarandant darbo kokybės ir klientų skaičiaus? Aleksandras Demidovas, Bitrix24 debesijos paslaugų direktorius, mūsų tinklaraštyje kalbėjo apie tai, kaip rezervavimo sistema vystėsi per 7 produkto gyvavimo metus.
„Prieš 24 metus paleidome Bitrix7 kaip SaaS. Pagrindinis sunkumas tikriausiai buvo toks: prieš tai, kai jis buvo pristatytas viešai kaip SaaS, šis produktas tiesiog egzistavo dėžutės sprendimo formatu. Klientai jį pirko iš mūsų, talpino savo serveriuose, sukūrė įmonės portalą – bendras sprendimas darbuotojų bendravimui, failų saugojimui, užduočių valdymui, CRM, ir viskas. Ir iki 2012 m. nusprendėme, kad norime jį paleisti kaip SaaS, administruodami patys, užtikrindami atsparumą gedimams ir patikimumą. Patirties įgijome pakeliui, nes iki tol jos tiesiog neturėjome – buvome tik programinės įrangos gamintojai, o ne paslaugų teikėjai.
Pradėdami paslaugą supratome, kad svarbiausia yra užtikrinti toleranciją gedimams, patikimumą ir nuolatinį paslaugos prieinamumą, nes jei turite paprastą įprastą svetainę, pavyzdžiui, parduotuvę, kuri užkrinta ant jūsų ir ten sėdi valandą kenčiate tik jūs, prarandate užsakymus, prarandate klientus, bet pačiam jūsų klientui tai nėra labai svarbu. Žinoma, jis buvo nusiminęs, bet nuėjo ir nusipirko kitoje svetainėje. O jei tai aplikacija, su kuria susietas visas darbas įmonės viduje, komunikacijos, sprendimai, tuomet svarbiausia įgyti vartotojų pasitikėjimą, tai yra jų nenuvilti ir nenukristi. Nes visi darbai gali sustoti, jei kažkas viduje neveikia.
Bitrix.24 kaip SaaS
Pirmąjį prototipą surinkome likus metams iki viešo pristatymo, 2011 m. Surinkome maždaug per savaitę, apžiūrėjome, sukame – net veikė. Tai yra, galite įeiti į formą, įvesti ten portalo pavadinimą, atsidarys naujas portalas ir bus sukurta vartotojų bazė. Pažiūrėjome, iš principo įvertinome prekę, išmetėme į metalo laužą ir tobulinome ištisus metus. Kadangi turėjome didelę užduotį: nenorėjome kurti dviejų skirtingų kodų bazių, nenorėjome palaikyti atskiro supakuoto produkto, atskirų debesų sprendimų – norėjome visa tai padaryti per vieną kodą.
Tipiška interneto programa tuo metu buvo vienas serveris, kuriame veikia kažkoks PHP kodas, mysql duomenų bazė, įkeliami failai, dokumentai, nuotraukos dedamos į įkėlimo aplanką – na, viskas veikia. Deja, naudojant tai neįmanoma paleisti kritiškai stabilios žiniatinklio paslaugos. Ten paskirstyta talpykla nepalaikoma, duomenų bazės replikacija nepalaikoma.
Suformulavome reikalavimus: tai galimybė būti skirtingose vietose, palaikyti replikaciją ir idealiu atveju būti skirtinguose geografiškai paskirstytuose duomenų centruose. Atskirkite produkto logiką ir, tiesą sakant, duomenų saugojimą. Gebėti dinamiškai keisti mastelį pagal apkrovą ir apskritai toleruoti statiką. Iš šių samprotavimų iš tikrųjų atsirado gaminiui keliami reikalavimai, kuriuos per metus išgryninome. Per tą laiką platformoje, kuri pasirodė esanti vieninga – dėžutės sprendimams, savo paslaugoms – palaikėme tuos dalykus, kurių mums reikėjo. Mysql replikacijos palaikymas paties produkto lygiu: tai yra, kodą rašantis kūrėjas negalvoja apie tai, kaip bus paskirstytos jo užklausos, jis naudoja mūsų api, o mes žinome, kaip teisingai paskirstyti rašymo ir skaitymo užklausas tarp meistrų. ir vergai.
Suteikėme palaikymą produktų lygiu įvairioms debesies objektų saugykloms: „Google“ saugyklai, „amazon s3“ ir atvirojo „swift“ palaikymui. Todėl tai buvo patogu tiek mums kaip paslaugai, tiek kūrėjams, kurie dirba su supakuotu sprendimu: jei jie tiesiog naudoja mūsų API darbui, jie negalvoja, kur failas galiausiai bus išsaugotas, lokaliai failų sistemoje ar objekto failų saugykloje.
Dėl to iš karto nusprendėme, kad rezervuosime viso duomenų centro lygiu. 2012 m. paleidome tik „Amazon AWS“, nes jau turėjome patirties su šia platforma – ten buvo priglobta mūsų svetainė. Mus patraukė tai, kad kiekviename regione „Amazon“ turi kelias pasiekiamumo zonas – iš tikrųjų (jų terminologija) keli duomenų centrai, kurie yra daugiau ar mažiau nepriklausomi vienas nuo kito ir leidžia rezervuoti viso duomenų centro lygmeniu: jei staiga sugenda, duomenų bazės pakartojamos pagrindiniu-pagrindiniu, žiniatinklio programų serverių atsarginės kopijos ir statiniai duomenys perkeliami į s3 objektų saugyklą. Krovinys subalansuotas – tuo metu Amazon elb, bet kiek vėliau priėjome prie savų apkrovos balansierių, nes reikėjo sudėtingesnės logikos.
Ko jie norėjo, tą ir gavo...
Visi pagrindiniai dalykai, kuriuos norėjome užtikrinti – pačių serverių, interneto programų, duomenų bazių atsparumas gedimams – viskas veikė gerai. Paprasčiausias scenarijus: jei viena iš mūsų žiniatinklio programų sugenda, tada viskas paprasta – jos išjungiamos iš balansavimo.
Balansuotojas (tuo metu tai buvo „Amazon“ elbė) sugedusias mašinas pažymėjo kaip nesveikus ir išjungė ant jų apkrovos paskirstymą. Amazon autoscaling veikė: kai apkrova išaugo, į autoscaling grupę buvo įtrauktos naujos mašinos, apkrova paskirstyta naujoms mašinoms – viskas buvo gerai. Mūsų balansuotojų logika yra maždaug ta pati: jei kas nors atsitiks su programų serveriu, pašaliname iš jo užklausas, išmetame šias mašinas, pradedame naujas ir dirbame toliau. Bėgant metams schema šiek tiek pasikeitė, bet veikia ir toliau: paprasta, suprantama ir nekyla jokių sunkumų.
Dirbame visame pasaulyje, klientų apkrovos viršūnės yra visiškai skirtingos ir draugiškai turėtume atlikti tam tikrus bet kurių mūsų sistemos komponentų aptarnavimo darbus bet kuriuo metu – klientų nepastebimai. Todėl turime galimybę išjungti duomenų bazę nuo veikimo, perskirstant apkrovą į antrą duomenų centrą.
Kaip visa tai veikia? — Perkeliame srautą į veikiantį duomenų centrą – jei duomenų centre įvyksta avarija, tai visiškai, jei tai yra mūsų planuojamas darbas su viena duomenų baze, dalį srauto, aptarnaujančio šiuos klientus, perkeliame į antrą duomenų centrą, sustabdydami tai replikacija. Jei žiniatinklio programoms reikia naujų mašinų, nes padidėjo antrojo duomenų centro apkrova, jie bus paleisti automatiškai. Baigiame darbą, atkuriama replikacija ir grąžiname visą įkrovą atgal. Jei mums reikia atspindėti kai kuriuos darbus antroje DC, pavyzdžiui, įdiegti sistemos naujinimus arba pakeisti nustatymus antroje duomenų bazėje, tada paprastai kartojame tą patį, tik kita kryptimi. O jei tai nelaimingas atsitikimas, tai viską darome trivialiai: stebėjimo sistemoje naudojame įvykių tvarkytojų mechanizmą. Jei suaktyvinami keli patikrinimai ir būsena tampa kritinė, paleidžiame šią tvarkyklę, tvarkyklę, kuri gali atlikti tą ar kitą logiką. Kiekvienai duomenų bazei nurodome, kuris serveris yra perjungimas ir kur reikia perjungti srautą, jei jis nepasiekiamas. Istoriškai viena ar kita forma naudojame nagios ar kai kurias jo šakutes. Iš esmės panašūs mechanizmai egzistuoja beveik bet kurioje stebėjimo sistemoje, nieko sudėtingesnio kol kas nenaudojame, bet galbūt kada nors tai padarysime. Dabar stebėjimą suaktyvina nepasiekiamumas ir turi galimybę ką nors pakeisti.
Ar viską rezervavome?
Turime daug klientų iš JAV, daug klientų iš Europos, daug klientų, kurie yra arčiau Rytų – Japonijos, Singapūro ir pan. Žinoma, didžiulė klientų dalis yra Rusijoje. Tai yra, darbas ne viename regione. Vartotojai nori greito atsako, yra reikalavimai laikytis įvairių vietinių įstatymų, kiekviename regione rezervuojame po du duomenų centrus, taip pat yra keletas papildomų paslaugų, kurias, vėlgi, patogu išdėstyti viename regione – klientams, kurie yra šis regionas dirba. REST tvarkyklės, autorizacijos serveriai, jie yra mažiau svarbūs viso kliento veikimui, galite perjungti juos su nedideliu priimtinu vėlavimu, bet nenorite išradinėti dviračio, kaip juos stebėti ir ką daryti su jais. Todėl stengiamės maksimaliai išnaudoti esamus sprendimus, o ne ugdyti kažkokią kompetenciją papildomuose produktuose. Ir kai kur mes trivialiai naudojame perjungimą DNS lygiu, o paslaugos gyvybingumą nustatome pagal tą patį DNS. „Amazon“ turi „Route 53“ paslaugą, tačiau tai ne tik DNS, į kurią galite įvesti įrašus, ir viskas – ji daug lankstesnė ir patogesnė. Per jį galite kurti geografiškai paskirstytas paslaugas su geografinėmis vietomis, kai naudojate ją nustatydami, iš kur klientas atvyko, ir duoti jam tam tikrus įrašus – su jo pagalba galite sukurti failover architektūras. Tie patys sveikatos patikrinimai sukonfigūruoti pačiame 53 maršrute, nustatote stebimus galinius taškus, nustatote metrikas, nustatote, kokiais protokolais nustatomas paslaugos „gyvumas“ - tcp, http, https; nustatyti patikrinimų, kurie nustato, ar paslauga veikia, ar ne, dažnumą. O pačiame DNS nurodai, kas bus pirminis, kas antrinis, kur perjungti, jei suveikia sveikatos patikra maršruto 53 viduje. Visa tai galima padaryti ir su kai kuriais kitais įrankiais, bet kodėl tai patogu - mes nustatome vieną kartą atsikelia ir tada visai negalvok, kaip atliekame patikrinimus, kaip persijungiame: viskas veikia savaime.
Pirmasis "bet": kaip ir su kuo rezervuoti patį 53 maršrutą? Kas žino, o jeigu jam kas nors atsitiks? Laimei, niekada neužlipome ant šio grėblio, bet vėl turėsiu istoriją, kodėl manėme, kad vis tiek reikia rezervuoti. Čia iš anksto išklojome sau šiaudelius. Kelis kartus per dieną visiškai iškrauname visas zonas, kurias turime 53 maršrute. „Amazon“ API leidžia lengvai siųsti juos JSON formatu, be to, turime keletą atsarginių serverių, kuriuose jį konvertuojame, įkeliame konfigūracijų pavidalu ir, grubiai tariant, turime atsarginę konfigūraciją. Jei kas nors atsitiks, galime greitai jį įdiegti rankiniu būdu neprarasdami DNS nustatymų duomenų.
Antras "bet": Kas šioje nuotraukoje dar nerezervuota? Pats balansuotojas! Mūsų klientų pasiskirstymas pagal regionus yra labai paprastas. Turime domenus bitrix24.ru, bitrix24.com, .de – dabar yra 13 skirtingų, kurie veikia įvairiose zonose. Priėjome taip: kiekvienas regionas turi savo balansuotojus. Tai leidžia patogiau paskirstyti regionus, atsižvelgiant į tai, kur yra didžiausia tinklo apkrova. Jei tai yra vieno balansavimo gedimo lygis, tada jis tiesiog išimamas ir pašalinamas iš dns. Jei kyla problemų dėl balansierių grupės, tada jų atsarginės kopijos sukuriamos kitose svetainėse, o tarp jų perjungiama tuo pačiu maršrutu53, nes dėl trumpo TTL perjungimas įvyksta daugiausiai per 2, 3, 5 minutes. .
Trečias "bet": Kas dar nerezervuota? S3, teisingai. Kai įdėjome failus, kuriuos saugome vartotojams į s3, nuoširdžiai tikėjome, kad tai šarvai pradurti ir ten nieko rezervuoti nereikia. Tačiau istorija rodo, kad viskas vyksta kitaip. Apskritai Amazon apibūdina S3 kaip fundamentalią paslaugą, nes pati Amazon naudoja S3 saugoti mašinų vaizdus, konfigūracijas, AMI vaizdus, momentines nuotraukas... O jei s3 sugenda, kaip kartą per šiuos 7 metus atsitiko, tiek laiko, kiek naudojome. bitrix24, jis seka jį kaip gerbėjas. Iškyla daugybė dalykų – negalėjimas paleisti virtualių mašinų, api gedimas ir pan.
O S3 gali nukristi – tai atsitiko kartą. Todėl priėjome prie tokios schemos: prieš keletą metų Rusijoje nebuvo rimtų visuomeninių objektų saugyklų, o mes svarstėme galimybę ką nors padaryti savo... Laimei, nepradėjome to daryti, nes norėtume. įsigilinome į žinias, kurių neturime, ir tikriausiai sujauktume. Dabar Mail.ru turi su s3 suderinamą saugyklą, ją turi „Yandex“ ir daugelis kitų teikėjų. Galiausiai sugalvojome, kad pirmiausia norime turėti atsarginę kopiją ir, antra, galimybę dirbti su vietinėmis kopijomis. Konkrečiai Rusijos regionui naudojame Mail.ru Hotbox paslaugą, kuri yra API suderinama su s3. Mums nereikėjo jokių didelių kodo modifikacijų programos viduje ir padarėme tokį mechanizmą: s3 yra trigeriai, kurie suaktyvina objektų kūrimą / ištrynimą, „Amazon“ turi paslaugą pavadinimu „Lambda“ – tai kodo paleidimas be serverio. kuris bus vykdomas tik tada, kai suaktyvinami tam tikri paleidikliai.
Mes tai padarėme labai paprastai: jei mūsų paleidiklis suveikia, vykdome kodą, kuris nukopijuos objektą į Mail.ru saugyklą. Norint visiškai pradėti darbą su vietinėmis duomenų kopijomis, mums taip pat reikalingas atvirkštinis sinchronizavimas, kad klientai, priklausantys Rusijos segmentui, galėtų dirbti su saugykla, kuri yra arčiau jų. Paštas netrukus baigs aktyviklius savo saugykloje – bus galima atlikti atvirkštinį sinchronizavimą infrastruktūros lygiu, tačiau kol kas tai darome savo kodo lygiu. Jei matome, kad klientas paskelbė failą, kodo lygiu mes įdedame įvykį į eilę, apdorojame jį ir atliekame atvirkštinę replikaciją. Kodėl tai blogai: jei dirbsime su savo objektais ne mūsų gaminyje, ty kažkokiomis išorinėmis priemonėmis, į tai neatsižvelgsime. Todėl laukiame pabaigos, kai atsiras trigeriai saugyklos lygyje, kad nesvarbu, iš kur vykdytume kodą, pas mus atėjęs objektas būtų nukopijuotas kita kryptimi.
Kodo lygiu kiekvienam klientui registruojame abi saugyklas: viena laikoma pagrindine, kita – atsargine. Jei viskas gerai, dirbame su saugykla, kuri yra arčiau mūsų: tai yra mūsų klientai, esantys Amazon, jie dirba su S3, o tie, kurie dirba Rusijoje, jie dirba su Hotbox. Jei vėliavėlė suveikia, tada perjungimas turėtų būti prijungtas ir mes perjungiame klientus į kitą saugyklą. Šį laukelį galime pažymėti atskirai pagal regioną ir perjungti juos pirmyn ir atgal. Praktikoje to dar nenaudojome, bet numatėme šį mechanizmą ir manome, kad kada nors mums prireiks šio jungiklio ir pravers. Taip jau buvo kartą.
O ir Amazon pabėgo...
Šį balandį minime „Telegram“ blokavimo Rusijoje pradžios metines. Labiausiai paveiktas paslaugų teikėjas, kuriam tai taikoma, yra „Amazon“. Ir, deja, labiau nukentėjo Rusijos įmonės, kurios dirbo visam pasauliui.
Jeigu įmonė globali ir Rusija jai labai mažas segmentas, 3-5% – na, vienaip ar kitaip, galite juos paaukoti.
Jei tai yra grynai rusiška įmonė - esu tikras, kad ji turi būti įsikūrusi vietoje - na, tai bus tiesiog patogu patiems vartotojams, patogu ir bus mažesnė rizika.
Ką daryti, jei tai yra įmonė, kuri veikia visame pasaulyje ir turi maždaug vienodą klientų skaičių iš Rusijos ir iš viso pasaulio? Segmentų jungiamumas yra svarbus, ir jie turi vienaip ar kitaip veikti tarpusavyje.
2018 metų kovo pabaigoje „Roskomnadzor“ išsiuntė laišką didžiausiems operatoriams, kuriuose nurodė, kad jie planuoja blokuoti kelis milijonus „Amazon“ IP, kad užblokuotų... „Zello messenger“. Ačiū tiems patiems tiekėjams – jie sėkmingai nutekino laišką visiems, ir atsirado supratimas, kad ryšys su Amazon gali nutrūkti. Buvo penktadienis, mes paniškai bėgome pas kolegas iš servers.ru sakydami: „Draugai, mums reikia kelių serverių, kurie bus ne Rusijoje, ne „Amazon“, o, pavyzdžiui, kur nors Amsterdame. į tam, kad galėtume bent kažkaip įdiegti savo VPN ir tarpinį serverį tam tikriems galiniams taškams, kurių niekaip negalime paveikti, pavyzdžiui, to paties s3 endpontams - negalime bandyti sukurti naujos paslaugos ir gauti kitokį IP, mums dar reikia ten patekti. Vos per kelias dienas sukonstravome šiuos serverius, paleidome juos ir apskritai pasiruošėme blokavimo pradžiai. Įdomu, kad RKN, žiūrėdamas į šurmulį ir paniką, pasakė: „Ne, dabar nieko neblokuosime“. (Bet tai yra būtent iki to momento, kai „Telegram“ buvo pradėta blokuoti.) Sukūrę aplinkkelio galimybes ir supratę, kad blokavimas neįvestas, mes vis dėlto nepradėjome viso reikalo spręsti. Taip, tik tuo atveju.
O 2019 metais vis dar gyvename blokavimo sąlygomis. Vakar pažiūrėjau: maždaug milijonas IP vis dar blokuojamas. Tiesa, Amazon buvo beveik visiškai atblokuotas, savo piko metu pasiekė 20 milijonų adresų... Apskritai realybė tokia, kad darnos, geros darnos gali ir nebūti. Staiga. Jo gali nebūti dėl techninių priežasčių – gaisrų, ekskavatorių, viso to. Arba, kaip matėme, ne visiškai techninė. Todėl kažkas didelis ir didelis, turintis savo AS, tikriausiai gali tai valdyti kitais būdais - tiesioginis ryšys ir kiti dalykai jau yra l2 lygyje. Tačiau paprastoje versijoje, kaip mūsų ar net mažesnėje, tik tuo atveju galite turėti perteklinį perteklinį serverių lygmenį kažkur kitur, iš anksto sukonfigūruotus vpn, tarpinį serverį, su galimybe greitai perjungti konfigūraciją į juos tuose segmentuose. kurie yra labai svarbūs jūsų ryšiui. Tai mums pravertė ne kartą, kai prasidėjo Amazon blokavimas, blogiausiu atveju per juos leisdavome tik S3 srautą, bet pamažu visa tai išsisprendė.
Kaip rezervuoti... visą tiekėją?
Šiuo metu mes neturime scenarijaus, jei visa „Amazon“ nukristų. Panašų scenarijų turime ir Rusijai. Rusijoje mus priglobė vienas tiekėjas, iš kurio pasirinkome turėti kelias svetaines. O prieš metus susidūrėme su problema: nors tai yra du duomenų centrai, jau tiekėjo tinklo konfigūracijos lygmenyje gali kilti problemų, kurios vis tiek turės įtakos abiem duomenų centrams. Ir mes galime būti nepasiekiami abiejose svetainėse. Žinoma, taip ir atsitiko. Galų gale persvarstėme architektūrą viduje. Ji labai nepasikeitė, bet Rusijai dabar turime dvi svetaines, kurios yra ne iš to paties tiekėjo, o iš dviejų skirtingų. Jei vienas nepavyksta, galime pereiti prie kito.
Hipotetiškai „Amazon“ svarstome galimybę rezervuoti kito tiekėjo lygiu; gal Google, gal kas nors kitas... Tačiau iki šiol praktikoje pastebėjome, kad nors Amazon avarijų įvyksta vienos prieinamumo zonos lygyje, tai viso regiono lygiu – gana retai. Todėl teoriškai turime idėją, kad galime padaryti išlygą „Amazon nėra Amazon“, tačiau praktiškai taip dar nėra.
Keletas žodžių apie automatizavimą
Ar visada reikia automatizuoti? Čia verta prisiminti Dunning-Kruger efektą. Ant „x“ ašies yra mūsų įgytos žinios ir patirtis, o „y“ ašyje – pasitikėjimas savo veiksmais. Iš pradžių nieko nežinome ir nesame tikri. Tada mes šiek tiek žinome ir tampame labai pasitikintys savimi - tai yra vadinamasis „kvailumo viršūnė“, gerai iliustruojamas paveikslu „demencija ir drąsa“. Tada mes šiek tiek išmokome ir esame pasirengę stoti į mūšį. Tada mes darome labai rimtas klaidas ir atsiduriame nevilties slėnyje, kai atrodo, kad kažką žinome, bet iš tikrųjų nežinome daug. Tada, įgydami patirties, labiau pasitikime savimi.
Mūsų logika apie įvairius automatinius perjungimus į tam tikras avarijas labai gerai aprašyta šiame grafike. Pradėjome - nieko nemokėjome daryti, beveik visas darbas buvo atliktas rankomis. Tada supratome, kad prie visko galime pritvirtinti automatiką ir, pavyzdžiui, ramiai miegoti. Ir staiga žengiame ant mega grėblio: suveikia klaidingas teigiamas signalas, ir mes keičiame srautą pirmyn ir atgal, kai, gerąja prasme, to daryti neturėjome. Vadinasi, replikacija sugenda arba kažkas kita – tai pats nevilties slėnis. Ir tada mes suprantame, kad turime į viską žiūrėti protingai. Tai yra, prasminga pasikliauti automatika, numatant klaidingų aliarmų galimybę. Bet! jei pasekmės gali būti pražūtingos, tai geriau tai palikti budėjimo pamainai, budintiems inžinieriams, kurie įsitikins ir stebės, kad tikrai nelaimė įvyktų, o reikiamus veiksmus atliks rankiniu būdu...
išvada
Per 7 metus nuo to, kad kažkas nukrito, kilo panika-panika, iki supratimo, kad problemų nėra, yra tik užduotys, jas reikia – ir galima – išspręsti. Kurdami paslaugą, pažiūrėkite į ją iš viršaus, įvertinkite visas rizikas, kurios gali atsitikti. Jei juos pamatysite iš karto, iš anksto numatykite atleidimą ir galimybę sukurti gedimams atsparią infrastruktūrą, nes bet kuris taškas, kuris gali sugesti ir lemti paslaugos neveikimą, tai tikrai padarys. Ir net jei jums atrodo, kad kai kurie infrastruktūros elementai tikrai nesuges – kaip tas pats s3, vis tiek turėkite omenyje, kad gali. Ir bent jau teoriškai turėkite idėją, ką su jais darysite, jei kas nors atsitiks. Turėkite rizikos valdymo planą. Kai galvojate viską daryti automatiškai ar rankiniu būdu, įvertinkite rizikas: kas bus, jei automatika pradės viską perjungti – ar tai nesukels dar blogesnės situacijos, palyginti su avarija? Galbūt kažkur reikia rasti pagrįstą kompromisą tarp automatikos naudojimo ir budinčio inžinieriaus reakcijos, kuris įvertins realų vaizdą ir supras, ar reikia ką nors keisti vietoje, ar „taip, bet ne dabar“.
Protingas kompromisas tarp perfekcionizmo ir tikrų pastangų, laiko, pinigų, kuriuos galite išleisti pagal schemą, kurią galiausiai turėsite.
Šis tekstas yra atnaujinta ir išplėsta Aleksandro Demidovo pranešimo konferencijoje versija .
Šaltinis: www.habr.com