Uzmanlık · Bakım

Bakım, formun bugün teslim ettiğini bilmek demektir; sunucunun 200 yanıtlaması değil.

Bir isteğin bir insana kadar olan tam yolunu kontrol eden izleme, üretimden önce gate içeren güncellemeler ve her yayımdan sonra çalıştırılan bir kabul kontrolü. Üçü de bu sitede çalışır ve dışarıdan açılabilir.

Bir projeyi konuşalım

Zaten kurduklarımızBu sitenin deposunda yer alan ve hepsi bugün doğrulanabilen üç kendi uygulamamız: `src/app/api/health/contact/route.ts` (teslim sondağı, şu anda canlıda 200 yanıt veriyor), `src/lib/lead-store.ts` (yazarken uygulanan saklama ile append-only günlük) ve `scripts/verify-redesign.ts` (yayından sonra çalıştırılan kabul doğrulaması). Bunları yazdık çünkü 06.09.2026 tarihinde kendi formumuz sessizce çöktü: bot tokenı iptal edilmişti, uç nokta 500 dönüyordu ve istekler iz bırakmadan kayboluyordu. Bu bir satış hikâyesi değil — yukarıdaki dosyaları üreten commit budur.

“Site çalışıyor” ifadesi ana sayfa hakkındadır. Formu doldurup hata alan bir ziyaretçi, çöken bir sayfa tarafından değil, sessizce süresi dolmuş bir teslimat kanalı tarafından durdurulmuştur. İki şey arasındaki fark, ciddi yapılmış bakımın tam olarak ne olduğudur: sunucunun yanıt verip vermediğini değil, bir insandan gelen bir talebin başka bir insana ulaşıp ulaşmadığını izleriz.

6 Eylül 2026 tarihinde bu sitede tam olarak bu oldu. Formdaki talepleri ekibe taşıyan bot tokenı iptal edilmişti; Telegram arayüzü `401 Unauthorized` yanıtlıyordu, bizim rota 500 dönüyordu ve ziyaretçi “mesaj gönderilemedi” görüyordu. Talep hiçbir yere yazılmıyordu. Süreç hata günlüğünde, önceki yayından itibaren geçen yaklaşık yedi saat içinde üç gerçek başarısızlık vardı. Kimse bakmıyordu.

Bundan çıkan şey, şimdi bakımını yaptığımız her projeye yerleştirdiğimiz üç parçadır. Teslimat denemesinden *önce* yazılan append-only günlük; böylece bozuk bir kanal “isteğin hiç var olmaması” yerine “dosyaya bakmamız gerekiyor”a düşer. Bir lead’in şu anda bir insana ulaşıp ulaşamayacağını tek bir istekte yanıtlayan bir sağlık sondası. Ve her yayından sonra çalıştırılan, kanonik bir adres kaybolduysa, bir soru anchor’u yok olduysa ya da site haritasında açılmayan adresler belirdiyse başarısız olan bir kabul doğrulaması.

Geri kalan, sıkıcı ve doğrulanabilir disiplindir: üretime dokunmadan önce bir denetim kapısıyla güncellemeler, bellek eşiği ve kararsız yeniden başlatma sınırıyla otomatik yeniden başlatma, politikada beyan edilmek yerine kodla uygulanan saklama ve bir yere yazılmadan önce IP adreslerinin ağ önekine kadar kesilmesi.

Neleri kapsıyor

Çalışma, bileşenlerine ayrılmış hâliyle

Kullanılabilirliği değil, teslimatı kontrol eden sonda

`GET /api/health/contact`, bir lead şu anda bir insana ulaşabiliyorsa 200, ulaşamıyorsa 503 yanıtlar. İki şeyi ayrı ayrı kontrol eder: bildirim kanalının jetonunun hâlâ geçerli olduğunu (sağlayıcıya 8 saniyelik zaman aşımıyla gerçek bir istek) ve istek günlüğünün yazılabilir olduğunu. Yanıt yalnızca mantıksal değerlerden oluşur — asla jeton, kanal kimliği veya bot adı değil. Sonuç 60 saniye bellekte tutulur, böylece sık bastırılan dış bir sonda kendi başına trafiğe dönüşmez. Sağlayıcıya erişilemiyorsa alan `null` olur, `false` değil: “bilmiyorum” ve “geçersiz” farklı durumlardır.

