Heddiw, nid oes gan wasanaeth Bitrix24 gannoedd o gigabits o draffig, ac nid oes ganddo fflyd enfawr o weinyddion ychwaith (er, wrth gwrs, mae yna dipyn o rai yn bodoli eisoes). Ond i lawer o gleientiaid dyma'r prif offeryn ar gyfer gweithio yn y cwmni; mae'n gymhwysiad busnes-gritigol go iawn. Felly, nid oes unrhyw ffordd i ddisgyn. Beth os digwyddodd y ddamwain, ond bod y gwasanaeth wedi “gwella” mor gyflym fel nad oedd neb wedi sylwi ar unrhyw beth? A sut mae'n bosibl gweithredu methiant drosodd heb golli ansawdd y gwaith a nifer y cleientiaid? Siaradodd Alexander Demidov, cyfarwyddwr gwasanaethau cwmwl Bitrix24, ar gyfer ein blog am sut mae'r system archebu wedi esblygu dros y 7 mlynedd ers bodolaeth y cynnyrch.
“Fe wnaethon ni lansio Bitrix24 fel SaaS 7 mlynedd yn ôl. Mae'n debyg mai'r prif anhawster oedd y canlynol: cyn iddo gael ei lansio'n gyhoeddus fel SaaS, roedd y cynnyrch hwn yn bodoli'n syml ar ffurf datrysiad mewn bocs. Fe wnaeth cleientiaid ei brynu gennym ni, ei gynnal ar eu gweinyddwyr, sefydlu porth corfforaethol - datrysiad cyffredinol ar gyfer cyfathrebu â gweithwyr, storio ffeiliau, rheoli tasgau, CRM, dyna i gyd. Ac erbyn 2012, penderfynasom ein bod am ei lansio fel SaaS, gan ei weinyddu ein hunain, gan sicrhau goddefgarwch a dibynadwyedd namau. Cawsom brofiad ar hyd y ffordd, oherwydd tan hynny, yn syml, nid oedd gennym ni - dim ond gweithgynhyrchwyr meddalwedd oedden ni, nid darparwyr gwasanaethau.
Wrth lansio'r gwasanaeth, roeddem yn deall mai'r peth pwysicaf yw sicrhau goddefgarwch bai, dibynadwyedd ac argaeledd cyson y gwasanaeth, oherwydd os oes gennych wefan gyffredin syml, siop, er enghraifft, ac mae'n disgyn arnoch chi ac yn eistedd yno am awr , dim ond eich bod yn dioddef , byddwch yn colli archebion , byddwch yn colli cleientiaid , ond ar gyfer eich cleient ei hun , nid yw hyn yn hanfodol iawn iddo . Roedd wedi cynhyrfu, wrth gwrs, ond fe aeth a'i brynu ar safle arall. Ac os yw hwn yn gais y mae'r holl waith o fewn y cwmni, cyfathrebu, penderfyniadau yn gysylltiedig ag ef, yna'r peth pwysicaf yw ennill ymddiriedaeth defnyddwyr, hynny yw, peidio â'u siomi a pheidio â chwympo. Oherwydd gall yr holl waith ddod i ben os nad yw rhywbeth y tu mewn yn gweithio.
Bitrix.24 fel SaaS
Fe wnaethom ymgynnull y prototeip cyntaf flwyddyn cyn y lansiad cyhoeddus, yn 2011. Fe wnaethon ni ei ymgynnull mewn tua wythnos, edrych arno, ei droelli - roedd hyd yn oed yn gweithio. Hynny yw, fe allech chi fynd i mewn i'r ffurflen, nodi enw'r porth yno, byddai porth newydd yn agor, a byddai sylfaen defnyddwyr yn cael ei greu. Fe wnaethom edrych arno, asesu'r cynnyrch mewn egwyddor, ei sgrapio, a pharhau i'w fireinio am flwyddyn gyfan. Oherwydd bod gennym ni dasg fawr: nid oeddem am wneud dwy sylfaen cod wahanol, nid oeddem am gefnogi cynnyrch wedi'i becynnu ar wahân, datrysiadau cwmwl ar wahân - roeddem am wneud y cyfan o fewn un cod.
Cymhwysiad gwe nodweddiadol bryd hynny oedd un gweinydd y mae rhywfaint o god PHP yn rhedeg arno, cronfa ddata mysql, caiff ffeiliau eu llwytho i fyny, dogfennau, rhoddir lluniau yn y ffolder uwchlwytho - wel, mae'r cyfan yn gweithio. Ysywaeth, mae'n amhosibl lansio gwasanaeth gwe hanfodol sefydlog gan ddefnyddio hwn. Yno, ni chefnogir storfa ddosbarthedig, ni chefnogir dyblygu cronfa ddata.
Fe wnaethom lunio'r gofynion: dyma'r gallu i gael eu lleoli mewn gwahanol leoliadau, cefnogi dyblygu, ac yn ddelfrydol cael eu lleoli mewn gwahanol ganolfannau data wedi'u dosbarthu'n ddaearyddol. Gwahanwch y rhesymeg cynnyrch ac, mewn gwirionedd, storio data. Gallu graddio'n ddeinamig yn ôl y llwyth, a goddef statigau yn gyfan gwbl. O'r ystyriaethau hyn, mewn gwirionedd, daeth y gofynion ar gyfer y cynnyrch i'r amlwg, y gwnaethom eu mireinio yn ystod y flwyddyn. Yn ystod yr amser hwn, yn y platfform, a drodd allan i fod yn unedig - ar gyfer datrysiadau mewn bocsys, ar gyfer ein gwasanaeth ein hunain - fe wnaethom gefnogi'r pethau hynny yr oedd eu hangen arnom. Cefnogaeth i ddyblygu mysql ar lefel y cynnyrch ei hun: hynny yw, nid yw'r datblygwr sy'n ysgrifennu'r cod yn meddwl sut y bydd ei geisiadau'n cael eu dosbarthu, mae'n defnyddio ein API, ac rydym yn gwybod sut i ddosbarthu'n gywir ysgrifennu a darllen ceisiadau rhwng meistri a chaethweision.
Rydym wedi gwneud cefnogaeth ar lefel y cynnyrch ar gyfer gwahanol storfeydd gwrthrychau cwmwl: storfa google, amazon s3, ynghyd â chefnogaeth ar gyfer pentwr cyflym agored. Felly, roedd hyn yn gyfleus i ni fel gwasanaeth ac i ddatblygwyr sy'n gweithio gyda datrysiad wedi'i becynnu: os ydyn nhw'n defnyddio ein API ar gyfer gwaith yn unig, nid ydyn nhw'n meddwl ble bydd y ffeil yn cael ei chadw yn y pen draw, yn lleol ar y system ffeiliau neu yn y storfa ffeiliau gwrthrych.
O ganlyniad, fe wnaethom benderfynu ar unwaith y byddem yn cadw ar lefel y ganolfan ddata gyfan. Yn 2012, fe wnaethom lansio'n gyfan gwbl ar Amazon AWS oherwydd bod gennym eisoes brofiad gyda'r platfform hwn - cynhaliwyd ein gwefan ein hunain yno. Cawsom ein denu gan y ffaith bod gan Amazon ym mhob rhanbarth sawl parth argaeledd - mewn gwirionedd, (yn eu terminoleg) sawl canolfan ddata sydd fwy neu lai yn annibynnol ar ei gilydd ac yn caniatáu inni gadw ar lefel canolfan ddata gyfan: os bydd yn methu'n sydyn, mae'r cronfeydd data yn cael eu hailadrodd meistr-feistr, mae gweinyddwyr y cais gwe yn cael eu hategu, ac mae'r data sefydlog yn cael ei symud i'r storfa gwrthrych s3. Mae'r llwyth yn gytbwys - bryd hynny gan Amazon elb, ond ychydig yn ddiweddarach daethom at ein balancers llwyth ein hunain, oherwydd roedd angen rhesymeg fwy cymhleth arnom.
Yr hyn yr oeddent ei eisiau yw'r hyn a gawsant ...
Yr holl bethau sylfaenol yr oeddem am eu sicrhau - goddefgarwch nam ar y gweinyddwyr eu hunain, cymwysiadau gwe, cronfeydd data - fe weithiodd popeth yn dda. Y senario symlaf: os bydd un o'n cymwysiadau gwe yn methu, yna mae popeth yn syml - maen nhw'n cael eu diffodd rhag cydbwyso.
Roedd y balancer (yr adeg honno'n benelin Amazon) yn nodi bod peiriannau a oedd allan o drefn yn afiach ac yn diffodd dosbarthiad llwyth arnynt. Gweithiodd autoscaling Amazon: pan dyfodd y llwyth, ychwanegwyd peiriannau newydd at y grŵp awtoscaling, dosbarthwyd y llwyth i beiriannau newydd - roedd popeth yn iawn. Gyda'n balanswyr, mae'r rhesymeg tua'r un peth: os bydd rhywbeth yn digwydd i weinydd y rhaglen, rydyn ni'n tynnu ceisiadau ohono, yn taflu'r peiriannau hyn allan, yn dechrau rhai newydd ac yn parhau i weithio. Mae'r cynllun wedi newid ychydig dros y blynyddoedd, ond mae'n parhau i weithio: mae'n syml, yn ddealladwy, ac nid oes unrhyw anawsterau ag ef.
Rydym yn gweithio ledled y byd, mae uchafbwyntiau llwyth cwsmeriaid yn hollol wahanol, ac, mewn ffordd gyfeillgar, dylem allu cyflawni gwaith gwasanaeth penodol ar unrhyw gydrannau o'n system ar unrhyw adeg - heb i gwsmeriaid sylwi arnynt. Felly, mae gennym gyfle i ddiffodd y gronfa ddata rhag gweithredu, gan ailddosbarthu'r llwyth i ail ganolfan ddata.
Sut mae'r cyfan yn gweithio? — Rydyn ni'n newid traffig i ganolfan ddata weithredol - os oes damwain yn y ganolfan ddata, yna'n llwyr, os mai hwn yw ein gwaith arfaethedig gydag un gronfa ddata, yna rydyn ni'n newid rhan o'r traffig sy'n gwasanaethu'r cleientiaid hyn i ail ganolfan ddata, gan atal dros dro. mae'n atgynhyrchu. Os oes angen peiriannau newydd ar gyfer cymwysiadau gwe oherwydd bod y llwyth ar yr ail ganolfan ddata wedi cynyddu, byddant yn cychwyn yn awtomatig. Rydyn ni'n gorffen y gwaith, mae ailadrodd yn cael ei adfer, ac rydyn ni'n dychwelyd y llwyth cyfan yn ôl. Os oes angen i ni adlewyrchu rhywfaint o waith yn yr ail DC, er enghraifft, gosod diweddariadau system neu newid gosodiadau yn yr ail gronfa ddata, yna, yn gyffredinol, rydym yn ailadrodd yr un peth, dim ond i'r cyfeiriad arall. Ac os yw hyn yn ddamwain, yna rydym yn gwneud popeth yn ddibwys: rydym yn defnyddio'r mecanwaith trin digwyddiadau yn y system fonitro. Os bydd nifer o wiriadau'n cael eu sbarduno a bod y statws yn mynd i gritigol, yna rydyn ni'n rhedeg y triniwr hwn, triniwr a all weithredu hyn neu'r rhesymeg honno. Ar gyfer pob cronfa ddata, rydym yn nodi pa weinydd yw'r methiant ar ei gyfer, a lle mae angen newid traffig os nad yw ar gael. Yn hanesyddol, rydym yn defnyddio nagios neu rai o'i ffyrc mewn rhyw ffurf neu'i gilydd. Mewn egwyddor, mae mecanweithiau tebyg yn bodoli mewn bron unrhyw system fonitro; nid ydym yn defnyddio unrhyw beth mwy cymhleth eto, ond efallai y byddwn yn gwneud hynny ryw ddydd. Nawr mae monitro'n cael ei sbarduno gan ddiffyg argaeledd ac mae ganddo'r gallu i newid rhywbeth.
Ydyn ni wedi cadw popeth?
Mae gennym lawer o gleientiaid o UDA, llawer o gleientiaid o Ewrop, llawer o gleientiaid sy'n agosach at y Dwyrain - Japan, Singapore ac yn y blaen. Wrth gwrs, mae cyfran enfawr o gleientiaid yn Rwsia. Hynny yw, nid yw gwaith mewn un rhanbarth. Mae defnyddwyr eisiau ymateb cyflym, mae gofynion i gydymffurfio â chyfreithiau lleol amrywiol, ac o fewn pob rhanbarth rydym yn cadw dwy ganolfan ddata, ynghyd â rhai gwasanaethau ychwanegol, sydd, unwaith eto, yn gyfleus i'w gosod o fewn un rhanbarth - ar gyfer cleientiaid sydd yn mae'r rhanbarth hwn yn gweithio. Trinwyr REST, gweinyddwyr awdurdodi, maen nhw'n llai hanfodol ar gyfer gweithrediad y cleient yn ei gyfanrwydd, gallwch chi newid trwyddynt gydag oedi derbyniol bach, ond nid ydych chi am ailddyfeisio'r olwyn ar sut i'w monitro a beth i'w wneud gyda nhw. Felly, rydym yn ceisio defnyddio atebion presennol i’r eithaf, yn hytrach na datblygu rhyw fath o gymhwysedd mewn cynhyrchion ychwanegol. Ac yn rhywle rydyn ni'n ddibwys yn defnyddio newid ar lefel DNS, ac rydyn ni'n pennu bywiogrwydd y gwasanaeth gan yr un DNS. Mae gan Amazon wasanaeth Route 53, ond nid DNS yn unig ydyw y gallwch chi wneud cofnodion iddo a dyna ni - mae'n llawer mwy hyblyg a chyfleus. Trwyddo gallwch chi adeiladu gwasanaethau geo-ddosbarthu gyda geolocations, pan fyddwch chi'n ei ddefnyddio i benderfynu o ble y daeth y cleient a rhoi cofnodion penodol iddo - gyda'i help gallwch chi adeiladu pensaernïaeth methu. Mae'r un gwiriadau iechyd wedi'u ffurfweddu yn Llwybr 53 ei hun, rydych chi'n gosod y pwyntiau terfyn sy'n cael eu monitro, yn gosod metrigau, yn gosod pa brotocolau i bennu “bywder” y gwasanaeth - tcp, http, https; gosod amlder y gwiriadau sy'n pennu a yw'r gwasanaeth yn fyw ai peidio. Ac yn y DNS ei hun rydych chi'n nodi beth fydd yn gynradd, beth fydd yn eilaidd, ble i newid os yw'r gwiriad iechyd yn cael ei sbarduno y tu mewn i lwybr 53. Gellir gwneud hyn i gyd gyda rhai offer eraill, ond pam ei fod yn gyfleus - rydym yn ei osod i fyny unwaith ac yna peidiwch â meddwl am y peth o gwbl sut rydym yn cynnal gwiriadau, sut rydym yn newid: mae popeth yn gweithio ar ei ben ei hun.
Y cyntaf "ond": sut a gyda beth i gadw llwybr 53 ei hun? Pwy a wyr, beth os bydd rhywbeth yn digwydd iddo? Yn ffodus, ni wnaethom erioed gamu ar y rhaca hwn, ond eto, bydd gennyf stori o'n blaenau pam yr oeddem yn meddwl bod angen inni gadw lle o hyd. Yma fe wnaethom osod gwellt i ni ein hunain ymlaen llaw. Sawl gwaith y dydd rydym yn dadlwytho'n llwyr yr holl barthau sydd gennym yn llwybr 53. Mae API Amazon yn caniatáu ichi eu hanfon yn JSON yn hawdd, ac mae gennym nifer o weinyddion wrth gefn lle rydyn ni'n ei drosi, yn ei uwchlwytho ar ffurf ffurfweddiadau ac mae gennym ni, yn fras, ffurfwedd wrth gefn. Os bydd rhywbeth yn digwydd, gallwn ei ddefnyddio'n gyflym â llaw heb golli data gosodiadau DNS.
Ail "ond": Beth yn y llun hwn sydd heb ei gadw eto? Y balancer ei hun! Mae ein dosbarthiad o gleientiaid yn ôl rhanbarth yn syml iawn. Mae gennym y parthau bitrix24.ru, bitrix24.com, .de - nawr mae yna 13 o rai gwahanol, sy'n gweithredu mewn amrywiaeth o barthau. Daethom at y canlynol: mae gan bob rhanbarth ei mantolenni ei hun. Mae hyn yn ei gwneud yn fwy cyfleus i'w ddosbarthu ar draws rhanbarthau, yn dibynnu ar leoliad y llwyth brig ar y rhwydwaith. Os yw hyn yn fethiant ar lefel cydbwyseddwr sengl, yna mae'n syml yn cael ei dynnu allan o wasanaeth a'i dynnu o'r dns. Os oes rhywfaint o broblem gyda grŵp o gydbwyswyr, yna maent yn cael eu hategu ar safleoedd eraill, ac mae newid rhyngddynt yn cael ei wneud gan ddefnyddio'r un llwybr53, oherwydd oherwydd y TTL byr, mae newid yn digwydd o fewn uchafswm o 2, 3, 5 munud .
Trydydd "ond": Beth sydd heb ei gadw eto? S3, cywir. Pan wnaethom osod y ffeiliau yr ydym yn eu storio ar gyfer defnyddwyr yn a3, roeddem yn credu'n ddiffuant ei fod yn tyllu arfau ac nad oedd angen cadw unrhyw beth yno. Ond mae hanes yn dangos bod pethau'n digwydd yn wahanol. Yn gyffredinol, mae Amazon yn disgrifio S3 fel gwasanaeth sylfaenol, gan fod Amazon ei hun yn defnyddio S3 i storio delweddau peiriant, cyfluniadau, delweddau AMI, cipluniau... Ac os bydd damweiniau s3, fel y digwyddodd unwaith yn ystod y 7 mlynedd hyn, cyn belled â'n bod wedi bod yn defnyddio bitrix24, mae'n ei ddilyn fel ffan Mae yna griw cyfan o bethau'n codi - anallu i gychwyn peiriannau rhithwir, methiant api, ac ati.
A gall S3 ddisgyn - digwyddodd unwaith. Felly, daethom at y cynllun a ganlyn: ychydig flynyddoedd yn ôl nid oedd unrhyw gyfleusterau storio gwrthrychau cyhoeddus difrifol yn Rwsia, ac fe wnaethom ystyried yr opsiwn o wneud rhywbeth ein hunain... Yn ffodus, ni wnaethom ddechrau gwneud hyn, oherwydd byddem yn gwneud hynny. wedi cloddio i mewn i'r arbenigedd nad oes gennym ni, ac mae'n debyg y byddai'n creu llanast. Nawr mae gan Mail.ru storfa sy'n gydnaws â s3, mae gan Yandex hwnnw, ac mae gan nifer o ddarparwyr eraill. Daethom yn y pen draw at y syniad ein bod am gael, yn gyntaf, wrth gefn, ac yn ail, y gallu i weithio gyda chopïau lleol. Ar gyfer rhanbarth Rwsia yn benodol, rydym yn defnyddio gwasanaeth Hotbox Mail.ru, sef API sy'n gydnaws â s3. Nid oedd angen unrhyw addasiadau mawr i'r cod y tu mewn i'r rhaglen, a gwnaethom y mecanwaith canlynol: yn s3 mae yna sbardunau sy'n sbarduno creu / dileu gwrthrychau, mae gan Amazon wasanaeth o'r enw Lambda - mae hwn yn lansiad cod heb weinydd. a fydd yn cael ei weithredu dim ond pan fydd sbardunau penodol yn cael eu sbarduno.
Fe wnaethom ni yn syml iawn: os yw ein sbardun yn tanio, rydyn ni'n gweithredu cod a fydd yn copïo'r gwrthrych i storfa Mail.ru. Er mwyn lansio gwaith yn llawn gyda chopïau lleol o ddata, mae angen cydamseru gwrthdro arnom hefyd fel y gall cleientiaid sydd yn y segment Rwsia weithio gyda storfa sy'n agosach atynt. Mae post ar fin cwblhau sbardunau yn ei storio - bydd yn bosibl perfformio cydamseriad gwrthdro ar lefel seilwaith, ond am y tro rydym yn gwneud hyn ar lefel ein cod ein hunain. Os gwelwn fod cleient wedi postio ffeil, yna ar lefel y cod rydym yn gosod y digwyddiad mewn ciw, yn ei brosesu ac yn ei ddyblygu o chwith. Pam ei fod yn ddrwg: os ydym yn gwneud rhyw fath o waith gyda'n gwrthrychau y tu allan i'n cynnyrch, hynny yw, trwy ryw ddulliau allanol, ni fyddwn yn ei gymryd i ystyriaeth. Felly, rydym yn aros tan y diwedd, pan fydd sbardunau'n ymddangos ar y lefel storio, fel na fydd y gwrthrych a ddaeth atom yn cael ei gopïo i'r cyfeiriad arall ni waeth o ble rydyn ni'n gweithredu'r cod.
Ar lefel y cod, rydym yn cofrestru'r ddau storfa ar gyfer pob cleient: mae un yn cael ei ystyried yn brif un, mae'r llall yn cael ei ystyried yn un wrth gefn. Os yw popeth yn iawn, rydyn ni'n gweithio gyda'r storfa sy'n agosach atom ni: hynny yw, ein cleientiaid sydd yn Amazon, maen nhw'n gweithio gyda S3, a'r rhai sy'n gweithio yn Rwsia, maen nhw'n gweithio gyda Hotbox. Os caiff y faner ei sbarduno, yna dylid cysylltu failover, ac rydym yn newid cleientiaid i storfa arall. Gallwn wirio'r blwch hwn yn annibynnol fesul rhanbarth a gallwn eu newid yn ôl ac ymlaen. Nid ydym wedi defnyddio hyn yn ymarferol eto, ond rydym wedi darparu ar gyfer y mecanwaith hwn ac rydym yn meddwl y bydd angen yr union newid hwn arnom ryw ddydd a dod yn ddefnyddiol. Mae hyn wedi digwydd unwaith yn barod.
O, a rhedodd Amazon i ffwrdd ...
Mae'r mis Ebrill hwn yn nodi pen-blwydd dechrau blocio Telegram yn Rwsia. Y darparwr yr effeithiwyd arno fwyaf a ddaeth o dan hyn yw Amazon. Ac, yn anffodus, roedd cwmnïau Rwsiaidd a oedd yn gweithio i'r byd i gyd yn dioddef mwy.
Os yw'r cwmni'n fyd-eang ac mae Rwsia yn segment bach iawn ar ei gyfer, 3-5% - wel, un ffordd neu'r llall, gallwch chi eu haberthu.
Os yw hwn yn gwmni Rwsia yn unig - rwy'n siŵr bod angen ei leoli'n lleol - wel, yn syml bydd yn gyfleus i'r defnyddwyr eu hunain, yn gyfforddus, a bydd llai o risgiau.
Beth os yw hwn yn gwmni sy'n gweithredu'n fyd-eang ac sydd â niferoedd cyfartal o gleientiaid o Rwsia a rhywle ledled y byd? Mae cysylltedd y segmentau yn bwysig, a rhaid iddynt weithio gyda'i gilydd un ffordd neu'r llall.
Ar ddiwedd mis Mawrth 2018, anfonodd Roskomnadzor lythyr at y gweithredwyr mwyaf yn nodi eu bod yn bwriadu rhwystro sawl miliwn o IPs Amazon er mwyn rhwystro ... negesydd Zello. Diolch i'r un darparwyr hyn - fe wnaethant ollwng y llythyr yn llwyddiannus i bawb, ac roedd dealltwriaeth y gallai'r cysylltiad ag Amazon ddisgyn ar wahân. Roedd hi'n ddydd Gwener, fe wnaethon ni redeg mewn panig at ein cydweithwyr o servers.ru, gan ddweud: “Ffrindiau, mae angen sawl gweinydd arnom a fydd wedi'u lleoli nid yn Rwsia, nid yn Amazon, ond, er enghraifft, rhywle yn Amsterdam,” mewn trefn er mwyn gallu gosod ein VPN a'n dirprwy ein hunain o leiaf rywsut ar gyfer rhai pwyntiau terfyn na allwn ddylanwadu arnynt mewn unrhyw ffordd, er enghraifft endponts o'r un s3 - ni allwn geisio codi gwasanaeth newydd a chael ip gwahanol, mae angen i chi gyrraedd yno o hyd. Mewn ychydig ddyddiau yn unig, fe wnaethom sefydlu'r gweinyddwyr hyn, eu rhoi ar waith, ac, yn gyffredinol, paratoi ar gyfer y funud y dechreuodd y blocio. Mae’n chwilfrydig bod RKN, wrth edrych ar y ffwdan a’r panig, wedi dweud: “Na, ni fyddwn yn rhwystro unrhyw beth nawr.” (Ond mae hyn yn union tan yr eiliad y dechreuodd Telegram gael ei rwystro.) Ar ôl sefydlu'r galluoedd ffordd osgoi a sylweddoli nad oedd y blocio wedi'i gyflwyno, fodd bynnag, ni wnaethom ddechrau datrys y mater cyfan. Ie, rhag ofn.
Ac yn 2019, rydym yn dal i fyw mewn amodau blocio. Edrychais neithiwr: mae tua miliwn o IPs yn parhau i gael eu rhwystro. Yn wir, roedd Amazon bron yn gyfan gwbl heb ei rwystro, ar ei anterth cyrhaeddodd 20 miliwn o gyfeiriadau... Yn gyffredinol, y gwir amdani yw efallai nad oes cydlyniad, cydlyniad da. Yn sydyn. Efallai nad yw'n bodoli am resymau technegol - tanau, cloddwyr, hynny i gyd. Neu, fel y gwelsom, nid yn gwbl dechnegol. Felly, mae'n debyg y gall rhywun mawr a mawr, gyda'u ASau eu hunain, reoli hyn mewn ffyrdd eraill - mae cysylltiad uniongyrchol a phethau eraill eisoes ar lefel l2. Ond mewn fersiwn syml, fel ein un ni neu hyd yn oed yn llai, gallwch, rhag ofn, gael diswyddiad ar lefel y gweinyddwyr a godwyd yn rhywle arall, wedi'u ffurfweddu ymlaen llaw vpn, dirprwy, gyda'r gallu i newid y ffurfweddiad iddynt yn gyflym yn y segmentau hynny sy'n hanfodol ar gyfer eich cysylltedd. Daeth hyn yn ddefnyddiol i ni fwy nag unwaith, pan ddechreuodd blocio Amazon; yn y senario waethaf, dim ond traffig S3 a ganiatawyd trwyddynt, ond yn raddol, cafodd hyn i gyd ei ddatrys.
Sut i gadw... darparwr cyfan?
Ar hyn o bryd nid oes gennym senario rhag ofn i'r Amazon gyfan fynd i lawr. Mae gennym senario tebyg ar gyfer Rwsia. Yn Rwsia, cawsom ein cynnal gan un darparwr, y gwnaethom ddewis cael sawl gwefan ganddo. A blwyddyn yn ôl roeddem yn wynebu problem: er bod y rhain yn ddwy ganolfan ddata, efallai y bydd problemau eisoes ar lefel cyfluniad rhwydwaith y darparwr a fydd yn dal i effeithio ar y ddwy ganolfan ddata. Ac efallai na fyddwn ar gael ar y ddau safle yn y pen draw. Wrth gwrs dyna beth ddigwyddodd. Yn y diwedd fe wnaethom ailystyried y bensaernïaeth y tu mewn. Nid yw wedi newid llawer, ond ar gyfer Rwsia mae gennym bellach ddau wefan, nad ydynt gan yr un darparwr, ond gan ddau wahanol. Os bydd un yn methu, gallwn newid i'r llall.
Yn ddamcaniaethol, ar gyfer Amazon rydym yn ystyried y posibilrwydd o gadw lle ar lefel darparwr arall; efallai Google, efallai rhywun arall... Ond hyd yn hyn rydym wedi arsylwi'n ymarferol, er bod gan Amazon ddamweiniau ar lefel un parth argaeledd, mae damweiniau ar lefel rhanbarth cyfan yn eithaf prin. Felly, yn ddamcaniaethol mae gennym y syniad y gallem wneud archeb “Nid Amazon yw Amazon”, ond yn ymarferol nid yw hyn yn wir eto.
Ychydig eiriau am awtomeiddio
A yw awtomeiddio bob amser yn angenrheidiol? Yma mae'n briodol cofio effaith Dunning-Kruger. Ar yr echelin “x” mae ein gwybodaeth a'n profiad rydyn ni'n eu hennill, ac ar echel “y” mae hyder yn ein gweithredoedd. Ar y dechrau, nid ydym yn gwybod dim ac nid ydym yn siŵr o gwbl. Yna rydyn ni'n gwybod ychydig ac yn dod yn fega-hyderus - dyma'r hyn a elwir yn “uchafbwynt hurtrwydd”, wedi'i ddarlunio'n dda gan y llun “dementia a dewrder”. Yna rydym wedi dysgu ychydig ac yn barod i fynd i frwydr. Yna rydyn ni'n camu ar rai camgymeriadau difrifol ac yn cael ein hunain mewn dyffryn o anobaith, pan rydyn ni'n ymddangos yn gwybod rhywbeth, ond mewn gwirionedd nid ydym yn gwybod llawer. Yna, wrth i ni ennill profiad, rydyn ni'n dod yn fwy hyderus.
Disgrifir ein rhesymeg am amrywiol switshis awtomatig i rai damweiniau yn dda iawn yn y graff hwn. Dechreuon ni - doedden ni ddim yn gwybod sut i wneud dim byd, roedd bron y cyfan o'r gwaith yn cael ei wneud â llaw. Yna sylweddolom y gallem gysylltu awtomeiddio â phopeth ac, fel, cysgu'n dawel. Ac yn sydyn rydyn ni'n camu ar grac mawr: mae positif ffug yn cael ei sbarduno, ac rydyn ni'n newid traffig yn ôl ac ymlaen pan, mewn ffordd dda, ni ddylem fod wedi gwneud hyn. O ganlyniad, mae atgynhyrchu yn chwalu neu rywbeth arall—dyma union ddyffryn anobaith. Ac yna rydyn ni'n dod i'r ddealltwriaeth bod yn rhaid inni fynd at bopeth yn ddoeth. Hynny yw, mae'n gwneud synnwyr dibynnu ar awtomeiddio, gan ddarparu ar gyfer y posibilrwydd o alwadau diangen. Ond! os gall y canlyniadau fod yn ddinistriol, yna mae'n well ei adael i'r shifft ddyletswydd, i'r peirianwyr ar ddyletswydd, a fydd yn sicrhau ac yn monitro bod damwain mewn gwirionedd, ac yn cyflawni'r camau angenrheidiol â llaw ...
Casgliad
Dros gyfnod o 7 mlynedd, aethom o'r ffaith, pan syrthiodd rhywbeth, bod panig-panig, i'r ddealltwriaeth nad yw problemau'n bodoli, mai dim ond tasgau sydd, mae'n rhaid - ac y gellir - eu datrys. Pan fyddwch yn adeiladu gwasanaeth, edrychwch arno oddi uchod, aseswch yr holl risgiau a all ddigwydd. Os byddwch yn eu gweld ar unwaith, yna darparwch ar gyfer diswyddo ymlaen llaw a’r posibilrwydd o adeiladu seilwaith sy’n gallu goddef diffygion, oherwydd bydd unrhyw bwynt a all fethu ac arwain at anweithredu’r gwasanaeth yn bendant yn gwneud hynny. A hyd yn oed os yw'n ymddangos i chi na fydd rhai elfennau o'r seilwaith yn bendant yn methu - fel yr un s3, cofiwch y gallant. Ac o leiaf mewn theori, cael syniad o beth fyddwch chi'n ei wneud gyda nhw os bydd rhywbeth yn digwydd. Bod â chynllun rheoli risg. Pan fyddwch chi'n ystyried gwneud popeth yn awtomatig neu â llaw, aseswch y risgiau: beth fydd yn digwydd os bydd yr awtomeiddio yn dechrau newid popeth - oni fydd hyn yn arwain at sefyllfa waeth byth o'i gymharu â damwain? Efallai yn rhywle bod angen defnyddio cyfaddawd rhesymol rhwng y defnydd o awtomeiddio ac ymateb y peiriannydd ar ddyletswydd, a fydd yn gwerthuso'r darlun go iawn ac yn deall a oes angen troi rhywbeth yn y fan a'r lle neu "ie, ond nid nawr."
Cyfaddawd rhesymol rhwng perffeithrwydd ac ymdrech wirioneddol, amser, arian y gallwch ei wario ar y cynllun a fydd gennych yn y pen draw.
Mae'r testun hwn yn fersiwn wedi'i ddiweddaru a'i ehangu o adroddiad Alexander Demidov yn y gynhadledd .
Ffynhonnell: hab.com