เรื่องราวของนักพัฒนา 1C: ผู้ดูแลระบบ

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

ช่องทางการสื่อสารความเร็วสูง

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

ลูกค้ารายใหม่มาเพื่อสนับสนุน 1C และเหนือสิ่งอื่นใด สัญญาดังกล่าวได้รวมส่วนที่เรารับผิดชอบในการสำรองข้อมูล แม้ว่าพวกเขาจะมีผู้ดูแลระบบเป็นพนักงานของตัวเองก็ตาม ฐานข้อมูลไคลเอ็นต์-เซิร์ฟเวอร์ MS SQL เป็น DBMS สถานการณ์ที่ค่อนข้างเป็นมาตรฐาน แต่ก็ยังมีความแตกต่างกันนิดหน่อย: ฐานหลักมีขนาดค่อนข้างใหญ่ แต่การเพิ่มขึ้นรายเดือนนั้นน้อยมาก นั่นคือฐานข้อมูลมีข้อมูลประวัติจำนวนมาก เมื่อคำนึงถึงคุณลักษณะนี้ ฉันจึงจัดทำแผนการบำรุงรักษาการสำรองข้อมูลดังต่อไปนี้: ในวันเสาร์แรกของแต่ละเดือน มีการสำรองข้อมูลทั้งหมด ซึ่งค่อนข้างหนัก จากนั้นจึงทำสำเนาส่วนต่างทุกคืน - ปริมาณค่อนข้างน้อย และสำเนาหนึ่งชุด ของบันทึกการทำธุรกรรมทุกชั่วโมง นอกจากนี้ สำเนาฉบับสมบูรณ์และสำเนาส่วนต่างไม่เพียงแต่ถูกคัดลอกไปยังทรัพยากรเครือข่ายเท่านั้น แต่ยังอัปโหลดไปยังเซิร์ฟเวอร์ FTP ของเราเพิ่มเติมอีกด้วย นี่เป็นข้อกำหนดบังคับเมื่อให้บริการนี้

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

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

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

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

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

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

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

ต่อจากนั้น คำขอทั้งหมดของเราที่ส่งไปยังแผนกไอทีได้รับการแก้ไขอย่างรวดเร็ว และไม่มีความขัดแย้งเกิดขึ้นอีก

ติดต่อผู้ดูแลระบบของคุณ

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

