นักพัฒนาควรจะสามารถสืบค้นฐานข้อมูลการผลิตได้หรือไม่


162

นักพัฒนาควรได้รับอนุญาตให้สืบค้นSELECTฐานข้อมูลการผลิต( / อ่านอย่างเดียว) หรือไม่? สถานที่ก่อนหน้านี้ที่ฉันทำงานทีมพัฒนามีdb_datareaderบทบาท; ที่ฉันทำงานอยู่ตอนนี้ทีมพัฒนาไม่สามารถเชื่อมต่อกับอินสแตนซ์การผลิตได้

หนึ่งในอินสแตนซ์ทดสอบคือสำเนาของการผลิตที่คืนค่าจากการสำรองการผลิตสัปดาห์ละครั้งดังนั้นจึงไม่มีปัญหาใด ๆ กับนักพัฒนาที่เห็นข้อมูลจริง

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


25
ก่อนอื่นบอกให้เราทราบว่าทำไมนักพัฒนาจึงต้องการเชื่อมต่อกับการผลิต
Nick Chammas

6
ฉันพยายามตรวจสอบปัญหาการผลิต ข้อมูลที่เกี่ยวข้องถูกโหลดเข้าสู่การผลิตในวันนี้และยังไม่ได้อยู่ในอินสแตนซ์ทดสอบ (ที่ฉันมีสิทธิ์เข้าถึง)
Tom Hunter

คำตอบ:


152

มันขึ้นอยู่กับว่านักพัฒนามีความรับผิดชอบในการสนับสนุนหรือไม่ หากพวกเขาอยู่ในขอการสนับสนุนบรรทัดที่สามพวกเขาอาจจะต้องดูฐานข้อมูลการผลิตเพื่อทำเช่นนี้

โดยทั่วไปแล้วคุณไม่ควรทำสิ่งใดบนเซิร์ฟเวอร์ที่ใช้งานจริงเว้นแต่จะจำเป็นจริงๆที่ต้องทำที่นั่น

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

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


57
+1 สำหรับGenerally it's a bad idea to do anything on a production server unless it's really necessary to do it there.ภาระการพิสูจน์ (เพื่อพูด) ควรอยู่ที่การให้สิทธิ์การเข้าถึงโดยไม่มีเหตุผลที่จะปฏิเสธ
JNK

135

เลขที่

นักพัฒนาไม่ควรเข้าถึงระบบฐานข้อมูลการผลิตด้วยเหตุผลดังต่อไปนี้:

  1. ความพร้อมใช้งานและประสิทธิภาพ : การมีสิทธิ์แบบอ่านอย่างเดียวในฐานข้อมูลจะไม่เป็นอันตราย ข้อความค้นหาที่เขียนไม่ดีสามารถ:

    1. ล็อคตารางปิดกั้นกระบวนการที่สำคัญอื่น ๆ
    2. ทิ้งแคชข้อมูลของคุณบังคับให้กระบวนการอื่นอ่านข้อมูลจากดิสก์อีกครั้ง
    3. เก็บเลเยอร์การจัดเก็บภาษีของคุณส่งผลกระทบต่อบริการอื่น ๆ ที่ใช้พื้นที่เก็บข้อมูลร่วมกันนั้น
  2. ความปลอดภัย : ฐานข้อมูลการผลิตของคุณอาจมีข้อมูลที่ละเอียดอ่อนเช่น:

    • แฮรหัสผ่าน
    • ข้อมูลการเรียกเก็บเงิน
    • ข้อมูลส่วนบุคคลอื่น ๆ ที่สามารถระบุตัวตนได้

    เฉพาะผู้ที่ต้องการเข้าถึงข้อมูลนี้เท่านั้นที่ควรมี ใน บริษัท ที่มีการจัดการที่ดีนักพัฒนาไม่ได้อยู่ในกลุ่มคนเหล่านั้น นอกจากนี้บริษัท ของคุณจะไม่ปฏิบัติตาม PCI และ SOX หากนักพัฒนาสามารถเข้าถึงระบบการผลิตด้วยข้อมูลนี้

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

    "แต่นั่นก็เพื่อ DBA ด้วยเช่นกัน! พวกเขาสามารถทำเช่นนั้นได้!" เผง คุณต้องการ superusers น้อยเท่าที่เป็นไปได้อย่างมีความรับผิดชอบ

