ดูแล workload หลังขึ้นคลาวด์

หลายคนเก่ง build และ migrate แต่พอถูกถามว่า "ย้ายเสร็จแล้วดูแลยังไง" กลับตอบไม่ได้ Team Lead ให้ความสำคัญกับเรื่องนี้มากเพราะงานจริงของ DCE ไม่ได้จบที่ go-live แต่ต้องช่วยลูกค้าดูแลระบบให้เสถียร คุ้มเงิน และปลอดภัยต่อเนื่อง คนที่เล่า Day-2 ops ได้ดีจะดูน่าเชื่อถือทันทีเพราะแสดงว่าเข้าใจ lifecycle เต็ม ไม่ใช่แค่สร้างเสร็จแล้วทิ้ง

รากฐานของการดูแลคือการมองเห็นสิ่งที่เกิดขึ้น Google Cloud Observability (เดิม Operations Suite) ประกอบด้วย:

• Cloud Monitoring: เก็บ metric, สร้าง dashboard, ตั้ง alert เมื่อค่าผิดปกติ
• Cloud Logging: รวม log จากทุก service ค้นและวิเคราะห์ได้
• Cloud Trace: ตาม latency ข้าม service เพื่อหาคอขวด
• Error Reporting: จับและจัดกลุ่ม error อัตโนมัติ
• Cloud Profiler: วิเคราะห์การใช้ทรัพยากรระดับโค้ด

แนวคิด SRE ที่ควรพูดได้:

• SLI (Service Level Indicator): ตัววัดจริง เช่น latency, error rate, availability
• SLO (Service Level Objective): เป้าที่ตั้งไว้ เช่น availability 99.9%
• SLA: สัญญากับลูกค้า มักตั้งต่ำกว่า SLO เพื่อมี buffer
• Error budget: ส่วนต่างที่ยอมให้ผิดพลาดได้ ใช้ตัดสินใจว่าจะเร่ง feature หรือเน้นความเสถียร
• Golden signals: latency, traffic, errors, saturation สี่ตัวหลักที่ควรเฝ้า

การพูดเรื่อง SLO/SLI/error budget แสดงวุฒิภาวะระดับ Team Lead

การคุมต้นทุนเป็นคุณค่าใหญ่ที่ DCE มอบให้ลูกค้าได้ และตรงกับความสนใจสาย cost optimization

• Billing และ budget: ตั้ง budget alert, แยก billing ตาม project/label เพื่อรู้ว่าต้นทุนไปที่ไหน
• Committed Use Discounts: จองการใช้ล่วงหน้าเพื่อลดราคาสำหรับ workload สม่ำเสมอ
• Sustained Use Discounts: ส่วนลดอัตโนมัติเมื่อใช้ต่อเนื่อง
• Right-sizing ด้วย Active Assist recommenders: จับ instance และ node pool ที่ใช้ไม่เต็มแล้วแนะนำให้ลดขนาด
• Autoscaling และ scale-to-zero: จ่ายตามใช้จริง เช่น Cloud Run scale ลงถึงศูนย์
• เลือก storage class และ lifecycle ให้เหมาะ, ปิดทรัพยากรที่ไม่ใช้, ใช้ preemptible/Spot VM สำหรับงานที่ทนการถูกดึงคืน
• Cost optimization audit: ตรวจหาจุดสิ้นเปลืองเป็นระยะ ทำเป็นบริการให้ลูกค้าได้

การเล่าเรื่องนี้ทำให้ CFO ของลูกค้าเห็นคุณค่า ไม่ใช่แค่ฝั่งเทคนิค

ความปลอดภัยไม่จบตอน deploy ต้องดูแลต่อเนื่อง

• Security Command Center: มองเห็นช่องโหว่ ภัยคุกคาม และสถานะ compliance ทั้งองค์กรอย่างต่อเนื่อง
• IAM review: ตรวจสิทธิ์เป็นระยะ ตัดสิทธิ์ที่เกินจำเป็น รักษา least privilege
• Organization policy: บังคับกฎความปลอดภัยระดับองค์กร
• Patch และ OS management: ใช้ OS Config จัดการ patch ของ VM อย่างเป็นระบบ
• VPC Service Controls และ perimeter: กันข้อมูลรั่วต่อเนื่อง
• Audit logging: เก็บว่าใครทำอะไร จำเป็นต่อการสืบสวนและ compliance
• Vulnerability scanning ของ container image ใน Artifact Registry

