For weeks, a cron job at Elevare Digital woke up on schedule, checked its queue, and logged a clean success. It approved

ആഴ്ചകളോളം, Elevare Digital-ലെ ഒരു cron job നിശ്ചിത സമയത്ത് പ്രവർത്തിക്കുകയും, അതിന്റെ ക്യൂ (queue) പരിശോധിക്കുകയും, വിജയകരമായി പൂർത്തിയായതായി രേഖപ്പെടുത്തുകയും (log) ചെയ്തു. അത് കൃത്യം പൂജ്യം ഡ്രാഫ്റ്റുകൾ മാത്രമാണ് അംഗീകരിച്ചത്. പത്തൊൻപത് ഉള്ളടക്കങ്ങൾ (content) കാത്തുനിൽക്കുകയായിരുന്നു. ഒരു ചെറിയ ബാക്ക്‌ലോഗ് (backlog) ആയി മാറുന്നതുവരെ ആ ടീം ഇത് അറിഞ്ഞതേയില്ല. ഒന്നും തകരാറിലായിരുന്നില്ല (crash). യാതൊരു അലേർട്ടുകളും (alerts) വന്നതുമില്ല. സാങ്കേതികമായി സിസ്റ്റം ആരോഗ്യത്തോടെ ഇരിക്കുകയായിരുന്നു, എന്നാൽ പ്രവർത്തനപരമായി അത് മരിച്ചതുപോലെയായിരുന്നു.

സ്വയം പ്രവർത്തിക്കുന്ന പൈപ്പ്‌ലൈനുകളുടെ (autonomous pipelines) നിശബ്ദമായ ഭീകരതയാണിത്. മനുഷ്യനെ ഇതിൽ നിന്ന് ഒഴിവാക്കുമ്പോൾ, ഒന്നും സംഭവിക്കുന്നില്ല എന്ന് തിരിച്ചറിയാൻ കഴിയുന്ന വ്യക്തിയെയും നിങ്ങൾ ഒഴിവാക്കുന്നു.

സ്വയം പ്രവർത്തിക്കുന്ന പൈപ്പ്‌ലൈൻ

Elevare Digital പൂർണ്ണമായും ഓട്ടോമേറ്റഡ് ആയ ഒരു കണ്ടന്റ് വർക്ക്ഫ്ലോ (content workflow) ആണ് നടത്തുന്നത്. സോഫ്റ്റ്‌വെയർ ഏജന്റുകൾ ഡ്രാഫ്റ്റുകൾ തയ്യാറാക്കുന്നു. ഒരു ഷെഡ്യൂൾ ചെയ്ത അപ്രൂവർ ക്രോൺ (approver cron) ഒരു കാവൽക്കാരനെപ്പോലെ പ്രവർത്തിക്കുന്നു, അവ പരിശോധിക്കുകയും അംഗീകരിച്ചവ നേരിട്ട് പബ്ലിഷിംഗിലേക്ക് എത്തിക്കുകയും ചെയ്യുന്നു. ഓരോ ബാച്ചും പരിശോധിക്കാൻ ഒരു മനുഷ്യനും ഡാഷ്‌ബോർഡ് തുറക്കാറില്ല. ടീം മറ്റ് പ്രശ്നങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുമ്പോൾ, വിരസമായ ജോലികൾ മെഷീൻ കൈകാര്യം ചെയ്യുക എന്നതാണ് ഇതിന്റെ ലക്ഷ്യം.

