डॉक्यूमेंटेशन अस-ए-मैनुअल बनाम डॉक्यूमेंटेशन ए-ए-चेकलिस्ट


17

मैंने अपने विभाग के अन्य लोगों के साथ प्रलेखन, विशेष रूप से, स्तर-विस्तार और आवश्यकताओं के बारे में पूर्व में चर्चा की है। उनके विचार में, प्रलेखन X चीजों के गलत होने पर करने के लिए Y चीजों का एक सरल चेकलिस्ट है।

मैं असहमत हूं। मुझे लगता है कि यह माना जाता है कि आईटी में सभी मुद्दों को आसानी से पुनर्प्राप्ति प्रक्रियाओं के सरल चेकलिस्ट के लिए उबला जा सकता है। मुझे लगता है कि यह स्थिति की जटिलता को पूरी तरह से नजरअंदाज करता है, और जैसा कि विभाग के अन्य लोगों को हमेशा इस मुद्दे के बारे में समझने की गहराई नहीं है (यही कारण है कि मैं दस्तावेज़ लिख रहा हूं - इसलिए उनके पास कुछ संदर्भित करने के लिए है ) कि प्रलेखन में कुछ मूल पृष्ठभूमि सामग्री शामिल होनी चाहिए, जैसे:

  • प्रश्न में (उप) प्रणाली का उद्देश्य
  • क्यों इसे उस तरीके से कॉन्फ़िगर किया गया है
  • सेटिंग्स / प्रक्रियाओं को लागू करने पर होने वाली घटनाओं की उम्मीद
  • संभावित समस्याएं जिनके कारण प्रक्रियाएँ विफल हो सकती हैं

हालाँकि, मुझे इस पर ध्यान नहीं दिया जा रहा है, इसलिए मेरे दस्तावेज़ को फिर से एक ऐसे रूप में लिखना आवश्यक है, जो कहता है कि "स्टेप ABC क्रम में लागू किया गया है जो समस्या X को हल करेगा"। मैं अक्सर विलाप सुनता हूं कि इसे कागज के एक पृष्ठ पर फिट होने की आवश्यकता है। किसी एक पृष्ठ के दस्तावेज़ के माध्यम से, समस्या निवारण सहित, इस तरीके से स्क्वीड एसीएल के विन्यास को समझाने का प्रयास करें। यह सिर्फ आधा दर्जन दस्तावेजों में से एक है जो "चेक लिखे जाने की प्रतीक्षा" कर रहे हैं।

क्या मैं जिस विधि की वकालत कर रहा हूं वह वास्तव में खत्म हो रही है? या क्या वे सही हैं, और मुझे यहां अपने व्यवसाय को ध्यान में रखना चाहिए और बस उन्हें एक साधारण चेकलिस्ट लिखना चाहिए? मेरी चिंता यह है कि आप चाहे कितनी भी अच्छी तरह से एक प्रक्रिया चेकलिस्ट लिख लें, यह वास्तव में एक समस्या को हल नहीं करता है जिसके लिए एक SysAdmin के माध्यम से सोचने की आवश्यकता होती है। यदि आप पुनर्प्राप्ति प्रक्रियाओं की एक चेकलिस्ट बनाने में समय बिता रहे हैं जो समस्या को हल नहीं करता है (क्योंकि दस्तावेज़ के संकीर्ण ध्यान केंद्रित करने के कारण अतिरिक्त कारक हैं जो दस्तावेज़ का हिस्सा नहीं हैं ), और का उद्देश्य दस्तावेज़ को फिर से मैन पेज और विकी और वेबसाइटों को फिर से पढ़ने से बचना था, फिर मैं गतियों से क्यों गुजर रहा हूं? क्या मैं सिर्फ बहुत ज्यादा चिंता कर रहा हूं, या यह एक वास्तविक मुद्दा है?

संपादित करें:

वर्तमान में विभाग में कोई हेल्पडेस्क स्थिति नहीं है। प्रलेखन के लिए दर्शक अन्य व्यवस्थापक या विभाग प्रमुख के लिए होंगे।