ใช่.

นักพัฒนาควรมีสิทธิ์เข้าถึงระบบการผลิต

ที่ บริษัท ของฉันเรามีสี่ทีมที่จัดการกับฐานข้อมูลการผลิต พวกเขาคือ:

  1. นักพัฒนาที่ออกแบบและเขียน schema และรหัสสำหรับฐานข้อมูล พวกเขาไม่สามารถเข้าถึงฐานข้อมูลในการผลิต อย่างไรก็ตามบางครั้งพวกเขาก็นั่งอยู่กับผู้ดูแลระบบหรือสนับสนุนผู้คนและช่วยพวกเขาดูบางสิ่งบางอย่างในชีวิต
  2. ผู้ดูแลระบบที่ปรับใช้ตรวจสอบและจัดการฐานข้อมูลในการผลิต
  3. สนับสนุนผู้คนที่ตรวจสอบปัญหาการผลิตตามเวลาและให้ข้อเสนอแนะแก่นักพัฒนาเพื่อให้พวกเขาสามารถพัฒนาแก้ไขได้
  4. Business Intelligence peopleซึ่งดึงข้อมูลจากฐานข้อมูลโปรดักชั่นโดยใช้สำเนาที่รีเฟรชเป็นประจำของฐานข้อมูลเหล่านั้นหรือเขียนอย่างระมัดระวังและแยก QA-ed (โดยปกติออกแบบโดยผู้ดูแลระบบ)

เป็นเรื่องเหมาะสมที่จะอนุญาตให้นักพัฒนาซอฟต์แวร์ของคุณเข้าถึงเมื่อคุณมีข้อบกพร่องบางอย่างในกลุ่มอื่น ๆ เหล่านี้

ตัวอย่างเช่น:

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

78

การแสดงจะเป็นเหตุผลที่ยิ่งใหญ่

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

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

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


33

หลักการคือ "สิทธิ์น้อยที่สุด" และ "จำเป็นต้องรู้": นักพัฒนาทำผ่านการทดสอบนี้หรือไม่?
โดยเฉพาะอย่างยิ่งเมื่อผู้สอบบัญชีหรือ Sarbannes-Oxley เข้ามาล้ม

จากนั้นข้อสันนิษฐานต่อไปของฉัน: นักพัฒนาโง่ ดังนั้นหากพวกเขาไม่จำเป็นต้องบอกว่าสำหรับการสนับสนุนบรรทัดที่ 3 ที่แล้วที่ต้องการหรือไม่ โดยปกติแล้วลิงเว็บจะไม่ทำ แต่จะเป็นประเภทฐานข้อมูลใช่หากคาดว่าจะรองรับ

จากนั้นจำเป็นต้องเข้าถึงอย่างถาวรหรือไม่ พวกเขาสามารถเข้าถึง "break glass" โดยใช้การเข้าสู่ระบบ SQL หรือบัญชี Windows อื่นที่จำเป็นต้องมีการลงชื่อออก ในกรณีของเรามันเป็นเจ้าของข้อมูล (หวังว่าจะเป็นนักธุรกิจที่มีความชำนาญด้านเทคโนโลยี) และผู้จัดการฝ่ายไอทีอนุมัติ

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

เหล่านี้ถือว่าเป็นร้านค้าขนาดพอสมควรแน่นอน ชาวบ้านสวมหมวกมากขึ้นการแยกหน้าที่น้อยลงคุณสามารถมี