Teslimattan sonra değil, önce yazılan günlük

Her istek bir kimlik alır ve bir append-only günlüğe, olay başına bir JSON satırı olarak, bildirim denenmeden *önce* yazılır. Aynı kimliğe sahip ikinci satır, gerçekte ne olduğunu söyler: `delivered` veya `failed`, neden 300 karaktere kırpılmış olarak. Dizin `0700` izinleriyle, dosyalar `0600` ile oluşturulur ve yol bilerek sürüm dizininin dışına konur, böylece geçmiş bir yayından sağ çıkabilsin.

Yayından sonra çalıştırılan kabul doğrulaması

Bir doğrulama betiği, her ürün sayfasını üçerli gruplar halinde açar ve 200 kodu, soru ankrası, örnek ankrası ya da kanonik adres eksikse başarısız olur. Ardından site haritasını kontrol eder — açılmayan dil varyantlarını içermemesi ve her ürünü içermesi gerekir — ve `robots.txt` dosyasını, oluşturma için gerekli kaynakları engellememesi için denetler. Ayrıca sayfada eski bir müşteriden içerik yeniden belirdiğinde de başarısız olur. Bu, bir kez zaten bozulmuş şeylerin listesidir.

Kapıyla yapılan güncellemeler, umutla değil

Yayınlama betiği, sunucuda 500 MB’den az boş bellek varsa çalışmayı reddeder, `npm audit --audit-level=high` çalıştırır ve siz açıkça onaylamazsanız yüksek düzeydeki güvenlik açıklarında durur, ardından temiz derleme yapar — `.next` ve `node_modules` silinir, kurulum kilit dosyasından yapılır. Süreç başlatıldıktan sonra `online` görünmezse, betik son 50 günlük satırını gösterir ve başarı bildirmek yerine hata ile çıkar.

Eşiklerle yeniden başlatma, rastgele değil

Süreç, 4 saniyelik denemeler arası gecikme, üstel gecikme artışı ve 10 kararsız yeniden başlatmadan sonra durma ile 500 MB bellek üzerindeyken otomatik olarak yeniden başlatılır — böylece bir çökme döngüsü sunucuyu sessizce tüketmek yerine görünür hale gelir. Durdurma için ek süre: 5 saniye, ardından zorla sonlandırma. Günlükler, tek bir akışta tarih ve saat dilimi içerir.

Çiftler iki kez sayılmaz, işlenir

Aynı kişi, aynı mesaj, iki kez — çift tıklama, sayfa yenileme — tek bir istek için iki özdeş bildirim üretiyordu. Şimdi adres + mesaj çiftinin `sha256` parmak izi 10 dakika boyunca bellekte tutulur; ikinci gönderim aynı istek kimliğini ve `duplicate` işaretini alır, bildirim tekrarlanmaz. Yalnızca başarılı bir teslimatın kopyaları bastırılır; başarısız olanın yeniden geçmesine izin verilir.

Ne kırıldığını söyleyen hata kodları

Geçersiz veriler için 400, yanlış yöntem için 405, bozuk istek gövdesi için 500, teslimat kanalı kötü yanıt verdiğinde 502, kimlik bilgileri eksik olduğunda 503. Fark, sabah 3’te önemlidir: 502 „sağlayıcı” demektir, 503 „bizim yapılandırmamız” demektir. Ziyaretçiye açıkça „isteğinizi aldık, ancak bildirim gönderemedik” denir — sahte bir başarı değil.

Siyasette vaat edilen değil, kodla uygulanan saklama

