เอกสารประกอบแบบ A-A-Manual และเอกสารประกอบ As-A-Checklist

ฉันเคยพูดคุยกับบุคคลอื่นในแผนกของฉันเกี่ยวกับเอกสารโดยเฉพาะระดับรายละเอียดและข้อกำหนด ในมุมมองของพวกเขาเอกสารเป็นรายการตรวจสอบอย่างง่ายของสิ่ง Y ที่ต้องทำเมื่อสิ่ง X ผิดพลาด

ฉันไม่เห็นด้วย. ฉันคิดว่านี่เป็นทึกทักว่าปัญหาทั้งหมดใน IT สามารถถูกต้มลงในรายการตรวจสอบอย่างง่ายของกระบวนการกู้คืน ฉันคิดว่ามันไม่สนใจความซับซ้อนของสถานการณ์อย่างสมบูรณ์และเนื่องจากคนอื่น ๆ ในแผนกไม่ได้มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับปัญหา (ซึ่งเป็นสาเหตุที่ฉันเขียนเอกสาร - ดังนั้นพวกเขาจึงมีบางสิ่งบางอย่างที่จะอ้างถึง ) ว่าเอกสารควรมีเนื้อหาพื้นหลังพื้นฐานบางอย่างเช่น:

• วัตถุประสงค์ของระบบ (ย่อย) ที่เป็นปัญหา
• ทำไมมันถูกกำหนดค่าในลักษณะที่
• ความคาดหวังของเหตุการณ์ที่จะเกิดขึ้นเมื่อมีการใช้การตั้งค่า / ขั้นตอน
• ปัญหาที่อาจเกิดขึ้นซึ่งอาจทำให้กระบวนการล้มเหลว

อย่างไรก็ตามฉันค่อนข้าง outvoted ในเรื่องนี้ดังนั้นเอกสารของฉันจะต้องเขียนใหม่ในแบบฟอร์มที่ระบุว่า "ขั้นตอน ABC ที่ใช้ในการสั่งซื้อจะแก้ไขปัญหา X" ฉันมักจะได้ยินถึงความโศกเศร้าที่ต้องใส่ลงในกระดาษหน้าเดียว ลองอธิบายการกำหนดค่า Squid ACL ให้กับใครบางคนในลักษณะนี้รวมถึงการแก้ไขปัญหาผ่านเอกสารหน้าเดียว นั่นเป็นเพียงหนึ่งในเอกสารครึ่งโหลที่ "รอการเขียน" เป็นรายการตรวจสอบการกู้คืน

เป็นวิธีที่ฉันเรียกร้องให้ลงน้ำจริงๆหรือไม่? หรือว่าถูกต้องและฉันควรคำนึงถึงธุรกิจของฉันที่นี่และเขียนรายการตรวจสอบง่ายๆ ความกังวลของฉันคือว่าไม่ว่าคุณจะเขียนรายการตรวจสอบขั้นตอนได้ดีเพียงใดมันไม่ได้แก้ปัญหาที่ต้องใช้ SysAdmin เพื่อคิดสิ่งต่าง ๆ หากคุณใช้เวลาทำรายการตรวจสอบขั้นตอนการกู้คืนซึ่งไม่สามารถแก้ไขปัญหาได้ (เนื่องจากมีปัจจัยเพิ่มเติมที่ไม่ได้เป็นส่วนหนึ่งของเอกสารเนื่องจากจุดเน้นที่แคบของเอกสาร ) และวัตถุประสงค์ของ เอกสารคือการหลีกเลี่ยงการอ่าน man pages และ wikis และเว็บไซต์อีกครั้งแล้วทำไมฉันต้องผ่านการเคลื่อนไหว? ฉันแค่กังวลมากเกินไปหรือเป็นปัญหาจริงหรือ

แก้ไข:

ไม่มีตำแหน่งงานช่วยเหลือในแผนกนี้ ผู้ชมสำหรับเอกสารจะเป็นของผู้ดูแลระบบคนอื่นหรือหัวหน้าแผนก

