รีวิว DevSecOps Transformation & Technologies — Skooldio (Part 3/3)

---

รีวิว DevSecOps Transformation & Technologies — Skooldio (Part 3/3)

พัฒนา Software อย่างมีประสิทธิภาพ ด้วย DevSecOps

Connect with me and follow our journey: Linkedin, Facebook

---

กลับมาพบกันอีกครั้งใน Part 3 ซึ่งเป็นตอนสุดท้ายของซีรีส์รีวิว DevSecOps Transformation & Technologies จาก Skooldio! หากยังไม่ได้อ่าน Part 1 และ Part 2 แนะนำให้ย้อนกลับไปอ่านก่อนเพื่อความต่อเนื่อง:

• Part 1: VSC, CI/CD และ Artifacts
• Part 2: Infrastructure, Monitoring และ Automation

ใน Part 3 นี้ เราจะพูดถึง วิธีเริ่มต้นทำ DevSecOps พร้อมกลยุทธ์ที่ช่วยให้ทีมงานและองค์กรสามารถนำ DevSecOps ไปปรับใช้ได้จริง

6. How to Start DevSecOps

Start with Why: เริ่มต้นด้วยคำถาม “ทำไม?”

การเริ่มต้นทำ DevSecOps ควรเริ่มจากการหา Pain Points ที่องค์กรกำลังเผชิญอยู่ ตัวอย่างเช่น:

• Test ผ่าน แต่ระบบ Production มีปัญหา
• Deploy ช้าเกินไป
• Bug เยอะ (Reliability ต่ำ)
• ระบบมีช่องโหว่ด้านความปลอดภัย (Security)
• ระบบล่มบ่อย และแก้ปัญหาได้ช้า

ยิ่งองค์กรมี Pain Points มากเท่าไหร่ การทำ DevSecOps ยิ่งสำคัญ!

Prerequisite: ความพร้อมก่อนเริ่ม DevSecOps

ก่อนจะเริ่มทำ DevSecOps คุณต้องเช็คความพร้อมใน 4 ด้านหลัก:

1. ทีมงาน: มีจำนวนคนและเวลาเพียงพอสำหรับปรับปรุงโค้ดให้เป็น Cloud Native Application
2. ทรัพยากรระบบ: ขั้นต่ำ: CPU 20 Cores, Memory 64GB, HDD 1TB
3. Mindset: พร้อมยอมรับความล้มเหลวด้วย No-Blame Culture
4. Development Process: เตรียมเปลี่ยนจาก Manual เป็น Automation
5. Application: ต้องสามารถรันบน Linux เพื่อรองรับ Kubernetes

DevSecOps Maturity Levels

DevSecOps แบ่งระดับการพัฒนาออกเป็น 5 ระดับ:

1. Ad-hoc: ทำงานแบบไม่มีแผน อยากทำก็ทำ
2. Proof of Concept (PoC): ทดลอง DevSecOps ในโปรเจกต์เล็ก
3. Org-wide Adoption: ทำ DevSecOps เป็นมาตรฐานองค์กร
4. Sustained and Repeatable: มี Tools และ Process ที่ชัดเจน
5. Optimized DevSecOps + SRE: ปรับปรุงระบบอย่างต่อเนื่อง

Strategies for Scaling DevSecOps

การนำ DevSecOps ไปใช้งานในองค์กรอย่างมีประสิทธิภาพมี 3 กลยุทธ์หลัก:

1. การเรียนรู้ DevSecOps
   - Training Center: อบรมความรู้ใหม่ๆ ให้ทีม
   - Communities of Practice: ตั้งกลุ่มแลกเปลี่ยนความรู้ เช่น ชมรม
   - Center of Excellence: จ้างผู้เชี่ยวชาญจากภายนอกมาให้คำปรึกษา
2. การทำ POC (Proof of Concept)
   - PoC but Stall: ทดลองเพื่อเรียนรู้เฉยๆ
   - PoC as a Template:ทำ Template สำหรับใช้ในอนาคต
   - PoC as Seed: สร้างผู้เชี่ยวชาญ และกระจายความรู้ไปยังทีมอื่น
