Penyedia cloud publik (AWS, GCP, Cloudflare, GitHub) menjanjikan Service Level Agreement (SLA) bulanan berkisar antara 99.9% hingga 99.99%. Ketika insiden infrastruktur terjadi, tim engineering berhak mengajukan klaim finansial (service credit). Masalahnya, cloud provider tidak memberikan credit secara otomatis. Beban pembuktian ada di tangan pengguna, mencakup rincian tanggal, durasi dampak, dan log korelasi backend. Tanpa otomatisasi, proses ini sering terabaikan karena manual dan menyita waktu.

Arsitektur Sistem SLA Credit Tracker

Sistem dirancang modular menggunakan cron job atau CI/CD scheduled pipeline (seperti GitHub Actions) yang berjalan harian. Sistem mengeksekusi tiga fase utama:

  1. Status Polling: Mengambil status feed publik provider (Statuspage JSON/RSS API) untuk mendeteksi event kategori major outage atau degraded performance.
  2. Telemetry Correlation: Jika ditemukan outage window, query metric internal (Prometheus/VictoriaMetrics) untuk mengecek apakah backend aplikasi mengalami lonjakan error HTTP 5xx atau latency spike pada rentang waktu yang sama.
  3. Report Generation & Alerting: Menghitung total durasi downtime yang tervalidasi, mengonversinya ke persentase availability bulanan, lalu memposting rekap ticket klaim ke Slack atau membuat GitHub Issue.

1. Polling Status Cloud Provider

Banyak provider mengandalkan platform Atlassian Statuspage atau endpoint JSON standar. Script Python berikut mengambil insiden dalam kurun waktu 24 jam terakhir dari endpoint status publik.

import urllib.request
import json
from datetime import datetime, timezone, timedelta

STATUS_ENDPOINT = "https://www.githubstatus.com/api/v2/incidents.json"

def get_recent_outages(lookback_hours=24):
    cutoff = datetime.now(timezone.utc) - timedelta(hours=lookback_hours)
    req = urllib.request.Request(
        STATUS_ENDPOINT, 
        headers={"User-Agent": "SlaCreditTracker/1.0"}
    )
    with urllib.request.urlopen(req) as resp:
        data = json.loads(resp.read().decode())
    
    impacted_windows = []
    for inc in data.get("incidents", []):
        created_at = datetime.fromisoformat(inc["created_at"].replace("Z", "+00:00"))
        resolved_str = inc.get("resolved_at")
        resolved_at = datetime.fromisoformat(resolved_str.replace("Z", "+00:00")) if resolved_str else datetime.now(timezone.utc)
        
        if resolved_at > cutoff and inc.get("impact") in ["critical", "major"]:
            impacted_windows.append({
                "id": inc["id"],
                "name": inc["name"],
                "impact": inc["impact"],
                "start": created_at,
                "end": resolved_at,
                "duration_min": (resolved_at - created_at).total_seconds() / 60
            })
    return impacted_windows

2. Korelasi dengan Telemetri Backend (Prometheus)

Provider mungkin mengalami degradasi, tetapi tim keuangan tidak bisa mengklaim kredit jika sistem Anda tidak terdampak. Verifikasi dilakukan dengan mengecek error rate pada Prometheus HTTP API untuk rentang waktu insiden terkait.

import urllib.parse

def verify_internal_impact(prom_base_url, start_iso, end_iso):
    # ponytail: query hardcoded untuk demo; ganti via ENV untuk metric fleksibel
    query = 'sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100'
    params = urllib.parse.urlencode({
        'query': query,
        'start': start_iso,
        'end': end_iso,
        'step': '60s'
    })
    
    req = urllib.request.Request(f"{prom_base_url}/api/v1/query_range?{params}")
    try:
        with urllib.request.urlopen(req, timeout=10) as resp:
            res = json.loads(resp.read().decode())
            values = [float(v[1]) for series in res["data"]["result"] for v in series["values"]]
            # Hitung apakah error rate melewati baseline threshold (> 5%)
            impacted_samples = [v for v in values if v > 5.0]
            return len(impacted_samples) > 0
    except Exception as e:
        print(f"Telemetry check failed: {e}")
        return False

3. Kalkulasi Uptime dan Service Credit

Sebagian besar SLA provider mengikuti struktur kompensasi berjenjang:

  • 99.0% - 99.9%: 10% credit pengembalian tagihan layanan terkait.
  • 95.0% - < 99.0%: 25% credit pengembalian tagihan.
  • < 95.0%: 100% credit pengembalian tagihan.

Uptime dihitung dengan rumus: ((Total Menit per Bulan - Menit Terdampak) / Total Menit per Bulan) * 100. Sebagai contoh, dalam bulan 30 hari (43.200 menit), downtime sebesar 45 menit menurunkan uptime menjadi 99.89%, yang memenuhi syarat klaim credit 10%.

4. Eksekusi Scheduled Pipeline di GitHub Actions

Alih-alih mengelola virtual machine khusus, pipeline dapat dijalankan otomatis setiap malam menggunakan GitHub Actions.

name: SLA Credit Tracker

on:
  schedule:
    # Eksekusi setiap pukul 01:00 UTC
    - cron: '0 1 * * *'
  workflow_dispatch:

jobs:
  track-sla:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Run Tracker & Notify
        env:
          PROM_BASE_URL: ${{ secrets.PROMETHEUS_ENDPOINT }}
          SLACK_WEBHOOK: ${{ secrets.SLACK_INFRABOT_WEBHOOK }}
        run: python ./scripts/sla_tracker.py

Batasan Teknis dan Pertimbangan Produksi

Catatan: Selalu periksa klausul SLA Exclusion di kontrak provider. Sebagian besar penyedia tidak menanggung downtime yang disebabkan oleh miskonfigurasi pengguna, DNS provider pihak ketiga, atau maintenance terjadwal yang telah diumumkan sebelumnya.

Pertimbangkan trade-off berikut saat mengimplementasikan tracker ini:

  • Statuspage Delay: Halaman status publik cloud provider sering terlambat diperbarui 15–30 menit setelah insiden dimulai. Script perlu mengecek window 24 jam ke belakang untuk mencakup update retroaktif.
  • Metric Retention: Prometheus default menyimpan metrik selama 15 hari. Pastikan Anda memiliki long-term metrics storage (Thanos, Cortex, atau AWS Timestream) jika proses reimbursement diajukan di akhir bulan buku.