Yayınlanan gizlilik notu, formdan gelen taleplerin 24 ay saklandığını söyler. Kod tam olarak aynı sayıyı uygular: `LEAD_RETENTION_DAYS` varsayılan olarak 730’dur ve eşiğinden eski dosyalar, unutulabilecek bir zamanlayıcı olmadan her yazmada silinir. IP adresi ağ önekine kırpılır — IPv4 için `/24`, IPv6 için `/48` — ve ilk değil, son atlama başlıktan okunur, çünkü ilki istemci tarafından gönderilir.

Kimsenin şikayet etmediğini de buluyoruz

Aynı kod geçişi, hiçbir kullanıcının bildirmediği iki şeyi ortaya çıkardı: dakikada 10 istek sınırı tamamen aşılabiliyordu, çünkü yönlendirilmiş adresler başlığındaki ilk öğe okunuyordu — istemci tarafından kontrol edilen öğe — ve telefon aramalarını başlatan bir rota anonim olarak, masrafı ve numaramız üzerinden açıktı, oysa onu kullanan bileşen artık hiçbir yere monte edilmemişti. İkisi de düzeltildi ve üretimde doğrulandı.

Nasıl görünüyor

Süreç, adım adım.

Bir isteğin bir insana ulaştığı yolların envanteri

İlk teslimat bir araç değil, bir listedir: bir talep düğmeye basılmasından onu okuyan birine kadar nelerden geçer, her adımda ne kırılır ve kırıldığında ne olması gerekir. Bu sitede listenin üç halkası vardı ve biri görünmezdi.

Sonda ve günlük, başka her şeyden önce kuruldu

Yolu eksiksiz, süreci değil, kontrol eden bir sağlık adresi ve teslimattan önce yazan bir günlük sunuyoruz. Bundan sonra bir çöküş, günlüklerde kazı yapmak değil, yanıtı olan bir sorudur. Adres, hassas hiçbir şey döndürmediği için herhangi bir dış izleme hizmeti tarafından sorgulanabilir.

Gerçek kusurlardan yazılmış kabul kontrolü

Bir kez bozulmuş her şey, yayınlamadan sonra çalışan doğrulama betiğine girer. Varsayımsal durumlar için test yazmayız; zaten bize maliyeti olmuş olanlar için yazarız. Yalnızca sonucu değil, betiğin kendisini de teslim ederiz — siz de çalıştırabilirsiniz.

Güncelleme ritmi ve üretim öncesi gate

Neyin otomatik güncelleneceğini, neyin insan doğrulamasından geçeceğini ve bildirilen bir pencere olmadan neye dokunulmayacağını belirleriz. Gate, bağımlılıkların güvenlik denetimini ve sunucu kaynak doğrulamasını içerir; ikisi de üretime dokunmadan önce çalıştırılır.

Eksik listesiyle teslim

Sonunda yayınlama prosedürünü, geri dönüş prosedürünü, sağlık adreslerini ve kapsanmayanların yazılı listesini teslim ederiz. Bu sitede, örneğin, sağlayıcıya yapılan istek için sonlanma dalı uygulanmıştır ve ağ hatasıyla aynı işlemde düşer, ancak abort’un kendisi testte tetiklenmemiştir — yürütme günlüğünde böyle yazar, dahili bir notta değil.

3 adımda süreç

Veriler

Neye dokunuyoruz, nerede duruyorlar ve ne kadar kalıyorlar

Veri koruma sorumlusu olan herkesin soracağı sorular — o sormadan önce burada sorulmuş hâliyle.

