Centering เป็นท่าหนึ่งของการโค้ชที่ผมใช้บ่อยมาก เป็นการทำสมาธิก่อนจะเข้าไปในบริบทของทีม ซึ่งเป็นท่าแรกของกระบวนท่า center, enter, turn ผมแปล centering เป็นไทยว่า เข้าสู่สมดุลย์

การกลับสู่สมดุลย์ประกอบด้วยสามส่วนคือ กาย, อารมณ์ และ ภาษา ผมแอบเล่าเรื่องนี้ในบทความที่ผมเล่าความต่างระหว่าง ความเห็นอกเห็นใจ และความเข้าอกเข้าใจไปแล้ว วันนี้ผมอยากแยกมันออกมาเป็นบทความตัวเอง จะได้เห็นกันชัด ๆ

ฐานกาย

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

ฐานอารมณ์

ปรับอารมณ์ให้อยู่ที่การยอมรับ การยอมรับเป็นอารมณ์ที่กลางที่สุดแล้ว ไม่ดี ไม่ร้าย พร้อมเปิดรับทุกอย่าง

ฐานภาษา

ทำให้เสียงในหัวเงียบ ความเงียบคือจุดศูนย์กลางของภาษา

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

บทความที่เกี่ยวข้อง

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

ทีมที่แก้ปัญหาได้เร็ว ทุกหน่วยงานจะแบ่งปันข้อมูลต่าง ๆ อย่างโปร่งใส แล้วหาคำตอบแค่ 4 ข้อดังนี้

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

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

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

เราสามารถทำอะไรเพื่อลดความเสียหายทางธุรกิจที่กำลังดำเนินไปได้บ้าง?

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

ผมพบว่าเวลามีคนมาบอกให้ทีมพัฒนา log ของในระบบหรือแอพพลิเคชันที่กำลังสร้าง เพื่อให้สามารถวิเคราะห์ปัญหาบน production ได้ เวลาระบบถูกใช้งาน บ่อยครั้งผมพบว่าทีมพัฒนาไม่รู้ว่าจะ log อะไรดี เพราะ ประสบการณ์สอนทีมพัฒนาซ้ำแล้วซ้ำเล่าว่า สิ่งที่ log ไว้จะไม่ได้ดู และสิ่งที่อยากดูจะไม่ได้ log

วันนี้ผมเอาของจากหนังสือ The DevOps Handbook มาแบ่งปันว่ามีอะไรบ้างที่นับว่าเป็น event สำคัญ ๆ ที่ควร log ไว้ เพื่อเราจะได้มีข้อมูลเพียงพอที่จะดูแลระบบ production

list ด้านล่างนี้ถูกรวบรวมโดย research VP ที่ Gartner’s GTP Security and Risk Management ชื่อ Anton A. Chuvakin นะครับ

• การตัดสินใจเกี่ยวกับ authentication และ authorization (รวมถึง logoff ด้วย)
• การเข้าถึงระบบและข้อมูล
• การเปลี่ยนแปลงในระบบและแอพพลิเคชันต่าง ๆ (โดยเฉพาะการเปลี่ยนแปลงที่เกิดขึ้นแบบพิเศษ) เช่น ตอน deploy หรือ upgrade OS ของเครื่อง
• การเปลี่ยนแปลงของข้อมูล เช่นการเพิ่ม, แก้ไข หรือลบ
• input ผิด ๆ (ซึ่งอาจจะกลายเป็นหลักฐานว่าเรากำลังโดนเจาะ/โจมตี)
• resources ต่าง ๆ (RAM, disk, CPU, bandwidth หรือทรัพยากรอื่น ๆ ที่มีขีดจำกัดทั้งที่เรากำหนดเองและขีดจำกัดเครื่อง)
• สุขภาพของระบบและ availability (อยู่หรือร่วง)
• ตอนระบบ startups และ shutdowns
• faults และ errors ต่าง ๆ
• เวลา circuit breaker ทำงาน
• delays ต่าง ๆ
• backup สำหร็จ / ล้มเหลว

บทความที่เกี่ยวข้อง

