Tek bir yapay zeka modeli kullanarak yazılım geliştirmek hızlıdır ancak risklidir. Bir AI modeli hata yaptığında çoğu zaman kendi hatasını fark edemez. Bu durum özellikle mimari kararlar, güvenlik açıkları veya yanlış yorumlanmış iş gereksinimleri söz konusu olduğunda ciddi problemlere yol açabilir.

Bu nedenle güvenli AI destekli geliştirme için giderek daha fazla kullanılan yaklaşım AI‑Against‑AI Development modelidir. Bu modelde farklı AI agentlar farklı rolleri üstlenir ve birbirlerinin çıktısını denetler.

Örneğin bir model gereksinimleri ayrıştırırken, başka bir model teknik tasarımı üretir ve üçüncü bir model bu tasarımın doğruluğunu kontrol eder. Böylece üretim süreci tek bir modele bağlı kalmaz.

Bu yaklaşımın üç temel avantajı vardır:

• AI hatalarının ikinci bir model tarafından yakalanması
• Mimari ve kapsam tutarlılığının korunması
• Kalite ve güvenlik risklerinin azaltılması

Başka bir ifadeyle AI‑Against‑AI yaklaşımı yazılım üretimini "tek bir AI tarafından yazılan kod" seviyesinden çıkarıp kontrollü bir üretim hattına dönüştürür.

Bu makalede açıklanan AI Yazılım Fabrikası modeli tam olarak bu prensip üzerine kuruludur.

Giriş

Yapay zeka destekli yazılım geliştirme araçları son birkaç yıl içinde dramatik bir hız kazandı. Modern AI modelleri yalnızca kod yazmakla kalmıyor; gereksinim analizi, mimari tasarım, hata ayıklama, test üretimi ve dağıtım süreçlerinde de aktif rol alabiliyor.

Bu durum yazılım geliştirme süreçlerinde büyük bir verimlilik artışı sağlarken, aynı zamanda yeni riskler de doğuruyor. Tek bir AI modeline güvenerek yazılım üretmek; yanlış mimari kararlar, gizli hatalar veya domain yanlış anlamaları gibi ciddi problemlere yol açabiliyor.

Bu nedenle güvenli AI destekli yazılım geliştirme için çoklu AI rol mimarisi (Multi‑Agent Development Model) giderek daha önemli hale geliyor.

Bu makalede, AI araçlarını birbirini denetleyecek şekilde kullanarak güvenli ve tutarlı yazılım geliştirmeyi sağlayan bir AI Yazılım Fabrikası modeli iki aşamalı olarak açıklanıyor.

Aşama 1 — Küçük ve Orta Ölçekli Projeler İçin Minimal AI Modeli

Birçok ekip AI destekli geliştirmeye başlarken doğrudan çok sayıda agent kullanan karmaşık modellere geçmeye çalışır. Ancak pratikte çoğu proje için bu gerekli değildir.

Başlangıç için en güvenli ve sürdürülebilir yaklaşım iki AI modelinin rol ayrımıyla çalıştırılmasıdır.

Temel Rol Dağılımı

AI1 → Product Governor
AI2 → Engineering Executor

AI1 — Product Governor

Bu rolün sorumlulukları:

• Gereksinimlerin ayrıştırılması
• Kapsam tanımı
• User story üretimi
• Acceptance criteria oluşturma
• Sistem genelinde tutarlılık kontrolü

AI1 bu aşamada bir Product Owner ve Sistem Denetçisi gibi davranır.

AI2 — Engineering Executor

Bu rolün sorumlulukları:

• Teknik tasarım oluşturma
• Kod üretimi
• Test yazımı
• Refactoring
• Deployment hazırlıkları

AI2 bu aşamada bir Mühendis ve DevOps uygulayıcısı rolündedir.

Kritik Nokta: İki Zorunlu Kontrol Kapısı

İki AI modeliyle güvenli geliştirme yapabilmek için süreçte iki kritik kapı bulunmalıdır.

Design Gate

AI2 doğrudan koda başlamamalıdır.

Önce aşağıdaki çıktıları üretmelidir:

• Etkilenen modüller
• Veri modeli değişiklikleri
• API kontratları
• Servis etkileşimleri
• Güvenlik etkileri

Bu aşama mini bir Technical Design Document üretmeyi amaçlar. Bu sayede AI tasarımsız kod üretmez.

Consistency Gate

Technical design üretildikten sonra tasarım tekrar AI1 tarafından değerlendirilmelidir.

Kontrol edilen noktalar:

• Gereksinimlerle uyum
• Gereksiz mimari karmaşıklık
• Kapsam genişlemesi (scope creep)
• Önceki sistem kararlarıyla uyum

Bu aşama AI'nın sık yaptığı overengineering hatasını büyük ölçüde azaltır.

Minimal AI Yazılım Fabrikası Akışı

Human
  ↓
AI1 (Scope & Requirements)
  ↓
AI2 (Technical Design)
  ↓
AI1 (Consistency Review)
  ↓
AI2 (Implementation)
  ↓
AI1 (Quality Review)
  ↓
Human Approval

Bu model küçük ve orta ölçekli projeler için oldukça güçlüdür.

Doğru kullanıldığında iki AI modeli bile bir yazılım fabrikası disiplini oluşturabilir.

Aşama 2 — Büyük veya Kritik Projeler İçin Çoklu AI Modeli

Sistem büyüdükçe veya proje kritik hale geldikçe daha fazla rol ayrımı yapmak gerekir.

Bu noktada 4 AI agent modeli daha güvenli hale gelir.

Çoklu Agent Mimarisi

Human Orchestrator
      ↓
Product AI
      ↓
Architecture AI
      ↓
Developer AI
      ↓
QA / Review AI

Bu model yazılım geliştirme süreçlerinin klasik SDLC rollerini AI ortamına taşır.

Product AI

Sorumluluklar:

• Gereksinim ayrıştırma
• Backlog üretimi
• Acceptance criteria
• Kapsam kontrolü

Bu rol sistemin iş doğruluğunu korur.

Architecture AI

Sorumluluklar:

• Sistem mimarisi
• Servis sınırları
• Veri modeli
• API kontratları
• Güvenlik etkileri

Bu rol sistemin teknik doğruluğunu sağlar.

Developer AI

Sorumluluklar:

• Kod üretimi
• Refactoring
• Test yazımı
• Migration hazırlığı

Bu rol implementasyon katmanını oluşturur.

QA / Review AI

Sorumluluklar:

• Acceptance criteria doğrulaması
• Edge case analizi
• Güvenlik kontrolleri
• Tutarlılık kontrolü

Bu rol sistemin kalite kapısıdır.

Büyük Projelerde Örnek Akış

Human
 ↓
Product AI
 ↓
Architecture AI
 ↓
Developer AI
 ↓
QA AI
 ↓
Developer AI (fixes)
 ↓
Release

Bu yapı özellikle şu durumlarda önemlidir:

• Kurumsal sistemler
• Çok modüllü uygulamalar
• Kritik veri sistemleri
• Yüksek güvenlik gereksinimi olan platformlar

Kullanılabilecek AI Platformları

Bu model belirli bir platforma bağlı değildir. Farklı AI araçları bu rolleri üstlenebilir.

Örnek olarak kullanılabilecek bazı platformlar:

AI Coding Agents

• Cursor
• GitHub Copilot
• Claude Code
• OpenAI Codex
• Windsurf
• Amazon Q Developer
• Aider
• Continue.dev
• Sourcegraph Cody
• Tabnine

AI geliştirme araçları genellikle iki kategoriye ayrılır:

IDE tabanlı araçlar

• Cursor
• Windsurf
• GitHub Copilot
• JetBrains AI

Terminal / Agent tabanlı araçlar

• Claude Code
• Codex CLI
• Aider
• Cline

Birçok geliştirici bu araçları tek başına kullanmak yerine birlikte kullanmayı tercih etmektedir.

Bu makalede kullanılan AI1 / AI2 rol modeli, herhangi bir AI platform kombinasyonu ile uygulanabilir.

İnsan Rolü: Domain Authority

AI destekli geliştirme modellerinde insan rolü ortadan kalkmaz.

İnsan geliştirici şu kritik soruların cevabından sorumludur:

1. Gerçek problem doğru tanımlandı mı?
2. Çözüm kurumun iş süreçleriyle uyumlu mu?
3. Operasyonel riskler var mı?

AI modelleri teknik çözümler üretmede çok başarılıdır; ancak gerçek dünya operasyonlarını ve kurum kültürünü her zaman doğru anlayamaz.

Bu nedenle insan geliştirici sistemde domain authority rolünü korur.

AI ile Güvenli Yazılım Geliştirme İçin 10 Kural

AI destekli geliştirme yüksek hız sağlar, ancak kontrol mekanizmaları kurulmazsa ciddi kalite ve güvenlik riskleri doğurabilir.

Aşağıdaki prensipler güvenli AI geliştirme için temel kurallardır.

1. AI doğrudan koda başlamamalıdır

Her geliştirme süreci önce tasarım aşamasından geçmelidir.

2. Gereksinim ve implementasyon farklı AI rolleri tarafından yapılmalıdır

Scope ve implementasyon aynı modelde yapılırsa hatalar büyüyebilir.

3. Tasarım mutlaka ikinci bir AI tarafından kontrol edilmelidir

Consistency Gate bu nedenle kritik bir adımdır.

4. Acceptance criteria olmadan kod yazılmamalıdır

AI üretimi her zaman doğrulanabilir kriterlere dayanmalıdır.

5. AI tarafından üretilen kod her zaman review sürecinden geçmelidir

Kod üretimi ve kalite kontrolü ayrı aşamalar olmalıdır.

6. Overengineering aktif olarak kontrol edilmelidir

AI modelleri gereğinden karmaşık mimariler üretmeye eğilimlidir.

7. Domain doğruluğu insan tarafından kontrol edilmelidir

AI teknik doğruluğu sağlayabilir ancak iş doğruluğunu garanti edemez.

8. Deployment ve rollback planı zorunlu olmalıdır

AI tarafından geliştirilen sistemler için geri dönüş planı her zaman hazır olmalıdır.

9. Test üretimi AI sürecinin parçası olmalıdır

Unit test ve edge case testleri otomatik olarak üretilmelidir.

10. AI tek başına otorite değildir

AI bir üretim aracıdır; nihai karar mekanizması her zaman insan olmalıdır.

Kurumsal SDLC Zorunluluklarının Entegrasyonu

AI destekli geliştirme süreçleri kurumların mevcut yazılım yaşam döngüsü (SDLC) kurallarının yerine geçmez. Aksine, AI üretim hattının kurumun üzerinde mutabık kalınmış SDLC kurallarıyla uyumlu çalışması gerekir.

Birçok kurumda bu kurallar ayrı bir dokümanda tanımlıdır (örneğin SDLC.md gibi kapsamlı bir süreç dokümanı).

AI geliştirme süreci bu dokümanda tanımlanan zorunlulukları otomatik olarak uygulayacak şekilde tasarlanmalıdır.

AI yazılım fabrikası modeline entegre edilmesi gereken tipik SDLC zorunlulukları şunlardır:

1. Gereksinim İzlenebilirliği

Her geliştirme aşağıdaki zinciri kurmalıdır:

Requirement → User Story → Acceptance Criteria → Implementation → Test

AI sistemleri bu zinciri üretmeli ve korumalıdır.

2. Mimari Uyum Kontrolü

Yeni geliştirilen kod mevcut sistem mimarisi ile uyumlu olmalıdır.

AI tarafından üretilen tasarım aşağıdaki sorulara cevap vermelidir:

• Mevcut servis sınırları korunuyor mu
• Veri modeli bozuluyor mu
• Entegrasyon sözleşmeleri değişiyor mu

Bu kontrol genellikle Architecture Gate içinde yapılır.

3. Kod Standartları

AI tarafından üretilen kod kurumun belirlediği standartlara uymalıdır.

Örneğin:

• Naming convention
• Logging standartları
• Error handling modeli
• Güvenlik kuralları

Bu kontroller genellikle Review AI tarafından yapılabilir.

4. Test Zorunlulukları

Kurumsal SDLC süreçlerinde genellikle aşağıdaki testler zorunludur:

• Unit test
• Integration test
• Edge case testleri

AI üretim hattı bu testleri otomatik olarak üretmelidir.

5. Güvenlik Kontrolleri

AI tarafından üretilen kod aşağıdaki risklere karşı kontrol edilmelidir:

• Veri sızıntısı
• Yetki kontrol hataları
• Injection saldırıları
• Gizli anahtarların kod içine yazılması

Bu kontroller Security Review aşamasının parçası olmalıdır.

6. Değişiklik İzleme

Her AI üretimi aşağıdaki artefaktları üretmelidir:

• Değişen dosyalar listesi
• Migration planı
• Geri dönüş planı

Bu sayede sistemde yapılan değişiklikler izlenebilir hale gelir.

7. Deployment ve Rollback Planı

Kurumsal sistemlerde her değişiklik için şu bilgiler zorunludur:

• Deployment sırası
• Environment değişiklikleri
• Rollback prosedürü

AI tarafından üretilen her değişiklik bu bilgileri içermelidir.

8. Audit Trail

AI üretim hattında alınan kararlar kaydedilmelidir.

Örneğin:

• Hangi gereksinim için geliştirme yapıldı
• Hangi tasarım onaylandı
• Hangi kod değişiklikleri üretildi

Bu kayıtlar özellikle kurumsal sistemlerde kritik öneme sahiptir.

AI destekli geliştirme süreçleri başarılı olabilmek için yalnızca hızlı değil, aynı zamanda kurumsal SDLC disiplinleriyle uyumlu olmalıdır.

Bu nedenle AI yazılım fabrikası modeli her zaman kurumun mevcut SDLC süreçlerini referans almalıdır.

AI Kurallarının Proje İçinde Kullanılması

Yukarıda açıklanan kuralların yalnızca dokümantasyon olarak kalması yeterli değildir. Bu prensipler doğrudan proje içinde kullanılan AI agentlara operasyonel kurallar olarak verilmelidir.

Pratikte bu yaklaşım genellikle proje içinde bir veya daha fazla referans dokümanı kullanılarak uygulanır. Örneğin:

• SDLC.md
• AI_RULES.md
• ARCHITECTURE.md

AI agentlar geliştirme sürecine başlamadan önce bu dokümanları okur ve kararlarını bu kurallara göre üretir.

Tipik bir proje dizini örneği:

/project
   /docs
      SDLC.md
      AI_RULES.md
      ARCHITECTURE.md
   /src
   /tests

AI agentlara verilen talimat genellikle şu şekilde olur:

• Bu projede geliştirilen tüm kodlar SDLC.md kurallarına uymalıdır.
• Mimari kararlar ARCHITECTURE.md ile uyumlu olmalıdır.
• Geliştirme süreci AI_RULES.md içindeki AI geliştirme prensiplerine göre yürütülmelidir.

Bu yaklaşımın iki önemli faydası vardır:

1. AI üretimi kurumsal standartlardan sapmaz
2. Farklı AI araçları kullanılsa bile davranış tutarlılığı korunur

Başka bir ifadeyle, AI agentlar yalnızca promptlarla değil, proje içinde bulunan yaşayan dokümantasyon ile yönlendirilmelidir.

Kurumsal ortamlarda bu yaklaşım AI üretimini rastgele bir aktivite olmaktan çıkarır ve onu kontrollü bir yazılım üretim sistemi haline getirir.

Sonuç

AI destekli yazılım geliştirme büyük bir hız artışı sağlamaktadır. Ancak bu hız kalite ve güvenlik risklerini de beraberinde getirir.

Güvenli geliştirme için en etkili yaklaşım:

• AI modellerini farklı roller için kullanmak
• Modelleri birbirini denetleyecek şekilde çalıştırmak
• Geliştirme sürecine kontrol kapıları eklemek

Küçük projelerde iki AI modeli ve iki kalite kapısı yeterli olabilir.

Büyük ve kritik sistemlerde ise çoklu AI agent mimarisi daha güvenli bir geliştirme ortamı sağlar.

Gelecekte yazılım geliştirme yalnızca kod yazma süreci olmayacak; iyi tasarlanmış bir AI destekli üretim sistemi haline dönüşecektir.

Kurumların Kendi Yazılım Platformlarını Kurabilmesi İçin Teknik Kılavuz

Giriş

Uzun yıllar boyunca kurumsal yazılım dünyası oldukça öngörülebilir bir model üzerine kuruluydu. Bir kurum ihtiyaç duyduğu sistemleri farklı üreticilerden satın alırdı. Örneğin;

• ERP bir yerden
• PDKS başka bir yerden
• Doküman yönetimi başka bir yerden
• IoT platformu başka bir yerden
• Varlık yönetimi başka bir yerden

Zaman içinde kurumların dijital yapısı onlarca farklı sistemden oluşan bir ekosisteme dönüştü. Bu sistemler çoğu zaman birbirinden bağımsız çalışıyor, entegrasyonlar sonradan ekleniyor ve her güncelleme yeni bir risk oluşturuyordu.

AI destekli yazılım geliştirme araçlarının ortaya çıkması bu dengeyi değiştirmeye başladı. Bugün kurumlar için yeni bir soru ortaya çıkıyor:

Kurumlar artık kendi dijital servislerini geliştirebilir mi?

Cevap çoğu durumda evet. Ancak bu yalnızca "AI ile kod yazmak" anlamına gelmez. Kurumların sürdürülebilir bir geliştirme kapasitesi oluşturabilmesi için belirli bir platform mimarisi, SDLC disiplini ve operasyon modeli kurması gerekir.

Bu makale bu yapının nasıl kurulabileceğine dair teknik bir rehber sunmayı amaçlar.

1. Platform Yaklaşımı

Kurum içi yazılım geliştirme "tek tek uygulama geliştirmek" olarak düşünülmemelidir.

Doğru yaklaşım bir Kurumsal Dijital Platform kurmaktır. Bu platform üzerinde farklı dijital servisler geliştirilebilir:

• GRC sistemleri
• İş süreçleri platformları
• Varlık yönetimi
• IoT uygulamaları
• Sürdürülebilirlik sistemleri
• Operasyonel uygulamalar

Platform yaklaşımı şu avantajları sağlar:

• Ortak kimlik yönetimi
• Standart entegrasyon modeli
• Tekrar kullanılabilir servisler
• Merkezi gözlemlenebilirlik
• Sürdürülebilir mimari

Kurumsal Identity Platform Tasarımı

Kurumsal dijital platformların en kritik bileşenlerinden biri identity platformudur. Çoğu kurumda kullanıcı bilgileri farklı sistemlerde ve farklı kimlik kaynaklarında dağınık halde bulunur.

Örneğin:

• Birden fazla Active Directory domain
• HR sistemleri
• Öğrenci veya eğitim sistemleri
• Uygulamaya özel kullanıcı kayıtları
• Merkezi kimliği olmayan çalışanlar (örneğin mavi yaka)

Bu nedenle kurumsal platformun identity sistemi yalnızca bir authentication servisi olmamalıdır. Aynı zamanda kurumun dijital kimlik grafiğini tutan bir servis olmalıdır.

Identity Platformunun Temel Sorumlulukları

Bir kurumsal identity platformu aşağıdaki sorumlulukları üstlenmelidir:

• Authentication (kimlik doğrulama)
• Authorization (yetkilendirme)
• Kullanıcı yaşam döngüsü yönetimi
• Rol ve yetki yönetimi
• Delegasyon (vekalet)
• Audit ve erişim kayıtları

Çoklu Kimlik Kaynakları

Kurumsal platformlar genellikle birden fazla kimlik kaynağı ile çalışmak zorundadır. Örnek kaynaklar:

• Active Directory / LDAP
• HR sistemleri
• Uygulama içi kullanıcı kayıtları

Identity platformu bu kaynaklardan veri toplayabilmeli ve gerektiğinde kendi kullanıcılarını oluşturabilmelidir.

Organizasyon Grafı

