Yn yr haf, mae gweithgarwch prynu a dwyster y newidiadau yn seilwaith prosiectau gwe yn draddodiadol yn lleihau, meddai Capten Amlwg wrthym. Yn syml oherwydd bod hyd yn oed arbenigwyr TG weithiau'n mynd ar wyliau. A GTG hefyd. Mae’n anoddach fyth i’r rhai sy’n parhau yn eu swyddi, ond nid dyna’r pwynt nawr: efallai mai dyna pam mai’r haf yw’r cyfnod gorau i feddwl yn araf am y cynllun cadw presennol a llunio cynllun i’w wella. A phrofiad Yegor Andreev o , y soniodd am dano yn y gynnadledd .
Mae yna nifer o beryglon y gallwch chi syrthio iddynt wrth adeiladu safleoedd wrth gefn. Ac mae'n gwbl amhosibl cael eich dal ynddynt. A'r hyn sy'n ein difetha yn hyn oll, fel mewn llawer o bethau eraill, yw perffeithrwydd a... diogi. Rydyn ni'n ceisio gwneud popeth, popeth, popeth yn berffaith, ond nid oes angen i ni ei wneud yn berffaith! Dim ond rhai pethau sydd angen i chi eu gwneud, ond eu gwneud yn gywir, eu cwblhau fel eu bod yn gweithio'n iawn.
Nid rhyw fath o beth hwyliog, hwyliog yw methiant; mae hwn yn beth ddylai wneud yn union un peth - lleihau amser segur fel bod y gwasanaeth, y cwmni, yn colli llai o arian. Ac ym mhob dull cadw, rwy'n awgrymu meddwl yn y cyd-destun canlynol: ble mae'r arian?
Trap cyntaf: pan fyddwn yn adeiladu systemau mawr, dibynadwy ac yn cymryd rhan mewn diswyddiadau, rydym yn lleihau nifer y damweiniau. Mae hyn yn gamsyniad ofnadwy. Pan fyddwn yn colli swyddi, rydym yn debygol o gynyddu nifer y damweiniau. Ac os gwnawn bopeth yn iawn, yna gyda'n gilydd byddwn yn lleihau amser segur. Bydd mwy o ddamweiniau, ond byddant yn digwydd ar gostau is. Beth yw archeb? - mae hyn yn gymhlethdod y system. Mae unrhyw gymhlethdod yn ddrwg: mae gennym ni fwy o gogiau, mwy o gerau, mewn gair, mwy o elfennau - ac, felly, siawns uwch o chwalu. Ac fe fyddan nhw wir yn torri. A byddant yn torri'n amlach. Enghraifft syml: gadewch i ni ddweud bod gennym wefan gyda PHP a MySQL. Ac mae angen ei gadw ar frys.
Shtosh (c) Rydyn ni'n cymryd yr ail safle, yn adeiladu system union yr un fath... Mae'r cymhlethdod yn dod yn ddwywaith cymaint - mae gennym ni ddau endid. Rydym hefyd yn cyflwyno rhesymeg benodol ar gyfer trosglwyddo data o un safle i'r llall - hynny yw, atgynhyrchu data, copïo data sefydlog, ac ati. Felly, mae'r rhesymeg atgynhyrchu fel arfer yn gymhleth iawn, ac felly, ni all cyfanswm cymhlethdod y system fod yn 2, ond yn 3, 5, 10 gwaith yn fwy.
Ail fagl: pan fyddwn yn adeiladu systemau cymhleth gwirioneddol fawr, rydym yn ffantasïo am yr hyn yr ydym am ei gael yn y diwedd. Voila: rydym am gael system hynod ddibynadwy sy'n gweithio heb unrhyw amser segur, yn newid hanner eiliad (neu'n well eto, ar unwaith), ac rydym yn dechrau gwireddu breuddwydion. Ond mae naws yma hefyd: po fyrraf yw'r amser newid a ddymunir, y mwyaf cymhleth y daw rhesymeg y system. Po fwyaf cymhleth sydd gennym i wneud y rhesymeg hon, y mwyaf aml y bydd y system yn chwalu. A gallwch yn y pen draw mewn sefyllfa annymunol iawn: rydym yn ceisio gyda'n holl nerth i leihau amser segur, ond mewn gwirionedd rydym yn gwneud popeth yn fwy cymhleth, a phan aiff rhywbeth o'i le, bydd amser segur yn hirach yn y pen draw. Yma rydych chi'n aml yn dal eich hun yn meddwl: wel... byddai'n well peidio â chadw lle. Byddai'n well pe bai'n gweithio ar ei ben ei hun a chydag amser segur dealladwy.
Sut allwch chi frwydro yn erbyn hyn? Mae angen i ni roi'r gorau i ddweud celwydd i'n hunain, rhoi'r gorau i wenu ein hunain ein bod yn mynd i adeiladu llong ofod yma nawr, ond deall yn ddigonol pa mor hir y gall y prosiect orwedd. Ac am yr amser mwyaf hwn, byddwn yn dewis pa ddulliau y byddwn yn eu defnyddio mewn gwirionedd i gynyddu dibynadwyedd ein system.
Mae'n amser ar gyfer “straeon o w”... o fywyd, wrth gwrs.
Enghraifft rhif un
Dychmygwch wefan cerdyn busnes ar gyfer Planhigyn Rholio Pibellau Rhif 1 yn ninas N. Mae'n dweud mewn llythyrau enfawr - PIPE ROLLING PLANT No. 1. Ychydig islaw mae’r slogan: “Ein pibellau ni yw’r pibellau mwyaf crwn yn N.” Ac isod mae rhif ffôn y Prif Swyddog Gweithredol a'i enw. Rydym yn deall bod angen i chi gadw lle - mae hyn yn beth pwysig iawn! Gadewch i ni ddechrau darganfod beth mae'n ei gynnwys. Html-statics - hynny yw, cwpl o luniau lle mae'r rheolwr cyffredinol, mewn gwirionedd, yn trafod rhyw fath o fargen nesaf wrth y bwrdd yn y baddondy gyda'i bartner. Rydyn ni'n dechrau meddwl am amser segur. Mae'n dod i'r meddwl: mae angen i chi orwedd yno am bum munud, dim mwy. Ac yna mae'r cwestiwn yn codi: faint o werthiannau oedd o'r wefan hon yn gyffredinol? Faint - faint? Beth mae "sero" yn ei olygu? Ac mae hynny'n golygu: oherwydd bod y cyffredinol wedi gwneud y pedwar trafodiad y llynedd wrth yr un bwrdd, gyda'r un bobl y maent yn mynd i'r baddondy ac yn eistedd wrth y bwrdd. Ac rydym yn deall, hyd yn oed os yw'r safle'n eistedd am ddiwrnod, na fydd unrhyw beth ofnadwy yn digwydd.
Yn seiliedig ar y wybodaeth ragarweiniol, mae diwrnod i godi'r stori hon. Gadewch i ni ddechrau meddwl am gynllun dileu swyddi. Ac rydym yn dewis y cynllun diswyddo mwyaf delfrydol ar gyfer yr enghraifft hon: nid ydym yn defnyddio dileu swyddi. Gall unrhyw weinyddwr godi'r holl beth hwn mewn hanner awr gyda seibiannau mwg. Gosod gweinydd gwe, ychwanegu ffeiliau - dyna ni. Bydd yn gweithio. Nid oes angen i chi gadw llygad ar unrhyw beth, nid oes angen i chi dalu sylw arbennig i unrhyw beth. Hynny yw, mae’r casgliad o enghraifft rhif un yn eithaf amlwg: nid oes angen cadw gwasanaethau nad oes angen eu cadw.
Enghraifft rhif dau
Blog cwmni: mae pobl sydd wedi'u hyfforddi'n arbennig yn ysgrifennu newyddion yno, fe wnaethom gymryd rhan mewn arddangosfa o'r fath ac o'r fath, ond fe wnaethom ryddhau cynnyrch newydd arall, ac ati. Gadewch i ni ddweud mai PHP safonol yw hwn gyda WordPress, cronfa ddata fach ac ychydig o statig. Wrth gwrs, daw i’r meddwl eto na ddylech o dan unrhyw amgylchiadau orwedd – “dim mwy na phum munud!” Dyna i gyd. Ond gadewch i ni feddwl ymhellach. Beth mae'r blog hwn yn ei wneud? Mae pobl yn dod yno o Yandex, o Google yn seiliedig ar rai ymholiadau, yn organig. Gwych. A oes gan werthiannau unrhyw beth i'w wneud ag ef? Ystwyll: ddim mewn gwirionedd. Mae traffig hysbysebu yn mynd i'r prif safle, sydd ar beiriant gwahanol. Gadewch i ni ddechrau meddwl am gynllun archebu. Mewn ffordd dda, mae angen ei godi mewn cwpl o oriau, a braf fyddai paratoi ar gyfer hyn. Byddai'n rhesymol cymryd peiriant o ganolfan ddata arall, rholio'r amgylchedd arno, hynny yw, gweinydd gwe, PHP, WordPress, MySQL, a'i adael yno. Ar hyn o bryd pan ddeallwn fod popeth wedi'i dorri, mae angen inni wneud dau beth - cyflwyno'r dymp mysql 50 metr, bydd yn hedfan yno mewn munud, ac yn cyflwyno nifer benodol o luniau o'r copi wrth gefn yno. Nid yw hyn hefyd yno ar gyfer Duw yn gwybod pa mor hir. Felly, mewn hanner awr mae'r holl beth yn codi. Dim atgynhyrchu, neu Dduw maddau i mi, yn awtomatig failover. Casgliad: nid oes angen gwneud copi wrth gefn o'r hyn y gallwn ei gyflwyno'n gyflym o gopi wrth gefn.
Enghraifft rhif tri, mwy cymhleth
Siop ar-lein. Mae PhP gyda chalon agored ychydig yn dweaked, mysql gyda sylfaen gadarn. Yn eithaf sefydlog (wedi'r cyfan, mae gan y siop ar-lein ddelweddau HD hardd a'r holl bethau hynny), Redis ar gyfer y sesiwn ac Elasticsearch ar gyfer chwilio. Rydyn ni'n dechrau meddwl am amser segur. Ac yma, wrth gwrs, mae'n amlwg na all siop ar-lein orwedd o gwmpas yn ddi-boen am ddiwrnod. Wedi'r cyfan, po hiraf y gorwedd, y mwyaf o arian y byddwn yn ei golli. Mae'n werth cyflymu. Faint? Rwy'n meddwl os byddwn yn gorwedd i lawr am awr, ni fydd neb yn mynd yn wallgof. Byddwn, byddwn yn colli rhywbeth, ond os byddwn yn dechrau gweithio'n galed, ni fydd ond yn gwaethygu. Rydym yn diffinio cynllun o amser segur a ganiateir fesul awr.
Sut y gellir cadw hyn i gyd? Mae angen car arnoch chi beth bynnag: ychydig iawn yw awr o amser. Mysql: yma mae angen atgynhyrchu eisoes, dyblygu byw, oherwydd mewn awr mae'n debyg na fydd 100 GB yn cael ei ychwanegu at y domen. Ystadegau, lluniau: eto, mewn awr efallai na fydd gan 500 GB amser i'w ychwanegu. Felly, mae'n well copïo'r lluniau ar unwaith. Redis: dyma lle mae pethau'n mynd yn ddiddorol. Yn Redis, mae sesiynau'n cael eu storio - ni allwn ei gymryd a'i gladdu. Oherwydd na fydd hyn yn dda iawn: bydd pob defnyddiwr yn cael ei allgofnodi, bydd eu basgedi'n cael eu gwagio, ac ati. Bydd pobl yn cael eu gorfodi i roi eu henw defnyddiwr a chyfrinair eto, a gall llawer o bobl dorri i ffwrdd a pheidio â chwblhau'r pryniant. Unwaith eto, bydd addasiadau yn gostwng. Ar y llaw arall, mae Redis yn gyfredol yn uniongyrchol, ac mae'n debyg nad oes angen y defnyddwyr olaf sydd wedi mewngofnodi ychwaith. A chyfaddawd da yw cymryd Redis a'i adfer o gopi wrth gefn o ddoe, neu, os gwnewch hynny bob awr, o awr yn ôl. Yn ffodus, mae ei adfer o gopi wrth gefn yn golygu copïo un ffeil. A'r stori fwyaf diddorol yw Elasticsearch. Pwy sydd erioed wedi codi atgynhyrchu MySQL? Pwy sydd erioed wedi codi atgynhyrchu Elasticsearch? Ac i bwy y gweithiodd fel arfer ar ôl? Yr hyn yr wyf yn ei olygu yw ein bod yn gweld endid penodol yn ein system. Mae'n ymddangos i fod yn ddefnyddiol - ond mae'n gymhleth.
Cymhleth yn yr ystyr nad oes gan ein cyd-beirianwyr unrhyw brofiad o weithio ag ef. Neu mae profiad negyddol. Neu rydym yn deall bod hon yn dal i fod yn dechnoleg eithaf newydd gyda naws neu amrwd. Rydyn ni'n meddwl ... Mae damn, elastig hefyd yn iach, mae hefyd yn cymryd amser hir i'w adfer o wrth gefn, beth ddylwn i ei wneud? Rydym yn deall bod elastig yn ein hachos ni yn cael ei ddefnyddio ar gyfer chwilio. Sut mae ein siop ar-lein yn gwerthu? Rydyn ni'n mynd at farchnatwyr ac yn gofyn o ble mae pobl yn dod yn gyffredinol. Maen nhw'n ateb: “Mae 90% o Yandex Market yn dod yn uniongyrchol i'r cerdyn cynnyrch.” A naill ai maen nhw'n ei brynu neu ddim. Felly, mae angen chwilio gan 10% o ddefnyddwyr. Ac mae cadw atgynhyrchu elastig, yn enwedig rhwng gwahanol ganolfannau data mewn gwahanol barthau, yn cynnwys llawer o arlliwiau. Pa allanfa? Rydym yn cymryd elastig o safle neilltuedig ac yn gwneud dim byd ag ef. Os bydd y mater yn llusgo ymlaen, mae'n debyg y byddwn yn ei godi ryw ddydd, ond nid yw hyn yn sicr. Mewn gwirionedd, yr un yw'r casgliad, plws neu finws: nid ydym ni, unwaith eto, yn cadw gwasanaethau nad ydynt yn effeithio ar arian. I gadw'r diagram yn symlach.
Enghraifft rhif pedwar, hyd yn oed yn fwy anodd
Integreiddiwr: gwerthu blodau, galw tacsi, gwerthu nwyddau, yn gyffredinol, unrhyw beth. Peth difrifol sy'n gweithio 24/7 i nifer fawr o ddefnyddwyr. Gyda phentwr diddorol llawn, lle mae seiliau diddorol, datrysiadau, llwyth uchel, ac yn bwysicaf oll, mae'n brifo gorwedd i lawr am fwy na 5 munud. Nid yn unig ac nid cymaint oherwydd na fydd pobl yn prynu, ond oherwydd y bydd pobl yn gweld nad yw'r peth hwn yn gweithio, byddant yn cynhyrfu ac efallai na fyddant yn dod yn ôl o gwbl.
IAWN. Pum munud. Beth ydym ni'n mynd i'w wneud am hyn? Yn yr achos hwn, rydym ni, fel oedolion, yn defnyddio'r holl arian i adeiladu safle wrth gefn go iawn, gan ailadrodd popeth, ac efallai hyd yn oed awtomeiddio newid i'r wefan hon gymaint â phosibl. Ac yn ogystal â hyn, mae angen i chi gofio gwneud un peth pwysig: mewn gwirionedd, ysgrifennwch y rheoliadau newid. Gall y rheoliadau, hyd yn oed os oes gennych bopeth awtomataidd, fod yn syml iawn. O'r gyfres “rhedeg sgript mor ansible”, “cliciwch y fath a blwch gwirio yn llwybr 53” ac yn y blaen - ond mae'n rhaid i hyn fod yn rhyw fath o union restr o gamau gweithredu.
Ac mae popeth yn ymddangos yn glir. Mae newid dyblygu yn dasg ddibwys, neu bydd yn newid ei hun. Daw ailysgrifennu enw parth yn DNS o'r un gyfres. Y drafferth yw pan fydd prosiect o'r fath yn methu, mae panig yn dechrau, a gall hyd yn oed y gweinyddwyr barfog cryfaf fod yn agored iddo. Heb gyfarwyddiadau clir “agorwch y derfynell, dewch yma, mae cyfeiriad ein gweinydd fel hyn o hyd,” mae'n anodd cwrdd â'r terfyn amser o 5 munud a neilltuwyd ar gyfer dadebru. Wel, yn ogystal, pan fyddwn yn defnyddio'r rheoliadau hyn, mae'n hawdd cofnodi rhai newidiadau yn y seilwaith, er enghraifft, a newid y rheoliadau yn unol â hynny.
Wel, os yw'r system archebu yn gymhleth iawn ac ar ryw adeg fe wnaethom gamgymeriad, yna gallwn ddinistrio ein gwefan wrth gefn, ac yn ogystal trowch y data yn bwmpen ar y ddau safle - bydd hyn yn gwbl drist.
Enghraifft rhif pump, craidd caled cyflawn
Gwasanaeth rhyngwladol gyda channoedd o filiynau o ddefnyddwyr ledled y byd. Mae'r holl barthau amser sydd yna, llwyth uchel ar gyflymder uchaf, ni allwch orwedd o gwbl. Munud - a bydd yn drist. Beth i'w wneud? Wrth gefn, eto, yn ôl y rhaglen lawn. Gwnaethom bopeth y soniais amdano yn yr enghraifft flaenorol, ac ychydig mwy. Byd delfrydol, ac mae ein seilwaith yn unol â holl gysyniadau IaaC devops. Hynny yw, mae popeth mewn git, a dim ond pwyso'r botwm rydych chi.
Beth sydd ar goll? Un - ymarferion. Mae'n amhosibl hebddynt. Mae'n ymddangos bod popeth yn berffaith gyda ni, yn gyffredinol mae gennym bopeth dan reolaeth. Rydyn ni'n pwyso'r botwm, mae popeth yn digwydd. Hyd yn oed os yw hyn yn wir - a deallwn nad yw'n digwydd fel hyn - mae ein system yn rhyngweithio â rhai systemau eraill. Er enghraifft, mae hyn yn dns o lwybr 53, storio s3, integreiddio â rhai api. Ni fyddwn yn gallu rhagweld popeth yn yr arbrawf hapfasnachol hwn. A nes i ni dynnu'r switsh mewn gwirionedd, ni fyddwn yn gwybod a fydd yn gweithio ai peidio.
Mae'n debyg mai dyna i gyd. Peidiwch â bod yn ddiog na gorwneud pethau. Ac efallai y bydd uptime gyda chi!
Ffynhonnell: hab.com