हरा server graph देर से पूरे होते orders छिपा सकता है। Business outcomes को metrics, सुरक्षित logs और traces से जोड़ें; हर alert का action और owner तय करें।
लेखक
Anichur Rahaman
सुबह 10:01 पर support बताता है, “Checkout अटका है।” CPU केवल 40% है और homepage खुल रहा है। इस teaching scene में server हरा है या नहीं, उपयोगी प्रश्न नहीं। Customer को सही outcome मिल रहा है और अधूरा काम कहाँ रुक रहा है, यह देखना है।
Engineering for High Volume के part 4 में छोटी evidence chain बनती है: business outcome, aggregate signal, specific operation और controlled response । यह real incident, personal benchmark या guaranteed diagnosis time का दावा नहीं।
HTTP 200, completed queue job या payment page खुलना paid order का प्रमाण नहीं। Eligible operation, correct result, time boundary और exclusions तय करें। Proposed checkout SLI में 2 seconds में accurate result या durable pending receipt माँगा जा सकता है। Payment/fulfilment completion के अलग freshness objectives चाहिए, वरना pending हमेशा हरा रह सकता है।
नीचे 30 days में 99% good-event objective और 3,000,000 eligible attempts का planning envelope मानें। Incorrect, failed या too-slow outcomes का union bad है: एक attempt fail और slow दोनों हो तो एक बार गिनें। ये teaching assumptions हैं, measured StoreConsole SLO नहीं।
| Teaching calculation | Result |
|---|---|
| Planned eligible attempts /30 days | 3,000,000 |
| Allowed bad fraction: 1−99% | 1% |
| Planned bad-event budget | 30,000 |
| Burst: 440×600 | 264,000 |
| Bad events: 264,000×2% | 5,280 |
| Planned budget consumed: 5,280÷30,000 | 17.6% |
440 eligible attempts/s पर 10 minutes में 264,000 attempts आते हैं। 2% bad यानी 5,280, जो planned 30,000 budget का 17.6% है। Bad-rate ratio allowed 1% का 2× है; budget समाप्त होने का समय traffic assumptions पर निर्भर है। Google SLO alerting guidance multi-window और impact-aware alerts का आधार देता है। Fixed 2% universal paging threshold नहीं; volume, risk और urgency मायने रखते हैं।
OpenTelemetry signals aggregate metrics, event logs और span-based traces जोड़ते हैं। चार golden signals—latency, traffic, errors, saturation—के साथ actual business completion देखें। CPU के अलावा pool/lock waits, eligible-ready queue age, oldest unresolved obligation, storage और memory मापें। भविष्य के लिए scheduled jobs अभी late नहीं हैं।
| Evidence | प्रश्न | Boundary |
|---|---|---|
| Outcome counter | सही result समय पर आया? | Eligibility; हर attempt एक बार गिनें |
| Structured log | इस operation/attempt में क्या हुआ? | Scoped access; minimal sensitive fields |
| Trace | Instrumented time कहाँ गया? | Coverage, overlap और sampling limits |
| Audit/reconciliation record | कौन-सा durable business effect मौजूद है? | अलग authority, retention और recovery controls |
Request ID एक request पहचानता है; trace ID instrumented work जोड़ता है। Business operation ID relevant retries में रहता है, हर attempt अलग पहचानें। Queue work बाद में linked trace में चल सकता है। W 3 C Trace Context propagation rules है, authentication नहीं। Untrusted incoming IDs validate/limit करें, ज़रूरत पर safe internal correlation बनाएँ; sensitive context partners को अंधाधुंध न भेजें।
Span instrumented time का evidence है, automatic root cause नहीं। Nested/parallel spans overlap होते हैं; हर duration जोड़ना double-count करता है। Timestamps/units normalize करें, sound duration measurement और deploy/config markers रखें। पास की release hypothesis है, safe rollback का प्रमाण नहीं।
Latency distributions और success/failure populations को counts/rates सहित देखें। Mean capacity planning में उपयोगी है पर tails छिपाता है। Prometheus histogram guidance aggregation समझाता है: per-node p95 का average fleet p95 नहीं। Known windows में compatible distributions/buckets या सही दूसरा तरीका लें।
Structured logs में timestamp, service/environment/release, normalised route, outcome/reason, duration/unit और ज़रूरी scoped correlation रखें। Query string बिना भी raw path में personal data हो सकता है। Internal IDs sensitive हो सकते हैं; minimise और restrict करें। OWASP logging guidance secrets हटाने, access, integrity, retention और injection control का आधार है। Card data, passwords, tokens या customer documents telemetry में नहीं।
Request/order/user IDs ज़रूरी हों तो protected searchable context में रखें, unbounded metric dimensions में नहीं। Prometheus label guidance high-cardinality series पर चेताता है; Loki label guidance stream labels और detailed fields अलग करता है। हर label पर customer ID मध्यम traffic में भी छोटा backend भर सकता है।
Purpose और applicable requirements से retention, deletion और legal holds तय करें। Measured volume से ingestion, indexing, query/recovery size करें; universal 2 GB log node या 30 day retention नहीं। Collector drops, exporter failures, buffers, disk और alert delivery monitor करें। Retry/backoff और buffering bounded रखें, ताकि telemetry failure checkout न रोके। Required durable audit evidence की अपनी policy हो, silent sampling/drop नहीं।
OpenTelemetry sampling guidance early head और later tail decision अलग करता है। Head sampling बाद में हुई हर error trace बचाने की guarantee नहीं। Tail policies errors/slow traces को प्राथमिकता दे सकती हैं, पर capacity, wait windows और consistent routing चाहिए; upstream discarded spans वापस नहीं आते। Loss/coverage record करें और SLI के लिए unsampled outcome counters रखें। Actual SDK/instrumentation versions जाँचें; सभी integrations stable न मानें।
पहली screen में critical journey का good/bad volume और latency, फिर waiting work और resource limits हों, scope drill-down सहित। Incident में उपयोग device पर पढ़ना आसान हो। External/synthetic checks और provider evidence internal metrics के पूरक हैं; missing telemetry zero errors नहीं।
Page के साथ owner, affected scope, evidence, runbook और escalation चाहिए। उचित short/long windows, जहाँ अर्थपूर्ण हो minimum traffic और severity मिलाएँ। Security, corruption या imminent capacity failure पर user-error rate बढ़ने से पहले urgent action हो सकता है। Low-volume money mismatch noisy CPU से अधिक urgent हो सकता है।
Affected service/business state verify करें, evidence रखें और reversible mitigation चुनें। Database automatic restart या पिछले 15 minutes की हर release rollback न करें। Schema/API compatibility, in-progress payment और accepted work देखें। External result unknown हो तो financial action दोहराने से पहले original reference query करें। Mitigation के बाद actual outcomes और recovery backlog reconcile करें; error graph गिरना closure नहीं।
Isolated या explicitly controlled load test में representative mix, cold cache और dependency behaviour लें। Offered/completed work, generator limits, scope और stop conditions दर्ज हों। CPU guard कभी outage नहीं होगा guarantee नहीं देता। Provider/app charts windows, denominators, units या scope से अलग हो सकते हैं; किसी को गलत कहने से पहले definitions मिलाएँ।
Slow dependency, failed enqueue, delayed callback और exporter outage inject करें। Alert owner तक पहुँचे और linked record दूसरी entity का data खोले बिना unfinished work समझाए—यह test करें। Results, decisions और limitations change के साथ रखें। 10:01 पर evidence wait को narrow और recovery को सुरक्षित करे; शांत CPU customer ठीक हैं का वादा न बने।
समीक्षा 6 November 2026 । Anichur Rahaman, StoreConsole के निर्माता। SLO, traffic और budget teaching examples हैं, measured service results नहीं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