เมื่อเขียนของฉันฉันมักจะตกไปเขียนสองสามชุด รายการตรวจสอบที่ทำเสร็จแล้วพร้อมภาคผนวกอีกมากมายเกี่ยวกับสถาปัตยกรรมของระบบรวมถึงสาเหตุที่สิ่งต่าง ๆ ทำในแบบที่พวกเขาเป็นจุดเกาะที่น่าจะเป็นไปได้เมื่อออนไลน์และสมมติฐานการออกแบบที่เป็นนามธรรม ตามด้วยรายการปัญหาที่น่าจะเป็นและการแก้ปัญหาของพวกเขาตามด้วยส่วนที่ยาวขึ้นพร้อมข้อมูลเกี่ยวกับวิธีการทำงานของระบบทำไมมันถึงเป็นเช่นนั้นและข้อมูลอื่น ๆ ที่มีประโยชน์สำหรับการชี้บุคคลในทิศทางที่ถูกต้อง

ในงานสุดท้ายของฉันเราจำเป็นต้องเขียนเอกสารเพื่อให้แม้แต่ผู้ช่วยเหลือระดับ 1 ก็สามารถนำสิ่งต่าง ๆ กลับมาได้ รายการตรวจสอบที่จำเป็นนี้ซึ่งโดยทั่วไปล้าสมัยภายใน 3 เดือนของการเขียน เราขอแนะนำอย่างยิ่งให้เขียนคู่มือการแก้ปัญหาทุกครั้งที่เป็นไปได้ แต่เมื่อต้นไม้ที่อาจเกิดขึ้นได้รับมากกว่าสามสาขาคุณจะไม่สามารถเขียนเอกสารนั้นโดยไม่เป็นนามธรรม

เมื่อออกจากงานล่าสุดของฉันฉันหันไปในคู่มือ 'วิธีการทำงานของฉัน' ในหน้า 100 ก่อนที่ฉันจะจากไป มันมีเนื้อหาที่เป็นนามธรรมปรัชญาการออกแบบรวมถึงประเด็นการรวมเข้าด้วยกัน เนื่องจากฉันถูกเขียนขึ้นสำหรับผู้ดูแลระบบคนอื่นที่กำลังจะมาแทนที่ฉันฉันจึงเล็งไปที่ใครบางคนที่สามารถใช้ความคิดเชิงนามธรรมและทำให้พวกเขากลายเป็นการกระทำที่เป็นรูปธรรม

ห้าปีผ่านไปแล้วและฉันพบว่าความคิดเห็นของฉันเกี่ยวกับเรื่องนี้ได้เปลี่ยนไปบ้าง ทั้งเอกสารเป็นคู่มือและเอกสารเป็นรายการตรวจสอบมีสถานที่ที่มีคุณค่ามากในลำดับชั้นของเอกสารและทั้งสองจะต้องมีการผลิต พวกเขากำหนดเป้าหมายไปยังผู้ชมที่แตกต่างกันมาก

เอกสารเป็นรายการตรวจสอบ

ตลาดเป้าหมายสำหรับเอกสารประเภทนี้คือเพื่อนร่วมงานที่ต้องการวิธีการทำสิ่งต่างๆ พวกเขามาในสองประเภท:

• เพื่อนร่วมงานที่ต้องการรู้วิธีทำสิ่งต่าง ๆ และไม่มีเวลาอ่านคู่มือสิบห้าหน้าและหาขั้นตอนต่าง ๆ สำหรับตนเอง
• ขั้นตอนที่ค่อนข้างซับซ้อนในขั้นตอน แต่จะต้องทำงานเป็นครั้งคราว

ความอดทนเป็นคนขับสำหรับประเภทแรก บางทีเพื่อนร่วมงานของคุณอาจไม่ต้องการรู้ว่าทำไมการแสดงผลจึงต้องมีการส่งผ่าน 90 อักขระ perl regex เพียงเพื่อที่จะได้ปิดตั๋ว รวมคำแถลงอย่างชัดเจน "สำหรับคำอธิบายโดยละเอียดเกี่ยวกับสาเหตุที่เวิร์กโฟลว์นี้มีลักษณะเช่นนี้ให้ไปที่ลิงค์นี้" ในรายการตรวจสอบสำหรับผู้ที่ต้องการทราบสาเหตุ

จุดที่สองสำหรับขั้นตอนที่ไม่ได้ทำงานบ่อย แต่มีข้อผิดพลาด รายการตรวจสอบทำหน้าที่เป็นแผนที่เพื่อหลีกเลี่ยงการแน่นอนบางอย่างเพียง winging มัน หากรายการตรวจสอบถูกเก็บไว้ใน repo เอกสารมันจะไม่ต้องค้นหาอีเมลในเวลาที่ผู้ดูแลระบบเก่าส่ง HOWTO

