- Antithesis, FoundationDB में प्रभावी साबित हुई deterministic autonomous testing को सामान्य software पर भी लागू कर, reproduce करना मुश्किल distributed systems bugs को दोहराए जा सकने वाली समस्याओं में बदलना चाहता है
- FoundationDB ने database implementation से पहले single-threaded, single-process simulation बनाया था, और उसी random seed से दुर्लभ failure scenarios को फिर से चला सकता था
- इस तरीके ने concurrency, network delay/reordering, disk issues, machine failures जैसी non-deterministic failures को test targets बना दिया, और FoundationDB में पूरे समय के दौरान customers द्वारा report किए गए bugs केवल 1–2 ही रहे, ऐसा आकलन है
- Antithesis ने existing software को शुरुआत से दोबारा लिखवाने से बचाने के लिए deterministic computer emulate करने वाला hypervisor बनाया, और फिलहाल distributed system reliability और fault-tolerance testing पर केंद्रित है
- MongoDB, Ethereum Foundation, Palantir के साथ collaboration किया है, और दुर्लभ bugs खोजने वाले tool से latest builds को लगातार verify करने वाली continuous testing service में विकसित हुआ है
FoundationDB अनुभव से शुरू हुआ Antithesis
- Antithesis ने 5 साल से अधिक समय तक stealth mode में development जारी रखने के बाद, FoundationDB से मिले deterministic testing अनुभव पर आधारित platform सार्वजनिक किया
- सार्वजनिक होने से पहले hiring, शुरुआती customers और investors के साथ काम किया गया, और सबसे पहले सामने आया core idea था complex systems को repeatably test करने का तरीका
Distributed database में सबसे कठिन verification समस्या
- FoundationDB ने 2010 में ACID transactions support करने वाला scalable और fault-tolerant distributed database बनाना शुरू किया
- उस समय Spanner सार्वजनिक नहीं हुआ था, और कई लोग CAP theorem को इस तरह गलत समझते थे कि strong consistency और high availability साथ-साथ संभव नहीं हैं
- सबसे बड़ी कठिनाई database खुद नहीं थी, बल्कि ऐसे system को कैसे test किया जाए और correctness को लेकर भरोसा कैसे पाया जाए, यह थी
Existing tests जिन “unknown unknowns” को छोड़ देते हैं
- Software को वे situations भी handle करनी होती हैं जिनकी developer ने पहले से कल्पना नहीं की होती, लेकिन सामान्य tests पहले से expected cases verify करने में मजबूत होते हैं
- अगर किसी specific case को test में लिखने जितना पहले से सोचा गया है, तो code भी संभवतः उस situation को handle करने के लिए लिखा गया होगा
- इसलिए existing tests regression prevention के लिए उपयोगी हैं, लेकिन real users और operating environments से आने वाली unexpected failures पकड़ने में कमजोर हैं
- Distributed storage systems में यह समस्या और बड़ी हो जाती है
- machines के अंदर और machines के बीच concurrency साथ-साथ मौजूद होती है
- network delay और packet reordering पैदा कर सकता है
- disk, machine failures, power outages, data center fires, और human mistakes तक failure causes बहुत व्यापक हो जाते हैं
- अगर कोई catastrophic bug कई machines में फैले events के order के प्रति sensitive हो, तो एक बार मिलने के बाद भी उसे फिर से reproduce करना मुश्किल होता है
FoundationDB की deterministic simulation
- FoundationDB team ने database लिखने से पहले पूरी तरह deterministic event-based network simulation बनाई
- पूरे cluster को single-threaded, single-process application के अंदर simulate किया गया, और same random number generator से execution drive किया गया
- Virtual cluster में network failures inject करना, machines kill करना, और कई abnormal situations बार-बार बनाना संभव था
- अगर कोई specific execution application logic bug खोज ले, तो उसी random seed से वही event order फिर चला सकते थे
- इससे बेहद दुर्लभ bugs भी logs जोड़ते हुए या debugging process दोहराते हुए trace किए जा सके
- संबंधित talk 2014 में Strangeloop में हुई थी, और video यहां देखी जा सकती है
Testing ने development speed कैसे बदली
- FoundationDB में पूरे company history के दौरान customers द्वारा report किए गए bugs केवल 1–2 थे, ऐसा आकलन है
- Kyle Kingsbury, यानी “aphyr”, ने FoundationDB को Jepsen से test नहीं किया क्योंकि उन्हें लगा कि खोजने के लिए कुछ नहीं होगा
- जब tests नए bugs तुरंत सामने लाने लगे, तो team की programming style भी बदल गई
- Compiler और strong type system कुछ प्रकार के bugs के खिलाफ confidence देते हैं, लेकिन यह हजारों unexpected situations में actual software चलाने जैसा नहीं है
- इस भरोसे के आधार पर FoundationDB team ने बड़े changes किए
- Zookeeper सहित सभी dependencies हटाईं और कम समय में अपना Paxos implementation लिखा; यह implementation FoundationDB paper में शामिल है
- Transaction processing subsystem को पूरा का पूरा ज्यादा तेज और scalable बनाने के लिए rewrite किया
- सबसे बड़ा असर सिर्फ database stability improvement नहीं था, बल्कि एक छोटी engineering team को 50x size वाली team जैसी productivity देना था
Apple acquisition के बाद सामने आया gap
- Apple ने 2015 में FoundationDB acquire किया, और इसे Apple की “cloud infrastructure” के आधार के रूप में इस्तेमाल किया
- कुछ साल बाद FoundationDB को open source के रूप में release किया गया
- FoundationDB team members अन्य बड़ी tech companies में फैल गए, लेकिन उन organizations में FoundationDB-style deterministic simulation testing नहीं थी
- Unintended system impact predict करना मुश्किल होने से backend system changes धीमे हुए, और production bugs diagnose और fix करने में senior engineers का महीनों समय लग जाता था
- 2018 में Dave Scherer के साथ Antithesis शुरू किया गया, और लक्ष्य FoundationDB-style deterministic autonomous testing दूसरी teams को भी उपलब्ध कराना था
Existing software को deterministic बनाने का तरीका
- FoundationDB शुरुआत से ही इस तरीके से test किए जाने को ध्यान में रखकर बनाया गया greenfield project था, और dependencies भी हटाई जा सकती थीं
- सामान्य software threads बनाता है, time check करता है, kernel से random values मांगता है, और network के जरिए दूसरे software से communicate करता है
- ऐसी development methodology जिसे अपनाने के लिए सभी software को शुरुआत से फिर लिखना पड़े, व्यापक रूप से इस्तेमाल होना कठिन है; इसलिए Antithesis ने deterministic computer emulate करने वाला hypervisor लिखा
- परिणामस्वरूप hypervisor के अंदर चलने वाले software को deterministic execution environment में रखा जा सकता है
- इस process में Intel CPU के extended page table जैसे low-level behaviors को handle करना शामिल है
- किसी arbitrary program के state space में property violations खोजने की समस्या halting problem से भी कठिन है, और सभी programs के लिए halting oracle होने पर भी कुछ test properties non-computable हो सकती हैं
Current platform और customer cases
- Antithesis platform का लक्ष्य users के software को लेकर bugs खोजना, और मिले हुए bugs को हमेशा reproduce करने योग्य बनाना है
- कई services के network से communicate करने जैसे complex cases में भी reproducibility बनाए रखने की कोशिश की जाती है
- Bug मिलने के बाद powerful debugging capabilities apply की जा सकती हैं
- Long term में इसे विभिन्न software में कई तरह के bugs खोजने के लिए design किया गया है, लेकिन फिलहाल यह पहले से अनुभव वाले distributed systems reliability और fault-tolerance testing पर केंद्रित है
- पिछले कुछ वर्षों में reliability-critical बड़े complex systems चलाने वाली engineering teams के साथ सहयोग किया गया
- MongoDB के साथ कई वर्षों तक सहयोग कर core server software और WiredTiger storage engine testing में मदद की
- Ethereum Foundation के साथ Merge से लगभग 1 साल पहले से सहयोग कर Merge testing में मदद की, और आज भी collaboration जारी है
- Palantir के साथ भी collaboration चल रहा है
दुर्लभ bugs के tool से continuous testing service तक
- शुरुआती customers Antithesis को सबसे मुश्किल और जोखिम भरे bugs खोजने और reproduce करने वाले special forces tool की तरह इस्तेमाल करते थे
- Platform अधिक mature और interactive होने के साथ latest builds को continuously test करने वाली always-on service में बदल गया
- लक्ष्य bug introduce होने के समय से उसके discover होने तक का समय कम करना है
- FoundationDB development के समय इस तरीके ने bug diagnosis और fixes को कहीं ज्यादा आसान बनाया, और efficiency तथा software quality बढ़ाई
- Antithesis distributed systems चलाने और reliability व engineering productivity को महत्व देने वाले organizations से बात करना चाहता है
- कठिन समस्याओं पर काम करना चाहने वालों के लिए job openings की ओर इशारा करता है
1 टिप्पणियां
Hacker News की राय
लगता है कि “लेजेंडरी 10x डेवलपर” का मतलब बिगड़कर ऐसे व्यक्ति तक सिमट गया है जो हफ्ते में 6.5 दिन, रोज़ 15 घंटे काम करके burnout हो जाता है
असली 10x, या 50x प्रोडक्टिविटी उन लोगों से आती है जो ऐसी चीज़ें बना देते हैं जिन्हें लगभग कोई संभव नहीं मानता या समझता नहीं, और जिनकी वजह से काम करने वाला software बहुत कम समय में बनाया जा सकता है
मैनेजर अक्सर 8 घंटे के काम को 12 घंटे में करने वाले व्यक्ति पर, वही काम 8 घंटे में खत्म करने वाले व्यक्ति से ज़्यादा ध्यान देते हैं
और ‘नॉर्मल’ से हटकर कोशिशों को भी अच्छा नहीं माना जाता, साथ ही process सुधारने का समय schedule में होता ही नहीं, इसलिए ऐसी स्थिति में जहाँ बस बाल्टी तेज़ी से ढोने को ही समाधान माना जाता है, वहाँ ठेला बनाना हतोत्साहित किया जाता है
इसलिए 10x engineer जैसी चीज़ सच में मौजूद है। 30 साल की उम्र तक उनके पास 10 नहीं, लगभग 20 साल का programming अनुभव होता है
उनके पास काम का अनुभव भी बहुत ज़्यादा होता है। 15 साल की उम्र में भले शुरुआत रिश्तेदारों के काम में इक्का-दुक्का अजीब assignments से होती हो, लेकिन 18 तक वे किसी professional company में जाकर computer science की पढ़ाई के साथ काम भी करते हैं
कम से कम पहले ऐसा होता था। 2004 से लेकर लगभग 2018 तक तो यह हकीकत थी, लेकिन आज के hiring माहौल में यह अभी भी संभव है या नहीं, पता नहीं
10x engineer के अस्तित्व के लिए बस कुछ उदाहरण ही काफी हैं। लगता है ज़्यादातर लोग मानते हैं कि वे दुर्लभ होते हैं, और सार्वजनिक रूप से दिखने वाले 10x engineer के उदाहरण के तौर पर इस व्यक्ति का नाम लिया जा सकता है। वे खुद कभी ऐसा नहीं कहेंगे, लेकिन मेरा अंदाज़ा है कि वे 10x engineer हैं https://bellard.org/
अगर आप सहमत नहीं हैं तो किस बात पर अलग सोचते हैं, यह जानना चाहूँगा। मैं तो बस अंधों और हाथी वाली स्थिति में थोड़ा-सा हिस्सा छू रहा हूँ, यह दावा नहीं कर रहा कि पूरी तस्वीर देख रहा हूँ
हर चीज़ अकेले कर लेने वाला one-man army डेवलपर उन टीमों के लिए ठीक fit नहीं होता जहाँ काम standardized, छोटे हिस्सों में बँटा और distributed होता है
ऐसे लोग तब सबसे अच्छा काम करते हैं जब वे बिना बाधा डालने वाले सहकर्मियों या managers के अपना project कर रहे हों, लेकिन ज़्यादातर workplaces ऐसे नहीं होते
टीम का हिस्सा बनते ही, चाहे कोई कितना भी शानदार हो, वह अकेले बहुत ज़्यादा काम नहीं कर सकता, और आखिर में उसे धीमे या कमज़ोर teammates द्वारा बनाई गई समस्याएँ या management की दिक्कतें संभालनी पड़ती हैं। इसलिए टीम, चाहे उसमें rockstar हो, चलती सबसे निचले common denominator की रफ्तार से ही है
यह भी मदद करता है कि हम internal tools बना रहे हैं और process व stakeholders के बहुत करीब हैं
“हम्म, इसे हासिल करने का कोई दूसरा तरीका है” — यही 10x वाली बात है, सिर्फ़ तेज़ी से करना उसका मूल नहीं है
यह शायद अब तक पढ़े गए सबसे बेहतरीन intro posts में से एक हो सकता है
यह अच्छी तरह आधार तैयार करता है कि लोग कौन हैं और उन्होंने क्या बनाया, और यह भी समझाता है कि वे अभी जो बना रहे हैं, वह पहले बनाई गई चीज़ों का नतीजा है
यह एहसास होता है कि वे इस समस्या को सबके लिए हल करना चाहते हैं, शायद इसलिए कि वे खुद पहले ही इस solution की गुणवत्ता का अनुभव कर चुके हैं
इसके बाद वे उन teams को भी दिखाते हैं जिन्होंने इसे पहले इस्तेमाल किया है, और उनमें काफ़ी बड़े नाम शामिल हैं जिनके systems जटिल हैं
यह सब developer और founder दोनों को appeal करने वाली अच्छी writing में पैक है, और landing page भी शानदार है
मैं कुछ वास्तविक use cases और examples देखना चाहता था
उसकी जगह कुछ बड़ी companies के नाम गिना दिए गए, फिर दावा किया गया कि यह कोई जादू की तरह काम करने वाला innovative product है, और उसके बाद ‘10x programmer’, ‘stealth mode’ जैसे घिसे-पिटे buzzwords डाल दिए गए। ग्राहक नाम सार्वजनिक करके stealth mode कहना आपस में मेल नहीं खाता
यह ऐसी जीवनशैली, सोचने के तरीके और काम करने के तरीके का एहसास देता है जिसे मैंने अब तक अनुभव नहीं किया, इसलिए वह solution चाहने का मन करता है
linked लेख में असल में क्या बनाया गया है, यह बताने से पहले 3/4 हिस्सा इतिहास और background पर ही है
यह वैसा है जैसे आपको vegan pancakes बनानी हों, लेकिन recipe blog पहले लेखक के बचपन की कहानी सुनाकर परेशान करे
यह एक बढ़िया pitch है, और मैं नकारात्मक नहीं दिखना चाहता, लेकिन मुझे लगता है कि “सभी bugs ढूंढ लिए” जैसी पंक्ति तभी सच हो सकती है जब bug की परिभाषा बहुत संकीर्ण रखी जाए
अब तक जिन सबसे खराब और ढूंढने में सबसे मुश्किल bugs का सामना मैंने किया है, वे error state में गिरने की बजाय application की business logic के आसपास थे
उदाहरण के लिए, database में ग्राहक का completed transaction दर्ज है, लेकिन completed purchase items नहीं हैं, तो ग्राहक के recent transactions page पर इसे कैसे दिखाया जाना चाहिए—ऐसी समस्या
ऐसे मामलों में “कुछ दिखे और crash न हो” लागू करना और यह सुनिश्चित करना कि वह पूरे stack में बाकी विकल्पों के संदर्भ में वास्तव में समझ में आने वाला विकल्प है, दोनों बहुत अलग बातें हैं
database में भी “query planner इस edge case में बहुत अप्रभावी plan बनाता है” जैसी समस्याएँ होती हैं
इस तरह की चीज़ों का automatic detection संभव नहीं है। क्योंकि यह program के error state तक पहुँचने की समस्या नहीं, बल्कि सबसे पहले application में ‘correctness’ क्या है, यह समझने की समस्या है
हो सकता है मैं bug के लिए मानदंड बहुत ऊँचा रख रहा हूँ, लेकिन 0 bugs की कल्पना करना और वास्तविक दुनिया में software बनाना अलग बातें हैं। फिर भी 0 runtime errors हो तो मैं उसे मान सकता हूँ
फिर भी यह सच है कि FoundationDB testing practices की सीमा को आगे बढ़ाने के लिए वास्तव में मशहूर है: https://apple.github.io/foundationdb/testing.html
आम तौर पर यह अहंकारी या overconfident लगता, लेकिन यहाँ वे सच में zero bugs के बहुत करीब पहुँचे थे
बेशक, किसी negative proposition को prove नहीं किया जा सकता, लेकिन ऐसी “सब green” स्थिति तक पहुँचना इस बात का बड़ा भरोसा देता है कि आप एक मजबूत नींव पर बना रहे हैं, और समय के साथ यह सच भी साबित हुआ
business logic के आसपास की समस्याएँ system की failure नहीं हैं; system ने spec के अनुसार काम किया, बस spec पर्याप्त रूप से व्यापक नहीं था, इसलिए अब उसे iterate करके सुधारा जा सकता है
जाहिर है, बहुत से software में documentation की कमी होती है, और वह documentation bug है
फिर भी यह परिभाषा इसलिए अच्छी है क्योंकि documentation अधूरी होने पर भी यह पूछने पर मजबूर करती है: “क्या हम सच में इस behavior को document करेंगे, या behavior बदलकर उसे document करेंगे?”
कम-से-कम मेरे लिए इससे अजीब behavior को बस ढककर आगे बढ़ जाना कठिन हो जाता है
sledsimulation guide https://sled.rs/simulation.html से इस क्षेत्र के बारे में जानने के बाद से मेरी इसमें बहुत रुचि हो गई है। वह लेख मोटे तौर पर दिखाता है कि FoundationDB यह कैसे करता हैअभी मैं अपनी नौकरी में इसी तरह की testing अपनाने की कोशिश कर रहा हूँ, और service को
madsimhttps://github.com/madsim-rs/madsim?tab=readme-ov-file#madsim के ऊपर चलने लायक लिख रहा हूँइससे हम tokio में async/await शैली की services लिखना जारी रख सकते हैं, और testing में उसे ऐसे deterministic executor में बदल सकते हैं जो operating system calls पर निर्भरता सहित non-determinism के हर स्रोत को patch कर दे। यह काफ़ी smoothly काम करता है
इस लेख के लेखक ने जब कहा कि शुरुआती लागत बहुत बड़ी होती है, तो वह कोई अतिशयोक्ति नहीं थी। non-determinism के हर संभव स्रोत को संभालना, और service को testable तथा sans-IO https://sans-io.readthedocs.io/ रूप में फिर से लिखना, इसमें बहुत engineering effort लगता है
लेकिन एक बार system तैयार हो जाए, तो code के बारे में जो confidence महसूस होता है, उसे शब्दों में समझाना मुश्किल है। quickcheck https://github.com/BurntSushi/quickcheck?tab=readme-ov-file#quickcheck जैसे tools के साथ मिलाकर आप I/O, event ordering, timeouts, packet loss, filesystem failures जैसी सैकड़ों हज़ार सूक्ष्म failure cases को test कर सकते हैं
अगर आपके पास निवेश करने लायक धैर्य और दृढ़ता है, तो इस तरह की testing toolkit में रखने लायक एक बेहद शक्तिशाली tool है
Antithesis खुद भी बहुत शानदार लगता है। deterministic testing को operating system के नीचे की layers तक ले जाना कमाल की बात है, और शायद इससे बिना हर बार manually harness जोड़े पूरे system को test करना संभव हो जाएगा। मैं इसे आज़माने के लिए उत्सुक हूँ
ऐसे systems में जो जटिलता मैंने देखी है, उसका बड़ा हिस्सा इस बात से आता है कि “function” call asynchronous है, operating system पर निर्भर है, कभी न कभी चल सकता है या शायद कभी चले ही नहीं, strings का एक गुच्छा लौटाता है जिसे static type system में वापस लाने के लिए parse करना पड़ता है, और उसके अपने failure modes होते हैं
logic को named components, यानी functions, के रूप में abstract करने जैसा ऊपर से सरल दिखने वाला काम अत्यंत जटिल हो जाता है
अगर logic को उसी process के भीतर रखा जाए और बस functions call किए जाएँ, तो ऊपर बताए गए सूक्ष्म failures को test करने की ज़रूरत ही नहीं पड़ती
ऐसा नहीं कि monolith हमेशा अच्छा या सही विकल्प है, लेकिन service-based software architecture का मौजूदा trend वाकई उचित है और उसके बदले मिलने वाला लाभ पर्याप्त है या नहीं—इस पर मुझे गहरा संदेह है
और यह भी कि क्या Rust इस्तेमाल करने वाली कंपनियाँ वास्तव में इस तरह develop कर रही हैं
अतिरिक्त रूप से, TigerBeetle भी ऐसा ही लिखा गया product है
madsimया deterministic simulation testing जैसा कुछ मौजूद हैलेख वाकई बहुत दिलचस्प है
"इस स्थिति में programming करना ऐसा है जैसे हर तरह के नुकसान से बचाने वाले force field से घिरकर जीना... हम यह कह सकते हैं, और सबूत के साथ कह सकते हैं, कि क्योंकि bugs थे इसलिए हमने Zookeeper समेत सभी dependencies हटा दीं, बहुत कम समय में खुद Paxos implementation लिखी, और उसमें bugs नहीं थे" — ऐसा कह पाना सच में कमाल की बात होगी
उस किताब में कहा गया है कि numerical software packages के bugs की वजह से अपनी समस्या हल करते-करते दूसरे के software को debug करना इतना परेशान करने वाला होता है कि linear algebra packages को छोड़कर वे आम तौर पर चीज़ें खुद बनाते हैं
उससे भी ज़्यादा सिरदर्द वाली बात यह मानी गई है कि packages समस्या के formulation की खामियों को छिपा देते हैं। अगर आप equations के एक set को solver में डालते हैं, तो खराब conditioning या अनपेक्षित singularity की वजह से जवाब physical reality से अलग हो सकता है, फिर भी वह आम तौर पर बिना शिकायत एक solution दे देगा, और अगर वह किसी बड़े program में दबा हुआ हो तो ऐसी संभावना को नज़रअंदाज़ करना आसान हो जाता है
संदिग्ध behavior दिखने पर भी package के अंदर जाकर समस्या की तह तक पहुँचना मुश्किल होता है, इसलिए आखिर में खुद दोबारा programming करनी पड़ती है; और अगर शुरुआत से ही ऐसा किया होता, तो शायद समस्या की वास्तविकता में गहराई से उतरते हुए logical confusion पहले ही दूर हो गया होता
आखिरकार यह इस पर निर्भर करता है कि आप खुद कितने rigorous हैं, कोई खास dependency कितनी rigorous है, और आपके पास कितना समय है। मैं database खुद नहीं लिखूँगा, क्योंकि वह बहुत जटिल है और अच्छे से tested विकल्प बहुत हैं। लेकिन अगर किसी छोटे package की सिर्फ कुछ functionality इस्तेमाल करनी हो, और उसका testing कमज़ोर हो, तो उसे खुद बनाना समझदारी हो सकती है
हालाँकि मैं यह दावा नहीं करता कि मेरी spec में bug नहीं है
मेरे मन में तीन बातें आती हैं
पहली, यह सही समय पर आया एक शानदार idea है। fuzzers, static typing, memory safety, standardized protocols, containers वगैरह को लेकर developers की भावना देखें, तो लगता है कि लोग आखिरकार unstable software के प्रति धैर्य खो रहे हैं
दूसरी, यह शायद niche market को निशाना बनाता है। कीमत CPU पर प्रति घंटा 2 डॉलर है, reservation पर CPU के हिसाब से सालाना 7000 डॉलर, hobby या free·open source के लिए कोई free tier नहीं है, और trial या खरीद भी सिर्फ inquiry के बाद ही संभव है। दर्दनाक है, लेकिन valid business model है। फिर भी यह अफ़सोस की बात है कि इसका लक्ष्य अधिकतम सकारात्मक प्रभाव नहीं लगता
तीसरी, लेखन और documentation की quality बहुत अच्छी है, और documentation में "अगर bug production या customer के यहाँ मिले, तो आपको हमसे explanation माँगनी चाहिए" जैसी पंक्तियाँ होना सच में पसंद आया
developers का दिल जीतने का तरीका यही है। इससे मुझे Mullvad याद आता है, जिसे मुझसे निराशा होने के बाद भी मैं आज तक लोगों को recommend करता हूँ
इसका ज़िक्र https://news.ycombinator.com/item?id=39358526 में किया गया था। संदर्भ के लिए, मैं Antithesis का co-founder हूँ
hardware भी इसे support करने वाले features जोड़ना शुरू कर सकता है, और 30 साल बाद शायद यही computing के काम करने का सामान्य तरीका बन जाए
लेकिन pioneers इसे सच में फैलाने से पहले, पहले लगे हुए तीरों की कीमत वसूलना चाहेंगे। इसे किसी एक घटना की तरह नहीं, बल्कि एक प्रक्रिया की शुरुआत की तरह देखना चाहिए
documentation के अनुसार, यह platform जिन bugs को ढूँढने के लिए बना है, वे वे खुरदरे, "reproduce नहीं होने वाले" प्रकार के bugs हैं जो production में बहुत कम सामने आते हैं
ज़्यादातर teams को इससे कहीं बड़े मुद्दे और साफ़ bugs ठीक करने होते हैं। सच कहें तो आज की production software का बड़ा हिस्सा मुश्किल से unit tests तक रखता है
असली use cases में लागत कैसे multiply होती है, यह जानने की जिज्ञासा है
इस साल Strangeloop में मेरी Antithesis से मुलाकात हुई और मैंने वहाँ के कर्मचारियों से बात की; Amazon में काम करते समय जिस automatic fault injection को मैं follow करता था, उसकी latest state की तुलना में भी यह product आज इस्तेमाल होने वाले कई formal verification systems से बहुत बड़ी छलाँग लगता है
मैंने वास्तव में Apache Spark streaming में इनके द्वारा खोजे गए issue की bug-tracking प्रक्रिया को follow किया। documentation के आधार पर देखें, तो इन्होंने आम कामकाज में subtle और nasty correctness errors खोजे, जो low-visibility edge cases में सालों तक सिरदर्द बने रह सकते थे
आखिर में निकला कि documentation ही गलत थी, लेकिन वह प्रक्रिया देखने के बाद यह कल्पना करना भी मुश्किल है कि distributed systems बनाने वाली कंपनियों के भीतर Antithesis जैसे tools कितने अहम हो सकते हैं
अच्छा होगा अगर जल्द ही technical details में गहराई से जाने वाली कोई blog post आए। मैं सुनना चाहूँगा कि वे अपने मौजूदा approach तक कैसे पहुँचे
मैं तुरंत hype cycle में कूदना नहीं चाहता, लेकिन यह holy grail जैसा लगता है। मौजूदा application को जैसा है वैसा इस्तेमाल करना, और अगर वह containerized है, तो बस उसके ऊपर properties check करना — क्या बात इतनी ही है?
जहाँ मैं हमेशा अटका, वह machine की foundation थी, यानी non-deterministic CPU और operating system
पूरे vertical computing stack को फिर से बनाना व्यावहारिक रूप से असंभव है, इसलिए इन्होंने high-fidelity deterministic simulator बनाकर उस समस्या को दरकिनार किया है
लेकिन simulator और मौजूदा operating system के बीच equivalence को ये कैसे check करते हैं, यह जानने की जिज्ञासा है। यह मामूली काम नहीं लगता। फिर भी इस idea ने मुझे काफ़ी हद तक convince किया है
उसके बाद वे operating system failures, network issues, race conditions और timing conditions, random number generator की समस्याएँ, और तरह-तरह की failures inject करते हुए tests चलाते हैं
आज की तारीख में इस तरह की चीज़ों को भरोसेमंद ढंग से test करने का शायद यही इकलौता practical तरीका है, लेकिन फिर भी आपको सारे tests लिखने होंगे और application state define करनी होगी
“सॉफ़्टवेयर लेकर उसके अंदर के bugs का शिकार करने वाला platform” कहा गया है, तो असल में यह क्या है?
यह integration tests चलाने वाली cloud service जैसा दिखता है। लगता है कि इस खास environment में deploy करने का तरीका समझना होगा, और special libraries का इस्तेमाल करके integration tests भी फिर भी लिखने होंगे
लेकिन अगर इस तरह पूरा integration refactoring भी कर लिया जाए, तब भी यह उन वास्तविक bugs को कैसे ढूंढेगा जिन्हें मेरे environment में मेरे integration tests पहले से नहीं ढूंढ पाए, यह समझ नहीं आ रहा
हालांकि Antithesis manual testing या integration tests लिखने की मांग नहीं करता
software system को containers में package करना होता है, जो काफ़ी सरल है, और उसके बाद system के सामान्य व्यवहार की नकल करने वाला workload लिखना होता है। उदाहरण के लिए, अगर यह एक e-commerce site है, तो product browse करना, cart में जोड़ना, checkout करना आदि
इसके आधार पर Antithesis workload चलाता है, inputs बदलता है, faults inject करता है, और software को test करके test property violations ढूंढना शुरू करता है
crashes, out-of-memory जैसी 60 से ज़्यादा test properties default रूप से दी जाती हैं। system-विशेष समस्याओं को और स्पष्ट करने के लिए custom properties भी define की जा सकती हैं, और वास्तव में ऐसा करना चाहिए
test चलते समय property violations report किए जाते हैं, और उनमें काफ़ी उपयोगी debug जानकारी शामिल होती है। खास तौर पर दिलचस्प test runs पर rewind करना, inputs बदलना, artifacts सुरक्षित करना, logging जोड़ना आदि संभव है, इसलिए काफ़ी अतिरिक्त analysis किया जा सकता है
अभी तक मुझे बस इतना ही पता है। मेरा अनुमान है कि इसमें किसी तरह का fuzzing, static analysis, या software द्वारा किए जा सकने वाले व्यवहार की परिभाषा शामिल होगी
सच कहूँ तो यह काफी हद तक उस चीज़ से मिलता-जुलता लगता है जिसे Vale language हल करने की कोशिश कर रही है: https://vale.dev/
लेकिन नई language बनाकर नए software को शुरुआत से ही उस अवस्था में लाने के बजाय, यह मौजूदा software को उस अवस्था के करीब लाने पर ज़्यादा केंद्रित लगता है
hypervisor का उपयोग करके random seeds बदले जाते हैं, HTTP requests को fail कराया जाता है या उन्हें धीमा किया जाता है, servers के बीच connections काटे जाते हैं, server responses का क्रम बदला जाता है, यानी ऐसी तमाम चीज़ें पैदा की जाती हैं जिन्हें आप आम तौर पर control नहीं करते लेकिन जो वास्तविक दुनिया में होती हैं
फिर expected workload responses से तुलना करके यह पता लगाया जाता है कि कौन-सी conditions system को तोड़ देती हैं
इसलिए इसे annual contract पर बेचा जाता है। यानी आप यह खर्च देते हैं कि workloads पूरे साल लगातार चलते रहें और failures के हर तरह के combinations आज़माएँ
मैं काफ़ी उत्साहित था इसलिए दस्तावेज़ थोड़ा देखा, लेकिन यह randomized unit tests से कैसे अलग है, यह ठीक से समझ नहीं आ रहा
अगर मेरे पास पहले से unit tests का एक संग्रह है, तो क्या वही 99% काम नहीं है? क्या मैं कुछ गलत समझ रहा हूँ?
यह निष्कर्ष मैंने documentation की getting started series, खासकर Workloads section https://antithesis.com/docs/getting_started/workload.html पढ़कर निकाला
How Antithesis Works page देखने पर यह समझने में मदद मिल सकती है कि यह सिर्फ unit tests को bundle करने से कैसे अलग है: https://antithesis.com/docs/introduction/how_antithesis_works.html
संक्षेप में, unit tests workloads बनाने में मदद कर सकते हैं, लेकिन वे ज़रूरी नहीं हैं
हम अलग-अलग inputs और faults आदि लाकर software system के execution paths को स्वायत्त रूप से explore करते हैं, और ऐसे व्यवहार खोजते हैं जिनकी unit test लिखने वाले ने शायद कल्पना भी नहीं की होगी
अगर आपने ऐसी function test लिखी है जो network call करती है और result को disk पर लिखती है, तो test उस स्थिति में fail होगा जब code network call failure या अनिश्चितकाल के लिए hang हो जाने, disk space खत्म हो जाने, या file बंद करने से ठीक पहले power चले जाने जैसी स्थितियों को संभाल नहीं पाता
यानी हाँ, लेकिन यह उस दायरे को, जिसे unit tests की तरह आसानी से test किया जा सकता है, कहीं ज़्यादा दिलचस्प जटिलता के स्तर तक बढ़ा देता है