Sot, shërbimi Bitrix24 nuk ka qindra gigabit trafik, as nuk ka një flotë të madhe serverësh (megjithëse, natyrisht, ka mjaft ekzistues). Por për shumë klientë është mjeti kryesor për të punuar në kompani; është një aplikacion i vërtetë kritik për biznesin. Prandaj, nuk ka asnjë mënyrë për të rënë. Po sikur përplasja të ndodhte, por shërbimi "rikuperohej" aq shpejt sa askush nuk vuri re asgjë? Dhe si është e mundur të zbatohet failover pa humbur cilësinë e punës dhe numrin e klientëve? Alexander Demidov, drejtor i shërbimeve cloud në Bitrix24, foli për blogun tonë se si ka evoluar sistemi i rezervimit gjatë 7 viteve të ekzistencës së produktit.
“Ne lançuam Bitrix24 si SaaS 7 vjet më parë. Vështirësia kryesore ishte ndoshta e mëposhtme: përpara se të lansohej publikisht si SaaS, ky produkt ekzistonte thjesht në formatin e një zgjidhjeje në kuti. Klientët e blenë atë nga ne, e pritën në serverët e tyre, krijuan një portal të korporatës - një zgjidhje e përgjithshme për komunikimin e punonjësve, ruajtjen e skedarëve, menaxhimin e detyrave, CRM, kjo është e gjitha. Dhe deri në vitin 2012, ne vendosëm që donim ta lëshonim atë si SaaS, duke e administruar vetë, duke siguruar tolerancë dhe besueshmëri ndaj gabimeve. Ne fituam përvojë gjatë rrugës, sepse deri atëherë thjesht nuk e kishim atë - ne ishim vetëm prodhues softuerësh, jo ofrues shërbimesh.
Kur nisëm shërbimin, ne kuptuam se gjëja më e rëndësishme është të sigurohet toleranca ndaj gabimeve, besueshmëria dhe disponueshmëria e vazhdueshme e shërbimit, sepse nëse keni një faqe interneti të thjeshtë të zakonshme, një dyqan, për shembull, dhe ju bie dhe ulet atje për një orë, vetëm ju vuani, humbni porositë, humbni klientët, por për vetë klientin tuaj, kjo nuk është shumë kritike për të. Ai ishte i mërzitur, sigurisht, por ai shkoi dhe e bleu në një faqe tjetër. Dhe nëse ky është një aplikacion mbi të cilin lidhet e gjithë puna brenda kompanisë, komunikimet, vendimet, atëherë gjëja më e rëndësishme është të fitoni besimin e përdoruesve, domethënë të mos i lëshoni ata dhe të mos bien. Sepse e gjithë puna mund të ndalet nëse diçka brenda nuk funksionon.
Bitrix.24 si SaaS
Ne montuam prototipin e parë një vit përpara lançimit publik, në 2011. Ne e montuam atë për rreth një javë, e shikuam, e rrotulluam - madje funksiononte. Kjo do të thotë, mund të shkoni në formular, të shkruani emrin e portalit atje, do të hapej një portal i ri dhe do të krijohej një bazë përdoruesi. Ne e shikuam, vlerësuam produktin në parim, e hoqëm dhe vazhduam ta përpunonim për një vit të tërë. Sepse kishim një detyrë të madhe: nuk donim të krijonim dy baza të ndryshme kodesh, nuk donim të mbështesnim një produkt të veçantë të paketuar, zgjidhje të veçanta cloud - donim t'i bënim të gjitha brenda një kodi.
Një aplikacion tipik në internet në atë kohë ishte një server në të cilin funksionon disa kode PHP, një bazë të dhënash mysql, skedarët ngarkohen, dokumentet, fotografitë vendosen në dosjen e ngarkimit - mirë, gjithçka funksionon. Mjerisht, është e pamundur të nisësh një shërbim të qëndrueshëm në internet duke përdorur këtë. Atje, cache e shpërndarë nuk mbështetet, përsëritja e bazës së të dhënave nuk mbështetet.
Ne formuluam kërkesat: kjo është aftësia për t'u vendosur në vende të ndryshme, për të mbështetur riprodhimin dhe në mënyrë ideale për t'u vendosur në qendra të ndryshme të të dhënave të shpërndara gjeografikisht. Ndani logjikën e produktit dhe, në fakt, ruajtjen e të dhënave. Të jetë në gjendje të shkallëzojë në mënyrë dinamike sipas ngarkesës dhe të tolerojë statikën tërësisht. Nga këto konsiderata, në fakt dolën kërkesat për produktin, të cilat i rafinuam gjatë vitit. Gjatë kësaj kohe, në platformën, e cila rezultoi e unifikuar - për zgjidhjet në box, për shërbimin tonë - ne bëmë mbështetje për ato gjëra që na duheshin. Mbështetje për përsëritjen e mysql në nivelin e vetë produktit: d.m.th., zhvilluesi që shkruan kodin nuk mendon se si do të shpërndahen kërkesat e tij, ai përdor api-në tonë dhe ne dimë të shpërndajmë saktë kërkesat për shkrim dhe lexim midis zotërinjve dhe skllevër.
Ne kemi bërë mbështetje në nivelin e produktit për ruajtje të ndryshme të objekteve cloud: ruajtja e google, amazon s3, plus mbështetje për swift të hapur stack. Prandaj, kjo ishte e përshtatshme si për ne si shërbim ashtu edhe për zhvilluesit që punojnë me një zgjidhje të paketuar: nëse ata thjesht përdorin API-në tonë për punë, ata nuk mendojnë se ku do të ruhet skedari përfundimisht, lokalisht në sistemin e skedarëve ose në ruajtjen e skedarit të objektit.
Si rezultat, vendosëm menjëherë që të rezervonim në nivelin e të gjithë qendrës së të dhënave. Në vitin 2012, ne u lançuam tërësisht në Amazon AWS sepse tashmë kishim përvojë me këtë platformë - uebsajti ynë u strehua atje. Na tërhoqi fakti që në secilin rajon Amazon ka disa zona disponueshmërie - në fakt, (në terminologjinë e tyre) disa qendra të të dhënave që janë pak a shumë të pavarura nga njëra-tjetra dhe na lejojnë të rezervojmë në nivelin e një qendre të tërë të dhënash: nëse papritmas dështon, bazat e të dhënave riprodhohen master-master, serverët e aplikacionit në ueb kopjohen dhe të dhënat statike zhvendosen në ruajtjen e objektit s3. Ngarkesa është e balancuar - në atë kohë nga Amazon elb, por pak më vonë arritëm te balancuesit tanë të ngarkesës, sepse kishim nevojë për logjikë më komplekse.
Ajo që ata donin ishte ajo që morën ...
Të gjitha gjërat themelore që donim të siguronim - toleranca e gabimeve të vetë serverëve, aplikacionet në ueb, bazat e të dhënave - gjithçka funksionoi mirë. Skenari më i thjeshtë: nëse një nga aplikacionet tona në internet dështon, atëherë gjithçka është e thjeshtë - ato janë të fikur nga balancimi.
Balancuesi (në atë kohë ishte elb i Amazon) shënoi makinat që ishin jashtë funksionit si të pashëndetshme dhe çaktivizoi shpërndarjen e ngarkesës në to. Shkallëzimi automatik i Amazon funksionoi: kur ngarkesa u rrit, makina të reja u shtuan në grupin e shkallëzimit automatik, ngarkesa u shpërnda në makina të reja - gjithçka ishte në rregull. Me balancuesit tanë, logjika është përafërsisht e njëjtë: nëse diçka ndodh me serverin e aplikacionit, ne heqim kërkesat prej tij, i hedhim këto makina, nisim të reja dhe vazhdojmë të punojmë. Skema ka ndryshuar pak me kalimin e viteve, por vazhdon të funksionojë: është e thjeshtë, e kuptueshme dhe nuk ka vështirësi me të.
Ne punojmë në të gjithë botën, maja e ngarkesës së klientit është krejtësisht e ndryshme dhe, në mënyrë miqësore, ne duhet të jemi në gjendje të kryejmë punë të caktuara shërbimi në çdo komponent të sistemit tonë në çdo kohë - pa u vënë re nga klientët. Prandaj, ne kemi mundësinë të çaktivizojmë bazën e të dhënave nga funksionimi, duke rishpërndarë ngarkesën në një qendër të dytë të të dhënave.
Si funksionon e gjitha? — Ne e kalojmë trafikun në një qendër të dhënash pune - nëse ka një aksident në qendrën e të dhënave, atëherë plotësisht, nëse kjo është puna jonë e planifikuar me një bazë të dhënash, atëherë kalojmë një pjesë të trafikut që u shërben këtyre klientëve në një qendër të dytë të të dhënave, duke pezulluar ajo përsëritje. Nëse nevojiten makina të reja për aplikacionet në ueb sepse ngarkesa në qendrën e dytë të të dhënave është rritur, ato do të fillojnë automatikisht. Ne përfundojmë punën, riprodhimi është rikthyer dhe e kthejmë të gjithë ngarkesën. Nëse duhet të pasqyrojmë disa punë në DC-në e dytë, për shembull, të instalojmë përditësime të sistemit ose të ndryshojmë cilësimet në bazën e të dhënave të dytë, atëherë, në përgjithësi, ne përsërisim të njëjtën gjë, vetëm në drejtimin tjetër. Dhe nëse ky është një aksident, atëherë ne bëjmë gjithçka në mënyrë të parëndësishme: ne përdorim mekanizmin e mbajtësve të ngjarjeve në sistemin e monitorimit. Nëse aktivizohen disa kontrolle dhe statusi shkon në kritik, atëherë ne ekzekutojmë këtë mbajtës, një mbajtës që mund të ekzekutojë këtë apo atë logjikë. Për çdo bazë të dhënash, ne specifikojmë se cili server është failover për të dhe ku duhet të ndërrohet trafiku nëse nuk është i disponueshëm. Historikisht, ne përdorim nagios ose disa nga pirunët e tij në një formë ose në një tjetër. Në parim, mekanizma të ngjashëm ekzistojnë pothuajse në çdo sistem monitorimi; ne nuk përdorim ende asgjë më komplekse, por ndoshta një ditë do ta bëjmë. Tani monitorimi shkaktohet nga mosdisponueshmëria dhe ka aftësinë të ndërrojë diçka.
A kemi rezervuar gjithçka?
Ne kemi shumë klientë nga SHBA, shumë klientë nga Evropa, shumë klientë që janë më afër Lindjes - Japonia, Singapori etj. Sigurisht, një pjesë e madhe e klientëve janë në Rusi. Kjo do të thotë, puna nuk është në një rajon. Përdoruesit duan një përgjigje të shpejtë, ka kërkesa për të respektuar ligje të ndryshme lokale, dhe brenda secilit rajon ne rezervojmë dy qendra të dhënash, plus ka disa shërbime shtesë, të cilat, përsëri, janë të përshtatshme për t'u vendosur brenda një rajoni - për klientët që janë në ky rajon është duke punuar. Trajtuesit REST, serverët e autorizimit, ata janë më pak kritikë për funksionimin e klientit në tërësi, ju mund të kaloni përmes tyre me një vonesë të vogël të pranueshme, por nuk dëshironi të rishpikni timonin se si t'i monitoroni dhe çfarë të bëni me ta. Prandaj, ne po përpiqemi të përdorim në maksimum zgjidhjet ekzistuese, në vend që të zhvillojmë një lloj kompetence në produkte shtesë. Dhe diku ne përdorim trivialisht ndërrimin në nivelin DNS dhe përcaktojmë gjallërinë e shërbimit nga i njëjti DNS. Amazon ka një shërbim Route 53, por nuk është thjesht një DNS në të cilin mund të bëni hyrje dhe kaq – është shumë më fleksibël dhe më i përshtatshëm. Nëpërmjet tij mund të ndërtoni shërbime gjeo-shpërndarë me gjeolokacione, kur e përdorni për të përcaktuar se nga ka ardhur klienti dhe t'i jepni atij regjistrime të caktuara - me ndihmën e tij mund të ndërtoni arkitektura failover. Të njëjtat kontrolle shëndetësore janë konfiguruar në vetë Route 53, ju vendosni pikat përfundimtare që monitorohen, vendosni metrikë, vendosni cilat protokolle për të përcaktuar "gjallërinë" e shërbimit - tcp, http, https; caktoni frekuencën e kontrolleve që përcaktojnë nëse shërbimi është i gjallë apo jo. Dhe në vetë DNS ju specifikoni se çfarë do të jetë parësore, çfarë do të jetë dytësore, ku të kaloni nëse kontrolli shëndetësor aktivizohet brenda rrugës 53. E gjithë kjo mund të bëhet me disa mjete të tjera, por pse është e përshtatshme - e vendosim ne njëherë dhe më pas mos mendo fare se si bëjmë kontrollet, si kalojmë: çdo gjë funksionon më vete.
E para "por": si dhe me çfarë të rezervoni vetë rrugën 53? Kush e di, po sikur t'i ndodhë diçka? Për fat të mirë, ne nuk kemi shkelur kurrë në këtë grabujë, por përsëri, do të kem një histori përpara se pse menduam se duhej të bënim ende një rezervim. Këtu kemi shtruar kashtë për veten tonë paraprakisht. Disa herë në ditë bëjmë një shkarkim të plotë të të gjitha zonave që kemi në itinerarin 53. API i Amazon ju lejon t'i dërgoni ato lehtësisht në JSON dhe ne kemi disa serverë rezervë ku e konvertojmë, e ngarkojmë në formën e konfigurimeve dhe kemi, përafërsisht, një konfigurim rezervë. Nëse ndodh diçka, ne mund ta vendosim shpejt atë manualisht pa humbur të dhënat e cilësimeve të DNS.
E dyta "por": Çfarë nuk është rezervuar ende në këtë foto? Vetë balancuesi! Shpërndarja jonë e klientëve sipas rajonit është bërë shumë e thjeshtë. Ne kemi domenet bitrix24.ru, bitrix24.com, .de - tani ka 13 të ndryshme, të cilat funksionojnë në zona të ndryshme. Arritëm në sa vijon: çdo rajon ka balancuesit e vet. Kjo e bën më të përshtatshëm shpërndarjen nëpër rajone, në varësi të vendit ku është ngarkesa e pikut në rrjet. Nëse ky është një dështim në nivelin e një balancuesi të vetëm, atëherë ai thjesht hiqet nga shërbimi dhe hiqet nga dns. Nëse ka ndonjë problem me një grup balancuesish, atëherë ato rezervohen në faqe të tjera dhe kalimi ndërmjet tyre bëhet duke përdorur të njëjtën rrugë53, sepse për shkak të TTL-së së shkurtër, ndërrimi ndodh brenda maksimumit 2, 3, 5 minutash. .
E treta "por": Çfarë nuk është ende e rezervuar? S3, saktë. Kur vendosëm skedarët që ruajmë për përdoruesit në s3, sinqerisht besuam se ishte depërtues dhe nuk kishte nevojë të rezervonim asgjë atje. Por historia tregon se gjërat ndodhin ndryshe. Në përgjithësi, Amazon e përshkruan S3 si një shërbim themelor, sepse vetë Amazon përdor S3 për të ruajtur imazhet e makinerive, konfigurimet, imazhet AMI, fotografitë... Dhe nëse s3 rrëzohet, siç ka ndodhur një herë gjatë këtyre 7 viteve, për aq kohë sa kemi përdorur. bitrix24, e ndjek si një tifoz. Ka një mori gjërash që dalin - pamundësia për të nisur makinat virtuale, dështimi i api, etj.
Dhe S3 mund të bjerë - ndodhi një herë. Prandaj, arritëm në skemën e mëposhtme: disa vite më parë nuk kishte objekte serioze të ruajtjes së objekteve publike në Rusi dhe ne shqyrtuam opsionin për të bërë diçka tonën... Për fat, ne nuk filluam ta bënim këtë, sepse do të kemi gërmuar në ekspertizën që nuk e kemi, dhe ndoshta do të ngatërronim. Tani Mail.ru ka ruajtje të pajtueshme me s3, Yandex e ka atë dhe një numër ofruesish të tjerë e kanë atë. Më në fund erdhëm në idenë se donim të kishim, së pari, kopje rezervë, dhe së dyti, aftësinë për të punuar me kopje lokale. Në mënyrë specifike për rajonin rus, ne përdorim shërbimin Mail.ru Hotbox, i cili është API i pajtueshëm me s3. Ne nuk kishim nevojë për ndonjë modifikim të madh të kodit brenda aplikacionit dhe bëmë mekanizmin e mëposhtëm: në s3 ka aktivizues që nxisin krijimin/fshirjen e objekteve, Amazon ka një shërbim të quajtur Lambda - ky është një nisje kodi pa server që do të ekzekutohet pikërisht kur aktivizohen disa shkaktarë.
Ne e bëmë atë shumë thjesht: nëse shkrepja jonë ndizet, ne ekzekutojmë kodin që do të kopjojë objektin në ruajtjen e Mail.ru. Për të nisur plotësisht punën me kopjet lokale të të dhënave, ne kemi nevojë gjithashtu për sinkronizim të kundërt, në mënyrë që klientët që janë në segmentin rus të mund të punojnë me ruajtje që është më afër tyre. Mail është gati të plotësojë aktivizuesit në ruajtjen e saj - do të jetë e mundur të kryhet sinkronizimi i kundërt në nivelin e infrastrukturës, por tani për tani ne po e bëjmë këtë në nivelin e kodit tonë. Nëse shohim që një klient ka postuar një skedar, atëherë në nivelin e kodit e vendosim ngjarjen në një radhë, e përpunojmë dhe bëjmë replikim të kundërt. Pse është keq: nëse bëjmë një lloj pune me objektet tona jashtë produktit tonë, domethënë me ndonjë mjet të jashtëm, nuk do ta marrim parasysh. Prandaj, presim deri në fund, kur të shfaqen triggers në nivelin e ruajtjes, në mënyrë që pa marrë parasysh se nga e ekzekutojmë kodin, objekti që na erdhi të kopjohet në drejtimin tjetër.
Në nivelin e kodit, ne regjistrojmë të dy depozitat për secilin klient: njëra konsiderohet kryesore, tjetra konsiderohet rezervë. Nëse gjithçka është në rregull, ne punojmë me hapësirën ruajtëse që është më afër nesh: domethënë, klientët tanë që janë në Amazon, ata punojnë me S3, dhe ata që punojnë në Rusi, ata punojnë me Hotbox. Nëse flamuri aktivizohet, atëherë duhet të lidhet dështimi dhe ne i kalojmë klientët në një hapësirë tjetër ruajtëse. Ne mund ta kontrollojmë këtë kuti në mënyrë të pavarur sipas rajonit dhe mund t'i ndërrojmë ato përpara dhe mbrapa. Nuk e kemi përdorur ende këtë në praktikë, por e kemi parashikuar këtë mekanizëm dhe mendojmë se një ditë do të na duhet pikërisht ky ndërrim dhe do të na vijë në ndihmë. Kjo ka ndodhur tashmë një herë.
Oh, dhe Amazon iku ...
Ky prill shënon përvjetorin e fillimit të bllokimit të Telegramit në Rusi. Ofruesi më i prekur që ra nën këtë është Amazon. Dhe, për fat të keq, kompanitë ruse që punuan për të gjithë botën vuajtën më shumë.
Nëse kompania është globale dhe Rusia është një segment shumë i vogël për të, 3-5% - mirë, në një mënyrë ose në një tjetër, ju mund t'i sakrifikoni ato.
Nëse kjo është një kompani thjesht ruse - jam i sigurt se duhet të vendoset në vend - mirë, thjesht do të jetë i përshtatshëm për vetë përdoruesit, i rehatshëm dhe do të ketë më pak rreziqe.
Po nëse kjo është një kompani që operon globalisht dhe ka një numër afërsisht të barabartë klientësh nga Rusia dhe diku në mbarë botën? Lidhja e segmenteve është e rëndësishme dhe ato duhet të punojnë me njëri-tjetrin në një mënyrë ose në një tjetër.
Në fund të marsit 2018, Roskomnadzor u dërgoi një letër operatorëve më të mëdhenj ku thuhej se planifikonin të bllokonin disa milionë IP të Amazon për të bllokuar... mesazherin Zello. Falë këtyre ofruesve të njëjtë - ata zbuluan me sukses letrën për të gjithë dhe u kuptua se lidhja me Amazon mund të prishej. Ishte e premte, ne vrapuam në panik te kolegët tanë nga servers.ru, duke thënë: "Miq, na duhen disa serverë që do të vendosen jo në Rusi, jo në Amazon, por, për shembull, diku në Amsterdam", me qëllim. për të qenë në gjendje të paktën disi të instalojmë VPN-në tonë dhe proxy-in atje për disa pika fundore që ne nuk mund të ndikojmë në asnjë mënyrë, për shembull endpontet e të njëjtit s3 - nuk mund të përpiqemi të ngremë një shërbim të ri dhe të marrim një ip të ndryshëm, ju ende duhet të arrini atje. Në vetëm pak ditë, ne vendosëm këta serverë, i vumë në punë dhe, në përgjithësi, u përgatitëm për momentin që filloi bllokimi. Është kurioze që RKN, duke parë bujën dhe panikun, tha: "Jo, nuk do të bllokojmë asgjë tani". (Por kjo është pikërisht deri në momentin kur Telegrami filloi të bllokohej.) Pasi vendosëm aftësitë e bypass-it dhe kuptuam që bllokimi nuk ishte futur, ne, megjithatë, nuk filluam të zgjidhim të gjithë çështjen. Po, për çdo rast.
Dhe në vitin 2019 jetojmë ende në kushte bllokimi. Shikova mbrëmë: rreth një milion IP vazhdojnë të jenë të bllokuara. E vërtetë, Amazon u zhbllokua pothuajse plotësisht, në kulmin e saj arriti në 20 milionë adresa... Në përgjithësi, realiteti është se mund të mos ketë koherencë, koherencë të mirë. Papritur. Mund të mos ekzistojë për arsye teknike - zjarre, ekskavatorë, të gjitha këto. Ose, siç e kemi parë, jo tërësisht teknike. Prandaj, dikush i madh dhe i madh, me AS-të e tyre, ndoshta mund ta menaxhojë këtë në mënyra të tjera - lidhja direkte dhe gjërat e tjera janë tashmë në nivelin l2. Por në një version të thjeshtë, si ky i yni apo edhe më i vogël, mund të keni, për çdo rast, tepricë në nivelin e serverëve të ngritur diku tjetër, të konfiguruar paraprakisht vpn, proxy, me aftësinë për të kaluar shpejt konfigurimin tek ata në ato segmente që janë kritike për lidhjen tuaj. Kjo na erdhi në ndihmë më shumë se një herë, kur filloi bllokimi i Amazon; në skenarin më të keq, ne lejuam vetëm trafikun S3 përmes tyre, por gradualisht e gjithë kjo u zgjidh.
Si të rezervoni... një ofrues të tërë?
Për momentin, ne nuk kemi një skenar në rast se e gjithë Amazona bie. Ne kemi një skenar të ngjashëm për Rusinë. Në Rusi, na priti një ofrues, nga i cili zgjodhëm të kishim disa sajte. Dhe një vit më parë u përballëm me një problem: edhe pse këto janë dy qendra të të dhënave, mund të ketë probleme tashmë në nivelin e konfigurimit të rrjetit të ofruesit që do të prekë ende të dyja qendrat e të dhënave. Dhe mund të përfundojmë të padisponueshëm në të dy faqet. Sigurisht që kështu ndodhi. Ne përfunduam duke rishqyrtuar arkitekturën brenda. Nuk ka ndryshuar shumë, por për Rusinë tani kemi dy faqe, të cilat nuk janë nga i njëjti ofrues, por nga dy të ndryshëm. Nëse njëra dështon, ne mund të kalojmë te tjetra.
Hipotetikisht, për Amazon ne po shqyrtojmë mundësinë e rezervimit në nivel të një ofruesi tjetër; ndoshta Google, ndoshta dikush tjetër... Por deri tani ne kemi vërejtur në praktikë se ndërsa Amazon ka aksidente në nivelin e një zone të disponueshmërisë, aksidentet në nivelin e një rajoni të tërë janë mjaft të rralla. Prandaj, teorikisht kemi idenë se mund të bëjmë një rezervim "Amazon nuk është Amazon", por në praktikë ende nuk është kështu.
Disa fjalë për automatizimin
A është gjithmonë i nevojshëm automatizimi? Këtu është e përshtatshme të kujtojmë efektin Dunning-Kruger. Në boshtin "x" është njohuria dhe përvoja jonë që fitojmë, dhe në boshtin "y" është besimi në veprimet tona. Në fillim nuk dimë asgjë dhe nuk jemi aspak të sigurt. Atëherë ne dimë pak dhe bëhemi mega-besues - ky është i ashtuquajturi "kulmi i marrëzisë", i ilustruar mirë nga fotografia "çmenduri dhe guxim". Pastaj kemi mësuar pak dhe jemi gati të shkojmë në betejë. Pastaj shkelim disa gabime mega-serioze dhe gjendemi në një luginë dëshpërimi, kur duket se dimë diçka, por në fakt nuk dimë shumë. Pastaj, ndërsa fitojmë përvojë, bëhemi më të sigurt.
Logjika jonë rreth ndërruesve të ndryshëm automatikë në aksidente të caktuara përshkruhet shumë mirë nga ky grafik. Ne filluam - nuk dinim të bënim asgjë, pothuajse e gjithë puna u bë me dorë. Pastaj kuptuam se mund t'i bashkëngjitnim automatizimin çdo gjëje dhe, si për shembull, të flinim të qetë. Dhe befas ne shkelim një mega-rake: shkaktohet një pozitiv i rremë dhe ne ndërrojmë trafikun mbrapa dhe mbrapa kur, në një mënyrë të mirë, nuk duhet ta kishim bërë këtë. Rrjedhimisht, riprodhimi prishet ose diçka tjetër - kjo është vetë lugina e dëshpërimit. Dhe pastaj arrijmë të kuptojmë se duhet t'i qasemi gjithçkaje me mençuri. Kjo do të thotë, ka kuptim të mbështetemi në automatizimin, duke siguruar mundësinë e alarmeve të rreme. Por! nëse pasojat mund të jenë shkatërruese, atëherë është më mirë t'ia lini turnit të detyrës, inxhinierëve në detyrë, të cilët do të sigurohen dhe do të monitorojnë që vërtet ka një aksident dhe do të kryejnë veprimet e nevojshme me dorë...
Përfundim
Gjatë 7 viteve, ne shkuam nga fakti se kur diçka binte, kishte panik-panik, në të kuptuarit se problemet nuk ekzistojnë, ka vetëm detyra, ato duhet - dhe mund - të zgjidhen. Kur po ndërtoni një shërbim, shikojeni nga lart, vlerësoni të gjitha rreziqet që mund të ndodhin. Nëse i shihni menjëherë, atëherë siguroni paraprakisht tepricën dhe mundësinë e ndërtimit të një infrastrukture rezistente ndaj gabimeve, sepse çdo pikë që mund të dështojë dhe të çojë në mosfunksionim të shërbimit do ta bëjë patjetër. Dhe edhe nëse ju duket se disa elementë të infrastrukturës definitivisht nuk do të dështojnë - si i njëjti s3, prapë mbani në mend se munden. Dhe të paktën në teori, kini një ide se çfarë do të bëni me ta nëse diçka ndodh. Keni një plan të menaxhimit të rrezikut. Kur po mendoni të bëni gjithçka automatikisht ose manualisht, vlerësoni rreziqet: çfarë do të ndodhë nëse automatizimi fillon të ndërrojë gjithçka - a nuk do të çojë kjo në një situatë edhe më të keqe në krahasim me një aksident? Ndoshta diku është e nevojshme të përdoret një kompromis i arsyeshëm midis përdorimit të automatizimit dhe reagimit të inxhinierit në detyrë, i cili do të vlerësojë pamjen reale dhe do të kuptojë nëse diçka duhet të ndërrohet në vend ose "po, por jo tani".
Një kompromis i arsyeshëm midis perfeksionizmit dhe përpjekjes reale, kohës, parave që mund të shpenzoni në skemën që do të keni përfundimisht.
Ky tekst është një version i përditësuar dhe i zgjeruar i raportit të Alexander Demidov në konferencë .
Burimi: www.habr.com