Risk-Storming Use Case (กรณีศึกษาการใช้ Risk Storming)

เพื่ออธิบายพลังของ risk storming และวิธีที่มันช่วยปรับปรุง architecture โดยรวม ลองพิจารณาตัวอย่างของ ระบบสนับสนุนสำหรับ call center ที่พยาบาลให้คำแนะนำผู้ป่วยเกี่ยวกับภาวะสุขภาพต่าง ๆ ข้อกำหนดของระบบ มีดังนี้

• diagnostics engine จากบุคคลที่สามจะให้คำถามและนำทางพยาบาลและผู้ป่วยผ่านปัญหาทางการแพทย์ของพวกเขา engine นี้รองรับได้ประมาณ 500 request ต่อวินาที

• ผู้ป่วยสามารถโทรเข้ามาที่ call center เพื่อพูดคุยกับพยาบาล หรือใช้เว็บไซต์ self-service ที่เข้าถึง diagnostic engine เดียวกันโดยตรง

• ระบบต้องรองรับพยาบาลพร้อมกัน 250 คนทั่วประเทศ และผู้ป่วย self-service พร้อมกันได้มากถึงหลายแสนคน ทั่วประเทศ

• พยาบาลสามารถเข้าถึงบันทึกทางการแพทย์ของผู้ป่วยผ่าน medical records exchange ได้ แต่ผู้ป่วยไม่สามารถ เข้าถึงบันทึกทางการแพทย์ของตัวเองได้

• ระบบต้องเป็นไปตามมาตรฐาน HIPAA (Health Insurance Portability and Accountability Act) หมายความว่าจำเป็นอย่างยิ่งที่จะต้องไม่มีใคร นอกจากพยาบาลที่จะเข้าถึงบันทึกทางการแพทย์ของผู้ป่วยได้ ตัวเลือก self-service ไม่สามารถรับประกันการ ปฏิบัติตาม HIPAA ได้

• ระบบต้องสามารถรองรับปริมาณสูงในช่วงการระบาดของหวัด, ไข้หวัดใหญ่ และ COVID ได้

• สายเรียกเข้าจะถูก route ไปยังพยาบาลตาม skill profile ของแต่ละคน (เช่น ภาษาที่พูดได้หรือความเชี่ยวชาญ ทางการแพทย์)

หลังจากวิเคราะห์ข้อกำหนดเหล่านี้ Logan ผู้เป็นสถาปนิกที่รับผิดชอบระบบนี้ ได้สร้าง architecture ระดับสูง ที่แสดงเป็น diagram ใน Figure 22-8 architecture นี้มี web-based UI แยกกันสามตัว ตัวหนึ่งสำหรับ self-service ตัวหนึ่งสำหรับพยาบาลที่รับสาย และตัวหนึ่งสำหรับเจ้าหน้าที่บริหารในการเพิ่มและดูแล profile ของพยาบาลและการตั้งค่าต่าง ๆ ส่วนของระบบ call-center ประกอบด้วย Call Accepter service ที่รับสาย และ Call Router service ที่ route ผู้โทรไปยังพยาบาลที่ว่างคนถัดไปตาม skill profile ของพยาบาล Call Router service เข้าถึงฐานข้อมูลกลางเพื่อดึงข้อมูล profile ของพยาบาล หัวใจสำคัญของ architecture นี้คือ diagnostics-system API Gateway ซึ่งทำการตรวจสอบความปลอดภัยและนำ request ไปยัง backend service ที่เหมาะสม

Figure 22-8. High-level architecture for a nursing-hotline diagnostics system

service หลักสี่ตัวในระบบนี้คือ Case Management service, Nurse Profile Management service, Medical Records Interface service ไปยัง medical records exchange และ Diagnostics Engine Interface service ของบุคคลที่สามภายนอก การสื่อสารทั้งหมดใช้ REST ยกเว้น protocol เฉพาะที่ใช้กับระบบภายนอกและ service ของ call-center พื้นที่ที่ architecture ต้องรองรับ สรุปแล้วคือ availability, elasticity และ security

หลังจากรีวิวหลายรอบ Logan เชื่อว่า architecture พร้อมสำหรับการ implement แล้ว อย่างไรก็ตาม เพราะเป็น สถาปนิกที่มีความรับผิดชอบและมีประสิทธิภาพ Logan จึงตัดสินใจจัด risk-storming exercise ขึ้น

Availability (Availability)

ในฐานะ facilitator Logan ตัดสินใจให้ risk-storming exercise แรกโฟกัสไปที่ availability ซึ่งสำคัญมากต่อความสำเร็จของระบบ หลังจากระยะ identification และ collaboration ผู้เข้าร่วมได้พื้นที่ เสี่ยงดังต่อไปนี้ (แสดงใน Figure 22-9 )

• availability ของฐานข้อมูลกลาง ความเสี่ยงสูง (6) เนื่องจาก impact สูง (3) และ likelihood ปานกลาง (2) ที่ฐานข้อมูลจะใช้งานไม่ได้เมื่อจำเป็น

