# Upgrade Karar Matrisi: Tarih Değil, Kritiklik ve Tür

> EOL tarihi upgrade sırasını değil, üst sınırı verir. Sistem kritikliğiyle tetikleyici türünü kesiştiren 3×3 matris ve her hücre için bir tepki penceresi.

- Tür: Notlar
- Yayın: 2026-11-08
- Etiketler: dependencies, decisions, security, production
- Dizi: Production'da Upgrade
- Okuma süresi: 6 dk okuma
- Kaynak: https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-karar-matrisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
> **Kısaca:** Upgrade sırasını destek bitiş tarihi değil, sistemin kritikliği ile tetikleyicinin türü (zorunlu, kilitleyen, fırsat) birlikte koyar; aynı CVE bir iç araçta fırsat, ödeme akışında zorunludur. 3×3 bir matris her hücreye bir sıra ve tepki penceresi verir, EOL tarihi yalnız üst sınır olur. Tür zamanla kaydığı için matris her planlama turunda yeniden okunur.

Tarihe göre dizilen upgrade kuyruğu, en kritik sistemin zorunlu sinyalini sona atabilir.

Şöyle bir kuyruk düşünün. Envanteriniz var, EOL listeniz var; ikisini birleştirip tarihe göre sıralıyorsunuz. En üstte EOL'ü en yakın olan satır duruyor: yalnız ekibin kullandığı bir iç rapor aracı. En altta tarihi olmayan ya da en uzak olan satır: ödeme akışında etkilendiğiniz bir CVE.

Sıralama doğru çalıştı. Yanlış olan, neyi sıraladığı.

[Bölüm 2](https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-envanteri/) sınırı baştan çizmişti: envanter karar vermez, karar matrisine girdi üretir. Tarih o girdinin bir sütunu, o kadar. Sistemin düştüğünde neyi durdurduğunu ve elinizdeki sinyalin hangi türden olduğunu bilmeden tarih kuyruğa sıra koyamaz.

Tarih yalnız üst sınırdır; sırayı, sistemin kritikliği ile tetikleyicinin türü birlikte koyar.

## Aynı CVE, iki ayrı hücre

İki sistemin aynı paketi kullandığını ve paketin bir bileşeninde CVE yayımlandığını varsayın. [Bölüm 1](https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-tetikleyicileri/)'deki iki soru burada ayırıcı oluyor: etkilenen bileşeni kullanıyor muyum, etkilenen kod yoluna dışarıdan erişilebiliyor mu?

- **İç rapor aracı.** Bileşen orada da var ama araca yalnız şirket ağından, yalnız ekip erişiyor. İkinci cevap "hayır". Sinyal fırsat; "etkilenmiyoruz" kaydı düşülür.
- **Ödeme akışı.** Aynı bileşen internetten erişilen bir endpoint'in arkasında. İki cevap da "evet". Sinyal zorunlu.

Paket aynı, CVE aynı, severity puanı aynı. Sıra farklı. Severity bileşenin ne kadar kötü olduğunu ölçer; sizin sisteminizin düştüğünde ne kaybedeceğini ölçmez. Bu yüzden severity tek başına sıra koymaz.

Tür, sinyal × sistemin özelliğidir: kritiklik sistemi etiketler, tür ise sinyalin o sisteme düştüğünde aldığı değeri. Matris ikisini kesiştirir.

İç araçtaki "fırsat" etiketi kalıcı bir hüküm de değil. Araç yarın internete açılırsa ya da düzeltme gelmeden önce bir exploit yayımlanırsa iki cevap da "evet" olur ve sinyal zorunluya geçer. Kayıt bu yüzden sonucu değil, gerekçeyi taşımalı: "dışarıdan erişilemiyor" cümlesi, hangi koşulda yeniden bakacağınızı da söyler.

## Üç sınıf, üç tür, dokuz hücre

Önce eksenler. Kritiklik, sistemin düştüğünde neyi durdurduğuyla tanımlanır. Ben üç sınıf kullanıyorum:

- **Kritik:** gelir ya da müşteri akışını durdurur (ödeme, giriş, sipariş).
- **Orta:** bir ekibin ya da müşteri kesiminin işini durdurur, ana akış sürer (admin paneli, raporlama, entegrasyon).
- **Düşük:** durduğunda günlerce kimse fark etmez (iç araç, tek seferlik batch).

Tür ekseni Bölüm 1'den tanıdık: zorunlu, kilitleyen, fırsat. Sıra iki adımda çıkar: önce tür, türün içinde kritiklik. Hücrelerdeki pencereler benim önerim; endüstri standardı değil. Ekibinizin kapasitesine göre kaydırın, ama bir pencere yazın.

