Single Point of Failure (SPoF) Nedir, Nasıl Bulunur?

Single Point of Failure (SPoF), yani tek nokta arızası, bir sistemde devre dışı kaldığında bütün işi durduran ve yerine geçecek ikincisi bulunmayan bileşendir. Bir sunucu olabilir, bir internet hattı olabilir, bir kablo olabilir. Bir kişi de olabilir, ve pratikte en pahalıya patlayan genellikle o sonuncusudur.

Eski apartmanların kazan dairesini düşünün. Bina ısınır, herkes memnundur, kimse o kapıya yıllarca bakmaz. Ta ki kışın ortasında kazan durana kadar. O gün iki ayrı soru aynı anda ortaya çıkar: yedek kazan var mı, ve kapının anahtarı kimde? İkisinin de cevabı çoğu binada aynıdır: yedek yok, anahtar da bir kişide. Kurumsal BT altyapısı da tam olarak böyle çalışır. Bu yazı boyunca kazan ile anahtarı birlikte takip edeceğiz, çünkü tek nokta arızasının teknik ve insani yüzü aslında aynı kusurun iki görünümüdür.

Bu makale, BT Danışmanlık hizmetimizin risk tespiti koluna odaklanır. Amacı bir felaket senaryosu anlatmak değil; kurumunuzdaki tek noktaları, onlar kendilerini haber vermeden önce bulmanızı sağlayacak pratik bir yöntem bırakmaktır.

Single Point of Failure (SPoF) Nedir?

Tek nokta arızası, teknik bir arıza türü değil bir mimari özelliktir. Bir bileşen, yalnızca bozulduğu için tek nokta arızası olmaz; bozulduğunda yerini alacak bir ikincisi olmadığı için olur. Bu ayrım kulağa ince gelebilir ama pratikte her şeyi değiştirir: tek nokta arızası, arıza gününde değil kurulum gününde doğar.

Tanımın İşe Yarayan Hâli: “İkincisi Var mı?”

Sahada işe yarayan tanım tek soruya iner: bu şey bu gece kaybolursa, yerine ne geçer? Cevap “hiçbir şey” ise elinizde bir tek nokta arızası vardır. Cevap “şu var ama devreye almak yarım gün sürer” ise elinizde bir tek nokta arızası yoktur, kabul edilmiş bir kesinti süresi vardır. İkisi farklı şeydir ve karıştırılması bütçeyi yanlış yere harcatır.

Bu ayrımın pratik değeri, konuşmayı duygudan çıkarıp planlamaya taşımasıdır. “Sunucumuz çökerse ne olur” sorusu genellikle bir felaket tarifiyle cevaplanır ve orada kalır. “Sunucumuz çökerse yerine ne geçer, ne kadar sürede” sorusunun cevabı ise bir sayıdır, ve bir sayı bütçelenebilir. Kurumun tahammül edebileceği kesinti süresini bilmek, hangi kalemin gerçekten yedeklenmesi gerektiğini de kendiliğinden belirler.

Bu soruyu cihazlara sorduğunuzda listeniz hızla uzar: tek switch, tek firewall, tek internet hattı, tek sunucu, tek disk, tek yedekleme diski. Aynı soruyu insanlara sorduğunuzda liste kısalır ama ağırlaşır, çünkü bir sunucunun ikincisi satın alınabilir, bir kişinin ikincisi satın alınamaz.

SPoF ile Arıza Aynı Şey Değildir

Kurumlarda en sık karışan iki kavram bunlardır. Arıza bir olaydır, tek nokta arızası bir durumdur. Kazanın bozulması arızadır ve er geç olur. Yedek kazanın olmaması ise bozulmadan önce de vardır, bozulduktan sonra da. Yani tek nokta arızası, arıza olmadığı sürece görünmez ama yok değildir.