Bir kullanıcı kimliği yalnızca bir kullanıcı adı değildir. Kurumsal bağlamda her kullanıcı bir organizasyon yapısının parçasıdır. Identity platformu şu bilgileri ilişkilendirebilmelidir:

• Kullanıcı
• Organizasyon
• Departman
• Pozisyon
• Rol

Bu sayede platform şu sorulara cevap verebilir:

• Bu kullanıcı kimdir
• Hangi organizasyonda çalışır
• Hangi rollerle işlem yapabilir

Rol ve Delegasyon Modeli

Kurumsal platformlarda kullanıcılar tek bir rol ile sınırlı değildir.

Bir kullanıcı:

• Birden fazla rol üstlenebilir
• Geçici vekalet alabilir
• Belirli sürelerle farklı yetkilerle işlem yapabilir

Identity platformu bu tür dinamik rol değişimlerini desteklemelidir.

Tenant Farkındalığı

Kurumsal platformlar çoğu zaman çoklu organizasyon yapıları içerir.

Örneğin:

• Ana kurum
• Bağlı iştirakler
• Farklı organizasyon birimleri

Identity platformu bu yapıyı tenant bazında modelleyebilmelidir.

İnsan ve Dijital Varlıklar Servisi

Kurumsal dijital platformlarda çoğu zaman "kullanıcı" kavramı gereğinden fazla dar tanımlanır. Oysa platform içindeki birçok süreç yalnızca sistem hesaplarını değil, insanları ve dijital varlıkları hedef alır.

Örneğin:

• Bir çalışana e‑posta gönderilir
• Bir kişiye SMS ile bilgilendirme yapılır
• Bir kioska "bu adreste elektrik kesilecek" mesajı iletilir
• Bir IoT cihazına durum bilgisi gönderilir

Bu nedenle platform mimarisinde yalnızca "account" veya "user" kavramı yeterli değildir. Platformun insanları ve dijital hedefleri birlikte modelleyebilen bir servis içermesi gerekir.

Temel Kavramlar

Bu modelde iki ana varlık bulunur:

İnsan

Gerçek dünyadaki bireyi temsil eder. Örnek bilgiler:

• Ad / soyad
• İletişim bilgileri
• Organizasyon ilişkileri

İnsan her zaman bir sistem hesabına sahip olmak zorunda değildir.

Dijital Varlık

Platform tarafından hedef alınabilen dijital bir varlığı temsil eder.

Örnekler:

• Kiosk
• IoT cihazı
• Bilgilendirme sistemi
• Robot veya makine
• Uygulama endpointi

Bu varlıkların her biri bir adreslenebilir hedef olabilir.

Neden Ayrı Bir Servis?

Kurumsal süreçlerin çoğu "account" üzerinden değil hedef varlıklar üzerinden çalışır.

Örneğin:

• Bir çalışan bilgilendirilebilir
• Bir departman ekranına duyuru gönderilebilir
• Bir kioska uyarı iletilebilir

Bu nedenle platform şu soruları cevaplayabilmelidir:

• Bu mesaj kime gidecek?
• Bu bildirim hangi dijital varlığa iletilecek?

Identity ile İlişkisi

Identity platformu hesapları (account) ve erişim yetkilerini yönetir.

İnsan ve Dijital Varlıklar servisi ise sistemde yer alan aktörleri tanımlar. Bu aktörler bazen bir account sahibi olabilir, bazen de yalnızca sistemin hedef aldığı bir varlık olabilir. Bu modelde önemli olan nokta şudur:

• Bir insan bir veya daha fazla account sahibi olabilir.
• Bir insanın hiç accountu olmayabilir ancak süreçlerde hedef alınabilir.
• Bir dijital varlık (örneğin kiosk veya cihaz) bir account sahibi olabilir.

Örneğin:

• Bir kiosk içerdeki bir servise çağrı yaparak "bir kullanıcı harita istedi" bilgisini iletebilir.
• Bir insan belirli bir serviste yapılacak bir işi gerçekleştirmek üzere görevlendirilebilir.

Bu durumda servislerle etkileşime giren şey doğrudan account değil, insan veya dijital varlığın kendisi olabilir.

Dolayısıyla mimari model şu şekilde düşünülebilir:

• İnsan / Dijital Varlık → sistemdeki aktör
• Account → bu aktörün sistemlerde işlem yapabilen kimliği

Bir aktörün birden fazla accountu olabilir veya hiç accountu olmayabilir. Bu ayrım platformun gerçek dünyadaki süreçleri daha doğru modellemesini sağlar.

2. Kurumsal Dijital Platformun Temel Servisleri

Kendi yazılım platformunu kurmak isteyen kurumların belirli fundamental servisleri oluşturması gerekir.

2.1 Identity & Access Platform

Tüm uygulamaların ortak kimlik ve yetki altyapısıdır. Bu servis aşağıdaki fonksiyonları sağlamalıdır:

• Merkezi authentication
• SSO
• Rol ve yetki yönetimi
• Delegasyon (vekalet)
• Kullanıcı yaşam döngüsü
• Audit

Birçok kurumda kullanıcı bilgileri farklı Active Directory domainlerinde bulunabilir. Ayrıca bazı kullanıcıların hiç merkezi kimlik kaynağı olmayabilir (örneğin mavi yaka çalışanlar).

Bu nedenle IAM sistemi farklı kaynaklardan veri toplayabilmeli ve gerekirse kendi kullanıcılarını oluşturabilmelidir.

2.2 Organization & Tenant Model

Kurumsal platformun merkezinde organizasyon modeli bulunmalıdır.

Bu model şu kavramları içermelidir:

• Tenant
• Organizasyon
• Departmanlar
• Pozisyonlar
• Çalışan ilişkileri

Bir kullanıcı için şu soruların cevaplanabilmesi gerekir:

• Kimdir
• Hangi organizasyonda çalışır
• Hangi rolü vardır
• Hangi uygulamalara erişebilir

2.3 Contract Registry

Kurumsal platformlarda uygulamalar birbirlerini doğrudan bilmemelidir.

Servisler arası iletişim kontratlar üzerinden tanımlanmalıdır. Contract registry aşağıdaki bilgileri tutmalıdır:

• API kontratları
• Event şemaları
• Kontrat versiyonları
• Kontrat sahipliği

Bu yaklaşım servislerin birbirinden bağımsız gelişebilmesini sağlar.

2.4 Event Bus

Servisler arası iletişimin önemli bir kısmı event-driven olmalıdır.

Örnek eventler:

• Employee.updated
• Organization.changed
• Asset.created
• Workflow.completed

Event-driven mimari servisler arasında gevşek bağlılık sağlar.

2.5 Application Registry

Platformdaki tüm uygulamaların merkezi katalogudur. Her uygulama için şu bilgiler tutulmalıdır:

• Uygulama sahibi
• Hangi kontratları yayınlıyor
• Hangi kontratları tüketiyor
• Hangi tenantlarda aktif

2.6 Observability Platform

Operasyonel güvenilirlik için güçlü bir gözlemlenebilirlik altyapısı gerekir.

Temel bileşenler:

• Merkezi loglama
• Metrikler
• Distributed tracing
• Alarm sistemleri

Bu altyapı olmadan büyük sistemleri troubleshoot etmek neredeyse imkansızdır.

Kurumsal Dijital Platform Referans Mimarisi

Kendi dijital servislerini geliştirmek isteyen kurumlar için en kritik konulardan biri platform mimarisinin doğru kurulmasıdır. Aşağıdaki yapı pratikte birçok kurum için çalışabilir bir referans model sunar.

Platform Katmanları

Bir kurumsal dijital platform genellikle aşağıdaki katmanlardan oluşur:

1. Identity Platform

Tüm sistemlerin kimlik ve yetkilendirme merkezi.

• Authentication
• Authorization
• Kullanıcı yaşam döngüsü
• Rol ve delegasyon yönetimi

2. Organization & Tenant Graph

Kurumun dijital organizasyon modelini tutar.

• Tenant yapısı
• Organizasyon birimleri
• Pozisyonlar
• Çalışan ilişkileri

Bu model tüm uygulamalar tarafından referans alınmalıdır.

3. Contract Registry

Servislerin birbirleriyle nasıl konuştuğunu tanımlar.

• API kontratları
• Event şemaları
• Kontrat versiyonları

Servisler birbirlerini doğrudan değil kontratlar üzerinden tanır.

4. Event Bus

Servisler arası asenkron iletişimi sağlar. Örnek olaylar:

• Employee.updated
• Asset.created
• Workflow.completed

Bu yapı servisler arasında gevşek bağlılık sağlar.

5. Service Layer

Kurumsal iş servislerinin bulunduğu katmandır. Örnek servisler:

• Varlık yönetimi
• İş süreçleri
• Sürdürülebilirlik
• IoT veri toplama

Bu servisler mümkün olduğunca bağımsız geliştirilmelidir.

6. Data Layer

Her servis kendi veri modeline sahip olmalıdır.

Temel prensip:

Veri sahipliği servise aittir.

Servisler mümkün olduğunca başka servislerin veritabanına doğrudan erişmemelidir.

7. Observability Layer

Tüm platformun gözlemlenebilirliğini sağlar.

• Log toplama
• Metrikler
• Distributed tracing

Bu katman büyük sistemlerde troubleshooting için kritik öneme sahiptir.

Önerilen Teknoloji Stack'i

Her kurum kendi teknoloji tercihlerini yapabilir. Ancak pratikte birçok platform aşağıdaki türde bileşenler kullanır:

• Containerization: Docker
• Orchestration: Docker Swarm veya Kubernetes
• Event Bus: Kafka, NATS veya benzeri mesajlaşma sistemleri
• Contract Definition: OpenAPI / AsyncAPI
• Observability: Prometheus, Grafana, Loki, Jaeger

Bu teknolojiler bir zorunluluk değildir ancak platform kurarken sık kullanılan bileşenlerdir.

3. Servis Mimarisi

Kurumsal platformların tamamı mikroservis olmak zorunda değildir. Çoğu kurum için başlangıç noktası modüler monolith olabilir. Bu yaklaşımın avantajları:

• Operasyonel basitlik
• Transaction yönetimi kolaylığı
• Hızlı geliştirme

Sistem büyüdükçe belirli modüller ayrı servislere ayrılabilir. Mikroservis mimarisi şu durumlarda anlamlı hale gelir:

• Farklı ekipler aynı sistem üzerinde çalışıyorsa
• Bağımsız ölçekleme gerekiyorsa
• Domain sınırları netleşmişse

Contract-Driven Architecture

Kurumsal platform mimarisinde servisler arası bağımlılığı azaltmanın en etkili yollarından biri contract-driven architecture yaklaşımıdır.

Bu yaklaşımın temel prensibi şudur:

Servisler birbirlerini doğrudan bilmez. Birbirlerini kontratlar üzerinden tanırlar.

Bir servisin başka bir servisle ilişki kurabilmesi için şu bilgilerin açıkça tanımlanması gerekir:

• Hangi API'leri sunuyor
• Hangi eventleri yayınlıyor
• Hangi kontratları tüketiyor

Bu bilgiler merkezi bir Contract Registry içinde tutulabilir.

API Kontratları

Servislerin sunduğu API'ler açık bir kontrat ile tanımlanmalıdır. Bu kontratlar şu bilgileri içerir:

• Endpoint tanımları
• Request / response şemaları
• Hata kodları

OpenAPI bu tür kontratlar için yaygın kullanılan bir standarttır.

Event Kontratları

Event-driven mimaride yayınlanan olayların da açık bir şeması olmalıdır.

Örnek:

employee.updated

Bu event aşağıdaki bilgileri içerebilir:

• employeeId
• organizationId
• updatedFields

AsyncAPI bu tür event kontratları için kullanılabilir.

Versiyon Yönetimi

Kontratların versiyonlanması kritik öneme sahiptir.

Temel prensipler:

• Backward compatibility korunmalıdır
• Eski kontratlar belirli süre desteklenmelidir

Bu yaklaşım platformdaki servislerin bağımsız gelişebilmesini sağlar.

4. Veri ve Transaction Yönetimi

AI ile geliştirilen sistemlere yönelik en sık eleştirilerden biri şudur:

"Transaction yönetimi doğru yapılmazsa sistem patlar."

Bu eleştiri doğrudur ancak sorun AI değildir. Transaction tasarımı mimari bir konudur.

Temel prensipler:

• Veri sahipliği net olmalıdır
• Transaction sınırları belirlenmelidir
• Servisler arası transactionlardan kaçınılmalıdır

Gerekli durumlarda event-driven eventual consistency kullanılabilir.

5. Container ve Deployment Stratejisi

Modern kurumsal platformların çoğu container tabanlı çalışır.

Docker

Servislerin paketlenmesi için standart yöntemdir.

Docker Swarm

Küçük ve orta ölçekli platformlar için oldukça yeterlidir.

Avantajları:

• Kurulum kolaylığı
• Düşük operasyonel karmaşıklık

Kubernetes

Daha büyük ölçekli platformlar için tercih edilir. Ancak operasyonel karmaşıklığı daha yüksektir. Birçok kurum için başlangıç noktası Docker Swarm olabilir.

6. Service Mesh Gerekli mi?

Service mesh çoğu zaman erken aşamada gereksiz karmaşıklık yaratır.

Service mesh şu durumlarda anlamlıdır:

• Çok sayıda mikroservis varsa
• Trafik yönetimi karmaşıksa
• Güvenlik politikaları merkezi yönetilmek isteniyorsa

Başlangıç aşamasında API gateway ve event bus çoğu ihtiyacı karşılar.

7. SDLC

Kurumsal geliştirme süreçleri güçlü bir SDLC disiplini gerektirir. Temel aşamalar:

1. Tasarım
2. Kontrat tanımı
3. Geliştirme
4. Test
5. Deployment
6. Operasyon

AI destekli geliştirme bu süreci hızlandırabilir ancak bu süreçlerin yerine geçmez.

8. DevOps ve CI/CD

Modern platformlar sürekli teslimat prensipleri ile çalışmalıdır.

Temel bileşenler:

• Otomatik build
• Otomatik test
• Container registry
• Otomatik deployment

9. AI Agent Destekli Geliştirme

AI ajanları geliştirme süreçlerinde farklı roller üstlenebilir:

• Mimari analiz
• Kod üretimi
• Test üretimi
• Güvenlik analizi
• Performans analizi

Bu model küçük ekiplerin üretim kapasitesini dramatik şekilde artırabilir.

10. Ölçeklenebilirlik Tartışması

AI ile geliştirilen sistemlerin ölçeklenemeyeceği sıkça dile getirilen bir eleştiridir.

Gerçekte ölçeklenebilirliği belirleyen faktörler şunlardır:

• Doğru veri modeli
• Doğru servis sınırları
• Doğru cache stratejisi
• Doğru observability

Bu prensipler uygulandığında AI destekli geliştirilmiş sistemler de yüksek yük altında çalışabilir.

AI-Native Development Organization

AI destekli geliştirme yalnızca araçların değişmesi anlamına gelmez. Aynı zamanda yazılım geliştirme organizasyonunun yapısını da değiştirir.

Geleneksel yazılım ekipleri genellikle sabit rollerden oluşur:

• Geliştiriciler
• Test mühendisleri
• Mimarlar
• Operasyon ekipleri

AI çağında bu yapı daha esnek bir modele evrilebilir.

İnsan + AI Hibrit Ekipler

Birçok projede üretken bir geliştirme kapasitesi için büyük ekipler gerekmeyebilir. Bunun yerine küçük bir çekirdek ekip yeterli olabilir:

• Bir insan mimar veya kıdemli geliştirici
• Bir veya daha fazla AI kod üretim ajanı
• Süreçleri ve kaliteyi izleyen AI ajanları

Farklı AI sağlayıcılarından ajanlar aynı projede birlikte çalışabilir.

AI Rollerinin Uzmanlaşması

Zaman içinde AI ajanları belirli konularda uzmanlaşabilir.

Örneğin bir projede şu tür ajanlar bulunabilir:

• Mimari analiz yapan AI
• Veri modeli inceleyen AI
• Güvenlik kontrolü yapan AI
• Performans analizi yapan AI
• Test senaryoları üreten AI

Bu tür uzmanlıklar çoğu kurum için insan kaynağı olarak bulması zor olan yetkinliklerdir.

Stateless Geliştirme Ortamı

AI-native organizasyonlarda önemli bir prensip şudur:

Projede çalışan herhangi biri için bugün ilk gün olabilir.

Bu kişi:

• Projeye yeni katılmış bir geliştirici olabilir
• Başka bir ekipten geçici olarak gelmiş olabilir
• Bir AI ajanı olabilir

Bu nedenle proje bilgisi bireylerin hafızasında değil sistem artefaktlarında tutulmalıdır.

Bu artefaktlar şunları içerir:

• Mimari dokümanlar
• Servis kontratları
• Domain modelleri
• Test senaryoları

Agent Orchestration

Gelecekte geliştirme süreçlerinde AI ajanlarının birbirleriyle iletişim kurarak iş paylaşması daha yaygın hale gelebilir.

Bir ajan:

• Bir kontrat değişikliğini analiz edebilir
• Başka bir ajana test üretmesini isteyebilir
• Başka bir ajandan performans analizi talep edebilir

Bu model yazılım geliştirmeyi tek bir geliştiricinin bireysel üretimi olmaktan çıkarıp çok aktörlü bir sistem haline getirebilir.

Workflow ve Task Platformu

Kurumsal dijital platformlarda sıklıkla tekrar edilen bir problem vardır: Her uygulama kendi workflow motorunu geliştirmeye başlar.

Sonuç genellikle aynıdır:

• Her uygulamada farklı bir workflow modeli
• Birbirinden kopuk görev yönetimi
• Merkezi görünürlüğün olmaması

Bugün piyasadaki birçok konvansiyonel kurumsal yazılım da bu soruna farklı bir şekilde yaklaşmaktadır. Birçok üretici artık uygulamanın içine no‑code workflow araçları eklemektedir. Bunun temel nedeni çoğu zaman mimari bir tercih değil, mevcut uygulamanın kod tabanını değiştirmeden süreçleri uyarlayabilmektir.

Ancak bu yaklaşım uzun vadede yeni bir probleme yol açar:

Kurum içinde onlarca farklı workflow motoru oluşur.

Bu nedenle kurumsal dijital platformlarda workflow yeteneği uygulama içinde değil platform seviyesinde ele alınmalıdır.

Workflow Platformunun Rolü

Workflow platformu kurumsal süreçlerin yürütülmesini sağlar.

Temel fonksiyonları şunlardır:

• Süreç tanımı
• Görev oluşturma
• Görev atama
• Süreç durum takibi
• Otomasyon adımları

Bu platform hem insanlara hem de servislere görev atayabilmelidir.

Aktör Bazlı Görev Atama

Daha önce tanımlanan modelde platformdaki aktörler şunlardır:

• İnsan
• Dijital Varlık
• Servis

Workflow motoru görevleri bu aktörlere atayabilmelidir.

Örnekler:

• Bir insan bir belgeyi onaylamakla görevlendirilebilir
• Bir servis belirli bir veri işleme görevini gerçekleştirebilir
• Bir cihaz belirli bir durumu raporlamakla görevlendirilebilir

Bu yaklaşım süreçlerin yalnızca insan merkezli değil platform merkezli çalışmasını sağlar.

Süreçlerin Servislerle Entegrasyonu

Workflow platformu servislerle kontratlar üzerinden konuşmalıdır.

Örneğin bir süreç şu adımları içerebilir:

1. Bir servis veri üretir
2. Workflow yeni bir görev oluşturur
3. Görev bir insana atanır
4. İnsan işlemi tamamlar
5. Workflow başka bir servisi tetikler

Bu yapı servisler, insanlar ve dijital varlıklar arasında koordinasyon sağlar.

Neden Platform Seviyesinde?

Workflow yeteneği platform seviyesinde sunulduğunda şu avantajlar ortaya çıkar:

• Tüm süreçler tek yerden izlenebilir
• Görev yönetimi standart hale gelir
• Uygulamalar workflow motoru geliştirmek zorunda kalmaz

