Haut huet de Bitrix24 Service keng Honnerte vu Gigabits Traffic, an och net eng rieseg Flott vu Serveren (och wann et natierlech e puer existéierend sinn). Awer fir vill Clienten ass et den Haaptinstrument fir an der Firma ze schaffen; et ass eng richteg geschäftlech kritesch Applikatioun. Dofir gëtt et kee Wee fir ze falen. Wat ass wann de Crash geschitt ass, awer de Service "erholl" sou séier datt keen eppes gemierkt huet? A wéi ass et méiglech failover ëmzesetzen ouni d'Qualitéit vun der Aarbecht an d'Zuel vun de Clienten ze verléieren? Den Alexander Demidov, Direkter vu Cloud Servicer bei Bitrix24, huet fir eise Blog geschwat wéi de Reservatiounssystem iwwer déi 7 Joer vun der Existenz vum Produkt evoluéiert huet.
"Mir hunn Bitrix24 als SaaS viru 7 Joer gestart. D'Haaptschwieregkeet war wahrscheinlech déi folgend: ier et ëffentlech als SaaS lancéiert gouf, existéiert dëst Produkt einfach am Format vun enger Box Léisung. Clienten hunn et vun eis kaaft, et op hire Server gehost, e Firmeportal opgeriicht - eng allgemeng Léisung fir Mataarbechterkommunikatioun, Dateilagerung, Taskmanagement, CRM, dat ass alles. A bis 2012 hu mir décidéiert datt mir et als SaaS lancéiere wollten, se selwer verwalten, Feeler Toleranz an Zouverlässegkeet garantéieren. Mir hunn Erfahrung ënnerwee gemaach, well mir et bis dohinner einfach net haten - mir waren nëmme Softwarehersteller, net Serviceprovider.
Wann Dir de Service lancéiert, hu mir verstanen datt dat Wichtegst ass fir Feeler Toleranz, Zouverlässegkeet a konstante Disponibilitéit vum Service ze garantéieren, well wann Dir eng einfach gewéinlech Websäit hutt, e Buttek, zum Beispill, an et fällt op Iech a sëtzt do fir eng Stonn, nëmmen Dir leiden, Dir verléiert Bestellungen, Dir verléiert Clienten, awer fir Äre Client selwer ass dëst net ganz kritesch fir hien. Hie war natierlech opgeregt, awer hien ass gaang an et op engem anere Site kaaft. A wann dëst eng Applikatioun ass, op där all d'Aarbechten an der Firma, Kommunikatioun, Entscheedunge gebonnen sinn, dann ass dat Wichtegst d'Vertraue vun de Benotzer ze gewannen, dat heescht, se net ze loossen an net ze falen. Well all Aarbecht kann ophalen wann eppes dobannen net funktionnéiert.
Bitrix.24 als SaaS
Mir hunn den éischte Prototyp e Joer virum ëffentleche Start, am Joer 2011, zesummegesat. Mir hunn et an ongeféier enger Woch versammelt, gekuckt, gedréint - et huet souguer geschafft. Dat ass, Dir kënnt an d'Form goen, den Numm vum Portal do aginn, en neie Portal géif opmaachen, an eng Benotzerbasis gëtt erstallt. Mir hunn et gekuckt, de Produit prinzipiell bewäert, ofgerappt an e ganzt Joer weider verfeinert. Well mir eng grouss Aufgab haten: mir wollten net zwee verschidde Codebasen maachen, mir wollten net e separat verpackt Produkt, separat Cloud-Léisungen ënnerstëtzen - mir wollten alles an engem Code maachen.
Eng typesch Webapplikatioun zu där Zäit war e Server op deem e PHP-Code leeft, eng mysql-Datebank, Dateien eropgeluede ginn, Dokumenter, Biller ginn an den Upload-Dossier gesat - gutt, et funktionnéiert alles. Och, et ass onméiglech e kritesch stabile Webservice mat dësem ze starten. Do gëtt verdeelt Cache net ënnerstëtzt, Datebankreplikatioun gëtt net ënnerstëtzt.
Mir hunn d'Ufuerderunge formuléiert: dëst ass d'Fäegkeet fir op verschiddene Plazen ze lokaliséieren, Replikatioun z'ënnerstëtzen an am Idealfall a verschiddene geographesch verdeelt Datenzenteren ze lokaliséieren. Trennt d'Produktlogik an, tatsächlech, Datenspeicherung. Kënnen dynamesch no der Belaaschtung skaléieren, a Statik ganz toleréieren. Aus dësen Iwwerleeungen sinn eigentlech d'Ufuerderunge vum Produkt entstanen, déi mir am Laf vum Joer verfeinert hunn. Wärend dëser Zäit, an der Plattform, déi sech als vereenegt erausgestallt huet - fir Boxléisungen, fir eisen eegene Service - hu mir Ënnerstëtzung gemaach fir déi Saachen déi mir gebraucht hunn. Ënnerstëtzung fir mysql Replikatioun um Niveau vum Produkt selwer: dat ass, den Entwéckler, deen de Code schreift, denkt net un wéi seng Ufroe verdeelt ginn, hien benotzt eisen API, a mir wësse wéi d'Schreiwen a Liesen Ufroen tëscht Masters korrekt verdeelen a Sklaven.
Mir hunn Ënnerstëtzung um Produktniveau fir verschidde Cloud Objektspeicherungen gemaach: Google Storage, Amazon s3, plus Ënnerstëtzung fir Open Stack Swift. Dofir war dëst praktesch souwuel fir eis als Service wéi och fir Entwéckler déi mat enger verpackter Léisung schaffen: wa se just eis API fir d'Aarbecht benotzen, denken se net un wou d'Datei schlussendlech gespäichert gëtt, lokal um Dateiesystem oder an der Objektdateilagerung.
Als Resultat hu mir direkt decidéiert datt mir um Niveau vum ganzen Datacenter reservéieren. Am 2012 hu mir ganz op Amazon AWS lancéiert well mir schonn Erfahrung mat dëser Plattform haten - eis eege Websäit gouf do gehost. Mir waren ugezunn vun der Tatsaach, datt an all Regioun Amazon e puer Disponibilitéitszonen huet - tatsächlech (an hirer Terminologie) e puer Datenzenteren, déi méi oder manner onofhängeg vuneneen sinn an eis erlaben um Niveau vun engem ganzen Rechenzentrum ze reservéieren: wann et op eemol klappt, ginn d'Datebanke replizéiert Master-Master, d'Webapplikatiounsservere ginn gebackupt, an déi statesch Daten ginn op d's3 Objektspeicher geplënnert. D'Laascht ass equilibréiert - deemools vun Amazon elb, awer e bësse méi spéit koume mir zu eisen eegene Lastbalancer, well mir méi komplex Logik gebraucht hunn.
Wat se wollten ass wat se kruten ...
All déi elementar Saachen déi mir wollten garantéieren - Feeler Toleranz vun de Serveren selwer, Web Uwendungen, Datenbanken - alles huet gutt geschafft. Den einfachsten Szenario: wann eng vun eise Webapplikatiounen klappt, dann ass alles einfach - si ginn aus Balance ausgeschalt.
De Balancer (deemools war et den Elb vun Amazon) markéiert Maschinnen, déi aus der Rei waren, als ongesond an hunn d'Laaschtverdeelung op hinnen ausgeschalt. Amazon Autoscaling huet geschafft: wann d'Laascht gewuess ass, goufen nei Maschinnen an d'Autoscaling Grupp bäigefüügt, d'Laascht gouf op nei Maschinnen verdeelt - alles war gutt. Mat eise Balancer ass d'Logik ongeféier d'selwecht: wann eppes mam Applikatiounsserver geschitt, hu mir Ufroe vun him ewechgeholl, dës Maschinnen erausgeheien, nei starten a weider schaffen. De Schema huet e bësse geännert iwwer d'Jore, awer funktionnéiert weider: et ass einfach, verständlech, an et gi keng Schwieregkeeten.
Mir schaffen op der ganzer Welt, Client Belaaschtung Peaks sinn komplett anescht, an, op eng frëndlech Manéier, solle mir fäheg sinn bestëmmte Service Aarbecht op all Komponente vun eisem System zu all Moment auszeféieren - onnotéiert vun Clienten. Dofir hu mir d'Méiglechkeet d'Datebank aus der Operatioun auszeschalten, d'Laascht op en zweeten Rechenzentrum ëmverdeelen.
Wéi funktionéiert dat alles? — Mir wiesselen den Traffic op en Aarbechtsdatenzenter - wann et en Accident am Rechenzentrum ass, dann komplett, wann dat eis geplangten Aarbecht mat enger Datebank ass, da schalte mir en Deel vum Traffic deen dëse Clienten servéiert an en zweeten Rechenzentrum, suspendéiert et Replikatioun. Wann nei Maschinnen fir Webapplikatioune gebraucht ginn, well d'Laascht op den zweeten Rechenzentrum eropgaang ass, fänken se automatesch un. Mir maachen d'Aarbecht fäerdeg, d'Replikatioun gëtt restauréiert, a mir ginn d'ganz Laascht zréck. Wa mir eng Aarbecht an der zweeter DC spigelen mussen, zum Beispill, Systemupdates installéieren oder Astellungen an der zweeter Datebank änneren, da widderhuelen mir allgemeng datselwecht, just an déi aner Richtung. A wann dëst en Accident ass, da maache mir alles trivial: mir benotzen den Event-Handler Mechanismus am Iwwerwaachungssystem. Wann e puer Kontrollen ausgeléist ginn an de Status op kritesch geet, da lafen mir dësen Handler, en Handler deen dës oder déi Logik ausféiere kann. Fir all Datebank spezifizéiere mir wéi ee Server de Failover dofir ass, a wou de Traffic muss gewiesselt ginn wann et net verfügbar ass. Historesch benotze mir Nagios oder e puer vu senge Gabel an enger oder anerer Form. Am Prinzip existéieren ähnlech Mechanismen a bal all Iwwerwaachungssystem, mir benotzen nach näischt méi komplex, awer vläicht iergendwann. Elo gëtt d'Iwwerwaachung duerch Onverfügbarkeet ausgeléist an huet d'Fäegkeet eppes ze wiesselen.
Hu mir alles reservéiert?
Mir hunn vill Clienten aus den USA, vill Clienten aus Europa, vill Clienten déi méi no un den Osten sinn - Japan, Singapur a sou weider. Natierlech, sinn e groussen Deel vun de Clienten an Russland. Dat ass, Aarbecht ass net an enger Regioun. D'Benotzer wëllen eng séier Äntwert, et ginn Ufuerderunge fir verschidde lokal Gesetzer ze respektéieren, a bannent all Regioun reservéiere mir zwee Datenzenteren, plus et ginn e puer zousätzlech Servicer, déi, erëm, bequem sinn an enger Regioun ze placéieren - fir Clienten déi an dëser Regioun schaffen. REST Handler, Autorisatiounsserver, si si manner kritesch fir d'Operatioun vum Client als Ganzt, Dir kënnt se mat engem klengen akzeptablen Verspéidung duerchschalten, awer Dir wëllt d'Rad net nei erfannen wéi se se iwwerwaachen a wat ze maachen mat hinnen. Dofir versichen mir existéierend Léisunge maximal ze benotzen, anstatt eng Zort Kompetenz an zousätzlech Produkter z'entwéckelen. An iergendwou benotze mir trivial Schalter um DNS-Niveau, a mir bestëmmen d'Liveliness vum Service duerch déiselwecht DNS. Amazon huet e Route 53 Service, awer et ass net nëmmen en DNS an deem Dir Entréen maache kënnt an dat ass et - et ass vill méi flexibel a praktesch. Duerch et kënnt Dir geo-verdeelt Servicer mat Geolocatiounen bauen, wann Dir se benotzt fir ze bestëmmen wou de Client hierkënnt an him bestëmmte Rekorder ginn - mat senger Hëllef kënnt Dir Failoverarchitekturen bauen. Déiselwecht Gesondheetskontrolle sinn an der Route 53 selwer konfiguréiert, Dir setzt d'Endpunkte fest, déi iwwerwaacht ginn, setzen Metriken, setzen wéi eng Protokoller fir d'"Liveness" vum Service ze bestëmmen - tcp, http, https; setzen d'Frequenz vun de Kontrollen déi bestëmmen ob de Service lieweg ass oder net. An an der DNS selwer spezifizéiert Dir wat primär wäert sinn, wat sekundär ass, wou ze wiesselen wann de Gesondheetscheck an der Route 53 ausgeléist gëtt. All dëst kann mat e puer aner Tools gemaach ginn, awer firwat ass et bequem - mir setzen et eng Kéier op an dann iwwerhaapt net driwwer nodenken wéi mir Kontrollen maachen, wéi mir wiesselen: alles funktionéiert eleng.
Déi éischt "awer": wéi a mat wat fir de Wee 53 selwer ze reservéieren? Wien weess, wat wann him eppes geschitt? Glécklecherweis hu mir ni op dëser Rake getrëppelt, awer nach eng Kéier, ech wäert eng Geschicht viraus hunn firwat mir geduecht hunn datt mir nach ëmmer musse reservéieren. Hei hu mir eis am Viraus Stréi ausgeluecht. E puer Mol am Dag maache mir eng komplett Ausluede vun all Zonen déi mir an der Route 53 hunn. D'Amazon API erlaabt Iech se einfach an JSON ze schécken, a mir hunn e puer Backup-Server wou mir et konvertéieren, eroplueden a Form vu Konfiguratiounen an hunn, ongeféier geschwat, eng Backupkonfiguratioun. Wann eppes geschitt, kënne mir et séier manuell ofsetzen ouni d'DNS-Astellungsdaten ze verléieren.
Zweet "awer": Wat op dëser Foto ass nach net reservéiert ginn? De Balancer selwer! Eis Verdeelung vu Clienten no Regioun ass ganz einfach gemaach. Mir hunn d'Domänen bitrix24.ru, bitrix24.com, .de - elo ginn et 13 verschidden, déi a verschiddenen Zonen operéieren. Mir sinn op déi folgend komm: all Regioun huet seng eege Balancer. Dëst mécht et méi bequem iwwer d'Regiounen ze verdeelen, ofhängeg vu wou d'Spëtzbelaaschtung um Netz ass. Wann dëst e Feeler um Niveau vun engem eenzege Balancer ass, da gëtt et einfach aus dem Déngscht geholl an aus den dns geläscht. Wann et e Problem mat enger Grupp vu Balancer ass, da ginn se op anere Site gebacken, an tëscht hinnen ze wiesselen gëtt mat der selwechter Route53 gemaach, well wéinst dem kuerzen TTL de Wiessel bannent maximal 2, 3, 5 Minutten geschitt. .
Drëtt "awer": Wat ass nach net reservéiert? S3, richteg. Wa mir d'Fichier'en plazéiert hunn, déi mir fir d'Benotzer an s3 späicheren, hu mir oprecht gegleeft datt et Rüstungspiercing war an et war net néideg eppes do ze reservéieren. Awer d'Geschicht weist datt d'Saachen anescht geschéien. Am Allgemengen beschreift Amazon S3 als fundamentale Service, well Amazon selwer S3 benotzt fir Maschinnbilder, Configuratiounen, AMI Biller, Snapshots ze späicheren ... A wann s3 crasht, wéi eemol an deene 7 Joer geschitt ass, soulaang mir benotzt hunn bitrix24, et follegt et wéi e Fan Et gëtt eng ganz Rëtsch Saachen déi opkommen - Onméiglechkeet fir virtuell Maschinnen ze starten, API-Feeler, asw.
A S3 ka falen - et ass eemol geschitt. Dofir si mir op de folgende Schema komm: Virun e puer Joer gouf et keng sérieux ëffentlech Objektlagerungsanlagen a Russland, a mir hunn d'Optioun ugesinn fir eppes vun eisem eegenen ze maachen ... Glécklech hu mir net ugefaang dat ze maachen, well mir géifen hunn an d'Expertise gegruewen, déi mir net hunn, déi mir hunn, a wäerte wahrscheinlech schueden. Elo huet Mail.ru s3-kompatibel Stockage, Yandex huet et, an eng Rei vun anere Fournisseuren hunn et. Mir sinn schlussendlech op d'Iddi komm, datt mir als éischt de Backup wollten hunn, an zweetens d'Fäegkeet mat lokalen Kopien ze schaffen. Fir déi russesch Regioun speziell benotze mir de Mail.ru Hotbox Service, deen API kompatibel ass mat s3. Mir hu keng gréisser Ännerunge fir de Code an der Applikatioun gebraucht, a mir hunn de folgende Mechanismus gemaach: an s3 ginn et Ausléiser déi d'Erstelle/Läschen vun Objeten ausléisen, Amazon huet e Service mam Numm Lambda - dëst ass e Serverlosen Start vum Code dat gëtt just ausgefouert wann bestëmmte Ausléiser ausgeléist ginn.
Mir hunn et ganz einfach gemaach: wann eisen Ausléiser brennt, maache mir Code aus, deen den Objet an d'Mail.ru Späichere kopéiert. Fir d'Aarbecht mat lokalen Kopien vun Daten voll ze lancéieren, brauche mir och ëmgedréint Synchroniséierung, fir datt Clienten, déi am russesche Segment sinn, mat Lagerung schaffen, déi méi no bei hinnen ass. Mail ass amgaang Trigger a senger Lagerung ze kompletéieren - et wäert méiglech sinn ëmgedréint Synchroniséierung um Infrastrukturniveau ze maachen, awer fir de Moment maache mir dat um Niveau vun eisem eegene Code. Wa mir gesinn datt e Client eng Datei gepost huet, da setzen mir um Codeniveau den Event an eng Schlaang, veraarbecht et a maachen ëmgedréint Replikatioun. Firwat ass et schlecht: wa mir eng Aart Aarbecht mat eisen Objeten ausserhalb vun eisem Produkt maachen, dat heescht, duerch e puer extern Mëttelen, wäerte mir et net berücksichtegen. Dofir waarden mir bis zum Schluss, wann Ausléiser um Späicherniveau erscheinen, sou datt egal wou mir de Code ausféieren, den Objet deen eis komm ass an déi aner Richtung kopéiert.
Um Code Niveau registréiere mir béid Späichere fir all Client: een gëtt als Haapt ugesinn, deen aneren als Backup. Wann alles gutt ass, schaffe mir mat der Späichere, déi eis méi no ass: dat ass, eis Clienten, déi an Amazon sinn, si schaffen mat S3, an déi, déi a Russland schaffen, si schaffen mat Hotbox. Wann de Fändel ausgeléist gëtt, da soll de Failover verbonne sinn, a mir wiessele Clienten op eng aner Späichere. Mir kënnen dës Këscht onofhängeg vun der Regioun kontrolléieren a kënnen se zréck an zréck wiesselen. Mir hunn dat nach net an der Praxis benotzt, awer mir hunn dëse Mechanismus virgesinn a mir mengen datt mir iergendwann dëse Schalter brauchen a praktesch kommen. Dat ass schonn eng Kéier geschitt.
Oh, an Amazon ass fortgelaf ...
Dësen Abrëll markéiert den Anniversaire vum Ufank vum Telegram Blocking a Russland. Dee meescht betraffene Fournisseur deen ënner dësem gefall ass Amazon. An, leider, russesch Firmen, déi fir d'ganz Welt geschafft hunn, méi leiden.
Wann d'Firma global ass a Russland ass e ganz klenge Segment dofir, 3-5% - gutt, op eng oder aner Manéier, kënnt Dir se opferen.
Wann dëst eng reng russesch Firma ass - ech si sécher datt et lokal muss lokaliséiert ginn - gutt, et wäert einfach fir d'Benotzer selwer bequem sinn, bequem an et gëtt manner Risiken.
Wat ass wann dëst eng Firma ass, déi weltwäit operéiert an ongeféier déiselwecht Zuel vu Clienten aus Russland an iergendwou ronderëm d'Welt huet? D'Konnektivitéit vun de Segmenter ass wichteg, a si mussen op eng oder aner Manéier matenee schaffen.
Enn Mäerz 2018 huet de Roskomnadzor e Bréif un déi gréisste Betreiber geschéckt datt se geplangt hunn e puer Millioune Amazon IPs ze blockéieren fir ze blockéieren ... de Zello Messenger. Dank dëse selwechten Ubidder - si hunn de Bréif un jiddereen erfollegräich geleckt, an et war e Verständnis datt d'Verbindung mat Amazon auserneen fällt. Et war Freideg, mir sinn an enger Panik un eis Kollegen vun servers.ru gelaf, a gesot: "Frënn, mir brauche verschidde Serveren, déi net a Russland, net an Amazon, awer zum Beispill iergendwou zu Amsterdam sinn", fir fir op d'mannst iergendwéi eisen eegene VPN a Proxy do ze installéieren fir e puer Endpunkten déi mir op kee Fall beaflosse kënnen, zum Beispill Endponte vum selwechte s3 - mir kënnen net probéieren en neie Service z'erhéijen an eng aner IP ze kréien, mir du muss nach dohinner kommen. An nëmmen e puer Deeg hu mir dës Serveren opgeriicht, se opgestallt a lafen, an allgemeng virbereet fir de Moment wou d'Blockéierung ugefaang huet. Et ass virwëtzeg datt de RKN, kuckt op d'Gesiicht a Panik, sot: "Nee, mir blockéieren elo näischt." (Awer dat ass genee bis de Moment wou d'Telegram ugefaang ze blockéieren.) Nodeems mir d'Bypass-Fähigkeiten ageriicht hunn a gemierkt hunn datt d'Blockéierung net agefouert gouf, hu mir awer net ugefaang déi ganz Saach ze sortéieren. Jo, just am Fall.
An am Joer 2019 liewen mir nach ëmmer a Blockéierungsbedéngungen. Ech hunn gëschter Owend gekuckt: ongeféier eng Millioun IPe si weider gespaart. Richteg, Amazon war bal komplett deblockéiert, op hirem Héichpunkt erreecht et 20 Milliounen Adressen ... Am Allgemengen ass d'Realitéit datt et vläicht keng Kohärenz gëtt, gutt Kohärenz. Op eemol. Et kann aus technesche Grënn net existéieren - Bränn, Bagger, all dat. Oder, wéi mir gesinn hunn, net ganz technesch. Dofir kann een grouss a grouss, mat hiren eegenen ASen, dëst wahrscheinlech op aner Manéier verwalten - direkt Verbindung an aner Saachen sinn schonn um l2 Niveau. Awer an enger einfacher Versioun, wéi eis oder souguer méi kleng, kënnt Dir, just am Fall, Redundanz hunn um Niveau vun Serveren, déi soss anzwousch opgewuess sinn, am Viraus konfiguréiert VPN, Proxy, mat der Fäegkeet fir d'Konfiguratioun séier an deene Segmenter ze wiesselen déi kritesch sinn fir Är Konnektivitéit. Dëst ass fir eis méi wéi eemol nëtzlech, wéi d'Blockéierung vun Amazon ugefaang huet; am schlëmmste Fall Szenario hu mir nëmmen de S3 Traffic duerch si erlaabt, awer no an no gouf dëst alles geléist.
Wéi reservéiert ... e ganze Provider?
De Moment hu mir keen Szenario am Fall wou d'ganz Amazon erofgeet. Mir hunn en ähnlechen Szenario fir Russland. A Russland ware mir vun engem Provider gehost, vun deem mir gewielt hunn e puer Site ze hunn. An virun engem Joer hu mir e Problem konfrontéiert: Och wann dës zwee Datenzenteren sinn, kënnen et Problemer schonn um Niveau vun der Netzkonfiguratioun vum Provider sinn, déi nach ëmmer béid Datenzenteren beaflossen. A mir kënnen op béide Site net verfügbar sinn. Natierlech ass dat geschitt. Mir hunn endlech d'Architektur dobannen iwwerluecht. Et huet net vill geännert, mee fir Russland hu mir elo zwee Siten, déi net aus dem selwechte Provider sinn, mä vun zwee verschiddene. Wann dat eent feelt, kënne mir op deen aneren wiesselen.
Hypothetesch, fir Amazon betruechte mir d'Méiglechkeet vun Reservatioun um Niveau vun engem aneren Provider; vläicht Google, vläicht een aneren ... Awer bis elo hu mir an der Praxis observéiert datt während Amazon Accidenter um Niveau vun enger Disponibilitéitszone huet, Accidenter um Niveau vun enger ganzer Regioun zimlech rar. Dofir hu mir theoretesch d'Iddi datt mir eng Reservatioun "Amazon is not Amazon" maachen, awer an der Praxis ass dat nach net de Fall.
E puer Wierder iwwer Automatisatioun
Ass Automatisatioun ëmmer néideg? Hei ass et ubruecht den Dunning-Kruger Effekt z'erënneren. Op der "x" Achs ass eist Wëssen an Erfahrung, déi mir gewannen, an op der "y" Achs ass Vertrauen an eis Handlungen. Am Ufank wësse mer näischt a si guer net sécher. Da wësse mer e bëssen a ginn mega-zouversichtlech - dat ass de sougenannte "Peak vun der Dommheet", gutt illustréiert duerch d'Bild "Demenz a Courage". Dann hu mir e bësse geléiert a si prett fir an d'Schluecht ze goen. Da trëppele mir op e puer mega-eescht Feeler a befannen eis an engem Dall vun der Verzweiflung, wa mir schéngen eppes ze wëssen, awer tatsächlech net vill wëssen. Dann, wéi mir Erfahrung kréien, gi mir méi zouversiichtlech.
Eis Logik iwwer verschidden automatesch Schalter op bestëmmten Accidenter ass ganz gutt vun dëser Grafik beschriwwen. Mir hunn ugefaang - mir woussten net wéi eppes ze maachen, bal all d'Aarbecht gouf vun der Hand gemaach. Dunn hu mir gemierkt datt mir Automatisatioun un alles kënne befestigen a wéi friddlech schlofen. An op eemol trëppele mir op eng Mega-Rake: e falscht Positiv gëtt ausgeléist, a mir wiesselen den Traffic hin an hier, wa mer dat op eng gutt Manéier net sollte maachen. Dofir brécht d'Replikatioun of oder soss eppes - dëst ass de ganzen Dall vun der Verzweiflung. An da komme mer zum Verständnis, datt mir alles verstänneg ugoen mussen. Dat ass, et mécht Sënn op Automatisatioun ze vertrauen, fir d'Méiglechkeet vu falschen Alarmer virgesinn. Awer! wann d'Konsequenze zerstéierend kënne sinn, dann ass et besser, et un d'Pflicht ze iwwerloossen, un d'Ingenieuren op der Flicht, déi sécherstellen an iwwerwaachen datt et wierklech en Accident ass, an déi néideg Aktiounen manuell maachen ...
Konklusioun
Am Laf vu 7 Joer si mir vun der Tatsaach gaang, datt wann eppes gefall ass, et Panik-Panik gouf, zum Verständnis datt Problemer net existéieren, et gëtt nëmmen Aufgaben, déi mussen - a kënnen - geléist ginn. Wann Dir e Service baut, kuckt et vun uewen un, beurteelt all d'Risiken déi geschéie kënnen. Wann Dir se direkt gesitt, da suergt fir Redundanz am Viraus an d'Méiglechkeet fir eng Feeler-tolerant Infrastruktur ze bauen, well all Punkt, deen versoen kann an zu der Inoperabilitéit vum Service féieren, wäert dat definitiv maachen. An och wann et Iech schéngt datt e puer Infrastrukturelementer definitiv net falen - wéi s3, behalen nach ëmmer datt se kënnen. An op d'mannst an der Theorie, hutt eng Iddi wat Dir mat hinnen maache wäert wann eppes geschitt. Hutt e Risikomanagementplang. Wann Dir drun denkt alles automatesch oder manuell ze maachen, bewäert d'Risiken: wat geschitt wann d'Automatisatioun alles ufänkt ze wiesselen - wäert dat net zu enger nach méi schlëmmer Situatioun am Verglach zu engem Accident féieren? Vläicht iergendwou ass et néideg e raisonnabele Kompromiss tëscht der Benotzung vun der Automatioun an der Reaktioun vum Ingenieur op der Pflicht ze benotzen, deen dat richtegt Bild evaluéiert a versteet ob eppes muss op der Plaz gewiesselt ginn oder "jo, awer net elo."
E raisonnabele Kompromiss tëscht Perfektionismus a realen Effort, Zäit, Suen, déi Dir op de Schema verbrénge kënnt, deen Dir schlussendlech hutt.
Dësen Text ass eng aktualiséiert an erweidert Versioun vum Alexander Demidov Bericht op der Konferenz .
Source: will.com