Fabrika için BT kesinti planı, kritik işleri ve uygulama bağımlılıklarını belirler; iletişim, geçici çalışma, kurtarma sırası ve kabul adımlarını tanımlar. Üretim güvenliğini etkileyen sistemler ilgili işletme ve üretici ekipleriyle birlikte değerlendirilmelidir.
Bir fabrikanın bilgi teknolojileri, ofis bilgisayarlarından ibaret değildir. Üretim emirleri, depo hareketleri, kalite kayıtları, bakım faaliyetleri ve sevkiyat birbirine bağlı uygulamalarla yürür. Bazı süreçler doğrudan ERP’ye, bazıları yerel üretim sistemlerine, bazıları da operatörün kullandığı terminale bağımlıdır. Devamlılık planı bu gerçek çalışma zincirini göstermelidir.
Öncelikli hedef, arıza veya bakım sırasında kritik işlerin devam edebileceği altyapıyı kurmaktır. Bunun yanında tamamen önlenemeyen olaylarda hangi işin nasıl sürdürüleceği, hangisinin güvenli biçimde durdurulacağı ve kayıtların nasıl korunacağı belirlenir. Bu kararlar BT, üretim, bakım ve ilgili uygulama ekiplerinin ortak çalışmasını gerektirir.
1. Üretim akışından teknik bağımlılık haritası çıkarın
Analize sunucu isimleriyle değil, bir ürünün siparişten sevkiyata yolculuğuyla başlayın. Üretim emrinin açılması, malzemenin alınması, operasyonun kaydedilmesi, kalite kontrol ve sevkiyat için hangi sistemler gerekir? Bir barkod yazıcısı veya etiket şablonu servisi küçük görünse de ilgili süreç için kritik olabilir.
Her adımda gerekli uygulama, veri kaynağı, ağ bölgesi, kullanıcı rolü ve fiziksel ekipman listelenir. Ardından bu bağımlılıkların birlikte arızalanabileceği noktalar işaretlenir. Aynı switch’e bağlı üretim terminalleri, tek enerji hattındaki erişim cihazları veya tek DNS servisine bağlı uygulamalar farklı ortak arıza alanlarıdır.
| İş adımı | Olası BT bağımlılığı | İş birimiyle netleştirilecek konu |
|---|---|---|
| Üretim emrini iletme | ERP, kimlik, ağ ve yerel terminal | Sistem erişilemezse onaylı emir nereden alınır? |
| Malzeme hareketi | Depo uygulaması, barkod ve veri bağlantısı | Geçici hareket nasıl numaralanır ve mutabakat yapılır? |
| Kalite kaydı | Kalite sistemi ve ölçüm/veri kaynağı | Hangi kayıt olmadan ürün ilerleyemez? |
| Sevkiyat | ERP, etiket ve dış entegrasyonlar | Hangi şartta sevkiyat bekletilir? |
Tablonun tamamı için yana kaydırabilirsiniz.
2. IT ve OT için aynı müdahaleyi varsaymayın
IT sistemleri iş bilgisini işlerken operasyonel teknoloji (OT) fiziksel süreçleri izleyebilir veya kontrol edebilir. PLC, SCADA ve üreticiye özgü sistemlerde gecikme, çalışma kararlılığı ve insan güvenliği farklı öncelikler doğurur. Ofis bilgisayarında uygulanabilen bir ajan, tarama veya yeniden başlatma yöntemi üretim sisteminde uygun olmayabilir.
NIST SP 800-82 Rev. 3, OT güvenliğini bu performans, güvenilirlik ve güvenlik gereksinimleriyle birlikte ele alır. NIST OT güvenliği rehberi. Envanter ve müdahale yöntemleri ürün desteğiyle doğrulanmalı; üretim ekipmanına yönelik işlemler yetkili ekip ve üretici prosedürleriyle koordine edilmelidir.
Bir güvenlik alarmında etkilenen cihazın ağını kesmek ofis ortamında uygun olabilirken üretim tarafında farklı sonuç doğurabilir. İzolasyon yetkisi, uygulanacak sınır ve üretimle iletişim adımı olay planında önceden tanımlanır. Gerektiğinde karar, süreci güvenli biçimde durdurmak olabilir; devamlılık hedefi fiziksel güvenliği geçersiz kılmaz.
3. Devamlılığı ağ, enerji ve uygulama katmanlarında kurun
Fabrika ve merkez ofis arasındaki bağlantı kritikse alternatif yolun gerçekten bağımsız olup olmadığı incelenir. Yedekli switch yapısında cihazların yanı sıra uplink, enerji ve yönetim bağımlılıkları değerlendirilir. Tek bir kabinet kaybının hangi alanları etkileyebileceği topoloji üzerinde görülebilmelidir.
Uygulama tarafında HA, veritabanı ve dosya katmanları birlikte planlanır. Bir sunucu arızasında diğer sunucunun devralması bekleniyorsa kalan kaynaklar yoğun üretim yükünü taşımalıdır. Planlı bakımın nasıl yapılacağı da tasarımın parçasıdır; bütün bileşenleri aynı anda güncellemek yedekli yapının korumasını ortadan kaldırabilir.
Buluttaki ERP ile yerel üretim sistemi birlikte çalışıyorsa internet kesintisindeki davranış açık olmalıdır. Yerel kuyruk veya çevrimdışı kayıt mekanizması ancak uygulama destekliyorsa kullanılabilir. Bağlantı geri geldiğinde sıra, tekrar işlem ve veri çakışması nasıl yönetilecek? Bu soruların cevabı olmadan “yerelde devam eder” varsayımı yapılmamalıdır.
- İş uygulamalarıERP, planlama ve raporlama
- Kontrollü veri geçişiTanımlı servisler ve erişim sınırları
- Üretim sistemleriYerel uygulama ve operasyon verisi
- Saha işlemiYetkili ekip ve güvenli işleyiş
Şema mantıksal bir örnektir. Gerçek ağ bölgeleri ve geçişler ekipman, uygulama ve risk analiziyle tasarlanır.
4. Kesinti senaryolarını birbirinden ayırın
İnternet kesintisi, sanallaştırma sunucusu arızası, ERP veri hatası ve güvenlik nedeniyle izolasyon aynı müdahale planıyla ele alınmaz. İnternet kesintisinde yerel uygulamalar çalışabilir; kimlik servisinin kaybı ise ağ açıkken yeni oturumları etkileyebilir. Bileşenin “açık” olmasıyla işin çalışması arasındaki fark özellikle burada görülür.
Her senaryoda olayın nasıl anlaşılacağı, ilk kontrol, alternatif çalışma yolu, karar yetkilisi ve kabul ölçütü tanımlanır. Ayrıca planın neye dayanarak başarılı sayılacağı yazılır. Yedek bağlantının aktif görünmesi yerine örnek sevkiyat işleminin doğru veriyle tamamlanması daha somut bir kabul sonucudur.
İlk kontrol bağlantı arızasını uygulama hatasından ayırır. Alternatif erişim varsa devralma doğrulanır. Yerel işlemler devam edecekse kullanılacak veri sürümü ve bekleyen kayıtların yöntemi belirlenir. Bağlantı geldiğinde bütün kuyrukları yeniden göndermeden önce tekrar işlem riski kontrol edilir.
5. Geçici çalışma, veri mutabakatıyla tamamlanmalı
Bazı işler onaylanmış formlar veya uygulamanın çevrimdışı yeteneğiyle kısa süre devam edebilir. Bunun sınırını iş birimi belirler. Kayıt zamanı, sorumlu kişi, ürün veya hareket kimliği ve geçici kayıt numarası tutulmadığında sistem geri geldiğinde hangi hareketin eksik olduğu anlaşılamayabilir.
Geri girişte aynı hareketin iki kez işlenmesini önleyen kontrol gerekir. Örneğin geçici numara aralığı, kayıtların teslim listesi ve ikinci kişi doğrulaması kullanılabilir. Uygulama otomatik eşitleme sunuyorsa tekrar deneme davranışı ve aynı işlemin bir kez uygulanması için kullanılan mekanizma incelenir. “Veri yeniden gönderildi” sonucu, stok ve üretim kayıtlarının doğru olduğu anlamına gelmez.
6. Tatbikatı üretimi riske atmadan aşamalandırın
İlk adımda masa başı senaryosu uygulanabilir: vardiya sorumlusu kime ulaşır, hangi doküman gerekir ve hangi karar kimdedir? İkinci adım izole teknik ortamda kurtarma veya erişim testidir. Planlı canlı devralma ise uygun kapsam, bakım penceresi ve geri dönüş yöntemiyle ayrıca tasarlanır. Her testte sistemi durdurmak gerekmez.
Ölçüm listesine algılama süresi, alternatif yolun açılması, uygulamanın hazır olması ve iş birimi kabulü eklenir. Test sonrasında eksik yetki, güncel olmayan telefon veya unutulmuş entegrasyon da teknik bulgu kadar değerlidir. Bunların sorumlusu belirlenir ve sonraki testten önce kapatılır.
7. Planı vardiya ve değişiklik düzenine bağlayın
Plan yalnız gündüz BT personelinin bildiği bir dosyada kalmamalıdır. Yetkili vardiya ekipleri gereken iletişim ve karar bilgisine ulaşabilmelidir. Hassas yönetim bilgileri ise herkese açık planın içinde tutulmaz; ilgili erişim yöntemi ayrı ve kontrollü şekilde tanımlanır.
Yeni üretim hattı, ERP entegrasyonu, ağ değişikliği veya farklı bir depo açıldığında bağımlılık haritası güncellenir. Fabrikanın sürekliliği, bir kez hazırlanmış kurtarma belgesinden çok; yedekli altyapının, uygulama davranışının, vardiya iletişiminin ve veri disiplininin birlikte işletilmesine dayanır.
Sık sorulan sorular
Bu plan yalnız BT ekibinin işi mi?
Hayır. İş öncelikleri ve geçici çalışma kararları ilgili birimlerle birlikte belirlenmelidir.
Her testte sistemi durdurmak gerekir mi?
Gerekmez. Masa başı senaryosu ve izole teknik test gibi farklı yöntemler, amaç ve risklere göre planlanabilir.