Failover Vendor API di CI/CD untuk Mengurangi Risiko Saat Insiden

Failover Vendor API di CI/CD diperlukan ketika pipeline build, test, review, atau release bergantung pada layanan eksternal seperti AI API, code analysis, notification, atau deployment gateway. Saat vendor mengalami elevated error rate, pipeline yang tidak dirancang defensif bisa berhenti total, memblokir merge, mengacaukan SLA rilis, dan membuat tim sulit membedakan bug aplikasi dari gangguan pihak ketiga.

Solusinya bukan sekadar menambah retry. Workflow CI/CD perlu dipisahkan antara step yang harus berhasil dan step yang bisa didegradasi sementara. Dengan health check dependensi, circuit breaker pada step pipeline, retry dengan batas aman, fallback provider, mode degraded, feature flag, serta cache untuk hasil non-kritis, tim dapat menjaga otomatisasi tetap berguna tanpa menggantungkan seluruh proses pada satu vendor.

Inspirasi praktisnya sederhana: bila sebuah layanan eksternal sedang bermasalah, pipeline seharusnya mampu mengenali gangguan lebih cepat, mengurangi blast radius, dan tetap menyelesaikan pekerjaan penting sejauh risikonya masih dapat diterima.

Masalah yang Sering Terjadi Saat CI/CD Bergantung pada Satu Vendor

Banyak tim menaruh vendor API di jalur kritis tanpa sadar. Contoh umum:

Lint atau review bot memakai AI API untuk memberi komentar wajib sebelum merge.
Test pipeline memanggil layanan pihak ketiga untuk generate fixture, mock response, atau evaluasi hasil.
Release pipeline membutuhkan API eksternal untuk changelog, security gate, atau approval otomatis.
Notification dan observability dijadikan syarat sukses pipeline, padahal sifatnya pendukung.

Masalahnya muncul ketika vendor mengalami timeout, error rate naik, latency melonjak, atau hasil menjadi tidak konsisten. Jika pipeline menganggap semua dependency sama pentingnya, maka satu gangguan eksternal bisa menghentikan seluruh alur engineering.

Dampak Operasional

Developer tidak bisa merge meski test inti aplikasi lulus.
Release tertunda karena step non-kritis dianggap blocker.
Retry berulang memperparah antrean runner dan memperbesar biaya API.
Tim sulit melakukan triase karena log pipeline bercampur antara error internal dan eksternal.
Insiden vendor berubah menjadi insiden internal karena automation tidak punya mode darurat.

Prinsip Desain Workflow CI/CD yang Tahan Insiden Vendor

1. Klasifikasikan Dependency: Kritis vs Non-Kritis

Jangan mulai dari tool, mulai dari keputusan bisnis dan risiko. Tanyakan untuk setiap step:

Apakah step ini memverifikasi kebenaran produk atau hanya menambah kenyamanan?
Apakah pipeline boleh lanjut bila step gagal karena vendor eksternal?
Apakah ada sumber data alternatif atau hasil cache yang cukup aman dipakai?

Contoh klasifikasi yang umum:

Fail-closed: unit test, integration test internal, verifikasi migrasi database, signing artifact, pemeriksaan compliance yang wajib.
Fail-open: komentar review AI, pembuatan ringkasan PR, notifikasi Slack, enrichment metadata, analisis tambahan non-wajib.
Conditional: security scanning eksternal, quality gate AI-assisted, semantic release assistant. Step ini bisa fail-closed di branch release, tetapi fail-open di branch development.

2. Pisahkan Jalur Kritis dan Jalur Tambahan

Jika vendor API dipakai untuk automation pendukung, tempatkan step tersebut di jalur terpisah agar kegagalannya tidak memblokir build inti. Misalnya:

Core pipeline: checkout, build, unit test, integration test, package artifact.
Auxiliary pipeline: AI code review, auto summary, label suggestion, release notes generation.

Pemisahan ini membuat CI/CD tetap menghasilkan sinyal utama walaupun layanan tambahan sedang bermasalah.

3. Jangan Gunakan Retry Buta

Retry membantu untuk kegagalan sementara, tetapi berbahaya bila dipakai tanpa batas. Saat vendor sedang error massal, retry agresif hanya menambah beban, memperpanjang waktu pipeline, dan berpotensi memicu rate limit.