1
आपके संपादन के बारे में: यदि आपका विभाग प्रमुख जानकारी के हर बिट को समझना चाहता है, तो वह शायद भारी मात्रा में सूक्ष्म प्रबंधन कर रहा है। आपको यह सुनिश्चित करने के लिए कुछ प्रक्रिया को सुव्यवस्थित करने के बारे में उससे बात करनी चाहिए कि साइट पर कम से कम एक व्यक्ति किसी भी समय दिए गए दस्तावेज़ के साथ काम कर सकता है। ऐसा नहीं कि वह यह सब समझता है।
सर्वरहोर

जवाबों:


11

जब मेरा लेखन होता है तो मैं हमेशा दो तीन सेट लिखने में विकसित होता हूं । सिस्टम के आर्किटेक्चर के बारे में एक MUCH LONGER परिशिष्ट के साथ गेट -एर्ग किया चेकलिस्ट, क्यों चीजों को जिस तरह से किया जाता है, ऑनलाइन आते समय संभावित चिपके बिंदु और अमूर्त डिजाइन मान्यताओं के साथ। संभावित समस्याओं और उनके समाधानों की एक सूची के बाद, एक लंबी प्रणाली के साथ एक प्रणाली कैसे काम करती है, यह इस तरह से क्यों करता है, और सही दिशा में लोगों को इंगित करने के लिए उपयोगी अन्य जानकारी के बारे में जानकारी के बाद कुछ अनूठा होना चाहिए।

मेरी पिछली नौकरी में हमें डॉक्टर लिखने की आवश्यकता थी ताकि स्तर -1 हेल्पडेस्क लोग भी चीजों को वापस ला सकें। इसके लिए आवश्यक जाँच सूची थी, जो आम तौर पर लेखन के 3 महीने के भीतर पुरानी हो जाती थी। हमें जब भी संभव हो समस्या निवारण गाइड लिखने का आग्रह किया गया था, लेकिन जब आकस्मिकता पेड़ को इसमें तीन से अधिक शाखाएं मिलती हैं, तो आप बिना सार जाने उस डॉक को नहीं लिख सकते।

जब मैंने अपनी आखिरी नौकरी छोड़ी , तो मैंने जाने से पहले एक 100 पृष्ठ 'अपनी नौकरी कैसे करें' मैनुअल में बदल दी। इसमें सार तत्व था, डिजाइन दर्शन, साथ ही एकीकरण अंक। चूँकि मैं संभवतः एक और sysadmin के लिए लिख रहा था जो मुझे प्रतिस्थापित करने जा रहा था, मैंने इसका उद्देश्य किसी ऐसे व्यक्ति पर किया जो अमूर्त धारणाएँ ले सकता था और उन्हें ठोस कार्यों में बदल सकता था।


पांच साल बीत चुके हैं और मुझे लगता है कि इस पर मेरी राय कुछ हद तक बदल गई है। चेकलिस्ट के रूप में मैनुअल और दस्तावेज़ दोनों दस्तावेज़ के पदानुक्रम में बहुत मूल्यवान स्थान हैं और दोनों का उत्पादन करने की आवश्यकता है। वे बहुत अलग दर्शकों को लक्षित करते हैं, हालांकि।

चेकलिस्ट के रूप में दस्तावेज

इस तरह के प्रलेखन के लिए लक्ष्य बाजार सहकर्मी हैं जो एक चीज कैसे करना चाहते हैं। वे दो प्रकारों में आते हैं:

  • सहकर्मी जो सिर्फ एक चीज करना चाहते हैं और पंद्रह पेज मैनुअल के माध्यम से अंगूठे लगाने का समय नहीं चाहते हैं और खुद के लिए कदम उठाते हैं।
  • प्रक्रियाएं जो चरणों में काफी जटिल हैं, लेकिन केवल एक बार एक समय में चलने की आवश्यकता है।

अधीरता पहली तरह का ड्राइवर है। हो सकता है कि आपका सहकर्मी वास्तव में यह जानना नहीं चाहता हो कि आउटपुट को 90 कैरेक्टर पर्ल रीजेक्स के माध्यम से क्यों पाइप किया जाना है, बस टिकट को बंद करने के लिए यह होना चाहिए। निश्चित रूप से एक विवरण शामिल करें, जैसे "यह वर्कफ़्लो इस तरह क्यों दिखता है, इसके लिए एक विस्तृत विवरण के लिए, इस लिंक का अनुसरण करें," उन लोगों के लिए चेकलिस्ट में जो जानना चाहते हैं।