ഈ മാതൃകയിൽ, വിശ്വാസമാണ് നിങ്ങളുടെ പ്രധാന ഇടപഴകൽ (interface). ഷെഡ്യൂളർ കൃത്യസമയത്ത് പ്രവർത്തിക്കുമെന്നും, ജോബ് നടക്കുമെന്നും, എക്സിറ്റ് കോഡ് (exit code) ശരിയാണെന്നും നിങ്ങൾ വിശ്വസിക്കുന്നു. ലോഗുകളിൽ (logs) നിരന്തരമായ 200 OK റെസ്‌പോൺസുകൾ കാണുമ്പോൾ, ജോലി നടക്കുന്നുണ്ടെന്ന് നിങ്ങൾ കരുതുന്നു. ആഴ്ചകളോളം ആ ഹൃദയമിടിപ്പ് കൃത്യമായിരുന്നു. ക്രോൺ ഓരോ തവണയും കൃത്യസമയത്ത് പ്രവർത്തിച്ചു. പക്ഷേ അത് യഥാർത്ഥ ജോലി ഒരിക്കലും ചെയ്തില്ല.

പത്തൊൻപത് ഡ്രാഫ്റ്റുകളും ഒരു അലാറവും ഇല്ലായിരുന്നു

ഈ കണ്ടെത്തൽ ആകസ്മികമായിരുന്നു. പബ്ലിഷിംഗ് ക്യൂ നിശബ്ദമായത് ആരെങ്കിലും ശ്രദ്ധിച്ചു, അല്ലെങ്കിൽ ഒരു ഡൗൺസ്ട്രീം മെട്രിക് (downstream metric) പരിശോധിച്ചപ്പോൾ മാറ്റമില്ലാത്ത അവസ്ഥ കണ്ടു. പത്തൊൻപത് ഡ്രാഫ്റ്റുകൾ ഒട്ടും തൊടാതെ ഇരിക്കുന്നത് അവർ കണ്ടെത്തി. അപ്രൂവർ കൃത്യമായി പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുകയായിരുന്നു, എല്ലാ ദിവസവും വിജയകരമായി പൂർത്തിയായതായി രേഖപ്പെടുത്തുന്നുണ്ടായിരുന്നു, എന്നാൽ അവയിൽ ഒന്നിനെയും പ്രോസസ്സ് ചെയ്തിരുന്നില്ല.

ഒരു മാനുവൽ വർക്ക്ഫ്ലോയിൽ, ഒരു മനുഷ്യൻ ഒന്നാം ദിവസം തന്നെ ഇൻബോക്സ് കാലിയായതോ അല്ലെങ്കിൽ പെൻഡിംഗ് ഐറ്റങ്ങൾ കുന്നുകൂടിയതോ ശ്രദ്ധിക്കുമായിരുന്നു. ഓട്ടോമേറ്റഡ് പതിപ്പിൽ, പ്രവർത്തനങ്ങളുടെ അഭാവം ജോലിയുടെ അഭാവമായിട്ടാണ് തോന്നിയത്. ക്രോണിനെ നിരാശപ്പെടുത്താൻ അവിടെ ഒരു മാനേജർ ഉണ്ടായിരുന്നില്ല. അത് കൃത്യസമയത്ത് ജോലിക്ക് വരികയും നേരത്തെ പോവുകയും ചെയ്തു.

രണ്ട് ബഗുകൾ, ഒരൊറ്റ ശൂന്യമായ ഫലം

ഈ പരാജയത്തിന് രണ്ട് കാരണങ്ങളുണ്ടായിരുന്നു. ഇവയൊന്നും സിന്റാക്സ് എററോ (syntax error), ടൈമൗട്ടോ (timeout), അല്ലെങ്കിൽ ഡിപെൻഡൻസി ഔട്ടേജോ (dependency outage) ആയിരുന്നില്ല. രണ്ടും സെമാന്റിക് തെറ്റുകളായിരുന്നു (semantic mistakes), അവ ക്വറി എഞ്ചിന്റെ (query engine) കണ്ണിൽ പത്തൊൻപത് സാധുവായ വരികളെ (rows) ഒന്നുമില്ലാത്തതാക്കി മാറ്റി.

