SysAdmin & ผู้พัฒนา: ความรับผิดชอบ [ปิด]

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

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

ถ้า devs มีปลั๊กอินแฮ็กที่กำหนดเองหรือไฟล์คอร์ที่กำหนดเองในแอพ (ในตัวอย่างนี้ WP)

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

นี่เป็นเพียงการถกเถียง "สงครามศักดิ์สิทธิ์" เพราะฉันแน่ใจว่าคุณจะพบนักพัฒนาที่ไม่เห็นด้วย ฉันได้รับทั้งการอภิปรายทั้งสองด้าน

เหตุผลหลักของฉันที่ไม่ให้เข้าถึงรูต devs (แม้แต่ devs ที่เชื่อถือได้ 100%) นั้นเป็นเพราะบ่อยครั้งที่แพ็กเกจที่ต้องการเพื่อให้ XYZ ทำงานได้อย่างถูกต้อง พวกเขาไปข้างหน้าและติดตั้ง ... หรือกำหนดค่าสิ่งที่มีอยู่แล้วเพื่อให้มันใช้งานได้ ... หรือ ... ดี ... คุณได้รับแนวคิด

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

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

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

หากนักพัฒนาต้องการปลั๊กอินโมดูลการกำหนดค่าการปรับแต่ง ... ไม่มีปัญหา ... ทำเพื่อพวกเขา ... แต่ให้เอกสารเพื่อให้คุณสามารถทำซ้ำได้ในครั้งต่อไป

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

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

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

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

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

มีแนวโน้มที่จะทำให้ความแตกต่างระหว่างเบลอและการดำเนินการไม่ชัดเจน ทำให้นักพัฒนา sysadmins ของคุณและนักพัฒนา sysadmins ของคุณ

ในแง่นี้ wordpress จะได้รับประโยชน์จากการทำงานในการพิสูจน์ (และเชิงโปรแกรม) โดยอัตโนมัติของบล็อก ผู้ใช้เวิร์ดเพรสหลายคนรักษาอินสแตนซ์ WP / WPMU มากกว่าสองสามอินสแตนซ์ไว้

คุณสามารถดูภาพรวมของปรัชญาที่ดี (และสนุกสนาน) ที่สไลด์โครงสร้างพื้นฐานของ Agile จาก Agile 2009

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

หนึ่งในลูกค้าธุรกิจขนาดเล็กที่ใช้เวลานานมากของฉันมีเว็บไซต์ที่มีการติดตั้ง Drupal เว็บไซต์ WordPress หลายแห่งฟอรัม SMF และแอปพลิเคชันเว็บขนาดเล็กอื่น ๆ อีกสองสามตัว ฉันเป็นผู้ดูแลระบบสัญญา (และด้วยเหตุผลทางประวัติศาสตร์อัปเดต / แฮ็ค WordPress และ SMF เมื่อจำเป็น) และลูกค้าของฉันมีสัญญานักพัฒนาของ Drupal สภาพแวดล้อมเป็นเครื่องเสมือน VMware หลายเครื่องบนผู้ให้บริการคลาวด์สาธารณะ

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

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

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

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

Root == ผู้ดูแลระบบ

ผู้ใช้ == นักพัฒนา DBA หรือผู้ใช้

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

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

00:33 CDT คุณรู้หรือไม่ว่าเอกสารสำรองและกู้คืนความเสียหายอยู่ที่ไหน :-P

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

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

ใน บริษัท มหาชนที่นี่ในสหรัฐอเมริกาคุณมี SOX, HIPPA และอื่น ๆ เพื่อจัดการ กฎเหล่านี้ส่วนใหญ่เจ้าพ่อจริงช่วยในการโต้แย้งนี้ SOX สั่งการแยกหน้าที่ซึ่งนักพัฒนาต้องแยกระบบการผลิตออกจากกัน