Bir entegrasyon aylarca çalışır, sonra bir sabah durur. Kod değişmemiş, veri değişmemiş, yapılandırma aynı. Değişen tek şey takvim.
İlk entegrasyonda bu bir sorun değildir. Sertifika yüklenir, çağrı çalışır, kimse tarihi not etmez — tek bir tarih kendiliğinden akılda kalır.
Üçüncü yılda tablo değişiyor. On beş gelen servis tanımı, farklı karşı taraflar, farklı yenileme döngüleri. Artık akılda kalması gereken şey bir tarih değil bir takvim; o takvimin sahibi yoksa ilk uyarıyı kullanıcı veriyor.
Sertifika ayarının servis tanımındaki yeri
Haricî bir servise yapılan çağrının tanımı yalnız URL’den oluşmuyor. Metot, içerik tipi, başlıklar, parametreler, gövde şablonu ve kimlik doğrulama ayarı aynı kayıtta durur; kimlik doğrulama Basic, Bearer belirteci veya API anahtarı başlığı olarak kurulabilir. Zaman aşımı, yönlendirme takibi ve sertifika doğrulama ayarları da bu tanımın parçası.
Buradaki zorluk teknik değil idari: sertifikanın bitiş tarihini kim izliyor? Ürün, süresi dolan bir sertifikayı kendiliğinden yenilemez. Yenileme kurumun sertifika yönetim süreciyle yürür ve genellikle iki tarafın koordinasyonunu gerektirir.
Sertifika doğrulamasını kapatan seçenek
Bir noktayı açıkça yazmak gerekiyor. Yapılandırmada sertifika doğrulamasını kapatabilen seçenekler bulunuyor. Devreye alma sırasında bir hatayı hızlı geçmek için kapatılan bu ayar, sonra açılmayı beklemeden üretimde kalıyor.
Sonucu düşünüldüğünden büyük: doğrulama kapalıyken çağrı şifreli kanaldan gider ama karşı tarafın gerçekten beklediğiniz taraf olduğu denetlenmez. Devreye alma kontrol listesinde bu yüzden tek satırlık bir madde olmalı — hangi servis tanımlarında doğrulama açık?
Bağlantı hatası ile kimlik hatasını ayırmak
Arıza anında en çok zaman kaybettiren şey yanlış yerde aramak. Sertifika kaynaklı hatalar yetki hatası gibi görünmez; bağlantı seviyesinde başarısızlık olarak kaydedilir. Kimlik doğrulama hatası alıyorsanız kullanıcı ve belirteç tarafına, bağlantı hatası alıyorsanız sertifika ve ağ tarafına bakmak gerekiyor.
Kayıtlar bu ayrımı destekliyor: giden servislerde istek ve yanıt kayıtları, süreler ve hata ayrıntıları tutulur; gelen tanımlarda çağrıyı yayına almadan test edebilirsiniz. Yenileme sonrası testi, üretim akışının çalışmasını bekleyerek yapmayın.
İşleyen bakım düzeni sade:
- Entegrasyon başına sertifika bitiş tarihini bir yere yazın; o yer bir takvim daveti olabilir.
- Bitişten en az bir ay önce hatırlatma kurun; yenileme iki tarafın koordinasyonunu gerektirir.
- Yenilemeden sonra çağrıyı elle test edin.
- Hata durumunda hangi kayda bakılacağını baştan not edin.
Bu konuda bir güvenlik iddiası kurmuyoruz. HTTPS ve sertifika yönetimi bir platformun güvenli olduğunu kanıtlamaz; yalnız çağrının şifreli kanaldan gittiğini ve karşı tarafın doğrulandığını sağlar. Asıl kazanç operasyonel: takvimi bilinen bir bakım işi, sabah sekizde teşhis edilen bir duruştan iyidir.
Bugün yapılabilecek en kısa iş: gelen servis tanımlarınızın listesini çıkarıp yanına iki kolon ekleyin — sertifika bitiş tarihi ve doğrulama açık mı? Bu tabloyu birlikte doldurmak çoğu kurumda bir saatlik bir oturum.