นอกจากนี้ยังมีสภาพแวดล้อมที่ผู้พัฒนาสามารถเรียกใช้คิวรีกับข้อมูลล่าสุดได้หรือไม่ ในร้านค้าสุดท้ายของฉันผลิตภัณฑ์ถูกคืนค่าทุกคืนไปยังเซิร์ฟเวอร์ทดสอบเพื่อมอบสิ่งนี้


20

ฉันคิดว่าคำตอบคือเหมือนกับหลายสิ่งหลายอย่าง IT "ขึ้นอยู่กับ"

ฐานข้อมูล ERP ขนาดใหญ่ที่มีข้อมูลสำคัญของ บริษัท และข้อมูลลูกค้าหรือไม่ อาจไม่ใช่ (ทั้งเพื่อความปลอดภัยและเหตุผลด้านประสิทธิภาพ)

ฐานข้อมูลขนาด 5 MB ของแผนกพร้อมส่วนหน้าของ Access ที่ติดตามการมีส่วนร่วมของกองทุนโดนัทและพิซซ่าหรือไม่ จะไม่สร้างความแตกต่างอย่างมากอย่างน้อยสำหรับการเข้าถึงแบบอ่านอย่างเดียว

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


20

ในสภาพแวดล้อม OLTP 24/7 ที่เป็นปกติไม่ควรอนุญาตนักพัฒนาทั่วไปในการผลิต ระยะเวลา! หากมีเหตุผลบางอย่างปรากฏขึ้นเป็นครั้งคราวอาจมีการอนุญาตเกินกว่าที่จะขอได้ แต่ตามปกติไม่มี

ฉันเห็นเหตุผลหลายประการสำหรับสิ่งนี้:

  • SELECT * จากตารางขนาดใหญ่ที่นำไปสู่:

    • ปัญหาด้านประสิทธิภาพ (ผลิตภัณฑ์คาร์ทีเซียน);
    • การปิดกั้นปัญหาที่ในที่สุดนำเว็บไซต์ไปที่หัวเข่าของมัน
    • การบล็อกโซ่ที่ทำให้เรพลิเคชันหยุดทำงาน;
    • การสั่งซื้อชุดข้อมูลขนาดใหญ่ที่เต็มไปด้วยไดรฟ์ TempDB ซึ่ง .. คาดเดาอะไร เกิดจากความบ้าคลั่งที่สมบูรณ์ :-)!
    • ความดันโลหิตสูงสำหรับ DBA ที่รับผิดชอบการผลิตในคืนนั้น
  • การอ่านข้อมูลที่ละเอียดอ่อน (นักพัฒนาไม่ควรมีข้อมูลบัตรเครดิต ... หรือรายละเอียดส่วนตัวของผู้ใช้)

ฉันแน่ใจว่ามีเหตุผลมากขึ้น


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

16

สองสามรายการที่ต้องพิจารณา

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

ดอลลาร์ขนาดเล็กต้องการกระบวนการที่น้อยลงซึ่งต้องการการไหลที่รวดเร็วของการพัฒนา

ดอลลาร์ที่ใหญ่ขึ้นต้องการกระบวนการที่มากขึ้นต้องการมาตรฐานที่เข้มงวดในการพัฒนา

ปรับการปฏิบัติของคุณกับสิ่งที่คุณกำลังทำ


