Er eftirlit dautt? — Lengi lifi eftirlit

Síðan 2008 hefur fyrirtækið okkar fyrst og fremst stundað innviðastjórnun og tækniaðstoð allan sólarhringinn fyrir vefverkefni: við höfum meira en 400 viðskiptavini, sem er um 15% af rússneskum rafrænum viðskiptum. Samkvæmt því er mjög fjölbreyttur arkitektúr studdur. Ef eitthvað dettur er okkur skylt að laga það innan 15 mínútna. En til að skilja að slys hafi átt sér stað þarf að fylgjast með verkefninu og bregðast við atvikum. Hvernig á að gera þetta?

Ég tel að það sé vandamál að skipuleggja almennilegt eftirlitskerfi. Ef engin vandræði hefðu verið, þá myndi ræða mín samanstanda af einni ritgerð: "Vinsamlegast settu upp Prometheus + Grafana og viðbætur 1, 2, 3." Því miður virkar það ekki þannig lengur. Og aðalvandamálið er að allir halda áfram að trúa á eitthvað sem var til árið 2008, hvað varðar hugbúnaðaríhluti.

Varðandi skipulag eftirlitskerfisins leyfi ég mér að fullyrða að... verkefni með hæfu eftirliti eru ekki til. Og ástandið er svo slæmt að ef eitthvað dettur er hætta á að það fari óséður - þegar allt kemur til alls eru allir vissir um að "allt sé fylgst með."
Kannski er verið að fylgjast með öllu. En hvernig?

Við höfum öll rekist á sögu eins og eftirfarandi: ákveðin devops, ákveðinn stjórnandi er að vinna, þróunarteymi kemur til þeirra og segir - „við erum látin laus, fylgstu með.“ Fylgjast með hverju? Hvernig það virkar?

Allt í lagi. Við fylgjumst með gamla mátanum. Og það er nú þegar að breytast og það kemur í ljós að þú fylgdist með þjónustu A, sem varð þjónusta B, sem hefur samskipti við þjónustu C. En þróunarteymið segir þér: "Settu upp hugbúnaðinn, hann ætti að fylgjast með öllu!"

Svo hvað hefur breyst? - Allt hefur breyst!

2008 Allt er í lagi

Það eru nokkrir forritarar, einn þjónn, einn gagnagrunnsþjónn. Það fer allt héðan. Við höfum smá upplýsingar, við setjum upp zabbix, Nagios, kaktusa. Og svo setjum við skýrar viðvaranir á örgjörva, um rekstur disks og um pláss. Við gerum líka nokkrar handvirkar athuganir til að tryggja að síðan svari og að pantanir berist í gagnagrunninn. Og það er það - við erum meira og minna vernduð.

Ef við berum saman vinnuna sem stjórnandinn vann þá til að veita eftirlit, þá var 98% af því sjálfvirkt: sá sem gerir eftirlitið verður að skilja hvernig á að setja upp Zabbix, hvernig á að stilla það og stilla viðvaranir. Og 2% - fyrir utanaðkomandi athuganir: að vefurinn svari og geri beiðni til gagnagrunnsins, að nýjar pantanir séu komnar.

2010 Álagið fer vaxandi

Við erum að byrja að stækka vefinn, bæta við leitarvél. Við viljum ganga úr skugga um að vörulistinn innihaldi allar vörurnar. Og sú vöruleit virkar. Að gagnagrunnurinn sé að virka, að pantanir séu gerðar, að síðan svari utanaðkomandi og svari frá tveimur netþjónum og notandanum sé ekki sparkað út af síðunni á meðan hann er endurjafnaður á annan netþjón o.s.frv. Það eru fleiri aðilar.

Þar að auki er einingin sem tengist innviðum enn stærst í höfði stjórnandans. Það er samt hugmynd í hausnum á mér að sá sem gerir eftirlitið sé sá sem mun setja upp zabbix og geta stillt það.

