Gece 03:00. Kritik bir sunucu yanıt vermiyor. Ekip panik halinde. Herkes farklı bir şey deniyor: biri servisi yeniden başlatıyor, diğeri config dosyasını düzenliyor, bir başkası kernel parametrelerini değiştiriyor. Sonuç? Sunucu nihayet ayağa kalktığında, kimse gerçekte neyin sorunu çözdüğünü bilmiyor.
Bu sahneyi kariyerimde sayısız kez gördüm. Ve her seferinde aklıma Öklid'in 2300 yıl önce formüle ettiği basit bir matematik ilkesi geliyor.
Bir Denklem, Bir Bilinmeyen
Öklid'in cebir kuralı açıktır: Bir bilinmeyenli bir denklemin tek bir çözümü vardır.
x + 5 = 12 → x = 7
Çözüm kesindir, tekrarlanabilir, doğrulanabilir.
Peki ya iki bilinmeyen eklerseniz?
x + y = 12 → x = ?, y = ?
Artık sonsuz çözüm var. x=1, y=11 olabilir. x=6, y=6 olabilir. x=100, y=-88 bile olabilir. Belirsizlik, bilinmeyen sayısıyla birlikte katlanarak artar.
Sistem Yönetiminde Öklid Prensibi
Bu matematiksel gerçeği altyapı operasyonlarına uyguladığımızda ortaya şu ilke çıkıyor:
Bir sistemde aynı anda yalnızca bir değişken değiştir. Sonucu gözlemle. Sonra devam et.
Kulağa basit geliyor. Ama saat gece 3'ü gösterirken, müşteri hattı kızarırken, herkes "hızlı çözelim" baskısı altındayken bu ilkeye sadık kalmak gerçek disiplin gerektirir.
Gerçek Hayattan Bir Örnek
Geçtiğimiz ay bir müşterimizin router'ında yapılandırma değişikliği gerekti. Aynı zamanda firmware güncellemesi de beklemedeydi. Mantıklı olan ne? "İkisini birden yapalım, nasılsa restart gerekiyor" demek.
Yapmadık.
Önce config değişikliğini yaptık. Restart ettik. Router sorunsuz ayağa kalktı. Değişikliğin doğru çalıştığını doğruladık. Sonra firmware güncellemesini planladık.
Neden? Çünkü router restart sonrası açılmasaydı, iki olasılıkla karşı karşıya kalacaktık:
- Config hatası mı?
- Firmware sorunu mu?
İki bilinmeyen. Sonsuz ihtimal. Gece 3'te son isteyeceğiniz şey.
Pratikte Nasıl Uyguluyoruz?
1. Değişiklikleri atomik tut
Her değişiklik bağımsız olmalı. "Şunu da yapayım madem" dürtüsüne karşı koy.
2. Gözlem penceresi bırak
Bir değişiklikten sonra sistemi gözlemle. Logları kontrol et. Metrikler normale döndü mü? Ancak ondan sonra bir sonraki adıma geç.
3. Geri alma planın hazır olsun
Tek değişken değiştirdiğinde, geri almak da tek adım. İki değişken değiştirdiğinde, geri alma sırası bile belirsizleşir.
4. Belgelemeyi ihmal etme
Ne zaman, ne değişti, sonuç ne oldu? Bu kayıtlar gelecekteki "x + y = ?" durumlarında hayat kurtarır.
Hız Yanılsaması
"Ama bu yaklaşım yavaş!" diyebilirsiniz.
Hayır, değil. Hızlı görünen yaklaşım aslında daha yavaştır. Üç değişikliği aynı anda yapıp sorun çıktığında harcanan debug süresi, üç ayrı değişikliği sırayla yapıp doğrulamanın çok üstündedir.
Acil müdahale gerektiren anlarda bile bu prensip geçerlidir. Hatta özellikle o anlarda geçerlidir. Panik halinde yapılan çoklu değişiklikler, küçük bir sorunu kurtarılamaz bir felakete dönüştürebilir.
Sonuç
Öklid'in matematiği bize 2300 yıldır aynı şeyi söylüyor: Belirsizliği azaltmak istiyorsan, bilinmeyenleri azalt.
Sistem yönetiminde bu, her seferinde tek bir değişiklik yapmak anlamına geliyor. Sabır gerektirir. Disiplin gerektirir. Ama kariyerim boyunca beni sayısız gece vardiyasından, sayısız eskalasyondan, sayısız "ne olduğunu bilmiyoruz" toplantısından kurtardı.
Bir sonraki değişikliğinizde kendinize sorun: Kaç bilinmeyenle uğraşıyorum?
Cevap birden fazlaysa, durun. Öklid'i hatırlayın.