เร่งวงจรการเผยแพร่ด้วยเส้นทางสู่การใช้งาน: ตอนที่ 1 – บล็อกของ IBM

สำหรับหลายๆ องค์กร การเดินทางสู่ระบบคลาวด์จะช่วยลดต้นทุนหนี้ทางเทคนิคและบรรลุผลสำเร็จ CapEx-to-OpEx วัตถุประสงค์ ซึ่งรวมถึง การออกแบบสถาปัตยกรรมใหม่ ไปยัง microservices, ยกและเปลี่ยนการเปลี่ยนแพลตฟอร์ม การปรับโครงสร้างใหม่ การแทนที่ และอื่นๆ ดังการปฏิบัติเช่น DevOps, เมฆพื้นเมือง, serverless และ วิศวกรรมความน่าเชื่อถือของไซต์ (SRE) มุ่งเน้นไปที่การเปลี่ยนแปลงไปสู่ระดับที่สำคัญของระบบอัตโนมัติ ความเร็ว ความคล่องตัว และการจัดแนวธุรกิจกับไอที (ซึ่งช่วยให้ไอทีระดับองค์กรเปลี่ยนไปสู่องค์กรด้านวิศวกรรม)

องค์กรหลายแห่งพยายามดิ้นรนเพื่อให้ได้มาซึ่งคุณค่าที่แท้จริงจากการเดินทางบนคลาวด์ และอาจต้องใช้จ่ายเงินมากเกินไปต่อไป หลายรายการ นักวิเคราะห์ ได้รายงานว่าองค์กรมากกว่า 90% ยังคงใช้จ่ายมากเกินไปในระบบคลาวด์ โดยมักไม่ได้รับผลตอบแทนจำนวนมาก

แก่นแท้ของคุณค่าเกิดขึ้นเมื่อธุรกิจและไอทีสามารถทำงานร่วมกันเพื่อสร้างความสามารถใหม่ๆ ได้ด้วยความเร็วสูง ส่งผลให้ประสิทธิภาพการทำงานของนักพัฒนาเพิ่มมากขึ้นและความเร็วในการออกสู่ตลาด วัตถุประสงค์เหล่านั้นจำเป็นต้องมี รูปแบบการดำเนินงานเป้าหมาย. การปรับใช้แอปพลิเคชันบนคลาวด์อย่างรวดเร็วไม่เพียงแต่ต้องเร่งการพัฒนาด้วยการบูรณาการ การใช้งาน และการทดสอบอย่างต่อเนื่อง (CI/CD/CT) แต่ยังต้องการการเร่งวงจรชีวิตของห่วงโซ่อุปทาน ซึ่งเกี่ยวข้องกับกลุ่มอื่นๆ อีกหลายกลุ่ม เช่น ความเสี่ยงด้านการกำกับดูแลและการปฏิบัติตามข้อกำหนด (GRC) การจัดการการเปลี่ยนแปลง การดำเนินงาน ความยืดหยุ่น และความน่าเชื่อถือ องค์กรต่างๆ กำลังมองหาวิธีที่จะช่วยให้ทีมผลิตภัณฑ์สามารถย้ายจากแนวคิดไปสู่การใช้งานได้เร็วกว่าที่เคย

แนวทางที่เน้นระบบอัตโนมัติเป็นหลักและนำโดย DevSecOps

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

