Let It Crash
The Way It Is
ความน่าเชื่อถือ (Reliability) เป็นหนึ่งในคุณสมบัติที่ดีของซอฟต์แวร์ ความน่าเชื่อถือว่ามันทำงานได้ถูกต้อง และความน่าเชื่อถือว่ามันจะพร้อมให้บริการตลอดเวลา นี่คือที่มาของความคิดที่นักพัฒนาซอฟต์แวร์ทุกคนจำขึ้นใจ — “ซอฟต์แวร์ห้ามแครช”
การออกแบบ การเขียนโค๊ด การทดสอบ ทุกอย่างถูกสร้างขึ้นด้วยปรัชญานี้หมด เพราะ No Crash = More Reliable หลายคนคิดแบบนี้ ที่จริงแล้วมันก็ไม่มีปัญหาอะไรหรอกถ้าเราทำแบบนั้นได้จริง แต่สำหรับคนที่ทำงานมานานจะพอรู้ว่าไม่มีซอฟต์แวร์ไหนที่ไม่มีบั๊ก ไม่มีระบบไหนที่ล่มไม่ได้ (แม้แต่ Facebook / Google เองก็ล่มมาแล้วทั้งนั้น) ความพยายามป้องกันไม่ให้เกิดแครชจึงเป็นเรื่องยากมาก เหนื่อยมาก ถึงขั้นเป็นไปไม่ได้เลย
- ถ้าไฟดับ?
- ถ้า Hardware เจ๊ง?
- ถ้า Database Server ล่ม?
- ถ้าระบบที่เราไปเชื่อมต่อด้วยทำงานผิดพลาด?
- สาเหตุอื่นๆอีกมากมายที่เราไม่สามารถล่วงรู้และควบคุมได้
The Way It Can Be
ในอีกขั้วหนึ่ง ด้วยความพยายามที่จะสร้างความน่าเชื่อถือให้กับซอฟต์แวร์ของตัวเองเช่นกัน เค้ามองเรื่องนี้ในมุมกลับว่า ซอฟต์แวร์ที่เกิดแครชแต่สามารถรักษาตัวเองแล้วกลับมาให้บริการได้ใหม่ในทันทีก็มีความน่าเชื่อถือไม่แพ้กัน
นี่คือที่มาของปรัชญา “Let It Crash” (ปล่อยให้ล่มไป) การออกแบบ การเขียนโค๊ด และการทดสอบจะมุ่งเป้าไปที่นี่ เมื่อเกิดแครชแล้วซอฟต์แวร์จะกู้ซากตัวเองขึ้นมาได้โดยอัตโนมัติ (ไม่มีคนไปเกี่ยวข้อง) ได้อย่างไร … มันทำให้เราเริ่มคิดถึง
- การแบ่งโปรเซสการทำงานให้เล็กและสั้นเพื่อตรวจสอบความผิดพลาดได้รวดเร็ว
- การสร้างและจัดการคิวให้โปรเซสอย่างมีระบบและการติดตามความคืบหน้าของงานในแต่ละโปรเซสเพื่อเตรียมพร้อมในการแชร์และส่งต่องานไปให้ระบบสำรอง
- การมีระบบฮาร์ดแวร์และซอฟต์แวร์สำรองที่พร้อมรองรับงานจากระบบหลักเมื่อเกิดปัญหา
- การทดสอบว่าต่อให้ซอฟต์แวร์บางส่วนแครชแต่ระบบทั้งหมดยังทำงานได้ ต่อให้เซิร์ฟเวอร์พังทั้งเครื่องระบบทั้งหมดจะยังทำงานได้
Let It Crash จะทำให้เราไม่กลัวคำว่าแครชเพราะตอนนี้เรามีระบบที่แข็งแรงและน่าเชื่อถือมากพอที่จะรับมือกับปัญหาที่จะเกิดขึ้นแล้ว
ระบบที่แข็งแรงไม่ใช่ระบบที่ไม่เคยล่มแต่เป็นระบบที่ล่มแล้วคืนชีพได้อย่างรวดเร็ว คนที่แข็งแกร่งไม่ใช่คนที่ไม่เคยล้มแต่เป็นคนที่ล้มแล้วลุกขึ้นมาใหม่ได้อย่างรวดเร็วทุกครั้ง ปรัชญานี้น่าสนใจในหลายกรณี ไม่ใช่แค่ซอฟต์แวร์ ไม่ใช่แค่เรื่องคน แม้แต่เรื่องการสร้างทีมงาน — ทีมที่แข็งแกร่งไม่ใช่ทีมที่ไม่เคยล้มเหลวแต่เป็นทีมที่ไม่ยอมแพ้ต่ออุปสรรค
- ถูกลูกค้าปฎิเสธ
- สมาชิกคนสำคัญหายไป
- เปลี่ยนหัวหน้า
- เปลี่ยนโปรเจกต์
อย่าเสียแรงและเวลาทั้งหมดไปกับการป้องกันความล้มเหลวแต่จงให้เวลากับการสร้างภูมิคุ้มกันเมื่อความล้มเหลวมันเกิดขึ้นจริงๆจะดีกว่า
ป.ล. “Let It Crash” เป็นปรัชญาที่ผมได้มาจากการอ่านเวปไซต์นี้ครับ http://akka.io/ — Akka เป็นเครื่องมือที่ช่วยให้เราสร้างระบบที่มีความน่าเชื่อถือสูงๆได้โดยง่าย (จริงๆไม่ง่ายสำหรับผมหรอก) ฮ่าๆ