ഒന്നാമതായി, ഒരു ടൈപ്പ് മിസ്മാച്ച് (type mismatch). ഡ്രാഫ്റ്റുകൾ തയ്യാറാക്കുന്ന ഏജന്റ് article എന്ന് ടാഗ് ചെയ്ത റെക്കോർഡുകളാണ് എഴുതിയത്. എന്നാൽ അപ്രൂവർ ക്രോൺ thread ടൈപ്പുകൾക്കായി മാത്രമാണ് തിരഞ്ഞത് (query). പ്രൊഡ്യൂസറുകളും കൺസ്യൂമറുകളും (producers and consumers) വ്യത്യസ്ത രീതിയിൽ വികസിക്കുമ്പോൾ സംഭവിക്കുന്ന തരത്തിലുള്ള മാറ്റമാണിത്. ഒരു ടീം—അല്ലെങ്കിൽ ഒരു ഏജന്റ്—ഔട്ട്‌പുട്ട് ഒരു ആർട്ടിക്കിൾ ആണെന്ന് തീരുമാനിച്ചു. എന്നാൽ കൺസ്യൂമർ അത് ത്രെഡുകൾ (threads) ആയി സ്വീകരിക്കുമെന്ന് കരുതി എഴുതപ്പെട്ടു. ഇതൊരു കോംപൈൽ-ടൈം എറർ (compile-time error) ആയി വന്നില്ല, കാരണം ഇവ വെറും സ്ട്രിംഗ് ടാഗുകൾ (string tags) മാത്രമായിരുന്നു, ഒരുപക്ഷേ JSON ഫീൽഡുകളോ അല്ലെങ്കിൽ എൻഫോഴ്സ് ചെയ്യാത്ത varchar വാല്യൂകളോ ആകാം. ഡാറ്റാബേസിന് പൊരുത്തപ്പെടുന്നവ ഒന്നും കണ്ടെത്താനായില്ല, അതിനാൽ അത് ഒരു ശൂന്യമായ സെറ്റ് (empty set) നൽകി. എഞ്ചിനെ സംബന്ധിച്ചിടത്തോളം ഇതൊരു എറർ കണ്ടീഷൻ അല്ല. തെറ്റായ ഒരു ചോദ്യത്തിനുള്ള ശരിയായ ഉത്തരമാണിത്.

രണ്ടാമതായി, അപ്രൂവറുടെ ക്വറിയിലെ ഒരു ഇന്നർ ജോയിൻ (inner join) വരികളെ പൂർണ്ണമായും വിഴുങ്ങി. ക്വറി ഡ്രാഫ്റ്റ് ടേബിളിനെ മറ്റൊരു ടേബിളുമായി—ഒരുപക്ഷേ മെറ്റാഡാറ്റയ്ക്കോ സ്റ്റാറ്റസ് ഫ്ലാഗുകൾക്കോ വേണ്ടിയുള്ളത്—ജോയിൻ ചെയ്യുകയും, ജോയിൻ കണ്ടീഷൻ പരാജയപ്പെടുകയും ചെയ്താൽ, ഇന്നർ ജോയിൻ അതിന്റെ ഡിസൈൻ അനുസരിച്ച് പ്രവർത്തിക്കും. അത് പൊരുത്തപ്പെടാത്ത വരികളെ ഒഴിവാക്കി. റിസൾട്ട് സെറ്റിൽ തെറ്റായ വരികളോ (orphan rows) NULL വാല്യൂസോ ഒന്നും കാണിച്ചില്ല. പത്തൊൻപത് ഡ്രാഫ്റ്റുകളും ഒരു അരിപ്പയിലൂടെ വെള്ളം ഒഴുകുന്നതുപോലെ ക്വറിയിലൂടെ കടന്നുപോയി, ആപ്ലിക്കേഷൻ ലെയറിന് (application layer) തികച്ചും ശൂന്യമായ ഒരു ലിസ്റ്റ് ലഭിച്ചു.

