Risk Storming (Risk Storming)

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

Risk storming คือกิจกรรมความร่วมมือเพื่อระบุความเสี่ยงด้าน architecture ภายในมิติเฉพาะเจาะจง (ไม่ว่าจะเป็นบริบท หรือเกณฑ์) แม้ความพยายาม risk storming ส่วนใหญ่จะเกี่ยวข้องกับสถาปนิกหลายคน แต่เราแนะนำอย่างยิ่งให้รวม senior developer และ tech lead เข้ามาด้วย ไม่เพียงแต่พวกเขาจะให้มุมมองด้าน implementation ต่อความเสี่ยง ด้าน architecture เท่านั้น การให้พวกเขามีส่วนร่วมยังช่วยให้พวกเขาเข้าใจ architecture ได้ดีขึ้นด้วย

Risk storming ประกอบด้วยสามระยะ ได้แก่ identification, consensus และ mitigation ในระยะแรก (phase 1) ผู้เข้าร่วมทุกคนทำงานคนเดียว ใช้ risk matrix เพื่อกำหนดความเสี่ยงให้กับพื้นที่ต่าง ๆ ของ architecture ระยะที่ทำคนเดียวนี้ของ risk storming สำคัญมาก เพื่อไม่ให้ผู้เข้าร่วมมีอิทธิพลต่อกัน หรือดึงความสนใจของ คนอื่นออกจากพื้นที่ใดพื้นที่หนึ่งของ architecture ในสองระยะที่เป็นความร่วมมือ ผู้เข้าร่วมทุกคนทำงาน ร่วมกันเพื่อหาข้อสรุปร่วมกันว่าพื้นที่เสี่ยงคืออะไรและพูดคุยกัน (phase 2) และหา solution เพื่อลด ความเสี่ยง (phase 3)

ทั้งสามระยะใช้ diagram architecture แบบครอบคลุมหรือแบบเจาะจงบริบท (ดู Chapter 23 ) สถาปนิกที่ดำเนินกิจกรรม risk storming—เราจะเรียกคนคนนี้ว่า facilitator —มีหน้าที่ส่ง diagram ที่อัพเดตแล้วให้ผู้เข้าร่วมทุกคนสำหรับ session risk storming

Figure 22-5 แสดงตัวอย่าง architecture ที่เราจะใช้อธิบายกระบวนการ risk storming ใน architecture นี้ Elastic Load Balancer จะส่งต่อ request ไปยัง EC2 instance แต่ละตัวที่มี web server (Nginx) และ application service อยู่ application service เรียกไปยังฐานข้อมูล MySQL, Redis cache และฐานข้อมูล MongoDB (สำหรับ logging) พวกมันยังเรียกไปยัง Push Expansion Servers ซึ่งก็เชื่อมต่อกับฐานข้อมูล MySQL, Redis cache และ MongoDB logging facility ด้วยเช่นกัน (ไม่ต้องกังวลถ้าคุณไม่เข้าใจผลิตภัณฑ์และศัพท์เทคนิคเหล่านี้ทั้งหมด— architecture ที่คลุมเครือและ generalize มากเกินไปนี้มีไว้เพื่ออธิบายวิธีการทำงานของ risk storming เท่านั้น)

Figure 22-5. Example architecture diagram for risk storming session

เราจะเริ่มด้วย phase 1

Phase 1: Identification (Phase 1: การระบุ)

ระยะ identification ของ risk storming เกี่ยวข้องกับการที่ผู้เข้าร่วมแต่ละคนระบุพื้นที่เสี่ยงภายใน architecture ด้วยตัวเอง สิ่งสำคัญมากในระยะนี้คือผู้เข้าร่วมแต่ละคนควรบันทึกมุมมองความเสี่ยงที่ไม่ลำเอียงของตัวเอง โดยไม่ถูกชี้นำหรือโน้มน้าวโดยผู้เข้าร่วมคนอื่น ระยะ identification มีสามขั้นตอน

1. facilitator ส่งคำเชิญให้ผู้เข้าร่วมทุกคนเข้าร่วมระยะความร่วมมือ คำเชิญมี diagram architecture (หรือบอกว่าจะหามันได้จากที่ไหน), เกณฑ์และบริบทความเสี่ยงที่จะวิเคราะห์ และวันที่, เวลา และ สถานที่ (ทางกายภาพหรือแบบเสมือน) ของ session ความร่วมมือ พร้อมรายละเอียด logistical อื่น ๆ