ในความคิดของฉันรายการตรวจสอบที่ดียังมีเอกสารในส่วนของจุดล้มเหลวที่เป็นไปได้และการตอบสนองต่อความล้มเหลวเหล่านั้น สิ่งนี้สามารถทำให้เอกสารมีขนาดค่อนข้างใหญ่และทำให้เกิด TL การตอบสนอง DR ในเพื่อนร่วมงานดังนั้นฉันจึงพบว่าการทำให้โหมดความล้มเหลวและการตอบสนองลิงก์จากรายการตรวจสอบมากกว่าในหน้านั้นเป็นรายการตรวจสอบที่ไม่ธรรมดา โอบกอด

เอกสารเป็นคู่มือ

ตลาดเป้าหมายสำหรับเอกสารประเภทนี้คือผู้ที่ต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการทำงานของระบบ เอกสารสไตล์ลักษณะสิ่งที่ต้องทำควรได้มาจากเอกสารนี้ แต่โดยทั่วไปฉันเห็นว่าเป็นส่วนเสริมสำหรับเอกสารประกอบรายการตรวจสอบเพื่อสำรองข้อมูลการตัดสินใจในเวิร์กโฟลว์

นี่คือเอกสารที่เรารวมชิ้นส่วนที่เหนียวนุ่มเช่น:

• อธิบายว่าทำไมจึงกำหนดค่าด้วยวิธีนี้
  • ส่วนนี้อาจรวมถึงปัญหาที่ไม่ใช่ด้านเทคนิคเช่นการเมืองโดยรอบเกี่ยวกับวิธีการซื้อและติดตั้งสิ่งของทั้งหมด
• อธิบายโหมดความล้มเหลวทั่วไปและการตอบสนองของพวกเขา
• อธิบายข้อตกลงระดับบริการใด ๆ ทั้งที่เป็นลายลักษณ์อักษรและโดยพฤตินัย
  • อันที่จริง: "ถ้าสิ่งนี้ล้มเหลวในช่วงสัปดาห์สุดท้ายของการแข่งขันมันเป็นปัญหาที่เกิดขึ้นทุกอย่างถ้าในช่วงพักฤดูร้อนกลับไปนอนและจัดการกับมันในตอนเช้า"
• การกำหนดเป้าหมายการอัพเกรดและการเปลี่ยนโครงสร้างใหม่
  • การเมืองอาจแตกต่างออกไปในภายหลังทำไมเราไม่แก้ไขความคิดที่ไม่ดีที่นำมาใช้ในตอนแรก

ซึ่งล้วนเป็นประโยชน์อย่างมากสำหรับการได้รับความเข้าใจที่ครอบคลุมของระบบทั้งหมด คุณไม่จำเป็นต้องมีความเข้าใจอย่างถ่องแท้เพื่อใช้งานระบบอัตโนมัติของมนุษย์อย่างง่ายคุณต้องเข้าใจก่อนว่าทำไมบางอย่างถึงผิดพลาดและมีความคิดว่าจะทำอย่างไร

คุณยังกล่าวถึงเอกสารประกอบการกู้คืนความเสียหายที่จะต้องมีรายการตรวจสอบ

ฉันเข้าใจคุณมีความเห็นอกเห็นใจของฉัน

ใช่เอกสาร DR ต้องเป็นรายการตรวจสอบให้มากที่สุด
ใช่เอกสาร DR มีความทนทานต่อการตรวจสอบมากที่สุดเนื่องจากมีหลายสิ่งที่อาจแตกหักได้

หากรายการตรวจสอบ DR ของคุณดูเหมือนว่า:

1. โทรหาดัสตินหรือกะเหรี่ยง
2. อธิบายปัญหา
3. ยืนกลับ.

คุณมีปัญหา. นั่นไม่ใช่รายการตรวจสอบนั่นคือการยอมรับว่าการกู้คืนระบบนี้มีความซับซ้อนดังนั้นจึงต้องใช้สถาปนิกในการคิดออก บางครั้งนั่นคือทั้งหมดที่คุณทำได้ แต่พยายามหลีกเลี่ยงถ้าเป็นไปได้

เอกสาร DR ที่เป็นเลิศประกอบด้วยรายการตรวจสอบขั้นตอนสำหรับสิ่งต่าง ๆ :