दूसरा बिंदु उन प्रक्रियाओं के लिए है जो अक्सर नहीं चलती हैं लेकिन उनमें नुकसान होते हैं। चेकलिस्ट सिर्फ विंगिंग के कुछ डूम से बचने के लिए नक्शे के रूप में कार्य करता है। अगर चेकलिस्ट को एक डॉक्यूमेंटेशन रेपो में रखा जाता है, तो यह उस समय के लिए ईमेल सर्च करने से बचाता है, जब पुराने एडमिन ने HOWTO को भेजा था।

मेरी राय में अच्छे चेकलिस्ट-डॉक्यूमेंटेशन में संभावित विफलता बिंदुओं पर अनुभाग और उन विफलताओं के जवाब भी शामिल हैं। यह दस्तावेज़ को बड़ा बना सकता है और टीएल को ट्रिगर कर सकता है; सहकर्मियों में डीआर प्रतिक्रियाएं, इसलिए मुझे लगता है कि विफलता-मोड और उनकी प्रतिक्रियाओं को चेकलिस्ट से लिंक करने के बजाय पृष्ठ पर ही एक नायाब चेकलिस्ट बनाता है। हाइपरटेक्स्टुलिटी को गले लगाओ।

दस्तावेज़ मैनुअल के रूप में

इस तरह के प्रलेखन के लिए लक्ष्य बाजार वे लोग हैं जो इस बारे में अधिक सीखना चाहते हैं कि सिस्टम कैसे काम करता है। इस दस्तावेज़ से कैसे-कैसे-करें-शैली स्टाइल दस्तावेज़ प्राप्त किया जा सकता है, लेकिन अधिक सामान्यतः मैं इसे वर्कफ़्लो में किए गए निर्णयों का बैक-अप करने के लिए चेकलिस्ट-स्टाइल दस्तावेज़ के पूरक के रूप में देखता हूं।

यह वह दस्तावेज है, जिसमें हम इस तरह के चाव के टुकड़े शामिल करते हैं:

  • यह समझाते हुए कि यह इस तरह क्यों कॉन्फ़िगर किया गया है।
    • इस खंड में राजनीति जैसे गैर-तकनीकी मुद्दों को शामिल किया जा सकता है कि कैसे पूरी चीज खरीदी और स्थापित की गई।
  • सामान्य विफलता मोड और उनकी प्रतिक्रियाएँ समझाते हुए।
  • किसी भी सेवा-स्तर-समझौतों की व्याख्या करते हुए, लिखित और वास्तविक दोनों तरह से।
    • डी फैक्टो: "अगर यह फाइनल वीक के दौरान विफल हो जाता है तो यह एक ड्रॉप-एवरीथिंग समस्या है। अगर गर्मियों में ब्रेक के दौरान, सो जाओ और सुबह इससे निपटो।"
  • उन्नयन और लक्ष्यीकरण को निर्धारित करना।
    • राजनीति बाद में अलग हो सकती है, हम शुरुआत में कुछ बुरे विचारों को ठीक क्यों नहीं करते हैं?

जो पूरे सिस्टम की व्यापक समझ प्राप्त करने के लिए बहुत उपयोगी हैं। आपको सरल मानव-स्वचालन कार्यों को चलाने के लिए एक व्यापक समझ की आवश्यकता नहीं है, आपको यह पता लगाने की आवश्यकता है कि कुछ ने ऐसा करने के तरीके को क्यों तोड़ दिया और एक विचार है जहां इसे फिर से नहीं करना है।


आपने डिजास्टर रिकवरी डॉक्यूमेंटेशन का भी उल्लेख किया है जिसे चेकलिस्ट होना है।

मैं समझता हूँ, आप मेरी सहानुभूति हैं।

हां, डीआर प्रलेखन को चेकलिस्ट की तरह होना चाहिए।
हां, डीआर प्रलेखन चेकलिस्टिंग के लिए सबसे प्रतिरोधी है कि कितने तरीके से चीजें टूट सकती हैं।

