Teknoloji sunumu
Yazılımı herkes gösterir.
Biz altını gösteriyoruz.
Bir platformun değeri ekranlarında değil, ekranlar çalışmayı bıraktığında ne olduğunda ortaya çıkar. Bu sunum tam olarak orayı anlatıyor.
→ ilerle · ← geri · F tam ekran · N notlar · O içindekiler
Nereden başlıyoruz
Demo herkeste güzel görünür.
Asıl soru: gece 03:00'te disk dolduğunda kim haberdar oluyor?
- Veriniz kaç yerde duruyor ve en son ne zaman geri döndüğü denendi?
- Bir sunucu çöktüğünde kaç dakikada ayağa kalkıyor — tahmin değil, ölçüm?
- Yeni sürüm üretime çıkarken kim onaylıyor, iki dakikada geri alınabiliyor mu?
Bu üç sorunun yazılı bir cevabı yoksa, cevap “bilmiyoruz” demektir.
Ayrım
İki tür sistem vardır
Çalışan sistem
Kurulur, açılır, iş görür. Sorun çıkana kadar her şey yolundadır. Sorun çıktığında kimse ne olduğunu bilmez; kurtarma o gece doğaçlama yapılır.
Çalışmaya devam eden sistem
Arızayı kendisi haber verir, yedeğini doğrulayarak alır, kötü günün prosedürü önceden yazılmıştır. Kurtarma doğaçlama değil, uygulama işidir.
Aradaki fark teknoloji seçimi değil, işletme disiplini. Sonraki slaytlar bu disiplinin nasıl göründüğünü anlatıyor.
Mimari
Uygulama katmanı ile veri katmanı ayrı durur
Bu şemayı okumanız gerekmiyor — göstermek istediğimiz tek şey şu: durumu tutan hiçbir şey uygulama katmanında değil.
Bunun pratik karşılığı
Bakım artık gece yapılan riskli bir iş değil
Uygulama katmanı yenilenir
Konteynerler değişir, veri hiç dokunulmadan yerinde kalır.
Ortam değiştirilebilir
Cluster baştan kurulsa bile veritabanı ve dosyalar aynı yerde durur.
Kapsam daralır
Bir arıza tüm sistemi değil, tek katmanı ilgilendirir.
Çoğu kesinti arızadan değil, arızayı düzeltme girişiminden doğar. Katmanları ayırmak bu riski baştan küçültür.
Dönüşüm
Bu olgunluk bir gecede kurulmadı
Her aşama bir öncekinin üstüne bindi. Sıra tesadüf değil: önce temel, sonra otomasyon, en sonda kanıt.
Temel
Küme, ağ, depolama ve sertifika yönetimi. Her adım script'e yazıldı.
Ayrıştırma
Veri katmanı kümenin dışına alındı. Bakım ile veri birbirinden koptu.
Otomasyon
Git → derleme → imaj deposu → dağıtım. Üretime elle dokunma bitti.
Koruma
Dört katmanlı yedek, doğrulama, iki ayrı depolama, yazılı geri dönüş.
Kanıt
Uçtan uca izleme, alarmın insana ulaşması, belgelendirme ve ISO 27001.
GitLab
Koddan dağıtıma tek platform
Kaynak kod, CI/CD, imaj deposu ve Kubernetes dağıtımı GitLab altında yönetilir. Runner işleri Kubernetes executor ile çalışır. TitConn ve BR dağıtımları GitLab Agent üzerinden elle başlatılır.
AI · Yerel model ve kod arama
Yerel Qwen modeli CPU sunucusunda çalışır. Ekip LibreChat üzerinden erişir; RAG MCP ilgili kodu getirerek sorun giderme ve kök neden analizini destekler. Erişim iç ağ / VPN ile sağlanır.
AI destekli sorun giderme ve kök neden analizi (RCA)
Yerel AI ile sorun giderme ve kök neden analizi yapıyoruz. Olayın belirtilerini, log ve metrik bulgularını, son değişiklikleri RAG MCP üzerinden bulunan ilgili kodla birlikte inceliyoruz.
Ekip olayın zaman aralığını, etkilenen servisi ve seçilmiş log/metrik çıktılarını LibreChat’e sağlar. Qwen, kod aramasıyla olası nedenleri ve kontrol adımlarını çıkarır. Ekip önerilen düzeltmeyi test eder, sonuçları izler ve doğrulanan kök nedeni RCA kaydına işler. Log ve metrik aktarımı bu kurulumda otomatik bir entegrasyon olarak tanımlı değildir.
Örnek vakalar
- Pod yeniden başlıyor: olaylar, loglar ve son değişikliklerden hata adaylarını çıkar; ilgili kodu MCP ile bul.
- API yavaş veya 5xx dönüyor: gecikme, hata logları ve bağımlılık bulgularını kodla ilişkilendir; kontrol adımlarını sırala.
- Dağıtım sonrası hata: değişen kodu ve hata mesajını karşılaştır; düzeltme veya geri alma önerisini testle doğrula.
CI/CD
GitLab → Kubernetes
Build → package → release adımları branch kurallarına göre çalışır. Üretime geçişte ilgili deploy işi başlatılır. Agent bağlantısı GitLab’da Connected olmalı; pod’un Running olması yeterli değildir. İmaj push başarısızsa dağıtıma devam edilmez. Geri alma için saklanan önceki imaj digest’i ve sürüm manifesti yeniden dağıtılır.
Değişiklik güvenliği
Yeni sürüm çıkmak korkulacak bir şey olmamalı
- Her sürüm kim, ne zaman, hangi değişiklikle — kalıcı kayıt
- Geri alma yeni bir dağıtım değil, bir önceki kayda dönmek
- Üretimde elle yapılan değişiklik sapma olarak bildirilir, sessizce kalmaz
- İmajlar kendi deponuzda; dış kaynak bir gün kaybolsa bile dağıtım çalışır
Veri güvenliği
Yedek tek katman değil, dört katman
Her gece, her veritabanı ayrı. Tek bir tabloyu geri almak mümkün — tüm sunucuyu dünkü haline döndürmeden.
Makinenin bütün görüntüsü. Donanım kaybında en hızlı dönüş yolu.
Cluster'ın kendisi de yedekleniyor: servisler, ayarlar, erişim kuralları, sertifikalar.
Merkezî log arşivi olay incelemesini destekler. İkinci depolama cihazı kopyaları korur.
- Yedekler korudukları sunucunun üzerinde durmaz — ayrı depolamaya yazılır
- Veritabanı dökümleri boyut, etcd snapshot’ları ayrıca bütünlük kontrolünden geçer; boş dosya “başarılı” sayılmaz
- Yedek alınamazsa haber gelir — sessizlik bir sonuç değildir
RPO hedefi: 24 saat; zamanlanmış yedeklerin başarılı olmasına bağlıdır. Dönüş noktası gece yarısı değil, son başarılı yedektir. Daha kısa hedefler motorun yedekleme ve işlem günlüğü stratejisine göre planlanır. Çoğaltma tek başına yanlışlıkla silmeye karşı koruma sağlamaz.
Felaket kurtarma
Aynı arıza, beş farklı kurtarma yolu
Doğru katmanı seçmek kurtarma süresini saatlerden dakikalara indirir. Bu tablodaki süreler hedeftir; geri dönüş tatbikatı henüz tamamlanmadığı için ölçülmüş sonuç değildir.
| Katman | Yöntem | RPO | RTO | Ne zaman |
|---|---|---|---|---|
| Tier 1 | Veritabanı dökümünden seçmeli geri yükleme | ≤ 24 sa | 5–30 dk | Tek tablo ya da tek kayıt kaybı |
| Tier 2 | Sunucudaki tüm dökümlerin geri yüklenmesi | ≤ 24 sa | 1–2 sa | Veritabanı motorunun bozulması |
| Tier 3 | Küme durumunun anlık görüntüden dönmesi | ≤ 24 sa | 1–3 sa | Yönetim düzlemi bozulması |
| Tier 4 | Sanal makinenin tamamının kopyadan dönmesi | ≤ 24 sa | 2–4 sa | Donanım ya da işletim sistemi kaybı |
| Tier 5 | Script'lerden sıfırdan inşa + veri geri yükleme | ≤ 24 sa | 4–8 sa | Ortamın tamamen kaybı |
Kritik ayrım: makine kopyası her şeyi dünkü hâline döndürür — tek bir tabloyu geri almanın yolu yoktur. Mantıksal döküm tam bu boşluğu kapatır.
Felaket kurtarma
Kötü günün her hâli için yazılı cevap
| Senaryo | Etki | İzlenecek yol | Hedef |
|---|---|---|---|
| Bir düğüm düşer | Yok — iş yükü diğerlerine kayar | Müdahale gerekmez | — |
| Yönetim düzlemi bozulur | Değişiklik yapılamaz, servisler ayakta | Tier 3 | 1–3 sa |
| Tablo yanlışlıkla silinir | Tek veri kümesi | Tier 1 — seçmeli geri yükleme | 5–30 dk |
| Veritabanı sunucusu çöker | Uygulama kesintisi | Tier 2 ya da Tier 4 | 1–4 sa |
| Birincil depolama gider | Yedekler ve disk verisi | İkincil kopyadan dönüş | 4–8 sa |
| Fidye yazılımı | Canlı veri kullanılamaz | İzole kopyadan temiz geri yükleme | 4–12 sa |
| Ortamın tamamen kaybı | Tam kesinti | Tier 5 — script'lerden inşa | 4–8 sa |
Bunlar hedef değerlerdir, ölçülmüş SLA değil. Ama yazılıdır — felaket anında “ne kadar kaybı göze aldık” sorusu tartışılmaz.
İzleme
Sorunu müşteri değil, sistem haber verir
- Çoğu kurumda izleme vardır ama zincir bildirimde kopar — ölçüm alınır, kimseye ulaşmaz
- Sertifikalar dolmadan haftalar önce uyarı verir; kimse takvime bakmak zorunda kalmaz
- Bildirim sisteminin kendisi de izlenir: “alarm gelmiyor” da bir alarmdır
Kapsam
İzlenen ne var
Servisler, veritabanları, dış adresler, sertifikalar, derleme sunucusu.
Her biri belirli bir arıza türü için ayrı yazılmış.
Anlık dalgalanmalar elendikten sonraki tipik uyarı süresi.
Doğrudan ekip kanalına; kimse ekrana bakmak zorunda değil.
Alarm sayısı bilinçli olarak düşük tutuluyor. Sürekli çalan bir kanal, hiç çalmayan bir kanaldan daha tehlikelidir — çünkü insanlar bakmayı bırakır.
Güvenlik
Kurumsal kimlik, kapalı kapılar
Kimlik yönetimi
Active Directory entegrasyonu. Bir kullanıcı işten ayrıldığında erişimi tek yerden kapanır; ayrı kullanıcı listesi tutulmaz.
Şifreli trafik
Bütün adresler gerçek sertifikalarla. Yenileme otomatik, süre takibi izleniyor.
Özel imaj deposu
Üretime giden her konteyner kendi deponuzdan gelir; dış kaynağa bağımlılık yok.
Denetim izi
Kim neyi ne zaman dağıttı — sürüm kaydında, sonradan değiştirilemez.
Uyum
Belge bir duvar süsü değil, işleyen bir sistem
Kimlik tek merkezden
Kullanıcılar kurumsal dizinde yönetilir. İşten ayrılan biri merkezden kapatıldığında bütün sistemlere erişimi biter — tek tek hesap kapatma turu yoktur.
Bütün loglar tek depolamada
Uygulama, küme, veritabanı ve cihaz kayıtları merkezî depolamaya toplanır; saklama süresi tanımlıdır. Bir olayın geriye dönük incelenmesi mümkündür — denetimde istenen tam olarak budur.
Her değişikliğin sahibi var
Üretime giden her değişiklik sürüm geçmişinde kayıtlı: kim, ne zaman, ne. Silinemez ve sonradan yazılamaz.
Yazılı iş sürekliliği
Yedekleme, doğrulama ve geri dönüş prosedürleri belgeli; RPO ve RTO hedefleri tanımlı. Standart bunu ister, biz sunumun yarısını buna ayırdık.
- Dışarıya açık yüzey bilinçli olarak dar: yalnızca üç port, geri kalan her şey kapalı ağda
- Şifre ve anahtarlar belgelerde değil, yetkiye bağlı kasada durur
Uyum
Kişisel veri nerede duruyor, kim görüyor?
Veri yurt dışına çıkmaz
On-prem kurulumda bütün veri kendi donanımınızda kalır. Yurt dışına aktarım gerektirmeyen bir mimari, KVKK tarafında en az soruyu doğuran mimaridir.
Görme yetkisi rol ile sınırlı
Kişisel veriye erişim rol bazlıdır ve loglanır. “Kim ne zaman neye baktı” sorusunun cevabı vardır.
Test ortamı gerçek veriyle çalışmaz
Geliştirme ve test ortamlarına veri maskelenerek aktarılır: ad, iletişim ve kimlik alanları anlamını korur, kişiyi işaret etmez.
- Saklama süreleri tanımlı — süresi dolan veri süresiz durmaz
- Yedekler de aynı kapsamda: koruma yalnızca canlı sistemde değil, kopyalarda da geçerli
- Silme ve anonimleştirme talepleri prosedürle karşılanır, tek tek elle değil
Ölçülebilir fark
Aynı işler, bambaşka süreler
Soldaki değerler elle yönetilen tipik bir ortamın, sağdakiler bu platformun süreleri.
Somut
Rakamlarla platform
Tek yönetim altında, birbirine bağlı çalışan bileşen.
İhtiyaca göre doğru araç: ilişkisel, doküman, önbellek, arama, kuyruk.
Her adım kayıtlı ve tekrarlanabilir. “Bir kişinin bildiği” hiçbir şey yok.
Karşılaşılmış, çözülmüş ve yazılmış sorun.
Son rakam en önemlisi. Bir ekibin olgunluğu hata yapmamasıyla değil, hatalarını yazılı hâle getirmesiyle ölçülür.
Teslim
Kurulumla birlikte belge de teslim edilir
- Kurulum kılavuzu — her bileşen için parametreler, gerekçeler, sürüm bilgisi
- Kurtarma prosedürleri — felaket senaryoları, adım adım komutlarla
- Bakım scriptleri — yükseltme, yedekleme, izleme; hepsi çalıştırılabilir
- Karar kayıtları — “neden böyle yapıldı” sorusunun altı ay sonraki cevabı
Bağımlılık yaratmıyoruz. Belgeler sizin, scriptler sizin — isterseniz başka bir ekip devralabilir. Güven de tam olarak buradan çıkıyor.
Geçiş
Şimdiye kadar anlattığım her şey bunu ayakta tutmak için var.
Altyapı kendi başına bir değer değil. Değer, üzerinde koşan uygulamanın kesintisiz ve güvenli çalışmasında.
Ürün
TitConn · yedi servis, tek platform
| Servis | Ne yapar | Bağlı olduğu |
|---|---|---|
| ui | Kullanıcı arayüzü — tarayıcının konuştuğu tek yer | api · hub |
| api | İş mantığı ve veri erişimi | SQL · Mongo · Redis · kuyruk |
| hub | Gerçek zamanlı bağlantı — anlık bildirim | api · Redis |
| microservice | Kuyruktan iş tüketen arka plan servisi | kuyruk · SQL · Mongo |
| scheduler | Zamanlanmış işler | kuyruk · SQL |
| keyvault | Yapılandırma ve gizli değer dağıtımı | SQL |
| grpcservice | Servisler arası ikili protokol iletişimi | SQL |
Ağır işler kullanıcıdan ayrı süreçlerde koşuyor. Bir rapor üretimi yavaşladığında arayüz yavaşlamıyor — çünkü aynı yerde çalışmıyorlar.
Erişim
Kimlik doğrulama — kurumsal ve yedekli
Azure SSO
Kurumsal kimlikle tek oturum açma. Kullanıcı Azure tarafında yönetilir; işten ayrılan biri orada kapatıldığında uygulamaya da giremez. Parola uygulamada hiç tutulmaz.
Uygulama kullanıcıları
Kurumsal hesabı olmayan dış kullanıcılar, servis hesapları — ve SSO erişilemediğinde kullanılan ikinci yol.
İkinci yol bilinçli. Tek kimlik kaynağına bağlı kalsaydık, sağlayıcı tarafındaki bir kesinti uygulamaya girişi tamamen durdururdu. Yedeği olmayan kimlik, tek noktalı arızadır.
Ürün · esneklik
Veritabanını siz seçersiniz, biz uyarız
TitConn üç veritabanı motorunda çalışır. Fark yalnızca lisans maliyetinde; uygulama davranışı aynıdır.
| Motor | Lisans | Yaklaşık maliyet | Ne zaman tercih edilir |
|---|---|---|---|
| PostgreSQL | Açık kaynak | Lisans yok | Varsayılan önerimiz. Yeni kurulumların tamamı için yeterli; maliyet yalnızca donanım ve işletme. |
| SQL Server | Ticari · çekirdek başına | Orta–yüksek | Kurumda hâlihazırda Microsoft yatırımı ve SQL Server uzmanlığı varsa. Standard sürüm çoğu kurulum için yeterlidir. |
| Oracle | Ticari · çekirdek başına | Yüksek | Mevcut Oracle altyapısına ve kurumsal politikaya uyum gerekiyorsa. |
- Motor seçimi uygulamanın yeteneklerini değiştirmez — aynı sürüm, aynı davranış
- Lisans maliyeti kurumun çekirdek sayısına ve anlaşmasına bağlıdır; net rakam kuruma özel çıkarılır
- PostgreSQL'de lisans kalemi tamamen ortadan kalkar — çok yıllık toplam sahip olma maliyetinde en belirleyici fark budur
Ürün mimarisi
TitConn · kendi veri merkezinizde
Dışarı açık servisler, cluster içinde kalan arka plan işçileri, ve ortak altyapı. Durumu tutan hiçbir şey cluster'ın içinde değil.
Aynı ürün, ikinci ortam
TitConn · Azure üzerinde
Grupların işlevi birebir aynı. Değişen tek şey ortak altyapının nerede durduğu — burada yönetilen bulut servisleri, orada kendi veritabanı sunucumuz.
Nerede çalışır
Aynı ürün, iki ortam, tek süreç
Azure
Yönetilen veritabanı, otomatik ölçekleme, sağlayıcı güvencesi. Donanım derdi yok.
Kubernetes
Veri kurum dışına çıkmaz. Mevzuat ya da politika gereği içeride tutulması gerekenler için.
Aynı kod
Aynı imajlar, aynı sürüm akışı, aynı geri alma yöntemi. Ortam değişir, süreç değişmez.
Bu, bir gün fikir değiştirebilmek demek. Seçim tek yönlü bir kapı değil — buluttan içeri, içeriden buluta taşınabilir.
Karar sizin
Ortam seçimi teknik değil, ticari ve hukuki bir karar
| Konu | Bulut | Kendi veri merkeziniz |
|---|---|---|
| Veri yerelliği | Sağlayıcının bölgesinde | Tamamen sizde |
| Veritabanı işletimi | Sağlayıcı üstlenir | Bizim kurduğumuz süreçlerle |
| Başlangıç maliyeti | Düşük | Donanım yatırımı |
| Uzun vadeli maliyet | Kullanıma göre artar | Öngörülebilir |
| Ölçekleme | Dakikalar | Donanım planlaması |
| Uygulama ve sürüm akışı | İkisinde de birebir aynı | |
Özet
Çalışan bir sistem kurmak zor değil.
Zor olan, çalışmaya devam edeceğini kanıtlayabilmek.
- Veri uygulamadan ayrı — bakımın etki alanı daralıyor
- Dört katmanlı yedek, doğrulanarak alınıyor
- Arızayı sistem haber veriyor, müşteri değil
- Kötü günün prosedürü yazılı, tahmine dayalı değil
- Her şey belgelenmiş — devredilebilir
Sorular · Detaylı teknik kılavuz talep üzerine paylaşılır