Özellik Geri Alma Kararları İçin Web Uygulaması Nasıl Oluşturulur

Uygulamanın Ne Çözmesi Gerekiyor (ve Kim İçin)

Bir “geri alma kararı”, bir ekibin üretimdeki bir değişikliği geri alıp almayacağına karar verdiği andır — bir feature flag'i devre dışı bırakmak, bir dağıtımı geri almak, bir konfigürasyonu geri çekmek veya bir sürümü çekmek gibi. Olayın ortasındayken kulağa basit gelebilir: sinyaller çelişir, sahiplik belirsizdir ve karar alınmayan her dakika bir maliyettir.

Ekipler zorlanır çünkü girdiler dağınıktır. İzleme grafikleri bir araçta, destek talepleri başka bir yerde, dağıtım geçmişi CI/CD'de, feature flag'ler başka bir yerde ve “karar” genellikle aceleyle gönderilmiş bir sohbet dizisidir. Sonra biri “neden geri aldık?” diye sorduğunda kanıt kaybolmuş olur — veya yeniden oluşturmak acı verir.

Uygulamanın hedefi

Bu web uygulamasının hedefi, tek bir yerde şunları sağlamaktır:

• Sinyaller toplanır (metrikler, hata oranları, müşteri etkisi, deney sonuçları).
• Kararlar kaydedilir (ne seçildi, kim onayladı, hangi alternatifler değerlendirildi).
• Eylemler koordine edilir (hangi geri alma adımı uygulandı, ne zaman ve kim tarafından).

Bu, büyük kırmızı bir düğmeyle her şeyi otomatik geri alması gerektiği anlamına gelmez. Varsayılan olarak, bu karar desteğidir: insanların “endişeliyiz”den “kendimizden eminiz”e ortak bağlam ve net bir iş akışıyla geçmesine yardımcı olur. Sonra otomasyon ekleyebilirsiniz; ilk kazanım kafa karışıklığını azaltmak ve hizalanmayı hızlandırmaktır.

Kim için

Bir geri alma kararı birden fazla rolü etkiler, bu yüzden uygulama herkesin aynı görünümde olmasını zorlamadan farklı ihtiyaçlara hizmet etmelidir:

• Mühendislik: ne değiştiğini doğrulamak, mevcut ile önceki davranışı karşılaştırmak, güvenli geri alma adımlarını yürütmek.
• Ürün: kullanıcı etkisini, gelir riskini ve kısmi geri alma (veya flag kapatma) ile hedeflerin karşılanıp karşılanamayacağını değerlendirmek.
• Destek/Başarı: gerçek müşteri raporlarını, önemi ve etkilenen segmentleri sağlamak.
• Ops/SRE: kararlılık, olay müdahalesi ve patlama alanı azaltımı üzerinde odaklanmak.

Bu iyi çalıştığında sadece “daha hızlı geri almaktan” fazlasını yaparsınız. Daha az panik hareketi olur, daha temiz bir denetim izi tutulur ve her üretim korkusu tekrarlanabilir, daha sakin bir karar sürecine dönüşür.

Roller, Sorumluluklar ve Kullanıcı Yolculukları

Bir geri alma karar uygulaması, insanların gerçekte risklere nasıl tepki verdiğini yansıttığında en iyi şekilde çalışır: birisi bir sinyal görür, birisi koordine eder, birisi karar verir ve birisi yürütür. Önce temel rolleri tanımlayın, sonra her kişinin o anda neye ihtiyaç duyduğunu çevreleyen yolculukları tasarlayın.

Birincil roller (ve ihtiyaçları)

Nöbetçi mühendis hıza ve netliğe ihtiyaç duyar: “Ne değişti, ne bozuluyor ve şu anki en güvenli adım nedir?” Öneri sunabilmeli, kanıt ekleyebilmeli ve onay gerekip gerekmediğini görebilmelidir.

Ürün sahibi kullanıcı etkisini ve ödünleşimleri bilmek ister: “Kim etkilendi, ne kadar ciddi ve geri alırsak neler kaybederiz?” Genellikle bağlam (özellik niyeti, rollout planı, iletişim) ekler ve onaylayıcı olabilir.

