ทุกคนพูดถึงกระบวนการพัฒนาและการทดสอบ การฝึกอบรมพนักงาน แรงจูงใจที่เพิ่มขึ้น แต่กระบวนการเหล่านี้ยังไม่เพียงพอเมื่อการหยุดให้บริการเพียงนาทีเดียวต้องเสียเงินจำนวนมหาศาล จะทำอย่างไรเมื่อคุณดำเนินธุรกรรมทางการเงินภายใต้ SLA ที่เข้มงวด? จะเพิ่มความน่าเชื่อถือและความทนทานต่อข้อผิดพลาดของระบบของคุณ โดยนำการพัฒนาและการทดสอบออกจากสมการได้อย่างไร
การประชุม HighLoad++ ครั้งต่อไปจะจัดขึ้นในวันที่ 6 และ 7 เมษายน 2020 ที่เซนต์ปีเตอร์สเบิร์ก รายละเอียดและตั๋วสำหรับ . วันที่ 9 พฤศจิกายน เวลา 18:00 น. HighLoad++ มอสโก 2018, เดลี + โกลกาตาฮอลล์ วิทยานิพนธ์และ .
Evgeniy Kuzovlev (ต่อไปนี้ - EC): - เพื่อนสวัสดี! ฉันชื่อ Kuzovlev Evgeniy ฉันมาจากบริษัท EcommPay แผนกเฉพาะคือ EcommPay IT ซึ่งเป็นแผนกไอทีของกลุ่มบริษัท และวันนี้เราจะพูดถึงการหยุดทำงาน - เกี่ยวกับวิธีการหลีกเลี่ยง และวิธีลดผลที่ตามมาหากไม่สามารถหลีกเลี่ยงได้ หัวข้อระบุไว้ดังนี้: “จะทำอย่างไรเมื่อการหยุดทำงานหนึ่งนาทีมีค่าใช้จ่าย $100”? มองไปข้างหน้าตัวเลขของเราเทียบเคียงได้
EcommPay IT ทำหน้าที่อะไร?
พวกเราคือใคร? ทำไมฉันถึงมายืนอยู่ที่นี่ต่อหน้าคุณ? ทำไมฉันถึงมีสิทธิ์บอกคุณบางอย่างที่นี่? และเราจะพูดถึงรายละเอียดเพิ่มเติมที่นี่อย่างไร?
กลุ่มบริษัท EcommPay เป็นผู้ซื้อระหว่างประเทศ เราประมวลผลการชำระเงินทั่วโลก - ในรัสเซีย ยุโรป เอเชียตะวันออกเฉียงใต้ (ทั่วทุกมุมโลก) เรามีสำนักงาน 9 แห่ง พนักงานทั้งหมด 500 คน และน้อยกว่าครึ่งหนึ่งเล็กน้อยเป็นผู้เชี่ยวชาญด้านไอที ทุกสิ่งที่เราทำ ทุกสิ่งที่เราทำเงิน เราทำด้วยตัวเอง
เราเขียนผลิตภัณฑ์ทั้งหมดของเรา (และเรามีผลิตภัณฑ์ค่อนข้างมาก - ในสายผลิตภัณฑ์ไอทีขนาดใหญ่ของเรา เรามีส่วนประกอบที่แตกต่างกันประมาณ 16 ชิ้น) ตัวเราเอง เราเขียนเอง เราพัฒนาตัวเอง และในขณะนี้เราทำธุรกรรมประมาณหนึ่งล้านรายการต่อวัน (ล้านรายการอาจเป็นวิธีที่ถูกต้องในการพูด) เราเป็นบริษัทที่ค่อนข้างใหม่ - เราอายุเพียงหกขวบเท่านั้น
เมื่อ 6 ปีที่แล้ว ถือเป็นการเริ่มต้นธุรกิจเมื่อคนเหล่านั้นเข้ามาทำธุรกิจนี้ พวกเขารวมกันเป็นหนึ่งด้วยความคิด (ไม่มีอะไรอื่นนอกจากความคิด) และเราก็วิ่งหนี เช่นเดียวกับสตาร์ทอัพอื่นๆ เราวิ่งได้เร็วกว่า... สำหรับเรา ความเร็วมีความสำคัญมากกว่าคุณภาพ
เมื่อถึงจุดหนึ่ง เราก็หยุด: เราตระหนักว่าเราไม่สามารถดำเนินชีวิตด้วยความเร็วและคุณภาพนั้นได้อีกต่อไป และเราจำเป็นต้องมุ่งเน้นไปที่คุณภาพก่อน ในขณะนี้ เราตัดสินใจที่จะเขียนแพลตฟอร์มใหม่ที่ถูกต้อง ปรับขนาดได้ และเชื่อถือได้ พวกเขาเริ่มเขียนแพลตฟอร์มนี้ (เริ่มลงทุน พัฒนาการพัฒนา ทดสอบ) แต่เมื่อถึงจุดหนึ่งพวกเขาก็ตระหนักว่าการพัฒนาและการทดสอบไม่ได้ช่วยให้เราเข้าถึงคุณภาพการบริการในระดับใหม่ได้
คุณสร้างผลิตภัณฑ์ใหม่ คุณนำไปผลิต แต่ก็ยังมีบางอย่างผิดปกติเกิดขึ้นที่ไหนสักแห่ง และวันนี้เราจะพูดถึงวิธีก้าวไปสู่ระดับคุณภาพใหม่ (วิธีที่เราทำ ประสบการณ์ของเรา) การนำการพัฒนาและการทดสอบออกจากสมการ เราจะพูดถึงสิ่งที่พร้อมใช้งานสำหรับการปฏิบัติงาน - การดำเนินการใดที่สามารถทำได้ด้วยตัวเอง สิ่งที่สามารถนำเสนอในการทดสอบเพื่อให้มีอิทธิพลต่อคุณภาพ
การหยุดทำงาน คำสั่งของการดำเนินการ
สิ่งสำคัญเสมอมา สิ่งที่เราจะพูดถึงในวันนี้คือการหยุดทำงาน คำพูดที่น่ากลัว หากเรามีเวลาหยุดทำงาน ทุกอย่างจะแย่สำหรับเรา เราวิ่งไปเลี้ยง แอดมินถือเซิฟเวอร์ พระเจ้าห้ามไม่ตกอย่างที่เขาบอกในเพลงนั้น นี่คือสิ่งที่เราจะพูดถึงในวันนี้
เมื่อเราเริ่มเปลี่ยนแนวทาง เราก็สร้างพระบัญญัติ 4 ประการ ฉันนำเสนอไว้บนสไลด์:
พระบัญญัติเหล่านี้ค่อนข้างง่าย:
- ระบุปัญหาได้อย่างรวดเร็ว
- กำจัดมันให้เร็วขึ้นอีก
- ช่วยให้เข้าใจเหตุผล (ภายหลัง สำหรับนักพัฒนา)
- และกำหนดแนวทางให้เป็นมาตรฐาน
ฉันอยากจะดึงความสนใจของคุณไปที่ประเด็นที่ 2 เรากำลังกำจัดปัญหา ไม่ใช่แก้ไข การตัดสินใจเป็นเรื่องรอง สำหรับเรา สิ่งหลักคือผู้ใช้ได้รับการปกป้องจากปัญหานี้ มันจะมีอยู่ในสภาพแวดล้อมที่แยกจากกัน แต่สภาพแวดล้อมนี้จะไม่สามารถติดต่อกับมันได้ จริงๆ แล้ว เราจะพูดถึงปัญหาสี่กลุ่มนี้ (บางกลุ่มมีรายละเอียดมากกว่า บางกลุ่มมีรายละเอียดน้อยกว่า) ฉันจะบอกคุณว่าเราใช้อะไร ประสบการณ์ที่เกี่ยวข้องใดบ้างที่เรามีในการแก้ปัญหา
การแก้ไขปัญหา: จะเกิดขึ้นเมื่อใดและต้องทำอย่างไร
แต่เราจะเริ่มไม่เป็นระเบียบเราจะเริ่มต้นด้วยจุดที่ 2 - จะกำจัดปัญหาได้อย่างรวดเร็วได้อย่างไร? มีปัญหาเกิดขึ้น - เราต้องแก้ไขมัน “เราควรทำอย่างไรกับเรื่องนี้?” - คำถามหลัก และเมื่อเราเริ่มคิดถึงวิธีแก้ปัญหา เราได้พัฒนาข้อกำหนดบางประการที่ต้องปฏิบัติตามในการแก้ไขปัญหาด้วยตนเอง
เพื่อกำหนดข้อกำหนดเหล่านี้ เราตัดสินใจถามตัวเองด้วยคำถามว่า “เราจะมีปัญหาเมื่อใด” และปัญหาที่เกิดขึ้นเกิดขึ้นในสี่กรณี:
- ความล้มเหลวของฮาร์ดแวร์
- บริการภายนอกล้มเหลว
- การเปลี่ยนเวอร์ชันซอฟต์แวร์ (การใช้งานเดียวกัน)
- การเติบโตของภาระระเบิด
เราจะไม่พูดถึงสองคนแรก ความผิดปกติของฮาร์ดแวร์สามารถแก้ไขได้ง่ายมาก: คุณต้องมีทุกสิ่งที่ซ้ำกัน หากสิ่งเหล่านี้เป็นดิสก์ ดิสก์จะต้องประกอบกันใน RAID หากนี่คือเซิร์ฟเวอร์ เซิร์ฟเวอร์จะต้องถูกทำซ้ำ หากคุณมีโครงสร้างพื้นฐานเครือข่าย คุณต้องจัดเตรียมสำเนาที่สองของโครงสร้างพื้นฐานเครือข่าย กล่าวคือ คุณรับมันและ ทำซ้ำมัน และหากมีอะไรผิดพลาดคุณก็เปลี่ยนไปใช้พลังงานสำรอง เป็นการยากที่จะพูดอะไรเพิ่มเติมที่นี่
ประการที่สองคือความล้มเหลวของบริการภายนอก สำหรับส่วนใหญ่แล้วระบบไม่ได้เป็นปัญหาแต่อย่างใด แต่ไม่ใช่สำหรับเรา เนื่องจากเราประมวลผลการชำระเงิน เราจึงเป็นผู้รวบรวมที่อยู่ระหว่างผู้ใช้ (ที่ป้อนข้อมูลบัตรของเขา) กับธนาคาร ระบบการชำระเงิน (Visa, MasterCard, Mira ฯลฯ) บริการภายนอกของเรา (ระบบการชำระเงิน ธนาคาร) มีแนวโน้มที่จะล้มเหลว ทั้งเราและคุณ (หากคุณมีบริการดังกล่าว) ไม่สามารถมีอิทธิพลต่อสิ่งนี้ได้
แล้วต้องทำอย่างไร? มีสองตัวเลือกที่นี่ ขั้นแรก หากทำได้ คุณควรทำซ้ำบริการนี้ในทางใดทางหนึ่ง ตัวอย่างเช่น หากเราทำได้ เราจะถ่ายโอนการรับส่งข้อมูลจากบริการหนึ่งไปยังอีกบริการหนึ่ง: ตัวอย่างเช่น การ์ดได้รับการประมวลผลผ่าน Sberbank, Sberbank กำลังประสบปัญหา - เราถ่ายโอนการรับส่งข้อมูล [แบบมีเงื่อนไข] ไปยัง Raiffeisen สิ่งที่สองที่เราทำได้คือสังเกตความล้มเหลวของบริการภายนอกอย่างรวดเร็ว ดังนั้นเราจะพูดถึงความเร็วในการตอบกลับในส่วนถัดไปของรายงาน
ในความเป็นจริงจากสี่ข้อนี้เราสามารถมีอิทธิพลต่อการเปลี่ยนแปลงเวอร์ชันซอฟต์แวร์โดยเฉพาะ - ดำเนินการที่จะนำไปสู่การปรับปรุงในสถานการณ์ในบริบทของการปรับใช้และในบริบทของการเติบโตอย่างรวดเร็วของโหลด จริงๆแล้วนั่นคือสิ่งที่เราทำ มาอีกแล้ว บันทึกเล็กๆ น้อยๆ...
จากปัญหาทั้งสี่ข้อนี้ มีหลายปัญหาได้รับการแก้ไขทันทีหากคุณมีคลาวด์ หากคุณอยู่ใน Microsoft Azhur, Ozone cloud หรือใช้คลาวด์ของเราจาก Yandex หรือ Mail อย่างน้อยความผิดปกติของฮาร์ดแวร์ก็จะกลายเป็นปัญหาของพวกเขาและทุกอย่างจะดีสำหรับคุณทันทีในบริบทของความผิดปกติของฮาร์ดแวร์
เราเป็นบริษัทที่แหวกแนวเล็กน้อย ที่นี่ทุกคนกำลังพูดถึง "Kubernets" เกี่ยวกับคลาวด์ - เราไม่มีทั้ง "Kubernets" และคลาวด์ แต่เรามีฮาร์ดแวร์มากมายในศูนย์ข้อมูลหลายแห่ง และเราถูกบังคับให้ต้องอาศัยฮาร์ดแวร์นี้ เราถูกบังคับให้ต้องรับผิดชอบทั้งหมด ดังนั้นเราจะพูดคุยกันในบริบทนี้ ดังนั้นเกี่ยวกับปัญหา สองอันแรกถูกนำออกจากวงเล็บ
การเปลี่ยนเวอร์ชั่นซอฟต์แวร์ ฐาน
นักพัฒนาของเราไม่สามารถเข้าถึงการผลิตได้ ทำไมเป็นอย่างนั้น? เพียงแต่เราได้รับการรับรอง PCI DSS และนักพัฒนาของเราก็ไม่มีสิทธิ์เข้าถึง "ผลิตภัณฑ์" นั่นแหละช่วง. เลย. ดังนั้นความรับผิดชอบในการพัฒนาจะสิ้นสุดลงทันทีที่การพัฒนาส่งบิลด์เพื่อการเปิดตัว
พื้นฐานประการที่สองที่เรามี ซึ่งช่วยเราได้มากเช่นกัน คือการไม่มีความรู้ที่ไม่มีเอกสารเฉพาะตัว ฉันหวังว่ามันจะเหมือนกันสำหรับคุณ เพราะถ้าไม่เป็นเช่นนั้นคุณจะมีปัญหา ปัญหาจะเกิดขึ้นเมื่อความรู้เฉพาะตัวที่ไม่มีเอกสารไม่ปรากฏในเวลาที่เหมาะสมและถูกที่ สมมติว่าคุณมีคนหนึ่งที่รู้วิธีปรับใช้ส่วนประกอบเฉพาะ - บุคคลนั้นไม่อยู่ที่นั่น เขาลาพักร้อนหรือป่วย - นั่นแหละ คุณมีปัญหา
และพื้นฐานที่สามที่เราได้มา เราค้นพบมันด้วยความเจ็บปวด เลือด และน้ำตา - เราได้ข้อสรุปว่างานสร้างใดๆ ของเรามีข้อผิดพลาด แม้ว่าจะปราศจากข้อผิดพลาดก็ตาม เราตัดสินใจสิ่งนี้ด้วยตัวเราเอง: เมื่อเราปรับใช้บางอย่าง เมื่อเรานำบางอย่างเข้าสู่การใช้งานจริง เราก็มีบิลด์ที่มีข้อผิดพลาด เราได้กำหนดข้อกำหนดที่ระบบของเราต้องปฏิบัติตาม
ข้อกำหนดสำหรับการเปลี่ยนเวอร์ชันซอฟต์แวร์
มีข้อกำหนดสามประการ:
- เราต้องย้อนกลับการปรับใช้อย่างรวดเร็ว
- เราต้องลดผลกระทบจากการปรับใช้ที่ไม่สำเร็จให้เหลือน้อยที่สุด
- และเราต้องสามารถปรับใช้แบบคู่ขนานได้อย่างรวดเร็ว
ตามลำดับนั่นแหละ! ทำไม เพราะก่อนอื่นเลย เมื่อปรับใช้เวอร์ชันใหม่ ความเร็วนั้นไม่สำคัญ แต่หากมีสิ่งผิดปกติเกิดขึ้น มันเป็นสิ่งสำคัญสำหรับคุณที่จะต้องย้อนกลับอย่างรวดเร็วและมีผลกระทบน้อยที่สุด แต่หากคุณมีชุดเวอร์ชันที่ใช้งานจริงซึ่งปรากฎว่ามีข้อผิดพลาด (โดยสรุป ไม่มีการปรับใช้ แต่มีข้อผิดพลาด) - ความเร็วของการปรับใช้ครั้งต่อไปเป็นสิ่งสำคัญสำหรับคุณ เราได้ทำอะไรเพื่อตอบสนองข้อเรียกร้องเหล่านี้? เราใช้วิธีการต่อไปนี้:
เป็นที่ทราบกันดีอยู่แล้วว่าเราไม่เคยคิดค้นมันขึ้นมา - นี่คือการใช้งานสีน้ำเงิน/เขียว มันคืออะไร? คุณต้องมีสำเนาสำหรับกลุ่มเซิร์ฟเวอร์แต่ละกลุ่มที่ติดตั้งแอปพลิเคชันของคุณ สำเนาเป็นแบบ "อบอุ่น": ไม่มีการรับส่งข้อมูล แต่สามารถส่งการรับส่งข้อมูลนี้ไปยังสำเนานี้ได้ตลอดเวลา สำเนานี้มีเวอร์ชันก่อนหน้า และในขณะที่ปรับใช้ คุณจะเผยแพร่โค้ดเป็นสำเนาที่ไม่ได้ใช้งาน จากนั้นคุณเปลี่ยนบางส่วนของการรับส่งข้อมูล (หรือทั้งหมด) เป็นเวอร์ชันใหม่ ดังนั้นในการเปลี่ยนโฟลว์การรับส่งข้อมูลจากเวอร์ชันเก่าไปเป็นเวอร์ชันใหม่คุณต้องดำเนินการเพียงอย่างเดียว: คุณต้องเปลี่ยนบาลานเซอร์ที่อัปสตรีมเปลี่ยนทิศทาง - จากที่หนึ่งไปยังอีกที่หนึ่ง สะดวกมากและแก้ปัญหาการสลับอย่างรวดเร็วและการย้อนกลับอย่างรวดเร็ววิธีแก้ปัญหาสำหรับคำถามที่สองคือการย่อให้เล็กสุด: คุณสามารถส่งการเข้าชมของคุณเพียงบางส่วนไปยังบรรทัดใหม่ไปยังบรรทัดที่มีรหัสใหม่ (ปล่อยให้เป็นเช่น 2%) และ 2% นี้ไม่ใช่ 100%! หากคุณสูญเสียการรับส่งข้อมูล 100% เนื่องจากการปรับใช้ไม่สำเร็จ นั่นก็น่ากลัว หากคุณสูญเสียการรับส่งข้อมูล 2% นั่นก็ไม่น่าพอใจ แต่ก็ไม่ได้น่ากลัว ยิ่งไปกว่านั้น ผู้ใช้มักจะไม่สังเกตเห็นสิ่งนี้ด้วยซ้ำ เพราะในบางกรณี (ไม่ใช่ทั้งหมด) ผู้ใช้คนเดียวกันซึ่งกด F5 จะถูกส่งไปยังเวอร์ชันอื่นที่ใช้งานได้
ปรับใช้สีน้ำเงิน/เขียว การกำหนดเส้นทาง
อย่างไรก็ตาม ไม่ใช่ทุกอย่างจะง่ายขนาดนี้ “ปรับใช้สีน้ำเงิน/เขียว”... ส่วนประกอบทั้งหมดของเราสามารถแบ่งออกเป็นสามกลุ่ม:
- นี่คือส่วนหน้า (หน้าการชำระเงินที่ลูกค้าของเราเห็น)
- แกนประมวลผล
- อะแดปเตอร์สำหรับการทำงานกับระบบการชำระเงิน (ธนาคาร, MasterCard, Visa...)
และมีความแตกต่างกันนิดหน่อยที่นี่ - ความแตกต่างนั้นอยู่ในเส้นทางระหว่างบรรทัด หากคุณเพียงแค่เปลี่ยนการรับส่งข้อมูล 100% คุณจะไม่มีปัญหาเหล่านี้ แต่ถ้าคุณต้องการเปลี่ยน 2% คุณเริ่มถามคำถาม: “ทำอย่างไร?” สิ่งที่ง่ายที่สุดคือตรงไปตรงมา: คุณสามารถตั้งค่า Round Robin ใน nginx ได้ด้วยการสุ่มเลือก และคุณมี 2% ไปทางซ้าย 98% ทางด้านขวา แต่สิ่งนี้ไม่เหมาะเสมอไป
ตัวอย่างเช่น ในกรณีของเรา ผู้ใช้โต้ตอบกับระบบด้วยคำขอมากกว่าหนึ่งรายการ นี่เป็นเรื่องปกติ: 2, 3, 4, 5 คำขอ - ระบบของคุณอาจจะเหมือนเดิม และหากเป็นสิ่งสำคัญสำหรับคุณที่คำขอของผู้ใช้ทั้งหมดมาที่บรรทัดเดียวกับที่คำขอแรกมา หรือ (จุดที่สอง) คำขอของผู้ใช้ทั้งหมดมาที่บรรทัดใหม่หลังจากสวิตช์ (เขาอาจเริ่มทำงานเร็วกว่านี้ด้วย ระบบก่อนสวิตช์) - ดังนั้นการแจกแจงแบบสุ่มนี้ไม่เหมาะกับคุณ จากนั้นมีตัวเลือกดังต่อไปนี้:
ตัวเลือกแรกที่ง่ายที่สุดจะขึ้นอยู่กับพารามิเตอร์พื้นฐานของไคลเอนต์ (IP Hash) คุณมี IP และคุณแบ่งจากขวาไปซ้ายตามที่อยู่ IP จากนั้นกรณีที่สองที่ฉันอธิบายไว้จะได้ผลสำหรับคุณ เมื่อมีการปรับใช้เกิดขึ้น ผู้ใช้สามารถเริ่มทำงานกับระบบของคุณได้แล้ว และตั้งแต่ช่วงเวลาของการปรับใช้ คำขอทั้งหมดจะไปที่บรรทัดใหม่ (ไปยังบรรทัดเดียวกัน)หากสิ่งนี้ไม่เหมาะกับคุณด้วยเหตุผลบางประการ และคุณต้องส่งคำขอไปยังบรรทัดที่คำขอเริ่มต้นของผู้ใช้มาถึง คุณมีสองทางเลือก...
ตัวเลือกแรก: คุณสามารถซื้อ nginx+ แบบชำระเงินได้ มีกลไกเซสชัน Sticky ซึ่งเมื่อผู้ใช้ร้องขอครั้งแรก จะกำหนดเซสชันให้กับผู้ใช้และผูกเข้ากับอัปสตรีมอย่างใดอย่างหนึ่ง คำขอของผู้ใช้ที่ตามมาทั้งหมดภายในช่วงอายุของเซสชันจะถูกส่งไปยังอัปสตรีมเดียวกันกับที่มีการโพสต์เซสชันสิ่งนี้ไม่เหมาะกับเราเพราะเรามี nginx ปกติอยู่แล้ว การเปลี่ยนมาใช้ nginx+ ไม่ใช่ว่ามันแพง แต่แค่ว่ามันค่อนข้างลำบากสำหรับเราและไม่ถูกต้องนัก ตัวอย่างเช่น “Sticks Sessions” ใช้งานไม่ได้สำหรับเราด้วยเหตุผลง่ายๆ ที่ว่า “Sticks Sessions” ไม่อนุญาตให้มีการกำหนดเส้นทางตาม “อย่างใดอย่างหนึ่งหรือ” ที่นั่น คุณสามารถระบุสิ่งที่เรา "ติดเซสชัน" ทำ เช่น ตามที่อยู่ IP หรือตามที่อยู่ IP และคุกกี้ หรือตามพารามิเตอร์ภายหลัง แต่ "อย่างใดอย่างหนึ่งหรือ" นั้นซับซ้อนกว่าที่นั่น
ดังนั้นเราจึงมาถึงตัวเลือกที่สี่ เราใช้ nginx กับสเตียรอยด์ (นี่คือ openresty) - นี่คือ nginx เดียวกันซึ่งรองรับการรวมสคริปต์ล่าสุดเพิ่มเติม คุณสามารถเขียนสคริปต์สุดท้าย โดยกำหนดให้เป็น "ส่วนที่เหลือแบบเปิด" และสคริปต์สุดท้ายนี้จะถูกดำเนินการเมื่อมีคำขอจากผู้ใช้
และอันที่จริงเราได้เขียนสคริปต์ดังกล่าวโดยตั้งค่าตัวเองเป็น "openresti" และในสคริปต์นี้เราเรียงลำดับพารามิเตอร์ที่แตกต่างกัน 6 ตัวโดยการต่อข้อมูล "หรือ" ขึ้นอยู่กับการมีอยู่ของพารามิเตอร์ตัวใดตัวหนึ่ง เรารู้ว่าผู้ใช้มาที่หน้าเดียวหรืออีกหน้าหนึ่ง บรรทัดเดียวหรืออีกบรรทัดหนึ่ง
ปรับใช้สีน้ำเงิน/เขียว ข้อดีและข้อเสีย
แน่นอนว่าอาจเป็นไปได้ที่จะทำให้ง่ายขึ้นเล็กน้อย (ใช้ "เซสชันที่ติดหนึบ" แบบเดียวกัน) แต่เรายังมีความแตกต่างที่ไม่เพียงแต่ผู้ใช้โต้ตอบกับเราภายในกรอบการทำงานของการประมวลผลครั้งเดียวของธุรกรรมเดียว... แต่ระบบการชำระเงินก็โต้ตอบกับเราด้วย: หลังจากที่เราประมวลผลธุรกรรม (โดยการส่งคำขอไปยังระบบการชำระเงิน) เราจะได้รับเงินคืน
และสมมติว่าถ้าภายในวงจรของเราเราสามารถส่งต่อที่อยู่ IP ของผู้ใช้ในคำขอทั้งหมดและแบ่งผู้ใช้ตามที่อยู่ IP เราจะไม่บอก "วีซ่า" แบบเดียวกัน: "เพื่อน เราเป็นบริษัทย้อนยุคมาก เราดูเหมือน ให้เป็นสากล (บนเว็บไซต์และในรัสเซีย)... โปรดระบุที่อยู่ IP ของผู้ใช้ในช่องเพิ่มเติม โปรโตคอลของคุณได้รับมาตรฐาน”! ชัดเจนว่าพวกเขาจะไม่เห็นด้วย
ดังนั้นสิ่งนี้จึงไม่ได้ผลสำหรับเรา - เราทำอย่างเปิดเผย ดังนั้นด้วยการกำหนดเส้นทางเราจึงได้สิ่งนี้:ดังนั้นการปรับใช้สีน้ำเงิน/เขียวจึงมีข้อดีและข้อเสียที่ผมกล่าวถึง
ข้อเสียสองประการ:
- คุณต้องกังวลกับการกำหนดเส้นทาง
- ข้อเสียเปรียบหลักประการที่สองคือค่าใช้จ่าย
คุณต้องการเซิร์ฟเวอร์เป็นสองเท่า คุณต้องใช้ทรัพยากรในการดำเนินงานเป็นสองเท่า คุณจำเป็นต้องใช้ความพยายามเป็นสองเท่าเพื่อรักษาสวนสัตว์ทั้งหมดนี้
อย่างไรก็ตามในบรรดาข้อดีมีอีกสิ่งหนึ่งที่ฉันไม่ได้กล่าวถึงมาก่อน: คุณมีเงินสำรองในกรณีที่ปริมาณเพิ่มขึ้น หากคุณมีปริมาณงานเพิ่มขึ้นอย่างรวดเร็ว คุณมีผู้ใช้จำนวนมาก จากนั้นคุณเพียงรวมบรรทัดที่สองในการแจกจ่าย 50 ถึง 50 - และคุณจะมีเซิร์ฟเวอร์ x2 ในคลัสเตอร์ของคุณทันทีจนกว่าคุณจะแก้ไขปัญหาการมีเซิร์ฟเวอร์เพิ่มขึ้น
จะทำให้การปรับใช้อย่างรวดเร็วได้อย่างไร?
เราได้พูดคุยเกี่ยวกับวิธีแก้ปัญหาการลดขนาดและการย้อนกลับอย่างรวดเร็ว แต่คำถามยังคงอยู่: “จะปรับใช้อย่างรวดเร็วได้อย่างไร”
มันสั้นและง่ายที่นี่- คุณต้องมีระบบซีดี (การจัดส่งแบบต่อเนื่อง) - คุณจะขาดไม่ได้ หากคุณมีเซิร์ฟเวอร์เดียว คุณสามารถปรับใช้ด้วยตนเองได้ เรามีเซิร์ฟเวอร์ประมาณหนึ่งแสนเซิร์ฟเวอร์และอีกราวหนึ่งแสนเครื่อง แน่นอนว่าเราสามารถวางแผนกที่มีขนาดเท่ากับห้องนี้เพื่อปรับใช้ได้
- การปรับใช้จะต้องขนานกัน หากการปรับใช้ของคุณเป็นไปตามลำดับ ทุกอย่างก็แย่ เซิร์ฟเวอร์หนึ่งเครื่องเป็นเรื่องปกติ คุณจะใช้งานเซิร์ฟเวอร์หนึ่งและครึ่งพันเซิร์ฟเวอร์ตลอดทั้งวัน
- อีกครั้ง สำหรับการเร่งความเร็ว สิ่งนี้อาจไม่จำเป็นอีกต่อไป ในระหว่างการปรับใช้ โปรเจ็กต์มักจะถูกสร้างขึ้น คุณมีโครงการเว็บ มีส่วนหน้า (คุณทำ web pack ที่นั่น คุณคอมไพล์ npm - อะไรประมาณนั้น) และตามหลักการแล้ว กระบวนการนี้ใช้เวลาสั้น - 5 นาที แต่ 5 นาทีเหล่านี้สามารถทำได้ มีความสำคัญ นั่นเป็นเหตุผลว่าทำไมเราไม่ทำอย่างนั้น เราลบ 5 นาทีเหล่านี้ออก เราปรับใช้อาร์ติแฟกต์
สิ่งประดิษฐ์คืออะไร? สิ่งประดิษฐ์คืองานประกอบที่ชิ้นส่วนประกอบทั้งหมดเสร็จสมบูรณ์แล้ว เราเก็บสิ่งประดิษฐ์นี้ไว้ในที่เก็บสิ่งประดิษฐ์ ครั้งหนึ่งเราใช้พื้นที่เก็บข้อมูลดังกล่าวสองแห่ง - มันคือ Nexus และตอนนี้คือ jFrog Artifactory) ในตอนแรกเราใช้ “Nexus” เพราะเราเริ่มฝึกฝนแนวทางนี้ในแอปพลิเคชัน Java (มันเหมาะสมอย่างยิ่ง) จากนั้นพวกเขาก็ใส่แอพพลิเคชั่นบางตัวที่เขียนด้วย PHP เข้าไปที่นั่น และ "Nexus" ไม่เหมาะอีกต่อไป ดังนั้นเราจึงเลือก jFrog Artefactory ซึ่งสามารถประดิษฐ์ได้เกือบทุกอย่าง เรายังมาถึงจุดที่พื้นที่เก็บข้อมูลสิ่งประดิษฐ์นี้เราจัดเก็บแพ็คเกจไบนารีของเราเองที่เรารวบรวมไว้สำหรับเซิร์ฟเวอร์
การเติบโตของภาระระเบิด
เราคุยกันเรื่องการเปลี่ยนเวอร์ชั่นซอฟต์แวร์ สิ่งต่อไปที่เรามีคือภาระที่เพิ่มขึ้นอย่างมาก ในที่นี้ฉันอาจหมายถึงการเติบโตของภาระที่เพิ่มขึ้นอย่างรวดเร็วนั้นไม่ใช่สิ่งที่ถูกต้องเลย...
เราเขียนระบบใหม่ - เน้นการบริการ ทันสมัย สวยงาม พนักงานทุกที่ คิวทุกที่ ไม่ตรงกันทุกที่ และในระบบดังกล่าว ข้อมูลสามารถไหลผ่านกระแสต่างๆ ได้ สำหรับธุรกรรมแรก สามารถใช้ผู้ปฏิบัติงานคนที่ 1, 3, 10 ได้ สำหรับธุรกรรมที่สอง - วันที่ 2, 4, 5 และวันนี้ สมมติว่าในตอนเช้าคุณมีโฟลว์ข้อมูลที่ใช้ผู้ปฏิบัติงานสามคนแรก และในตอนเย็นข้อมูลจะเปลี่ยนแปลงไปอย่างมาก และทุกอย่างก็ใช้ผู้ปฏิบัติงานอีกสามคนแรก
และปรากฎว่าคุณต้องปรับขนาดพนักงานคุณต้องปรับขนาดบริการของคุณ แต่ในขณะเดียวกันก็ป้องกันไม่ให้ทรัพยากรขยายตัว
เราได้กำหนดข้อกำหนดของเราแล้ว ข้อกำหนดเหล่านี้ค่อนข้างง่าย: มีการค้นหาบริการ การกำหนดพารามิเตอร์ - ทุกอย่างเป็นมาตรฐานสำหรับการสร้างระบบที่ปรับขนาดได้ ยกเว้นจุดเดียว - ค่าเสื่อมราคาทรัพยากร เราบอกว่าเราไม่พร้อมที่จะตัดจำหน่ายทรัพยากรเพื่อให้เซิร์ฟเวอร์ทำความร้อนในอากาศ เรารับ "กงสุล" เรารับ "เร่ร่อน" ซึ่งจัดการคนงานของเราเหตุใดจึงเป็นปัญหาสำหรับเรา มาย้อนรอยกันหน่อย ขณะนี้เรามีระบบการชำระเงินประมาณ 70 ระบบอยู่ข้างหลังเรา ในตอนเช้าการจราจรจะผ่าน Sberbank จากนั้น Sberbank ก็ล้มลง และเราก็เปลี่ยนไปใช้ระบบการชำระเงินอื่น เรามีพนักงาน 100 คนก่อน Sberbank และหลังจากนั้นเราจำเป็นต้องเพิ่มพนักงาน 100 คนอย่างรวดเร็วสำหรับระบบการชำระเงินอื่น และเป็นที่พึงปรารถนาที่ทั้งหมดนี้จะเกิดขึ้นโดยปราศจากการมีส่วนร่วมของมนุษย์ เพราะหากมีการมีส่วนร่วมของมนุษย์ ควรมีวิศวกรนั่งอยู่ที่นั่นตลอด 24 ชั่วโมงทุกวัน ซึ่งควรจะทำเช่นนี้เท่านั้น เพราะความล้มเหลวดังกล่าว เมื่อมี 7 ระบบตามหลังคุณ จะเกิดขึ้นเป็นประจำ
ดังนั้นเราจึงดู Nomad ซึ่งมี IP แบบเปิดและเขียนสิ่งที่เราเอง Scale-Nomad - ScaleNo ซึ่งทำสิ่งต่อไปนี้โดยประมาณ: ติดตามการเติบโตของคิวและลดหรือเพิ่มจำนวนพนักงานขึ้นอยู่กับการเปลี่ยนแปลง ของคิว เมื่อเราทำสิ่งนี้ เราคิดว่า: “บางทีเราอาจจะเปิดซอร์สได้หรือไม่” จากนั้นพวกเขาก็มองดูเธอ - เธอเรียบง่ายเหมือนโกเปคสองคน
จนถึงตอนนี้ เรายังไม่ได้เปิดซอร์สมัน แต่หากจู่ๆ หลังจากรายงาน หลังจากตระหนักว่าคุณต้องการสิ่งนั้น คุณต้องการมัน ผู้ติดต่อของฉันอยู่ในสไลด์สุดท้าย - โปรดเขียนถึงฉัน หากมีอย่างน้อย 3-5 คนเราจะสนับสนุน
มันทำงานอย่างไร? มาดูกันดีกว่า! มองไปข้างหน้า: ทางด้านซ้ายมีส่วนในการตรวจสอบของเรา: นี่คือหนึ่งบรรทัด ที่ด้านบนคือเวลาของการประมวลผลเหตุการณ์ ตรงกลางคือจำนวนธุรกรรม ที่ด้านล่างคือจำนวนพนักงานหากมองดูมีข้อผิดพลาดในภาพนี้ บนกราฟด้านบน กราฟใดกราฟหนึ่งพังทลายภายใน 45 วินาที - ระบบการชำระเงินระบบใดระบบหนึ่งล่ม ทันใดนั้น ปริมาณข้อมูลก็เข้ามาภายใน 2 นาที และคิวก็เริ่มเพิ่มขึ้นในระบบการชำระเงินอื่นซึ่งไม่มีคนงาน (เราไม่ได้ใช้ทรัพยากร - ในทางกลับกัน เรากำจัดทรัพยากรอย่างถูกต้อง) เราไม่ต้องการให้ความร้อน - มีจำนวนน้อยที่สุดคือประมาณ 5-10 คน แต่พวกเขารับมือไม่ได้
กราฟสุดท้ายแสดง "โคก" ซึ่งหมายความว่า "Skaleno" เพิ่มจำนวนนี้เป็นสองเท่า จากนั้นเมื่อกราฟลดลงเล็กน้อย กราฟก็ลดลงเล็กน้อย จำนวนคนงานก็เปลี่ยนไปโดยอัตโนมัติ นั่นเป็นวิธีที่สิ่งนี้ทำงาน เราพูดถึงประเด็นที่ 2 - "วิธีกำจัดเหตุผลอย่างรวดเร็ว"
การตรวจสอบ จะระบุปัญหาได้อย่างรวดเร็วได้อย่างไร?
ประเด็นแรกคือ “จะระบุปัญหาได้อย่างรวดเร็วได้อย่างไร” การติดตาม! เราต้องเข้าใจบางสิ่งอย่างรวดเร็ว เราควรเข้าใจเรื่องอะไรบ้างอย่างรวดเร็ว?
สามสิ่ง!- เราต้องเข้าใจและเข้าใจอย่างรวดเร็วถึงประสิทธิภาพของทรัพยากรของเราเอง
- เราต้องเข้าใจความล้มเหลวอย่างรวดเร็วและติดตามประสิทธิภาพของระบบที่อยู่ภายนอกเรา
- จุดที่สามคือการระบุข้อผิดพลาดเชิงตรรกะ นี่คือตอนที่ระบบทำงานเพื่อคุณ ทุกอย่างเป็นปกติตามตัวบ่งชี้ทั้งหมด แต่มีบางอย่างผิดปกติ
ฉันอาจจะไม่บอกคุณอะไรที่เจ๋งๆ ที่นี่ ฉันจะเป็นกัปตันออบเวียส เรามองหาสิ่งที่อยู่ในตลาด เรามี "สวนสัตว์แสนสนุก" นี่คือสวนสัตว์แบบที่เรามีตอนนี้:
เราใช้ Zabbix เพื่อตรวจสอบฮาร์ดแวร์ เพื่อตรวจสอบตัวบ่งชี้หลักของเซิร์ฟเวอร์ เราใช้ Okmeter สำหรับฐานข้อมูล เราใช้ “Grafana” และ “Prometheus” สำหรับตัวชี้วัดอื่นๆ ทั้งหมดที่ไม่ตรงกับสองตัวแรก บางตัวมี “Grafana” และ “Prometheus” และบางตัวมี “Grafana” ที่มี “Influx” และ Telegrafปีที่แล้วเราต้องการใช้ New Relic เจ๋งครับทำได้ทุกอย่าง แต่เท่าที่เธอทำได้ทุกอย่างเธอก็มีราคาแพงมาก เมื่อเราเติบโตจนมีปริมาณเซิร์ฟเวอร์ถึง 1,5 พันเซิร์ฟเวอร์ ผู้ขายรายหนึ่งมาหาเราและพูดว่า: "มาสรุปข้อตกลงสำหรับปีหน้ากันดีกว่า" เราดูราคาแล้วบอกว่าไม่ เราจะไม่ทำแบบนั้น ตอนนี้เรากำลังละทิ้ง New Relic เรามีเซิร์ฟเวอร์ประมาณ 15 เครื่องที่เหลืออยู่ภายใต้การตรวจสอบของ New Relic ราคากลายเป็นบ้าอย่างแน่นอน
และมีเครื่องมือหนึ่งที่เรานำมาใช้เอง - นี่คือดีบักเกอร์ ตอนแรกเราเรียกมันว่า "แบ็กเกอร์" แต่แล้วครูสอนภาษาอังกฤษคนหนึ่งเดินผ่านไป หัวเราะอย่างบ้าคลั่ง และเปลี่ยนชื่อมันว่า "ดีแบ็กเกอร์" มันคืออะไร? นี่คือเครื่องมือที่จริงๆ แล้ว ใช้เวลา 15-30 วินาทีในแต่ละส่วนประกอบ เช่น “กล่องดำ” ของระบบ เพื่อทำการทดสอบประสิทธิภาพโดยรวมของส่วนประกอบ
ตัวอย่างเช่น หากมีหน้าภายนอก (หน้าชำระเงิน) เขาก็เพียงแค่เปิดมันขึ้นมาและดูว่าควรมีลักษณะอย่างไร หากกำลังประมวลผล เขาจะส่ง "ธุรกรรม" ทดสอบและตรวจสอบให้แน่ใจว่า "ธุรกรรม" นี้มาถึง หากนี่คือการเชื่อมต่อกับระบบการชำระเงิน เราจะส่งคำขอทดสอบตามลำดับเท่าที่ทำได้ และเห็นว่าทุกอย่างเรียบร้อยดีสำหรับเรา
ตัวชี้วัดใดที่สำคัญในการติดตาม?
เราติดตามอะไรเป็นหลัก? ตัวบ่งชี้ใดที่สำคัญสำหรับเรา?
- เวลาตอบสนอง / RPS ที่ด้านหน้าเป็นตัวบ่งชี้ที่สำคัญมาก เขาตอบทันทีว่ามีบางอย่างผิดปกติกับคุณ
- จำนวนข้อความที่ประมวลผลในทุกคิว
- จำนวนคนงาน
- ตัวชี้วัดความถูกต้องพื้นฐาน
ประเด็นสุดท้ายคือตัวชี้วัด "ธุรกิจ" "ธุรกิจ" หากคุณต้องการตรวจสอบสิ่งเดียวกัน คุณต้องกำหนดหนึ่งหรือสองตัวชี้วัดที่เป็นตัวบ่งชี้หลักสำหรับคุณ ตัวชี้วัดของเราคือปริมาณงาน (นี่คืออัตราส่วนของจำนวนธุรกรรมที่สำเร็จต่อโฟลว์ธุรกรรมทั้งหมด) หากมีอะไรเปลี่ยนแปลงในช่วงเวลา 5-10-15 นาที แสดงว่าเรามีปัญหา (หากเปลี่ยนแปลงอย่างรุนแรง)
สิ่งที่ดูเหมือนสำหรับเราคือตัวอย่างหนึ่งในบอร์ดของเรา:
ทางด้านซ้ายมีกราฟ 6 เส้น เรียงตามบรรทัด - จำนวนพนักงานและจำนวนข้อความในคิว ทางด้านขวา – RPS, RTS ด้านล่างนี้คือเมตริก "ธุรกิจ" เดียวกัน และในตัวชี้วัด "ธุรกิจ" เราจะเห็นได้ทันทีว่ามีบางอย่างผิดปกติในกราฟตรงกลางทั้งสองกราฟ... นี่เป็นเพียงอีกระบบหนึ่งที่ยืนอยู่ข้างหลังเราที่พังทลายลงสิ่งที่สองที่เราต้องทำคือติดตามการล่มสลายของระบบการชำระเงินภายนอก ที่นี่เราใช้ OpenTracing ซึ่งเป็นกลไก มาตรฐาน กระบวนทัศน์ที่ช่วยให้คุณติดตามระบบแบบกระจาย และมีการเปลี่ยนแปลงเล็กน้อย กระบวนทัศน์ OpenTracing มาตรฐานบอกว่าเราสร้างการติดตามสำหรับคำขอแต่ละรายการ เราไม่ต้องการสิ่งนี้ และเรารวมมันไว้ในสรุปการติดตามการรวมกลุ่ม เราได้สร้างเครื่องมือที่ช่วยให้เราสามารถติดตามความเร็วของระบบที่อยู่ข้างหลังเราได้
กราฟแสดงให้เราเห็นว่าหนึ่งในระบบการชำระเงินเริ่มตอบสนองภายใน 3 วินาที - เรามีปัญหา ยิ่งไปกว่านั้น สิ่งนี้จะตอบสนองเมื่อปัญหาเริ่มต้นขึ้น ในช่วงเวลา 20-30 วินาทีและข้อผิดพลาดในการตรวจสอบประเภทที่สามที่มีอยู่คือการตรวจสอบเชิงตรรกะ
พูดตามตรง ฉันไม่รู้ว่าจะวาดอะไรในสไลด์นี้ เพราะเรามองหาสิ่งที่เหมาะกับเราในตลาดมานานแล้ว เราไม่พบอะไรเลยเราจึงต้องทำเอง
ฉันหมายถึงอะไรโดยการตรวจสอบเชิงตรรกะ? ลองนึกภาพ: คุณสร้างระบบให้ตัวเอง (เช่น Tinder clone); คุณสร้างมันขึ้นมา เปิดตัวมัน ผู้จัดการที่ประสบความสำเร็จ Vasya Pupkin วางโทรศัพท์ไว้ เห็นผู้หญิงที่นั่น ชอบเธอ... และอะไรทำนองนี้ก็ไม่เข้ากับผู้หญิงคนนั้น - เหมือนกับเป็นของเจ้าหน้าที่รักษาความปลอดภัย Mikhalych จากศูนย์ธุรกิจเดียวกัน ผู้จัดการลงไปชั้นล่างแล้วสงสัยว่า: "ทำไมเจ้าหน้าที่รักษาความปลอดภัยคนนี้ Mikhalych จึงยิ้มให้เขาด้วยความยินดีขนาดนี้"ในสถานการณ์เช่นนี้... สำหรับเรา สถานการณ์นี้ฟังดูแตกต่างออกไปเล็กน้อย เพราะ (ฉันเขียน) นี่คือการสูญเสียชื่อเสียงที่นำไปสู่การสูญเสียทางการเงินทางอ้อม สถานการณ์ของเราตรงกันข้าม: เราอาจประสบความสูญเสียทางการเงินโดยตรง - ตัวอย่างเช่น หากเราทำธุรกรรมสำเร็จ แต่ไม่สำเร็จ (หรือกลับกัน) ฉันต้องเขียนเครื่องมือของตัวเองที่ติดตามจำนวนธุรกรรมที่ประสบความสำเร็จในช่วงเวลาหนึ่งโดยใช้ตัวชี้วัดทางธุรกิจ ไม่พบสิ่งใดในตลาด! นี่คือความคิดที่ฉันต้องการจะถ่ายทอด ไม่มีอะไรในตลาดที่จะแก้ปัญหาประเภทนี้ได้
นี่เป็นเรื่องเกี่ยวกับวิธีระบุปัญหาอย่างรวดเร็ว
วิธีระบุเหตุผลในการปรับใช้
ปัญหากลุ่มที่ XNUMX ที่เราแก้ไขคือหลังจากที่เราระบุปัญหาได้แล้ว หลังจากที่เรากำจัดมันไปแล้ว ก็คงจะดีถ้าเข้าใจเหตุผลในการพัฒนา ทดสอบ และทำอะไรกับมันบ้าง ดังนั้นเราจึงจำเป็นต้องตรวจสอบ เราต้องยกบันทึก
หากเรากำลังพูดถึงบันทึก (เหตุผลหลักคือบันทึก) บันทึกส่วนใหญ่ของเราอยู่ใน ELK Stack - เกือบทุกคนมีเหมือนกัน สำหรับบางคนอาจไม่ได้อยู่ใน ELK แต่ถ้าคุณเขียนบันทึกเป็นกิกะไบต์ ไม่ช้าก็เร็วคุณก็จะมาที่ ELK เราเขียนเป็นเทราไบต์
มีปัญหาที่นี่ เราแก้ไข แก้ไขข้อผิดพลาดให้กับผู้ใช้ เริ่มขุดหาสิ่งที่มีอยู่ ปีนเข้าไปใน Kibana ใส่รหัสธุรกรรมที่นั่น และได้ผ้าเช็ดเท้าแบบนี้ (แสดงเยอะมาก) และไม่มีอะไรชัดเจนเลยในผ้าเช็ดเท้านี้ ทำไม ใช่ เนื่องจากยังไม่ชัดเจนว่าส่วนใดเป็นของพนักงานคนใด ส่วนใดเป็นของส่วนประกอบใด และในขณะนั้น เราก็ตระหนักได้ว่าเราต้องการการติดตาม ซึ่งเป็น OpenTracing แบบเดียวกับที่ผมพูดถึงปีที่แล้วเราคิดว่าสิ่งนี้หันความสนใจไปที่ตลาด และมีเครื่องมือสองอย่างที่นั่น - "Zipkin" และ "Jaeger" ในความเป็นจริงแล้ว "Jager" เป็นทายาทในอุดมคติซึ่งเป็นผู้สืบทอดอุดมการณ์ของ "Zipkin" ทุกอย่างดีใน Zipkin ยกเว้นว่าไม่ทราบวิธีการรวม ไม่ทราบวิธีรวมบันทึกในการติดตาม มีเพียงการติดตามเวลาเท่านั้น และ “เยเกอร์” ก็สนับสนุนเรื่องนี้
เราดูที่ "Jager": คุณสามารถใช้งานแอปพลิเคชันได้คุณสามารถเขียนใน Api ได้ (อย่างไรก็ตามมาตรฐาน Api สำหรับ PHP ในเวลานั้นไม่ได้รับการอนุมัติ - นี่เป็นปีที่แล้ว แต่ตอนนี้ได้รับการอนุมัติแล้ว) แต่มี ไม่ใช่ลูกค้าอย่างแน่นอน “ตกลง” เราคิดและเขียนถึงลูกค้าของเราเอง เราได้อะไร? หน้าตาประมาณนี้ครับ:
ใน Jaeger ช่วงจะถูกสร้างขึ้นสำหรับแต่ละข้อความ นั่นคือเมื่อผู้ใช้เปิดระบบ เขาเห็นหนึ่งหรือสองบล็อกสำหรับแต่ละคำขอที่เข้ามา (1-2-3 - จำนวนคำขอที่เข้ามาจากผู้ใช้ จำนวนบล็อก) เพื่อให้ผู้ใช้ง่ายขึ้น เราได้เพิ่มแท็กลงในบันทึกและการติดตามเวลา ดังนั้น ในกรณีที่เกิดข้อผิดพลาด แอปพลิเคชันของเราจะทำเครื่องหมายบันทึกด้วยแท็กข้อผิดพลาดที่เหมาะสม คุณสามารถกรองตามแท็กข้อผิดพลาดได้ และจะแสดงเฉพาะช่วงที่มีบล็อกนี้ซึ่งมีข้อผิดพลาดเท่านั้น ถ้าเราขยาย span จะเป็นดังนี้:
ภายในช่วงมีร่องรอยชุดหนึ่ง ในกรณีนี้ นี่คือการติดตามทดสอบสามรายการ และการติดตามที่สามบอกเราว่ามีข้อผิดพลาดเกิดขึ้น ในเวลาเดียวกัน ที่นี่เราเห็นการติดตามเวลา: เรามีมาตราส่วนเวลาที่ด้านบน และเราเห็นว่าช่วงเวลาใดที่บันทึกนี้หรือบันทึกนั้นถูกบันทึกไว้สิ่งต่างๆ ก็เป็นไปด้วยดีสำหรับเรา เราเขียนส่วนขยายของเราเองและเราเปิดแหล่งที่มา หากคุณต้องการทำงานกับการติดตาม หากคุณต้องการทำงานกับ “Jager” ใน PHP มีส่วนขยายของเรา ยินดีต้อนรับที่จะใช้ ตามที่กล่าวไว้:
เรามีส่วนขยายนี้ - เป็นไคลเอนต์สำหรับ OpenTracing Api ซึ่งสร้างเป็นส่วนขยาย php นั่นคือคุณจะต้องประกอบและติดตั้งลงในระบบ ปีที่แล้วไม่มีอะไรแตกต่าง ขณะนี้มีไคลเอนต์อื่น ๆ ที่เป็นเหมือนส่วนประกอบ ขึ้นอยู่กับคุณ: ไม่ว่าคุณจะขยายส่วนประกอบออกมาด้วยผู้แต่งหรือใช้ส่วนขยายขึ้นอยู่กับคุณมาตรฐานองค์กร
เราพูดถึงพระบัญญัติสามประการ พระบัญญัติประการที่สี่คือการสร้างมาตรฐานแนวทาง เรื่องนี้เกี่ยวกับอะไร? มันเกี่ยวกับเรื่องนี้:
ทำไมถึงมีคำว่า “องค์กร” ที่นี่? ไม่ใช่เพราะเราเป็นบริษัทใหญ่หรือระบบราชการหรอก ไม่ใช่! ฉันต้องการใช้คำว่า "องค์กร" ในบริบทที่ว่าทุกบริษัท ทุกผลิตภัณฑ์ควรมีมาตรฐานของตัวเอง รวมถึงคุณด้วย เรามีมาตรฐานอะไรบ้าง?
- เรามีกฎระเบียบในการใช้งาน เราจะไม่ย้ายไปไหนโดยไม่มีเขาเราทำไม่ได้ เราปรับใช้ประมาณ 60 ครั้งต่อสัปดาห์ กล่าวคือ เราปรับใช้เกือบตลอดเวลา ในเวลาเดียวกัน เรามีข้อห้ามในการปรับใช้ในวันศุกร์ เช่น ในกฎข้อบังคับการปรับใช้ - โดยหลักการแล้ว เราไม่ปรับใช้
- เราต้องการเอกสาร ไม่มีส่วนประกอบใหม่สักชิ้นที่เข้าสู่การผลิตหากไม่มีเอกสารประกอบ แม้ว่าจะเกิดจากปากกาของผู้เชี่ยวชาญ RnD ของเราก็ตาม เราต้องการคำแนะนำในการติดตั้ง แผนที่การตรวจสอบ และคำอธิบายคร่าวๆ (ตามที่โปรแกรมเมอร์เขียนได้) ว่าส่วนประกอบนี้ทำงานอย่างไร และวิธีแก้ไขปัญหา
- เราไม่ได้แก้ปัญหาที่สาเหตุของปัญหา แต่เป็นปัญหา - สิ่งที่ฉันพูดไปแล้ว การปกป้องผู้ใช้จากปัญหาเป็นสิ่งสำคัญสำหรับเรา
- เรามีช่องว่าง ตัวอย่างเช่น เราไม่พิจารณาถึงการหยุดทำงานหากเราสูญเสียการรับส่งข้อมูล 2% ภายในสองนาที โดยพื้นฐานแล้วจะไม่รวมอยู่ในสถิติของเรา หากเป็นเปอร์เซ็นต์มากกว่าหรือชั่วคราวเราก็นับแล้ว
- และเรามักจะเขียนการชันสูตรพลิกศพอยู่เสมอ ไม่ว่าจะเกิดอะไรขึ้นกับเรา สถานการณ์ใดก็ตามที่มีคนประพฤติตัวผิดปกติในกระบวนการผลิตจะถูกสะท้อนให้เห็นในการชันสูตรพลิกศพ การชันสูตรพลิกศพคือเอกสารที่คุณเขียนว่าเกิดอะไรขึ้นกับคุณ กำหนดเวลาโดยละเอียด สิ่งที่คุณทำเพื่อแก้ไข และ (นี่คือมาตรการป้องกัน!) สิ่งที่คุณจะทำเพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้นในอนาคต นี่เป็นข้อบังคับและจำเป็นสำหรับการวิเคราะห์ในภายหลัง
การหยุดทำงานถือว่าอะไร?
ทั้งหมดนี้นำไปสู่อะไร?สิ่งนี้นำไปสู่ความจริงที่ว่า (เรามีปัญหาบางประการเกี่ยวกับความเสถียร ซึ่งไม่เหมาะกับลูกค้าหรือเรา) ในช่วง 6 เดือนที่ผ่านมา ตัวบ่งชี้ความเสถียรของเราคือ 99,97 เราบอกได้เลยว่าเรื่องนี้ไม่มากนัก ใช่ เรามีบางอย่างที่ต้องดิ้นรนเพื่อให้ได้มา จากตัวบ่งชี้นี้ ประมาณครึ่งหนึ่งคือความเสถียร ไม่ใช่ของเรา แต่เป็นไฟร์วอลล์เว็บแอปพลิเคชันของเรา ซึ่งอยู่ตรงหน้าเราและถูกใช้เป็นบริการ แต่ลูกค้าไม่สนใจเรื่องนี้
เราเรียนรู้ที่จะนอนตอนกลางคืน ในที่สุด! หกเดือนที่แล้วเราทำไม่ได้ และในบันทึกนี้พร้อมกับผลลัพธ์ ผมอยากจดบันทึกไว้หนึ่งเรื่อง เมื่อคืนมีรายงานที่ยอดเยี่ยมเกี่ยวกับระบบควบคุมเครื่องปฏิกรณ์นิวเคลียร์ หากคนที่เขียนระบบนี้ได้ยินฉัน โปรดลืมสิ่งที่ฉันพูดเกี่ยวกับ “2% ไม่ใช่การหยุดทำงาน” สำหรับคุณ 2% คือการหยุดทำงาน แม้ว่าจะเป็นเวลาสองนาทีก็ตาม!
นั่นคือทั้งหมด! คำถามของคุณ.
เกี่ยวกับบาลานเซอร์และการย้ายฐานข้อมูล
คำถามจากผู้ฟัง (ต่อไปนี้ – B): – สวัสดีตอนเย็น. ขอบคุณมากสำหรับรายงานของผู้ดูแลระบบ! คำถามสั้นๆ เกี่ยวกับบาลานเซอร์ของคุณ คุณบอกว่าคุณมี WAF นั่นคืออย่างที่ฉันเข้าใจ คุณใช้บาลานเซอร์ภายนอกบางประเภท...
เอก: – ไม่ เราใช้บริการของเราเป็นตัวสร้างสมดุล ในกรณีนี้ WAF เป็นเครื่องมือป้องกัน DDoS สำหรับเราโดยเฉพาะ
ที่: – คุณช่วยพูดสักสองสามคำเกี่ยวกับบาลานเซอร์ได้ไหม?
เอก: – อย่างที่ผมบอกไปแล้ว นี่คือกลุ่มของเซิร์ฟเวอร์ที่เปิดกว้าง ขณะนี้เรามีกลุ่มสำรอง 5 กลุ่มที่ตอบสนองเฉพาะ... นั่นคือเซิร์ฟเวอร์ที่ทำงานแบบ openresty โดยเฉพาะ เฉพาะการรับส่งข้อมูลพร็อกซีเท่านั้น ดังนั้น เพื่อทำความเข้าใจว่าเราถือครองได้มากเพียงใด ขณะนี้เรามีปริมาณการรับส่งข้อมูลปกติหลายร้อยเมกะบิต พวกเขารับมือ พวกเขารู้สึกดี พวกเขาไม่ได้กดดันตัวเองด้วยซ้ำ
ที่: – ยังเป็นคำถามง่ายๆ นี่คือการปรับใช้สีน้ำเงิน/เขียว เช่น คุณทำอะไรกับการย้ายฐานข้อมูล?
เอก: - คำถามที่ดี! ดูสิ ในการปรับใช้สีน้ำเงิน/เขียว เรามีคิวแยกกันสำหรับแต่ละบรรทัด นั่นคือถ้าเรากำลังพูดถึงคิวเหตุการณ์ที่ส่งจากผู้ปฏิบัติงานไปยังผู้ปฏิบัติงาน จะมีคิวแยกต่างหากสำหรับเส้นสีน้ำเงินและสำหรับเส้นสีเขียว หากเรากำลังพูดถึงฐานข้อมูล เราก็จงใจจำกัดให้แคบลงให้มากที่สุดเท่าที่จะเป็นไปได้ ย้ายทุกอย่างในทางปฏิบัติไปไว้ในคิว ในฐานข้อมูลเราจัดเก็บเฉพาะสแต็กของธุรกรรมเท่านั้น และธุรกรรมของเราเหมือนกันในทุกบรรทัด ด้วยฐานข้อมูลในบริบทนี้ เราไม่แบ่งเป็นสีน้ำเงินและสีเขียว เพราะโค้ดทั้งสองเวอร์ชันจะต้องรู้ว่าเกิดอะไรขึ้นกับธุรกรรม
เพื่อนๆ ฉันยังมีรางวัลเล็กๆ น้อยๆ มากระตุ้นคุณด้วย - หนังสือ และฉันควรได้รับรางวัลสำหรับคำถามที่ดีที่สุด
ที่: - สวัสดี. ขอบคุณสำหรับรายงาน คำถามคือสิ่งนี้ คุณตรวจสอบการชำระเงิน คุณตรวจสอบบริการที่คุณสื่อสารด้วย... แต่คุณจะติดตามได้อย่างไรเพื่อให้มีคนมาที่หน้าการชำระเงินของคุณ ชำระเงิน และโครงการให้เครดิตเขาด้วยเงิน นั่นคือคุณจะตรวจสอบได้อย่างไรว่า Marchant ว่างและยอมรับการโทรกลับของคุณแล้ว?
เอก: – “ผู้ขาย” สำหรับเราในกรณีนี้คือบริการภายนอกที่เหมือนกับระบบการชำระเงินทุกประการ เราตรวจสอบความเร็วในการตอบกลับของร้านค้า
เกี่ยวกับการเข้ารหัสฐานข้อมูล
ที่: - สวัสดี. ฉันมีคำถามที่เกี่ยวข้องเล็กน้อย คุณมีข้อมูลที่ละเอียดอ่อนของ PCI DSS ฉันอยากทราบว่าคุณจัดเก็บ PAN ไว้ในคิวที่คุณต้องการโอนเข้าไปอย่างไร คุณใช้การเข้ารหัสใด ๆ หรือไม่? และสิ่งนี้นำไปสู่คำถามที่สอง: ตาม PCI DSS จำเป็นต้องเข้ารหัสฐานข้อมูลใหม่เป็นระยะในกรณีที่มีการเปลี่ยนแปลง (การไล่ผู้ดูแลระบบ ฯลฯ ) - จะเกิดอะไรขึ้นกับการเข้าถึงในกรณีนี้
เอก: - คำถามมหัศจรรย์! ประการแรก เราไม่จัดเก็บ PAN ไว้ในคิว โดยหลักการแล้วเราไม่มีสิทธิ์จัดเก็บ PAN ในรูปแบบที่ชัดเจน ดังนั้นเราจึงใช้บริการพิเศษ (เราเรียกว่า "Kademon") - นี่คือบริการที่ทำสิ่งเดียวเท่านั้น: รับข้อความเป็นอินพุตและส่ง ข้อความที่เข้ารหัสออกมา และเราจัดเก็บทุกสิ่งด้วยข้อความที่เข้ารหัสนี้ ดังนั้น ความยาวคีย์ของเราจึงต่ำกว่า XNUMX กิโลไบต์ ดังนั้นสิ่งนี้จึงจริงจังและเชื่อถือได้ที่: – คุณต้องการ 2 กิโลไบต์ตอนนี้หรือไม่?
เอก: – ดูเหมือนเมื่อวานจะเป็น 256... แล้วที่ไหนอีกล่ะ?!
ตามนี้เป็นครั้งแรก และประการที่สอง โซลูชันที่มีอยู่ รองรับขั้นตอนการเข้ารหัสใหม่ - มี "keks" (คีย์) สองคู่ ซึ่งให้ "สำรับ" ที่เข้ารหัส (คีย์คือคีย์ dek เป็นอนุพันธ์ของคีย์ที่เข้ารหัส) . และหากกระบวนการเริ่มต้นขึ้น (เกิดขึ้นเป็นประจำตั้งแต่ 3 เดือนถึง ± บางส่วน) เราจะดาวน์โหลด "เค้ก" คู่ใหม่ และเราจะเข้ารหัสข้อมูลอีกครั้ง เรามีบริการแยกต่างหากที่จะดึงข้อมูลทั้งหมดออกและเข้ารหัสด้วยวิธีใหม่ ข้อมูลจะถูกเก็บไว้ถัดจากตัวระบุของคีย์ที่ถูกเข้ารหัส ดังนั้นทันทีที่เราเข้ารหัสข้อมูลด้วยคีย์ใหม่ เราจะลบคีย์เก่าออก
บางครั้งจำเป็นต้องชำระเงินด้วยตนเอง...
ที่: – นั่นคือ หากมีการคืนเงินมาถึงสำหรับการดำเนินการบางอย่าง คุณจะยังถอดรหัสมันด้วยคีย์เก่าหรือไม่
เอก: - ใช่.
ที่: – จากนั้นอีกหนึ่งคำถามเล็กๆ น้อยๆ เมื่อเกิดความล้มเหลว การล่มสลาย หรือเหตุการณ์บางอย่าง จำเป็นต้องดำเนินการธุรกรรมด้วยตนเอง มีสถานการณ์เช่นนี้
เอก: - ใช่บางเวลา.
ที่: – คุณได้รับข้อมูลนี้จากที่ไหน? หรือคุณไปที่สถานที่จัดเก็บนี้ด้วยตัวเอง?
เอก: – ไม่ แน่นอนว่า เรามีระบบแบ็คออฟฟิศบางประเภทที่มีอินเทอร์เฟซสำหรับการสนับสนุนของเรา หากเราไม่ทราบว่าธุรกรรมอยู่ในสถานะใด (เช่น จนกว่าระบบการชำระเงินจะตอบกลับด้วยการหมดเวลา) เราจะไม่ทราบลำดับความสำคัญ นั่นคือ เราจะกำหนดสถานะสุดท้ายด้วยความมั่นใจอย่างเต็มที่เท่านั้น ในกรณีนี้ เรากำหนดธุรกรรมให้เป็นสถานะพิเศษสำหรับการประมวลผลด้วยตนเอง ในตอนเช้าหรือวันถัดไป ทันทีที่ฝ่ายสนับสนุนได้รับข้อมูลว่าธุรกรรมดังกล่าวยังคงอยู่ในระบบการชำระเงิน พวกเขาจะประมวลผลด้วยตนเองในอินเทอร์เฟซนี้
ที่: – ฉันมีคำถามสองสามข้อ. หนึ่งในนั้นคือความต่อเนื่องของโซน PCI DSS: คุณจะบันทึกวงจรของพวกเขาได้อย่างไร? คำถามนี้เป็นเพราะนักพัฒนาสามารถใส่อะไรก็ได้ลงในบันทึก! คำถามที่สอง: คุณจะเผยแพร่โปรแกรมแก้ไขด่วนได้อย่างไร การใช้ตัวจัดการในฐานข้อมูลเป็นทางเลือกหนึ่ง แต่อาจมีโปรแกรมแก้ไขด่วนฟรี - มีขั้นตอนอะไรบ้าง? และคำถามที่สามน่าจะเกี่ยวข้องกับ RTO, RPO ความพร้อมของคุณคือ 99,97 เกือบสี่เก้าวินาที แต่อย่างที่ฉันเข้าใจ คุณมีศูนย์ข้อมูลแห่งที่สอง ศูนย์ข้อมูลแห่งที่สาม และศูนย์ข้อมูลที่ห้า... คุณจะซิงโครไนซ์พวกมัน จำลองพวกมัน และทุกอย่างอื่น ๆ ได้อย่างไรเอก: - เริ่มจากอันแรกกันก่อน คำถามแรกเกี่ยวกับบันทึกคืออะไร เมื่อเราเขียนบันทึก เรามีเลเยอร์ที่ปกปิดข้อมูลที่ละเอียดอ่อนทั้งหมด เธอมองไปที่หน้ากากและช่องเพิ่มเติม ด้วยเหตุนี้ บันทึกของเราจึงมีข้อมูลที่ปกปิดอยู่แล้วและวงจร PCI DSS นี่เป็นหนึ่งในงานปกติที่ได้รับมอบหมายให้กับแผนกทดสอบ พวกเขาจำเป็นต้องตรวจสอบแต่ละงาน รวมถึงบันทึกที่พวกเขาเขียน และนี่เป็นหนึ่งในงานปกติในระหว่างการตรวจสอบโค้ด เพื่อควบคุมว่านักพัฒนาจะไม่เขียนบางสิ่งลงไป การตรวจสอบครั้งต่อไปจะดำเนินการเป็นประจำโดยแผนกรักษาความปลอดภัยข้อมูลประมาณสัปดาห์ละครั้ง: บันทึกสำหรับวันสุดท้ายจะถูกคัดเลือกและดำเนินการผ่านเครื่องวิเคราะห์สแกนเนอร์พิเศษจากเซิร์ฟเวอร์ทดสอบเพื่อตรวจสอบทุกอย่าง
เกี่ยวกับโปรแกรมแก้ไขด่วน สิ่งนี้รวมอยู่ในข้อบังคับการปรับใช้ของเรา เรามีข้อกำหนดแยกต่างหากเกี่ยวกับโปรแกรมแก้ไขด่วน เราเชื่อว่าเราปรับใช้โปรแกรมแก้ไขด่วนตลอดเวลาเมื่อเราต้องการ ทันทีที่เวอร์ชันถูกประกอบ ทันทีที่รัน ทันทีที่เรามีสิ่งประดิษฐ์ เรามีผู้ดูแลระบบที่ทำหน้าที่รับสายจากฝ่ายสนับสนุน และเขาจะปรับใช้ในเวลาที่จำเป็นเกี่ยวกับ โฟร์ ไนน์. ตัวเลขที่เราได้รับในขณะนี้บรรลุผลสำเร็จอย่างแท้จริง และเรามุ่งมั่นเพื่อให้ได้มาในศูนย์ข้อมูลอื่น ขณะนี้เรามีศูนย์ข้อมูลแห่งที่สอง และเรากำลังเริ่มกำหนดเส้นทางระหว่างศูนย์ข้อมูลเหล่านั้น และปัญหาของการจำลองแบบข้ามศูนย์ข้อมูลถือเป็นคำถามที่ไม่สำคัญจริงๆ เราพยายามแก้ไขในคราวเดียวโดยใช้วิธีการที่แตกต่างกัน: เราพยายามใช้ "ทารันทูล่า" แบบเดียวกัน - มันไม่ได้ผลสำหรับเรา ฉันจะบอกคุณทันที นั่นเป็นเหตุผลที่เราลงเอยด้วยการสั่ง "เซ็นเซอร์" ด้วยตนเอง ในความเป็นจริง แต่ละแอปพลิเคชันในระบบของเราดำเนินการซิงโครไนซ์ "เปลี่ยนแปลง - เสร็จสิ้น" ที่จำเป็นระหว่างศูนย์ข้อมูลแบบอะซิงโครนัส
ที่: – ถ้าคุณมีอันที่สอง ทำไมคุณถึงไม่ได้อันที่สาม? เพราะยังไม่มีใครสมองแตก...
เอก: – แต่เราไม่มี Split Brain เนื่องจากแต่ละแอปพลิเคชันขับเคลื่อนโดยมัลติมาสเตอร์ จึงไม่สำคัญสำหรับเราว่าคำขอจะส่งไปที่ศูนย์ใด เราพร้อมสำหรับความจริงที่ว่าหากศูนย์ข้อมูลแห่งใดแห่งหนึ่งของเราล้มเหลว (เราพึ่งพาสิ่งนี้) และในระหว่างที่ผู้ใช้ร้องขอสลับไปที่ศูนย์ข้อมูลแห่งที่สอง เราก็พร้อมที่จะสูญเสียผู้ใช้รายนี้ไปอย่างแน่นอน แต่พวกนี้จะเป็นหน่วย, หน่วยสัมบูรณ์.
ที่: - สวัสดีตอนเย็น. ขอบคุณสำหรับรายงาน คุณได้พูดคุยเกี่ยวกับดีบักเกอร์ของคุณซึ่งรันธุรกรรมทดสอบบางอย่างในการใช้งานจริง แต่บอกเราเกี่ยวกับธุรกรรมทดสอบ! มันลึกแค่ไหน?
เอก: – จะต้องผ่านวงจรเต็มของส่วนประกอบทั้งหมด สำหรับส่วนประกอบ ไม่มีความแตกต่างระหว่างธุรกรรมทดสอบและธุรกรรมการผลิต แต่จากมุมมองเชิงตรรกะ นี่เป็นเพียงโปรเจ็กต์แยกต่างหากในระบบ ซึ่งรันเฉพาะธุรกรรมทดสอบเท่านั้น
ที่: - ตัดตรงไหนคะ? ที่นี่ Core ส่ง...
เอก: – ในกรณีนี้เราอยู่เบื้องหลัง “ก” สำหรับการทดสอบธุรกรรม... เรามีสิ่งที่เรียกว่าการกำหนดเส้นทาง: “ก” รู้ว่าระบบการชำระเงินใดที่จะส่งไป - เราส่งไปยังระบบการชำระเงินปลอมซึ่งเพียงแค่ให้สัญญาณ http และ นั่นคือทั้งหมดที่
ที่: – โปรดบอกฉันหน่อยว่าแอปพลิเคชันของคุณเขียนด้วยหินใหญ่ก้อนเดียวหรือคุณตัดมันออกเป็นบริการบางอย่างหรือแม้แต่ไมโครเซอร์วิส?
เอก: – เราไม่มี Monolith แน่นอน เรามีแอปพลิเคชันที่เน้นการบริการ เราล้อเล่นว่าบริการของเราทำจากหินใหญ่ก้อนเดียว - พวกมันค่อนข้างใหญ่จริงๆ ยากที่จะเรียกมันว่าไมโครเซอร์วิส แต่บริการเหล่านี้เป็นบริการที่พนักงานของเครื่องจักรแบบกระจายทำงาน
หากบริการบนเซิร์ฟเวอร์ถูกบุกรุก...
ที่: – จากนั้นฉันก็มีคำถามต่อไป แม้ว่าจะเป็นเซิร์ฟเวอร์ขนาดใหญ่ แต่คุณยังคงบอกว่าคุณมีเซิร์ฟเวอร์ทันทีเหล่านี้จำนวนมาก โดยพื้นฐานแล้วเซิร์ฟเวอร์ทั้งหมดจะประมวลผลข้อมูล และคำถามก็คือ: “ในกรณีที่เซิร์ฟเวอร์ทันทีหรือแอปพลิเคชันตัวใดตัวหนึ่งถูกประนีประนอม ลิงก์ใด ๆ ของบุคคลใด ๆ พวกเขามีการควบคุมการเข้าถึงบ้างไหม? อันไหนทำอะไรได้บ้าง? ฉันควรติดต่อใครเพื่อขอข้อมูลอะไรบ้าง?
เอก: - ใช่อย่างแน่นอน. ข้อกำหนดด้านความปลอดภัยค่อนข้างจริงจัง ประการแรก เรามีการเคลื่อนย้ายข้อมูลแบบเปิด และพอร์ตต่างๆ เป็นเพียงพอร์ตที่เราคาดการณ์ล่วงหน้าเกี่ยวกับความเคลื่อนไหวของการรับส่งข้อมูล หากส่วนประกอบสื่อสารกับฐานข้อมูล (เช่น Muskul) ผ่าน 5-4-3-2 ระบบจะเปิดเฉพาะ 5-4-3-2 เท่านั้น และพอร์ตอื่นๆ และเส้นทางการรับส่งข้อมูลอื่นๆ จะไม่สามารถใช้งานได้ นอกจากนี้ คุณต้องเข้าใจว่าในการผลิตของเรานั้นมีลูปการรักษาความปลอดภัยที่แตกต่างกันประมาณ 10 ลูป และแม้ว่าแอปพลิเคชันจะถูกบุกรุกก็ตาม พระเจ้าห้าม ผู้โจมตีจะไม่สามารถเข้าถึงคอนโซลการจัดการเซิร์ฟเวอร์ได้ เพราะนี่คือโซนความปลอดภัยของเครือข่ายอื่นที่: – และในบริบทนี้ สิ่งที่น่าสนใจกว่าสำหรับฉันคือคุณมีสัญญาบางอย่างกับบริการ - สิ่งที่พวกเขาสามารถทำได้ ผ่าน "การกระทำ" ที่พวกเขาสามารถติดต่อซึ่งกันและกันได้... และในกระแสปกติ บริการเฉพาะบางอย่างร้องขอบางอย่าง แถวรายการ "การกระทำ" ในอีกรายการหนึ่ง ดูเหมือนพวกเขาจะไม่หันไปหาผู้อื่นในสถานการณ์ปกติ และพวกเขาก็มีความรับผิดชอบด้านอื่นด้วย หากหนึ่งในนั้นถูกบุกรุก มันจะสามารถขัดขวาง “การดำเนินการ” ของบริการนั้นได้หรือไม่..
เอก: - ฉันเข้าใจ. หากในสถานการณ์ปกติที่อนุญาตให้มีการสื่อสารกับเซิร์ฟเวอร์อื่นได้เลย แสดงว่าใช่ ตามสัญญา SLA เราไม่ได้ติดตามว่าคุณได้รับอนุญาตเฉพาะ "การกระทำ" 3 ประการแรกเท่านั้น และคุณไม่ได้รับอนุญาตให้ "การกระทำ" 4 ประการ นี่อาจจะซ้ำซ้อนสำหรับเรา เนื่องจากตามหลักการแล้ว เรามีระบบป้องกัน 4 ระดับสำหรับวงจรอยู่แล้ว เราชอบที่จะปกป้องตัวเองด้วยรูปทรงมากกว่าการป้องกันจากภายใน
Visa, MasterCard และ Sberbank ทำงานอย่างไร
ที่: – ฉันต้องการชี้แจงประเด็นเกี่ยวกับการเปลี่ยนผู้ใช้จากศูนย์ข้อมูลหนึ่งไปยังอีกศูนย์หนึ่ง เท่าที่ฉันรู้ Visa และ MasterCard ทำงานโดยใช้โปรโตคอลไบนารีซิงโครนัส 8583 และมีหลายรูปแบบผสมกัน และฉันอยากรู้ว่า ตอนนี้เราหมายถึงการเปลี่ยน - เป็น "Visa" และ "MasterCard" โดยตรงหรือก่อนระบบการชำระเงินก่อนดำเนินการ
เอก: - นี่คือก่อนผสม มิกซ์ของเราตั้งอยู่ในศูนย์ข้อมูลเดียวกัน
ที่: – พูดโดยคร่าวๆ คุณมีจุดเชื่อมต่อจุดเดียวหรือไม่?
เอก: – “วีซ่า” และ “มาสเตอร์การ์ด” - ใช่ เพียงเพราะว่า Visa และ MasterCard ต้องการการลงทุนที่ค่อนข้างจริงจังในโครงสร้างพื้นฐานเพื่อทำสัญญาแยกกันเพื่อรับคู่ผสมที่สอง เป็นต้น พวกมันถูกสงวนไว้ภายในศูนย์ข้อมูลแห่งเดียว แต่ถ้าพระเจ้าห้าม ศูนย์ข้อมูลของเราซึ่งมีการผสมผสานสำหรับการเชื่อมต่อกับ Visa และ MasterCard ตายไป เราก็จะสูญเสียการเชื่อมต่อกับ Visa และ MasterCard...
ที่: – จะจองได้อย่างไร? ฉันรู้ว่าโดยหลักการแล้ว Visa อนุญาตการเชื่อมต่อเพียงครั้งเดียว!
เอก: – พวกเขาจัดหาอุปกรณ์เอง ไม่ว่าในกรณีใด เราได้รับอุปกรณ์ที่ซ้ำซ้อนอยู่ข้างใน
ที่: – สแตนด์มาจาก Connects Orange เหรอ?..
เอก: - ใช่.
ที่: – แต่แล้วกรณีนี้ล่ะ: ถ้าศูนย์ข้อมูลของคุณหายไป คุณจะใช้งานมันต่อไปได้อย่างไร? หรือการจราจรเพิ่งหยุดลง?
เอก: - เลขที่. ในกรณีนี้ เราจะเปลี่ยนการรับส่งข้อมูลไปยังช่องทางอื่น ซึ่งแน่นอนว่าจะมีราคาแพงกว่าสำหรับเราและแพงกว่าสำหรับลูกค้าของเรา แต่การรับส่งข้อมูลจะไม่ผ่านการเชื่อมต่อโดยตรงของเรากับ Visa, MasterCard แต่ผ่าน Sberbank ที่มีเงื่อนไข (เกินจริงมาก)
ฉันขอโทษอย่างมากถ้าฉันทำให้พนักงาน Sberbank ขุ่นเคือง แต่ตามสถิติของเรา Sberbank ล้มบ่อยที่สุดในบรรดาธนาคารรัสเซีย ไม่ถึงหนึ่งเดือนผ่านไปโดยที่ Sberbank ไม่มีของหล่นลงมา
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com