3. การ Scaling ในองค์กร
   - Big Bang: เปลี่ยนระบบทั้งหมดในครั้งเดียว
   - Bottom-Up/Top-Down: เปลี่ยนจากทีมเล็กไปทีมใหญ่ หรือจาก Management ลงไป
   - Mashup: ผสมผสานวิธีต่างๆ ตามความเหมาะสม

Figure: DevSecOps Adoption Flow (Image by Author)

DevSecOps Adoption Flow

ขั้นตอนเริ่มต้น DevSecOps:

1. Basic Training: อบรมพื้นฐาน DevSecOps
2. พัฒนา DevSecOps Tools:
   - ทำ Roadmap
   - ออกแบบ Process & Policy (To be)
   - ออกแบบและเตรียม Infrastructure เช่น Cloud
   - เลือกและติดตั้ง Tools ที่จำเป็น เช่น GitLab, Kubernetes
3. Onboarding New Application:
   - ปรับ Application ให้เป็น Cloud Native
   - ทดลอง Deploy แบบ Manual
   - สร้าง CI/CD พร้อม Automation Security
   - ติดตั้ง Monitoring
4. Sharing & Optimization: แชร์ความรู้และปรับปรุงระบบ

Key Metrics for DevSecOps

การวัดผล DevSecOps มี 4 Metrics สำคัญ:

1. Lead Time: เวลาตั้งแต่เริ่มเขียนโค้ดจน Deploy สู่ Production
2. Deployment Frequency: ความถี่ของการ Deploy
3. Change Failure Rate: อัตราความล้มเหลวของการเปลี่ยนแปลง
4. Time to Restore: เวลากู้คืนระบบเมื่อเกิดปัญหา

Deployment Strategies

กลยุทธ์การ Deploy ระบบใหม่อย่างมีประสิทธิภาพ:

1. Assessment and Roadmap:
   ขั้นตอนการเริ่มต้น DevSecOps ควรมีการวางแผนที่ชัดเจน:
   - Planning: วางแผนขั้นตอนการทำงาน เช่น เลือก Tools, Design Process
   - Initial 1st Project: เริ่มทำโปรเจกต์นำร่องเพื่อทดสอบความเป็นไปได้
   - Production: นำระบบขึ้น Production เพื่อใช้งานจริง
   - Improvement: ปรับปรุงระบบตาม Feedback และแก้ไขปัญหา
   - Sharing: แชร์ความรู้และประสบการณ์ให้ทีมอื่นในองค์กร
   - 2nd Project: เริ่มต้นโปรเจกต์ที่สองบนพื้นฐานของบทเรียนจากโปรเจกต์แรก
   - Org-wide Adoption: ขยายผล DevSecOps ไปทั้งองค์กร
2. Assessment (ประเมินรายละเอียดของ Application):การเก็บข้อมูลเบื้องต้นของ Application ที่จะทำ DevSecOps:
   - Application Name: ชื่อ Application
   - Application Summary: สรุปภาพรวมของระบบ
   - Developer: ผู้พัฒนา (In-house/Outsource)
   - User: ผู้ใช้งาน (Internal/External)
   - Programming Languages and Frameworks: Frontend ใช้อะไร? Backend ใช้อะไร?
   - Databases: ใช้ฐานข้อมูลแบบใด (SQL, NoSQL)
   - Infrastructure: เซิร์ฟเวอร์และ Cloud ที่ใช้
   - Environments: มี Environment อะไรบ้าง เช่น Dev, Test, Prod
   - Workload: ควรระบุปริมาณการใช้งาน เช่น CCU (Concurrent Users)
   - SLA: ระบุข้อตกลงด้านความเสถียร เช่น 99.9% Availability
3. Draft Architecture:
   การออกแบบ Architecture จะช่วยกำหนดแนวทางในการปรับใช้ DevSecOps เช่น การแบ่ง Environment, Load Balancer, และการใช้ Container หรือ Orchestration Tools