Bu ayrım, sorumluluğun nereye düştüğünü de değiştirir. Arıza teknik bir olaydır ve kimsenin kusuru olmayabilir; disk bozulur, elektrik kesilir, hat kopar. Tek nokta arızası ise bir karardır, üstelik çoğu zaman bilinçli olarak değil, ertelenerek verilmiş bir karardır. İkinci sunucu alınmamıştır, ikinci hat çekilmemiştir, yedek personel yetiştirilmemiştir. Arıza gününde konuşulan şey diskin bozulması olur, oysa konuşulması gereken şey o diskin neden tek olduğudur.

Bu yüzden “yıllardır sorun yaşamadık” cümlesi bir yedeklilik kanıtı değildir. Sadece kazanın henüz bozulmadığını söyler.

SPoF Neden Yıllarca Fark Edilmez?

Tek nokta arızaları kurumlara bir kerede girmez, birike birike girer. Her biri kendi gününde makul bir kararla doğar ve hiçbiri o gün risk gibi görünmez. Görünürlük kazandıkları tek an, kendilerini haber verdikleri andır.

Riskin Sessiz Dönemi

Tek nokta arızasının ekonomisi tuhaftır: maliyeti arıza gününe kadar tam olarak sıfırdır. İkinci sunucuyu almayan kurum, almadığı her ay için para biriktirmiş gibi görünür. Bu görüntü, kararın yanlış olduğunu gösteren hiçbir sinyal üretmez; tersine, her sorunsuz ay kararı doğrulamış gibi hissettirir.

Sonra bir gün fatura tek seferde kesilir ve biriktirilen tasarrufun kaç katı olduğu o gün öğrenilir. Sahada bunun en yaygın hâli, yedeklilik yatırımının ilk kesintiden sonra yapılmasıdır. Yani karar aslında verilir, sadece geç verilir, ve arada geçen sürede kurum riski taşıdığını bilmeden taşır.

Bu sessiz dönemin uzunluğu kalemden kaleme çok değişir ve bu değişkenlik önemlidir. Bazı tek noktalar durduğu anda kendini haber verir: internet hattı koptuğunda telefonlar aynı dakika çalar. Bazıları ise günlerce sessiz kalır, çünkü sistemin geri kalanı onlarsız bir süre daha yürüyebilir. Fark edilme süresi uzadıkça riskin sinsiliği artar, çünkü arıza ile fark ediliş arasındaki boşlukta kurum yedeksiz çalıştığını bilmeden çalışır.

”Çalışıyor” Bir Yedeklilik Kanıtı Değildir

Sistemin çalışıyor olması, yedekliliği hakkında hiçbir şey söylemez. Bunu ayırt etmenin tek yolu denemektir: yedek hat gerçekten devreye giriyor mu, yedekten dönüş gerçekten çalışıyor mu, ikinci sunucu gerçekten yükü alıyor mu? Test edilmemiş bir yedek, olmayan bir yedekle aynı güveni verir ama daha pahalıdır, çünkü üstüne bir de yanlış bir güven duygusu satın alınmıştır.

Denenmemiş yedeğin özel bir tehlikesi de şudur: kurumu yanlış tarafta rahatlatır. Yedeği olmadığını bilen kurum temkinli davranır, bakım penceresini dar tutar, riskli değişiklikleri erteler. Yedeği olduğunu sanan kurum ise bu temkini bırakır. Yani denenmemiş yedek yalnızca çalışmama riski taşımaz, aynı zamanda kurumun davranışını da gevşetir.

Yedekleme tarafında bu konu kendi başına bir disiplindir ve veri yedekleme ve felaket kurtarma yazımızda ayrıca ele alıyoruz. Buradaki mesele daha dar: yedeğin varlığı değil, denenmiş olması.

Teknik SPoF: Kurumda İkincisi Olmayan Cihazlar

Teknik tek nokta arızaları, kurumun katmanlarına dağılmış hâlde durur. Aşağıdaki liste bir korku listesi değil, bir envanter başlangıcıdır: her maddeyi kendi kurumunuz için “ikincisi var mı” sorusundan geçirin.

