การแยก Buzz ออกจาก Bull: สิ่งที่ไม่ควรทำให้เป็นอัตโนมัติ

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

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

รายงานล่าสุดจาก Red Hat พบว่าบริษัทต่าง ๆ ดำเนินการระบบคลาวด์โดยอัตโนมัติโดยเฉลี่ย 36% ยิ่งก่อตั้งธุรกิจนานขึ้นเท่าใด กระบวนการที่ต้องทำด้วยตัวเองก็ยิ่งถูกแทนที่ด้วยเวิร์กโฟลว์อัตโนมัติมากขึ้นเท่านั้น

มีเหตุผลหลายประการที่ทำให้ความนิยมในระบบอัตโนมัติเพิ่มขึ้น:

• บริษัทต่างๆ ต้องการให้การดำเนินการพัฒนามุ่งเน้นไปที่ภารกิจที่สำคัญยิ่ง
• ความปรารถนาที่จะเร่งไทม์ไลน์สำหรับการเผยแพร่
• ผู้นำต้องการความคล่องตัวและการทำงานร่วมกันจากทีมมากขึ้น
• ระบบแมนนวลมักจะเกิดข้อผิดพลาดจากมนุษย์ได้ง่าย
• มีความต้องการบทบาทด้าน IT, SRE และ DevOps มากกว่าที่จะมีคนมาเติมเต็ม

ระบบอัตโนมัติ – เป็นมากกว่าคำศัพท์?

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

Scott Sturgeon, CTO ของ Tugboat Logic by One Trust ไม่เชื่อ “จากมุมมองของฉัน ระบบอัตโนมัติกลายเป็นคำยอดนิยม ไม่ใช่ทุกอย่างจะเป็นไปโดยอัตโนมัติอย่างมีเหตุผล ไม่ใช่ทุกสิ่งที่ควรจะเป็น สิ่งที่ซ้ำซากและใช้เวลานานเป็นสิ่งที่ฉันมักจะให้ความสำคัญ ระบบอัตโนมัติส่วนใหญ่ที่คุณได้ยินเกี่ยวกับทุกวันนี้มาจาก CI/CD ซึ่งก็คือการผสานรวมอย่างต่อเนื่อง การปรับใช้อย่างต่อเนื่อง คุณสามารถสร้างไปป์ไลน์ที่ซับซ้อนมากซึ่งสามารถอัปเดตอินสแตนซ์การผลิตของคุณโดยอัตโนมัติ ซึ่งดีมากถ้าคุณพร้อมที่จะทำอย่างถูกต้อง”

“ฉันคิดว่าระบบอัตโนมัติเป็นคำทั่วไปและคุณต้องการเจาะจงมากขึ้นเกี่ยวกับสิ่งที่คุณต้องการ มันเป็นเทคนิคและวิธีการมากกว่าผลลัพธ์” Nigel Kersten, Field CTO ของ Puppet อธิบาย คุณไม่ได้ทำงานอัตโนมัติเพราะเห็นแก่การทำงานอัตโนมัติ คุณทำงานอัตโนมัติเพราะคุณพยายามบรรลุผลลัพธ์ ฉันยังคิดว่ามันเป็นคำศัพท์ทางการตลาดที่ดีเพราะมันสะท้อนกับกลุ่มคนที่คิดว่า 'ฉันทำให้หุ่นยนต์ทำได้' ดังนั้นคุณต้องระมัดระวังเกี่ยวกับวิธีที่คุณใช้คำนั้น”

เมื่อคำนึงถึงข้อควรระวังนี้ ต่อไปนี้คืองานหลักบางส่วนที่มัก ทำงานอัตโนมัติมากเกินไป หรือซับซ้อนโดยไม่จำเป็นโดยระบบอัตโนมัติ

สิ่ง ที่ไม่ ควรทำให้เป็นอัตโนมัติ

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

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

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

James Ciesielski ซีทีโอของ Rewind ขยายแนวทางตามความเสี่ยงนี้ไปสู่การพัฒนาระบบอัตโนมัติ “เมื่อต้องตัดสินใจว่าจะทำอะไรให้เป็นอัตโนมัติ เราประเมินความเสี่ยงของการมีคนที่เกี่ยวข้องในการดูแลกระบวนการ ฉันเคยเห็นสภาพแวดล้อมการพัฒนาที่ผู้คนได้รับสิทธิพิเศษเหมือนพระเจ้าในทีมพัฒนา บ่อยครั้งที่สิ่งนี้ทำในนามของการให้บริการลูกค้า แต่ผู้คนทำผิดพลาดโดยตั้งใจและไม่ตั้งใจ”

วิธีตัดสินใจว่าสิ่งใดต้องการระบบอัตโนมัติ

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

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

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

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

Lena Feygin หัวหน้าทีม DevOps ที่ OwnBackups เน้นย้ำถึงความระมัดระวังและความรอบคอบเหนือความปรารถนาที่จะ ': automate_all_the_things: ' คำแนะนำของเธอ? “ในท้ายที่สุด เราต้องการเพียงแค่ทำให้ปัญหาที่ทำให้เกิดปัญหาเป็นไปโดยอัตโนมัติเท่านั้น และไม่แก้ไขปัญหาที่ไม่มีอยู่จริง”

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