• สถาปัตยกรรมตามรูปแบบที่สร้างมาตรฐานให้กับสถาปัตยกรรมและกระบวนการออกแบบ (ในขณะที่ทีมมีอิสระในการเลือกรูปแบบและเทคโนโลยีหรือร่วมสร้างรูปแบบใหม่)
• รูปแบบที่ตอบสนองมิติด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด เพื่อให้มั่นใจว่าสามารถตรวจสอบย้อนกลับไปยังข้อกำหนดเหล่านี้ได้
• รูปแบบเป็นโค้ดที่ช่วยจัดรูปแบบข้อกังวลแบบ cross-cut หลายรายการ (ซึ่งยังส่งเสริมโมเดลแหล่งที่มาภายในของความสมบูรณ์ของรูปแบบและขับเคลื่อนการนำกลับมาใช้ใหม่)
• กิจกรรมที่ขับเคลื่อนด้วยไปป์ไลน์ DevOps ที่สามารถนำไปใช้ได้ตลอดวงจรชีวิต
• การสร้างข้อมูลเฉพาะโดยอัตโนมัติที่จำเป็นสำหรับการตรวจสอบความปลอดภัยและการปฏิบัติตามข้อกำหนด
• การทบทวนความพร้อมในการปฏิบัติงานโดยมีการแทรกแซงด้วยตนเองอย่างจำกัดหรือไม่มีเลย

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

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

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

เส้นทางสู่การใช้งาน: มุมมองและความท้าทายในปัจจุบัน

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

ความท้าทายที่สำคัญในลักษณะดั้งเดิมของ SDLC คือ:

1. ระยะเวลารอก่อนการพัฒนา 4-8 สัปดาห์ภายในขั้นตอนสถาปัตยกรรมและการออกแบบเพื่อเข้าสู่การพัฒนา สิ่งนี้เกิดจาก:
   • การตรวจสอบในระยะแรกหลายครั้งเพื่อให้แน่ใจว่าไม่มีผลกระทบเชิงลบทางธุรกิจ รวมถึงข้อกังวลด้านความเป็นส่วนตัว การจัดประเภทข้อมูล ความต่อเนื่องทางธุรกิจ และการปฏิบัติตามกฎระเบียบ (และส่วนใหญ่เป็นการดำเนินการด้วยตนเอง)
   • กระบวนการ SDLC ทั่วทั้งองค์กรที่ยังคงเป็นแบบน้ำตกหรือแบบกึ่งเปรียว โดยต้องมีการดำเนินการตามลำดับ แม้ว่าจะมีหลักการแบบ Agile ในวงจรการพัฒนาก็ตาม (เช่น การจัดเตรียมสภาพแวดล้อมหลังจากได้รับการอนุมัติการออกแบบเต็มรูปแบบแล้วเท่านั้น)
   • การใช้งานที่ถูกมองว่า “ไม่เหมือนใคร” จะต้องได้รับการตรวจสอบอย่างละเอียดและการแทรกแซงโดยมีโอกาสจำกัดในการเร่งความเร็ว
   • ความท้าทายในการจัดสถาปัตยกรรมและการพัฒนาตามรูปแบบให้เป็นสถาบัน เนื่องจากขาดความพยายามที่เหนียวแน่นและการเปลี่ยนแปลงการขับเคลื่อนของตัวแทน การกำหนดมาตรฐานดังกล่าว
   • วัฒนธรรมความปลอดภัยที่ส่งผลต่อความรวดเร็วของการพัฒนา โดยยึดมั่นในการควบคุมและแนวทางด้านความปลอดภัยซึ่งมักเกี่ยวข้องกับกระบวนการแบบแมนนวลหรือแบบกึ่งแมนนวล
2. เวลารอการพัฒนาเพื่อจัดเตรียมสภาพแวดล้อมและการรวมเครื่องมือ CI/CD/CT เนื่องจาก:
   • การจัดเตรียมสภาพแวดล้อมด้วยตนเองหรือกึ่งอัตโนมัติ
   • รูปแบบ (บนกระดาษ) เป็นแนวทางที่กำหนดเท่านั้น
   • เครื่องมือ DevOps ที่แยกส่วนซึ่งต้องใช้ความพยายามในการต่อเข้าด้วยกัน