यदि आपका DR चेकलिस्ट दिखता है:

  1. डस्टिन या करेन को बुलाओ।
  2. समस्या के बारे में बताएं।
  3. पीछे हटो।

आपको कोई समस्या है। यह एक चेकलिस्ट नहीं है, यह एक प्रवेश है कि इस प्रणाली की वसूली इतनी जटिल है कि यह एक वास्तुकार को पता लगाने के लिए लेता है। कभी-कभी यह सब आप कर सकते हैं, लेकिन यदि संभव हो तो इससे बचने की कोशिश करें।

आदर्श रूप से DR प्रलेखन में कुछ अलग चीजों के लिए प्रक्रिया जाँचक शामिल हैं:

  • यह पता लगाने के लिए कि क्या गलत हुआ, जो पहचानने में मदद करेगा ...
  • कुछ विफलता-मामलों के लिए पुनर्प्राप्ति प्रक्रिया। जिसके द्वारा समर्थित है ...
  • वसूली स्क्रिप्ट पहले से ठीक होने के बाद मानव त्रुटि को कम करने में मदद करने के लिए अच्छी तरह से लिखा गया है।
  • विफलता के मामलों के बारे में मैनुअल-शैली के दस्तावेज, वे क्यों होते हैं और उनका क्या मतलब है।

ट्राइएज प्रक्रियाएं कभी-कभी सभी डीआर प्रलेखन होती हैं जिन्हें आप कुछ प्रणालियों के लिए बना सकते हैं। लेकिन इसका मतलब है कि 4am कॉल-आउट अधिक समझदार होगा और रिकवरी करने वाले सीनियर इंजीनियर वास्तविक समस्या को तेजी से हल कर पाएंगे।

कुछ विफलता के मामलों में सीधे-आगे वसूली प्रक्रिया होती है। उन्हें दस्तावेज दें। उन्हें प्रलेखित करते समय, आपको ऐसे मामले मिल सकते हैं, जहां आदेशों की सूची एक विशिष्ट क्रम में दर्ज की जा रही है, जो स्क्रिप्टिंग के लिए एक महान उपयोग-मामला है; यह 96 बिंदु पुनर्प्राप्ति प्रक्रिया को 20 बिंदु एक में बदल सकता है। आप कभी भी यह पता नहीं लगा पाएंगे कि क्या आप तब तक कुछ स्क्रिप्ट कर सकते हैं जब तक कि आप पुनर्प्राप्ति प्रक्रिया को कार्रवाई द्वारा मैप नहीं करते हैं।

विफलता के मामलों के लिए मैनुअल-शैली का दस्तावेज़ीकरण अंतिम खाई बैकस्टॉप है जिसका उपयोग तब किया जाता है जब कोई पुनर्प्राप्ति प्रक्रिया नहीं होती है या पुनर्प्राप्ति प्रक्रिया विफल हो जाती है। यह संभवत: किसी और को खोजने के लिए आवश्यक Google-संकेत प्रदान करता है, जिसके पास वह समस्या थी और इसे ठीक करने के लिए उन्होंने क्या किया।


यह उस वातावरण से बहुत मिलता-जुलता है जो मैं (माइनस द हेल्पडेस्क) में हूं। +1 के लिए "मैंने ऐसा क्यों किया"
एवरी पेने

@ sysadmin1138, आपने कहा "जब मैंने अपनी आखिरी नौकरी छोड़ दी, तो मैं 100 पेज में बदल गया 'मैं अपने काम को कैसे चलाऊं' इससे पहले कि मैं चला जाता" । आपने ऐसा क्यों किया? क्या वास्तव में इसकी आवश्यकता है? अन्यथा, आप पहले से ही छोड़ने वाले 100 पृष्ठों से परेशान क्यों हैं?
पचेरियर

1
@Pacerier वह था ... 12 साल पहले। और मैं कुछ चीजों को कवर करने वाला एकमात्र एडमिन था । इसके अलावा, मुझे वह कंपनी पसंद आई, इसलिए वह साफ-सुथरा हाथ चाहता था। अन्य कंपनियों ने मुझे 2 सप्ताह के 'ज्ञान साझाकरण सत्र' में बंद कर दिया है, जिसका उद्देश्य उसी तरह का काम करना था। केवल कम विश्वसनीय है, क्योंकि मानव स्मृति वास्तव में खराब है।
sysadmin1138

