Online judge nasıl çalışır?

Bir değerlendirme sisteminin temel girdileri kaynak kod, programlama dili ve problem kimliğidir. Sistem önce kodu derler, ardından her test için programı çalıştırır. En basit toplam değerlendirme süresi şöyle düşünülebilir:

Programın herhangi bir testte süre sınırını aşması TLE, fazla bellek kullanması MLE, hatalı çıktı üretmesi ise WA sonucuna yol açar. Doğru sonuç yalnızca çıktının doğru olması değildir; programın belirlenen kaynak sınırları içinde çalışması da gerekir.

Gönderilen kod güvenilir kabul edilmez. Sonsuz döngüye girebilir, süreç oluşturmaya çalışabilir veya dosya sistemine erişmek isteyebilir. Bu nedenle judge sunucuları Linux kullanıcıları, cgroups, chroot, container veya benzeri izolasyon mekanizmalarından yararlanır. Kısacası değerlendirme sunucusu, yarışmacının koduna “Seni çalıştırırım ama evin anahtarını vermem” der.

Üç platformun karşılaştırması

DOMjudge: ICPC ruhunun temsilcisi

DOMjudge, takım yarışmaları ve klasik ICPC kuralları için oldukça uygundur. Yanlış gönderimler ceza süresine eklenir; problem çözüldüğünde süre hesabı kesinleşir. Basitleştirilmiş ceza modeli şöyledir:

Burada $T_{kabul}$ kabul dakikası, $W$ ise kabulden önceki yanlış gönderim sayısıdır. DOMjudge; yarışma yönetimi, canlı sıralama, hakem işlemleri ve ayrı judgehost makineleriyle ölçeklendirme konusunda güçlüdür. Üniversite kulübünde gerçekçi bir ICPC provası düzenlemek istiyorsanız genellikle ilk adaydır.

DMOJ: Esnek ve geliştirici dostu

DMOJ, sürekli açık problem arşivleri ve eğitim platformları için öne çıkar. Çok sayıda dili destekler; özel checker, interaktif problem ve kısmi puanlama gibi özellikler sunar. Django tabanlı web uygulaması ile değerlendirme düğümleri birbirinden ayrılabilir.

Bir problemin basit yapılandırması kavramsal olarak şöyle görünebilir:

archive: data.zip
time: 2
memory: 256
test_cases:
  - points: 20
    input: sample.in
    output: sample.out
  - points: 80
    batched:
      - input: secret.in
        output: secret.out

Bu yapı süreyi, bellek sınırını ve testlerin puan ağırlığını tanımlar. Gerçek sözdizimi sürüme ve problem paketine göre değişebilse de temel fikir aynıdır: değerlendirme davranışı kod yerine yapılandırmayla açıklanır.

CMS: Olimpiyat seviyesinde kontrol

Contest Management System, özellikle IOI biçimindeki yarışmalara yöneliktir. Alt görevler, geri bildirim düzeyleri, token sistemi ve ayrıntılı puanlama senaryolarında çok başarılıdır. Örneğin çözüm ilk alt görevden 20, ikinci alt görevden 30 puan alabilir; en zor grup başarısız olsa bile toplam puan korunur.

CMS güçlüdür ancak kurulumu ve işletimi diğer seçeneklere göre daha fazla sistem yönetimi bilgisi ister. Servislerin dağıtılması, worker makinelerinin hazırlanması ve yarışma verilerinin doğru modellenmesi dikkat gerektirir.

Hangisini seçmeli?

Tek günlük ICPC benzeri bir etkinlik için DOMjudge, okul veya topluluk tabanlı sürekli bir soru platformu için DMOJ, ulusal olimpiyat düzeyinde alt görevli yarışmalar için CMS daha doğal seçimdir. Platformdan bağımsız olarak yedekleme, HTTPS, kaynak izolasyonu ve yarışma öncesi yük testi ihmal edilmemelidir. Çünkü en zor algoritma sorusu bile çözülebilir; yarışma ortasında çöken judge sunucusu ise herkese aynı anda sistem tasarımı dersi verir.

Önce temel: OpenAPI nedir?

OpenAPI, REST tabanlı bir API’nin insanlar ve makineler tarafından okunabilen sözleşmesidir. Endpoint yolları, HTTP metotları, parametreler, veri modelleri, kimlik doğrulama yöntemleri ve olası yanıtlar YAML veya JSON biçiminde tanımlanır.

Bir API sözleşmesini kabaca şu fonksiyonla düşünebiliriz:

Burada $P$ yolları, $R$ istekleri, $M$ veri modellerini, $A$ kimlik doğrulamayı ve $E$ hata yanıtlarını temsil eder. Sözleşme ne kadar eksiksizse istemci üretimi, test otomasyonu ve geliştirici deneyimi o kadar başarılı olur.

Swagger UI ve Redoc bu sözleşmeyi görselleştirir. Docusaurus ise rehberler, eğitimler, sürüm notları ve kavramsal açıklamalar için genel bir dokümantasyon sitesi sunar.

Araçların karşılaştırması

Kısacası Swagger UI laboratuvar, Redoc düzenli bir ansiklopedi, Docusaurus ise bütün kampüstür.

Küçük bir OpenAPI sözleşmesi