ക്വറി ഒരു വരി പോലും നൽകാത്തതിനാൽ ഫംഗ്ഷൻ സുഗമമായി അവസാനിച്ചു. യാതൊരു എക്സെപ്ഷനുകളും (exceptions) ഉണ്ടായില്ല. HTTP റെസ്‌പോൺസ് 200 OK ആയിരുന്നു. ക്രോൺ വിജയം രേഖപ്പെടുത്തി വീണ്ടും ഉറങ്ങാൻ പോയി.

'Processed Zero' എന്ന കെണി

ഇതാണ് പ്രശ്നത്തിന്റെ കാതൽ. ഒരു ക്യൂ അടിസ്ഥാനമാക്കിയുള്ള സിസ്റ്റത്തിൽ, പ്രോസസ്സ് ചെയ്യാൻ പൂജ്യം വരികൾ മാത്രം ലഭിക്കുന്നത് സാധാരണമാണ്. ക്യൂ കാലിയാകുന്നു. വർക്കർ വേഗത്തിൽ ജോലി തീർക്കുന്നു. ലോഗിൽ processed: 0 എന്ന് കാണുമ്പോൾ ടീം അത് നല്ല വാർത്തയായി കാണുന്നു: നമ്മൾ ആവശ്യത്തിനനുസരിച്ച് ജോലി ചെയ്യുന്നു എന്ന്. അത് ഒരു ആരോഗ്യകരമായ അവസ്ഥയാണ്.

എന്നാൽ processed: 0 എന്നത് രണ്ട് വ്യത്യസ്ത യാഥാർത്ഥ്യങ്ങളെ സൂചിപ്പിക്കുന്നു:

• ആരോഗ്യകരമായ അവസ്ഥ: പ്രോസസ്സ് ചെയ്യാൻ ഒന്നുമില്ലാത്തതിനാൽ പൂജ്യം. ക്യൂ കാലിയാണ്. സിസ്റ്റം ഡിസൈൻ അനുസരിച്ച് വിശ്രമത്തിലാണ്.
• തകരാറിലായ അവസ്ഥ: കൺസ്യൂമറിന് ജോലി കാണാൻ കഴിയാത്തതിനാൽ പൂജ്യം. ക്യൂവിൽ പത്തൊൻപത് വരികളുണ്ട്. സിസ്റ്റം വിശ്രമത്തിലല്ല, മറിച്ച് അന്ധമാണ്.

ക്യൂവിന്റെ ആഴം (queue depth) സ്വതന്ത്രമായി പരിശോധിച്ചില്ലെങ്കിൽ, ഈ രണ്ട് അവസ്ഥകളും ഒരേ ടെലിമെട്രി (telemetry) വിവരങ്ങളാണ് നൽകുന്നത്. ഡാഷ്‌ബോർഡുകളിൽ അവ ഒരേപോലെയിരിക്കും, ലോഗ് അഗ്രഗേറ്ററുകളിൽ (log aggregators) ഒരേപോലെ തോന്നും, PagerDuty-യിൽ ഒരേപോലെ നിശബ്ദത ഉണ്ടാക്കും. യഥാർത്ഥ ജോലികൾ കുന്നുകൂടി കിടക്കുമ്പോൾ അത് നിശബ്ദമായിരിക്കുന്നതല്ല, മറിച്ച് വർക്കർ നിലവിളിക്കുമ്പോൾ മാത്രം തിരിച്ചറിയുന്ന ഒരു മോണിറ്ററിംഗ് സ്ട്രാറ്റജിയാണ് നിങ്ങൾ നിർമ്മിച്ചിരിക്കുന്നത്.

വിടവ് നികത്തുക

തങ്ങൾ നിരീക്ഷിക്കുന്ന കാര്യങ്ങളിൽ മാറ്റം വരുത്തിക്കൊണ്ട് Elevare Digital പ്രശ്നം പരിഹരിച്ചു. അവർ എറർ റേറ്റുകളെയും (error rates) സക്സസ് സ്റ്റാറ്റസുകളെയും (success statuses) മാത്രം ആശ്രയിക്കുന്നത് നിർത്തി. പകരം, ലഭ്യമായ ജോലിയും പൂർത്തിയാക്കിയ ജോലിയും തമ്മിലുള്ള വ്യത്യാസത്തെ അടിസ്ഥാനമാക്കി അലേർട്ടുകൾ നൽകാൻ അവർ തുടങ്ങി.