4. ตั้ง KPI (Key Performance Indicator):
   กำหนดตัวชี้วัดความสำเร็จเพื่อประเมินผลลัพธ์ของ DevSecOps:
   - Deployment Frequency: ความถี่ในการ Deploy
   - Cycle/Lead Time: ระยะเวลาตั้งแต่เขียนโค้ดจนถึงใช้งานจริง
   - Mean Time to Resolution (MTTR): เวลาที่ใช้ในการแก้ไขปัญหา
5. ทำความเข้าใจ As-Is Process**:**
   ศึกษากระบวนการปัจจุบัน (As-Is Process) เพื่อทำความเข้าใจว่า:
   - ใครรับผิดชอบในแต่ละขั้นตอน: Code → Build → Test → Package → Release → Configure → Monitoring
   - ขั้นตอนใดใช้เวลานานที่สุด: เพื่อหาแนวทางปรับปรุง

DevSecOps Design

1. เริ่มจาก Pain Point
   วิเคราะห์ปัญหาหลัก เช่น Deploy ช้า, Bug เยอะ, ระบบไม่เสถียร เพื่อออกแบบการแก้ไขให้ตรงจุด
2. เลือก Git Branching Strategy
   2.1) By Concept: เน้นความยืดหยุ่นและปรับเปลี่ยนได้ง่าย (แนะนำ)
   - Environment Branch Strategy: แต่ละ Branch แยกตาม Environment เช่น Dev, UAT, Prod
   - Feature Branch Strategy: ใช้ Branch แยกสำหรับการพัฒนา Feature ใหม่
   - Scheduled Release Strategy: ปล่อย Release ตามกำหนดเวลาชัดเจน
   2.2) Full Poposing Idea: มี Process ที่ชัดเจน
   - GitLab Flow, GitHub Flow, Git Flow: ใช้ Flow มาตรฐานสำหรับจัดการ Branch
3. เลือก Deployment Strategies
   วิธี Deploy ที่เหมาะสมกับความต้องการขององค์กร:
   - Recreate/Replace Deployment: ลบระบบเก่าแล้วแทนที่ด้วยระบบใหม่
   - Rolling Deployment: ค่อยๆ ทดแทนระบบเก่าด้วยระบบใหม่ทีละส่วน
   - Blue-Green Deployment: ใช้ 2 ระบบคู่ขนาน เช่น Blue (เก่า), Green (ใหม่)
   - Canary Deployment: ทดสอบระบบใหม่กับผู้ใช้งานบางส่วนก่อน Roll Out
4. Automation Tools สำหรับ Environment
   - Ansible: เขียน Playbook สำหรับ Automate Deployment (เหมาะกับระบบขนาดเล็ก)
   - Docker: สร้าง Application เป็น Container พร้อม Deploy
   - Helm + Kubernetes: จัดการ Container สำหรับ Scaling และ Reusability
   - The Twelve-Factor App: แนวทางเขียนโปรแกรมที่รองรับ Cloud Native
5. Security ใน DevSecOps
   - วางแผนการทำ Automation Security เช่น การใช้ Tools สแกนช่องโหว่
   - Secure Coding: ปลูกฝังแนวคิดการเขียนโค้ดที่ปลอดภัยในทีม Dev

People: การจัดทีมเพื่อความสำเร็จใน DevSecOps

1. Anti-Types (แบบที่ล้มเหลว)

รูปแบบการจัดทีมที่มักไม่ประสบความสำเร็จ:

• Dev and Ops Silos:
  - Dev และ Ops แยกการทำงานออกจากกัน ไม่มีการสื่อสารและทำงานร่วมกั
  - ผลลัพธ์: ระบบที่ส่งขึ้น Production มีปัญหา เพราะ Ops ไม่เข้าใจโค้ด และ Dev ไม่เข้าใจ Infrastructure
• DevOps Team Silo:
  - ตั้งทีม DevOps แยกออกมาเพื่อดูแลทุกอย่าง เช่น CI/CD และ Infrastructure
  - ผลลัพธ์: ทีม DevOps แบกรับงานหนักเกินไป ทำให้ทีม Burnout และคนลาออก
• Dev Don’t Need Ops:
  - Dev ทำทุกอย่างเอง ตั้งแต่เขียนโค้ดไปจนถึง Deploy
  - แม้เหมาะกับ Startups แต่ในองค์กรใหญ่จะเจอปัญหา เช่น Scale ระบบไม่ได้ หรือ Data รั่วไหล
