Harness kesinti geçmişi

1. 27 Ekim 2026 19:52 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 27 Ekim 2026 19:58 UTCinvestigating

   VM altyapısı üzerindeki CI boru hatları ilk adımda başarısız oluyor çünkü görev amaçlanan havuz dışındaki bir delegeye gidiyor

3. 27 Ekim 2026 21:15 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

4. 27 Ekim 2026 22:16 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

5. 27 Ekim 2026 22:24 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 19 Ekim 2026 07:46 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 19 Ekim 2026 08:02 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 19 Ekim 2026 08:04 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 19 Ekim 2026 08:21 UTCresolved

   Bu olay çözüldü.

5. 23 Ekim 2026 18:21 UTCpostmortem

   # **Summary** 19 Ekim 2026'da yaklaşık 12:10 AM ve 12:55 AM PDT arasında, Prod4'teki müşteriler Harness Borularının servislerinin ayrılmazlığını yaşadılar. Ağır boru hatları infazları, CPU'da keskin bir artış sürdü ve kanal servisinde bellek kullanımı ve kısa bir süre boyunca tüm servis örnekleri mevcut değildi. Harness mühendisliği hem dikey hem de yatay olarak hizmet eden hizmeti ölçeklendirmektedir. Altta yatan davranış için bir düzeltme ortaya çıkıyor. # **Root Cause** 19 Ekim'de, çok büyük yürütme grafiklerle yüksek sayıda koncurrent infaz, küme kaynaklarında keskin bir artış sürdü. Servis mağazaları ve bu tam uygulama grafiği görselleştirme amaçlı alır ve boru hatlarının bir sonraki devletlere daha da ilerlemektedir. Prod4'teki oto-scalaersimiz, CPU ve hafızadaki keskin bir artış nedeniyle her zamankinden daha uzun sürdü. Düzeltmenin bir parçası olarak, uygulama grafiği güncelleştirmesi şimdi grafik değişiklikleri tam grafik yerine artacaktır. Bir aşamada yapılır ve en erkenden tamamen çıkarılacaktır. # **Impact** * Etkilenen kullanıcılar: Prod4 müşterileri. * Symptom: Harness platformunda boru hattı işlevselliğinin yetersizliği. * Veri: Veri kaybı yok. * Önerilen çalışmalar devam etti: Müşterilerden hiçbiri gerekli değil. Harness mühendisliği sorunu çözdü. * Etki süresi: 25 dakika boyunca tam uygun olmayan ve bozulan performansın yaklaşık 20 dakikası. Harness kurtarmadan sonra izlemeye devam etti ve platform istikrarı müşterileri ile doğruladı. # **R protectedation** **Immediate** Harness mühendisliği hem dikey olarak hem de yatay olarak \ (örneğin daha fazla kaynak) ve yatay olarak \ (daha fazla durumda) ve sağlıksız bir durumda örnekleri kaldırdı. Örnek sayımı stabilize edildi ve normal hizmet restore edildi. Sistem, düzeltmeye kadar ölçeklendirilecektir. **Permanent Fix and Action Elements** Bu tür sorunların tekrar gerçekleşmesini önlemek için, Harness 1. Otomatik iyileştirici/scaling sürecini tamamlamak, bu yüzden bu etki hiçbir şeye eşit değildir. 2. Uygulama grafiği akışını optimize etmek, böylece büyük grafikler daha hızlı bir şekilde işlemlenebilir.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 15 Ekim 2026 10:10 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 15 Ekim 2026 10:10 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 15 Ekim 2026 10:27 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 15 Ekim 2026 08:04 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 15 Ekim 2026 08:05 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 15 Ekim 2026 08:09 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 15 Ekim 2026 08:15 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 13 Ekim 2026 01:06 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 13 Ekim 2026 01:07 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 13 Ekim 2026 01:56 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 13 Ekim 2026 04:29 UTCresolved

   Bu olay çözüldü.

5. 23 Ekim 2026 03:16 UTCpostmortem

   . .

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 12 Ekim 2026 15:25 UTCinvestigating

   Şu anda, Harness Cloud'un Maven Central'a erişebileceğine dair HTTP 429 (eski-limiting) hataları yaşıyoruz ve bu da yürütmeyi etkileyebilir. Ekibimiz, sorunu mümkün olduğunca çabuk çözmek için Sonatype ile aktif olarak çalışıyor. İlerleme yaptığımız gibi daha fazla güncelleme sağlayacağız.

2. 12 Ekim 2026 19:31 UTCresolved

   Bu olay çözüldü.

3. 23 Ekim 2026 03:06 UTCpostmortem

   tldr: \(Tldr merkezi tarafından kısıtlanmış kısa bir oran vardı) Takip etmek için daha fazla ayrıntı

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 8 Ekim 2026 10:23 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

2. 8 Ekim 2026 10:53 UTCresolved

   Bu olay çözüldü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Ekim 2026 21:46 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 6 Ekim 2026 21:47 UTCinvestigating

   Bu konuyu araştırmaya devam ediyoruz.

3. 6 Ekim 2026 22:03 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

4. 6 Ekim 2026 22:30 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

5. 6 Ekim 2026 22:30 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz. Bu konuyu düzeltmenin bir kanıtı var.

