The review process

การทบทวนสถาปัตยกรรมต้องทำอย่างสม่ำเสมอ ด้วยแนวทางแบบไม่มุ่งเน้นการจับผิด (Blame-free) ซึ่งสนับสนุนให้มีการเจาะลึกในรายละเอียด กระบวนการนี้ควรเป็นกระบวนการที่เบาตัว (ใช้เวลาเป็นชั่วโมง ไม่ใช่เป็นวัน) โดยเน้นการสนทนามากกว่าการตรวจสอบ (Audit) วัตถุประสงค์ของการทบทวนสถาปัตยกรรมคือเพื่อระบุประเด็นสำคัญที่อาจต้องได้รับการจัดการ หรือส่วนที่สามารถปรับปรุงได้ ผลลัพธ์จากการทบทวนคือชุดการดำเนินการที่ควรจะช่วยปรับปรุงประสบการณ์ของลูกค้าที่ใช้งานเวิร์กโหลดนั้น ๆ

ตามที่ได้หารือในส่วน "ว่าด้วยเรื่องสถาปัตยกรรม" (On Architecture) คุณย่อมต้องการให้สมาชิกแต่ละคนในทีมรับผิดชอบต่อคุณภาพของสถาปัตยกรรมของตนเอง เราแนะนำให้สมาชิกในทีมที่สร้างสถาปัตยกรรมใช้ Well-Architected Framework ในการทบทวนสถาปัตยกรรมของตนเองอย่างต่อเนื่อง แทนที่จะจัดประชุมทบทวนอย่างเป็นทางการเพียงอย่างเดียว แนวทางที่ทำอย่างสม่ำเสมอนี้จะช่วยให้ทีมงานสามารถอัปเดตคำตอบได้ตามการวิวัฒนาการของสถาปัตยกรรม และปรับปรุงสถาปัตยกรรมไปพร้อมกับการส่งมอบฟีเจอร์ใหม่ ๆ

AWS Well-Architected Framework มีแนวทางที่สอดคล้องกับวิธีที่ AWS ใช้ทบทวนระบบและบริการภายใน โดยตั้งอยู่บนพื้นฐานของหลักการออกแบบที่มีอิทธิพลต่อแนวทางการสร้างสถาปัตยกรรม และชุดคำถามที่ช่วยตรวจสอบเพื่อให้แน่ใจว่าผู้คนจะไม่ละเลยส่วนที่มักปรากฏในการวิเคราะห์หาสาเหตุที่แท้จริง (Root Cause Analysis - RCA) เมื่อใดก็ตามที่มีปัญหาสำคัญเกิดขึ้นกับระบบภายใน บริการของ AWS หรือลูกค้า เราจะย้อนกลับไปดู RCA เพื่อดูว่าเราสามารถปรับปรุงกระบวนการทบทวนที่เราใช้งานอยู่ได้หรือไม่

ควรมีการทบทวนในระยะสำคัญ (Milestones) ของวงจรชีวิตผลิตภัณฑ์ ตั้งแต่ระยะเริ่มต้นของการออกแบบเพื่อหลีกเลี่ยง "ประตูทางเดียว" (One-way doors) ซึ่งยากต่อการเปลี่ยนแปลงในภายหลัง และทบทวนอีกครั้งก่อนวันเปิดใช้งานจริง (Go-live) (ทั้งนี้ การตัดสินใจหลายอย่างสามารถย้อนกลับได้ หรือที่เรียกว่า "ประตูสองทาง" (Two-way doors) ซึ่งสามารถใช้กระบวนการที่เบาตัวได้ แต่ประตูทางเดียวคือการตัดสินใจที่ย้อนกลับได้ยากหรือเป็นไปไม่ได้ และต้องมีการตรวจสอบอย่างละเอียดก่อนตัดสินใจ) หลังจากเข้าสู่ขั้นตอนการใช้งานจริง (Production) เวิร์กโหลดของคุณจะวิวัฒนาการต่อไปเมื่อมีการเพิ่มฟีเจอร์ใหม่และเปลี่ยนเทคโนโลยีที่ใช้ คุณต้องปฏิบัติตามแนวทาง "สุขอนามัยที่ดี" (Hygiene practices) เพื่อป้องกันไม่ให้ลักษณะทางสถาปัตยกรรมเสื่อมถอยลงเมื่อระบบเติบโตขึ้น เมื่อมีการเปลี่ยนแปลงสถาปัตยกรรมที่สำคัญ คุณควรทำตามขั้นตอนสุขอนามัยซึ่งรวมถึงการทบทวนตามหลัก Well-Architected ด้วย

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

นี่คือรายการสิ่งที่แนะนำเพื่อช่วยอำนวยความสะดวกในการประชุม:

• ห้องประชุมที่มีไวท์บอร์ด
• แผนผังหรือบันทึกการออกแบบที่พิมพ์ออกมา
• รายการคำถามที่ต้องใช้การค้นคว้าเพิ่มเติม (เช่น "เราได้เปิดใช้งานการเข้ารหัสข้อมูลหรือไม่?")

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

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

• “เรายุ่งเกินไป!” (มักพูดเมื่อทีมกำลังเตรียมตัวสำหรับการเปิดตัวครั้งสำคัญ)

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

• “เราไม่มีเวลาทำอะไรกับผลลัพธ์ที่ได้!” (มักพูดเมื่อมีเหตุการณ์ที่ขยับวันไม่ได้ เช่น การแข่งขัน Super Bowl)

• เหตุการณ์เหล่านี้เลื่อนไม่ได้ คุณต้องการเข้าสู่เหตุการณ์นั้นโดยไม่รู้ความเสี่ยงในสถาปัตยกรรมจริง ๆ หรือ? แม้คุณจะไม่ได้จัดการปัญหาทั้งหมด แต่คุณก็ยังสามารถมีคู่มือการปฏิบัติงาน (Playbooks) สำหรับรับมือหากปัญหาเหล่านั้นเกิดขึ้นจริง

• “เราไม่ต้องการให้คนอื่นรู้ความลับในการแก้ปัญหาของเรา!”

• หากคุณให้ทีมดูชุดคำถามใน Well-Architected Framework พวกเขาจะเห็นว่าไม่มีคำถามใดที่เปิดเผยข้อมูลความลับทางการค้าหรือข้อมูลทางเทคนิคที่เป็นกรรมสิทธิ์เลย

เมื่อคุณทำการทบทวนร่วมกับทีมต่าง ๆ ในองค์กรหลาย ๆ ครั้ง คุณอาจระบุปัญหาที่เป็นประเด็นร่วมได้ (Thematic issues) ตัวอย่างเช่น คุณอาจเห็นว่ากลุ่มของทีมมีปัญหาในเสาหลักหรือหัวข้อใดหัวข้อหนึ่งเป็นพิเศษ คุณควรพิจารณาการทบทวนทั้งหมดในภาพรวม และระบุกลไก การฝึกอบรม หรือการบรรยายทางวิศวกรรมที่จะสามารถช่วยแก้ปัญหาเชิงประเด็นเหล่านั้นได้