Îro, karûbarê Bitrix24 ne bi sedan gigabit seyrûsefer e, ne jî xwedan fîloyek mezin a pêşkêşkeran e (her çend, bê guman, çend yên heyî hene). Lê ji bo gelek xerîdar ew amûrek sereke ye ku di pargîdaniyê de bixebite, ew serîlêdanek karsaziyek krîtîk e. Ji ber vê yekê, rê li ber ketinê tune. Ger qeza çêbibe, lê karûbar ew qas zû "vegere" ku çu kesî tiştek ferq nekir? Û çawa gengaz e ku failover bêyî windakirina kalîteya kar û hejmara xerîdaran were sepandin? Alexander Demidov, derhênerê karûbarên cloudê li Bitrix24, ji bo bloga me di derbarê 7 salên hebûna hilberê de pergala veqetandinê çawa pêş ketiye.
"Me 24 sal berê Bitrix7 wekî SaaS dest pê kir. Zehmetiya sereke belkî ev bû: berî ku ew bi gelemperî wekî SaaS were destpêkirin, ev hilber tenê di forma çareseriyek qutikê de hebû. Xerîdar ew ji me kirî, ew li ser serverên xwe mêvan kirin, portalek pargîdanî saz kirin - çareseriyek gelemperî ji bo ragihandina karmendan, hilanîna pelan, rêveberiya peywirê, CRM, ew hemî. Û heya sala 2012-an, me biryar da ku em dixwazin wê wekî SaaS bidin destpêkirin, wê bixwe îdare bikin, tolerans û pêbaweriya xeletiyê misoger bikin. Me di rê de ezmûnek bi dest xist, ji ber ku heya wê demê me ew bi hêsanî tunebû - em tenê hilberînerên nermalavê bûn, ne pêşkêşkerên karûbar.
Dema destpêkirina karûbarê, me fêm kir ku ya herî girîng ew e ku meriv tolerasyona xeletiyê, pêbawerî û hebûna domdar a karûbarê peyda bike, ji ber ku heke we malperek asayî ya hêsan hebe, mînakek dikanek, û ew li we dikeve û li wir rûdine. saetekê, tenê hûn diêşin, hûn fermanan winda dikin, hûn xerîdaran winda dikin, lê ji bo muwekîlê we bixwe, ev ji bo wî ne pir krîtîk e. Bê guman ew xemgîn bû, lê ew çû û li ser malperek din kirî. Û heke ev serîlêdanek e ku hemî karên di hundurê pargîdaniyê, ragihandin, biryar li ser ve girêdayî ye, wê hingê ya herî girîng ew e ku meriv pêbaweriya bikarhêneran bidest bixe, ango nehêle wan û nekeve. Ji ber ku heke tiştek hundur nexebite, hemî kar dikare raweste.
Bitrix.24 wekî SaaS
Me prototîpa yekem salek berî destpêkirina giştî, di 2011 de, civandin. Me ew di nav hefteyekê de civand, lê nihêrî, zivirî - ew jî dixebitî. Ango, hûn dikarin bikevin formê, li wir navê portalê têkevin, dê portalek nû vebe, û bingehek bikarhêner dê were afirandin. Me lê nihêrî, hilber bi prensîbê nirxand, ew hilweşand, û salek tevahî paqijkirina wê domand. Ji ber ku peywirek me ya mezin hebû: me nexwest ku em du bingehên kodê yên cihêreng çêbikin, me nexwest ku piştgirî bidin hilberek pakkirî ya cihê, çareseriyên ewr ên cihêreng - me dixwest ku em hemî di nav yek kodê de bikin.
Di wê demê de serîlêdanek webê ya gelemperî yek serverek bû ku li ser hin kodên PHP-ê dimeşîne, databasek mysql, pel têne barkirin, belge, wêne di peldanka barkirinê de têne danîn - baş e, ew hemî dixebite. Mixabin, ne mimkûn e ku meriv karûbarek webê ya krîtîk bi karanîna vê yekê bide destpêkirin. Li wir, cache-ya belavkirî nayê piştgirî kirin, dubarekirina databasê nayê piştgirî kirin.
Me pêdiviyan formule kir: ev şiyana ku meriv li cîhên cihêreng bi cih bibe, piştgiriyek piştgirî bike, û bi îdeal li navendên daneyên cihêreng ên erdnîgarî yên belavbûyî de cîh bigire. Mantiqa hilberê û, bi rastî, hilanîna daneyê ji hev veqetînin. Dikarin bi dînamîk li gorî barkirinê pîvan bikin, û bi tevahî statîkan tehemûl bikin. Ji van ramanan, bi rastî, hewcedariyên hilberê derketin, ku me di nav salê de paqij kir. Di vê demê de, di platforma ku yekgirtî derket holê - ji bo çareseriyên qutkirî, ji bo xizmeta xwe - me piştgirî da wan tiştên ku ji me re hewce bûn. Piştgiriya ji bo dubarekirina mysql di asta hilberê bixwe de: ango pêşdebirê ku kodê dinivîse nafikire ka dê daxwazên wî çawa werin belavkirin, ew api me bikar tîne, û em dizanin ka meriv çawa daxwazên nivîsandin û xwendinê rast di navbera axayan de belav dike. û koleyan.
Me di asta hilberê de ji bo hilanîna tiştên ewr ên cihêreng piştgirî çêkir: hilanîna google, amazon s3, plus piştgirî ji bo stack swift vekirî. Ji ber vê yekê, ev hem ji bo me wekî karûbar û hem jî ji bo pêşdebirên ku bi çareseriyek pakkirî re dixebitin rehet bû: heke ew tenê API-ya me ji bo xebatê bikar bînin, ew nafikirin ka pel dê di dawiyê de li ku derê were hilanîn, herêmî li ser pergala pelê an di hilanîna pelê objeyê de.
Wekî encamek, me tavilê biryar da ku em ê di asta tevahiya navenda daneyê de veqetînin. Di sala 2012-an de, me bi tevahî li ser Amazon AWS dest pê kir ji ber ku me berê xwedan ezmûna vê platformê bû - malpera me li wir hate mêvan kirin. Em ji vê yekê balkêş bûn ku li her deverê Amazon xwedan çend deverên peydabûnê ye - bi rastî, (bi termînolojiya wan) çend navendên daneyê ku kêm-zêde ji hev serbixwe ne û rê didin me ku em di asta navendek daneya tevahî de rezerv bikin: heke ew ji nişka ve têk biçe, databasên master-master têne dubare kirin, serverên serîlêdana webê têne piştguh kirin, û daneyên statîk berbi hilanîna tiştên s3 ve têne veguhestin. Barkirin hevseng e - di wê demê de ji hêla Amazon elb ve, lê piçek şûnda em gihîştin balanserên xwe yên barkirinê, ji ber ku me hewceyê mantiqek tevlihevtir bû.
Ya ku wan dixwest ew e ku ew bi dest xistin…
Hemî tiştên bingehîn ên ku me dixwest em piştrast bikin - tolerasyona xeletiya serveran bixwe, serîlêdanên malperê, databas - her tişt baş xebitî. Senaryoya herî hêsan: heke yek ji serîlêdanên webê me têk bibe, wê hingê her tişt hêsan e - ew ji hevsengiyê têne qut kirin.
Balansek (wê demê ew elbê Amazonê bû) makîneyên ku ji rêzê derketin wekî nebaş nîşan da û belavkirina barkirinê li ser wan qut kir. Xweseriya Amazon xebitî: gava ku bar mezin bû, makîneyên nû li koma otoscaling hatin zêdekirin, bar li makîneyên nû hate belav kirin - her tişt baş bû. Digel hevsengên me, mantiq hema hema yek e: heke tiştek bi servera serîlêdanê re çêbibe, em daxwazan jê derdixin, van makîneyan davêjin, yên nû dest pê dikin û xebatê didomînin. Pîlana bi salan hinekî guherî, lê xebata xwe berdewam dike: ew hêsan e, têgihîştî ye û bi wê re ti dijwarî tune.
Em li çaraliyê cîhanê dixebitin, lûtkeyên barkirina xerîdar bi tevahî cûda ne, û, bi rengek dostane, divê em karibin di her kêliyê de li ser her pêkhateyên pergala xwe hin xebata karûbarê bimeşînin - ji hêla xerîdar ve nayên dîtin. Ji ber vê yekê, me fersendek heye ku em databasê ji xebatê qut bikin, barkirinê li navendek daneya duyemîn belav bikin.
Ew hemî çawa dixebite? - Em seyrûseferê diguhezînin navendek daneya xebatê - heke li navenda daneyê qezayek çêbibe, wê hingê bi tevahî, heke ev xebata me ya plansazkirî bi yek databasê re be, wê hingê em beşek seyrûsefera ku ji van xerîdaran re xizmet dike vediguhezînin navendek daneya duyemîn, sekinandin ew dubarekirin. Ger makîneyên nû ji bo serîlêdanên malperê hewce ne ji ber ku barkirina navenda daneya duyemîn zêde bûye, ew ê bixweber dest pê bikin. Em xebatê diqedînin, dubarekirin tê vegerandin, û em tevahiya barkirinê vedigerînin. Ger hewce be ku em di DC-ya duyemîn de hin karan neynikê bikin, mînakî, nûvekirinên pergalê saz bikin an mîhengan di databasa duyemîn de biguhezînin, wê hingê, bi gelemperî, em heman tiştî dubare dikin, tenê di riya din de. Û heke ev qezayek be, wê hingê em her tiştî bi sivikî dikin: em di pergala şopandinê de mekanîzmaya rêvebirên bûyerê bikar tînin. Ger çend kontrol bên kirin û statû berbi krîtîk ve biçe, wê hingê em vê rêvekerê dimeşînin, hilberek ku dikare vê an wê mantiqê pêk bîne. Ji bo her databasê, em diyar dikin ka kîjan server ji bo wê têkçûn e, û ger ku ew ne berdest be divê seyrûsefer li ku were guheztin. Ji hêla dîrokî ve, em nagios an hin çeqilkên wê bi rengekî an yekî din bikar tînin. Di prensîbê de, mekanîzmayên wekhev hema hema di her pergalên çavdêriyê de hene, em hîn tiştek tevlihevtir bikar neynin, lê dibe ku rojek em bikar bînin. Naha çavdêrî ji hêla tunebûnê ve tê rêve kirin û jêhatîbûna ku tiştek biguhezîne heye.
Me her tişt parastiye?
Gelek xerîdarên me ji DY hene, gelek xerîdarên ji Ewrûpayê, gelek xerîdarên ku nêzî Rojhilat in - Japonya, Singapûr û hwd. Bê guman, beşek mezin a xerîdar li Rûsyayê ne. Yanî kar ne li herêmekê ye. Bikarhêner bersivek bilez dixwazin, pêdivî hene ku bi qanûnên cihêreng ên herêmî re tevbigerin, û di nav her herêmê de em du navendên daneyê vedigirin, plus hin karûbarên din jî hene, ku, dîsa, hêsan e ku meriv di nav yek herêmê de bi cih bike - ji bo xerîdarên ku li vê herêmê dixebitin. Rêvebirên REST, serverên destûrnameyê, ew ji bo xebata xerîdar bi tevahî kêmtir krîtîk in, hûn dikarin bi derengiyek piçûk a pejirandî bi wan veguhezînin, lê hûn naxwazin çerxa li ser meriv çawa çavdêriya wan û çi bikin ji nû ve îcad bikin. bi wan re. Ji ber vê yekê, em hewl didin ku çareseriyên heyî herî zêde bikar bînin, ne ku di hilberên zêde de celebek jêhatîbûnê pêşve bibin. Û li deverekê em di asta DNS-ê de veguheztina bi sivikî bikar tînin, û em zindîbûna karûbarê bi heman DNS-ê diyar dikin. Amazon xwedan karûbarek Route 53 e, lê ew ne tenê DNS-yek e ku hûn dikarin tê de têkevinê û ew e - ew pir maqûltir û rehettir e. Bi navgîniya wê hûn dikarin karûbarên erdnîgarî-belavkirî bi erdnîgarî ava bikin, gava ku hûn wê bikar bînin da ku diyar bikin ku xerîdar ji ku derê hatiye û hin tomaran bidin wî - bi alîkariya wê hûn dikarin mîmariyên failover ava bikin. Heman kontrolên tenduristiyê di Route 53-ê bixwe de têne mîheng kirin, hûn xalên dawî yên ku têne şopandin destnîşan dikin, metrîkan destnîşan dikin, kîjan protokolan destnîşan dikin ku "jiyana" ya karûbarê diyar bikin - tcp, http, https; frekansa kontrolên ku diyar dikin ka karûbar zindî ye an na bicîh bikin. Û di DNS-ya xwe de hûn diyar dikin ka dê çi bibe seretayî, dê çi bibe duyemîn, ger kontrolkirina tenduristiyê di hundurê riya 53-ê de were veguheztin li ku derê biguhezîne. Hemî ev dikare bi hin amûrên din re were kirin, lê çima ew hêsan e - me ew destnîşan kir carekê û dû re qet nefikirin ka em çawa kontrol dikin, em çawa diguhezin: her tişt bi serê xwe dixebite.
Yekem "lê": Meriv çawa û bi çi riya 53 bixwe veqetîne? Kî dizane, eger tiştek were serê wî? Xweşbextane, me tu carî gav neavêt ser vê raketinê, lê dîsa, ez ê çîrokek li pêşiya me hebe ku çima me difikirî ku em hîn jî hewce ne ku rezervasyonek çêbikin. Li vir me ji bo xwe ji berê de çîp danîn. Rojê çend caran em hemî deverên ku di rêça 53-an de hene bi tevahî dakêşin. API-ya Amazon dihêle hûn bi hêsanî wan di JSON-ê de bişînin, û me gelek pêşkêşkerên hilanînê hene ku em wê vediguhezînin, di forma mîhengan de bar dikin û bi gelemperî veavakirinek hilanînê heye. Ger tiştek diqewime, em dikarin bi lez wê bi destan saz bikin bêyî ku daneyên mîhengên DNS-ê winda bikin.
Duyemîn "lê": Çi di vê wêneyê de hîn nehatiye veqetandin? Balansek bixwe! Dabeşkirina me ya xerîdar li gorî herêmê pir hêsan tê çêkirin. Domênên me hene bitrix24.ru, bitrix24.com, .de - niha 13 yên cuda hene, ku li gelek deveran kar dikin. Em gihîştin vê yekê: her herêmek hevsengên xwe hene. Ev yek hêsantir dike ku meriv li herêman belav bike, li gorî ku barkirina lûtkeyê li ser torê ye. Ger ev têkçûnek di asta hevsengiyek yekane de be, wê hingê ew bi tenê ji karûbarê tê derxistin û ji dns-ê tê derxistin. Ger di komek balansan de pirsgirêkek hebe, wê hingê ew li ser malperên din têne piştguh kirin, û veguheztina di navbera wan de bi heman rêyê pêk tê53, ji ber ku ji ber kurteya TTL-ê, veguheztin di nav herî zêde 2, 3, 5 hûrdem de pêk tê. .
Ya sêyemîn "lê": Çi hîn nehatiye veqetandin? S3, rast. Dema ku me pelên ku em ji bo bikarhêneran di s3 de hilînin bi cih kirin, me ji dil bawer kir ku ew zirxpoş e û ne hewce ye ku li wir tiştek veqetînin. Lê dîrok nîşan dide ku tiştên cuda diqewimin. Bi gelemperî, Amazon S3 wekî karûbarek bingehîn binav dike, ji ber ku Amazon bixwe S3 bikar tîne da ku wêneyên makîneyê, mîhengan, wêneyên AMI, wêneyan hilîne... Û heke s3 têk biçe, wekî ku di van 7 salan de carekê qewimî, heya ku em bikar tînin. bitrix24, ew mîna fanek dişopîne. Bi tevahî tiştên ku derdikevin holê hene - nekaribûna destpêkirina makîneyên virtual, têkçûna api, û hwd.
Û S3 dikare bikeve - ew yek carî çêbû. Ji ber vê yekê, em gihîştin plana jêrîn: çend sal berê li Rûsyayê cîhên hilanîna tiştên gelemperî yên cidî tune bûn, û me li ser vebijarka ku em tiştek ji xwe bikin… Xwezî, me dest bi vî karî nekir, ji ber ku em ê di nav pisporiya ku me tune ye em kolandine, û belkî dê tevlihev bikin. Naha Mail.ru xwedan hilanîna s3-lihevhatî ye, Yandex ew heye, û hejmarek pêşkêşkerên din jî hene. Em di dawiyê de gihîştin vê ramanê ku em dixwazin, yekem, paşvegirtinê, û ya duyemîn jî, şiyana xebata bi kopiyên herêmî re hebe. Ji bo herêma Rûsyayê bi taybetî, em karûbarê Mail.ru Hotbox bikar tînin, ku API bi s3 re hevaheng e. Me ne hewceyî guheztinên mezin ên kodê di hundurê serîlêdanê de bû, û me mekanîzmaya jêrîn çêkir: di s3 de teşqele hene ku çêkirina / jêbirina tiştan çêdike, Amazon karûbarek bi navê Lambda heye - ev destpêkirina kodê ya bê server e. ku dê bi tenê gava ku hin teşqele têne derxistin were darve kirin.
Me ew pir sade kir: heke tetika me bişewite, em kodê dimeşînin ku dê tiştê li hilanîna Mail.ru kopî bike. Ji bo ku bi tevahî kopiyên daneya herêmî dest bi xebatê bikin, em di heman demê de hevdemkirina berevajî hewce ne da ku xerîdarên ku di beşa rûsî de ne karibin bi hilanînê ya ku nêzê wan e bixebitin. Mail nêzîk e ku di hilanîna xwe de destanan biqedîne - dê gengaz be ku di asta binesaziyê de hevdemkirina berevajî pêk were, lê heya niha em vê yekê di asta koda xwe de dikin. Ger em bibînin ku xerîdarek pelek şandiye, wê hingê em di asta kodê de bûyerê di rêzek de bi cih dikin, wê pêvajo dikin û berevajîkirina dubare dikin. Çima xirab e: Ger em bi tiştên xwe yên derveyî berhema xwe re, ango bi hin awayên derve, karekî bikin, em ê vê yekê nehesibînin. Ji ber vê yekê, em li bendê ne ku heya dawiyê, dema ku teşqele di asta hilanînê de xuya bibin, ji ber vê yekê em ji ku derê kodê bi darve dikin jî, tiştê ku ji me re hatî li aliyek din were kopî kirin.
Di asta kodê de, em her du hilanînê ji bo her xerîdar tomar dikin: yek sereke tê hesibandin, ya din wekî paşvekişîn tê hesibandin. Ger her tişt baş be, em bi hilanînê ya ku nêzê me ye re dixebitin: ango xerîdarên me yên ku li Amazonê ne, ew bi S3 re dixebitin, û yên ku li Rûsyayê dixebitin, ew bi Hotbox re dixebitin. Ger ala were kişandin, wê hingê divê failover were girêdan, û em xerîdaran veguherînin depoyek din. Em dikarin vê qutîkê serbixwe ji hêla herêmê ve kontrol bikin û dikarin wan bi paş û paş ve biguherînin. Me hê di pratîkê de ev yek bi kar neaniye, lê me ev mekanîzma peyda kiriye û em difikirin ku rojekê hewcedariya me bi vê veguheztinê hebe û bi kêr were. Jixwe ev yek carek bûye.
Oh, û Amazon reviya...
Vê Nîsanê salvegera destpêka astengkirina Telegram li Rûsyayê ye. Pêşkêşvanê herî bandor ê ku ketiye binê vê Amazon e. Û, mixabin, şirketên rûsî yên ku ji bo tevahiya cîhanê dixebitin bêtir zirarê bûn.
Ger pargîdanî gerdûnî be û Rûsya ji bo wê perçeyek pir piçûk e, 3-5% - baş e, bi rengekî an din, hûn dikarin wan bikin qurban.
Ger ev pargîdaniyek bi tenê rûsî ye - ez pê bawer im ku ew hewce ye ku li herêmî were cîh kirin - baş e, ew ê ji bo bikarhêneran bixwe rehet be, rehet be, û dê xetereyên hindiktir hebin.
Ger ev pargîdaniyek e ku li çaraliyê cîhanê tevdigere û ji Rûsya û cîhek li çaraliyê cîhanê bi qasî hejmarek xerîdar hene? Girêdana beşan girîng e, û divê ew bi rengekî din bi hev re bixebitin.
Di dawiya Adara 2018-an de, Roskomnadzor nameyek ji operatorên herî mezin re şand û diyar kir ku wan plan kiriye ku çend mîlyon IP-yên Amazon-ê asteng bikin da ku ... peyamnêra Zello asteng bikin. Spas ji van heman pêşkêşvanan re - wan bi serfirazî nameyê ji her kesî re vekir, û têgihîştinek hebû ku têkiliya bi Amazon re dibe ku ji hev derbikeve. Roja Înê bû, em bi tirs û xof reviyan cem hevkarên xwe ji servers.ru, bi van gotinan: "Hevalno, ji me re çend server hene ku dê ne li Rûsyayê, ne li Amazonê, lê, mînakî, li cîhek li Amsterdamê bin." ji bo ku em bikaribin bi kêmanî bi rengek VPN-ya xwe û proxy-ya xwe li wir saz bikin ji bo hin xalên dawî yên ku em nikanin bi tu awayî bandorê li wan bikin, mînakî endpontên heman s3 - em nekarin hewl bidin ku karûbarek nû rakin û karûbarek cûda bistînin. ip, em hîn jî hewce ne ku hûn biçin wir. Tenê di nav çend rojan de, me van serveran saz kir, wan rakir û xebitand, û, bi gelemperî, ji bo dema destpêkirina astengkirinê amade kir. Meraq e ku RKN, li xirecirî û panîkê mêze kir, got: "Na, em ê nuha tiştek asteng nekin." (Lê ev tam heya wê gavê ye ku Telegram dest bi astengkirinê kir.) Piştî ku kapasîteyên dorpêçê saz kirin û fêhm kirin ku astengkirin nehatiye danîn, me, lêbelê, me dest bi sererastkirina tevahiyê nekir. Erê, tenê di rewşê de.
Û di sala 2019 de, em hîn jî di şert û mercên astengkirinê de dijîn. Min şeva çûyî nihêrî: Nêzîkî mîlyonek IP-ê têne asteng kirin. Rast e, Amazon hema hema bi tevahî hate rakirin, di lûtkeya xwe de gihîşt 20 mîlyon navnîşanan ... Bi gelemperî, rastî ev e ku dibe ku hevrêzî nebe, hevrêziyek baş be. Nişkê. Dibe ku ew ji ber sedemên teknîkî nemîne - agir, kolp, her tişt. An jî, wekî ku me dît, ne bi tevahî teknîkî ye. Ji ber vê yekê, kesek mezin û mezin, bi AS-ên xwe, belkî dikare vê yekê bi awayên din îdare bike - girêdana rasterast û tiştên din jixwe di asta l2 de ne. Lê di guhertoyek sade, mîna ya me an jî piçûktir de, hûn dikarin, di her rewşê de, di asta serverên ku li cîhek din de hatine hilanîn de zêdebûnek hebe, vpn, proxy pêşwext hatî mîheng kirin, bi şiyana ku zû veavakirinê li wan beşan veguherîne. ku ji bo girêdana we krîtîk in. Ev yek ji carekê zêdetir ji me re bi kêr hat, dema ku astengkirina Amazon di senaryoya herî xirab de dest pê kir, me tenê destûr da seyrûsefera S3 bi wan re, lê hêdî hêdî ev yek hate çareser kirin.
Meriv çawa hildibijêre ... tevahî pêşkêşvanek?
Naha senaryoyek me tune ku heke tevahiya Amazon têkeve. Ji bo Rûsyayê senaryoyeke me ya bi vî rengî heye. Li Rûsyayê, em ji hêla yek pêşkêşker ve hatin mêvandar kirin, ku ji wî me çend malperan hilbijart. Û salek berê em bi pirsgirêkek re rû bi rû man: her çend ev du navendên daneyê bin jî, dibe ku jixwe di asta veavakirina torê ya pêşkêşker de pirsgirêk hebin ku dê hîn jî bandorê li her du navendên daneyê bike. Û dibe ku em li ser herdu malperan nebin. Helbet wisa bû. Me bi dawî bû ku mîmariya hundurîn ji nû ve binirxînin. Ew pir neguheriye, lê ji bo Rûsyayê naha du malper hene, ku ne ji heman pêşkêşkerê, lê ji du yên cûda ne. Ger yek têk neçe, em dikarin derbasî ya din bibin.
Bi hîpotetîk, ji bo Amazon em îhtîmala veqetandinê di asta pêşkêşkerek din de dinirxînin; dibe ku Google, belkî kesek din... Lê heya niha me di pratîkê de dît ku dema ku Amazon di asta yek devera hebûna qezayan de ye, qezayên di asta herêmek tevahî de kêm in. Ji ber vê yekê, me bi teorîkî ramanek heye ku dibe ku em rezervasyonek "Amazon ne Amazon e" bikin, lê di pratîkê de ev hîn ne wusa ye.
Çend gotin li ser otomatê
Ma otomasyon her gav hewce ye? Li vir minasib e ku em bandora Dunning-Kruger bi bîr bînin. Li ser eksena "x" zanîn û ezmûna me ya ku em bi dest dixin, û li ser eksena "y" bawerî bi kirinên me heye. Di destpêkê de em tiştek nizanin û qet ne ewle ne. Dûv re em hinekî dizanin û mega-bawer dibin - ev bi navê "lûtkeya bêaqiliyê" ye, ku ji hêla wêneya "dementia û wêrekiyê" ve baş tê xuyang kirin. Wê demê em hinekî fêr bûne û amade ne ku biçin şer. Dûv re em gav bavêjin ser hin xeletiyên mega-ciddî û xwe di newalek bêhêvîtiyê de dibînin, gava ku em xuya dikin ku tiştek dizanin, lê bi rastî em pir nizanin. Dûv re, her ku em ezmûnê digirin, em bêtir xwebawer dibin.
Mantiqa me di derbarê veguheztinên cihêreng ên otomatîkî yên hin qezayan de ji hêla vê grafikê ve pir xweş tê vegotin. Me dest pê kir - me nizanibû meriv çawa tiştek bike, hema hema hemî kar bi destan hate kirin. Dûv re me fêm kir ku em dikarin otomasyonê bi her tiştî ve girêbidin û, mîna, bi aramî razin. Û ji nişkê ve em li ser mega-rake: pozîtîfek derewîn çêdibe, û em seyrûseferê ber bi paş û paş ve diguherînin dema ku, bi awayek baş, diviya me ev nekira. Di encamê de, dubarekirin têk diçe an tiştek din - ev geliyê bêhêvîtiyê ye. Û paşê em têgihîştina ku divê em bi aqilane nêzîkî her tiştî bibin. Ango, maqûl e ku meriv xwe bispêre otomasyonê, îhtîmala alarmên derewîn peyda dike. Lebê! eger encam wêranker bin, wê demê çêtir e ku mirov dev ji dewreya peywirê ve, ji endezyarên li ser erkê xwe re bihêle, ew ê piştrast bikin û bişopînin ku bi rastî qezayek heye û dê bi destan kiryarên pêwîst pêk bînin...
encamê
Di nav 7 salan de, em ji rastiya ku gava tiştek ket, panîk-panîk bû, em gihîştin vê têgihîştinê ku pirsgirêk tune ne, tenê peywir hene, divê - û dikarin - werin çareser kirin. Dema ku hûn karûbarek ava dikin, ji jor ve lê binihêrin, hemî xetereyên ku dibe ku bibin binirxînin. Ger hûn tavilê wan bibînin, wê hingê pêşdeçûn û îhtîmala avakirina binesaziyek xelet-tolerant peyda bikin, ji ber ku her xalek ku dikare têk biçe û bibe sedema nexebitîna karûbarê bê guman wiya bike. Û her çend ji we re xuya dike ku hin hêmanên binesaziyê bê guman têk naçin - wek s3, dîsa jî ji bîr mekin ku ew dikarin. Û bi kêmanî di teoriyê de, ramanek heye ku hûn ê bi wan re çi bikin ger tiştek bibe. Plana rêveberiya rîskê hebe. Gava ku hûn difikirin ku her tiştî bixweber an bi destan bikin, xetereyan binirxînin: dê çi bibe ger otomasyon dest bi guheztina her tiştî bike - gelo ev ê li gorî qezayekê rê nede rewşek hîn xirabtir? Dibe ku li cîhek pêdivî ye ku meriv lihevkirinek maqûl di navbera karanîna otomasyonê û reaksiyona endezyarê peywirdar de bikar bîne, yê ku dê wêneya rastîn binirxîne û fêm bike ka tiştek hewce ye ku di cih de were guheztin an "erê, lê ne nuha".
Lihevkirinek maqûl di navbera bêkêmasî û hewildana rastîn, dem, dravê ku hûn dikarin li ser nexşeya ku hûn ê di dawiyê de hebin xerc bikin.
Ev nivîs guhertoyek nûvekirî û berfireh a rapora Alexander Demidov a li konferansê ye .
Source: www.habr.com