En á sama tíma kemur fram vinna við að framkvæma utanaðkomandi athuganir, við að búa til hóp leitarforrita fyrir leitarvísitölu, safn forskrifta til að athuga hvort leitin breytist á meðan á flokkunarferlinu stendur, safn forskrifta sem athuga hvort vörur séu fluttar til sendingarþjónusta o.fl. og svo framvegis.

Athugið: Ég skrifaði „sett af skriftum“ 3 sinnum. Það er að segja að sá sem ber ábyrgð á eftirliti er ekki lengur sá sem einfaldlega setur zabbix upp. Þetta er manneskja sem byrjar að kóða. En ekkert hefur breyst í huga liðsins ennþá.

En heimurinn er að breytast, verður sífellt flóknari. Sýndarvæðingarlagi og nokkrum nýjum kerfum er bætt við. Þeir byrja að hafa samskipti sín á milli. Hver sagði "lyktar eins og örþjónustur?" En hver þjónusta lítur samt út eins og vefsíða fyrir sig. Við getum snúið okkur að því og skilið að það veitir nauðsynlegar upplýsingar og virkar eitt og sér. Og ef þú ert stjórnandi sem tekur stöðugt þátt í verkefni sem hefur verið að þróast í 5-7-10 ár safnast þessi þekking upp: nýtt stig birtist - þú áttaði þig á því, annað stig birtist - þú áttaði þig á því...

En sjaldan fylgir einhver verkefni í 10 ár.

Ferilskrá Monitoringman

Segjum sem svo að þú hafir komið til nýrrar gangsetningar sem réði strax 20 forritara, skrifaði 15 örþjónustur og þú ert stjórnandi sem er sagt: „Byggðu CI/CD. Vinsamlegast." Þú hefur smíðað CI/CD og allt í einu heyrirðu: „Það er erfitt fyrir okkur að vinna með framleiðslu í „kubba“ án þess að skilja hvernig forritið mun virka í því. Gerðu okkur sandkassa í sama "tenningnum".
Þú býrð til sandkassa í þessum teningi. Þeir segja þér strax: „Við viljum sviðsgagnagrunn sem er uppfærður á hverjum degi frá framleiðslu, þannig að við skiljum að hann virki á gagnagrunninum, en á sama tíma spilli ekki framleiðslugagnagrunninum.

Þú lifir í þessu öllu. Það eru 2 vikur eftir af útgáfunni, þeir segja þér: "Nú skulum við fylgjast með þessu öllu..." Það er að segja. fylgjast með klasainnviðum, fylgjast með smáþjónustuarkitektúrnum, fylgjast með vinnu með ytri þjónustu...

Og samstarfsmenn mínir taka venjulegt kerfi út úr hausnum á sér og segja: „Jæja, hér er allt á hreinu! Settu upp forrit sem mun fylgjast með þessu öllu." Já, já: Prometheus + Grafana + viðbætur.
Og þeir bæta við: „Þú hefur tvær vikur, vertu viss um að allt sé öruggt.

Í mörgum verkefnum sem við sjáum er einn maður úthlutað til eftirlits. Ímyndaðu þér að við viljum ráða mann til að sinna eftirliti í 2 vikur og við skrifum ferilskrá fyrir hann. Hvaða hæfileika ætti þessi manneskja að hafa, miðað við allt sem við höfum sagt hingað til?

• Hann verður að skilja eftirlit og sérstöðu í rekstri járninnviða.
• Hann verður að skilja sérkenni þess að fylgjast með Kubernetes (og allir vilja fara í „teninginn“, því þú getur dregið úr öllu, falið þig, því stjórnandinn mun takast á við restina) - sjálfan sig, innviði þess og skilja hvernig á að fylgjast með forritum inni.
• Hann verður að skilja að þjónusta hefur samskipti sín á milli á sérstakan hátt og vita hvernig þjónusta hefur samskipti sín á milli. Það er alveg hægt að sjá verkefni þar sem sumar þjónustur hafa samskipti samstillt, því það er engin önnur leið. Til dæmis fer bakendinn í gegnum REST, í gegnum gRPC í vörulistaþjónustuna, fær vörulista og skilar honum til baka. Þú getur ekki beðið hér. Og með annarri þjónustu virkar það ósamstillt. Flytja pöntunina til afgreiðsluþjónustunnar, senda bréf o.s.frv.
  Þú hefur sennilega þegar synt úr þessu öllu saman? Og stjórnandinn, sem þarf að fylgjast með þessu, varð enn ruglaður.