2. ผู้เข้าร่วมใช้ risk matrix เพื่อวิเคราะห์ความเสี่ยงด้าน architecture ด้วยตัวเอง

3. ผู้เข้าร่วมจัดหมวดหมู่แต่ละความเสี่ยงเป็นต่ำ (1–2), ปานกลาง (3–4) หรือสูง (6–9) แล้วเขียนตัวเลข ลงบน sticky note สีเขียว, เหลือง หรือแดงเล็ก ๆ

ความพยายาม risk storming ส่วนใหญ่จะวิเคราะห์แค่เกณฑ์หรือบริบทเดียวเท่านั้น (เช่น “ความเสี่ยงด้าน ความปลอดภัยของเราอยู่ที่ไหน?” หรือ “พื้นที่ไหนมีความเสี่ยงภายในการลงทะเบียนลูกค้า?”) อย่างไรก็ตาม ถ้ามีปัญหาเรื่องความพร้อมของบุคลากรหรือเวลา ทีมประเมินความเสี่ยงอาจต้องวิเคราะห์หลายมิติภายใน บริบทเฉพาะเจาะจง (เช่น performance และ scalability) ในกรณีนี้ ผู้เข้าร่วมมักจะเขียนเกณฑ์เฉพาะเจาะจง ไว้ข้าง ๆ ตัวเลขความเสี่ยงบน sticky note ตัวอย่างเช่น สมมติว่าผู้เข้าร่วมสามคนระบุความเสี่ยงกับ ฐานข้อมูลกลาง ทั้งสามคนระบุความเสี่ยงเป็นสูง (6) แต่คนหนึ่งมองว่าเป็นความเสี่ยงต่อ availability ในขณะที่อีกสองคนมองว่าเป็นความเสี่ยงต่อ performance ผู้เข้าร่วมควรพูดคุยสองเกณฑ์นี้แยกกัน

Tip (เคล็ดลับ)

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

Phase 2: Consensus (Phase 2: ข้อสรุปร่วมกัน)

ระยะ consensus ของ risk storming เป็นความร่วมมืออย่างมาก โดยมีเป้าหมายเพื่อให้ผู้เข้าร่วมทุกคนหาข้อสรุปร่วมกัน เกี่ยวกับความเสี่ยงภายใน architecture กิจกรรมนี้จะมีประสิทธิภาพที่สุดเมื่อ facilitator ติดตั้ง diagram architecture ขนาดใหญ่ที่พิมพ์ไว้บนกำแพง (หรือเวอร์ชันอิเล็กทรอนิกส์บนจอขนาดใหญ่) เมื่อ ผู้เข้าร่วมมาถึง session risk storming facilitator จะบอกให้พวกเขาเริ่มติด sticky note ระดับ ความเสี่ยงของตัวเองลงบนพื้นที่ที่เกี่ยวข้องของ diagram architecture (ดู Figure 22-6 )

เมื่อ sticky note ทั้งหมดถูกติดแล้ว ระยะความร่วมมือก็เริ่มได้ เป้าหมายตรงนี้คือวิเคราะห์พื้นที่ เสี่ยงในฐานะทีม และหาข้อสรุปร่วมกันเกี่ยวกับระดับความเสี่ยงของมัน ในตัวอย่างที่แสดงใน Figure 22-6 ทีมได้ระบุพื้นที่เสี่ยงหลายแห่ง (เกณฑ์จริง ๆ ไม่สำคัญสำหรับตัวอย่างนี้) เราจะเห็นได้ว่า

• ผู้เข้าร่วมสองคนระบุ Elastic Load Balancer ว่ามีความเสี่ยงปานกลาง (3) ในขณะที่ผู้เข้าร่วมอีก คนหนึ่งระบุว่ามีความเสี่ยงสูง (6)

• ผู้เข้าร่วมคนหนึ่งระบุ Push Expansion Servers ว่ามีความเสี่ยงสูง (9)

• ผู้เข้าร่วมสามคนระบุฐานข้อมูล MySQL ว่ามีความเสี่ยงปานกลาง (3)

• ผู้เข้าร่วมคนหนึ่งระบุ Redis cache ว่ามีความเสี่ยงสูง (9)

• ผู้เข้าร่วมสามคนระบุ MongoDB logging ว่ามีความเสี่ยงต่ำ (2)

• ไม่มีใครระบุพื้นที่อื่นใดของ architecture ว่ามีความเสี่ยงเลย จึงไม่มี sticky note ติดที่ พื้นที่อื่น