Katmanları yan yana koyduğunuzda, aralarındaki asıl farkın etkinin büyüklüğü değil fark edilme süresi olduğu görülür:

Son satır özellikle dikkat ister: veri katmanında fark edilme süresi sıfırdır çünkü fark edildiğinde iş çoktan bitmiştir.

Kimlik Katmanı: Tek Domain Controller

Kimlik katmanı, durduğunda en geniş yüzeyi birden söndüren katmandır. Tek Domain Controller’lı bir ortamda o sunucu durduğunda kullanıcılar oturum açamaz, dosya paylaşımlarına erişilemez, yazıcı kimlik doğrulaması yapılamaz. Yani tek bir kutu, kullanıcının masasındaki neredeyse her şeyi aynı anda etkiler.

Bu katmanın ikinci bir özelliği daha var: yedeklemesi görece ucuzdur. İkinci bir Domain Controller, birincisinin donanımıyla aynı sınıfta olmak zorunda değildir ve sanal makine olarak çalışabilir. Yani buradaki tek nokta arızası genellikle bütçe yokluğundan değil, ilk kurulumda “sonra ekleriz” denmesinden doğar ve o “sonra” gelmez.

Bu yüzden ikinci DC bir iyileştirme değil, kurulumun tamamlayıcı parçasıdır ve ilk kurulumun hemen ardından yapılmalıdır. Ayrıntısı Active Directory kurulum rehberimizde duruyor. Gerçek bir ortamda bunun nasıl kapatıldığını Active Directory modernizasyon vakamızda anlatıyoruz.

Adresleme Katmanı: Tek DHCP Sunucusu

Adresleme katmanının tek nokta arızası, kimlik katmanınınkinden daha sinsidir: hemen fark edilmez. DHCP sunucusu durduğunda çalışan cihazlar kira süreleri dolana kadar çalışmaya devam eder. Yani sistem cuma akşamı ölür, kimse fark etmez, arıza pazartesi sabahı herkes bilgisayarını açtığında ortaya çıkar.

Bu gecikmenin iki ayrı sonucu var ve ikisi de kötü. Birincisi, arıza en kalabalık anda ortaya çıkar; pazartesi sabahı aynı anda yüzlerce cihaz adres ister ve destek ekibi tek bir sunucu arızasını yüzlerce ayrı şikâyet olarak karşılar. İkincisi, arıza ile sebep arasındaki zaman farkı teşhisi zorlaştırır: cuma akşamı yapılan bir değişiklik pazartesi sabahki arızanın sebebi olarak akla gelmez.

Windows tarafında failover yapılandırmasının nasıl kurulduğunu Windows Server DHCP kurulumu yazısında adım adım ele alıyoruz; protokolün kendisi merak ediliyorsa DHCP nedir yazısı temeli veriyor.

Ağ ve İnternet Katmanı

Ağ tarafında tek nokta arızası genellikle bir cihazda değil, bir yolda durur. Tek uplink, tek switch, tek internet hattı. Bu katmanın ayırt edici özelliği, arızanın kendini saklayamamasıdır: hat koptuğunda telefonlar aynı dakika çalar, yani sessiz dönem yoktur. Bu bir avantaj gibi görünür ama değildir; sessiz dönemin olmaması riski küçültmez, yalnızca gizlenmesini engeller.

Kablosuz tarafında ise en sık rastlanan hâli yönetim katmanıdır: onlarca access point sağlam olabilir, hepsi yerinde olabilir, ama hepsi tek bir controller’a bağlıysa o controller kurumun kablosuz ağının tamamını taşıyor demektir. Bu, tek nokta arızasının en aldatıcı biçimidir, çünkü envanterde onlarca cihaz görünür ve yapı yedekli sanılır. Bunun ders kitabı örneğini kablosuz ağ tasarımı yazısında anlattık.

