How Much Is Too Much? (มากแค่ไหนถึงเรียกว่ามากเกินไป)

เรา ได้พูดถึงหัวข้อ cross-functional requirements ใน Chapter 9 แล้ว การเข้าใจ cross-functional requirements คือการพิจารณาแง่มุมต่างๆ เช่น durability ของข้อมูล availability ของบริการ throughput และ latency ของการดำเนินการที่ยอมรับได้ เทคนิคหลายอย่างในบทนี้พูดถึงแนวทางในการทำให้ requirement เหล่านี้เป็นจริง แต่มีเพียงคุณเท่านั้นที่รู้ว่า requirement ของคุณเองคืออะไรกันแน่ ดังนั้นให้จำ requirement ของคุณเองไว้ในใจขณะอ่านต่อไป

การมีระบบ autoscaling ที่สามารถตอบสนองต่อโหลดที่เพิ่มขึ้นหรือความล้มเหลวของ node แต่ละตัวอาจฟังดูยอดเยี่ยม แต่มันอาจมากเกินไปสำหรับระบบรายงานที่รันแค่เดือนละสองครั้ง ที่ซึ่งการหยุดทำงานหนึ่งหรือสองวันไม่ใช่เรื่องใหญ่ ในทำนองเดียวกัน การหาวิธีทำ zero-downtime deployment เพื่อขจัดการหยุดชะงักของบริการอาจสมเหตุสมผลสำหรับระบบ ecommerce ออนไลน์ของคุณ แต่สำหรับ knowledge base ภายในองค์กรของคุณ มันอาจไปไกลเกินความจำเป็น

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

ตามที่ผมกล่าวไว้ก่อนหน้านี้ cross-functional requirements เหล่านี้สามารถแตกต่างกันไปในแต่ละบริการ แต่ผมขอแนะนำให้กำหนด cross-functional ทั่วไปบางอย่างก่อน แล้วค่อย override สำหรับกรณีใช้งานเฉพาะ เมื่อพิจารณาว่าจะ scale out ระบบของคุณเพื่อรับมือกับโหลดหรือความล้มเหลวได้ดีขึ้นหรือไม่และอย่างไร ให้เริ่มจากการทำความเข้าใจ requirement ต่อไปนี้:

Response time/latency

การดำเนินการต่างๆ ควรใช้เวลานานแค่ไหน? การวัดสิ่งนี้กับจำนวนผู้ใช้ที่แตกต่างกันจะเป็นประโยชน์ เพื่อเข้าใจว่าโหลดที่เพิ่มขึ้นส่งผลต่อ response time อย่างไร ด้วยธรรมชาติของเครือข่าย คุณจะมี outlier เสมอ ดังนั้นการตั้งเป้าหมายสำหรับ percentile หนึ่งๆ ของ response ที่ถูกวัดจะเป็นประโยชน์ เป้าหมายควรรวมถึงจำนวนการเชื่อมต่อ/ผู้ใช้พร้อมกัน ที่คุณคาดว่าซอฟต์แวร์ของคุณจะรับมือได้ด้วย ดังนั้นคุณอาจพูดว่า "เราคาดหวังว่าเว็บไซต์จะมี 90th-percentile response time ที่ 2 วินาที เมื่อรับมือกับการเชื่อมต่อพร้อมกัน 200 ครั้งต่อวินาที"

Availability

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

Durability of data

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

การนำ แนวคิดเหล่านี้มาระบุเป็น service-level objectives (SLO) ซึ่งเราพูดถึงไปใน Chapter 10 เป็นวิธีที่ดีในการฝัง requirement เหล่านี้เข้าไปเป็นส่วนสำคัญของกระบวนการส่งมอบซอฟต์แวร์ของคุณ