İstek günlüğü: Ad, e-posta adresi, telefon, şirket, seçilen hizmet, mesaj, gönderildiği sayfa, çıkış sayfasının host adı (yalnızca host, tam adres değil) ve ziyaretçinin ağ öne eki. Günde birer JSON dosyası, kendi sunucusunda, sürüm dizininin dışında. Süre: yazıldığı andan itibaren 24 ay.
İşlem ve sunucu günlükleri: İşlemin standart çıktısı ve hataları, tarih ve saat dilimiyle birlikte, ayrıca web sunucusu günlükleri. Burada sessiz bir çöküş görülür: referans olayındaki üç teslim başarısızlığı hata günlüğündeydi, herhangi bir uyarıda değil. Döndürme ve süre her sunucu için belirlenir; bunlar teknik verilerdir, hesap içeriği değildir.
Sunucudan asla çıkmayan şeyler: Jetonlar, kanal tanımlayıcıları ve sağlayıcı anahtarları. Sağlık sondası yalnızca mantıksal değerler döndürür; tam da bu yüzden dış bir araç tarafından hiçbir şey ifşa etmeden çağrılabilir. Bildirimde de aynı kural geçerlidir: mesaj, kimlik bilgileri değil, istek tanımlayıcısını ve sayfayı içerir.
Trafik istatistikleri: Trafik ölçümü, proje üzerinde yapılandırılmış analiz aracı üzerinden geçer ve onaydan sonra etkinleşir. Analiz hesabındaki gerçek saklama ayarı, varsaydığımız değil, hesaptan okuduğumuz bir değerdir — bu sitenin işleme kaydı bunu açıkça netleştirilmesi gereken bir öğe olarak işaretler, belirlenmiş bir olgu olarak değil.
İşleme kaydı: Site tarafından dokunulan her veri türünün, kodla birlikte sürümlenen bir belgede amaç, hukuki dayanak, kategoriler ve süre içeren bir girdisi vardır. Kod bir süreyi değiştirdiğinde, belge de aynı commit’te değişir — aksi halde politika ve program farklı şeyler söyler, ve genellikle hata yapan belgedir.

Bir vaka

500'ü leadler yerine teslim eden bir form, yedi saat

Durum

İletişim formu olan, yeni yayımlanmış bir tanıtım sitesi. Tüm sayfalar 200 döndürüyor, gösterge paneli yeşil, kimse bir şey bildirmiyor. Bir talebin ekibe ulaşabildiği tek kanal, bir mesajlaşma uygulamasındaki bildirimdi.

Ne kurduk

Bildirim botunun jetonu iptal edilmişti; sağlayıcının arayüzü `401 Unauthorized` dönüyordu. Form yolu 500 dönüyor ve hiçbir şey yazmıyordu. İlk düzeltme jeton değil, işlem sırası oldu: istek artık teslim denenmeden *önce*, kendi kimliğiyle, append-only bir günlüğe yazılıyor; teslim sonucu ikinci satır olarak ekleniyor. Bunun üzerine jetonu ve yazılabilirliği kontrol eden bir kamu sağlık sondası, “sağlayıcı kötü yanıt verdi” ile “kimlik bilgilerimiz eksik” için ayrı hata kodları, teslim için 10 saniyelik timeout ve 10 dakikalık bir pencere üzerinde yinelenenlerin bastırılması kuruldu. Aynı kod incelemesi, atlatılabilen bir istek sınırını ve anonim bırakılmış bir telefon çağrıları yolunu da ortaya çıkardı.

Ne çıktı

Sonda artık geçerli jeton ve yazılabilir günlük ile 200 döndürüyor; hiçbir şey ifşa etmeden herhangi bir dış izleme hizmetinden sorgulanabilir. Üretimde yapılan testler her yanıt kodunu kapsadı — 400, 405, 500, 502, 503 — ve iki özdeş gönderim aynı istek tanımlayıcısını döndürdü; ikincisi yinelenen olarak işaretlendi, günlükte dört değil iki satır vardı. Bildirim kanalında gelecekte olacak bir kesinti artık isteği silmiyor: istek, nedeni yazılı halde günlükte kalıyor.

Vakanın söylemedikleri

