Í dag er Bitrix24 þjónustan ekki með hundruð gígabita umferðar, né hefur hún risastóran flota af netþjónum (þó að það séu auðvitað nokkrir til). En fyrir marga viðskiptavini er það helsta tólið til að vinna í fyrirtækinu; það er raunverulegt viðskipta mikilvægt forrit. Þess vegna er engin leið að falla. Hvað ef hrunið gerðist, en þjónustan „batnaði“ svo fljótt að enginn tók eftir neinu? Og hvernig er hægt að innleiða failover án þess að tapa gæðum vinnunnar og fjölda viðskiptavina? Alexander Demidov, forstöðumaður skýjaþjónustu hjá Bitrix24, talaði fyrir bloggið okkar um hvernig bókunarkerfið hefur þróast á 7 árum vörunnar.
„Við settum Bitrix24 á markað sem SaaS fyrir 7 árum. Helsti erfiðleikinn var líklega eftirfarandi: áður en hún var sett opinberlega á markað sem SaaS var þessi vara einfaldlega til í formi kassalausnar. Viðskiptavinir keyptu það af okkur, hýstu það á netþjónum sínum, settu upp fyrirtækjagátt - almenn lausn fyrir samskipti starfsmanna, skráageymslu, verkefnastjórnun, CRM, það er allt. Og árið 2012 ákváðum við að við vildum setja það á markað sem SaaS, stjórna því sjálf, tryggja bilanaþol og áreiðanleika. Við öðluðumst reynslu á leiðinni, því þangað til höfðum við hana einfaldlega ekki - við vorum bara hugbúnaðarframleiðendur, ekki þjónustuaðilar.
Við opnun þjónustunnar áttum við okkur á að mikilvægast er að tryggja bilanaþol, áreiðanleika og stöðugt aðgengi að þjónustunni, því ef þú ert með einfalda venjulega vefsíðu, verslun, til dæmis, og hún fellur á þig og situr þar fyrir klukkutíma, aðeins þú þjáist, þú tapar pöntunum, þú missir viðskiptavini, en fyrir viðskiptavininn þinn sjálfan er þetta ekki mjög mikilvægt fyrir hann. Hann var auðvitað reiður, en hann fór og keypti það á annarri síðu. Og ef þetta er forrit þar sem öll vinna innan fyrirtækisins, samskipti, ákvarðanir eru bundin, þá er mikilvægast að öðlast traust notenda, það er að láta þá ekki falla og falla ekki. Vegna þess að öll vinna getur stöðvast ef eitthvað inni virkar ekki.
Bitrix.24 sem SaaS
Við settum saman fyrstu frumgerðina ári fyrir opinbera kynningu, árið 2011. Við settum það saman á um það bil viku, skoðuðum það, snúðum því - það virkaði meira að segja. Það er að segja að þú gætir farið inn í eyðublaðið, slegið inn nafn gáttarinnar þar, ný gátt myndi opnast og notendagrunnur myndast. Við skoðuðum hana, mátum vöruna í grundvallaratriðum, skrappum hana og héldum áfram að betrumbæta hana í heilt ár. Vegna þess að við höfðum stórt verkefni: við vildum ekki búa til tvo mismunandi kóðagrunna, við vildum ekki styðja aðskilda pakkavöru, aðskildar skýjalausnir - við vildum gera þetta allt í einum kóða.
Dæmigert vefforrit á þeim tíma var einn netþjónn sem keyrir PHP kóða á, mysql gagnagrunnur, skrám er hlaðið upp, skjölum, myndir settar í upphleðslumöppuna - jæja, þetta virkar allt. Því miður, það er ómögulegt að setja af stað mjög stöðuga vefþjónustu með því að nota þetta. Þar er dreift skyndiminni ekki stutt, afritun gagnagrunns er ekki studd.
Við mótuðum kröfurnar: þetta er hæfileikinn til að vera staðsettur á mismunandi stöðum, styðja afritun og helst vera staðsett í mismunandi landfræðilega dreifðum gagnaverum. Aðskilja vörurökfræði og í raun gagnageymslu. Vertu fær um að skala á kraftmikinn hátt í samræmi við álagið og þola truflanir að öllu leyti. Út frá þessum hugleiðingum komu í raun og veru kröfurnar til vörunnar sem við betrumbætum á árinu. Á þessum tíma, á vettvangnum, sem reyndist vera sameinað - fyrir kassalausnir, fyrir okkar eigin þjónustu - gerðum við stuðning fyrir þá hluti sem við þurftum. Stuðningur við mysql afritun á stigi vörunnar sjálfrar: það er að verktaki sem skrifar kóðann hugsar ekki um hvernig beiðnum hans verður dreift, hann notar API okkar og við vitum hvernig á að dreifa skrif- og lesbeiðnum rétt á milli meistara. og þrælar.
Við höfum gert stuðning á vörustigi fyrir ýmsar skýjahlutageymslur: Google geymslu, Amazon s3, auk stuðning fyrir opna stafla Swift. Þess vegna var þetta þægilegt bæði fyrir okkur sem þjónustu og fyrir þróunaraðila sem vinna með pakkalausn: ef þeir nota bara API okkar í vinnunni, hugsa þeir ekki um hvar skráin verður á endanum vistuð, staðbundið í skráarkerfinu eða í hlut skráargeymslunni.
Þar af leiðandi ákváðum við strax að við myndum panta á vettvangi alls gagnaversins. Árið 2012 fórum við alfarið af stað á Amazon AWS vegna þess að við höfðum þegar reynslu af þessum vettvangi - okkar eigin vefsíða var hýst þar. Okkur laðaðist að því að á hverju svæði hefur Amazon nokkur framboðssvæði - í raun (í hugtökum þeirra) nokkur gagnaver sem eru meira og minna óháð hvort öðru og gera okkur kleift að panta á stigi heils gagnavera: ef það mistekst skyndilega, eru gagnagrunnarnir endurteknir master-master, vefforritaþjónarnir eru afritaðir og kyrrstæðu gögnin eru færð í s3 hlutgeymsluna. Álagið er jafnvægi - á þeim tíma af Amazon elb, en litlu síðar komum við að okkar eigin álagsjafnara, vegna þess að við þurftum flóknari rökfræði.
Það sem þeir vildu er það sem þeir fengu...
Allt grunnatriði sem við vildum tryggja - bilanaþol á netþjónunum sjálfum, vefforritum, gagnagrunnum - allt virkaði vel. Einfaldasta atburðarásin: ef eitt af vefforritum okkar bilar, þá er allt einfalt - slökkt er á þeim frá jafnvægi.
Jafnvægisbúnaðurinn (á þeim tíma var það alb frá Amazon) merkti vélar sem voru bilaðar sem óhollar og slökkti á álagsdreifingu á þeim. Amazon sjálfstærð virkaði: þegar álagið stækkaði bættust nýjar vélar í sjálfvirka stærðarhópinn, álaginu var dreift á nýjar vélar - allt var í lagi. Með jafnvægistækjum okkar er rökfræðin nokkurn veginn sú sama: ef eitthvað kemur fyrir forritaþjóninn fjarlægjum við beiðnir frá honum, hentum þessum vélum út, byrjum nýjar og höldum áfram að vinna. Kerfið hefur breyst aðeins í gegnum árin, en heldur áfram að virka: það er einfalt, skiljanlegt og það eru engir erfiðleikar við það.
Við vinnum um allan heim, álagstoppar viðskiptavina eru allt öðruvísi og á vinsamlegan hátt ættum við að geta framkvæmt ákveðna þjónustuvinnu á hvaða íhluti sem er í kerfi okkar hvenær sem er - án þess að viðskiptavinir sjái það. Þess vegna höfum við tækifæri til að slökkva á notkun gagnagrunnsins og dreifa álaginu aftur í annað gagnaver.
Hvernig virkar þetta allt saman? — Við skiptum um umferð yfir í starfandi gagnaver - ef slys verður í gagnaverinu, þá algjörlega, ef þetta er fyrirhuguð vinna okkar með einn gagnagrunn, þá skiptum við hluta af umferðinni sem þjónar þessum viðskiptavinum yfir í annað gagnaver og stöðvum það afritun. Ef þörf er á nýjum vélum fyrir vefforrit vegna þess að álag á seinni gagnaverið hefur aukist fara þær sjálfkrafa í gang. Við ljúkum verkinu, afritun er endurreist og við skilum öllu álaginu til baka. Ef við þurfum að spegla einhverja vinnu í seinni DC, til dæmis, setja upp kerfisuppfærslur eða breyta stillingum í seinni gagnagrunninum, þá endurtökum við almennt það sama, bara í hina áttina. Og ef þetta er slys, þá gerum við allt léttvægt: við notum atburðastjórnunarkerfið í eftirlitskerfinu. Ef nokkrar athuganir eru settar af stað og staðan verður mikilvæg, þá keyrum við þennan meðhöndlun, meðhöndlun sem getur framkvæmt þessa eða hina rökfræði. Fyrir hvern gagnagrunn tilgreinum við hvaða þjónn er bilunarviðskipti fyrir hann og hvar þarf að skipta um umferð ef hann er ekki tiltækur. Sögulega notum við nagios eða nokkra gaffla þess í einni eða annarri mynd. Í grundvallaratriðum eru svipaðar aðferðir til í næstum hvaða vöktunarkerfi sem er; við notum ekkert flóknara ennþá, en kannski munum við einhvern tíma gera það. Nú er vöktun kveikt af óaðgengi og hefur getu til að skipta um eitthvað.
Höfum við frátekið allt?
Við höfum marga viðskiptavini frá Bandaríkjunum, marga viðskiptavini frá Evrópu, marga viðskiptavini sem eru nær Austurlöndum - Japan, Singapúr og svo framvegis. Auðvitað er stór hluti viðskiptavina í Rússlandi. Það er, vinnan er ekki á einu svæði. Notendur vilja skjót viðbrögð, það eru kröfur um að fara að ýmsum staðbundnum lögum, og innan hvers svæðis áskiljum við okkur tvö gagnaver, auk þess er nokkur viðbótarþjónusta, sem aftur er þægilegt að setja innan eins svæðis - fyrir viðskiptavini sem eru í þetta svæði er að vinna. REST meðhöndlarar, leyfisþjónar, þeir eru minna mikilvægir fyrir rekstur viðskiptavinarins í heild sinni, þú getur skipt í gegnum þá með lítilli ásættanlegri töf, en þú vilt ekki finna upp hjólið á ný hvernig á að fylgjast með þeim og hvað á að gera með þeim. Þess vegna erum við að reyna að nota núverandi lausnir sem mest, frekar en að þróa einhvers konar hæfni í viðbótarvörum. Og einhvers staðar notum við léttvægt að skipta á DNS stigi, og við ákveðum lífleika þjónustunnar með sama DNS. Amazon er með Route 53 þjónustu, en það er ekki bara DNS sem þú getur fært inn í og það er það - það er miklu sveigjanlegra og þægilegra. Í gegnum það geturðu byggt upp landfræðilega dreifða þjónustu með landfræðilegum staðsetningum, þegar þú notar það til að ákvarða hvaðan viðskiptavinurinn kom og gefur honum ákveðnar skrár - með hjálp þess geturðu smíðað failover arkitektúr. Sömu heilbrigðisskoðanir eru stilltar á leið 53 sjálfri, þú stillir endapunkta sem eru fylgst með, stillir mælikvarða, stillir hvaða samskiptareglur til að ákvarða „lífleika“ þjónustunnar - tcp, http, https; stilla tíðni athugana sem ákvarðar hvort þjónustan sé á lífi eða ekki. Og í DNS sjálfu tilgreinirðu hvað verður aðal, hvað verður aukaatriði, hvar á að skipta ef heilsufarsskoðunin fer af stað inni á leið 53. Allt þetta er hægt að gera með einhverjum öðrum tækjum, en hvers vegna er það þægilegt - við stillum það upp einu sinni og hugsa svo ekki um það hvernig við gerum athuganir, hvernig við skiptum: allt virkar af sjálfu sér.
Fyrsta "en": hvernig og með hverju á að panta leið 53 sjálfa? Hver veit, hvað ef eitthvað kemur fyrir hann? Sem betur fer stigum við aldrei á þessa hrífu, en aftur mun ég hafa sögu á undan af hverju við héldum að við þyrftum enn að panta. Hér lögðum við út strá fyrir okkur fyrirfram. Nokkrum sinnum á dag tökum við algjörlega af öllum þeim svæðum sem við höfum á leið 53. API Amazon gerir þér kleift að senda þau auðveldlega í JSON og við erum með nokkra öryggisafritunarþjóna þar sem við umbreytum því, höldum því upp í formi stillinga og höfum, í grófum dráttum, öryggisafritunarstillingar. Ef eitthvað gerist getum við fljótt dreift því handvirkt án þess að tapa DNS stillingagögnunum.
Annað "en": Hvað á þessari mynd hefur ekki enn verið frátekið? Jafnvægið sjálft! Dreifing viðskiptavina okkar eftir svæðum er gerð mjög einföld. Við erum með lénin bitrix24.ru, bitrix24.com, .de - nú eru 13 mismunandi, sem starfa á ýmsum svæðum. Við komumst að eftirfarandi: hvert svæði hefur sína eigin jafnvægismenn. Þetta gerir það þægilegra að dreifa á milli svæða, eftir því hvar hámarksálagið á netið er. Ef þetta er bilun á stigi eins jafnvægis, þá er það einfaldlega tekið úr notkun og fjarlægt úr dns. Ef það er einhver vandamál með hóp jafnvægisaðila, þá er afritað af þeim á öðrum síðum og skipt er á milli þeirra með sömu leið53, vegna þess að vegna stutts TTL verður skipt innan hámarks 2, 3, 5 mínútna .
Þriðja "en": Hvað er ekki enn frátekið? S3, rétt. Þegar við settum skrárnar sem við geymum fyrir notendur í s3 trúðum við því í einlægni að þetta væri brynjagat og það væri engin þörf á að panta neitt þar. En sagan sýnir að hlutirnir gerast öðruvísi. Almennt séð lýsir Amazon S3 sem grundvallarþjónustu, því Amazon sjálft notar S3 til að geyma vélamyndir, stillingar, AMI myndir, skyndimyndir... Og ef s3 hrynur, eins og gerðist einu sinni á þessum 7 árum, svo lengi sem við höfum notað bitrix24, það fylgir því eins og aðdáandi. Það er fullt af hlutum sem koma upp - vanhæfni til að ræsa sýndarvélar, api bilun og svo framvegis.
Og S3 getur fallið - það gerðist einu sinni. Þess vegna komumst við að eftirfarandi fyrirkomulagi: Fyrir nokkrum árum voru engar alvarlegar geymslur fyrir opinbera hluti í Rússlandi og við skoðuðum þann kost að gera eitthvað af okkar eigin... Sem betur fer byrjuðum við ekki að gera þetta, því við myndum hafa grafið í sér þá sérfræðiþekkingu sem við höfum ekki, og myndi líklega klúðra. Nú er Mail.ru með s3-samhæfða geymslu, Yandex hefur það og fjöldi annarra veitenda hefur það. Við komumst að lokum að þeirri hugmynd að við vildum hafa í fyrsta lagi öryggisafrit og í öðru lagi getu til að vinna með staðbundin eintök. Fyrir rússneska svæðið sérstaklega, notum við Mail.ru Hotbox þjónustuna, sem er API samhæft við s3. Við þurftum engar meiriháttar breytingar á kóðanum inni í forritinu og við gerðum eftirfarandi kerfi: í s3 eru kveikjur sem koma af stað stofnun/eyðingu hluta, Amazon er með þjónustu sem heitir Lambda - þetta er netþjónslaus keyrsla á kóða sem verður keyrt þegar ákveðnar kveikjur eru ræstar.
Við gerðum það mjög einfaldlega: ef kveikja okkar kviknar, keyrum við kóða sem mun afrita hlutinn í Mail.ru geymsluna. Til að hefja vinnu að fullu með staðbundin afrit af gögnum þurfum við einnig öfuga samstillingu svo að viðskiptavinir sem eru í rússneska hlutanum geti unnið með geymslu sem er nær þeim. Póstur er að fara að klára kveikjur í geymslunni sinni - það verður hægt að framkvæma öfuga samstillingu á innviðastigi, en í bili gerum við þetta á stigi okkar eigin kóða. Ef við sjáum að viðskiptavinur hefur sent inn skrá, þá setjum við atburðinn í biðröð á kóðastigi, vinnum hann og gerum öfuga afritun. Af hverju það er slæmt: ef við vinnum einhvers konar vinnu með hlutina okkar utan vörunnar okkar, það er að segja með einhverjum ytri hætti, munum við ekki taka tillit til þess. Þess vegna bíðum við til loka, þegar kveikjur birtast á geymslustigi, þannig að það er sama hvaðan við keyrum kóðann, hluturinn sem kom til okkar er afritaður í hina áttina.
Á kóðastigi skráum við báðar geymslurnar fyrir hvern viðskiptavin: önnur er talin aðal, hin er talin vara vara. Ef allt er í lagi vinnum við með geymsluna sem er nær okkur: það er að segja viðskiptavinir okkar sem eru í Amazon, þeir vinna með S3 og þeir sem vinna í Rússlandi vinna með Hotbox. Ef fáninn er ræstur, þá ætti failover að vera tengdur og við skiptum viðskiptavinum yfir í aðra geymslu. Við getum hakað við þennan reit sjálfstætt eftir svæðum og getum skipt þeim fram og til baka. Við höfum ekki notað þetta í reynd ennþá, en við höfum séð fyrir þessu fyrirkomulagi og við teljum að einhvern tíma munum við þurfa á þessu að halda og koma okkur að góðum notum. Þetta hefur þegar gerst einu sinni.
Ó, og Amazon hljóp í burtu...
Nú í apríl er afmælisárið frá því að lokun Telegram hófst í Rússlandi. Þjónustuveitan sem hefur mest áhrif á þetta er Amazon. Og því miður þjáðust rússnesk fyrirtæki sem unnu fyrir allan heiminn meira.
Ef fyrirtækið er alþjóðlegt og Rússland er mjög lítill hluti fyrir það, 3-5% - jæja, með einum eða öðrum hætti geturðu fórnað þeim.
Ef þetta er eingöngu rússneskt fyrirtæki - ég er viss um að það þarf að vera staðsett á staðnum - jæja, það mun einfaldlega vera þægilegt fyrir notendurna sjálfa, þægilegt og það verður minni áhætta.
Hvað ef þetta er fyrirtæki sem starfar á heimsvísu og hefur um það bil jafn marga viðskiptavini frá Rússlandi og einhvers staðar um allan heim? Tenging hlutanna er mikilvæg og þeir verða að vinna saman á einn eða annan hátt.
Í lok mars 2018 sendi Roskomnadzor bréf til stærstu rekstraraðilanna þar sem fram kom að þeir hygðust loka á nokkrar milljónir Amazon IP til að loka fyrir... Zello sendiboðann. Þökk sé þessum sömu veitendum - þeim tókst að leka bréfinu til allra og það var skilningur á því að tengingin við Amazon gæti slitnað. Það var föstudagur, við hlupum í læti til samstarfsmanna okkar frá servers.ru, með orðunum: "Vinir, við þurfum nokkra netþjóna sem verða ekki staðsettir í Rússlandi, ekki á Amazon, heldur, til dæmis, einhvers staðar í Amsterdam," til þess að geta að minnsta kosti einhvern veginn sett upp okkar eigin VPN og proxy þarna fyrir suma endapunkta sem við getum ekki haft áhrif á á nokkurn hátt, til dæmis endapunkta á sama s3 - við getum ekki reynt að hækka nýja þjónustu og fá aðra ip, við þú þarft samt að komast þangað. Á örfáum dögum settum við þessa netþjóna upp, komum þeim í gang og undirbúum okkur almennt fyrir augnablikið sem lokunin hófst. Það er forvitnilegt að RKN, sem horfði á lætin og lætin, sagði: „Nei, við munum ekki loka á neitt núna. (En þetta er einmitt þangað til þegar byrjað var að loka á Telegram.) Eftir að hafa sett upp hliðarbrautargetuna og áttað okkur á því að lokunin hafði ekki verið kynnt, byrjuðum við hins vegar ekki að redda öllu málinu. Já, bara svona.
Og árið 2019 búum við enn við lokunarskilyrði. Ég skoðaði í gærkvöldi: um milljón IP-tölur halda áfram að vera læst. Að vísu var Amazon nánast alveg opnað, þegar mest var náði það 20 milljón heimilisföngum... Almennt séð er raunveruleikinn sá að það er kannski ekki samræmi, gott samræmi. Skyndilega. Það er kannski ekki til af tæknilegum ástæðum - eldsvoða, gröfur, allt það. Eða, eins og við höfum séð, ekki alveg tæknilega. Þess vegna getur einhver stór og stór, með eigin AS, líklega stjórnað þessu á annan hátt - bein tenging og annað er nú þegar á l2 stigi. En í einfaldri útgáfu, eins og okkar eða jafnvel minni, geturðu, fyrir tilfelli, haft offramboð á stigi netþjóna sem eru hækkaðir einhvers staðar annars staðar, stillt fyrirfram vpn, proxy, með getu til að breyta stillingunum fljótt yfir á þá í þessum hlutum sem eru mikilvæg fyrir tenginguna þína. Þetta kom okkur að góðum notum oftar en einu sinni þegar lokun Amazon hófst; í versta falli leyfðum við aðeins S3 umferð í gegnum þá, en smám saman leystist þetta allt.
Hvernig á að panta... heilan þjónustuaðila?
Núna höfum við enga atburðarás ef allt Amazon fer niður. Við höfum svipaða atburðarás fyrir Rússland. Í Rússlandi vorum við hýst hjá einum þjónustuaðila, sem við völdum að hafa nokkrar síður frá. Og fyrir ári síðan stóðum við frammi fyrir vandamáli: jafnvel þó að þetta séu tvær gagnaver, gætu verið vandamál þegar uppi á stigi netuppsetningar þjónustuveitunnar sem mun samt hafa áhrif á báðar gagnaverin. Og við gætum endað ófáanleg á báðum síðum. Auðvitað gerðist það. Við enduðum á því að endurskoða arkitektúrinn inni. Það hefur ekki breyst mjög mikið, en fyrir Rússland höfum við nú tvær síður, sem eru ekki frá sömu þjónustuveitunni, heldur frá tveimur mismunandi. Ef annað mistekst getum við skipt yfir í hitt.
Tilgáta, fyrir Amazon erum við að íhuga möguleikann á bókun á vettvangi annars þjónustuaðila; kannski Google, kannski einhver annar... En hingað til höfum við fylgst með því í reynd að á meðan Amazon hefur slys á stigi eins tiltæks svæðis eru slys á stigi heils svæðis frekar sjaldgæf. Þess vegna höfum við fræðilega hugmynd um að við gætum gert „Amazon er ekki Amazon“ fyrirvara, en í reynd er þetta ekki enn raunin.
Nokkur orð um sjálfvirkni
Er sjálfvirkni alltaf nauðsynleg? Hér er rétt að rifja upp Dunning-Kruger áhrifin. Á „x“ ásnum er þekking okkar og reynsla sem við öðlumst og á „y“ ásnum er traust á gjörðum okkar. Í fyrstu vitum við ekkert og erum alls ekki viss. Þá vitum við svolítið og verðum mega sjálfsörugg - þetta er svokallaður „toppur heimsku“, vel sýndur af myndinni „vitglöp og hugrekki“. Þá erum við búin að læra smá og erum tilbúin í slaginn. Svo stígum við á nokkur stóralvarleg mistök og lendum í dal örvæntingar, þegar við virðumst vita eitthvað, en í rauninni vitum við ekki mikið. Síðan, eftir því sem við öðlumst reynslu, verðum við öruggari.
Rökfræði okkar um ýmsa sjálfvirka skiptingu á ákveðin slys er mjög vel lýst í þessu grafi. Við byrjuðum - við vissum ekki hvernig á að gera neitt, nánast öll vinnan var unnin í höndunum. Svo komumst við að því að við gætum tengt sjálfvirkni við allt og sofið rólega. Og skyndilega stígum við á stórhrífu: rangt jákvætt kemur af stað og við skiptum um umferð fram og til baka þegar, á góðan hátt, við hefðum ekki átt að gera þetta. Afleiðingin bilar þar af leiðandi eða eitthvað annað - þetta er einmitt dalur örvæntingar. Og þá komumst við að þeim skilningi að við verðum að nálgast allt skynsamlega. Það er, það er skynsamlegt að treysta á sjálfvirkni, sem kveður á um möguleika á falskum viðvörunum. En! ef afleiðingarnar geta verið hrikalegar, þá er betra að láta það eftir vaktvaktinni, verkfræðingunum á vakt, sem sjá um og fylgjast með því að raunverulega verði slys og framkvæma nauðsynlegar aðgerðir handvirkt...
Ályktun
Á 7 árum fórum við frá því að þegar eitthvað féll, þá urðu læti-læti, yfir í skilninginn á því að vandamál eru ekki til, það eru bara verkefni, þau verða - og má - leysa. Þegar þú ert að byggja upp þjónustu skaltu skoða hana ofan frá, meta alla áhættu sem getur gerst. Ef þú sérð þá strax, gerðu ráð fyrir offramboði fyrirfram og möguleika á að byggja upp bilunarþolið innviði, því allir punktar sem geta bilað og leitt til óvirkni þjónustunnar mun örugglega gera það. Og jafnvel þótt þér sýnist að sumir þættir innviðanna muni örugglega ekki mistakast - eins og sama s3, hafðu samt í huga að þeir geta það. Og að minnsta kosti í orði, hafið hugmynd um hvað þú munt gera við þá ef eitthvað gerist. Hafa áhættustjórnunaráætlun. Þegar þú ert að hugsa um að gera allt sjálfkrafa eða handvirkt skaltu meta áhættuna: hvað gerist ef sjálfvirknin byrjar að skipta um allt - mun þetta ekki leiða til enn verri ástands miðað við slys? Kannski er einhvers staðar nauðsynlegt að nota eðlilega málamiðlun milli notkunar sjálfvirkni og viðbragða vakthafandi verkfræðings, sem metur raunverulega mynd og skilur hvort eitthvað þurfi að skipta á staðnum eða „já, en ekki núna.“
Sanngjarn málamiðlun milli fullkomnunaráráttu og raunverulegrar fyrirhafnar, tíma, peninga sem þú getur eytt í kerfið sem þú munt að lokum hafa.
Þessi texti er uppfærð og aukin útgáfa af skýrslu Alexander Demidov á ráðstefnunni .
Heimild: www.habr.com