don't have timeहो सकता है don't have time। कुल मिलाकर, पुन: प्रयोज्य अनुभव!
n611x007

14

दरअसल न तो, हम डॉक्यूमेंटेशन अस-ए-टेस्टकेस का उपयोग करते हैं

कहा जा रहा है कि हमने प्रलेखन लिखा है जो प्रलेखन ए-मैनुअल के साथ जाता है । हमारे पास जगह-जगह चेकलिस्ट थे, लेकिन जब हम बढ़ रहे थे तो उन्हें त्रुटि वाला पाया गया और वास्तव में पूरे सिस्टम में फेल हो गया।

लेकिन हम क्या ज़रूरत है एक तरह से जैसा कि ऊपर उल्लेख - - हम बड़े पैमाने पर हमारी सेवाओं की निगरानी "प्रलेखन के रूप में एक चेकलिस्ट" स्थापित है, है। एक कहावत है:

यदि आप इसकी निगरानी नहीं कर रहे हैं तो आप इसे प्रबंधित नहीं कर रहे हैं

यह पूरी तरह सच है, लेकिन एक और होना चाहिए:

यदि आप इसकी निगरानी नहीं कर रहे हैं तो आप इसका दस्तावेजीकरण नहीं कर रहे हैं

जब भी हमें सेवाओं को स्थानांतरित करने की आवश्यकता होती है तो हम बस "सेवा समूह", "मेजबान समूह", जो भी लागू होता है (हम नागिओस का उपयोग करते हैं, जैसा कि आप शब्दावली से अनुमान लगा सकते हैं) को खुला रखते हैं और यह तब तक माइग्रेट नहीं होता है जब तक कि एक लाल बिंदु नहीं होता है। सेवाओं में से किसी पर।

परीक्षण किसी भी हाथ से लिखी गई चेक सूची की तुलना में बेहतर चेकलिस्ट प्रदान कर सकते हैं। यह वास्तव में सेल्फ डॉक्यूमेंटिंग है, जैसे ही हमें कुछ विफलता होती है, जिसकी निगरानी अभी तक नहीं की गई थी, कम से कम टेस्ट में नागियोस को जोड़ा जाएगा, इसके साथ ही हमें 2 चीजें मुफ्त में मिलेंगी:

  • हम जानते हैं कि यह कब विफल होता है
  • चेकलिस्ट पर एक और बिंदु

"वास्तविक" प्रलेखन को विकी में विशिष्ट सेवा या परीक्षण के बाधाओं और अंत का उल्लेख करते हुए रखा जाता है। यदि यह याद आ रहा है तो लोग इसे जल्द से जल्द जोड़ देंगे क्योंकि हमें कुछ माइग्रेशन करने की जरूरत है या इसके साथ कुछ काम करने की जरूरत है, अब तक उस दृष्टिकोण ने बहुत अच्छा काम किया है।

इसके अलावा, विखंडन प्रलेखन वास्तव में तेजी से इस्त्री किया जाता है, हर बार कुछ विफल हो जाता है लोग दस्तावेज़ीकरण देखना शुरू करते हैं और हॉवोस के साथ समस्या को हल करने की कोशिश करते हैं, अगर यह गलत है तो बस इसे अपने निष्कर्षों के साथ अपडेट करें।

केवल उन त्रुटियों के बारे में सोचें जो एक चेकलिस्ट का अनुसरण करके बना सकते हैं और किसी भी परीक्षण को स्थापित नहीं कर रहे हैं जो उन्हें लागू करने के बाद आपको ग्रीन चेकबॉक्स देगा। मुझे नहीं लगता कि मॉनिटरिंग से डॉक्यूमेंटेशन को अलग करना संभव है।


2
वैकल्पिक दृष्टिकोण के लिए +1।
अवन पायने

2
मैंने एक साफ-सुथरा यूट्यूब वीडियो देखा जो एक ऐसी प्रणाली को प्रदर्शित करता है जो एकीकरण / स्वीकृति परीक्षण और रिकॉर्ड स्क्रैनास्ट करता है। youtube.com/watch?v=78mts_sKNGs
jldugger

5

यह आपके प्रलेखन के लिए लक्षित दर्शकों पर निर्भर करता है।

