Sistemin çok iyi çalışıyor. Ta ki nedenini bilen kişi çalışana kadar.
Şirketin yedi yıldır geliştirilen bir sistemi var. Çalışıyor. Müşterileri destekliyor. Diğer sistemlerle bağlantı kuruyor. Şirketin normal şekilde işleyebilmesi için aslında vazgeçilmez olan süreçleri yürütüyor.
Bu yedi yıl boyunca projede beş geliştirici çalıştı. Buna ek olarak iki freelancer ve bir ajans vardı. Belgelerin bir kısmı Confluence’ta, bir kısmı Google Drive’da, bir kısmı da ticket’larda duruyor. Bir yerde hâlâ entegrasyonlardan birine ait eski bir belge var. Ve biri sistemin belirli bir bölümünün neden tam da bu şekilde çalıştığını sorduğunda cevap şu oluyor: "Galiba bunu Michał hatırlıyordu."
Michał üç yıl önce ayrıldı.
Ve asıl sorun tam da o zaman başlıyor.
Çünkü sistem kötü yazıldığı için değil. Birdenbire çalışmayı durdurduğu için de değil. Sorun, şirketin kendi sistemine dair tam bilgiye artık sahip olmamasıdır.
Sistem çalışıyor, ama şirket onu kontrol edemeyebilir
Bu, teknolojik borcun en az değerlendirilen biçimlerinden biridir.
Teknolojik borçtan söz ettiğimizde genellikle eski kodu, güncel olmayan kütüphaneleri, mimari hataları, test eksikliğini veya bir zamanlar hızlı olan ama bugün gelişimi zorlaştıran çözümleri düşünürüz.
Oysa bir başka borç türü daha vardır. Bilgi borcu.
Bu, sistem belgelendirmede, depoda, prosedürlerde ya da organizasyonda değil, yalnızca belirli kişilerin kafasında bulunan bilgilere bağımlı olduğunda ortaya çıkar.
Ve bu kişiler erişilebilir olduğu sürece her şey normal görünebilir.
Sorun, ekip değiştiğinde, bir geliştirici ayrıldığında, bir software house ile iş birliği sona erdiğinde, sunucu çöktüğünde, yönetici değiştiğinde ya da yeni bir çözümün hızla devreye alınması gerektiğinde ortaya çıkar.
Birden şirketin kodu vardır, ama bilgisi yoktur.
Sunucusu vardır, ama kimin erişimi olduğu kesin değildir.
Bir entegrasyonu vardır, ama hangi hesapla kurulduğu bilinmez.
Dokümantasyonu vardır, ama hangi sürümün güncel olduğu bilinmez.
Bir süreci vardır, ama neden tam olarak böyle tasarlandığı bilinmez.
Ve tam o anda çok hızlı bir soru ortaya çıkar: bu sistemin aslında sahibi kim?
Bus factor, yani bir kişi kaybolursa ne olur?
IT dünyasında bus factor diye bir kavram vardır. Basitleştirirsek, bir ekibin bir proje geliştirmeyi veya sürdürmeyi etkili biçimde devam ettirememesine yol açabilecek erişilemez kişi sayısını ifade eder.
Elbette bu, kelime anlamıyla bir olay demek değildir. Bu, bilginin tek elde toplanmasını düşünme biçimidir.
Kritik bir entegrasyonun nasıl çalıştığını yalnızca bir kişi biliyorsa, o bilginin bus factor’ü birdir.
Üretim ortamına yalnızca bir yönetici erişebiliyorsa, bus factor birdir.
Sistemin her gece belirli bir işlemi neden yaptığını yalnızca bir kişi biliyorsa, bus factor bir olabilir.
Şirket bir dış software house ile çalışıyorsa ve müşteri tarafında kimse çözümün mimarisini anlamıyorsa, daha da büyük bir sorun ortaya çıkar - bilgi organizasyonun dışında olabilir.
Bu, her şirketin sistemin her parçası için beş uzmana sahip olması gerektiği anlamına gelmez.
Mesele çok daha basittir: şirket, kritik bilginin nerede olduğunu ve belirli bir kişi olmadan onu geri kazanıp kazanamayacağını bilmelidir.
Kod nasıl olduğunu söyler. Her zaman neden olduğunu söylemez.
Bir geliştirici kodu okuyup belirli bir fonksiyonun ne yaptığını anlayabilir.
Ancak her zaman neden tam da bu şekilde yazıldığını bilemeyebilir.
Bu, çok büyük bir farktır.
Dış bir sisteme veri göndermekten sorumlu bölümü bulabilirsiniz. Endpoint’i, parametreleri, yetkilendirmeyi ve hata yönetimini analiz edebilirsiniz.
Ama kod şu sorulara mutlaka cevap vermez:
- Verileri neden gece 2:00’de gönderiyoruz?
- Neden bu belirli durum atlanıyor?
- Neden bir hatadan sonra sistem tam üç kez yeniden deniyor?
- Neden bir değer gönderilmeden önce dönüştürülüyor?
- Neden bu işlemlerin sırası değiştirilemiyor?
- Neden bu entegrasyon belirli bir hesabı kullanıyor?
Cevap proje geçmişinde, yıllar öncesinden kalma bir ticket’ta, altı yıl önce atılmış bir e-postada ya da - daha kötüsü - artık şirkette çalışmayan birinin hafızasında olabilir.
Bu yüzden iyi bir dokümantasyon yalnızca "nereye tıklanır" talimatı olmamalıdır.
Aynı zamanda bağlamı ve kararları da saklamalıdır.
En büyük sorun, artık kimsenin hatırlamadığı bir entegrasyon olabilir
Modern bir sistem neredeyse hiçbir zaman tamamen bağımsız çalışmaz.
ERP sistemiyle. CRM ile. Ödeme geçidiyle. SMS sağlayıcısıyla. Kargo sistemiyle. İş ortağı API’siyle. Bulut hizmetiyle. Analitik platformuyla. Muhasebe sistemiyle. Yetkilendirme mekanizmasıyla bağlantı kurar.
Bu bağlantıların her biri teknolojik zincirin bir parçasıdır.
Ve bu zincirin her parçasının kendi sahibi, hesabı, API anahtarı, sertifikası, sözleşmesi, limiti, API sürümü ve yaşam döngüsü olabilir.
Birkaç yıl sonra artık o hesabı kimin açtığını kimse hatırlamayabilir.
Ve o zaman sistemin çalışmayı durdurması için yalnızca sertifikanın süresinin dolması ya da API’nin değişmesi yeterlidir.
Daha da kötüsü, şirket o bağımlılığın var olduğunu bile bilmiyorsa.
Bu nedenle sistemlere yönelik olgun yaklaşımlarda yazılım menşei, bağımlılık yönetimi ve yazılım tedarik zincirinin şeffaflığı giderek daha fazla önem kazanıyor. NIST, güvenlik tedarik zincirine ilişkin güncel materyallerinde diğerlerinin yanı sıra bileşenler, bunların kökeni, yaşam döngüsü ve bağımlılıkları hakkındaki bilginin önemine dikkat çekiyor. SBOM, yani Software Bill of Materials, yazılımın hangi bileşenlerden oluştuğuna dair bilgiyi düzenlemeye yardımcı olan araçlardan biridir.
Bu artık yalnızca güvenlik ekibinin konusu değil.
Bu aynı zamanda yönetim kurulunun da konusu.
Çünkü şirket sisteminin nelerden oluştuğunu bilmiyorsa, riski, bakım maliyetini ve değişikliklerin sonuçlarını değerlendirmesi zorlaşır.
Dokümantasyon bir maliyet değildir. Bir poliçedir.
Birçok şirkette dokümantasyon, "sonra yapılır" diye görülen bir şey olarak ele alınır.
Önce işlevsellik.
Sonra devreye alma.
Sonra düzeltmeler.
Sonra bir sonraki proje.
Peki ya dokümantasyon?
"Zaman olunca."
Sorun şu ki, dokümantasyon için zaman genellikle artık çok geç olduğunda gelir.
Dokümantasyon, iş dünyasındaki bir sigorta gibi çalışmalıdır. Bunun sebebi birinin onu her gün okuyacak olması değil. Aksine - mümkünse bir acil durumda ona en seyrek şekilde ihtiyaç duyulsun.
Ama bir sorun çıktığında şirketin temel sorulara cevap verebilme imkânı olmalıdır:
- Sistem nasıl çalışıyor?
- Nelerden oluşuyor?
- Üretim ortamı nerede?
- Kimlerin erişimi var?
- Kritik entegrasyonlar neler?
- Hangi hesaplar ve dış hizmetler kullanılıyor?
- Bağımlılıklar neler?
- Yedekler nasıl alınıyor?
- Yayınlama süreci nasıl görünüyor?
- Bir arıza sırasında ne oluyor?
- İş açısından hangi unsurlar kritik?
- Temel mimari kararlar neden alındı?
- Sistemin bakımını kim devralabilir?
Bu, yüzlerce sayfalık dokümantasyon anlamına gelmek zorunda değil.
İyi dokümantasyon her şeyden önce yararlı, güncel ve doğru kişilerin erişimine açık olmalıdır.
"Dokunmayalım, çalışıyor" her zaman kötü bir karar değildir
Bir de çok yaygın bir başka sorun var.
Sistem yıllardır çalışıyor, bu yüzden şirket şu ilkeyi benimsiyor: "Dokunmuyoruz. Çalışıyor."
Ve bazen bu tamamen makul olabilir.
Her eski teknoloji hemen değiştirilmek zorunda değildir. Her eski kod parçasının yeniden yazılması gerekmez. Her kütüphane felaket anlamına gelmez. Birkaç yıl öncesinin her mimarisi yanlış değildir.
Sorun, "dokunmayalım" aynı zamanda şunları da ifade etmeye başladığında ortaya çıkar:
- "Analiz etmeyelim."
- "Dokümante etmeyelim."
- "Bağımlılıkları kontrol etmeyelim."
- "Kimin erişimi olduğunu sormayalım."
- "Hâlâ tüm hesaplara sahip olup olmadığımızı kontrol etmeyelim."
- "Mevcut yüklenici artık erişilebilir olmadığında ne olacağını belirlemeyelim."
O zaman değişiklik olmaması bir strateji değildir.
Riskin ertelenmesidir.
Bazen en iyi teknik karar gerçekten hiçbir şeyi yeniden inşa etmemektir.
Ama bu karar, sistem hakkındaki bilgiye dayanmalı; sistem hakkındaki bilgi eksikliğine değil.
Devralınan bir sistemin denetimi neleri içermelidir?
Bir şirket bir sistemi başka bir yazılım ajansından, freelancerdan ya da dahili bir ekipten devraldığında, ilk adım her şeyi otomatik olarak yeniden yazmak olmamalıdır.
Önce gerçekte neyin devralındığını anlamak gerekir.
Denetim en az birkaç temel alanı yanıtlamalıdır.
Mimari. Sistem nasıl kurulmuş? Başlıca bileşenleri neler? Veriler nerede? Farklı parçalar nasıl iletişim kuruyor?
Kod ve depolar. Şirket tam kaynak koda sahip mi? Hangi dalın ve sürümün üretimde olduğu biliniyor mu? Derleme ve dağıtım süreci yeniden oluşturulabiliyor mu?
Altyapı. Üretim nerede çalışıyor? Test ortamı nasıl görünüyor? Kimlerin erişimi var? İzleme ve yedekleme nasıl?
Entegrasyonlar. Sistem neyle iletişim kuruyor? Hangi API’leri kullanıyor? İlgili hesapların ve anahtarların sahibi kim?
Bağımlılıklar. Hangi kütüphaneler, çerçeveler ve dış bileşenler kullanılıyor? Güncelleniyorlar mı? Bilinen güvenlik sorunları var mı? Yaşam döngüleri nasıl görünüyor?
Yayın süreci. Yeni biri, eski yazılımcıyı aramadan bir değişikliği hazırlayıp test edip yayınlayabiliyor mu?
Bilgi. Dokümantasyonda ne var, neler hâlâ insanların kafasında yaşıyor?
İş riski. Belirli bir bileşen bir saat, bir gün ya da bir hafta çalışmazsa ne olur?
Yazılım tedarik zinciri güvenliğine yönelik modern yaklaşım, bileşenler, tedarikçiler, bağımlılıklar, bunların kökeni ve yaşam döngüsü hakkında bilgi sahibi olma ihtiyacını giderek daha fazla vurguluyor. NIST ayrıca teknoloji tedarikçilerine karşı gerekli özenin gösterilmesinin ve tüm tedarik zinciriyle ilişkili dayanıklılık ve riskin değerlendirilmesinin önemine dikkat çekiyor.
Denetim "sistemi baştan yazalım" demek değildir
Bu önemlidir, çünkü teknik denetim çoğu zaman yanlışlıkla yeniden inşa etmekle karıştırılır.
Oysa denetim çok basit bir sonuca da varabilir: "Sistem gayet iyi. Sadece bilgiyi düzenlemek ve birkaç riski ortadan kaldırmak gerekiyor."
Sistemin yalnızca bir alanda modernizasyona ihtiyacı olduğu da ortaya çıkabilir.
Ya da en büyük sorunun kod değil, altyapıya erişim eksikliği olduğu anlaşılabilir.
Ya da uygulamanın iyi yazılmış olduğu, ancak hiç kimsenin yayınlama süreci hakkında güncel bilgiye sahip olmadığı görülebilir.
Ya da her şeyin çalıştığı, fakat şirketin tek bir dış sağlayıcıya bağımlı olduğu anlaşılabilir.
Bu yüzden devralınmış bir projeye ilişkin iyi bir analiz şu soruya yanıt vermelidir: "Gerçekte neyi değiştirmek gerekiyor, neye dokunmamak gerekiyor?"
Ancak o zaman yatırım kararları alınabilir.
Peki ya software house değiştiriyorsanız?
Bu, görünmeyen bilgi borcu sorununu ortaya çıkaran anlardan biridir.
Şirket, yükleniciyle iş birliğini sonlandırır.
Yeni ortak depo yapısını alır.
Ve sorular sormaya başlar:
- "Üretim nerede?"
- "Projeyi yerel olarak nasıl çalıştırırım?"
- "Hangi sürüm güncel?"
- "Bu servis ne işe yarıyor?"
- "Bu API için hesaba kim sahip?"
- "Bu cron ne yapıyor?"
- "Bu süreç neden o saatte başlıyor?"
- "Bu parametreyi nereden alıyoruz?"
- "Bunu kapatırsak ne olur?"
Soruların çoğuna cevap "bilmiyoruz" ise, yeni software house projeyi devralmıyor. Önce onu keşfetmesi gerekir.
Ve sistemi keşfetmek zaman alır. Sonunda bu zamanı müşteri öder.
Bu yüzden projeyi ekipler arasında devretmek, bir ZIP dosyasını ve tek bir hesabın şifresini vermek değil, bir süreç olmalıdır.
Sistem insanlardan uzun yaşamalı
Bence en önemli ilke bu.
İnsanlar değişir. Yazılımcılar iş değiştirir. Freelancerlar iş birliğini sonlandırır. Software house'lar müşterilerini değiştirir. Yöneticiler başka şirketlere geçer. Yönetimler değişir.
Sistem kalır.
Bu yüzden sistem, onun bakımını sürdürmek için gereken bilginin geri kazanılabilir olduğu şekilde tasarlanmalıdır.
Bu, her çalışanın her şeyi bilmesi gerektiği anlamına gelmez.
Bu, organizasyonun bilgiyi saklama mekanizmasına sahip olması gerektiği anlamına gelir:
- Depolar.
- Dokümantasyon.
- Entegrasyon kaydı.
- Altyapı bilgileri.
- Şirket tarafından yönetilen erişimler.
- Temel süreçlerin açıklaması.
- Önemli kararların geçmişi.
- Bağımlılıklar hakkında bilgiler.
- Acil durum prosedürleri.
- Ve hepsinden önemlisi - bu dokümantasyonu kullanabilen insanlar.
NIST, sistem güvenliği planlamasına ilişkin güncel kılavuzlarında da sorumluluğun, sistemin operasyonel durumunun ve sistemi yöneten, destekleyen veya ona erişimi olan kişilerin rollerinin resmen tanımlanmasına dikkat çekiyor.
Bu, teknolojiye bakışta daha geniş bir değişimi gösteriyor.
Sistem sadece kod değildir. Sistem aynı zamanda insanlar, süreçler, altyapı, bağımlılıklar, veriler, erişim ve sorumluluktur.
Web24’te çoğu zaman tam da şu soruyla başlarız: "Burada aslında ne var?"
Mevcut bir projeyi devralmak, her şeyin baştan yazılacağı vaadiyle başlamamalıdır.
Durumu anlamakla başlamalı:
- Ne işe yarıyor?
- Ne işe yaramıyor?
- Kritik olan ne?
- Neler eski?
- En büyük riskler nerede?
- Dokümantasyonda ne eksik?
- Hangi bağımlılıklar görünmüyor?
- Mevcut sistemi güvenli bir şekilde geliştirmek mümkün mü?
- Modernizasyon mu gerekiyor, yoksa sadece düzenleme mi?
Ancak bundan sonra projenin geliştirilip geliştirilmeyeceğine, yeniden inşa edilip edilmeyeceğine, kısmen yeniden yazılıp yazılmayacağına ya da sadece iyi bir şekilde dokümante edilip edilmeyeceğine karar verilebilir.
Bu, yıllar boyunca farklı kişiler ve farklı şirketler tarafından geliştirilen projelerde özellikle önemlidir.
Çünkü iyi bir teknoloji ortağı, sadece sistemi nasıl çalıştığını bildiği için gerekli olmamalıdır.
Gerekli olmasının nedeni, bu sistemi geliştirebilmesi, güvence altına alabilmesi ve bilgiyi başkalarına aktarabilmesidir.
En tehlikeli hata, artık ortada olmayan bir kişi olabilir
Sorun her zaman eski kod değildir.
Sorun her zaman eski teknoloji değildir.
Sorun her zaman en yeni framework'ün eksikliği değildir.
Bazen en büyük risk, kimsenin yazmadığı bilgidir.
Tek bir ifade.
Tek bir mimari karar.
Tek bir entegrasyon.
Süreçteki tek bir istisna.
Yıllarca bunun nasıl çalıştığını bilen tek bir kişi.
Ve sonra ayrıldı.
Bu yüzden bugün kendinize çok basit bir soru sormakta fayda var: Yarın sisteminizi en iyi bilen kişi şirketten kaybolsa, hâlâ onu yönetebilir miydiniz?
Cevap "evet" ise - harika.
Cevap "bilmiyorum" ise - kontrol etmeye değer.
Ve cevap "kesinlikle hayır" ise - büyük olasılıkla şirketinizdeki en önemli teknolojik risk alanlarından birini yeni buldunuz demektir.
Sistem, tek bir kişinin hafızasından daha büyük olmalıdır.
