क्रमिक ऑटोमेशन की कुंजी: Do-nothing स्क्रिप्टिंग (2019)

 (blog.danslimmon.com)
1 पॉइंट द्वारा GN⁺ 2025-02-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ऑपरेशंस टीमों में infrastructure changes या account provisioning जैसी manual procedures (toil) बची रहती हैं जिन्हें पूरी तरह हटाना मुश्किल होता है, और कंपनी के बढ़ने के साथ steps और exceptions बढ़ते जाते हैं
  • हर step automated किया जा सकता है ऐसा लगता है, लेकिन अगर केवल कुछ हिस्सों को script किया जाए तो single-purpose tools बढ़ जाते हैं, और users को फिर भी लंबे procedure documents follow करने पड़ते हैं
  • Do-nothing script असली काम अपने-आप execute नहीं करती; यह procedure के हर step को function में wrap करती है और user को एक-एक step के निर्देश देती है
  • user के current position खोने या step skip करने की संभावना घटती है, और developer के लिए बाद में किसी खास step के guidance text को actual automation code से बदलना आसान हो जाता है
  • तुरंत manual workload कम नहीं होता, लेकिन automation की starting cost घटती है, जिससे समय के साथ toil को क्रमिक रूप से हटाया जा सकता है

जब manual procedures कष्टदायक बन जाते हैं

  • हर operations team में अभी भी ऐसी manual procedures होती हैं जिन्हें automate नहीं किया गया है, और toil का पूरी तरह गायब होना मुश्किल है
  • बढ़ती हुई कंपनी में infrastructure changes या user account provisioning जैसी procedures बड़े toil का केंद्र बन सकती हैं
  • user account provisioning procedure में इस तरह कई steps हो सकते हैं
    • user की SSH key pair बनाना
    • public key को Git में commit करना और master पर push करना
    • build job पूरा होने का इंतज़ार करना
    • employee directory में user का email address देखना
    • 1Password के जरिए user को private key भेजना
  • वास्तविक environment में procedure 20 steps तक बढ़ सकती है, या process के दौरान branches और special cases को लगातार track करना पड़ सकता है
  • ऐसा काम काफी concentration मांगता है, लेकिन दिलचस्प problem solving के बजाय एक और checkbox भरने जैसा होता है, इसलिए यह slog बन जाता है

partial automation से छूट जाने वाली gaps

  • slog automation के लिए अच्छा target लगता है
    • हर step को automate करने का तरीका आसानी से सोचा जा सकता है
    • computers इंसानों की तुलना में instructions को ज्यादा तेज़ और सटीक तरीके से execute कर सकते हैं
    • practical drift होने की संभावना भी कम होती है
  • समस्या यह है कि slog automation अक्सर all-or-nothing जैसा महसूस होता है
  • step 2 या step 5 को handle करने वाली script बनाई जा सकती है, लेकिन पूरी procedure की झंझट बहुत कम नहीं होती
  • single-purpose scripts बढ़ने पर हर tool की conventions और expected behavior अलग हो जाते हैं, और users को फिर भी multi-step documents follow करने पड़ते हैं

Do-nothing script कैसे काम करती है

  • लगभग हर slog को Do-nothing script में बदला जा सकता है
  • core idea यह है कि slog के instructions को code में रखा जाए और हर step को एक function में encapsulate किया जाए
  • example script का flow इस तरह है
    • CreateSSHKeypairStep ssh-keygen command print करता है और user के Enter दबाने तक wait करता है
    • GitCommitStep public key को Git repository में copy करने के बाद git commit, git push चलाने का निर्देश देता है
    • WaitForBuildStep build job URL पर completion का इंतज़ार करने को कहता है
    • RetrieveUserEmailStep directory में email address खोजकर input लेता है और उसे context["email"] में store करता है
    • SendPrivateKeyStep 1Password में private key document बनाने और उसे उस email वाले user के साथ share करने का निर्देश देता है
  • यह script procedure के किसी भी step को वास्तव में perform नहीं करती; यह user को एक-एक step बताती है और manual completion का इंतज़ार करती है

