คำถามติดแท็ก operating-model

ในสภาพแวดล้อมที่มีการควบคุมอย่างเข้มงวดเช่นภาคบริการทางการเงินการแยกหน้าที่เป็นกลไกสำคัญในการหลีกเลี่ยงการปะทะกันระหว่างบุคคลที่มีความรับผิดชอบในการพัฒนาและสิทธิพิเศษในการผลิต ตามเนื้อผ้าสิ่งนี้ได้หมายความว่านักพัฒนาพัฒนารหัสแล้วมอบมันให้กับฝ่ายปฏิบัติการอย่างไรก็ตามในหลาย ๆ รูปแบบการปฏิบัติการ DevOps การแยกระหว่างการพัฒนาและการปฏิบัติการคืออย่างน้อยเบลอ: ในวิศวกรรมความน่าเชื่อถือของไซต์หรือ SRE ของ Google ให้ฝึกปฏิบัติงานที่มีฟังก์ชั่น SRE แยกต่างหากภายใน Google อย่างไรก็ตามนักพัฒนาจะถูกนำมาใช้เพื่อหนุนหลัง SREs ในเวลาที่มีภาระงานสูง ในรูปแบบ"คุณสร้างมันคุณเรียกใช้"ไม่มีฟังก์ชั่นการทำงานแยกต่างหาก หลังจากใช้เวลาหลายเดือนเจาะลึกลงไปถึงสาเหตุของการแบ่งแยกหน้าที่กลไกดูเหมือนว่ามันมีอยู่เป็นส่วนใหญ่ที่จะสนองSarbanes Oxley มาตรา 404 : การประเมินการจัดการการควบคุมภายใน: (a) กฎที่จำเป็น คณะกรรมการจะกำหนดกฎระเบียบที่กำหนดให้รายงานประจำปีแต่ละรายการตามมาตรา 13 (a) หรือ 15 (d) ของพระราชบัญญัติหลักทรัพย์และตลาดหลักทรัพย์ปี 2477 เพื่อให้มีรายงานการควบคุมภายในซึ่งจะ - (1) ระบุความรับผิดชอบของฝ่ายบริหารในการจัดตั้งและบำรุงรักษาโครงสร้างการควบคุมภายในและขั้นตอนการรายงานทางการเงินอย่างเพียงพอ และ (2) มีการประเมิน ณ สิ้นปีบัญชีล่าสุดของผู้ออกหลักทรัพย์เกี่ยวกับประสิทธิภาพของโครงสร้างการควบคุมภายในและกระบวนการของผู้ออกหลักทรัพย์สำหรับการรายงานทางการเงิน (b) การประเมินและการรายงานการควบคุมภายใน ในการประเมินการควบคุมภายในที่กำหนดโดยส่วนย่อย (a) แต่ละ บริษัท บัญชีสาธารณะที่ลงทะเบียนที่จัดทำหรือออกรายงานการตรวจสอบสำหรับผู้ออกจะต้องยืนยันและรายงานเกี่ยวกับการประเมินโดยการจัดการของผู้ออก …

18 sre  financial-services  operating-model 

"SRE เป็นสิ่งที่เกิดขึ้นเมื่อคุณขอให้วิศวกรซอฟต์แวร์ออกแบบทีมปฏิบัติการ" - วิศวกรรมความน่าเชื่อถือของไซต์ ตั้งแต่หนังสือวิศวกรรมความน่าเชื่อถือของไซต์ของ Googleเปิดตัวมากกว่าหนึ่งครั้งฉันได้รับแจ้งว่า SRE เป็นส่วนขยายของรูปแบบการดำเนินงานหรือการสนับสนุนแอปพลิเคชันที่มีอยู่ เรามีคำถามสองสามข้อที่กำหนดความแตกต่างระหว่าง Sys ผู้ดูแลระบบวิศวกร DevOps และวิศวกรความน่าเชื่อถือของไซต์: Sysadmin และ DevOps Engineer แตกต่างกันอย่างไร ความแตกต่างระหว่าง SRE และ DevOps คืออะไร คำจำกัดความที่ถูกต้องของ DevOps ในการแนะนำให้รู้จักกับผู้เริ่มต้นคืออะไร แต่ไม่มีของคำถามเหล่านี้หรือคำตอบของพวกเขาอธิบายความแตกต่างระหว่างผู้ดูแลระบบและวิศวกรความน่าเชื่อถือ กล่าวอย่างกว้าง ๆ : อะไรคือความแตกต่างที่สำคัญระหว่างการฝึกปฏิบัติงานวิศวกรรมความน่าเชื่อถือของไซต์กับฟังก์ชั่นการพัฒนาและการดำเนินงานที่แยกจากกันแบบดั้งเดิมภายในธุรกิจ