हेल्पडेस्क (स्तर 1) प्रकारों के लिए, एक चेकलिस्ट जाने का सही तरीका है; बेशक, यह मानता है कि आपके द्वारा वर्णित गहन ज्ञान के साथ समर्थन के उच्च स्तर हैं।

यदि प्रलेखन सिस्टम समूह के लिए है, तो मैं हमेशा अधिक प्रलेखन के पक्ष में गलत हूं। यदि आपके पास कोई (स्वयं) अपेक्षित पृष्ठभूमि जानकारी के साथ अधिक व्यापक डॉक्स लिखना चाहता है, तो कोई भी व्यक्ति आपके रास्ते में खड़ा नहीं होना चाहिए।


+1 दस्तावेज़ीकरण हमेशा लक्षित दर्शकों को ध्यान में रखकर लिखा जाना चाहिए। वे इसमें से कुछ पाने के लिए दस्तावेज़ पढ़ रहे हैं ... क्या वह ज्ञान है या यह है कि कुछ कैसे किया जाए। अगर इसके कुछ करने के लिए कुछ अतिरिक्त ज्ञान की आवश्यकता हो सकती है, तो मैंने अतिरिक्त ज्ञान को परिशिष्ट में डाल दिया है।
पॉल रॉलैंड

5

व्यक्तिगत रूप से मैं कोशिश करता हूं और प्रलेखन को यथासंभव सरल रखता हूं। इसमें शामिल हैं:

  • क्या [एक्स] करना चाहिए (आवश्यकताओं)।
  • कैसे [X] को उच्च स्तर (डिजाइन) पर संरचित किया गया है।
  • मैंने जिस तरह से किया (कार्यान्वयन विचार) क्यों [एक्स] लागू किया।
  • [X] का कार्यान्वयन कैसे गैर-मानक (वर्कअराउंड) है।
  • [X] के साथ सामान्य मुद्दे और उन्हें कैसे हल करें (मुद्दे)।

इसलिए माना जाता है कि मेरे सामान्य मुद्दे अनुभाग में क्या हुआ है और इसे कैसे ठीक करना है, इस पर बिंदु बिंदु walkthroughs का एक संक्षिप्त विवरण होने की संभावना है।

मैं आमतौर पर प्रश्न के सिस्टम के पाठक से कुछ ज्ञान ग्रहण करता हूं (जब तक कि यह विशेष रूप से रहस्यमय नहीं है)। मेरे पास अपने अधिकांश तकनीकी दस्तावेज़ीकरण स्तर 1 या प्रबंधन को पठनीय बनाने का समय नहीं है - लेकिन एक सुराग स्तर 3 ठीक होना चाहिए।


4

मुझे लगता है कि यह स्पष्ट रूप से विषय पर निर्भर करता है। सब कुछ एक साधारण चेकलिस्ट में नहीं घटाया जा सकता है, और न ही सब कुछ एक विस्तृत उपयोगकर्ता पुस्तिका की आवश्यकता है।

यह निश्चित रूप से लगता है कि आप आंतरिक दस्तावेज के बारे में बात कर रहे हैं, और मेरे अनुभव में आप केवल चरणों की एक सूची नहीं दे सकते, क्योंकि बहुत सारे विकल्प हैं। यहां तक ​​कि उपयोगकर्ता खाते को बनाने के कुछ विकल्प (हमारे वातावरण में) हैं, इसलिए हमारे "नए खाते" दस्तावेज़ में क्रम में बुनियादी चरणों को सूचीबद्ध किया गया है, लेकिन प्रत्येक चरण के लिए विवरण है कि विविधताएं क्या हैं।

दूसरी ओर, हमें कभी भी "किसी कार्यालय में पैच करने के लिए" दस्तावेज़ के बारे में अधिक लिखने के लिए नहीं मिला, लेकिन हमारे बहुत ही स्केच दस्तावेज़ भी एक चेकलिस्ट नहीं थे - यह उन सम्मेलनों का उल्लेख करता है जो हम केबलों के रंगों के लिए उपयोग करते हैं, पर जोर दिया। है कि आप था स्प्रेडशीट कि कनेक्शन सूचीबद्ध अद्यतन करने के लिए, और कहा कि इसके बारे में था।

