Üretim Kurulumu Kontrol Listesi

Bu rehber, çalışan bir Knowentra kurulumunu üretime kabul edilebilir hâle getirmek için teknik ve operasyonel kontrolleri sıralar. Amaç yalnızca servislerin “ayakta” olması değil; kimlik, veri, model, workflow ve dış sistem etkilerinin güvenli, izlenebilir ve geri döndürülebilir olduğunu kanıtlamaktır.

Bu kontrol listesi nasıl kullanılmalı?

Her madde için yalnızca “tamamlandı” işareti koymak yerine bir sahip, kanıt ve tarih belirleyin:

Koşullu kabul edilen her maddenin risk sahibi, son tarihi ve geçici kontrolü bulunmalıdır. “Daha sonra bakılacak” ifadesi üretim kabul kararı değildir.

Faz 0 — Kapsam ve sahiplik

• Üretime alınacak Knowentra sürümü ve image digest'leri sabitlendi.
• Dağıtım modeli: kurum içi, özel bulut, hibrit veya air-gapped olarak belgelendi.
• Üretim, staging ve geliştirme ortamları ayrıldı.
• Uygulama, veritabanı, vektör deposu, obje deposu, model, gateway ve workflow sahipleri belli.
• Veri sahibi, güvenlik sahibi ve iş süreci sahibi atandı.
• RPO, RTO, kullanılabilirlik hedefi ve bakım penceresi onaylandı.
• Destek ve olay eskalasyon zinciri iletişim bilgileriyle kaydedildi.
• Üçüncü taraf model ve connector'lar için sözleşmesel/onaylı kullanım kapsamı belirlendi.

Üretim kabul kapıları

Faz 1 — Artefact ve tedarik zinciri

Üretime giren her uygulama, model ve bağımlılığın kaynağı doğrulanabilmelidir.

• Container image'ları değişken etiket yerine digest veya immutable sürümle sabitlendi.
• Image ve offline paket checksum/imzaları doğrulandı.
• Kullanılan bileşenler için SBOM saklandı.
• Kritik ve yüksek zafiyetler tarandı; istisnalar süreli risk kaydıyla onaylandı.
• Base image, işletim sistemi ve runtime destek yaşam döngüsü incelendi.
• Model dosyasının kaynağı, lisansı, sürümü ve checksum'ı kaydedildi.
• Üretim registry'sinde yalnızca onaylı artefact'lara izin veriliyor.
• Build ve deploy yetkileri ayrıldı; yayın işlemi audit ediliyor.

Yayın manifest'i

Bir yayın kaydı en az şu bilgileri taşımalıdır:

Knowentra sürümü:
Uygulama image digest:
Workflow servisi sürümü:
LLM Secure Gateway sürümü:
Guardrail/politika paketi sürümü:
Veritabanı migration sürümü:
Model ve embedding sürümleri:
Connector paket sürümleri:
Konfigürasyon revision:
Değişiklik kaydı:
Geri dönüş hedefi:

Bu kayıt, olay sırasında “hangi kod ve politika çalışıyordu?” sorusunu tek yerden yanıtlayabilmelidir.

Faz 2 — Ağ, DNS ve TLS

• Kullanıcı trafiği yalnızca reverse proxy veya ingress üzerinden geliyor.
• Uygulama, veritabanı, Redis, vektör deposu ve workflow yönetim portları internete açık değil.
• Her servis akışı kaynak, hedef, protokol, port ve amaçla kayıtlı.
• Outbound trafik varsayılan kapalı; model ve connector hedefleri allowlist ile sınırlandı.
• Yönetim erişimi ayrı ağ, VPN, bastion veya eşdeğer kontrol üzerinden sağlanıyor.
• İç ve dış DNS adları, sertifika SAN'ları ve uygulama callback URL'leri birbiriyle uyumlu.
• TLS 1.2 veya üzeri kullanılıyor; zayıf şifre kümeleri kapalı.
• İç servislerde hassas trafik için mTLS veya doğrulanmış servis kimliği değerlendirildi.
• Sertifika yenileme otomatik veya alarmlı; süresi dolma senaryosu test edildi.
• Proxy body-size ve timeout değerleri belge yükleme ve uzun isteklerle test edildi.

Ağ akışı kabul kanıtı

Firewall kuralı yalnızca kâğıt üzerinde incelenmemelidir:

1. İzinli kullanıcı ağından uygulamaya erişin.
2. Yasaklı segmentten aynı erişimin engellendiğini doğrulayın.
3. Uygulama pod/container'ından yalnızca izinli model ve connector hedeflerini test edin.
4. Veritabanı ve dahili servis portlarının kullanıcı ağından erişilemediğini doğrulayın.
5. DNS veya sertifika hatasında sistemin güvenli biçimde başarısız olduğunu kaydedin.

Faz 3 — Secret ve anahtar yönetimi

• Oturum imzalama, uygulama şifreleme ve dahili API secret'ları güçlü ve benzersiz üretildi.
• Geliştirme varsayılanları ve örnek parolalar tamamen kaldırıldı.
• Secret'lar image, repository, workflow tanımı veya düz metin log içinde bulunmuyor.
• Secret değerleri merkezi kasa, orchestrator secret'ı veya eşdeğer güvenli mekanizmadan geliyor.
• Veritabanı, connector ve model credential'ları farklı amaçlar için ayrıldı.
• Credential kapsamları en az ayrıcalıkla sınırlandı.
• Secret okuma ve değiştirme yetkileri audit ediliyor.
• Rotasyon sırası ve eski anahtarla şifrelenmiş verinin geçiş yöntemi test edildi.
• Acil credential iptal prosedürü ve sorumlusu belli.
• Yedeklerdeki secret ve şifreleme anahtarları ayrı koruma alanlarında tutuluyor.

Faz 4 — Kimlik ve yetkilendirme

• Üretim ortamı kurumsal IdP'ye OIDC veya SAML ile bağlı.
• Redirect/callback URL'leri yalnızca üretim domain'lerini içeriyor.
• MFA ve şartlı erişim politikaları yönetici hesaplarında zorunlu.
• Break-glass hesapları sınırlı, izlenen ve periyodik test edilen biçimde hazır.
• Organizasyon, departman, Space ve roller gerçek yetki modeline göre oluşturuldu.
• İlk yönetici hesabı paylaşımlı değil ve günlük kullanım için kullanılmıyor.
• İşe giriş, rol değişikliği ve işten ayrılma süreçleri kullanıcı yaşam döngüsüne bağlı.
• Oturum süresi, yenileme, iptal ve eşzamanlı oturum politikaları belirlendi.
• Servis hesapları insan hesaplarından ayrıldı ve interaktif giriş yapamıyor.
• Negatif yetki testleri yapıldı: başka organizasyon, departman ve Space verisine erişilemiyor.

Faz 5 — Stateful servisler

İlişkisel veritabanı

• Üretim parolası varsayılan değil; yalnızca uygulama ve yetkili yönetim ağı erişebiliyor.
• Kalıcı disk, at-rest encryption ve kapasite alarmı yapılandırıldı.
• Connection pool toplamı veritabanı limitleriyle uyumlu.
• Migration işi uygulamadan kontrollü ve tekil biçimde çalışıyor.
• Otomatik yedekleme, point-in-time recovery ve restore testi mevcut.
• Replika/failover kullanılıyorsa uygulamanın davranışı test edildi.
• Uzun sorgu, connection kullanımı, lock ve replication lag izleniyor.

Dosya veya obje deposu

• Bucket/container public değil.
• Uygulama erişimi dar servis kimliğiyle sağlanıyor.
• Sürümleme, yaşam döngüsü ve silme politikası veri sınıfına uygun.
• Yüklenen dosyalar boyut, tür ve zararlı içerik açısından kontrol ediliyor.
• Yarım kalan yükleme ve orphan obje temizleme süreci tanımlı.
• Yedek/replica bölgesi veri yerleşimi kararına uygun.

Vektör deposu

• Ağ erişimi uygulama/worker katmanıyla sınırlandı.
• Organizasyon, departman ve Space filtreleri retrieval sorgularında test edildi.
• İndeks ve embedding modeli sürümü birlikte izleniyor.
• Kaynak belge silindiğinde chunk ve embedding yaşam döngüsü doğrulandı.
• Yeniden indeksleme yöntemi ve tahmini süresi ölçüldü.
• Sorgu gecikmesi, indeks boyutu ve başarısız yazmalar izleniyor.

Redis, queue ve realtime

• Redis kullanılıyorsa kimlik doğrulama, TLS ve ağ izolasyonu açık.
• Cache verisi ile kalıcı iş durumunun farkı belgelenmiş.
• TTL, eviction ve memory limitleri beklenen davranışa göre ayarlı.
• Queue retry, backoff ve dead-letter politikası tanımlı.
• Birden fazla instance varsa socket/realtime koordinasyonu test edildi.
• Redis kaybının hangi işlerin tekrarına veya oturum sonlanmasına yol açacağı biliniyor.