ช่วงนี้ผมกำลังอ่านหนังสือ The DevOps Handbook แล้วเจอคำอธิบายของ Log 5 ระดับที่ผมเห็นบ่อย ๆ คิดว่าอาจจะมีประโยชน์กับคนอ่าน ก็เลยเอามาแบ่งปันครับ

DEBUG

เป็นรายละเอียดลึก ๆ ของโปรแกรม ซึ่งโปรแกรมเมอร์จดไว้เพื่อ debug ปัญหาบน production ซึ่งปรกติจะปิดไว้ และเปิดชั่วคราวเมื่อจำเป็น

จากประสบการณ์ของผม ในระบบที่ใหญ่มาก ๆ debug log จะเปิดเป็นส่วน ๆ ตาม feature หรือ component ได้ เพื่อไม่ให้กระทบกับ performance โดยรวมของระบบมากเกินไป และบางระบบก็รองรับการเปิดและปิดโดยไม่ต้อง restart server ด้วย

INFO

เป็นพฤติกรรมของ user หรือสิ่งที่ระบบทำ เช่น เริ่มตัดบัตรเครดิต เป็นต้น

WARN

เอาไว้เตือนสิ่งที่อาจจะทำให้เกิด error ได้ เช่น เตือนเวลา database ตอบช้ากว่าเวลาที่เรากำหนดไว้ บ่อยครั้ง log ระดับนี้จะ trigger alert และทำให้ทีมรู้ตัวว่าต้องเริ่มวิเคราะห์ปัญหาละโดยทีมอาจจะดู log อื่น ๆ ประกอบเพื่อหาว่าอะไรทำให้เกิดการเตือนครั้งนี้

ERROR

เอาไว้แจ้ง error เช่น API call แล้วได้ error หรืออาจจะเป็น internal error ต่าง ๆ

จากประสบการณ์ของผม บางครั้ง log ประเภทนี้คนที่พัฒนากับคนดูแลระบบจะมาตกลงกัน ว่า error ประเภทไหนบ้างที่ต้อง monitor หรือ trigger system alert

FATAL

อันนี้เอาไว้แจ้งกรณีที่ระบบต้องปิดตัวลง เช่น เชื่อมต่อ network ไม่ได้เป็นต้น

วิธีเลือกระหว่าง WARN กับ ERROR

ในฐานะคนพัฒนา บางครั้งผมรู้สึกว่าเส้นแบ่งระหว่าง WARN กับ ERROR มันเบลอ ๆ แยกยากมากเลย

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

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

ผมหยิบใบเสร็จไปแบบเดิม ไปถึงหน้าเคาน์เตอร์ผมก็บอกความต้องการว่าผมจะจ่ายรายปี ให้เค้าคำนวนยอดมาให้ตามปรกติ ผมก็บอกเค้าว่าให้ออกใบกำกับให้ด้วย แล้วสิ่งมี่ไม่คาดฝันก็เกิดขึ้น

พนักงานก็ถามผมว่า

พนักงาน: หัก ณ ที่จ่ายด้วยไหมครับ?

ผมอึ้งไปแป๊บนึง เพราะว่าผมจำไม่ได้เลยว่าปีที่แล้วมีการหัก ณ ที่จ่ายด้วย

ผม: ขอปรึกษาบัญชีแปปนึงนะครับ

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

ผมบ่นกระปอดกระแปดกับพนักงานว่า ปีที่แล้วไม่เห็นมีหัก ณ ที่จ่ายเลย พนักงานตรวจดูในระบบแล้วตอบกลับว่า “ปีที่แล้วก็หักนะครับ”

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

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

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

ผมเลยสร้างอีเว้นท์รายปี เขียนขั้นตอนพร้อมถ่ายรูปของที่เสร็จแล้วลงไป ผมในปีหน้าเปิดจะได้จำได้

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

เพื่อน ๆ มี time machine แห่งการเรียนรู้เหมือนผมไหมครับ? เอามาแบ่งปันกันนะ ขอบคุณที่สละเวลาอ่านครับ