Gunakan retry hanya untuk error yang layak diulang, misalnya timeout atau respons 5xx, dengan aturan:

batas percobaan kecil,
backoff bertahap,
jitter acak untuk menghindari lonjakan serentak,
batas waktu total per step,
jangan ulang untuk error permanen seperti autentikasi salah atau payload invalid.

4. Tambahkan Circuit Breaker

Circuit breaker mencegah pipeline terus memanggil vendor yang sedang tidak sehat. Jika tingkat kegagalan melewati ambang tertentu, step terkait langsung dilewati, dialihkan ke fallback, atau masuk mode degraded selama jangka waktu tertentu.

Mengapa ini efektif? Karena saat insiden, sinyal yang dibutuhkan bukan "coba terus", tetapi "hentikan akses ke dependency yang sedang rusak agar sistem lain tetap bergerak".

Komponen Utama Failover Vendor API di CI/CD

Health Check Dependensi Sebelum Step Mahal

Sebelum menjalankan step yang sangat bergantung pada vendor, lakukan health check ringan. Health check tidak harus kompleks. Bisa berupa:

permintaan sederhana ke endpoint status atau health,
uji konektivitas ke domain API,
synthetic request murah dengan timeout ketat,
membaca sinyal dari status page internal yang disalin ke cache atau config.

Tujuannya bukan menjamin vendor 100% sehat, tetapi menghindari menjalankan rangkaian step mahal ketika ada indikasi kuat vendor sedang bermasalah.

Hal yang perlu dihindari:

Mengandalkan status page sebagai satu-satunya kebenaran. Status page bisa terlambat diperbarui.
Health check yang terlalu berat hingga malah menambah latency atau biaya.
Timeout default terlalu lama, sehingga pipeline tetap menunggu terlalu lama sebelum tahu vendor bermasalah.

Circuit Breaker pada Step Pipeline

Circuit breaker di konteks CI/CD biasanya lebih sederhana daripada implementasi di service runtime. Intinya:

Baca status kegagalan vendor dari penyimpanan bersama, misalnya Redis, artifact sebelumnya, atau file state di object storage.
Jika status vendor sedang open, jangan panggil API. Langsung fallback atau tandai step sebagai degraded.
Jika status masih closed, lakukan request dengan timeout dan retry terbatas.
Bila kegagalan melewati ambang, ubah status ke open untuk durasi pendek, misalnya beberapa menit.
Setelah durasi berlalu, izinkan satu percobaan lagi dalam mode half-open.

Karena runner CI sering stateless, state circuit breaker sebaiknya tidak disimpan hanya di memori job. Gunakan penyimpanan yang bisa dibaca pipeline lain agar ada koordinasi antar job dan antar runner.

Fallback Provider

Jika ada lebih dari satu vendor yang dapat menjalankan fungsi serupa, letakkan abstraksi tipis di depan keduanya. Contohnya untuk AI automation:

Provider A untuk komentar review,
Provider B sebagai cadangan dengan prompt lebih sederhana,
fallback lokal berupa template statis jika kedua provider gagal.

Trade-off-nya:

Fallback provider meningkatkan ketahanan, tetapi menambah kompleksitas integrasi dan pengujian.
Output antar vendor bisa berbeda kualitas, format, atau token limit.
Kontrol biaya lebih sulit bila failover otomatis tidak diberi guardrail.

Karena itu, fallback paling aman dipakai untuk fungsi non-kritis atau fungsi yang output-nya dapat ditoleransi bervariasi.

Mode Degraded

Mode degraded berarti pipeline tetap jalan, tetapi dengan kemampuan yang dikurangi. Contoh:

AI review dimatikan sementara, namun lint dan test tetap berjalan.
Release notes tidak digenerate otomatis; diganti template minimum.
Coverage summary tidak diposting ke PR, tetapi artifact tetap diunggah.

Mode ini harus terlihat jelas di log dan notifikasi agar tim paham bahwa kualitas sinyal menurun, bukan hilang diam-diam.

Feature Flag untuk Automation

Jangan hanya feature flag untuk aplikasi produksi. Automation CI/CD juga sebaiknya punya flag sendiri, misalnya:

AI_REVIEW_ENABLED
EXTERNAL_SECURITY_GATE_REQUIRED
FALLBACK_PROVIDER_ENABLED
DEGRADED_MODE_ALLOW_MERGE

Dengan flag, tim incident commander atau platform engineer bisa mematikan step bermasalah tanpa mengubah definisi pipeline secara darurat di banyak repositori.

Cache Hasil Non-Kritis

Untuk proses yang tidak perlu selalu real-time, cache dapat mengurangi ketergantungan langsung pada vendor. Misalnya:

hasil analisis AI untuk file yang hash-nya belum berubah,
ringkasan dependency risk yang diperbarui periodik,
template release note dari commit history lokal jika API eksternal gagal.

Gunakan cache hanya bila staleness dapat diterima. Jangan gunakan cache untuk keputusan yang wajib merefleksikan kondisi terkini, seperti approval keamanan yang benar-benar harus terbaru.

Kriteria Fail-Open vs Fail-Closed di Pipeline

Keputusan terpenting dalam Failover Vendor API di CI/CD adalah memilih kapan sebuah step boleh dilewati dan kapan harus menghentikan pipeline.

Kapan Fail-Open

Step hanya memberi konteks tambahan, bukan verifikasi kebenaran.
Kegagalannya tidak meningkatkan risiko produksi secara material.
Ada jejak audit bahwa step dilewati karena insiden vendor.
Tim punya proses manual sementara bila output step dibutuhkan.

Contoh:

AI-generated PR summary
komentar style suggestion
posting notifikasi chat
generate changelog draft non-final

Kapan Fail-Closed

Step terkait keamanan, integritas artifact, atau kepatuhan.
Tanpa step itu, risiko merilis defect atau pelanggaran compliance terlalu tinggi.
Tidak ada alternatif yang setara secara keandalan atau auditability.

Contoh:

verifikasi signature artifact,
test yang memeriksa kontrak internal,
kontrol persetujuan wajib sebelum release.

Kapan Hybrid

Banyak step lebih realistis dikelola secara hybrid:

Branch feature: fail-open agar developer tetap produktif.
Main branch: fail-open dengan warning dan ticket otomatis.
Release branch: fail-closed atau perlu approval manual.

Pola ini lebih praktis daripada memaksakan satu kebijakan untuk semua tahap SDLC.

Contoh Alur Pipeline yang Lebih Tahan Gangguan Vendor

Berikut contoh alur yang memisahkan jalur kritis dan non-kritis:

Preflight: cek environment, secret, dan health dependency eksternal.
Core validation: build, lint lokal, unit test, integration test internal.
External optional automation: AI review, release notes, metadata enrichment.
Package: buat artifact dan simpan checksum.
Release gate: kontrol wajib yang tidak bergantung pada vendor opsional.
Notify: kirim status dan tandai bila mode degraded aktif.

Poin pentingnya: preflight tidak hanya memeriksa apakah vendor hidup, tetapi juga memutuskan mode eksekusi pipeline. Jika vendor eksternal buruk, pipeline tidak terus masuk ke step yang jelas akan gagal.

Contoh Pseudo-YAML CI

stages:
  - preflight
  - validate
  - optional_automation
  - package
  - release
  - notify

variables:
  EXTERNAL_API_TIMEOUT_SEC: "5"
  EXTERNAL_API_MAX_RETRIES: "2"
  DEGRADED_MODE: "false"

preflight:dependency-health:
  stage: preflight
  script:
    - ./ci/check-internal-services.sh
    - ./ci/check-vendor-health.sh || echo "VENDOR_UNHEALTHY=true" > preflight.env
    - ./ci/check-circuit-breaker.sh vendor-ai || true
  artifacts:
    reports:
      dotenv: preflight.env

validate:build-and-test:
  stage: validate
  script:
    - ./ci/build.sh
    - ./ci/lint.sh
    - ./ci/test.sh

optional:ai-review:
  stage: optional_automation
  needs: ["preflight:dependency-health", "validate:build-and-test"]
  script:
    - ./ci/run-ai-review.sh
  rules:
    - if: '$VENDOR_UNHEALTHY == "true"'
      when: never
    - if: '$AI_REVIEW_ENABLED == "false"'
      when: never
    - when: on_success
  allow_failure: true