Kurum içinde onlarca farklı workflow uygulaması yerine tek bir güçlü workflow platformu oluşur.

Contract Governance ve Workflow Stabilitesi

Kurumsal platformlarda sık karşılaşılan kritik bir problem şudur: Bir servisin kontratı değiştiğinde ona bağlı workflow'ların kırılmaması gerekir. Platform büyüdükçe servisler, workflow'lar ve entegrasyonlar arasındaki ilişki ağı çok karmaşık hale gelir.

Bu nedenle kurumsal platformlarda contract governance (kontrat yönetişimi) mimarinin temel parçalarından biri olmalıdır.

Servis Kontratı ile Workflow Kontratı Ayrımı

Bir workflow doğrudan bir servisin API şemasına bağlanmamalıdır. Bunun yerine servis kontratı ile workflow arasında bir domain kontrat katmanı bulunmalıdır.

Önerilen katman yapısı:

Service Contract → Integration Adapter → Domain Contract → Workflow

Servis tarafında bir alanın anlamı değişse bile adapter katmanı gerekli dönüşümü yaparak workflow'un stabil kalmasını sağlar.

Canonical Domain Model

Kurumsal platformlarda workflow'ların servis şemalarına değil, platformun canonical domain modeline bağlanması önerilir.

Örnek domain kavramları:

• Employee
• Asset
• Organization
• WorkflowTask
• NotificationTarget

Servisler kendi veri modellerine sahip olabilir ancak workflow'lar bu canonical model üzerinden çalışır.

Versiyonlama ve Geriye Dönük Uyumluluk

Kontratların versiyonlanması zorunludur.

Örnek:

employee.updated.v1 employee.updated.v2

Temel prensip:

• Mevcut kontrat kırılmaz
• Breaking change yeni versiyon oluşturur
• Eski versiyonlar belirli süre desteklenir

Bu sayede eski workflow'lar çalışmaya devam eder.

Impact Analysis

Contract registry yalnızca kontrat şemalarını saklayan bir depo olmamalıdır. Aynı zamanda kontrat tüketicilerini de bilmelidir.

Örnek:

Contract: employee.updated.v1 consumers:

• workflow.leaveApproval
• notification.employee
• analytics.pipeline

Bir kontratta değişiklik yapılmadan önce etki analizi (impact analysis) yapılabilir.

Dynamic Workflow Sistemleri

n8n gibi dinamik workflow araçları kullanıldığında kontrat yönetimi daha da önem kazanır. Bu tür sistemlerde workflow node'larının servis API'lerine doğrudan bağlanması kırılgan mimarilere yol açar.

Bu nedenle önerilen yaklaşım:

• Workflow node'larının platform kontratlarına bağlanması
• Servis değişimlerinin adapter veya mediation katmanında çözülmesi

Contract Mediation Katmanı

Büyük platformlarda servis kontratları ile platform kontratları arasında bir contract mediation katmanı bulunabilir.

Bu katmanın görevleri:

• Schema doğrulama
• Versiyon yönlendirme
• Payload dönüşümü
• Backward compatibility

Bu yaklaşım platform büyüdükçe servislerin bağımsız evrim geçirmesine olanak tanır.

Kurumsal Dijital Platformun Minimum Çekirdeği

Birçok kurum kendi dijital platformunu kurmak istediğinde en büyük soru şudur:

Nereden başlamalıyız?

Kurumsal platformlar zaman içinde büyür ve olgunlaşır. Ancak başlangıç için tüm bileşenleri aynı anda kurmak gerekmez. Çoğu kurum için aşağıdaki minimum çekirdek platform yeterli bir başlangıç noktası oluşturur.

1. Identity Platform

Tüm sistemlerin ortak kimlik doğrulama ve yetkilendirme altyapısı.

Bu servis olmadan platform parçalanır.

2. İnsan ve Dijital Varlıklar Servisi

Platformun hedef alabileceği aktörleri tanımlar:

• İnsanlar
• Kiosklar
• Cihazlar
• Ekran sistemleri

Bu servis gerçek dünyadaki aktörleri dijital platformla ilişkilendirir.

3. Contract Registry

Servislerin birbirleriyle nasıl konuşacağını tanımlar.

• API kontratları
• Event şemaları
• Kontrat versiyonları

Bu servis platformun entegrasyon düzenini belirler.

4. Event Bus

Servisler arası asenkron iletişimi sağlar. Bu yapı servisler arasında gevşek bağlılık oluşturur.

5. Workflow Platformu

Kurumsal süreçlerin yürütülmesini sağlar.

Görevler:

• İnsanlara
• Servislere
• Dijital varlıklara

atanabilir.

6. Observability Platformu

Platformun sağlığını izlemek için gereklidir.

• Loglar
• Metrikler
• Tracing

Bu altyapı olmadan büyük sistemleri işletmek mümkün değildir.

Başlangıç İçin Önerilen Yol

Bir kurum bu platformu kurmaya aşağıdaki sırayla başlayabilir:

1. Identity Platform
2. İnsan ve Dijital Varlıklar Servisi
3. Contract Registry
4. Event Bus
5. Workflow Platformu
6. Observability

Bu çekirdek oluşturulduktan sonra diğer servisler zaman içinde platforma eklenebilir.

Kurumsal Platform Kurarken Yapılan 10 Büyük Hata

Kurumsal dijital platformlar kurmaya çalışan birçok organizasyon benzer hataları tekrar eder. Bu hatalar genellikle teknik eksikliklerden değil, mimari yaklaşımın eksik tanımlanmasından kaynaklanır.

1. Her Uygulamaya Ayrı Workflow Motoru Eklemek

Uygulama üreticileri çoğu zaman kendi workflow motorlarını geliştirir veya uygulamanın içine no‑code araçlar ekler. Bu yaklaşım kısa vadede pratik görünse de kurum içinde onlarca farklı workflow sistemi oluşmasına neden olur.

2. API Yerine Veritabanı Entegrasyonu Kullanmak

Sistemler doğrudan veritabanları üzerinden entegre edildiğinde bağımlılıklar artar. Bir veritabanı şemasındaki küçük bir değişiklik bile birçok sistemi etkileyebilir.

3. Contract Versioning Kullanmamak

Kontrat versiyonlama yapılmadığında servis değişiklikleri workflow'ları ve diğer sistemleri kırabilir. Breaking change her zaman yeni bir versiyon olarak yayınlanmalıdır.

4. Canonical Domain Model Tanımlamamak

Servislerin veri modelleri doğrudan diğer sistemler tarafından kullanıldığında platform zamanla kontrolsüz bir entegrasyon ağına dönüşür. Workflow'lar ve entegrasyonlar platformun canonical domain modeline bağlanmalıdır.

5. Çok Erken Microservice Mimarisine Geçmek

Birçok kurum daha ilk günden mikroservis mimarisine geçmeye çalışır. Çoğu durumda modüler bir monolith ile başlamak daha sağlıklı bir yaklaşımdır.

6. Observability Altyapısını Kurmamak

Log, metrik ve tracing altyapısı olmadan büyük sistemleri işletmek ve sorunları teşhis etmek çok zor hale gelir.

7. Identity Platformunu Platformun Merkezine Koymamak

Kimlik ve yetki yönetimi merkezi bir servis olarak tasarlanmazsa uygulamalar kendi kullanıcı yönetimlerini oluşturmaya başlar ve sistem hızla parçalanır.

8. İnsan ve Dijital Varlıkları Ayrı Modellememek

Kullanıcı, insan, cihaz ve account kavramlarını tek bir modelde birleştirmek birçok süreçte karmaşaya yol açar. İnsanlar ve dijital varlıklar platformun temel aktörleri olarak ayrı modellenmelidir.

9. Contract Governance Mekanizması Kurmamak

Contract registry yalnızca şema saklayan bir depo değil, aynı zamanda tüketicileri bilen ve değişikliklerde etki analizi yapabilen bir yönetişim mekanizması olmalıdır.

10. Platformu Sadece Teknoloji Projesi Olarak Görmek

Kurumsal dijital platformlar yalnızca teknik mimari değildir. Organizasyon yapısı, SDLC süreçleri ve geliştirme kültürü de bu platformun parçasıdır.

Bu hatalardan kaçınmak platformun uzun vadede sürdürülebilir olmasını sağlar.

AI Çağında Kurumsal Yazılım Geliştirme Gerçekten Mümkün mü?

Bu makalede anlatılan mimari ilk bakışta birçok kuruma oldukça karmaşık ve hatta gerçekçi olmayan bir hedef gibi görünebilir.

Bugün birçok organizasyonda mevcut durum çok daha parçalıdır:

• Bir Active Directory veya benzeri bir kimlik sistemi vardır
• Workflow ayrı bir ürün olarak satın alınmıştır
• Farklı uygulamalar birbirleriyle sınırlı entegrasyonlara sahiptir
• Sistemler arasında açıkça tanımlanmış kontratlar çoğu zaman bulunmaz

Bu nedenle burada anlatılan platform yaklaşımı başlangıçta "fazla ideal" veya "fazla büyük" bir hedef gibi algılanabilir.

Ancak dikkat edilmesi gereken nokta şudur: Kurumlar zaten bugün bu karmaşıklığın içinde yaşamaktadır. Sadece bu karmaşıklık çoğu zaman tasarlanmış bir mimari olarak değil, yıllar içinde oluşmuş bir yamalı yapı olarak ortaya çıkar.

AI destekli geliştirme araçları küçük ekiplerin üretim kapasitesini dramatik şekilde artırmaktadır. Bu durum geçmişte yalnızca büyük yazılım şirketlerinin kurabildiği mimari yapıların artık kurum içinde de kurulabilmesini mümkün hale getirmektedir.

Bu, kolay bir dönüşüm değildir. Ancak artık teknik olarak mümkündür.

Kurumlar tüm bu platformu tek bir projede kurmak zorunda değildir. Çoğu durumda bu dönüşüm aşağıdaki şekilde ilerler:

1. Kimlik altyapısı merkezi hale getirilir
2. Kontratlar tanımlanmaya başlanır
3. Servisler event tabanlı iletişim kurmaya başlar
4. Workflow platformu merkezi hale gelir

Zaman içinde parçalı sistemler yerini daha tutarlı bir platform mimarisine bırakır.

AI çağında asıl değişen şey şudur:

Kurumlar artık yalnızca yazılım tüketicisi olmak zorunda değildir.

Doğru mimari yaklaşım, güçlü bir SDLC disiplini ve AI destekli geliştirme araçları ile kurumlar kendi dijital platformlarını inşa edebilir.

Sonuç

AI çağında kurumlar yalnızca yazılım satın alan organizasyonlar olmak zorunda değil.

Doğru mimari, doğru platform servisleri ve güçlü bir SDLC disiplini ile kurumlar kendi dijital servislerini geliştirebilir.

Bu dönüşüm yalnızca teknolojik değil aynı zamanda organizasyonel bir dönüşüm.

Ve bu dönüşüm çoktan başladı ve hıza devam ediyor.

Okuma süresi: ~12 dakika

Giriş

Yıllardır kurumların yazılım stratejisi oldukça basitti. ERP satın al. PDKS satın al. Doküman yönetim sistemi satın al. IoT platformu satın al. Kurumlar yazılım üretmezdi. Yazılım satın alırdı.

Bunun çok iyi sebepleri vardı. Yazılım geliştirmek pahalıydı, yavaştı ve ciddi uzmanlık gerektiriyordu. Bir kurumsal sistemi sıfırdan geliştirmek çoğu kurum için gerçekçi değildi.

Ama son birkaç yılda bir şey değişmeye başladı. Üretken yapay zekâ araçları yazılım geliştirme hızını dramatik biçimde değiştirdi. Küçük ekipler, geçmişte büyük yazılım organizasyonlarının aylarca geliştirdiği sistemleri günler içinde üretebilir hale geldi.

Bu değişim doğal olarak şu soruyu ortaya çıkarıyor:

Kurumlar artık kendi yazılımlarını geliştirebilir mi?

Bu yazı bu soruya mimari, süreç ve insan perspektifinden bakmaya çalışıyor.

Paket Yazılım Dönemi Nasıl Ortaya Çıktı?

1990'lı yıllarda yazılım dünyası bugünkünden çok farklıydı.

O yıllarda yazılım firmaları genellikle her müşteri için o kuruma özel yazılım geliştirirdi. Bir proje yazıldığında o proje o kurumun olurdu.

• Veri modeli o kuruma göre tasarlanırdı
• İş süreçleri o kuruma göre kodlanırdı
• Sistem o kurumun gerçekliğini yansıtırdı

Sonra yazılım üreticileri aynı sistemi farklı müşterilere satabilmenin yollarını aramaya başladı. Böylece "paket program" dönemi doğdu. ERP sistemleri, PDKS çözümleri, doküman yönetim sistemleri ve daha pek çok kurumsal yazılım bu modelle yayıldı.

Bu model ilk bakışta harikaydı.

• Geliştirme maliyeti birçok müşteri arasında paylaşıldı
• Kurumlar hızlı şekilde yazılım kullanmaya başladı
• Yazılım üreticileri ölçeklenebilir iş modelleri kurdu

Ama zaman içinde başka bir problem ortaya çıktı. Kurumların dijital dünyası silo halinde çalışan uygulamalardan oluşmaya başladı.

Entegrasyon Çağı

Bir kurum ERP kullanıyordu. Başka bir sistem PDKS tutuyordu. Başka bir sistem dokümanları yönetiyordu.

Bu sistemlerin konuşması gerekiyordu. Böylece entegrasyon dönemi başladı. Bu entegrasyonlar yıllar içinde farklı şekiller aldı:

1. Veritabanı üzerinden entegrasyon
2. SOAP servisleri
3. REST API'leri

Ancak çoğu entegrasyon güçlü bir kontrat yönetimi olmadan geliştirildi. Sonuçta her yazılım güncellemesi potansiyel bir risk haline geldi. Bir sistem güncellendiğinde diğer sistemler bozulabiliyordu. Kurumlarda şu cümle çok tanıdık hale geldi:

"Bu sistemi güncellersek diğer sistemler etkilenir mi?"

Güncelleme Problemi

Birçok paket yazılım üreticisi sağlam yazılım geliştirme metodolojileri kullanmıyor.

• Kontrat sürümleme yoktur
• Backward compatibility çoğu zaman düşünülmez
• Dev → Test → Prod döngüsü yeterince güçlü değildir

Bu nedenle güncellemeler çoğu zaman riskli hale gelir. Birçok kurum güncelleme yaparken şunu hisseder:

Bir şeyi düzeltirken başka bir şeyi bozuyor olabiliriz.

Kurum İçi Geliştirmenin Problemleri

Paket yazılımların sınırlamaları nedeniyle bazı kurumlar kendi yazılımlarını geliştirmeye çalıştı.

Ama bu yol da kolay değildi. Kurumsal geliştirme ekiplerinin karşılaştığı sorunlar oldukça tanıdıktır:

• Backlog'da yıllarca bekleyen işler
• Küçük ekiplerle büyük sistemler geliştirme zorunluluğu
• Hızla demode olan teknoloji stack'leri
• Yeni teknolojilere adaptasyon zorluğu
• Ekip değişikliklerine karşı kırılganlık

Birçok kurum şu iki seçenek arasında sıkıştı:

• Paket yazılım esnek değildi
• Kurum içi geliştirme yavaştı

Öğrenme Problemi

Kurum içi geliştirme ekiplerinin bir başka problemi de öğrenme kapasitesiydi. Bir kurum kendi yazılımını geliştirdiğinde çoğu zaman yalnızca kendi deneyimlerinden öğrenir. Bu nedenle kurum içi uygulamalar çoğu zaman "en iyi uygulama" olarak kabul edilir.

Paket yazılım üreticileri ise farklı müşterilerden öğrenebilir. Ama onların da başka bir problemi vardır. Bir özellik tüm müşterilerin işine yaramıyorsa çoğu zaman geliştirilmez.

Bunun yerine başka bir şey yapılır:

parametrizasyon.

Zaman içinde birçok kurumsal yazılım şu hale geldi:

• On binlerce parametre
• İş akış motoru ile özelleştirme
• Karmaşık konfigürasyon ekranları
• Anlaşılması zor davranışlar

Paradigma Değişimi

Bugün yaşanan değişim yalnızca "AI ile kod yazmak" değildir.

Asıl değişim şudur:

Kurumlar artık yazılım tüketicisi değil, dijital servis üreticisi olabilir.

Ama bunun gerçekleşebilmesi için kurumların uygulama değil platform düşünmesi gerekir.

Stateless Development

AI çağında yazılım geliştirme farklı bir modele evriliyor. Bu modelin temel varsayımı şaşırtıcıdır:

Projede çalışan herkes için bugün ilk gün olabilir.

Bir geliştirici projeye yeni katılmış olabilir. Bir AI ajanı projeye yeni dahil olmuş olabilir. Akşam olduğunda ise projede olmayabilirler.

Bu model ilk bakışta kaotik görünür.

Ama sistem bilgisi insanların kafasında değil sistemin içinde tutulduğunda bu durum bir risk olmaktan çıkar. Dokümantasyon, kontratlar, testler ve mimari kararlar sistemin hafızası haline gelir.

Uzun yıllardır yazılım mühendisliğinde arzulanan bir hedef vardı:

Gerçekten stateless geliştirilebilen sistemler.

AI ile birlikte bu hedef ilk kez pratik olarak mümkün hale geliyor.

AI'nin Kolektif Öğrenme Avantajı

Bir insan geliştirici kariyeri boyunca sınırlı sayıda projede çalışır. AI sistemleri ise geniş açık kaynak ekosisteminden öğrenir.

Bu nedenle bazen tek bir insanın sahip olamayacağı kadar geniş bir perspektif sunabilir. Bu AI'nın her şeyi bildiği anlamına gelmez.

Ama farklı yaklaşımları karşılaştırabilen bir kolektif deneyim sağlar.

Çoklu AI Ajanları ile Geliştirme

Bugün bir projede üretken şekilde çalışmak için çoğu zaman şunlar yeterlidir:

• İki farklı AI sağlayıcısından ajan
• Bir insan geliştirici veya mimar

İşin ilginç tarafı şu:

Bu insan ve AI ajanların her biri için o gün projedeki ilk gün olabilir. Akşam olduğunda ise projeden ayrılmış olabilirler. Ama sistem ayakta kalır.

Çünkü bilgi bireylerde değil sistemdedir.

AI Ekosisteminin Hızla Evrilmesi

Bugün konuştuğumuz pratikler altı ay sonra farklı bir noktaya evrilmiş olacak. AI gelişimi doğrusal değil logaritmik ilerliyor. Yakın gelecekte projelerde şu tür uzman AI ajanları görmek şaşırtıcı olmayacak:

• Veri ambarı uzmanı AI
• Güvenlik mimarı AI
• Performans analizi yapan AI
• Yalın süreç uzmanı AI

Bugün kurumların istihdam etmekte zorlandığı uzmanlıklar projelere kolayca dahil olabilir. Bir sonraki adım ise AI ajanlarının birbirleriyle doğrudan iletişim kurabilmesi.

Sonuç

İnsan meraklı bir varlık.

Aynı anda umut ile korku arasında yaşayan, yeni şeyleri denemek isteyen ama risklerden çekinen bir bilinç. AI çağında yazılım geliştirme de tam olarak bu duyguların arasında şekilleniyor.

Ama bir gerçek giderek daha görünür hale geliyor. AI yazılım üretimini demokratikleştiriyor.

Kurumlar artık yalnızca yazılım satın almak zorunda değil. İsterlerse kendi dijital platformlarını kurabilirler.

Ve bu platformlar yalnızca insanlar tarafından değil,

insanlar ve AI ajanlarının birlikte çalıştığı yeni bir üretim modeliyle geliştirilebilir.

AI çağında en büyük risk yanlış karar vermek değildir.

En büyük risk hiç başlamamaktır.

Yazarın Notu

