ความล้มเหลว: ความสมบูรณ์แบบและ... ความเกียจคร้านกำลังทำลายเรา

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

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

การเฟลโอเวอร์ไม่ใช่เรื่องสนุกและน่าสนุก นี่คือสิ่งที่ควรทำสิ่งหนึ่งอย่างแน่นอน - ลดการหยุดทำงานเพื่อให้การบริการ บริษัท เสียเงินน้อยลง และในทุกวิธีการจองฉันแนะนำให้คิดในบริบทต่อไปนี้: เงินอยู่ที่ไหน?

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

Shtosh (c) เราใช้ไซต์ที่สองสร้างระบบที่เหมือนกัน... ความซับซ้อนเพิ่มขึ้นเป็นสองเท่า - เรามีสองเอนทิตี นอกจากนี้ เรายังเปิดตัวตรรกะบางอย่างสำหรับการถ่ายโอนข้อมูลจากไซต์หนึ่งไปยังอีกไซต์หนึ่ง นั่นก็คือ การจำลองข้อมูล การคัดลอกข้อมูลคงที่ และอื่นๆ ดังนั้น ตรรกะการจำลองมักจะซับซ้อนมาก ดังนั้น ความซับซ้อนรวมของระบบจึงไม่สามารถเป็น 2 แต่มากกว่า 3, 5, 10 เท่า

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

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

ถึงเวลา “เรื่องราวจาก w”...จากชีวิตแน่นอน

ตัวอย่างหมายเลขหนึ่ง

ลองนึกภาพเว็บไซต์นามบัตรของ Pipe Rolling Plant No. 1 ในเมือง N. มีข้อความเป็นตัวอักษรขนาดใหญ่ว่า PIPE ROLLING PLANT No. 1 ด้านล่างคือสโลแกน: “ท่อของเราเป็นท่อที่กลมที่สุดในกลุ่ม N” และด้านล่างนี้คือหมายเลขโทรศัพท์ของ CEO และชื่อของเขา เราเข้าใจดีว่าคุณต้องทำการจอง - นี่เป็นสิ่งสำคัญมาก! มาเริ่มกันดีกว่าว่ามันประกอบด้วยอะไร Html-statics - นั่นคือรูปภาพสองสามภาพที่ในความเป็นจริงแล้วผู้จัดการทั่วไปกำลังคุยเรื่องข้อตกลงต่อไปที่โต๊ะในโรงอาบน้ำกับคู่ของเขา เราเริ่มคิดถึงการหยุดทำงาน อยู่ในใจ: คุณต้องนอนอยู่ที่นั่นห้านาทีไม่มากไปกว่านี้ แล้วคำถามก็เกิดขึ้น: โดยทั่วไปแล้วไซต์ของเรามียอดขายเท่าใด เท่าไหร่-เท่าไหร่? "ศูนย์" หมายถึงอะไร? และนั่นหมายความว่า เนื่องจากนายพลทำธุรกรรมทั้งสี่รายการเมื่อปีที่แล้วที่โต๊ะเดียวกัน โดยกับคนกลุ่มเดียวกับที่พวกเขาไปโรงอาบน้ำและนั่งที่โต๊ะด้วย และเราเข้าใจดีว่าแม้ว่าไซต์นั้นจะอยู่เพียงวันเดียว แต่ก็ไม่มีอะไรเลวร้ายเกิดขึ้น

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

ตัวอย่างหมายเลขสอง

บล็อกของบริษัท: ผู้ที่ได้รับการฝึกอบรมมาเป็นพิเศษเขียนข่าวที่นั่น เรามีส่วนร่วมในนิทรรศการดังกล่าว แต่เราได้เปิดตัวผลิตภัณฑ์ใหม่อื่น ๆ เป็นต้น สมมติว่านี่คือ PHP มาตรฐานกับ WordPress ซึ่งเป็นฐานข้อมูลขนาดเล็กและเป็นแบบคงที่เล็กน้อย แน่นอนว่าต้องคำนึงถึงอีกครั้งว่าคุณไม่ควรนอนราบไม่ว่าในกรณีใด - "ไม่เกินห้านาที!" เท่านั้น แต่ลองคิดต่อไป บล็อกนี้ทำอะไร? ผู้คนมาจาก Yandex หรือจาก Google โดยอิงจากข้อความค้นหาบางอย่าง ยอดเยี่ยม. การขายมีส่วนเกี่ยวข้องกับเรื่องนี้หรือไม่? Epiphany: ไม่จริง ปริมาณการโฆษณาไปที่ไซต์หลักซึ่งอยู่บนเครื่องอื่น มาเริ่มคิดถึงรูปแบบการจองกันดีกว่า ในทางที่ดีมันจะต้องได้รับการเลี้ยงดูภายในสองสามชั่วโมง และเป็นการดีที่จะเตรียมตัวสำหรับสิ่งนี้ การนำเครื่องจากศูนย์ข้อมูลอื่นมารวมสภาพแวดล้อมไว้บนเครื่องนั้น เช่น เว็บเซิร์ฟเวอร์, PHP, WordPress, MySQL และปล่อยไว้ตรงนั้นก็สมเหตุสมผล ในขณะนี้เมื่อเราเข้าใจว่าทุกอย่างพังเราจำเป็นต้องทำสองสิ่ง - ปล่อย mysql dump ออกไป 50 เมตร มันจะบินไปที่นั่นในหนึ่งนาที และปล่อยรูปภาพจำนวนหนึ่งจากข้อมูลสำรองที่นั่น สิ่งนี้ไม่ได้อยู่ที่นั่นด้วยเพราะพระเจ้าทรงรู้ว่านานแค่ไหน ดังนั้นภายในครึ่งชั่วโมงทุกอย่างก็เพิ่มขึ้น ไม่มีการจำลองแบบ หรือพระเจ้ายกโทษให้ฉัน เฟลโอเวอร์อัตโนมัติ สรุป: สิ่งที่เราสามารถทำได้อย่างรวดเร็วจากการสำรองข้อมูลไม่จำเป็นต้องสำรองข้อมูล