Olay komutanı koordinasyona ihtiyaç duyar: “Mevcut hipotezde, karar durumunda ve sonraki adımlarda uyumlu muyuz?” Sahipleri atayabilmeli, karar sonu tarihi belirleyebilmeli ve paydaşları senkronize tutabilmelidir.

Onaylayan (mühendislik yöneticisi, sürüm kaptanı, uyumluluk) güven ister: “Bu karar gerekçeli ve tersinir mi, politika ile uyuyor mu?” Kısa bir karar özeti ve destekleyici sinyaller isterler.

Yapılması gereken ana işler (kullanıcı yolculukları)

1. Sorun tespit et: izleme uyarıları, destek biletleri ve dağıtım notları tek bir olay görünümünde toplanır.
2. Etkisini değerlendir: hata oranlarını, etkilenen kohortları ve son değişiklikleri hızla karşılaştır.
3. Karar ver: seçenekler öner (geri al, flag kapat, daha fazla veri bekle) açık gerekçe ile.
4. Yürüt: geri alma veya flag değişikliğini tetikle (veya bir araca devret) ve tamamlanmasını doğrula.
5. Belgele: kim neyi, ne zaman ve neden karar verdiğini ekstra iş yükü olmadan kaydet.

Karmaşayı önleyen izinler

Dört net yetenek tanımlayın: öner, onayla, yürüt, ve görüntüle. Birçok ekip nöbetçidekilerin önerde bulunmasına izin verir, küçük bir grup onaylar ve üretimde yürütme yalnızca sınırlı bir grubun yetkisinde olur.

Tasarlanması gereken ortak başarısızlık noktaları

Çoğu geri alma kararı başı aşağı gider çünkü bağlam dağınık, sahiplik belirsiz ve kayıt/kanıt eksik. Uygulamanız sahipliği açık hale getirmeli, tüm girdileri bir yerde tutmalı ve karar anında bilinenleri kalıcı olarak yakalamalıdır.

Veri Modeli: Özellikler, Sürümler, Olaylar ve Kararlar