• Hann verður að geta skipulagt og skipulagt rétt - eftir því sem vinnan verður meira og meira.
• Hann verður því að búa til stefnu úr skapaðri þjónustu til að skilja hvernig á að fylgjast sérstaklega með henni. Hann þarf skilning á arkitektúr verkefnisins og þróun þess + skilning á þeirri tækni sem notuð er við þróun.

Við skulum muna algjörlega eðlilegt tilvik: sumar þjónustur eru í PHP, sumar þjónustur eru í Go, sumar þjónustur eru í JS. Þeir vinna einhvern veginn með hvort öðru. Þaðan kemur hugtakið „örþjónusta“: það eru svo mörg einstök kerfi að verktaki geta ekki skilið verkefnið í heild sinni. Einn hluti teymisins skrifar þjónustu í JS sem virkar á eigin spýtur og veit ekki hvernig restin af kerfinu virkar. Hinn hlutinn skrifar þjónustu í Python og truflar ekki hvernig aðrar þjónustur virka; þær eru einangraðar á sínu eigin svæði. Sá þriðji er að skrifa þjónustu í PHP eða einhverju öðru.
Öllum þessum 20 manns er skipt í 15 þjónustur og það er aðeins einn stjórnandi sem verður að skilja þetta allt. Hættu! við skiptum kerfinu bara í 15 örþjónustur vegna þess að 20 manns geta ekki skilið allt kerfið.

En það þarf einhvern veginn að fylgjast með þessu...

Hver er niðurstaðan? Þar af leiðandi er einn aðili sem kemur með allt sem allt teymið þróunaraðila getur ekki skilið, og á sama tíma verður hann líka að vita og geta gert það sem við bentum á hér að ofan - vélbúnaðarinnviðir, Kubernetes innviðir o.s.frv.

Hvað get ég sagt... Houston, við eigum í vandræðum.

Eftirlit með nútíma hugbúnaðarverkefni er hugbúnaðarverkefni í sjálfu sér

Frá þeirri fölsku trú að vöktun sé hugbúnaður þróum við trú á kraftaverk. En kraftaverk, því miður, gerast ekki. Þú getur ekki sett upp zabbix og búist við að allt virki. Það þýðir ekkert að setja upp Grafana og vona að allt verði í lagi. Mestur tími fer í að skipuleggja athugun á rekstri þjónustu og samspili þeirra innbyrðis, athuga hvernig ytri kerfi virka. Reyndar fer 90% tímans ekki í að skrifa handrit, heldur í að þróa hugbúnað. Og það ætti að vera meðhöndlað af teymi sem skilur vinnu verkefnisins.
Ef í þessu ástandi er einum manni hent í eftirlit, þá mun hörmung gerast. Sem er það sem gerist alls staðar.

Til dæmis eru nokkrar þjónustur sem eiga samskipti sín á milli í gegnum Kafka. Pöntunin barst, við sendum skilaboð um pöntunina til Kafka. Það er þjónusta sem hlustar á upplýsingar um pöntunina og sendir vörurnar. Það er þjónusta sem hlustar á upplýsingar um pöntunina og sendir bréf til notanda. Og svo birtist fullt af fleiri þjónustum og við byrjum að ruglast.