Bu metni kaleme alan insan tarafı olarak şunu açıkça söylemek isterim.

Bu yazıda anlatılan tarih yalnızca kitaplardan veya arşivlerden derlenmiş bir teknoloji kronolojisi değildir. Bu satırları yazan kişi, burada bahsedilen dönemlerin tamamında aktif olarak çalışmış bir yazılım geliştirici, sistem mühendisi ve yazılım mimarıdır.

1990'lı yıllarda kurumlara özel yazılım geliştirilen dönemde de vardım. Paket yazılımların yükselişini de yaşadım. SOAP servislerinin entegrasyon mucizesi olarak görüldüğü günleri de hatırlıyorum. REST API'lerin ortaya çıkışını da. Ve her birinin beraberinde getirdiği sorunları da.

Bu nedenle bu metindeki birçok gözlem tekil bir örneğe dayanmıyor. Çoğu hüküm yıllar boyunca farklı kurumlarda, farklı projelerde, tekrar tekrar yaşanmış deneyimlerin ortak sonucudur.

Bazen genç geliştiriciler "yeni geldik diye eksik miyiz" diye sitem edebiliyor. Elbette değiller. Her nesil kendi zamanının araçlarıyla dünyayı yeniden kurar.

Ama yazılım dünyasında bazı kalıplar onlarca yıl boyunca tekrar eder. Bu yazı o tekrar eden kalıpların içinden konuşuyor.

Dolayısıyla burada anlatılanlar bir arşiv taramasının sonucu değil, uzun bir mühendislik pratiğinin içinden süzülmüş gözlemlerdir.

Not

Bu makale, insan ve yapay zekâ arasında gerçekleşen uzun bir fikir alışverişinin sonucunda ortaya çıktı. Sorular, itirazlar, karşı argümanlar ve yeni fikirlerle birlikte şekillendi.

AI ile düşünmek yalnızca metin üretimini değil, fikirlerin olgunlaşma hızını da değiştiriyor.

Ülkemiz yazılım üreticilerinin, geliştirmiş oldukları yazılımlara destek verme konusundaki performansları hızla düşüyor. Ekosistem geliştikçe bağımlılıklar artıyor ve çözülemeyen problemler hızla çoğalıyor. "Çözüm Ortağı" firmaların DevOps olarak üstlendikleri rol ise bu performans düşüşüyle birlikte bir kabusa dönüşüyor.

Başlangıçta, yani daha önceki yıllarda sorunlar oldukça hızlı çözülebilirken, artık her bir sorun bir krize dönüşüyor. Sahada koşturan "Bayi" ya da "Çözüm Ortağı" firmalar da giderek başarısız birer DevOps departmanına dönüşüyor.

Bu sorunun çözümü, yazılım üreticilerinin birbirlerinden görüp benimsedikleri destek izleme sistemlerinin ve destek ekibi kompozisyonlarının yeniden yapılandırılması ile mümkün görünüyor. Eğer üreticiler müşteri memnuniyetini olay bazlı toplayıp analiz etselerdi, yaşanan bu sorunu daha erken görebilir, destek ekiplerini uygulama desteği ve DevOps desteği olarak ayırmaları gerektiğini fark edebilirlerdi.

Problem

Önceki dönemlerde basitçe bir sunucuda host edilen tekil uygulamalar, bugün birbiriyle sürekli gelişen entegrasyonların içinde ayakta kalmakta zorlanıyor. Problem çözme hızı ve şekli zaman içinde yavaş yavaş değiştiği için, aslında sorunu fark etmek çoğu zaman son ana kadar kolay değil.

Bir yazılım ürünü için yaşam döngüsünde oldukça kritik olan "DevOps" ve "Uyarlama" fonksiyonlarının, üretici tarafından çeşitli gerekçelerle tamamen "Çözüm Ortağı"na yüklenmesi; sorunun azalmasını değil, tam tersine kontrol edilemez hale gelmesini sağlıyor.

Ürün geliştiricileri, kademelendirilmiş destek hizmetlerini müşteri memnuniyeti temelinde değil, minimum maliyet temelinde yapılandırmakta kararlı görünüyorlar. Üstelik bu yaklaşımı birbirlerinden kopyaladıkları için sorunu fark etseler bile çözüm için harekete geçemiyorlar.

On yılı aşkın süredir bu alanda çalışan ve güçlü ürünleri olan firmaların sahipleriyle görüşüldüğünde ise, yetkin personelin elde tutulamamasından ve doğal olarak destek faaliyetlerinin toplam maliyetinin yüksekliğinden şikayet ediyorlar. Dolayısıyla müşteri memnuniyeti, artık ilk öncelik olmaktan çıkıp arka sıralara düşüyor.

Semptomlar

Bu sorun, temel tehlike olarak kararsız ve zayıf sistemlerin ortaya çıkmasına neden oluyor. Eskiden sıkı ve kapalı kod entegrasyonlar varken, bugün daha esnek ve performanslı REST gibi açık iletişim kanalları tercih ediliyor. Bu durum olağanüstü fırsatlar sunsa da, servisi sağlayan ya da tüketen uygulamada bir hata olduğunda krizlere hızla dönüşebiliyor. Çünkü "Çözüm Ortağı"nın elinde kaynak kod bulunmuyor, üretici ise sadece ürün içindeki fonksiyonlara destek veriyor. Dolayısıyla herhangi bir ürünü güncellemek çoğu zaman tam bir kabusa dönüşüyor.

Basit bir örnek üzerinden ilerleyelim:

Bir uygulamanın web tabanlı olduğunu ve bir reverse proxy arkasında çalıştığını düşünelim. Uygulamanın internete açılması gerektiğinde SSL endpoint’in reverse proxy’de bitecek şekilde yapılandırılması gerekir. Bu durumda DevOps ekibinde hem müşteri tarafı hem de üretici tarafı birlikte çalışmalıdır. İlk kurulumda üretici kendi DevOps ekibinden kaynak tahsis ettiği için kurulum sorunsuz yapılır. Sistem çalışır, ancak bir güncelleme gerektiğinde üretici artık "Ben sadece uygulama içi desteği veririm, DevOps benim işim değil" diyerek desteği reddeder.

Kurulumda beraber çalışabildiğiniz üretici, işletim sürecinde DevOps desteği gerektiğinde konuyu kapsam dışına çıkarmış olur.

Bu sorun, ne yazılım ekosisteminin doğasından ne de müşteri tarafındaki kaynak yetersizliğinden kaynaklanmaktadır.

Çözüm

Üretici firma, saha uygulamalarında "Çözüm Ortağı"nı öne sürüp kendisi geri çekilmezse; son kullanıcılar daha efektif çözümler için daha talepkar olur. "Çözüm Ortağı" tarafından yapılan uyarlamaların uzun vadede tutarlı çalışacağından emin olunabilir. "Firmaya Yazdık" klişesi de yerini "Birlikte çalışıyoruz" anlayışına bırakabilir.

Bu sorun çözüldüğünde, son kullanıcı tarafındaki belirsizlikler ortadan kalkar ve doğrudan iş sürekliliğine katkı sağlar. Aynı zamanda ekosisteme sonradan katılan uygulamaların uyarlanabilmesi için de daha büyük fırsatlar yaratır.

Tüm bu süreçte, nitelikli personelin sahadaki kapasite gereksinimini karşılayacak sayıda ve kalitede bulunması kritik bir faktör olarak göz ardı edilmemelidir.

"Nasıl başlamalı?" sorusuna cevap olarak, ürün desteği ile DevOps desteğinin iki ayrı destek hattı olarak sunulması iyi bir başlangıç noktasıdır. DevOps ekipleri uygulamalar arası etkileşim ve uyumlulukla ilgilenirken, uygulama destek ekipleri ürün içi sorunları çözebilir. Bu ikisi çok farklı yetkinlikler gerektirdiği için tek kişide toplanmaları mümkün görünmemektedir.

Sonuç

Yazılım üreticileri, son kullanıcı desteği konusunda ekiplerini geliştirme, uygulama desteği ve DevOps desteği olarak ayırmalı; destek hizmetleri yönetimini müşteri memnuniyetini olay bazlı takip edebilecekleri bir yapıya dönüştürmelidir.

Bu makale ile, bir ZFS uyarlaması olan ve şu anda pek çok platformda desteklenen OpenZFS dosya sistemi hakkında bilgiler ve yine OpenZFS'e özel bazı uygulamalar anlatılmıştır. Uçtan uca tüm özelliklerden ziyade bir NAS kurulumu için gerekli olabilecek temel bilgilere yer verilmiştir. Bu nedenle snapshot, clone ve replication gibi oldukça güçlü özellikler için topluluk sitesinin incelenmesi yerinde olacaktır. Dokümanın çok uzayıp gitmemesi için dosya sistemi dataset ya da zvol dataset oluşturma ile ilgili bölümler bu doküman kapsamına alınmamış, kapsam zpool oluşturma ile sınırlı tutulmuştur.

OpenZFS Hakkında

OpenZFS, başlangıçta Sun Microsystems tarafından Solaris işletim sistemi için geliştirilen ve şu anda OpenZFS Projesi tarafından sürdürülen, ZFS dosya sistemi ve birim yöneticisinin açık kaynaklı bir uygulamasıdır.

ZFS, veri bütünlüğü, depolama kapasitesi ve esnekliğiyle öne çıkan, son derece güçlü ve çok yönlü bir dosya sistemidir. RAIDZ gibi gelişmiş veri koruma özelliklerine ve kopya üzerinde yazma gibi yenilikçi özelliklere sahiptir.

OpenZFS, ZFS'nin tüm temel özelliklerini korurken, açık kaynaklı bir geliştirme topluluğu tarafından sürekli olarak geliştirilmektedir. Bu da, OpenZFS'yi şu amaçlar için ideal bir seçim haline getirir:

• Sunucu ve NAS cihazları için güvenilir ve yüksek performanslı depolama
• Kişisel bilgisayarlarda veri bütünlüğü ve güvenliği
• Veri merkezlerinde ve bulut ortamlarında büyük ölçekli depolama

OpenZFS'nin bazı önemli avantajları şunlardır:

Veri Bütünlüğü: ZFS, veri hatalarını ve bozulmalarını tespit ve düzeltmek için gelişmiş veri bütünlüğü özelliklerine sahiptir.
Depolama Kapasitesi: ZFS, petabaytlarca veriye kadar depolama kapasitesi sunar.
Esneklik: ZFS, farklı boyutlarda ve kapasitelerde sabit diskleri birleştirmek için kullanılabilir.
RAIDZ: RAIDZ, veri koruması için RAID 1, RAID 2 ve RAID 3'e benzer seviyeler sunan, ZFS'ye özgü bir RAID çözümüdür.
Kopya Üzerinde Yazma: Kopya üzerinde yazma, ZFS'nin anlık görüntüler oluşturmak ve geri yüklemeleri gerçekleştirmek için kullanılabilen bir özelliğidir.
Açık Kaynak: OpenZFS, ücretsiz ve açık kaynaklı bir yazılımdır.

OpenZFS, aşağıdakiler de dahil olmak üzere çeşitli işletim sistemlerinde kullanılabilir:

• Linux
• FreeBSD
• macOS
• Solaris
• Windows (üçüncü taraf çözümleri aracılığıyla)

Proje ile ilgili dokümantasyona https://openzfs.github.io/openzfs-docs/ adresinden ulaşılabilir.

Topluluk

OpenZFS topluluğuna https://github.com/openzfs/zfs adresinden ulaşılabilir. İlk başlangıçta platformlar bazında geliştirici gruplar birbirinden bağımsız ilerlerken, 2020 yılı itibarı ile tüm platform codebase leri birleştirilerek çalışmaları tek bir repo altında toplanmış ve proje OpenZFS çatısı altında devam etmektedir. https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0 ilk bileşik codebase olarak ortaya çıkan sürümdür.

OpenZFS RAID

Genel Bilgiler

Bu bölümdeki tüm ayrımlar, spare ve parity kullanımı ile ilgili düzenlemeler sonucu ortaya çıkan standartlara ilişkin olarak yapılmıştır. Takip eden bölümlerdeki tariflerin daha iyi anlaşılabilmesi için, aşağıdaki görsel iyi bir referans olacaktır.

RAIDZ

RAIDZ, RAID-5'in bir varyasyonudur ve paritenin daha iyi dağıtılmasını sağlar ve tek parite ile yedeklilik sağlar. Aynı zamanda veri kaybına yol açabilen RAID-5'teki "yazma boşluğu" sorununu ortadan kaldırır. Bu yazma boşluğu, güç kesintisi yaşandığında verilerin ve paritenin tutarsız hale gelmesi durumudur. Zira RAID-5 sabit büyüklükte parity bloğu kullanarak veriyi in-place değiştirirken, copy-on-write yapılan I/O nedeni ile RAIDZ, bir tutarlı durumdan diğerine doğrudan geçiş yapmaktadır. RAID'den farklı olarak stripe checksum bilgisi de saklanmakta ve sessiz hatalar tespit edilebilmektedir. Daha detaylı bilgi için https://jro.io/truenas/openzfs/ adresinde oldukça detaylı bir makaleye ulaşılabilir.

RAIDZ2, RAIDZ3

Bir RAIDZ grubu tekli, çiftli veya üçlü pariteye sahip olabilir. Bu, RAIDZ grubunun sırasıyla bir, iki veya üç disk arızasına veri kaybı yaşamadan dayanabileceği anlamına gelir. raidz1 vdev tipi tekli pariteli bir RAIDZ grubunu, raidz2 vdev tipi çift pariteli bir RAIDZ grubunu ve raidz3 vdev tipi ise üç pariteli bir RAIDZ grubunu belirtir. raidz vdev tipi, raidz1 için kullanılan bir takma isimdir.

dRAID

Declustered RAID olarak adlandırılan bu yöntem, disk hataları sonrası RAID rebuild için yapılan I/O nun dağıtılarak daha hızlı sonuç alınması amacı ile geliştirilmiştir. Geleneksel RAID içerisinde konumlandırılan SPARE disklerin yerine mevcuttaki diskler içindeki spare blokların kullanılması ile bu yedek alan tüm disklere dağıtıldığından rebuild dramatik şekilde kısa sürede gerçekleştirilebilmektedir. Bu yeni SPARE için "Logical Spare" ifadesi kullanılmaktadır.

Örnek Uygulama

Örnek çalışmada, üzerinde 36 adet 4TB disk bulunan bir storage ve üzerinde kurulu bulunan Debian 12 (bookworm) dağıtımı kullanılacaktır.

Planlama

ZFS, ihtiyaca göre sınırsız sayıda yapılandırma kombinasyonu sağlayabilir. Bu dokümanda kullanılan büyük kapasiteli (~3.64TBx36) NAS için, maksimum kapasite ve parity sağlayacak yapılandırma irdelenmiştir. Öncelikle 4TB gibi büyük disklerin olduğu ve bunların da bir hayli çok olduğu sistemlerde duraylılık maksimizasyonu için RAID2 (2 parity) kullanımı oldukça iyi bir pratik sağlayacaktır. 36 diskten tek bir vdev oluşturmak yerine 3 ayrı vdev oluşturmak da hem I/O kapasitesi hem de yedekliliğin geliştirilmesi için tercih edilmiştir. Spare olarak ise her bir vdev için birer tane olmak koşuluyla toplamda 3 adet kullanılmıştır. Toplam kapasite ve disk büyüklüğü, DRAID seçilmesi için temel nedeni oluşturmaktadır.

Kapasite hesaplaması için aşağıdaki formül kullanılabilir;

kapasite = (C - S) * (D / (D+P)) * DS

C - Öğe sayısı
S - Dağıtık spare sayısı
D - Veri diski adedi
P - Parite adedi
DS - Minimum disk büyüklüğü

Disk sayıları ve elde edilen çıplak kapasite aşağıdak şekilde hesaplanmıştır;

Çıplak Kapasite = (36 - 3) * (27 / (27 + 6)) * 3.64 = 33 * 0.81 * 3.64 = 94.62 TB

Metadata ve operasyonlarda kullanılmak üzere rezerve edilen alanlar gözönünde bulundurulduğunda yaklaşık 90 TB kullanılabilir alan elde edilmiş olacaktır.

Yapılandırma

Bu bölümde, örnek donanımımız planlama aşamasında belirlendiği üzere 3 adet 2 parity bulunduran vdev olacak şekilde yapılandırılacaktır. Bunun için aşağıdaki komut kullanılabilir;

$ sudo zpool create tank1 draid2:9d:12c:1s /dev/sd[b-m]

dRAID pool içinde bir vdev oluşturulacağı zaman yukarıdaki gibi bir ifade kullanılır. Bu örnekte kullanılan değerler;

draid2: Her bir blok için iki parity blok kullanımı
9d: Toplamda 9 adet veri diski kullanımı
12c: VDEV içinde toplamda 12 disk kullanımı (söz diziminin tutarlılığı için kullanılır)
1s: VDEV içinde her bir blok için 1 spare blok kullanımı

Günlük Operasyonlar

ZFS dosya sistemi kullanan cihazlar, genellikle ya kapasite açısından ya da disk büyüklüğü açısından kritik sistemlerin kullandığı cihazlardır. Bu nedenle periyodik inceleme planlarının içerisine dahil edilmeleri iyi bir pratik olacaktır. Öcelikle mevcut pool durumları kontrol edilmelidir. Bunun için;

$ sudo zpool status

zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices has been removed by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using zpool online' or replace the device with
	'zpool replace'.
  scan: scrub repaired 0B in 00:00:01 with 0 errors on Mon Jul 22 11:03:26 2024
  scan: resilvered (draid2:9d:12c:1s-0) 652K in 00:00:05 with 0 errors on Mon Jul 22 11:03:25 2024
config:

	NAME                  STATE     READ WRITE CKSUM
	tank1                 DEGRADED     0     0     0
	  draid2:9d:12c:1s-0  DEGRADED     0     0     0
	    sdb               ONLINE       0     0     0
	    sdc               ONLINE       0     0     0
	    sdd               ONLINE       0     0     0
	    sde               ONLINE       0     0     0
	    sdf               ONLINE       0     0     0
	    sdg               ONLINE       0     0     0
	    spare-6           DEGRADED     0     0     0
	      sdh             REMOVED      0     0     0
	      draid2-0-0      ONLINE       0     0     0
	    sdi               ONLINE       0     0     0
	    sdj               ONLINE       0     0     0
	    sdk               ONLINE       0     0     0
	    sdl               ONLINE       0     0     0
	    sdm               ONLINE       0     0     0
	spares
	  draid2-0-0          INUSE     currently in use

errors: No known data errors

komutunun kullanılması yeterli olacaktır. Yukarıdaki örnekte draid2:9d:12c:1s-0 vdev içindeki sdh diskinin yerinde olmadığını ve yerine geçici olarak draid2-0-0 spare alanının kullanıldığı görülmektedir. Örnek olması amacı ile disk arızası simülasyonu için disk çıkarıldığı için bu şekilde görünmektedir.

Disk Online/Offline

Bir disk yerinden cikartıldığında ya da bir nedenle aşağıdaki komutla offline konuma getirildiğinde, ancak tekrar online olması komutu verildiğinde online olacaktır.

$ sudo zpool offline tank1 sdi

Ardından pool kontrol edildiğinde;

$ sudo zpool status
  pool: tank1
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: resilvered 11.3M in 00:00:02 with 0 errors on Mon Jul 22 11:04:40 2024
config:

	NAME                  STATE     READ WRITE CKSUM
	tank1                 DEGRADED     0     0     0
	  draid2:9d:12c:1s-0  DEGRADED     0     0     0
	    sdb               ONLINE       0     0     0
	    sdc               ONLINE       0     0     0
	    sdd               ONLINE       0     0     0
	    sde               ONLINE       0     0     0
	    sdf               ONLINE       0     0     0
	    sdg               ONLINE       0     0     0
	    sdh               ONLINE       0     0     0
	    sdi               ONLINE       0     0     0
	    sdj               OFFLINE      0     0     0
	    sdk               ONLINE       0     0     0
	    sdl               ONLINE       0     0     0
	    sdm               ONLINE       0     0     0
	spares
	  draid2-0-0          AVAIL

