Upgrade'i Ertelemenin Maliyeti

info@muhammetsafak.com (Muhammet Şafak) — Sun, 18 Oct 2026 00:00:00 GMT

PHP 7.1’den stabil 8.2’ye geçmeyi önerdiğimde cevap kısaydı: “Çalışıyor, ne gerek var?” Cevap doğruydu — o gün hiçbir şey bozuk değildi. Bozulmaya başlayan şey görünmüyordu: paketler eski PHP desteğini tek tek kesiyor, uygulama 7.1’e kilitleniyordu.

“Çalışıyor” cümlesi bugünü anlatır. Faturayı ise sonraki günler keser.

İtiraz mantıksız değil, o yüzden hafife almıyorum. Bozuk olmayan bir şeye zaman ayırmak, hiçbir şey kazanılmıyormuş gibi görünür. Haklı bir cümleyi çürütmek için cümleyle tartışmak yetmez; sayıyla gelmek gerekir. Aşağıdaki, o cümlenin bana neye mal olduğunun hesabı: hangi mekanizmayla, hangi kalemlerle ve hangi kısmı ölçebildiğimle.

Kilit Nasıl Kuruluyor

Kilit tek bir günde kurulmadı; her paket güncellemesinde bir kapı daha kapandı.

Mekanizma sıradan. Bir paket yeni sürümünde eski runtime’ı desteklemeyi bırakır. Runtime yükseltilmediği için o sürüm kurulamaz, eski sürümde kalınır. Aynı şey bir sonraki pakette olur, ardından bir sonrakinde. Hiçbiri tek başına alarm üretmez: eski sürüm çalışmaya devam eder.

Bir noktadan sonra güncellenebilen paket kalmaz. Buna bağımlılık kilidi diyorum: uygulama runtime’a, paketler uygulamaya, hepsi birlikte 7.1’e bağlanmış durumda. Çıkış tek parça. Runtime’ı yükseltmeden hiçbir paketi ileri alamıyordum; paketleri ileri almadan da yükseltmenin neye mal olacağını göremiyordum.

Kilit bu yüzden fark edilmeden kuruluyor. Her kapanan kapı tek başına ertelenebilir bir ayrıntı; hiçbir paket güncellemesi “upgrade’i bugün yapmalıyız” dedirtecek kadar büyük görünmüyor. Kararı ertelemek her seferinde makul. Makul kararların toplamı ise bir köşeye sıkışmak oluyor.

Kilidin en kötü yanı sessiz olması. Hiçbir hata mesajı “bugün bir kapı daha kapandı” demiyor. Bunu ancak bir paketi güncellemeye çalıştığınız gün, güncellemenin neden kurulmadığını okurken fark ediyorsunuz.

Kendi sisteminizde bakılacak işaret basit: Bekleyen paket güncellemelerinden kaçı, runtime sürümü yüzünden kurulamıyor? Sıfırdan büyük her sayı, bir kapının kapanmış olduğunu gösterir.

Elimdeki Tek Rakam

Önerdiğim gün iş, 1–2 günlük bir upgrade’di. Kilit kurulurken ise her paket güncellemesi birkaç saat tutuyordu. İkisi de küçük bir iş gibi duruyordu ve bu yüzden ertelemek kolaydı.

Küçük iş, ertelemek için iyi bir adaydır; “önce acil olanı bitirelim” cümlesi her takvimde yer bulur.

Ertelenince iş yalnız büyümedi, biriktiği için tek parça hâline geldi. Sürüm atlamak zorunda kaldım: 7.1’den 8.2’ye adım adım değil, aradaki her şeyi tek seferde geçerek. Önüme onlarca breaking change ve deprecated metot çıktı ve hepsi aynı anda çözülmek zorundaydı. Parça parça ödenebilecek bir borç, tek bir tahsilata dönüştü.

Rakamın asıl öğrettiği, tutarın kendisi değil iş türünün değişmesi. Birkaç saatlik paket güncellemeleri istenen sırayla, istenen günde yapılabilen parçalı işlerdi. Onlarca breaking change ise bölünemeyen, başlayınca bitmesi gereken tek bir iş. Ertelemek işi büyütmekle kalmadı, esnekliğini de aldı.

Bu, elimdeki tek rakam: 1–2 günlük iş, artı her paket güncellemesinde birkaç saat. Ertelemenin toplam bedelini bunun yanına koyabilecek bir ölçümüm yok. Koymayacağım da; ölçmediğim bir sayıyı yazmak, “çalışıyor ya” cevabından daha kötü bir argüman olur.

Yine de bu tek rakam bile bir konuşmayı başlatmaya yeter. “Çalışıyor ya” karşısına “hiçbir şey kazanmıyoruz” diye değil, “şimdi 1–2 gün, sonra tek seferde onlarca değişiklik” diye gidebilirsiniz. İkisi arasındaki farkı yöneticiye açıklamak için ölçüm şart değil, yalnız karşılaştırmanın yönü yeter.

Rakamı nasıl çıkaracağınız serinin 7. bölümünde; hangi upgrade’in önce geleceği 3. bölümde. Burada yalnız şunu söylüyorum: bu karşılaştırmayı o gün masaya koyabilseydim, “çalışıyor” cevabı tek başına yetmezdi.