Bir geri alma uygulaması, veri modeli ekibinizin gerçekte nasıl yazılım göndermekte ve riski yönetmekte olduğuna uyarsa başarılı olur. Küçük bir net varlık setiyle başlayın, sonra kararları ileride açıklanabilir kılan yapı (taksonomi ve snapshot'lar) ekleyin.

Temel varlıklar (isimler)

En azından şunları modelleyin:

• Feature: değiştirilen şey (genellikle bir flag, konfig veya kod yolu ile bağlı).
• Release: birçok özelliği içerebilen dağıtılabilir paket/sürüm.
• Environment: sürümün çalıştığı yer (prod, staging, bölge, tenant vb.).
• Incident: müşteri etkileyen bir olay veya dahili uyarı kümesi.
• Decision: kaydedilmiş seçim (geri alma, hafifletme, izleme vb.).
• Action: yürütülen işlem (flag devre dışı, commit geri al, yeniden deploy, hotfix).
• Metric Snapshot: karar anında yakalanan kanıt (hata oranı, gecikme, dönüşüm sinyalleri).

Güvenilir ilişkilere dayananlar

Panoların “ne etkilendi?” sorusunu hızla cevaplayabilmesi için ilişkileri açık tutun:

• Feature ↔ Release: çoktan-çoğa (bir feature birden fazla sürümde olabilir; bir sürüm birçok feature içerir).
• Release ↔ Environment: bir sürüm birden fazla ortama dağıtılabilir, farklı zaman damgaları ve sağlık değerleri ile.
• Incident ↔ Decision: genellikle bire-çoğa (bir olay zaman içinde birden fazla kararı tetikleyebilir).
• Decision ↔ Action: bire-çoğa (bir karar birden fazla eylem ve doğrulama gerektirebilir).

Değiştirilemez vs düzenlenebilir veriler

Erken karar verin hangi verinin asla değişmemesi gerektiğine:

• Değiştirilemez: denetim olayları (kim onayladı, ne zaman yürütüldü, önce/sonra değerler, kanıtlara bağlantılar), metrik snapshot'ları.
• Düzenlenebilir: notlar, etiketler, olay özetleri ve isteğe bağlı “gerekçe” yorumları — bunlar sürüm geçmişiyle düzenlenebilir.

Raporlamayı tutarlı tutan taksonomi

Filtrelemeyi tutarlı yapan hafif enum'lar ekleyin:

• Severity (S0–S4), Impact (etkilenen kullanıcılar, gelir riski), Status (open/monitoring/resolved)
• Decision outcome (rollback/disable flag/partial rollout/monitor)
• Reason codes (performans regresyonu, artan hatalar, fatura uyuşmazlığı, UX bozulması, güvenlik endişesi)

Bu yapı hızlı triage panolarını destekler ve post-incident incelemelerinde işe yarayan bir denetim izi oluşturur.

Geri Alma Türleri ve Ekipte “Geri Alma”nın Anlamı

İş akışları ve panolar inşa etmeden önce ekibinizin “geri alma” ile ne kastettiğini tanımlayın. Farklı ekipler aynı kelimeyi çok farklı eylemler için kullanır — çok farklı risk profilleriyle. Uygulamanız geri alma türünü örtük değil, açık hale getirmeli.

Geri alma mekanizmalarını seçin

Çoğu ekibin üç temel mekanizmaya ihtiyacı vardır:

• Önceki sürümü yeniden dağıt: hizmeti veya frontend paketini bilinen iyi artefakta geri almak. Bu geniş kapsamlı, daha yavaş ve ilişkisiz değişiklikleri geri alabilir.
• Feature flag devre dışı bırakma: dağıtımı korurken belirli bir özelliği kapatmak. Flag'ler varsa genellikle en hızlı ve en güvenli yoldur.
• Konfig toggle / kill switch: çalışma zamanı konfigürasyonunu değiştirmek (rate limitler, routing kuralları, öneri ağırlıkları vb.). Flag yoksa faydalıdır ama sebeplerini anlamak ve doğrulamak daha zor olabilir.

UI'da bunları kendi ön koşulları, beklenen etkileri ve doğrulama adımları olan ayrı “eylem tipleri” olarak ele alın.

Ortamlar ve bölgeler sonradan düşünülmemeli

Bir geri alma kararı genellikle nerede sorusuna bağlıdır. Kapsamı açıkça modelleyin:

• Environment: dev/staging/prod (ve paylaşılan test ortamları).
• Bölge veya shard: us-east, eu-west, belirli bir cluster veya yüzde bazlı rollout.

Bir inceleyicinin “prod'da EU için flag'i devre dışı bırak” ile “küresel prod rollback”i ayırt edebilmesi gerekir; çünkü bunlar eşdeğer kararlar değildir.

Güvenli eylemler vs sadece izlenen eylemler

Uygulamanın tetikleyebileceği şeyleri belirleyin:

• Güvenli, otomatikleştirilebilir eylemler (örn. flag devre dışı bırakma, rollout duraklatma) doğrudan muhafazalarla yürütülebilir.
• Yüksek riskli veya çok adımlı eylemler (örn. veritabanı geri alma, acil yeniden dağıtım) izlenen olabilir: uygulama kim onayladı, ne yapıldı ve kanıtı kaydeder — yürütme CI/CD veya SRE tarafından yapılır.

İdempotentlik: çift geri almayı önleyin

Olay sırasında çakışan tıklamaları önlemek için eylemleri idempotent hale getirin:

• Benzersiz bir eylem anahtarı kullanın (feature + environment + region + mechanism + target state).
• “Zaten uygulanmış” durumları tespit edin ve Yürüt'ü Doğrula'ya çevirin.
• Çakışan eylemleri kilitleyin veya sıraya koyun (örn. “önceki sürümü yeniden dağıt” sırasında bir “flag off” bekleniyorsa izin vermeyin).

Bunun net tanımları onay iş akışını sakinleştirir ve olay zaman çizelgesini temiz tutar.

Karar Girdileri: Sinyaller, Eşikler ve Bağlam

Ekip hangi şeyin “iyi kanıt” olduğunu kabul ettiğinde geri alma kararları kolaylaşır. Uygulamanız dağınık telemetriyiyi tutarlı bir karar paketine dönüştürmelidir: sinyaller, eşikler ve bu sayıların neden değiştiğini açıklayan bağlam.

Sinyal kontrol listesi (standart, isteğe bağlı değil)

Bir sürüm veya inceleme altındaki özellik için her zaman görünen kısa ama tamamlayıcı bir kontrol listesi oluşturun:

• Hata oranı (genel ve endpoint bazında)
• Gecikme (p95/p99) ve zaman aşımı
• Önemli adımlarda dönüşüm veya funnel düşüşü
• Çökme raporları (uygulama sürümü, cihaz/OS, en sık stack'ler)
• Destek biletleri (hacim ve en sık kategoriler)

Amaç her seferinde aynı temel sinyallerin kontrol edildiğini doğrulamaktır; her grafiği göstermek değil.

Eğilimlere saygı duyan eşikler (tek sıçramaya göre değil)

Tek bir sıçrama olabilir. Kararlar süregelen sapma ve değişim hızı tarafından yönlendirilmelidir.

Hem şunları destekleyin:

• Statik eşikler (örn. “hata oranı > %2 için 10 dakika”)
• Bazeline-duyan eşikler (örn. “dönüşüm geçen haftanın aynı gününe göre %5 azaldı”)

UI'da her metriğin yanında son 60–120 dakikayı gösteren küçük bir “trend çubuğu” gösterin ki inceleyenler problemin büyüyor mu, stabil mi yoksa iyileşiyor mu anlayabilsin.

Bağlam: “Bilinen değişiklikler” paneli

Sayılarsız bağlam zaman kaybettirir. Şunları yanıtlayan bir “Bilinen değişiklikler” paneli ekleyin:

• Son 24 saatte ne gönderildi?
• Nerelere gönderildi (bölgeler, platformlar, kohortlar)?
• Ürün dışı neler değişti (kampanyalar, üçüncü taraf durumları, kesintiler)?

Bu panel sürüm notları, feature flag'ler ve dağıtımlardan veri çekmeli ve “hiçbir şey değişmedi” ifadesini açıkça belirtmelidir — varsayılan olarak varsayılmasın.

Derin kanıta hızlı erişim yolları

Birisi detaylara ihtiyaç duyduğunda doğru yeri hemen açacak kısayollar sağlayın (panolar, izler, biletler) via /integrations — uygulamanızı başka bir izleme aracına dönüştürmeden doğru kaynağa yönlendirin.

İş Akışı: Öner, İncele, Onayla, Yürüt

Bir geri alma karar uygulaması, “herkes bir sohbet dizisinde” durumunu tek, zaman kutulu bir iş akışına dönüştürdüğünde değer kazanır. Hedef basit: tek sorumlu öneren, tanımlı bir inceleyici seti ve tek nihai onaylayıcı — acil aksiyonu yavaşlatmadan.

1) Öner: bir karar kaydı oluşturun

Öneren, belirli bir sürüm/özellik ile ilişkili bir Geri Alma Önerisi başlatır. Form hızlı ama yapılandırılmış olmalı:

• Ne etkileniyor: feature, environment, rollout yüzdesi
• Önerilen eylem: geri al / rollout'u duraklat / veri bekle
• Etkileşim özeti: ana metrikler ve müşteri semptomları
• “Neden” (zorunlu): yapılandırılmış sebepler (örn. hata sıçraması, gelir düşüşü, güvenlik endişesi) artı serbest metin notlar

Öneri hemen paylaşılabilir bir bağlantı oluşturmalı ve atanmış inceleyicilere bildirim göndermelidir.

2) İncele: sinyal topla, görüş değil