• ขั้นตอนการจัดเรียงเพื่อหาว่ามีอะไรผิดพลาดซึ่งจะช่วยระบุ ...
• ขั้นตอนการกู้คืนสำหรับความล้มเหลวบางกรณี สนับสนุนโดย ...
• สคริปต์การกู้คืนเขียนไว้ล่วงหน้าเพื่อช่วยลดข้อผิดพลาดของมนุษย์ระหว่างการกู้คืน
• เอกสารคู่มือสไตล์เกี่ยวกับกรณีความล้มเหลวสาเหตุที่เกิดขึ้นและสิ่งที่พวกเขาหมายถึง

บางครั้งขั้นตอน Triage เป็นเอกสาร DR ทั้งหมดที่คุณสามารถทำได้สำหรับบางระบบ แต่ถ้ามีหมายความว่าการโทรออก 4am จะเป็นที่เข้าใจได้ง่ายขึ้นและวิศวกรอาวุโสที่ทำการกู้คืนจะสามารถแก้ไขปัญหาที่เกิดขึ้นได้เร็วขึ้น

บางกรณีความล้มเหลวมีขั้นตอนการกู้คืนตรงไปตรง จัดทำเอกสาร ในขณะที่บันทึกเอกสารคุณอาจพบกรณีที่รายการคำสั่งถูกป้อนตามลำดับเฉพาะซึ่งเป็นกรณีการใช้งานที่ยอดเยี่ยมสำหรับการสร้างสคริปต์ มันสามารถเปลี่ยนกระบวนการกู้คืน 96 จุดเป็น 20 จุดหนึ่ง คุณจะไม่มีทางรู้ได้เลยว่าคุณสามารถเขียนสคริปต์อะไรได้จนกว่าคุณจะแมปการดำเนินการตามขั้นตอนการกู้คืนตามการกระทำ

เอกสารประกอบแบบคู่มือสำหรับกรณีความล้มเหลวเป็นสต็อปหลังทิ้งสุดท้ายที่จะใช้เมื่อไม่มีกระบวนการกู้คืนหรือกระบวนการกู้คืนล้มเหลว มันให้คำแนะนำของ google ที่จำเป็นในการหาคนอื่นที่มีปัญหานั้นและสิ่งที่พวกเขาทำเพื่อแก้ไข

จริงๆแล้วเราใช้Documentation As-a-Testcase

ที่ถูกกล่าวว่าเราได้เขียนเอกสารที่จะไปด้วยเอกสาร as-a-คู่มือการใช้งาน เรามีรายการตรวจสอบในสถานที่ แต่เมื่อมีการเติบโตเราพบว่าพวกเขามีแนวโน้มที่จะเกิดข้อผิดพลาดและล้มเหลวในระบบโดยรวม

แต่เราจะมีชนิดของ "เอกสาร as-a-รายการตรวจสอบ" การติดตั้งที่เป็น - ดังกล่าวข้างต้น - เราอย่างกว้างขวางในการตรวจสอบการบริการของเรา มีคำพูด:

หากคุณไม่ได้ตรวจสอบมันคุณไม่ได้จัดการมัน

นั่นเป็นความจริงโดยสิ้นเชิง แต่อีกสิ่งหนึ่งควรเป็น:

หากคุณไม่ได้ตรวจสอบว่าคุณไม่ได้เอกสาร

เมื่อใดก็ตามที่เราต้องการโยกย้ายบริการเราเพียงแค่เก็บ "Service Group", "Host Group" ไม่ว่าจะใช้อะไร (เราใช้ Nagios เพราะคุณสามารถเดาได้จากคำศัพท์) เปิดและมันจะไม่โยกย้ายตราบใดที่มีจุดแดงเดียว ในบริการใด ๆ

การทดสอบให้รายการตรวจสอบที่ดีกว่ารายการตรวจสอบที่เขียนด้วยมือใด ๆ จริงๆแล้วมันคือการจัดทำเอกสารด้วยตนเองทันทีที่เรามีความล้มเหลวบางอย่างที่ไม่ได้รับการตรวจสอบ แต่อย่างน้อยการทดสอบจะถูกเพิ่มลงใน Nagios โดยที่เราได้รับ 2 สิ่งฟรี:

• เรารู้เมื่อมันล้มเหลว
• อีกจุดหนึ่งในรายการตรวจสอบ