Aşağıdaki dosya, kullanıcı bilgisini kimliğe göre döndüren bir endpoint tanımlar:

openapi: 3.0.3
info:
  title: Kullanıcı API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Kimliğe göre kullanıcı getirir
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: Kullanıcı bulundu
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: Kullanıcı bulunamadı
components:
  schemas:
    User:
      type: object
      required: [id, name]
      properties:
        id:
          type: integer
        name:
          type: string

Bu tanım tek bir doğruluk kaynağıdır. Aynı dosya arayüz oluşturmak, sözleşme testi yapmak veya istemci SDK’sı üretmek için kullanılabilir.

Swagger UI ve Redoc’u çalıştırmak

En hızlı yöntem Docker kullanmaktır:

# Etkileşimli Swagger UI

docker run --rm -p 8080:8080 \
  -e SWAGGER_JSON=/spec/openapi.yaml \
  -v "$PWD:/spec" swaggerapi/swagger-ui

# Okuma odaklı Redoc

docker run --rm -p 8081:80 \
  -e SPEC_URL=openapi.yaml redocly/redoc

İlk komut API’yi localhost:8080 üzerinde deneyebilmenizi sağlar. İkinci komut aynı sözleşmeyi daha sade ve referans odaklı bir görünümle sunar. Gerçek projede dosyayı Redoc sunucusunun erişebileceği dizine kopyalamak veya bir URL üzerinden yayımlamak gerekir.

Docusaurus ile merkezi portal

Docusaurus projesinde kavramsal rehberleri Markdown ile tutabilir, API referansına menüden bağlantı verebilirsiniz:

// docusaurus.config.js
export default {
  themeConfig: {
    navbar: {
      items: [
        { to: '/docs/intro', label: 'Rehberler' },
        { href: '/api/redoc.html', label: 'API Referansı' },
        { href: '/swagger/', label: 'API’yi Dene' }
      ]
    }
  }
};

Bu yapı kullanıcıya üç katman sunar: “Neden kullanmalıyım?” sorusunu rehberler, “Hangi alanlar var?” sorusunu Redoc, “Bu istek gerçekten çalışıyor mu?” sorusunu Swagger UI cevaplar.

Sürdürülebilir iş akışı

OpenAPI dosyasını uygulama koduyla aynı depoda saklayın. CI sürecinde sözdizimini doğrulayın, kırıcı değişiklikleri karşılaştırın ve başarılı derlemeden sonra üç aracı da yayımlayın. Sürüm numarasını URL’ye eklemek, eski istemcilerin dokümantasyona erişmesini kolaylaştırır.

Ayrıca örneklerde gerçek erişim anahtarları kullanmayın. Swagger UI üzerindeki yetkilendirme alanlarını yalnızca güvenli test ortamlarına bağlayın. Böylece güzel görünen değil; güncel, test edilebilir ve güvenilir bir API dokümantasyon sistemi elde edersiniz.

``

API testi aslında neyi doğrular?

Bir istemci API’ye HTTP isteği gönderir; sunucu ise durum kodu, başlıklar ve gövde içeren bir yanıt üretir. Test aracının temel görevi bu alışverişi görünür ve tekrar edilebilir hâle getirmektir.

Örneğin bir kullanıcı endpoint’i için yalnızca 200 OK almak yeterli değildir. Yanıt gövdesindeki id alanının bulunması, içerik türünün JSON olması ve sürenin belirlenen sınırı aşmaması da kontrol edilmelidir.

Performansı basitçe şöyle değerlendirebiliriz:

Bir test 400 ms sürüyorsa bunun tamamı sunucunun işlem süresi değildir. Ağ gecikmesi ve yanıt boyutu da sonucu etkiler. Çoklu isteklerde ortalama süre ise

formülüyle hesaplanabilir. Bu nedenle tek bir hızlı yanıt görüp zafer dansına başlamak yerine testi birkaç kez çalıştırmak daha sağlıklıdır.

Üç aracın karakteri

Hoppscotch: Tarayıcıyı aç ve isteği gönder

Hoppscotch, kurulumla uğraşmadan REST, GraphQL ve WebSocket istekleri denemek isteyenler için idealdir. Arayüzü hafiftir; URL’yi, metodu ve gerekli başlıkları girerek saniyeler içinde sonuç alabilirsiniz. Özellikle eğitimlerde, hata ayıklamada ve geçici kontrollerde parıldar.

Ancak hassas token’larla çalışırken ekip politikalarını ve verinin nerede saklandığını incelemek gerekir. Tarayıcı kolaylığı, güvenlik değerlendirmesini ortadan kaldırmaz.

Bruno: Koleksiyonlar da kod gibi yaşasın

Bruno, koleksiyonları düz metin dosyalarında saklayarak Git üzerinden sürümlemeyi kolaylaştırır. Böylece API değişiklikleri pull request içinde görülebilir; “Bu header’ı kim değiştirdi?” sorusu polisiye romana dönüşmez.

Örnek bir Bruno isteği şöyle görünebilir:

meta {
  name: Kullanıcı Getir
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/users/42
  body: none
  auth: bearer
}

assert {
  res.status: eq 200
  res.body.id: eq 42
}

