Çoğu release engineering literatürü, deployment penceresini teknik bir olay olarak ele alır: trafiği boşalt, migration'ları çalıştır, deploy et, smoke test yap, gerekirse rollback uygula. Blue-green, canary, feature flag — hangisini tercih ederseniz. Bu modele gömülü varsayımlar, SaaS ürünleri ve e-ticaret platformları için makuldür. Emeklilik yönetimi ve sigorta core sistemleri için ise yanlıştır.
Yıllarımı içinde geçirdiğim BES (Bireysel Emeklilik Sistemi) dünyasında, bir cutover penceresi bir downtime penceresi değildir. Aynı anda gerçekleşen ve hepsi başkasının saatine bağlı olan bir düzenleyici sınır, bir finansal state-machine duraksaması ve bir mutabakat checkpoint'idir.
Pencere Sizin Değildir
Standart bir release runbook'u "düşük trafikli bir pencere seçin" ile başlar. Bir emeklilik sistemi için, mühendislerin kastettiği anlamda düşük trafikli bir pencere yoktur. Yalnızca state değişikliklerinin sonuçlarının tersine çevrilmesinin daha az maliyetli olduğu bir pencere vardır.
Herhangi bir gecede bir emeklilik platformundan geçen şeyleri düşünün:
- İşverenlerden gelen, çoğunlukla katı bildirim SLA'leriyle SGK bağlantılı kanallar üzerinden iletilen katkı payı dosyaları
- Devlet katkısı hesaplamaları — işleme tarihine değil, katkı tarihine bağlı
- Saklamacı bankalardan, saklamacının takvimine göre gelen fon fiyat güncellemeleri
- Poliçe state geçişleri: hak ediş kilometre taşları, emeklilik uygunluğu, ayrılma hakları
- EGM (Emeklilik Gözetim Merkezi) mutabakat dosyaları — katılımcı bakiyelerinizi merkezi sicile karşılaştırır
Bunların hiçbiri, deployment'ı 02:00'a planladığınız için duraksamaz. 23:55'te alınan bir katkı bir muhasebe gününe aittir. Ona bağlı sübvansiyon hesaplaması bir başkasına aittir. İkisini de mutabık kılan EGM dosyası, sabit bir takvimde üretilir ve migration'ınızın bitip bitmediğine aldırmaz.
Uçuş Sırasındaki State Bir Bug Değil, Varsayılan Durumdur
Standart release engineering, sistemi sessizleştirebileceğinizi varsayar. Bağlantıları boşalt, uçuştaki istekleri bitir, deploy et. Bir emeklilik veya sigorta core'unda, "uçuşta" çok günlü bir kavramdır.
Bir katkı yaşam döngüsü şöyle görünebilir:
- İşveren dosyayı gönderir (gün T)
- Dosya doğrulanır, katılımcı hesaplarına dağıtılır (T veya T+1)
- Bir sonraki kullanılabilir NAV ile fon birimleri satın alınır (T+1 veya T+2)
- Devlet katkısı talebi oluşturulur (döngüye göre T+2 ila T+15)
- EGM mutabakatı doğrular (T+N)
- Sübvansiyon alınır ve dağıtılır (T+30 ila T+60)
Döngü ortasında deploy etmek, kod sürümü N tarafından kısmen işlenmiş ve sürüm N+1 tarafından tamamlanacak kayıtlara karşı deploy etmek anlamına gelir. Schema migration'ınız sübvansiyon uygunluğunun nasıl hesaplandığını veya bir fon dağıtımının altı yerine dört ondalığa nasıl yuvarlandığını değiştirirse, kodunuzun hiçbir sürümünün tam olarak anlamadığı bir kayıt popülasyonu yaratmış olursunuz.
Bu hipotetik değil. Bir deployment'ın bir Çarşamba günü dağıtım mantığının yuvarlama davranışını değiştirmesi ve Cuma günkü EGM mutabakatının izlenmesi, sınıflandırılması ve ya düzeltilmesi ya da resmi olarak itiraz edilmesi gereken binlerce kuruşluk farkı işaretlemesi nedeniyle çözülmesi üç hafta süren mutabakat kırılmaları gördüm.
Rollback Çoğu Zaman İmkansızdır
Release engineering playbook'u rollback'i bir güvenlik ağı olarak ele alır. Deploy et, gözlemle, gerekirse geri al. Sigorta ve emeklilik sistemlerinde, herhangi bir finansal state değişikliğinden sonra rollback, mühendislik anlamında sıklıkla imkansızdır.
Fon birimlerinin satın alımını geri alamazsınız. Gönderilmiş bir sübvansiyon talep dosyasını geri alamazsınız. Bir katılımcıya emeklilik uygunluğunun aslında dün verilmediğini söyleyemezsiniz. Bir işlem dışarıdan — bir saklamacı, EGM veya bir düzenleyici tarafından — onaylandıktan sonra, rollback'iniz artık bir veritabanı operasyonu değildir. Bir telafi işlemidir, bir düzeltme bildirimidir ve çoğu zaman bir düzenleyici açıklamadır.
Bu, her deployment kararının hesabını değiştirir:
- Feature flag'ler, flag'in çevrilmesinin kendisi finansal bir olay olmayacak şekilde tasarlanmalıdır
- Schema migration'ları en az iki döngü boyunca geriye dönük uyumlu olmalıdır, iki deployment değil
- Smoke test'ler yalnızca HTTP 200'leri değil, mutabakat çıktılarını doğrulamalıdır
- "Başarılı deployment" deploy zamanında ölçülmez. Bir sonraki EGM mutabakatında ölçülür
Gerçekte Ne İşe Yarar
Düzenlenmiş gerçeklikle teması atlatan birkaç ilke:
Cutover'ları mühendislik kolaylığıyla değil, düzenleyici döngülerle hizalayın. Doğru deployment penceresi çoğu zaman bir mutabakat dosyasının çıkması ile bir sonraki döngünün başlaması arasındaki boşluktur. Bu, belirli bir hafta içi gecesinde dört saatlik bir pencere olabilir. Sprint kadansınıza uyacak şekilde pazarlık edilemez.
Upstream girişleri açıkça dondurun. Katkıların gelmesini durduramıyorsanız, en azından yeni kod doğrulanana kadar state machine'e işlenmelerini durdurun. Dosyaları bir karantina kuyruğunda tutun. İşlemeyi yalnızca deploy sonrası doğrulama geçtikten sonra sürdürün.
Yalnızca kodu değil, iş mantığını da versiyonlayın. Kural sürümü 4.2 altında alınan bir katkı, sistem 4.3'e geçtikten sonra bile uçtan uca 4.2 altında işlenebilir olmalıdır. Bu, feature flag'lerden daha ağırdır. Esasen domain modeline gömülü temporal mantıktır.
Mutabakat gerçek smoke test'tir. Bir deployment, pod'lar sağlıklı olduğunda bitmiş değildir. Bir sonraki EGM dosyası uyuştuğunda, bir sonraki saklamacı mutabakatı uyuştuğunda ve bir sonraki sübvansiyon döngüsü temizlendiğinde bitmiştir. Bundan azı, DevOps kılığına sokulmuş hüsnükuruntudur.
Düzenleyiciyi deployment planının bir paydaşı olarak ele alın. Hesaplama mantığındaki büyük değişiklikler, işlevsel olarak eşdeğer olsalar bile çoğu zaman bildirim veya ön onay gerektirir. Bunu deployment sonrasında keşfeden mühendislik ekipleri, bunu pahalıya öğrenir.
Altta Yatan Uyumsuzluk
Standart release engineering, deployment sıklığı ve ortalama iyileşme süresi için optimize eder. Emeklilik ve sigorta core sistemleri ise izlenebilirlik, iş etkisinin (teknik state'in değil) tersine çevrilebilirliği ve düzenleyici savunulabilirlik için optimize eder. Bunlar aynı amaç fonksiyonu değildir.
Sektör bir on yılını herkese daha hızlı, daha küçük, daha sık deploy etmelerini söyleyerek geçirdi. Bu tavsiye çoğu yazılım için doğrudur. Bir deployment'ın altı ay sonra bir düzenleyiciye açıklanması gereken bir katılımcı bakiye uyumsuzluğu yaratabileceği sistemler için, tavsiyenin ciddi şekilde değiştirilmesi gerekir — yoksa ekip, bir mutabakat kırılması veya resmi bir bulgu aracılığıyla, cutover penceresinin kontrol etmelerine asla bırakılmamış olduğunu eninde sonunda öğrenecektir.