14

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

  1. เราจำเป็นต้องเข้าถึงเรียลไทม์เพื่อคอยดูการประมวลผลประจำวันของเรา (ในขณะที่เรามีแดชบอร์ดเราต้องสามารถจับตามองในเชิงลึกเกี่ยวกับสิ่งต่าง ๆ ในขณะที่มันจะดีถ้ามีฟีเจอร์นี้ในแดชบอร์ดของเรา
  2. เราต้องการการเข้าถึงแบบเรียลไทม์เพื่อตรวจสอบความล้มเหลวในการผลิตเนื่องจากความล่าช้าอาจมีผลกระทบอย่างมาก (ฉันจะไม่พูดคุยเกี่ยวกับความล้มเหลวของเราที่นี่พวกเขามาในทุกประเภท)
  3. บ่อยครั้งที่เราต้องทำรายงานที่กำหนดเองสำหรับผู้ใช้ทางธุรกิจและข้อมูลนี้ต้องเป็นข้อมูลล่าสุด (dba ไม่มีเวลาทำเช่นนี้และเราไม่มีเวลารอพวกมันไม่เหมาะแน่นอน)
  4. เราจำเป็นต้องทำการตรวจสอบการปรับใช้ / โปรแกรมแก้ไข DDL / DML ที่ใช้งานจริง (DBA ปรับใช้พวกเขา แต่มีเพียงเราเท่านั้นที่รู้ว่าควรจัดโครงสร้างอย่างไรเรารู้เพิ่มเติมเกี่ยวกับโครงสร้างฐานข้อมูลของเรามากกว่า DBA เราอาจแปลกที่นี่ แต่ฐานข้อมูลออกซับซ้อนมากเพราะธุรกิจของเราซับซ้อนมาก)

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


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

@gbn, 4) เรายังต้องยืนยันอีกครั้ง 3) ไม่สามารถเป็นวันเก่าได้
606723

11

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


10

ฉันยอมรับว่าภาระของการให้เหตุผลควรอยู่ในคนที่ต้องการการเข้าถึง โดยทั่วไปในสภาพแวดล้อมที่ฉันได้ปรึกษาฉันได้เข้าถึงระบบการผลิตซึ่งเป็นสภาพแวดล้อมขนาดเล็กและฉันเป็นผู้สนับสนุน ฉันสามารถเข้าถึงการสำรองข้อมูลและอื่น ๆ ที่ฉันได้รับการสนับสนุนสำหรับการสนับสนุนและการเข้าถึงทางอ้อม (ผ่านผู้พัฒนาสนับสนุนเฉพาะ) ไปยังข้อมูลการผลิต

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

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

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

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

หวังว่านี่จะช่วยได้

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


9

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

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

อย่างไรก็ตามผู้พัฒนาสามารถใส่ mini-dumps หรือ log files และใช้ไฟล์สัญลักษณ์ PDB เพื่อสร้างบั๊กใหม่

หากข้อมูลไม่จำเป็นต้องนำมาลงในสภาพแวดล้อมการทดสอบมันเป็นเรื่องปกติสำหรับกระบวนการบางชนิดในการขัดข้อมูลซึ่งสามารถสร้างงานพิเศษได้

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

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

ข้อมูลเป็นส่วนที่มีค่าที่สุดของการใช้งานส่วนใหญ่!


8

ประสิทธิภาพอาจเป็นหนึ่งในเหตุผล

คิวรีนักพัฒนามักจะไม่มีประสิทธิภาพทำให้เกิดการล็อคหรือการใช้ทรัพยากรมากเกินไปจนกว่าจะได้รับการปรับอย่างเหมาะสม

ระบบการผลิตไม่เหมาะสำหรับนักพัฒนาในการทดลอง


8

ขึ้นอยู่กับ DBA และวิธีที่เขาหรือเธอมีความมั่นใจกับผู้พัฒนา โดยทั่วไปนักพัฒนาจะได้รับสิทธิ์ในการสืบค้น (อ่าน) ในฐานข้อมูลการผลิต ตามกฎทั่วไปผู้พัฒนาควรทำงานกับฐานข้อมูลทดสอบ / dev เท่านั้น


8

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

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

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

นี่เป็นเพียงหนึ่งในสิ่งที่เราให้ ตรวจสอบเราที่http://www.Stackify.comเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับโซลูชันการสนับสนุน DevOpsของเรา


4
บางคนอาจคิดว่านี่เป็นสแปมเพราะเจตนาที่จะส่งเสริมผลิตภัณฑ์ของคุณ OTOH มันเกี่ยวข้องกับคำถามและได้รับการเปิดเผยอย่างถูกต้องดังนั้นฉันจึงคิดว่ามันคุ้มค่า
แจ็คดักลาส

