{"id":44244,"date":"2026-08-22T09:08:25","date_gmt":"2026-08-22T06:08:25","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/maliyet-takip-sistemlerindeki-veri-sapmalari-ve-otomasyon-hatalari-set-e-bir-haftalik-sessizlige-nasil-yol-acti\/"},"modified":"2026-08-22T09:09:00","modified_gmt":"2026-08-22T06:09:00","slug":"maliyet-takip-sistemlerindeki-veri-sapmalari-ve-otomasyon-hatalari-set-e-bir-haftalik-sessizlige-nasil-yol-acti","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/maliyet-takip-sistemlerindeki-veri-sapmalari-ve-otomasyon-hatalari-set-e-bir-haftalik-sessizlige-nasil-yol-acti\/","title":{"rendered":"Maliyet Takip Sistemlerindeki Veri Sapmalar\u0131 ve Otomasyon Hatalar\u0131: set -e Bir Haftal\u0131k Sessizli\u011fe Nas\u0131l Yol A\u00e7t\u0131?"},"content":{"rendered":"

Maliyet Takip Sistemlerindeki Veri Sapmalar\u0131 ve Otomasyon Hatalar\u0131: set -e<\/code> Bir Haftal\u0131k Sessizli\u011fe Nas\u0131l Yol A\u00e7t\u0131?<\/h2>\n

Bir maliyet takip sistemi, ger\u00e7ek faturan\u0131n 48 dolar oldu\u011fu bir durumda size 234 dolar g\u00f6sterdi\u011finde ne hissedersiniz? Muhtemelen bir \u015feylerin yanl\u0131\u015f gitti\u011fini d\u00fc\u015f\u00fcn\u00fcrs\u00fcn\u00fcz. \u0130\u015fte tam da bu noktada, bir otomasyon scriptine eklenen basit bir set -e<\/code> komutu, bir haftal\u0131k bir sessizli\u011fe ve kritik maliyet verilerinin kaybolmas\u0131na neden olabilir. Bu makalede, maliyet izleme sistemlerindeki veri sapmalar\u0131n\u0131n nedenlerini, set -e<\/code> gibi komutlar\u0131n beklenmedik etkilerini ve bu t\u00fcr sorunlar\u0131 \u00f6nlemek i\u00e7in uygulanabilecek sa\u011flam hata y\u00f6netimi ve izleme stratejilerini detayl\u0131 bir \u015fekilde ele alaca\u011f\u0131z. Amac\u0131m\u0131z, benzer durumlarla kar\u015f\u0131la\u015fan veya kar\u015f\u0131la\u015fma potansiyeli olan herkes i\u00e7in kapsaml\u0131 bir rehber sunmakt\u0131r.<\/p>\n

Maliyet Takip Sistemlerindeki Veri Sapmalar\u0131 Neden Ortaya \u00c7\u0131kar?<\/h2>\n

Maliyet takip sistemleri, i\u015fletmelerin finansal sa\u011fl\u0131\u011f\u0131n\u0131 anlamalar\u0131 ve optimize etmeleri i\u00e7in hayati \u00f6neme sahiptir. Ancak, bu sistemlerin sundu\u011fu veriler ger\u00e7ekle \u00f6rt\u00fc\u015fmedi\u011finde, b\u00fcy\u00fck problemlere yol a\u00e7abilir. “Sistem 234 dolar g\u00f6sterirken ger\u00e7ek fatura 48 dolard\u0131” senaryosu, veri sapmalar\u0131n\u0131n ne kadar ciddi olabilece\u011fini g\u00f6zler \u00f6n\u00fcne seriyor. Peki, bu t\u00fcr sapmalar neden ortaya \u00e7\u0131kar ve arkas\u0131ndaki temel nedenler nelerdir?<\/p>\n

\u00d6ncelikle, yanl\u0131\u015f veya eksik veri kaynaklar\u0131<\/strong> en yayg\u0131n nedenlerden biridir. Bir maliyet takip sistemi, birden fazla kaynaktan (bulut sa\u011flay\u0131c\u0131 API’leri, dahili veritabanlar\u0131, fatura d\u00f6k\u00fcmleri vb.) veri \u00e7eker. Bu kaynaklardan herhangi birinde bir kesinti, format de\u011fi\u015fikli\u011fi veya yetkilendirme sorunu ya\u015fand\u0131\u011f\u0131nda, sistem yanl\u0131\u015f veya eksik veri toplayabilir. \u00d6rne\u011fin, bir bulut sa\u011flay\u0131c\u0131n\u0131n yeni bir hizmetini do\u011fru \u015fekilde entegre etmeyi unutmak, o hizmete ait maliyetlerin sisteme yans\u0131mamas\u0131na veya yanl\u0131\u015f hesaplanmas\u0131na neden olabilir.<\/p>\n

\u0130kinci olarak, yap\u0131land\u0131rma hatalar\u0131<\/strong> \u00f6nemli bir rol oynar. Maliyet takip sistemleri genellikle karma\u015f\u0131k yap\u0131land\u0131rmalar gerektirir. Yanl\u0131\u015f bir birim d\u00f6n\u00fc\u015f\u00fcm\u00fc (\u00f6rne\u011fin, gigabayt yerine terabayt hesaplamak), yanl\u0131\u015f bir d\u00f6viz kuru uygulamas\u0131 veya belirli bir kayna\u011f\u0131n yanl\u0131\u015f etiketlenmesi, sistemin maliyetleri abartmas\u0131na veya eksik g\u00f6stermesine yol a\u00e7abilir. Bir m\u00fc\u015fterimiz, bulut depolama maliyetlerinin aniden f\u0131rlad\u0131\u011f\u0131n\u0131 fark etti. Yap\u0131lan incelemede, sistemin belirli bir depolama s\u0131n\u0131f\u0131n\u0131 yanl\u0131\u015fl\u0131kla “premium” olarak etiketledi\u011fi ve bu nedenle \u00e7ok daha y\u00fcksek bir birim fiyatla hesaplama yapt\u0131\u011f\u0131 ortaya \u00e7\u0131kt\u0131. Ger\u00e7ekte ise kullan\u0131lan depolama “standart” seviyedeydi ve bu basit yap\u0131land\u0131rma hatas\u0131, y\u00fczlerce dolarl\u0131k bir sapmaya neden olmu\u015ftu.<\/p>\n

\u00dc\u00e7\u00fcnc\u00fc bir neden, birle\u015ftirme ve hesaplama mant\u0131\u011f\u0131 hatalar\u0131d\u0131r<\/strong>. \u00d6zellikle b\u00fcy\u00fck ve da\u011f\u0131t\u0131k sistemlerde, farkl\u0131 hizmetlerden gelen maliyet verilerini do\u011fru bir \u015fekilde birle\u015ftirmek ve toplam maliyeti hesaplamak zor olabilir. Yanl\u0131\u015f bir toplama algoritmas\u0131, yinelenen maliyetlerin birden fazla kez say\u0131lmas\u0131 veya belirli indirimlerin (rezervasyonlar, taahh\u00fctl\u00fc kullan\u0131m indirimleri) do\u011fru \u015fekilde uygulanmamas\u0131, nihai maliyetin ger\u00e7ek de\u011ferinden sapmas\u0131na neden olabilir. Karma\u015f\u0131k bulut faturaland\u0131rma modelleri (\u00f6rne\u011fin, veri transferi, IOPS, CPU saati gibi farkl\u0131 metriklerin birle\u015fimi), bu t\u00fcr mant\u0131k hatalar\u0131na zemin haz\u0131rlayabilir.<\/p>\n

Son olarak, g\u00f6lge maliyetler ve kullan\u0131lmayan kaynaklar<\/strong> da yan\u0131lt\u0131c\u0131 olabilir. Sistem, asl\u0131nda kullan\u0131lmayan ancak hala faturaland\u0131r\u0131lan kaynaklar\u0131 (\u00f6rne\u011fin, durdurulmu\u015f ancak silinmemi\u015f sanal makineler, kullan\u0131lmayan IP adresleri) do\u011fru bir \u015fekilde ay\u0131rt edemedi\u011finde, gereksiz maliyetleri \u015fi\u015firebilir. Bu durum, teknik olarak bir “sapma” olmasa da, ger\u00e7ekte i\u015fletmenin \u00f6dedi\u011fi gereksiz maliyetleri gizleyerek yanl\u0131\u015f bir maliyet alg\u0131s\u0131 yarat\u0131r. Bu t\u00fcr durumlar, genellikle detayl\u0131 bir envanter y\u00f6netimi ve d\u00fczenli denetimlerle ortaya \u00e7\u0131kar\u0131labilir. Maliyet takip sistemlerinin bu t\u00fcr “hayalet” maliyetleri belirleyebilmesi i\u00e7in geli\u015fmi\u015f etiketleme (tagging) ve raporlama yeteneklerine sahip olmas\u0131 gerekmektedir.<\/p>\n

set -e<\/code> Komutu Nedir ve Shell Scripting’deki Rol\u00fc?<\/h2>\n

Shell scripting, otomasyon g\u00f6revleri i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r ve geli\u015ftiricilere, sistem y\u00f6neticilerine zaman kazand\u0131r\u0131r. Ancak, bu scriptlerin beklenmedik hatalarla nas\u0131l ba\u015fa \u00e7\u0131kt\u0131\u011f\u0131, sistemin genel g\u00fcvenilirli\u011fi i\u00e7in kritik \u00f6neme sahiptir. \u0130\u015fte bu noktada set -e<\/code> komutu devreye girer. Peki, bu komut tam olarak ne yapar ve neden bazen iyi niyetli bir \u00e7\u00f6z\u00fcmken bir anda ba\u015f a\u011fr\u0131s\u0131na d\u00f6n\u00fc\u015febilir?<\/p>\n

set -e<\/code>, Bash (ve di\u011fer uyumlu shell’ler) ortam\u0131nda kullan\u0131lan bir se\u00e7enektir. Temel amac\u0131 olduk\u00e7a basittir: bir komutun ba\u015far\u0131s\u0131z olmas\u0131 durumunda (yani, s\u0131f\u0131r olmayan bir \u00e7\u0131k\u0131\u015f koduyla sonlanmas\u0131 durumunda) scriptin hemen sonland\u0131r\u0131lmas\u0131n\u0131 sa\u011flamakt\u0131r. Bu, \u00f6zellikle bir scriptin belirli bir s\u0131raya g\u00f6re ad\u0131mlar\u0131 tamamlamas\u0131 gerekti\u011fi ve \u00f6nceki bir ad\u0131m\u0131n ba\u015far\u0131s\u0131zl\u0131\u011f\u0131n\u0131n sonraki ad\u0131mlar\u0131 anlams\u0131z veya tehlikeli hale getirece\u011fi durumlarda olduk\u00e7a faydal\u0131d\u0131r. Geli\u015ftiriciler, genellikle “e\u011fer bir \u015fey ters giderse, daha fazla zarar vermeden dur” mant\u0131\u011f\u0131yla bu komutu kullan\u0131r.<\/p>\n

\u00d6rne\u011fin, bir veritaban\u0131 yede\u011fi alan bir script d\u00fc\u015f\u00fcn\u00fcn. E\u011fer veritaban\u0131na ba\u011flanma komutu ba\u015far\u0131s\u0131z olursa, yede\u011fi almaya \u00e7al\u0131\u015fman\u0131n bir anlam\u0131 yoktur. set -e<\/code> kullan\u0131ld\u0131\u011f\u0131nda, ba\u011flant\u0131 ba\u015far\u0131s\u0131z oldu\u011funda script hemen durur ve yedekleme i\u015flemi ba\u015flamaz. Bu, hatal\u0131 veya eksik yedeklerin olu\u015fmas\u0131n\u0131 engelleyerek veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korumaya yard\u0131mc\u0131 olur.<\/p>\n

\n
#!\/bin\/bash\nset -e\n\necho \"Veritaban\u0131na ba\u011flan\u0131l\u0131yor...\"\n# Ger\u00e7ekte ba\u015far\u0131s\u0131z olabilecek bir komut \u00f6rne\u011fi\n# ps aux | grep non_existent_process > \/dev\/null\n# Yukar\u0131daki komut bulunamazsa hata verir\n\n# Bu komut bir hata \u00fcretirse, script burada durur.\ngrep \"non_existent_pattern\" \/tmp\/non_existent_file.txt\n\necho \"Ba\u011flant\u0131 ba\u015far\u0131l\u0131, yedekleme ba\u015fl\u0131yor...\"\n# Bu sat\u0131r, \u00f6nceki komut ba\u015far\u0131s\u0131z olursa asla \u00e7al\u0131\u015fmayacak.\n<\/code><\/pre>\n<\/p><\/div>\n
Yukar\u0131daki \u00f6rnekte, grep<\/code> komutu var olmayan bir dosyada arama yapmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131 i\u00e7in hata verecek ve set -e<\/code> nedeniyle script “Ba\u011flant\u0131 ba\u015far\u0131l\u0131, yedekleme ba\u015fl\u0131yor…” sat\u0131r\u0131na asla ula\u015famayacakt\u0131r. Bu, potansiyel bir hatan\u0131n erken fark edilmesini sa\u011flar.<\/p>\n
Ancak, set -e<\/code>‘nin beklenmedik yan etkileri de olabilir. Her s\u0131f\u0131r olmayan \u00e7\u0131k\u0131\u015f kodunun “kritik bir hata” anlam\u0131na gelmedi\u011fi durumlar vard\u0131r. Bazen bir komutun ba\u015far\u0131s\u0131z olmas\u0131 beklenen bir durum olabilir ve scriptin bu durumu ele alarak yoluna devam etmesi gerekebilir. \u00d6rne\u011fin, bir dosyan\u0131n var olup olmad\u0131\u011f\u0131n\u0131 kontrol eden bir komut, dosya yoksa s\u0131f\u0131r olmayan bir \u00e7\u0131k\u0131\u015f kodu verebilir. E\u011fer set -e<\/code> aktifse, bu durum scripti durduracakt\u0131r, oysa scriptin dosya yoksa ba\u015fka bir i\u015flem yapmas\u0131 gerekebilir. Bu gibi durumlarda, set -e<\/code> gereksiz yere scriptin durmas\u0131na neden olarak otomasyon ak\u0131\u015f\u0131n\u0131 kesintiye u\u011fratabilir.<\/p>\n
Bu sebeple, set -e<\/code> kullan\u0131rken dikkatli olmak ve scriptin her bir ad\u0131m\u0131n\u0131n olas\u0131 hata durumlar\u0131n\u0131 iyi analiz etmek \u00f6nemlidir. \u00d6zellikle kritik otomasyon scriptlerinde, set -e<\/code> yerine veya onunla birlikte daha geli\u015fmi\u015f hata yakalama mekanizmalar\u0131 (\u00f6rne\u011fin trap<\/code> komutu veya if [ $? -ne 0 ]<\/code> gibi ko\u015fullu ifadeler) kullanmak, scriptin hem sa\u011flam hem de esnek olmas\u0131n\u0131 sa\u011flayabilir.<\/p>\n
Maliyet Takip Script’inin Sessizli\u011fe B\u00fcr\u00fcnen Hikayesi: Bir Vaka Analizi<\/h2>\n
\u015eimdi, makalenin ba\u015fl\u0131\u011f\u0131ndaki senaryoyu daha derinlemesine inceleyelim: “Maliyet takip sistemim 234 dolar g\u00f6sterirken ger\u00e7ek fatura 48 dolard\u0131. Sonra set -e<\/code> onu bir hafta susturdu.” Bu ifade, bir otomasyon scriptinin nas\u0131l beklenmedik bir \u015fekilde kritik bir hizmeti devre d\u0131\u015f\u0131 b\u0131rakabilece\u011fine dair klasik bir \u00f6rnektir. Bu vaka analizinde, bu sessizli\u011fin ard\u0131ndaki olaylar zincirini ve set -e<\/code>‘nin bu s\u00fcre\u00e7teki rol\u00fcn\u00fc ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n
Senaryomuzda, bir \u015firketin bulut altyap\u0131 maliyetlerini g\u00fcnl\u00fck olarak toplayan ve bir veritaban\u0131na kaydeden basit bir Bash scripti bulunmaktad\u0131r. Bu script, her sabah belirli bir saatte \u00e7al\u0131\u015facak \u015fekilde zamanlanm\u0131\u015f (cron job) ve bulut sa\u011flay\u0131c\u0131n\u0131n API’lerini kullanarak faturaland\u0131rma verilerini \u00e7ekmektedir. Scriptin ba\u015f\u0131nda, hatalar\u0131n erken fark edilip scriptin durdurulmas\u0131 amac\u0131yla set -e<\/code> komutu eklenmi\u015ftir. Bu, geli\u015ftiricinin iyi niyetli bir karar\u0131yd\u0131; herhangi bir ad\u0131mda bir hata olu\u015fursa, yanl\u0131\u015f verilerin i\u015flenmesini veya eksik veriyle ilerlenmesini engellemek istiyordu.<\/p>\n
\n
#!\/bin\/bash\nset -e\n\nLOG_FILE=\"\/var\/log\/cost_monitor.log\"\nAPI_ENDPOINT=\"https:\/\/api.cloudprovider.com\/cost_data\"\nDB_HOST=\"db.internal.network\"\n\necho \"$(date): Maliyet verileri \u00e7ekiliyor...\" >> $LOG_FILE\n\n# 1. API'den verileri \u00e7ek\n# Bu komut, bir network hatas\u0131, API kimlik do\u011frulama sorunu veya API servis kesintisi nedeniyle ba\u015far\u0131s\u0131z olabilir.\ncurl -s --fail \"$API_ENDPOINT\" -H \"Authorization: Bearer $API_TOKEN\" > \/tmp\/cost_data.json\n\necho \"$(date): Veriler ba\u015far\u0131yla \u00e7ekildi, i\u015fleniyor...\" >> $LOG_FILE\n\n# 2. \u00c7ekilen veriyi i\u015fle ve veritaban\u0131na kaydet\n# Bu komut, JSON parse hatas\u0131, veritaban\u0131 ba\u011flant\u0131 sorunu veya SQL hatas\u0131 nedeniyle ba\u015far\u0131s\u0131z olabilir.\npython3 \/opt\/scripts\/process_cost_data.py \/tmp\/cost_data.json \"$DB_HOST\"\n\necho \"$(date): Maliyet verileri ba\u015far\u0131yla veritaban\u0131na kaydedildi.\" >> $LOG_FILE\n<\/code><\/pre>\n<\/p><\/div>\n
Bir g\u00fcn, bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n faturaland\u0131rma API’sinde k\u0131sa s\u00fcreli bir kesinti ya\u015fand\u0131. Script, curl<\/code> komutu ile API’ye ba\u011flanmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, API bir hata kodu (\u00f6rne\u011fin 500 Internal Server Error) d\u00f6nd\u00fcrd\u00fc. curl<\/code> komutunda kullan\u0131lan --fail<\/code> parametresi, HTTP hata kodlar\u0131 d\u00f6nd\u00fc\u011f\u00fcnde curl<\/code>‘\u00fcn s\u0131f\u0131r olmayan bir \u00e7\u0131k\u0131\u015f koduyla sonlanmas\u0131na neden olur. \u0130\u015fte tam bu noktada set -e<\/code> devreye girdi. curl<\/code> komutu ba\u015far\u0131s\u0131z oldu\u011fu i\u00e7in, script hemen durduruldu ve “Veriler ba\u015far\u0131yla \u00e7ekildi, i\u015fleniyor…” ve sonraki sat\u0131rlar asla \u00e7al\u0131\u015fmad\u0131.<\/p>\n
Problem \u015fu ki, scriptin durdurulmas\u0131 hakk\u0131nda herhangi bir bildirim veya uyar\u0131 sistemi mevcut de\u011fildi. Cron job, scriptin \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve bitti\u011fini kaydetti, ancak i\u00e7eri\u011findeki hatay\u0131 veya scriptin erken sonland\u0131\u011f\u0131n\u0131 raporlamad\u0131. Log dosyas\u0131na yaln\u0131zca “Maliyet verileri \u00e7ekiliyor…” mesaj\u0131 yaz\u0131ld\u0131, ancak sonraki ba\u015far\u0131 mesajlar\u0131 eksikti. Kimse scriptin sessizce durdu\u011funu fark etmedi. Bir g\u00fcn, iki g\u00fcn, bir hafta boyunca bu durum devam etti. Her sabah script \u00e7al\u0131\u015ft\u0131, API hatas\u0131 ald\u0131, set -e<\/code> nedeniyle durdu ve kimse bundan haberdar olmad\u0131.<\/p>\n
Sonu\u00e7 olarak, maliyet takip sistemi bir hafta boyunca yeni veri alamad\u0131. Sistemdeki son ba\u015far\u0131l\u0131 veriler bir haftal\u0131k eski verilerdi ve bu da sistemin yanl\u0131\u015f (eski) maliyetleri g\u00f6stermesine neden oldu. Kullan\u0131c\u0131lar, sistemin g\u00f6sterdi\u011fi 234 dolarl\u0131k maliyetin asl\u0131nda g\u00fcncel olmad\u0131\u011f\u0131n\u0131, \u00e7\u00fcnk\u00fc o tarihten sonraki ger\u00e7ek maliyetlerin (48 dolar) sisteme hi\u00e7 ula\u015fmad\u0131\u011f\u0131n\u0131 fark etmediler. Bu durum, hem maliyet kontrol\u00fcnde k\u00f6r noktalar olu\u015fturdu hem de sistemin g\u00fcvenilirli\u011fine olan inanc\u0131 sarst\u0131. Bu vaka, set -e<\/code> gibi g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131n dikkatli kullan\u0131lmas\u0131n\u0131n ve otomasyon s\u00fcre\u00e7lerinin kapsaml\u0131 izleme ve hata y\u00f6netimi stratejileriyle desteklenmesinin ne kadar kritik oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\n
Otomatik Sistemlerde Hata Y\u00f6netimi ve Sa\u011flamla\u015ft\u0131rma Stratejileri<\/h2>\n
Otomatik sistemler, verimlili\u011fi art\u0131r\u0131rken, beklenmedik hatalara kar\u015f\u0131 savunmas\u0131z kalabilirler. Maliyet takip scriptinin bir hafta boyunca sessiz kalmas\u0131, sa\u011flam bir hata y\u00f6netimi stratejisinin ne kadar kritik oldu\u011funu vurgulamaktad\u0131r. Peki, otomasyon scriptlerimizi bu t\u00fcr “sessiz \u00f6l\u00fcmlerden” nas\u0131l koruyabiliriz? \u0130\u015fte baz\u0131 temel stratejiler:<\/p>\n
1. Kapsaml\u0131 Hata Yakalama Mekanizmalar\u0131<\/h3>\n
Sadece set -e<\/code>‘ye g\u00fcvenmek yeterli de\u011fildir. Scriptin belirli b\u00f6l\u00fcmlerinde veya genelinde hatalar\u0131 yakalamak i\u00e7in daha spesifik mekanizmalar kullanmal\u0131y\u0131z. Bash’te trap<\/code> komutu, scriptin belirli sinyalleri (EXIT, ERR, DEBUG gibi) yakalamas\u0131na ve bunlara tepki vermesine olanak tan\u0131r. \u00d6zellikle trap \"hata_fonksiyonu\" ERR<\/code> kullan\u0131m\u0131, scriptin herhangi bir yerinde bir komut s\u0131f\u0131r olmayan bir \u00e7\u0131k\u0131\u015f koduyla sonland\u0131\u011f\u0131nda belirli bir fonksiyonun \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Bu fonksiyon i\u00e7inde hata mesaj\u0131 loglanabilir, bir uyar\u0131 g\u00f6nderilebilir ve scriptin durumu hakk\u0131nda bilgi toplanabilir.<\/p>\n
\n
#!\/bin\/bash\n\nLOG_FILE=\"\/var\/log\/cost_monitor.log\"\n\n# Hata durumunda \u00e7al\u0131\u015facak fonksiyon\nhandle_error() {\n    local last_command=\"${BASH_COMMAND}\"\n    local line_number=\"${BASH_LINENO[0]}\"\n    echo \"$(date): HATA! Script $line_number. sat\u0131rda '$last_command' komutuyla ba\u015far\u0131s\u0131z oldu.\" >> $LOG_FILE\n    # Hata durumunda e-posta veya Slack bildirimi g\u00f6nder\n    # send_alert \"Maliyet Takip Scripti Hatas\u0131\" \"Hata: $last_command, Sat\u0131r: $line_number\"\n    exit 1 # Scripti durdur\n}\n\n# Hata sinyalini yakala ve handle_error fonksiyonunu \u00e7a\u011f\u0131r\ntrap 'handle_error' ERR\n\necho \"$(date): Maliyet verileri \u00e7ekiliyor...\" >> $LOG_FILE\n\n# Hata \u00fcretmesi muhtemel bir komut\ncurl -s --fail \"https:\/\/api.nonexistentcloud.com\/cost_data\" -H \"Authorization: Bearer mytoken\" > \/tmp\/cost_data.json\n\necho \"$(date): Veriler ba\u015far\u0131yla \u00e7ekildi, i\u015fleniyor...\" >> $LOG_FILE\n\n# Bu sat\u0131r, \u00f6nceki komut ba\u015far\u0131l\u0131 olursa \u00e7al\u0131\u015facak\npython3 \/opt\/scripts\/process_cost_data.py \/tmp\/cost_data.json \"db.internal.network\"\n\necho \"$(date): Maliyet verileri ba\u015far\u0131yla veritaban\u0131na kaydedildi.\" >> $LOG_FILE\n<\/code><\/pre>\n<\/p><\/div>\n
Yukar\u0131daki \u00f6rnekte, curl<\/code> komutu ba\u015far\u0131s\u0131z oldu\u011funda handle_error<\/code> fonksiyonu \u00e7al\u0131\u015facak, hata loglanacak ve bir uyar\u0131 mekanizmas\u0131 tetiklenebilecektir.<\/p>\n
2. Tekrar Deneme (Retry) Mant\u0131\u011f\u0131<\/h3>\n
Ge\u00e7ici a\u011f sorunlar\u0131, API kesintileri veya veritaban\u0131 kilitlenmeleri gibi durumlar, genellikle k\u0131sa s\u00fcrelidir. Bir komutun hemen ba\u015far\u0131s\u0131z olmas\u0131 yerine, belirli bir gecikmeyle birka\u00e7 kez daha denemek, scriptin daha dayan\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flar. Bu, \u00f6zellikle d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klara (API’ler, veritabanlar\u0131) dayanan scriptler i\u00e7in hayati \u00f6neme sahiptir. Basit bir for<\/code> d\u00f6ng\u00fcs\u00fc veya while<\/code> d\u00f6ng\u00fcs\u00fc ile tekrar deneme mant\u0131\u011f\u0131 uygulanabilir.<\/p>\n
\n
MAX_RETRIES=5\nRETRY_DELAY=10 # saniye\n\nfor i in $(seq 1 $MAX_RETRIES); do\n    echo \"$(date): API'den veri \u00e7ekme denemesi #$i...\" >> $LOG_FILE\n    if curl -s --fail \"$API_ENDPOINT\" -H \"Authorization: Bearer $API_TOKEN\" > \/tmp\/cost_data.json; then\n        echo \"$(date): API'den veri ba\u015far\u0131yla \u00e7ekildi.\" >> $LOG_FILE\n        break\n    else\n        echo \"$(date): API'den veri \u00e7ekme ba\u015far\u0131s\u0131z oldu. $RETRY_DELAY saniye bekleniyor...\" >> $LOG_FILE\n        sleep $RETRY_DELAY\n    fi\n    if [ \"$i\" -eq \"$MAX_RETRIES\" ]; then\n        echo \"$(date): Maksimum deneme say\u0131s\u0131na ula\u015f\u0131ld\u0131, API'den veri \u00e7ekilemedi.\" >> $LOG_FILE\n        exit 1 # Tamamen ba\u015far\u0131s\u0131z olduysa scripti sonland\u0131r\n    fi\ndone\n<\/code><\/pre>\n<\/p><\/div>\n
3. Kritik Scriptler \u0130\u00e7in \u0130zleme ve Uyar\u0131 Sistemleri<\/h3>\n
Scriptlerin sadece \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 de\u011fil, ayn\u0131 zamanda beklenen \u00e7\u0131kt\u0131y\u0131 \u00fcretip \u00fcretmedi\u011fini de izlemek \u00f6nemlidir. Bir scriptin sessizce durmas\u0131 veya hatal\u0131 veri \u00fcretmesi, izleme sistemleri taraf\u0131ndan fark edilmelidir. Bu, a\u015fa\u011f\u0131daki y\u00f6ntemlerle sa\u011flanabilir:<\/p>\n