Hodiaŭ, la servo Bitrix24 ne havas centojn da gigabitoj da trafiko, nek ĝi havas grandegan aron da serviloj (kvankam, kompreneble, ekzistas sufiĉe multaj ekzistantaj). Sed por multaj klientoj ĝi estas la ĉefa ilo por labori en la kompanio; ĝi estas vera komerca aplikaĵo. Tial, ne estas maniero fali. Kio se la kraŝo ja okazus, sed la servo "resaniĝis" tiel rapide ke neniu rimarkis ion ajn? Kaj kiel eblas efektivigi malsukceson sen perdi la kvaliton de laboro kaj la nombron da klientoj? Alexander Demidov, direktoro de nubaj servoj ĉe Bitrix24, parolis por nia blogo pri kiel la rezerva sistemo evoluis dum la 7 jaroj de la ekzisto de la produkto.
"Ni lanĉis Bitrix24 kiel SaaS antaŭ 7 jaroj. La ĉefa malfacilaĵo estis verŝajne la sekva: antaŭ ol ĝi estis lanĉita publike kiel SaaS, ĉi tiu produkto simple ekzistis en la formato de boksita solvo. Klientoj aĉetis ĝin de ni, gastigis ĝin sur siaj serviloj, starigis kompanian portalon - ĝeneralan solvon por dungita komunikado, dosier-stokado, tasko-administrado, CRM, jen ĉio. Kaj antaŭ 2012, ni decidis, ke ni volas lanĉi ĝin kiel SaaS, administrante ĝin mem, certigante misfunkciadon kaj fidindecon. Ni akiris sperton survoje, ĉar ĝis tiam ni simple ne havis ĝin - ni estis nur softvarproduktantoj, ne servaj provizantoj.
Lanĉante la servon, ni komprenis, ke la plej grava afero estas certigi misfunkciadon, fidindecon kaj konstantan haveblecon de la servo, ĉar se vi havas simplan ordinaran retejon, vendejon, ekzemple, kaj ĝi falas sur vin kaj sidas tie por horo, nur vi suferas, vi perdas mendojn, vi perdas klientojn, sed por via kliento mem, ĉi tio ne estas tre kritika por li. Li estis ĉagrenita, kompreneble, sed li iris kaj aĉetis ĝin sur alia retejo. Kaj se ĉi tio estas aplikaĵo, sur kiu estas ligita la tuta laboro ene de la kompanio, komunikadoj, decidoj, tiam la plej grava afero estas gajni la fidon de uzantoj, tio estas, ne lasi ilin kaj ne fali. Ĉar ĉiu laboro povas ĉesi se io ene ne funkcias.
Bitrix.24 kiel SaaS
Ni kunvenis la unuan prototipon jaron antaŭ la publika lanĉo, en 2011. Ni kunmetis ĝin en ĉirkaŭ unu semajno, rigardis ĝin, turnis ĝin - ĝi eĉ funkciis. Tio estas, vi povus eniri la formularon, enigi la nomon de la portalo tie, nova portalo malfermiĝus, kaj uzantbazo estus kreita. Ni rigardis ĝin, taksis la produkton principe, forĵetis ĝin kaj daŭre rafinis ĝin dum tuta jaro. Ĉar ni havis grandan taskon: ni ne volis fari du malsamajn kodbazojn, ni ne volis subteni apartan pakitan produkton, apartajn nubsolvojn - ni volis fari ĉion ene de unu kodo.
Tipa TTT-apliko tiutempe estis unu servilo sur kiu funkcias iom da PHP-kodo, mysql-datumbazo, dosieroj estas alŝutitaj, dokumentoj, bildoj estas metitaj en la alŝuta dosierujo - nu, ĉio funkcias. Ve, estas neeble lanĉi kritike stabilan retservon uzante ĉi tion. Tie, distribuita kaŝmemoro ne estas subtenata, datumbaza reproduktado ne estas subtenata.
Ni formulis la postulojn: ĉi tio estas la kapablo situi en malsamaj lokoj, subteni reproduktadon, kaj ideale troviĝi en malsamaj geografie distribuitaj datumcentroj. Apartigu la produktan logikon kaj, fakte, datumstokadon. Esti kapabla dinamike grimpi laŭ la ŝarĝo, kaj toleri statiko entute. El ĉi tiuj konsideroj, fakte, aperis la postuloj por la produkto, kiujn ni rafinis dum la jaro. Dum ĉi tiu tempo, en la platformo, kiu montriĝis unuigita - por skatolaj solvoj, por nia propra servo - ni faris subtenon por tiuj aferoj, kiujn ni bezonis. Subteno por mysql-reproduktado je la nivelo de la produkto mem: tio estas, la programisto, kiu skribas la kodon, ne pensas pri kiel liaj petoj estos distribuitaj, li uzas nian apion, kaj ni scias kiel ĝuste distribui skribajn kaj legi petojn inter majstroj. kaj sklavoj.
Ni faris subtenon ĉe la produkta nivelo por diversaj stokado de nubaj objektoj: google-stokado, amazon s3, krom subteno por malferma stack swift. Tial tio estis oportuna kaj por ni kiel servo kaj por programistoj kiuj laboras kun pakita solvo: se ili nur uzas nian API por laboro, ili ne pensas pri kie la dosiero finfine estos konservita, loke en la dosiersistemo aŭ en la objekta dosierstokado.
Rezulte, ni tuj decidis, ke ni rezervos je la nivelo de la tuta datumcentro. En 2012, ni lanĉis tute sur Amazon AWS ĉar ni jam havis sperton kun ĉi tiu platformo - nia propra retejo estis gastigita tie. Altiris nin la fakto, ke en ĉiu regiono Amazono havas plurajn havebleczonojn - fakte, (laŭ ilia terminologio) pluraj datumcentroj, kiuj estas pli-malpli sendependaj unu de la alia kaj permesas al ni rezervi je la nivelo de tuta datumcentro: se ĝi subite malsukcesas, la datumbazoj estas reproduktitaj majstro-majstro, la ret-aplikaj serviloj estas sekurkopiitaj, kaj la senmovaj datumoj estas movitaj al la s3-objekta stokado. La ŝarĝo estas ekvilibra - tiutempe de Amazon elb, sed iom poste ni venis al niaj propraj ŝarĝbalanciloj, ĉar ni bezonis pli kompleksan logikon.
Kion ili deziris estas tio, kion ili ricevis...
Ĉiuj bazaj aferoj, kiujn ni volis certigi - mistoleremo de la serviloj mem, TTT-aplikoj, datumbazoj - ĉio funkciis bone. La plej simpla scenaro: se unu el niaj TTT-aplikoj malsukcesas, tiam ĉio estas simpla - ili estas malŝaltitaj de ekvilibro.
La ekvilibristo (tiutempe ĝi estis la kubo de Amazono) markis maŝinojn kiuj estis malordaj kiel nesanaj kaj malŝaltis ŝarĝdistribuon sur ili. Amazon-a aŭtoscalado funkciis: kiam la ŝarĝo kreskis, novaj maŝinoj estis aldonitaj al la aŭtoskala grupo, la ŝarĝo estis distribuita al novaj maŝinoj - ĉio estis bona. Kun niaj ekvilibristoj, la logiko estas proksimume la sama: se io okazas al la aplikaĵoservilo, ni forigas petojn de ĝi, forĵetas ĉi tiujn maŝinojn, komencas novajn kaj daŭre laboras. La skemo iom ŝanĝiĝis dum la jaroj, sed daŭre funkcias: ĝi estas simpla, komprenebla, kaj ne estas malfacilaĵoj kun ĝi.
Ni laboras ĉie en la mondo, klientaj ŝarĝpintoj estas tute malsamaj, kaj, amikeme, ni devus povi plenumi certan servan laboron sur iuj komponantoj de nia sistemo iam ajn - nerimarkite de klientoj. Tial ni havas la ŝancon malŝalti la datumbazon de funkciado, redistribuante la ŝarĝon al dua datumcentro.
Kiel ĉio funkcias? — Ni ŝanĝas trafikon al funkcianta datumcentro - se estas akcidento ĉe la datumcentro, tiam tute, se ĉi tio estas nia planita laboro kun unu datumbazo, tiam ni ŝanĝas parton de la trafiko servanta ĉi tiujn klientojn al dua datumcentro, suspendante. ĝi reproduktado. Se novaj maŝinoj estas bezonataj por TTT-aplikoj ĉar la ŝarĝo sur la dua datumcentro pliiĝis, ili komenciĝos aŭtomate. Ni finas la laboron, reproduktado estas restarigita, kaj ni resendas la tutan ŝarĝon. Se ni bezonas speguli iun laboron en la dua DC, ekzemple, instali sistemajn ĝisdatigojn aŭ ŝanĝi agordojn en la dua datumbazo, tiam, ĝenerale, ni ripetas la samon, nur en la alia direkto. Kaj se ĉi tio estas akcidento, tiam ni faras ĉion bagatele: ni uzas la mekanismon de evento-traktiloj en la monitora sistemo. Se pluraj kontroloj estas ekigitaj kaj la statuso iĝas kritika, tiam ni rulas ĉi tiun pritraktilon, pritraktilon, kiu povas ekzekuti tian aŭ alian logikon. Por ĉiu datumbazo, ni specifas kiu servilo estas la malsukceso por ĝi, kaj kie trafiko devas esti ŝanĝita se ĝi estas neatingebla. Historie, ni uzas nagios aŭ kelkajn el ĝiaj forkoj en unu aŭ alia formo. En principo, similaj mekanismoj ekzistas en preskaŭ ajna monitora sistemo; ni ankoraŭ ne uzas ion pli kompleksan, sed eble iam ni faros. Nun monitorado estas ekigita de nehavebleco kaj havas la kapablon ŝanĝi ion.
Ĉu ni rezervis ĉion?
Ni havas multajn klientojn el Usono, multajn klientojn el Eŭropo, multajn klientojn, kiuj estas pli proksime al la Oriento - Japanio, Singapuro ktp. Kompreneble, granda parto de klientoj estas en Rusio. Tio estas, laboro ne estas en unu regiono. Uzantoj volas rapidan respondon, estas postuloj por plenumi diversajn lokajn leĝojn, kaj ene de ĉiu regiono ni rezervas du datumcentrojn, krome ekzistas kelkaj aldonaj servoj, kiuj, denove, estas oportunaj por meti ene de unu regiono - por klientoj kiuj estas en. ĉi tiu regiono funkcias. REST-traktantoj, rajtigaj serviloj, ili estas malpli kritikaj por la funkciado de la kliento entute, vi povas ŝanĝi per ili kun malgranda akceptebla prokrasto, sed vi ne volas reinventi la radon pri kiel kontroli ilin kaj kion fari. kun ili. Tial ni provas uzi ekzistantajn solvojn al la maksimumo, prefere ol disvolvi ian kompetentecon en pliaj produktoj. Kaj ie ni banale uzas ŝanĝadon ĉe la DNS-nivelo, kaj ni determinas la vivecon de la servo per la sama DNS. Amazon havas Itinero 53-servon, sed ĝi ne estas nur DNS, en kiu vi povas fari enskribojn kaj jen ĝi - ĝi estas multe pli fleksebla kaj oportuna. Per ĝi vi povas konstrui geo-distribuitajn servojn kun geolokigoj, kiam vi uzas ĝin por determini de kie venis la kliento kaj doni al li certajn rekordojn - kun ĝia helpo vi povas konstrui malsukcesajn arkitekturojn. La samaj sankontroloj estas agorditaj en Itinero 53 mem, vi agordas la finpunktojn, kiuj estas monitoritaj, agordas metrikojn, agordas kiajn protokolojn por determini la "vivecon" de la servo - tcp, http, https; starigu la oftecon de kontroloj, kiuj determinas ĉu la servo vivas aŭ ne. Kaj en la DNS mem vi specifu kio estos primara, kio estos malĉefa, kie ŝanĝi se la sankontrolo estas ekigita en la itinero 53. Ĉio ĉi povas esti farita per iuj aliaj iloj, sed kial ĝi estas oportuna - ni starigas ĝin. supren unufoje kaj tiam tute ne pripensu kiel ni faras kontrolojn, kiel ni ŝanĝas: ĉio funkcias per si mem.
La unua "sed": kiel kaj kun kio rezervi itineron 53 mem? Kiu scias, kio se io okazos al li? Feliĉe, ni neniam paŝis sur ĉi tiun rastilon, sed denove mi havos rakonton antaŭ kial ni pensis, ke ni ankoraŭ bezonas rezervadon. Ĉi tie ni antaŭmetis pajlojn por ni mem. Plurfoje tage ni faras kompletan malŝarĝon de ĉiuj zonoj, kiujn ni havas en la itinero 53. La API de Amazon permesas vin facile sendi ilin en JSON, kaj ni havas plurajn rezervajn servilojn, kie ni konvertas ĝin, alŝutas ĝin en formo de agordoj kaj havas, proksimume, rezervan agordon. Se io okazas, ni povas rapide disfaldi ĝin permane sen perdi la datumojn de DNS-agordoj.
Dua "sed": Kio en ĉi tiu bildo ankoraŭ ne estis rezervita? La ekvilibristo mem! Nia distribuado de klientoj laŭ regiono estas tre simpla. Ni havas la domajnojn bitrix24.ru, bitrix24.com, .de - nun estas 13 malsamaj, kiuj funkcias en diversaj zonoj. Ni venis al la jena: ĉiu regiono havas siajn proprajn ekvilibrilojn. Ĉi tio igas ĝin pli oportuna distribui trans regionoj, depende de kie estas la pintŝarĝo sur la reto. Se ĉi tio estas malsukceso je la nivelo de ununura ekvilibristo, tiam ĝi estas simple forigita kaj forigita de la dns. Se estas iu problemo kun grupo de ekvilibristoj, tiam ili estas sekurkopiitaj en aliaj retejoj, kaj ŝanĝi inter ili estas farita per la sama vojo53, ĉar pro la mallonga TTL, ŝanĝado okazas ene de maksimume 2, 3, 5 minutoj. .
Tria "sed": Kio ankoraŭ ne estas rezervita? S3, ĝusta. Kiam ni metis la dosierojn, kiujn ni stokas por uzantoj en s3, ni sincere kredis, ke ĝi estas kiras-penetra kaj ne necesas rezervi ion tie. Sed la historio montras, ke aferoj okazas alimaniere. Ĝenerale, Amazon priskribas S3 kiel fundamentan servon, ĉar Amazon mem uzas S3 por konservi maŝinajn bildojn, agordojn, AMI-bildojn, momentfotojn... Kaj se s3 kraŝas, kiel okazis unufoje dum ĉi tiuj 7 jaroj, dum ni uzis. bitrix24, ĝi sekvas ĝin kiel adoranto. Estas tuta aro da aferoj kiuj aperas - nekapablo komenci virtualajn maŝinojn, api-malsukceso, ktp.
Kaj S3 povas fali - ĝi okazis unufoje. Tial ni venis al la jena skemo: antaŭ kelkaj jaroj ne ekzistis seriozaj publikaj objektoj en Rusio, kaj ni pripensis la eblon fari ion propran... Feliĉe, ni ne komencis fari tion, ĉar ni volus. fosis en la kompetenteco, kiun ni ne havas, kaj verŝajne fuŝos. Nun Mail.ru havas s3-kongruan stokadon, Yandex havas ĝin, kaj kelkaj aliaj provizantoj havas ĝin. Ni finfine venis al la ideo, ke ni volas havi, unue, sekurkopion, kaj due, la kapablon labori kun lokaj kopioj. Por la rusa regiono specife, ni uzas la Mail.ru Hotbox-servon, kiu estas API kongrua kun s3. Ni ne bezonis gravajn modifojn al la kodo ene de la aplikaĵo, kaj ni faris la jenan mekanismon: en s3 estas ellasiloj, kiuj ekigas la kreadon/forigon de objektoj, Amazon havas servon nomatan Lambda - ĉi tio estas senservila lanĉo de kodo. tio estos efektivigita ĝuste kiam certaj ellasiloj estas ekigitaj.
Ni faris ĝin tre simple: se nia ellasilo ekfunkciigas, ni ekzekutas kodon, kiu kopios la objekton al la stokado de Mail.ru. Por plene lanĉi laboron kun lokaj kopioj de datumoj, ni ankaŭ bezonas inversan sinkronigon, por ke klientoj, kiuj estas en la rusa segmento, povu labori kun stokado pli proksima al ili. Poŝto estas kompletigonta ellasilon en sia stokado - eblos plenumi inversan sinkronigon ĉe la infrastruktura nivelo, sed nuntempe ni faras tion je la nivelo de nia propra kodo. Se ni vidas, ke kliento afiŝis dosieron, tiam ĉe la kodnivelo ni metas la eventon en atendovico, procesas ĝin kaj faras inversan reproduktadon. Kial ĝi estas malbona: se ni faras ian laboron kun niaj objektoj ekster nia produkto, tio estas, per iuj eksteraj rimedoj, ni ne konsideros ĝin. Sekve, ni atendas ĝis la fino, kiam ellasiloj aperas ĉe la stokadnivelo, tiel ke ne gravas de kie ni ekzekutas la kodon, la objekto, kiu venis al ni, estas kopiita en la alia direkto.
Je la kodnivelo, ni registras ambaŭ stokaĵojn por ĉiu kliento: unu estas konsiderata la ĉefa, la alia estas konsiderata rezerva. Se ĉio estas en ordo, ni laboras kun la stokado, kiu estas pli proksima al ni: tio estas, niaj klientoj, kiuj estas en Amazon, ili laboras kun S3, kaj tiuj, kiuj laboras en Rusio, ili laboras kun Hotbox. Se la flago estas ekigita, tiam malsukceso devus esti konektita, kaj ni ŝanĝas klientojn al alia stokado. Ni povas marki ĉi tiun skatolon sendepende laŭ regiono kaj povas ŝanĝi ilin tien kaj reen. Ni ankoraŭ ne uzis ĉi tion praktike, sed ni provizis ĉi tiun mekanismon kaj ni pensas, ke iam ni bezonos ĉi tiun ŝaltilon kaj utilos. Ĉi tio jam okazis unufoje.
Ho, kaj Amazon forkuris...
Ĉi tiu aprilo estas la datreveno de la komenco de Telegram-blokado en Rusio. La plej tuŝita provizanto, kiu falis sub ĉi tio, estas Amazon. Kaj, bedaŭrinde, rusaj kompanioj, kiuj laboris por la tuta mondo, suferis pli.
Se la kompanio estas tutmonda kaj Rusio estas tre malgranda segmento por ĝi, 3-5% - nu, iel aŭ alie, vi povas oferi ilin.
Se ĉi tio estas pure rusa kompanio - mi certas, ke ĝi devas esti loke loke - nu, ĝi simple estos oportuna por la uzantoj mem, komforta, kaj estos malpli da riskoj.
Kio se ĉi tio estas kompanio, kiu funkcias tutmonde kaj havas proksimume egalajn nombrojn da klientoj el Rusio kaj ie ĉirkaŭ la mondo? La konektebleco de la segmentoj estas grava, kaj ili devas funkcii unu kun la alia unumaniere aŭ alian.
Fine de marto 2018, Roskomnadzor sendis leteron al la plej grandaj telefonistoj, deklarante, ke ili planas bloki plurajn milionojn da Amazon IP-oj por bloki... la Zello-mesaĝon. Danke al ĉi tiuj samaj provizantoj - ili sukcese likis la leteron al ĉiuj, kaj estis kompreno, ke la ligo kun Amazono povus disiĝi. Estis vendredo, ni panike kuris al niaj kolegoj de servers.ru, dirante: "Amikoj, ni bezonas plurajn servilojn, kiuj troviĝos ne en Rusio, ne en Amazono, sed, ekzemple, ie en Amsterdamo", en ordo. al por povi almenaŭ iel instali nian propran VPN kaj prokurilon tie por iuj finpunktoj, kiujn ni neniel ne povas influi, ekzemple endpontojn de la sama s3 - ni ne povas provi altigi novan servon kaj akiri alian ip, ni vi ankoraŭ bezonas atingi tien. Post nur kelkaj tagoj, ni starigis ĉi tiujn servilojn, ekfunkciigis ilin kaj, ĝenerale, prepariĝis por la momento, kiam la blokado komenciĝis. Estas kurioze, ke RKN, rigardante la tumulton kaj panikon, diris: "Ne, ni nenion blokos nun." (Sed ĉi tio estas ĝuste ĝis la momento, kiam Telegramo komencis esti blokita.) Stariginte la pretervojajn kapablojn kaj konsciante, ke la blokado ne estis enkondukita, ni tamen ne komencis ordigi la tutan aferon. Jes, ĉiaokaze.
Kaj en 2019, ni ankoraŭ vivas en kondiĉoj de blokado. Mi rigardis hieraŭ nokte: ĉirkaŭ miliono da IP-oj daŭre estas blokitaj. Vere, Amazon estis preskaŭ tute malblokita, en sia pinto ĝi atingis 20 milionojn da adresoj... Ĝenerale, la realo estas, ke eble ne ekzistas kohereco, bona kohereco. Subite. Ĝi eble ne ekzistas pro teknikaj kialoj - fajroj, fosmaŝinoj, ĉio tio. Aŭ, kiel ni vidis, ne tute teknikaj. Tial iu granda kaj granda, kun siaj propraj AS-oj, verŝajne povas administri tion alimaniere - rekta konekto kaj aliaj aferoj jam estas sur la l2-nivelo. Sed en simpla versio, kiel la nia aŭ eĉ pli malgranda, vi povas, ĉiaokaze, havi redundon je la nivelo de serviloj levitaj ie aliloke, agordita anticipe vpn, prokurilo, kun la kapablo rapide ŝanĝi la agordon al ili en tiuj segmentoj. kiuj estas kritikaj por via konektebleco. Ĉi tio estis utila por ni pli ol unufoje, kiam la blokado de Amazon komenciĝis; en la plej malbona kazo, ni nur permesis S3-trafikon tra ili, sed iom post iom ĉio ĉi estis solvita.
Kiel rezervi... tutan provizanton?
Ĝuste nun ni ne havas scenaron, se la tuta Amazono falos. Ni havas similan scenaron por Rusio. En Rusio, ni estis gastigitaj de unu provizanto, de kiu ni elektis havi plurajn retejojn. Kaj antaŭ unu jaro ni alfrontis problemon: kvankam ĉi tiuj estas du datumcentroj, eble ekzistas problemoj jam ĉe la nivelo de la reto-agordo de la provizanto, kiuj ankoraŭ influos ambaŭ datumcentrojn. Kaj ni eble estos neatingeblaj en ambaŭ retejoj. Kompreneble tio okazis. Ni finis rekonsideri la arkitekturon ene. Ĝi ne multe ŝanĝiĝis, sed por Rusio ni nun havas du retejojn, kiuj ne estas de la sama provizanto, sed de du malsamaj. Se unu malsukcesas, ni povas ŝanĝi al la alia.
Hipoteze, por Amazon ni pripensas la eblecon de rezervo je la nivelo de alia provizanto; eble Guglo, eble iu alia... Sed ĝis nun ni observis praktike, ke dum Amazono havas akcidentojn je la nivelo de unu havebleca zono, akcidentoj je la nivelo de tuta regiono estas sufiĉe maloftaj. Tial ni teorie havas la ideon, ke ni povus fari rezervadon "Amazono ne estas Amazono", sed praktike tio ankoraŭ ne estas la kazo.
Kelkaj vortoj pri aŭtomatigo
Ĉu aŭtomatigo ĉiam necesas? Ĉi tie estas konvene rememori la Dunning-Kruger-efekton. Sur la "x" akso estas nia scio kaj sperto kiun ni akiras, kaj sur la "y" akso estas konfido je niaj agoj. Komence ni scias nenion kaj tute ne certas. Tiam ni scias iomete kaj fariĝas mega-megefidaj - ĉi tio estas la tiel nomata "pinto de stulteco", bone ilustrita de la bildo "demenco kaj kuraĝo". Tiam ni lernis iomete kaj estas pretaj iri en batalon. Tiam ni tretas kelkajn mega-gravajn erarojn kaj trovas nin en valo de malespero, kiam ni ŝajnas scii ion, sed fakte ni ne scias multon. Tiam, dum ni akiras sperton, ni iĝas pli memfidaj.
Nia logiko pri diversaj aŭtomataj ŝaltiloj al certaj akcidentoj estas tre bone priskribita de ĉi tiu grafikaĵo. Ni komencis - ni sciis fari ion ajn, preskaŭ la tuta laboro estis farita mane. Tiam ni rimarkis, ke ni povus alligi aŭtomatigon al ĉio kaj, kiel, dormi trankvile. Kaj subite ni paŝas sur mega-raketon: falsa pozitivo estas ekigita, kaj ni ŝanĝas trafikon tien kaj reen kiam, en bona maniero, ni ne devus fari ĉi tion. Sekve, reproduktado rompiĝas aŭ io alia - ĉi tio estas la valo mem de malespero. Kaj tiam ni ekkomprenas, ke ni devas saĝe aliri ĉion. Tio estas, ĝi havas sencon fidi aŭtomatigon, provizante la eblecon de falsaj alarmoj. Sed! se la sekvoj povas esti ruinigaj, tiam estas pli bone lasi ĝin al la deĵorŝanĝo, al la deĵorantaj inĝenieroj, kiuj zorgos kaj kontrolos, ke vere okazas akcidento, kaj plenumos la necesajn agojn permane...
konkludo
En la daŭro de 7 jaroj, ni iris de tio, ke kiam io falis, estis paniko-paniko, al la kompreno, ke problemoj ne ekzistas, ekzistas nur taskoj, ili devas - kaj povas - esti solvitaj. Kiam vi konstruas servon, rigardu ĝin de supre, taksu ĉiujn riskojn, kiuj povas okazi. Se vi tuj vidas ilin, tiam antaŭzorgu redundon kaj la eblecon konstrui misfunkcian infrastrukturon, ĉar iu ajn punkto, kiu povas malsukcesi kaj konduki al la nefunkciebleco de la servo, certe faros tion. Kaj eĉ se ŝajnas al vi, ke iuj elementoj de la infrastrukturo certe ne malsukcesos - kiel la sama s3, tamen memoru, ke ili povas. Kaj almenaŭ teorie, havu ideon pri tio, kion vi faros kun ili, se io okazos. Havu planon pri administrado de risko. Kiam vi pensas fari ĉion aŭtomate aŭ permane, taksu la riskojn: kio okazos se la aŭtomatigo komencos ŝanĝi ĉion - ĉu tio ne kondukos al eĉ pli malbona situacio kompare kun akcidento? Eble ie necesas uzi akcepteblan kompromison inter la uzo de aŭtomatigo kaj la reago de la deĵoranta inĝeniero, kiu taksos la realan bildon kaj komprenos ĉu io devas esti ŝanĝita surloke aŭ "jes, sed ne nun."
Akceptebla kompromiso inter perfektismo kaj vera penado, tempo, mono, kiun vi povas elspezi por la skemo, kiun vi poste havos.
Ĉi tiu teksto estas ĝisdatigita kaj pligrandigita versio de la raporto de Alexander Demidov ĉe la konferenco .
fonto: www.habr.com