เอกสาร "ของจริง" จะถูกเก็บไว้ใน Wiki ที่กล่าวถึงอัตราต่อรองและจุดสิ้นสุดของบริการหรือการทดสอบเฉพาะ ถ้ามันหายไปคนจะเพิ่มมันทันทีที่เราต้องทำการย้ายถิ่นบางอย่างหรือต้องทำงานกับมันจนถึงตอนนี้วิธีการที่ได้ผลดีมาก

นอกจากนี้เอกสารที่ผิดพลาดก็ถูกรีดออกอย่างรวดเร็วทุกครั้งที่มีคนล้มเหลวในการค้นหาเอกสารและพยายามแก้ไขปัญหาด้วย HowTos ในนั้นถ้ามันผิดเพียงแค่อัปเดตพร้อมกับสิ่งที่คุณค้นพบ

ลองนึกถึงข้อผิดพลาดที่อาจเกิดขึ้นได้โดยทำตามรายการตรวจสอบและไม่ได้ติดตั้งการทดสอบใด ๆ ที่จะให้ช่องทำเครื่องหมายสีเขียวแก่คุณหลังจากใช้งาน ฉันคิดว่ามันเป็นไปไม่ได้ที่จะแยกเอกสารจากการตรวจสอบ

ขึ้นอยู่กับกลุ่มเป้าหมายสำหรับเอกสารของคุณ

สำหรับประเภทช่วยเหลือ (ระดับ 1) รายการตรวจสอบเป็นวิธีที่ถูกต้อง แน่นอนว่าทึกทักว่ามีระดับการสนับสนุนที่สูงขึ้นพร้อมกับความรู้ที่ลึกซึ้งที่คุณอธิบาย

หากเอกสารประกอบสำหรับกลุ่มระบบฉันมักจะทำผิดพลาดที่ด้านข้างของเอกสารเพิ่มเติม มันยากพอที่จะมีเอกสารเพียงพอเพียงเพื่อให้ผ่านหากใครบางคน (ตัวคุณเอง) ต้องการที่จะเขียนเอกสารที่ครอบคลุมมากขึ้นด้วยข้อมูลพื้นฐานที่จำเป็น - ไม่มีบุคคลที่มีสติควรยืนอยู่ในทางของคุณ!

โดยส่วนตัวแล้วฉันพยายามทำให้เอกสารง่ายที่สุดเท่าที่จะทำได้ มันมีแนวโน้มที่จะรวมถึง:

• [X] ที่ควรทำ (ข้อกำหนด)
• วิธีที่ [X] มีโครงสร้างในระดับสูง (การออกแบบ)
• เหตุใดฉันจึงนำ [X] ไปใช้ในวิธีที่ฉันทำ
• วิธีการนำ [X] ไปใช้นั้นไม่ได้มาตรฐาน (วิธีแก้ปัญหา)
• ปัญหาทั่วไปเกี่ยวกับ [X] และวิธีแก้ไข (ปัญหา)

ดังนั้นในส่วนของปัญหาที่พบบ่อยของฉันน่าจะเป็นคำอธิบายสั้น ๆ เกี่ยวกับสิ่งที่เกิดขึ้นและคำแนะนำแบบจุดในการแก้ไข

ฉันมักจะสมมติความรู้บางอย่างจากผู้อ่านของระบบที่เป็นปัญหา (เว้นแต่ว่ามันเป็นความลับโดยเฉพาะ) ฉันไม่มีเวลาที่จะใช้ประโยชน์จากเอกสารทางเทคนิคระดับที่ 1 หรือการจัดการที่สามารถอ่านได้ - แต่ระดับ 3 ควรจะดี

ฉันคิดว่ามันชัดเจนขึ้นอยู่กับหัวข้อ ไม่ใช่ทุกสิ่งที่สามารถลดเป็นรายการตรวจสอบได้ง่ายและไม่ใช่ทุกสิ่งที่ต้องการคู่มือผู้ใช้อย่างละเอียด

ดูเหมือนว่าคุณกำลังพูดถึงเอกสารภายในและจากประสบการณ์ของฉันคุณไม่สามารถบอกรายการขั้นตอนได้เนื่องจากมีตัวเลือกมากมายเกินไป แม้แต่การสร้างบัญชีผู้ใช้ก็มีตัวเลือกบางอย่าง (ในสภาพแวดล้อมของเรา) ดังนั้นเอกสาร "บัญชีใหม่" ของเราจะแสดงขั้นตอนพื้นฐานตามลำดับ แต่สำหรับแต่ละขั้นตอนมีคำอธิบายว่ารูปแบบใดบ้าง

