<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Dukasim Blog</title>
    <link>https://dukasim.com.tr/blog</link>
    <atom:link href="https://dukasim.com.tr/blog/rss.xml" rel="self" type="application/rss+xml" />
    <description>Network health check, NOC ve monitoring, yönetilen BT, IT destek ve kurumsal kablolama üzerine Dukasim uzmanlarından rehberler ve teknik yazılar.</description>
    <language>tr-TR</language>
    <copyright>© 2026 Dukasim Haberleşme ve Elektronik Sist. San. ve Tic. LTD. ŞTİ.</copyright>
    <lastBuildDate>Fri, 04 Sep 2026 10:50:47 GMT</lastBuildDate>
    <image><url>https://dukasim.com.tr/icon-192.png</url><title>Dukasim Blog</title><link>https://dukasim.com.tr/blog</link></image>
    <item>
      <title>Network Sistemlerinin Kullanım Alanları</title>
      <link>https://dukasim.com.tr/blog/network-sistemlerinin-kullanim-alanlari</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/network-sistemlerinin-kullanim-alanlari</guid>
      <pubDate>Thu, 03 Sep 2026 13:20:00 GMT</pubDate>
      <description>Kurumsal ağların bugün neden vazgeçilmez olduğuna ve network sistemlerinin işletmelere en çok fayda sağladığı altı alana kısaca göz atıyoruz.</description>
      <category>Network Çözümleri</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<p>Rekabetin arttığı her sektörde, işletmelerin teknolojiye dayalı, ölçeklenebilir altyapılara duyduğu ihtiyaç da aynı oranda büyüyor. Bu noktada network sistemleri, artık “olsa iyi olur” değil, günlük operasyonların üzerinde yükseldiği temel bir katman haline geldi. Dukasim olarak sahada en sık karşılaştığımız, network yatırımının en somut karşılığını verdiği altı alanı sizler için derledik.</p>
<h2 id="i̇şletme-i̇çi-ağ-altyapısı">İşletme İçi Ağ Altyapısı</h2>
<p>Kurum büyüklüğü ne olursa olsun, çalışanların dosya paylaşımı, ortak uygulamalara erişim ve departmanlar arası iletişim kurabilmesi sağlam bir iç ağa bağlı. Doğru planlanmış bir altyapı, hem donanım hem yazılım tarafında ileride yaşanacak tıkanıklıkların da önüne geçiyor.</p>
<h2 id="veri-merkezi-yönetimi">Veri Merkezi Yönetimi</h2>
<p>Büyüyen kurumlar için veri merkezinin güvenliği, sürekli erişilebilirliği ve performansı kritik önemde. Network katmanı, bu üç unsuru bir arada tutan görünmez omurga görevi görüyor.</p>
<h2 id="bulut-bilişim-hizmetleri">Bulut Bilişim Hizmetleri</h2>
<p>Depolama, işlem gücü ve uygulama sunumunu buluta taşıyan işletmeler için, o hizmetlerin arkasındaki ağ altyapısı en az bulut sağlayıcısının kendisi kadar belirleyici. Gecikmesiz ve güvenli bir bağlantı olmadan bulutun getirdiği esneklik de anlamını yitiriyor.</p>
<h2 id="uzaktan-erişim-ve-mobilite">Uzaktan Erişim ve Mobilite</h2>
<p>Saha ekipleri ya da hibrit çalışan personel için şirket kaynaklarına güvenli ve hızlı erişim artık standart bir beklenti. Network sistemleri, bu erişimi sağlayan uzaktan bağlantı ve mobil cihaz yönetimi çözümlerinin temelini oluşturuyor.</p>
<h2 id="güvenlik-ve-i̇zleme">Güvenlik ve İzleme</h2>
<p>Dış tehditlerin çeşitlendiği bir dönemde, güvenlik duvarları, erişim politikaları ve sürekli izleme araçları network mimarisinin ayrılmaz bir parçası. İyi kurgulanmış bir ağ, tehdidi engellemekle kalmıyor, aynı zamanda görünür kılıyor.</p>
<h2 id="video-ve-ses-i̇letişimi">Video ve Ses İletişimi</h2>
<p>Video konferans ve sesli görüşme altyapıları, ekipler arası işbirliğini kolaylaştırırken seyahat ve toplantı maliyetlerini de düşürüyor. Bu tür iletişim araçlarının kesintisiz çalışması, yine sağlam bir network omurgasına bağlı.</p>
<p>Dukasim olarak, her işletmenin farklı bir olgunluk seviyesinden ve farklı ihtiyaçlardan geldiğini biliyoruz. Bu yüzden network çözümlerimizi hazır bir paket olarak değil, sizin mevcut altyapınızı ve büyüme hedeflerinizi analiz ederek şekillendiriyoruz. Aklınıza takılan bir konu olursa, bize ulaşmaktan çekinmeyin.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Kurumsal IT Destek ve Help Desk Firması Nasıl Seçilir? 2026 Rehberi</title>
      <link>https://dukasim.com.tr/blog/kurumsal-it-destek-ve-help-desk-2026</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/kurumsal-it-destek-ve-help-desk-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:36:22 GMT</pubDate>
      <description>Türkiye'deki kurumların bir IT destek ortağı seçmeden önce karşılaştırması gerekenler.</description>
      <category>Kurumsal IT</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<p>Dışarıdan alınan IT destek hizmeti tek bir nedenle satın alınır: operasyonların kesintisiz sürmesini sağlamak. Bir barkod terminalinin ağ bağlantısını kaybetmesi nedeniyle duran bir üretim hattı ya da check-in sırasında fatura çıktısı alamayan bir otel resepsiyonu, teknik bir sorundan önce bir iş sorunudur. Bu bakış açısı, neyi karşılaştırmanız gerektiğini de değiştirir.</p>
