Henüz kamuya açık olmayan operasyon dokümanları

Bu sayfa nasıl okunmalı?

Aşağıdaki maddeler Smart Kubaba'nın çalışmadığı anlamına gelmez; kamuya açık, tekrar çalıştırılabilir ve tarihli üretim prosedürünün henüz tamamlanmadığını gösterir. Her madde hedef release ve topoloji için ayrı kapatılmalıdır.

• Pending etiketi bir özellik durumu değil, dokümantasyon ve kabul kanıtı durumudur.
• İç runbook veya tek seferlik başarı, temiz ortamda ikinci kişi tekrarı olmadan kamuya açık doğrulama sayılmaz.
• Bir alt başlığın kapanması ilişkili bağımlılıkları otomatik kapatmaz; örneğin storage yedeği, veritabanı ve raw SBOM recovery kanıtının yerine geçmez.

Yayımlanması için ek kanıt gerekenler

• Chart dışındaki tüm uygulama ortam değişkenleri ile Tomcat/Docker runtime referansı
• Her format için publish/resolve/proxy komutları, minimum istemci sürümü ve kabul çıktısı
• PostgreSQL, artifact storage ve raw SBOM'u birlikte kapsayan backup/restore sırası ve tutarlılık kontrolü
• Uygulama/Flyway sürüm uyumluluğu ile veri katmanını kapsayan upgrade ve rollback runbook'u
• Incident response ve güvenlik bildirim akışı
• Ölçülmüş kapasite, failover, RTO/RPO ve SLA
• Doğrulanmış air-gapped çalışma profili

Deployment ve runtime referansı

Helm chart kapsamı dışında kalan çalışma zamanı seçenekleri, varsayılanlar ve güvenlik etkileri tek bir sürümlü referansta toplanmalıdır. Değer örnekleri secret içermemeli ve hangi bileşenin her ayarı tükettiğini göstermelidir.

• Ortam değişkeni veya property adı, zorunluluk, varsayılan, veri tipi, örnek placeholder ve yeniden başlatma gereksinimi
• Tomcat/Docker ve Kubernetes çalışma modellerinde port, context path, temp/data yolu, kullanıcı kimliği ve yazılabilir filesystem sınırı
• Secret değerinin kendisi yerine Secret key adı, owner, oluşturma/rotation/revoke akışı ve eksik/bozuk değer davranışı
• Chart, image ve uygulama sürümü arasındaki desteklenen kombinasyon ile temiz kurulum kanıtı

Format ve istemci referans paketleri

Üretimde kullanılacak her paket formatı için Hosted, Proxy ve Group kapsamı ayrı yazılmalı; yalnız gerçek istemciyle alınan sonuç yayımlanmalıdır.

• Format ve istemci adı/sürümü, işletim sistemi, repository tipi ve kimlik doğrulama yöntemi
• Secret içermeyen yapılandırma örneği ile publish, resolve/download, proxy fetch ve gerekiyorsa metadata/search komutları
• Beklenen exit code/çıktı, oluşan server kaydı, checksum ve başarısız kimlik/yetki senaryosu
• Minimum ve kabul edilen istemci sürümleri; protokolün desteklenmeyen veya sınırlı davranışları

Koordineli backup ve recovery runbook'u

PostgreSQL metadata, artifact nesneleri ve raw SBOM verisi aynı recovery point hedefiyle ele alınmalıdır. Yalnız yedek alma değil, boş veya izole bir hedefe geri yükleme ve paket istemcisiyle doğrulama kanıtı gerekir.

• Yazma dondurma veya tutarlılık mekanizması, bileşenlerin yedekleme sırası ve tamamlanma işaretleri
• Şifreleme, erişim, saklama, off-site kopya ve yedek silme sahipliği; credential değerleri dokümana alınmaz
• Boş hedefe restore sırası, migration uyumluluğu, eksik/bozuk parça davranışı ve iptal/yeniden başlatma adımları
• Repository envanteri, artifact sayısı/boyutu/checksum, örnek istemci indirmesi, scan/risk-acceptance ve audit geçmişiyle recovery doğrulaması
• Ölçülen restore süresi ve ulaşılabilen veri noktası kaybı; onay olmadan RTO/RPO taahhüdüne dönüştürülmez

Upgrade ve rollback runbook'u

Uygulama, chart ve Flyway/veri katmanı tek bir değişiklik planında ele alınmalıdır. Rollback ifadesi, geri döndürülemeyen migration veya yeni sürümle yazılmış verinin eski sürümdeki davranışı gösterilmeden yayımlanmamalıdır.

• Desteklenen kaynak/hedef sürüm yolları, ön kontrol, bakım etkisi ve yedek/recovery ön koşulu
• Image/chart digest veya immutable referans, değer farkı, migration sırası ve readiness doğrulaması
• Repository, package client, identity, scan/policy, task ve audit için upgrade sonrası smoke/acceptance seti
• Rollback tetikleyicisi, karar sahibi, veri uyumluluğu sınırı ve ileri düzeltme zorunluysa recovery yolu

Incident response ve güvenlik bildirimi

Kamuya açık akış; güvenlik bildirimini alma, operasyon olayını sınıflandırma ve hassas kanıtı yetkili kişilerle paylaşma sınırlarını ayırmalıdır. Gerçek iletişim adresi ve yanıt hedefi yalnız sahipliği onaylandıktan sonra yayımlanmalıdır.