| | Zorunlu | Kilitleyen | Fırsat |
|---|---|---|---|
| **Kritik** | **1** · triage aynı iş günü, yama 7 gün; EOL'de bitişten en az 3 ay önce | **4** · bu çeyreğin planına | **7** · ölçülmüş kazanç varsa çeyrek planına |
| **Orta** | **2** · triage 1 iş günü, yama 14 gün; EOL'de en az 2 ay önce | **5** · sonraki çeyreğin planına | **8** · backlog |
| **Düşük** | **3** · triage 1 hafta, yama 30 gün; EOL'de en az 1 ay önce ya da sistemi kapatın | **6** · bir sonraki major'dan önce | **9** · tarih yok |

Bir sinyali hücreye yerleştirmek üç adım: sistemin sınıfını belirleyin, sinyalin türünü Bölüm 1'deki tablodan alın, kesişimdeki sırayı ve pencereyi okuyun. Aynı hücreye birden çok sinyal düşerse EOL tarihi yakın olan öne geçer. Hücreler arasında ise tarih sıra koymaz; yalnız pencereyi daraltabilir.

Dokuz hücreyi tek tek anlatmayacağım; iki köşe yeter.

Kritik × zorunlu birinci sıra: hem düştüğünde en pahalı sistem hem de bekletilemeyecek sinyal. Açılıştaki kuyrukta en alta düşen satır tam burada. Tarih sütunu ona sıra veremiyordu, çünkü CVE takvime uymaz.

Düşük × fırsat dokuzuncu sıra. Bu "hiç yapmayın" demek değil, "tarih vermeyin" demek: o repoya başka bir iş için zaten girildiğinde yapılır. Dokuzuncu sıranın işlevi, bu işin kuyruğu şişirip birinci sıradaki işi yavaşlatmasını engellemek.

Ortadaki hücreler iki köşenin arasında kalır ve en çok tartışma çıkaran yer burası: Orta × zorunlu ile Kritik × kilitleyen. Önerim, zorunluyu öne almak. Zorunlu sinyalin tarihi ya da istismar riski sizden bağımsız ilerler; kilidin ise bugün bir şey bozmasa da çeyrek ölçeğinde bir bütçesi var. Kilidin bütçesi bitmek üzereyse bu kuralı bozmak size ait bir karardır, matris bunu yasaklamaz.

Pencereyle EOL çakışırsa EOL kazanır. Hücredeki süre kuralın kendisi, EOL tarihi ise tavan; ikisinden erken olan geçerli. Düşük × zorunlu hücresinin 30 günü, bitişe 20 gün kalmışsa 20 güne iner.