Anahtarlama ve yönlendirme tarafındaki yedeklilik kararları için switch ve router kurulumu yazısındaki yedeklilik bölümü başlangıç noktası olabilir.

Veri Katmanı: Yedeği Olmayan Disk

Veri katmanında tek nokta arızasının özel bir hâli vardır: yedeği olduğu sanılan veri. RAID bir yedekleme değildir, disk arızasına karşı bir süreklilik önlemidir; silinen dosyayı, şifrelenen diski ya da yanlışlıkla üzerine yazılan veriyi geri getirmez. Bu ikisinin karıştırılması, kurumların yedeği olduğunu sanarak yıllarca yedeksiz çalışmasının en yaygın sebebidir.

Bu katmanı diğerlerinden ayıran şey, arızanın geri alınamaz olmasıdır. Duran bir sunucu yeniden kurulur, kopan bir hat yenilenir, çöken bir switch değiştirilir; hepsinde kayıp zamandır. Veri katmanında ise kayıp verinin kendisidir ve hiçbir bütçe onu geri getirmez. Bu yüzden tek nokta arızası avında veri katmanı, etkisi en büyük olduğu için değil, telafisi olmadığı için ilk sırada durmalıdır.

Ama En Pahalı SPoF Cihaz Değildir

Buraya kadarki listenin ortak özelliği şudur: hepsi satın alınabilir. İkinci sunucu, ikinci hat, ikinci disk. Bütçe bulununca kapanan risklerdir.

İnsan kaynaklı tek nokta arızası bu listeye benzemez, ve tam da bu yüzden daha uzun yaşar. Kazana dönersek: bu, yedek kazanın olmaması değil, kazan dairesinin anahtarının tek kişide olmasıdır. İkinci bir kazan alabilirsiniz. Ama o kişinin kafasındakini satın alamazsınız.

İnsan SPoF’u Neden Daha Zor Görünür?

Cihaz tarafındaki tek nokta arızası bir envanter listesinde görünür. İnsan tarafındaki görünmez, çünkü her şey yolundayken bir erdem gibi durur. Her şeyi bilen, her sorunun çözüldüğü, aranan kişi. Kurum bunu bir risk olarak değil bir varlık olarak yaşar. Bu kişi izne çıkana kadar.

Görünmezliğin ikinci sebebi ölçü birimi eksikliğidir. Sunucunun yedekli olup olmadığı bir envanter alanıdır, bakılır ve görülür. “Bu bilgiyi kaç kişi biliyor” ise hiçbir yerde tutulmaz; sorulduğunda da genellikle iyimser cevaplanır, çünkü herkes bir konuyu “az çok bildiğini” düşünür. Gerçek cevap ancak o kişi yokken bir arıza çıktığında öğrenilir.

Sahada bunun nasıl göründüğüne dair yayınladığımız bir örnek var: bayram öncesi sevkiyat telaşında bir firewall kuralının kilitlenmesi ve o kurala müdahale edebilecek tek kişinin yıllık izinde olması. Anlatının tamamı BT danışmanlığı ile dijital dönüşüm yazısında duruyor. Teknik sorun küçüktü, etkisi büyüktü, ve büyüten şey arızanın kendisi değil arızayı kimin çözebildiğiydi.

Son cümle bu bölümün asıl dersini taşıyor ve bir sonraki bölümün de kapısını açıyor: bu, bilgiyi istifleyen birinin hikâyesi değil. Belgelenmiş, yazıya dökülmüş, erişilebilir hâle getirilmiş bir bilgi bile tek nokta arızasını kendiliğinden ortadan kaldırmıyor. Yani sorun her zaman bilginin nerede durduğu değil; bazen kurumun o bilgiye gitme alışkanlığının hiç kurulmamış olması.

Brent Arketipi: Herkesin Tanıdığı Kişi

