Leo, huduma ya Bitrix24 haina mamia ya gigabits ya trafiki, wala haina kundi kubwa la seva (ingawa, bila shaka, kuna chache zilizopo). Lakini kwa wateja wengi ni zana kuu ya kufanya kazi katika kampuni; ni maombi halisi muhimu ya biashara. Kwa hiyo, hakuna njia ya kuanguka. Ikiwa ajali ilitokea, lakini huduma "ilipona" haraka sana kwamba hakuna mtu aliyeona chochote? Na inawezekanaje kutekeleza failover bila kupoteza ubora wa kazi na idadi ya wateja? Alexander Demidov, mkurugenzi wa huduma za wingu katika Bitrix24, alizungumza kwa blogu yetu kuhusu jinsi mfumo wa kuhifadhi umebadilika kwa miaka 7 ya kuwepo kwa bidhaa.
"Tulizindua Bitrix24 kama SaaS miaka 7 iliyopita. Ugumu kuu labda ulikuwa ufuatao: kabla ya kuzinduliwa hadharani kama SaaS, bidhaa hii ilikuwepo tu katika muundo wa suluhisho la sanduku. Wateja waliinunua kutoka kwetu, wakaipangisha kwenye seva zao, wakaanzisha tovuti ya shirika - suluhisho la jumla kwa mawasiliano ya wafanyakazi, kuhifadhi faili, usimamizi wa kazi, CRM, ndivyo tu. Na kufikia 2012, tuliamua kwamba tunataka kuizindua kama SaaS, tukiisimamia sisi wenyewe, kuhakikisha uvumilivu wa makosa na kutegemewa. Tulipata uzoefu njiani, kwa sababu hadi wakati huo hatukuwa nayo - tulikuwa watengenezaji wa programu tu, sio watoa huduma.
Wakati wa kuzindua huduma hiyo, tulielewa kuwa jambo muhimu zaidi ni kuhakikisha uvumilivu wa makosa, kuegemea na upatikanaji wa mara kwa mara wa huduma, kwa sababu ikiwa una tovuti rahisi ya kawaida, duka, kwa mfano, na inakuanguka na kukaa pale. saa, unateseka tu, unapoteza maagizo, unapoteza wateja, lakini kwa mteja wako mwenyewe, hii sio muhimu sana kwake. Alikasirika, bila shaka, lakini akaenda na kuinunua kwenye tovuti nyingine. Na ikiwa hii ni maombi ambayo kazi yote ndani ya kampuni, mawasiliano, maamuzi imefungwa, basi jambo muhimu zaidi ni kupata uaminifu wa watumiaji, yaani, si kuwaacha chini na si kuanguka. Kwa sababu kazi yote inaweza kuacha ikiwa kitu ndani haifanyi kazi.
Bitrix.24 kama SaaS
Tulikusanya mfano wa kwanza mwaka mmoja kabla ya kuzinduliwa kwa umma, mnamo 2011. Tuliikusanya ndani ya wiki moja, tukaitazama, tukaizungusha - ilikuwa inafanya kazi. Hiyo ni, unaweza kwenda kwenye fomu, ingiza jina la lango hapo, lango mpya litafunguliwa, na msingi wa mtumiaji utaundwa. Tuliiangalia, tukatathmini bidhaa kwa kanuni, tukaifuta, na tukaendelea kuiboresha kwa mwaka mzima. Kwa sababu tulikuwa na kazi kubwa: hatukutaka kutengeneza besi mbili tofauti za misimbo, hatukutaka kuunga mkono bidhaa tofauti iliyofungashwa, suluhu tofauti za wingu - tulitaka kufanya yote ndani ya msimbo mmoja.
Programu ya kawaida ya wavuti wakati huo ilikuwa seva moja ambayo nambari fulani ya PHP inaendesha, hifadhidata ya mysql, faili zinapakiwa, hati, picha zimewekwa kwenye folda ya upakiaji - vizuri, yote hufanya kazi. Ole, haiwezekani kuzindua huduma ya wavuti thabiti kwa kutumia hii. Huko, akiba iliyosambazwa haitumiki, uigaji wa hifadhidata hautumiki.
Tuliunda mahitaji: huu ni uwezo wa kupatikana katika maeneo tofauti, usaidizi wa urudufishaji na kupatikana katika vituo tofauti vya data vilivyosambazwa kijiografia. Tenganisha mantiki ya bidhaa na, kwa kweli, uhifadhi wa data. Kuwa na uwezo wa kupima kwa nguvu kulingana na mzigo, na kuvumilia tuli kabisa. Kutokana na mazingatio haya, kwa kweli, mahitaji ya bidhaa yalijitokeza, ambayo tulisafisha kwa kipindi cha mwaka. Wakati huu, kwenye jukwaa, ambalo liligeuka kuwa umoja - kwa suluhu za sanduku, kwa huduma yetu wenyewe - tuliunga mkono vitu ambavyo tulihitaji. Usaidizi wa replication ya mysql katika kiwango cha bidhaa yenyewe: yaani, msanidi programu ambaye anaandika kanuni hafikirii jinsi maombi yake yatasambazwa, anatumia api yetu, na tunajua jinsi ya kusambaza kwa usahihi kuandika na kusoma maombi kati ya mabwana. na watumwa.
Tumetoa usaidizi katika kiwango cha bidhaa kwa hifadhi mbalimbali za vitu vya wingu: hifadhi ya google, amazon s3, pamoja na usaidizi wa uwekaji stack wazi. Kwa hivyo, hii ilikuwa rahisi kwetu kama huduma na kwa watengenezaji wanaofanya kazi na suluhisho lililowekwa vifurushi: ikiwa wanatumia tu API yetu kufanya kazi, hawafikirii juu ya wapi faili itahifadhiwa, ndani ya mfumo wa faili au. kwenye hifadhi ya faili ya kitu.
Kama matokeo, tuliamua mara moja kwamba tutahifadhi kwenye kiwango cha kituo kizima cha data. Mnamo 2012, tulizindua kabisa kwenye Amazon AWS kwa sababu tayari tulikuwa na uzoefu na mfumo huu - tovuti yetu wenyewe ilipangishwa hapo. Tulivutiwa na ukweli kwamba katika kila eneo Amazon ina kanda kadhaa za upatikanaji - kwa kweli, (katika istilahi zao) vituo kadhaa vya data ambavyo vinajitegemea zaidi au chini vya kila mmoja na huturuhusu kuhifadhi katika kiwango cha kituo kizima cha data: ikiwa itashindwa ghafla, hifadhidata zinaigwa bwana-bwana, seva za programu ya wavuti zinachelezwa, na data tuli huhamishiwa kwenye hifadhi ya kitu cha s3. Mzigo ni wa usawa - wakati huo na Amazon elb, lakini baadaye kidogo tulikuja kwa mizani yetu ya mzigo, kwa sababu tulihitaji mantiki ngumu zaidi.
Walichokuwa wakitaka ni kile walichokipata...
Mambo yote ya msingi ambayo tulitaka kuhakikisha - uvumilivu wa makosa ya seva zenyewe, programu za wavuti, hifadhidata - kila kitu kilifanya kazi vizuri. Hali rahisi zaidi: ikiwa moja ya programu zetu za wavuti inashindwa, basi kila kitu ni rahisi - zimezimwa kutoka kwa kusawazisha.
Kisawazisha (wakati huo kilikuwa kiwiko cha Amazon) kilitia alama kwenye mashine ambazo hazikuwa na mpangilio mzuri kama zisizofaa na kuzima usambazaji wa mzigo kwenye hizo. Amazon autoscaling ilifanya kazi: wakati mzigo ulikua, mashine mpya ziliongezwa kwa kikundi cha autoscaling, mzigo ulisambazwa kwa mashine mpya - kila kitu kilikuwa sawa. Pamoja na wasawazishaji wetu, mantiki ni takriban sawa: ikiwa kitu kitatokea kwa seva ya programu, tunaondoa maombi kutoka kwayo, kutupa mashine hizi, kuanza mpya na kuendelea kufanya kazi. Mpango huo umebadilika kidogo zaidi ya miaka, lakini inaendelea kufanya kazi: ni rahisi, inaeleweka, na hakuna ugumu nayo.
Tunafanya kazi kote ulimwenguni, kilele cha mzigo wa wateja ni tofauti kabisa, na, kwa njia ya kirafiki, tunapaswa kuwa na uwezo wa kutekeleza kazi fulani ya huduma kwenye vipengee vyovyote vya mfumo wetu wakati wowote - bila kutambuliwa na wateja. Kwa hiyo, tuna fursa ya kuzima database kutoka kwa uendeshaji, kusambaza tena mzigo kwenye kituo cha data cha pili.
Yote hufanyaje kazi? - Tunabadilisha trafiki hadi kituo cha data kinachofanya kazi - ikiwa kuna ajali kwenye kituo cha data, basi kabisa, ikiwa hii ni kazi yetu iliyopangwa na hifadhidata moja, basi tunabadilisha sehemu ya trafiki inayohudumia wateja hawa hadi kituo cha pili cha data, kusimamisha ni replication. Ikiwa mashine mpya zinahitajika kwa programu za wavuti kwa sababu mzigo kwenye kituo cha data cha pili umeongezeka, zitaanza moja kwa moja. Tunamaliza kazi, replication ni kurejeshwa, na sisi kurudi mzigo mzima nyuma. Ikiwa tunahitaji kuangazia kazi fulani katika DC ya pili, kwa mfano, sasisha sasisho za mfumo au ubadilishe mipangilio kwenye hifadhidata ya pili, basi, kwa ujumla, tunarudia jambo lile lile, kwa upande mwingine. Na ikiwa hii ni ajali, basi tunafanya kila kitu kidogo: tunatumia utaratibu wa washughulikiaji wa tukio katika mfumo wa ufuatiliaji. Ikiwa ukaguzi kadhaa umeanzishwa na hali inakwenda kwa muhimu, basi tunaendesha kidhibiti hiki, kidhibiti kinachoweza kutekeleza mantiki hii au ile. Kwa kila hifadhidata, tunabainisha ni seva gani iliyoshindwa, na ambapo trafiki inahitaji kubadilishwa ikiwa haipatikani. Kihistoria, tunatumia nagios au baadhi ya uma zake kwa namna moja au nyingine. Kimsingi, mifumo kama hiyo ipo katika karibu mfumo wowote wa ufuatiliaji; hatutumii chochote ngumu zaidi, lakini labda siku moja tutatumia. Sasa ufuatiliaji unasababishwa na kutopatikana na una uwezo wa kubadili kitu.
Je! tumehifadhi kila kitu?
Tuna wateja wengi kutoka Marekani, wateja wengi kutoka Ulaya, wateja wengi walio karibu na Mashariki - Japan, Singapore na kadhalika. Bila shaka, sehemu kubwa ya wateja ni katika Urusi. Hiyo ni, kazi haiko katika mkoa mmoja. Watumiaji wanataka jibu la haraka, kuna mahitaji ya kuzingatia sheria mbalimbali za ndani, na ndani ya kila eneo tunahifadhi vituo viwili vya data, pamoja na kuna huduma za ziada, ambazo, tena, ni rahisi kuweka ndani ya eneo moja - kwa wateja walio katika mkoa huu unafanya kazi. Vidhibiti vya REST, seva za uidhinishaji, sio muhimu sana kwa uendeshaji wa mteja kwa ujumla, unaweza kuzibadilisha kwa ucheleweshaji mdogo unaokubalika, lakini hutaki kuunda tena gurudumu la jinsi ya kuzifuatilia na nini cha kufanya. pamoja nao. Kwa hiyo, tunajaribu kutumia ufumbuzi uliopo kwa kiwango cha juu, badala ya kuendeleza aina fulani ya uwezo katika bidhaa za ziada. Na mahali pengine tunatumia ubadilishaji kwa kiwango cha DNS, na tunaamua uchangamfu wa huduma kwa DNS sawa. Amazon ina huduma ya Njia 53, lakini sio tu DNS ambayo unaweza kuingiza na ndivyo hivyo - ni rahisi zaidi na rahisi. Kupitia hiyo unaweza kujenga huduma za kusambazwa kwa geo na geolocations, unapoitumia ili kuamua ambapo mteja alitoka na kumpa rekodi fulani - kwa msaada wake unaweza kujenga usanifu wa kushindwa. Ukaguzi sawa wa afya umesanidiwa katika Njia ya 53 yenyewe, unaweka miisho ambayo inafuatiliwa, kuweka metriki, kuweka itifaki za kuamua "uhai" wa huduma - tcp, http, https; weka marudio ya ukaguzi unaoamua ikiwa huduma iko hai au la. Na katika DNS yenyewe unataja nini kitakuwa cha msingi, nini kitakuwa sekondari, wapi kubadili ikiwa ukaguzi wa afya unasababishwa ndani ya njia 53. Yote hii inaweza kufanywa na zana zingine, lakini kwa nini ni rahisi - tunaiweka. mara moja na kisha usifikirie juu yake hata kidogo jinsi tunavyofanya ukaguzi, jinsi tunavyobadilisha: kila kitu hufanya kazi peke yake.
Ya kwanza "lakini": jinsi gani na kwa nini kuhifadhi njia 53 yenyewe? Nani anajua, nini ikiwa kitu kitatokea kwake? Kwa bahati nzuri, hatukuwahi kukanyaga safu hii, lakini tena, nitakuwa na hadithi mbele ya kwa nini tulifikiria kuwa bado tulihitaji kuweka nafasi. Hapa tulijiwekea majani mapema. Mara kadhaa kwa siku tunapakua maeneo yote ambayo tunayo katika njia ya 53. API ya Amazon hukuruhusu kuzituma kwa urahisi katika JSON, na tuna seva kadhaa chelezo ambapo tunaibadilisha, kuipakia katika mfumo wa usanidi na kuwa na usanidi wa chelezo. Jambo likitokea, tunaweza kulitumia kwa haraka bila kupoteza data ya mipangilio ya DNS.
Pili "lakini": Ni nini kwenye picha hii bado hakijahifadhiwa? Msawazishaji mwenyewe! Usambazaji wetu wa wateja kwa mkoa unafanywa rahisi sana. Tuna vikoa bitrix24.ru, bitrix24.com, .de - sasa kuna 13 tofauti, ambazo zinafanya kazi katika maeneo mbalimbali. Tulikuja kwa zifuatazo: kila mkoa una wasawazishaji wake. Hii inafanya iwe rahisi zaidi kusambaza katika mikoa yote, kulingana na mahali ambapo kilele cha mzigo kwenye mtandao kiko. Ikiwa hii ni kushindwa kwa kiwango cha usawa mmoja, basi inachukuliwa tu nje ya huduma na kuondolewa kutoka kwa dns. Ikiwa kuna shida fulani na kikundi cha wasawazishaji, basi zinaungwa mkono kwenye tovuti zingine, na kubadili kati yao hufanyika kwa kutumia njia sawa53, kwa sababu kutokana na TTL fupi, kubadili hutokea ndani ya kiwango cha juu cha 2, 3, 5 dakika. .
Tatu "lakini": Ni nini ambacho bado hakijahifadhiwa? S3, sawa. Tulipoweka faili ambazo tunahifadhi kwa watumiaji katika s3, tuliamini kwa dhati kuwa ilikuwa ni kutoboa silaha na hakukuwa na haja ya kuhifadhi chochote hapo. Lakini historia inaonyesha kwamba mambo hutokea tofauti. Kwa ujumla, Amazon inaelezea S3 kama huduma ya msingi, kwa sababu Amazon yenyewe hutumia S3 kuhifadhi picha za mashine, usanidi, picha za AMI, picha... bitrix3, inaifuata kama shabiki Kuna rundo zima la vitu vinavyojitokeza - kutokuwa na uwezo wa kuanzisha mashine pepe, kushindwa kwa api, na kadhalika.
Na S3 inaweza kuanguka - ilitokea mara moja. Kwa hiyo, tulikuja kwenye mpango wafuatayo: miaka michache iliyopita hapakuwa na vifaa vikubwa vya kuhifadhi vitu vya umma nchini Urusi, na tulizingatia chaguo la kufanya kitu chetu wenyewe ... Kwa bahati nzuri, hatukuanza kufanya hivyo, kwa sababu tungefanya hivyo. wamechimba utaalamu ambao hatuna tunao, na pengine ungevuruga. Sasa Mail.ru ina uhifadhi unaoendana na s3, Yandex inayo, na idadi ya watoa huduma wengine wanayo. Hatimaye tulikuja kwenye wazo kwamba tulitaka kuwa, kwanza, chelezo, na pili, uwezo wa kufanya kazi na nakala za ndani. Kwa eneo la Kirusi hasa, tunatumia huduma ya Mail.ru Hotbox, ambayo ni API inayoendana na s3. Hatukuhitaji marekebisho yoyote makubwa kwa msimbo ndani ya programu, na tulifanya utaratibu ufuatao: katika s3 kuna vichochezi vinavyosababisha uundaji / ufutaji wa vitu, Amazon ina huduma inayoitwa Lambda - huu ni uzinduzi usio na seva wa nambari. hiyo itatekelezwa wakati vichochezi fulani vimeanzishwa.
Tulifanya hivyo kwa urahisi sana: ikiwa kichocheo chetu kitawaka, tunatoa nambari ambayo itakili kitu kwenye hifadhi ya Mail.ru. Ili kuzindua kikamilifu kazi na nakala za data za ndani, tunahitaji usawazishaji wa kinyume ili wateja walio katika sehemu ya Kirusi waweze kufanya kazi na hifadhi iliyo karibu nao. Barua inakaribia kukamilisha vichochezi katika hifadhi yake - itawezekana kufanya usawazishaji wa kinyume katika kiwango cha miundombinu, lakini kwa sasa tunafanya hivi katika kiwango cha msimbo wetu wenyewe. Ikiwa tunaona kwamba mteja amechapisha faili, basi katika kiwango cha msimbo tunaweka tukio kwenye foleni, tukilichakata na tunarudia kinyume. Kwa nini ni mbaya: ikiwa tunafanya aina fulani ya kazi na vitu vyetu nje ya bidhaa zetu, yaani, kwa njia fulani za nje, hatutazingatia. Kwa hiyo, tunasubiri hadi mwisho, wakati vichochezi vinapoonekana kwenye kiwango cha kuhifadhi, ili bila kujali wapi tunafanya msimbo kutoka, kitu kilichokuja kwetu kinakiliwa kwa upande mwingine.
Katika kiwango cha msimbo, tunasajili hifadhi zote mbili kwa kila mteja: moja inachukuliwa kuwa moja kuu, nyingine inachukuliwa kuwa salama. Ikiwa kila kitu ni sawa, tunafanya kazi na hifadhi iliyo karibu na sisi: yaani, wateja wetu ambao wako Amazon, wanafanya kazi na S3, na wale wanaofanya kazi nchini Urusi, wanafanya kazi na Hotbox. Ikiwa alama imeanzishwa, basi kushindwa kunapaswa kuunganishwa, na tunabadilisha wateja hadi hifadhi nyingine. Tunaweza kuteua kisanduku hiki kwa kujitegemea kulingana na eneo na tunaweza kuzibadilisha na kurudi. Hatujatumia hii katika mazoezi bado, lakini tumetoa kwa utaratibu huu na tunafikiri kwamba siku moja tutahitaji swichi hii na kuja kwa manufaa. Hii tayari imetokea mara moja.
Ah, na Amazon ilikimbia ...
Aprili hii inaashiria kumbukumbu ya mwanzo wa kuzuia Telegraph nchini Urusi. Mtoa huduma aliyeathiriwa zaidi ambaye alianguka chini ya hii ni Amazon. Na, kwa bahati mbaya, kampuni za Kirusi ambazo zilifanya kazi kwa ulimwengu wote ziliteseka zaidi.
Ikiwa kampuni ni ya kimataifa na Urusi ni sehemu ndogo sana kwa ajili yake, 3-5% - vizuri, kwa njia moja au nyingine, unaweza kuwatoa sadaka.
Ikiwa hii ni kampuni ya Kirusi - nina hakika kwamba inahitaji kuwekwa ndani - vizuri, itakuwa rahisi kwa watumiaji wenyewe, vizuri, na kutakuwa na hatari chache.
Je, ikiwa hii ni kampuni inayofanya kazi duniani kote na ina takriban idadi sawa ya wateja kutoka Urusi na mahali pengine duniani kote? Uunganisho wa makundi ni muhimu, na lazima wafanye kazi kwa njia moja au nyingine.
Mwishoni mwa Machi 2018, Roskomnadzor alituma barua kwa waendeshaji wakubwa zaidi akisema kwamba walipanga kuzuia milioni kadhaa za IP za Amazon ili kuzuia ... mjumbe wa Zello. Shukrani kwa watoa huduma hawa - walifanikiwa kuvuja barua kwa kila mtu, na kulikuwa na ufahamu kwamba uhusiano na Amazon unaweza kuanguka. Ilikuwa Ijumaa, tulikimbia kwa hofu kwa wenzetu kutoka servers.ru, na maneno haya: "Marafiki, tunahitaji seva kadhaa ambazo hazitapatikana nchini Urusi, sio Amazon, lakini, kwa mfano, mahali fulani huko Amsterdam," ili kuweza angalau kwa namna fulani kusakinisha VPN yetu na wakala hapo kwa vidokezo vingine ambavyo hatuwezi kushawishi kwa njia yoyote, kwa mfano viunga vya s3 sawa - hatuwezi kujaribu kuongeza huduma mpya na kupata tofauti. ip, bado unahitaji kufika huko. Katika siku chache tu, tulianzisha seva hizi, tukawaweka na kukimbia, na, kwa ujumla, tumejiandaa kwa wakati kuzuia kuanza. Inashangaza kwamba RKN, akiangalia ugomvi na hofu, alisema: "Hapana, hatutazuia chochote sasa." (Lakini hii ni hasa hadi wakati ambapo Telegram ilianza kuzuiwa.) Baada ya kuanzisha uwezo wa bypass na kutambua kwamba kuzuia hakujaanzishwa, sisi, hata hivyo, hatukuanza kutatua suala zima. Ndio, ikiwa tu.
Na mnamo 2019, bado tunaishi katika hali ya kuzuia. Niliangalia jana usiku: kuhusu IPs milioni moja zinaendelea kuzuiwa. Kweli, Amazon ilikuwa karibu kufunguliwa kabisa, katika kilele chake ilifikia anwani milioni 20 ... Kwa ujumla, ukweli ni kwamba kunaweza kuwa hakuna mshikamano, mshikamano mzuri. Ghafla. Inaweza kuwa haipo kwa sababu za kiufundi - moto, wachimbaji, yote hayo. Au, kama tumeona, sio kiufundi kabisa. Kwa hiyo, mtu mkubwa na mkubwa, na AS zao wenyewe, wanaweza pengine kusimamia hili kwa njia nyingine - kuunganisha moja kwa moja na vitu vingine tayari viko kwenye kiwango cha l2. Lakini katika toleo rahisi, kama letu au hata ndogo, unaweza, ikiwa tu, kuwa na upungufu katika kiwango cha seva zilizoinuliwa mahali pengine, zilizosanidiwa mapema vpn, wakala, na uwezo wa kubadili usanidi haraka kwao katika sehemu hizo. ambazo ni muhimu kwa muunganisho wako. Hii ilikuja kutufaa zaidi ya mara moja, wakati uzuiaji wa Amazon ulipoanza; katika hali mbaya zaidi, tuliruhusu trafiki ya S3 tu kupitia kwao, lakini hatua kwa hatua yote haya yalitatuliwa.
Jinsi ya kuweka... mtoa huduma mzima?
Hivi sasa hatuna scenario ikiwa Amazon nzima itapungua. Tunayo hali kama hiyo kwa Urusi. Katika Urusi, tulikuwa mwenyeji na mtoa huduma mmoja, ambaye tulichagua kuwa na tovuti kadhaa. Na mwaka mmoja uliopita tulikabiliwa na tatizo: ingawa hivi ni vituo viwili vya data, kunaweza kuwa na matatizo tayari katika kiwango cha usanidi wa mtandao wa mtoa huduma ambayo bado yataathiri vituo vyote viwili vya data. Na tunaweza kuishia kutopatikana kwenye tovuti zote mbili. Bila shaka ndivyo ilivyotokea. Tulimaliza kufikiria upya usanifu wa ndani. Haijabadilika sana, lakini kwa Urusi sasa tuna tovuti mbili, ambazo hazitokani na mtoa huduma mmoja, lakini kutoka kwa mbili tofauti. Ikiwa moja itashindwa, tunaweza kubadili nyingine.
Kidhahania, kwa Amazon tunazingatia uwezekano wa kuweka nafasi katika kiwango cha mtoaji mwingine; labda Google, labda mtu mwingine ... Lakini hadi sasa tumeona kwa vitendo kwamba wakati Amazon ina ajali katika kiwango cha eneo moja la upatikanaji, ajali katika ngazi ya eneo zima ni nadra sana. Kwa hivyo, kinadharia tuna wazo kwamba tunaweza kufanya uhifadhi wa "Amazon sio Amazon", lakini kwa mazoezi hii bado haijafanyika.
Maneno machache kuhusu automatisering
Je, otomatiki ni muhimu kila wakati? Hapa inafaa kukumbuka athari ya Dunning-Kruger. Kwenye mhimili wa "x" kuna ujuzi na uzoefu wetu tunaopata, na kwenye mhimili wa "y" ni ujasiri katika matendo yetu. Mwanzoni hatujui chochote na hatuna uhakika kabisa. Halafu tunajua kidogo na tunajiamini sana - hii ndio inayoitwa "kilele cha ujinga", iliyoonyeshwa vizuri na picha "shida ya akili na ujasiri". Kisha tumejifunza kidogo na tuko tayari kwenda vitani. Kisha sisi hatua juu ya makosa mega-kubwa na kujikuta katika bonde la kukata tamaa, wakati tunaonekana kujua kitu, lakini kwa kweli hatujui mengi. Kisha, tunapopata uzoefu, tunakuwa na ujasiri zaidi.
Mantiki yetu kuhusu swichi mbalimbali otomatiki kwa ajali fulani imeelezewa vizuri na grafu hii. Tulianza - hatukujua jinsi ya kufanya chochote, karibu kazi yote ilifanywa kwa mikono. Kisha tukagundua kuwa tunaweza kushikamana na otomatiki kwa kila kitu na, kama, kulala kwa amani. Na ghafla tunakanyaga mega-rake: chanya ya uwongo imeanzishwa, na tunabadilisha trafiki na kurudi wakati, kwa njia nzuri, hatukupaswa kufanya hivi. Kwa hiyo, uigaji huvunjika au kitu kingineβhili ndilo bonde lenyewe la kukata tamaa. Na kisha tunakuja kuelewa kwamba ni lazima tufikie kila kitu kwa busara. Hiyo ni, ni mantiki kutegemea otomatiki, kutoa uwezekano wa kengele za uwongo. Lakini! ikiwa matokeo yanaweza kuwa mabaya, basi ni bora kuiacha kwa mabadiliko ya kazi, kwa wahandisi wa zamu, ambao watahakikisha na kufuatilia kuwa kweli kuna ajali, na watafanya vitendo muhimu kwa mikono ...
Hitimisho
Katika kipindi cha miaka 7, tulitoka kwa ukweli kwamba wakati kitu kilianguka, kulikuwa na hofu-hofu, kwa kuelewa kwamba matatizo haipo, kuna kazi tu, lazima - na zinaweza kutatuliwa. Unapojenga huduma, angalia kutoka juu, tathmini hatari zote zinazoweza kutokea. Ikiwa unawaona mara moja, basi toa upungufu mapema na uwezekano wa kujenga miundombinu isiyo na makosa, kwa sababu hatua yoyote ambayo inaweza kushindwa na kusababisha kutofanya kazi kwa huduma itakuwa dhahiri kufanya hivyo. Na hata kama inaonekana kwako kuwa baadhi ya vipengele vya miundombinu hakika havitashindwa - kama vile s3, bado kumbuka kwamba wanaweza. Na angalau kwa nadharia, kuwa na wazo la nini utafanya nao ikiwa kitu kitatokea. Kuwa na mpango wa usimamizi wa hatari. Unapofikiria kufanya kila kitu kiatomati au kwa mikono, tathmini hatari: nini kitatokea ikiwa otomatiki itaanza kubadili kila kitu - hii haitasababisha hali mbaya zaidi ikilinganishwa na ajali? Labda mahali pengine inahitajika kutumia maelewano ya busara kati ya utumiaji wa otomatiki na mwitikio wa mhandisi aliye kazini, ambaye atatathmini picha halisi na kuelewa ikiwa kitu kinahitaji kubadilishwa papo hapo au "ndio, lakini sio sasa."
Maelewano ya busara kati ya ukamilifu na juhudi halisi, wakati, pesa ambazo unaweza kutumia kwenye mpango ambao utakuwa nao hatimaye.
Maandishi haya ni toleo lililosasishwa na lililopanuliwa la ripoti ya Alexander Demidov kwenye mkutano huo .
Chanzo: mapenzi.com