15 sre  operating-model  sysadmin 

ฉันพยายามประเมินว่าเป็นความคิดที่ดีหรือไม่ที่จะย้ายจากเวิร์กโฟลว์แบบ devops ไปเป็นแบบ dev-then-ops แบบดั้งเดิม (ไม่แน่ใจว่าสิ่งที่คุณเรียกว่า) เราเป็นแผนกเล็ก ๆ 5 คนซ่อนตัวอยู่ในสื่อดั้งเดิมของพนักงาน 4,000 คน (เช่นไม่ใช่ซอฟต์แวร์) สองปีที่ผ่านมาเราเริ่มสร้างซอฟต์แวร์เพื่อให้แผนกของเราสามารถขยายการผลิตได้อย่างมีนัยสำคัญ เราประสบความสำเร็จเป็นอย่างดีและ บริษัท ที่ยิ่งใหญ่กว่าเริ่มที่จะสังเกตเห็นได้ จนถึงวันนี้เรารับผิดชอบ แต่เพียงผู้เดียวในการออกแบบพัฒนาและปรับใช้สิ่งที่กลายเป็นแพลตฟอร์มบริการไมโครไฟเบอร์ AWS ~ 10 ทีมของเราไม่ได้ระบุว่าเป็น DevOps แต่หากไม่มีคำถามเรากำลังใช้ชีวิตของ DevOps โดยที่นักพัฒนาแต่ละคนคุ้นเคยกับทั้งรหัสและระบบที่ทำงานอยู่ หนึ่งในคำถามที่เราจะเผชิญในไม่ช้าก็คือสิ่งที่ "ประสิทธิภาพ" ร่วมกันระหว่างเราและแผนกไอทีสำหรับ บริษัท แม่ของเรา เจ้าของโครงการของเรามักจะชอบจ้างมากกว่าการเรียนรู้ภายในองค์กรดังนั้นในกรณีของเราประสิทธิภาพเหล่านี้อาจหมายถึงการทำงานด้านไอทีให้มากที่สุด "หลุดออกจากจานของเรา" เท่าที่จะทำได้ ขณะนี้ฉันจะบอกว่าทีมของเรามีการแบ่ง 70/30% ระหว่างประสบการณ์ในการเขียนโปรแกรมและโครงสร้างพื้นฐาน แผนกไอทีอยู่ในขอบเขตด้านไอทีอย่างแน่นหนาโดยไม่ต้องมองข้ามการพัฒนาซอฟต์แวร์ เจ้าของโครงการของเรา (บุคคลที่ไม่ใช่ด้านเทคนิค) หวังว่าด้วยการมอบงานให้มากที่สุดเท่าที่จะเป็นไปได้ให้กับทีมงานด้านไอทีเราจะเห็นการเพิ่มผลผลิตประมาณ 1: 1 สำหรับการปฏิบัติการแต่ละชั่วโมงที่เราทำ ฉันสงสัยเกี่ยวกับเรื่องนี้แม้ว่า ผลิตภัณฑ์ของเรายังคงเป็นรุ่นเบต้าล่วงหน้า (แม้จะเป็นสินทรัพย์ทางธุรกิจที่สำคัญแล้ว) และจากประสบการณ์ที่ จำกัด …

9 process  operating-model