คำถามติดแท็ก process

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

28 amazon-web-services  process  automation  servers  sysadmin 

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

19 terminology  process  project-management  analysis 

กฎหมายของ Brooks: การ เพิ่มกำลังคนไปยังโครงการซอฟต์แวร์ที่ล่าช้าทำให้ภายหลัง ในหนังสือของเขาNo Silver Bullet - Essence and Accidents of Software Engineeringเฟรดเดอริกบรูกส์กำหนดแนวคิดของMythical Man Month : สมมติฐานบรูกส์คือโครงการการเขียนโปรแกรมที่ซับซ้อนไม่สามารถแบ่งพาร์ติชันที่ดีที่สุดที่เป็นงานต่อเนื่องที่สามารถทำงานได้โดยไม่ต้องสื่อสารระหว่างคนงานและไม่มีการสร้างชุดของความสัมพันธ์ที่ซับซ้อนระหว่างงานและผู้ปฏิบัติงานที่มีประสิทธิภาพพวกเขา ตั้งแต่ปี 1982 เราได้ก้าวไปข้างหน้าอย่างแน่นอนและรวบรวมประสบการณ์เพิ่มเติมในการบรรเทาปัญหานี้ มีวิธีแก้ไขปัญหาอะไรบ้างที่คุณได้นำไปใช้ในงานของคุณเพื่อเพิ่มทรัพยากรให้กับโครงการโดยไม่ต้องสร้างปัญหามากขึ้น

16 project-management  process  software-engineering 

เมื่อเร็ว ๆ นี้ Amazon S3 มีไฟดับครั้งใหญ่ในภูมิภาคตะวันออกเฉียงใต้ ดูเหมือนว่ามีสาเหตุมาจากข้อผิดพลาดในการสะกดคำเมื่อเรียกใช้ Playbook การบำรุงรักษาใน Ansible หรือเครื่องมือที่คล้ายกัน คุณสามารถใส่ shell สคริปต์ wrapper รอบ ansible-playbook ให้มีลักษณะดังนี้: #!/bin/bash /usr/bin/ansible-playbook "$@" --list-hosts --list-tasks read -p "Are you sure? (y/n) " answer test "$answer" = "y" || exit 0 exec /usr/bin/ansible-playbook "$@" แต่มีวิธีอื่นอีกบ้างที่คุณใช้ในการปรับปรุงความปลอดภัยและลดโอกาสที่จะเกิดข้อผิดพลาดซึ่งเป็นสาเหตุสำคัญของ บริษัท ของคุณ

12 ansible  process 

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

10 release  process  branch 

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

9 process  operating-model