Sistemin çok iyi çalışıyor. Ta ki işin nedenini bilen kişi çalıştığı sürece.
Yedi yıldır çalışan bir sistemi olan bir şirket hayal edin. Aşamalar halinde gelişti. Önce bir yazılım şirketi yaptı. Sonra bir serbest çalışan bazı parçaları devraldı. Daha sonra başka bir ekip B2B modülünü ekledi. Başka bir ajans CRM bağladı. Birisi ödeme entegrasyonunu ekledi.
Sistem çalışıyor.
Şirket onun sayesinde para kazanıyor.
Çalışanlar her gün kullanıyor.
Müşteriler arka planda kaç sürecin işlediğini dahi bilmiyor.
Sadece bir problem var.
Artık kimse her şeyin neden böyle çalıştığını tam olarak bilmiyor.
Dokümantasyon kısmen Confluence’ta. Bir şeyler Google Drive’da kalmış. Bazı bilgiler ticket’larda. Bir entegrasyon dört yıl önce gönderilmiş bir emaile dayanıyor.
Ve en önemli bilgi "sanırım Lukasz hatırlıyor".
Ama Lukasz üç yıl önce ayrıldı.
Ve üç yıl boyunca hiçbir şey olmadı.
Ta ki bir salı sabahına kadar.
Sistem çalışıyor. Yani her şey yolunda mı?
Bu, kurumsal bir sistemin düşebileceği en aldatıcı durumlardan biridir.
Çalışıyor.
Kesinti yok.
Kullanıcılar memnun.
Satış uygulamayı kullanıyor.
Siparişler akıyor.
Veriler CRM’e gidiyor.
Raporlar üretiliyor.
Bu yüzden doğal tepki: Çalışanı bozmayalım. Neden çalışan bir şeye karışalım?
Ve elbette — sadece "olduğu gibi" çalışan bir sistemi değiştirmek için bir sebep yoktur.
Sorun şu ki sistem teknik olarak stabil olabilir ama organizasyonel olarak çok kırılgan olabilir.
Bugün çalışıyor olabilir ama sunucu, API sağlayıcısı, domain, kütüphane, kimlik doğrulama yöntemi veya iş sürecinin bir parçası değiştiğinde ne olacağı bilinmez.
Verimli olabilir ama tek bir kişiye bağımlı olabilir.
Güvenli olabilir ama tüm erişim anahtarlarının nerede olduğu bilinmeyebilir.
Geliştiriliyor olabilir ama sadece tüm kararların geçmişini bilen bir kişi tarafından.
İşte burada bus factor kavramı ortaya çıkıyor.
Proje sorun yaşamaya başlamadan önce kaç kişi kaybolabilir?
Bus factor çok basit ama acımasız bir konsepttir.
Soru şudur: Bir projenin verimli şekilde sürdürülebilmesi için kaç kişinin artık erişilebilir olmaması gerekir?
Cevap "bir" ise, problem var.
Cevap "iki ama ikisi farklı şirketlerde çalışıyor" ise, daha büyük bir problem var.
Elbette burada insanların tam anlamıyla "kaybolmasından" bahsetmiyoruz.
Geliştirici şirketten ayrılabilir.
Freelancer iş birliklerini sonlandırabilir.
Yazılım firması müşteriye hizmet vermeyi bırakabilir.
Yönetici işi değiştirebilir.
Bir entegrasyondan sorumlu kişi başka bir departmana geçebilir.
Bilginin sahibi bir şekilde hasta olabilir veya birkaç hafta erişilemez olabilir.
Eğer onunla birlikte sistemin anlaşılma kapasitesi de kayboluyorsa, şirketin insan kaynağı sorunu yoktur.
İş (business) sorunu vardır.
Kod her zaman bir şeyin neden yapıldığını söylemez
"Zaten kaynak kodumuz var. Yeni geliştirici okur ve anlar" denebilir.
Teorik olarak evet.
Pratikte kod öncelikle "sistemin bir şeyi nasıl yaptığı" sorusuna cevap verir.
Her zaman "neden bu şekilde yaptığı" sorusuna cevap vermez.
Ve bu çok büyük bir farktır.
Kodda şu şart olabilir: "Eğer müşterinin belirli bir hesap tipi varsa X işlemini yap."
Yeni geliştirici bunu bulabilir.
Ama nedenini nereden bilsin?
Belki bu bir iş gereği.
Belki eski bir entegrasyondan kalmadır.
Belki harici API hatasına karşı bir korumadır.
Belki beş yıl önce ortaya çıkan bir sorunun etrafından dolaşmaktır.
Belki en büyük müşterilerden birinin sıra dışı durumunu çözmek için vardır.
Çok iyi bir nedenle orada olabilir.
Ya da hiç neden olmadan.
Bağlam olmadan değerlendirmek zordur.
Bu yüzden sistem dokümantasyonu sadece "şuna tıkla, sonra şuna tıkla" talimatlarıyla sınırlı olmamalıdır.
En değerli dokümantasyon genellikle kararları ve bağımlılıkları açıklar, sadece fonksiyonların kullanımını değil.
En tehlikeli bilgi, yalnızca birinin zihninde olan bilgidir
Şirketler genellikle dokümantasyona sahiptir. Ama dokümantasyon her zaman bilgi demek değildir.
API açıklamasına sahip olabiliriz — ama neden o API’yi kullandığımızı bilmiyor olabiliriz.
Dağıtım kılavuzumuz olabilir — ama yapılandırmayı nerelerde değiştirmemiz gerektiğinin tam listesi olmayabilir.
Entegrasyon tanımı olabilir — ama harici sağlayıcı yetkilendirmeyi değiştirirse ne olacağını bilmiyor olabiliriz.
Sunucu listesimiz olabilir — ama hangisinin belirli bir süreç için kritik olduğunu bilmiyor olabiliriz.
Repo erişimimiz olabilir — ama üretim altyapısının bulunduğu hesaba erişimimiz olmayabilir.
İşte bu öğeler, görünüşte basit bir değişikliği birkaç günlük soruşturmaya çevirebilir.
Beş yıldır çalışan bir entegrasyon hâlâ bir bağımlılıktır
En sık göz ardı edilen alanlardan biri dış hizmetlerdir;
- Ödemeler.
- SMS.
- E-posta.
- CRM.
- ERP.
- Haritalar.
- Kurye sistemleri.
- Pazarlama platformları.
- Muhasebe sistemleri.
- Bulut hizmetleri.
- Dış API’ler.
- Açık kaynak kütüphaneler.
Her biri daha büyük bir ekosistemin parçasıdır.
Eğer sistem on dış hizmet kullanıyorsa, tek bir sistemimiz yoktur. Sisteme ek olarak on bağımlılığımız var. Ve bunların her biri değişebilir.
Sağlayıcı API’yi değiştirebilir.
Hizmeti sonlandırabilir.
Fiyat modelini değiştirebilir.
Eski sürümü geri çekebilir.
Yeni güvenlik gereksinimleri getirebilir.
Başka bir şirket tarafından satın alınabilir.
Bu yüzden bileşenlerin kökeni ve yazılım bağımlılıkları hakkında bilgi giderek daha önemli hale geliyor. NIST, yazılım bileşen listesinin (SBOM - Software Bill of Materials) önemine dikkat çekiyor — bir yazılımın inşasında kullanılan bileşenlerin resmi bir dökümü. Böyle bir liste, sistemin neyden oluştuğunu anlamaya ve tedarik zincirindeki değişimlerin veya açıkların etkisini daha hızlı değerlendirmeye yardımcı olur.
İş açısından bunu çok basit bir soruya indirgeyebiliriz:
Sisteminizin hangi şeylere bağımlı olduğunu biliyor musunuz?
Ve şimdi bir yazılım firmasının değiştiğini hayal edin
Bu, tüm eksikliklerin gün yüzüne çıktığı anlardandır.
Şirket yıllarca tek bir tedarikçiyle çalıştı. Aniden iş birliği bitiyor. Sebepleri çok olabilir; strateji değişikliği. Bütçe değişikliği. Ajansın devri. Organizasyonel sorunlar. Devam edecek yetkinliklerin olmaması. Ya da şirket başka bir ortakla çalışmak istemesi.
Yeni yazılım firması sorar:
"Repo nerede?" - Var.
"Altyapı nerede?" - Var.
"Canlıya nasıl alıyoruz?" - "Bilmiyoruz, önceki ekip yapıyordu."
"ERP entegrasyonu nasıl çalışıyor?" - "Sanırım şu sunucu üzerinden."
"API anahtarlarımız nerede?" - "Emaillerde olmalı."
"Hangi API’ler üretimde kullanılıyor?" - "Bilmiyoruz."
"Hangi süreçler kritik?" - "Lukasz’a sormak lazım."
Lukasz artık orada çalışmıyor...
Ve bu yüzden proje devri sadece kodun taşınması değildir. Bilginin de taşınması gerekir.
Dokümantasyon maliyet değil. Bir sigortadır
Çok sayıda şirkette dokümantasyon "zamanı olunca" yapılan bir iş olarak görülür.
Yani genellikle hiç yapılmaz.
Ya da projenin sonunda yapılır.
Ya da birisi sorduğunda yapılır.
Bu bir hatadır.
Dokümantasyon operasyonel riski azaltan bir mekanizmadır. Doğrudan satış üretmez. Dönüşümü (conversion) artırmaz. Sunumda etkileyici görünmez.
Ama kriz anında fark yaratabilir: "bugün tamir ederiz" ile "önce sistemi hatırlayan birini bulmalıyız" arasındaki farkı.
NIST’in güvenlik, gizlilik ve yazılım tedarik zinciri risk yönetimine dair yeni yönergelerinde, sistemin amacı, durumu, kontrolleri, sorumlulukları ve sistemi yöneten kişilerin davranışlarının dokümante edilmesi düzenli sistem yönetiminin bir parçası olarak ele alınıyor.
Bu düşünce değişimini güzel gösterir.
Dokümantasyon yalnızca geliştirici için bir araç değildir.
Organizasyonun sürekliliğinin bir parçasıdır.
Ne dokümante edilmeli?
Amacımız kimsenin açmayacağı 800 sayfalık bir doküman oluşturmak değil.
İyi dokümantasyon, özellikle bir şey değiştiğinde veya çalışmaz hale geldiğinde ortaya çıkacak sorulara cevap vermelidir.
- Sistemin sahibi kim?
- Kod nerede?
- Prod ortamı nerede?
- Dağıtım süreci nasıl işler?
- Hangi ortamlar var?
- Hangi entegrasyonlar kritik?
- Hangi dış hizmetleri kullanıyoruz?
- Onların sağlayıcıları kim?
- Hangi sözleşmeler ve hesaplar var?
- Anahtarlar ve erişim verileri nerede?
- Kimlerin yetkisi var?
- Yedekleme nasıl yapılıyor?
- Sistemi geri getirme süreci nasıl?
- Hangi açık kaynak bileşenleri kullanılıyor?
- Hangi kütüphaneler artık eskimiş?
- En önemli mimari kararlar neler?
- Hangi öğeler iş için kritik?
- Belirli bir dış hizmet çalışmayı durdurursa ne olur?
Bu dokümantasyon "sadece geliştiriciler için" değildir.
Bu, teknolojinin işe olan bağımlılığının haritasıdır.
"Çalışıyor, öyleyse karışmayalım" bir strateji olabilir. Ama bedelini bilmek gerekir
Her şirket eski sistemi baştan tasarlamaya ihtiyaç duymaz.
Her legacy sistem kötü değildir.
Her eski kod yeniden yazılmak zorunda değildir.
Tam tersine — bazen stabil, daha eski bir sistem gereksiz maliyetli bir migrasyondan daha iyidir.
Sorun sistemin yaşı değildir.
Sorun durumu hakkında bilgi eksikliğidir.
Sistemin nasıl çalıştığını, hangi bağımlılıkları olduğunu, risklerin nerede olduğunu ve kimlerin sürdürebileceğini biliyorsak bilinçli bir şekilde karar verebiliriz:
- bırakmak,
- modernize etmek,
- bir kısmını yeniden yazmak,
- göç etmek,
- ya da hiçbir şeye dokunmamak.
Bunu bilmiyorsak "dokunmamak" bir strateji değildir.
Bir bahis oyunudur.
Miras alınmış bir sistemin denetimi nasıl görünür?
Yeni bir yazılım ekibinin eline geçen mevcut bir sistemde ilk adım "hemen yeniden yazalım" olmamalıdır — önce anlamak gerekir.
İyi bir denetim uygulama mimarisi, kaynak kodu, veri tabanı, altyapı, dağıtım süreci, bağımlılıklar, entegrasyonlar, güvenlik, hizmet erişimleri ve dokümantasyonu gibi alanları kapsamalıdır.
Ama işin anlaşılması da bir o kadar önemlidir;
- Hangi süreçler kritik?
- Hangi özellikler günlük olarak kullanılıyor?
- Hangi modüller gelirden sorumlu?
- Hangi parçalar kapatılabilir, sonuçları ne olur?
- Belirli bir entegrasyon durursa ne olur?
- Hangi parçalar en riskli?
Teknik ve iş perspektifleri birleştirildikten sonra ancak gerçekte neyin değişmesi gerektiği söylenebilir.
Denetim devrimle sonuçlanmak zorunda değil
Bazen denetimin sonucu şaşırtıcı derecede basittir.
Sistem iyi durumdadır, sadece yapılması gerekenler:
- Dokümantasyonu tamamlamak.
- Erişimleri düzenlemek.
- Birkaç kütüphaneyi güncellemek.
- Hesapların sahipliğini devretmek.
- Dağıtım sürecini belgelemek.
- Monitoring eklemek.
- Yedeklemeyi düzenlemek.
- Sadece bir geliştiricinin bildiği alanlara ikinci bir kişiyi dahil etmek.
Ve aniden bus factor 1’den 3’e çıkar.
Tüm uygulamayı yeniden yazmaya gerek yok.
Yedi yılın emeğini çöpe atmaya gerek yok.
Her şeyi baştan inşa etmeye gerek yok.
Bazen en büyük problem teknoloji değildir.
Haritanın eksik olmasıdır.
Sistem, onu yaratan insanlardan daha uzun yaşamalı
Sanırım en önemli kural budur: iyi bir sistem geliştiricinin ayrılmasını kaldırabilmelidir.
Yönetici değişimini kaldırabilmelidir.
Yazılım firmasının değişimini kaldırabilmelidir.
Şirket reorganizasyonunu kaldırabilmelidir.
Birkaç yıl gelişimi kaldırabilmelidir.
Bu, her geliştiricinin her satırı anlaması gerektiği anlamına gelmez. Ama işin sürekliliği için kritik bilgi sadece bir kişinin kafasında olamaz.
Çünkü çalışan ayrılabilir.
Freelancer işi bırakabilir.
Ajans ortadan kaybolabilir.
Sağlayıcı hizmetini değiştirebilir.
Ve şirket yine çalışmak zorunda.
Teknoloji organizasyonun mülkiyeti olmalı, tek bir kişinin hafızası değil
Bu, özellikle yıllarca inşa edilen sistemler için önemlidir.
Eğer şirket yazılım için ödeme yapıyorsa, sadece kodun nerede olduğunu bilmek yetmez.
Ayrıca bilmelidir:
- neye sahip olduğu,
- neyden bağımlı olduğu,
- kimin erişimi olduğu,
- kimin değiştirebileceği,
- nasıl dağıtılacağı,
- nasıl geri getirileceği,
- nasıl başka bir ekibe devredileceği.
NIST’in tedarikçi due diligence konusunda güncel materyalleri, köken, dayanıklılık, siber güvenlik uygulamaları ve tedarik zinciri bağımlılıklarına dikkat çekiyor. Bu daha geniş bir yönü gösteriyor: organizasyonlar artık sadece sistemi kimin sağladığını değil, sistemin neyden oluştuğunu ve bakımının hangi riskleri taşıdığını da bilmelidir.
Bu artık sadece BT bölümü için bir konu değil.
Bu bir iş riski yönetimi konusudur.
Sisteminizi tanımanın en kötü zamanı bir arıza anıdır
Bir denetime birkaç gün ayırabilirsiniz.
Dokümantasyonu düzenleyebilirsiniz.
Bağımlılıkları kontrol edebilirsiniz.
Mimarinin tanımını yapabilirsiniz.
Erişimleri doğrulayabilirsiniz.
Gerçekten kimlerin hangi alanlardan sorumlu olduğunu belirleyebilirsiniz.
Bus factor’ı azaltabilirsiniz.
Ya da bekleyebilirsiniz.
Sistem çalışmayı bıraktığında kadar.
O zaman sorular aynı olacaktır.
Sadece baskı daha yüksek olacak, kullanıcılar bekleyecek, satış durabilir ve her bir saat para kaybettirecektir.
Bu yüzden bir sorun çıkmadan önce kendinize şu soruyu sormaya değer: Yarın sisteminizi en iyi bilen kişi yok olsaydı, sistemi yine nasıl sürdürebileceğimizi bilirmiydik?
Cevap "hayır" ise, bu sistemin kötü olduğu anlamına gelmez.
Bu, şirketin şimdiye kadar tetiklemediği gizli bir riske sahip olduğu anlamına gelir.
Web24 olarak sadece kodu devralmıyoruz
Mevcut bir projeyi devralmak, sıfırdan yeni bir sistem başlatmaktan tamamen farklı bir iştir.
Önce var olanı anlamak gerekir.
Ne çalışıyor.
Ne kritik.
Ne bağımlılık.
Ne problem.
Ne sadece önceki kararların bir kalıntısı.
Ve her şeyden önce — sistemin güvenli bir şekilde geliştirilebilmesi için hangi bilginin nerede olduğu.
İşte o zaman sonraki adımlar planlanabilir.
Bazen bu modernizasyon olur.
Bazen geliştirme olur.
Bazen altyapının düzenlenmesi olur.
Bazen bakım devri olur.
Bazen de sadece yıllarca kimsenin zamanı olmadığı için hazırlanamayan düzgün bir sistem haritası oluşturmak gerekir.
Çünkü sorumlu bir yazılım firması, sadece doğru kişi bilgisayarın başında olduğunda çalışan teknoloji inşa etmemelidir.
Sistem, tek bir kişinin belleğinden daha büyük olmalıdır.
Ve iş, birisi ayrıldığında teknolojinin de onunla gitmeyeceğinden emin olmalıdır.