BT kültüründe bu kişinin bir adı var. The Phoenix Project romanındaki Brent, her acil işin uğradığı, koridorda yakalanan, hiçbir proje onsuz ilerlemeyen mühendistir. Kitabın anlattığı şey Brent’in kötü çalışması değil, tersine çok iyi çalışmasıdır: kurum bütün kritik işleri ona yönlendirdiği için o, farkında olmadan kurumun tek nokta arızasına dönüşmüştür.

Arketipin kalıcı olmasının sebebi, okuyan herkesin kendi kurumundan birini tanımasıdır. Ve tanıdığı kişi genellikle suçlanacak biri değildir; aksine ekibin en çalışkanıdır. Sorun kişide değil, kurumun bütün yolları tek kapıdan geçirmesindedir.

Kitabı okumak isterseniz Türkçesi Bitmeyen Proje adıyla yayımlandı. Önce tadına bakmak isteyenler için yayıncının kendi sitesinde ücretsiz bir özet duruyor; Brent ilk bölümde adıyla geçiyor ve darboğaz bağı orada kuruluyor.

Bu arketip üzerine yapılan tartışmalarda tekrarlanan bir ayrım var ve işe yarar: iki tür Brent vardır, paylaşanlar ve istifleyenler. İkisi de aynı riski üretir, ikisi de aynı görünür, ama sebepleri farklıdır ve bir sonraki bölümde göreceğimiz gibi çözümleri de farklıdır.

Bus Factor: Tek Nokta Arızasını Ölçmek

İnsan kaynaklı tek nokta arızasının bir ölçüsü var ve adı biraz karanlık bir espriden geliyor: bus factor, yani ekipten kaç kişi bir otobüsün altında kalırsa işin duracağı. Bus factor = 1 demek, kurumun bir kişinin devamlılığına bağlı olması demektir.

Ölçüyü kullanışlı kılan şey, soruyu somutlaştırmasıdır. “Bilgi paylaşımımız yeterli mi?” sorusunun cevabı tartışmaya açıktır; “şu sistemin bus factor’ü kaç?” sorusunun cevabı bir sayıdır. Ve o sayıyı çıkarmak için bir anket gerekmez, üç gözlem yeterlidir: kime sık soru soruluyor, kimin izni ertelettiriliyor, hangi işler o kişi dönene kadar bekletiliyor. Üçü de kurumun günlük akışında zaten görünür, yalnız kimse not almaz.

Bilginin kendisinin de bir adı var: tribal knowledge, yani yazılı hiçbir yerde olmayan, yalnızca deneyimle biriken kurum bilgisi. Hangi sunucunun gerçekte ne işe yaradığı, bir ayarın neden o şekilde bırakıldığı, hangi kuralın neden silinemediği. Bu bilgi kaybolduğunda sistem çalışmayı sürdürür ama anlaşılmaz hale gelir, ve anlaşılmayan sistem er geç dokunulamayan sisteme dönüşür. Kimse silmeye cesaret edemediği için kurallar birikir, kimse değiştirmeye cesaret edemediği için yapılandırma donar.

Bilgi İstifleme ile Bilgi Saklama Farkı

Buraya kadar insan kaynaklı tek nokta arızasını tek bir sorun gibi anlattık. Değil. Görünüşü aynı olan iki ayrı davranış var ve çözümleri aynı değil. Karıştırıldığında yanlış müdahale yapılır: iyi niyetli bir çalışan suçlanır ya da gerçek bir sorun süreç eksikliği sanılır.

Kasıtsız Olan: Bilgi İstifleme

Bilgi yönetimi literatüründe knowledge hoarding, bilginin kişide birikmesi ama bunun bilinçli bir saklama olmamasıdır. Kişi anlatmaya vakit bulamamıştır, yazmak kimsenin işi olarak tanımlanmamıştır, ya da anlatmak her seferinde işi yapmaktan uzun sürdüğü için ertelenmiştir.

