ความแตกต่างระหว่าง DevOps และระบบอัตโนมัติคืออะไร

ฉันเห็นว่าเมื่อใดก็ตามที่มีคนทำ DevOps ส่วนใหญ่เกี่ยวกับการทำสิ่งต่าง ๆ โดยอัตโนมัติเช่นการปรับใช้ ฯลฯ

แต่ระบบอัตโนมัติสิ้นสุดลงและ DevOps เริ่มต้นที่ใด

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

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

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

การทำงานอัตโนมัติเป็นคุณลักษณะที่สำคัญของ DevOps แต่ไม่ใช่เรื่องเต็ม คำถามก็เหมือนกัน "อะไรคือความแตกต่างระหว่างเวลามวยและการต่อสู้?"

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

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

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

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

แจ้งให้ทราบล่วงหน้าฉันสามารถให้คำอธิบายนี้โดยไม่พูดถึง Jenkins, Check, Puppet, Ansible, Vagrant, AWS หรือเครื่องมืออื่น ๆ ที่สนับสนุน นี่คือสิ่งที่เราหมายถึงโดย buzzwords ระดับใหญ่เช่น 'วิธีการ' ในที่สุดชุดเครื่องมือใด ๆ ที่สามารถเปลี่ยนได้ ... สิ่งที่เราเหลืออยู่คือหลักการจัดการหลักที่เปิดใช้งานโดยระบบอัตโนมัติและการมุ่งเน้นไปที่ไปป์ไลน์

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

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

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

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

ฉันต้องการเพิ่ม 2 เซ็นต์ของฉัน:
1) ระบบอัตโนมัติ :
     สิ่งที่เราทุกวันนี้ต้องก้าวไปข้างหน้า มันมีความจำเป็นมากขึ้นโดยที่วิธีที่ต้องการคือการทำให้ชิ้นส่วนเป็นอัตโนมัติหากไม่ใช่กระบวนการทั้งหมด วิธีนี้ช่วยให้ผู้ใช้ (นักพัฒนา) มีความยืดหยุ่นในการใช้ขั้นตอนคงที่พร้อมกับความสามารถในการปรับแต่งตามต้องการ
     ข้อได้เปรียบในวิธีการนี้คือเราสามารถทำให้ชิ้นส่วนต่าง ๆ ที่เราต้องการได้โดยอัตโนมัติในขณะที่ผู้พัฒนาสามารถเชื่อมโยงกระบวนการแต่ละกระบวนการเข้าด้วยกัน ยิ่งขั้นตอนการดำเนินการอัตโนมัติเป็นรูปธรรมมากขึ้นเท่าไหร่การควบคุมก็จะยิ่งดีขึ้นเท่านั้น
     นอกจากนี้ยังมีเครื่องมือมากมายสำหรับระบบอัตโนมัติในพื้นที่เช่นหุ่นยนต์อัตโนมัติ, ระบบอัตโนมัติ SOP (สำหรับอุตสาหกรรมการบริการ), ระบบรายงานอัตโนมัติ (เช่น Splunk) เป็นต้น
2) DevOps:
     เนื่องจากสถานะของคุณภาพการจัดส่งและความตรงต่อเวลาที่คาดว่าจะได้รับจากโลกปัจจุบันจึงมีความจำเป็นที่จะต้องขยายกระบวนการอัตโนมัติของกระบวนการจัดส่งซอฟต์แวร์ เพื่อเปิดใช้งานสิ่งนี้และมอบคุณค่าให้กับลูกค้าในวิธีที่เร็วที่สุดที่เป็นไปได้ DevOps จะพึ่งพาเครื่องมืออัตโนมัติอย่างกว้างขวาง
     ข้อได้เปรียบในวิธีการนี้คือขั้นตอนแต่ละขั้นสามารถเป็นแบบอัตโนมัติเพื่อให้เกิดความสอดคล้องกันทั่วทั้งองค์กรในขณะที่การปรับแต่งภาพรวมโดยรวมสามารถปรับเปลี่ยนให้เหมาะสมกับกระบวนการที่โครงการนั้นต้องการ
     เครื่องมืออัตโนมัติแต่ละตัว (ในทางใดทางหนึ่ง) เช่น Chef สำหรับการปรับใช้ Docker ผ่าน Dockerfile, Maven สำหรับการสร้าง ฯลฯ สามารถเชื่อมโยงเข้าด้วยกันอาจจะผ่าน Jenkins เพื่อให้โซลูชันที่ต้องการในขณะเดียวกันก็ช่วยลดเวลาที่จำเป็นสำหรับการนำไปใช้ .
หวังว่านี่จะช่วยเพิ่มมูลค่าให้กับกระบวนการคิดที่คุณมีอยู่แล้ว

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

การเคลื่อนย้าย DevOps ประกอบด้วยสี่ส่วนหลักที่ย่อว่าCam4 :

1. วัฒนธรรม
2. การทำงานอัตโนมัติ
3. การวัด
4. ที่ใช้ร่วมกัน

นี่คือโพสต์ที่กำหนดต้นฉบับจาก 2010

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

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

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

สังเกตุฉันไม่ได้พูดอะไรเกี่ยวกับระบบอัตโนมัติ

ระบบอัตโนมัติเป็นเรื่องของความสำเร็จในการทำซ้ำ ถ้าฉันทำตามขั้นตอน a, b และ c และกระบวนการ x ใช้งานได้เสมอแล้วขั้นตอน a, b และ c เป็นตัวเลือกที่ดีสำหรับระบบอัตโนมัติ จากนั้นฉันสามารถใช้เวลาสำหรับสิ่งที่เคยเป็นกระบวนการแบบแมนนวลเพื่อทำสิ่งที่ทำให้ฉันมีเงินมากขึ้น ระบบอัตโนมัติสำเร็จเมื่อใช้งานง่าย การปรับใช้รีลีสใหม่การรันการทดสอบการรวมการขันน็อตลงบนสลักการสำรองข้อมูลการปรับสมดุลเครดิตเทียบกับเดบิต ฯลฯ ล้วนเป็นตัวเลือกที่ยอดเยี่ยมสำหรับระบบอัตโนมัติเนื่องจากขั้นตอนซ้ำ ๆ

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