Sonda, teslimatın artık mümkün olduğunu söylüyor; birilerinin bildirimleri okuduğunu değil. Onlara kimin baktığı ve ne kadar sürede baktığı, kodun değil ekibin kararıdır. Ve sağlayıcıya yapılan istek için sonlanma dalı, uygulanmış olsa da, testte tetiklenmedi — test edilmiş olan ağ hatasıyla aynı işlemde düşüyor; bunu doğrulanmış değil, denenmemiş olarak not ediyoruz.

Sorular

İnsanların aramadan önce bize sordukları

Neyi, somut olarak izliyorsunuz?

Bir isteğin bir insana ulaşma yolunu, sunucu kullanılabilirliğini değil. `GET /api/health/contact`, tek bir istekte iki şeyi kontrol eder: bildirim kanalı jetonunun hâlâ geçerli olduğunu — sağlayıcıya gerçek bir çağrıyla, 8 saniyelik zaman aşımıyla — ve istek günlüğünün yazılabildiğini. İkisi de doğruysa 200, değilse 503 döner. Şimdi bu site üzerinden hemen çağırabilirsiniz: herkese açıktır, çünkü yalnızca mantıksal değerler döndürür.

Neden kimse fark etmeden bir form çöker?

Çünkü görünen kısım çalışmaya devam eder. Sayfa yüklenir, düğme yanıt verir, sunucu tüm sayfalarda 200 döner — yalnızca son halka kopar, onun da arayüzü yoktur. Bu sitede bildirim botunun jetonu iptal edildi: sağlayıcı `401 Unauthorized` yanıt veriyordu, rota 500 dönüyordu ve istek hiçbir yere yazılmıyordu. Yaklaşık yedi saat içinde üç gerçek hata, yalnızca işlem hata günlüğünde görünüyordu. Bu yüzden artık günlüğe kaydetme teslimattan önce yapılıyor: bildirim başarısız olsa bile istek vardır.

Bildirim, onardıktan sonra başarısız olursa ne olur?

İstek zaten kendi kimliğiyle günlüğe yazılmış olur ve günlükteki ikinci satır `failed` ile nedeni belirtir. Ziyaretçiye ayrı bir yanıt verilir — „isteğinizi aldık, ancak bildirim gönderemedik” — sahte bir başarı değil. Yanıt kodu nedeni ayırt eder: 502, sağlayıcının kötü yanıt verdiği anlamına gelir; 503 ise bizde kimlik bilgilerinin eksik olduğu anlamına gelir. Saat 3'te bu iki fark, birini arayıp aramayacağınıza karar verir.

Bağımlılıkları otomatik güncelliyor musunuz?

Gate olmadan değil. Yayınlama `high` düzeyinde `npm audit` çalıştırır ve bu düzeydeki güvenlik açıklarında açıkça devam onayı verilmezse durur; önce sunucunun kullanılabilir belleğini de 500 MB eşiğiyle kontrol eder, çünkü dar bir sunucuda başlatılan bir build uygulamayı kapalı bırakır. Build sıfırdan yapılır: build dizini ve bağımlılıklar silinir, kurulum kilit dosyasından yapılır. Nelerin otomatik güncelleneceği ve nelerin insan kontrolünden geçeceği projeye göre belirlenir, varsayılan değildir.

Bir yayının başka bir şeyi bozmadığını nasıl biliyorsunuz?

Yayın sonrası çalıştırılan bir doğrulama betiğiyle; her ürün sayfasını açar ve 200 kodu, soru ankrası, örnek ankrası ya da kanonik adres eksikse başarısız olur. Ardından site haritasını kontrol eder — her ürünü içermeli ve açılamayan dil sürümlerini içermemelidir — ve `robots.txt`'yi, oluşturma kaynaklarını engellememesi için. Listedeki her kontrol, daha önce bir kez bozulan bir şeye karşılık gelir. Betik proje ile birlikte teslim edilir.

Uygulama kilitlendiğinde veya bellek tükettiğinde ne yapıyorsunuz?