EOL'ün de "upstream bitti" ile "düzeltme gelmeyecek" arasında bir boşluğu var. Debian 12'nin EOL tarihi [12 Temmuz 2026](https://wiki.debian.org/DebianReleases); aynı sayfaya göre LTS 30 Haziran 2028'e kadar sürüyor. LTS'ye ya da başka bir uzatılmış destek (ELS) sağlayıcısına yaslanıyorsanız tavanınız o tarih olur. Ama hangi paketlerin kapsandığını okumak ve "LTS'ye dayanıyor" notunu hücreye yazmak sizin işiniz.

## Hücreler yerinde durmaz

Matris bir fotoğraf, sinyaller hareket eder. Tür zamanla kayar: fırsat kilitleyene, kilitleyen zorunluya döner. Mekanizma basit: ertelenen fırsat seçenekleri daraltır, daralan seçenek bir tarihe dayanır.

PHP 8.2 üzerinde çalışan orta kritiklikte bir sistem düşünün. Kullandığınız bir paketin yeni major sürümü çıktığında ona geçmek fırsattır; eski major hâlâ çalışıyor, hiçbir şey bozulmuyor. Paket eski major'a düzeltme göndermeyi bırakınca aynı iş kilitleyene döner. Bir güvenlik düzeltmesi yalnız yeni major'a gelirse kilit zorunluya geçer.

Runtime satırı bu yolu yürümez, çünkü EOL tarihi yayımlandığı gün sinyal zorunludur. [php.net](https://www.php.net/supported-versions.php) 8.2'nin security desteğinin **31 Aralık 2026**'da bittiğini yazıyor; bu yazının yayın tarihinden 53 gün sonra. Orta × zorunlu hücresi bitişten en az 2 ay önce bitirmeyi istiyor; o pencere bu yazı yayımlanmadan kapandı.

Aynı sistemde iki saat birden çalışır. [Laravel 12.x sürüm notları](https://laravel.com/docs/12.x/releases) Laravel 12'nin security fix'lerinin **24 Şubat 2027**'ye kadar sürdüğünü söylüyor. Runtime satırı ile framework satırı 55 gün arayla tavana dayanır. Tek bir "PHP 8.2" satırı bu iki tavanı tek tarihe sıkıştırır.

Eksenlerin ikincisi de kayar, ama farklı bir nedenle: kritiklik zamanla değil, işle değişir. Ödeme akışına endpoint açan iç araç, o gün Düşük'ten Kritik'e geçer. Kod aynı kalır, sınıfı değişir.

Kayma yönü tek taraflı: fırsat kendiliğinden zorunluya yürür, geri dönmez. Bu yüzden "sonra bakarız" kararı bedelsiz değil; her turda hücreyi bir adım zorunluya yaklaştırır. Ertelenen iş ucuz kalmaz, pahalı bir tarihe doğru ilerler.

Bu yüzden matrisi bir kez doldurup kuyruğa gömmeyin. Her planlama turunda, her sinyalin hücresini yeniden okuyun. Hücreyi sinyalin yanında tutun (issue etiketi, PR açıklaması); kayma bir sürpriz değil, turun ilk maddesi olur.


> **Tan:** Matrisin kuralını bozduğunuz her kararı, gerekçesi ve bir bitiş tarihiyle birlikte yazın. Bir bağımlılık kilidi yüzünden sırası öne alınan iş, kilit kalktığında kendi hücresine dönmeli. Yazılmamış istisna, bir sonraki planlama turunda kural gibi okunur.


## Bu çerçevenin sınırı

Matris sırayı verir. Hedef sürümü vermez: 8.3 mü, 8.4 mü, 8.5 mi kararı Bölüm 4'te. Hazır olup olmadığınızı da vermez: testleriniz, geri dönüş yolunuz ve bağımlılık haritanız Bölüm 5'te.

Birinci sırada olmak, başlamaya hazır olmak demek değil. Matris "önce bu" der; "bugün bu" demez. Birinci sıradaki sistemin testi yoksa, ilk iş upgrade değil o testin yazılması olabilir; bu ayrımı Bölüm 5 yapacak.

Matris ayrıca bir sistemin hangi sınıfa girdiğini sizin yerinize söylemez. "Bu sistem Kritik mi, Orta mı?" sorusu çoğu ekipte ilk tartışmayı çıkarır. Tanım sorusunu "düştüğünde ne durur?" olarak tutarsanız tartışma kısalır: cevap bir ürün özelliğine değil, bir iş akışına işaret etmeli.

Üç sınıf bilerek kaba tutuldu. Burada risk skoru ya da formül yok; formüle ihtiyaç duyan bir ekip sınıfları dörde bölebilir, matrisin mantığı değişmez.

## Kuyruğu yeniden dizin

Başa dönelim. İç rapor aracı en üstteydi, ödeme akışındaki CVE en altta. Matrisle sıra tersine döner: ödeme × zorunlu birinci, iç araç ise EOL'ü yakın olsa da üçüncü sıraya, kendi penceresine iner. Tarih iç aracı kuyruktan çıkarmadı; yalnız sırasını belirlemekten vazgeçti.

Tarih sırasıyla ilerleyen kuyruk, işi sakin gösterir: her satırın bir günü var, hiçbiri yanlış değil. Matris bu sakinliği bozar, çünkü bazı satırları tarihine bakmadan öne çeker. Rahatsız edici ama doğru olan bu.

Sırayı yanlış koymanın bedeli [Bölüm 0](https://muhammetsafak.com/tr/muhendislik/denemeler/upgrade-ertelemenin-maliyeti/)'da yazılı. [Bölüm 1](https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-tetikleyicileri/) sinyalleri türlere, [Bölüm 2](https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-envanteri/) sistemi katmanlara ayırmıştı. Bu bölüm ikisini sıraya çevirdi.

Tarih, kuyruğa girmek için bir neden olabilir; sırayı koymak için yetmez.

Envanterinizdeki sistemleri üç kritiklik sınıfına ayırın, kuyruğunuzdaki upgrade sinyallerini matrise yerleştirin, en üst hücredekini bu sprint'e alın.

## Kaynaklar

- [Supported Versions](https://www.php.net/supported-versions.php) — PHP
- [Laravel 12.x Release Notes](https://laravel.com/docs/12.x/releases) — Laravel
- [DebianReleases](https://wiki.debian.org/DebianReleases) — Debian