ในทางกลับกันเราไม่เคยมีโอกาสเขียนเอกสารมากสำหรับ "วิธีการปะในสำนักงาน" แต่เอกสารที่สมบูรณ์ของเราก็ไม่ใช่รายการตรวจสอบ - มันกล่าวถึงการประชุมที่เราใช้สำหรับสีของสายเคเบิลเน้น คุณต้องอัปเดตสเปรดชีตที่ระบุการเชื่อมต่อและที่เกี่ยวกับมัน

ดังนั้นตอนนี้ที่ฉันเขียนสิ่งนี้ฉันเห็นด้วยอย่างยิ่ง: รายการตรวจสอบทีละขั้นตอนจะไม่ตัดสำหรับกระบวนการจำนวนมาก

ฉันเห็นด้วยอย่างยิ่งกับคุณในเรื่องนี้ (ในความโปรดปรานของเอกสารครบถ้วนสมบูรณ์) ส่วนหนึ่งเพราะฉันเคยมีรุ่นก่อนที่ไม่สนใจเอกสารเลย ในฐานะที่ได้รับการกล่าวว่าในการโพสต์ที่เกี่ยวข้องกับการเขียนมันออกมาไม่ได้เป็นเพียงที่ดีสำหรับคนอื่น ๆ แต่ช่วยให้คุณเข้าใจมากขึ้นอย่างเต็มที่และสภาพแวดล้อมของคุณแข็งในของคุณเองใจ มันจบลงด้วยตนเอง

นอกจากนี้ฉันพบว่าการกดปุ่มจำนวนมากมาจากความเชื่อที่แปลก ๆ ที่เอกสารที่ไม่มีเสี้ยวระยะ = ความปลอดภัยของงาน การคิดแบบนั้นดูเหมือนไม่น่าไว้วางใจและร่มรื่น

ขอชื่นชมคุณในการรักษาสถานะที่เป็นอยู่

ฉันบันทึกเอกสารค่อนข้างมากฉันยังมีรายการตรวจสอบลำดับความสำคัญของเอกสาร :-) แต่ฉันจะไม่บันทึกสิ่งที่ถือเป็นความรู้ทั่วไป (เช่นคำอธิบายที่ดีพอสมควรของปัญหาให้คำตอบในหน้าแรกของ google)

สำหรับทุกคนที่สนใจที่นี่คือรายการตรวจสอบ doc prio ของฉัน (เหมาะสำหรับฉันอาจไม่เหมาะสำหรับคุณความคิดเห็นและข้อเสนอแนะได้รับการชื่นชมอย่างมาก):

1. สร้างบันทึกส่วนตัว / ไดอารี่ที่คุณจดทุกสิ่งที่คุณทำงาน / ความรู้อย่างชาญฉลาด
2. บริการใดที่ให้บริการคืออะไรมันทำอะไรและใครทำอะไรบ้าง (ข้อตกลง SLA ใดควรสร้างขึ้นมาหนึ่งข้อ)
3. เซิร์ฟเวอร์เซิร์ฟเวอร์ใดอยู่ที่ไหนอายุเท่าไหร่และเขียนเมื่อไร
4. ข้างต้น แต่สำหรับอุปกรณ์เครือข่าย UPS และอื่น ๆ
5. ข้างต้น แต่สำหรับผู้ใช้ทุกเครื่อง
6. เลย์เอาต์ของเครือข่ายทางกายภาพ (ซึ่งสายเคเบิลจะไปที่ใดระยะเวลานานและคุณภาพของการวัด)
7. ภาพรวมการกำหนดค่าของซอฟต์แวร์และสิทธิ์ใช้งานสำหรับเซิร์ฟเวอร์
8. ภาพรวมการกำหนดค่าของซอฟต์แวร์และใบอนุญาตสำหรับเครื่องของผู้ใช้
9. ภาพรวมการกำหนดค่าของสวิตช์เราเตอร์และฮาร์ดแวร์เฉพาะอื่น ๆ
10. สัญญาและ SLA ของบุคคลภายนอกทั้งหมดที่บริการของฉันขึ้นอยู่กับโดยตรง (ISP, โดเมน ฯลฯ )
11. ตั้งค่าระบบตั๋วด้วยวิกิแบบรวมเพื่อใส่ทุกอย่างไว้ในนั้น
12. สำหรับทุกเหตุการณ์สร้างตั๋ว (แม้ว่าคุณจะใช้เพื่อตนเองเท่านั้น)
13. สร้างสคริปต์ที่ในวันอาทิตย์รวบรวมตั๋วและจัดกลุ่มตามประเภทของปัญหา
14. ในวันจันทร์ที่สร้างโซลูชันอัตโนมัติหรือเอกสารวิธีการผู้ใช้ปลายทางสำหรับปัญหาที่เกิดขึ้นมากที่สุด
15. หากเวลาอนุญาตให้ทำสิ่งต่อไป
16. ถ้าไม่มีอะไรทำให้มองหางานใหม่และให้คนที่แทนที่คุณด้วยบันทึก ;-)

