NE ANLAMA GELİYOR?

Şirket içi BT, dış kaynak hizmeti ve karma model farklı ihtiyaçlara cevap verir. Günlük yakınlık, uzmanlık çeşitliliği, çalışma saatleri ve işin sürekliliği birlikte değerlendirilerek görev dağılımı yapılmalıdır.

Bir şirketin kendi BT personeline sahip olması, her uzmanlığı içeride tutması gerektiği anlamına gelmez. Dışarıdan hizmet alınması da kurum içindeki teknik sorumluluğu ortadan kaldırmaz. Karar, kaç kişinin çalışacağından önce hangi işlerin sürekli yapılması gerektiği ve bu işlerin hangi yetkinliklere ihtiyaç duyduğu üzerinden verilmelidir.

Örneğin kullanıcı desteği güçlü olan bir ekip; veritabanı performansı, sanallaştırma kümeleri veya güvenlik olayı incelemesi için ek uzmanlık isteyebilir. Burada ihtiyaç bütün BT yönetimini devretmek değil, belirli bir boşluğu tamamlamaktır. İşletim modelini doğru kurmak için insan, teknoloji, erişim ve karar yetkisini aynı tabloda değerlendirmek gerekir.

1. Önce yapılacak işleri ve gerekli kapasiteyi çıkarın

Destek taleplerini, periyodik bakımı, proje işlerini ve olay müdahalesini ayrı iş yükleri olarak ölçün. Günlük taleplerle sürekli meşgul olan bir uzman, altyapı iyileştirmesine yeterli zaman ayıramayabilir. Açılan talep sayısı tek başına kapasiteyi açıklamaz: bir kullanıcı hesabı işlemiyle depolama arızasının araştırılması aynı emek değildir.

Kapasite tablosunda izin, eğitim, hastalık, saha yolculuğu ve beklenmeyen olaylar için de yer olmalıdır. Mesai dışında bir uygulama çalışıyorsa yalnız telefon numarasının bulunması yeterli değildir; görevi üstlenecek kişinin yetkisi, erişimi ve yedeği de gerekir. Bu ihtiyacın vardiya, nöbet veya sözleşmeli destekle nasıl karşılanacağı tasarlanır.

İş grubuGerekli yakınlıkDeğerlendirilecek kaynak
Kullanıcı ve saha desteğiİşletmenin günlük çalışma biçimine yakınlıkİç ekip, yerinde hizmet veya birlikte yürütme
Altyapı işletimiSistemler arasında bütünlük ve düzenli bakımYetkin iç ekip veya yönetilen BT
Özel teknik uzmanlıkBelirli platformda derin bilgiİhtiyaca göre uzman desteği
İş önceliği ve risk kararıOperasyon ve bütçe yetkisiKurumun yetkilendirdiği sorumlu

Tablonun tamamı için yana kaydırabilirsiniz.

2. Üç işletim modelinin teknik farkı

İç ekip ağırlıklı model

Günlük yönetim ve değişiklikler içeride yürütülür. Dış uzmanlık belirli projeler veya zor olaylar için kullanılır. Bu modelde dokümantasyonun tek kişide kalması, uzmanlık yedeğinin bulunmaması ve görevler arası kontrol eksikliği ayrıca ele alınmalıdır. Bir yöneticinin izinde olması, kritik bir sistemin bakımını durdurmamalıdır.

Yönetilen hizmet ağırlıklı model

Altyapı takibi ve tanımlanan operasyon işleri hizmet sağlayıcı tarafından yürütülür. Kurum tarafında iş önceliğini belirleyecek ve değişiklikleri onaylayacak bir hizmet sahibi bulunur. Uygulama lisansı, üretici desteği veya iş birimi süreç tasarımı gibi başlıkların hangi tarafta olduğu açıkça yazılır.

Birlikte yönetim modeli

İç ekip kullanıcı ve iş birimleriyle yakın çalışırken sağlayıcı sunucu, ağ, yedekleme veya güvenlik gibi alanları üstlenebilir. En önemli teknik gereksinim ortak görünürlüktür. Ayrı talep sistemleri ve güncellenmeyen iki farklı envanter, olayın iki ekip arasında beklemesine neden olabilir. En azından olay durumu, sorumlu, değişiklik geçmişi ve güncel topoloji ortak erişilebilir olmalıdır.

3. RACI tablosunu gerçek olaylarla sınayın

RACI; işi yapanı, sonuçtan sorumlu kişiyi, görüşü alınanı ve bilgilendirileni ayırmak için kullanılabilir. Fakat bir tabloda isim yazmak tek başına yeterli olmaz. “Gece ERP erişimi kesildi” senaryosunda kimin ilk kontrolü yapacağı, kimin uygulama üreticisini arayacağı ve kimin geçici kesinti kararını vereceği anlaşılmalıdır.

