Dosya Transfer meselesi

Kullanıcıların iki ayrı bilgisayarı var. Bu bilgisayarların farklı ağlarda çalıştığını varsayıyoruz: biri kapalı proje ağı, diğeri internet ağı. İş sürekliliği adına bir süre boyunca firmada harici bellekler elden ele dolaştı. Ancak savunma sanayi sektöründe faaliyet gösteren bir kurum için bunun ne kadar problemli ve riskli göründüğünü tahmin etmek zor değil.

80’den fazla kullanıcının bulunduğu bir ofiste, kapalı ağdan internet ağına ve internet ağından kapalı ağa günlük ortalama 20–30 veri transferi gerçekleşiyor. Bir gün, elde olmayan nedenlerle aslında yapılması gereken şey yapıldı: ofis içerisindeki tüm harici bellekler ve diskler toplandı.

“Neden?” ve “Nasıl?” sorularını bir kenara bırakırsak, asıl soru şuydu: Bu ihtiyaç bundan sonra nasıl karşılanacaktı?

Herhangi bir planlama yapılmadan alınan bu kararın ardından Bilgi Teknolojileri biriminden bir personel bu işe “dedike” edildi. Sonuç, genç bir BT çalışanı için ciddi bir hayal kırıklığıydı.

Haftalar boyunca USB bellekle masa masa dolaşıp veri taşıdıktan sonra şu gerçek daha net görünmeye başladı: Bu yöntem sürdürülebilir değildi. Ortada bir loglama mekanizması yoktu. Aktarılan verinin içeriği, önemi, bağlamı bilinmiyordu. Bir AR-GE firmasında çalışan BT personelinin yalnızca fiziksel taşıyıcı rolünde olması hem operasyonel hem de güvenlik açısından rahatsız ediciydi.

Bir süre sonra süreci daha kontrollü hale getirmek için dosya transferlerini ManageEngine Helpdesk sistemi ile entegre ettik. Kullanıcılar artık veri transferi için talep açmaya başladı. Yine bir BT personeli bu işe “dedike” edildi; internet bilgisayarından veriyi alıyor, kapalı ağ bilgisayarına geçiriyor ve ilgili kullanıcıya teslim ediyordu.

En azından artık şu soruların cevabı vardı:

  • Hangi kullanıcı?
  • Hangi veriyi?
  • Nereye?
  • Hangi gerekçeyle taşıdı?

Bu kayıt altına alınabiliyordu. Bu, önemli bir adımdı.

Ancak sorunlar bitmedi. Mesai saatleri dışında ortaya çıkan transfer ihtiyaçları, BT ekibine olan bağımlılığı daha da artırdı. Süreç kontrol altındaydı ama hâlâ insan bağımlıydı.

2025 Şubat ayında yayımlanan GPT-4.5 ile birlikte farklı bir yaklaşım denemeye karar verdik. Amaç, kullanıcıların bu süreci BT’den bağımsız şekilde yürütebilmesini sağlamaktı. İlk adımı attık.

Ortaya çıkan uygulama estetik kaygılar taşımıyordu. Tam anlamıyla “ihtiyacı karşılasın yeter” mantığıyla geliştirilmişti. Ancak aradan bir yıl geçmesine rağmen hâlâ sorunsuz çalışıyor. Stabil, güvenilir ve işlevsel.

Şimdi ise aynı ihtiyacı kurumsal portal içerisinde yeniden ele alıyorum. Bu kez:

  • Daha sistematik bir mimari,
  • Daha ayrıntılı loglama,
  • Daha anlamlı raporlama,
  • Ve estetik kaygılar gözetilmiş bir arayüz ile.

Ve belki de en önemlisi, bir BT personelinin yalnızca veri taşıyan biri olmaktan çıkıp, problem çözen ve sistem kuran biri olarak kalabilmesine alan açtı.

Arka plandaki e-posta bilgilendirmeleri ve BT’ye sunulan aksiyon raporları, şu an geliştirdiğim versiyon kadar detaylı olmasa da, o dönem için yeterliydi. Süreci kontrol altına aldı. Riski azalttı. Bağımlılığı kısmen düşürdü.

Yorum bırakın