6. 6 Ekim 2026 22:44 UTCresolved

   Bu olay çözüldü.

7. 23 Ekim 2026 02:12 UTCpostmortem

   # 1. Özet 6 Ekim 2026'da, bir IaCM aşaması içeren boru hatları yaklaşık iki saat boyunca Prod1'de başlayamadı. Etkilenen kullanıcılar, boru hattının infaz planını yaratmaya çalıştığı bir hata gördü. IaCM aşamasını kullanmayanlar normalde boyunca koşmaya devam etti. Altta yatan neden IaCM sahne infazını idare eden hizmette içsel bir giriş hatasıydı: belirli, nadir bir zamanlama koşulu altında, bu hizmetin kendi günlük sistemi, son zamanlarda kendini beklemeye devam edebilir, bu da boru yürütme planlarını hazırlamaktan sorumlu süreci daha genişledi. Sorun, bir müşteri boru hattından alışılmadık derecede büyük bir log aktivitesinin patlamasıyla tetiklendi. Hizmeti önceki stabil versiyonuna geri döndürerek acil etkiyi çözdük ve kalıcı bir kod düzeltmesi şu anda testte. # 2 Etkisi * Prod1'de bir IaCM aşamasını kullanan tüm boru hatları yaklaşık iki saat boyunca başlamadı. * Prod1 kümesindeki çoklu müşteriler etkilendi. * Bir IaCM aşaması kullanmayanlar etkilenmedi ve normalde koşmaya devam etti. * Bu olayın sonucu olarak hiçbir veri kaybedilmedi. *Bu olayı çözmek için kullanılan geri dönüşün bir yan etkisi olarak, bir müşteri için ilgili olmayan bir düzeltme (belirli bir doğrulama token uzun süren boru hatları sırasında geçerli kalmasının ardından) geçici olarak geri alındı. Bu düzeltme aynı akşam tekrar alındı. # 3. Kök Sebep IaCM boru hatları aşamalarından sorumlu olan hizmet, faaliyetlerini içsel bir kuyrukla kaydeder: giriş mesajları kuyrukta yerleştirilir ve tek bir arka plan işçisi ondan sürekli okur ve mesajları yazıyor. Ayrı bir şekilde, bu hizmet, belirli günlük mesajların ciddiyetini aynı kuyrukta yeniden yazabilecek bir filtreye sahiptir. Belirli bir süre içinde, dar zamanlama koşulu altında, bu ölü bir kilit yarattı, kuyruk tam şu anda yeniden yazılmış bir mesaj geri gönderilmekte olsaydı, kuyrukta boş yere yer almaktan sorumlu bir işçi kendini asla çözemezdi, çünkü o alanı özgürleştirebilecek tek şey buydu. Bu gerçekleştikten sonra, bir IaCM aşamasını kullanarak herhangi bir boru hattı için başarısız olan bir boru hattına basılması gereken hizmetin diğer kısmı da sıkı bir şekilde beklendi. # 4 Karar * Hizmeti son istikrarlı versiyonuna geri döndürdü, bu da acil olayı çözdü. # 5 Önleyici Eylemler 1. ** Temel kusuru optimize edin**: Kayıt filtresini optimize edin ve ayarlar, böylece bir mesajın şiddetini yeniden yazmak, aynı arka plan işçisinin kuyruğunu yeniden ortaya çıkarmak yerine, ölü koşulu tamamen ortadan kaldırmak için oturum açın. 2. **Gerçeği sağlık üzerine izleme **: Bu iç kuyrukta metrikler ve uyarılar ekleyin, böylece bu kategorideki saturasyon sayfalarımızı müşteri raporlarına güvenmek yerine otomatik olarak arayınız. 3. **Evaluate sınırları ve çok büyük boru hatlarıyla yüksek stres testleri gerçekleştirin**:

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 16 Ekim 2026 10:41 UTCresolved

   7 Ekim 2026'da, 08:00 UTC'den 11:00 UTC (1:30 PM IST'ye kadar), Prod 7 kümedeki bazı boru hatları, Politika'da (OPA) adım değerlendirmeleri gördü.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Ekim 2026 12:54 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

2. 6 Ekim 2026 15:35 UTCresolved

   Bu olay çözüldü.

3. 10 Ekim 2026 01:57 UTCpostmortem

   # ### Özet Prod 2'deki müşteriler, başlangıçta birkaç Verify adımlarının kesintilerini yaşadılar. Etkilenen adımlar, Sürekli Verification'nin (CV\) bir iç Harness hizmetine ulaşamadıktan kısa bir süre sonra başarısız oldu. Sorun, satın alma hizmetinin zamanout ile uyumlu bir şekilde performans ve güvenilirlik geliştirmek için bağlantı havuzunu sunan son bir hizmet güncellemesinden kaynaklanıyor. Hiçbir müşteri verileri kaybedilmedi veya bozulmuştu. ### Müşteri Etkisi CV'yi kullanan müşteriler Prod-2'deki adımları, olay penceresi sırasında geçici bir adım başarısızlık gördü. Başarısızlık oranı düşüktü - infazların çoğunluğu pencere boyunca başarıyla tamamlandı. CV Verify adımlarını kullanmayanlar etkilenmedi. # ## Root Cause Son bir CV servisi güncellemesi, iç bir platform bileşenine bağlantı havuzunu tanıttı, bu bileşenin boş zamanlarından daha uzun süre devam etti. Bağlantılar yeterince sessiz bir şekilde sunucu tarafından kapatıldı; CV servisi bunu tespit etmedi ve bu tür başarısızlıklar için yeniden deneme mantığı yoktu, doğrudan Verify adım başarısızlıkları olarak yüzeye çıkmasına neden oldu. Sorun intermittent idi, çünkü sadece sona erecek kadar boş olan bağlantıları etkiledi. # # ## Bağlantı tutma süresi, alınan hizmetin boş zamanlarında düşmesi azaltıldı. Başarısızlar hemen sıfıra düştü ve bu tür bir adım daha başarısızlıkları herhangi bir üretim ortamında gözlemlendi. ### Next Steps Recurrence önlemek için Harness olacaktır: * **Fix bağlantı adresi:** Varsayılan tutma kabiliyetine sahipti ve bağlantı hataları üzerinde otomatik yeniden deneme etkinleştirdi, böylece stale-connection hataları şeffaf olarak ele alınır. * **Başlangıçta direnç ekleyin:** İç hizmet çağrısı için geri dönüş ile ilgili olarak, Verify adım başlangıçta, bu yüzden izole geçici başarısızlıklar hemen adım hataları olarak yüzeylemez. * ** Uyarılama:** İç bağlantı hataları oranları için gelişmiş izleme.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Ekim 2026 11:58 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 6 Ekim 2026 11:59 UTCinvestigating

   Bu konuyu araştırmaya devam ediyoruz.

3. 6 Ekim 2026 12:24 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

4. 6 Ekim 2026 16:21 UTCresolved

   Bu olay çözüldü.

5. 9 Ekim 2026 18:48 UTCpostmortem

   # # # Özet **Tuesday, 6 Ekim 2026**, **OpenTofu eklentisini kullanan IaCM boru hatları **Prod1**, bir üretim hesabı için geçici olarak başarısız oldu. Aynı boru hattı genellikle yeniden denemeyi başardı, hiçbir yapılandırma değişikliği ile. Tipik başarısız infazlar yaklaşık 90 dakika boyunca koştu. Diğer Harness modülleri geniş ölçüde etkilenmedi. Müşteri veri kaybı raporumuz yok. Token ömrünün içinde tamamlanan boru hatları bu kusur tarafından etkilenmedi. # # # Root Cause IaCM aşamaları, bir saat sonra sona eren doğrulama jetleri. Politika daha sonra uzun bir vadede token'i reddetti, bu yüzden adım zamanı çıktı veya doğrulamadı. Bu bir saatlik ömür sabitlendi. Yaklaşık 90 dakika Runs bir saatlik işareti geçti, bu yüzden başarısızlıklar daha uzun boru hatlarında ortaya çıktı ve genellikle daha kısa bir yeniden denemede temizlendi. Aynı hesaptaki ayrı bir plan hataları, müşteri çalışma alanında belirgin bir kurulumdan geldi ve bu olay dışında. ## Effects * **Ürün alanı:** IaCM boru hatları, OPA sdk ile konuşuyor. * **Müşteri deneyimi: ** gizli enjeksiyondan sonra kesintiler ve kimlik doğrulama başarısızlıkları, yaklaşık bir saatten daha uzun çalışır. * **Environment:** Prod1, bir üretim hesabı * **Data:** Hiçbir veri kaybı rapor edilmedi. ## Remediation * **Immediate:** Etkilenen Prod1 hesabı için bir statü sayfası açın ve eklenti düzeltmesi yapılmışken gözlemlenen başarısızlıkların bir sınıfı için bir Interim IaCM yöneticisi değişikliği gönderdi. * **Permanent:** Shipped an OpenTofu plugin hotfix so token expiry yapılandırılabilir. Üretimde ömür yaklaşık 6 saate yükseltildi, bu yüzden uzun bir boru hattı token yaşamıyor. Sıcak ek QA'da onaylanmıştır ve Prod1'e dağıtıldı. Hasar nedeniyle özür dileriz. Lütfen Harness destek bağlantınıza daha fazla sorunuz varsa ulaşabilirsiniz.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 5 Ekim 2026 22:01 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 5 Ekim 2026 23:50 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 6 Ekim 2026 00:26 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 6 Ekim 2026 00:26 UTCmonitoring

   Daha fazla sorun için izlemeye devam ediyoruz.

5. 6 Ekim 2026 00:39 UTCresolved

   Tamamlanan ve SSO sorunlarını çözdü.

6. 9 Ekim 2026 16:17 UTCpostmortem

   ## Okta Uygulaması SP-Initiated SSO Giriş Başarısızlıkları # Özet 5 Ekim 2026, 18:18 ve 6 Ekim 2026, 00:26 UTC, bazı Harness müşterileri Harness Hosted MCP sunucusuna SAML Single Sign-On \ (SSO\) ile işaret edemiyorlardı. Ana Harness Portal kullanıcı doğrulama tamamen operasyonel kaldı. Etkilenen kullanıcılar giriş hataları gördü ya da işareti tamamlamak yerine geçersiz bir SSO sayfasına yönlendirildi. Sorun, Harness kimlik servisi HarnessID'nin bir versiyonundaki değişiklikleri bozmaya neden oldu. Bunu bir dizi sıcak ekle düzelttik ve SSO girişi tüm etkilenen müşteriler için tamamen restore edildi. # Etkisi Kullanıcılar SAML SSO aracılığıyla Harness MCP'ye kaydoldu. SSO'ya dayanan MCP seansları yenilenmedi, bu yüzden bazı kullanıcılar tekrar imzalamak zorunda kaldı ve olamazdı. MCP'ye ev sahipliği yapmak için dış girişler çoğu olay sırasında çalıştı. Hiçbir müşteri verileri kayboldu ya da maruz kaldı. Okta'daki kendi genel SAML 2.0 uygulama yapılandırmalarını kullanan müşteriler etkilenmedi. # Root Cause 29 Eylül 2026'da Harness uygulamasının güncel bir versiyonu Okta Entegrasyon Ağı'na yayınlandı. Güncelleme, birden fazla cevap kaydetmek için destek ekledi \(ACS\) URL'ler, bu yüzden birçok bölgede Harness çalışan müşteriler bir çağrı URL'den daha fazla yapılandırabilir. Harness, Okta'ya gönderdiği SAML doğrulama isteğinde AssertionConsumerServiceURL değerini içerir. Bu güncellemeden önce, Okta, ek ACS URL'leri yapılandırmaksızın uygulama örnekleri için bu değeri doğrulamadı ve bunun yerine Uygulamanın varsayılan ACS URL'sine geri döndü. Güncellemeden sonra, bu geçerlilik mevcut tüm uygulama örnekleri üzerinde aktif hale geldi, çünkü müşteri hiçbir zaman ek ACS URL oluşturmamıştı. Çünkü talep edilen değer, örneğin kayıtlı listesinde mevcut değildi, Okta bir HTTP 400 hatası geri döndü. Güncellenen uygulama, Okta'nın standart OIN yayın incelemesinden geçti, bu da yayımlanmış entegrasyondaki mevcut yüklemelere karşı geriye dönük doğrulama doğrulamayı içeriyor. Bu değişiklik, herhangi bir ACS URL'leri yapılandırılmamış olan durumlar için geçerli olan davranış değişikliği bu inceleme sırasında yüzeysel değildi, bu yüzden salıverme zamanında müşterilere ulaştı. # Remediation **Immediate Response** Durum sayfasında iki eser yayınlandı: Okta \ (IdP-initiated login\) Harness Okta SSO URL'leri Harness Okta uygulamasında kaydetti. Harness, her rapor edilen müşteriyi doğrudan etkiledi ve işaretlerini doğruladı. **Resolution** Uygulamanın önceki sürüme geri çekilmesi kasıtlı olarak engellendi, çünkü bu sadece bir sonraki sürüme aynı kesintiyi ertelemekti. Her etkilenen müşteri, ACS URL kaydı aracılığıyla engellenmedi ve ACS URL'nin geçerliliğini tekrar yapmak için Okta ile çalışıyoruz, bu yüzden daha önce hiçbir ACS URL’leri yapılandıran örnekleri tam olarak gerekli değildir ve müşteri eylemi gerekmez. # Aksiyon Bu sorunların tekrar gerçekleşmesini önlemek için Harness aşağıdaki aksiyon öğelerini alacaktır 1. Okta ile koşullu ACS URL doğrulamasını geri almak için çalışmak, bu yüzden daha önce hiçbir ACS URL'leri yapılandıran örnekler ve hiçbir müşteri eylemi gerekli değildir. 2. Harness OIN uygulama için Harness belgesi için özel bir yapılandırma kılavuzunu ifade edin, cevap \(ACS\) URL gereksinimleri de dahil. 3. Mevcut müşteri yapılandırmalarına karşı bağımsız bir ön sürüm doğrulama adımı ekleyin, Okta'nın kendi incelemesinin yanı sıra, Okta'nın kendi incelemesine gelecekteki herhangi bir güncelleme için. 4. Migrate kullanıcı doğrulaması Harness ID'ye, bu doğrulama davranışına tamamen bağımlılığı ortadan kaldırır.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 29 Eylül 2026 20:31 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 29 Eylül 2026 20:31 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 29 Eylül 2026 20:57 UTCidentified

   Sadece yayınlanan Harness Okta uygulaması aracılığıyla SP-initiated login için geçerli olan bir sorunu tespit ettik. Bu uygulama için son bir güncellemeden sonra, bu giriş girişimleri, yapılandırılmış SSO URL'si Ek ACS URL'lerden eksik olduğunda bir HTTP 400 hataya geri döndü. Okta'daki General SAML 2.0 konfigürasyonları etkilenmez. Immediate Solutions: IDP-initiated login kullanın. Okta'daki Harness uygulamasından giriş yapın. Ya da Harness SSO URL'nizi yayınlanan Harness Okta uygulamasında ek ACS URL'lerine ekleyin.

4. 2 Ekim 2026 00:33 UTCresolved

   Bu olay çözüldü.

5. 7 Ekim 2026 18:30 UTCpostmortem

   # 1. Özet 29 Eylül 2026'dan başlayarak, Okta Entegrasyon Ağı'nda yayınlanan Harness uygulaması aracılığıyla Harness'a imzalayan müşteriler SP'yi tamamlayamadı. Etkilenen kullanıcılar Okta'dan imzalanmak yerine HTTP 400 hata aldı. Sorun, Okta'nın talep edilen cevap \(ACS\) URL'nin, yayınlanan Harness uygulamasının mevcut kurulumları için nasıl onaylandığının bir değişiklik tarafından tanıtıldı. Çalışma alanları ilk raporunun bir saati içinde yayınlandı ve her etkilenen müşteri engellendi. # 2 Etkisi * Etkisi, yayınlanan Harness uygulamasını kullanarak müşteriler için, Okta Bütünleme Ağı'ndan SP-initiated login için sınırlıydı. Bu girişimler Okta'dan bir HTTP 400 hata geri döndü. * İdP-initiated login, Okta'daki Harness karosından başladı, sürekli çalışmaya devam etti. * Okta'daki kendi genel SAML 2.0 uygulama konfigürasyonunu kullanan müşteriler etkilenmedi. * Hiçbir müşteri verileri kayboldu ya da açığa çıktı. # 3. Kök Sebep 29 Eylül 2026'da Harness uygulamasının güncel bir versiyonu Okta Entegrasyon Ağı'na yayınlandı. Güncelleme, birden fazla cevap kaydetmek için destek ekledi \(ACS\) URL'ler, bu yüzden birçok bölgede Harness çalışan müşteriler bir çağrı URL'den daha fazla yapılandırabilir. Harness, Okta'ya gönderdiği SAML doğrulama isteğinde AssertionConsumerServiceURL değerini içerir. Bu güncellemeden önce, Okta, ek ACS URL'leri yapılandıran uygulama örnekleri için bu değeri doğrulamadı ve sadece SAML iddiasını uygulama varsayılan ACS URL'ye geri döndü. Güncellemeden sonra, bu geçerlilik, müşterinin hiçbir zaman ek ACS URL'yi yapılandırdığı tüm uygulama örnekleri üzerinde aktif hale geldi. Çünkü talep edilen değer, örneğin kayıtlı listesinde mevcut değildi, Okta doğrulama talebini HTTP 400 hatasıyla reddetti. Güncellenen uygulama Okta'nın standart OIN yayın incelemesi aracılığıyla gitti, bu da yayımlanmış bir entegrasyondaki mevcut yüklemelere karşı geri uyumluluk doğrulamayı içeriyor. Bu değişiklik, bu inceleme sırasında hiçbir ACS URL'leri yapılandırılmamış olan durumlar için geçerli olan davranışlar için geçerli değildi, bu yüzden salıverilen müşterilere ulaştı. # 4 Remediation **Immediate Response** Durum sayfasında iki eser yayınlandı: Okta \ (IdP-initiated login\) Harness Okta SSO URL'leri Harness Okta uygulaması alanından kayıt. Her etkilenen müşteriyi doğrudan destekleyen ve onlarla işaret doğrulama. **Resolution** Uygulamanın önceki sürüme geri çekilmesi kasıtlı olarak engellendi, çünkü bu sadece bir sonraki sürüme aynı kesintiyi ertelemekti. Her etkilenen müşteri, ACS URL kaydı aracılığıyla engellenmedi ve ACS URL'nin geçerliliğini tekrar yapmak için Okta ile çalışıyoruz, bu yüzden daha önce yapılan ek ACS URL'leri yapılandıran örnekler tam olarak gerekli değil. # 5 Aksiyon Maddeleri Bu sorunların tekrar gerçekleşmesini önlemek için, üzerinde çalışıyoruz | **Action Item** | | --- | | Okta ile koşullu ACS URL doğrulamasını geri almak için çalışmak, bu yüzden ek ACS URL'leri yapılandıran örnekler tam olarak daha önce ve müşteri eylemi gerekli değildir. | | Harness OIN uygulama için Harness belgesi için özel bir yapılandırma kılavuzunu ifade edin, cevap \(ACS\) URL gereksinimleri de dahil. | | Mevcut müşteri konfigürasyonlarına karşı herhangi bir gelecek güncelleme için bağımsız bir ön sürüm doğrulama adımı ekleyin, Okta'nın kendi incelemesiyle birlikte. | | Migrate kullanıcı doğrulaması Harness ID'ye, bu geçerlilik davranışına tamamen bağımlılığı ortadan kaldırır. |

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 29 Eylül 2026 18:45 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 29 Eylül 2026 21:55 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 29 Eylül 2026 22:01 UTCresolved

   Bu olay çözüldü.

4. 2 Ekim 2026 22:40 UTCpostmortem

   # ### Özet Yaklaşık **11:37 AM ve 3:01 PM PDT \(18:37-22:01 UTC\) 29 Eylül 2026** arasında, Harness CI'yi ev sahipliği yapan Linux bulut koşucuları **prod1/prod2 \ (us-west1\) **, boru hattı infaz sırasında geçici ağ başarısızlıkları yaşadı - öncelikle kaynak kodu alırken. **Root Cause** Bu öncelikle NAT'ın saturasyonu nedeniyle, geçici bir bulut sağlayıcı hesap kapasitesi tarafından kesintiye uğradı, orada yeni VM düzenlemesini engelledi. # ## Effects * Müşteriler Linux CI'yi bize ev sahipliği yaptı -1'i gördü **Sonmittent inşa / boru hatları hataları**, tam bir kesinti değil. * Gözlemlenen müşteri odaklı hataları, Git zamanlarını, e.g. "Failed to connect to Syhub.com port 443: Bağlantı zamanı çıktı" **R capturedation** * **Immediate:** Rebalanced ARM, merkezi1 \(özellikle de merkezi1 kapasite ile sınırlı), etkilenen Bulut NAT ağ ağlarını yeniden başlattı. **Action Elements ** 1. Güvenli ek NAT Gateway/IP kapasitesi \(In Progress\) 2. NAT saturasyon tespitini geliştirin ve müşteri etkisinden önce uyarılayın. 3. Tek bir bölgenin hesaplama eksikliğini engellemez.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 29 Eylül 2026 14:41 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 29 Eylül 2026 15:54 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 29 Eylül 2026 15:57 UTCmonitoring

   Daha fazla sorun için izlemeye devam ediyoruz.

4. 29 Eylül 2026 18:49 UTCresolved

   Bu olay çözüldü.

5. 2 Ekim 2026 05:37 UTCpostmortem

   **Summary** Prod-2'deki müşteriler sürekli Doğrulama boru hatlarında yüksek başarısızlık oranları yaşadılar. Doğrulama işleri hataları tamamlanmadı, çünkü CV veri toplama işçileri, işlerini koordine eden platform servisiyle iletişim kuramadı. Bu, arka uç sistemlerimizden birine beklenmedik bir trafik artışına neden oldu. Hizmet etkilenen platform bileşeni ölçeklenerek restore edildi. Hiçbir veri kaybı veya yolsuzluk gerçekleşmedi. **Müşteri Etkisi** Prod-2'de Sürekli Doğrulama kullanan müşteriler, olay penceresi sırasında doğrulama boru hatlarının başarısız veya zamanında başarısız olduğunu gördü. Bu dönemde koştuğunuz önemli bir doğrulama işi örneği operasyonel bir başarısızlıkla sona erdi. CV kullanmayan borular normalde çalışmaya devam etti. **Root Cause** Büyük bir otomatik düzenleme çalışması, ortak bir platform bileşeni olan kısa bir pencerede önemli sayıda kalıcı CV izleme çalışanı yarattı. Eş zamanlı aramalarda ani artış, her hizmet örneğinde mevcut ağ bağlantılarını tükenmiştir. **Mitigation** CV hizmeti için maksimum ölçeklendirme sınırı yükseltildi, talep karşılamak için kapasite genişletmesine izin verdi. Başarısızlıklar ölçek bittikten kısa bir süre sonra durduruldu. **Next Steps ** Recurrence önlemek için Harness olacaktır: * **Increase kapasite başı oda ve geçici bekçileri ekleyin:** CV servis ölçeklendirme limitini patlama yükleri altında tutmak ve takip edilen hizmetlerin toplu teslim edilmesi için oranı sınırlamak. * **İmprove Resiliency:** Üstel geri dönüş ve işçi retries için jitter ekleyin ve yüksek koncurrency altında bileşiklemeden geçici başarısızlıkları azaltmak için yeniden uygulanabilir bir bağlantı havuzu kullanın. * ** İzleme ve uyarılama:** Anormal per-account işçi büyüme oranları için uyarı geliştirmek, bu nedenle benzer koşullar tespit edilir ve daha önce hareket eder.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 29 Eylül 2026 13:12 UTCresolved

   28 Eylül 2026'da, ihracat sırasında Harness Filestore'dan gelen dosyaları kopyalamakla ilgili bir sorun gördük, dosyaların çıplak / boş dosyalar olarak kopyalandığı yerde. Sonuç olarak, Filestore API'leri kullanan tüm boru hatları olay penceresi sırasında engellendi. Sorun, konu bir kez keşfedildikten sonra yeniden tekrarlanan bir özel Bayrak rollout nedeniyle kaynaklandı. Tüm işlemler normale geri döndü.

2. 1 Ekim 2026 17:28 UTCpostmortem

   # ### Özet 28 Eylül 2026'da, Prod-2'deki bazı müşteriler File Store içeriklerini boru hatları ifadeleri kullanarak okuyan adımlarda deneyimlediler \(e.g., “\). Etkilenen ifadeler beklenen dosya içeriği yerine null geri döndü, başarısız olmaya veya yanlış davranmaya yol açtı. Sorun, File Store API'leri üzerindeki izinleri sıkılayan bir platform güncellemesine izlendi. Güncelleme geri alındı ve File Store ifadeleri normalde beri çalışıyor. ### Müşteri Etkisi * Yalnızca File Store içeriğini ifadelerle okuyan Prod-2'deki boru hatları adımları etkilendi. File Store ifadelerini kullanmayan boru hatları etkili değildi. * Etkilenen ifadeler null'a karar verdi, yapılandırmaya veya ayarlar dosyalarına bağlı olarak yanlış çıktı üretmek veya üretmek için adımlara neden oldu. * Hiçbir File Store içeriği değiştirildi. Hiçbir dosya, sırlar, kimlikler veya eserler açığa alındı ve hiçbir veri kaybedilmedi. # ## Root Cause Devam eden bir güvenlik inisiyatifinin bir parçası olarak Harness, File Store içeriğine hizmet eden API dahil olmak üzere birkaç platform API'si üzerinde sıkı yetki kontrolleri dağıtmıştı. Bir boru hattı bir File Store ifadesini değerlendirirken, bir iç Harness hizmeti dosyayı almak için başka bir şey çağırır. Yeni yetki kontrolleri başarısız oldu, taleplerin reddedilmesi ve geri dönüş ilanları ile sonuçlandı. # # ## Platform güncelleme nedeni olarak tanımlandıktan sonra, üretim ortamında geri alındı. File Store ifadeleri, rollback'den beri doğru bir şekilde çözdü. Hiçbir müşteri eylemi gerekli değildir. ### Önlemler & Sonraki Adımlar * **Sürücü API'leri etkiledi:** Tüm API'leri katı yetki kontrollerinin iç hizmet hizmetleri aramalarının doğru bir şekilde hesaplanmasını sağlamak için uygulandığını gözden geçirin. * **Profesyonel test kapsamı:** File Store ifade değerlendirme dahil etmek için gelişmiş otomatik test süitleri boru hattı yürütme yolları

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 23 Eylül 2026 20:17 UTCinvestigating

   Şu anda, Palo Alto Networks güvenlik duvarları tarafından korunan müşterileri etkileyen bağlantı sorunlarını araştırıyoruz. Bu duvarlar Harness API'lere bağlantıları engelliyor, bu da sonuçlanabilir: - Başarısız boru hatları infazları - Uygulamaları dağıtma becerisi - Harness platformuna eriştiğinde kesintiler - Üçüncü taraf aletlerle entegrasyon başarısızlıkları - Harness platformu ile Delegate bağlantı Bu sorun bir Harness hizmeti kesintiye neden değildir, ancak ağ tarafında güvenlik kuralları tarafından yerine. Müşterilerin DNS uç noktalarımız için bir istisna yapmasını tavsiye ediyoruz.

2. 24 Eylül 2026 08:43 UTCmonitoring

   Uygunluk: Network Security Policy tarafından Harness Trafik Bloku Bazı müşterilerin Harness'e erişemeyeceği bir sorunu tespit ettik çünkü Harness trafiği, Palo Alto network güvenlik kontrolleri tarafından “AI-Platform” olarak kategorize ediliyor ve daha sonra müşterinin güvenlik duvarı/INET politikası tarafından bloke edildi. Bu sorunu yaşıyorsanız: Lütfen organizasyonunuzun Ağı/Firewall/Cyber Güvenlik ekibi ile iletişime geçin ve gerekli Harness trafiğinin Palo Alto güvenlik politikamız aracılığıyla izin verilmesini talep edin. Bir mitigation olarak, müşteriler “AI-Platform” URL kategorisine gerekli Harness endpointleri için izin verebilir veya etkilenen Harness domains/FQDNs'leri organizasyonlarının onaylanmış/allow listesine ekleyebilir, güvenlik politikalarına uygun olarak. Güvenlik politikası güncellendikten sonra Harness'e erişim restore edilmelidir. Önemli: Güvenlik politikası müşterinin ağ/güvenlik ekibi tarafından yönetilir. Harness endpoint Palo Alto tarafından yanlış kategorize edilmişse, müşteriler Palo Alto Networks'ten URL-kategory incelemesini isteyebilirler.

3. 25 Eylül 2026 17:10 UTCresolved

   Palo Alto Networks ile danışmanlık yaptıktan sonra, 23. 2026 Eylül'de bunu onaylayabiliriz, uygulama.harness. io Palo Alto Networks Team tarafından bir AI Platform Servisi olarak kategorize edildi. Palo Alto Networks, Ağustos ayında yeniden sınıflandırılması hakkında müşterilere bir bildirim gönderdi. Bu değişiklik, AI Platform Servisi'ni uygulama.harness'tan farklı bir politika altında tutabilir. io'nun önceki kuralları kategorileme, Bilgisayar ve İnternet bilgisi. Uygulanan politika müşteri ayarlarına bağlıdır. Harness Müşteriler bu kategoriyi ve iç ağ ekibi ve Palo Alto Networks ile uyarıları tartışmalıdır.

4. 13 Ekim 2026 04:50 UTCpostmortem

   .

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 22 Eylül 2026 16:40 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 22 Eylül 2026 17:14 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 22 Eylül 2026 18:01 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 22 Eylül 2026 18:38 UTCresolved

   Bu olay çözüldü.

5. 2 Ekim 2026 22:05 UTCpostmortem

   # Özet 22 Eylül 2026'da, bir bölgeden gelen ağ geçitlerinin üçü sağlıksız hale geldi ve yeni bağlantı girişimlerinin küçük bir yüzdesi reddetti. Sorun aynı gün problemini tamamen başka bir recurrence veya takip-on etkisi ile çözdü. Altta yatan sebep, bu ağ geçitlerinde doymamış bir iç trafik-monitoring tampondu, bu da sağlık kontrollerine çok yavaş cevap vermek ve belirgin sağlıksız hale gelmekti. # Etkisi * Bir bölgede sadece üç ağ geçidi örneği etkilendi; aynı bölgede diğer bölgeler ve diğer ağ geçitleri etkilenmedi. * Kaliding başarısızlığı yoktu, sorun tek bir ağ geçidi yeniden başlatılmıştı ve sonrasında hiçbir takip konusu olmadı. # Root Cause Outbound ağ geçitlerimiz, operasyonel görünürlük için ağ trafiğini izleyen içsel bir bileşen yönetiyor. Sürekli yüksek trafik altında, bu bileşenin iç tamponu, ağ geçidin kendi sağlık kontrol yanıtlarını zamanımızın ötesinde yavaşlatmak için yeterince şiddetli bir şekilde baskı yarattı. Bu sefer sona erdiğinde, yük bakiyesi etkilenen ağ geçitlerini sağlıksız olarak işaret etti ve onlar için kaderlenen yeni bağlantıların bir kısmını reddetmeye başladı. Actual paketi, olay boyunca normalde çalışmaya devam etti. Bu özellikle bir sağlık kontrol ve izleme-buffer meselesiydi, ağ geçidinin temel ileriye dönük kapasitesinin başarısızlığı değildi. # Karar Üç etkilenen ağ geçidi örneği manuel olarak yeniden başlatıldı, bu da doymamış izleme tamponunu temizledi ve hemen normal sağlık kontrol davranışını restore etti. Bağlantı Reddetleri, yeniden tamamlandığında durdu ve daha fazla müdahale gerekli değildi. # Önleme Eylemleri | **Action** | | --- | | Mevcut trafik izleme yaklaşımını tüm ağ geçitlerinde daha verimli, daha düşük bir uygulama ile değiştirin, bu şekilde aturate yapamaz ve herhangi bir müşteri gözetimi olmadan iyi uyarılar. | | Sabit bir programda uzun süreli ağ geçidi örneklerini uygulama, bu durumda görülen yaşla ilgili bozulma türü bir araya getiremez. | | Migrate ağ destekli altyapıya büyük ölçüde daha özel ağ kapasitesi ile girişli, yüksek bağlantı trafiğini sürdürmek için daha uygun. | | Mevcut izleme tamponun kullanımı daha uzun vadeli bir yedek ortaya çıktığında. | | Özellikle ağ geçidi sağlığı kontrol yanıt gecikmesi konusunda uyarım, müşteri gözetimi haline gelmeden önce erken bozulma belirtileri yakalamak. |

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 22 Eylül 2026 14:00 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

2. 22 Eylül 2026 14:08 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

3. 22 Eylül 2026 14:20 UTCresolved

   Bu olay çözüldü.

4. 2 Ekim 2026 22:10 UTCpostmortem

   Önceki kök nedeni olarak aynı.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 21 Eylül 2026 16:39 UTCinvestigating

   Şu anda bu konuyu araştırıyoruz.

2. 21 Eylül 2026 17:12 UTCidentified

   Sorun tespit edildi ve bir düzeltme uygulanır.

3. 21 Eylül 2026 18:27 UTCmonitoring

   Bir düzeltme uygulandı ve sonuçları takip ediyoruz.

4. 21 Eylül 2026 18:33 UTCresolved

   Bu olay çözüldü.

5. 29 Eylül 2026 22:39 UTCpostmortem

   # # # Özet 21 Eylül 2026'da, Prod 2'deki müşteriler mezun oldu ve sonra yaklaşık üç saat boyunca büyük ölçüde dağıtım paniği yoktu. Sorun, bu panoların arkasındaki bir dizi analitik sorguya neden oldu, ihtiyaç duyduklarından çok daha fazla veri okuyordu, bu veritabanının kapasitelerini onlara hizmet ediyor. Etkilenen servis yenilenmiş panoların tamamen yeniden başlatılması ve platform o zamandan beri stabil olmuştur. ## Müşteri Etkisi Dashboard sayfaları, 14:48 ve 18:11 UTC arasında yavaş veya zamanlanmış. Boru yürütme ve dağıtım kaydı ayrı altyapı üzerinde çalışır ve normalde çalışmaya devam etti. Hiçbir veri kaybı veya yolsuzluk gerçekleşmedi. # # # Root Cause Panel sorguları, en büyük tabloyu haftalık segmentlere bölmek için kullanılan sütunda zaman ayarlı bir filtre eksikti, bu nedenle her bir sorgu yalnızca istenen süre yerine tüm tarihi verileri okudu. Doğruluk asla etkilenmedi - panolar doğru sonuçları geri döndü; sadece onları üretmek için okunan verilerin miktarı aşırıydı. Veri hacmi büyüdükçe, bu okumaların maliyeti veritabanının hizmet edebileceği şeyi aştı ve başarısız sorguların geri çekilmesini sağladı, bu yüzden durum hizmete yeniden başlatılıncaya kadar net değildi. # # * Etkilenen hizmetin yeniden deneme döngüsünü durduran ve veritabanının olağanüstü işlerini tamamlamasına izin veren bir yeniden başlatılmıştı. * Onaylanmış panjur ve veritabanı bağlantısı kullanımı normal seviyelere geri döndü ## Next Steps Recurrence önlemek için Harness olacaktır: * Etkilenen pano sorgularına eksik zaman ayarlı filtre ekleyin, böylece her biri sadece talep edilen dönemi okur. * Bağlantılı, geri dönüşümlü retries * Veritabanı bağlantı kullanımı ve per-query uygulama maliyeti konusunda uyarı ekleyerek algılamayı geliştirin

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.