Felaket Kurtarma, İş Sürekliliği ve Olay Müdahalesi
ProcessMind Felaket Kurtarma, İş Sürekliliği ve Olay Müdahalesi
Yürürlük tarihi: 14 Eylül 2026
Bu belge, ProcessMind B.V.’nin bulut hizmetine ilişkin olağanüstü durum kurtarma (“DR”), iş sürekliliği (“BCP”) ve güvenlik olayı müdahale prosedürlerinin üst düzey bir özetini sunar. Güvenlik Önlemlerini, SaaS Barındırma Politikasını, Hizmet Seviyesi Sözleşmesini ve Veri İşleme Ekini tamamlar.
Bu belge mevcut yaklaşımımızı açıklar ve geçerli sözleşmede, DPA’da veya SLA’da açıkça belirtilenlerin ötesinde ayrı sözleşmesel kurtarma süresi hedefleri, kurtarma noktası hedefleri, veri dayanıklılığı garantileri, bildirim süreleri, hizmet seviyeleri veya sorumluluk standartları oluşturmaz.
1. Amaçlar ve Kapsam
ProcessMind bu prosedürleri aşağıdaki amaçlarla yürütür:
- kesintiye yol açan bir olay sırasında Müşteri Verilerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini korumak
- ProcessMind’in kontrolündeki sistemlerde meydana gelen arızaların ardından kritik üretim hizmeti bileşenlerini yeniden çalışır hâle getirmek
- hizmet kesintileri sırasında olay yönetimini, müşteri iletişimini ve operasyonel karar alma süreçlerini sürdürmek
- altyapı, dağıtım, uygulama veya veri katmanı arızalarından belgelenmiş prosedürler ve kaynak denetimindeki altyapı tanımları kullanılarak kurtulmak
- Güvenlik Olaylarını belirlemek ve değerlendirmek, tehditleri kontrol altına almak, temel nedenleri ortadan kaldırmak, etkilenen sistemleri kurtarmak, gerektiği şekilde iletişim kurmak ve çıkarılan dersleri kaydetmek
Bu prosedürler, üretimdeki ProcessMind bulut hizmeti için ve Hizmeti etkiledikleri ve ProcessMind’in makul ölçüde soruşturma ve yönetim yetkisi dahilinde oldukları ölçüde alt işleyenleri veya bulut hizmetlerini ilgilendiren güvenlik olayları için geçerlidir. Geliştirme ve test ortamları birbirinden ayrıdır ve müşterilere yönelik üretim taahhütleri kapsamında kurtarma hedefleri olarak değerlendirilmez.
2. Dayanıklılık Stratejisi
2.1 Bölgesel Tasarım. Üretim hizmetleri AWS EU’da (Frankfurt, Almanya, eu-central-1) barındırılır. Mimari, AWS’nin birden fazla Kullanılabilirlik Alanında işlettiği bu bölgedeki AWS yönetilen hizmetlerine dayanır. Aurora kümesi şu anda tek bir yazıcı örneğiyle çalışmaktadır; bu nedenle veritabanı kurtarma, aynı bölgedeki bir yedek örnek yerine otomatik yedeklemelere ve belirli bir zamana geri yüklemeye dayanır. ProcessMind şu anda müşteri verilerinin bulunduğu ikinci bir etkin bölge işletmemektedir.
2.2 Yönetilen ve Sunucusuz Hizmetler. ProcessMind; AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS ve Amazon CloudWatch hizmetlerine dayanır. Bu, müşteri tarafından yönetilen ve uzun süre çalışan sunuculara bağımlılığı azaltır ve uygulama ile statik bileşenlerin kaynaktan yeniden oluşturularak kurtarılmasını destekler.
2.3 Ortamların Ayrılması. Üretim ve geliştirme ortamları, ayrı veritabanları ve altyapı yığınlarıyla ayrı AWS hesaplarında çalışır. Bu, geliştirme faaliyetlerinin üretim kurtarma işlemlerini etkileme riskini azaltır.
2.4 İzleme ve Tespit. CloudWatch alarmları, panolar, ölü harf kuyruğu uyarıları, merkezi günlük kaydı ve sentetik hizmet izleme; olayların tespitini, önceliklendirilmesini ve üst kademeye iletilmesini destekler. Olası olaylar ayrıca destek talepleri, çalışan bildirimleri, tedarikçi bildirimleri veya diğer soruşturma tetikleyicileri aracılığıyla da belirlenebilir.
3. Kurtarma Öncelikleri
Büyük bir olay sırasında ProcessMind’in kurtarma öncelikleri genel olarak şunlardır:
- Müşteri verilerinin bütünlüğünü korumak ve daha fazla zararı önlemek.
- Olayı kontrol altına almak ve etkilenen sistemleri istikrara kavuşturmak.
- Temel üretim erişim yollarını ve kritik iş akışlarını yeniden çalışır hâle getirmek.
- Kurtarmanın tamamlandığını ilan etmeden önce hizmet davranışını, veri bütünlüğünü ve izlemeyi doğrulamak.
- Durum güncellemelerini, müşteriler üzerindeki etkileri ve takip işlemlerini bildirmek.
Kesin sıra, olayın niteliğine ve olayın veri bütünlüğünü, müşteri erişimini, eşzamansız işlemeyi veya destekleyici altyapıyı etkileyip etkilemediğine bağlı olarak değişebilir.
4. Felaket Kurtarma Prosedürleri
4.1 Olayın İlanı ve Koordinasyon. Önemli hizmet kesintileri ve güvenlik olayları, olay müdahale prosedürleri kapsamında önceliklendirilir. ProcessMind bir olay lideri belirler, müdahaleye katılımı yetkili personelle sınırlar, olayın ciddiyetini ve kapsamını değerlendirir, teknik müdahale ekiplerini koordine eder ve olay çözülene veya önem derecesi düşürülene kadar kurtarma işlemlerini takip eder.
4.2 Kontrol Altına Alma. ProcessMind, daha kapsamlı kurtarma işlemleri başlamadan önce devam eden etkiyi durdurmak veya azaltmak için ticari açıdan makul çabayı gösterir. Arıza türüne bağlı olarak kontrol altına alma işlemleri; yakın tarihli değişiklikleri geri almayı, etkilenen yolları devre dışı bırakmayı, arızalı bileşenleri yalıtmayı, bütünlük kontrolleri yapılırken arka plan işlemlerini duraklatmayı, kimlik bilgilerini iptal etmeyi veya yenilemeyi ya da kötüye kullanım faaliyetlerini engellemeyi içerebilir.
4.3 Ortadan Kaldırma. Acil etki istikrara kavuşturulduktan sonra ProcessMind, temel nedeni veya katkıda bulunan koşulu ortadan kaldırmak için çalışır. Bu işlemler; kod veya yapılandırma düzeltmeleri uygulamayı, kötü amaçlı unsurları kaldırmayı, gizli bilgileri yenilemeyi, güvenilir yapılandırmayı geri yüklemeyi veya açık erişim yollarını kapatmayı içerebilir.
4.4 Veritabanı Kurtarma. Aurora PostgreSQL, yedi (7) günlük saklama süresiyle sürekli otomatik yedeklemeler gerçekleştirir ve belirli bir zamana geri yüklemeyi destekler. Veritabanı düzeyindeki bir arıza, bozulma olayı veya yanlışlıkla yapılan yıkıcı bir değişiklik nedeniyle geri yükleme gerekirse ProcessMind, uygun en son yedeklemeden veya seçilen bir zamana ait yedeklemeden geri yükleme yapabilir, geri yüklenen ortamı doğrulayabilir ve uygulama trafiğini kurtarılan veritabanı yoluna yönlendirebilir.
4.5 Nesne ve Yapıt Kurtarma. Müşteri dosyası yüklemeleri ve operasyonel yapıtlar Amazon S3’te saklanır. Yanlışlıkla silme veya üzerine yazma durumlarında kurtarmayı desteklemek için yükleme kovasında ve kaynak kovalarında sürüm oluşturma etkindir. Web sitesi ve ön uç dağıtım kovaları yeniden üretilebilir yapıtlar olarak değerlendirilir ve yedeklerden geri yüklenmek yerine kaynaktan yeniden oluşturulabilir.
4.6 Eşzamansız İş Yükü Kurtarma. Eşzamansız işleme yollarında, başarısız olayları inceleme amacıyla saklamak için ölü harf kuyrukları kullanılır. Kurtarma; başarısız mesajların yeniden denenmesini, işleme mantığının yeniden çalıştırılmasını veya temel iş akışının güvenli yeniden işlemeyi desteklediği durumlarda işin yeniden yürütülmesini içerebilir.
4.7 Uygulama ve Altyapının Yeniden Oluşturulması. Altyapı, kaynak denetimindeki altyapı kodu tanımları aracılığıyla yönetilir. Uygulama altyapısının veya statik varlıkların yeniden oluşturulması gerekirse ProcessMind, etkilenen bileşenleri sürüm denetimindeki tanımlardan ve derleme yapıtlarından yeniden oluşturup dağıtabilir.
4.8 Hizmetin Yeniden Başlatılmasından Önce Doğrulama. Bir olay kapatılmadan önce ProcessMind, mevcut izleme araçlarını, günlükleri, sentetik kontrolleri ve hedefli işlevsel doğrulamayı kullanarak hizmetin durumunu doğrular ve etkilenen işlevleri doğrulanmış dağıtım, kurtarma ve altyapı prosedürlerini kullanarak yeniden çalışır hâle getirir. Olay veri geri yükleme veya veri bütünlüğü riski içeriyorsa ek inceleme yapılabilir.
5. İş Sürekliliği Önlemleri
5.1 Operasyonel Süreklilik. ProcessMind, kesintiye yol açan olaylar sırasında olay yönetiminin, müşteri destek taleplerinin alınmasının, mühendislik müdahalesinin ve karar alma süreçlerinin devam edebilmesi için belgelenmiş operasyonel prosedürleri yürütür.
5.2 İletişim. Önemli üretim olaylarında ProcessMind, müşteri destek kanalları ve uygun olduğu durumlarda processmind.com/status adresindeki herkese açık durum sayfası aracılığıyla güncellemeler sağlamak için ticari açıdan makul çabayı gösterir.
5.3 Kontrollü Değişiklik Yönetimi. Önlenebilir kesintileri azaltmak ve zaman içinde sürekliliği iyileştirmek için birden fazla bağımsız otomatik doğrulama katmanı, kontrollü dağıtımlar, merkezi izleme ve olay sonrası incelemeyi içeren derinlemesine savunma yaklaşımına sahip bir yazılım geliştirme yaşam döngüsü kullanılır.
5.4 Kurtarma Sırasında Güvenlik. Kurtarma işlemleri; en az ayrıcalık ilkesi, mevcut olduğu durumlarda operasyonel faaliyetlerin kaydedilmesi ve üretim sistemlerine ve verilerine kontrollü erişim dâhil olmak üzere, normal operasyonlar sırasında geçerli olan aynı genel güvenlik ilkelerine tabi olarak gerçekleştirilir.
6. Yedekleme ve Veri Koruması Özeti
6.1 Veritabanı Yedekleri. Aurora otomatik yedekleri şifrelenir ve yedi (7) gün boyunca saklanır; bu saklama süresi içinde belirli bir zamana geri yükleme mümkündür.
6.2 S3 Koruması. Amazon S3, depolanan nesneler için yüksek dayanıklılık sağlar. Değiştirilebilir müşteri verisi bucket’ları, birincil bölgedeki dayanıklılığa ve sürüm oluşturmaya dayanır. ProcessMind şu anda bu bucket’lar için bölgeler arası S3 çoğaltmasını etkinleştirmemektedir.
6.3 Günlükler ve Tanılama. Merkezi günlükler, alarmlar ve telemetri; arıza incelemesini ve kurtarmanın doğrulanmasını destekler. Bu mekanizmalar iş sürekliliği operasyonlarını destekler, ancak kendileri ayrı bir yedekleme ürünü olarak sunulmaz.
7. Olayların Belirlenmesi ve Önceliklendirilmesi
7.1 İlk Değerlendirme. Bildirilen olaylar; Güvenlik Olayı tanımına girip girmediklerini, hangi sistemlerin veya verilerin etkilenmiş olabileceğini, muhtemel kapsam ve ciddiyeti ve derhâl kontrol altına alma gerekip gerekmediğini belirlemek üzere önceliklendirilir. Kanıtların korunması, olayın niteliğine ve ilgili sistemlere uygun şekilde ele alınır.
7.2 Nöbetçi Destek ve Üst Makama Bildirim. ProcessMind, üretim ortamındaki olaylar için nöbetçi destek sağlar; buna, olayların her zaman kabul edilip önceliklendirilebilmesi için Kritik olaylarda (Hizmet Seviyesi Sözleşmesi’nde tanımlandığı üzere) 7/24 destek de dâhildir.
7.3 Belgelendirme. ProcessMind, olay zaman çizelgesinin ve bunun sonucunda alınan düzeltici önlemlerin olaydan sonra incelenebilmesi için önemli inceleme bulgularını, müdahale eylemlerini ve kurtarma kararlarını belgeler.
8. İletişim ve Bildirim
8.1 İç İletişim. ProcessMind, teknik müdahalenin ve müşteri iletişiminin olayın tüm yaşam döngüsü boyunca uyumlu kalmasını sağlamak üzere müdahale ekiplerini, karar vericileri ve destek kanallarını koordine eder.
8.2 Müşterilere Bildirim. DPA veya yürürlükteki mevzuat uyarınca bildirim gerektiren bir Güvenlik Olayı meydana gelmesi hâlinde ProcessMind, etkilenen müşterileri gereksiz gecikme olmaksızın ve mümkün olduğu durumlarda olaydan haberdar olmasından itibaren yetmiş iki (72) saat içinde bilgilendirir. Bildirimler genellikle olayın niteliğini ve kapsamını, biliniyorsa etkilenen veri kategorilerini, olayı kontrol altına almak ve gidermek için alınan önlemleri ve ilgili olduğu durumlarda müşterilere önerilen eylemleri içerir.
8.3 Süregelen Güncellemeler. Olay devam ediyorsa veya önemli olgular değişiyorsa ProcessMind, doğrulanmış ek bilgiler elde edildikçe takip güncellemeleri sağlar. Daha geniş kapsamlı üretim hizmeti kesintileri için ProcessMind, müşteri destek kanallarını ve uygun olduğu durumlarda processmind.com/status adresindeki herkese açık durum sayfasını da kullanabilir.
9. Test, Gözden Geçirme ve Bakım
ProcessMind, bu prosedürleri en az yılda bir kez ve önemli olaylardan veya kayda değer mimari değişikliklerden sonra gözden geçirir; müdahale ve kurtarma yaklaşımının ilgili unsurlarını (yedeklerin geri yüklenmesi, dağıtımın yeniden oluşturulması, izleme, uyarı ve olay iletişimi gibi) periyodik olarak tatbik eder ve çıkarılan dersleri güvenlik, güvenilirlik ve iş sürekliliği prosedürlerine dâhil eder.
10. Sınırlamalar ve Sözleşmesel Sınırlar
Bu belge üst düzey bir özettir ve her bir iç operasyon kılavuzunu, üst makama bildirim yolunu, inceleme yöntemini veya kanıt işleme adımını operasyonel ayrıntılarıyla açıklamaz. Bu belge, geçerli sözleşmede veya siparişte açıkça belirtilenlerin ötesinde ayrı bir bölgeler arası yük devretme tasarımı, değiştirilebilir tüm bucket’lar için değiştirilemez depolama saklama süresi veya bağımsız RTO/RPO garantileri taahhüt etmez.
Bu belge ile geçerli Müşteri Sözleşmesi, Veri İşleme Eki, Hizmet Seviyesi Sözleşmesi veya emredici mevzuat arasında herhangi bir çelişki olması hâlinde, söz konusu kaynaklar esas alınır.