automation तक पहुंचने का रास्ता

  • Do-nothing script पहली नज़र में ऐसा लग सकता है जैसे document पढ़ना और मुश्किल बना दिया गया हो, लेकिन असल में यह workflow को ज्यादा सुरक्षित तरीके से थामे रखता है
    • user के progress position खोने या steps skip करने की संभावना कम होती है
    • concentration बनाए रखते हुए slog को अंत तक पूरा करना आसान होता है
    • हर step function में अलग होने से किसी specific step के text को actual action code से replace किया जा सकता है
    • समय के साथ reusable steps की library बनती है, और बाद की automation work ज्यादा efficient हो जाती है
  • Do-nothing script खुद टीम की manual workload कम नहीं करती
  • इसका असर automation शुरू करना आसान बनाने में है, और इसी आधार पर टीम समय के साथ toil को हटा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-09
Hacker News की टिप्पणियां

  • मुझे यह तरीका वाकई पसंद है
    कुल मिलाकर देखें तो यह किसी प्रक्रिया के आसपास interface परिभाषित करने का एक और तरीका है। वह प्रक्रिया manual हो सकती है या automated, लेकिन interface वैसा ही रह सकता है। इसलिए जब आप steps को automate करते हैं, तो यह काफी शक्तिशाली होता है
    इसे वैसे ही लागू करें जैसे आप किसी दूसरे system पर करते हैं
    पहले मैंने Google Sheets को manually भरना शुरू किया था और बाद में script से automate किया, और Jira ticket बनते ही उसे अपने-आप उठाकर process करने का भी setup किया था। आप जल्दी शुरू कर सकते हैं, सिर्फ सबसे परेशान करने वाले हिस्से को automate कर सकते हैं, और जरूरी नहीं कि पूरी चीज automate करें
    कुछ न करने वाली script का side effect यह है कि उसके documents की तुलना में वास्तव में इस्तेमाल होने की संभावना ज्यादा होती है, इसलिए वह अधिक बार up-to-date रह सकती है

    • मेरी बहुत विनम्र न होने वाली राय में, इस तरह process को धीरे-धीरे script में encode करने से process को निगल जाने वाला system नहीं, बल्कि process-केंद्रित system बनता है
      आम tasks को automate करने वाली scripts की list से मुझे सहमति है। लेकिन जैसे ही वे scripts operational service से call होने लगती हैं, उस spaghetti-जाल को खोलने वाले बदकिस्मत व्यक्ति के लिए भारी technical debt बन जाता है
      आगे चलकर, क्योंकि human-centric process ने system को codify कर दिया होता है, software system के हित में बदलाव—जैसे system को components में बांटना—असंभव हो जाता है। अंततः incremental expansion का मतलब process में और चीजें ठूंसना बन जाता है, और यह script monolith में लगातार जुड़ते रहने वाला self-reinforcing cycle बन जाता है
    • पुराना तरीका ऐसा था: 1) मौजूदा process को जस का तस capture करना 2) उस process को laugh test pass करने लायक बनाना 3) उसे automatable बनाना
      3 और 4 पर काम करते समय process को बार-बार, जितने ज्यादा लोगों से हो सके, इस्तेमाल करवाएं, और real-world में दिखने वाले misuse के हिसाब से process को adjust करें
      4) process को automate करें
      1 और 2 से हर कोई सहमत होता है, और ज्यादातर लोग आखिरकार 4 पर भी साथ आ जाते हैं, लेकिन 3 करने से 4 की मांग और समझ रखने वाले लोग ज्यादा हो जाते हैं
      हालांकि इस approach की सीमा यह है कि अगर process की शुरुआत या अंत को automate किया जा सके तो ठीक है, लेकिन अगर बीच में islands की तरह अलग-अलग दो automation points हों, तो यह prompts वाले command-line tool से बेहतर नहीं है
    • सही है। मेरे लिए यह Jupyter notebooks इस्तेमाल और share करने का एक और मौका भी है
      बस करने वाले कामों को समझाएं, boilerplate या examples और parameterized executable दें
      Notebooks को असल में documentation system की तरह इस्तेमाल करना शानदार होगा। बस Confluence जैसे cloud SaaS के ऊपर layer के रूप में रखना बहुत भारी है, और मौजूदा रूप में permissions escalation जैसी समस्याओं की गुंजाइश भी बहुत ज्यादा है
    • “Zen and the Art of Motorcycle Maintenance” वाला पहाड़ दिखना शुरू हो रहा है
      यह approach Confluence guide page को आधा interactive walkthrough बना देता है। यह conscious side है
      दूसरी तरफ test automation है। शुरुआत में यह overfitted XPath के ढेर और undocumented steps से शुरू होता है। application बदलते ही वे steps फिर से खोजने पड़ते हैं। यह unconscious side है
      उम्मीद है कि हम शिखर तक पहुंचें और तेजी से execute करें, फिर भी यह समझते रहें कि वहां तक कैसे पहुंचे और ऐसा क्यों हुआ
    • जो काम पहले से commands से हो सकते हैं, उन्हें script सीधे कर दे तो अच्छा होगा
      user से Execute command (y/N)? जैसा confirmation ले लिया जाए
      एक terminal से दूसरे terminal में copy-paste करना मुझे सच में नापसंद है। वह भी काफी ध्यान खा जाता है
      user से सिर्फ वे manual tasks पूछें जो अभी command नहीं हैं: Look up the e-mail address for foo. Paste it here: या Put that shit in 1Password: Are you done (y/N)?

  • दिलचस्प approach है
    लेकिन example में दिया गया काम सिर्फ यह दिखाता है कि उस company का SSH keys जारी करने का तरीका कितना insecure था। वास्तव में users को खुद private key generate करनी चाहिए, और access देने के लिए सिर्फ public key system administrator को देनी चाहिए—ऐसा सिखाया जाना चाहिए। किसी भी point पर system administrator के पास private key की copy नहीं होनी चाहिए, अस्थायी रूप से भी नहीं। इसलिए 1Password वाला step होना ही नहीं चाहिए
    वैसे, मैं github-keygen का author हूं, जो GitHub access के लिए dedicated SSH key बनाने और उस context की SSH configuration automate करने वाला tool है
    https://github.com/dolmen/github-keygen

    • inexperienced users से अपनी keys खुद manage करवाना भी बहुत secure नहीं लगता। इसलिए इसे script में ले जाना ही मुख्य बात है
    • users को खुद private key generate करनी चाहिए और सिर्फ public key system administrator को देनी चाहिए वाला step implement करना हमेशा झंझट भरा रहा है
      हम SSH में certificate-based authentication पर चले गए, और अब public keys इधर-उधर नहीं ले जाते। पूरी process सच में काफी सरल हो गई है
    • क्या यह सच में baseline है? आखिर IT वैसे भी private key वाली work machine के हर हिस्से का मालिक नहीं होता? मुझे पता है passwords अलग हैं, लेकिन private key तो machine में stored रहती है

  • यह लेख पहली बार प्रकाशित होने के करीब 1 साल बाद आखिरकार मैंने इस तरीके को आज़माया
    हमारे toolchain के एक bug की वजह से hotfix के लिए runbook सामान्य release process से लगभग दोगुना जटिल था
    उसे उतनी सराहना नहीं मिली, लेकिन पहले जो चीज़ केवल sev 1 issues या अंतिम चरण के epic कामों में लगभग हर 10 हफ्ते में एक बार इस्तेमाल होती थी, वह औसतन हफ्ते में 1 बार, और कुछ हफ्तों में 3 बार तक इस्तेमाल होने लगी। अब हर चीज़ को feature toggle बनाना ज़रूरी नहीं रह गया, इसलिए हम technical debt में कहीं ज़्यादा गहराई तक जा पाए
    अगर आप छोटी कंपनी हैं और production data को pre-production environment में replicate करना आसान है, तो शायद आपको ऐसे नतीजे न दिखें। लेकिन जिन endpoints से हम बात करते थे वे 150 से ज़्यादा थे, और मेरे हिसाब से प्रति service औसतन करीब 3 थे। datasets बहुत ज़्यादा थे, और उनमें से कुछ Kafka के आने से पहले Kafka जैसी किसी पद्धति से इकट्ठे किए गए थे
    production data को replicate करने की कोशिश करने वाला सिर्फ एक व्यक्ति था, और उसके पास भी समय और ऊर्जा की कमी थी, इसलिए वह साल में सिर्फ एक-दो बार ही कर पाता था। यह रफ्तार customers और features के बदलने की रफ्तार से बहुत धीमी थी। अंततः हमें blue-green deployment process और jmeter के साथ प्रयोग करते हुए यह पता लगाना पड़ा कि हम कितने करीब हैं, और live जाने से पहले success/failure कैसे मापेंगे
    आखिरकार लोगों को रोकने वाली चीज़ छोटा-छोटा और गलती-प्रवण build process था, और जब मैंने उसे आधा-automate किया तभी रास्ता खुला
    बाद में usage बढ़ने पर मैंने manual steps के सभी URLs ढूंढकर tool के अंदर lookup table में डाल दिए, और उन्हें release approval के सामान्य verification process में भी expose कर दिया। इससे coordinator थोड़ा तेज़ और कम stress में हो गया। वह process इतना झंझट वाला था कि बोझ बांटने के लिए तीन teams बारी-बारी से उसे संभालती थीं

  • “काम automation की activation energy कम करना” क्या अंततः यह मतलब रखता है कि कुछ न करने वाली script में बाद में सचमुच कुछ automate करने वाले steps जुड़ जाते हैं?
    अगर इसे भविष्य के automation के लिए placeholder माना जाए, तो यह automation और efficiency के बीच सही संतुलन जैसा लगता है। बिना बहुत ज़्यादा निवेश किए पहली कोशिश की जा सकती है, और बाद में जब effort की value ज़्यादा स्पष्ट हो जाए तो निचले लटके फल के रूप में करने लायक काम बचा रहता है

    • सही
      procedure का हर step अब function में encapsulate है, इसलिए किसी खास step के text को उस code से replace किया जा सकता है जो सच में वह action automatically करता है

  • class Foo(object): def run(self, context): ...
    सिर्फ एक execution method वाला object Python में पहले से built-in है। वही function है
    def foo(context): ...

    • लेकिन रोज़ाना एक बार पूरी तरह टूटी हुई abstraction निगले बिना इंसान ज़िंदा कैसे रहेगा?
    • मूल approach का फायदा यह है कि बाद में ज़रूरत पड़ने पर आप उसी class से जुड़ी private methods बस और जोड़ सकते हैं
      function approach में अगर नया function चाहिए तो उसे global level पर जोड़ना पड़ता है। एक-दो हों तो बिल्कुल ठीक है, लेकिन ज़्यादा होने पर उसी level पर functions की भरमार हो जाती है और उनके बीच की dependencies अब साफ़ नहीं रहतीं
    • Brain Will का https://www.youtube.com/watch?v=QM1iUe6IofM याद आता है। ऐसे topics पर उनकी लगभग शिकायत करने वाली एक series है
      उनमें से एक में अनावश्यक रूप से abstract किए गए code को simplify करने के examples हैं

  • शानदार है, लेकिन इसे interrupt नहीं किया जा सकता
    अच्छा होगा कि पहले से सभी steps दिखाए जाएं, और आगे बढ़ते हुए हर item को check किया जाए। कभी-कभी बड़े perspective से सच में तैयारी करना बेहतर होता है
    summary को file में log के तौर पर भी छोड़ा जा सकता है
    सुधारने को इतनी चीज़ें हैं कि शायद सबसे simple solution ही best हो

    • बेहतर command-line library इस्तेमाल करें तो checklist और हर step का execution output दिखाया जा सकता है। कोई step automate हो या न हो, यह ठीक तरीका है
      हालांकि कुछ न करने वाली shell script शुरू करना इतना आसान है कि उसे अंत तक न बनाना मुश्किल है। वह effort शायद किसी एक step को automate करने में लगाना बेहतर हो सकता है। आप किस TUI library का इस्तेमाल करें, structure कैसे रखें जैसी मज़ेदार लेकिन बहुत productive नहीं वाली दलदल में फंस सकते हैं
    • “interrupt नहीं किया जा सकता” वाली बात देखकर अच्छा लगा। इसलिए मैं Bash script की जगह Makefile इस्तेमाल करता हूं
      हर step *.done नाम का rule होता है, और पूरा होने पर .done file बनाता है। आप कभी भी interrupt कर सकते हैं, कुछ fix करने के लिए script बदल सकते हैं, और फिर make से resume कर सकते हैं
      लेकिन वह Makefile लिखना सचमुच दर्दनाक है। क्या कोई बेहतर solution है?
    • ऐसी चीज़ बनाते समय मैं interrupt करने लायक बनाने के लिए persistent state छोड़ता हूं। जैसे अगर यह annual task है तो ./do-the-thing.sh 2025 की तरह चलाता हूं, और 2025 directory बनाकर यह state रखता हूं कि कहां तक किया है
      first step approve होने पर 2025/first-step file को touch कर सकता हूं। अगर script मर जाए या interrupt हो जाए और फिर से चले, तो वह file check करके first step skip कर देती है
      जब कुछ बदल जाए और automation काम न करे, तो state खोए बिना बाहर निकलना, script fix करना और फिर से run करना अच्छा होता है
      आमतौर पर मैं script को सिर्फ अगला manual step बताने और exit करने देता हूं। इससे terminal दूसरे कामों के लिए इस्तेमाल किया जा सकता है। command history से script को आसानी से फिर से run किया जा सकता है
    • क्या यह सच में लेख की आलोचना है? और आप conclusion छोड़े बिना चले गए। कौन-सा solution “सबसे simple solution” है?
    • मैंने ऐसी ही script इस्तेमाल की है, और अगर गलती से गलत email address डाल दें तो “अब क्या करें?” वाली स्थिति बन जाती है। क्या पूरी script फिर से शुरू करनी पड़ेगी? script में फंस जाना दर्दनाक हो सकता है

  • पिछली discussions भी हैं। comments बहुत हैं
    https://news.ycombinator.com/item?id=29083367 - 3 साल पहले, 230 comments
    https://news.ycombinator.com/item?id=20495739 - 6 साल पहले, 124 comments

  • मुझे यह approach कितनी पसंद है, इसे बढ़ा-चढ़ाकर कहना भी मुश्किल है
    मैंने इसे कई projects में सफलतापूर्वक apply किया है। मेरा पसंदीदा example 3 करोड़ डॉलर का surgical robot है जो “human factors” की वजह से lab testing में fail हो रहा था

    • अगर आप एक या उससे ज़्यादा examples थोड़े विस्तार से share कर सकें, या अपने experience और tips summarize कर सकें, तो अच्छा होगा। यहां हो या blog post, मैं पढ़ना चाहूंगा
      मैं अलग field, legal practice, में हूं, लेकिन सोचना चाहता हूं कि हमारी company में इस approach को कैसे लागू किया जा सकता है

  • यह approach अच्छी है। एक निश्चित स्तर से ज़्यादा complexity वाले programming language-based systems में भी मुझे पहले से ही ऐसा ही कुछ करना पसंद है। functional programming की तरफ़ इसे शायद holes कहा जाता है
    interface में not implemented error भी मिलती-जुलती logic follow करता है, लेकिन मेरा मानना है कि आपस में dependent कई pieces में से हर एक के लिए कोई छोटा-सा ऐसा हिस्सा लिखना, जो meaningful न हो लेकिन valid output दे, काफ़ी valuable है। इससे उन pieces को बनाने की प्रक्रिया तेज़ हो जाती है, और एक-एक करके test करने और बनाने की संभावना कहीं ज़्यादा बढ़ जाती है। test शुरू करने से पहले कई parts को एक साथ लिखने की ज़रूरत कम हो जाती है
    article में बताए गए use case की तरह, script के context में कभी-कभी इस तरह की type-level validity महत्वपूर्ण होना मुश्किल हो सकता है। क्योंकि command line के effects functional नज़रिए से काफ़ी हद तक side effects ही होंगे। लेकिन sequentially आगे बढ़ने की वजह से impact काफ़ी छोटा रहता है, और waiting prompt के कारण script के बिना वैसे भी करने पड़ने वाले manual steps को थोड़ी-सी cost पर बनाए रखते हुए काम का क्रम preserve किया जा सकता है
    scaffolding अधूरी होती है, लेकिन बुनियादी तौर पर उपयोगी होती है

  • Theory में अच्छा है, लेकिन practice में मुश्किल लगता है
    अगर operations team वही काम बार-बार कर रही है, और देखती है कि do-nothing script सच में कुछ नहीं करती, तो जैसे ही उन्हें लगे कि steps याद हो गए हैं, या manual करना ज़्यादा तेज़ या ज़्यादा interesting है, वे इसे जल्दी ही इस्तेमाल करना छोड़ देंगे
    मैंने operations teams के लिए काफ़ी automation और documentation लिखी है, लेकिन लोगों से उसे इस्तेमाल करवाना और लगातार इस्तेमाल करवाते रहना हमेशा समस्या रहा है। documentation में बदलाव के लिए भी announcement चाहिए होता था। लोग जैसे ही कुछ करना सीख जाते हैं, बहुत जल्दी documentation पढ़ना बंद कर देते हैं
    perfect दुनिया में यह approach बहुत reasonable है, और personal कामों में मैं भी इसे इस्तेमाल कर सकता हूँ। लेकिन reality लगभग कभी perfect नहीं होती। मैं शायद यह तरीका सिर्फ़ तब अपनाऊँगा जब 90% automate हो चुका हो और सिर्फ़ 1 unresolved step बचा हो। तब भी operations team के कुछ लोग उस manual step को skip कर सकते हैं और मान सकते हैं कि पूरी चीज़ automate हो चुकी magic है

    • आम तौर पर कुछ हिस्सा automate किया जा सकता है, या कुछ manual steps verify किए जा सकते हैं। तब अचानक यह कुछ करने वाली script बन जाती है