Bu dosya isteğin adresini tanımlar ve yanıtın durum koduyla kullanıcı kimliğini doğrular. CLI desteği sayesinde aynı koleksiyon CI/CD hattında da çalıştırılabilir.

Insomnia: Düzenli ve kapsamlı çalışma masası

Insomnia; ortam değişkenleri, kimlik doğrulama yöntemleri, GraphQL desteği ve koleksiyon organizasyonuyla kapsamlı projelerde rahat bir deneyim sunar. Çok sayıda servisi olan ekipler için klasörlü yapı ve yeniden kullanılabilir değişkenler önemlidir.

Örneğin geliştirme ve üretim adreslerini ayrı ayrı yazmak yerine şu mantık kullanılabilir:

{
  "base_url": "https://api.example.com",
  "token": "{{ secret_token }}"
}

Böylece isteklerde `` kullanılır ve ortam değiştirirken her endpoint’i elle düzenlemek gerekmez. Token değerlerini repoya eklememek ise temel güvenlik kuralıdır.

Hangisini seçmelisiniz?

Hızlı, kurulumsuz denemeler için Hoppscotch; koleksiyonları Git ile yönetmek ve testleri pipeline’a taşımak için Bruno; kapsamlı masaüstü deneyimi ve düzenli proje yönetimi için Insomnia öne çıkar. En iyi araç, en fazla düğmeye sahip olan değil, ekibinizin testleri düzenli çalıştırmasını sağlayandır. Küçük bir örnek API’yi üçünde de deneyin; ardından hız, paylaşım, güvenlik ve otomasyon ihtiyaçlarınıza göre karar verin.

``

Hata takip sistemi nasıl çalışır?

Uygulamaya eklenen SDK, yakalanmamış bir istisna oluştuğunda bir hata olayı üretir. Bu olay genellikle hata mesajını, stack trace bilgisini, sürümü, çalışma ortamını ve isteğe bağlı kullanıcı bağlamını içerir. Veriler bir DSN adresi üzerinden sunucuya gönderilir.

Sistem, benzer olayları tek bir sorun altında gruplandırmaya çalışır. Böylece aynı NullReferenceException hatası bin kez oluştuğunda panelde bin bağımsız kayıt yerine, gerçekleşme sayacı yükselen tek bir sorun görürüz.

Belirli sürede oluşan olay sayısını $E$, süreyi dakika cinsinden $t$ kabul edersek hata yoğunluğu şöyle ifade edilebilir:

Örneğin 10 dakikada 500 olay alınması, $R = 50$ olay/dakika anlamına gelir. Ancak yüksek sayı her zaman daha kritik hata demek değildir. Etkilenen kullanıcı sayısı, hata oranı ve işlemin önemi birlikte değerlendirilmelidir.

Üç aracın kısa karşılaştırması

Sentry, hata takibinin yanında performans izleme, dağıtık tracing, sürüm takibi ve oturum tekrarı gibi geniş özellikler sunar. Yönetilen bulut hizmeti operasyon yükünü azaltır; fakat yoğun trafik, veri kotası ve gizlilik gereksinimleri dikkatle değerlendirilmelidir.

GlitchTip, Sentry SDK’larıyla uyumlu açık kaynaklı bir deneyim sağlamayı amaçlar. Arayüzü daha sade, self-hosted kurulumu ise genellikle daha ulaşılabilirdir. Sentry’nin bütün ileri analiz özelliklerini beklemeyen ekipler için güçlü bir dengedir.

Bugsink, “önce hatayı yakalayalım” yaklaşımına yakındır. Daha az bileşenle çalışması, küçük sunucularda yönetimi kolaylaştırabilir. Kapsamlı observability platformu yerine anlaşılır bir hata kutusu isteyen projelere uygundur.

Python uygulamasına SDK eklemek

Üç ürün de Sentry protokolüyle uyumlu kurulum senaryoları sunabildiğinden Python tarafında çoğunlukla resmi SDK kullanılabilir:

import sentry_sdk

sentry_sdk.init(
    dsn="https://anahtar@hata-sunucusu.example/1",
    environment="production",
    release="magaza-api@2.4.0",
    traces_sample_rate=0.1,
)

def fiyat_hesapla(toplam, adet):
    return toplam / adet

fiyat_hesapla(250, 0)

Bu kodda DSN, olayların gideceği projeyi belirtir. environment üretim ve test kayıtlarını ayırır; release ise hatanın hangi sürümde başladığını bulmayı kolaylaştırır. traces_sample_rate=0.1, performans işlemlerinin yaklaşık yüzde 10’unu örnekler. Ürün ve sürüme göre desteklenen SDK özellikleri değişebileceğinden uyumluluk belgeleri kontrol edilmelidir.

Hangisini seçmeli?

Hazır servis, gelişmiş analiz ve minimum bakım istiyorsanız Sentry mantıklı başlangıçtır. Veriyi kendi altyapınızda tutmak, açık kaynak kullanmak ve daha ölçülü kaynak tüketmek istiyorsanız GlitchTip değerlendirilebilir. Yalnızca temel hata toplama, gruplama ve bildirim özelliklerine ihtiyacınız varsa Bugsink sadeliğiyle öne çıkar.

