Aðgerðirnar sem taldar eru upp hér að neðan eru tiltölulega einfaldar í framkvæmd en hafa mikil áhrif. Ef þú hefur ekki prófað þá áður muntu verða hissa á umtalsverðum framförum.
Innviðir sem kóða
Fyrsti hluti ráðleggingarinnar er að innleiða innviði sem kóða. Þetta þýðir að þú verður að hafa forritalega leið til að dreifa öllu innviði. Það hljómar flókið, en við erum í raun að tala um eftirfarandi kóða:
Uppsetning á 100 sýndarvélum
með Ubuntu
2 GB vinnsluminni hver
þeir munu hafa eftirfarandi kóða
með þessum breytum
Þú getur fylgst með breytingum á innviðum þínum og farið fljótt aftur í þær með útgáfustýringu.
Módernistinn í mér segir að þú getir notað Kubernetes/Docker til að gera allt ofangreint, og það er rétt hjá honum.
Að auki geturðu veitt sjálfvirkni með því að nota Chef, Puppet eða Terraform.
Stöðug samþætting og afhending
Til að búa til stigstærða þjónustu er mikilvægt að hafa smíði og prófunarleiðslu fyrir hverja dráttarbeiðni. Jafnvel þótt prófið sé mjög einfalt, mun það að minnsta kosti tryggja að kóðinn sem þú setur upp safnar saman.
Í hvert skipti á þessu stigi svarar þú spurningunni: mun samkoman mín taka saman og standast próf, er það gilt? Þetta kann að virðast vera lágt borð, en það leysir mörg vandamál.
Það er fátt fallegra en að sjá þessa mítla
Fyrir þessa tækni er hægt að meta Github, CircleCI eða Jenkins.
Álagsjafnarar
Þannig að við viljum keyra álagsjafnara til að beina umferð og tryggja jafnt álag á alla hnúta eða þjónustan heldur áfram ef bilun kemur upp:
Álagsjafnari gerir venjulega gott starf við að dreifa umferð. Besta aðferðin er að ofjafna jafnvægi svo að þú sért ekki með eitt einasta bilunarpunkt.
Venjulega eru álagsjafnarar stilltir í skýinu sem þú notar.
RayID, fylgniauðkenni eða UUID fyrir beiðnir
Hefur þú einhvern tíma rekist á villu í forriti með skilaboðum eins og þessum: "Eitthvað fór úrskeiðis. Vistaðu þetta auðkenni og sendu það til stuðningsteymis okkar"?
Einstakt auðkenni, fylgniauðkenni, RayID, eða hvaða afbrigði sem er, er einstakt auðkenni sem gerir þér kleift að fylgjast með beiðni í gegnum líftíma hennar. Þetta gerir þér kleift að fylgjast með allri beiðnislóðinni í annálunum.
Notandinn gerir beiðni til kerfis A, síðan tengir A tengiliður B, sem tengir C, geymir hana í X, og síðan er beiðnin skilað til A
Ef þú myndir fjartengjast sýndarvélum og reyna að rekja beiðnislóðina (og tengja handvirkt hvaða símtöl eru hringd), myndirðu verða brjálaður. Að hafa einstakt auðkenni gerir lífið miklu auðveldara. Þetta er eitt það einfaldasta sem þú getur gert til að spara tíma þegar þjónustan þín stækkar.
Millistig
Ráðgjöfin hér er flóknari en hin fyrri, en réttu verkfærin gera verkefnið auðveldara og skilar arði af fjárfestingu jafnvel fyrir lítil og meðalstór fyrirtæki.
Miðstýrð skógarhögg
Til hamingju! Þú hefur sett upp 100 sýndarvélar. Daginn eftir kemur forstjórinn og kvartar yfir villu sem hann fékk þegar hann var að prófa þjónustuna. Það greinir frá samsvarandi auðkenni sem við ræddum um hér að ofan, en þú verður að fletta í gegnum annála 100 véla til að finna þá sem olli hruninu. Og það þarf að finna það fyrir kynningu á morgun.
Þó að þetta hljómi eins og skemmtilegt ævintýri, þá er best að ganga úr skugga um að þú hafir getu til að leita í öllum tímaritum á einum stað. Ég leysti vandamálið við að miðstýra annálum með því að nota innbyggða virkni ELK stafla: hann styður leitarhæfan annálasöfnun. Þetta mun virkilega hjálpa til við að leysa vandamálið við að finna ákveðna dagbók. Sem bónus geturðu búið til töflur og annað slíkt skemmtilegt.
ELK stafla virkni
Eftirlitsaðilar
Nú þegar þjónustan þín er komin í gang þarftu að ganga úr skugga um að hún gangi vel. Besta leiðin til að gera þetta er að keyra nokkra umboðsmenn, sem vinna samhliða og athuga hvort það virki og grunnaðgerðir séu gerðar.
Á þessum tímapunkti athugarðu það hlaupabyggingin líður vel og virkar vel.
Fyrir lítil og meðalstór verkefni mæli ég með Postman til að fylgjast með og skjalfesta API. En almennt viltu bara ganga úr skugga um að þú hafir leið til að vita hvenær bilun hefur átt sér stað og fá tilkynningu tímanlega.
Sjálfvirk stærð eftir álagi
Það er mjög einfalt. Ef þú ert með þjónustubeiðnir um VM og hann er að nálgast 80% minnisnotkun geturðu annað hvort aukið tilföng hans eða bætt fleiri VM við þyrpinguna. Sjálfvirk framkvæmd þessara aðgerða er frábær fyrir teygjanlegar aflbreytingar undir álagi. En þú ættir alltaf að gæta þess hversu miklum peningum þú eyðir og setja hæfileg mörk.
Með flestum skýjaþjónustum geturðu stillt hana þannig að hún mælist sjálfvirkt með því að nota fleiri netþjóna eða öflugri netþjóna.
Tilraunakerfi
Góð leið til að útfæra uppfærslur á öruggan hátt er að geta prófað eitthvað fyrir 1% notenda í klukkutíma. Þú hefur auðvitað séð slíkar aðferðir í gangi. Til dæmis sýnir Facebook hluta áhorfenda annan lit eða breytir leturstærð til að sjá hvernig notendur skynja breytingarnar. Þetta er kallað A/B próf.
Jafnvel að gefa út nýjan eiginleika er hægt að hefja sem tilraun og síðan ákvarða hvernig eigi að gefa hann út. Þú færð líka möguleika á að „muna“ eða breyta stillingum á flugu út frá aðgerðinni sem veldur niðurbroti í þjónustunni þinni.
Háþróaður stigi
Hér eru ábendingar sem eru frekar erfiðar í framkvæmd. Þú þarft líklega aðeins meira fjármagn, svo lítið eða meðalstórt fyrirtæki mun eiga erfitt með að stjórna þessu.
Blágrænar dreifingar
Þetta er það sem ég kalla "Erlang" leiðina til að þróast. Erlang varð mikið notaður þegar símafyrirtæki komu fram. Farið var að nota mjúkrofa til að beina símtölum. Megintilgangur hugbúnaðarins á þessum rofum var að sleppa ekki símtölum meðan á kerfisuppfærslu stendur. Erlang hefur góða leið til að hlaða nýrri einingu án þess að hrynja þá fyrri.
Þetta skref fer eftir tilvist álagsjafnara. Við skulum ímynda okkur að þú sért með útgáfu N af hugbúnaðinum þínum og þá viltu nota útgáfu N+1.
Þú við gætum hættu bara þjónustunni og settu út næstu útgáfu á þeim tíma sem hentar notendum þínum og fáðu smá niður í miðbæ. En segjum að þú hafir það virkilega ströng SLA skilyrði. Svo, SLA 99,99% þýðir að þú getur farið án nettengingar aðeins um 52 mínútur á ári.
Ef þú vilt virkilega ná slíkum vísbendingum þarftu tvær dreifingar á sama tíma:
sá sem er núna (N);
næsta útgáfa (N+1).
Þú segir álagsjafnaranum að beina hlutfalli af umferð yfir í nýju útgáfuna (N+1) á meðan þú fylgist virkan með aðhvarfinu.
Hér höfum við græna N dreifingu sem virkar fínt. Við erum að reyna að fara í næstu útgáfu af þessari uppsetningu
Fyrst sendum við mjög lítið próf til að sjá hvort N+1 dreifingin okkar virkar með lítilli umferð:
Að lokum höfum við sett af sjálfvirkum athugunum sem við keyrum að lokum þar til uppsetningu okkar er lokið. Ef þú mjög mjög varkár, þú getur líka vistað N dreifinguna þína að eilífu til að skjóta afturköllun ef slæmt afturför:
Ef þú vilt fara á enn lengra stig, láttu allt í blágrænu dreifingunni keyra sjálfkrafa.
Fráviksuppgötvun og sjálfvirk mildun
Í ljósi þess að þú ert með miðlæga skógarhögg og góða annálasöfnun geturðu nú þegar sett þér hærri markmið. Til dæmis, spáðu fyrir um mistök. Aðgerðir eru raktar á skjáum og í annálum og ýmsar skýringarmyndir eru smíðaðar - og þú getur spáð fyrir um hvað mun fara úrskeiðis:
Þegar frávik hafa fundist byrjarðu að skoða nokkrar vísbendingar sem þjónustan veitir. Til dæmis getur aukning í CPU-álagi bent til þess að harður diskur sé bilaður, en aukning í beiðnum gæti bent til þess að þú þurfir að stækka. Svona tölfræðileg gögn gera þér kleift að gera þjónustuna fyrirbyggjandi.
Með þessari innsýn geturðu stækkað í hvaða vídd sem er og breytt eiginleikum véla, gagnagrunna, tenginga og annarra auðlinda með fyrirbyggjandi og viðbragðslegum hætti.
Það er allt og sumt!
Þessi listi yfir forgangsröðun mun spara þér mörg vandamál ef þú ert að hækka skýjaþjónustu.
Höfundur upprunalegu greinarinnar býður lesendum að skilja eftir athugasemdir sínar og gera breytingar. Greininni er dreift sem opinn uppspretta, beiðnir frá höfundi samþykkir á Github.