errors: No known data errors

Diskin offline olduğu ve fakat spare'in devreye alınmadığı görülecektir. Bunun nedeni offline durumunun disk arızasından değil, istemli bir şekilde gerçekleştirilmesinden kaynaklıdır. Diski tekrar online hale getirmek için;

$ sudo zpool online tank1 sdj

komutunu kullanmak yeterli olacaktır. Eğer disk gerçekten arızalandı ise değişimle ilgili bölümdeki yönergeler kullanılmalıdır.

Bozulan Disk Değişimi

ZFS pool içinden bir disk bozulduğunda, söz konusu disk yenisi ile değiştirildiğinde aşağıdaki komut ile zfspool'a bu değişiklik uygulanır;

$ sudo zpool replace tank1 sdh

Şayet disk adı farklı olacak ise;

$ sudo zpool replace tank1 sdh sd<yeni harf>

komutu ile değiştirilebilir.

Sonuç

OpenZFS, veri bütünlüğü, performans ve ölçeklenebilirlik için tasarlanmış açık kaynaklı bir dosya sistemidir. Bu dokümanda çok küçük bir bölümü ile ilgili bir inceleme yapılmıştır.

Veri bütünlüğünü korumak için ECC ve checksum kullanır, RAIDZ ve cache gibi çeşitli performans optimizasyon tekniklerini destekler ve petabaytlarca veri depolayabilen büyük veri kümeleri için idealdir.