İnceleyenler kanıt eklemeye ve bir tutum belirtmeye teşvik edilmelidir:

• Onayla, Değişiklik iste, veya Engelle (gerekçe ile)

Tartışmaları üretken tutmak için notları önerinin yanında saklayın (araçlar arasında dağılmasın) ve bilet veya monitörlere /incidents/123 veya /releases/45 gibi göreli bağlantılarla referans vermeyi teşvik edin.

3) Onayla: bir kişi kararı verir

Nihai onaylayanı tanımlayın (genellikle nöbet lideri veya ürün sahibi). Onayı:

• Seçilen eylemi kilitlemeli
• Onaylayanın gerekçesini kaydetmeli
• Zaman damgası, kimlik ve varsa koşulları (örn. “şimdi geri al, 30 dakika sonra tekrar değerlendir”) damgalamalıdır

SLA'lar ve hatırlatmalar

Geri almalar zaman duyarlıdır; bu yüzden son tarihleri iş akışına gömün:

• İnceleyen yanıt SLA'sı (örn. 10 dakika)
• Nihai onay SLA'sı (örn. incelemeler tamamlandıktan sonra 5 dakika)

SLA kaçırılırsa uygulama artış yapmalı — önce yedek inceleyiciye, sonra nöbet yöneticisine — karar kaydını değişmeden ve denetlenebilir tutarak.