<p>Türkiye’de kurumsal IT destek ve help desk hizmetleri için dört temel kriter söz konusudur:</p>
<ul>
<li><strong>On-site (yerinde) müdahale süresi</strong> — bir mühendisin her lokasyona fiziksel olarak ne kadar sürede ulaştığı ve bu sürenin sadece merkez ofis için değil, her saha için ayrı ayrı taahhüt edilip edilmediği.</li>
<li><strong>Uzaktan (remote) destek</strong> — saha ziyareti gerektirmeden çözülen olay oranı ve bunun arkasındaki araç seti.</li>
<li><strong>SLA kapsamı</strong> — mesai saatleri mi yoksa 7/24 mü, yanıt süresi ile çözüm süresinin ayrımı ve kapsam dışında kalan konular.</li>
<li><strong>Son kullanıcı help desk hizmeti</strong> — bir teknisyenin cep telefonu numarası yerine, ticket kayıtları tutan ve tanımlı bir escalation (yükseltme) sürecine sahip tek bir başvuru kanalı.</li>
</ul>
<p>Bu kriterler; çok lokasyonlu kurumlarda, hastaneler ve fabrikalar gibi paylaşımlı iş istasyonu ortamlarında ve eski sunucuların bulut hizmetleriyle bir arada bulunduğu karma altyapılarda en kritik hale gelir. Modern çalışma ortamı kapsamı da aynı değerlendirmenin parçası olmalıdır: Microsoft 365 yönetimi, Active Directory ve kullanıcı yaşam döngüsü (user lifecycle) yönetimi, endpoint ve cihaz desteği ile yapılandırılmış onboarding ve offboarding süreçleri.</p>
<p>Aşağıdaki bölümlerde hizmet modellerini, gereksinimlerin sektöre göre nasıl farklılaştığını, ihaleye eklemeniz gereken değerlendirme kriterlerini ve alıcıların sağlayıcıları karşılaştırırken en sık sorduğu soruları ele alıyoruz.</p>
<h2 id="temel-hizmet-modelleri-on-site-destek-uzaktan-destek-help-desk-ve-tam-kapsamlı-dış-kaynaklı-it-operasyonları">Temel hizmet modelleri: on-site destek, uzaktan destek, help desk ve tam kapsamlı dış kaynaklı IT operasyonları</h2>
<p>Kurumsal IT destek ve help desk hizmetlerine yönelik sözleşmelerin çoğu dört ayrı bloktan oluşur. İhaleye çıkmadan önce bu blokları birbirinden ayıran alıcılar, daha net bir kapsam, daha temiz bir fiyatlandırma ve daha az escalation anlaşmazlığı elde eder.</p>
<p>On-site destek, sahada müdahale anlamına gelir: donanım arızaları, yapısal kablolama (structured cabling) ve patch panel çalışmaları, switch ve access point değişimi, sunucu odası kontrolleri ve bir teknisyenin fiziksel olarak lokasyonda bulunması gereken her türlü olay. Bazı sağlayıcılar bu hizmeti planlı personel konuşlandırmasına kadar genişletir; eğitimli teknik personelin müşteri sahasında günlük, haftalık, aylık veya yıllık esaslarla konumlandırılması Türkiye pazarında yaygın bir uygulamadır ve hızlı bir yanıt penceresinden çok kalıcı bir saha varlığına ihtiyaç duyan kuruluşlara uygundur.</p>
<p>Uzaktan destek, ilk hat çözümünü üstlenir: işletim sistemi ve uygulama hataları, VPN ve erişim sorunları, yazıcı ve çevre birimi yapılandırmaları, yazılım güncellemeleri ile kullanıcı hesabı ve yetkilendirme talepleri gibi konular, doğru araç setiyle sahaya çıkmadan çözülür. Bu katmanın verimliliği iki ölçütle görülür: ilk temastan çözüme kadar geçen süre ve bir saha ziyareti gerektirmeden kapatılan olayların oranı. İyi kurgulanmış bir uzaktan destek katmanı, on-site ekibin yalnızca gerçekten fiziksel müdahale gerektiren durumlara yönlendirilmesini sağlayarak hem maliyeti hem de ortalama çözüm süresini aşağı çeker.</p>
<p>Help Desk, kullanıcıya bakan giriş katmanıdır ve genellikle en çok yanlış anlaşılan bileşendir. İşlevi teknik çözüm üretmek değil, gelen talebi doğru şekilde karşılamaktır: ticket’ın alınması, önceliklendirilmesi, kullanıcıyla düzenli iletişim kurulması ve talebin kapanana kadar takip edilmesidir. Tek bir başvuru noktası olmadan, aynı sorun farklı kişilere farklı kanallardan iletilir, önceliklendirme öznel hale gelir ve hangi taleplerin ne zaman çözüldüğüne dair kurumsal bir kayıt oluşmaz. Olgun bir help desk yapısı; standart bir bilet açma süreci, tanımlı önceliklendirme kuralları, kullanıcıya durum güncellemesi sağlayan bir iletişim akışı ve talebin kapanışına kadar sorumluluğun net biçimde izlenebildiği bir takip mekanizması içerir.</p>
<p>Bu üç katmanın üzerine, bazı kurumlar tam kapsamlı dış kaynaklı IT operasyonları modelini tercih eder. Bu model; endpoint yönetimini, Microsoft 365 ortamının idaresini, Active Directory üzerinden kullanıcı ve yetkilendirme yönetimini ve çok katmanlı escalation süreçlerini tek bir çatı altında birleştiren daha geniş bir yapıdır. Amaç, günlük olay çözümünün ötesine geçip kullanıcı yaşam döngüsünün, kimlik yönetiminin ve cihaz filosunun sürekli ve tutarlı biçimde yönetilmesidir. Karma altyapıya sahip kurumlarda — yani farklı üreticilerden ağ ekipmanı, sunucu, uç nokta cihazı ve yazılımın bir arada bulunduğu ortamlarda — üretici bağımsız (multi-vendor) destek verebilme yeteneği özellikle önem kazanır; çünkü tek bir marka veya platforma bağlı bir destek modeli, karma bir ortamda kaçınılmaz olarak kapsam boşlukları bırakır. Bununla birlikte her kurumun bu genişlikte bir modele ihtiyacı yoktur: bazı kuruluşlar için dar kapsamlı, olay bazlı bir destek sözleşmesi yeterliyken, dağıtık lokasyonlara ve karmaşık kimlik/erişim yapısına sahip kurumlar için daha geniş, yönetilen bir hizmet modeli daha sürdürülebilir bir seçenek olur. Doğru karar, mevcut altyapının karmaşıklığına ve iç IT ekibinin kapasitesine bağlıdır.</p>
<h2 id="sektöre-göre-değişen-destek-ihtiyaçları">Sektöre göre değişen destek ihtiyaçları</h2>
<p>IT destek ihtiyaçları sektörden sektöre önemli ölçüde farklılaşır ve bu farklılık bir pazarlama söylemi değil, müdahale tasarımına, ekip yapısına ve destek saatlerine somut biçimde yansıması gereken bir gerçekliktir. Bir sağlayıcının “sektöre uygunluğu” iddiası, ancak bu unsurlarda görülebiliyorsa anlamlıdır.</p>
<p>Üretim tesislerinde önceliğin başında tesis kesintisizliği gelir; bir hattın veya bir barkod/terminal sisteminin durması doğrudan üretim kaybına dönüşür. Bu nedenle vardiya kapsamının üretim saatleriyle örtüşmesi, sahadaki ağ altyapısının (switch, access point, kablolama) dayanıklılığı ve bir olay büyüdüğünde hızlı escalation mekanizmasının işlemesi kritik hale gelir.</p>
<p>Otelcilik sektöründe süreklilik beklentisi resepsiyon operasyonundan misafir deneyimine uzanır. Check-in/check-out sistemlerinin kesintisiz çalışması, misafir ağının (guest Wi-Fi) stabil olması, oda içi ve ortak alan cihazlarının desteklenmesi ve mesai dışı saatlerde — özellikle gece ve hafta sonu — müdahale edilebilmesi bu sektörde belirleyici unsurlardır.</p>
<p>Sağlık kuruluşlarında öncelik farklı bir eksene kayar: kullanıcı erişim kontrolünün sıkı biçimde yönetilmesi, endpoint cihazların güvenilirliği, hassas sistemlerin güvenli biçimde yönetilmesi ve destek kapsamının belirsizlik taşımaması. Sağlık ortamlarında öngörülebilir bir destek kapsamı — hangi olayın ne kadar sürede ve kim tarafından karşılanacağının net olması — operasyonel güven açısından diğer sektörlere kıyasla daha ağır basar.</p>
<p>Kamu kurumlarında ise dokümantasyon disiplini, escalation adımlarının net biçimde tanımlanmış olması, hizmetin izlenebilirliği (raporlama ve kayıt tutma) ve genellikle eski sistemlerle modern altyapının bir arada bulunduğu karma ortamlara destek verebilme yeteneği öne çıkar. Bu tür ortamlarda bir sağlayıcının hem güncel hem de eski nesil sistemlere aynı anda hâkim olması beklenir.</p>
<p><strong>Bu farklılıkların pratik sonucu şudur:</strong> bir sağlayıcıyı değerlendirirken sektörünüze “uygun” olduğunu söyleyen genel ifadeler yerine, o sağlayıcının müdahale tasarımının, ekip yapısının ve destek saatlerinin sizin operasyonel gerçekliğinizle nasıl örtüştüğünü somut olarak sorgulamak gerekir.</p>
<h2 id="it-destek-sağlayıcısı-değerlendirme-kontrol-listesi">IT destek sağlayıcısı değerlendirme kontrol listesi</h2>
<p>Bir IT destek ve help desk sağlayıcısını karşılaştırırken kullanılabilecek pratik bir kontrol listesi, ihale sürecini önemli ölçüde netleştirir. Aşağıdaki maddeler, teklif değerlendirmesinde sorulması gereken temel sorulardır:</p>
<ul>
<li><strong>Müdahale süreleri:</strong> Yanıt ve çözüm süreleri olay tipine (kritik/önemli/düşük öncelikli) ve kanala (on-site, uzaktan, help desk) göre ayrı ayrı tanımlanmış mı, yoksa tek bir genel süre mi verilmiş?</li>
<li><strong>Kapsam saatleri:</strong> Destek mesai saatleriyle mi sınırlı, mesai dışı ve hafta sonu için ayrı bir kapsam var mı, resmi tatillerde hizmet nasıl işliyor?</li>
<li><strong>Onboarding/offboarding desteği:</strong> Yeni çalışan işe başlarken hesap ve cihaz hazırlığı, çalışan ayrılırken erişim kaldırma süreçleri sağlayıcının kapsamında mı, yoksa yalnızca iç ekibin sorumluluğunda mı bırakılıyor?</li>
<li><strong>Cihaz desteği kapsamı:</strong> Dizüstü ve masaüstü bilgisayarlar, yazıcılar, ortak kullanılan iş istasyonları ve mobil uç noktalar destek kapsamına dahil mi, yoksa yalnızca belirli cihaz tiplerine mi sınırlı?</li>
<li><strong>Escalation sürecinin netliği:</strong> Bir olay ilk hatta çözülemediğinde hangi adımların, hangi sürede ve kime yükseltileceği yazılı olarak tanımlanmış mı?</li>
<li><strong>SLA raporlama ve ticket görünürlüğü:</strong> Kurumun açık/kapalı ticket’ları, ortalama çözüm sürelerini ve SLA performansını gerçek zamanlı veya periyodik olarak görebileceği bir raporlama mekanizması sunuluyor mu?</li>
<li><strong>Microsoft 365 ve Active Directory yönetimi:</strong> Sağlayıcı bu alanda Microsoft Solutions Partner statüsüne sahip mi ve bu yönetimi cihaz/endpoint yönetimiyle birlikte, entegre bir hizmet olarak mı sunuyor, yoksa bu konu kapsam dışında mı bırakılıyor? Bu, özellikle geniş kapsamlı bir dış kaynak modeli arayan kurumlar için sorulması gereken bir seçim kriteridir.</li>
</ul>
<p>Bu listedeki her madde, teklif aşamasında yazılı olarak teyit edilmeli; sözlü taahhütler yerine sözleşme metnine yansıyan somut ifadeler aranmalıdır.</p>
<h2 id="microsoft-365-active-directory-ve-endpoint-desteğinde-dikkat-edilmesi-gerekenler">Microsoft 365, Active Directory ve Endpoint Desteğinde Dikkat Edilmesi Gerekenler</h2>
<p>Bu başlık ana değerlendirme ekseni olmasa da, modern kurumsal ortamlarda göz ardı edilmemesi gereken bir alt bileşendir. Değerlendirilmesi gereken temel noktalar şunlardır: kullanıcı hesabının açılışından kapanışına kadar tüm yaşam döngüsünün (account lifecycle) yönetilip yönetilmediği, mailbox erişiminin doğru ve zamanında sağlanıp sağlanmadığı, lisans koordinasyonunun (kimin hangi Microsoft 365 lisansına sahip olduğunun) düzenli takip edilip edilmediği ve kimlik/erişim/provizyonlama kontrollerinin tutarlı biçimde uygulanıp uygulanmadığı. Dağıtık, çok lokasyonlu kuruluşlarda endpoint yönetiminin merkezi bir politika altında yürütülmesi beklenir; aksi halde her lokasyon kendi cihaz standardını oluşturur ve güvenlik boşlukları doğar. Onboarding ve offboarding süreçleri de bu alanla doğrudan bağlantılıdır: bir çalışan ayrıldığında erişimlerin zamanında kaldırılması, yeni bir çalışan başladığında cihazın ve hesabın hazır olması, hem güvenlik hem de operasyonel süreklilik açısından kritik bir kontrol noktasıdır. Bu hizmetleri değerlendiren kurumların, sağlayıcının bu alanda Microsoft Solutions Partner statüsüne veya eşdeğer belgelenmiş bir yetkinliğe sahip olup olmadığını doğrulaması önerilir — ancak bu tür bir etiketin tek başına operasyonel uyumun kanıtı sayılmaması, sözleşme kapsamının ve süreçlerin ayrıca teyit edilmesi gerektiği unutulmamalıdır.</p>
<p>Kurumsal IT destek ihtiyaçlarını değerlendiren kuruluşlar için altyapı tarafındaki temel yapı taşları — ağ güvenliği, network altyapısı, sunucu ve depolama sistemleri, veri merkezi çözümleri ve yapısal kablolama — hizmetin sürdürülebilirliğini doğrudan etkiler. Dukasim, bu alanlarda edindiği network, sistem ve BT altyapısı deneyimini teknik destek ve entegrasyon yetkinlikleriyle bir araya getirerek, kurumların altyapı ve destek ihtiyaçlarına bütünleşik bir yaklaşımla bakabilmelerine katkı sağlar. Altyapınızı ve destek gereksinimlerinizi birlikte değerlendirmek için Dukasim ile iletişime geçebilirsiniz.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Kurumsal Kablolama ve Network Kurulumunu Tek Ekipte Nasıl Planlarsınız?</title>
      <link>https://dukasim.com.tr/blog/kurumsal-kablolama-ve-network-kurulumu</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/kurumsal-kablolama-ve-network-kurulumu</guid>
      <pubDate>Thu, 03 Sep 2026 09:36:22 GMT</pubDate>
      <description>Kurumsal kablolama ve network kurulumunu tek ekipte planlamak neden önemlidir?</description>
      <category>Network Altyapısı</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<p>Yeni bir bina, fabrika ya da veri merkezi devreye alınırken en sık yaşanan sorun teknik değil, organizasyoneldir: kablolamayı bir taşeron, aktif cihazları başka bir ekip, güvenlik ve kamera tarafını üçüncü bir firma üstlendiğinde sorumluluk dağılır. Kanal ve priz montajı biterken switch konfigürasyonu beklemeye girer, test raporları farklı formatlarda gelir, arıza çıktığında hangi tarafın kapsamında olduğu tartışılır. Sonuç genellikle devreye alma gecikmesi ve teslimde belirsizliktir.</p>