Figure 22-6. Initial identification of risk areas

ฐานข้อมูล MySQL และ MongoDB logging ไม่จำเป็นต้องพูดคุยเพิ่มเติมใน session นี้ เพราะผู้เข้าร่วม ทุกคนเห็นตรงกันเรื่องระดับความเสี่ยง อย่างไรก็ตาม มีความเห็นต่างกันเกี่ยวกับ Elastic Load Balancer และ Push Expansion Servers กับ Redis cache ถูกระบุว่าเป็นความเสี่ยงโดยผู้เข้าร่วมแค่คนละคนเท่านั้น การจัดการความไม่ลงรอยกันเหล่านี้คือสิ่งที่ระยะความร่วมมือทำ

ผู้เข้าร่วมสองคน (Austen และ Logan) ระบุ Elastic Load Balancer ว่ามีความเสี่ยงปานกลาง (3) ส่วน อีกคน (Addison) ระบุว่ามีความเสี่ยงสูง (6) Austen และ Logan ถาม Addison ว่าทำไมถึงระบุความเสี่ยง เป็นสูง Addison ตอบว่าถ้า Elastic Load Balancer ล่ม ระบบทั้งหมดจะเข้าถึงไม่ได้เลย แม้เรื่องนี้ จะเป็นจริง—และทำให้ระดับ impact สูงขึ้น—แต่ผู้เข้าร่วมอีกสองคนก็โน้มน้าว Addison ว่าความเสี่ยงที่เรื่องนี้จะเกิดขึ้นจริงนั้นต่ำ เพราะมี clustering Addison เห็นด้วย และกลุ่มก็ปรับระดับความเสี่ยงด้าน likelihood ลงมาเป็นปานกลาง (3)

อย่างไรก็ตาม เรื่องนี้อาจกลับกันก็ได้ ถ้า Austen และ Logan พลาดแง่มุมบางอย่างของความเสี่ยงใน Elastic Load Balancer ที่ Addison เห็น Addison อาจโน้มน้าวผู้เข้าร่วมอีกสองคนให้จัดหมวดหมู่ระดับ ความเสี่ยงนี้เป็นสูงแทนที่จะเป็นปานกลางก็ได้ นี่คือเหตุผลว่าทำไมระยะความร่วมมือของ risk storming ถึงสำคัญมาก

ผู้เข้าร่วมคนหนึ่งระบุ Push Expansion Servers ว่ามีความเสี่ยงสูง (9) แต่ไม่มีผู้เข้าร่วมคนอื่น ระบุความเสี่ยงในพื้นที่นี้ของ architecture เลย คนที่ระบุความเสี่ยงอธิบายว่าเขาให้คะแนนความเสี่ยง เป็นสูง เพราะเคยมีประสบการณ์ไม่ดีกับ Push Expansion Servers ที่ crash บ่อย ๆ ภายใต้ load สูง คล้ายกับ load ของ architecture นี้ ตัวอย่างนี้แสดงคุณค่าของ risk storming—หากไม่มีผู้เข้าร่วมคนนั้น มาร่วม ก็คงไม่มีใครเห็นความเสี่ยงสูงนี้จนกว่าจะเข้าสู่ production ไปแล้ว

Redis cache เป็นกรณีที่น่าสนใจ ผู้เข้าร่วมคนหนึ่ง เป็นนักพัฒนาชื่อ Devon ระบุว่ามีความเสี่ยงสูง (9) แต่ไม่มีใครคนอื่นเห็นว่า cache นั้นมีความเสี่ยงเลย เมื่อผู้เข้าร่วมคนอื่นถาม Devon ถึงเหตุผลที่ให้ คะแนนความเสี่ยงนี้เป็นสูง Devon ตอบว่า “Redis cache คืออะไร?” เมื่อไหร่ก็ตามที่ผู้เข้าร่วม risk storming ระบุว่าเทคโนโลยีหนึ่งเป็นสิ่งที่ตัวเองไม่รู้จัก พื้นที่นั้นจะถูกกำหนดระดับความเสี่ยงสูง (9) โดยอัตโนมัติ

Tip (เคล็ดลับ)

ให้กำหนดระดับความเสี่ยงสูงสุด (9) กับเทคโนโลยีที่ยังไม่ผ่านการพิสูจน์หรือไม่รู้จักเสมอ เพราะ risk matrix ไม่สามารถใช้กับเกณฑ์หรือบริบทนี้ได้