Og ef þú gefur þetta líka til stjórnanda og þróunaraðila á því stigi þegar það er stuttur tími eftir fyrir útgáfu, mun viðkomandi þurfa að skilja alla þessa samskiptareglu. Þeir. Verkefni af þessum mælikvarða tekur talsverðan tíma og það ætti að taka það með í kerfisþróunina.
En mjög oft, sérstaklega í sprotafyrirtækjum, sjáum við hvernig eftirliti er frestað þar til síðar. „Nú munum við búa til Proof of Concept, við munum hefja hana með henni, láta hana falla - við erum tilbúin að fórna. Og svo munum við fylgjast með þessu öllu." Þegar (eða ef) verkefnið byrjar að græða peninga vill fyrirtækið bæta við enn fleiri eiginleikum - vegna þess að það er byrjað að virka, svo það þarf að rúlla því frekar út! Og þú ert á þeim stað þar sem þú þarft fyrst að fylgjast með öllu því sem er á undan, sem tekur ekki 1% af tímanum, heldur miklu meira. Og við the vegur, verktaki þarf til að fylgjast með og það er auðveldara að láta þá vinna að nýjum eiginleikum. Fyrir vikið eru nýir eiginleikar skrifaðir, allt fer í rúst og þú ert í endalausu stoppi.

Svo hvernig á að fylgjast með verkefni sem byrjar frá upphafi og hvað á að gera ef þú færð verkefni sem þarf að fylgjast með en þú veist ekki hvar á að byrja?

Fyrst þarftu að skipuleggja.

Ljóðræn útrás: mjög oft byrja þeir á innviðaeftirliti. Til dæmis höfum við Kubernetes. Byrjum á því að setja upp Prometheus með Grafana, setja upp viðbætur til að fylgjast með „teningnum“. Ekki aðeins forritarar, heldur einnig stjórnendur hafa þá óheppilegu venju að: „Við munum setja upp þessa viðbót, en viðbótin veit líklega hvernig á að gera það. Fólki finnst gott að byrja á einföldu og einföldu frekar en mikilvægum aðgerðum. Og eftirlit með innviðum er auðvelt.

Fyrst skaltu ákveða hvað og hvernig þú vilt fylgjast með, og veldu síðan tæki, vegna þess að annað fólk getur ekki hugsað fyrir þig. Og ættu þeir að gera það? Annað fólk hugsaði með sjálfu sér, um alhliða kerfi - eða hugsaði alls ekki þegar þessi viðbót var skrifuð. Og þó að þetta viðbót hafi 5 þúsund notendur þýðir það ekki að það sé til nokkurs gagns. Kannski verður þú sá 5001 einfaldlega vegna þess að það voru þegar 5000 manns þar áður.

Ef þú byrjar að fylgjast með innviðum og bakendi forritsins þíns hættir að svara, munu allir notendur missa tenginguna við farsímaforritið. Villa mun birtast. Þeir munu koma til þín og segja "Forritið virkar ekki, hvað ertu að gera hér?" - "Við erum að fylgjast með." - "Hvernig fylgist þú með ef þú sérð ekki að forritið virkar ekki?!"

1. Ég tel að þú þurfir að byrja að fylgjast nákvæmlega frá inngangspunkti notandans. Ef notandinn sér ekki að forritið virkar, þá er það það, það er bilun. Og eftirlitskerfið ætti að vara við þessu hið fyrsta.
2. Og aðeins þá getum við fylgst með innviðunum. Eða gerðu það samhliða. Það er auðveldara með innviði - hér getum við loksins sett upp zabbix.
3. Og nú þarftu að fara að rótum forritsins til að skilja hvar hlutirnir virka ekki.

Mín meginhugsun er að eftirlit eigi að fara samhliða þróunarferlinu. Ef þú afvegaleiðir eftirlitsteymið fyrir önnur verkefni (að búa til CI/CD, sandkassa, endurskipulagningu innviða) mun eftirlit byrja að seinka og þú gætir aldrei náð þróuninni (eða fyrr eða síðar verður þú að hætta því).

Allt eftir stigum

Þannig sé ég skipulag eftirlitskerfis.

1) Umsóknarstig:

• eftirlit með viðskiptarökfræði umsókna;
• eftirlit með heilsumælingum þjónustu;
• samþættingareftirlit.

2) Innviðastig:

• eftirlit með hljómsveitarstigi;
• eftirlit með kerfishugbúnaði;
• eftirlit með járnstigi.

3) Aftur umsóknarstigið - en sem verkfræðileg vara:

• safna og fylgjast með forritaskrám;
• APM;
• rekja.

4) Viðvörun:

• skipulag viðvörunarkerfis;
• skipulag vaktkerfis;
• skipulagningu „þekkingargrunns“ og vinnuflæðis fyrir úrvinnslu atvika.

Það er mikilvægt: við komumst að viðvöruninni ekki eftir, heldur strax! Það er engin þörf á að hefja vöktun og „einhvern veginn seinna“ finna út hver mun fá viðvaranir. Þegar öllu er á botninn hvolft, hvert er verkefnið við eftirlit: að skilja hvar í kerfinu eitthvað er að virka vitlaust og láta rétta fólk vita af því. Ef þú skilur þetta eftir til enda, þá mun rétta fólkið vita að eitthvað er að fara úrskeiðis með því að kalla „ekkert virkar fyrir okkur“.

Umsóknarlag - Vöktun viðskiptarökfræði

Hér erum við að tala um að athuga þá staðreynd að forritið virkar fyrir notandann.

Þetta stig ætti að vera gert á þróunarstigi. Til dæmis höfum við skilyrtan Prometheus: hann fer á netþjóninn sem gerir athuganir, dregur endapunktinn og endapunkturinn fer og athugar API.

Þegar þeir eru oft beðnir um að fylgjast með heimasíðunni til að ganga úr skugga um að síðan virki, gefa forritarar handfang sem hægt er að draga í hvert skipti sem þeir þurfa að ganga úr skugga um að API virki. Og forritarar á þessari stundu taka enn og skrifa /api/test/helloworld
Eina leiðin til að tryggja að allt virki? - Nei!

• Að búa til slíkar athuganir er í meginatriðum verkefni þróunaraðila. Einingapróf ættu að vera skrifuð af forriturum sem skrifa kóðann. Vegna þess að ef þú lekur því til stjórnandans, "Guð, hér er listi yfir API samskiptareglur fyrir allar 25 aðgerðir, vinsamlegast fylgstu með öllu!" - ekkert gengur upp.
• Ef þú prentar „halló heimur“ mun enginn vita að API ætti og virkar. Sérhver API breyting verður að leiða til breytinga á ávísunum.
• Ef þú átt nú þegar við slík vandamál að stríða, stöðvaðu eiginleikana og úthlutaðu forriturum sem munu skrifa þessar athuganir, eða samþykkja tapið, samþykkja að ekkert sé athugað og muni mistakast.

Tæknilegar ráðleggingar:

• Vertu viss um að skipuleggja ytri netþjón til að skipuleggja athuganir - þú verður að vera viss um að verkefnið þitt sé aðgengilegt umheiminum.
• Skipuleggja athuganir yfir alla API samskiptareglur, ekki bara einstaka endapunkta.
• Búðu til prometheus-endapunkt með prófunarniðurstöðum.

Umsóknarlag - eftirlit með heilsumælingum

Nú erum við að tala um ytri heilsumælingar þjónustu.

Við ákváðum að fylgjast með öllum „höndum“ umsóknarinnar með ytri eftirliti, sem við köllum frá ytra eftirlitskerfi. En þetta eru „handföngin“ sem notandinn „sér“. Við viljum vera viss um að þjónustan okkar sjálf virki. Hér er sagan betri: K8s er með heilsufarsskoðanir, svo að að minnsta kosti "kubburinn" sjálfur geti verið sannfærður um að þjónustan sé að virka. En helmingur ávísana sem ég hef séð er sama prentið „halló heimur“. Þeir. Svo hann togar einu sinni eftir dreifingu, hann svaraði að allt væri í lagi - það er allt. Og þjónustan, ef hún býður upp á sitt eigið API, hefur gríðarlega marga aðgangspunkta fyrir sama API, sem einnig þarf að fylgjast með, vegna þess að við viljum vita að það virkar. Og við erum nú þegar að fylgjast með því inni.