इसलिए, अब जब मैंने यह लिखा है, तो मैं पूरी तरह से सहमत हूं: चरण-दर-चरण चेकलिस्ट केवल बहुत सारी प्रक्रियाओं के लिए इसे नहीं काटेंगे।


3

मैं इस भाग में आपके साथ दृढ़ता से (संपूर्ण दस्तावेज़ीकरण के पक्ष में) सहमत हूं क्योंकि मैं पूर्ववर्तियों के लिए उपयोग किया जाता हूं, जिनकी डॉक्स में बिल्कुल भी रुचि नहीं थी। जैसा कि संबंधित पोस्ट में कहा गया है, इसे लिखना न केवल दूसरों के लिए अच्छा है, बल्कि आपको अपने वातावरण को पूरी तरह से समझने और इसे अपने दिमाग में ठोस बनाने में मदद करता है। यह अपने आप में एक अंत है।

एक तरफ के रूप में, मुझे लगता है कि बहुत से पुलबैक एक अजीब विश्वास से आते हैं जो भद्दा / कोई नहीं है दस्तावेज़ीकरण = नौकरी सुरक्षा। इस तरह की सोच सिर्फ बेईमानी और छायादार लगती है।

यथास्थिति के लिए आप के लिए यश।


3

मैं काफी दस्तावेज करता हूं, मेरे पास एक दस्तावेज प्राथमिकता चेकलिस्ट :-) भी है, लेकिन मैं सामान को दस्तावेज नहीं करूंगा जिसे सामान्य ज्ञान माना जा सकता है (यानी समस्या का एक उचित अच्छा वर्णन Google के पहले पृष्ठ के भीतर एक उत्तर देता है)।

यहां रुचि रखने वाले किसी व्यक्ति के लिए मेरा डॉक्टर प्रियो चेकलिस्ट है (मेरे लिए काम करता है, आपके लिए नहीं हो सकता है, टिप्पणियों और सुझावों की बहुत सराहना की जाती है):

  1. एक व्यक्तिगत लॉग / डायरी बनाएं, जो आपने वह सब लिखा है जो आपने काम किया / ज्ञान वार
  2. सेवाएँ, कौन सी सेवा कहाँ है, क्या करती है और किसके लिए की जाती है (किसी भी SLA समझौते? क्या किसी को बनाया जाना चाहिए?)
  3. सर्वर, क्या सर्वर कहाँ, कितना पुराना है और कब लिखा गया है
  4. ऊपर के रूप में लेकिन नेटवर्क उपकरण, यूपीएस और जैसे के लिए
  5. ऊपर के रूप में लेकिन सभी उपयोगकर्ता मशीनों के लिए
  6. भौतिक नेटवर्क का लेआउट (कौन सी केबल कहां जाती है, यह कितनी देर है और मापा गुणवत्ता क्या है)
  7. सर्वर के लिए सॉफ्टवेयर और लाइसेंस का कॉन्फ़िगरेशन अवलोकन
  8. सॉफ्टवेयर और उपयोगकर्ता मशीनों के लिए लाइसेंस का विन्यास अवलोकन
  9. स्विच, राउटर और अन्य समर्पित हार्डवेयर का कॉन्फ़िगरेशन अवलोकन
  10. सभी बाहरी पार्टियों के अनुबंध और एसएलए, जिसके लिए मेरी सेवा सीधे (आईएसपी, डोमेन आदि) पर निर्भर करती है
  11. इसमें उपरोक्त सभी सामान डालने के लिए एकीकृत विकी के साथ एक टिकट प्रणाली सेट-अप करें।
  12. प्रत्येक घटना के लिए एक टिकट बनाएं (भले ही आप इसे अपने स्वयं के लिए उपयोग करें)।
  13. एक स्क्रिप्ट बनाएं जो रविवार को टिकट इकट्ठा करता है और उन्हें समस्या प्रकार पर समूहित करता है।
  14. सोमवार को सबसे अधिक समस्या उत्पन्न करने के लिए एक स्वचालित समाधान या एंड-यूज़र हाउटो दस्तावेज़ बनाएं
  15. यदि समय अनुमति देता है, तो अगले एक को करें।
  16. अगर ज्यादा कुछ नहीं करना है, तो एक नई नौकरी की तलाश करें और उस व्यक्ति को दें जो आपको लॉग;