ഓരോ ബാച്ചിന് ശേഷവും, അവർ ഇപ്പോൾ ഒരു ലളിതമായ ഇൻവേരിയന്റ് ചെക്ക് (invariant check) നടത്തുന്നു:

• പ്രോസസ്സ് ചെയ്തവ (processed) 0 ഉം പെൻഡിംഗ് വരികൾ (pending rows) 0-യേക്കാൾ കൂടുതലുമാണെങ്കിൽ, ഒരു ഹൈ സെവെരിറ്റി അലേർട്ട് (high severity alert) നൽകുക.

ഈ നിയമം മനഃപൂർവ്വം കാരണങ്ങളെ പരിഗണിക്കുന്നില്ല. പിഴവ് സംഭവിച്ചത് ഒരു മോശം ഫിൽട്ടർ മൂലമാണോ, തകരാറിലായ ഒരു ജോയിൻ (join) മൂലമാണോ, അതോ തെറ്റായി ടൈപ്പ് ചെയ്ത ഒരു enum സ്ട്രിംഗ് മൂലമാണോ എന്നത് ഇത് നോക്കുന്നില്ല. ജോലി നിലവിലുണ്ടെന്നും എന്നാൽ ഒരു ജോലിയും പൂർത്തിയായിട്ടില്ലെന്നും മാത്രമേ ഇത് ശ്രദ്ധിക്കുന്നുള്ളൂ. ഇത് മോണിറ്ററിംഗിന്റെ രീതിയെ “പ്രോസസ്സ് പരാതിപ്പെട്ടോ?” എന്നതിൽ നിന്ന് “ജോലി മുന്നോട്ട് നീങ്ങിയോ?” എന്നതിലേക്ക് മാറ്റുന്നു.

ഇതിനെ പിന്തുണയ്ക്കുന്നതിനായി, അവർ ക്യൂ ഡെപ്ത്തിനെ (queue depth) ഒരു പ്രധാന മെട്രിക് ആയി കണക്കാക്കുന്നു; ഇത് വെറുമൊരു പരിശോധന എന്നതിലുപരി കാലാടിസ്ഥാനത്തിൽ ട്രാക്ക് ചെയ്യുന്നു. കൺസ്യൂമർ (consumer) തുടർച്ചയായി സക്സസ് റിപ്പോർട്ട് ചെയ്യുമ്പോഴും പ്രൊഡ്യൂസർ (producer) വരികൾ കൂട്ടിച്ചേർത്തു കൊണ്ടിരിക്കുകയാണെങ്കിൽ, ഡെപ്ത്ത് ട്രെൻഡ് (depth trend) ഒരു വ്യക്തമായ തെളിവായി മാറുന്നു. ഒരു സ്റ്റാറ്റിക് സ്നാപ്ഷോട്ട് (static snapshot) തെറ്റായ വിവരം നൽകിയേക്കാം, എന്നാൽ വർദ്ധിച്ചുവരുന്ന ബാക്ക്‌ലോഗ് (backlog) ഒരിക്കലും കള്ളം പറയില്ല.

ഓട്ടോണമസ് സിസ്റ്റങ്ങൾക്കുള്ള പാഠങ്ങൾ

സ്വയം പ്രവർത്തിക്കുന്ന പൈപ്പ്‌ലൈനുകൾ (hands-off pipelines) കൈകാര്യം ചെയ്യുന്നവർക്കായി Elevare സംഭവത്തിൽ നിന്ന് ചില പ്രായോഗിക നിയമങ്ങൾ താഴെ നൽകുന്നു.