Hvernig á að innleiða þetta rétt tæknilega: hver þjónusta afhjúpar endapunkt um núverandi frammistöðu sína og í línuritum Grafana (eða annarra forrita) sjáum við stöðu allrar þjónustu.

• Sérhver API breyting verður að leiða til breytinga á ávísunum.
• Búðu til nýja þjónustu strax með heilsumælingum.
• Stjórnandi getur komið til hönnuða og spurt „bættu mér við nokkrum eiginleikum svo að ég skilji allt og bæti upplýsingum um þetta við eftirlitskerfið mitt. En verktaki svara venjulega: „Við munum ekki bæta neinu við tveimur vikum fyrir útgáfu.
  Látið þróunarstjóra vita að slíkt tap verði, látið stjórnendur þróunarstjóra vita líka. Vegna þess að þegar allt fellur mun einhver samt hringja og krefjast þess að fylgjast með „sífellt fallandi þjónustu“ (c)
• Við the vegur, úthlutaðu forriturum til að skrifa viðbætur fyrir Grafana - þetta mun vera góð hjálp fyrir stjórnendur.

Umsóknarlag - Samþættingarvöktun

Samþættingarvöktun beinist að því að fylgjast með samskiptum milli mikilvægra viðskiptakerfa.

Til dæmis eru 15 þjónustur sem hafa samskipti sín á milli. Þetta eru ekki lengur aðskildar síður. Þeir. við getum ekki dregið þjónustuna á eigin spýtur, fengið /helloworld og skilið að þjónustan er í gangi. Vegna þess að pöntunarvefþjónustan þarf að senda upplýsingar um pöntunina í strætó - úr rútunni, verður vöruhúsaþjónustan að taka við þessum skilaboðum og vinna með þau áfram. Og tölvupóstdreifingarþjónustan verður að vinna þetta einhvern veginn frekar o.s.frv.

Í samræmi við það getum við ekki skilið, að pæla í hverri einstakri þjónustu, að þetta virki allt. Vegna þess að við erum með ákveðinn strætó þar sem allt hefur samskipti og samskipti.
Þess vegna ætti þetta stig að marka stig prófunarþjónustu fyrir samskipti við aðra þjónustu. Það er ómögulegt að skipuleggja samskiptavöktun með því að fylgjast með skilaboðamiðlaranum. Ef það er þjónusta sem gefur út gögn og þjónusta sem tekur við þeim, við eftirlit með miðlara munum við aðeins sjá gögn sem fljúga frá hlið til hlið. Jafnvel þótt okkur tækist einhvern veginn að fylgjast með samspili þessara gagna innbyrðis - að ákveðinn framleiðandi birti gögnin, einhver les þau, þetta flæði heldur áfram að fara til Kafka - mun þetta samt ekki gefa okkur upplýsingar ef ein þjónusta sendi skilaboðin í einni útgáfu , en hin þjónustan bjóst ekki við þessari útgáfu og sleppti henni. Við munum ekki vita af þessu, þar sem þjónustan mun segja okkur að allt sé að virka.

Það sem ég mæli með að gera:

• Fyrir samstillt samskipti: endapunkturinn gerir beiðnir til tengdrar þjónustu. Þeir. við tökum þennan endapunkt, drögum handrit inni í þjónustunni, sem fer í alla punktana og segir „Ég get dregið þangað, og dregið þangað, ég get dregið þangað...“
• Fyrir ósamstillt samskipti: skilaboð sem berast - endapunkturinn athugar strætó fyrir prófunarskilaboðum og sýnir vinnslustöðu.
• Fyrir ósamstillt samskipti: send skilaboð - endapunkturinn sendir prufuskilaboð í strætó.