• availability ของ Diagnostics Engine ความเสี่ยงสูง (9) เนื่องจาก impact สูง (3) และ likelihood ที่ใช้งานไม่ได้ที่ยังไม่รู้ (3)

• availability ของ Medical Records Interface ความเสี่ยงต่ำ (2) component นี้ไม่จำเป็นต้องใช้ในการระบุผลลัพธ์ทางการแพทย์ที่เฉพาะเจาะจง

• ทีมตัดสินว่าไม่มีส่วนอื่นใดของระบบที่เป็นความเสี่ยงด้าน availability เพราะ architecture มี หลาย instance ของแต่ละ service และทำ cluster ให้กับ API Gateway

Figure 22-9. Availability risk areas, as identified by the risk-storming team

ผู้เข้าร่วมทุกคนเห็นตรงกันว่าถ้าฐานข้อมูลล่ม พยาบาลสามารถจดบันทึก case ด้วยมือได้ แต่ call router จะทำงานไม่ได้เลย เพื่อลดความเสี่ยงนี้ พวกเขาตัดสินใจร่วมกันแยกฐานข้อมูล physical เดียวออกเป็นสอง ฐานข้อมูล ฐานข้อมูลหนึ่งเป็น clustered database ที่มีข้อมูล nurse-profile และอีกฐานข้อมูลเป็น single-instance database สำหรับ case notes การเปลี่ยนแปลง architecture นี้ไม่เพียงแก้ไขข้อกังวลด้าน availability ของฐานข้อมูล แต่ยังช่วยรักษาความปลอดภัยของ case notes ด้วย

การลดความเสี่ยงด้าน availability ในระบบภายนอก (ในกรณีนี้คือ Diagnostics Engine และ Medical Records Interface ) นั้นยากกว่ามาก เพราะพวกมันถูกควบคุมโดยบุคคลที่สาม ทีมจึงตัดสินใจค้นคว้าว่าระบบเหล่านี้มี service-level agreement (SLA) หรือ service-level objective (SLO) ที่เผยแพร่ไว้หรือไม่ SLA มักเป็นสัญญาที่มีผลผูกพันทางกฎหมาย ส่วน SLO มักไม่มีผลผูกพันทาง กฎหมาย พวกเขาพบ SLA สำหรับทั้งสองระบบ SLA ของ Diagnostics Engine รับประกัน availability 99.99% (นั่นคือ downtime 52.60 นาทีต่อปี) และ Medical Records Interface รับประกัน availability ที่ 99.90% (นั่นคือ downtime 8.77 ชั่วโมงต่อปี) จากการวิเคราะห์นี้ ข้อมูลนี้ เพียงพอสำหรับทีมประเมินความเสี่ยงที่จะลบความเสี่ยงที่ระบุไว้ออกไป

หลังจาก session risk-storming นี้ ทีมได้เปลี่ยนแปลง architecture ดังแสดงใน Figure 22-10 โดยสร้างฐานข้อมูลสองฐานและเพิ่ม SLA ลงใน diagram architecture

Figure 22-10. Availability risk areas can be mitigated by using separate databases

Elasticity (Elasticity)

risk-storming exercise ที่สองโฟกัสไปที่ elasticity—การพุ่งขึ้นของ user load (หรือที่รู้จักกันว่า variable scalability) แม้จะมีพยาบาลแค่ 250 คน (หมายความว่าจะมีพยาบาลไม่เกิน 250 คนที่เข้าถึง Diagnostics Engine ) แต่ส่วน self-service ของระบบก็เข้าถึง Diagnostics Engine ได้เช่นกัน ซึ่งเพิ่มจำนวน request ไปยัง interface ของ Diagnostics Engine อย่างมาก ผู้เข้าร่วม risk-storming กังวลเกี่ยวกับฤดูไข้หวัดใหญ่และการระบาดของ COVID ซึ่งจะเพิ่ม load ที่คาดว่าจะเกิดขึ้นกับระบบอย่างมาก

ผู้เข้าร่วมระบุ interface ของ Diagnostics Engine ว่ามีความเสี่ยงสูง (9) เป็นเอกฉันท์ เนื่องจากมันรองรับได้แค่ 500 request ต่อวินาที พวกเขาคำนวณได้ อย่างถูกต้องว่ามีความเสี่ยงสูงที่มันจะตามไม่ทัน throughput ที่คาดไว้ โดยเฉพาะเมื่อใช้ REST เป็น protocol ของ interface

ทีมตัดสินว่าวิธีหนึ่งในการลดความเสี่ยงนี้คือการใช้ asynchronous queue (messaging) สำหรับการสื่อสาร ระหว่าง API Gateway และ interface ของ Diagnostics Engine วิธีนี้จะให้จุด backpressure ถ้า call ไปยัง Diagnostics Engine เริ่มค้างอยู่ แม้นี่จะเป็น practice ที่ดี แต่ก็ยังไม่ได้ลดความเสี่ยงทั้งหมด พยาบาลและผู้ป่วย self-service ก็ยังต้องรอ response จาก Diagnostics Engine นานเกินไป และ request ของพวกเขาก็มีแนวโน้มที่จะ timeout

