Tangu nilipoanza katika teknolojia mwaka 1992 (zaidi ya miongo mitatu iliyopita!), Nimewasiliana na matukio mengi ambapo nilitarajia "kufanya zaidi na chini."
Uzoefu mmoja unaonekana kutoka wakati wangu kama msanifu wa nyuma katika mradi wa usafirishaji wa wingu.minimize or eliminate service-level logging—logging kwamba sisi kutegemea sana kwa ajili ya debugging na uchambuzi wa ajali. Uamuzi ulikuwa unaendeshwa na gharama kubwa ya log ingestion kwenye jukwaa letu la ufuatiliaji.
Hii ilifanya kazi - mpaka haikufanyika.
Kwa kweli tunahitaji nyaraka hizi!
Bila ya shaka, tatizo lile lilitokea, na tulihitaji kumbukumbu hizo zilizopo. Zilipatikana kuwa njia pekee ya kutambua sababu ya msingi. Bila yao, masaa yaliyotumika bila suluhisho, kutokuwa na uhakika uliongezeka, na wasiwasi ulifuata timu nzima.
// Sample (but not the real) log line removed during our cost-cutting
{
"timestamp": "2025-03-21T14:05:03Z",
"service": "preference-engine",
"level": "ERROR",
"message": "Worker queue overflow: unable to dispatch to worker pool",
"requestId": "abc123",
"userId": "admin_42"
}
Ikiwa tungelihifadhi, kumbukumbu rahisi ya makosa ya muundo (kama ilivyo hapo juu) ingekuwa rahisi kufichuliwa katika jukwaa la kumbukumbu kwa query rahisi ya kumbukumbu (kama ilivyo hapa chini) na inatuwezesha kuelewa, kutambua, na kurekebisha tatizo.
_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId
Kuambiwa kupunguza kwa kiasi kikubwa uvuvi wetu unaweka mradi mzima katika hali mbaya.
Lean haina maana ya njaa kwa rasilimali
Ili kuwa wazi, mawazo ya "kufanya zaidi na chini" sio mbaya kwa asili. Makampuni mengi ya kuanzisha yanaendelea kwa kuzingatia vipaumbele muhimu na kutumia programu ndogo, yenye ufanisi. kubuni ya minimalist inaweza kusababisha ubora bora, ikiwa zana muhimu ziko mahali.
Lakini hii haikuwa aina nzuri ya lean. Na muda wetu wa kuhamia kwenye wingu ulikuwa imara. Sisi tulishindana na tarehe ya kupunguzwa kwa kivinjari. Hiyo ilimaanisha kuandika upya huduma kwa muundo wa wingu, kushirikiana na timu za wateja, na kutoa chini ya shinikizo.we relied on logs to resolve our issuesna kusaidia kuamua chanzo cha chanzo cha matukio yasiyotarajiwa. Hiyo ilikuwa vizuri mwanzoni, tu iliongeza logging muhimu wakati wa kufanya kazi juu ya kila mbinu.
Lakini wakati uvuvi uliporomoka, timu ilifichuliwa. mtandao wetu wa usalama wa msingi ulikuwa umepotea.
Sababu ya mizizi bila mtandao
Utafiti wa ndani ulifanyika vizuri. Kama uzalishaji ulifika karibu, tulihisi ujasiri katika usanifu wetu mpya wa wingu. Tulijibu matatizo yaliyojulikana katika majaribio na kutimiza muda wetu.
Lakini tulielewa haraka kuwa ujasiri wetu ulikuwa ukifichwa na ukomo wetu wa mtihani ulikuwa ukosefu.
Mara tu tulipokuwa katika uzalishaji na wateja halisi walikuwa kutumia jukwaa, kesi hizo zisizotarajiwa zisizotarajiwa zilionekana. Na bila shaka, bila kumbukumbu za kina au ufuatiliaji wa kutosha, hakuwa na njia ya kuchunguza tatizo.
Ikiwa tungekuwa na logs kwa ajili ya majaribio ya backend na wateja wa uzalishaji kwenye frontend, tungeweza kujua kile kilichotokea na kumwambia timu (na mtumiaji).
_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
on requestId
| fields requestId, _sourceCategory, message
Lakini bila kumbukumbu, kuigiza matukio ya ndani ilikuwa karibu haiwezekani. Kulikuwa na tofauti nyingi sana katika matukio ya matumizi ya dunia halisi. Tulijaribu kuwezesha kumbukumbu ya sehemu, lakini hii tu ilisababisha ongezeko la gharama za kuchukua tulipaswa kupunguza, bila kutoa ufahamu unaoweza kutumika.
Katika baadhi ya matukio, hatuwezi kutambua sababu ya msingi kabisa. Hiyo ni nafasi ngumu ya kuwa: kujua kuna tatizo ambalo linaathiri watumiaji na kutokuwa na uwezo wa kuelezea.
MTTR dhidi ya ubora wa ishara
Jambo jingine lilikuwa kwamba katika matukio yetu ya retrospectives, maana ya wakati wa kurejesha (MTTR yaLakini tuligundua kuwa MTTR mara nyingi ilikuwa dalili, sio sababu ya msingi.
Viwango vya viwango vya sekta mara nyingi vinaonyesha timu za juu zinafikia MTTR kwa chini ya saa moja. Lakini kile tulichokijua kilikuwa kwamba kasi sio tu automatisering - nihigh-fidelity signalsMaonyesho ya uaminifu mdogo, kama vile makosa ya kawaida ya 500 au tahadhari ya muda mrefu kutoka kwa takwimu za jumla, haifanyi kazi.
Kwa upande mwingine, ishara za kina, za mazingira - kama vile kumbukumbu za muundo na userId, requestId, na kufuatilia huduma - zinachukuliwa moja kwa moja kwa sababu ya msingi. majukwaa ya ufuatiliaji yanaweza kupunguza MTTR, lakini tu ikiwa data unayotumia inaweza kufanywa.
Ikiwa kumbukumbu zako hazijibu maswali haya, MTTR yako sio kuhusu kasi ya timu - ni kuhusu uwazi wa ishara.
Jinsi Mfano wa Sumo Logic Inaweza Kuokoa Siku
Hivyo nini kilikuwa naweza kuwa tofauti - na bora - wakati wa mradi wangu wa kuboresha wingu?
Kwanza, ningependa kuwa na uchambuzi bora wa kumbukumbu na ufuatiliaji wa utendaji wa programu (APM). Na pamoja na hiyo APM, usimamizi wa kumbukumbu, ufuatiliaji wa huduma, tahadhari, na takwimu zilizoelezwa zinapatikana karibu na mafanikio ya kazi au kushindwa.
Na nataka kumbukumbu zangu nyuma! katika machapisho yangu ya awali, "DevSecOps: Ni wakati wa kulipa kwa mahitaji yako, sio upungufu,“Nimejifunza jinsi yaMaana ya mantikikuharibu nafasi ya ufuatiliaji kwa kutoa mfano wa pay-per-analysis. Logs inaweza kuchukuliwa mara kwa mara, lakini unalipa tu wakati unahitaji kuuliza au kuchambua.
Je, wewe ni timu bila uhakika kamili wa mtihani wa kipengele? Kuteseka na ukosefu wa tahadhari ya wakati halisi au takwimu za granular? juu ya bajeti ngumu? Kuanguka kwa ukosefu wa kumbukumbu?
Na wakati tukio hilo hatimaye hutokea (na itakuwa), uchambuzi unaweza kufanywa juu ya mahitaji, kwa gharama halali inayohusiana moja kwa moja na athari ya wateja au uendelevu wa biashara.
Njia hii inarejesha udhibiti na kupunguza wasiwasi kwa sababu timu zina uwezo wa kuchunguza kwa kina wakati ni muhimu zaidi.
Lakini kusubiri: Unahitaji Triage ya Machine-Assisted ili kufafanua maswali yako
Ufuatiliaji wa kisasa sio tu kuhusu kuwa na data nzuri ya kumbukumbu - pia ni kuhusu kujua wapi kuangalia data hiyo.high-fidelity signals.
Wakati una upungufu usio na kikomo, una tani ya data. Na wakati unapoanza kutafuta habari, unahitaji mahali pa kuanza.machine-assisted triage toolsambayo moja kwa moja inachanganya tabia zisizo za kawaida, kugundua outliers, na kufunika ishara zinazohusiana kati ya huduma kabla ya kuandika query moja.
Nyuma ya nyota, Sumo Logic alitumia algorithms takwimu na kujifunza mashine:
- Cluster logs kwa usawa (hata kama ilivyoelezwa tofauti kati ya nodes).
- Kutambua outliers katika takwimu na logs (kwa mfano, makosa ya juu kwa huduma, mkoa, au cohort ya mtumiaji).
- Kuimarisha anomali na metadata (kwa mfano, alama za AWS, Kubernetes pod info, alama za utekelezaji).
- Lugha ya asili ya usindikaji clusters logs kwa mfano wa semantic, si tu string matching.
Hii ni muhimu hasa katika mazingira ya kiasi kikubwa cha upungufu usio na kikomo. Badala ya kutazama maelfu ya mstari wa kumbukumbu, unapata "maandiko ya kumbukumbu" - mifano iliyoongozwa ambayo inawakilisha makundi ya matukio yanayohusiana.
Mfano wa Workflow
_sourceCategory=prod/* error
| logreduce
Amri hii ya pekee inachanganya data ya redio yenye sauti katika buckets zinazoweza kutumika kama vile:
Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *
Mara moja clustered, timu inaweza pivot katika mazingira ya kina:
| where message matches "Auth token expired*"
| count by userId, region
Matokeo? Utafutaji wa kipofu wa chini. Njia za uamuzi wa haraka. Ukosefu wa wasiwasi wakati wa ajali.
Mwisho wa
Dini ya "kufanya zaidi na chini" haipaswi kuweka timu za uhandisi katika hasara. lakini inapaswa kuunganishwa na zana sahihi. Bila yao, hata timu za uwezo zaidi zinaweza kujisikia kama wao ni kuendesha bila lengo wakati wa tukio - kusababisha hasira na shinikizo.
Wasomaji wangu wanaweza kukumbuka taarifa yangu ya ujumbe wa kibinafsi, ambayo nadhani inaweza kutumika kwa wataalamu wowote wa IT:
“Kusisitiza muda wako kwa kutoa vipengele / utendaji ambao huongeza thamani ya mali yako ya akili. Kuimarisha mifumo, bidhaa na huduma kwa kila kitu kingine.” —J. Vester
“Kusisitiza muda wako kwa kutoa vipengele / utendaji ambao huongeza thamani ya mali yako ya akili. Kuimarisha mifumo, bidhaa na huduma kwa kila kitu kingine.” —J. Vester
Katika makala hii, tumeangalia jinsi mfano wa gharama isiyo na gharama inavyoweza kufanana na kazi hii. Inasaidia timu kupata sababu za msingi haraka, kupunguza muda wa upungufu, na viwango vya chini vya shinikizo - yote bila kuharibu bajeti.
Kuwa na siku nzuri kweli!
