Kritik sistem güncellemeleri ve canlıya alma süreçleri öncesinde risk değerlendirmesi, test kontrol listesi ve geri alma planı oluşturmak.
Aşağıdaki yazılım değişikliği için canlıya çıkış (Production Deployment) risk analizi ve hazırlık kontrol listesi oluştur:
Değişiklik Kapsamı: [DEGISIKLIKLER_DATABASE_API_FRONTEND]
Etkilenen Sistemler: [SISTEMLER]
Planlanan Dağıtım Saati: [ZAMAN]
Çıktı Planı:
1. Risk Seviyesi Değerlendirmesi (Yüksek / Orta / Düşük ve nedenleri)
2. Dağıtım Öncesi Kontrol Listesi (Pre-deployment Checklist)
3. Dağıtım Adımları (Sıralı komutlar ve migration akışı)
4. Doğrulama ve Sağlık Kontrolleri (Smoke Test & Health Checks)
5. Geri Alma Planı (Rollback Strategy): Beklenmedik bir arıza durumunda veri kaybı olmadan eski sürüme dönüş adımları.
Aşağıdaki yazılım değişikliği için canlıya çıkış (Production Deployment) risk analizi ve hazırlık kontrol listesi oluştur:
Değişiklik Kapsamı: [DEGISIKLIKLER_DATABASE_API_FRONTEND]
Etkilenen Sistemler: [SISTEMLER]
Planlanan Dağıtım Saati: [ZAMAN]
Çıktı Planı:
1. Risk Seviyesi Değerlendirmesi (Yüksek / Orta / Düşük ve nedenleri)
2. Dağıtım Öncesi Kontrol Listesi (Pre-deployment Checklist)
3. Dağıtım Adımları (Sıralı komutlar ve migration akışı)
4. Doğrulama ve Sağlık Kontrolleri (Smoke Test & Health Checks)
5. Geri Alma Planı (Rollback Strategy): Beklenmedik bir arıza durumunda veri kaybı olmadan eski sürüme dönüş adımları.
1. Risk Seviyesi: YÜKSEK (Veritabanı şema değişikliği ve ödeme altyapısı içeriyor).
2. Dağıtım Öncesi:
- Tam veritabanı yedeği alındı mı?
- Staging ortamında test senaryoları geçti mi?
- API token ve gizli anahtarlar güncellendi mi?
3. Rollback Planı:
- Veritabanı için ters migration (down) scripti hazır.
- Önceki Docker imaj etiketi (image tag) hazır tutuluyor.
Yavaş çalışan karmaşık SQL sorgularını analiz ederek indeksleme stratejileri ve sorgu yeniden yazımı (query rewrite) ile optimize etmek.
Aşağıdaki yavaş çalışan SQL sorgusunu ve veritabanı şemasını optimize et:
Veritabanı Türü: [MYSQL_POSTGRESQL_ORACLE_MSSQL]
Sorgu:
```sql
[SQL_SORGU]
```
Tablo Boyutları ve Mevcut İndeksler: [TABLOLAR_INDEKSLER]
Optimizasyon Raporu:
1. Darboğaz Analizi: Sorgunun neden yavaş çalıştığı (Full table scan, geçici tablolar, filesort vb.)
2. Önerilen İndeksler (B-Tree, Composite Index tanımları)
3. Yeniden Yazılmış Optimize SQL (Query Rewrite)
4. EXPLAIN Plan İnceleme Kılavuzu: Hangi satırların kontrol edilmesi gerektiği
5. Canlıya Alırken Dikkat Edilecek Kilitlenme (Locking) Riskleri.
Aşağıdaki yavaş çalışan SQL sorgusunu ve veritabanı şemasını optimize et:
Veritabanı Türü: [MYSQL_POSTGRESQL_ORACLE_MSSQL]
Sorgu:
```sql
[SQL_SORGU]
```
Tablo Boyutları ve Mevcut İndeksler: [TABLOLAR_INDEKSLER]
Optimizasyon Raporu:
1. Darboğaz Analizi: Sorgunun neden yavaş çalıştığı (Full table scan, geçici tablolar, filesort vb.)
2. Önerilen İndeksler (B-Tree, Composite Index tanımları)
3. Yeniden Yazılmış Optimize SQL (Query Rewrite)
4. EXPLAIN Plan İnceleme Kılavuzu: Hangi satırların kontrol edilmesi gerektiği
5. Canlıya Alırken Dikkat Edilecek Kilitlenme (Locking) Riskleri.
1. Darboğaz: `created_at` üzerinde indeks olmadığından 2 milyon satırlık `orders` tablosunda Full Table Scan yapılıyor.
2. İndeks Önerisi:
CREATE INDEX idx_orders_created_user ON orders(created_at, user_id);
3. Optimize SQL:
SELECT o.id, o.total_price, u.name
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE o.created_at >= '2026-01-01';
QA test uzmanları ve kullanıcılar için geliştiricilerin hatayı hızla yeniden üretebileceği standart Jira/GitHub bug raporları hazırlamak.
Aşağıdaki teknik hata için Jira / GitHub standartlarında profesyonel bir Hata Raporu (Bug Report) oluştur:
Hata Özeti: [HATA]
Çalışma Ortamı (OS, Tarayıcı, Versiyon): [ORTAM]
Gerçekleşen Hata Durumu: [GERCEKLESEN]
Beklenen Normal Davranış: [BEKLENEN]
Rapor Formatı:
- Başlık: [Modül Adı] Kısa ve Net Problem Tanımı
- Öncelik ve Şiddet Seviyesi (Severity / Priority)
- Yeniden Üretme Adımları (Steps to Reproduce - Numaralı)
- Gerçekleşen Sonuç vs. Beklenen Sonuç
- İlgili Log / Hata Çıktısı Alanı
- Olası Kök Neden Tahmini (Geliştiriciye ipucu)
Aşağıdaki teknik hata için Jira / GitHub standartlarında profesyonel bir Hata Raporu (Bug Report) oluştur:
Hata Özeti: [HATA]
Çalışma Ortamı (OS, Tarayıcı, Versiyon): [ORTAM]
Gerçekleşen Hata Durumu: [GERCEKLESEN]
Beklenen Normal Davranış: [BEKLENEN]
Rapor Formatı:
- Başlık: [Modül Adı] Kısa ve Net Problem Tanımı
- Öncelik ve Şiddet Seviyesi (Severity / Priority)
- Yeniden Üretme Adımları (Steps to Reproduce - Numaralı)
- Gerçekleşen Sonuç vs. Beklenen Sonuç
- İlgili Log / Hata Çıktısı Alanı
- Olası Kök Neden Tahmini (Geliştiriciye ipucu)
Title: [Auth/Profile] 500 Server Error on PNG Avatar Upload > 1MB
Severity: High | Priority: P2
Steps to Reproduce:
1. Go to Profile Settings (/profil/duzenle)
2. Select a 1.5MB PNG file
3. Click 'Kaydet'
Actual Result: 500 Server Error.
Expected Result: Image is resized and saved successfully.
Projenin gereksinimlerine göre microservice mimarisi tasarlayan, domain-driven design prensiplerine uygun bir prompt.
Sen deneyimli bir yazılım mimarısın. Şu proje için microservice mimarisi tasarla: [PROJE_AÇIKLAMASI]. Domain-Driven Design prensiplerine uygun bounded context'leri belirle. Her servis için: sorumluluklar, API endpoint'leri, veritabanı şeması, event'ler ve servisler arası iletişim yöntemlerini tanımla.
Sen deneyimli bir yazılım mimarısın. Şu proje için microservice mimarisi tasarla: [PROJE_AÇIKLAMASI]. Domain-Driven Design prensiplerine uygun bounded context'leri belirle. Her servis için: sorumluluklar, API endpoint'leri, veritabanı şeması, event'ler ve servisler arası iletişim yöntemlerini tanımla.
Mimari özet: Sipariş, katalog ve bildirim bounded contextleri ayrıldı. Sipariş servisi kendi veritabanına sahip; olaylar için güvenilir mesaj kuyruğu kullanılıyor. API gateway kimlik doğrulama ve rate limit uyguluyor. Her servis için sorumluluk, endpoint, tablo, domain event ve gözlemlenebilirlik notları tanımlandı. Dağıtım stratejisi: önce staging, sonra kademeli production.
Proje tipine göre optimize, güvenli ve multi-stage Dockerfile oluşturan prompt.
[TEKNOLOJİ] projesi için production-ready, multi-stage Dockerfile oluştur. Security best practice'leri uygula (non-root user, minimal base image). Health check, .dockerignore önerisi ve docker-compose.yml de ekle.
[TEKNOLOJİ] projesi için production-ready, multi-stage Dockerfile oluştur. Security best practice'leri uygula (non-root user, minimal base image). Health check, .dockerignore önerisi ve docker-compose.yml de ekle.
Çıktı: Multi-stage Node.js Dockerfile; builder aşamasında bağımlılık kurulumu, runtime aşamasında dist klasörü ve production bağımlılıkları. Non-root app kullanıcısı, read-only çalışma dizini ve /health healthcheck tanımlı. .dockerignore node_modules ve test çıktısını dışarıda bırakır. Compose dosyası uygulama ve PostgreSQL servislerini health dependency ile başlatır.
OWASP standardına uygun penetrasyon testi rapor şablonu oluşturan prompt.
Bir siber güvenlik uzmanı olarak [SİSTEM_TÜRÜ] için OWASP metodolojisine uygun penetrasyon testi raporu hazırla. Executive summary, vulnerability assessment (CVSS v3.1 puanlama), risk matrisi, technical findings ve remediation planı bölümlerini detaylandır.
Bir siber güvenlik uzmanı olarak [SİSTEM_TÜRÜ] için OWASP metodolojisine uygun penetrasyon testi raporu hazırla. Executive summary, vulnerability assessment (CVSS v3.1 puanlama), risk matrisi, technical findings ve remediation planı bölümlerini detaylandır.
Executive summary: İncelenen web uygulamasında iki yüksek, üç orta ve dört düşük riskli bulgu tespit edildi. CVSS v3.1 ile puanlama yapıldı; en yüksek bulgu yetkilendirme kontrolünün eksikliği. Risk matrisi etki ve olasılığı gösterir. Remediation planı: acil erişim kontrolü, 30 gün içinde güvenli başlıklar, 60 gün içinde sürekli tarama. Kanıtlar hassas veri içermeden eklenir.
Büyük ölçekli veritabanlarında execution plan, karmaşık JOIN ve indeksleme optimizasyonu yapmak.
Sen bir kıdemli veritabanı performans mimarısın. Aşağıdaki karmaşık SQL sorgusunu ve çalışma planını (Execution Plan) optimize et:
Veritabanı Türü: [VERITABANI_TURU]
SQL Sorgusu:
```sql
[SORGU]
```
Tablo İstatistikleri ve İndeksler: [TABLO_BILGISI]
Lütfen şu başlıklarla analiz sun:
1. Execution Plan Analizi ve Maliyet Darboğazları
2. Bileşik İndeks (Composite Index) ve Kapsayan İndeks (Covering Index) Önerileri
3. Query Rewrite: Alt sorguları (Subquery) JOIN veya CTE'ye dönüştürme
4. Benchmark Test Planı (p95 / p99 gecikme süreleri karşılaştırması).
Sen bir kıdemli veritabanı performans mimarısın. Aşağıdaki karmaşık SQL sorgusunu ve çalışma planını (Execution Plan) optimize et:
Veritabanı Türü: [VERITABANI_TURU]
SQL Sorgusu:
```sql
[SORGU]
```
Tablo İstatistikleri ve İndeksler: [TABLO_BILGISI]
Lütfen şu başlıklarla analiz sun:
1. Execution Plan Analizi ve Maliyet Darboğazları
2. Bileşik İndeks (Composite Index) ve Kapsayan İndeks (Covering Index) Önerileri
3. Query Rewrite: Alt sorguları (Subquery) JOIN veya CTE'ye dönüştürme
4. Benchmark Test Planı (p95 / p99 gecikme süreleri karşılaştırması).
1. Execution Plan Analizi: Sorgu orders tablosunda Full Table Scan yapıyor.
2. İndeks Önerisi: CREATE INDEX idx_orders_status_date ON orders(status, created_at INCLUDE(total_amount));
3. Query Rewrite: Gereksiz SELECT * yerine yalnızca ihtiyaç duyulan alanlar seçildi.
Toplam 19 içerikten 13 - 19 arası gösteriliyor•Sayfa 2 / 2
Görsel Çıktı
Prompt alanlarını doldurun
Değerler yalnız bu cihazda promptu hazırlamak için kullanılır.
