DevOps คืออะไร?

ประวัติโดยย่อของเวลา

เพื่อให้เข้าใจ DevOps เราต้องย้อนเวลากลับไปในวัยชราเมื่อไม่มีอะไรเลยนอกจากโปรแกรมเมอร์

ตามที่เต๋าสอนเราว่า

โปรแกรมเมอร์ในสมัยก่อนนั้นช่างลึกลับและลึกซึ้ง เราไม่สามารถหยั่งรู้ความคิดของพวกเขาได้ ดังนั้นสิ่งที่เราทำคืออธิบายลักษณะที่ปรากฏของพวกเขา:

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

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

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

แล้วธรรมชาติของมนุษย์ก็เข้ามา และเราก็เริ่มถามหาเพิ่มเติม ความเร็วมากขึ้น คุณสมบัติมากขึ้น ผู้ใช้มากขึ้น ทุกอย่างมากขึ้น

เนื่องจากเป็นคนเจียมเนื้อเจียมตัว ถ่อมตัว และสงบสุข โปรแกรมเมอร์จึงมีโอกาสน้อยมากที่จะเอาชีวิตรอดจากผู้ใช้ที่ขัดสนที่เรียกร้องอะไรเพิ่มเสมอ โอกาสที่ดีที่สุดที่จะชนะคือการเริ่มพัฒนาไปในทิศทางต่างๆ และสร้างวรรณะ ในไม่ช้า โปรแกรมเมอร์ก็สูญสิ้นไปในฐานะบรรพบุรุษของสายพันธุ์ใหม่ที่เรียกว่านักพัฒนา วิศวกรซอฟต์แวร์ ผู้ดูแลระบบเครือข่าย ผู้พัฒนาฐานข้อมูล นักพัฒนาเว็บ สถาปนิกระบบ วิศวกร QA และอื่นๆ อีกมากมาย การพัฒนาอย่างรวดเร็วและปรับตัวเข้ากับความท้าทายจากโลกภายนอกได้กลายเป็นส่วนหนึ่งของ DNA ของพวกเขา วรรณะใหม่สามารถพัฒนาได้ในเวลาไม่กี่สัปดาห์ นักพัฒนาเว็บกลายเป็นนักพัฒนาแบ็คเอนด์, นักพัฒนาฟรอนต์เอนด์, นักพัฒนา PHP, นักพัฒนา Ruby, นักพัฒนาเชิงมุม ... ทุกอย่างจะต้องตกนรก

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

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

หากพวกเขาค้นหาความรู้สึกของตนเท่านั้น พวกเขาจะค้นพบว่าจุดประกายของโปรแกรมเมอร์อยู่ในใจ รอคอยที่จะส่องแสงและนำสันติสุขมาสู่จักรวาล

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

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

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

โครงการซอฟต์แวร์มีแนวโน้มที่จะล้มเหลวมากจนเป็นที่ยอมรับว่าเป็นมาตรฐานอุตสาหกรรม สถิติแสดงให้เห็นว่ากว่า 50% ของโครงการล้มเหลว และดูเหมือนว่าไม่มีอะไรต้องทำเลย (ZDNet, CNet)

ทุกรุ่นมีบุคคลเปิดกว้างเพียงไม่กี่คนที่รู้ว่ากลุ่มนักพัฒนาเหล่านี้ทั้งหมดต้องหาวิธีการทำงานร่วมกัน สื่อสาร และมีความยืดหยุ่นเพื่อให้มั่นใจว่าลูกค้าจะได้รับโซลูชันที่ดีที่สุด มีร่องรอยของความพยายามเหล่านี้เกิดขึ้นตั้งแต่ต้นปี 2500 โดยเพื่อนร่วมงานของ John Von Neumann ผู้ยิ่งใหญ่ อย่างไรก็ตาม เราต้องรอจนถึงต้นปี 2544 เพื่อเริ่มการปฏิวัติ เมื่อโหลสกปรกสร้างประกาศ Agile

Agile Manifesto ตั้งอยู่บนหลักการสิบสองประการ:

1. ความพึงพอใจของลูกค้าโดยการส่งมอบซอฟต์แวร์ที่มีค่าในช่วงต้นและต่อเนื่อง
2. ยินดีต้อนรับความต้องการที่เปลี่ยนแปลง แม้อยู่ในช่วงการพัฒนาที่ล่าช้า
3. ซอฟต์แวร์ที่ใช้งานได้มีการจัดส่งบ่อยครั้ง (สัปดาห์แทนที่จะเป็นเดือน)
4. ความร่วมมืออย่างใกล้ชิดทุกวันระหว่างนักธุรกิจและนักพัฒนา
5. โครงการสร้างขึ้นจากบุคคลที่มีแรงบันดาลใจซึ่งควรได้รับความไว้วางใจ
6. การสนทนาแบบตัวต่อตัวเป็นรูปแบบการสื่อสารที่ดีที่สุด (co-location)
7. ซอฟต์แวร์ทำงานเป็นตัววัดความก้าวหน้าที่สำคัญ
8. การพัฒนาที่ยั่งยืน สามารถรักษาอัตราการก้าวให้คงที่
9. ความเอาใจใส่อย่างต่อเนื่องสู่ความเป็นเลิศทางเทคนิคและการออกแบบที่ดี
10. ความเรียบง่าย—ศิลปะของการเพิ่มปริมาณงานที่ไม่ได้ทำ—เป็นสิ่งสำคัญ
11. ทีมงานจัดเอง
12. การปรับตัวให้เข้ากับสถานการณ์ที่เปลี่ยนแปลงเป็นประจำ

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

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

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

มี 7 หลักการของลีน:

1. กำจัดของเสีย
2. สร้างคุณภาพใน
3. สร้างความรู้ (ขยายการเรียนรู้)
4. เลื่อนความมุ่งมั่น (ตัดสินใจช้าที่สุด)
5. จัดส่งให้เร็วที่สุด
6. เคารพผู้คน (เพิ่มพลังให้ทีม)
7. เพิ่มประสิทธิภาพทั้งหมด

นอกเหนือจาก Agile แล้ว หลักการแบบ Lean ยังสนับสนุนความคิดและการมุ่งเน้นที่การทำสิ่งที่ถูกต้อง ในขณะเดียวกันก็มีความยืดหยุ่นในระหว่างกระบวนการทั้งหมด

เมื่อทีมพัฒนาซอฟต์แวร์นำ Agile และ Lean มาใช้แล้ว ก็ต้องใช้เวลาอีกเพียงขั้นตอนเดียวในการนำหลักการทั้งชุดมาใช้กับไอทีโดยรวม ซึ่งท้ายที่สุดก็นำเราไปสู่ ​​DevOps!

เข้าสู่ DevOps - ทางหลวงสามเลน

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

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

Gene Kim เป็นผู้ให้คำอธิบายที่ดีที่สุดเกี่ยวกับโซลูชัน DevOps และหากคุณยังไม่ได้อ่าน The Phoenix Project ฉันขอแนะนำให้คุณใช้เวลาสักครู่แล้วลงมือทำ

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

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

• เลนที่หนึ่ง - ประสิทธิภาพของระบบโดยรวมเป็นจุดโฟกัสหลัก และเน้นที่ประสิทธิภาพของแต่ละองค์ประกอบของระบบ

• ช่องทางที่สอง - ตรวจสอบให้แน่ใจว่ามีการวนรอบป้อนกลับคงที่ที่ส่งต้นน้ำและไม่ถูกละเลย

• ช่องทางที่สาม - ฝึกฝนการทดลอง ปรับปรุงอย่างต่อเนื่อง และล้มเหลวอย่างรวดเร็ว

เลนหนึ่ง - เร่งความเร็ว

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

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

ตรวจสอบให้แน่ใจว่างานไม่สะดุดไม่เพียงพอ องค์กรที่มีประสิทธิผลควรพยายามเพิ่มการไหลอยู่เสมอ มีวิธีการมากมายในการเพิ่มการไหล คุณสามารถหาวิธีแก้ปัญหาได้ใน Theory Of Constraints, Six Sigma, Lean หรือ Toyota Production System อย่าลังเลที่จะเลือกสิ่งเหล่านี้ คิดขึ้นมาเอง หรือรวมเข้าด้วยกัน

หลักการ DevOps ไม่สนใจว่าคุณจะอยู่ในทีมใด หากคุณเป็น System Architect, DBA, QA หรือผู้ดูแลระบบเครือข่าย กฎเดียวกันนี้ใช้กับทุกคน และทุกคนต้องปฏิบัติตามหลักการง่ายๆ สองประการ:

• ให้การไหลของระบบไม่ขาดตอน
• เพิ่มและเพิ่มประสิทธิภาพเวิร์กโฟลว์ตลอดเวลา

เลนที่สอง - เกียร์ขึ้น

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

อย่างไรก็ตาม DevOps ไม่ใช่ Utopia และหากเป็นไปได้ในการจัดส่งแบบทางเดียว วิธีการแบบ Waterfall ก็เพียงพอแล้ว การประเมินสิ่งที่ส่งมอบและการสื่อสารถึงขั้นตอนเป็นสิ่งสำคัญมากในการประกันคุณภาพ ช่องทางการสื่อสาร "ต้นน้ำ" ช่องแรกที่ต้องดำเนินการคือ Ops to Dev