Seçimden önce günlük olay hacmini, saklama süresini ve örnekleme oranını hesaplayın. Ayrıca parola, erişim belirteci ve kişisel veri gibi hassas bilgileri SDK filtreleriyle temizleyin. Çünkü iyi bir hata takip sistemi yalnızca çok veri toplayan değil, doğru veriyi güvenli biçimde anlamlı hale getiren sistemdir.

Bir güvenlik araştırmacısı kritik bir açık bulduğunda kime, nasıl ve hangi kanıtlarla ulaşacağını bilmelidir. Open Bug Bounty veya HackerOne benzeri özel bir sistem; araştırmacıları, güvenlik ekiplerini ve ürün sahiplerini aynı iş akışında buluşturur. Fakat bu proje, sıradan bir destek talebi uygulamasından daha fazlasıdır: hassas verileri korumalı, mükerrer raporları yakalamalı ve kontrollü açıklama sürecini yönetmelidir. ``

Temel iş akışı

Bir raporun yaşam döngüsü durum makinesi olarak modellenebilir:

Taslak → Gönderildi → İnceleniyor → Doğrulandı → Çözüldü → Açıklandı

Rapor geçersizse Reddedildi, daha önce bildirilmişse Mükerrer durumuna taşınır. Durum makinesi kullanmak, örneğin çözülmüş bir raporun yanlışlıkla yeniden “gönderildi” yapılmasını engeller.

Bu ayrım, en az ayrıcalık ilkesi üzerine kurulmalıdır. Yalnızca giriş yapmış olmak yeterli değildir; her API isteğinde rol, kaynak sahipliği ve program üyeliği ayrıca denetlenmelidir.

Önem derecesi ve ödül hesabı

Açıkların önceliği CVSS gibi standartlarla belirlenebilir. Daha sade bir özel puanlama için şu model kullanılabilir:

Her değişken 1 ile 5 arasında seçilirse en yüksek risk puanı $5^3 = 125$ olur. Ödül ise taban tutar ve risk oranıyla hesaplanabilir:

Ancak otomatik sonuç yalnızca öneri olmalıdır. Kaliteli açıklama, çalışan kavram kanıtı ve daha önce raporlanmış olma durumu nihai kararı değiştirebilir.

Veri modeli ve güvenlik

Temel tablolar users, programs, assets, reports, comments, attachments, rewards ve audit_logs olabilir. Rapor; başlık, etkilenen varlık, açıklık türü, tekrar üretme adımları, etki açıklaması ve çözüm önerisi içermelidir.

Kanıt dosyaları doğrudan herkese açık klasörlere konulmamalıdır. Nesne depolamada şifrelenmeli, kısa ömürlü imzalı bağlantılarla sunulmalı ve zararlı dosya taramasından geçirilmelidir. Parolalar Argon2id ile özetlenmeli; oturumlarda çok faktörlü kimlik doğrulama desteklenmelidir. Audit log kayıtları da “kim, neyi, ne zaman değiştirdi?” sorusunu yanıtlamalıdır.

Güvenli durum geçişi örneği

Aşağıdaki FastAPI kodu, istemcinin istediği her duruma serbestçe geçmesini engeller:

from enum import Enum
from fastapi import FastAPI, HTTPException

app = FastAPI()

class Status(str, Enum):
    submitted = "submitted"
    triage = "triage"
    confirmed = "confirmed"
    resolved = "resolved"
    rejected = "rejected"

ALLOWED = {
    Status.submitted: {Status.triage, Status.rejected},
    Status.triage: {Status.confirmed, Status.rejected},
    Status.confirmed: {Status.resolved},
    Status.resolved: set(),
    Status.rejected: set()
}

@app.post("/reports/{report_id}/transition")
def transition(report_id: int, current: Status, target: Status):
    if target not in ALLOWED[current]:
        raise HTTPException(409, "Geçersiz durum geçişi")

    # Burada rol kontrolü ve veritabanı güncellemesi yapılır.
    return {"report_id": report_id, "status": target}

Gerçek uygulamada current değeri kullanıcıdan alınmamalı, veritabanından okunmalıdır. Güncelleme atomik bir işlem içinde yapılmalı ve audit log kaydı aynı işlemde oluşturulmalıdır.

Sistemi olgunlaştıran özellikler

Mükerrer rapor tespiti için başlık benzerliği, açıklık türü ve etkilenen varlık birlikte değerlendirilebilir; ancak gizlilik nedeniyle araştırmacıya başka raporun ayrıntıları gösterilmemelidir. Bildirimler e-posta ve uygulama içi kanallardan iletilebilir. Oran sınırlama, CAPTCHA ve kötüye kullanım tespiti de spam saldırılarını azaltır.

Son olarak açık bir kapsam politikası hazırlayın: test edilebilen alan adları, yasak yöntemler, hizmet kesintisi kuralları, yanıt süreleri ve güvenli liman şartları net olsun. İyi bir bug bounty platformunun asıl süper gücü yalnızca kodu değil, araştırmacıyla kurulan güveni de korumasıdır.

``

Önce temel kavramlar