ผู้เข้าร่วมตัดสินใจใช้ pattern ที่เรียกว่า Ambulance pattern เพื่อแยก request เหล่านี้ออกจากกันด้วยการใช้ message channel สองช่องแทนที่จะใช้แค่ช่องเดียว วิธีนี้ จะให้ระบบให้ความสำคัญกับ request ของพยาบาลมากกว่า request ของ self-service วิธีนี้จะช่วยลด ความเสี่ยงได้ แต่ก็ยังไม่ได้แก้ปัญหาเรื่องเวลารอ หลังจากพูดคุยกันเพิ่มเติม กลุ่มก็ตัดสินใจลด call ที่เกี่ยวข้องกับการระบาดไปยัง Diagnostics Engine โดยการ cache คำถาม diagnostic เฉพาะเจาะจงเหล่านั้น เพื่อไม่ให้มันไปถึง interface ของ Diagnostics Engine เลย

นอกจากการสร้าง messaging channel สองช่อง (หนึ่งช่องสำหรับพยาบาลและอีกหนึ่งช่องสำหรับผู้ป่วย self-service) ทีมยังสร้าง service ใหม่ชื่อว่า Diagnostics Outbreak Cache Server ที่จัดการ request ทั้งหมดที่เกี่ยวข้องกับการระบาดหรือคำถามเกี่ยวกับไข้หวัดใหญ่โดยเฉพาะ ( Figure 22-11 ) architecture ใหม่นี้ลดจำนวน call ไปยัง diagnostics engine ทำให้รองรับ request ที่เกี่ยวข้องกับ อาการอื่น ๆ พร้อมกันได้มากขึ้น หากไม่มีความพยายาม risk storming ความเสี่ยงนี้อาจไม่ถูกระบุจนกว่า จะถึงฤดูไข้หวัดใหญ่

Figure 22-11. Architecture modifications to address elasticity risk

Security (Security)

ได้กำลังใจจากความสำเร็จเหล่านี้ สถาปนิกจึงตัดสินใจจัด session risk-storming สุดท้ายโดยโฟกัสไปที่ characteristic สำคัญอีกอย่างของระบบนี้—security เนื่องจากข้อกำหนดด้านกฎหมาย HIPAA Medical Records Interface ต้องให้แค่พยาบาลเท่านั้นที่เข้าถึงบันทึกทางการแพทย์ของผู้ป่วยได้ สถาปนิกเชื่อว่าการตรวจสอบ authentication และ authorization ใน API Gateway ทำให้ความเสี่ยงนี้เป็นกลางแล้ว แต่ก็อยากรู้ว่า ผู้เข้าร่วมจะพบความเสี่ยงด้านความปลอดภัยอื่น ๆ หรือไม่

ผู้เข้าร่วมทุกคนระบุ API Gateway ของระบบ diagnostics ว่ามีความเสี่ยงด้านความปลอดภัยสูง (6) พวกเขา อ้างถึง impact สูงถ้าเจ้าหน้าที่บริหารหรือผู้ป่วย self-service เข้าถึงบันทึกทางการแพทย์ได้ (3) แต่ ให้คะแนน likelihood เป็นปานกลาง (2) แม้การตรวจสอบความปลอดภัยสำหรับแต่ละ API call จะช่วยได้ แต่ call ทั้งหมด (self-service, admin และพยาบาล) ก็ยังคงผ่าน API Gateway เดียวกัน ในที่สุดพวกเขาก็โน้มน้าว facilitator ที่ตอนแรกให้คะแนนความเสี่ยงนี้ต่ำ (2) ว่าความเสี่ยงนี้จริง ๆ แล้วสูงและต้องลดความเสี่ยง

ทุกคนเห็นตรงกันว่าการมี API Gateway แยกกันสำหรับผู้ใช้แต่ละประเภท (เจ้าหน้าที่บริหาร, ผู้ใช้ self-service และพยาบาล) จะป้องกันไม่ให้ call ที่ไม่ใช่ของพยาบาลไปถึง Medical Records Interface ได้เลย architecture เวอร์ชันสุดท้ายของสถาปนิกแสดงอยู่ใน Figure 22-12

Figure 22-12. Architecture modifications to address security risk

ตัวอย่างนี้แสดงพลังของ risk storming สถาปนิก, นักพัฒนา และ stakeholder หลักทำงานร่วมกัน พิจารณา architectural characteristic ที่สำคัญที่สุดต่อความสำเร็จของระบบ และระบุพื้นที่เสี่ยงที่ไม่เช่นนั้น จะไม่มีใครสังเกตเห็น

architecture ดั้งเดิม ( Figure 22-8 ) เปลี่ยนแปลงไปอย่างมากหลังจาก risk storming ( Figure 22-12 ) ในวิธีที่แก้ไขข้อกังวลเกี่ยวกับ availability, elasticity และ security และทำให้ architecture นี้ มีประสิทธิภาพมากขึ้นและมีแนวโน้มที่จะประสบความสำเร็จมากขึ้น