Faturanın Asıl Kalemi

Breaking change’leri temizledik; beklemediğimiz şey, ondan sonra gelen bug’lardı.

Breaking change’in iyi bir özelliği var: hata mesajı onu gösterir. Listeyi çıkarırsınız, tek tek kapatırsınız, biter. Bu kalem uzun ama bellidir: büyüklüğünü kabaca kestirir, takvime yerleştirir, yöneticiye de söyleyebilirsiniz.

Bug’lar öyle değildi. Bir kısmı yalnız tek bir case’de ortaya çıkıyordu — sık tetiklenmeyen bir yol, belirli bir veri, belirli bir sıra. Böyle bir bug’ı önce görmek, sonra yeniden üretmek, sonra nedenini bulmak gerekiyor. Her biri ayrı bir araştırma. Çözümleri aylara yayıldı. Bir bug kapanıyor, başka bir case’de bir başkası çıkıyordu.

Planlama açısından ikisini ayrı yazmak gerekiyor. Breaking change tahmin edilebilir bir kalem; bug’lar edilemez. Bütçeyi yalnız birincisine göre kurarsanız, ikincisi bütçenin dışında, takvimin içinde yaşanır.

Asıl maliyet orada: uzun kuyruk. Toplu geçişin bedeli takvime sığar, kuyruğun bedeli sığmaz. Üstelik onlarca değişikliği bir arada taşıyınca her bug’ın kaynağı onlarca adaydan biri oldu; hangisinin hangi değişiklikten geldiğini ayırmak ayrı bir iş çıkardı.

Çalışıyor Bugünü Anlatır

“Çalışıyor ya” itirazına “teknik borç var” demek yetmiyor; karşınızdaki bunu bir görüş olarak duyuyor. İş diliyle cevap vermek için riski kalemlere ayırmak gerekiyor. Ertelenen her upgrade dört kalem biriktirir:

Destek bitişi: runtime ya da framework’ün bakımı bitince yeni düzeltme gelmez. Takvimde belli bir gün, bilinen bir tarih.
CVE’ye açık kalma süresi: desteğin bittiği günden sonra duyurulan her CVE için resmi yama gelmez; dağıtımınız ya da ücretli bir uzatılmış destek yamalamıyorsa açık, siz yükseltene kadar sistemde durur. Sayaç desteğin bittiği gün başlar, upgrade günü durur.
Bağımlılık kilidi: paketler eski sürüme sabitlendikçe güncelleme seçenekleri daralır. Kilit kurulduktan sonra tek çıkış, her şeyi birlikte taşımak.
Büyüyen sürüm farkı: aradaki sürüm sayısı arttıkça tek seferde çözülecek breaking change ve deprecated metot sayısı artar. Benim vakamda bu, onlarca kalemdi.

Bunların hiçbiri bugün bir hata üretmiyor ve izleme panelinde görünmüyor; hepsi yarın ödenecek. Yönetici açısından da fark bu: bozuk bir şey için bütçe istemek kolay, bozulmamış bir şeyin neden bozulacağını anlatmak zor. Kalemleri adlandırmak bu yüzden işe yarıyor, çünkü her biri bir tarihe, bir sayaca ya da bir sayıya bağlanabilir.

Dört kalemin özeti şu: çalışıyor bugünü anlatır, risk yarının bilanço kalemidir. Upgrade’in bedeli bellidir ve ödemeyi siz zamanlarsınız. Ertelemenin bedeli ise belirsizdir ve tahsilat zamanını siz seçemezsiniz.

Ne Zaman Bırakırsınız?

Upgrade etmemek de meşru bir karar olabilir; hangi durumlarda olduğunu serinin 8. bölümüne bırakıyorum. Buradaki itirazım ertelemeye değil, ertelemenin bir karar olarak yazılmamasına.

Ertelemek bilinçli bir karar olabilir; ama yazılı olmayan karar, bir gün sürpriz olarak geri gelir. Tarihi ve gerekçesi yazılmış bir erteleme risk yönetimidir, yazılmamış olan ise yalnızca unutmaktır.

Bugün yapabileceğiniz tek bir şey var: kullandığınız runtime ve framework sürümlerinin destek bitiş tarihlerine bakın, bir yere yazın. Sistemin envanteri yoksa bile iki satır yeter: ne çalışıyor, desteği ne zaman bitiyor. Bir sonraki “neden?” sorusunda elinizde en azından bir tarih olur. Tarihin yanına, sistemin o güne kadar kaç sürüm geride kalacağını da yazarsanız, soru “çalışıyor mu” olmaktan çıkıp “ne zaman ödeyeceğiz” olur; konuşma da orada başlar.

Kendinize sorun: bu sistemi bugün yükseltmek 1–2 günlük bir iş olsaydı yapar mıydınız? Cevap evetse, bekleyerek elde edeceğiniz şey yok; yalnız iş büyüyor.

Seri buradan devam ediyor: 1. bölümde upgrade’i tetikleyen durumlar, 2. bölümde neyin yükseltileceğini görmek için envanter ve katmanlar, 3. bölümde karar matrisi; 8. bölüme kadar hedef sürüm, ön koşullar, rollout ve organizasyon.

Upgrade’i ertelediğinizde riski kapatmazsınız; faturayı bir sonraki güne yazarsınız.