- ลองอีกครั้งโดยใช้คำแนะนำเหล่านี้ ทุกอย่างมีการอธิบายไว้อย่างละเอียด หากไม่ได้ผล โปรดเขียนถึงผู้เขียนไซต์นี้ บางทีเขาอาจช่วยได้
“ไม่” ฉันพูด “มันช่วยไม่ได้”
- ทำไม
— ฉันเป็นผู้เขียนเว็บไซต์นี้... (

ด้วยเหตุนี้ เราจึงเปิดตัวมันบน Apache โดยไม่มีปัญหาใดๆ IIS ไม่เคยพ่ายแพ้

ลึกลงไปอีกระดับหนึ่ง

เรามีลูกค้ารายหนึ่งซึ่งเป็นองค์กรการผลิตขนาดเล็ก พวกเขามีเซิร์ฟเวอร์แบบ "คลาสสิก" 3 ใน 1: เซิร์ฟเวอร์เทอร์มินัล + เซิร์ฟเวอร์แอปพลิเคชัน + เซิร์ฟเวอร์ฐานข้อมูล พวกเขาทำงานในการกำหนดค่าเฉพาะอุตสาหกรรมตาม UPP ​​มีผู้ใช้ประมาณ 15-20 คน และโดยหลักการแล้วประสิทธิภาพของระบบนั้นเหมาะกับทุกคน

เมื่อเวลาผ่านไป ทุกอย่างทำงานได้เสถียรไม่มากก็น้อย แต่แล้วยุโรปก็เริ่มคว่ำบาตรรัสเซีย ซึ่งส่งผลให้ชาวรัสเซียเริ่มซื้อสินค้าที่ผลิตในประเทศเป็นหลัก และธุรกิจของ บริษัทนี้ก็ก้าวขึ้นอย่างรวดเร็ว จำนวนผู้ใช้งานเพิ่มขึ้นเป็น 50-60 คน มีการเปิดสาขาใหม่ และการไหลของเอกสารก็เพิ่มขึ้นตามไปด้วย และตอนนี้เซิร์ฟเวอร์ปัจจุบันไม่สามารถรับมือกับโหลดที่เพิ่มขึ้นอย่างรวดเร็วได้อีกต่อไปและ 1C ก็เริ่ม "ช้าลง" ตามที่พวกเขาพูด ในช่วงชั่วโมงเร่งด่วน เอกสารจะถูกประมวลผลเป็นเวลาหลายนาที เกิดข้อผิดพลาดในการบล็อก แบบฟอร์มใช้เวลานานในการเปิด และบริการอื่นๆ ที่เกี่ยวข้องทั้งหมด ผู้ดูแลระบบภายในปัดเป่าปัญหาทั้งหมดโดยพูดว่า “นี่คือ 1C ของคุณ คุณจะเข้าใจเอง” เราได้เสนอให้ดำเนินการตรวจสอบประสิทธิภาพของระบบซ้ำแล้วซ้ำอีก แต่ก็ไม่เคยมีการตรวจสอบเลย ลูกค้าเพียงขอคำแนะนำเกี่ยวกับวิธีการแก้ไขปัญหา

ฉันนั่งลงแล้วเขียนจดหมายค่อนข้างยาวเกี่ยวกับความจำเป็นในการแยกบทบาทของเทอร์มินัลเซิร์ฟเวอร์และแอปพลิเคชันเซิร์ฟเวอร์ด้วย DBMS (ซึ่งโดยหลักการแล้วเราได้กล่าวไว้หลายครั้งแล้ว) ฉันเขียนเกี่ยวกับ DFSS บนเทอร์มินัลเซิร์ฟเวอร์ เกี่ยวกับ Shared Memory ให้ลิงก์ไปยังแหล่งข้อมูลที่เชื่อถือได้ และแม้แต่แนะนำตัวเลือกบางอย่างสำหรับอุปกรณ์ จดหมายฉบับนี้ส่งถึงผู้มีอำนาจในบริษัท และกลับไปที่แผนกไอทีพร้อมกับมติ "นำไปใช้" และโดยทั่วไปแล้วน้ำแข็งก็แตกสลาย

หลังจากนั้นสักพัก ผู้ดูแลระบบจะส่งที่อยู่ IP ของเซิร์ฟเวอร์ใหม่และข้อมูลรับรองการเข้าสู่ระบบมาให้ฉัน เขาบอกว่ามีการปรับใช้ส่วนประกอบเซิร์ฟเวอร์ MS SQL และ 1C ที่นั่น และจำเป็นต้องถ่ายโอนฐานข้อมูล แต่ตอนนี้ไปยังเซิร์ฟเวอร์ DBMS เท่านั้น เนื่องจากมีปัญหาบางอย่างเกิดขึ้นกับคีย์ 1C

ฉันเข้ามาจริง ๆ แล้ว บริการทั้งหมดกำลังทำงานอยู่ เซิร์ฟเวอร์ไม่ได้ทรงพลังมาก แต่โอเค ฉันคิดว่ามันดีกว่าไม่มีอะไรเลย ฉันจะถ่ายโอนฐานข้อมูลในตอนนี้เพื่อช่วยบรรเทาเซิร์ฟเวอร์ปัจจุบัน ฉันดำเนินการโอนทั้งหมดเสร็จสิ้นตามเวลาที่ตกลงไว้ แต่สถานการณ์ไม่เปลี่ยนแปลง - ยังคงมีปัญหาด้านประสิทธิภาพเหมือนเดิม แน่นอนว่ามันแปลก มาลงทะเบียนฐานข้อมูลในคลัสเตอร์ 1C แล้วเราจะได้เห็นกัน

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

อืม... เซิร์ฟเวอร์เสมือนเหรอ? ดูเหมือนว่าไม่เคยมีการจำลองเสมือนใด ๆ และไม่เคยมีเลย... ฉันจำปัญหาที่รู้จักกันดีพอสมควรด้วยความเป็นไปไม่ได้ที่จะส่งต่อคีย์เซิร์ฟเวอร์ 1C ไปยังเครื่องเสมือนบน Hyper-V ใน Windows Server 2008 และที่นี่ ความสงสัยบางอย่างเริ่มก่อตัวขึ้นในตัวฉัน...

ฉันเปิดตัวจัดการเซิร์ฟเวอร์ - บทบาท - บทบาทใหม่ปรากฏขึ้น - Hyper-V ฉันไปที่ตัวจัดการ Hyper-V ดูเครื่องเสมือนหนึ่งเครื่อง เชื่อมต่อ... และแน่นอน... เซิร์ฟเวอร์ฐานข้อมูลใหม่ของเรา...

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

หลังจากนั้นไม่นาน วิกฤติก็เกิดขึ้น สาขาใหม่ต้องปิดตัวลง โหลดลดลง และประสิทธิภาพของระบบก็ยอมรับได้ไม่มากก็น้อย

แน่นอนว่าพวกเขาไม่สามารถส่งต่อรหัสเซิร์ฟเวอร์ไปยังเครื่องเสมือนได้ เป็นผลให้ทุกอย่างยังคงเหมือนเดิม: เซิร์ฟเวอร์เทอร์มินัล + คลัสเตอร์ 1C บนเครื่องจริง เซิร์ฟเวอร์ฐานข้อมูลที่นั่นในเครื่องเสมือน

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

ตารางวันหยุดของฮาร์ดไดรฟ์

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

ก่อนอื่น จำเป็นต้องปรับใช้ฐานข้อมูลการผลิตและทดสอบ นักพัฒนาได้รับข้อมูลการเชื่อมต่อ เข้าสู่ระบบเซิร์ฟเวอร์ เห็นการติดตั้ง MS SQL เซิร์ฟเวอร์ 1C เห็น 2 โลจิคัลไดรฟ์: ไดรฟ์ “C” ที่มีความจุ 250 กิกะไบต์ และไดรฟ์ “D” ที่มีความจุ 1 เทราไบต์ “C” คือระบบ “D” ใช้สำหรับข้อมูล นักพัฒนาตัดสินใจอย่างมีเหตุผลและปรับใช้ฐานข้อมูลทั้งหมดที่นั่น ฉันยังจัดทำแผนการบำรุงรักษา รวมถึงการสำรองข้อมูลด้วย เผื่อไว้ (แม้ว่าเราจะไม่รับผิดชอบในเรื่องนี้ก็ตาม) จริงอยู่ มีการเพิ่มข้อมูลสำรองที่นี่เป็น "D" ในอนาคตมีการวางแผนที่จะกำหนดค่าใหม่ให้กับทรัพยากรเครือข่ายที่แยกจากกัน

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

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

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

ขอบคุณพระเจ้าที่เขาไม่สามารถลบไฟล์ฐานข้อมูลได้และสามารถกู้คืนฐานข้อมูลที่มีประสิทธิผลได้

เป็นที่น่าสังเกตว่าโดยทั่วไปแล้วทุกคนพอใจกับประสิทธิภาพของระบบที่อยู่ในไดรฟ์ USB ไม่มีใครบ่นเกี่ยวกับประสิทธิภาพที่ไม่น่าพอใจของ 1C หลังจากนั้นไม่นานการถือครองได้เริ่มโครงการขนาดใหญ่เพื่อถ่ายโอนฐานข้อมูลข้อมูลทั้งหมดไปยังไซต์รวมศูนย์แห่งเดียวที่มีซุปเปอร์เซิร์ฟเวอร์ ระบบจัดเก็บข้อมูลมูลค่ากว่าล้านรูเบิล ไฮเปอร์ไวเซอร์ที่ซับซ้อน และเบรก 1C ที่ทนไม่ได้ในทุกสาขา

แต่นั่นเป็นเรื่องราวที่แตกต่างอย่างสิ้นเชิง...

ที่มา: will.com