Kimlik doğrulama (authentication), kullanıcının kim olduğunu kanıtlamasıdır. Yetkilendirme (authorization) ise doğrulanan kullanıcının hangi kaynaklara erişebileceğini belirler. Kısaca ilk soru “Sen kimsin?”, ikinci soru “Burada ne yapabilirsin?” şeklindedir.

Modern sistemlerde parola her uygulamaya gönderilmez. Kullanıcı bir Kimlik Sağlayıcıya (Identity Provider veya IdP) yönlendirilir. Başarılı girişten sonra uygulamaya imzalı bir token verilir. Basitleştirilmiş güven modeli şöyle ifade edilebilir:

Token içinde kullanıcı kimliği, roller ve geçerlilik süresi gibi talepler bulunur. Bir tokenın kullanılabilirliği kabaca şu koşula bağlıdır:

OpenID Connect (OIDC) kimlik bilgisini OAuth 2.0 üzerine ekler. SAML daha çok kurumsal ve eski sistemlerde görülürken LDAP merkezi kullanıcı dizini görevi üstlenir.

Üç adayın karşılaştırması

Keycloak, realm, client, rol, grup ve identity brokering özellikleriyle adeta kimlik yönetiminin İsviçre çakısıdır. Büyük organizasyonlar ve karmaşık rol modelleri için güçlüdür; buna karşılık kurulumu ve işletimi daha fazla dikkat ister.

Authentik, akış tabanlı yaklaşımı ve modern arayüzüyle daha yumuşak bir öğrenme eğrisi sunar. OIDC, SAML, LDAP ve proxy provider seçeneklerini aynı merkezde toplar. Ev laboratuvarları ile büyüyen ekipler arasında güzel bir köprü kurar.

Authelia ise özellikle Nginx, Traefik veya Caddy arkasındaki uygulamalara giriş ekranı ve çok faktörlü doğrulama eklemek için hafif bir çözümdür. Tam teşekküllü kurumsal IdP yerine güvenlik kapısı gibi düşünülmelidir.

Basit bir OIDC istemcisi

Bir uygulamanın sağlayıcıyı keşfetmesi çoğunlukla standart bir adres üzerinden gerçekleşir:

const issuer = "https://kimlik.example.com/realms/ekip";

const oidcConfig = {
  authority: issuer,
  client_id: "blog-paneli",
  redirect_uri: "https://panel.example.com/callback",
  response_type: "code",
  scope: "openid profile email"
};

Bu yapılandırma uygulamanın hangi IdP’ye bağlanacağını, dönüş adresini ve talep ettiği kullanıcı bilgilerini belirtir. authorization code akışı kullanılmalı; tarayıcı tabanlı istemcilerde ayrıca PKCE etkinleştirilmelidir. Böylece ele geçirilen yetkilendirme kodunun başka bir istemci tarafından kullanılması zorlaşır.

Güvenli kurulum kontrol listesi

• Yönetici hesabında çok faktörlü doğrulamayı etkinleştirin.
• Yalnızca HTTPS kullanın ve yönlendirme adreslerini kesin tanımlayın.
• Token ömrünü gereksiz yere uzun tutmayın.
• Servis hesaplarına en az ayrıcalık ilkesini uygulayın.
• Veritabanı, anahtarlar ve yapılandırmalar için düzenli yedek alın.
• Giriş denemelerini ve yönetici işlemlerini merkezi olarak kaydedin.

Sonuç olarak karmaşık kurumsal federasyon için Keycloak, modern arayüz ve esnek self-hosted deneyim için Authentik, ters proxy arkasındaki servisleri hızlıca korumak için Authelia öne çıkar. En iyi ürün, en uzun özellik listesine sahip olan değil; ekibinizin güvenle işletebildiği ve düzenli güncelleyebildiği üründür.

``

Online derleyici nasıl çalışır?

Bir online derleyici temel olarak kaynak kodunu ve kullanıcı girdisini alır, uygun çalışma ortamını seçer ve işlemi yalıtılmış bir alanda yürütür. Derlenen dillerde süreç genellikle şu şekildedir:

Python gibi yorumlanan dillerde derleme adımı görünür olmayabilir; ancak ortam hazırlama ve süreç başlatma maliyeti devam eder. Sistem, çalıştırma sonunda standart çıktıyı, standart hatayı, durum kodunu, süreyi ve bellek tüketimini döndürür.

Yalıtım kritik önemdedir. Kullanıcının gönderdiği kod sonsuz döngüye girebilir, dosya sistemini kurcalayabilir veya bir fork bombası başlatmayı deneyebilir. Bu nedenle container, namespace, cgroup, seccomp ve ayrıcalıksız kullanıcı gibi mekanizmalar kullanılır. Basitleştirilmiş bir kaynak koşulu şöyledir:

Bu sınırlardan biri aşılırsa çalıştırma sonlandırılır. Kısacası sistem yalnızca kodu çalıştırmaz; ona güvenli bir oyun alanı da çizer.

Üç sistemin karakteri

Judge0

Judge0, özellikle otomatik değerlendirme sistemlerine yakışır. Bir gönderim oluşturur, dil kimliğini, kaynak kodunu ve girdiyi iletirsiniz. Sonucu eşzamanlı alabilir veya daha ölçeklenebilir biçimde bir token üzerinden sorgulayabilirsiniz. Zaman ve bellek sınırları, derleme çıktısı ve çalışma durumu gibi alanlar eğitim platformları için oldukça değerlidir.