การไฮไฟว์ให้ตัวเองเป็นเรื่องง่าย แต่การขอความคิดเห็นและการให้คำติชมเป็นวิธีที่จะได้เห็นภาพจริง จำเป็นที่ดาวน์สตรีมขั้นตอนเล็ก ๆ แต่ละขั้นตามด้วยการยืนยันต้นน้ำทันที

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

เลนสาม - วาร์ป 10

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

แต่ก่อนที่คุณจะเริ่มรวมการเคลื่อนไหว คุณจำเป็นต้องเชี่ยวชาญแต่ละขั้นตอนก่อน

“สิ่งที่เหมาะสมสำหรับอาจารย์ไม่เหมาะกับสามเณร คุณต้องเข้าใจเต๋าก่อนที่จะก้าวข้ามโครงสร้าง”

DevOps Third Way/Fast Lane รวมถึงการจัดสรรเวลาสำหรับการทดสอบอย่างต่อเนื่องในแต่ละวัน ให้รางวัลแก่ทีมอย่างต่อเนื่องสำหรับการเสี่ยงภัย และการแนะนำข้อผิดพลาดเข้าสู่ระบบเพื่อเพิ่มความยืดหยุ่น

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

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

สรุป - รายการตรวจสอบองค์กร DevOps

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

• ไม่มีกำแพงกั้นระหว่างทีมพัฒนาและทีมปฏิบัติการ ทั้งสองเป็นส่วนหนึ่งของกระบวนการเดียวกัน
• งานที่ส่งจากทีมหนึ่งไปยังอีกทีมหนึ่งได้รับการตรวจสอบและคุณภาพสูงสุดเสมอ
• ไม่มี "งานซ้อน" และปัญหาคอขวดทั้งหมดจะได้รับการจัดการ
• ทีมพัฒนาไม่ได้ใช้เวลา Operations สำหรับกิจกรรมเนื่องจากการปรับใช้และการบำรุงรักษาเป็นส่วนหนึ่งของกล่องเวลาเดียวกัน
• ทีมพัฒนาไม่ส่งรหัสสำหรับการปรับใช้เวลา 17.00 น. ในวันศุกร์ ทำให้ฝ่ายปฏิบัติการต้องทำความสะอาดงานในช่วงสุดสัปดาห์
• สภาพแวดล้อมการพัฒนาได้รับการกำหนดมาตรฐาน และการดำเนินงานสามารถทำซ้ำและปรับขนาดให้เป็นการผลิตได้อย่างง่ายดาย
• ทีมพัฒนาสามารถส่งมอบเวอร์ชันใหม่ได้ตามความเหมาะสมและการดำเนินการต่างๆ สามารถนำไปใช้ในการผลิตจริงได้อย่างง่ายดาย
• มีเส้นการสื่อสารที่ชัดเจนระหว่างทุกทีม
• สมาชิกในทีมทุกคนมีเวลาทดลองและปรับปรุงระบบ
• มีการแนะนำข้อบกพร่อง (หรือจำลอง) และจัดการในระบบเป็นประจำ บทเรียนที่เรียนรู้จากการทดลองแต่ละครั้งจะได้รับการบันทึกและแบ่งปันกับผู้ที่เกี่ยวข้องทั้งหมด การจัดการเหตุการณ์เป็นกิจวัตรและส่วนใหญ่จัดการในลักษณะที่ทราบกันดีอยู่แล้ว

บทสรุป

การใช้ เครื่องมือ DevOps ที่ทันสมัย ​​เช่น Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS เป็นต้น ไม่ได้หมายความว่าคุณกำลังใช้หลักการ DevOps DevOps เป็นวิธีการคิด เราทุกคนล้วนเป็นส่วนหนึ่งของกระบวนการเดียวกัน เราแบ่งปันเวลาเดียวกันและส่งมอบคุณค่าร่วมกัน ทุกคนที่มีส่วนร่วมในกระบวนการจัดส่งซอฟต์แวร์สามารถเร่งหรือลดความเร็วทั้งระบบได้ ข้อผิดพลาดที่เกิดขึ้นระหว่างการพัฒนาอาจทำให้ระบบล่มได้ เช่นเดียวกับการกำหนดค่าไฟร์วอลล์ที่ไม่ถูกต้อง

ทุกคนเป็นส่วนหนึ่งของ DevOps และเมื่อองค์กรของคุณเข้าใจแล้ว กองเครื่องมือและเทคโนโลยีที่จะช่วยคุณจัดการก็จะปรากฏขึ้นมาอย่างน่าอัศจรรย์