• Managed instance groups และ autoscaling: ปรับจำนวน instance ตามโหลดอัตโนมัติ พร้อม health check และ auto-healing
• Load balancing และ multi-zone: กระจายโหลดและกัน zone ล่ม
• Incident response: มี runbook, on-call, การแจ้งเตือน และ postmortem แบบ blameless เพื่อเรียนรู้
• Capacity planning: คาดการณ์โหลดและ quota ล่วงหน้า
• DR readiness: ทดสอบ failover ตาม RTO/RPO เป็นระยะ (โยงกับเรื่อง DR)
• Chaos/ game day: ซ้อมสถานการณ์ล้มเหลวเพื่อพิสูจน์ความพร้อม

• Infrastructure as code drift: ตรวจว่า resource จริงยังตรงกับโค้ดไหม กัน config drift
• Policy as code: บังคับ compliance อัตโนมัติ
• Label และ organization: ติด label ให้ทรัพยากรเพื่อจัดการต้นทุนและ ownership
• Automation งานซ้ำ: ใช้ scheduler และ function อัตโนมัติงาน ops ประจำ ลดภาระคนและความผิดพลาด

ถาม: "ย้าย workload เสร็จแล้ว จะดูแลต่อยังไง" ตอบ: วาง observability (monitoring, logging, tracing) ตั้ง SLO/SLI และ alert, คุมต้นทุนด้วย recommenders และ CUD, ดูแล security posture ด้วย Security Command Center, และเตรียม incident response กับ DR

ถาม: "จะช่วยลูกค้าลดต้นทุนบนคลาวด์ยังไง" ตอบ: right-sizing ด้วย Active Assist, committed use discount, autoscaling/scale-to-zero, เลือก storage class, ปิดทรัพยากรที่ไม่ใช้ และทำ cost audit เป็นระยะ

ถาม: "SLO กับ SLA ต่างกันยังไง error budget คืออะไร" ตอบ: SLI คือตัววัด, SLO คือเป้าภายใน, SLA คือสัญญากับลูกค้า, error budget คือส่วนที่ยอมพลาดได้ ใช้ตัดสินใจระหว่างเร่ง feature กับเน้นเสถียร

ถาม: "จะรู้ได้ยังไงว่าระบบมีปัญหาก่อนลูกค้าโวย" ตอบ: เฝ้า golden signals ตั้ง alert ตาม SLO และมี dashboard/observability ที่มองเห็นล่วงหน้า

ถาม: "ดูแล security หลัง go-live ยังไง" ตอบ: Security Command Center ต่อเนื่อง, IAM review เป็นระยะ, patch ด้วย OS Config, audit log และ vulnerability scan

ตอบ build/migrate ได้แต่ตอบ Day-2 ops ไม่ได้; ไม่รู้จัก SLO/SLI/error budget; พูดเรื่อง cost แบบลอย ๆ ไม่มีเครื่องมือจริง; มองความปลอดภัยเป็นแค่ตอน deploy; ลืม incident response และ postmortem; ไม่พูด observability ทั้งที่เป็นรากฐาน; ไม่เชื่อม Day-2 ops กับคุณค่าธุรกิจอย่างการคุมต้นทุนและความเสถียร

managing คือการดูแล workload หลัง go-live และมักเป็นตัวตัดสินความน่าเชื่อถือ วางรากฐานด้วย observability (monitoring, logging, tracing) และ SLO/SLI/error budget แบบ SRE คุมต้นทุนด้วย FinOps (recommenders, CUD, autoscaling, cost audit) ดูแล security posture ต่อเนื่องด้วย Security Command Center และ IAM review รักษา reliability ด้วย autoscaling, incident response และ DR testing และทำ governance/automation ให้ยั่งยืน เล่าโยงกับคุณค่าธุรกิจเสมอ เพราะการดูแลที่ดีคือสิ่งที่ทำให้ลูกค้าอยู่กับคลาวด์ได้อย่างมั่นใจ