Faz 6 — Model, embedding ve LLM güvenliği

• İzin verilen model sağlayıcıları ve model kimlikleri allowlist'e alındı.
• Yerel model endpoint'i kullanıcı ağından doğrudan erişilebilir değil.
• Harici model API anahtarı yalnızca gateway/router katmanında bulunuyor.
• LLM Secure Gateway harici egress'ten önce konumlandırıldı.
• Organizasyon temel politikası ve departman sıkılaştırmaları test edildi.
• Politika servisi erişilemediğinde harici çağrı korumayı atlamıyor.
• Geri döndürülebilir maskelemede token eşlemesi dar süre ve kapsamda saklanıyor.
• Guardrail'in girdi, çıktı veya ikisinde hangi kontrolleri yaptığı belgeli.
• Prompt ve model yanıtı loglarında hassas veri politikası uygulanıyor.
• Timeout, retry, rate limit ve provider kesintisi davranışı test edildi.
• Model fallback yalnızca veri politikası aynı hedefe izin veriyorsa devreye giriyor.
• Embedding verisinin harici servise çıkıp çıkmadığı mimari kayıtta açık.

Model kabul testleri

En az şu senaryoları kayıt altına alın:

Faz 7 — Knowledge Hub ve connector'lar

• Üretim bilgi kaynakları veri sahibi tarafından onaylandı.
• İlk senkronizasyon dar ve geri alınabilir bir kaynak kapsamıyla yapıldı.
• Connector credential'ı mümkünse salt-okunur ve ayrı servis hesabına ait.
• Senkronizasyon checkpoint'i, retry ve rate-limit davranışı doğrulandı.
• Kaynak silme ile Knowentra indeksinden silme davranışı belgelendi.
• Belge ACL veya Space sınırlarının retrieval'a yansıdığı negatif testlerle gösterildi.
• Ayrıştırılamayan, şifreli veya bozuk dosyalar görünür hata üretiyor.
• Chunk/embedding kuyruğu ve başarısız işler izleniyor.
• İlk tam senkronizasyonun kaynak sisteme oluşturduğu yük ölçüldü.
• Connector webhook'larında imza, replay koruması ve payload limiti var.

Faz 8 — Agent ve workflow güvenliği

• Üretime yalnızca yayınlanmış ve sürümü sabitlenmiş agent/workflow tanımları çıkıyor.
• Agent yalnızca açıkça atanmış bilgi kaynaklarını ve araçları görebiliyor.
• Model tarafından üretilen araç argümanları sunucu tarafında şema doğrulamasından geçiyor.
• Yazma veya silme etkili işlemler için onay ve işlem sahibi belirlendi.
• Credential erişimi agent adıyla değil gerçek kullanıcı/servis bağlamıyla sınırlandı.
• Workflow timeout, retry, backoff ve maksimum çalışma süresi tanımlı.
• Dış sistem yazmalarında idempotency veya tekrar önleme mekanizması var.
• İnsan onayı pause/resume, timeout ve reject senaryolarıyla test edildi.
• Workflow servisi ile Knowentra arasındaki çağrılar dahili servis kimliğiyle doğrulanıyor.
• Tetikleyici webhook'ları imza, audience, süre ve replay kontrolü yapıyor.
• Başarısız workflow yeniden çalıştırıldığında aynı dış etki iki kez oluşmuyor.
• Acil durumda connector, agent veya workflow'u merkezi olarak devre dışı bırakma yolu var.

Faz 9 — Log, audit ve alarm

Uygulama logu ile audit kaydı aynı amaçta değildir. Log operasyonel teşhis sağlar; audit “kim, ne zaman, hangi yetkiyle, ne yaptı?” sorusuna dayanıklı cevap verir.

• Tüm servisler ortak zaman kaynağı ve saat dilimi kullanıyor.
• Correlation/trace kimliği web, model, retrieval, workflow ve connector akışında taşınıyor.
• Oturum açma, rol değişikliği, secret değişimi ve yayınlama audit ediliyor.
• Model sağlayıcısı, agent sürümü, politika sonucu ve araç etkisi ilişkilendirilebiliyor.
• Loglarda token, parola, cookie, API anahtarı veya maskeleme eşlemesi bulunmuyor.
• Audit deposuna yazma erişimi sınırlı; silme/değiştirme işlemleri ayrıca izleniyor.
• Log ve audit saklama süreleri veri politikasıyla uyumlu.
• Kritik alarmın gerçek nöbet kanalına ulaştığı uçtan uca test edildi.

Minimum alarm seti