ZFS yönetimi ZFS komut satırı araçları veya grafiksel kullanıcı ara yüzleri (GUI'ler) aracılığıyla kolayca gerçekleştirilebilir ve Linux, macOS ve FreeBSD dahil olmak üzere çeşitli işletim sistemlerini destekler.

OpenZFS, veri merkezleri, masaüstü ve dizüstü bilgisayarlar, sunucular ve depolama cihazları dahil olmak üzere çeşitli kullanım durumları için ideal bir dosya sistemidir.

Veri bütünlüğü, performans ve ölçeklenebilirlik için önemseyen kullanıcılara güçlü ve kullanımı kolay bir dosya sistemi sunar.

OpenZFS hakkında daha fazla bilgi edinmek için şu kaynaklara göz atabilirsiniz:

• OpenZFS topluluğu: https://github.com/openzfs/zfs
• Proje ile ilgili dokümantasyon: https://openzfs.github.io/openzfs-docs/
• OpenZFS Wiki: https://en.wikipedia.org/wiki/OpenZFS

Bu doküman ile, bir radius sunucu ve yönetim panelinin kurulumu ve uygulama alanları hakkında detaylı bilgiler verilmektedir.

Radius

FreeRADIUS, ağ erişim kontrolü, kimlik doğrulama ve yetkilendirme gibi konularda geniş bir yelpazede kullanım alanına sahip güçlü bir açık kaynaklı RADIUS sunucusudur. Ağında kimlik doğrulama ve yetkilendirmeyi merkezi olarak yönetmek isteyen organizasyonlar için ideal bir çözüm sunar.

Bazı önemli kullanım alanları şunlardır:

• Kablosuz Ağ Erişim Kontrolü: FreeRADIUS, 802.1X gibi standartlar aracılığıyla kablosuz ağlara erişimi kontrol eder. Bu sayede, yalnızca yetkili kullanıcıların ağa erişmesini sağlayabilir ve yetkisiz erişimi engeller.
• VPN Erişim Kontrolü: FreeRADIUS, VPN bağlantıları için kimlik doğrulama ve yetkilendirme sağlar. Bu sayede, yalnızca yetkili kullanıcıların VPN'e erişmesini sağlayabilir ve kurumsal verilerini korur.
• Uygulama Yetkilendirme: FreeRADIUS, web uygulamalarına, sunuculara ve diğer kaynaklara erişimi kontrol eder. Bu sayede, yalnızca yetkili kullanıcıların belirli kaynaklara erişmesini sağlayabilir ve veri güvenliğini korur.
• Hesap Yönetimi: FreeRADIUS, kullanıcı hesaplarını yönetir. Bu sayede, kullanıcı adları, parolalar, yetkiler ve diğer bilgileri merkezi olarak yönetir.
• Oturum Yönetimi: FreeRADIUS, kullanıcı oturumlarını yönetir. Bu sayede, oturum sürelerini sınırlayabilir, oturumları otomatik olarak sonlandırabilir ve oturum etkinliğini izleyebilir.
  

FreeRADIUS, esnekliği ve geniş özellik yelpazesi ile farklı sektörlerde ve kuruluşlarda yaygın olarak kullanılır. Eğitim, sağlık, kamu hizmetleri, finans ve perakende gibi sektörlerde ağ erişim kontrolü, kimlik doğrulama ve yetkilendirme gibi konularda tercih edilen bir çözümdür.

FreeRADIUS'un Kullanım Avantajları:

• Açık Kaynak Kodlu: FreeRADIUS ücretsiz ve açık kaynaklı bir yazılımdır. Bu sayede, lisans ücreti ödemeden kullanabilir, kaynak kodu incelenebilir ve ihtiyaçlara göre özelleştirilebilir.
• Esneklik: FreeRADIUS, çok çeşitli kimlik doğrulama ve yetkilendirme yöntemlerini destekler. Bu sayede, farklı ağ ortamları ve kullanıcı gereksinimleri için kullanılabilir.
• Güvenlik: FreeRADIUS, RADIUS protokolü ve diğer güvenlik standartlarını destekleyerek ağı ve verileri korur.
• Ölçeklenebilirlik: FreeRADIUS, küçük ve orta ölçekli ağlardan büyük ve karmaşık ağlara kadar her ölçekte kullanılabilir.
• Kolay Kullanım: FreeRADIUS, kullanımı ve yönetimi kolay bir yazılımdır. Web arayüzü ve komut satırı araçları ile kolayca yönetilebilir.

FreeRADIUS, ağ erişim kontrolü, kimlik doğrulama ve yetkilendirme gibi konularda güçlü ve güvenilir bir çözüm arayan kuruluşlar için ideal bir seçimdir.

Daloradius

Daloradius, FreeRADIUS sunucusuna web tabanlı bir yönetim arayüzü sunan açık kaynaklı bir yazılımdır. Bu araç sayesinde FreeRADIUS yapılandırması CLI ihtiyacı olmadan yapılabilir.

Kurulum

Bu belge, FreeRADIUS hizmeti ve ilgili yönetim modülü Daloradius'u, Debian'ın en son sürümü olan "Bookworm" kod adlı sürümüne kurulum sürecini açıklamaktadır. Aşağıdaki bölümler, güvenli ve işlevsel bir RADIUS kimlik doğrulama sunucusu ortamı oluşturmak için gerekli sistem bileşenlerinin yapılandırılmasını detaylandırmaktadır.

İşletim sisteminin hazırlanması

$ sudo apt -y update

Her şeyden önce, güvenlik duvarı hizmetinin kurulması ve yalnızca gerekli portların bağlantıya izin vermesi sağlanmalıdır. Bunu yapmak için aşağıdaki komutlar kullanılabilir;

$ sudo apt install ufw
$ sudo ufw allow ssh
$ sudo ufw allow "WWW Full"
$ sudo ufw allow radius/tcp
$ sudo ufw allow radius/udp
$ sudo ufw allow radius-acct/tcp
$ sudo ufw allow radius-acct/udp
$ sudo ufw enable

Daha güçlü bir güvenlik duvarı elde etmek istenirse, sistemde yönetim hizmetleri (ssh ve web) ve RADIUS hizmetleri ayırrılabilir ve farklı kurallar oluşturulabilir. Bu, yönetim trafiğini RADIUS trafiğinden ayırır ve saldırganların potansiyel olarak bir hizmete erişerek diğerine sıçrama yapmasını zorlaştırır.

Gerekli servislerin kurulması

MariaDB Sunucusu

RADIUS hizmetine veritabanı hizmeti sağlamak için MariaDB kullanılacaktır. MariaDB'yi apt komutu ile kurmak için öncelikle aşağıdaki komut ile apt kaynaklarına MariaDB deposunun eklenmesi gerekmektedir;

$ curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s --

Şimdi, gerekli MariaDB paketleri depodan kurulabilir;

$ sudo apt install mariadb-server mariadb-client

MariaDB sunucu örneğini güvence altına almak için şu komut kullanılabilir;

$ sudo mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.

Enter current password for root (enter for none):

Bu yeni kurulumda root kullanıcı için bir parola bulunmuyor. Devam etmek için sadece Enter'a basılmalıdır. Ancak güvenlik açısından önemli bir adım olarak Unix soket kimlik doğrulaması etkinleştirilmelidir;

OK, successfully used password, moving on...

Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.

You already have your root account protected, so you can safely answer 'n'.

Switch to unix_socket authentication [Y/n] Y

Her ne kadar gerekmese de MariaDB sunucusunda root kullanıcı için bir parola belirlenmelidir. Bu parola sonraki dönemlerde gerekli olabilir.

You already have your root account protected, so you can safely answer 'n'.

Change the root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!

MariaDB ilk yüklemesi anonim bir kullanıcı sağlar. Bu kullanıcı sistemden kaldırılmalıdır.

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Ağdan yapılacak oturum açma girişimlerinde root kullanıcının bloklanması iyi bir alışkanlık olacaktır;

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 ... Success!

Test veritabanının silinmesi iyi bir pratik olarak mutlaka önerilir;

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Son olarak, çalışan örnekteki yetki tablosu yeniden yüklenmelidir;

Reload privilege tables now? [Y/n] Y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

Bu aşamada MariaDB sunucusunun kurulumu tamamlandı.

Apache & PHP

Bu paketler, aşağıdaki komutlar kullanılarak kurulabilir;

$ sudo apt -y install apache2
$ sudo apt -y install php libapache2-mod-php php-{gd,common,mail,mail-mime,mysql,pear,mbstring,xml,curl}
$ sudo systemctl enable apache2

Freeradius

Freeradius paketini kurmak için aşağıdaki komut kullanılabilir;

$ sudo apt -y install vi freeradius freeradius-mysql freeradius-utils

Aşağıdaki komut ile bu hizmetin başlangıçta çalışacak şekilde ayarlanması yeterli olacaktır;

$ sudo systemctl enable --now freeradius.service 

Daloradius

Bu paketi kurmak için git aracına ihtiyaç vardır, ancak bu araç Debian'ın temel kurulumunda bulunmamaktadır. Kurulum için aşağıdaki komut yeterli olacaktır;

$ sudo apt -y install git

GitHub'dan daloradius adlı yazılımın kaynak kodu aşağıdaki komutla klonlanabilir;

$ git clone https://github.com/lirantal/daloradius.git

Web sunucusunun barındırabileceği konuma daloradius dosyaları aşağıdaki komutla taşınabilir;

# sudo mv daloradius /var/www/

Örnek konfigürasyon dosyası kopyalayarak,gerçek konfigürasyon dosyası olarak kullanılacak şekilde adlandırılmalıdır;

cd /var/www/daloradius/app/common/includes/
$ sudo cp daloradius.conf.php.sample daloradius.conf.php
$ sudo chown www-data:www-data daloradius.conf.php

Apache2 web sunucusunun dosyalara erişim yetkileri aşağıdaki komutlarla ayarlanabilir;

cd /var/www/daloradius/
$ sudo mkdir -p var/{log,backup}
$ sudo chown -R www-data:www-data var

Yapılandırma

Bu bölümde tüm hizmetlerin konfigürasyonu anlatılmıştır. İlk olarak, ana veritabanının oluşturulması ve RADIUS sunucusunun çalışması için gerekli olan yapılandırmanın veritabanına uygulanması gerekmektedir. Veritabanı adı, kullanıcısı ve parolası kuruluma özel olarak değiştirilmeli ve takip eden bölümlerde atıf yapıldığında burada belirlenen değerler kullanılmalıdır.

Veritabanının oluşturulması

$ sudo mariadb -u root -p

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 45
Server version: 10.11.6-MariaDB-0+deb12u1 Debian 12

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> CREATE DATABASE radius CHARACTER SET utf8 COLLATE utf8_general_ci;
MariaDB [(none)]> GRANT ALL ON radius.* TO radius@localhost IDENTIFIED BY "Password.!";
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> \q

Freeradius

Aşağıdaki komut ile radius sunucusunun çalışması için gerekli şema, veritabanına uygulanmalıdır;

$ sudo su -
# mariadb -u root -p radius < /etc/freeradius/*/mods-config/sql/main/mysql/schema.sql

DB Yükseltme:

Eğer FreeRADIUS veritabanınızı yeni bir sürüme yükseltiyorsanız, aktarılan veritabanında bazı değişiklikler yapmanız gerekebilir. Bu doküman için yapılan çalışmada, eski veritabanında aşağıdaki değişikliklerin uygulaması yeterli sonucun alınmasını sağlamıştır;

MariaDB [radius]> alter table radacct add framedipv6address varchar(45) NOT NULL default '',framedipv6prefix varchar(45) NOT NULL default '';
MariaDB [radius]> alter table radacct add framedipv6address varchar(45) NOT NULL default '';
MariaDB [radius]>  alter table radacct add framedipv6prefix varchar(45) NOT NULL default '';
MariaDB [radius]>  alter table radacct add framedinterfaceid varchar(44) NOT NULL default '';
MariaDB [radius]> alter table radacct add delegatedipv6prefix varchar(45) NOT NULL default '';
MariaDB [radius]>  alter table radacct add class varchar(64) default NULL;
MariaDB [radius]> alter table radacct add KEY framedipv6address (framedipv6address);
MariaDB [radius]> alter table radacct add KEY framedipv6prefix (framedipv6prefix);
MariaDB [radius]>  alter table radacct add KEY framedinterfaceid (framedinterfaceid);
MariaDB [radius]> alter table radacct add KEY delegatedipv6prefix (delegatedipv6prefix);
MariaDB [radius]>  alter table radacct modify column nasportid varchar(32) default NULL;

FreeRADIUS'un SQL konfigürasyon modülünü etkinleştirmek için, kullanılabilir modüller dizini ile etkinleştirilmiş modüller dizini arasında sembolik bir bağlantı oluşturulması gerekir. Bu bağlantı, FreeRADIUS'un SQL veritabanı ile iletişim kurmasını sağlar;

$ sudo ln -s /etc/freeradius/*/mods-available/sql /etc/freeradius/*/mods-enabled/

Bu dosyadaki aşağıdaki kısımların ve değişkenlerin düzenlenmesi gerekir. Elbette parola ve kullanıcı kodu alanları kuruluma özel olarak düzenlenmelidir;

$ sudo vim /etc/freeradius/*/mods-enabled/sql

sql {
driver = "rlm_sql_mysql"
dialect = "mysql"

# Connection info:

server = "localhost"
port = 3306
login = "radius"
password = "Password.!"

# Database table configuration for everything except Oracle

radius_db = "radius"
}

# Set to ‘yes’ to read radius clients from the database (‘nas’ table)
# Clients will ONLY be read on server startup.
read_clients = yes

# Table to keep radius client info
client_table = "nas"

Aynı dosyada, güvenlik açısından önemli olabileceği için MySQL sunucusuna olan SSL bağlantısının devre dışı bırakılması istenmeyebilir. Ancak bu örnekte yerel olarak bağlanıldığı için bunu devre dışı bırakılmıştır. Bunun için aşağıdaki alanların açıklama haline getirilmesi gereklidir;

mysql {
                # If any of the files below are set, TLS encryption is enabled
#               tls {
#                       ca_file = "/etc/ssl/certs/my_ca.crt"
#                       ca_path = "/etc/ssl/certs/"
#                       certificate_file = "/etc/ssl/certs/private/client.crt"
#                       private_key_file = "/etc/ssl/certs/private/client.key"
#                       cipher = "DHE-RSA-AES256-SHA:AES128-SHA"
#
#                       tls_required = no
#                       tls_check_cert = no
#                       tls_check_cert_cn = no
#               }

                # If yes, (or auto and libmysqlclient reports warnings are
                # available), will retrieve and log additional warnings from
                # the server if an error has occured. Defaults to 'auto'
                warnings = auto
        }

Dosyaya erişim izinlerinin doğru ayarlandığından emin olmak için aşağıdaki komutlar çalıştırılmalıdır;

$ sudo chgrp -h freerad /etc/freeradius/*/mods-available/sql
$ sudo chown -R freerad:freerad /etc/freeradius/*/mods-enabled/sql

Son olarak, yeni yapılandırmanın etkili olması için FreeRADIUS sunucusu yeniden başlatılmalıdır;

$ sudo systemctl restart freeradius

Daloradius

Daloradius yazılımı için gerekli olan veritabanı şeması, radius veritabanına aşağıdaki komutlarla uygulanmalıdır;

$ sudo su -
# mariadb -u root -p radius < daloradius/contrib/db/fr2-mysql-daloradius-and-freeradius.sql
# mariadb -u root -p radius < daloradius/contrib/db/mysql-daloradius.sql

Aşağıdaki kısımların ve değişkenlerin düzenlenmesi gerekir. Elbette parola ve kullanıcı kodu alanları kuruluma özel olarak freeradius bölümünde belirtilen değerlerle değiştirilmelidir;

$ sudo vi daloradius.conf.php

$configValues['CONFIG_DB_HOST'] = 'localhost';
$configValues['CONFIG_DB_PORT'] = '3306';
$configValues['CONFIG_DB_USER'] = 'radius';
$configValues['CONFIG_DB_PASS'] = 'Password.!';
$configValues['CONFIG_DB_NAME'] = 'radius';

Apache

Dolayısıyla, http ve https bağlantıları için kullanılan portların yanında 8000 portunun da daloradius yönetim arayüzünü çalıştırmak için apache2 içinde etkinleştirilmesi yeterli olacaktır. Operatör ve kullanıcı portallarının birbirinden ayrılması için bu iyi bir pratik olacaktır;

$ sudo tee /etc/apache2/ports.conf<<EOF
Listen 80
Listen 8000

<IfModule ssl_module>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>
EOF

Daloradius'un operatör arayüzüne erişmek için gereken sanal ana bilgisayar ayarlarının apache web sunucusu konfigürasyon dosyalarında bulunması gerekir;

$ sudo tee /etc/apache2/sites-available/operators.conf<<EOF
<VirtualHost *:8000>
    ServerAdmin operators@localhost
    DocumentRoot /var/www/daloradius/app/operators

    <Directory /var/www/daloradius/app/operators>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    <Directory /var/www/daloradius>
        Require all denied
    </Directory>

    ErrorLog \${APACHE_LOG_DIR}/daloradius/operators/error.log
    CustomLog \${APACHE_LOG_DIR}/daloradius/operators/access.log combined
</VirtualHost>
EOF

Kullanıcılar için bir bilgi sayfası oluşturulabilir ancak bu doküman içinde bu uygulanmamıştır. Bunun sebebi, temel alınan uygulamada kullanıcıların RADIUS hesap kayıtlarını görüntülemeye ihtiyaç duymamasıdır. Yine de, bu amaç için şu site kullanılabilir;

$ sudo tee /etc/apache2/sites-available/users.conf<<EOF
<VirtualHost *:80>
    ServerAdmin users@localhost
    DocumentRoot /var/www/daloradius/app/users

    <Directory /var/www/daloradius/app/users>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    <Directory /var/www/daloradius>
        Require all denied
    </Directory>

    ErrorLog \${APACHE_LOG_DIR}/daloradius/users/error.log
    CustomLog \${APACHE_LOG_DIR}/daloradius/users/access.log combined
</VirtualHost>
EOF

Oluşturulan operatör ve kullanıcı uygulamaları apache içinde etkinleştirilmelidir. Bunun için aşağıdaki komutlar kullanılabilir;

$ sudo a2ensite users.conf operators.conf

Her iki uygulama için log klasörleri aşağıdaki komutla oluşturulabilir;

$ sudo mkdir -p /var/log/apache2/daloradius/{operators,users}

apache2 kurulumu ile gelen ön tanımlı site, aşağıdaki komutla devre dışı bırakılabilir;

$ sudo a2dissite 000-default.conf

Son yapılandırmanın etkin olması için apache sunucusu aşağıdaki komutla yeniden başlatılabilir;

$ sudo systemctl restart apache2

Daloradius iki tane pear modülüne ihtiyaç duyar. Bu modüller de aşağıdaki komutla kurulabilir;

$ sudo pear install DB
$ sudo pear install MDB2

Son

Kurulum bu aşamada sona ermiş durumda. Daloradius arayüzüne ulaşarak kullanım amacına göre yapılandırma için her şey hazır.

https://computingforgeeks.com/install-freeradius-and-daloradius-on-debian/ sayfası, bu doküman içinde anlatılanlar ile ilgili kaynak olarak kullanılmıştır.

AKKY seçmek, benzeri türden sistemlerin seçilmesinden pek de farklı değil. Bununla birlikte AKKY taraftarları ve karşıtları arasında ifrat-tefrit tahterevanı bu alanda da belirgin şekilde ortaya çıkıyor ve maalesef "makul" her zamanki gibi yitip gidiyor.

Bu durumu anlamak için çok çabalamaya gerek yok. Nerede bir olay olsa, taraflar hemen karşılıklı geliyor ve konuyu objektif değerlendirmek mümkün olmuyor. Bir bilgi sızıntısı mı oldu, hemen başlıyor AKKY taraftarları kapalı kod elbet olur demeye ve tabii ki karşıt gruptakiler altta kalmayıp başlıyor hazır ürün mü var türküsünü söylemeye.

Şahsi kanaatim, beklenen fonksiyonlar ve hedefler temelinde hareket eden, şayet mümkünse projeyi hibrit bir yapıda tasarlayabilenler bu durumu hakkıyla yönetebiliyorlar.

Problem Nedir ?

Bu makalenin konusunu oluşturan sorun, birbirinin muadili sistemlerin var olduğu varsayımından kaynaklanıyor. Uçtan uca tekil bir ürünle üretilen çözümlerin, tüm bileşenleri ile bir başka üründe aynıyla bulunması bile mümkün değilken açık kaynak ürünlerle aynıyla bulunması mümkün değil.

Bu sorun, kurulacak sistemlerin bileşenler bazında değil bir bütün olarak tasarlanmasından dolayı devam edip gidiyor. Zira AKKY taraftarları bütünün parçaları için var olan çözümleri öne sürüyor ve fakat çoğu zaman projeler monoblok olarak tasarlanıp uygulanıyor.

AKKY kullanımı konusunda çekingen olan profesyonellerin bu davranışı haksız değil elbet. 7x24 destek, öğrenme döngüsü ve özellik seti uyumlu ürün bulunamaması gibi nedenler bu durumun değişmesini engelliyor.

Semptomları Neler ?

Projelerin bileşenlerinin tümüyle aynı üreticiye ait olduğu durumlar, AKKY kullanımı açısından oldukça zorlayıcı durumlar. Bu durumu bir ağ güvenlik sistemi tasarımı örneği ile biraz açmak isterim;

Ağ güvenliği dendiğinde hemen kullanılan kelime Firewall. Bu kelimeye yüklenen anlama baktığımızda, her türden projede farklı seviyeler olduğu görülecektir. Bazı projelerde NGFW bileşenleri (SDWAN, Router, Firewall, Shaper, ZTNA, UTM+Endpoint Protection, DLP ve Logger gibi liste uzar) gerekirken, bazı projelerde belki de sadece gerçekten IP trafiğini yönetecek bir bileşen gerekiyordur. Şayet örnek projemiz tüm bu bileşenlere ihtiyaç duyuyor (yani bir NGFW gerektiriyorsa) ve bunun da tek bir üreticiden karşılanması isteniyorsa, AKKY pek olası görünmüyor haliyle.

Fakat proje fazlarına bölünebilecek olsa, Logger, Router ve Firewall için çeşit çeşit AKKY ürün bulunabilir. Tabi aynı şeyi UTM için söyleyemeyiz. SSL Deep Inspection destekli Application Control, Web Filter ve DLP gibi NGFW bileşenleri konuşulduğunda ise AKKY konumlandırmak mümkün olmayacaktır.

Yetkin personel olmaması, yeterli yetkinlikte AKKY olmaması gibi argümanların bu makalede bahsettiğim probleme doğrudan bir etkisi olmadığını düşünüyorum. Gereklilikler ve bu gerekliliklerin tasarımı burada bahsettiğim probleme neden oluyor.

Çözüm Nedir ?

Eğer tasarlanan sistemler kendi içinde bölümlenebilseydi ve bu işlem herhangi bir uyumluluk sorunu çıkarmasaydı, AKKY kullanımı kesinlikle çok hızlı bir şekilde yükselirdi. Bu nedenle bu sorunun çözümü, sistem tasarımı ekiplerinden geçiyor. Tasarıma dahil edecekleri AKKY ürünlerle de benzer sistemlerin kurulabildiğini gösterecek olan yine onlar.

Bu sayede gerek kritik sektörler, gerekse her seviyeden organizasyonlar çok daha fazla AKKY kullanır ve bu tip bir uygulama kullanmanın verdiği özgürlüğün tadını doyasıya çıkarabilirdi. Dikkat edilirse sektör bölümlemesi de oldukça kritik bir husus olarak öne çıkıyor.

Dikkat edilmesi gereken tehlike, proje bileşenine uyumsuz bir ürünü, sadece AKKY olduğu için kullanmaya kalkışmaktır. Zira oyuna yeni giren bir oyuncu durumundaki AKKY, sistem başarımı açısından hep göz önünde olacaktır.

Bir projede AKKY ürünleri konumlandırmaya niyet ettiğimizde;

• Projede kullanılacak bileşenler farklı ürünlerden oluşabiliyor mu ?
• Her bir bileşen için beklenen fonksiyonlar neler belirlenmiş mi ?
• Projenin nihai amacı nedir ?
• Proje, ihtiayaca uygun ölçekte tasarlanmış mı (Çekici olan her şeyi çivi görüyor malum) ?

konularının dikkatlice planlanması gerekiyor. Ardından her bir bileşen için AKKY uygunluğu değerlendirilmeye başlanabilir.

Sonuç

AKKY ürünleri konumlandırmak çok kolay olabileceği gibi, imkansıza yakın da olabilir. Bunu belirleyen şey projenin kendisi ve bu projeyi tasarlayan ekiptir. Her projede AKKY kullanılamayacağı gibi, sadece AKKY ile oluşturulabilek onlarca proje alanı yer almaktadır.

Şayet sizin de projenin AKKY ile çözülebilecek olur ise, üreticiden kaynaklı her türlü sorundan hasıl olacak riskleri, daha proje aşamasında azaltmış ve hatta ortadan kaldırmış olursunuz.

Bu yazıda sizlere, OSS/FOSS yazılımların yaygınlaştırılabilmesi ve bizi özgür kılabilmesi için yapılabilecek birkaç makro hususu paylaşmak istedim. Zira bu sıralarda sürekli aklımda bu konu var ve üzerinde düşündüğüm ve kendimce geliştirilebileceğine inandığım çözüm fikirlerim kaybolup gitsin istemedim. Biraz da kendime not gibi oldu.

"Özgür Yazılım, Özgür Kılar" diye bir deyişimiz var biliyorsunuz. İlk söyleyeni bulamadım, lakin bilen varsa bana da haber verirse sevinirim. Güzel ülkemizde ve bizim gibi gelişmekte olan diğer ülkelerde "Özgür" yazılımın değeri, diğer ülkelerden biraz daha farklılaşıyor. Zira ürettiği ve ihraç ettiği değer, dışarıya bağımlı olduğu ve ithal ettiği değere yakın ve hatta az olan bir ekonomide sonsuza kadar gelişmekte/gelişmeye çalışmakta olan ülke olarak kalmak söz konusu.

Son üç yıldır ülkemiz inovasyon ekosistemi içerisindeki oyuncuların bir çoğu ile temas etme ve bu habitatta değer üretmeye yönelik geliştirilebilecek proje fırsatlarını araştırmakla geçti vaktimin bir kısmı. Ülkemiz temel stratejisinin de kabaca;

• Oyun Geliştir
• Inovasyonu Destekle
• Yerli ikameyi artır (sivil ve askeri)

olduğuna ilişkin yaptığım çıkarımın çok da isabetsiz olmadığını umuyorum. Bu başlıkların her birisi, dünya ile bağlarımızda bir karşılıklılık, denge oluşturmaya yönelik çabaları içeriyor. Ekonomik, politik ve hatta sosyolojik açıdan dış olaylardan daha az etkilenme ve daha uzun dengede kalabilmeye yönelik girişimler.

Hal böyle olunca, "Yerli İkame" konusunda oldukça ciddi potansiyeli olan "FOSS/OSS" yazılımların yerel üreticiler tarafından neden hiç göz önüne alınmadığını anlamak zor değil.

Zira yerli üretici firmalar gerek mevcut gelir modelleri ve gerekse konfor alanlarından çıkmak istememeleri nedeni ile bu tip bir şeye uzak bakıyorlar. Zira yukarıda belirttiğim makro hedefler, firmaları pek ilgilendirmiyor. Onları sadece satışın ve gelirin devamlılığı ilgilendiriyor, ötesi değil. Bu durumu, bu firmaların vizyon ve misyon beyanlarını incelediğinizde rahatlıkla görebiliyorsunuz.

Mevcut Durum

Yerli kurumsal yazılım üreticileri, ellerinde imkan olsa bile FOSS araçları kullanmamakta kararlı görünüyorlar.

Kurulumu yapılan bir sistemde kullanılan bileşenlere bakıldığında neredeyse %100 FOSS araçlarla kurulabilecek ürün, gidip kapalı kod ürünler kullanılarak yükleniyor.

Kurumsal yapılar için uygulama geliştiren firmaların, sadece geliştirirken değil, müşteride yapılan kurulumlarda da FOSS sistemleri öncelemeleri sağlanmalı. Ama nasıl ?

Problem Nedir ?

Yakın zamanda çalıştığım kuruma aldığımız ve ülkemizin yüz akı yazılım firmalarından bir tanesi tarafından geliştirilmiş IK yönetim uygulamasının kurulumunu planlarken bu tuhaf durumun farkına vardım. Tümüyle açık kaynak olarak servis edilebilecek bir ürünü, tümüyle kapalı kod bir sistem üzerinde koşturmak konusundaki israrını anlamakta gerçekten zorlandım.

Öyle ya, şimdiye kadar eldeki geliştirilmiş ürünler uyumsuz, ondan FOSS deploy edilmiyor diye bir argüman üzerinden tartışıp dururken, önümde FOSS uyumlu bir ürün var ve o da yine kapalı kod araçlarla deploy ediliyor, üretici diğer alternatifleri kabul etmiyor. Hadi biraz daha açık konuşayım, Tomcat servlet engine üzerinde koşan ve JNI benzeri bir bağımlılık da kullanmayan bir uygulamayı geliştirip de, neden kapalı bir kod işletim sisteminde zorla çalıştırmak ister bir üretici ? Gerek donanım ve gerekse işletim sistemi kaynağı kullanımında daha etkin bir kullanım imkanı varken ? Hatta hatta konteynerize edilmesi neredeyse dakikakalar alabilecekken ? Yurt dışındaki kapalı kod üreticilere  $6.500 ödememek varken ?

Sorunun neden devam ettiğini anlamaya yönelik girişimlerimde ise değişik aktörlerden değişik cevaplar alıyorum sürekli. Bu hususu kurulumu yapan, ya da üretimi yapan firma yetkilileri ile tartıştığımda genellikle; "Sahada bunu destekleyecek bayi ağı nasıl oluşturacağız, bilen mi var FOSS/OSS araçları?" argümanı geliyor. Buna ilişkin ülkedeki insan kaynağı ile ilgili biraz bilgi verdiğimde ise "FOSS ürünler güvenilmezdir, zira içinde ne var ne yok görünüyor, o nedenle kullanmamak gerek" diyenler çıkıyor.

"İyi de hocam github, git gibi şeyleri geliştirmede kullanıyorsunuz, apache nginx tomcat kullanıyorsunuz. Kodunuz kapalı olunca içindeki zaafiyetleri bulunamıyor mu sanıyorsunuz." deyince de "O başka" cevabı geliyor.

Direncin temelinde ne var diye iyice bir baktığınızda aslında bir kaç husus göze çarpıyor;

• Üreticinin ürününün altyapısında kullandığı kapalı kod ürünlerden elde ettiği ikincil gelirler
• FOSS kullanımı için firma ve çalışanlarında bir gelişim/öğrenim gerekliliğinin olması
• FOSS bir ürün kullanmanın firma karlılığı açısından hiçbir anlamlı karşılığının olmaması
• Sahada üreticinin ürününü satan ve yerel kurulumlarını yapan yapıların da yukarıdaki maddeleri paylaşıyor olmaları
• Aslında sahada yapılan kurulumların, kapalı kod bile olsa yetkin olmayan kişilerce, asgari düzeyde sistem bilgisi ile yapılıyor olması.

Semptomlar

Açık kaynak araçlarla geliştirilmiş bir ürünü gidip kapalı kod bir ortama yüklüyorsanız, sorunu bütün çıplaklığıyla görebilirsiniz demektir. Üstelik bu ürün yeni geliştirilmiş bir ürün ise. Yani uygulamanın geçmişten getirdiği bir yükü de yok ise. Peki bu durum neden tehlikeli bir durum ? Kamusal bağımsızlığımız açısından ortaya çıkmış bir fırsatın heba edilmesi anlamına geliyor bu senaryo da ondan. Evet, tek bir uygulamada FOSS kullanımı ülkeyi bağımsız kılmayacaktır, fakat bu şekilde örnekler bir araya geldiğinde uygulama yazılımları ve genel olarak bilişim alanındaki özgürlüğümüze inanılmaz bir katkı sağlayacaktır. Finansal yükten kurtulma bunun yanında küçük bir bonus olarak kalacaktır.

En başından söyleyeyim son söylenecek şeyi; "Elimizde tüm ülkeye yetecek kadar işinin ehli adam yok, kapalı kod sistemler olduğunda da, FOSS olduğunda da". Kurulum yapılan kurumlarda da yapılan işi irdeleyip kitaba uygunluğunu doğrulayacak yetkin kapasite yok. Böyle olunca "Çalışıyor" olması çoğu zaman yeterli oluyor. Bu sorunu, basit bir tomcat kurulumunda webapps klasörünün yerini değiştirmeyi bilemediğinden uygulamayı gidip "c:\program files" altında deploy eden uzmanda görebilirsiniz. Bunu eleştirmek için söylemiyorum, sadece durumun mevcutta da sorunlu olduğunu ifade etmek için söylüyorum. Bu durum, FOSS kullanımında temel sorunun işgücü olmadığını açıkça ortaya koyuyor.

Çözüm Nedir ?

Sorunun yazılım üreticisi firmalar ile ülke politikalarının arasında bir ilinti olmamasından kaynaklandığı konusunda oldukça güçlü bir inancım var ki önceki bölümlerde detayı ile incelediğimi düşünüyorum bu hususu. Peki kamu otoritesi ve politika yapıcılar neden bunu hiç masaya koymuyor derken birden "Kamu'da OSS kullanımının yaygınlaştırılması" hususunda kamu otoritesinin bir irade beyanı geldi biliyorsunuz. E o zaman gelin biraz da yazılım üreticileri ile, ülkenin gelecek projeksiyonu ile ilgili politikalarını nasıl uyumlulaştırabiliriz, firmaları mevcut hedeflerinden dönmek zorunda kalmadan bu işe destek verecek şekilde hareket etmeye nasıl razı ederiz diye düşünelim, ne dersiniz ?

Uyumlulaşmayı sağlayacağını düşündüğüm önerim şöyle ifade edilebilir;

"Firma mevcut hedeflerine yönelik, yani karlılığına katkı sağlayacak şekilde FOSS kullanımından kaynaklı teşvik mekanizmaları kurarak, ülkenin makro hedeflerine ulaşmasında bu firmaları birer araç olarak kullanmak".

Zira kamu otoritesinin kendi misyonu gereği üstlendiği özgürlük ve makro sürdürülebilirlik için koyduğu hedefleri, firmaların müşteri/satış sürdürülebilirliğinden çok daha farklı aksiyonlar gerektiriyor ve doğrudan örtüşmüyor. Firma hedefinin makro hedefi desteklemesini sağlamak pekala mümkün diye düşünüyorum.

Bu sorunu farkettiğim vaka örneğindeki yazılım gibi eminim bir sürü yazılım vardır ülkemizde üretilen ya da kullanılan. Yerli üreticinin ürününün kurulumunu yaptığı her bir sistem için, hem ürünü satın alan firmaya, hem de ürün üreticisi firmaya avantaj sağlayacak bir teşvik mekanizması sağlansa nasıl olur ? Söz konusu üretici firma ürün yüklemesi için aynı şekilde mi davranır, ürün satın alan firma ürün alırken FOSS bir platformu tercih etmede istekli olur mu acaba. Şöyle bir seviyelendirme de yapılabilir. Bu sayede geçiş için üretici firmalar da motive edilebilir.

• FOSS işletim sistemi başına %xx
• FOSS veritabanı başına %yy
• FOSS uygulama sunucusu başına %zz

Buradaki %xx, %yy, %zz tıpkı teknopark da ofis açan firmaya sağlanan vergi avantajı gibi tasarlanabilir.

Bu yumurta ve civciv kısır döngüsünü da kırmak için FOSS ürünlere yerinde destek veren firmalara da (siz bayilerine diye anlayın) benzer şekilde;

• FOSS ürün kurulumu gelirine %ff
• FOSS ürün operasyon desteği gelirine %gg
• FOSS ürün eğitimi gelirine %hh

gibi teşvikler sahada çalışan bayi/firma ağına da bir motivasyon olarak verilebilir.

Tabi tüm sistemlerin üzerinde koştuğu IaaS platformları kuran "entegratör" firmalar da benzer şekilde teşvik edilebilirler.

Oldukça yüzeysel incelediğim bu hususta sorumu yineleyerek kendi cevabınızı düşünmenizi istirham ediyorum;

- Özgürlük ne ister ?

Benim cevabım "Özveri"'dir ve bu özveri kamu tarafından üstlenilmek zorundadır. Bu olay özelinde bizler, yani kamu, yazılım üreticisi ya da hizmet sağlayıcısı firmaların mal ve hizmet satışından kaynaklı gelirlerinden alınacak vergilerden elde edeceğimiz kamu gelirinin oldukça cüzzi bir kısmından vaz geçerek mobilize edeceğimiz bir BT ekosistemini, kamusal bağımsızlığımıza, yani özgürlüğümüze destek verecek bir yapıya dönüştürerek bu konuda pozitif etki oluşturacak bir adım atmış olacağız.

Nihai ve kesin çözümü önerdiğimi iddia etmiyorum. Fakat saha gerçeğinden hareketle nasıl bir motivasyon, nasıl bir aksiyon ortaya konabilir farklı açılardan da bakmak gerektiğini söylüyorum.

Kalın sağlıcakla,

Bu makaleyi yazmaya, ülkemiz gündemine yakın zamanda giren ve kamu kurumlarında OSS, daha da geniş bir yorumla FOSS kullanımını çerçevelemeyi hedefleyen kamu iradesinin ortaya çıkışı ile karar verdim. FOSS araç gereçlerle bir BT sisteminin hangi bölümlerinde neleri ne kadar karşılarız bunu size sunmaya çalışacağım. Başlarken birkaç hususta mutabık kalmamız lazım. Bu nedenle konuya kategorik olarak nasıl yaklaştığımı izah etmek isterim. Bilişim araç gereçlerini ezelden beri iki kısımda incelerim;

• Masaüstü / Son Kullanıcı araç gereçleri
• Sunucu / Backend sunucu araç gerçleri

Bunun için de kendimce haklı bir gerekçem var; Son kullanıcı dediğimizde insandan, doğal olarak bir kültürden bahsediyor oluruz. Bu alandaki yargılar ve buna bağlı kararlar hep subjektif olarak kalır ve irrasyonel bile olsa kabul görebilir doğal olarak. Stratejik her hamle de mevcut kültürle kıran kırana savaşmayı gerektirir ki çoğu zaman boşuna bir uğraşıdır bu (Druker ağabeyin kulakları çınlasın)

İkinci başlık ise daha rasyonel bir zemine işaret eder. Bu alanda da insan bir faktördür ama ana faktör değildir. Bir de bu alanda karşımıza çıkan profesyoneller nispeten daha rasyonel yaklaşımlar sergileyeceklerdir (yani öyle umuyorum).

Bu kadar izahat yeterli sanırım. Buradaki bilgiler Fiziksel zeminden IaaS a kadar, yani VM teslimatına kadarki kısmı içeriyor. Konteynerizasyon tarafına ilerlediğimizde, ya da PaaS a doğru giderken bambaşka hikayeelerimiz var elbet. Aşağıda vereceğim tablo, tabandan tavana kadar, bir servisin son kullanıcıya erişebilmesi için gerekli sistemlerde uzun zamandır kullandığım FOSS araçlardan oluşuyor. Yani internette arayıp, yorumlardan esinlenerek değil, bizatihi canlı sistemde kullandığım araçları bulacaksınız burada. Detay merak ediyorsanız benimle temasa geçmekten çekinmemenizi özellikle istirham ederim.

Elbette operasyon gereklilikleri nedeni ile her araç her senaryoda çalışmayacaktır. Bununla birlikte iddia ediyorum ki, kendi iç servislerini host eden bir veri merkezi / sistem odasının IaaS platformu yeterli güvenlik seviyesinde kolaylıkla FOSS araçlarla tasarlanabilir ve hayata geçirilebilir. Şimdi soruyorum, böylesi bir dönüşümün bize, ülkemize ve dünyaya faydası nedir ? Tartışmaya değer değil mi ?

Wig preparation should consider comfort, tangling and how the fibres appear under camera lighting. Density should support the hairstyle without making the wig unnecessarily heavy. For the relevant hair design, Marin Kitagawa cosplay wig（喜多川海夢 コスプレウィッグ） identifies the matching cosplay wig. Heat resistance should be confirmed before any styling tool is used. Comfort improves when the cap, hairline and securing points are adjusted carefully. Small fringe changes may be enough to improve character recognition.

İnternet üzerinde zaman zaman karşılaştığımız BT personeli iş ilanlarındaki aşırı yetkinlik setleri, her türden sosyal medyada ve özellikle bir iş ağı olan linkedinde sürekli olarak eleştiri konusu oluyor. Bu konuda şikayet etmektense çözümün parçası olmak amacıyla da bir şeyler yapmak gerekiyor. İnsan Kaynakları bölümünde çalışan sevgili dostlar onlara verilen setler üzerinden ilana çıkıyorlar, ya da internetten bulunan örnekleri kullanıyorlar.

Bu durum başvuru performansını oldukça kötü yönde etkileyen bir yan etki yapıyor. İK departmanındaki arkadaşlarımızın daha profesyonel bir iş ilanına çıkmalarına ve doğal olarak daha iyi adaylara ulaşabilmelerine destek verebilmek için yakın zamanda çıkmış bir ilanın (ki ilanda gereklilikler oldukça detaylı verilmiş ve görev tanımı bu yetkinlik setine sahip bir ekiple birlikte bu operasyonlara destek vereceği şeklinde tanımlanmış) incelemesini yaparak, bu ilanın nasıl olursa daha çok ilgi göreceğini irdelemeye çalışalım.

Haydi başlayalım. Öncelikle mevcut ilanın bir fotosunu vererek başlalım.

Yukarıda ilk başta göze çarpan en önemli sorun, tüm yetkinliklerin bir arada verilmiş olması gibi görünüyor. Tabi bu yetkinliklerin tümünü eş zamanlı kullanıp kullanmayacağı da belirsiz. Bu nedenle “tek kişilik dev kadro” görüntüsü veriyor ve başvuranlar bunu kabul ederek başvuruyor olacaklar. Bu şekliyle ilerlenmesi durumunda yaşanacak serüven yaklaşık şu şekilde olacaktır;

Öncelikle ilana başvuracak adaylara bir bakalım. Adayımızın;

• Yetkinlikleri tutan ilk tipteki adayımızın bu kadar aşırı yüke razı olarak bu işe talip olması ancak bu işe şu anda çok ihtiyacı olmasındandır. İlk fırsatta bırakıp gidecektir.
• Yetkinliklerin bir kısmını veya hiçbirini karşılamayan tipteki adayımız ya nasip diye gelir. “Belki tüm yetkinlikler gerekmiyordur, bir şekilde bu yetkinlikleri karşılayan birini bulamazlarsa girer bildiklerimi yapar, bilmediklerimi öğrenirim” diyecektir.

Birinci seçenekteki adayın işe alındığını düşünelim. Bu personelinizin zamanı burada verilmiş yetkinliklerin tamamını kullanmak zorunda kalacağı bir iş yüküne maruz kaldığında günlük operasyonlarda yetmeyecektir. Bu durumda gerçekleştirilecek görevlerin tamamında zaman içinde sorun yaşanacaktır. Sorunun yaşandığı alana göre de kuruma maliyeti değişecektir. Üstelik fırsatını bulduğunda sizden ayrılacak olmasından dolayı da iş sürekliliği ile ilgili çanlar çalmaktadır.

İkinci seçenekte yer alan ve yetkinliklerin bazılarına sahip bir personelin işe alındığını düşünelim. Yetiştiririm ben dersiniz, yetişince gider. Zira yetkinlik kazandırdıkça iş yükü artar ve belirli bir yükü geçtiğinde bu kadar ağır bir iş yükünü kimse kaldıramaz.

Muhtemelen üçüncü ve son seçenek gerçekleşecektir. Yetkinlikleri biraz geliştirilebilmiş ikinci aday, zamanının yettiği oranda belirli bir alanda çalışacak ve işe alım süreci bu şekilde sonlanacaktır. Elbette pozitif bir sonuç elde edilmiş olmakla birlikte, ilanla istihdam edilmek istenen kapasite ile ele geçen kapasite arasında çok büyük bir fark olması gibi bir durum söz konusu olacaktır.

Peki Ne Yapmalı ?

Bu tip bir personelin işe alımının kolay olmadığını öncelikle kabul ederek başlamakta yarar var. Öncelikle BT alanının birbirine entegre uzmanlıklar gerektirdiğini hatırdan çıkarmamak gerekir. Bu alandaki yetkinliklerin hiç biri bir diğerinden bağımsız değildir. Bu nedenle kendi içinde uzmanlık alanları vardır ve bu uzmanlıklar kendi alanında yetkinlik gerektirir. Bu örnekte talep edilen yetkinliklere bakarak ilana çıkan firmanın temel uzmanlıklardan;

• Sistem Yöneticisi,
• Sistem Destek Uzmanı,
• Ağ ve Güvenlik Uzmanı,
• Altyapı Uzmanı,
• Son Kullanıcı / Endpoint Destek Uzmanı

uzmanlıklarına sahip bir çalışan aradığını anlıyoruz. Eğer bir yazılım da geliştiriliyor olsaydı Geliştirici / Tester / DevOps gibi uzmanlıklar da eklenecektir bu listeye. “Tecrübe” kelimesi oldukça önemli zira tecrübeli kişi ne yapılacağı ile birlikte nasıl yapılacağını da bilen kişidir. Gerçekten tecrübe gerekli mi iyi değerlendirilmelidir. Aday listesini çok hızlı daraltacak, yada aday kalitesini kötü yönde etkileyecektir.

Standart bir işletmede bu uzmanlıklarda birer personel bulundurmak gerekir. Bulundurulamadığı durumda sahada ve masa başında yapılan işleri hiç olmazsa birbirinden ayırmak yerinde olacaktır. Yedeklilik için her bir personelde ikişer uzmanlık aranabilir. Uzmanlık adedi arttıkça çalışanın yaşı artacaktır. Zira her birisinde gerçekten yetkin olmak çoğu zaman yıllar alacak bir saha deneyimi gerektirir. Unutmayın, bu yetkinliklerin bazıları “biraz” olamaz eğer kullanılacaksa. Buna mutlaka dikkat edilmelidir.

Bu örnekteki pozisyonun tüm rolleri tek başına üstlenmeyeceği varsayımı ile ilana şu şekilde çıkılması, doğru adaya ulaşabilmek için daha uygun olabilir;

“Aşağıda detay özellikleri verilmiş rolleri üstlenmiş BT takımımıza, yine bu rollerde görev alacak bir takım arkadaşı arıyoruz. İlgilenenlerin …….”

Genel Nitelikler
Burası firmaya kalmış, kurum kültürü, mezuniyet, organizasyonel yetkinlikler vs. normaldir. Bu örnekte;

• Gizlilik ilkesini benimsemiş, güvenilir
• Bilgi Güvenliği, KVKK ve ISO süreçleri hakkında bilgi/tecrübe sahibi
• MS. Office programlarını etkin olarak kullanabilen
• Sonuç odaklı, düzenli ve planlı çalışan, raporlama alışkanlığı olan ve dokümantasyona önem veren
• Yoğun iş temposuna ve esnek çalışma saatlerine uyum sağlayabilecek
• Yeni çıkan teknolojileri takip eden ve öğrenmeye açık
• İletişim yönü kuvvetli,
• Aktif araç kullanabilen
• Erkek adaylar için askerlik görevini tamamlamış veya en az 4 yıl tecilli
• Seyahat engeli olmayan

şeklinde verilmiş.

Sistem Yöneticisi

• Veri depolama, yedekleme ve bilgi güvenliği önemine sahip
• Veri depolama ve yedekleme çözümleri konularında tecrübe sahibi,
• Lisanslama konusunda bilgi sahibi ve önemine sahip, takibini yapabilecek, yönetebilecek,
• Server, Storage, Nas… Donanımları ve MS işletim sistemine hakim
• Storage, NAS cihazlarının yönetim ve kontrolleri konusunda bilgi sahibi
• Gerekli sistem odası donanımları/yazılımları montaj/demontaj bakım tecrübesine sahip, kurulum ve devreye alma işlemlerini yürütebilecek
• DC,DHCP,DNS,IIS konularında tecrübe sahibi
• Sanallaştırma platformlarını yönetebilecek bilgiye sahip

Sistem Destek Uzmanı

• SQL konularında tecrübe sahibi

Ağ ve Güvenlik Uzmanı

• Firewall, Network, AP yönetimi konularında tecrübe sahibi
• Anti Virüs; Anti Spam, gibi güvenlik yazılımlarına hakim, kurulum ve yönetim tecrübesi olan
• IP kamera sistemleri,
• IP kamera, IP/Analog santral konularında bilgi sahibi
• Demirbaş takibi yapabilecek * Buraya da girdiği için ekledim varlık yönetimi olarak geçer, aktif pasif tüm cihazların izlenmesini kapsar *

Altyapı Uzmanı

• Yapısal network kablolama, Patch panel ve network kablo sonlandırmada tecrübesine sahip,
• kablolama yapabilecek

Son Kullanıcı / Endpoint Destek Uzmanı

• Bilgisayar bilgisine sahip
• Anti Virüs; Anti Spam, gibi güvenlik yazılımlarına hakim, kurulum ve yönetim tecrübesi olan
• CAMA, NX, AUTOFORM vb. çizim programları kurulumu hakkında bilgi sahibi,
• Yazıcı, barkod yazıcıları ve okuyucuları konularında tecrübe sahibi
• Yerinde/ Uzaktan Son kullanıcı desteği verebilecek
• Demirbaş takibi yapabilecek

Eğer siz de bir ilan hazırlıyorsanız elinizdeki yetkinlikleri bu tablodaki uygun yerlere yerleştirebilirsiniz.

1989 yılında ilk profesyonel kodumu yazdığımda başladı bilişim yolculuğum. Pişman değilim, bir daha olursa aynı şeyi bir daha yaparım. Evdeki konteyner platformunu yeni sunucuya migrate etmeyi bitirmiş dinlenirken, haydi bir 5S yapalım diye kalkıştığımızda artık 25 yıldır kullanılmayan malzemelere gelmişti sıra. Evet bizim 5S kriterlerimiz evde biraz değişik, kabul ediyorum. Bir "Progress Software" çantasından 5-6 kutu disket çıktı araştırırken. Oldukça orjinal zamanlara götürdü beni. Artık kullanmam diyerek kenara ayırdığim birkaç bileşeni paylaşayım, eğlencelik olsun diye yazıyorum bu yazıyı da.

İlk dikkatimi çeken "Adobe Wordperfect", 1992 yılından kalan bir disket. Demin baktım ürün halen yaşıyor, inanılır gibi değil. Bugün kullandığımıza benzer çıktılar elde edebildiğimiz ilk kelime işlemci uygulamalardan birisi. Bendeki sürümü, Türkçe desteği de sağlayan ilk sürümlerden birisi.

İkinci dikkatimi çeken Novel Netware 2.2 16bit işletim sistemi. DOS üzerinde çalışıyordu ve ilk client-server çok kullanıcılı uygulamayı deploy ettiğimiz platformdu. Ardından da 32bit Netware 3.12 geliyordu tabi.

Bir diğer ilginç şey ise 16bit ve 32bit uygulamalar için Btrieve sürücülerinin disketleriydi. Tahmin edin, evet Windows NT için btrieve sunucusu da vardı içlerinde.

SCO Unix, oldum olası çok sevdiğim bir işletim sistemiydi ve tam sürüm disketlerim halen duruyordu. Üzerinde 4GL bir veritabanı uygulama geliştirme platformu olarak Progress 4GL disketleri de halen mevcuttu.

Liant'ın C için geliştirdiği framework (ekran formatlamak için elbet) o dönemki matris text ekranları tekrar hatırlattı bana. Epey bir kütüphane de kendi yazmışlığım vardı o yıllarda. Sanırım 1993 olması lazım.

Bu arada dBase IV 2.0 seti çıkageldi elime. Uluşlararası bir yüzme şampiyonasının uygulamasını yazmıştı eşim bununla ve bu ilk kez oluyordu. Sonuçları anında yayınlayabilmek ve tüm organizasyonu tuşlarla hızlıca yönetebilmek mucize gibiydi o zamanlar.

Neyse, birkaç da fotoğraf paylaşayım;

Kalın sağlıcakla.

A broad costume category can help organise choices for events, group shoots and themed projects. Planning by series also helps coordinate related characters in a group. For event or photo planning, Genshin Impact cosplay for events（原神 イベント向けコスプレ） keeps the selection connected to the intended series. This keeps related characters together without reducing them to one costume. A useful comparison considers character identity, preparation time and the planned setting. Careful comparison helps preserve the distinctions between related character designs.

Avrupa birliği, "Ufuk Avrupa" programı ile ilgili 2025-2027 yıllarını kapsayan stratejik planı ile ilgili bir analiz yayınladı. R&I (Research & Innovation) konusunda çalışan ekosistemi geliştirmek yine temel öncelikleri olarak görünüyor. Bu amaçla yapılacak yatırımlar hangi alanlarda olacak diye sorar sormaz gelen ilk dört cevap;

• İklim değişikliği
• Enerji güvenliği
• Sağlık
• Dijital Dönüşüm

olarak öne çıkıyor. Bizler, yani bilişim teknolojileri profesyonellerinin ana gücü olduğu dijital dönüşümün bu şekilde önem kazanması ile birlikte sorumlulukları ve yetkinlik seti gereksinimleri de değişiyor doğal olarak.

"Kardeşim, biz araştırmacı mıyız ?" denilebilir fakat unutmayalım ki teknoloik hazırlık seviyesi 8 e dayanmadan bile geliştirilen teknolojileri uygulayacak entellektüel sermayeye gereksinim olacağı aşikar.

Peki bu dönüşüm/değişime karşı bireysel olarak BT profesyonelleri olarak ne yapmalı, gelecek stratejileri ne olmalı ? Yine raporun içinde oldukça ilgi çekici bir "Emerging Digital Technologies" (Figure 49, sayfa 97) görseli oldukça yol gösterici diye düşünüyorum.

IK görüşmelerinde hep sorarlar ya, XX yıl sonra kendinizi nerede görüyorsunuz diye. Alın size olunması gereken alanlardan bir demet. Bu bilgileri, yine raporda yer alan dijital teknolojiler alanındaki patentlerin dağılımını veren tablo ile birlikte okunduğunda bir yön belirlemek isteyenler için oldukça iyi bir başlangıç noktası oluşturuyor.

Raporun 136 ve 143. sayfaları arasında dijital teknolojiler açısından mevcut stratejik plan ve iş programlarının kapsamları ile, nihai olarak ortaya çıkması ihtimali olan açıklara yer verilmiş, dikkatlice incelenmeli diyorum.

Covid-19 pandemisi ile birlikte iş ve işbirliği yapma şekilleri ile ilgili oldukça radikal değişiklikler oldu. Özellikle WEF (World Economic Forum) raporlarında da sıklıkla yer aldığı gibi kendi kendine öğrenebilen, meraklı ve mental olarak dayanıklı çalışan profili için artık tüm olanaklar mevcut.

Avrupa Birliği stratejistleri, bu çalışan profilinin yenilikçilik kültürüne sahip olmasını da istiyor. Zira R&I ile ilgili çalışmaların Avrupa'nın yüzyüze olduğu sosyal, ekonomik, çevresel, politik ve güvenlik risklerine karşı büyük bir potansiyel taşıdığını düşünüyor.

Yenilikçi firma gelişimlerine bakıldığında temelde dijital dönüşümle ilişkili firmaların çok hızlı büyüdüğünü söylüyor analiz. Unicorn ların sektörel dağılımlarını verdikleri bir grafik zaten bağıra bağıra bunu söylüyor. Firmaların büyür büyümez firma merkezlerini Avrupa'dan taşıdıklarını, dünua ile kıyaslandığında ise US unicorn larının yedi, çinli unicorn ların ise iki katından fazla olduğunu söylüyor.

Wig preparation should consider comfort, tangling and how the fibres appear under camera lighting. Density should support the hairstyle without making the wig unnecessarily heavy. For styling and photo preparation, Marin Kitagawa heat-resistant cosplay wig（喜多川海夢 耐熱コスプレウィッグ） provides the correct wig reference. The colour can be checked under the lighting planned for the shoot. Gentle detangling and suitable storage help maintain the wig between uses. Final styling is easiest after the costume neckline and accessories are considered.

BT sektöründeki değişime ilişkin EU bakışını da yansıtması açısından diğer otoritelerle aynı şeyi söylüyor;

"Ey BT profesyoneli, durduğun yerde duramazsın, ya  kendini doğru alanlarda geliştireceksin, ya da kendine başka bir uğraşı bulacaksın ...!"

Dijital teknolojilerin gelişimine ilişkin öngörüler düşünüldüğünde,  insanların ürettiği bilginin ve entellektüel birikimin niteliği ile ilgili var sayımlar, geçerliliğini kaybediyor. Bilgi artık sadece insan tarafından üretilmiyor, yapay zeka da gün geçtikçe çok daha nitelikli veri üretiyor.

Aniden ortaya çıkan ve oyunun kurallarını çok hızlı bir şekilde değiştiren teknolojilere “Yıkıcı Teknolojiler” adı veriliyor. “Dijital Teknolojiler” söz konusu olduğunda bunun örneklerine çok daha fazla rastlıyoruz.

Bu yazıya konu olarak “Yıkıcı Dijital Teknolojiler”i seçtim  ve oldukça güçlü bir gerekçem var. Tüm dünyanın dilinden düşürmediği bu kavramın, salt hype bir konu olmasından değil, bireyler ve organizasyonel yapılar  açısından oldukça yakın bir tehdit ve aynı zamanda büyük bir fırsat kaynağı olmasından kaynaklanması.

Hype kelimesi, bir ürün, olay veya fikrin abartılı bir şekilde popülerleştirilmesi ve tanıtılmasına deniyor. Sonuçları açısından bakıldığında bazı alanlarda, abartının gerçeğin ta kendisi olduğu durumlar da sıklıkla gözleniyor.

Günümüz teknolojileri,  veri artış hızına ve yapay zeka tarafından işlenebilen veri miktarının artışına bağlı olarak  büyük sıçramalar şeklinde değişiyor ve gelişiyor. Çoklu disiplinlerin eş zamanlı olarak gelişmesine neden olan bu durum, günün sonunda mevcut teknolojinin terk edilerek, yeni teknolojiye geçişin oldukça çabuk olmasına, geçmiş zamanlara bir kaç on yılda oluşan dönüşümlerin yıllar ile ifade edilen zaman aralıklarına dönüşmesine neden oluyor.

Aslında her şey öyle bir sabah oluşmuyor. Belirli yaklaşımlar ile geleceği tahmin etmek mümkün. Bu konudadaki ünlü yaklaşımlardan birisi, konuyla ilgili ortamlarda sıklıkla kullanılan “Hype Cycle for Emerging Technologies” adını taşıyor, 2017 yılında Gartner tarafından yayınlanan ve Türkçe’ye “Yükselen Teknolojiler için Hype Döngüsü” olarak çevrilebilecek olan  bu yaklaşım ile, henüz yeni piyasaya sürülen ve yaygınlaşmaya başlayan teknoloji alanlarının, bundan önce hangi aşamalardan geçtiğini anlamaya yönelik bir metodoloji sunuyor.

Peki bu yaklaşımların bizler ve çalıştığımız kurumlar için önemi nedir ? Bu yaklaşımlar, kurumlar ve bireyler için önümüzdeki  yıllarda karşılaşılacak, dolayısıyla şimdiden pozisyon alınabilecek teknolojileri bilebilme imkanı sağlıyor.

Bu durumu daha anlaşılır kılmak amacı ile bu yaklaşım temelinde iki farklı zaman dilimi için bir analiz ortaya koymak isterim. İlk zaman dilimi, içinde bulunduğumuz 2023 yılı ve yakın gelecek zamanı içeriyor.  Gelin birkaç teknoloji başlığı sayayım;

• Derin Öğrenme
• Makine öğrenmesi
• IoT Platformları
• Serverless PaaS Platformları
• SDS, Yazılım tanımlı güvenlik
• Ticari Drone’lar

Birden bire önümüze çıkıveren ve bedeli karşılığı hemen kullanılabilir durumdaki bu teknolojilerin, bugün bu durumda olacağı beş yıl öncesinden tahmin edilmişti. 2017 yılında bilinir olan ve bugün her yerde karşılaştığımız bu teknolojiler,  için artık ancak tüketici olabilmek mümkün. Zira gelişimlerini tamamlayarak tüketici önünde olgunlaşmış birer ürün olarak duruyorlar.

Ben bu teknolojilerin hiç biri ile karşılaşmadım diyen olabilir. Bunu söyleyenlere sormak isterim,  buzdolabınız yada klimanız evin kablosuz ağına bağlanıyor değil mi  ?  Sosyal medyada ve genel olarak internette dolaşırken, arkadaşınızla demin yazıştığınız ve hatta konuştuğunuz konular sürpriz bir şekilde önünüze çıkıveriyor değil mi ?

Görüleceği üzere içinde yaşadığımız  zaman diliminde farkında olsak da olmasak da karşılaştığımız bu teknoloji alanları, 2017 yılı için kişisel gelişim hedefi, ya da çalıştığımız organizasyon için gerek ürün ve gerekse üretim süreçleri için değişim hedefleri olarak konabilecek alanlardı.

Hiç bir şey için çok geç değil. Önümüzdeki beş yılın sonunda olgunluklarını tamamlayacak teknoloji alanları ise şunlar;

• Akıllı Çalışma Alanları
• Sohbet Odaklı Kullanıcı Arayüzleri
• Blokchain
• Bağlantılı Evler
• Derin Takviyeli Öğrenme
• Akıllı Robotlar

Harekete geçmek için hiçbir zaman geç değil. Bu alanların etkilerini değerlendirmek yeterli. Peki bu teknolojiler yıkıcı sonuçlar doğurabilir mi gerçekten ?

Kurumunuz dahili telefon aboneleri artık mutlu değiller, zira gelişen teknoloji ile birlikte diğer tüm alanlarda olduğu gibi ofis telefonu kullanımında da farklı beklentiler var ve artık mevcut PBX'in değişmesi gerekiyor.

Dış hatlardaki aksamalar, mevcut santraldeki temel fonksiyonlarla ve özellikle IVR ve benzeri uygulamalarla ilgili kullanıcı talepleri, kapasite yönetimi konusunda yaşanan zorluklar mevcut sistemle çözülemez duruma geldi ise, harekete geçmek gerekiyor demektir.

Üç seçenek var. İlk seçenek yönetilen bir servis olarak dışarıdan bu hizmeti almak. İkincisi, pandemi ile artık daha erişilebilir hale gelen bulut PBX altyapılarından birisini (MS Teams, Cisco ya da diğerleri) kullanmak. Üçüncüsü kurum bünyesinde bir tane kurmak. Yazının devamı daha çok üçüncü seçenekle ilgilenenleri ilgisini çekecektir sanırım.

Tarihçe

PBX (Private Branch Exchange) santralleri, 1800'lü yılların sonunda Bell Telephone Company tarafından icat edilen manuel telefon santrallerine dayanıyor. Bununla birlikte modern anlamda kullanılan ilk PBX santralleri, 1960'larda ortaya çıktı ve o zamanlar özellikle büyük şirketler tarafından kullanılıyordu. Günümüzde bu santraller çoğunlukla IP tabanlı çalışan ve telefon gibi gerçek zamanlı kullanılan bir yapı için oldukça yetkin sistemlere dönüştü. Diğer pek çok servis gibi her türden kurumda karşımıza çıkıyor.

Problem Nedir ?

Geleneksel PBX sistemleri, hızla değişen ICT dünyasında yerlerini "Sanal PBX" denilen yazılım tabanlı sistemlere bırakalı epey bir zaman oldu. Muhtemelen ya kurumunuzda kullanılan yapı bu yeni sistemlerden değil, ya beklediğiniz fonksiyonları karşılaması imkansız ya da pahalı. Son dönemde kimle bir araya gelsem konu dönüp dolaşıp bu konuya geliyor.

PBX işi çetrefilli bir iş ve bu nedenle kimse üzerine almak istemiyor. Fakat mevcut sistemler için standart hale gelen IP altyapısı nedeni ile günün sonunda kerhen bir sahiplenme söz konusu. Bu durum PBX projelerinin kurum içinde bir proje olarak ele alınmasını güçleştiriyor. Aslında IT ekipleri bir şekilde (uçtan uca güvenlik yaklaşımına uygun olmadığı için doğru bulmadığım şekilde) güvenlik kameraları ve fiziksel erişim denetimi gibi yapıların yönetiminden kaçınmayı başarmış olsa da, konu PBX olunca çoğu zaman bundan kaçınamıyor sanırım.

İşe koyulmak isteyenler için sistemin temel tasarımını etkileyen birkaç hususu paylaşmak istiyorum;

• Dahili aboneler hangi kanalları kullanacak ? (telefon, mobil telefon, bilgisayar, vb)
• Mevcut sistemle uyumluluk gereksinimi var mı ?
• Görüşmeler hangi tip dış bağlantılarla sağlanacak (PRI, SIP ?) ?
• Bölgesel ya da uluslararası lokal sağlayıcılar kullanılacak mı ?
• Çağrı merkezi uygulaması gerekiyor mu ?
• İş sürekliliği gerekli mi  (Uçtan uca ya da yerel, örn. operatör ve devre yedekliliği gerekiyor mu ?)
• Diğer iletişim kanalları ile bir entegrasyon gerekiyor mu ?
• Gelişmiş bir IVR alt yapısı gerekli mi ?
• Varsa anonsları kim seslendirecek, aynı sesin zaman içinde sürekliliği nasıl sağlanacak ?

Bu liste elbet daha uzun ve kontrol edilmesi gereken başka parametreler de var. Bununla birlikte ortalama bir kurum PBX tasarımı için yeterli sanırım bunlar. Bir çağrı merkezi işletilecekse, elbet bu listenin yanına çağrı merkezi yönetimi ile ilgili maddelerin de eklenmesi oldukça önemli bir husus.

Tam bu noktada bir ilave bilgi vermek isterim. Asterisk, 2000 li yılların başından beri kullanılan bir açık kaynak PBX altyapısı. Sahada araştırma yapmaya başladığınızda oldukça fazla bu sistemin üzerinde yazılmış yönetim konsollarından oluşan ürünlerle karşılacaksınız. Ürünün arkasına baktığınızda yönetim konsolu + tftp + asterisk üçlüsünü görmek sizi şaşırtmasın. Özellikle cisco altyapılarından bu tip bir sisteme geçecek olanlara bir iyi haber vereyim. Pek çok model bu sistemler tarafından destekleniyor ki 8821 gibi modeller de buna dahil.

Hâsıl-ı Kelâm

Kurum içi PBX kullanımında hangi metodu kullanırsanız kullanın, sistem içindeki yapılandırmalarla ilgili bilgi ve yeteneği geliştirmekte yarar var. Bu, firewall içinde bir kural yazmak gibi temel bir yetkinlik bana sorarsanız.

Yedekleme kritik bir husus. Mümkünse PRI + SIP benzeri bir yedeklilik için en başından planlama yapılmalı. Zira sabit telefonla ulaşılamaz olmak (söz konusu olan bir firma/kurum ise) hem iş hem de prestij kaybı anlamına geliyor.

Günümüzde, maliyet etkin ve esnek yapıları kurabilmek artık mümkün. Tümüyle IP çalışan ve özellikle dış devreleri de aynı şekilde olan yapıları kullanan firmalar için PBX, gündelik kullanımda önemli bir destek sistemine sahip olmak anlamına geliyor.

Kalın sağlıcakla,

Merhaba,

Beril, otizmi olan bir genç ve bilgisayarla bir şeyler yapmayı acayip seviyor. Bu yazıda sizlere bir çok hususta yaşadığımız serüvenlerden Wii oyun konsolu ve konsoldan video capture için yaşadığıklarımızı anlatmak istiyorum.

Her şey yaklaşık sekiz hafta önce eşimin; "Beril yengesine whatsapp dan yazmış, wii yi istemiş" demesi ile başladı. Beril normalde böyle bir şeyi yazmaz ve bu tip bir iletişimde bulunmaz. İlginç geldi bize de ve hoşumuza da gitti açıkçası. Wii'yi beklerken bir akşam iş dönüşü "Dolphin Bakalım" cümlesi ile koyulduk maceraya. Dolphin nedir kızım falan derken o gün internette arayıp Wii emulatörü Dolphin'i bulup WII oyunlarını da indirmiş ve ayarlarını yapıp ilk oyunları da oynamış olduğunu farkettim.

Ertesi akşam iş dönüşü, "Dolphin homebrew kuralım" mesajıyla beraber Wii kanallarının bazılarının artık kapalı olduğunu çalışmadığını da öğrenmiş oldum. R24 adında bir grup servisleri yeniden açmış. Sitesinden patch edelim diye indirip yönergeleri uyguladık ama bir türlü aggrement sayfasını geçemedik.

Sonraki akşam geldiğimde Beril epey ilerlemiş bir kaç how-to bulmuştu bile. Hangi yöntemi uygularsak uygulayalım kanalları çalıştıramadık. Custom bir DNS üzerinden hazırladıkları sitelere gidip online kanalları aktive etmişler basitçe ve fakat dolphin içinde ne kadar dns ayarlarsak ayarlayalım çözemedik. Bu durum günlerce sürdü. Kah ağlama krizleri, kah hadi hadi baskısı ile hafta sonuna ulaştık ki bu arada yengemiz fiziksel Wii, denge tahtası ve kumandaları ile çıkageldi.

Yeni hafta için yeni problemimiz hazırdı artık; "Çevre birimlerini dolphin'e tanıtmak". Takla attık günlerce uğraştık nafile. Monster'a Linux kurup dolphin i orada çalıştırarak ilk kez çevre birimlere erişebilmek ancak dördüncü günde mümkün oldu. Bu arada monster windows'un bitlocker anahtarını da bulamadığımızdan yeni baştan windows ve programları kurmak gerekti dual boot ile iki günümüzü de bu aldı. Hafta sonuna ulaştığımızda oyunu dolphin de çalıştırabiliyor, çevre birimleri kullanabiliyorduk. OBS ile kayıtları almaya kalkınca acı gerçekle karşılaştık. Vulcan sürücüleri ile çalışan dolphin görüntülerini OBS ile alabilmek için OBS'i neredeyse sıfırdan derlemek gerekiyordu. Bu arada tesadüfen Monster'da windows Wii kumandasını bir şekilde gördü.Ardından balans board da eklendi. Hah tamam dedik. Artık hem OBS ile kayıt yapabiliyor hem de dolphini windows da kullanabiliyorduk.

Sonraki hafta başı eve geldiğimde yeni görev çoktan hazırdı; "Büyük bilgisayarda çalıştıralım". Monster da windows da nasıl çalıştı diye düşününce bluetooth adaptöründen diye düşündük ve desktop makineye bir bt dongle sipariş ettik. Çarşamba günü geldi, büyük bilgisayara taktık denedik fakat çalışmadı. Bir sürü google araması sonrası uyumsuz olabileceğini düşündük. Hafta sonuna kadar saatlerce süren çalışmalarımız sonuçsuz kaldı ve maalesef desktop a çevre birimleri bağlayamadık. Hafta sonu da bunun için yeterli gelmedi. Bu arada DNS sorununu çözdük yanlışlıkla. Hatırlayabildiniz mi bilmem ikinci hafta online kanalları çalıştıramamıştık emülatörde. Hah, o işlem için windowsun dns leri değiştirdik düzeldi. Yönergeler emulatör içinden değiştirmemizi söylüyordu. Meğerse sorun buymuş.

Yeni hafta başında yeni task gelmişti; "Wii kaydedelim". Wii kendine has bir arayüzden s-video ve rca ses ile çıkış veriyordu ve makineye kayıt yapmak için donanım lazımdı. Aradık bir HDMI dönüştürücü ve bir USB HDMI capture kartı ile orjinal donanımdan kayıt yapmaya karar verdik. Sipariş verdik. İlk gelen ürünlerden HDMI Wii çıkış adaptörü yerine bir HDMI ekleme aparatı geldi. İade edip tekrar sipariş ettik donanımlar ancak cuma elimize geçti. Cumaya kadar geçen beş koca günde ise homebrew kurabilmek için Wii'yi hackledik. USB den .wbf yükleyebilecek eklentileri kurduk. Wii online kanallarını aktive ettik. Yani kayda hazırdık artık. Cuma akşamı ilk kayıt denemesi için Wii den desktopa capture kartı ile görüntü ve ses aldık. 50hz FHD ile nispeten stabil bir görüntü aldık. Ses iyiydi ama ara sıra ekran sync kaçırdığı için hafta sonu da süren çalışmalarımız başarısız oldu.

Yeni hafta yeni task geldi; "BT adaptörü değiştirelim". Emulatorü desktop da çalıştırmamız giderek daha acil bir durum alıyordu. Hatırlarsanız ikinci hafta Monster'ı linux yapıp kullanmıştık. Windows varken denemek hiç aklımıza gelmemişti. Sonra windows da çevre birimler çalışmış ama desktop da çalışmamıştı. Oyun kumandası desktopa bağlanıyor fakat bağlantı ışıkları bir tuhaf yanıyordu. Wii game controller için yazılmış bir araç gözüme takılıyordu ama dolphinle geldi diye şüphelenmemiştim. Aklıma kaldırıp tekrar kurmak geldi. Kaldırıp sürücüleri de sildim tam kuracakken kumanda düzgünce bağlandı. Meğerse ilk hafta Beril dolphini indirirken oradan bunu da indirmiş kendi kurmuş. Yüklenen sürücü de elimizdeki çevre birimlerin çalışmasını engelliyormuş. Neyse bu sayede BT dongle da aklanmış oldu. Biz de hafta sonunu ettik. Gel gelelim emulatörde Wii vote kanalı öldürsen çalışmıyordu. Pazar akşamına kadar çalıştık nafile.

Yeni hafta başında yeni task geldi; "Wii usb bar alalım". Neymiş bu diye interneti araştırınca Wii infrared barın USB den çalışanı olduğunu gördüm. Yeni strateji tekrar bir şekilde emülatörü kullanmak ve fakat kumandayı fiziksel makinedeki gibi motion detect eder şekilde kullanmak olarak belirlenmişti. İnternette bulduk sipariş verdik çarşamba gün yine yanlış ürün geldi ve iade ettim. Bu zamana kadar Beril, emülatörde ve fiziksel Wii de Wii Fit uygulamasını çalıştırmış, balance board ile bir onda bir diğerinde çalışır durumdaydı ve fakat bar olmadığından kumanda hareket sensörü emulatorde kullanılamıyordu. Barın pasif bir ürün olduğunu ancak cuma farkettim. Akşamına Wii dolphin emulatörde, çevre birimler Monster'a bağlı ve bar olarak da fiziksel Wii nin barını wii yi açıp getirip notebook önüne koyarak başarmıştık. Aslında her şey tamamlanmış gibiydi.

Pazartesi aslında yine bir şeylerin eksik olduğunu S-Video capture kartının hepsiburadaki ürün katoloğundan gösterilmesi ile anlamıştım. Beril, HDMI olmayınca S-Video ve RCA dan capture alabilen bir ürün bulmuştu. Sipariş ettik ve çarşamba günü geldi. Ofisteyken telefonum çaldı "Düştü, düştü kırık" şeklindeki ifadeden kargoda cihazın zarar gördüğünü anladım. Akşam bir kablo bağı ile adaptörü toparladık ve ilk görüntü geldi. Ses de geldi. Görüntü bulanık bulundu ve fakat asıl sorun sesteki latency idi. Bu durumda oyunu oynayıp capture almak mümkün olamıyordu. Uğraşırken elektrikler kesildi. Beklerken müzik kanal kaydı yaparken yaşadığımıza benzer ortya çıkan video-ses latency yi, profesyonel USB ses kartımı kullanarak şabilir miyim diye düşündüm. Beril hemen atladı ve karanlıkta arayıp tarayıp cihazı bulup desktop makinenin ve wii makinesinin yanına koyduk. RCA sesi çivi ya da 3.5 çevirecek bir adaptörümüz yoktu tabi. Cuma günü akşam çıkışta Çankaya'da epey bir aradım bulamadım.

Haftalar sonra bu işin istediği gibi olamayacağına ikna oldu Beril. Monster + Dolphin + Çevre Birimler + Fiziksel Wii inf bar + OBS ile çalışmaya razı oldu. Aslında dördüncü hafta gibi bu setup a ulaşmıştık ama otizm böyle bir şey işte. Üç tane video yapmış getirdi demin. Youtube kanal açalım dedi. Birkaç kanal açtık. aşağıda vereyim linklerini;

Beril's Wii Channel

Hemen ardından diğer oyunlar için açtığımız şu anda boş olan kanallar;

Beril's The SIMS4 Channel
Beril's The SIMS3 Channel
Beril's ETS2 Steam Channel
Beril's OMSI2 Channel

Şimdi baktım, kanal avatarları hazırlanmaya başlamış. Videolar yüklenmeye başlamış.

Neyse, işte böyle dostlar. Otizmli ve dijital artist olarak çalışmayı seven bir kızınız varsa hayat biraz da böyle bir şey.

Kalın sağlıcakla,