• Olay kategorileri, severity/öncelik ölçütü, triage sahibi ve mesai dışı escalation yolu
• Log, audit, task, artifact ve SBOM kanıtını koruma; token/credential rotate veya revoke karar noktaları
• Containment, service recovery, bütünlük kontrolü, iç/dış bildirim onayı ve kapanış sonrası inceleme
• Vulnerability disclosure için kapsam, güvenli iletişim kanalı, beklenen araştırmacı davranışı ve yayımlama koordinasyonu

Kapasite, yüksek erişilebilirlik ve hizmet hedefleri

Node sayısı, throughput, failover, RTO/RPO veya SLA değeri varsayımla yayımlanmamalıdır. Sonuçlar belirli release, veri profili, topoloji ve yük modeliyle ölçülmeli; sözleşmesel taahhüt ile teknik gözlem ayrıştırılmalıdır.

• Artifact sayısı/boyut dağılımı, eşzamanlı istemci, cache oranı, scan/SBOM hacmi ve background task yükü
• CPU, bellek, PostgreSQL, storage kapasite/latency ve network ölçümleriyle darboğaz ve ölçekleme eşiği
• Pod/node, PostgreSQL, storage, ingress ve dış bağımlılık kesintileri için beklenen servis davranışı ve ölçülen toparlanma
• Test tekrar sayısı, ham sonuç konumu, bilinen sınırlar ve ölçümü onaylayan platform/ürün sahipleri

Kısıtlı ağ ve air-gapped profil

Air-gapped kullanım; yalnız uygulamanın internetsiz açılmasıyla doğrulanmış sayılmaz. Image, chart, paket bağımlılığı, OSV/intelligence verisi, CA/identity bağımlılığı ve güncelleme kanalı birlikte tanımlanmalıdır.

• İçe aktarılacak image/chart ve paketlerin kaynağı, checksum/imza doğrulaması, malware kontrol sahipliği ve taşıma ortamı
• OSV/intelligence snapshot üretme, dış ortamdan taşıma, içe alma, freshness görünürlüğü ve başarısız güncelleme davranışı
• Proxy repository için yasak/izinli upstream modeli, DNS/egress reddi ve cache miss'in kullanıcıya yansıyan sonucu
• Offline CA, OIDC/LDAP seçimi, lisans veya zaman bağımlılıkları ve clock drift etkisi
• Yama, güvenlik bildirimi ve acil güncellemenin iç ortama alınması için sahipli ve süreli operasyon akışı

Tamamlanma standardı

Bir başlık ancak tekrar çalıştırılabilir adımlar, gerekli rol ve secret kaynağı, başarı/hata sonucu, rollback veya recovery davranışı ve tarihli kabul kanıtı yayımlandığında bu listeden çıkarılır.

Öncelik ve bağımlılık

Kanıt açıkları üretim etkisine göre sıralanmalı; birbirine bağlı başlıklar tek başına tamamlanmış sayılmamalıdır.

• P0: koordineli backup/restore, upgrade/rollback, secret sınırları ve incident response
• P0: üretimde kullanılacak her format/istemci için komut, minimum sürüm ve kabul sonucu
• P1: hedef topoloji için kapasite, failover, RTO/RPO ve operasyon runbook'ları
• P1: internet erişimi kısıtlı veya air-gapped profil için dependency, intelligence ve image tedarik akışı
• P2: kamuya açık SDK/endpoint matrisi, troubleshooting örnekleri ve destek/SLA materyali

Kanıt sahibi ve yayın kapısı

Her açık madde için ürün sahibi, platform sahibi, güvenlik inceleyeni ve doküman onaylayanı belirlenmelidir. Komutlar temiz bir ortamda ikinci bir kişi tarafından tekrar çalıştırılmadan ve secret taramasından geçmeden verified durumuna alınmamalıdır.

Durum kaydı ve sürümleme

Her boşluk, tek bir takip kaydında kapsam, durum, bağımlılık ve kanıt bağlantılarıyla yönetilmelidir. Genel bir 'tamamlandı' işareti yerine hangi release ve topolojinin doğrulandığı açıkça görünmelidir.

• Önerilen durumlar: Not started, Draft, Reproduced, Security reviewed, Approved, Published ve Superseded
• Kayıtta owner/reviewer/approver, hedef tarih, etkilenen release/topoloji, ön koşullar ve son doğrulama tarihi bulunur.
• Yeni image/chart, migration, storage, identity, network veya istemci değişikliği etkilenen kanıtı yeniden açar; eski belge Superseded olarak korunur.

Geçici güvenli kullanım

Bu listede kalan başlıklar için kurum içi runbook kullanılabilir; ancak release, topoloji, owner ve tarih açıkça yazılmalı, varsayımlar üretim garantisi gibi sunulmamalı ve sonuç kamuya açık dokümana otomatik taşınmamalıdır.

Canlı demo doğrulaması — 1 Ağustos 2026

Demo; repository/artifact, source/scan/policy, task, audit, package usage, outbound, storage, proxy ve identity ekranlarının çalışan üründe bulunduğunu gösterdi. Ekranların varlığı; per-format gerçek istemci komut paketlerini, koordineli backup/restore'u, upgrade/rollback'u, incident response'u, ölçülmüş kapasite/failover/RTO/RPO/SLA'yı veya air-gapped profili üretmez. Bu eksiklerin hiçbiri demo incelemesiyle kapanmadığından Doğrulama bekliyor durumu onaylanarak korunmuştur.