optional:ai-review-fallback:
  stage: optional_automation
  needs: ["preflight:dependency-health", "validate:build-and-test"]
  script:
    - ./ci/run-ai-review-fallback.sh
  rules:
    - if: '$VENDOR_UNHEALTHY == "true" && $FALLBACK_PROVIDER_ENABLED == "true"'
      when: on_success

package:artifact:
  stage: package
  script:
    - ./ci/package.sh
    - ./ci/checksum.sh

release:gate:
  stage: release
  script:
    - ./ci/verify-artifact.sh
    - ./ci/manual-approval-if-degraded.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success

notify:status:
  stage: notify
  script:
    - ./ci/notify.sh
  allow_failure: true

YAML di atas bersifat pseudo-code, tetapi pola desainnya penting:

Preflight menghasilkan state yang dipakai stage berikutnya.
Step AI review tidak berada di jalur wajib.
Fallback provider dijalankan hanya saat perlu.
Notifikasi tidak menjadi syarat sukses pipeline.
Release gate tetap memverifikasi integritas artifact secara independen dari vendor opsional.

Contoh Implementasi Logika Retry dan Circuit Breaker

Contoh berikut menunjukkan skrip shell sederhana untuk membungkus request ke vendor API. Fokusnya adalah timeout, retry terbatas, dan pembaruan state circuit breaker ke penyimpanan eksternal.

#!/usr/bin/env bash
set -euo pipefail

VENDOR_NAME="vendor-ai"
MAX_RETRIES="${EXTERNAL_API_MAX_RETRIES:-2}"
TIMEOUT_SEC="${EXTERNAL_API_TIMEOUT_SEC:-5}"
CB_OPEN_FILE="/tmp/${VENDOR_NAME}.open"

is_circuit_open() {
  if [ -f "$CB_OPEN_FILE" ]; then
    now=$(date +%s)
    until_ts=$(cat "$CB_OPEN_FILE")
    [ "$now" -lt "$until_ts" ]
  else
    return 1
  fi
}

open_circuit() {
  now=$(date +%s)
  cool_down=300
  echo $((now + cool_down)) > "$CB_OPEN_FILE"
}

call_vendor() {
  curl --silent --show-error \
    --fail \
    --max-time "$TIMEOUT_SEC" \
    https://api.example-vendor.test/review
}

if is_circuit_open; then
  echo "Circuit open for ${VENDOR_NAME}, skipping primary provider"
  exit 20
fi

attempt=0
while true; do
  attempt=$((attempt + 1))
  if call_vendor; then
    echo "Vendor call succeeded"
    exit 0
  fi

  if [ "$attempt" -gt "$MAX_RETRIES" ]; then
    echo "Vendor call failed after retries, opening circuit"
    open_circuit
    exit 10
  fi

  sleep_time=$((attempt * 2))
  sleep "$sleep_time"
done

Di sistem nyata, file lokal seperti di atas kurang memadai karena job CI sering berjalan di runner berbeda. Sebagai pengganti:

pakai Redis untuk menyimpan status circuit breaker,
atau simpan state ke object storage ringan,
atau gunakan service internal kecil yang menjadi decision point untuk health dependency.

Yang penting bukan medianya, melainkan adanya state bersama agar semua pipeline membaca keputusan yang sama selama insiden.

Strategi Fallback Provider yang Aman

Gunakan Kontrak Output yang Sederhana

Jika provider utama dan cadangan mengembalikan format berbeda, jangan biarkan format vendor bocor ke pipeline. Buat adapter internal yang mengubah output ke struktur minimal yang sama, misalnya:

status sukses/gagal,
ringkasan teks,
severity,
metadata sumber provider.

Dengan begitu, pindah provider tidak memaksa perubahan banyak step downstream.

Batasi Fallback pada Use Case yang Tepat

Fallback provider cocok untuk:

PR summary,
code review suggestion,
tagging atau classification,
draft release notes.

Fallback provider kurang cocok untuk:

proses legal atau compliance yang formatnya harus seragam,
kontrol keamanan yang hasilnya harus dapat diaudit ketat,
step yang sensitif terhadap variasi model atau vendor behavior.

Jangan Lupa Guardrail Biaya dan Keamanan