ตัวอย่างหมายเลข XNUMX ซับซ้อนกว่า

ร้านค้าออนไลน์. PhP ที่เปิดใจกว้างมีการปรับแต่งเล็กน้อย mysql มีฐานที่มั่นคง ค่อนข้างคงที่ (ท้ายที่สุดแล้ว ร้านค้าออนไลน์มีภาพ HD ที่สวยงามและทุกสิ่งเหล่านั้น), Redis สำหรับเซสชันและ Elasticsearch สำหรับการค้นหา เราเริ่มคิดถึงการหยุดทำงาน และแน่นอนว่าที่นี่เห็นได้ชัดว่าร้านค้าออนไลน์ไม่สามารถโกหกอย่างไม่ลำบากได้สักวันหนึ่ง ท้ายที่สุดยิ่งมันอยู่นานเท่าไหร่เราก็ยิ่งสูญเสียเงินมากขึ้นเท่านั้น มันคุ้มค่าที่จะเร่งความเร็ว เท่าไร? ฉันคิดว่าถ้าเรานอนสักชั่วโมงจะไม่มีใครบ้า ใช่ เราจะสูญเสียบางอย่างไป แต่ถ้าเราเริ่มทำงานหนัก มันก็จะแย่ลงเท่านั้น เรากำหนดรูปแบบการหยุดทำงานที่อนุญาตต่อชั่วโมง

ทั้งหมดนี้จองได้ยังไง? ไม่ว่าในกรณีใดคุณต้องมีรถยนต์: เวลาหนึ่งชั่วโมงนั้นค่อนข้างน้อย Mysql: ที่นี่ เราต้องการการจำลองแบบอยู่แล้ว การจำลองแบบสด เนื่องจากภายในหนึ่งชั่วโมง 100 GB มักจะไม่ถูกเพิ่มลงในดัมพ์ สถิติ รูปภาพ: อีกครั้งในหนึ่งชั่วโมง 500 GB อาจไม่มีเวลาเพิ่ม ดังนั้นจึงควรคัดลอกรูปภาพทันที Redis: นี่คือจุดที่น่าสนใจ ใน Redis เซสชันจะถูกจัดเก็บ - เราไม่สามารถนำมันไปฝังไว้ได้ เพราะสิ่งนี้จะไม่ดีนัก: ผู้ใช้ทั้งหมดจะถูกออกจากระบบ ตะกร้าของพวกเขาจะว่างเปล่า และอื่นๆ ผู้คนจะถูกบังคับให้ป้อนชื่อผู้ใช้และรหัสผ่านอีกครั้ง และหลายๆ คนอาจแยกทางและทำการซื้อไม่เสร็จสิ้น อีกครั้ง Conversion จะลดลง ในทางกลับกัน Redis เป็นเวอร์ชันล่าสุดโดยตรง โดยผู้ใช้ที่เข้าสู่ระบบครั้งล่าสุดอาจไม่จำเป็นเช่นกัน และการประนีประนอมที่ดีคือนำ Redis ไปกู้คืนจากข้อมูลสำรองเมื่อวาน หรือหากคุณทำทุกชั่วโมงจากหนึ่งชั่วโมงที่แล้ว โชคดีที่การกู้คืนจากข้อมูลสำรองหมายถึงการคัดลอกไฟล์เดียว และเรื่องราวที่น่าสนใจที่สุดคือ Elasticsearch ใครเคยเลือกการจำลองแบบ MySQL บ้าง? ใครเคยเลือกการจำลองแบบ Elasticsearch บ้าง? และมันใช้งานได้ตามปกติหลังจากใคร? สิ่งที่ฉันหมายถึงคือเราเห็นเอนทิตีบางอย่างในระบบของเรา ดูเหมือนว่าจะมีประโยชน์ - แต่มันซับซ้อน
ซับซ้อนในแง่ที่ว่าเพื่อนวิศวกรของเราไม่มีประสบการณ์ในการทำงานด้วย หรือมีประสบการณ์ด้านลบ หรือเราเข้าใจว่านี่ยังคงเป็นเทคโนโลยีที่ค่อนข้างใหม่ซึ่งมีความแตกต่างหรือความดิบ เราคิดว่า... เวร ความยืดหยุ่นก็ดีต่อสุขภาพเช่นกัน การเรียกคืนจากข้อมูลสำรองใช้เวลานาน ฉันควรทำอย่างไร? เราเข้าใจว่าในกรณีของเรามีการใช้ยางยืดในการค้นหา ร้านค้าออนไลน์ของเราขายได้อย่างไร? เราไปหานักการตลาดและถามว่าผู้คนมาจากไหน พวกเขาตอบว่า: “90% จาก Yandex Market มาสู่การ์ดผลิตภัณฑ์โดยตรง” และไม่ว่าพวกเขาจะซื้อมันหรือไม่ก็ตาม ดังนั้นจึงจำเป็นต้องมีการค้นหาโดยผู้ใช้ 10% และการรักษาการจำลองแบบยืดหยุ่น โดยเฉพาะอย่างยิ่งระหว่างศูนย์ข้อมูลที่แตกต่างกันในโซนที่แตกต่างกัน มีความแตกต่างมากมายจริงๆ ทางออกไหน? เราใช้ยางยืดจากไซต์ที่สงวนไว้และไม่ทำอะไรกับมัน หากเรื่องนี้ยืดเยื้อ สักวันหนึ่งเราคงจะหยิบยกเรื่องนี้ขึ้นมา แต่ก็ไม่แน่นอน จริงๆ แล้วข้อสรุปก็เหมือนกัน บวกหรือลบ เราไม่จองบริการที่ไม่กระทบเงินอีก เพื่อให้ไดอะแกรมง่ายขึ้น

