I dag har Bitrix24-tjenesten ikke hundredvis af gigabits trafik, og den har heller ikke en kĂŠmpe flĂ„de af servere (selvom der selvfĂžlgelig er en del eksisterende). Men for mange kunder er det det vigtigste vĂŠrktĂžj til at arbejde i virksomheden; det er en rigtig forretningskritisk applikation. Derfor er der ingen mĂ„de at falde pĂ„. Hvad hvis styrtet skete, men tjenesten "kom sig" sĂ„ hurtigt, at ingen bemĂŠrkede noget? Og hvordan er det muligt at implementere failover uden at miste kvaliteten af ââarbejdet og antallet af klienter? Alexander Demidov, direktĂžr for cloud-tjenester hos Bitrix24, talte for vores blog om, hvordan reservationssystemet har udviklet sig i lĂžbet af de 7 Ă„r af produktets eksistens.
"Vi lancerede Bitrix24 som en SaaS for 7 Ă„r siden. Den stĂžrste vanskelighed var sandsynligvis fĂžlgende: fĂžr det blev lanceret offentligt som SaaS, eksisterede dette produkt simpelthen i formatet af en bokslĂžsning. Kunder kĂžbte det af os, hostede det pĂ„ deres servere, oprettede en virksomhedsportal - en generel lĂžsning til medarbejderkommunikation, fillagring, opgavestyring, CRM, det er alt. Og i 2012 besluttede vi, at vi ville lancere det som SaaS, administrere det selv og sikre fejltolerance og pĂ„lidelighed. Vi fik erfaring undervejs, for indtil da havde vi det simpelthen ikke â vi var kun softwareproducenter, ikke serviceudbydere.
Ved lanceringen af ââtjenesten forstod vi, at det vigtigste er at sikre fejltolerance, pĂ„lidelighed og konstant tilgĂŠngelighed af tjenesten, for hvis du har en simpel almindelig hjemmeside, for eksempel en butik, og den falder pĂ„ dig og sidder der for en time, kun du lider, du mister ordrer, du mister kunder, men for din klient selv er dette ikke sĂŠrlig kritisk for ham. Han var selvfĂžlgelig ked af det, men han gik hen og kĂžbte den pĂ„ en anden side. Og hvis dette er en applikation, hvor alt arbejdet i virksomheden, kommunikation, beslutninger er bundet, sĂ„ er det vigtigste at vinde brugernes tillid, det vil sige ikke at svigte dem og ikke at falde. Fordi alt arbejde kan stoppe, hvis noget indeni ikke virker.
Bitrix.24 som SaaS
Vi samlede den fÞrste prototype et Är fÞr den offentlige lancering, i 2011. Vi samlede den pÄ omkring en uge, sÄ pÄ den, snurrede den - den virkede endda. Det vil sige, du kunne gÄ ind i formularen, indtaste navnet pÄ portalen der, en ny portal ville Äbne, og en brugerbase ville blive oprettet. Vi kiggede pÄ det, vurderede produktet i princippet, skrottede det og fortsatte med at forfine det i et helt Är. Fordi vi havde en stor opgave: vi ville ikke lave to forskellige kodebaser, vi ville ikke understÞtte et separat pakket produkt, separate cloud-lÞsninger - vi ville gÞre det hele inden for én kode.
En typisk webapplikation pÄ det tidspunkt var én server, hvorpÄ noget PHP-kode kÞrer, en mysql-database, filer uploades, dokumenter, billeder lÊgges i uploadmappen - jamen, det hele virker. Ak, det er umuligt at lancere en kritisk stabil webtjeneste ved hjÊlp af denne. Der understÞttes distribueret cache ikke, databasereplikering understÞttes ikke.
Vi formulerede kravene: dette er evnen til at vÊre placeret forskellige steder, understÞtte replikering og ideelt set vÊre placeret i forskellige geografisk distribuerede datacentre. Adskil produktlogikken og faktisk datalagring. Kunne dynamisk skalere efter belastningen og helt tolerere statik. Ud fra disse overvejelser opstod faktisk kravene til produktet, som vi har finpudset i lÞbet af Äret. I lÞbet af denne tid, i platformen, som viste sig at vÊre samlet - for boxed-lÞsninger, til vores egen service - lavede vi support til de ting, vi havde brug for. UnderstÞttelse af mysql-replikering pÄ selve produktets niveau: det vil sige, at udvikleren, der skriver koden, ikke tÊnker pÄ, hvordan hans anmodninger vil blive distribueret, han bruger vores api, og vi ved, hvordan man korrekt distribuerer skrive- og lÊseanmodninger mellem mastere og slaver.
Vi har lavet support pÄ produktniveau til forskellige cloud-objektlager: google storage, amazon s3 plus support til open stack swift. Derfor var dette praktisk bÄde for os som en service og for udviklere, der arbejder med en pakket lÞsning: hvis de bare bruger vores API til arbejdet, tÊnker de ikke pÄ, hvor filen i sidste ende bliver gemt, lokalt pÄ filsystemet eller i objektfillageret.
Som et resultat besluttede vi straks, at vi ville reservere pÄ niveau med hele datacenteret. I 2012 lancerede vi helt pÄ Amazon AWS, fordi vi allerede havde erfaring med denne platform - vores egen hjemmeside var hostet der. Vi var tiltrukket af det faktum, at Amazon i hver region har flere tilgÊngelighedszoner - faktisk (i deres terminologi) flere datacentre, der er mere eller mindre uafhÊngige af hinanden og giver os mulighed for at reservere pÄ niveau med et helt datacenter: hvis det pludselig mislykkes, replikeres databaserne master-master, webapplikationsserverne sikkerhedskopieres, og de statiske data flyttes til s3-objektlageret. Belastningen er balanceret - pÄ det tidspunkt af Amazon elb, men lidt senere kom vi til vores egne load balancers, fordi vi havde brug for mere kompleks logik.
Det, de ville have, er, hvad de fik...
Alle de grundlĂŠggende ting, som vi ville sikre - fejltolerance pĂ„ selve serverne, webapplikationer, databaser - alt fungerede godt. Det enkleste scenarie: Hvis en af ââvores webapplikationer fejler, sĂ„ er alt enkelt - de er slukket for balancering.
Balanceren (dengang var det Amazons elb) markerede maskiner, der var ude af drift, som usunde og slukkede for belastningsfordeling pÄ dem. Amazon autoskalering virkede: nÄr belastningen voksede, blev der tilfÞjet nye maskiner til autoskaleringsgruppen, belastningen blev fordelt pÄ nye maskiner - alt var i orden. Med vores balancere er logikken omtrent den samme: Hvis der sker noget med applikationsserveren, fjerner vi anmodninger fra den, smider disse maskiner ud, starter nye og fortsÊtter med at arbejde. Ordningen har Êndret sig lidt gennem Ärene, men fortsÊtter med at fungere: den er enkel, forstÄelig, og der er ingen vanskeligheder med den.
Vi arbejder over hele verden, kundebelastningstoppene er helt anderledes, og pÄ en mindelig mÄde bÞr vi vÊre i stand til at udfÞre visse serviceopgaver pÄ alle komponenter i vores system til enhver tid - ubemÊrket af kunderne. Derfor har vi mulighed for at slukke for databasen fra drift og omfordele belastningen til et andet datacenter.
Hvordan fungerer det hele? â Vi skifter trafik til et fungerende datacenter - hvis der sker en ulykke i datacentret, sĂ„ fuldstĂŠndigt, hvis dette er vores planlagte arbejde med Ă©n database, sĂ„ skifter vi en del af trafikken, der betjener disse klienter til et andet datacenter, og suspenderer det replikation. Hvis der er behov for nye maskiner til webapplikationer, fordi belastningen pĂ„ det andet datacenter er Ăžget, starter de automatisk. Vi afslutter arbejdet, replikeringen gendannes, og vi returnerer hele belastningen. Hvis vi skal spejle noget arbejde i den anden DC, for eksempel installere systemopdateringer eller ĂŠndre indstillinger i den anden database, sĂ„ gentager vi generelt det samme, bare i den anden retning. Og hvis dette er et uheld, sĂ„ gĂžr vi alt trivielt: vi bruger hĂŠndelseshĂ„ndteringsmekanismen i overvĂ„gningssystemet. Hvis flere kontroller udlĂžses, og status bliver kritisk, kĂžrer vi denne handler, en handler, der kan udfĂžre denne eller hin logik. For hver database angiver vi, hvilken server der er failover for den, og hvor trafikken skal skiftes, hvis den ikke er tilgĂŠngelig. Historisk set bruger vi nagios eller nogle af dens gafler i en eller anden form. I princippet findes lignende mekanismer i nĂŠsten ethvert overvĂ„gningssystem; vi bruger ikke noget mere komplekst endnu, men mĂ„ske vil vi en dag. Nu udlĂžses overvĂ„gning af utilgĂŠngelighed og har mulighed for at skifte noget.
Har vi reserveret alt?
Vi har mange kunder fra USA, mange kunder fra Europa, mange kunder, der er tĂŠttere pĂ„ Ăsten - Japan, Singapore og sĂ„ videre. SelvfĂžlgelig er en stor del af kunderne i Rusland. Det vil sige, at arbejdet ikke er i Ă©n region. Brugere Ăžnsker et hurtigt svar, der er krav om at overholde forskellige lokale love, og inden for hver region reserverer vi to datacentre, plus der er nogle ekstra tjenester, som igen er praktiske at placere inden for Ă©n region - for kunder, der er i denne region arbejder. REST-handlere, autorisationsservere, de er mindre kritiske for driften af ââklienten som helhed, du kan skifte igennem dem med en lille acceptabel forsinkelse, men du vil ikke genopfinde hjulet for, hvordan man overvĂ„ger dem, og hvad man skal gĂžre med dem. Derfor forsĂžger vi at udnytte eksisterende lĂžsninger maksimalt, frem for at udvikle en form for kompetence inden for yderligere produkter. Og et eller andet sted bruger vi trivielt switching pĂ„ DNS-niveau, og vi bestemmer tjenestens livlighed ved den samme DNS. Amazon har en Route 53-tjeneste, men det er ikke kun en DNS, som du kan indtaste, og det er det â det er meget mere fleksibelt og bekvemt. Gennem det kan du bygge geo-distribuerede tjenester med geolokationer, nĂ„r du bruger det til at bestemme, hvor klienten kom fra og give ham visse poster - med dens hjĂŠlp kan du bygge failover-arkitekturer. De samme sundhedstjek er konfigureret i selve Route 53, du indstiller de endepunkter, der overvĂ„ges, indstiller metrics, indstiller hvilke protokoller, der skal bestemme "liveness" af tjenesten - tcp, http, https; indstille hyppigheden af ââkontroller, der afgĂžr, om tjenesten er i live eller ej. Og i selve DNS'en angiver du, hvad der skal vĂŠre primĂŠrt, hvad der skal vĂŠre sekundĂŠrt, hvor du skal skifte, hvis sundhedstjekket udlĂžses inde pĂ„ rute 53. Alt dette kan gĂžres med nogle andre vĂŠrktĂžjer, men hvorfor er det praktisk - vi indstiller det op en gang og sĂ„ slet ikke tĂŠnke over det, hvordan vi kontrollerer, hvordan vi skifter: alt fungerer af sig selv.
Det fÞrste "men": hvordan og med hvad reserverer man selve rute 53? Hvem ved, hvad hvis der sker ham noget? Heldigvis trÄdte vi aldrig pÄ denne rake, men igen, jeg vil have en historie forud for, hvorfor vi troede, at vi stadig skulle reservere. Her lagde vi sugerÞr ud til os selv pÄ forhÄnd. Flere gange om dagen foretager vi en komplet aflÊsning af alle de zoner, vi har i rute 53. Amazons API giver dig mulighed for nemt at sende dem i JSON, og vi har flere backup-servere, hvor vi konverterer det, uploader det i form af configs og har groft sagt en backup-konfiguration. Hvis der sker noget, kan vi hurtigt implementere det manuelt uden at miste DNS-indstillingsdataene.
Andet "men": Hvad pÄ dette billede er endnu ikke reserveret? Selve balanceren! Vores fordeling af kunder efter region er gjort meget enkel. Vi har domÊnerne bitrix24.ru, bitrix24.com, .de - nu er der 13 forskellige, som opererer i en rÊkke forskellige zoner. Vi kom frem til fÞlgende: Hver region har sine egne balancere. Dette gÞr det mere bekvemt at fordele pÄ tvÊrs af regioner, afhÊngigt af hvor spidsbelastningen pÄ netvÊrket er. Hvis dette er en fejl pÄ niveau med en enkelt balancer, sÄ tages den simpelthen ud af drift og fjernes fra dns. Hvis der er et eller andet problem med en gruppe balancere, sÄ bliver de sikkerhedskopieret pÄ andre sider, og skift mellem dem sker ved hjÊlp af samme rute53, fordi pÄ grund af den korte TTL, sker skift inden for maksimalt 2, 3, 5 minutter .
Tredje "men": Hvad er endnu ikke reserveret? S3, korrekt. Da vi placerede de filer, som vi gemmer for brugere i s3, troede vi oprigtigt, at det var panserbrydende, og der var ingen grund til at reservere noget der. Men historien viser, at tingene sker anderledes. Generelt beskriver Amazon S3 som en fundamental service, fordi Amazon selv bruger S3 til at gemme maskinbilleder, konfigurationer, AMI-billeder, snapshots... Og hvis s3 gÄr ned, som det skete en gang i lÞbet af disse 7 Är, sÄ lÊnge vi har brugt bitrix24, den fÞlger den som en fan Der er en hel masse ting, der dukker op - manglende evne til at starte virtuelle maskiner, api-fejl og sÄ videre.
Og S3 kan falde - det skete en gang. Derfor kom vi frem til fÞlgende ordning: For nogle Är siden var der ingen seriÞse offentlige objektopbevaringsfaciliteter i Rusland, og vi overvejede muligheden for at gÞre noget af vores eget... Heldigvis begyndte vi ikke at gÞre dette, for vi ville har gravet i den ekspertise, som vi ikke har, vi har, og ville sandsynligvis rode. Nu har Mail.ru s3-kompatibel lagerplads, Yandex har det, og en rÊkke andre udbydere har det. Til sidst kom vi til den idé, at vi for det fÞrste ville have backup, og for det andet evnen til at arbejde med lokale kopier. Specifikt til den russiske region bruger vi Mail.ru Hotbox-tjenesten, som er API-kompatibel med s3. Vi behÞvede ingen stÞrre Êndringer af koden inde i applikationen, og vi lavede fÞlgende mekanisme: i s3 er der triggere, der udlÞser oprettelse/sletning af objekter, Amazon har en tjeneste kaldet Lambda - dette er en serverlÞs lancering af kode som vil blive udfÞrt, lige nÄr visse triggere udlÞses.
Vi gjorde det meget enkelt: Hvis vores trigger udlĂžses, udfĂžrer vi kode, der kopierer objektet til Mail.ru-lageret. For fuldt ud at starte arbejdet med lokale kopier af data, har vi ogsĂ„ brug for omvendt synkronisering, sĂ„ kunder, der er i det russiske segment, kan arbejde med lager, der er tĂŠttere pĂ„ dem. Mail er ved at fuldfĂžre triggere i sin lagring - det vil vĂŠre muligt at udfĂžre omvendt synkronisering pĂ„ infrastrukturniveau, men indtil videre gĂžr vi dette pĂ„ niveau med vores egen kode. Hvis vi ser, at en klient har postet en fil, placerer vi pĂ„ kodeniveau hĂŠndelsen i en kĂž, behandler den og laver omvendt replikering. Hvorfor det er dĂ„rligt: ââHvis vi udfĂžrer en eller anden form for arbejde med vores objekter uden for vores produkt, det vil sige pĂ„ en eller anden mĂ„de eksternt, tager vi det ikke i betragtning. Derfor venter vi til slutningen, hvor triggere dukker op pĂ„ lagerniveauet, sĂ„ uanset hvor vi eksekverer koden fra, bliver objektet, der kom til os, kopieret i den anden retning.
PĂ„ kodeniveau registrerer vi begge lagre for hver klient: den ene betragtes som den vigtigste, den anden betragtes som en backup. Hvis alt er i orden, arbejder vi med lageret, der er tĂŠttere pĂ„ os: det vil sige, vores kunder, der er i Amazon, de arbejder med S3, og dem, der arbejder i Rusland, de arbejder med Hotbox. Hvis flaget udlĂžses, skal failover vĂŠre forbundet, og vi skifter klienter til et andet lager. Vi kan afkrydse dette felt uafhĂŠngigt efter region og kan skifte dem frem og tilbage. Vi har ikke brugt dette i praksis endnu, men vi har sĂžrget for denne mekanisme, og vi tror, ââat vi en dag fĂ„r brug for netop denne switch og kommer til nytte. Dette er allerede sket en gang.
Ă h, og Amazon lĂžb vĂŠk...
Denne april markerer Ă„rsdagen for begyndelsen af ââTelegram-blokering i Rusland. Den mest berĂžrte udbyder, der faldt ind under dette, er Amazon. Og desvĂŠrre led russiske virksomheder, der arbejdede for hele verden, mere.
Hvis virksomheden er global, og Rusland er et meget lille segment for det, 3-5% - ja, pÄ en eller anden mÄde kan du ofre dem.
Hvis dette er et rent russisk firma - jeg er sikker pÄ, at det skal placeres lokalt - ja, det vil simpelthen vÊre bekvemt for brugerne selv, behageligt, og der vil vÊre fÊrre risici.
Hvad hvis dette er en virksomhed, der opererer globalt og har omtrent lige mange kunder fra Rusland og andre steder i verden? Forbindelsen mellem segmenterne er vigtig, og de skal arbejde sammen pÄ den ene eller anden mÄde.
Tilbage i slutningen af ââmarts 2018 sendte Roskomnadzor et brev til de stĂžrste operatĂžrer, hvori de informerede dem om deres planer om at blokere flere millioner Amazon IP-adresser for at blokere... Zello messenger. Takket vĂŠre de samme udbydere lĂŠkkede de med succes brevet til alle, og det blev klart, at forbindelsen til Amazon kunne bryde sammen. Det var fredag, og vi lĂžb i panik til vores kolleger pĂ„ servers.ru og sagde: "Venner, vi har brug for flere servere, der ikke skal vĂŠre i Rusland, ikke hos Amazon, men for eksempel et sted i Amsterdam," sĂ„ vi i det mindste pĂ„ en eller anden mĂ„de kan oprette vores egne servere der. vpn Og proxyer til nogle endpoints, som vi ikke har kontrol over, som f.eks. S3-endpoints â vi kan ikke forsĂžge at oprette en ny tjeneste og fĂ„ en anden IP-adresse; vi skal stadig kunne nĂ„ dem. Inden for et par dage havde vi konfigureret disse servere, de var oppe at kĂžre, og var stort set forberedt pĂ„, at blokeringen skulle begynde. Interessant nok sagde Roskomnadzor, efter at have set postyret og panikken: "Nej, vi blokerer ikke noget lige nu." (Men det var lige indtil det Ăžjeblik, de begyndte at blokere Telegram.) Efter at have konfigureret bypass-muligheder og indset, at blokeringen ikke var blevet implementeret, besluttede vi alligevel ikke at undersĂžge det hele. Bare for en sikkerheds skyld.
Og i 2019 lever vi stadig under forhold med blokering. Jeg kiggede i gÄr aftes: omkring en million IP'er er fortsat blokeret. Sandt nok var Amazon nÊsten fuldstÊndig ophÊvet, pÄ sit hÞjeste nÄede det 20 millioner adresser... Generelt er virkeligheden, at der mÄske ikke er sammenhÊng, god sammenhÊng. Pludselig. Det eksisterer mÄske ikke af tekniske Ärsager - brande, gravemaskiner, alt det der. Eller, som vi har set, ikke helt teknisk. Derfor kan nogen store og store, med deres egne AS'er, sikkert klare dette pÄ andre mÄder - direct connect og andre ting er allerede pÄ l2 niveau. Men i en simpel version, som vores eller endnu mindre, kan du, for en sikkerheds skyld, have redundans pÄ niveauet med servere rejst et andet sted, konfigureret pÄ forhÄnd vpn, proxy, med mulighed for hurtigt at skifte konfigurationen til dem i disse segmenter der er afgÞrende for din tilslutning. Dette var nyttigt for os mere end én gang, da Amazons blokering begyndte; i vÊrste fald tillod vi kun S3-trafik gennem dem, men efterhÄnden blev alt dette lÞst.
Hvordan reserverer man... en hel udbyder?
Lige nu har vi ikke et scenarie, hvis hele Amazonas gÄr ned. Vi har et lignende scenarie for Rusland. I Rusland blev vi hostet af én udbyder, fra hvem vi valgte at have flere websteder. Og for et Är siden stod vi over for et problem: Selvom det er to datacentre, kan der vÊre problemer allerede pÄ niveau med udbyderens netvÊrkskonfiguration, som stadig vil pÄvirke begge datacentre. Og vi kan ende med at vÊre utilgÊngelige pÄ begge sider. Det er selvfÞlgelig det, der skete. Vi endte med at genoverveje arkitekturen indeni. Det har ikke Êndret sig ret meget, men for Rusland har vi nu to websteder, som ikke er fra samme udbyder, men fra to forskellige. Hvis det ene fejler, kan vi skifte til det andet.
Hypotetisk, for Amazon overvejer vi muligheden for reservation pÄ niveau med en anden udbyder; mÄske Google, mÄske en anden... Men indtil videre har vi observeret i praksis, at mens Amazon har ulykker pÄ niveau med én tilgÊngelighedszone, er ulykker pÄ niveau med en hel region ret sjÊldne. Derfor har vi teoretisk set den idé, at vi mÄske foretager en "Amazon is not Amazon" reservation, men i praksis er det endnu ikke tilfÊldet.
Et par ord om automatisering
Er automatisering altid nÞdvendigt? Her er det passende at minde om Dunning-Kruger-effekten. PÄ "x"-aksen er vores viden og erfaring, som vi opnÄr, og pÄ "y"-aksen er tillid til vores handlinger. FÞrst ved vi ingenting og er slet ikke sikre. SÄ ved vi lidt og bliver mega-sikre - det er den sÄkaldte "top af dumhed", godt illustreret af billedet "demens og mod". SÄ har vi lÊrt lidt og er klar til at gÄ i kamp. SÄ trÊder vi pÄ nogle mega-alvorlige fejl og befinder os i en fortvivlelses dal, nÄr vi tilsyneladende ved noget, men faktisk ikke ved meget. SÄ, efterhÄnden som vi fÄr erfaring, bliver vi mere selvsikre.
Vores logik omkring forskellige automatiske skift til bestemte ulykker er meget godt beskrevet af denne graf. Vi startede - vi vidste ikke, hvordan vi skulle gÞre noget, nÊsten alt arbejde blev udfÞrt i hÄnden. SÄ indsÄ vi, at vi kunne knytte automatisering til alting og ligesom sove roligt. Og pludselig trÊder vi pÄ en mega-rive: en falsk positiv udlÞses, og vi skifter trafik frem og tilbage, nÄr vi pÄ en god mÄde ikke skulle have gjort dette. FÞlgelig bryder replikationen sammen eller noget andet - dette er selve fortvivlelsens dal. Og sÄ kommer vi til den forstÄelse, at vi skal gribe alt fornuftigt an. Det vil sige, at det giver mening at stole pÄ automatisering, hvilket giver mulighed for falske alarmer. Men! hvis konsekvenserne kan vÊre ÞdelÊggende, sÄ er det bedre at overlade det til vagtskiftet, til de vagthavende ingeniÞrer, som vil sÞrge for og overvÄge, at der virkelig er en ulykke, og vil udfÞre de nÞdvendige handlinger manuelt...
Konklusion
I lĂžbet af 7 Ă„r gik vi fra, at nĂ„r noget faldt, var der panik-panik, til forstĂ„elsen af, at problemer ikke findes, der er kun opgaver, de skal - og kan - lĂžses. NĂ„r du bygger en service, sĂ„ se pĂ„ den fra oven, vurder alle de risici, der kan ske. Hvis du ser dem med det samme, sĂ„ sĂžrg for redundans pĂ„ forhĂ„nd og muligheden for at bygge en fejltolerant infrastruktur, fordi ethvert punkt, der kan fejle og fĂžre til tjenestens ubrugelighed, vil helt sikkert gĂžre det. Og selvom det ser ud til, at nogle elementer i infrastrukturen absolut ikke vil fejle - som den samme s3, sĂ„ husk stadig pĂ„, at de kan. Og i det mindste i teorien, hav en idĂ© om, hvad du vil gĂžre med dem, hvis der sker noget. Hav en risikostyringsplan. NĂ„r du tĂŠnker pĂ„ at gĂžre alting automatisk eller manuelt, sĂ„ vurder risiciene: hvad sker der, hvis automatiseringen begynder at skifte alt - vil det ikke fĂžre til en endnu vĂŠrre situation sammenlignet med en ulykke? MĂ„ske et eller andet sted er det nĂždvendigt at bruge et rimeligt kompromis mellem brugen af ââautomatisering og reaktionen fra den vagthavende ingeniĂžr, som vil vurdere det reelle billede og forstĂ„, om noget skal skiftes pĂ„ stedet eller "ja, men ikke nu."
Et rimeligt kompromis mellem perfektionisme og reel indsats, tid, penge, som du kan bruge pÄ den ordning, du i sidste ende vil have.
Denne tekst er en opdateret og udvidet version af Alexander Demidovs rapport pÄ konferencen .
Kilde: www.habr.com