Eins og venjulega: Við erum með þjónustu sem hendir gögnum inn í strætó. Við komum að þessari þjónustu og biðjum þig um að segja okkur frá samþættingarheilbrigði hennar. Og ef þjónustan þarf að framleiða skilaboð einhvers staðar lengra (WebApp), þá mun hún framleiða þessi prófskilaboð. Og ef við keyrum þjónustu á OrderProcessing hliðinni, þá birtir hún fyrst það sem hún getur sent óháð, og ef það eru einhver háð atriði, þá les hún hóp prufuskilaboða úr rútunni, skilur að hún getur unnið úr þeim, tilkynnt það og , ef þörf krefur, póstaðu þeim frekar, og um þetta segir hann - allt er í lagi, ég er á lífi.

Mjög oft heyrum við spurninguna „hvernig getum við prófað þetta á bardagagögnum? Við erum til dæmis að tala um sömu pöntunarþjónustuna. Pöntunin sendir skilaboð til vöruhússins þar sem vörurnar eru afskrifaðar: við getum ekki prófað þetta á bardagagögnum, því „vörur mínar verða afskrifaðar!“ Lausn: Skipuleggðu allt þetta próf í upphafi. Þú ert líka með einingapróf sem gera grín að. Svo gerðu það á dýpri stigi þar sem þú ert með samskiptarás sem skaðar ekki rekstur fyrirtækisins.

Innviðastig

Innviðavöktun er eitthvað sem lengi hefur verið talið sjálft.

• Innviðavöktun getur og ætti að hefja sem sérstakt ferli.
• Þú ættir ekki að byrja með innviðavöktun á gangi verkefni, jafnvel þó þú viljir það virkilega. Þetta er sársauki fyrir alla devops. „Fyrst mun ég fylgjast með klasanum, ég mun fylgjast með innviðunum“ - þ.e. Í fyrsta lagi mun það fylgjast með því sem liggur fyrir neðan, en fer ekki inn í umsóknina. Vegna þess að forritið er óskiljanlegt fyrir devops. Það var lekið til hans og hann skilur ekki hvernig það virkar. Og hann skilur innviðina og byrjar á því. En nei - þú þarft alltaf að fylgjast með forritinu fyrst.
• Ekki fara of langt með fjölda viðvarana. Miðað við margbreytileika nútímakerfa fljúga viðvaranir stöðugt og þú verður einhvern veginn að lifa með þessum fjölda viðvarana. Og vaktmaðurinn, eftir að hafa skoðað hundrað af næstu tilkynningum, mun ákveða „ég vil ekki hugsa um það.“ Viðvaranir ættu aðeins að tilkynna um mikilvæga hluti.

Umsóknarstig sem rekstrareining

Lykil atriði:

• ELK. Þetta er iðnaðarstaðallinn. Ef þú ert ekki af einhverjum ástæðum að safna annálum skaltu byrja að gera það strax.
• APM. Ytri APM sem leið til að loka eftirliti með forritum fljótt (NewRelic, BlackFire, Datadog). Þú getur sett þetta upp tímabundið til að skilja að minnsta kosti einhvern veginn hvað er að gerast hjá þér.
• Rekja. Í tugum örþjónustur þarftu að rekja allt, því beiðnin lifir ekki lengur ein og sér. Það er mjög erfitt að bæta við seinna, svo það er betra að skipuleggja rakningu strax í þróun - þetta er vinna og gagnsemi þróunaraðila. Ef þú hefur ekki innleitt það enn, innleiða það! Sjá Jaeger/Zipkin

Viðvörun

