Kejuruteraan Keluaran DevOps dan Pagar CI/CD: Panduan Praktikal

Senario

Semasa tempoh jualan puncak, platform e-dagang menghantar kemas kini perkhidmatan mikro. Versi baru memperkenalkan titik akhir semakan kesihatan yang salah, menyebabkan Kubernetes menganggap Pod sihat walaupun perkhidmatan tidak dapat memproses permintaan. Saluran CI/CD gagal mengesan ini kerana ujian unit dan integrasi tidak meliputi logik semakan kesihatan. Selepas penggunaan, trafik dihalakan ke Pod yang tidak sihat, menyebabkan lonjakan ralat 5xx dan aduan pengguna.

Gejala

• Amaran pemantauan: Kadar ralat HTTP 502/503 meningkat
• Maklum balas pengguna: Halaman gagal dimuatkan, beberapa fungsi tidak tersedia
• Keadaan kluster: Pod berjalan tetapi prob kesediaan gagal (jika dikonfigurasi), prob liveness lulus
• Log: Log kontena aplikasi menunjukkan tamat masa sambungan atau ralat penghantaran permintaan

Diagnosis

1. Periksa acara Kubernetes: kubectl describe pod <nama-pod> - cari kegagalan prob atau but semula.
2. Lihat log Pod: kubectl logs <nama-pod> --previous - cari ralat peringkat aplikasi.
3. Sahkan titik akhir perkhidmatan: kubectl get endpoints <nama-perkhidmatan> - pastikan Pod dalam senarai titik akhir.
4. Uji semakan kesihatan secara manual: contoh curl http://localhost:8080/healthz dari dalam Pod.
5. Periksa saluran CI/CD: Semak log binaan terkini untuk melihat sama ada ujian dilangkau atau gagal.

Arahan

# Dapatkan status Pod
kubectl get pods -n production -l app=myservice

# Huraikan Pod untuk acara
kubectl describe pod myservice-xxx -n production

# Lihat log
kubectl logs -l app=myservice --tail=100 -n production

# Sahkan titik akhir perkhidmatan
kubectl get endpoints myservice -n production

# Uji semakan kesihatan (masuk Pod)
kubectl exec -it myservice-xxx -n production -- curl http://localhost:8080/healthz

# Periksa saluran CI/CD (contoh dengan Jenkins)
curl -u user:token https://jenkins.example.com/job/myservice-release/lastBuild/consoleText

Kawalan Risiko

• Pengembalian segera: Gunakan mekanisme pengembalian cepat (lihat bahagian seterusnya).
• Sekatan trafik: Gunakan NetworkPolicy Kubernetes atau peraturan Ingress untuk menyekat versi rosak.
• Hentikan keluaran: Hentikan penggunaan selanjutnya sehingga punca ditentukan.
• Dayakan pemutus litar: Jika menggunakan mesh perkhidmatan, konfigurasikan pemutusan litar.
• Maklumkan pasukan: Hantar amaran insiden melalui PagerDuty/Slack.

Pengembalian

# Kaedah 1: kubectl rollout undo
kubectl rollout undo deployment/myservice -n production

# Kaedah 2: Kembali ke versi stabil diketahui
kubectl set image deployment/myservice myservice=myregistry.azurecr.io/myservice:v1.2.3-stable -n production

# Kaedah 3: Pengembalian Helm
helm rollback myservice 1 -n production

Selepas pengembalian, pantau kadar ralat untuk memastikan ia menurun.

Pengesahan

• Pantau metrik: Sahkan kadar ralat kembali sifar, latensi P95 normal.
• Periksa status Pod: Semua Pod harus Ready.
• Ujian fungsional: Jalankan ujian asap untuk mengesahkan aliran pengguna kritikal.
• Ujian regresi: Laksanakan suite ujian integrasi automatik.
• Semak saluran: Tambah langkah pengesahan semakan kesihatan dalam CI/CD.

Bila Perlu Hantar Tiket OpsGlobal

• Jika isu berterusan selepas pengembalian, infrastruktur asas mungkin terlibat.
• Perlu audit kebenaran CI/CD atau perubahan konfigurasi.
• Memerlukan kepakaran SRE untuk mereka bentuk pagar yang lebih mantap (keluaran canary, penggunaan biru-hijau).
• Perlu analisis punca utama dan laporan selepas insiden.

Semasa menghantar, sertakan: cap masa, perkhidmatan terjejas, coretan log ralat, dan langkah penyelesaian masalah yang telah dilakukan.