Bu hâlin ayırt edici işareti şudur: sorulduğunda anlatır. Sorun bilginin verilmemesi değil, hiçbir zaman istenmemiş olmasıdır. Çözümü de o yüzden süreçtir: dokümantasyonu bir işin parçası hâline getirmek, devir toplantısını takvime koymak, ikinci bir kişiyi aynı işe düzenli olarak sokmak.

Bu ayrımı yapmadan müdahale eden kurumlar genellikle aynı hatayı yapar: iyi niyetli ve yorgun bir uzmandan “bilgini paylaş” diye talep ederler, oysa o kişi zaten paylaşmaya isteklidir, sadece o iş kimsenin takviminde yoktur. Talep yerine takvim koymak, bu vakaların çoğunu sessizce çözer.

Kasıtlı Olan: Bilgi Saklama

Knowledge hiding ise farklıdır: bilgi istendiği hâlde verilmez. Literatür bunu ayrı bir davranış olarak inceler, çünkü sebebi de sonucu da farklıdır. Burada bilgi bir iş aracı değil, bir pazarlık gücü olarak tutulur; vazgeçilmezlik bilinçli olarak korunur.

Bu ayrımın pratik değeri şudur: birinci durumda süreç kurmak sorunu çözer, ikinci durumda çözmez. İkinci durumda süreç kurmak yalnızca direnci görünür kılar, ki bu da bir kazançtır ama farklı bir kazançtır ve farklı bir konuşma gerektirir. Dokümantasyon talebi karşısında sürekli ertelenen, hep başka bir önceliğin arkasına saklanan bir iş, çoğu zaman bir zaman sorunu değil bir istek sorunudur.

Burada dikkat edilecek nokta, teşhisi acele koymamaktır. Dışarıdan bakıldığında iki davranış aynı görünür ve iyi niyetli bir uzmanı “bilgiyi saklıyor” diye işaretlemek, hem haksızlık hem de kurumun kaybedeceği bir ilişkidir. Ayrımı yapan tek soru şudur: istendiğinde veriyor mu?

İstifleyen de Tuzağa Düşer

Bu bölümün en az konuşulan tarafı da bu. Vazgeçilmez olmak bir güvence gibi görünür ama pratikte kişinin kendi ayağına dolanır: izne çıkamaz, hastalanamaz, ve en önemlisi terfi edemez, çünkü bulunduğu yerde fazla değerlidir. Bilgiyi paylaşmamak, kişiyi bulunduğu pozisyona kilitler.

Bunu ekibe anlatmak, çoğu zaman “dokümantasyon yazın” demekten daha etkili olur. Çünkü ilki bir talep, ikincisi bir çıkar örtüşmesidir. Bir uzmanın kendi işini devredebilir hâle getirmesi, kurumun riskini azaltırken o kişinin önünü de açar; bu iki çıkarın aynı yöne baktığı az sayıdaki konudan biridir.

Kurumdaki SPoF’ları Nasıl Bulursunuz?

Bu bölümün amacı, buraya kadar anlatılanı bir denetim adımına çevirmek. Tek nokta arızası aramanın en pratik yolu, felaket senaryoları kurmak değil envanterden yürümektir.

Envanterle Başlayın, Tahminle Değil

Bir kurumda neyin tek olduğunu bilmek için önce neyin var olduğunu bilmek gerekir. Envanter dışında kalan bir cihaz, tanımı gereği yedekliliği de hiç düşünülmemiş bir cihazdır. Bu yüzden tek nokta arızası avı, aslında bir envanter işidir; açık kaynak tarafında bunu GLPI ile nasıl kurduğumuzu ayrıca anlatıyoruz. Bu avın en zor kısmı, envantere hiç girmemiş olanlardır: tek olup olmadıkları bir yana, var oldukları bile bilinmez. O listeyi nasıl çıkaracağınızı gölge BT yazımızda ele alıyoruz.

