What Is Resiliency? (Resiliency คืออะไร)

เรา ใช้คำว่า resiliency ในบริบทและความหมายที่แตกต่างกันมากมาย ซึ่งอาจนำไปสู่ความสับสนว่าคำนี้หมายถึงอะไรกันแน่ และอาจทำให้เรามองประเด็นนี้แคบเกินไป นอกเหนือขอบเขตของงานด้าน IT แล้ว ยังมีสาขาที่กว้างกว่านั้นคือ resilience engineering ซึ่งมองแนวคิดเรื่องความยืดหยุ่นทนทานว่าใช้ได้กับระบบหลากหลายประเภท—ตั้งแต่การดับเพลิงไปจนถึงการควบคุมจราจรทางอากาศ ระบบชีวภาพ และห้องผ่าตัด David D. Woods ได้อาศัยองค์ความรู้จากสาขานี้พยายามจำแนกแง่มุมต่างๆ ของ resilience เพื่อช่วยให้เราคิดเรื่องความหมายที่แท้จริงของ resiliency ได้กว้างขึ้น 1 สี่แนวคิดนี้ได้แก่:

Robustness

ความสามารถในการรองรับความปั่นป่วน (perturbation) ที่คาดการณ์ไว้ล่วงหน้า

Rebound

ความสามารถในการฟื้นตัวหลังเหตุการณ์ร้ายแรง

Graceful extensibility

เรารับมือกับสถานการณ์ที่ไม่คาดคิดได้ดีแค่ไหน

Sustained adaptability

ความสามารถในการปรับตัวอย่างต่อเนื่องต่อสภาพแวดล้อม ผู้มีส่วนได้ส่วนเสีย และความต้องการที่เปลี่ยนแปลงไป

มาดูกันทีละแนวคิดว่าไอเดียเหล่านี้อาจ (หรืออาจจะไม่) แปลงมาใช้ในโลกของการสร้างสถาปัตยกรรม microservice ได้อย่างไร

Robustness (ความทนทาน)

Robustness คือแนวคิดที่เราสร้างกลไกเข้าไปในซอฟต์แวร์และกระบวนการทำงานของเรา เพื่อรองรับปัญหาที่คาดการณ์ไว้แล้ว เรามีความเข้าใจขั้นสูงเกี่ยวกับประเภทของความปั่นป่วนที่อาจเจอ และเราวางมาตรการไว้ล่วงหน้าเพื่อให้เมื่อปัญหาเหล่านี้เกิดขึ้น ระบบของเราสามารถรับมือได้ ในบริบทของสถาปัตยกรรม microservice เรามีความปั่นป่วนหลายรูปแบบที่อาจคาดเดาได้: host อาจล่ม การเชื่อมต่อเครือข่ายอาจ time out microservice ตัวใดตัวหนึ่งอาจใช้งานไม่ได้ เราสามารถพัฒนาความทนทานของสถาปัตยกรรมได้หลายวิธีเพื่อรับมือกับความปั่นป่วนเหล่านี้ เช่น การสร้าง host ทดแทนโดยอัตโนมัติ การทำ retry หรือการจัดการความล้มเหลวของ microservice ตัวใดตัวหนึ่งอย่างนุ่มนวล

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

ตามคำนิยาม robustness ต้องอาศัยความรู้ล่วงหน้า—เราวางมาตรการเพื่อรับมือกับความปั่นป่วนที่รู้จักอยู่แล้ว ความรู้นี้อาจมาจากการคาดการณ์ล่วงหน้า (foresight): เราอาจอาศัยความเข้าใจเกี่ยวกับระบบคอมพิวเตอร์ที่เรากำลังสร้าง บริการสนับสนุนต่างๆ และทีมงานของเรา เพื่อพิจารณาว่าอะไรอาจผิดพลาดได้ แต่ robustness ก็อาจมาจากการมองย้อนกลับ (hindsight) ได้เช่นกัน—เราอาจพัฒนาความทนทานของระบบหลังจากที่มีบางอย่างที่เราไม่ได้คาดคิดเกิดขึ้น บางทีเราไม่เคยคิดว่า global filesystem ของเราอาจใช้งานไม่ได้ หรือบางทีเราประเมินผลกระทบจากการที่ทีมบริการลูกค้าไม่พร้อมให้บริการนอกเวลาทำการต่ำเกินไป

หนึ่งในความท้าทายของการพัฒนา robustness ของระบบคือ ยิ่งเราเพิ่มความทนทานให้กับแอปพลิเคชันมากเท่าไร เราก็ยิ่งเพิ่มความซับซ้อนเข้าไปในระบบมากเท่านั้น ซึ่งอาจกลายเป็นต้นตอของปัญหาใหม่ๆ ได้ สมมติว่าคุณกำลังย้ายสถาปัตยกรรม microservice ของคุณไปที่ Kubernetes เพราะต้องการให้มันจัดการ desired state ของ workload ต่างๆ ในระบบ microservice ของคุณ คุณอาจพัฒนาบางแง่มุมของความทนทานของแอปพลิเคชันได้จริง แต่คุณก็ได้นำจุดเปราะบางใหม่ๆ เข้ามาด้วยเช่นกัน ดังนั้น ความพยายามใดๆ ในการพัฒนาความทนทานของแอปพลิเคชันจึงต้องพิจารณาไม่ใช่แค่ในแง่การวิเคราะห์ cost/benefit แบบง่ายๆ แต่ต้องพิจารณาด้วยว่าคุณพอใจกับระบบที่ซับซ้อนขึ้นซึ่งจะได้มาจากสิ่งนี้หรือไม่