സ്കാൻ ചെയ്ത വരികളെ (scanned rows) പ്രോസസ്സ് ചെയ്ത വരികളിൽ (processed rows) നിന്ന് വേറിട്ട് രേഖപ്പെടുത്തുക. കൺസ്യൂമർ നാൽപ്പത് വരികളെ സ്പർശിക്കുന്ന ഒരു ക്വറി (query) പ്രവർത്തിപ്പിക്കുകയും, മോശം മാനദണ്ഡങ്ങൾ ഉപയോഗിച്ച് അവയെല്ലാം ഫിൽട്ടർ ചെയ്ത് ഒഴിവാക്കുകയും ചെയ്ത ശേഷം processed: 0 എന്ന് റിപ്പോർട്ട് ചെയ്തേക്കാം. നിങ്ങൾ അവസാന കണക്ക് മാത്രം രേഖപ്പെടുത്തുകയാണെങ്കിൽ, ആ പ്രശ്നം നിങ്ങൾക്ക് തിരിച്ചറിയാൻ കഴിയില്ല. സ്കാൻ ചെയ്ത വരികളുടെ മെട്രിക് പരിശോധിച്ചാൽ, വർക്കർ അവിടെ വരികയും ജോലി പരിശോധിക്കുകയും എന്നാൽ ആശയക്കുഴപ്പത്തിലായി തിരിച്ചുപോവുകയും ചെയ്തു എന്ന് മനസ്സിലാക്കാം. സ്കാൻ ചെയ്തതും പ്രോസസ്സ് ചെയ്തതും തമ്മിലുള്ള ആ വ്യത്യാസമാണ് പലപ്പോഴും നിങ്ങളുടെ ആദ്യത്തെ സൂചന.

ക്യൂ ഡെപ്ത്തിനെ (queue depth) ഒരു ടൈം-സീരീസ് (time-series) ആയി ട്രാക്ക് ചെയ്യുക. ഒരു ക്യൂ താൽക്കാലികമായി കാലിയായിരിക്കുന്നത് കുഴപ്പമില്ല. എന്നാൽ വർക്കർമാർ കൃത്യമായി പ്രവർത്തിക്കുന്നു എന്ന് കാണിക്കുമ്പോഴും (green status) ക്യൂ നിരന്തരം വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണെങ്കിൽ അത് പ്രശ്നമാണ്. ഡെപ്ത്തും കൺസ്യൂമർ ത്രൂപുട്ടും (consumer throughput) തമ്മിലുള്ള ബന്ധം വിശകലനം ചെയ്യുക. ഇവ രണ്ടും തമ്മിൽ വ്യത്യാസം കാണുമ്പോൾ, എല്ലാ ഹെൽത്ത് ചെക്കുകളും (health checks) പാസ്സായതാണെങ്കിൽ പോലും ഉടൻ തന്നെ അന്വേഷണം നടത്തുക.

കൺസ്യൂമറുകളെ മോക്കുകൾക്ക് (mocks) പകരം യഥാർത്ഥ പ്രൊഡ്യൂസർ ഔട്ട്‌പുട്ട് ഉപയോഗിച്ച് പരിശോധിക്കുക. മോക്ക് ഡാറ്റ ഉപയോഗിച്ചുള്ള യൂണിറ്റ് ടെസ്റ്റുകൾ ടെസ്റ്ററുടെ മുൻധാരണകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. മോക്ക് ഫാക്ടറി thread ടൈപ്പുകൾ നൽകുകയും കൺസ്യൂമർ thread ടൈപ്പുകൾ പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങളുടെ ടെസ്റ്റുകൾ വിജയിച്ചേക്കാം, എന്നാൽ പ്രൊഡക്ഷനിൽ അത് പരാജയപ്പെട്ടേക്കാം. പ്രൊഡ്യൂസറുടെ ഔട്ട്‌പുട്ടിൽ നിന്ന് യഥാർത്ഥ റെക്കോർഡുകൾ എടുക്കുന്ന ഇൻ്റഗ്രേഷൻ ടെസ്റ്റുകൾ (integration tests) നടത്തുക. പ്രൊഡ്യൂസർ എഴുതുന്നത് കൺസ്യൂമറിന് കൃത്യമായി കാണാൻ കഴിയുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.