İşlem, 500 MB eşiğinin üzerinde 4 saniye gecikmeyle ve üstel artışla otomatik olarak yeniden başlatılır, ancak kısa bir süre içinde 10 kararsız yeniden başlatmadan sonra durur. Bu önemlidir: sonsuzca yeniden başlayan bir çökme döngüsü bir panoda sağlıklı görünür ve sunucuyu sessizce tüketir. Sürecin kapalı ve görünür kalmasını tercih ederiz.

Form verilerini ne kadar süre saklıyorsunuz ve kimler okuyabilir?

24 ay; kodla uygulanır, yalnızca beyan edilmez: eşik varsayılan değeri 730 gün olan bir değişkendir ve daha eski dosyalar, unutulabilecek bir zamanlayıcı olmadan her yeni yazımda silinir. Dizin `0700` izinlerine, dosyalar `0600` izinlerine sahiptir ve yol sürüm dizininin dışında durur, böylece geçmiş yayından sağ çıksın. IP adresi tam olarak saklanmaz: IPv4 için `/24`, IPv6 için `/48`'e kırpılır; ilk değil, başlıktaki son hop okunur — ilki istemci tarafından gönderilir ve hiçbir anlam ifade etmez.

Bizim şikayet etmediğimiz sorunları da buluyor musunuz?

Oluyor ve genelde pahalı olanlar onlar. Formu düzelten aynı kod incelemesi, kimsenin bildirmediği iki şeyi ortaya çıkardı: yönlendirilmiş adres başlığındaki ilk öğe okunduğu için istek sınırı tamamen aşılabiliyordu — tam da istemcinin gönderdiği öğe; ve telefon çağrıları başlatan bir rota, onu kullanan bileşen sökülmüş olmasına rağmen bizim maliyetimize anonim olarak açıktı. İkisi de düzeltildi ve üretimde doğrulandı. Tümünü bulacağımızı vaat edemeyiz; ancak siz istemeseniz bile raporlayacağımızı vaat edebiliriz.

Bakım neleri kapsamaz?

7/24 izleme yapan bir güvenlik hizmeti değildir ve bir operasyon merkezi değildir. Bunu destekleyecek bir ölçüm olmadan bir erişilebilirlik yüzdesi garanti etmeyiz — ve açık söylemek gerekirse, şu anda kendi sitemiz için böyle bir sayı yayımlamıyoruz. Erişimi olmayan üçüncü taraf bir platformun sorumluluğunu üstlenmeyiz. Ve 200 dönen bir sayfayı her şey yolunda diye kanıt saymayız: yukarıda yazılan her şeyin başladığı sorun tam olarak buydu.

Yukarıdaki iddialar neye dayanıyor (13 kaynak)

Teslim sondası üretimde 200 yanıt veriyor: `{"ok":true,"telegram":{"configured":true,"credentialsValid":true},"leadJournal":{"writable":true}}`https://www.megapromoting.com/api/health/contact · 2026-09-06
Üretimde aktif güvenlik başlıkları: HSTS `max-age=63072000; includeSubDomains; preload`, `X-Content-Type-Options: nosniff`, `X-Frame-Options: SAMEORIGIN`, `Referrer-Policy: strict-origin-when-cross-origin`, `Permissions-Policy` ile `microphone=(self)`https://www.megapromoting.com/servicii · 2026-09-06

Bunlardan 11 tanesi depolarımızdaki kod ve dosyalardır. Adlarını ya da satırlarını yayımlamıyoruz: hepsi bir arada, tek bir sayfada, yalnızca bize ait olmayan sistemlerin nasıl kurulduğunu fazla net anlatırdı. İstek üzerine, depoda sizinle birlikte gözden geçiriyoruz — doğrulama hâlâ mümkün, sadece bir görüşme içinde yapılıyor.

Nasıl çalışıyoruz Tüm hizmetler

Neyin daha iyi çalışmasını isterdiniz?

Bize sürecinizi anlatın. Neyin kurulmaya değer olduğuna, neyi bağlayabileceğimize ve sonucu nasıl doğrulayacağımıza birlikte karar verelim.

Hadi konuşalım