<p>Yapısal kablolama ve BT entegrasyonu yaklaşımı bu dağınıklığı tek plan altında toplar: pasif altyapı (kanal, priz, bakır ve fiber hatlar), kabinet ve rack yerleşimi, aktif network kurulumu, ölçüm–test kayıtları ve kabul süreci aynı proje takviminde ilerler. Sektörde birçok sağlayıcı yalnızca kablolamaya veya yalnızca aktif tarafa odaklanır; kurumsal alıcının ihtiyacı ise ikisinin aynı sorumluluk çatısında birleşmesidir.</p>
<p>Kurumsal projelerde tercih edilen tek ekip modelinde; yeni bina ve fabrika altyapısı kurulumu, veri merkezi kurulum ve taşıma projeleri, ofis taşınması sonrası yeniden kablolama ve network devreye alma çalışmaları aynı sorumluluk çatısı altında yürütülebilir. Dukasim de bu alanda hizmet veren, benzer proje deneyimine sahip firmalardan biri olarak konumlanıyor.</p>
<p>İlerleyen bölümlerde kablolama standartları, fiber hatlar ve OTDR testleri, rack kurulumu, network devreye alma, veri merkezi taşıma senaryoları ve hangi projede tek ekipli teslimin doğru tercih olduğunu gösteren bir karar rehberi ele alınıyor. Odak noktası üç başlıkta toplanıyor: operasyon sürekliliği, ölçülebilir test kanıtı ve disiplinli teslim.</p>
<h2 id="kurumsal-yapısal-kablolama-ve-fiber-optik-kablolama-hangi-kapsamı-içerir">Kurumsal yapısal kablolama ve fiber optik kablolama hangi kapsamı içerir?</h2>
<p>Pasif altyapı, bir ağ projesinin en uzun ömürlü katmanıdır: anahtar ve güvenlik duvarı donanımı yenilense de güzergâh, kanal ve sonlandırma yerinde kalır. Bu nedenle kapsam, “kablolama yapılacak” gibi genel bir ifadeyle değil, teslim kalemleri düzeyinde tanımlanmalıdır.</p>
<h3 id="yapısal-kablolama-kapsamı">Yapısal kablolama kapsamı</h3>
<p>Kablo tavası ve güzergâh planı, priz noktalarının konumlandırılması, patch panel yerleşimi, standartlara uygun sonlandırma ve her iki uçta etiketleme temel kalemlerdir. Senaryo kapsamı değiştirir: ofis katında nokta yoğunluğu, fabrikada mesafe, mekanik koruma ve elektromanyetik girişim, kampüste binalar arası omurga, çok katlı binada dikey omurga ile kat dağıtım odaları öne çıkar.</p>
<h3 id="fiber-optik-kablolama">Fiber optik kablolama</h3>
<p>Indoor fiber çekimi, bina ve kat arası omurga, fiber sonlandırma, ODF yerleşimi ile patch kordon planlaması ayrı teslim kalemleridir. Sektörde birçok sağlayıcı fiber planlama, indoor fiber kablolama, sonlandırma ve ölçüm-raporlama adımlarını ayrı başlıklar olarak tanımlarken; kablo tavası, priz, UTP/fiber kablolama, kabinet ve pano işlerini tek bir proje kapsamında birlikte ele alır. Bu yaklaşım, kablolamanın yalnızca çekim işi olmadığını, planlama ve ölçüm gerektiren bir süreç olduğunu gösterir.</p>
<h3 id="otdr-testi-ve-kabul-ölçümleri">OTDR testi ve kabul ölçümleri</h3>
<p>Bakır hatlarda link/kanal testi, fiberde OTDR ölçümü ile ek ve konnektör kayıpları, toplam zayıflama ve mesafe kayıt altına alınır. Bu raporlar kabul sürecinin kanıtıdır; arıza anında referans değer olmadan sorunun kablodan mı cihazdan mı geldiği tartışmalı kalır.</p>
<h3 id="kabinet-ve-sistem-odası-kurulumu">Kabinet ve sistem odası kurulumu</h3>
<p>Rack yerleşimi, U planı, güç ve kesintisiz güç kaynağı beslemesi, kablo yönetimi, havalandırma ve topraklama bu başlığın kapsamındadır. Veri merkezi ve sistem odası tarafında erişim kontrolü ile ortam izleme de aynı projeye dahil edilebilir.</p>
<h3 id="devreye-alma-ve-büyümeye-zemin">Devreye alma ve büyümeye zemin</h3>
<p>Yapısal kablolama ve BT entegrasyonu aynı ekipte planlandığında yedek port kapasitesi, PoE bütçesi ve VLAN segmentasyonu daha kurulum aşamasında hesaplanır; çok lokasyonlu yapılarda ikinci faz genişlemeler bu sayede yeniden kablolama gerektirmez.</p>
<h2 id="fiber-optik-kablolama-ve-otdr-testinden-hangi-teslim-kanıtları-beklenmelidir">Fiber optik kablolama ve OTDR testinden hangi teslim kanıtları beklenmelidir?</h2>
<p>Fiber işleri ışığın geçtiği gerçeğine değil, ölçüm sonuçlarına göre kabul edilir. Bir OTDR (optik zaman domenli reflektometre) ölçümü; hat boyunca kayıp bütçesini, her ek ve konnektör noktasındaki konum ve kayıp değerini, herhangi bir anomaliye olan mesafeyi ve fiberin uçtan uca kesintisiz olup olmadığını gösterir. Ölçüm yöne bağlı olduğundan, her iki çalışma dalga boyunda çift yönlü sonuçlar ile doğrulayıcı yöntem olarak ışık kaynağı ve güç ölçer kullanılan ekleme kaybı (insertion loss) testi talep edilmelidir.</p>
<p>Bu ölçüm ve raporlama çıktıları teknisyenin bilgisayarında değil, kabul dosyasında yer almalıdır. Kullanılabilir bir dosya; ham sonuç dosyalarını, uygulanan test limitini, kullanılan başlangıç ve bitiş jumper detaylarını, cihazın kalibrasyon tarihini, test tarihini ve teknisyen adını içerir — bu, bakır sertifikasyon raporlarında aranan denetlenebilirlikle aynıdır; burada da bir “GEÇTİ” sonucu ancak kullanılan limit, adaptör ve hat modeliyle birlikte anlam kazanır.</p>
<p>Indoor fiber hatları da binalar veya katlar arasındaki omurga kadar titiz test edilmelidir. Testi atlanan kısa bir dikey omurga bağlantısı, iki yıl sonra kimsenin yerini bulamadığı bir arıza noktasına dönüşebilir.</p>
<p>Sonuçlar ancak etiketleme ve port eşleştirmesiyle uyumlu olduğunda işe yarar: fiber kimliği, panel, port ve sonlandığı kabinet çizimlerle eşleşmelidir. Bu şekilde teslim edildiğinde, yapısal kablolama ve BT entegrasyonu yalnızca kurulu malzeme değil, doğrulanabilir performans sunmuş olur.</p>
<h2 id="rack-kurulumu-ve-network-devreye-alma-tek-iş-akışı-olarak-nasıl-yürütülür">Rack kurulumu ve network devreye alma tek iş akışı olarak nasıl yürütülür?</h2>
<p>Yeni bir fabrika salonunda, hastane biriminde veya çok lokasyonlu bir yaygınlaştırma projesinde kabinet, pasif altyapı ile aktif network’ün fiziksel olarak buluştuğu noktadır — bu nedenle iki takvim de aynı plan üzerinde çizilmelidir. Rack çalışması; kabinetin sistem odasındaki konumunun belirlenmesini, rack unit dağılımını, kesintisiz güç kaynağı bulunan ortamlarda ayrı beslemelerle güç dağıtımının boyutlandırılmasını, dikey ve yatay kablo yönetiminin düzenlenmesini ve patch panellerin kabloların geldiği sıraya göre değil, kat planına göre sıralanmasını kapsar. Fiber dağıtım panelleri (ODF), switch yığınları ve hava akışı boşlukları aynı yerleşimde, yedek kapasite ayrılarak konumlandırılır.</p>
<p>Devreye alma bu çatı üzerinde başlar: switch ve router konfigürasyonu, kablosuz kontrolör ve erişim noktası ayarları, üretim, ofis, kamera ve misafir trafiğini ayıran VLAN segmentasyonu ile yönetim erişim kontrolü, port güvenliği, firewall politikası ve 5651 log yönetimi gibi temel güvenlik önlemleri.</p>
<p>Sektör pratiğinde bu birleşik model sıkça uygulanır: proje tasarımı, kablo tavaları, prizler, bakır ve fiber kablolama, kabinetler, paneller ve cihaz kurulumu tek kapsam olarak ele alınır; kesintiyi düşük tutmak için aşamalı, mesai dışı geçiş planlaması ise her teklif verenden aranması gereken bir disiplindir.</p>
<p>İki sözleşme ayrıldığında hata noktası neredeyse her zaman dokümantasyondadır: port haritasıyla eşleşmeyen etiketler, görsel olarak sorunsuz görünen ama OTDR kayıp bütçesini geçemeyen fiber hatlar ve birbirini suçlayan iki ekip. Sınırı yazılı olarak belirleyin: kurulum, konfigürasyon, sertifikalı test raporlarıyla test, ardından etiketleme şeması ve as-built çizimlere göre ilk kabul.</p>
<h2 id="veri-merkezi-taşıma-ve-yeniden-kablolama-için-proje-akışı-nasıl-planlanır">Veri merkezi taşıma ve yeniden kablolama için proje akışı nasıl planlanır?</h2>
<p>Bir veri merkezi taşıma projesi nadiren kablo kalitesinden dolayı başarısız olur; genellikle sıralamadan dolayı başarısız olur. Beş aşama, ilk kayıttan bakım devrine kadar çalışmayı denetlenebilir kılar.</p>
<ol>
<li>
<p><strong>Keşif.</strong> Herhangi bir teklif verilmeden önce her iki katman da envanterlenmelidir: kabinet ve rack yerleşimleri, patch panel ve port haritaları, bakır ve fiber hatlar, switch, router ve firewall konfigürasyonları, uplink’ler ve internet hatları. Ardından bağımlılıklar haritalanır — hangi sunucunun ERP, sanallaştırma, yedekleme ve telefon sistemini taşıdığı belirlenir ve her biri için kabul edilebilir kesinti penceresi kayıt altına alınır. Bir fabrikada veya yeni binada bu pencereler BT tercihinden değil, vardiya programlarından ve üretim hatlarından belirlenir.</p>
</li>
<li>
<p><strong>Planlama.</strong> İş sırası netleştirilir, kablolar, paneller, portlar ve kabinetler için tek bir etiketleme standardı benimsenir (ANSI/TIA-606 tabanlı bir şema yaygın referanstır), geçiş planı sistem sistem, geri dönüş (rollback) yolu ile birlikte yazılır, tek bir patch kablo bile çekilmeden önce yedekler doğrulanır ve sorumluluk entegratör, kurum içi BT ve iş birimi sahipleri arasında açıkça paylaştırılır. Aşamalı veya mesai dışı geçiş burada planlanır, sahada doğaçlama yapılmaz.</p>
</li>
<li>
<p><strong>Uygulama.</strong> Gereksiz hatlar devre dışı bırakılır, yeni yapısal kablolama tavalar ve kanallar üzerinden çekilir, kabinet yerleşimleri güç, soğutma ve kablo yönetimi etrafında kurulur, ardından aktif cihazlar yerleştirilip konfigüre edilir ve hizmetler grup grup taşınır.</p>
</li>
<li>
<p><strong>Test.</strong> Bakır kalıcı hatlar sertifikalandırılır, ekleme kaybı ve OTDR ölçümleriyle fiber optik test yapılır ve raporlar arşivlenir, port bazında bağlantı durumu ve VLAN segmentasyonu doğrulanır, ardından hizmet sürekliliği teyit edilir: ERP, çağrı merkezi, kameralar ve güvenlik sisteminin tamamının yanıt verdiği kontrol edilir.</p>
</li>
<li>
<p><strong>Teslim.</strong> As-built çizimler, port ve kablo şemaları, IP ve VLAN planları, test raporları, aşama bazlı kabul tutanakları, garanti ve SLA koşulları teslim edilir.</p>
</li>
</ol>
<h2 id="pasif-altyapı-ile-aktif-network-kurulumu-birlikte-ne-zaman-tercih-edilmelidir">Pasif altyapı ile aktif network kurulumu birlikte ne zaman tercih edilmelidir?</h2>
<p>Birlikte teslim, pasif ve aktif katmanın aynı takvimde birbirine bağımlı olduğu işlerde anlam kazanır: yeni bina, yeni fabrika, kampüs yerleşkesi ve veri merkezi kurulumları. Bu projelerde kablo güzergâhı, kabinet yerleşimi, patch panel–switch port eşleşmesi, PoE bütçesi ve fiber omurga kapasitesi tek tasarımda çözülür; korunması gereken çalışan bir ağ olmadığı için belirleyici kriter kesinti değil, teslim süresidir.</p>
<p>Karar verirken şu beş başlığı ayrı ayrı puanlayın:</p>
<ul>
<li><strong>Mevcut altyapıyla uyum:</strong> Kablolama sınıfı ve aktif cihaz mimarisi birlikte değişecekse bütünleşik model, sadece cihaz yenileniyorsa ayrık model uygundur.</li>
<li><strong>Kesinti toleransı:</strong> Üretim, otel veya hastane gibi 7/24 ortamlarda geçiş aşamalı ve mesai dışı planlanmalı, sorumluluk tek ekipte toplanmalıdır.</li>
<li><strong>Teslim süresi:</strong> İnşaat takvimine bağlı işlerde kablolama ve devreye alma paralel yürütülemiyorsa süre uzar.</li>
<li><strong>Bakım ve SLA modeli:</strong> Arıza anında ölçüm raporu, konfigürasyon ve saha müdahalesi aynı sözleşmede mi toplanacak?</li>
<li><strong>Kabul süreci:</strong> Sertifikalı test raporları, VLAN/segmentasyon dokümanı ve as-built çizimlerin tek elden teslimi.</li>
</ul>
<p>Sektörde bu bütünleşik yaklaşımın örnekleri yaygındır; aktif ve pasif network bileşenleri sistem odası tasarımıyla birlikte ele alınır ve SLA kapsamında saha desteği sunulur.</p>
<p>Ayrık teslim ise mevcut kablolamanın korunacağı yenilemelerde, bütçenin yıllara yayıldığı aşamalı yatırımlarda ve farklı tedarikçi zorunluluğu bulunan ihalelerde daha gerçekçidir. Kararı fiyat farkına değil, arıza anında sorumluluğun kimde olduğuna ve kabul testlerinin nasıl belgeleneceğine göre verin.</p>
<h2 id="hangi-sektörlerde-bu-model-daha-uygundur-ve-teslimde-neler-verilmelidir">Hangi sektörlerde bu model daha uygundur ve teslimde neler verilmelidir?</h2>
<p>Hangi sektörlerde bu model daha uygundur? Tek ekipten yürütülen yapısal kablolama ve BT entegrasyonu, uç sayısı yüksek ve kesinti maliyeti ağır olan ortamlarda anlamlıdır: yeni kurulan fabrikalar, hastaneler, oteller, çok lokasyonlu şube ve perakende ağları, kamu kurumları ve veri merkezi projeleri. Tek kat, sınırlı sayıda prizi olan küçük ofislerde ayrı yükleniciler de yeterli olabilir; bu modelin farkı, pasif altyapı ile aktif network kurulumunun aynı takvimde ilerlemesidir.</p>
<p>Hangi ekipmanlar gerekir? Bakır ve fiber kablo, kablo tavası, rack kabinetler, patch panel ve patch kablolar, fiber sonlandırma malzemeleri (pigtail, ek kaseti, ODF); aktif tarafta switch, router, firewall ve kablosuz erişim noktaları. Buna etiketleme sistemi, kablo test cihazı ve fiber ölçüm ekipmanı eklenir.</p>
<p>Test ve teslimde ne verilmelidir? Kanal/link test raporları ve fiber ölçüm çıktıları, kabinet bazlı port listeleri, kalıcı kablo etiketleri, kat ve kabinet yerleşim şemaları, imzalı kabul dokümanı, konfigürasyon yedekleri ile bakım ve garanti notları.</p>
<p>Saha uygulamaları bu bileşenlerin tek projede birleşebildiğini gösteriyor: fabrika ölçekli projelerde ağ kurulumu, sunucu ve yedekleme altyapısı, kamera ve alarm sistemleri ile yerinde destek sıklıkla aynı çalışma kapsamında yürütülüyor.</p>
<p>Teklifleri karşılaştırırken kapsam sınırlarını, test yöntemini ve destek/SLA maddelerini yazılı isteyin.</p>
<p>Kurumunuzun mevcut altyapısını bu başlıklar üzerinden değerlendirmek isterseniz, ihtiyaç analizi görüşmesi için Dukasim ekibiyle iletişime geçebilirsiniz.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Network Health Check Nedir? Packet Loss, Darboğaz ve Ağ Performans Analizi – 2026 Rehberi</title>
      <link>https://dukasim.com.tr/blog/network-health-check-2026</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/network-health-check-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:36:22 GMT</pubDate>
      <description>Network Health Check'in packet loss, darboğaz ve ağ performansı sorunlarını nasıl görünür hale getirdiğini inceliyoruz.</description>
      <category>Network Analizi</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<h2 id="network-health-check-nedir-ve-hangi-problemi-çözer">Network Health Check Nedir ve Hangi Problemi Çözer?</h2>
