Habari, Habr! Nimekuwa nikisaidia mifumo ya Highload IT kwa miaka kumi. Sitaandika katika makala hii kuhusu matatizo ya kuanzisha nginx kufanya kazi katika hali ya 1000 + RPS au mambo mengine ya kiufundi. Nitashiriki uchunguzi wangu kuhusu matatizo katika michakato inayotokea katika usaidizi na uendeshaji wa mifumo hiyo.
Ufuatiliaji
Usaidizi wa kiufundi hausubiri hadi ombi lifike na maudhui "Nini Kwa nini... tovuti haifanyi kazi tena?" Ndani ya dakika moja baada ya tovuti kukatika, usaidizi unapaswa kuona tatizo na kuanza kulitatua. Lakini tovuti ni ncha ya barafu. Upatikanaji wake ni mojawapo ya ya kwanza kufuatiliwa.
Nini cha kufanya na hali wakati bidhaa zilizobaki za duka la mtandaoni haziwasili tena kutoka kwa mfumo wa ERP? Au je, mfumo wa CRM unaokokotoa punguzo kwa wateja umeacha kujibu? Tovuti inaonekana kufanya kazi. Zabbix yenye masharti inapokea majibu yake 200. Kitengo cha zamu hakijapokea arifa zozote kutoka kwa ufuatiliaji na kinatazama kwa furaha kipindi cha kwanza cha msimu mpya wa Game of Thrones.
Ufuatiliaji mara nyingi hupunguzwa kwa kupima tu hali ya kumbukumbu, RAM na mzigo wa processor ya seva. Lakini kwa biashara ni muhimu zaidi kupata upatikanaji wa bidhaa kwenye tovuti. Kushindwa kwa masharti kwa mashine moja ya kawaida kwenye nguzo itasababisha ukweli kwamba trafiki itaacha kwenda kwake na mzigo kwenye seva zingine utaongezeka. Kampuni haitapoteza pesa.
Kwa hiyo, pamoja na kufuatilia vigezo vya kiufundi vya mifumo ya uendeshaji kwenye seva, unahitaji kusanidi metrics za biashara. Vipimo vinavyoathiri pesa moja kwa moja. Mwingiliano mbalimbali na mifumo ya nje (CRM, ERP na wengine). Idadi ya maagizo kwa muda fulani. Uidhinishaji wa mteja uliofanikiwa au ambao haujafanikiwa na vipimo vingine.
Mwingiliano na mifumo ya nje
Tovuti yoyote au programu ya simu yenye mauzo ya kila mwaka ya rubles zaidi ya bilioni huingiliana na mifumo ya nje. Kuanzia CRM na ERP zilizotajwa hapo juu na kumalizia na uhamisho wa data ya mauzo kwenye mfumo wa Data Kubwa wa nje kwa ajili ya kuchanganua ununuzi na kumpa mteja bidhaa ambayo bila shaka atanunua (kwa kweli, sivyo). Kila mfumo kama huo una msaada wake. Na mara nyingi mawasiliano na mifumo hii husababisha maumivu. Hasa wakati tatizo ni la kimataifa na unahitaji kuchambua katika mifumo tofauti.
Mifumo mingine hutoa nambari ya simu au telegramu kwa wasimamizi wao. Mahali fulani unahitaji kuandika barua kwa wasimamizi au kwenda kwa wafuatiliaji wa hitilafu wa mifumo hii ya nje. Hata ndani ya muktadha wa kampuni moja kubwa, mifumo tofauti mara nyingi hufanya kazi katika mifumo tofauti ya uhasibu ya matumizi. Wakati mwingine inakuwa vigumu kufuatilia hali ya programu. Unapokea ombi katika Jira moja yenye masharti. Kisha katika maoni ya Jira hii ya kwanza unaweka kiungo cha suala hilo kwenye Jira nyingine. Katika Jira ya pili katika maombi, mtu tayari anaandika maoni ambayo unahitaji kumpigia simu msimamizi wa masharti Andrey ili kutatua suala hilo. Na kadhalika.
Suluhisho bora kwa tatizo hili litakuwa kuunda nafasi moja ya mawasiliano, kwa mfano katika Slack. Kuwaalika washiriki wote katika mchakato wa uendeshaji wa mifumo ya nje kujiunga. Na pia tracker moja ili usirudie programu. Maombi yanapaswa kufuatiliwa katika sehemu moja, kutoka kwa arifa za ufuatiliaji hadi matokeo ya utatuzi wa hitilafu katika siku zijazo. Utasema kwamba hii sio kweli na imetokea kihistoria kwamba tunafanya kazi katika tracker moja, na wanafanya kazi katika nyingine. Mifumo tofauti ilionekana, walikuwa na timu zao za uhuru za IT. Nakubali, na kwa hivyo tatizo linahitaji kutatuliwa kutoka juu katika kiwango cha CIO au mmiliki wa bidhaa.
Kila mfumo unaowasiliana nao unapaswa kutoa usaidizi kama huduma iliyo na SLA iliyo wazi ili kutatua masuala kwa kipaumbele. Na sio wakati msimamizi wa masharti Andrey ana dakika kwa ajili yako.
Mtu wa chupa
Je, kila mtu kwenye mradi (au bidhaa) ana mtu ambaye kwenda likizoni husababisha degedege kati ya wakuu wao? Huyu anaweza kuwa mhandisi wa devops, mchambuzi au msanidi programu. Baada ya yote, mhandisi wa devops tu ndiye anayejua ni seva gani zilizo na vyombo vilivyosanikishwa, jinsi ya kuwasha tena chombo ikiwa kuna shida, na kwa ujumla, shida yoyote ngumu haiwezi kutatuliwa bila yeye. Mchambuzi ndiye pekee anayejua jinsi utaratibu wako mgumu unavyofanya kazi. Mitiririko ya data inakwenda wapi. Chini ya vigezo gani vya maombi kwa huduma gani, ni zipi tutapokea majibu.
Nani ataelewa haraka kwa nini kuna makosa kwenye kumbukumbu na kurekebisha mara moja hitilafu muhimu kwenye bidhaa? Bila shaka developer sawa. Kuna wengine, lakini kwa sababu fulani tu anaelewa jinsi moduli tofauti za mfumo zinavyofanya kazi.
Mzizi wa tatizo hili ni ukosefu wa nyaraka. Baada ya yote, ikiwa huduma zote za mfumo wako zilielezwa, basi itawezekana kukabiliana na tatizo bila mchambuzi. Ikiwa devops ilichukua siku kadhaa nje ya ratiba yake yenye shughuli nyingi na kuelezea seva zote, huduma na maagizo ya kutatua shida za kawaida, basi shida bila kukosekana kwake inaweza kutatuliwa bila yeye. Huna haja ya kumaliza haraka bia yako ufukweni ukiwa likizoni na utafute wi-fi ili kutatua tatizo.
Uwezo na wajibu wa wafanyakazi wa usaidizi
Katika miradi mikubwa, kampuni hazipunguzi mishahara ya wasanidi programu. Wanatafuta watu wa kati wa bei ghali au wazee kutoka kwa miradi kama hiyo. Kwa msaada, hali ni tofauti kidogo. Wanajaribu kupunguza gharama hizi kwa kila njia iwezekanavyo. Makampuni huajiri wafanyikazi wa Enikey wa jana na kwa ujasiri kwenda vitani. Mkakati huu unawezekana ikiwa tunazungumzia tovuti ya kadi ya biashara ya mmea huko Zelenograd.
Ikiwa tunazungumzia juu ya duka kubwa la mtandaoni, basi kila saa ya muda wa chini ina gharama zaidi ya mshahara wa kila mwezi wa msimamizi wa Enikey. Wacha tuchukue rubles bilioni 1 za mauzo ya kila mwaka kama sehemu ya kuanzia. Hiki ndicho kiwango cha chini cha mauzo ya duka lolote la mtandaoni kutoka kwa ukadiriaji . Gawanya kiasi hiki kwa idadi ya masaa kwa mwaka na kupata rubles zaidi ya 100 ya hasara halisi. Na ikiwa hutahesabu masaa ya usiku, unaweza mara mbili kwa usalama.
Lakini pesa sio jambo kuu, sawa? (hapana, bila shaka jambo kuu) Pia kuna hasara za sifa. Kuanguka kwa duka maarufu la mtandaoni kunaweza kusababisha wimbi la hakiki kwenye mitandao ya kijamii na machapisho katika vyombo vya habari vya mada. Na mazungumzo ya marafiki jikoni katika mtindo wa "Usinunue chochote huko, tovuti yao daima iko chini" haiwezi kupimwa kabisa.
Sasa kuwajibika. Katika mazoezi yangu, kulikuwa na kesi wakati msimamizi wa zamu hakujibu kwa wakati kwa taarifa kutoka kwa mfumo wa ufuatiliaji kuhusu kutokuwepo kwa tovuti. Katika majira ya joto ya kupendeza Ijumaa jioni, tovuti ya duka inayojulikana ya mtandaoni huko Moscow ililala kimya. Jumamosi asubuhi, msimamizi wa bidhaa wa tovuti hii hakuelewa kwa nini tovuti haikufunguliwa, na kulikuwa na ukimya katika usaidizi na gumzo za arifa za dharura katika Slack. Kosa kama hilo lilitugharimu jumla ya takwimu sita, na afisa huyu wa zamu kazi yake.
Wajibu ni ujuzi mgumu kukuza. Ama mtu anayo au hana. Kwa hivyo, wakati wa mahojiano, ninajaribu kutambua uwepo wake na maswali anuwai ambayo yanaonyesha moja kwa moja ikiwa mtu amezoea kuchukua jukumu. Ikiwa mtu anajibu kwamba alichagua chuo kikuu kwa sababu wazazi wake walisema hivyo au anabadilisha kazi kwa sababu mke wake alisema kwamba hana mapato ya kutosha, basi ni bora kutojihusisha na watu kama hao.
Mwingiliano na timu ya maendeleo
Watumiaji wanapokutana na matatizo rahisi na bidhaa wakati wa operesheni, usaidizi hutatua peke yao. Inajaribu kuzalisha tatizo, kuchambua magogo, na kadhalika. Lakini nini cha kufanya wakati mdudu unaonekana kwenye bidhaa? Katika kesi hii, usaidizi unapeana kazi kwa watengenezaji na hapa ndipo furaha huanza.
Watengenezaji wamejaa kila wakati. Wanaunda vipengele vipya. Kurekebisha mende na mauzo sio shughuli inayovutia zaidi. Tarehe ya mwisho ya kukamilisha mbio zinazofuata inakaribia. Na kisha watu wasiopendeza kutoka kwa usaidizi huja na kusema: "Acha kila kitu mara moja, tuna shida." Kipaumbele cha kazi hizo ni ndogo. Hasa wakati shida sio muhimu zaidi na utendakazi mkuu wa tovuti hufanya kazi, na wakati msimamizi wa toleo hafanyi kazi na macho yaliyojaa na kuandika: "Ongeza kazi hii haraka kwa toleo linalofuata au suluhu."
Masuala yenye kipaumbele cha kawaida au cha chini huhamishwa kutoka kutolewa hadi kutolewa. Kwa swali "Je, kazi itakamilika lini?" utapokea majibu kwa mtindo wa: "Samahani, kuna kazi nyingi kwa sasa, waulize viongozi wa timu yako au acha meneja."
Matatizo ya uzalishaji huchukua kipaumbele cha juu kuliko kuunda vipengele vipya. Maoni mabaya hayatachukua muda mrefu kuja ikiwa watumiaji hujikwaa kila wakati kwenye hitilafu. Sifa iliyoharibiwa ni ngumu kurejesha.
Masuala ya mwingiliano kati ya maendeleo na usaidizi yanatatuliwa na DevOps. Ufupisho huu mara nyingi hutumiwa katika mfumo wa mtu mahususi ambaye husaidia kuunda mazingira ya majaribio kwa maendeleo, hutengeneza mabomba ya CICD na kuleta msimbo uliojaribiwa kwa haraka katika uzalishaji. DevOps ni mbinu ya uundaji wa programu wakati washiriki wote katika mchakato huingiliana kwa karibu na kusaidia kuunda na kusasisha bidhaa na huduma za programu kwa haraka. Ninamaanisha wachambuzi, wasanidi programu, wanaojaribu na usaidizi.
Katika mbinu hii, msaada na maendeleo sio idara tofauti zenye malengo na malengo yao. Maendeleo yanahusika katika uendeshaji na kinyume chake. Maneno maarufu ya timu zinazosambazwa: "Tatizo haliko upande wangu" haionekani tena kwenye gumzo mara nyingi, na watumiaji wa mwisho huwa na furaha kidogo.
Chanzo: mapenzi.com