Örnek bir sorumluluk dağılımında sağlayıcı veritabanı ve depolama kontrollerini yapar; kurumun hizmet sahibi iş etkisini ve önceliğini belirler; uygulama üreticisi kendi yazılımındaki hatayı inceler. Olayın toplam takibini bir taraf üstlenir. Böylece bütün taraflar kendi bileşenini “çalışıyor” ilan ederken kullanıcı sorununun açık kalması önlenir.

Sözleşmeye çevrilebilecek örnek

“Üretim ERP’sinin tüm kullanıcılara kapalı olması”: kritik olay tanımı, ilk yanıt hedefi, görevli teknik ekip, üreticiye aktarım yolu, iletişim sıklığı ve iş birimi kabulü birlikte yazılır. Süreler teklifin adıyla değil, bu koşullarla anlam kazanır.

4. Dış erişimi kişiye, göreve ve kayda bağlayın

Uzaktan yönetim için paylaşılan tek yönetici hesabı kullanılması, işlemi yapan kişiyi ayırt etmeyi ve çalışan ayrıldığında erişimi sonlandırmayı güçleştirir. Kişisel yönetim hesapları, mümkün olan sistemlerde çok faktörlü doğrulama ve ihtiyaca göre süreli yetki verilmesi daha izlenebilir bir düzen sağlar. Ayrıcalıklı oturumların nereden kurulabildiği de tanımlanır.

Sağlayıcının erişimi bütün ağa yayılmak zorunda değildir. Belirli yönetim noktalarından, tanımlı hizmetlere ve protokollere izin veren bir yapı kurulabilir. NIST’in Zero Trust yaklaşımı, yalnız ağ içinde bulunmayı güven nedeni saymaz; kimlik ve kaynağa erişim kararını öne çıkarır. NIST SP 800-207.

Acil erişim yöntemi normal oturumdan ayrılır. Kim tarafından açıldığı, ne kadar süre açık kalacağı ve kullanım sonrasında hangi kontrolün yapılacağı kayda alınır. Sağlayıcı değiştiğinde kullanıcılar, API anahtarları, uzaktan destek ajanları ve otomatik görev hesapları tek tek gözden geçirilir.

5. Geçiş dönemi bir teknik devralma projesidir

Yeni ekip ilk gün bütün sistemleri eksiksiz tanıyamaz. Devralma; erişimlerin doğrulanması, topolojinin çıkarılması, yedeklerin kullanılabilirliğinin kontrolü ve mevcut açık olayların aktarılmasıyla başlar. Dokümanda yazan yapı ile çalışan sistem karşılaştırılmadan yapılan değişiklikler beklenmeyen bağımlılıkları etkileyebilir.

Örnek bir aşamalı geçişte ilk bölüm gözlem ve envantere, ikinci bölüm sorumlulukların beraber yürütülmesine, son bölüm ise ölçülebilir kabul kontrollerine ayrılabilir. Takvim sistem sayısına göre değişir. Kabul sırasında yalnız erişim hesabının açılması değil, bir alarmın doğru ekibe ulaşması ve örnek bir olayın uçtan uca takip edilebilmesi denenmelidir.

6. Maliyeti aynı hizmet seviyesiyle karşılaştırın

İç ekip maliyetine ücret dışında eğitim, araçlar, üretici desteği, izin dönemi kapasitesi ve özel uzmanlık ihtiyacı dâhildir. Dış hizmet tarafında ise temel pakete ek olarak yerinde çalışma, proje değişiklikleri, lisanslar ve mesai dışı kapsam değerlendirilir. İki model ancak aynı hizmet saatleri ve sorumluluklarla karşılaştırıldığında anlamlı sonuç verir.

Teknik değerlendirmeye bir çıkış planı da ekleyin. Güncel yapılandırmalar, envanter, olay geçmişi ve yönetim erişimleri kurumun kullanımına açık olmalıdır. İş birliğinin başarısı sadece ilk kurulumla ölçülmez; başka bir ekibin gerektiğinde hizmeti düzenli devralabilmesi de işletmenin bağımsızlığını ve devamlılığını destekler.

Doğru model, kurumdaki bilgiyi kaybetmeden eksik kapasiteyi tamamlayandır. Önce sorumluluk haritasını çıkarıp sonra ekip ve hizmet seçmek, ürün listesi üzerinden başlanan bir satın alma sürecine göre daha somut bir karar zemini oluşturur.

Sık sorulan sorular

Dış kaynak kullanınca BT yöneticisine gerek kalmaz mı?

İş önceliklerini ve bütçeyi yönetecek kurum içi bir muhatap yine gereklidir. Rolün kapsamı organizasyona göre değişir.

Kendi veri merkezimiz varsa dışarıdan yönetilebilir mi?

Evet. Barındırmanın müşteride olduğu, yönetimin hizmet sağlayıcı tarafından yürütüldüğü modeller kurulabilir.

İlgili hizmetler ve rehberler

VK
Vekosis KurumsalBT, bulut ve siber güvenlik hizmetleri.
Vekosis’i tanıyın