3. เวลารอหลังการพัฒนา (ไมล์สุดท้าย) ก่อนเริ่มใช้งานจริงคือ 6–8 สัปดาห์หรือมากกว่านั้นอย่างง่ายดาย เนื่องจาก:
   • การรวบรวมหลักฐานด้วยตนเองเพื่อรับการตรวจสอบความปลอดภัยและการปฏิบัติตามข้อกำหนดที่เกินกว่ามาตรฐาน SAST/SCA/DAST (เช่น การกำหนดค่าความปลอดภัย การควบคุมวันที่ 2 การแท็ก และอื่นๆ)
   • การรวบรวมหลักฐานด้วยตนเองสำหรับการดำเนินการและการตรวจสอบความยืดหยุ่น (เช่น การสนับสนุนการดำเนินงานบนคลาวด์และความต่อเนื่องทางธุรกิจ)
   • การตรวจสอบการเปลี่ยนแปลงบริการเพื่อสนับสนุนบริการด้านไอทีและการจัดการเหตุการณ์และการแก้ไข

เส้นทางในการปรับใช้: สถานะเป้าหมาย

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

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

แผนภาพด้านล่างแสดงมุมมองเป้าหมายที่เป็นไปได้ของเส้นทางในการปรับใช้ ซึ่งช่วยรองรับโมเดล SDLC แบบคลาวด์เนทีฟ

องค์ประกอบสำคัญของโมเดล SDLC บนคลาวด์ ได้แก่:

• สถาปัตยกรรมและการออกแบบที่ขับเคลื่อนด้วยรูปแบบเป็นสถาบันทั่วทั้งองค์กร
• รูปแบบที่รวมข้อกำหนดที่สำคัญด้านความปลอดภัย การปฏิบัติตามข้อกำหนด ความยืดหยุ่น และนโยบายองค์กรอื่นๆ (เป็นโค้ด)
• การตรวจสอบความปลอดภัยและการปฏิบัติตามกฎระเบียบที่เร่งรัดเป็นรูปแบบและใช้เพื่ออธิบายโซลูชัน
• การพัฒนาหลัก รวมถึงการสร้างสภาพแวดล้อม ไปป์ไลน์ และการกำหนดค่าบริการ (ซึ่งขับเคลื่อนผ่านแค็ตตาล็อกองค์กรด้านวิศวกรรมแพลตฟอร์ม)
• ไปป์ไลน์ CI/CD/CT ที่สร้างการเชื่อมโยงไปยังกิจกรรมทั้งหมดตลอดเส้นทางเพื่อปรับใช้วงจรชีวิต
• วิศวกรรมแพลตฟอร์มสร้าง กำหนดค่า จัดการแพลตฟอร์มและบริการด้วยนโยบายองค์กรทั้งหมด (เช่น การเข้ารหัส) ที่ฝังอยู่ในนโยบายแพลตฟอร์ม
• เครื่องมือด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด (เช่น การสแกนช่องโหว่หรือการตรวจสอบนโยบาย) และระบบอัตโนมัติที่รวมอยู่ในไปป์ไลน์หรือพร้อมใช้งานในรูปแบบบริการตนเอง
• การสร้างข้อมูลระดับสูง (จากบันทึก ผลลัพธ์ของเครื่องมือ และข้อมูลเชิงลึกในการสแกนโค้ด) สำหรับการตรวจสอบหลายๆ ครั้งโดยไม่ต้องมีการแทรกแซงด้วยตนเอง
• ความสามารถในการตรวจสอบย้อนกลับตั้งแต่ Backlog ไปจนถึงบันทึกประจำรุ่นการปรับใช้งานและผลกระทบจากการเปลี่ยนแปลง
• การแทรกแซงโดยข้อยกเว้นเท่านั้น

เส้นทางในการปรับใช้การขับเคลื่อนการเร่งความเร็วผ่านความชัดเจน ความรับผิดชอบ และการตรวจสอบย้อนกลับ

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

อ่านส่วนที่ 2: การสำรวจโมเดลความสมบูรณ์และแนวทางการตระหนักรู้