DevOps Troubleshooting | Resavanje produkcionih problema i pronalazenje root cause
Resite probleme u produkciji, pronadjite root cause i stabilizujte sisteme bez rituala i nagadjanja.
Pregled
Kada sistemi otkazu, vecini timova ne treba jos dashboard-a, sastanaka ili teorija.
Potrebno je da se problem razume, izoluje i resi.
Produkcioni problemi su skupi jer brzo prestaju da budu samo tehnicki.
Pretvaraju se u:
- izgubljen prihod
- kasnjenja u isporuci
- naruseno poverenje korisnika
- burnout tima
- ponavljajuca hitna resenja koja nikada ne uklanjaju pravi uzrok
Ova usluga je fokusirana na resavanje infrastrukturnih i delivery problema sa velikim uticajem na nivou root cause-a.
Ne upravljanje simptomima.
Ne “pratimo pa cemo videti”.
Ne jos jedno privremeno resenje.
Cilj je jednostavan: vratiti stabilnost sistema i spreciti da se isti problem ponovo pojavi.
Izvršeni radovi po ovoj usluzi
Kada vise CPU-a nije pomoglo: pracenje SQL Server THREADPOOL gladovanja do jedne SET opcije
Produkcijski SQL Server je povremeno prestajao da odgovara cak i nakon sto su CPU i memorija bili povecani. Pratili smo THREADPOOL gladovanje kroz blokiranje pri kompajliranju i Extended Events do nepotrebnog SET ANSI_WARNINGS OFF unutar stored procedure.
MySQL slow_log: Pronadji najcesce i najsporije query digeste
Praktican nacin da se MySQL slow_log pretvori u rangiranu listu familija upita po ucestalosti, ukupnom vremenu izvrsavanja i najgoroj latenciji.
Kubernetes aplikacija koristi javno DNS ime za interni API: kako zadrzati saobracaj unutar klastera
Kubernetes aplikacija je povremeno postajala primetno spora zato sto su interni API zahtevi izlazili iz klastera preko javnog DNS imena. Kako smo pratili latenciju do spoljnog network RTT-a i zadrzali saobracaj unutar Kubernetes-a.
Oporavak RabbitMQ klastera nakon ispada noda: kako je nedovoljno pracenje dovelo do split-brain klastera
Incident sa RabbitMQ Streams gde su neki upisi prolazili, dok su drugi padali sa porukom da je coordinator unavailable. Kako smo identifikovali autoritativno Raft stanje, bezbedno oporavili klaster i popravili propust u pracenju koji je dozvolio da split-brain stanje ostane neprimeceno.
NGINX 502 greske sa jednog load balancera: kako je segfault izazvao trajne upstream neuspehe
Jedan load balancer je nastavljao da vraca 502 greske iako je svaki backend bio zdrav. Osnovni uzrok bio je NGINX segfault tokom rotacije logova, a dugorocni popravak je spojio pracenje 5xx stope sa automatskim oporavkom od padova prijavljenih iz kernela.