1

एक चेकलिस्ट ठीक है, जब तक कि यह पूर्ण दस्तावेज होने का नाटक नहीं कर रहा है । पिछले कुछ दस्तावेज़ जो मैंने लिखे थे, वे दो भागों में आए: XYZ for Users, जिसमें सुंदर स्क्रीनशॉट शामिल थे कि इसे कैसे उपयोग किया जाए; और सिस्टम प्रशासकों के लिए XYZ, जिसमें शामिल था कि यह कैसे सेटअप किया गया था, और क्यों (संभवतः इसके लिए व्यावसायिक आवश्यकता भी मौजूद है), बचने के लिए जाल, और समस्या निवारण पर एक अनुभाग। समस्या निवारण वह है जहां मैं चेकलिस्ट खोजने की उम्मीद करूंगा। शायद टेक सपोर्ट के लिए एक्सवाईजेड के रूप में चेकलिस्ट लिखना एक बिंदु बनाने में मदद कर सकता है।

अब, लाइनों के बीच पढ़ने, केवल चेकलिस्ट पर ध्यान केंद्रित करना मेरे लिए "बिग पिक्चर" सोच और दीर्घकालिक योजना की कमी को इंगित करता है जो मैं किसी ऐसे व्यक्ति से अपेक्षा करता हूं जो: कभी केवल तकनीकी समर्थन किया है; या एक जूनियर एडमिन अभी शुरू कर रहा है; या काम से इतना तंग आ गया है कि उसके पास इसके बारे में सोचने का समय नहीं है; या इसके बारे में सोचने के लिए कभी धक्का नहीं दिया गया है; या सिर्फ सादे परवाह नहीं है। मुझे नहीं पता कि इनमें से कौन सा, यदि कोई हो, आपके मामले में लागू होता है।


ओवरराइड मुख्य रूप से विभाग प्रमुख से है। लेकिन दूसरे लोग सहमत हैं। मैं अभी भी अपनी बंदूकों से चिपकता हूं और दिन में मेरे पास जितना भी समय बचा है, उसके साथ टाइप कर सकता हूं।
अवनी पायने

1

मैं प्रलेखन पर बहुत बड़ा हूँ। जिस कंपनी में मैं अब काम करता हूं उसे लगता है कि प्रलेखन महत्वपूर्ण है, लेकिन कंपनी के कुछ लोगों को लगता है कि उनके पास दस्तावेज लिखने का समय नहीं है। यह उस व्यक्ति के अलावा किसी के लिए भी जीवन को मुश्किल बना सकता है जो मूल रूप से किया था।

कुछ चीजों के लिए, मैंने चरण-दर-चरण निर्देश लिखे हैं। आप चाहें तो इसे एक चेकलिस्ट कह सकते हैं, लेकिन यह वास्तव में शारीरिक रूप से जाँच करने का इरादा नहीं है। मैं अपने प्रलेखन शैली को "किंडरगार्टन स्टेप्स" कहता हूं। यह एक MCSE अभ्यास पुस्तक के बाद पैटर्न है, जो मैंने विंडोज 2000 परीक्षाओं में से एक के लिए किया था। कदम बहुत विस्तृत हैं, लेकिन बोल्ड / इटैलिक / टाइपफेस के उपयोग से चमक खत्म करना आसान हो जाता है और बस महत्वपूर्ण भागों को चुनना पड़ता है ताकि आपको चरणों को सीखने के बाद सब कुछ पढ़ने की आवश्यकता न हो।

कुछ चीजें चरण-दर-चरण निर्देशों के लिए अच्छी तरह से उधार नहीं देती हैं, इसलिए मैं जितना संभव हो उतना कॉन्फ़िगरेशन डेटा प्रदान करने का प्रयास करता हूं। कुछ तकनीकी रूप से इच्छुक व्यक्ति जो सड़क को बनाए रखना चाहते हैं, उन्हें इस बात का बेहतर अंदाजा होगा कि वे क्या कर रहे हैं, और उम्मीद है कि कुछ गलत होने पर यह उनके जीवन को थोड़ा आसान बना देगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.