Piston

Piston, farklı dillerde kod çalıştırmayı anlaşılır bir HTTP API arkasında toplar. Dil paketleri ve sürümleri yönetilebilir; bu da onu web tabanlı editörler, Discord botları veya hızlı prototipler için çekici yapar. Judge0 kadar yarışma odaklı bir değerlendirme modeli sunmak yerine, “kodu ver, çıktıyı al” deneyimine yaklaşır.

Aşağıdaki JavaScript örneği, Piston uyumlu bir uç noktaya Python kodu gönderir:

const response = await fetch("https://example.com/api/v2/execute", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    language: "python",
    version: "3.x",
    files: [{ content: "print(sum([4, 8, 15, 16, 23, 42]))" }]
  })
});

const result = await response.json();
console.log(result.run.stdout);

Kod, çalıştırılacak dosyayı JSON gövdesine yerleştirir ve dönen standart çıktıyı gösterir. Gerçek sürüm değeri ile uç nokta, kullandığınız Piston kurulumundan sorgulanmalıdır.

Wandbox

Wandbox özellikle C++ dünyasında farklı derleyicileri, sürümleri ve bayrakları karşılaştırırken parlar. Aynı kodu GCC ve Clang ile deneyip standart sürümünü değiştirmek, taşınabilirlik sorunlarını yakalamayı kolaylaştırır. Bu nedenle klasik bir sınav motorundan çok etkileşimli bir derleyici laboratuvarına benzer.

Hangisini seçmelisiniz?

Otomatik puanlama, test senaryoları ve ayrıntılı durum yönetimi istiyorsanız Judge0 güçlü adaydır. Küçük ve anlaşılır bir kod çalıştırma servisi arıyorsanız Piston daha rahat hissettirebilir. Derleyici sürümleri ve bayraklarla deney yapacaksanız Wandbox öne çıkar.

Hangi sistemi seçerseniz seçin API’yi doğrudan sınırsız biçimde internete açmayın. Kimlik doğrulama, istek kotası, çıktı boyutu sınırı, zaman aşımı ve düzenli imaj güncellemeleri ekleyin. Çünkü online derleyicide en zor soru “Kod çalıştı mı?” değil, “Kod çalışırken sunucu hâlâ güvende mi?” sorusudur.

Her hesapta aynı parolayı kullanmak, bütün kapıları tek anahtarla kilitlemeye benzer: Anahtar ele geçirilirse mahallede açık kapı bırakmazsınız. Şifre yöneticileri; güçlü parolalar üretir, bunları şifreli bir kasada saklar ve cihazlar arasında eşitler. Peki popüler Bitwarden, hafifliğiyle öne çıkan Vaultwarden ve ekip odaklı Passbolt arasında nasıl seçim yapılır? Gelin dijital anahtarlığımızı masaya yatıralım.

``

Şifre yöneticisinin temel mantığı

Bir şifre yöneticisi, kayıtlarınızı ana paroladan türetilen bir anahtarla şifreler. Güvenilir sistemlerde sunucu kasanın açık hâlini veya ana parolayı bilmez; şifre çözme işlemi istemci cihazda gerçekleşir. Bu yaklaşım genellikle sıfır bilgi mimarisi olarak adlandırılır.

Rastgele üretilmiş bir parolanın teorik entropisi yaklaşık olarak şöyle hesaplanır:

Burada $L$ parola uzunluğu, $N$ ise kullanılabilecek karakter sayısıdır. Örneğin 94 karakterlik bir kümeden üretilen 20 karakterli parola yaklaşık $20 \times \log_2(94) \approx 131$ bit entropiye sahiptir. İnsan zihninin ürettiği Kedim123 benzeri parolalarda ise tahmin edilebilir kalıplar nedeniyle gerçek güvenlik çok daha düşüktür.

Ana parola güçlü ve benzersiz olmalı; ayrıca kasada iki faktörlü kimlik doğrulama etkinleştirilmelidir. Kasayı kendi sunucunuza kurmak kontrol sağlar, fakat bakım sorumluluğunu ortadan kaldırmaz.

Üç çözümün karşılaştırması

Bitwarden: Güvenli varsayılan seçenek

Bitwarden; mobil uygulamaları, tarayıcı eklentileri, masaüstü istemcileri ve komut satırı aracıyla eksiksiz bir ekosistem sunar. Teknik bakım yapmak istemeyen kullanıcılar resmî bulutu seçebilir. Kurumlar ise organizasyonlar, koleksiyonlar ve erişim politikalarıyla kayıtları yönetebilir.

Self-hosted kurulumu mümkündür; ancak resmî sunucu bileşenleri küçük bir ev sunucusu için ağır gelebilir. Buna karşılık resmî destek ve belgeler, kurumsal kullanımda önemli avantajdır.

Vaultwarden: Küçük sunucunun çalışkan cücesi

Vaultwarden, Bitwarden sunucu API’sinin topluluk tarafından geliştirilen ve Rust ile yazılan uyumlu bir uygulamasıdır. Resmî Bitwarden istemcileriyle çalışır ve düşük kaynak tüketimi sayesinde Raspberry Pi, mini PC veya uygun bir VPS üzerinde sıkça tercih edilir.