• Skipulag tilkynningakerfis: við aðstæður til að fylgjast með fullt af hlutum ætti að vera sameinað kerfi til að senda tilkynningar. Þú getur í Grafana. Á Vesturlöndum nota allir PagerDuty. Viðvaranir ættu að vera skýrar (td hvaðan þær komu...). Og það er ráðlegt að hafa eftirlit með því að tilkynningar berist yfirleitt
• Skipulag vaktkerfis: viðvaranir ættu ekki að berast til allra (annaðhvort bregðast allir við í hópi eða enginn bregst við). Hönnuðir þurfa líka að vera á vakt: vertu viss um að skilgreina ábyrgðarsvið, gera skýrar leiðbeiningar og skrifa í það hvern nákvæmlega á að hringja á mánudag og miðvikudag og hvern á að hringja á þriðjudag og föstudag (annars hringja þeir ekki í neinn, jafnvel í ef upp koma stór vandamál - þeir munu vera hræddir við að vekja þig eða trufla þig: fólki líkar almennt ekki við að hringja og vekja annað fólk, sérstaklega á nóttunni). Og útskýrðu að það að biðja um hjálp sé ekki vísbending um vanhæfni ("ég bið um hjálp, það þýðir að ég er slæmur starfsmaður"), hvettu til hjálparbeiðna.
• Skipulag „þekkingargrunns“ og vinnuflæðis fyrir úrvinnslu atvika: fyrir hvert alvarlegt atvik ætti að skipuleggja skurðaðgerð og sem tímabundin ráðstöfun ætti að skrá aðgerðir sem leysa atvikið. Og gerðu það að venju að endurteknar viðvaranir séu synd; þau þarf að laga í kóða eða innviðavinnu.

Tæknistafla

Við skulum ímynda okkur að staflan okkar sé sem hér segir:

• gagnasöfnun - Prometheus + Grafana;
• loggreining - ELK;
• fyrir APM eða Tracing - Jaeger (Zipkin).

Val á valkostum er ekki mikilvægt. Vegna þess að ef þú skildir í upphafi hvernig á að fylgjast með kerfinu og skrifaðir niður áætlun, þá byrjar þú að velja verkfæri sem henta þínum þörfum. Spurningin er hvað þú valdir að fylgjast með í fyrsta lagi. Vegna þess að tólið sem þú valdir í upphafi hentar alls ekki þínum þörfum.

Nokkrir tæknilegir punktar sem ég sé alls staðar undanfarið:

Það er verið að troða Prometheus inn í Kubernetes - hver fann upp á þessu?! Ef þyrpingin þín hrynur, hvað gerirðu? Ef þú ert með flókinn klasa inni, þá ætti að vera einhvers konar eftirlitskerfi inni í klasanum og eitthvað utan sem mun safna gögnum innan úr klasanum.

Inni í klasanum söfnum við stokkum og öllu öðru. En eftirlitskerfið verður að vera fyrir utan. Mjög oft, í þyrpingu þar sem Promtheus er uppsett innandyra, eru líka kerfi sem framkvæma utanaðkomandi athuganir á starfsemi síðunnar. Hvað ef tengsl þín við umheiminn hafa rofnað og forritið virkar ekki? Það kemur í ljós að allt er í lagi að innan, en það gerir hlutina ekki auðveldari fyrir notendur.

Niðurstöður

• Eftirlit með þróun er ekki uppsetning veitna heldur þróun hugbúnaðarvöru. 98% af eftirliti í dag er kóðun. Kóðun í þjónustu, kóðun utanaðkomandi athugana, athuga utanaðkomandi þjónustu, og það er allt.
• Ekki eyða tíma þróunaraðila þinna í að fylgjast með: það getur tekið allt að 30% af vinnu þeirra, en það er þess virði.
• Devops, ekki hafa áhyggjur af því að þú getir ekki fylgst með einhverju, því sumt er allt annar hugsunarháttur. Þú varst ekki forritari og eftirlitsvinna er einmitt þeirra starf.
• Ef verkefnið er þegar í gangi og ekki er fylgst með (og þú ert framkvæmdastjóri), úthlutaðu fjármagni til eftirlits.
• Ef varan er þegar í framleiðslu og þú ert devops sem var sagt að "setja upp eftirlit" - reyndu að útskýra fyrir stjórnendum hvað ég skrifaði allt þetta um.

Þetta er útbreidd útgáfa af skýrslunni á Saint Highload++ ráðstefnunni.

Ef þú hefur áhuga á hugmyndum mínum og hugsunum um það og tengd efni, þá getur þú það hér lestu rásina 🙂

Heimild: www.habr.com