Envanterin insan tarafındaki karşılığı da vardır ve çoğu kurumda hiç tutulmaz: hangi sistemin sorumlusu kim, o kişi yokken kim bakıyor, ve o ikinci kişi gerçekten bakabiliyor mu yoksa listede mi duruyor? Bu son soru önemlidir, çünkü kâğıt üstündeki yedek personel gerçek bir yedeklilik değildir; denenmemiş bir yedek hattan farkı yoktur.

Bu Aslında ISO 27001’in Zaten İstediği Şey

Buraya kadar anlattığımız envanter işi size tanıdık geldiyse sebebi var: bunlar bir bilgi güvenliği standardının maddeleri. ISO 27001’in Ek A kontrolleri arasında A.5.9 bilgi ve ilgili varlıkların envanterini, A.5.2 bilgi güvenliği rollerinin ve sorumluluklarının tanımlanmasını, A.6.5 ise işten ayrılma veya görev değişikliği sonrası sorumlulukları düzenler. Yani “neyim var, kim sorumlu, o kişi giderse ne oluyor” sorularının üçü de standarda ayrı birer madde olarak girmiş.

Belgeyi almak zorunda olmayabilirsiniz. Çoğu kurum için ISO 27001 bir müşteri şartı ya da ihale şartı olarak gündeme gelir; öyle bir zorlama yoksa belgelendirme masrafına girmenizi gerektiren bir sebep de yoktur. Ama standardın maddelerini gayriresmî olarak uygulamak başka bir şey ve karşılığı doğrudan: elinizde, sıfırdan düşünmek zorunda kalmadan bir çalışma planı olur.

Bunun en ikna edici tarafı da şu: tek nokta arızalarını kendi başınıza çözmeye kalksanız, birkaç ay sonra vardığınız yer zaten bu maddeler olacak. Envanter tutmadan neyin tek olduğunu bilemediğinizi göreceksiniz, sorumluyu yazmadan yedeğin gerçek olup olmadığını ölçemediğinizi göreceksiniz, ayrılan personelin devrini kurala bağlamadan aynı boşluğun tekrar açıldığını göreceksiniz. Standart, bu keşifleri sizden önce yapmış insanların notlarıdır. Belgesini almasanız bile listesini okumak zaman kazandırır.

Üç Soruluk Test

Her kalem için sırayla sorun. Testin değeri kısalığında: uzun bir risk analizi yapılmadan, bir toplantıda tamamlanabilir.

1. Bu gece kaybolursa yerine ne geçer? Cevap “hiçbir şey” ise tek nokta arızasıdır.
2. Yerine geçecek şey son ne zaman denendi? Cevap “denemedik” ise pratikte hâlâ tek nokta arızasıdır.
3. Devreye almayı kim biliyor, o kişi tek mi? Cevap “tek” ise cihazın yedeği vardır ama bilginin yoktur, yani tek nokta yer değiştirmiştir.

Üçüncü soru bu testin en çok atlanan ve en çok iş görenidir. Yedekli kurulmuş bir sistemin, devreye alma bilgisi tek kişideyse gerçekte yedekli olmadığını gösterir. Kazan ikilenmiştir, anahtar hâlâ tektir.

Testi uygularken listeyi bilinçli olarak kısa tutun. Bir kurumda onlarca tek nokta bulunur ve hepsini aynı anda kapatmaya çalışmak, çoğu zaman hiçbirini kapatmamakla sonuçlanır. İlk turda yalnız iki soruya bakmak yeterlidir: hangisi durduğunda iş hemen durur, ve hangisinin arızası geri alınamaz? Bu ikisinin kesiştiği yer, bütçenin gideceği yerdir.

Dokümantasyon Bir Yedeklilik Aracıdır

Dokümantasyon bu yazıda bir düzen işi olarak değil, doğrudan bir yedeklilik önlemi olarak geçiyor. Bilgiyi bir kişinin kafasından çıkarıp kurumun erişebileceği bir yere koymak, insan kaynaklı tek nokta arızasını ikilemenin en ucuz yoludur.