<p>Network health check (ağ sağlık kontrolü), bir kurumsal ağın mevcut durumunu ölçen ve zayıf noktalarını görünür kılan yapılandırılmış bir değerlendirmedir — bir şey bozulduktan sonra yapılan onarım çağrısı değildir. Bu çalışma iki ayrı katmandan oluşur ve bu ikisini birbirine karıştırmak, tekrarlayan arızaların sürekli geri gelmesinin en yaygın nedenidir.</p>
<p><strong>Performans analizi semptomlara bakar:</strong> belirli bir segmentteki paket kaybı, yükselen gecikme (latency) ve jitter, yeniden gönderimler (retransmission), doygun uplink’ler, yük altında düşen kablosuz hücreler. Kök neden araştırması ise bu sayıların neden ortaya çıktığını sorar — bir dupleks uyuşmazlığı, aşırı abone olmuş bir switch uplink’i, bir spanning-tree topoloji değişikliği, aşırı yüklenmiş bir firewall oturum tablosu veya ağ izleme verileriyle ancak sonradan fark edilen bir DHCP/IP adresleme hatası. Kök neden çalışması olmadan yapılan ölçüm bir rapor üretir; ikisi birlikte ise kalıcı olan bir çözüm üretir.</p>
<p>Kapsam genellikle LAN ve WAN bağlantılarını, kablolu ve kablosuz segmentleri, switch ve router yapılandırmasını, firewall sistemlerini, DHCP/IP servislerini, ağ izleme altyapısını ve sunucu ile depolama birimlerine giden bağlantı yollarını kapsar. Birden fazla lokasyonda, üretim hattında, otelde veya hastanede faaliyet gösteren kurumlar için bu, hizmet seviyesi anlaşması (SLA) açısından doğrudan önem taşır: ölçülmeyen bozulma kesintiye, kesinti de iş sürekliliği ve kullanıcı deneyimi sorununa dönüşür.</p>
<p>Türkiye’de birçok sağlayıcı kurulum ve arıza giderme çalışmalarını iyi belgelemektedir; örneğin vendor’a bağlı entegratörler switch, router, access point ve firewall kurulumunu trafik analiziyle birlikte anlatır. Değerlendirme (assessment) ise farklı bir disiplindir. İlerideki bölümler uyarı işaretlerini, analiz akışını, bir alıcının beklemesi gereken teslimatları ve tekrarlayan soruları ele almaktadır.</p>
<h2 id="packet-loss-latency-ve-kesinti-tekrarı-hangi-i̇şaretleri-verir">Packet Loss, Latency ve Kesinti Tekrarı Hangi İşaretleri Verir?</h2>
<p>Kullanıcı tarafında tek bir cümle duyulur: “Ağ yavaş.” Ölçüm tarafında ise bu şikâyet en az üç ayrı metriğe dağılır. Paket kaybı, çağrı merkezi ve VoIP trafiğinde kelime kopmaları, ekran paylaşımında donma olarak hissedilir. Gecikme (latency), uzak veri merkezindeki ERP ekranlarının geç açılmasıyla; jitter ise bant genişliği yeterliyken dalgalanan ses ve görüntü kalitesiyle kendini gösterir. Aynı şikâyet, uçtan uca prob testleri, iperf ölçümleri ve switch portlarındaki CRC/discard sayaçları birlikte okunduğunda farklı kaynaklara işaret edebilir.</p>
<p><strong>Darboğaz belirtileri:</strong> yoğun saatlerde sürekli dolu kalan uplink, hız/dupleks uyuşmazlığı yaşayan portlar, tek bir yayın alanına sıkışmış hatalı VLAN tasarımı, yedekleme trafiğinin üretim trafiğiyle aynı hattı paylaşması. Kullanıcı bunu “switch yavaşladı” diye bildirir; akış verisi (NetFlow/sFlow) hattı hangi uygulamanın doldurduğunu gösterir.</p>
<p><strong>Tekrarlayan kesintiler:</strong> çoğu zaman arızalı cihazdan değil; spanning-tree topoloji değişimlerinden, ikinci bir DHCP sunucusundan, asimetrik yönlendirmeden, standart dışı veya gevşek kablolamadan, ısınan modüllerden kaynaklanır.</p>
<p><strong>Segment farkı:</strong> kablolu tarafta kararsızlık port flapping, artan hata sayaçları ve tek bir kat/oda ile sınırlı şikâyet biçiminde görünür. Kablosuz tarafta ise kanal doluluğu, düşük sinyal-gürültü oranı, yüksek yeniden gönderim oranı, komşu erişim noktası girişimi ve roaming sorunları olarak ortaya çıkar; kullanıcı “sadece toplantı odasında kopuyor” der.</p>
<p>Bu işaretlerin hiçbiri tek başına teşhis değildir. Yapılandırılmış bir network health check ve performans analizi, semptomu SNMP sayaçları, akış verisi, kablosuz saha ölçümü ve log korelasyonuyla eşleştirir. Ölçüm olmadan alınan karar, çoğu zaman gereksiz donanım yatırımıyla sonuçlanır.</p>
<h2 id="kurumsal-ağ-performans-değerlendirmesi-nasıl-yürütülür">Kurumsal Ağ Performans Değerlendirmesi Nasıl Yürütülür?</h2>
<p>Güvenilir bir network health check ve performans analizi tek bir saha ziyaretinden ibaret değildir — her biri kendi çıktısına sahip beş aşamadan geçer. Türkiye’deki danışmanlık firmalarını karşılaştırırken pratik test basittir: her adımdan hangi teslimatın çıktığını sormak.</p>
<ol>
<li>
<p><strong>Keşif.</strong> Mevcut topoloji, belgelenmiş olanla karşılaştırılarak haritalanır: cihaz envanteri (switch, router, access point, firewall), VLAN ve yönlendirme tasarımı, WAN ve internet bağlantıları ve trafik akışları. Kritik bağımlılıklar burada listelenir — ERP ve veritabanı trafiği, iletişim ve çağrı merkezi sistemleri, kamera ve görüntü sistemleri ve bunları taşıyan veri merkezi veya şube bağlantıları.</p>
</li>
<li>
<p><strong>Ölçüm.</strong> Gecikme, jitter, paket kaybı, uplink başına bant genişliği kullanımı, arayüz hata ve discard sayaçları ile kablosuz kapsama ve sinyal kalitesi; izlenime göre değil ölçüm araçlarıyla belirlenir. Ölçüm tam bir iş döngüsünü kapsamalıdır — vardiya değişimleri, ay sonu kapanışı, yedekleme pencereleri — çünkü doygunluk sakin bir öğleden sonrasında nadiren ortaya çıkar.</p>
</li>
<li>
<p><strong>Analiz.</strong> Bulgular semptom, kök neden ve etkilenen kapsam olarak ayrılır. “Uygulama yavaş” ifadesi; bir dupleks uyuşmazlığına, aşırı abone olmuş bir uplink’e, DHCP/IP adresleme hatalarına, ağ izleme sisteminin geç yakaladığı bir servis arızasına, baskı altındaki bir firewall oturum tablosuna veya bozulmuş yapısal kablolamaya kadar gidebilir. Bu ayrım yapılmadan yürütülen iyileştirme, arızayı değil alarmı tedavi eder.</p>
</li>
<li>
<p><strong>İyileştirme planı.</strong> Aksiyonlar risk ve efora göre önceliklendirilir: kısa vadeli yapılandırma düzeltmeleri, segment yeniden tasarımı veya Cat6/fiber yenilemesi gibi orta vadeli çalışmalar ve bütçe döngülerine bağlı uzun vadeli kapasite ve veri merkezi yatırımları.</p>
</li>
<li>
<p><strong>Doğrulama.</strong> Aynı metrikler aynı yöntemle yeniden ölçülür ve öncesi/sonrası farkı raporlanır.</p>
</li>
</ol>
<p>Bölgesel sağlayıcılar bu aşamalara farklı ağırlık verir. Vendor’a bağlı entegratörler ve yerel hizmet sağlayıcılar genellikle switch, router, access point ve firewall kurulumunu trafik analiziyle birlikte belgeler ve barındırdıkları sunucular için sürekli izleme ve raporlama sunar — hizmet bölgeleri içinde güçlü saha kapsamı sağlarlar. Çok lokasyonlu kurumlar için Dukasim, çalışmasını denetim raporu, risk listesi ve önceliklendirilmiş yol haritasıyla sonuçlanan kapsamlı bir değerlendirme projesi olarak konumlandırır. Burada dürüst bir denge söz konusudur: doğru bir ölçüm penceresi günler değil haftalar sürer.</p>
<h2 id="bir-ağ-değerlendirmesi-sonunda-hangi-çıktılar-teslim-edilir">Bir Ağ Değerlendirmesi Sonunda Hangi Çıktılar Teslim Edilir?</h2>
<p>Bir değerlendirme çalışmasının karşılığı, sahada geçirilen saatlerde değil, teslim edilen belgelerde görünür. Türkiye’de network assessment ve danışmanlık hizmeti veren firmaları karşılaştırırken en pratik yöntem, sözleşme öncesinde örnek bir çıktı seti istemektir. Olgun bir network health check ve performans analizi çalışması dört temel teslimatla kapanır.</p>
<p>Denetim raporu. Mevcut durum envanteri (switch, router, access point, firewall, kablolama segmentleri), ölçüm sonuçları ve kritik bulgular tek belgede toplanır. Ölçüm bölümünde paket kaybı oranı, gecikme ve jitter değerleri, arayüz hata sayaçları, uplink doluluk yüzdeleri; ayrıca ölçümün hangi tarih aralığında ve hangi yöntemle alındığı yer almalıdır. Yöntemi yazılmayan bir sonuç, ikinci ölçümde doğrulanamaz.</p>
<p>Risk listesi. Yedeksiz omurga bağlantısı, tek noktada toplanan yönlendirme, destek dışı yazılım sürümü, aşırı yüklü segment gibi zayıf noktalar; etki ve olasılık kriterine göre sıralanır. Her satırda hangi iş sürecinin (üretim hattı, ön büro, hasta kayıt, kamera kaydı) etkilendiği açıkça yazılır.</p>
<p>Kapasite bulguları. Bant genişliği trendi, cihaz başına istemci ve oturum yükü, port ve PoE bütçesi doluluğu yorumlanır. Buradaki asıl soru, mevcut kapasitenin değil büyüme baskısının ne zaman sınırı zorlayacağıdır: yeni lokasyon, kamera ve görüntü sistemleri ya da IoT entegrasyonu eklendiğinde hangi segmentin önce doyacağı belirtilir.</p>
<p>Önceliklendirilmiş iyileştirme yol haritası. Konfigürasyonla hemen çözülecek işler, planlı bakım penceresine alınacak müdahaleler ve yatırım gerektiren kalemler ayrı ayrı sıralanır; her kalem için beklenen süre ve doğrulama ölçütü tanımlanır.</p>
<p>Bu dört çıktı, teknik ekibin bulgularını bütçe gerekçesine, satın alma biriminin ise şartname maddelerine çevirmesini sağlar.</p>
<h3 id="türkiyede-ağ-değerlendirmesi-alırken-karşılaştırılacak-sağlayıcı-tipleri">Türkiye’de Ağ Değerlendirmesi Alırken Karşılaştırılacak Sağlayıcı Tipleri</h3>
<p>Alıcılar genellikle dört farklı sağlayıcı tipini birbiriyle tartar ve her biri farklı bir ağırlık merkezi etrafında kuruludur.</p>
<p>Vendor’a bağlı entegratörler. Tek bir ekosistem etrafında yapılanmış firmalar donanım tedariki, yapılandırma ve platforma özgü izleme konularında genellikle güçlüdür. Otomatik olarak gelmeyen ise değerlendirme metodolojisidir. Çalışmanın segment başına paket kaybı ve gecikme ölçümü, darboğaz tespiti ve yazılı bir iyileştirme planı içerip içermediğini, yoksa cihaz kurulumu ve sağlık panellerinde mi kaldığını sorgulamak gerekir.</p>
<p>Operatörler ve yönetilen servis sağlayıcılar. Bu grup farklı bir ihtiyacı karşılar: operatör sınıfı bağlantı, çok lokasyonlu WAN işletimi ve bir hizmet anlaşması kapsamında sürekli ağ operasyonları. Onlarca şubesi operatör hatlarında çalışan bir kurum için bu gerçekten daha uygun bir seçenek olabilir — hattı ve izlemeyi aynı taraf yürütür. Bina içi LAN, kablosuz kapsama ve veri merkezi altyapısı konusundaki değerlendirme derinlikleri sözleşmeye göre değişir; bu nedenle kapsamın hizmet tanımında teyit edilmesi, varsayılmaması gerekir.</p>
<p>İzleme platformları ve araçları. Ölçüm katmanında kullanılan izleme araçları ve platform-yerli telemetri; arayüz hataları, kullanım trendleri, çalışma süresi geçmişi açısından faydalıdır. Semptomları güvenilir biçimde ortaya çıkarırlar. Ancak tek başlarına, bir erişim switch’indeki dupleks uyuşmazlığının ya da aşırı abone olmuş bir uplink’in kök neden olduğunu söylemezler — bu çıkarım, veriyi topolojiyle birlikte okuyan bir mühendis gerektirir.</p>
<p>Uçtan uca proje firmaları. Dukasim; ihtiyaç analizi, sistem tasarımı, kurulum ve kurulum sonrası destek süreçlerinin tamamında çalışır; bu da ağı ölçen ekiple çözümden ve yeniden testten sorumlu ekibin aynı olması anlamına gelir. Denge burada da açıktır: Dukasim bir operatör değildir ve omurga kapasitesi satmaz; bu nedenle hat seviyesindeki SLA taahhütleri operatörde kalır.</p>
<p>Hangi tipi ön elemeye alırsanız alın, teklifte dört noktayı karşılaştırın: gerçekte ne ölçülüyor ve ne kadar süreyle; denetim raporu ve risk listesinin formatı; iyileştirmenin ardından bir doğrulama ölçümü yapılıp yapılmadığı; ve bulguların mevcut switch, firewall ve kablolama altyapınızla nasıl eşleştiği.</p>
<p>Mevcut ağınızın gerçekte nerede tıkandığını görmek istiyorsanız, Dukasim ekibiyle bir network health check ve performans analizi kapsam görüşmesi planlayabilirsiniz.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Türkiye'de NOC ve Monitoring Hizmeti Nasıl Seçilir? 2026 Rehberi</title>
      <link>https://dukasim.com.tr/blog/noc-ve-monitoring-hizmeti-2026</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/noc-ve-monitoring-hizmeti-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:36:22 GMT</pubDate>
      <description>Alıcılar merkezi izleme, NOC, alarm yönetimi ve SLA destekli destekten ne anlıyor?</description>
      <category>NOC &amp; Monitoring</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<p>Neredeyse her teklifte dört terim karşımıza çıkar ve bu terimler farklı şeyleri ifade eder.</p>