ഡാറ്റാ ടൈപ്പുകളെയും (data types) enum വാല്യൂസിനെയും കരാറുകളായി (contracts) പരിഗണിക്കുക. JSON ബ്ലോബുകളിലെ (JSON blobs) അയഞ്ഞ സ്ട്രിംഗ് ടാഗുകൾ സൗകര്യപ്രദമാണെങ്കിലും അവ പിന്നീട് തിരിച്ചറിയാൻ കഴിയാത്ത പരാജയ കാരണങ്ങളായി മാറിയേക്കാം. സ്കീമകൾ (schemas) വ്യക്തമായി നിർവചിക്കുക. കോൺസ്റ്റന്റുകൾ (constants) പങ്കുവെക്കുക. പ്രൊഡ്യൂസറും കൺസ്യൂമറും തമ്മിലുള്ള ഇടയിൽ പേലോഡുകൾ (payloads) പരിശോധിക്കുക. കരാർ ലംഘിക്കപ്പെട്ടാൽ, സിസ്റ്റം ഒരു WHERE ക്ലോസിനുള്ളിൽ നിശബ്ദമായി പരാജയപ്പെടുന്നതിന് പകരം അതിൻ്റെ അതിർത്തിയിൽ തന്നെ വ്യക്തമായി പരാജയം അറിയിക്കണം.

യഥാർത്ഥ പാഠം

ഓട്ടോണമസ് സിസ്റ്റങ്ങൾ മനുഷ്യരെപ്പോലെ പരാജയപ്പെടുന്നില്ല. അവ അവധി എടുക്കുകയോ, എപ്പോഴും എക്സെപ്ഷനുകൾ (exceptions) കാണിക്കുകയോ, അല്ലെങ്കിൽ വ്യക്തമായ ക്രാഷ് ഡമ്പുകൾ (crash dumps) അവശേഷിപ്പിക്കുകയോ ചെയ്യുന്നില്ല. അവ 200 OK നൽകുകയും ഇൻവെന്ററി നശിക്കാൻ അനുവദിക്കുകയും ചെയ്യുന്നു. നിങ്ങളുടെ അലേർട്ടുകൾ നിലവിളികൾക്കായി മാത്രം കാത്തിരിക്കുകയാണെങ്കിൽ, ഏറ്റവും വലിയ പരാജയങ്ങൾ നിങ്ങൾക്ക് നഷ്ടമാകും—എല്ലാം ശരിയാണെന്ന് തോന്നുകയും എന്നാൽ ഒരു ജോലിയും നടക്കാതിരിക്കുകയും ചെയ്യുന്ന സാഹചര്യങ്ങൾ.

വ്യത്യാസങ്ങൾ നിരീക്ഷിക്കാൻ പാകത്തിൽ നിങ്ങളുടെ ഒബ്സർവബിലിറ്റി (observability) രൂപകൽപ്പന ചെയ്യുക. അകത്തേക്ക് വരുന്ന ജോലിയും പുറത്തേക്ക് വരുന്ന ജോലിയും തമ്മിൽ താരതമ്യം ചെയ്യുക. ഇവ രണ്ടും തമ്മിൽ പൊരുത്തപ്പെടാതിരിക്കുമ്പോൾ, മെഷീൻ നിങ്ങളോട് കള്ളം പറയുകയാണെന്ന് കരുതുക. കാരണം ചിലപ്പോൾ, ഒരു സിസ്റ്റം പൂർണ്ണമായും അന്ധമായി മാറിയതിന്റെ ഏക ലക്ഷണമായിരിക്കാം തികഞ്ഞ ഒരു സക്സസ് ലോഗ് (success log).