ตัวอย่างที่สี่ ยากยิ่งกว่านั้นอีก

Integrator: ขายดอกไม้, เรียกแท็กซี่, ขายสินค้าทั่วไป, อะไรก็ได้. สิ่งสำคัญที่ทำงานตลอด 24 ชั่วโมงทุกวันสำหรับผู้ใช้จำนวนมาก ด้วยสแต็คที่น่าสนใจครบครันที่มีฐานที่น่าสนใจ วิธีแก้ปัญหา โหลดสูง และที่สำคัญนอนเกิน 7 นาทีก็เจ็บ ไม่ใช่เพียงแต่ไม่มากเพราะคนไม่ซื้อแต่เพราะคนจะเห็นว่าสิ่งนี้ไม่ได้ผลก็จะอารมณ์เสียและอาจไม่ได้กลับมาเลย

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

และทุกอย่างดูชัดเจน การสลับการจำลองแบบเป็นงานเล็กๆ น้อยๆ หรือจะเปลี่ยนตัวมันเอง การเขียนชื่อโดเมนใหม่ใน DNS นั้นมาจากซีรี่ส์เดียวกัน ปัญหาคือเมื่อโปรเจ็กต์ดังกล่าวล้มเหลว ความตื่นตระหนกก็เริ่มขึ้น และแม้แต่ผู้ดูแลระบบที่มีหนวดมีเคราที่แข็งแกร่งที่สุดก็สามารถยอมรับได้ หากไม่มีคำแนะนำที่ชัดเจน “เปิดเทอร์มินัล มานี่ ที่อยู่เซิร์ฟเวอร์ของเรายังคงเป็นเช่นนี้” เป็นการยากที่จะปฏิบัติตามกำหนดเวลา 5 นาทีที่กำหนดไว้สำหรับการช่วยชีวิต นอกจากนี้ เมื่อเราใช้กฎระเบียบเหล่านี้ มันเป็นเรื่องง่ายที่จะบันทึกการเปลี่ยนแปลงบางอย่างในโครงสร้างพื้นฐาน เป็นต้น และเปลี่ยนแปลงกฎระเบียบตามนั้น
ถ้าระบบการจองซับซ้อนมากและเมื่อถึงจุดหนึ่งเราทำผิดพลาดเราก็สามารถทำลายไซต์สำรองของเราได้และนอกจากจะเปลี่ยนข้อมูลเป็นฟักทองในทั้งสองไซต์แล้ว นี่คงจะเป็นเรื่องน่าเศร้าอย่างยิ่ง

ตัวอย่างที่ห้า ฮาร์ดคอร์แบบสมบูรณ์

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

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

นั่นอาจเป็นทั้งหมด อย่าขี้เกียจหรือหักโหมจนเกินไป และสถานะการออนไลน์อาจอยู่กับคุณ!

ที่มา: will.com