<p>Merkezi izleme, fiziksel ve sanal sunucular, switch ve router’lar, güvenlik duvarları, depolama sistemleri, sanallaştırma sunucuları, endüstriyel ve IoT uç noktaları ile bağlı tüm lokasyonlar genelinde tek bir operasyonel görünüm sunar. Verinin yaygın kullanılan izleme platformlarından biriyle mi yoksa sağlayıcının kendi konsoluyla mı toplandığı, tüm lokasyonların ve markaların tek bir ilişkilendirilmiş görünümde bir araya gelip gelmediği kadar önemli değildir. Bir yazılım kurulumu, hizmet anlamına gelmez.</p>
<p>NOC, bu verinin üzerine kurulan insan ve süreç katmanıdır: uyarıları izleyen, olayları önceliklendiren, ciddiyet seviyesine göre eskalasyon uygulayan ve yalnızca mesai saatlerinde değil, gece ve hafta sonları da müdahaleyi koordine eden bir ağ operasyon merkezidir.</p>
<p>Alarm yönetimi, yalnızca uyarıları almaktan ibaret değildir. Tekrarlayan olayların ayıklanmasını, ilişkili belirtilerin tek bir olay altında birleştirilmesini, önceliklendirmeyi, doğru sorumluya yönlendirmeyi ve belgelenmiş kapanışı kapsar — böylece sabah 03:00’te yaşanan bir bağlantı dalgalanması 400 talep oluşturmaz.</p>
<p>SLA destekli destek kavramı harfiyen okunmalıdır: ciddiyet seviyesine göre yanıt süresi, eskalasyonun kimin sorumluluğunda olduğu, raporlama sıklığı ve alıcıların çoğu zaman atladığı soru — sözleşmenin yalnızca bildirim mi yoksa müdahaleyi de mi kapsadığı.</p>
<p>Buradaki temel sorun; süreklilik, müdahale disiplini ve karma altyapı genelinde görünürlüktür. Aşağıdaki bölümlerde sağlayıcı türleri — sistem entegratörleri, yönetilen hizmet sağlayıcıları, telekom operatörleri ve şirket içi ekipler — imzadan önce doğrulayabileceğiniz kriterlere göre karşılaştırılmaktadır.</p>
<h2 id="hangi-sağlayıcı-türü-hangi-işletim-modeline-uygundur-entegratör-yönetilen-hizmet-sağlayıcı-veya-platform-sağlayıcısı">Hangi sağlayıcı türü hangi işletim modeline uygundur: entegratör, yönetilen hizmet sağlayıcı veya platform sağlayıcısı</h2>
<p>Bir izleme talebine üç farklı türde şirket yanıt verir ve bunlar birbirinin yerine geçmez.</p>
<p>Sistem entegratörleri, önce ortamı tasarlar ve kurar: ihtiyaç analizi, yapısal kablolama, switch, güvenlik duvarı ve sunucu kurulumu, ardından kurdukları altyapının üzerine izleme katmanı eklenir. Sektördeki bazı entegratörler uzun yıllardır sunucu ve ağ projelerinde faaliyet gösterir; hizmet kapsamları genellikle ağ kurulumu ve arıza giderme, kablolu ve kablosuz tasarım, sunucu kurulumu, sanallaştırma ve bakımı kapsar ve farklı sunucu markalarında (Dell, HP, Lenovo, Fujitsu, Supermicro gibi) deneyim beyan ederler. Entegratörler, görünürlüğün fiziksel bir kurulumu takip etmesi gerektiğinde güçlüdür. Dukasim da bu modelde çalışır; izleme kapsamını devreye alma aşamasında bırakmak yerine proje fazından sürekli desteğe taşır.</p>
<p>Yönetilen hizmet sağlayıcıları, sözleşme kapsamında operasyonun yürütülmesini üstlenir: alarm yönetimi, eskalasyon, periyodik raporlama ve bazı anlaşmalarda teknik müdahale. Kapsam sağlayıcıdan sağlayıcıya belirgin şekilde değişir. Bazı sağlayıcılar ITIL tabanlı hizmet yönetimi ve 7/24 çalışan bir operasyon ekibi üzerinden konumlanırken, bazıları sunucuları, veri merkezlerini, ağ cihazlarını, güvenlik duvarlarını, router ve switch’leri kapsayan otomatikleştirilmiş bir NOC yapısını, merkezi alarm yönetimini, güncel tutulan bir CMDB’yi ve yapay zekâ destekli olay yönetimini öne çıkarır; bir kısmı ise NOC’u daha çok alarm yönetimi, eskalasyon ve düzenli raporlama etrafında konumlandırır. Her durumda kapsamın broşürde değil sözleşmede doğrulanması gerekir.</p>
<p>Platform sağlayıcıları, ağ, sunucu, depolama ve IoT telemetrisi için araç setini sağlar. Metrik toplama ve pano derinliğindeki ürün kapasiteleri genellikle yalnızca bir hizmet sözleşmesinin sunabileceğinin ötesine geçer; ancak kurulum, ayarlama ve 7/24 yanıt sorumluluğu sizde veya bir iş ortağınızda kalır. Asıl denge noktası budur: ürün derinliği ile operasyonel sahiplik arasındaki tercih.</p>
<h2 id="sağlayıcılar-arasında-noc-kapsamı-nasıl-karşılaştırılır-kapsam-yanıt-süreleri-raporlama-otomasyon-ve-entegrasyon">Sağlayıcılar arasında NOC kapsamı nasıl karşılaştırılır: kapsam, yanıt süreleri, raporlama, otomasyon ve entegrasyon</h2>
<p>Satış sunumları sonuçları anlatır; sözleşmeler kapsamı tanımlar. İkisini birbirinden ayıran beş soru vardır.</p>
<ol>
<li>
<p><strong>Kapsam.</strong> Bir hizmet adı değil, izlenen cihazların listesini isteyin. Eksiksiz bir liste; fiziksel ve sanal sunucuları, güvenlik duvarlarını, switch’leri, router’ları, depolama sistemlerini, hipervizörleri ve — üretim tesisi veya hastane ortamlarında — IoT ile endüstriyel uç noktaları adlandırır. Ardından bu listenin çoklu lokasyonlarda nasıl işlediğini sorun: şube cihazları merkezi bir toplayıcıdan mı taranıyor, yoksa her lokasyonun kendi probu mu olması gerekiyor? Kullanılan izleme yazılımı burada önemlidir, çünkü farklı platformlar host, sensör ve uzak toplayıcı lisanslamasını farklı biçimde yapılandırır. Cihaz sayısı artmadan önce lisanslama modelini yazılı olarak alın.</p>
</li>
<li>
<p><strong>Yanıt süreleri.</strong> 7/24 vaadi tek başına bir hizmet seviyesi değildir. Sözleşme; her ciddiyet sınıfı için ilk yanıt süresini, seviyeler arası eskalasyon süresini, olay kapanışının kime ait olduğunu ve arızanın operatörünüzde veya üçüncü taraf bir tedarikçide olduğu durumlarda ne olacağını tanımlamalıdır.</p>
</li>
<li>
<p><strong>Raporlama.</strong> Alarm kayıtları ham veridir. Faydalı çıktı; sisteme göre kullanılabilirlik ve olay eğilimlerini, kök neden özetlerini, depolama ve bant genişliği için kapasite payını ve bir denetimde veya yönetim değerlendirmesinde geçerliliğini koruyacak kayıtları içerir.</p>
</li>
<li>
<p><strong>Otomasyon.</strong> Bir operasyon ekibini yoran şey alarmın yokluğu değil, alarm hacmidir. Olay korelasyonu, tekrarlayan alarmların ayıklanması, otomatik talep (ticket) oluşturma ve doğru olayı doğru nöbetçi ekibe yönlendiren kuralların olup olmadığını özellikle sorgulayın.</p>
</li>
<li>
<p><strong>Entegrasyon.</strong> Mevcut altyapınız için okuma erişim yöntemlerini — SNMP, WMI, API, syslog — ve izleme katmanının yapılandırma yönetimi veritabanınıza (CMDB), talep yönetim sisteminize ve dokümantasyon sürecinize nasıl yazdığını doğrulayın.</p>
</li>
</ol>
<p><strong>Dürüst bir denge noktası:</strong> bir platform sağlayıcısı genellikle daha derin telemetri ve daha yapılandırılabilir panolar sunarken, yönetilen bir hizmet sağlayıcısı operasyonel devri sağlar — adı belli bir mühendis, bir eskalasyon yolu, bir kapanış kaydı. Seçim yapmadan önce ikisini de kendi olay geçmişinize göre puanlayın.</p>
<h2 id="724-monitoring-hizmetinin-pratikte-ne-içermesi-gerektiği">7/24 monitoring hizmetinin pratikte ne içermesi gerektiği</h2>
<p>“7/24 monitoring” ifadesi tek başına bir hizmet seviyesi tanımlamaz; asıl belirleyici olan bu sürenin arkasındaki operasyonel düzendir. Sağlayıcının gece, hafta sonu ve resmi tatil vardiyalarını nasıl planladığı, bir vardiyadan diğerine devrin nasıl belgelendiği ve bir alarmın kaç dakika içinde bir kişi tarafından fiilen görüldüğü sözleşmede net biçimde tanımlanmalıdır.</p>
<p><strong>Pratikte süreç dört aşamadan oluşur:</strong> alarmın tetiklenmesi ve kayıt altına alınması, ilgili vardiyadaki personel tarafından değerlendirilmesi, ciddiyet seviyesine göre eskalasyon zincirinin işletilmesi ve olayın hangi koşullarda kapatılmış sayılacağının belgelenmesi. Bu dört aşamadan herhangi birinin sözleşmede tanımsız bırakılması, bir olay sırasında sorumluluğun kimde olduğunun belirsizleşmesine yol açar.</p>
<p>Kurumsal alıcılar için pratik soru şudur: gece saat 03:00’te oluşan bir alarmı kim, ne kadar sürede görür; bu kişi olayı kapatma yetkisine mi sahiptir yoksa yalnızca dahili ekibe bildirim mi iletir? Bu sorunun yanıtı sağlayıcının tanıtım materyalinde değil, SLA maddelerinde aranmalıdır.</p>
<h2 id="çok-lokasyonlu-ve-farklı-marka-altyapılarda-merkezi-görünürlük">Çok lokasyonlu ve farklı marka altyapılarda merkezi görünürlük</h2>
<p>Üretim tesisleri, hastaneler, oteller ve çok şubeli işletmelerde altyapı nadiren tek bir markadan oluşur. Farklı zamanlarda alınmış sunucular, güvenlik duvarları, switch’ler, depolama sistemleri ve sanallaştırma katmanları genellikle bir arada çalışır; bazı lokasyonlarda ise IoT ve endüstriyel uç noktalar bu tabloya eklenir.</p>
<p>Merkezi görünürlük, bu farklı marka ve lokasyonlardaki cihazların ayrı ayrı panolarda değil, tek bir operasyonel görünümde izlenebilmesi anlamına gelir. Bunun için sağlayıcıdan iki şeyin doğrulanması gerekir: birincisi, her lokasyondaki cihazların merkezi bir toplayıcı üzerinden mi yoksa yerel bir prob aracılığıyla mı izlendiği; ikincisi, farklı marka cihazlardan gelen verinin tek bir ilişkilendirilmiş görünümde birleşip birleşmediği. Aksi halde her lokasyon veya her marka için ayrı bir izleme adası oluşur ve bu durum, olayların bütünsel biçimde değerlendirilmesini zorlaştırır.</p>
<p>Çok lokasyonlu kurumlar için bir diğer önemli nokta, yeni bir şube veya tesis devreye alındığında merkezi görünürlüğe dahil edilme sürecinin ne kadar sürdüğü ve bunun ek bir proje mi yoksa hizmetin doğal bir parçası mı olduğudur.</p>
<h2 id="alarmdan-gerçek-müdahaleye-korelasyon-önceliklendirme-atama-ve-olay-sonrası-kayıt">Alarmdan gerçek müdahaleye: korelasyon, önceliklendirme, atama ve olay sonrası kayıt</h2>
<p>Bir alarmın oluşması ile bu alarma karşılık gerçek bir müdahalenin yapılması arasında birkaç ayrı adım vardır ve bu adımların her biri operasyonel olgunluğu gösterir.</p>
<p><strong>İlk adım korelasyondur:</strong> birbiriyle ilişkili birden fazla uyarının tek bir olay altında birleştirilmesi, örneğin bir switch arızasının o switch’e bağlı onlarca cihazdan gelen uyarıyı tek bir kök olaya indirgemesi. İkinci adım önceliklendirmedir; olayın iş etkisine göre ciddiyet seviyesinin belirlenmesidir. Üçüncü adım, olayın doğru sorumluya veya doğru nöbetçi ekibe atanmasıdır. Dördüncü adım fiilen çözüme yönelik aksiyondur; bu aksiyon sağlayıcının sözleşme kapsamına göre yeniden başlatma, yapılandırma değişikliği veya ilgili tedarikçiyle koordinasyon şeklinde olabilir. Son adım ise olayın nasıl çözüldüğünün, ne kadar sürdüğünün ve tekrarını önlemek için alınan aksiyonun belgelenmesidir.</p>
<p>Alıcılar açısından kritik nokta, bu beş adımın tamamının mı yoksa yalnızca ilk üçünün mü sağlayıcının sorumluluğunda olduğudur. Bir sağlayıcının “alarm yönetimi sunduğunu” söylemesi, otomatik olarak dördüncü adımı yani teknik müdahaleyi de üstlendiği anlamına gelmez.</p>
<h2 id="monitoring-hizmet-modelleri-nasıl-karşılaştırılır-izleme-eskalasyon-ve-teknik-müdahale">Monitoring hizmet modelleri nasıl karşılaştırılır: izleme, eskalasyon ve teknik müdahale</h2>
<p>Sağlayıcıların operasyonel sorumluluğu üç ayrı modelden birine karşılık gelir ve bu modeller birbirinin yerine geçmez.</p>
<p>Yalnızca izleme modelinde sağlayıcı sistemleri izler ve uyarı üretir; bu uyarının değerlendirilmesi, yönlendirilmesi ve çözülmesi müşterinin dahili BT ekibinde kalır. İzleme + eskalasyon modelinde sağlayıcı alarmları değerlendirir ve tanımlı süreler içinde belirlenen kişilere veya sürece yönlendirir; ancak fiili teknik müdahale müşteride veya ayrı bir sözleşmede kalabilir. İzleme + teknik müdahale modelinde ise sağlayıcı bildirimle yetinmez; sözleşme kapsamında teknik olarak da müdahale eder — yeniden başlatma, yapılandırma değişikliği, donanım veya network tedarikçileriyle koordinasyon gibi adımları üstlenir ve süreci kapanışa kadar takip eder.</p>
<p>Bu ayrım yalnızca teorik değildir; hangi modelin seçildiği fiyatı, gereken dahili personel sayısını, SLA metnini ve bir olayın kimin tarafından kapatılacağını doğrudan etkiler. “Monitoring” kelimesinin otomatik olarak teknik müdahaleyi içerdiği varsayılmamalıdır; her sağlayıcıda kapsam farklılık gösterebileceğinden, alıcının hangi modelin fiilen sunulduğunu sözleşme aşamasında netleştirmesi gerekir.</p>
<h2 id="dukasimin-altyapı-yetkinlikleri-monitoring-yaklaşımıyla-nasıl-ilişkilenir">Dukasim’in altyapı yetkinlikleri monitoring yaklaşımıyla nasıl ilişkilenir</h2>
<p>Dukasim, network, güvenlik duvarı, sunucu ve depolama, veri merkezi ve IoT alanlarında uçtan uca proje, kurulum ve destek hizmeti sunan bir sistem entegratörü olarak konumlanır. Bu yapı, monitoring ihtiyacının çoğu zaman tek başına bir yazılım kurulumu değil, mevcut altyapıyla bütünleşik bir operasyon meselesi olduğu gerçeğiyle örtüşür: bir switch’i kuran, bir güvenlik duvarını yapılandıran veya bir sunucu/depolama sistemini devreye alan ekip, aynı zamanda bu bileşenlerin izlenmesi gereken noktalarını da bilir.</p>
<p>Dukasim’in kendi DMS katmanı, bu bütünleşik yaklaşımın bir parçası olarak izleme ihtiyaçlarının bir kısmına destek olacak şekilde konumlanır; ancak bu katmanın kapsamı proje bazında değişebileceğinden, belirli bir SLA süresi, otomatik teknik müdahale veya yapay zekâ destekli olay yönetimi gibi taahhütler burada genellenmemelidir. Kurumsal alıcılar için doğru yaklaşım, bu tür yetkinliklerin varlığını ve kapsamını doğrudan Dukasim ile görüşerek, kendi altyapıları ve SLA beklentileri üzerinden netleştirmektir.</p>
<p><strong>Bu konumlandırmanın pratik sonucu şudur:</strong> network, güvenlik, sunucu/depolama ve veri merkezi projelerini aynı ekipten alan kurumlar için, izleme katmanının proje kapsamıyla uyumlu şekilde tasarlanması ve zaman içinde genişletilmesi daha az koordinasyon gerektirir.</p>
<p>Kurumunuzun mevcut cihaz envanterini ve beklediğiniz SLA seviyesini paylaştığınızda, Dukasim ekibi bu ihtiyacı network, güvenlik, sunucu/depolama ve veri merkezi yetkinlikleriyle birlikte değerlendirip size uygun kapsamı netleştirebilir.</p>
]]></content:encoded>
    </item>
    <item>
      <title>Yönetilen BT Hizmetleri, vCIO/vCTO ve Portal Destekli Hizmet Modelleri Nasıl Değerlendirilir? 2026 Rehberi</title>
      <link>https://dukasim.com.tr/blog/yonetilen-bt-vcio-vcto-2026</link>
      <guid isPermaLink="true">https://dukasim.com.tr/blog/yonetilen-bt-vcio-vcto-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:36:22 GMT</pubDate>
      <description>Çok lokasyonlu şirketlerin yönetilen BT hizmetlerinden, danışmanlık desteğinden ve müşteri portalından beklentileri nelerdir?</description>
      <category>Yönetilen BT</category>
      <dc:creator>Dukasim</dc:creator>
      <content:encoded><![CDATA[<p>Bir üretim tesisi, bir otel grubu, bir hastane kampüsü ve bir şube ağı ortak bir sorunu paylaşır: destek kalitesi lokasyondan lokasyona değişkenlik gösterir. Bir lokasyon aynı gün içinde teknisyen desteği alırken, bir diğeri üç gün bekler ve hangi lokasyonda neyin değiştirildiğine dair tek bir kayıt ortaya konulamaz. Türkiye’deki sağlayıcı sayfalarının çoğu, hizmetin bileşenlerini anlatır — telefon ve e-posta ile bakım, kurulum, yapısal kablolama, yıllık yerinde personel — ancak alıcının aslında hangi hizmet modelini satın aldığını netleştirmez. Bu nedenle herhangi bir sağlayıcı kısa listesi oluşturulmadan önce ciddi bir BT hizmetleri ve hizmet modeli analizi yapılmalıdır.</p>
<p>Üç katman farklı sorulara cevap verir. Yönetilen BT (Managed IT), tekrarlayan işleri kapsar: izleme, olay yönetimi, varlık ve lisans takibi ve her lokasyonda standartlaştırılmış hizmet sunumu. Sanal CIO (vCIO) desteği; yol haritası planlaması, yönetişim, bütçe önceliklendirmesi ve teknoloji kararlarının iş hedefleriyle uyumlaştırılması için danışmanlık katmanıdır — kurumun tam zamanlı bir BT yöneticisi olmadığında değerlidir. Sanal CTO (vCTO) desteği ise mühendislik tarafına daha yakındır: mimari seçimi, network ve güvenlik tasarımı, mevcut ITSM, CRM veya ERP sistemleriyle entegrasyon.</p>
<p>Müşteri portalı, tüm bunları denetlenebilir kılan unsurdur — talepler, talep (ticket) durumu, onaylar, raporlama ve tüm lokasyonlardaki hizmet geçmişi için tek bir giriş noktası.</p>
<p>Aşağıdaki bölümler hizmet kapsamını, portal yeteneklerini ve sağlayıcı değerlendirme kriterlerini pratik açıdan ele almaktadır.</p>
<h2 id="dukasim-network-güvenlik-sunucu-veri-merkezi-ve-destek-hizmetlerini-nasıl-yapılandırıyor">Dukasim, network, güvenlik, sunucu, veri merkezi ve destek hizmetlerini nasıl yapılandırıyor?</h2>
<p>Dukasim, kendisini orta ve büyük ölçekli kurumlara yönelik konumlandırıyor ve şirket tanıtımı uçtan uca bir model tanımlıyor: ihtiyaç analizi, ürün tedariki, proje tasarımı, kurulum ve sürekli destek; bunların tümü, telekomünikasyon ve kurumsal teknoloji pazarında 25 yıllık deneyime sahip bir iç ekip tarafından, Türkiye’de ve yurt dışında hizmet verecek şekilde sunuluyor.</p>
<p>Operasyonel olarak bu model birkaç hizmet hattına ayrılıyor. Network çalışmaları, kurumsal bağlantı için tasarım, kurulum ve sürekli destek hizmetlerini kapsıyor — kablosuz ortamlar da dahil olmak üzere, şirketin bu alanda Aruba ile MSP partner statüsüne sahip olduğunu belirttiği bir alan. Network güvenliği çözümleri bunun yanında yer alıyor: uç noktada firewall sistemleri, kullanıcı tarafında uç nokta güvenliği ve iş sürekliliği ile Türkiye’deki mevzuat yükümlülüklerinin gerektirdiği yönetişim ve loglama disiplini. Sunucu ve depolama projeleri ile veri merkezi planlama, kurulum ve destek hizmetleri, çok lokasyonlu kurumların uygulamalarını üzerinde çalıştırdığı paylaşılan altyapıyı kapsıyor.</p>
<p>Bitişik hizmet hatları, alıcıların genellikle beklediğinden daha fazla önem taşır, çünkü bunlar arızalandığında hizmet sürekliliğini kesintiye uğratır: iletişim ve çağrı merkezi sistemleri (Dukasim, bu alanda TEGSOFT’u iş ortağı olarak belirtiyor), IoT entegrasyonu, kamera ve görüntü sistemleri ve yapısal kablolama — bir network genişletmesinin bir konfigürasyon değişikliği mi yoksa yeniden yapılanma mı olduğunu belirleyen fiziksel katman.</p>
<p>Buradaki denge gerçek bir denge. Kablolamadan firewall’a kadar tek bir sağlayıcının hizmet vermesi, tedarikçiler arası devir teslimleri ve olay anında sorumluluk kaydırmayı azaltır; bu da konsolidasyonun temel argümanıdır. Ancak bu durum kapsam tanımını da zorlaştırır: tek bir sözleşme dokuz çözüm ailesini kapsadığında, sözleşmenin hangi sistemlerin izlendiğini, hangilerinin yalnızca talep üzerine desteklendiğini ve lokasyon başına yanıt taahhüdünün ne olduğunu net biçimde belirtmesi gerekir.</p>
<p>Bir BT hizmetleri ve hizmet modeli analizinin doğrudan teyit etmesi gereken bir nokta şudur: Dukasim’in kamuya açık sayfaları çözüm ailelerini ve iş ortaklıklarını tanımlıyor, ancak belgelenmiş bir müşteri portalı veya ITSM talep (ticket) iş akışından söz etmiyor. Sözleşme imzalanmadan önce talep, varlık ve raporlama katmanının bir demosunu talep edin.</p>
<h2 id="portal-katmanı-müşterilerin-neleri-takip-etmesine-talep-etmesine-onaylamasına-ve-raporlamasına-olanak-tanımalı">Portal katmanı, müşterilerin neleri takip etmesine, talep etmesine, onaylamasına ve raporlamasına olanak tanımalı?</h2>
<p>Bir hizmet portalı, çok lokasyonlu bir kurumun BT’yi telefon görüşmeleri ve e-posta yazışmaları üzerinden yönetmeyi bıraktığı noktadır. Yerel pazarın büyük bölümü desteği hâlâ “telefon veya e-posta ile bize ulaşın” şeklinde tanımlıyor; bu, tek bir ofis için işe yarar ancak bir otel grubu, hastane veya üretici on iki lokasyonu farklı firewall altyapıları, kablolama standartları ve kamera ve görüntü sistemleriyle işlettiğinde yetersiz kalır.</p>
<p>Dört işlev, bir portalın gerçek mi yoksa göstermelik mi olduğunu belirler:</p>
<p>Talep girişi (Intake). Olaylar, hizmet talepleri ve değişiklik talepleri için kontrollü tek bir giriş noktası; lokasyon, varlık ve önem derecesi, sonradan yeniden oluşturulmak yerine talep anında kayıt altına alınır.</p>
<p>Takip. Talep durumu, atanan sorumlu, öncelik, açılış/yanıt/çözüm zaman damgaları ve mevcut ilerleme, müşteri tarafından sorulmadan görülebilir olmalıdır.</p>
<p>Onaylar. Satın almalar, değişiklik pencereleri, erişim izinleri ve planlı bakımlar için iş akışı adımları; böylece yönetişim kararları, kimin neyi ne zaman onayladığına dair bir kayıt bırakır.</p>
<p>Raporlama. Hizmet geçmişi, tekrarlayan arıza örüntüleri, varlıkla ilişkilendirilmiş kayıtlar ve lokasyon bazlı eğilimler — yenileme müzakereleri ve BT hizmetleri ile hizmet modelleri analizi için kanıt temeli.</p>
<p>Entegrasyon beklentileri, özellikler kadar önemlidir. Portalın mevcut ITSM aracınız, CRM’iniz, ERP’niz, kimlik sağlayıcınız ve varlık envanterinizle veri alışverişi yapıp yapmadığını ve bunun belgelenmiş bir API üzerinden mi yoksa manuel dışa aktarım yoluyla mı gerçekleştiğini sorun. Bazı Türkiye’deki sağlayıcıların danışmanlık katmanı olarak sunduğu ITIL uyumlu hizmet yönetimi, bu iş akışlarının arkasındaki süreç çerçevesidir; portal ise sürecin denetlenebilir hale geldiği yerdir.</p>
<p>Herhangi bir sağlayıcıdan ekran görüntüleri yerine canlı bir kiracı (tenant) ortamında demo talep edin.</p>
<h2 id="sağlayıcılar-yanıt-süreleri-çoklu-lokasyon-kapsamı-güvenlik-raporlama-ve-entegrasyon-açısından-nasıl-karşılaştırılır">Sağlayıcılar; yanıt süreleri, çoklu lokasyon kapsamı, güvenlik, raporlama ve entegrasyon açısından nasıl karşılaştırılır?</h2>
<p>BT hizmetleri için ciddi bir hizmet modeli analizi, bir teklif dokümanının sıfatlarla yanıtlayamayacağı sorularla başlar. Beş kriter, sağlayıcıları hızlıca birbirinden ayırır.</p>
<p>Yanıt süreleri. Olayların öncelik seviyelerine nasıl sınıflandırıldığını, her seviye için ilk yanıt ve çözüm taahhütlerinin ne olduğunu ve mesai saatleri dışında sürenin nasıl işlediğini sorun. Ardından bu rakamların nasıl ölçüldüğünü ve raporlandığını sorun — ölçüm yöntemi olmayan bir taahhüt, bir hizmet seviyesi anlaşması değil, yalnızca bir cümledir. Eskalasyon yolunu isimlerle teyit edin: birinci seviyede kim yanıt veriyor, üçüncü seviyede sorumluluk kimde ve ne kadar süre sonra.</p>
<p>Çoklu lokasyon kapsamı. Her şubenin, tesisin, otelin veya kliniğin merkez ofisle aynı düzeyde ele alındığını teyit edin. Uzaktan sorun giderme kapasitesini fiziksel sahaya çıkış (dispatch) yeteneğinden ayırt edin ve lokasyon başına yerinde ziyaret taahhütlerini talep edin. Bazı bölgesel sağlayıcılar, kendi şehirlerindeki yerinde müdahale konusunda gerçekten daha güçlüdür; örneğin bazı bölgesel sağlayıcılar, yıllık bakım ve yerinde teknik personel konuşlandırmasını belirli bir bölge etrafında konumlandırır. Eğer faaliyet alanınız orada yoğunlaşıyorsa, bu yakınlık göz önünde bulundurulması gereken gerçek bir avantajdır.</p>
<p>Güvenlik yönetişimi. Ayrıcalıklı erişimi kimin elinde tuttuğunu, bunun nasıl verilip geri alındığını, firewall politika değişikliklerinin nasıl onaylandığını ve uç nokta koruması ile 5651 log yönetimi yükümlülüklerinin nasıl ele alındığını inceleyin. Örnek bir olay eskalasyon kaydı görmeyi talep edin.</p>
<p>Raporlama derinliği. Operasyonel raporlar, cihaz ve lokasyon bazında eksiksiz hizmet geçmişi ve tekrarlayan olay analizi, desteği planlama girdisine dönüştüren unsurlardır. Lokasyon bazlı görünürlük, en kolay vaat edilen ancak en az sağlanan kısımdır.</p>
<p>Entegrasyon uyumu. Müşteri portalının veya ITSM katmanının mevcut servis masanız, kimlik dizininiz, varlık envanterinizi, CRM ve ERP sisteminizle — belgelenmiş bir API veya bağlayıcı (connector) üzerinden, manuel dışa aktarım yoluyla değil — veri alışverişi yapıp yapmadığını doğrulayın.</p>
<p>Hiçbir sağlayıcı bu beş kriterin tamamında öne çıkmaz. Onları puanlayın, ardından hangi boşlukları içeride karşılayabileceğinize karar verin.</p>
<h2 id="dukasim-piyasadaki-yaygın-hizmet-modelleriyle-nasıl-karşılaştırılır">Dukasim, piyasadaki yaygın hizmet modelleriyle nasıl karşılaştırılır?</h2>
<p>Türkiye pazarındaki sağlayıcıların çoğu iki ana örüntüden birinin etrafında kümeleniyor ve bu fark, satış sunumundan çok, tedarik aşamasında önem kazanıyor.</p>
<p>İlk örüntü, geleneksel teknik servis modelidir. Bazı sağlayıcıların yayımladığı network ve yerinde hizmet kapsamı, adil bir taban çizgisi oluşturur: telefon ve e-posta ile hizmet talepleri, donanım kurulumu ve devreye alma, yapısal kablolama, yıllık bakım anlaşmaları ve müşteri sahasına günlük, haftalık veya aylık olarak yerleştirilen teknik personel. Öngörülebilir donanım ihtiyaçları olan tek lokasyonlu bir ofis için bu model genellikle yeterli ve bütçelemesi kolay bir modeldir.</p>
<p>İkinci örüntü, süreç odaklı hizmet yönetimidir. Bazı sağlayıcılar örneğin, sunumlarını ITIL tabanlı BT hizmet yönetimi, kullanıcıya dönük bir servis masası, süreç tanımlama ve eğitim desteği etrafında kurguluyor — bu, talep (ticket) yaşam döngüleri ve tanımlı eskalasyon yolları isteyen, rastgele çağrı yönetiminden ziyade süreç odaklı bir yaklaşım arayan kurumlar için kullanışlı bir dil sunuyor.</p>
<p>Dukasim, uçtan uca teslimata daha yakın konumlanıyor: kendi materyalleri, iletişim sistemleri, network, güvenlik, veri merkezi, sunucu ve depolama, IoT, kamera ve görüntü sistemleri ile yapısal kablolama alanlarında proje, tedarik ve uygulama çalışmalarını tanımlıyor; 25 yıllık deneyim ile Aruba ve TEGSOFT gibi iş ortaklıklarını belirtiyor.</p>
<p><strong>Dürüst olmak gerekirse:</strong> teslimat genişliği, hizmet yönetimi derinliğiyle aynı şey değildir. Portal işlevselliği ve danışmanlık kapasitesi genellikle varsayılan olarak pakete dahil edilmez; bu nedenle BT hizmetleri ve hizmet modelleri konusunda ciddi bir analiz üç noktayı doğrudan test etmelidir — müşteri portalının sağlayıcının kendi yazılımı mı yoksa lisanslı bir ITSM platformu mu olduğu, SLA’nın lokasyon başına gerçekte neyi taahhüt ettiği ve taleplerin mevcut ERP veya CRM sistemleriyle nasıl entegre olduğu.</p>
<p>Hizmet kapsamını, portal iş akışını ve yönetişim uyumunu tek bir karar olarak değerlendirin — bir sonraki adım için Dukasim ile iletişime geçin.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