Basitleştirilmiş bir Docker Compose servisi şöyle tanımlanabilir:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    volumes:
      - ./vw-data:/data
    ports:
      - 127.0.0.1:8080:80

Bu yapı verileri kalıcı dizinde tutar ve servisi yalnızca yerel arayüzde açar. Dış erişim için HTTPS sağlayan bir ters vekil, düzenli güncelleme ve şifreli yedekleme gerekir. Vaultwarden resmî Bitwarden sunucusu değildir; özellik uyumluluğu ve destek beklentisi buna göre değerlendirilmelidir.

Passbolt: Takım paylaşımının uzmanı

Passbolt özellikle sistem yöneticileri, ajanslar ve geliştirici ekipleri için tasarlanmıştır. Kayıtların kullanıcı veya gruplarla kontrollü paylaşılması, erişimlerin kaldırılması ve değişikliklerin izlenmesi temel senaryolardır. OpenPGP tabanlı yaklaşımı nedeniyle anahtar yönetimi önemli bir rol oynar.

Kişisel otomatik doldurma deneyimi önceliğinizse Bitwarden ailesi daha doğal gelebilir. Çok sayıda çalışanın ortak altyapı parolalarına farklı yetkilerle erişmesi gerekiyorsa Passbolt daha anlamlıdır.

Hangisini seçmelisiniz?

Bakım istemeyen bireyler için Bitwarden bulutu, düşük kaynaklı kendi sunucusunu yönetecek meraklılar için Vaultwarden, ekip paylaşımını merkeze alan kuruluşlar için Passbolt güçlü adaylardır. Hangi aracı seçerseniz seçin; güçlü ana parola, MFA, HTTPS, güncelleme ve test edilmiş yedekler vazgeçilmezdir. Unutmayın: Self-hosted sistem otomatik olarak daha güvenli değil, yalnızca güvenlik sorumluluğunun adresi farklıdır.

Bir sunucunun çalışıyor görünmesi, sağlıklı olduğu anlamına gelmez. İşlemci tavana vurmuş, disk dolmak üzere veya ağ gecikmesi kullanıcıları çileden çıkarıyor olabilir. Sunucu izleme sistemleri; altyapının nabzını ölçer, sorunları görünür hâle getirir ve gece telefonunuz çalmadan önce sizi uyarır. Bu alandaki üç güçlü seçenek Zabbix, Nagios ve Checkmk’tir. ``

İzleme sistemlerinin temel mantığı

Bir izleme platformu belirli aralıklarla metrik toplar. CPU kullanımı, boş disk alanı, bellek tüketimi ve HTTP yanıt süresi bu metriklere örnektir. Toplanan değerler önceden belirlenmiş eşiklerle karşılaştırılır; şart sağlandığında olay oluşturulur ve bildirim gönderilir.

Basit bir CPU kullanım oranı şöyle hesaplanabilir:

Ancak tek bir yüksek ölçüm her zaman sorun değildir. Kısa süreli sıçramaları filtrelemek için hareketli ortalama kullanılabilir:

Örneğin son beş ölçümün ortalaması yüzde 90’ı geçerse alarm üretmek, anlık bir yükselişte gereksiz bildirim almaktan daha mantıklıdır. Aksi hâlde izleme sistemi yardımcı olmak yerine dijital bir yangın alarmına dönüşür.

Üç aracın hızlı karşılaştırması

Zabbix: Her şey tek çatı altında

Zabbix; metrik toplama, grafik çizme, alarm üretme, otomatik keşif ve raporlama özelliklerini birlikte sunar. Agent kullanarak işletim sisteminden ayrıntılı veri alabilir; SNMP, IPMI, JMX ve HTTP kontrolleriyle farklı cihazları izleyebilir.

Linux sunucuya kurulan agent’ın temel durumunu şu komutlarla kontrol edebilirsiniz:

sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2

İlk komut servisi başlatıp sistem açılışına ekler; ikincisi agent’ın düzgün çalışıp çalışmadığını gösterir. Zabbix özellikle merkezi gösterge panelleri ve geçmiş veriler üzerinden kapasite planlaması isteyen ekipler için başarılıdır.

Nagios: Eklentilerle büyüyen klasik

Nagios, izleme dünyasının deneyimli ustasıdır. Temel felsefesi basittir: Bir eklenti kontrol gerçekleştirir ve durum kodu döndürür. 0 başarılı, 1 uyarı, 2 kritik, 3 ise bilinmeyen durum anlamına gelir.

Örneğin disk kullanımını denetleyen bir eklenti şöyle çağrılabilir:

/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /

Bu kontrol, kök bölümde boş alan yüzde 20’nin altına inince uyarı, yüzde 10’un altına inince kritik durum üretir. Nagios son derece esnektir; ancak eklenti ve yapılandırma yönetimi büyüyen ortamlarda ciddi emek isteyebilir.

Checkmk: Otomasyon sevenlerin seçeneği

Checkmk, Nagios ekosisteminin kontrol mantığından yararlanırken keşif, yapılandırma ve görselleştirme süreçlerini kolaylaştırır. Tek bir agent çıktısından yüzlerce servisi otomatik keşfedebilir. Bu özellik, çok sayıda benzer sunucuyu yöneten ekiplerin tekrar eden işlerini azaltır.