ในฐานะที่เป็นจุดสำคัญอย่างน้อยที่สุดใน PostgreSQL แผนแบบสอบถามไม่เพียงพอที่จะรู้ว่ามันเป็นแบบสอบถามแบบอ่านอย่างเดียว
Chris Travers

7

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

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


5

ใน บริษัท ของเราเราดูแลรักษาฐานข้อมูลการผลิตแบบอ่านอย่างเดียวที่ไม่ได้พึ่งพาบริการการผลิต เราอนุญาตให้นักพัฒนาเข้าถึงผู้ที่สามารถเข้าถึงข้อมูลการผลิตได้ หากมีข้อมูลที่ละเอียดอ่อน (ข้อมูลลูกค้าข้อมูลการชำระเงิน ฯลฯ ) เราจะ จำกัด การจำลองแบบของตารางเหล่านั้นและเก็บรักษาตารางข้อมูลตัวอย่างบนเซิร์ฟเวอร์ทาส


1

ไม่ไม่เคย!!

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

ข้อมูลใด ๆ ที่พวกเขาต้องการควรผ่าน DBA ที่สามารถเรียกใช้สิ่งที่พวกเขาต้องการ (เลือก) และส่งผลลัพธ์ให้ นั่นเป็นวิธีที่เราทำในสภาพแวดล้อมของเรา


-1

ฉันไม่แน่ใจว่าทำไมทุกคนถือว่านักพัฒนางี่เง่าและไม่รู้อะไรเลย ฉันได้รับตัวอย่างของบทบาทที่แตกต่างกันมากมายที่พวกเขาทำผิดพลาดและไม่ควรเป็น "กำลังการผลิต" ฉันเป็น DBAs ผู้ดูแลระบบ Sys ผู้ดูแลระบบเครือข่ายนักพัฒนาและอื่น ๆ ล้วน แต่สับสน

ไม่มีใคร (dev, dba, sa) เข้าถึงเซิร์ฟเวอร์หรือฐานข้อมูลใด ๆ ในสภาพแวดล้อมใด ๆ ที่มีการเข้าสู่ระบบเครือข่ายปกติ พวกเขาทั้งหมดมีบัญชี "ผู้ดูแลระบบ" เฉพาะที่ต้องใช้ ใช่โดยทั่วไป dba และ sa กำลังใช้งานของพวกเขาบ่อยขึ้น แต่ถึงแม้ว่าพวกเขาควรเหยียบเบา ๆ ฉันถูกเผาโดยทุกคน

ดังนั้นในวันที่ดีไม่มีบทบาทด้านไอทีที่จำเป็นต้องเข้าถึง อย่างไรก็ตาม sh! t โดนแฟนมือทั้งหมดบนดาดฟ้าและเราต้องการคนที่เหมาะสมในการแก้ปัญหา ซึ่งมักจะนำโดยนักพัฒนาที่รู้จักแอปพลิเคชันและให้คำแนะนำ dba และ sa ไปยังบางจุด มันเป็นเพียงความล่าช้าที่ไม่จำเป็นหรือขอและอนุมัติ

นอกจากนี้การอนุมัติจะไม่ตามมาด้วยการตรวจสอบทุกประเภทดังนั้นการอนุมัติจึงไม่มีความหมาย


2
ไม่แน่ใจว่าคุณกำลังพูดถึงสภาพแวดล้อมใด แต่ใน บริษัท ใด ๆ ที่ต้องปฏิบัติตามกฎระเบียบที่เข้มงวดเช่นระดับสูงกว่า PCI, SOX, SISR, ฯลฯ เข้าสู่ระบบ SA SA ระดับและเข้าสู่ระบบความต้องการที่จะเข้าสู่ระบบ ในกรณีของเราไม่เพียง แต่เราจะบันทึกมัน แต่เรายัง Splunk มันขึ้นมาเพื่อให้ไม่มีใครสามารถแก้ไขได้หลังจากความจริง
Ali Razeghi
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.