ตัวอย่างของ Redis cache แสดงให้เห็นว่าทำไมการดึงนักพัฒนาเข้าร่วม session risk storming ถึงสำคัญ ความจริงที่ว่าผู้เข้าร่วมคนนี้ไม่รู้จักเทคโนโลยีที่กำหนดไว้เป็นข้อมูลที่มีค่าสำหรับสถาปนิกเกี่ยวกับ ความเสี่ยงโดยรวม สถาปนิกอาจตัดสินใจเปลี่ยนเทคโนโลยี หรือลงทุนค่าใช้จ่ายในการฝึกอบรมเพื่อให้ทีม พัฒนาตามทัน

ระยะนี้จะดำเนินต่อไปจนกว่าผู้เข้าร่วมทุกคนจะเห็นตรงกันเกี่ยวกับพื้นที่เสี่ยงที่ระบุไว้ เมื่อ sticky note ทั้งหมดถูกรวมกันแล้ว ระยะนี้ก็จะจบลง ผลลัพธ์สุดท้ายแสดงอยู่ใน Figure 22-7

Figure 22-7. Consensus of risk areas

Phase 3: Risk Mitigation (Phase 3: การลดความเสี่ยง)

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

ระยะนี้ ซึ่งก็เป็นความร่วมมือเช่นกัน มุ่งหาวิธีลดหรือกำจัดความเสี่ยงที่ระบุไว้ในระยะที่สอง ขึ้นอยู่กับความเสี่ยงที่ระบุไว้ architecture เดิมอาจต้องเปลี่ยนแปลงทั้งหมด หรือการเปลี่ยนแปลงอาจ จำกัดอยู่แค่การ refactor architecture แบบตรงไปตรงมาในพื้นที่เฉพาะเจาะจง เช่นการเพิ่ม queue สำหรับ backpressure เพื่อลด throughput bottleneck

ไม่ว่าการเปลี่ยนแปลงที่จำเป็นจะเป็นอะไร ระยะ risk mitigation มักจะมีค่าใช้จ่ายเพิ่มเติม ด้วยเหตุนี้ จึงสำคัญที่ระยะนี้ต้องมี business stakeholder หลักที่มีอำนาจตัดสินใจว่าต้นทุนของ solution ที่ใช้ ลดความเสี่ยงนั้นคุ้มค่ากับความเสี่ยงหรือไม่

ตัวอย่างเช่น สมมติว่าใน session risk-storming ตัวอย่างของเรา ทีมระบุว่าฐานข้อมูลกลางมีความเสี่ยง ปานกลาง (4) เกี่ยวกับ availability โดยรวมของระบบ ผู้เข้าร่วมเห็นตรงกันว่าการทำ clustering ฐานข้อมูล และแยกออกเป็นฐานข้อมูล physical แยกกันจะช่วยลดความเสี่ยงนั้นได้ อย่างไรก็ตาม solution นั้นจะมีค่าใช้ จ่าย $50,000 สถาปนิกผู้ทำหน้าที่ facilitator พบกับ business stakeholder หลัก รวมถึงเจ้าของธุรกิจ เพื่อพูดคุย trade-off ระหว่างความเสี่ยงด้าน availability กับต้นทุน เจ้าของธุรกิจตัดสินว่าราคานั้น สูงเกินไป และต้นทุนไม่คุ้มค่ากับความเสี่ยงด้าน availability สถาปนิกจึงเสนอแนวทางอื่น แทนที่จะทำ clustering ที่มีราคาแพง จะแยกฐานข้อมูลออกเป็นสองฐานข้อมูลตาม domain แทนดีไหม? solution นี้จะมี ค่าใช้จ่ายแค่ $16,000 ในขณะที่ยังคงลดความเสี่ยงด้าน availability ลงได้ stakeholder เห็นด้วยกับ การประนีประนอมนี้

สถานการณ์นี้แสดงให้เห็นว่า risk storming กำหนดรูปแบบไม่เพียงแค่ architecture โดยรวมเท่านั้น แต่ยัง รวมถึงการเจรจาระหว่างสถาปนิกและ business stakeholder ด้วย เมื่อรวมกับ risk assessment ที่เรา อธิบายไว้ตอนต้นบทนี้ risk storming เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการระบุและติดตามความเสี่ยง ปรับปรุง architecture และจัดโครงสร้างการเจรจาระหว่าง stakeholder หลัก