Ama yazılmış olması tek başına yetmiyor, ve bunu deneyerek öğrendim. Yukarıdaki saha notunda anlattığım kurumda dokümantasyon vardı, üstelik hatırı sayılır bir dokümantasyondu; yine de telefon çalmaya devam etti. BT dokümanı yazmak ayrı bir iş, onu okumak ayrı bir iştir. Kurum ilkini yaptırır, ikincisini alışkanlık hâline getirmezse elde kalan şey kimsenin açmadığı bir arşivdir.

Bu yüzden dokümantasyonun karşılığı yalnız yazmakla ölçülmez. İşe yarayıp yaramadığını gösteren tek soru şudur: son bir ayda kaç soru dokümana bakılarak çözüldü, kaçı o kişi aranarak? Oran ikinciden yanaysa doküman vardır ama yedeklilik yoktur. Ama bir uyarıyla: yazılmış olması yetmez, güncel olması gerekir. Bakılmayan bir doküman altı ay içinde yanlış bilgi kaynağına döner ve o noktadan sonra hiç olmamasından daha zararlıdır, çünkü kurum ona güvenerek karar verir. Bu yüzden dokümantasyonun kendisi de üçüncü sorudan geçmelidir: son ne zaman denendi, yani biri o dokümanı takip ederek işi gerçekten yapabildi mi?

Yıllarca birikmiş yazısız kurum bilgisini gerçek bir ortamda nasıl topladığımızı BT dokümantasyon sistemi vaka çalışmasında anlatıyoruz. Dışarıdan destekle kapatma seçeneği de masadadır ve tek kişiye bağımlılığı azaltmanın bilinen yollarından biridir; kararın ölçeğe göre nasıl değiştiğini BT dış kaynak kullanımı yazısında ele alıyoruz.

Sonuç

Tek nokta arızası, kurumun kötü yönetildiğinin işareti değildir; büyürken biriken ve kendini yalnızca arıza gününde gösteren bir mimari borçtur. Her biri kendi gününde makul bir kararla doğar, hiçbiri o gün risk gibi görünmez, ve hepsi aynı soruyla ortaya çıkar: ikincisi var mı?

O soruyu cihazlara sormak kolaydır ve çoğu kurum bir ölçüde sorar. Asıl kazanç, aynı soruyu insanlara ve bilgiye sormaya başladığınızda gelir. Çünkü kazanın ikincisi satın alınabilir, anahtarın ikincisi ise ancak biri onu yazıya dökerse çoğalır.

Başlamak için büyük bir proje gerekmez. Elinizdeki envanteri açın, üç soruluk testi uygulayın, ve listenin en üstündeki iki kalemi kapatın. Tek nokta arızalarının tamamını kapatmak zaten hedef değildir; hedef, hangilerinin açık olduğunu bilerek çalışmaktır. Son olarak, bütün bu tek noktaların altında yatan ortak sebebi söylemek gerek: günü kurtarmayı seçmek. Bir işi bugün en hızlı bitirecek yol, o işi zaten bilen kişiye vermektir; ikinci bir kişiye öğretmek bugün daha yavaştır. Her seferinde hızlı olanı seçtiğinizde, aylar sonra elinizde her yolu üstünden geçen tek bir kişi kalır. Sonra o kişi hakkında “ne yaptığını tam bilmiyoruz” deniyorsa, ortada bir personel sorunu değil bir iş yönetimi sorunu vardır.

Aynı tercih dokümantasyonda da karşınıza çıkar. Biri oturup kurumun hafızasını yazmışsa ve siz o yazıyı açmak yerine yazarını arıyorsanız, yine günü kurtarmayı seçmişsinizdir. Tek nokta arızalarını kapatan şey tek seferlik bir proje değil, her seferinde biraz daha yavaş olanı seçme alışkanlığıdır.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.