AUT-12 · ประสบการณ์
การทำงานอัตโนมัติและการเขียนสคริปต์ที่ทีมของคุณอ่านและไว้วางใจได้
ผมรับงานซ้ำซากที่ต้องทำด้วยมือ ซึ่งกินเวลาทั้งสัปดาห์ของทีมคุณ มาเปลี่ยนให้เป็นสคริปต์ที่ทำงานได้เองและรายงานสิ่งที่มันทำ ผมเขียนด้วย Bash, PowerShell และ Python เก็บทุกอย่างไว้ใน Git และใส่การบันทึกล็อกเพื่อให้คุณเห็นการทำงานทุกครั้งแทนที่จะต้องเดา เป้าหมายคือการทำงานอัตโนมัติที่คนของคุณอ่าน ทบทวน และเป็นเจ้าของได้เองหลังจากผมส่งมอบ ไม่ใช่กล่องดำที่มีแต่ผมเท่านั้นที่เข้าใจ
01 · สิ่งที่ผมทำ
เนื้องานจริง
- แทนที่งานซ้ำซากที่ต้องทำด้วยมือ ด้วยสคริปต์ Bash, PowerShell หรือ Python ที่เข้ากับสภาพแวดล้อมเดิมของคุณ
- เพิ่มการบันทึกล็อก, exit code และการแจ้งเตือน เพื่อให้ทุกการทำงานมองเห็นได้ และความล้มเหลวถูกสังเกตเห็น ไม่ใช่ถูกกลบหาย
- ออกแบบให้มีค่าเริ่มต้นที่ปลอดภัยในตัว: โหมด dry-run, การตรวจสอบค่าที่ป้อนเข้า และจุดหยุดที่ชัดเจนก่อนการกระทำใดๆ ที่ทำลายข้อมูล
- จัดการข้อมูลรับรองและความลับอย่างถูกวิธี ให้อยู่นอกตัวสคริปต์และนอกข้อความธรรมดา
- จัดเก็บเวอร์ชันทุกอย่างใน Git ด้วยคอมมิตและคอมเมนต์ที่อ่านง่าย เพื่อให้คนถัดไปตามตรรกะได้
- ตั้งเวลางานและเชื่อมเข้ากับ cron, Task Scheduler หรือ CI ของคุณ เพื่อให้ทำงานได้โดยไม่ต้องมีคนคอยเฝ้า
- จัดทำเอกสารแต่ละสคริปต์ด้วยภาษาที่เข้าใจง่าย: มันทำอะไร, รันอย่างไร และปิดการทำงานอย่างไร
02 · สิ่งที่คุณได้รับ
สิ่งที่ยังอยู่กับคุณ
- เวลาหลายชั่วโมงต่อสัปดาห์จากงานที่ทำด้วยมือ ถูกคืนกลับให้ทีมของคุณ
- สคริปต์ที่วิศวกรของคุณเองอ่าน แก้ไข และดูแลรักษาได้โดยไม่ต้องมีผม
- ร่องรอยล็อกที่ชัดเจน แสดงว่าอะไรทำงาน เมื่อไร และสำเร็จหรือไม่
- ความผิดพลาดของคนน้อยลงในงานประจำที่เคยต้องพึ่งความจำ
- เอกสารภาษาที่เข้าใจง่าย เพื่อให้การพาคนใหม่เข้างานใช้เวลาเป็นนาที ไม่ใช่เป็นสัปดาห์
03 · เครื่องมือและความรู้
สิ่งที่ผมใช้ทำงานในด้านนี้
04 · วิธีที่ผมลงมือทำ
วางแผน กำหนดขอบเขต และรับผิดชอบจนจบ
ผมเริ่มด้วยการพูดคุยกำหนดขอบเขต 30 นาที แล้วส่งบทประเมินความเหมาะสมเป็นลายลักษณ์อักษรภายในวันเดียวกัน เพื่อให้เราทั้งสองฝ่ายรู้ว่างานนี้คุ้มค่าที่จะทำก่อนที่ใครจะผูกมัด สำหรับงานใดก็ตามที่กระทบระบบที่ใช้งานจริง ผมจะเขียนแผนการเปลี่ยนแปลงที่มีเอกสารพร้อมแนวทางย้อนกลับไว้ก่อน จากนั้นทดสอบสคริปต์ในโหมดปลอดภัยกับข้อมูลจริงก่อนที่มันจะลงมือทำ การสับเปลี่ยนเข้าใช้งานจริงเกิดขึ้นภายในช่วงเวลาที่กำหนด ตรวจสอบกับเกณฑ์ที่เราตกลงกันไว้ล่วงหน้า โดยมีแนวทางย้อนกลับที่ผมรับผิดชอบและเตรียมพร้อมไว้หากเกณฑ์ใดไม่ผ่าน ไม่มีสิ่งใดถูกนำขึ้นใช้งานจริงหากผมย้อนกลับไม่ได้ และไม่มีสิ่งใดถูกส่งมอบโดยไม่มีเอกสารที่ทีมของคุณใช้งานได้จริง
05 · คำถาม
คำถามที่ดี คำตอบที่ตรงไปตรงมา
ทีมของเราจะดูแลรักษาสคริปต์เหล่านี้ต่อได้เองไหมหลังจากคุณไปแล้ว?
ได้ครับ นั่นแหละคือหัวใจสำคัญ ผมเขียนโค้ดที่อ่านง่าย เก็บไว้ใน Git ใส่คอมเมนต์ในส่วนที่ซับซ้อน และจัดทำเอกสารอธิบายวิธีรันและหยุดแต่ละสคริปต์ด้วยภาษาที่เข้าใจง่าย คุณไม่ได้ถูกผูกไว้กับผม
คุณทำอย่างไรไม่ให้สคริปต์อัตโนมัติทำให้อะไรเสียหายในระบบที่ใช้งานจริง?
ผมออกแบบให้มีโหมด dry-run การตรวจค่าที่ป้อนเข้า และจุดหยุดที่ชัดเจนก่อนทุกขั้นตอนที่ทำลายข้อมูล และผมทดสอบกับข้อมูลจริงก่อนเสมอ สำหรับการเปลี่ยนแปลงในระบบที่ใช้งานจริง จะมีแผนที่มีเอกสารพร้อมแนวทางย้อนกลับที่มีผู้รับผิดชอบก่อนการสับเปลี่ยนเสมอ
ถ้ายังไม่แน่ใจว่าจะทำอะไรให้อัตโนมัติดีล่ะ?
เป็นเรื่องปกติครับ การพูดคุยกำหนดขอบเขต 30 นาทีมีไว้เพื่อค้นหางานซ้ำซากที่ควรทำให้อัตโนมัติก่อนเป็นอันดับแรก คุณจะได้รับบทประเมินเป็นลายลักษณ์อักษรภายในวันเดียวกันว่าอะไรเหมาะและอะไรไม่เหมาะ ก่อนที่คุณจะเสียค่าใช้จ่ายใดๆ
06 · ประสบการณ์ที่เกี่ยวข้อง
งานในด้านใกล้เคียงที่ผมทำ
ต้องการให้จัดการเรื่องนี้ไหม?
บอกผมได้เลยว่าคุณกำลังพยายามย้ายอะไร และติดขัดอยู่ตรงไหน แค่ไม่กี่ประโยคก็เริ่มได้แล้ว และมันจะส่งตรงถึงกล่องข้อความของผม