Acil mod (break-glass)

Bazen bekleyemezsiniz. Break-glass Yürütme yolu ekleyin; bu anında eyleme izin verir ama şu gereksinimleri zorunlu kılar:

• Zorunlu bir “neden” notu
• Ek logging (kimi yürüttü, nereden, ne değişti)
• Otomatik oluşturulan takip maddeleri: post-incident inceleme, müşteri iletişimi taslağı ve doğrulama kontrol listesi

4) Yürüt: onayla, doğrula, kapat

Yürütme “düğmeye basıldı” ile bitmemeli. Doğrulama adımlarını (geri alma tamamlandı, flag'ler güncellendi, izleme kontrol edildi) yakalayın ve doğrulama imzalanana kadar kaydı kapatmayın.

UI/UX: Hızlı, Sakin Kararlar İçin Panolar

Bir sürüm sorun çıkardığında insanlar aracın “nasıl kullanıldığını” öğrenmeye zaman bulamaz. UI bilişsel yükü azaltmalı: neler oluyor, ne kararlaştırıldı ve güvenli bir sonraki adım ne sorularına cevap vermeli — kimseyi grafiklerle boğmadan.

Planlanacak ana ekranlar

Genel görünüm (ana pano). Bu triage giriş noktasıdır. İki saniyede üç soruyu yanıtlamalı: Şu anda risk altında olan ne? Hangi kararlar bekliyor? Son neler değişti? İyi bir düzen soldan sağa taramadır: aktif olaylar, bekleyen onaylar ve kısa bir “son sürümler / flag değişiklikleri” akışı.

Olay/Karar sayfası. Ekip burada birleşir. Anlatısal bir özet (“Gördüklerimiz”) ile canlı sinyalleri ve net bir karar panelini eşleştirin. Karar kontrollerini tutarlı bir yerde (sağ rail veya yapışkan footer) tutun ki insanlar “Geri alma öner”i aramasın.

Feature sayfası. Bunu “sahip görünümü” olarak ele alın: mevcut rollout durumu, feature ile bağlantılı son olaylar, ilişkili flag'ler, riskli segmentler ve karar geçmişi.

Sürüm zaman çizelgesi. Dağıtımların, flag rampalarının, konfig değişikliklerinin ve olayların kronolojik görünümü. Bu, ekiplerin neden-sonuç ilişkisini araçlar arasında atlamadan bağlamasını sağlar.

Durumu açık hale getirin (yanlış okunması zor)

Belirgin, tutarlı durum rozetleri kullanın:

• Mevcut risk seviyesi: Normal / Yükselmiş / Kritik
• Karar durumu: Taslak → İncelemede → Onaylandı → Yürütülüyor → Tamamlandı (veya Reddedildi)
• Son eylem: kim ne yaptı ve ne zaman (tek tıkla detaylar)

Salt renk ipuçlarından kaçının. Renkleri etiketler ve ikonlarla eşleştirip tüm ekranlarda dili tutarlı kullanın.

“Karar paketi” görünümü

Bir karar paketi, Neden geri alma düşünüyoruz ve seçenekler neler? sorusunu cevaplayan tek, paylaşılabilir bir özet olmalıdır.

İçerikler:

• Sinyaller: ana metrikler, hata eğilimleri, kullanıcı etkisi ve uyarılar (eşikler vurgulanmış)
• Değişiklik özeti: ne gönderildi, hangi flag'ler değişti ve etkilenen servisler
• Önerilen seçenekler: ekip için mevcut geri alma tipleri (örn. flag kapatma, deploy geri alma) ile tahmini patlama alanı ve yürütme süresi

Bu görünüm sohbet içine yapıştırmak ve sonra raporlama için dışa aktarmak kolay olmalıdır.

Baskı altındayken önemli olan erişilebilirlik

Hız ve netlik için tasarlayın:

• Açık etiketler (örn. “Execute” gibi tekil jargon butonlarından kaçının)
• Güçlü kontrast ve okunabilir font boyutları
• Kritik eylemler için tam klavye navigasyonu (incele, onayla, yürüt)
• Odak durumları ve yanlış yüksek riskli tıklamaları önleyen onay diyalogları

Hedef gösterişli panolar değil — doğru eylemin bariz hissettirdiği sakin bir arayüzdür.

Entegrasyonlar: Dağıtımlar, Flag'ler, İzleme ve Ticketing

Entegrasyonlar, bir geri alma uygulamasını “fikri olan bir form”dan karar kokpitine dönüştürür. Amaç her şeyi almak değil — ekibin karar verip hızlıca hareket etmesini sağlayan birkaç güvenilir sinyal ve kontrolü çekmektir.

Ana entegrasyon noktaları

Çoğu ekibin zaten kullandığı beş kaynaktan başlayın:

• Dağıtım sistemi (CI/CD): ne gönderildi, ne zaman, kim tarafından ve rollout kapsamı (bölge, cluster, % rollout).
• Feature flag servisi: mevcut flag durumu, hedefleme kuralları ve değişim geçmişi.
• İzleme & analitik: hata oranı, gecikme, crash-free kullanıcılar, dönüşüm düşüşleri, ana iş KPI'ları.
• Ticketing / incident araçları: olay durumu, önem derecesi, etkilenen servisler, atanmış müdahaleciler.
• Sohbet: hafif güncellemeler, onaylar ve karar kaydına dönen linkler.

Entegrasyon stilini seçme (güvenli bir geri dönüş ile)

Hız gereksinimini hala karşılayan en az kırılgan yöntemi kullanın:

• Önemli anlık olaylar için webhook (dağıtım bitti, flag değişti, olay oluşturuldu).
• Güvenilir webhook olmayan araçlar için polling, net aralıklar ve backoff ile.
• Anlık sorgular için API client (“servis X'e son 5 deploy'u göster” gibi).
• Sistemler çalışmazsa manuel giriş yedeği. Bunu açıkça etiketleyin: girişleri “manuel” olarak işaretleyin ve kısa bir gerekçe isteyin.

Olayları tek biçimli bir formata normalize edin

Farklı sistemler aynı şeyi farklı tanımlar. Gelen veriyi küçük, stabil bir şemaya normalize edin:

• source (deploy/flags/monitoring/ticketing/chat)
• entity (release, feature, service, incident)
• timestamp (UTC)
• environment (prod/staging)
• severity ve metric_values
• links (göreli linkler, ör. /incidents/123)

Bu, UI'nın tek bir zaman çizelgesi göstermesini ve sinyaller arasında karşılaştırma yapmasını kolaylaştırır.

Hataları kaybetmeden ele alma

Entegrasyonlar hata verir; uygulama sessiz veya yanıltıcı olmamalı.

• Geçici hatalar için backoff ile yeniden denemeler.
• Kötü yükler için dead-letter queue ve düzeltip tekrar oynatma yolu.
• Son başarının zamanı, hata sayısı ve bozulan mod davranışı gösteren bir entegrasyon sağlık sayfası (/integrations/health).

Sistem bir sinyali doğrulayamazsa bunu açıkça söyleyin — belirsizlik bile yararlı bilgidir.

Denetim Kaydı, Kanıt Snapshot'ları ve Raporlama

Bir geri alma masaya yatırıldığında kararın kendisi hikayenin yarısıdır. Diğer yarısı ise sonradan "neden bunu yaptık ve o anda ne biliyorduk?" sorusunu net cevaplayabilmektir. Açık bir denetim izi ikinci tahminleri azaltır, incelemeleri hızlandırır ve ekipler arası devirleri sakinleştirir.

Denetim olaylarını tanımlayın (kim/ne/ ne zaman/nerede)

Denetim izini eklenebilir olmayan bir kayıt olarak ele alın. Her olay için şunu yakalayın:

• Kim: kullanıcı ID'si, gösterim adı, rol ve ekip
• Ne: eylem (örn. “Geri alma önerildi”, “Onaylandı”, “Yürütüldü”, “İptal edildi”) ve etkilenmiş nesne (feature/release/incident)
• Ne zaman: UTC zaman damgası (isteğe bağlı olarak gösterimde yerel zaman)
• Nereden: IP adresi, user agent ve çalışma alanı/ortam (prod/staging)
• Ne değişti: ana alanlar için önce/sonra değerleri (eşikler, rollout yüzdesi, seçilen geri alma türü, bağlı biletler)

Bu, denetim kaydını kullanışlı kılar; karmaşık bir uyumluluk anlatısına zorlamadan.

Kanıt snapshot'ları: karar anındaki gerçekleri dondurun

Metrikler ve panolar dakika dakika değişir. “Hareketli hedef” karışıklığını önlemek için bir öneri oluşturulduğunda, güncellendiğinde, onaylandığında veya yürütüldüğünde kanıt snapshot'ları saklayın.

Bir snapshot şunları içerebilir: kullanılan sorgu (örn. feature kohort için hata oranı), dönen değerler, grafikler/yüzdelikler ve orijinal kaynağa bağlantılar. Amaç izleme aracınızı birebir kopyalamak değil — ekibin güvendiği spesifik sinyalleri korumaktır.

Saklama, dışa aktarma ve raporlama

Saklama süresini pratiklikle karar verin: olay/karar geçmişini ne kadar süre aranabilir tutmak istediğiniz ve neyin arşivleneceği. Takımların gerçekten kullandığı dışa aktarımları sunun:

• Analiz için CSV
• Karar özetlerini paylaşmak için PDF

Olaylar ve kararlar arasında hızlı arama ve filtreleme (servis, feature, tarih aralığı, onaylayan, sonuç, ciddiyet) ekleyin. Temel raporlama; geri alma sayıları, ortanca onay süresi ve tekrarlayan tetikleyicilerin özetini verebilir — ürün operasyonları ve post-incident incelemeler için yararlı.

Güvenlik ve Erişim Kontrolü Yüksek Riskli Eylemler İçin

Geri alma karar uygulamanız ancak insanlar ona güvenirse kullanışlıdır — özellikle üretimi değiştirebiliyorsa. Güvenlik yalnızca “kim giriş yapabilir” meselesi değildir; hızlı hareket ederken aceleyle, yanlışlıkla veya yetkisiz eylemleri nasıl önlediğinizdir.

Kimlik doğrulama: insanları ve sistemleri kanıtlayın

Net ve sınırlı oturum yolları sunun ve en güvenlisini varsayılan yapın.

• Çalışanlar için SSO/OAuth (Google Workspace, Okta, Azure AD). Bu parola riskini azaltır ve offboarding'i merkezileştirir.
• Kontratörler veya küçük ekipler için e-posta ile giriş yedeği, tercihen magic link veya MFA ile.
• Entegrasyonlar için service account (CI/CD, izleme, ticketing). Bunlar insan olmayan kimlikler olmalı, sıkı kapsamlı izinlere ve mümkünse kısa ömürlü tokenlara sahip olmalı.

Yetkilendirme: her kimliğin ne yapabileceğini belirleyin

Rol tabanlı erişim kontrolü (RBAC) ile ortam kapsamı kullanın ki izinler dev/staging/production için farklı olsun.

Pratik bir model:

• Viewer: panoları, denetim izini, kanıt snapshot'larını görür.
• Operator: geri alma önerisi sunar, kanıt ekler, dry-run kontrolleri çalıştırır.
• Approver: üretim geri almalarını onaylar/geri çevirir.
• Admin: roller, entegrasyonlar, saklama politikalarını yönetir.

Ortam kapsamı önemlidir: biri staging'de Operator olabilir ama üretimde sadece Viewer.

En tehlikeli eylemleri koruyun

Geri almalar yüksek etkili olabilir; hataları önleyecek sürtünce ekleyin:

• Açık detaylı onaylar (“Feature X'i prod'da sürüm Y'ye geri al”)
• Yüksek riskli adımlar için iki kişilik kural (örn. üretim geri alma yürütmesi bir öneren ve ayrı bir onaylayan gerektirir)
• Zamana bağlı onaylar (onay 15 dakika sonra geçersiz) gibi opsiyonel politikalar, “eski onay” riskini azaltır.

Güvenli tokenlar ve savunulabilir bir denetim oluşturun

Hassas erişimleri (olay kanıtlarını kim görüntüledi, eşikleri kim değiştirdi, geri almayı kim yürüttü) zaman damgası ve istek meta verisiyle kaydedin. Logları eklenebilir yapın ve dışa aktarmayı kolaylaştırın.

API tokenları, webhook imzalama anahtarları gibi sırları vault içinde saklayın (koda veya düz veritabanı alanlarına koymayın). Döndürün ve entegrasyon kaldırıldığında hemen iptal edin.

Mimari ve Yapı Planı (MVP'den Üretime)

Geri alma karar uygulaması kullanması hafif hissettirmeli, ama yine de yüksek riskli eylemleri koordine ediyor. Temiz bir yapı planı MVP'yi hızla göndermenize yardımcı olur ve sonrasında kimsenin güvenmediği bir “gizem kutusu” oluşturmaz.

Basit başlayın: UI + API + veritabanı + işler

MVP için çekirdek mimariyi sıkıcı tutun:

• Web UI: panolar, karar formları, onaylar ve geçmiş görünümleri.
• API: iş kurallarını yöneten tek servis (kimin neyi onaylayabileceği, hangi kanıtların gerekli olduğu vb.).
• Veritabanı: sürümler, feature/flag'ler, olaylar, kararlar ve kanıt snapshot'ları.
• Arka plan işleri: webhook olaylarını almak, metrikleri poll etmek, rapor üretmek ve bildirim göndermek.

Bu yapı birincil hedefi destekler: ne karar verildiğinin ve neden verildiğinin tek bir kaynağı. Entegrasyonlar asenkron çalışsın ki üçüncü taraf API'ler yavaşsa UI bloke olmasın.

Ekibinize uyan bir stack seçin

Ekibinizin güvenle işletip geliştirebileceği teknolojiyi seçin. Tipik kombinasyonlar şunlardır:

• Backend: Node.js (Express/Nest), Python (Django/FastAPI), Ruby on Rails veya Go.
• Frontend: React, Vue veya maksimum sadelik için sunucu tarafı render.
• Veritabanı: Postgres (ilişkisel veri + denetim geçmişi için uygun).
• Jobs/queue: Sidekiq, Celery, BullMQ veya yönetilen bir kuyruk.

Küçük ekipler için daha az parça tercih edin. Tek repo ve tek deploy edilebilir servis genelde başlangıç için yeterlidir.

Hızlı ilk sürümü hızlandırmak ama sürdürülebilirliği kaybetmemek isterseniz, Koder.ai gibi vibe-coding platformu pratik bir başlangıç olabilir: roller, varlıklar ve iş akışını sohbetle tanımlayıp React UI ile Go + PostgreSQL backend üretebilir ve formları, zaman çizelgelerini ve RBAC'i hızlıca yineleyebilirsiniz. Bu tür iç araçlar için MVP oluşturup kaynak kodu dışa aktarmanız ve sonra entegrasyonları, denetim kaydını ve dağıtımı sertleştirmeniz mümkündür.

Test stratejisi: önemli yerlerde güven

Hataları önleyen kısımlara odaklanın:

• Karar kuralları için birim testleri: eşikler, gerekli onaycılar, zaman pencereleri ve "iki kez yürütmeyi engelleme" korumaları.
• Webhook entegrasyon testleri: imzaları doğru doğrulama, yeniden denemeleri ve idempotentliği doğrulama.
• UI duman testi: kritik yolun (sürümü aç → sinyalleri incele → onayla → yürüt) kırılmadığını doğrulayın.

Operasyonel temel maddeler

Uygulamayı ilk günden beri üretim yazılımı gibi ele alın:

• İzleme: API gecikmesi, iş kuyruğu derinliği, webhook hataları ve yürütme başarı oranı.
• Yedekler: otomatik DB yedekleri ve periyodik geri yükleme testleri.
• Çalıştırma kitapları: basit bir /docs/runbooks sayfası oluşturun: “webhook'lar başarısız”, “kuyruk tıkandı”, “geri alma yürütülemiyor”, “erişim nasıl iptal edilir”.

MVP'yi karar yakalama + denetlenebilirlik etrafında planlayın, sonra ekip günlük kullanmaya başladıkça zengin entegrasyonlar ve raporlama ekleyin.