สร้างเพื่อวันนี้ วางแผนเพื่อพรุ่งนี้ วางแผนรับความล้มเหลว

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 5 จาก 7 ในบท คิดแบบสถาปนิกข้อมูล ซึ่งเป็นบทแรกของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: สถาปัตยกรรมคือศิลปะแห่งการแลกเปลี่ยนได้เสีย · ถัดไป: รู้จักเครื่องมือของคุณ: คำถามเก้าข้อ

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

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

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

สร้างเพื่อวันนี้ วางแผนเพื่อพรุ่งนี้ วางแผนรับความล้มเหลว

คุณต้องใช้ทั้งสามอัน

Click to enlarge

สร้างเพื่อวันนี้

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

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

มองหาความต้องการที่แฝงอยู่

ความต้องการที่คุณได้รับมาไม่จำเป็นต้องเป็นความต้องการทั้งหมดที่คุณมี เกือบทุกครั้งจะมีความต้องการที่แฝงอยู่

ฝ่ายธุรกิจพูดว่า “เราต้องการข้อมูลลูกค้าใน Salesforce” โอเค แล้วก็ต้องมีใครสักคนเป็นเจ้าของข้อมูลนั้นและตัดสินใจว่ามันต้องสดใหม่แค่ไหน เราต้องรู้ว่าจะเกิดอะไรขึ้นเมื่อระบบต้นทางล่ม จะรู้ได้อย่างไรเมื่อการซิงก์ล้มเหลว และฝ่ายไหนชนะเมื่อ Salesforce กับต้นทางไม่ตรงกัน เราต้องมีระยะเวลาเก็บรักษา โมเดลการเข้าถึง การตัดสินใจเรื่องฟิลด์ที่อ่อนไหว และวิธีแก้ไขข้อมูลที่ไม่ดี

ไม่มีสิ่งใดในนั้นอยู่ใน user story แต่ทั้งหมดก็ยังเป็นสถาปัตยกรรม ส่วนสำคัญของการเป็นสถาปนิกคือการเรียนรู้ที่จะเห็นคำถามที่ยังไม่มีใครถาม

รู้จักตัวเลขของคุณ

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

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

ผมเรียกสิ่งนี้ว่าจำนวนเลขศูนย์ของ Steve (Steve’s Number of Zeros) เลขศูนย์เพิ่มมาเพียงตัวเดียวก็เปลี่ยนสถาปัตยกรรมของคุณได้ทั้งหมด หนึ่งหมื่น หนึ่งแสน หนึ่งล้าน สิบล้าน หนึ่งร้อยล้าน: ฟีเจอร์ไม่ได้เปลี่ยน ความต้องการอาจไม่ได้เปลี่ยน แต่สถาปัตยกรรมอาจเปลี่ยน

จำเรื่องนัดหมายในโมดูลที่ 1 ได้ไหม? ลองใส่ตัวเลขจริงลงไป สถานที่กว่า 1,200 แห่ง แห่งละ 100 นัดหมายต่อวัน สัปดาห์ละหกวัน ประมาณ 305 วันต่อปี นั่นคือนัดหมายกว่า 36 ล้านรายการในปีแรก การมาแต่ละครั้งสร้างสองเรกคอร์ด จึงเป็นกว่า 73 ล้านเรกคอร์ด ทีนี้เก็บประวัติไว้ห้าปี เติบโตปีละ 30 เปอร์เซ็นต์ ก็เกิน 650 ล้านเรกคอร์ด ฟีเจอร์เดิม ความต้องการเดิม เลขศูนย์เพิ่มอีกสองสามตัว และสถาปัตยกรรมที่ต่างไปมาก

วางแผนเพื่อพรุ่งนี้

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

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

อย่าสร้างพรุ่งนี้ในวันนี้

มีความสมดุลตรงนี้ การวางแผนเพื่อพรุ่งนี้ไม่ได้หมายถึงการสร้างระบบของพรุ่งนี้ในวันนี้ ถ้าเรามี 100,000 เรกคอร์ดและอาจมี 100 ล้านในห้าปี ไม่ได้แปลว่าเราสร้างสถาปัตยกรรมสำหรับ 100 ล้านเรกคอร์ดตอนนี้ มันอาจนำมาซึ่งต้นทุนและความซับซ้อนที่เรายังไม่ต้องการ