Kural tabanlı yapılandırma sayesinde aynı disk eşiğini her sunucu için ayrı ayrı yazmak yerine sunucu gruplarına uygulayabilirsiniz. Raw Edition açık kaynak odaklıdır; Enterprise Edition ise daha gelişmiş performans ve kurumsal özellikler sunar.

Hangisini seçmelisiniz?

Hazır grafikler, geniş protokol desteği ve bütünleşik deneyim istiyorsanız Zabbix güçlü bir tercihtir. Kontrolleri tamamen özelleştirmek ve geniş eklenti ekosisteminden yararlanmak istiyorsanız Nagios uygundur. Hızlı keşif, kolay yönetim ve düşük operasyon yükü önceliğinizse Checkmk öne çıkar.

Son kararı özellik listesinden önce ekibinizin deneyimi, izlenecek cihaz sayısı ve alarm yönetimi ihtiyacı belirlemelidir. Çünkü en iyi izleme sistemi, en fazla grafiği çizen değil; doğru sorunu, doğru kişiye, doğru zamanda bildiren sistemdir.

``

Uptime ölçümü nasıl çalışır?

Bir monitör, hedef servise belirli aralıklarla istek gönderir. HTTP kontrolünde durum kodu, yanıt süresi ve içerik doğrulanabilir. TCP kontrolü portun erişilebilirliğini, ICMP kontrolü ise sunucunun ağa yanıt verip vermediğini ölçer.

Belirli bir dönemde uptime oranı şu şekilde hesaplanır:

Örneğin 30 günlük bir ayda 43 dakika kesinti yaşayan servisin erişilebilirliği yaklaşık $99{,}9\%$ olur. Kontrol aralığı da önemlidir: Beş dakikada bir yapılan kontrol, iki dakikalık kesintiyi hiç yakalamayabilir. Kısa aralıklar daha hassastır ancak daha fazla ağ trafiği ve kayıt üretir.

Sistemin yanlış alarm vermemesi için genellikle art arda birkaç başarısız kontrol beklenir. Üç denemeden sonra alarm üretmek, geçici paket kayıplarının gece yarısı telefonunuzu çaldırmasını önler.

Üç aracın kısa karşılaştırması

Uptime Kuma, şık paneli ve kolay kurulumu sayesinde hızlı başlangıç şampiyonudur. HTTP, TCP, DNS, ping ve Docker container kontrollerini destekler. Telegram, Slack, Discord ve e-posta gibi pek çok bildirim kanalı sunar.

Statping-ng, servis takibiyle herkese açık durum sayfasını bir arada isteyenler için uygundur. Kullanıcılar planlı bakımları ve geçmiş olayları görebilir. Ancak proje sürümünü seçerken güncel bakım durumunu ve açık sorunları incelemek akıllıca olur.

Gatus, arayüzde tıklamak yerine yapılandırmayı kod olarak saklar. Pull request ile kontrol eklemek, değişiklik geçmişini görmek ve aynı ayarı farklı ortamlara taşımak isteyen ekiplerin gözdesidir.

Uptime Kuma kurulumu

Docker ile birkaç dakikada çalışan bir sistem oluşturabiliriz:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - ./kuma-data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

Bu dosya verileri kuma-data dizininde kalıcı tutar ve paneli 3001 numaralı porttan yayımlar. docker compose up -d komutundan sonra paneli açıp yönetici hesabı oluşturabilir, ardından “Add New Monitor” üzerinden hedeflerinizi ekleyebilirsiniz. İnternete açarken ters proxy, HTTPS ve güçlü kimlik doğrulama kullanmayı unutmayın.

Gatus ile yapılandırma tabanlı takip

Aşağıdaki örnek, API’nin hem başarılı durum kodu döndürmesini hem de 500 milisaniyeden hızlı yanıt vermesini bekler:

endpoints:
  - name: production-api
    group: backend
    url: "https://api.example.com/health"
    interval: 30s
    conditions:
      - "[STATUS] == 200"
      - "[RESPONSE_TIME] < 500"

Bu yaklaşımda sağlık şartları açıkça belgelenir. Dosyayı Git deposuna koyarak yapılan her eşik değişikliğini inceleyebilirsiniz. Gatus ayrıca yanıt gövdesi, sertifika süresi ve DNS gibi kontrolleri de koşullara bağlayabilir.

Hangisini seçmelisiniz?

Ev laboratuvarı, kişisel projeler veya hızlı kurulum için Uptime Kuma en pratik seçimdir. Markalı ve ziyaretçilere yönelik bir durum sayfası öncelikliyse Statping-ng değerlendirilebilir. Altyapınız GitOps mantığıyla yönetiliyor ve kontrollerin kod incelemesinden geçmesini istiyorsanız Gatus daha doğal hissettirir.

Hangi aracı seçerseniz seçin, takip sistemini izlediği sunucudan farklı bir makinede çalıştırın. Aksi hâlde sunucu çöktüğünde hem uygulama hem de alarm mekanizması ortadan kaybolur; dijital bekçi de bina ile birlikte uykuya dalar!