รายการตรวจสอบนั้นใช้ได้ตราบใดที่เอกสารดังกล่าวไม่ได้ทำเป็นเอกสารที่สมบูรณ์ เอกสารล่าสุดที่ฉันเขียนมามีสองส่วนด้วยกัน: XYZ สำหรับผู้ใช้ซึ่งรวมถึงภาพหน้าจอสวย ๆ เกี่ยวกับวิธีใช้งาน และ XYZ สำหรับผู้ดูแลระบบซึ่งรวมถึงวิธีการตั้งค่าและทำไม (อาจรวมถึงความต้องการทางธุรกิจเพื่อให้มีอยู่) กับดักเพื่อหลีกเลี่ยงและส่วนในการแก้ไขปัญหา การแก้ไขปัญหาคือที่ที่ฉันคาดว่าจะพบรายการตรวจสอบ บางทีการเขียนรายการตรวจสอบเป็น XYZ สำหรับฝ่ายสนับสนุนด้านเทคนิคอาจช่วยชี้ประเด็น

ตอนนี้การอ่านระหว่างบรรทัดการจดจ่อกับรายการตรวจสอบเท่านั้นทำให้ฉันขาดความคิด "บิ๊กรูปภาพ" และการวางแผนระยะยาวที่ฉันคาดหวังจากใครบางคนที่เคยสนับสนุนเทคโนโลยีมาแล้วเท่านั้น หรือผู้ดูแลระบบที่เพิ่งเริ่มต้น; หรือล้นมือกับงานที่พวกเขาไม่มีเวลาคิด หรือไม่เคยถูกผลักให้คิด หรือแค่ธรรมดาก็ไม่สนใจ ฉันไม่รู้ว่าจะใช้ข้อใดในกรณีของคุณ

ฉันค่อนข้างใหญ่ในเอกสาร บริษัท ที่ฉันทำงานอยู่ตอนนี้รู้สึกว่าเอกสารเป็นสิ่งสำคัญ แต่บางคนใน บริษัท รู้สึกว่าพวกเขาไม่มีเวลาเขียนเอกสาร สิ่งนี้สามารถทำให้ชีวิตยากลำบากสำหรับทุกคนนอกเหนือจากบุคคลที่เคยทำมา

สำหรับบางสิ่งฉันได้เขียนคำแนะนำทีละขั้นตอน คุณสามารถเรียกรายการตรวจสอบนี้หากคุณต้องการ แต่มันไม่ได้ตั้งใจที่จะตรวจสอบทางกายภาพ ฉันเรียกเอกสารของฉันว่า "ขั้นตอนอนุบาล" มันถูกออกแบบมาตามแบบฝึกหัด MCSE ที่ฉันมีสำหรับการสอบ Windows 2000 ขั้นตอนมีรายละเอียดมาก แต่การใช้ตัวหนา / ตัวเอียง / แบบอักษรทำให้ง่ายต่อการปัดเศษและเลือกส่วนที่สำคัญเพื่อให้คุณไม่จำเป็นต้องอ่านทุกอย่างหลังจากที่คุณเรียนรู้ขั้นตอน

บางสิ่งบางอย่างไม่ค่อยดีสำหรับคำแนะนำทีละขั้นตอนดังนั้นฉันจึงพยายามให้ข้อมูลการกำหนดค่ามากที่สุดเท่าที่จะทำได้ ผู้ที่มีความโน้มเอียงทางเทคนิคบางคนที่ลงเอยที่การดูแลรักษาถนนจะมีความคิดที่ดีขึ้นเกี่ยวกับสิ่งที่พวกเขาต่อต้านและหวังว่ามันจะทำให้ชีวิตของพวกเขาง่ายขึ้นเล็กน้อยเมื่อมีอะไรผิดพลาด