ประวัติย่อของเวลา
เพื่อที่จะเข้าใจ DevOps เราต้องย้อนเวลากลับไปสู่ยุคเก่าเมื่อไม่มีอะไรนอกจากโปรแกรมเมอร์
ในฐานะที่เป็น เต๋า สอนเรา:
โปรแกรมเมอร์สมัยก่อนลึกลับและลึกซึ้ง เราไม่สามารถเข้าใจความคิดของพวกเขาได้ดังนั้นสิ่งที่เราทำคืออธิบายรูปลักษณ์ของพวกเขา:
- รู้เหมือนสุนัขจิ้งจอกข้ามน้ำ
- แจ้งเตือนเหมือนนายพลในสนามรบ
- ใจดีเหมือนพนักงานต้อนรับต้อนรับแขกของเธอ
- เรียบง่ายเหมือนบล็อกไม้ที่ไม่ได้เจียระไน
- ขุ่นเหมือนแอ่งน้ำสีดำในถ้ำที่มืดมิด
โปรแกรมเมอร์ให้กำเนิดภาษาเครื่อง ภาษาเครื่องให้กำเนิดแอสเซมเบลอร์ แอสเซมเบลอร์ให้กำเนิดคอมไพเลอร์ ตอนนี้มีหลายพันภาษา แต่ละภาษามีจุดประสงค์ไม่ว่าจะต่ำต้อย แต่ละภาษาแสดงออกถึงหยินและหยางของซอฟต์แวร์ แต่ละภาษามีสถานที่ภายในซอฟต์แวร์
ในเวลานั้นสำนักงานพัฒนาซอฟต์แวร์ส่วนใหญ่เรียกว่าห้องทดลองและโปรแกรมเมอร์เป็นนักวิทยาศาสตร์ ในการสร้างแอปพลิเคชันที่ดีโปรแกรมเมอร์ต้องเข้าใจปัญหาที่แอปพลิเคชันกำลังแก้ปัญหาอย่างเต็มที่ พวกเขาต้องรู้ว่าจะนำแอปพลิเคชันไปใช้ที่ใดและจะใช้ระบบประเภทใด โดยพื้นฐานแล้วโปรแกรมเมอร์รู้ทุกอย่างเกี่ยวกับแอปพลิเคชันของตนตั้งแต่ข้อกำหนดการพัฒนาจนถึงการปรับใช้และการสนับสนุน
จากนั้นธรรมชาติของมนุษย์ก็เริ่มเข้ามาและเราก็เริ่มถามหามากขึ้น ความเร็วมากขึ้นคุณสมบัติมากขึ้นผู้ใช้มากขึ้นทุกอย่างมากขึ้น
การเป็นสิ่งมีชีวิตที่สงบเสงี่ยมเจียมตัวและสงบสุขโปรแกรมเมอร์จึงมีโอกาสน้อยมากที่จะอยู่รอดจากผู้ใช้ที่ยากไร้เช่นนี้มักจะขอเพิ่ม โอกาสที่ดีที่สุดที่จะชนะคือการเริ่มพัฒนาไปในทิศทางที่แตกต่างกันและสร้างวรรณะ ในไม่ช้าโปรแกรมเมอร์ก็สูญพันธุ์ไปในฐานะบรรพบุรุษของสายพันธุ์ใหม่ที่เรียกว่านักพัฒนาวิศวกรซอฟต์แวร์ผู้ดูแลระบบเครือข่ายนักพัฒนาฐานข้อมูลนักพัฒนาเว็บสถาปนิกระบบวิศวกร QA และอื่น ๆ อีกมากมาย การเปลี่ยนแปลงอย่างรวดเร็วและการปรับตัวให้เข้ากับความท้าทายจากโลกภายนอกกลายเป็นส่วนหนึ่งของดีเอ็นเอของพวกเขา วรรณะใหม่สามารถพัฒนาได้ในเวลาไม่กี่สัปดาห์ นักพัฒนาเว็บกลายเป็นนักพัฒนาแบ็คเอนด์นักพัฒนาฟรอนต์เอนด์นักพัฒนา PHP นักพัฒนารูบี้นักพัฒนาแองกูลาร์…ทุกอย่างจะต้องตกนรก
ในไม่ช้าพวกเขาก็ลืมไปว่าพวกเขามาจากพ่อคนเดียวกันคือโปรแกรมเมอร์ นักวิทยาศาสตร์ที่เรียบง่ายและสงบสุขที่ต้องการทำให้โลกนี้น่าอยู่ขึ้น พวกเขาเริ่มต่อสู้กันโดยอ้างว่าพวกเขาแต่ละคนเป็นลูกหลานที่แท้จริงของ“ The Programmer” และเลือดของพวกเขาบริสุทธิ์มากกว่าคนอื่น ๆ
เมื่อเวลาผ่านไปพวกเขาลดการมีปฏิสัมพันธ์ให้เหลือน้อยที่สุดและพูดคุยกันเมื่อจำเป็นจริงๆเท่านั้น พวกเขาหยุดเฉลิมฉลองความสำเร็จของสมาชิกในครอบครัวที่ห่างไกลกันและในที่สุดก็หยุดส่งโปสการ์ดทุกๆครั้ง
หากพวกเขาค้นหาเพียงความรู้สึกของพวกเขาพวกเขาจะพบว่าจุดประกายของโปรแกรมเมอร์อยู่ในใจพวกเขารอคอยที่จะส่องแสงและนำสันติสุขมาสู่กาแลคซี
ในการแข่งขันที่เห็นแก่ตัวและเห็นแก่ตัวเพื่อยึดครองโลกลูกหลานของโปรแกรมเมอร์ลืมจุดประสงค์ในการทำงานนั่นคือการแก้ปัญหาให้กับลูกค้า ลูกค้าเริ่มรู้สึกเจ็บปวดจากพฤติกรรมเช่นโครงการล่าช้าแพงเกินไปหรือแม้กระทั่งล้มเหลว
ทุกๆครั้งที่ดาวสว่างจะส่องแสงและใครบางคนจะได้รับแรงบันดาลใจที่จะพยายามสร้างสันติภาพท่ามกลาง The Descendants พวกเขามากับน้ำตก นี่เป็นแนวคิดที่ยอดเยี่ยมเนื่องจากใช้ความจริงที่ว่านักพัฒนากลุ่มต่างๆสื่อสารกันเมื่อจำเป็นเท่านั้น เมื่อกลุ่มหนึ่งทำงานเสร็จแล้วกลุ่มหนึ่งจะสื่อสารกับกลุ่มถัดไปเพื่อส่งงานผ่านกระบวนการและไม่หันกลับมามองอีก
สิ่งนี้ใช้งานได้ระยะหนึ่ง แต่ตามปกติมนุษย์ (ลูกค้า) ต้องการมากขึ้นอีกครั้ง พวกเขาต้องการมีส่วนร่วมมากขึ้นในกระบวนการทั้งหมดในการสร้างซอฟต์แวร์แสดงความคิดเห็นบ่อยขึ้นและขอให้มีการเปลี่ยนแปลงแม้ว่าจะสายเกินไป
โครงการซอฟต์แวร์มีแนวโน้มที่จะล้มเหลวมากจนได้รับการยอมรับว่าเป็นมาตรฐานอุตสาหกรรม สถิติพบว่ากว่า 50% ของโครงการล้มเหลวและดูเหมือนว่าไม่มีอะไรต้องทำ ( ZDNet , CNet )
ทุกรุ่นมีบุคคลที่เปิดกว้างไม่กี่คนที่รู้ว่ากลุ่มนักพัฒนาเหล่านี้ต้องหาวิธีทำงานร่วมกันสื่อสารและมีความยืดหยุ่นเพื่อให้มั่นใจว่าลูกค้าจะได้รับโซลูชันที่ดีที่สุดเท่าที่จะเป็นไปได้ มีร่องรอยของความพยายามเหล่านี้ตั้งแต่ต้นปี 2500 โดยเพื่อนร่วมงานของ John Von Neumann ผู้ยิ่งใหญ่ อย่างไรก็ตามเราต้องรอจนถึงต้นปี 2544 เพื่อเริ่มการปฏิวัติเมื่อโหลสกปรกสร้างแถลงการณ์แบบว่องไว
Agile Manifesto ตั้งอยู่บนหลักการสิบสองประการ:
- ความพึงพอใจของลูกค้าด้วยการส่งมอบซอฟต์แวร์ที่มีคุณค่าอย่างต่อเนื่องและรวดเร็ว
- ยินดีต้อนรับความต้องการที่เปลี่ยนแปลงแม้จะอยู่ในช่วงการพัฒนา
- มีการส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อย (หลายสัปดาห์แทนที่จะเป็นเดือน)
- ความร่วมมือระหว่างนักธุรกิจและนักพัฒนาอย่างใกล้ชิดทุกวัน
- โครงการสร้างขึ้นจากบุคคลที่มีแรงบันดาลใจซึ่งควรได้รับความไว้วางใจ
- การสนทนาแบบเห็นหน้าเป็นรูปแบบการสื่อสารที่ดีที่สุด (ตำแหน่งร่วม)
- ซอฟต์แวร์ที่ใช้งานได้คือตัวชี้วัดความก้าวหน้าที่สำคัญ
- การพัฒนาที่ยั่งยืนสามารถรักษาก้าวอย่างต่อเนื่อง
- ใส่ใจอย่างต่อเนื่องในความเป็นเลิศทางเทคนิคและการออกแบบที่ดี
- ความเรียบง่าย - ศิลปะในการเพิ่มปริมาณงานที่ไม่ได้ทำ - เป็นสิ่งสำคัญ
- จัดทีมด้วยตนเอง
- การปรับตัวให้เข้ากับสถานการณ์ที่เปลี่ยนแปลงเป็นประจำ
Agile manifesto เป็นก้าวแรกที่ยิ่งใหญ่ในการนำสันติภาพมาสู่ Galaxy และคืนความสมดุลให้กับ Force เป็นครั้งแรกในระยะเวลาอันยาวนานที่การเชื่อมโยงผู้มีส่วนได้ส่วนเสียทั้งหมดในกระบวนการพัฒนาซอฟต์แวร์ขึ้นอยู่กับวิถีทางวัฒนธรรมและ 'มนุษย์' เช่นเดียวกับขั้นตอนและวิธีการที่ใช้เครื่องจักร ผู้คนเริ่มพูดคุยกันพบปะกันเป็นประจำและแลกเปลี่ยนความคิดเห็นและความคิดเห็นตลอดเวลา พวกเขาตระหนักว่าพวกเขามีอะไรที่เหมือนกันมากกว่าที่พวกเขาคิดและลูกค้าก็กลายเป็นส่วนหนึ่งของทีมไม่ใช่แค่ปัจจัยภายนอกบางอย่างเท่านั้นที่คาดว่าจะส่งเงินและไม่ถามคำถามใด ๆ
ยังมีอุปสรรคอีกเล็กน้อยที่ต้องเอาชนะ แต่อนาคตดูสดใสกว่าที่เคย ความคล่องตัวหมายถึงการเปิดกว้างและเต็มใจที่จะปรับตัวให้เข้ากับการเปลี่ยนแปลงอย่างต่อเนื่อง อย่างไรก็ตามด้วยการเปลี่ยนแปลงที่มากเกินไปจึงเป็นเรื่องยากที่จะมุ่งเน้นไปที่เป้าหมายสูงสุดและการส่งมอบ และนั่นคือวิธีที่การพัฒนาซอฟต์แวร์แบบลีนมีชีวิตขึ้นมา
ติดยาเสพติด LSD (ตั้งใจเล่นสำนวน) และเสี่ยงต่อการถูกเนรเทศและถูกขับไล่ลูกหลานบางคนมองหาแนวทางแก้ไขนอกวรรณะและอุตสาหกรรมซอฟต์แวร์ พวกเขาพบความรอดในผลงานของผู้ผลิตรถยนต์รายใหญ่ ระบบการผลิตของโตโยต้า น่าทึ่งในความเรียบง่ายและเห็นได้ชัดว่า การผลิตแบบลีน สามารถนำไปใช้กับการพัฒนาซอฟต์แวร์ได้อย่างง่ายดาย
หลักการลีนมี 7 ประการ:
- กำจัดของเสีย
- สร้างคุณภาพใน
- สร้างความรู้ (ขยายการเรียนรู้)
- เลื่อนความมุ่งมั่น (ตัดสินใจให้ช้าที่สุด)
- จัดส่งให้เร็วที่สุด
- เคารพผู้คน (เพิ่มพลังให้ทีม)
- เพิ่มประสิทธิภาพทั้งหมด
นอกเหนือจาก Agile แล้วหลักการแบบ Lean สนับสนุนความคิดและการมุ่งเน้นไปที่การทำสิ่งที่ถูกต้องในขณะที่มีความยืดหยุ่นในระหว่างกระบวนการทั้งหมด
เมื่อเปรียวและลีน ถูกนำมาใช้โดยทีมพัฒนาซอฟต์แวร์ใช้เวลาอีกเพียงขั้นเดียวในการนำหลักการทั้งหมดมาใช้กับ IT as a Whole ซึ่งในที่สุดก็นำเราไปสู่ DevOps!
เข้าสู่ DevOps - ทางหลวงสามเลน
มุมมองของทีมพัฒนาซอฟต์แวร์ในโรงเรียนเก่า ได้แก่ นักวิเคราะห์ธุรกิจสถาปนิกระบบนักพัฒนาส่วนหน้านักพัฒนาส่วนหลังผู้ทดสอบและอื่น ๆ การเพิ่มประสิทธิภาพกระบวนการพัฒนาซอฟต์แวร์รวมถึงหลักการที่คล่องตัวและแบบลีนส่วนใหญ่มุ่งเน้นไปที่สิ่งเหล่านี้ เมื่อแอปพลิเคชัน“ พร้อมใช้งานจริง” แอปพลิเคชันจะถูกส่งไปยัง“ ฝ่ายปฏิบัติการ” ซึ่งรวมถึงวิศวกรระบบวิศวกรรุ่น DBA วิศวกรเครือข่ายผู้เชี่ยวชาญด้านความปลอดภัย ฯลฯ การลบกำแพงใหญ่ระหว่าง Dev และ Ops เป็นแรงผลักดันหลักของ DevOps .
DevOps เป็นผลมาจากการนำหลักการแบบลีนไปใช้กับกระแสมูลค่าไอทีทั้งหมด กระแสมูลค่าไอทีขยายการพัฒนาไปสู่การผลิตโดยรวม 'ญาติห่าง ๆ ' ทั้งหมดที่สืบเชื้อสายมาจากโปรแกรมเมอร์ดั้งเดิม
คำอธิบายที่ดีที่สุดของ โซลูชัน DevOps ให้โดย ยีนคิม และหากคุณยังไม่ได้อ่าน โครงการฟีนิกซ์ ฉันขอแนะนำให้คุณใช้เวลาและทำมัน
คุณไม่ควรจ้างวิศวกร DevOps และ DevOps ไม่ควรเป็นแผนกใหม่ในไอทีของคุณ DevOps เป็นวัฒนธรรมความคิดและเป็นส่วนหนึ่งของ IT as the Whole ไม่มีเครื่องมือใดที่จะทำให้ไอทีของคุณเป็น องค์กร DevOps และไม่มีระบบอัตโนมัติในระดับใดที่จะช่วยให้ทีมของคุณสามารถส่งมอบคุณค่าสูงสุดให้กับลูกค้าของคุณได้
DevOps มักเรียกว่าวิธีการสามทาง แต่ฉันเห็นว่าเป็นสามเลนของทางหลวงเดียวกัน คุณเริ่มในเลนที่หนึ่งจากนั้นคุณจะเร่งความเร็วและเปลี่ยนไปเลนสองและในที่สุดคุณก็เร่งความเร็วในเลนที่สาม
-
เลนที่หนึ่ง - ประสิทธิภาพของระบบโดยรวมเป็นจุดโฟกัสหลักและจะเน้นที่ประสิทธิภาพขององค์ประกอบใด ๆ ของระบบ
-
ช่องทางที่สอง - ตรวจสอบให้แน่ใจว่ามีการวนรอบข้อเสนอแนะคงที่ที่ส่งไปทางต้นน้ำและไม่ถูกละเลย
-
เลนที่สาม - ดูแลการทดลองปรับปรุงอย่างต่อเนื่องและล้มเหลวอย่างรวดเร็ว
เลนที่หนึ่ง - เร่งความเร็ว
การทำความเข้าใจความสำคัญของทั้งระบบและการจัดลำดับความสำคัญของรายการงานอย่างถูกต้องเป็นสิ่งแรกที่องค์กรไอทีต้องเรียนรู้เมื่อนำหลักการของ DevOps มาใช้ ไม่มีใครในสายธารคุณค่าไอทีได้รับอนุญาตให้สร้างคอขวดและลดขั้นตอนการทำงาน
การดูแลให้ขั้นตอนการทำงานไม่สะดุดเป็นเป้าหมายสูงสุดสำหรับทุกคนที่รวมอยู่ในกระบวนการนี้ ไม่ว่าบุคคลหรือทีมจะมีบทบาทอย่างไรก็จำเป็นที่พวกเขาจะต้องพยายามบรรลุเป้าหมาย ความเข้าใจอย่างลึกซึ้งเกี่ยวกับระบบ . การใช้วิธีคิดแบบนี้มีผลโดยตรงต่อคุณภาพเนื่องจากข้อบกพร่องจะไม่ถูกส่งไปตามกระแสเพราะจะทำให้เกิดปัญหาคอขวด
การตรวจสอบให้แน่ใจว่าการทำงานไม่หยุดชะงักนั้นไม่เพียงพอ องค์กรที่มีประสิทธิผลควรพยายามเพิ่มกระแสอยู่เสมอ มีวิธีการมากมายในการเพิ่มการไหล คุณสามารถค้นหาวิธีแก้ปัญหาได้ใน ทฤษฎีข้อ จำกัด , ซิกซ์ซิกม่า , ระบบการผลิตแบบ Lean หรือ Toyota อย่าลังเลที่จะเลือกสิ่งเหล่านี้สร้างขึ้นเองหรือรวมเข้าด้วยกัน
หลักการ DevOps ไม่สนใจว่าคุณจะอยู่ในทีมใดถ้าคุณเป็น System Architect, DBA, QA หรือผู้ดูแลระบบเครือข่าย กฎเดียวกันนี้ใช้กับทุกคนและทุกคนต้องปฏิบัติตามหลักการง่ายๆสองข้อ:
- ให้ระบบไหลไม่สะดุด
- เพิ่มและเพิ่มประสิทธิภาพเวิร์กโฟลว์ตลอดเวลา
เลนสอง - เกียร์ขึ้น
การไหลของระบบอย่างต่อเนื่องเป็นทิศทางเดียวและคาดว่าจะเปลี่ยนจากการพัฒนาไปสู่การปฏิบัติงาน ในโลกแห่งอุดมคติหมายความว่าซอฟต์แวร์ถูกสร้างขึ้นอย่างรวดเร็วด้วยคุณภาพสูงนำไปใช้ในการผลิตและส่งมอบคุณค่าให้กับลูกค้า
อย่างไรก็ตาม DevOps ไม่ใช่ Utopia และหากการส่งแบบทิศทางเดียวเป็นไปได้วิธีการ Waterfall ก็เพียงพอแล้ว การประเมินสิ่งที่ส่งมอบและการสื่อสารถึงโฟลว์เป็นสิ่งสำคัญมากในการรับประกันคุณภาพ ช่องทางการสื่อสาร 'ต้นน้ำ' ช่องแรกที่ต้องดำเนินการคือ Ops ถึง Dev
เริ่มต้นกับ angular js
การให้คะแนนสูงแก่ตัวเองเป็นเรื่องง่าย แต่การขอความคิดเห็นและการให้ข้อเสนอแนะเป็นวิธีที่จะเห็นภาพจริง มีความจำเป็นที่แต่ละขั้นตอนเล็ก ๆ จะต้องตามด้วยการยืนยันต้นน้ำทันที
ไม่สำคัญว่าคุณจะสร้างลูปคำติชมอย่างไร คุณสามารถเชิญนักพัฒนาเข้าร่วมการประชุมทีมสนับสนุนหรือนำผู้ดูแลระบบเครือข่ายมาร่วมวางแผนการวิ่งรายสัปดาห์ ตราบใดที่ความคิดเห็นของคุณยังคงอยู่และมีการรับและจัดการความคิดเห็นองค์กรของคุณกำลังเร่งดำเนินการตามทางหลวง DevOps
เลนที่สาม - วิปริต 10
DevOps Fast Lane ไม่เหมาะสำหรับคนอ่อนแอ หากต้องการเข้าสู่ช่องทางที่รวดเร็วของ DevOps องค์กรของคุณต้องมีวุฒิภาวะเพียงพอ ทุกอย่างเกี่ยวกับการเสี่ยงและเรียนรู้จากความล้มเหลวทดลองอย่างต่อเนื่องและยอมรับว่าการทำซ้ำและการฝึกฝนเป็นสิ่งที่จำเป็นสำหรับการเรียนรู้ บ่อยครั้งที่คุณจะได้ยินคำนี้ คำ และนี่คือเหตุผล การฝึกฝนอย่างต่อเนื่องและการทำซ้ำจะนำไปสู่ความเชี่ยวชาญเพราะมันทำให้การเคลื่อนไหวที่ซับซ้อนกลายเป็นกิจวัตร
แต่ก่อนที่คุณจะเริ่มรวมท่าต่างๆคุณจำเป็นต้องเชี่ยวชาญในแต่ละขั้นตอนก่อน
“ สิ่งที่เหมาะสมสำหรับอาจารย์ไม่เหมาะสำหรับมือใหม่ คุณต้องเข้าใจเต่าก่อนที่จะก้าวข้ามโครงสร้าง”
DevOps Third Way / Fast Lane รวมถึงการจัดสรรเวลาสำหรับการทดลองอย่างต่อเนื่องในแต่ละวันให้รางวัลแก่ทีมอย่างต่อเนื่องสำหรับการรับความเสี่ยงและแนะนำข้อผิดพลาดในระบบเพื่อเพิ่มความยืดหยุ่น
เพื่อให้มั่นใจได้ว่าองค์กรของคุณจะไม่ระเบิดเมื่อใช้มาตรการเหล่านี้คุณต้องสร้างข้อเสนอแนะที่เกิดขึ้นบ่อยครั้งระหว่างทุกทีมในขณะที่ตรวจสอบให้แน่ใจว่าคอขวดทั้งหมดมีความชัดเจนและการไหลเวียนของระบบไม่สะดุด
การใช้มาตรการเหล่านี้ทำให้องค์กรของคุณตื่นตัวตลอดเวลาและสามารถตอบสนองต่อความท้าทายได้อย่างรวดเร็วและมีประสิทธิผล
สรุป - รายการตรวจสอบองค์กร DevOps
นี่คือรายการตรวจสอบที่คุณสามารถใช้เพื่อตรวจสอบความถูกต้องได้ เปิดใช้งาน DevOps องค์กรไอทีของคุณคือ โปรดอย่าลังเลที่จะแสดงความคิดเห็นในบทความและเพิ่มคะแนนของคุณเอง
- ไม่มีกำแพงระหว่างทีมพัฒนาและทีมปฏิบัติการ ทั้งสองเป็นส่วนหนึ่งของกระบวนการเดียวกัน
- งานที่ส่งจากทีมหนึ่งไปยังอีกทีมจะได้รับการตรวจสอบและมีคุณภาพสูงสุดเสมอ
- ไม่มีการ 'ซ้อน' ของงานและมีการจัดการปัญหาคอขวดทั้งหมด
- ทีมพัฒนาไม่ได้ใช้เวลาปฏิบัติการสำหรับกิจกรรมของตนเนื่องจากการปรับใช้และการบำรุงรักษาเป็นส่วนหนึ่งของกล่องเวลาเดียวกัน
- ทีมพัฒนาไม่ส่งมอบรหัสสำหรับการปรับใช้เวลา 17.00 น. ของวันศุกร์ออกจากการดำเนินงานเพื่อสะสางงานในช่วงสุดสัปดาห์
- สภาพแวดล้อมการพัฒนาเป็นมาตรฐานและการดำเนินงานสามารถทำซ้ำและปรับขนาดเป็นการผลิตได้อย่างง่ายดาย
- ทีมพัฒนาสามารถส่งมอบเวอร์ชันใหม่ได้ตามความเหมาะสมและการดำเนินการสามารถปรับใช้ในการผลิตได้อย่างง่ายดาย
- มีสายสื่อสารที่ชัดเจนระหว่างทุกทีม
- สมาชิกในทีมทุกคนมีเวลาทดลองและปรับปรุงระบบ
- มีการนำข้อบกพร่อง (หรือการจำลอง) มาใช้และจัดการในระบบเป็นประจำ บทเรียนที่ได้รับจากการทดลองแต่ละครั้งจะได้รับการจัดทำเป็นเอกสารและแบ่งปันกับผู้ที่เกี่ยวข้องทั้งหมด การจัดการเหตุการณ์เป็นกิจวัตรและส่วนใหญ่จัดการด้วยวิธีที่ทราบกันดี
สรุป
โดยใช้ความทันสมัย เครื่องมือ DevOps เช่น Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS เป็นต้นไม่ได้หมายความว่าคุณกำลังใช้หลักการ DevOps DevOps คือวิธีคิด เราทุกคนเป็นส่วนหนึ่งของกระบวนการเดียวกันเราแบ่งปันเวลาเดียวกันและส่งมอบคุณค่าร่วมกัน ทุกคนที่มีส่วนร่วมในกระบวนการส่งมอบซอฟต์แวร์สามารถเร่งหรือชะลอระบบทั้งหมดได้ จุดบกพร่องที่สร้างขึ้นระหว่างการพัฒนาอาจทำให้ระบบล่มรวมทั้งการกำหนดค่าไฟร์วอลล์ที่ไม่ถูกต้อง
ทุกคนเป็นส่วนหนึ่งของ DevOps และเมื่อองค์กรของคุณเข้าใจแล้วเครื่องมือและเทคโนโลยีที่จะช่วยคุณจัดการก็จะปรากฏขึ้นอย่างน่าอัศจรรย์
ที่เกี่ยวข้อง: Bridging Gaps: ความสำคัญของการสื่อสาร DevOps
