Helo, Habr! Rwyf wedi bod yn cefnogi systemau TG Highload ers deng mlynedd. Ni fyddaf yn ysgrifennu yn yr erthygl hon am y problemau o sefydlu nginx i weithio yn y modd 1000 + RPS neu bethau technegol eraill. Byddaf yn rhannu fy sylwadau am y problemau yn y prosesau sy'n codi wrth gefnogi a gweithredu systemau o'r fath.
Monitro
Nid yw cymorth technegol yn aros nes bod cais yn cyrraedd gyda'r cynnwys “Beth Pam... nad yw'r wefan yn gweithio eto?” O fewn munud ar ôl i'r safle ddamweiniau, dylai cefnogaeth eisoes weld y broblem a dechrau ei datrys. Ond y safle yw blaen y mynydd iâ. Ei argaeledd yw un o'r rhai cyntaf i gael ei fonitro.
Beth i'w wneud â'r sefyllfa pan nad yw'r nwyddau sy'n weddill o siop ar-lein bellach yn cyrraedd o'r system ERP? Neu a yw'r system CRM sy'n cyfrifo gostyngiadau i gleientiaid wedi rhoi'r gorau i ymateb? Mae'n ymddangos bod y safle'n gweithio. Mae Conditional Zabbix yn derbyn ei ymateb 200. Nid yw'r shifft ddyletswydd wedi derbyn unrhyw hysbysiadau o'r monitro ac mae'n hapus i wylio pennod gyntaf y tymor newydd o Game of Thrones.
Mae monitro yn aml yn gyfyngedig i fesur cyflwr cof, RAM a llwyth prosesydd gweinydd yn unig. Ond i fusnes mae'n llawer pwysicach sicrhau bod cynnyrch ar gael ar y wefan. Bydd methiant amodol un peiriant rhithwir yn y clwstwr yn arwain at y ffaith y bydd traffig yn stopio mynd iddo a bydd y llwyth ar weinyddion eraill yn cynyddu. Ni fydd y cwmni'n colli arian.
Felly, yn ogystal â monitro paramedrau technegol systemau gweithredu ar weinyddion, mae angen i chi ffurfweddu metrigau busnes. Metrigau sy'n effeithio'n uniongyrchol ar arian. Rhyngweithio amrywiol gyda systemau allanol (CRM, ERP ac eraill). Nifer y gorchmynion am gyfnod penodol o amser. Awdurdodiadau cleient llwyddiannus neu aflwyddiannus a metrigau eraill.
Rhyngweithio â systemau allanol
Mae unrhyw wefan neu raglen symudol gyda throsiant blynyddol o fwy na biliwn rubles yn rhyngweithio â systemau allanol. Gan ddechrau o'r CRM ac ERP uchod a gorffen gyda throsglwyddo data gwerthu i system Data Mawr allanol ar gyfer dadansoddi pryniannau a chynnig cynnyrch i'r cleient y bydd yn bendant yn ei brynu (mewn gwirionedd, nid). Mae gan bob system o'r fath ei chefnogaeth ei hun. Ac yn aml mae cyfathrebu â'r systemau hyn yn achosi poen. Yn enwedig pan fo'r broblem yn un fyd-eang a bod angen i chi ei dadansoddi mewn gwahanol systemau.
Mae rhai systemau yn darparu rhif ffôn neu delegram ar gyfer eu gweinyddwyr. Yn rhywle mae angen i chi ysgrifennu llythyrau at reolwyr neu fynd at dracwyr bygiau'r systemau allanol hyn. Hyd yn oed o fewn cyd-destun un cwmni mawr, mae systemau gwahanol yn aml yn gweithredu mewn gwahanol systemau cyfrifo cymwysiadau. Weithiau mae'n dod yn amhosibl olrhain statws cais. Byddwch yn derbyn cais mewn un Jira amodol. Yna yn sylw'r Jira cyntaf hwn rydych chi'n rhoi dolen i'r mater mewn Jira arall. Yn yr ail Jira yn y cais, mae rhywun eisoes yn ysgrifennu sylw sy'n mae angen i chi ffonio'r gweinyddwr amodol Andrey i ddatrys y mater. Ac yn y blaen.
Yr ateb gorau i'r broblem hon fyddai creu un gofod ar gyfer cyfathrebu, er enghraifft yn Slack. Gwahodd yr holl gyfranogwyr yn y broses o weithredu systemau allanol i ymuno. A hefyd traciwr sengl er mwyn peidio â dyblygu ceisiadau. Dylid olrhain ceisiadau mewn un lle, o fonitro hysbysiadau i allbwn datrysiadau bygiau yn y dyfodol. Byddwch yn dweud bod hyn yn afrealistig ac mae wedi digwydd yn hanesyddol ein bod yn gweithio mewn un traciwr, ac maent yn gweithio mewn un arall. Ymddangosodd systemau gwahanol, roedd ganddynt eu timau TG ymreolaethol eu hunain. Rwy'n cytuno, ac felly mae angen datrys y broblem o'r uchod ar lefel CIO neu berchennog cynnyrch.
Dylai pob system rydych yn rhyngweithio â hi ddarparu cymorth fel gwasanaeth gyda CLG clir i ddatrys materion yn ôl blaenoriaeth. Ac nid pan fydd gan y gweinyddwr amodol Andrey funud i chi.
Dyn Dagfa
A oes gan bawb ar brosiect (neu gynnyrch) berson y mae mynd ar wyliau yn achosi confylsiynau ymhlith ei uwch swyddogion? Gallai hwn fod yn beiriannydd devops, dadansoddwr neu ddatblygwr. Wedi'r cyfan, dim ond peiriannydd devops sy'n gwybod pa weinyddion sydd â pha gynwysyddion wedi'u gosod, sut i ailgychwyn y cynhwysydd rhag ofn y bydd problem, ac yn gyffredinol, ni ellir datrys unrhyw broblem gymhleth hebddo. Y dadansoddwr yw'r unig un sy'n gwybod sut mae eich mecanwaith cymhleth yn gweithio. Pa ffrydiau data sy'n mynd i ble. O dan ba baramedrau ceisiadau i ba wasanaethau, pa rai y byddwn yn derbyn ymatebion.
Pwy fydd yn deall yn gyflym pam mae gwallau yn y logiau ac yn trwsio nam critigol yn y cynnyrch yn brydlon? Wrth gwrs yr un datblygwr. Mae yna rai eraill, ond am ryw reswm yn unig mae'n deall sut mae gwahanol fodiwlau'r system yn gweithio.
Gwraidd y broblem hon yw diffyg dogfennaeth. Wedi'r cyfan, pe bai holl wasanaethau eich system yn cael eu disgrifio, yna byddai'n bosibl delio â'r broblem heb ddadansoddwr. Pe bai devops yn cymryd cwpl o ddiwrnodau allan o'i amserlen brysur ac yn disgrifio'r holl weinyddion, gwasanaethau a chyfarwyddiadau ar gyfer datrys problemau nodweddiadol, yna gallai'r broblem yn ei absenoldeb gael ei datrys hebddo. Nid oes angen i chi orffen eich cwrw yn gyflym ar y traeth tra ar wyliau a chwilio am wi-fi i ddatrys y broblem.
Cymhwysedd a chyfrifoldeb staff cymorth
Ar brosiectau mawr, nid yw cwmnïau'n anwybyddu cyflogau datblygwyr. Maent yn chwilio am ganolwyr neu bobl hŷn drud o brosiectau tebyg. Gyda chefnogaeth mae'r sefyllfa ychydig yn wahanol. Maent yn ceisio lleihau'r costau hyn ym mhob ffordd bosibl. Mae cwmnïau'n llogi gweithwyr Enikey ddoe rhad ac yn eofn yn mynd i frwydr. Mae'r strategaeth hon yn bosibl os ydym yn sôn am wefan cerdyn busnes o blanhigyn yn Zelenograd.
Os ydym yn sôn am siop ar-lein fawr, yna mae pob awr o amser segur yn costio mwy na chyflog misol gweinyddwr Enikey. Gadewch i ni gymryd 1 biliwn rubles o drosiant blynyddol fel man cychwyn. Dyma isafswm trosiant unrhyw siop ar-lein o'r sgôr . Rhannwch y swm hwn â nifer yr oriau y flwyddyn a chewch fwy na 100 rubles o golledion net. Ac os na fyddwch chi'n cyfrif oriau'r nos, gallwch chi ddyblu'r swm yn ddiogel.
Ond nid arian yw'r prif beth, iawn? (na, wrth gwrs y prif beth) Mae yna hefyd golledion enw da. Gall cwymp siop ar-lein adnabyddus achosi ton o adolygiadau ar rwydweithiau cymdeithasol a chyhoeddiadau yn y cyfryngau thematig. Ac ni ellir mesur o gwbl sgyrsiau ffrindiau yn y gegin yn arddull “Peidiwch â phrynu unrhyw beth yno, mae eu gwefan bob amser i lawr”.
Nawr i gyfrifoldeb. Yn fy arfer i, roedd achos pan na wnaeth y gweinyddwr ar ddyletswydd ymateb mewn pryd i hysbysiad gan y system fonitro nad oedd y safle ar gael. Ar nos Wener haf braf, roedd gwefan siop ar-lein adnabyddus ym Moscow yn gorwedd yn dawel. Fore Sadwrn, nid oedd rheolwr cynnyrch y wefan hon yn deall pam na agorodd y wefan, a bu tawelwch yn y gefnogaeth a'r sgyrsiau hysbysu brys yn Slack. Costiodd camgymeriad o'r fath swm chwe ffigur i ni, a'r swyddog dyletswydd hwn oedd ei swydd.
Mae cyfrifoldeb yn sgil anodd i'w ddatblygu. Naill ai mae gan berson neu beidio. Felly, yn ystod cyfweliadau, ceisiaf nodi ei bresenoldeb gyda chwestiynau amrywiol sy'n dangos yn anuniongyrchol a yw person yn gyfarwydd â chymryd cyfrifoldeb. Os bydd rhywun yn ateb ei fod wedi dewis prifysgol oherwydd bod ei rieni wedi dweud hynny neu'n newid swyddi oherwydd bod ei wraig wedi dweud nad yw'n ennill digon, yna mae'n well peidio â bod yn gysylltiedig â phobl o'r fath.
Rhyngweithio gyda'r tîm datblygu
Pan fydd defnyddwyr yn dod ar draws problemau syml gyda chynnyrch yn ystod gweithrediad, mae cefnogaeth yn eu datrys ar eu pen eu hunain. Yn ceisio atgynhyrchu'r broblem, yn dadansoddi'r logiau, ac ati. Ond beth i'w wneud pan fydd nam yn ymddangos yn y cynnyrch? Yn yr achos hwn, mae cefnogaeth yn aseinio'r dasg i'r datblygwyr a dyma lle mae'r hwyl yn dechrau.
Mae datblygwyr yn cael eu gorlwytho'n gyson. Maent yn creu nodweddion newydd. Nid trwsio chwilod gyda gwerthiant yw'r gweithgaredd mwyaf diddorol. Mae dyddiadau cau yn agosáu ar gyfer cwblhau'r sbrint nesaf. Ac yna mae pobl annymunol o gefnogaeth yn dod i ddweud: “Rhowch y gorau i bopeth ar unwaith, mae gennym ni broblemau.” Mae blaenoriaeth tasgau o'r fath yn fach iawn. Yn enwedig pan nad y broblem yw'r mwyaf hanfodol a bod prif ymarferoldeb y wefan yn gweithio, a phan nad yw'r rheolwr rhyddhau yn rhedeg o gwmpas gyda llygaid chwyddedig ac yn ysgrifennu: “Ychwanegwch y dasg hon ar frys at y datganiad nesaf neu'r ateb poeth.”
Mae materion â blaenoriaeth arferol neu isel yn cael eu symud o ryddhau i ryddhau. I’r cwestiwn “Pryd fydd y dasg wedi’i chwblhau?” byddwch yn derbyn atebion yn arddull: “Mae'n ddrwg gennym, mae llawer o dasgau ar hyn o bryd, gofynnwch i arweinwyr eich tîm neu'ch rheolwr rhyddhau.”
Mae problemau cynhyrchiant yn cael blaenoriaeth uwch na chreu nodweddion newydd. Ni fydd adolygiadau gwael yn hir i ddod os bydd defnyddwyr yn baglu ar fygiau'n gyson. Mae'n anodd adfer enw da sydd wedi'i ddifrodi.
Mae materion yn ymwneud â rhyngweithio rhwng datblygu a chymorth yn cael eu datrys gan DevOps. Defnyddir y talfyriad hwn yn aml ar ffurf person penodol sy'n helpu i greu amgylcheddau prawf i'w datblygu, yn adeiladu piblinellau CICD ac yn dod â chod profedig i mewn i gynhyrchu yn gyflym. Mae DevOps yn ddull o ddatblygu meddalwedd pan fydd yr holl gyfranogwyr yn y broses yn rhyngweithio'n agos â'i gilydd ac yn helpu i greu a diweddaru cynhyrchion a gwasanaethau meddalwedd yn gyflym. Rwy'n golygu dadansoddwyr, datblygwyr, profwyr a chefnogaeth.
Yn y dull hwn, nid yw cymorth a datblygiad yn adrannau gwahanol gyda'u nodau a'u hamcanion eu hunain. Mae datblygiad yn ymwneud â gweithredu ac i'r gwrthwyneb. Nid yw ymadrodd enwog timau dosbarthedig: “Nid yw'r broblem ar fy ochr” bellach yn ymddangos mewn sgyrsiau mor aml, ac mae defnyddwyr terfynol yn dod ychydig yn hapusach.
Ffynhonnell: hab.com