• Rebranded SysAdmin:
  - ดึง System Admin มาทำ DevOps แต่ไม่ได้ดึง Dev มาร่วมมือ
  - ผลลัพธ์: ขาดความเข้าใจในการพัฒนาระบบร่วมกัน

2. รูปแบบการจัดทีมที่ Success (ประสบความสำเร็จ)

รูปแบบการทำงานที่มีความร่วมมือระหว่าง Dev และ Ops:

• Dev and Ops Collaboration:
  Dev และ Ops ทำงานร่วมกัน และแบ่ง On-call Responsibilities เมื่อระบบมีปัญหา
• Fully Shared Ops Responsibilities:
  แบ่งปันงาน เช่น Monitoring, Troubleshooting, และ Deployment
• Ops and Infrastructure-as-a-Service (Platform):
  Dev ร่วมสร้าง Platform DevOps กับ Ops เพื่อรองรับ CI/CD
• DevOps Advocacy Team:
  สร้างทีมชั่วคราวเพื่อเชื่อม Dev และ Ops ให้สามารถทำงานร่วมกันได้อย่างราบรื่น

3. การแบ่งหน้าที่ระหว่าง Dev และ Ops

• Dev: สร้างโครงสร้างโค้ด (Structure), Build, Test, และ Deploy
• Ops: ตรวจสอบและ Optimize ระบบ รวมถึงดูแล Security (ร่วมกับทีม Security)

Site Reliability Engineering (SRE)

1. ความแตกต่างระหว่าง SRE และ DevSecOps

• DevSecOps: เป็น Mindset หรือ Culture ที่รวม Security เข้ากับ DevOps
• SRE (Site Reliability Engineering): เป็นตำแหน่งงานที่รับผิดชอบ Implement DevSecOps ในองค์กร

2. Service Levels (SLs): ตัวชี้วัดความสำเร็จใน SRE

• Service Level Indicator (SLI):
  ตัวชี้วัดผลการทำงาน เช่น Latency, Availability
• Service Level Objective (SLO):
  เป้าหมาย เช่น 95% ของ HTTP Requests ต้องตอบกลับภายใน 200ms
• Service Level Agreement (SLA):
  ข้อตกลงกับลูกค้า พร้อมข้อกำหนด Compensation หากไม่เป็นไปตาม SLA

3. Error Budget: เครื่องมือวางแผนสำหรับความล้มเหลว

• Error Budget คือ เวลาที่ระบบสามารถล่มได้ โดยไม่ทำให้ผิด SLA
• หากมี Error Budget เหลือเยอะ เราสามารถใช้เวลาเพื่อทดลองสิ่งใหม่ๆ เช่นการทำ Performance Test หรือการ Deploy Feature ใหม่

4. Workflow ใน SRE

1. Monitor: ตรวจสอบว่า SLI, SLO, SLA ตรงตามที่กำหนดหรือไม่
2. Visualize: สร้าง Dashboard ดูระบบและ Error Budget เหลือเท่าไหร่
3. Remediate: แก้ไขปัญหาเพื่อให้ระบบกลับมาทำงานตาม SLA
4. Improve: ปรับปรุงระบบอย่างต่อเนื่องเพื่อเพิ่ม Reliability

นอกจากนี้ ในคอร์สยังพูดถึง DevOps Learning Path สำหรับคนที่อยากพัฒนาตัวเองในสายงานนี้อีกด้วยนะครับ หวังว่าเนื้อหาในซีรีส์นี้จะเป็นประโยชน์กับทุกคนนะครับ

---

Data Science Explore the world of data science with Donato_Story

Dashboard Discover the power of data visualization with Donato_Story

Donato_Journey Join me on my journey (Thai version)

Course_Review Discover the training courses with Donato_Story (Thai version)

Let’s Connect!

Your feedback is invaluable. Feel free to share your thoughts or questions in the comments below. You can also connect with me on:

• Medium: medium.com/donato-story
• Facebook: web.facebook.com/DonatoStory
• Linkedin: linkedin.com/in/nattapong-thanngam