Faz 10 — Yedekleme ve geri yükleme

• İlişkisel veritabanı, obje deposu, yapılandırma ve şifreleme anahtarı kapsamda.
• Vektör deposunun yedekleneceği mi yeniden üretileceği mi kararlaştırıldı.
• Yedekler üretim credential'ından farklı kimlikle korunuyor.
• Yedekler şifreli, immutable veya değiştirilmeye karşı korumalı.
• Saklama ve coğrafi kopya politikası veri yerleşimiyle uyumlu.
• Restore işlemi izole ortamda düzenli test ediliyor.
• Restore sonrası kullanıcı, belge, indeks, agent ve workflow tutarlılığı doğrulanıyor.
• Ölçülen RPO ve RTO hedeflerle karşılaştırılıyor.
• Fidye yazılımı ve yanlışlıkla silme senaryosu runbook'ta yer alıyor.

Faz 11 — Performans ve kapasite

• Test verisi gerçekçi belge boyutu ve filtre dağılımını temsil ediyor.
• Eşzamanlı chat, retrieval, embedding ve workflow yükü birlikte test edildi.
• P50, P95 ve P99 gecikmeleri ayrı kaydedildi.
• Model token/saniye, queue bekleme ve GPU/CPU bellek kullanımı ölçüldü.
• Connector rate limit altında senkronizasyon penceresi karşılanıyor.
• Veritabanı pool'u, worker sayısı ve downstream limitleri birlikte ayarlandı.
• Büyük dosya ve maksimum context sınırında kontrollü hata davranışı test edildi.
• Bir bağımlılık yavaşladığında retry storm oluşmadığı doğrulandı.
• Kapasite eşiği ve ölçekleme sorumlusu belirlendi.

Faz 12 — Yayın provası ve geri dönüş

1. Üretime benzeyen staging yedeği alın.
2. Mevcut sürümden hedef sürüme migration'ı çalıştırın.
3. Smoke test, yetki testi ve kritik iş senaryolarını tamamlayın.
4. Uyumsuzluk varsa geri dönüş karar eşiğini uygulayın.
5. Uygulama geri alınırken veritabanı şemasının uyumluluğunu doğrulayın.
6. Geri dönüşten sonra veri kaybı ve çift dış sistem etkisi olmadığını kontrol edin.
7. Ölçülen süreyi bakım penceresi ve RTO ile karşılaştırın.

Go / no-go kriterleri

Go kararı için:

• Kritik güvenlik açığı bulunmamalı.
• Restore ve rollback provası hedef süre içinde tamamlanmalı.
• Kimlik, tenant izolasyonu ve yazma etkili workflow testleri geçmeli.
• Kritik alarmlar gerçek sorumlulara ulaşmalı.
• Açık koşullu maddelerin risk sahipleri yazılı olmalı.

No-go gerektiren örnekler:

• Varsayılan veya bilinmeyen secret
• Doğrulanmamış yedek
• Harici modele kontrolsüz veri çıkışı
• Organizasyon/Space sınırı ihlali
• Tekrarda çoğalan finansal veya operasyonel işlem
• Migration için doğrulanmış geri dönüş yolu olmaması

İlk 24 saat ve ilk 30 gün

İlk 24 saat

• Hata oranı, gecikme, kuyruk ve kaynak tüketimini sık aralıklarla izleyin.
• Yeni yetki reddi ve beklenmeyen outbound trafiği inceleyin.
• Connector ve workflow checkpoint'lerini doğrulayın.
• Model kullanımı, maskeleme ve fallback olaylarını örnekleyin.
• Kullanıcı geri bildirimini release kaydıyla ilişkilendirin.

İlk 30 gün

• Kapasite varsayımlarını gerçek kullanım verisiyle güncelleyin.
• Kullanılmayan admin, servis hesabı ve credential'ları temizleyin.
• Alarm eşiklerini gerçek baseline'a göre ayarlayın.
• Restore, anahtar rotasyonu ve break-glass kontrollerini takvime bağlayın.
• Agent ve workflow sahipliklerinin hâlâ geçerli olduğunu doğrulayın.
• Koşullu kabul risklerini kapatın veya yeniden onaylayın.

Üretim kabul özeti

Sonraki adımlar

• Topolojiyi seçmek için Dağıtım Modelleri
• Bileşen sınırları için Platform Mimarisi
• İlk kurulum için Kurulum
• Kimlik tasarımı için Kimlik, SSO ve Yetkilendirme
• Operasyonel devamlılık için Yedekleme, Geri Yükleme ve Felaket Kurtarma