Pastikan secret untuk vendor cadangan tersedia dan diuji sebelum insiden terjadi.
Batasi ukuran payload agar failover tidak memicu lonjakan biaya.
Samakan kebijakan redaksi data sensitif di semua provider.
Log provider yang dipakai untuk setiap job sebagai bagian audit trail.

Observability dan Debugging Saat Vendor Bermasalah

Pipeline yang andal bukan hanya bisa bertahan, tetapi juga mudah didiagnosis. Minimal, log harus menjawab pertanyaan berikut:

Apakah error berasal dari kode internal atau vendor eksternal?
Apakah step gagal karena timeout, 5xx, rate limit, atau auth?
Apakah circuit breaker sedang aktif?
Apakah pipeline memakai provider utama, fallback, atau mode degraded?
Apakah keputusan fail-open diambil secara otomatis atau manual?

Praktik Logging yang Berguna

Sertakan dependency name di setiap log error.
Catat durasi request dan jumlah retry.
Bedakan exit code untuk jenis kegagalan berbeda bila memungkinkan.
Tambahkan anotasi ke job summary: degraded mode active, fallback provider used, atau vendor circuit open.

Debugging Tip

Jika banyak job gagal serentak di step yang sama, curigai dependency eksternal lebih dulu.
Bandingkan log branch yang gagal dengan branch yang sukses beberapa menit sebelumnya.
Cek apakah retry memperpanjang waktu tanpa memperbaiki hasil; itu sinyal kuat untuk membuka circuit.
Uji fallback secara berkala, jangan tunggu insiden. Failover yang tidak pernah diuji hampir pasti gagal saat dibutuhkan.

Kesalahan Umum

Menjadikan AI review sebagai blocker merge utama. Review otomatis berguna, tetapi sebaiknya bukan satu-satunya penjaga kualitas.
Menyamakan semua error sebagai retriable. Error autentikasi, payload salah, atau izin tidak cukup tidak akan sembuh dengan retry.
Tidak punya timeout yang ketat. Default timeout sering terlalu lama untuk konteks CI.
Fallback provider tidak pernah diuji. Secret kadaluwarsa, format berubah, atau quota habis baru ketahuan saat insiden.
Mode degraded tidak terlihat. Pipeline tampak hijau, tetapi tim tidak sadar bahwa sebagian kontrol sedang dimatikan.
Menggunakan hasil cache untuk keputusan kritis. Ini bisa mengorbankan akurasi demi ketersediaan pada area yang seharusnya tidak boleh kompromi.
Tidak membedakan policy per branch. Feature branch dan release branch biasanya memerlukan toleransi risiko yang berbeda.

Checklist Implementasi

Inventaris semua step CI/CD yang memanggil vendor eksternal.
Tandai setiap step sebagai fail-open, fail-closed, atau hybrid.
Pisahkan jalur core validation dari automation tambahan.
Tambahkan health check ringan sebelum step vendor yang mahal.
Terapkan timeout ketat, retry terbatas, dan backoff.
Tambahkan circuit breaker dengan state bersama antar runner.
Siapkan fallback provider atau fallback lokal untuk use case non-kritis.
Aktifkan feature flag untuk mematikan automation tanpa mengubah banyak pipeline.
Tambahkan mode degraded yang terlihat di log, summary, dan notifikasi.
Gunakan cache hanya untuk output non-kritis yang boleh stale.
Uji skenario insiden secara berkala, termasuk simulasi elevated error rate vendor.
Dokumentasikan runbook: siapa yang boleh mengaktifkan degraded mode, kapan fail-open diizinkan, dan kapan release harus dihentikan.

Penutup

Ketahanan CI/CD saat vendor API mengalami insiden tidak datang dari satu teknik tunggal. Kombinasi health check, circuit breaker, retry dengan batas aman, fallback provider, mode degraded, feature flag, dan klasifikasi fail-open vs fail-closed membuat pipeline tetap memberikan sinyal yang benar tanpa menjadikan satu vendor sebagai titik kegagalan tunggal.

Jika saat ini lint, test, release, atau code review automation Anda masih bergantung pada satu layanan eksternal, mulailah dari audit dependency dan kebijakan risiko per step. Targetnya bukan membuat pipeline kebal terhadap semua gangguan, melainkan memastikan gangguan vendor tidak otomatis berubah menjadi penghentian total proses engineering.

Quick Search

shopping_cart Keranjang