คำถามที่ผมอยากได้คำตอบคือ: สถาปัตยกรรมของวันนี้พัฒนาไปเป็นของพรุ่งนี้ได้ไหม? ถ้าเราเริ่มอย่างเรียบง่ายพร้อมเส้นทางไปข้างหน้าที่ชัดเจน นั่นมักดีกว่าการจ่ายต้นทุนความซับซ้อนก่อนหลายปี อันตรายไม่ใช่การเริ่มเล็ก อันตรายคือการเริ่มที่ไหนสักแห่งที่ไม่มีทางไปต่อ

วางแผนรับความล้มเหลว

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

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

สำเร็จบางส่วนก็ยังเป็นความล้มเหลวที่คุณต้องเข้าใจ

ความล้มเหลวบางส่วนอันตรายเป็นพิเศษในสถาปัตยกรรมข้อมูล ลองนึกภาพการย้ายหนึ่งล้านเรกคอร์ด แล้วกระบวนการรายงานว่าเสร็จสมบูรณ์ เยี่ยม แต่มาถึงหนึ่งล้านจริงไหม หรือ 999,997 แล้วสามรายการไหนที่หายไป? บางที 200,000 รายการล้มเหลว บางรายการถูกสร้างสองครั้ง หรือทุกอย่างมาถึงแต่บางฟิลด์แปลงข้อมูลไม่สำเร็จ

“งานเสร็จสมบูรณ์” ไม่ใช่สิ่งเดียวกับข้อมูลถูกต้อง สถาปนิกข้อมูลคิดเรื่องการกระทบยอด: เราจะรู้ได้อย่างไรว่าอะไรควรเกิดขึ้น อะไรเกิดขึ้นจริง และต่างกันอย่างไร? แล้วเราจะทำอย่างไรกับมัน?

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

Click to enlarge

ล้มเหลวอย่างสง่างาม

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

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

เฝ้าติดตามสิ่งที่สำคัญ

การวางแผนรับความล้มเหลวโดยไม่มีการเฝ้าติดตามไม่ใช่การวางแผนจริงๆ ถ้าการผสานรวมล้มเหลวตอนตีสองแล้วไม่มีใครสังเกตจนลูกค้าโทรมาในอีกสามวัน เราไม่ได้มีสถาปัตยกรรมเชิงปฏิบัติการ เรามีแต่ความหวัง

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

คิดทั้งสามทิศทาง

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

เทคโนโลยีเปลี่ยนไปในแต่ละบท แต่คำถามไม่เปลี่ยน

สถาปัตยกรรมมีอยู่ข้ามกาลเวลา

บางครั้งนักพัฒนาอาจมองความต้องการแล้วถามว่า “สิ่งนี้ใช้ได้ไหม?” สถาปนิกต้องถามมากกว่านั้น: มันใช้ได้วันนี้ไหม จะยังใช้ได้พรุ่งนี้ไหม และจะเกิดอะไรขึ้นเมื่อมันใช้ไม่ได้เลย? คำถามสามข้อนี้พาเราไปไกลกว่าการ implement และเข้าสู่ชีวิตของระบบ

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

สร้างเพื่อวันนี้ วางแผนเพื่อพรุ่งนี้ วางแผนรับความล้มเหลว เราจะใช้เลนส์สามอันนี้ซ้ำแล้วซ้ำอีก

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

• ปริมาณและการเติบโตจริงเป็นเท่าไร และตัวเลขใดจะเปลี่ยนการออกแบบ
• ความต้องการที่แฝงอยู่ข้อใดที่ฝ่ายธุรกิจยังไม่ได้พูดออกมา
• การออกแบบของวันนี้จะพัฒนาไปเป็นของพรุ่งนี้ได้อย่างไร โดยไม่สร้างระบบของพรุ่งนี้ในวันนี้
• จะเกิดอะไรขึ้นเมื่อบางอย่างล้มเหลว: การกู้คืน การกระทบยอด และการเฝ้าติดตาม