Robustness เป็นด้านหนึ่งที่ microservices มอบตัวเลือกให้คุณมากมาย และเนื้อหาส่วนใหญ่ในบทนี้จะเน้นไปที่สิ่งที่คุณทำได้ในซอฟต์แวร์เพื่อพัฒนาความทนทานของระบบ เพียงแค่จำไว้ว่านี่เป็นเพียงแง่มุมเดียวของ resiliency โดยรวม และยังมี robustness ที่ไม่เกี่ยวกับซอฟต์แวร์อีกมากมายที่คุณอาจต้องพิจารณา

Rebound (การฟื้นตัว)

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

เราสามารถพัฒนาความสามารถในการฟื้นตัวจากเหตุการณ์ได้ โดยการวางมาตรการไว้ล่วงหน้า ตัวอย่างเช่น การมี backup ไว้ล่วงหน้าช่วยให้เราฟื้นตัวได้ดีขึ้นหลังเกิดการสูญเสียข้อมูล (โดยสมมติว่า backup ของเราได้รับการทดสอบแล้วนะ!) การพัฒนาความสามารถในการฟื้นตัวยังอาจรวมถึงการมี playbook ที่เราสามารถใช้เป็นแนวทางในช่วงที่ระบบล่ม: คนในทีมเข้าใจบทบาทของตัวเองเมื่อเกิด outage หรือไม่? ใครจะเป็นคนหลักในการจัดการสถานการณ์? เราต้องแจ้งผู้ใช้เร็วแค่ไหนว่าเกิดอะไรขึ้น? เราจะสื่อสารกับผู้ใช้อย่างไร? การพยายามคิดอย่างมีสติในการรับมือ outage ขณะที่ outage กำลังเกิดขึ้นนั้นเป็นเรื่องยาก เพราะความเครียดและความวุ่นวายที่มาพร้อมกับสถานการณ์ การมีแผนปฏิบัติการที่ตกลงกันไว้ล่วงหน้าเพื่อรับมือกับปัญหาแบบนี้ จะช่วยให้คุณฟื้นตัวได้ดีขึ้น

Graceful Extensibility (ความสามารถในการขยายตัวอย่างนุ่มนวล)

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

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

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

Sustained Adaptability (การปรับตัวอย่างต่อเนื่อง)

การมี sustained adaptability ต้องอาศัยความไม่ประมาท ตามที่ David Woods กล่าวไว้ว่า: "ไม่ว่าเราจะทำได้ดีแค่ไหนในอดีต ไม่ว่าเราจะประสบความสำเร็จมากแค่ไหน อนาคตก็อาจแตกต่างออกไป และเราอาจไม่ได้ปรับตัวให้เข้ากับมันดีพอ เราอาจเปราะบางและง่อนแง่นเมื่อเผชิญกับอนาคตใหม่นั้น" 2 การที่เรายังไม่เคยเจอ outage ครั้งใหญ่ ไม่ได้แปลว่ามันจะไม่มีทางเกิดขึ้น เราต้องท้าทายตัวเองให้แน่ใจว่าเรากำลังปรับตัวสิ่งที่เราทำในฐานะองค์กรอย่างต่อเนื่อง เพื่อรับประกันความยืดหยุ่นทนทานในอนาคต หากทำได้ถูกต้อง แนวคิดอย่าง chaos engineering—ซึ่งเราจะพูดถึงสั้นๆ ในบทนี้—จะเป็นเครื่องมือที่มีประโยชน์ในการช่วยสร้าง sustained adaptability

Sustained adaptability มักต้องอาศัยมุมมองแบบองค์รวมต่อระบบมากขึ้น นี่เป็นเรื่องย้อนแย้งตรงที่การผลักดันให้มีทีมขนาดเล็ก ที่ทำงานอิสระ (autonomous) พร้อมความรับผิดชอบเฉพาะจุดที่มากขึ้น อาจทำให้เรามองข้ามภาพรวมไปได้ ตามที่เราจะสำรวจใน Chapter 15 มีความสมดุลระหว่างการปรับให้เหมาะสมในระดับ global และระดับ local เมื่อพูดถึงพลวัตขององค์กร และสมดุลนั้นก็ไม่หยุดนิ่ง ในบทนั้นเราจะดูบทบาทของทีมที่มุ่งเน้นเฉพาะทาง (stream-aligned) ที่เป็นเจ้าของ microservice ที่ต้องส่งมอบให้แก่ผู้ใช้ และมีความรับผิดชอบในระดับที่สูงขึ้นเพื่อให้สิ่งนี้เกิดขึ้นได้ เราจะดูบทบาทของ enabling team ที่ช่วยสนับสนุนทีม stream-aligned เหล่านี้ในการทำงานด้วย และดูว่า enabling team สามารถเป็นส่วนสำคัญในการช่วยสร้าง sustained adaptability ในระดับองค์กรได้อย่างไร

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

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

And Microservice Architecture (และสถาปัตยกรรม Microservice)

ตามที่เราได้พูดถึง เราจะเห็นว่าสถาปัตยกรรม microservice ช่วยให้เราบรรลุคุณสมบัติด้าน robustness ได้ แต่นั่นยังไม่เพียงพอถ้าคุณต้องการ resiliency จริงๆ

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