เทคนิคการตรวจสอบและแก้ปัญหา สำหรับผู้ดูแลระบบ Google Apps for Business

สำหรับผู้ดูแลระบบ Google Apps for Business ในองค์กรต่างๆ ซึ่งเป็นผู้ที่รับผิดชอบในการดูแลระบบให้ทำงานได้เรียบร้อย สิ่งที่อยู่คู่กับการดูแลระบบก็คือการแก้ไขปัญหาในการใช้งาน ให้สามารถทำงานได้เรียบร้อยเป็นปกติ

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


How to think like a troubleshooter


Define the problem

หมายถึงการระบุปัญหาที่เกิดขึ้นให้ชัดเจน ว่าปัญหาคืออะไรพร้อมบริบทของปัญหานั้น การแก้ปัญหาจะทำได้ยากมาก ถ้าเรายังไม่เข้าใจว่าปัญหาคืออะไร 

ตัวอย่างคลาสสิค คือ "ผู้ใช้ส่งอีเมลไม่ได้" ซึ่งการระบุปัญหาในรูปแบบนี้จะไม่ได้ให้ข้อมูลที่เป็นประโยชน์ในการแก้ไขปัญหา ถ้าลองระบุปัญหาเป็น "ผู้ใช้ pakorn.n@tangerine.co.th ส่งอีเมลไปหาปลายทาง niw@niwpopkorn.com และได้รับอีเมลตีกลับพร้อม error message 550: mailbox unavailable" ก็จะช่วยให้เห็นปัญหาได้ชัดเจนมากขึ้น และช่วยให้เราสามารถระบุสาเหตุที่เป็นไปได้ทั้งหมด ให้เหลือน้อยลง และทดสอบปัญหาได้ง่ายขึ้น

เปรียบเทียบการระบุปัญหาที่กว้างเกินไป (แบบบน) กับการระบุปัญหาที่ชัดเจน (แบบล่าง)


Define the scope

หมายถึงการระบุว่าปัญหานั้น มีผลกระทบในวงกว้างแค่ไหน โดยการตั้งคำถามว่า How many? (ขออนุญาตใช้ภาษาอังกฤษ เพราะจะช่วยให้เห็นความเชื่อมโยงของคำถามในแต่ละประเด็น)
  • How many users affected? (only 1 or all domain)
  • How many computers?
  • How many network?
  • How many devices?
การตอบคำถามของ How many? จะช่วยให้เราเห็นภาพรวมของปัญหา และสามารถสรุปปัญหาในเบื้องต้นได้ เช่น 
  • หากกระทบกับผู้ใช้คนเดียว ในขณะที่คนอื่นไม่เกิดปัญหา ปัญหาอาจจะเกิดจากผู้ใช้งานตั้งค่าบางอย่างไม่ถูกต้อง
  • หากปัญหาเกิดกับคอมพิวเตอร์เครื่องเดียว ปัญหาอาจจะเกิดจาก hardware หรือการตั้งค่าในคอมพิวเตอร์เครื่องนั้นๆ 
  • ในกรณีที่ผู้ใช้งานทั้งโดเมนเจออาการอย่างเดียวกัน ปัญหาอาจจะเกิดจากการตั้งค่าของ Google Apps ใน CPanel (admin สามารถตรวจสอบการเปลี่ยนค่าได้จาก Audit log)

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


Reproduce

หมายถึง การทำให้เกิดปัญหาเดียวกันขึ้นมาใน environment ของเราเอง ซึ่งการ reproduce ปัญหาได้นั้นจะต้องได้ข้อมูลจากการระบุปัญหา (Define the problem) ที่ชัดเจน ข้อดีของการ reproduce ปัญหานั้น คือเราได้ข้อมูลรายละเอียดต่างๆ ของปัญหา โดยไม่ต้องรอข้อมูลจากผู้ใช้ นอกจากนี้ยังช่วยให้เราระบุผลกระทบ (Define the scope) ได้อีกทางหนึ่ง


What's not the anwser?

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


Start time?

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



Check online

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

สำหรับผู้ดูแลระบบ Google Apps for Business คำแนะนำเหล่านี้จะช่วยให้การแก้ปัญหา มีรูปแบบมากขึ้น ช่วยให้เข้าใจปัญหาและจัดการกับปัญหาได้ง่าย รวดเร็ว และมีประสิทธิภาพมากยิ่งขึ้นครับ



สนใจใช้บริการ Google Apps for Business ติดต่อได้ ทีนี่
email: google@tangerine.co.th
---
www.tangerine.co.th

ความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

การเรียกใช้งาน Google Apps Script

ลดเวลาการเรียก API ใน Apps Script ด้วย fecthAll

ออกแบบระบบให้คุยข้าม module กันได้ ด้วย Pub/Sub