นิ่ง

Share
นิ่ง
Photo by David Tip on Unsplash

น้อง ๆ ที่ทำงานถามกับผมว่า
“ทำไมพี่นิ่งจัง”
“พี่ดูใจเย็น”

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

ผมตอบกลับไปว่า
“รู้จัก Hulk มั้ยล่ะ”

แล้วผมก็ยิ้ม


ใน The Avengers
มีประโยคหนึ่งที่ผมชอบมาก

“That’s my secret, Cap. I’m always angry.”

มันไม่ใช่การ “ระเบิดอารมณ์”
แต่มันคือการ “อยู่กับมันได้ตลอดเวลา”


การเป็นวิศวกรซอฟต์แวร์
โดยเฉพาะในวันที่ระบบกำลังจะพัง
มันไม่ต่างอะไรกับการถือระเบิดเวลาไว้ในมือ

  • ระบบล่ม แต่ลูกค้ากำลังใช้งานอยู่
  • API พัง แต่ dependency อีก 5 ตัวรออยู่
  • log เต็มไปด้วย error แต่ไม่มีใครบอกได้ว่า root cause คืออะไร
  • ทีมเริ่มสื่อสารกันไม่รู้เรื่อง
  • decision ที่ควรชัด กลับเต็มไปด้วยความลังเล

นี่ไม่ใช่แค่ “ปัญหาเทคนิค”
แต่มันคือ “แรงกดดัน” ที่ถาโถมเข้ามาพร้อมกัน


คนส่วนใหญ่พอเจอสถานการณ์แบบนี้
จะมี 2 แบบ

แบบแรก: ตื่นตระหนก
แบบที่สอง: เงียบ… แต่กำลังจะระเบิด

แต่มีอีกแบบหนึ่ง
ที่ไม่ได้ถูกพูดถึงบ่อยนัก

คือ “นิ่ง”


ความนิ่ง ไม่ได้แปลว่า “ไม่รู้สึก”
แต่แปลว่า “ควบคุมสิ่งที่รู้สึกได้”

คุณยังเห็นความพังทั้งหมดเหมือนเดิม
คุณยังรู้ว่ามันแย่แค่ไหน
คุณยังรู้ว่าถ้าพลาดอีกนิด มันจะลุกลาม

แต่คุณ “ไม่ปล่อยให้มันควบคุมคุณ”


ผมไม่ได้ใจเย็นโดยธรรมชาติ

ผมเคย panic
เคยพิมพ์ command ผิดตอน production ล่ม
เคย deploy แก้ bug แล้วทำให้ bug ใหม่หนักกว่าเดิม
เคยเถียงกันในทีมจนหลุดโฟกัสจากปัญหาจริง

แต่พอเจอบ่อยเข้า
คุณจะเริ่มเข้าใจบางอย่าง

ความวุ่นวาย ไม่ได้ต้องการ “คนเก่งที่สุด”
แต่มันต้องการ “คนที่นิ่งที่สุด”

เวลาระบบพัง
สิ่งที่ทีมต้องการ ไม่ใช่คนที่คิดได้ 10 วิธี
แต่คือคนที่เลือก “1 วิธีที่ชัด” แล้วพาทีมไป

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

เวลาทุกอย่างดูควบคุมไม่ได้
สิ่งที่สำคัญที่สุด คือ
“ใครบางคนที่ยังควบคุมตัวเองได้”


ความนิ่ง มันส่งต่อได้

ถ้าคุณนิ่ง
ทีมจะเริ่มนิ่งตาม

ถ้าคุณ panic
panic จะกระจายเร็วกว่า incident อีก


ผมไม่ได้เก่งกว่าใคร
ผมแค่ “ฝึกอยู่กับความโกลาหล” บ่อยพอ

เหมือน Hulk
มันไม่ใช่ว่าเขาไม่โกรธ
เขาแค่ “คุ้นเคยกับมัน”


แต่ความคุ้นเคยแบบนี้
มันไม่ได้เกิดขึ้นเอง

มันถูก “ซ้อม”


ผมได้แนวคิดนี้มาจาก Marcus Aurelius
ที่พูดถึงการเตรียมใจรับสิ่งเลวร้ายล่วงหน้า

ทุกเช้าระหว่างเดินทางไปทำงาน
ผมจะจินตนาการว่า…

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

ผมไม่ได้แค่คิดเล่น ๆ

ผม “ดันมันไปให้สุด”


ผมปล่อยให้ตัวเองโกรธ
หงุดหงิด
ไม่พอใจ

เหมือนมันเกิดขึ้นจริงตรงหน้า

จนถึงจุดที่รู้สึกว่า
“ถ้าเกิดขึ้นจริง มันก็เลวร้ายชะมัด”

ผมกำหมัดทุกเช้า


แล้วผมก็หยุด

แล้วกลับมาเป็นปกติ


สิ่งที่เปลี่ยนไป
ไม่ใช่โลก

แต่เป็น “ตัวผมเอง”


พอเหตุการณ์จริงเกิดขึ้น

มันไม่ใช่ครั้งแรกอีกต่อไป

ผมเคย “ผ่านมันมาแล้ว”
ในหัวของตัวเอง


นี่แหละคือเหตุผลที่ผมนิ่ง

ไม่ใช่เพราะผมไม่โกรธ
แต่เพราะผม “รู้จักความโกรธดีพอแล้ว”


ผมไม่ได้รอให้สถานการณ์ควบคุมผม
ผม “ซ้อมให้ตัวเองคุมมัน” ไว้ก่อนแล้ว


ทุกระบบที่คุณดูแล
วันหนึ่งมันจะพัง

ทุก architecture ที่คุณภูมิใจ
วันหนึ่งมันจะเผยจุดอ่อน

ทุกทีมที่คุณเชื่อใจ
วันหนึ่งจะสื่อสารกันไม่เข้าใจ

มันหลีกเลี่ยงไม่ได้


สิ่งเดียวที่คุณเลือกได้
คือ ตอนที่มันเกิดขึ้น

คุณจะ “เป็นอะไร”

  • คนที่เติมความวุ่นวายเข้าไป
    หรือ
  • คนที่ทำให้มันนิ่งลง

และบางที
ความนิ่งของคุณ
ไม่ได้เกิดจากความใจเย็น

แต่มาจาก
“ความโกลาหลที่คุณเคยเผชิญมันมาแล้ว — ล่วงหน้า”


“ความเก่ง ทำให้คุณแก้ปัญหาได้”

“แต่ความนิ่ง ทำให้คุณยังเป็นคนที่คนอื่นพึ่งได้ ในวันที่ทุกอย่างพัง”


หากบทความนี้มีประโยชน์

คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง

ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer

แบบไม่ต้องใส่สูท

แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ

Read more

The Five Ideals

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

By Chokchai Phatharamalai
Communication, Reliability and Modern concepts - System Design, Simply Explained

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API

By Boonsong Srithong
Race condition

Race condition

ผมกำลังอ่านหนังสือ The Unicorn Project ซึ่งเป็นนิยายเกี่ยวกับ developer สาวคนหนึ่งที่ใช้ชีวิตในองค์กรท่ามกลางกระแส digital disruption อ่านแล้วสนุกมาก เป็นเรื่องที่ตื่นเต้น และหลาย ๆ dynamic ที่เกิดขึ้นก็คล้ายกับที่ผมพบเจอในบริษัทซอฟต์แวร์ เลยทำให้

By Chokchai Phatharamalai
Distributed Systems Concepts - System Design, Simply Explained

Distributed Systems Concepts - System Design, Simply Explained

ในช่วงแรก Product เราสามารถออกแบบระบบให้อยู่ใน Server และ Database เดียวกันได้ แต่เมื่อระบบโตขึ้น มีผู้ใช้งานเพิ่มขึ้น ข้อมูลเยอะขึ้น ระบบเริ่มทำงานช้าลดเรื่อยๆ สิ่งที่หนีไม่ได้คือการ Decomposition Service ไปเป็น Distributed System เช่น Member Service, Booking Service, Payment

By Boonsong Srithong