Kod-siz uygulamalar için bu olay çalışma kitabını kullanarak sorunları hızlıca tespit edin, etkiyi triyaj edin, güvenli şekilde geri alın, net iletişim kurun ve tekrarları önleyin.
Bir incident, insanların uygulamanızı kullanmasını engelleyen, uygulamayı acı verici derecede yavaşlatan veya veriyi riske atan beklenmedik her sorundur. Kod-siz uygulamalarda bu ani giriş hataları, bir değişiklik sonrası bozulan ekranlar, arka plan otomasyonlarının durması, API hataları veya “başarılı” görünen iş akışlarının veritabanına yanlış değerler yazması şeklinde olabilir.
Yazılı bir runbook, stresli bir anı küçük, net eylemlere dönüştürür. Tahminleri azaltır, kararları (örneğin ne zaman geri alına karar verileceği) hızlandırır ve herkesin aynı gerçekleri paylaşmasına yardımcı olur. Olaylar sırasında yaşanan gecikmelerin çoğu teknik değildir. Bunlar belirsizlikten gelir: Gerçek mi? Kim liderlik ediyor? Ne değişti? Kullanıcılara ne söylemeliyiz?
Bu oyun kitabı, işler ters gittiğinde uygulamaya dokunan herkes içindir: değişiklik gönderen kurucular, dağıtımları ve erişimi yöneten operasyon veya platform sahipleri, ilk bildirimleri duyan destek ekipleri ve etki ve öncelikleri değerlendiren ürün veya iş sahipleri.
Bilerek hafif tutuldu; AppMaster gibi görsel mantık, üretilmiş servisler ve birden fazla dağıtım seçeneği olan platformlarda çalışan ekipler için uygundur.
Tüm olay döngüsünü kapsar: gerçek bir sorunu tespit edip doğrulama, hızlı triyaj, stabilize edip kurtarma (geri alma kararları dahil), kesinti sırasında iletişim kurma ve aynı sorunun tekrarlanmaması için kısa bir olay sonrası inceleme yapma.
Uzun vadeli mimari yeniden tasarım, derin güvenlik adli analizleri veya karmaşık uyumluluk prosedürlerini kapsamaz. Düzenlenmiş veri veya kritik altyapıyla çalışıyorsanız, bu runbook'un üzerine daha katı adımlar ekleyin.
Olaylar, “normal”in ne olduğunu bilmediğinizde kaotik hissedilir. Ekip gerçek sorunları hızla fark edebilmesi için temel durumu tanımlayın. Kod-siz bir uygulamada erken sinyaller genellikle platform sağlığı, iş metrikleri ve insanlardan gelen karışık uyarılarla gelir.
Her gün izleyeceğiniz sinyalleri yazın, sadece kesintiler sırasında değil. Yaygın olanlar arasında çalışma süresi (uptime), hata oranı, yavaş ekranlar, başarısız girişler, ödeme hataları ve destek taleplerinde veya kullanıcı mesajlarında ani artışlar bulunur.
Herkesin kullanabileceği sade bir şiddet tanımı belirleyin:
Hareket yaratacak hedefler belirleyin. Örnek hedefler: 5 dakika içinde onaylama, ilk güncellemeyi 15 dakika içinde paylaşma ve 60 dakika içinde stabilize etmeyi hedefleme (tam düzeltme daha uzun sürebilir).
Rolleri ihtiyacınız olduğunda değil, önce kararlaştırın. Kim bir olayı ilan edebilir, kim yönetir ve o kişi çevrimdışıyken yedek kimdir, isimlendirin. AppMaster ekiplerinde bu genellikle Business Process mantığından sorumlu olan kişi ve dağıtımları veya dışa aktarmaları yapabilecek bir yedeği içerir.
Son olarak, olay notları için tek bir paylaşılan yer tutun. Her eylem için zaman damgası kullanın (ne değişti, ne zaman, kim tarafından) ki daha sonra tahmin etmeden hikâyeyi yeniden oluşturabilesiniz.
Panellere bakmadan önce etkiyi doğrulayın. Açık bir soru sorun: şu anda kim neyi yapamıyor? “Destek ekibi bilet açamıyor” demek, “uygulama yavaş” demekten daha faydalıdır. Mümkünse, etkilenen kullanıcıyla aynı rol ve cihazı kullanarak sorunu yeniden üretin.
Sonra yaygınlığı belirleyin. Tek bir hesap mı, bir müşteri segmenti mi yoksa herkes mi etkileniyor? Hızlı bölümler yapın: bölge, hesap türü, web vs mobil ve tek bir özellik mi yoksa tüm uygulama mı. Kod-siz araçlarda bir sorun küresel görünürken aslında bir izin kuralı veya tek bir bozuk ekran olabilir.
Sonrasında ne değiştiğine bakın. Bir sürüm, yapılandırma anahtarı, veritabanı şeması düzenlemesi veya veri aktarımı için son 1-2 saate bakın. AppMaster gibi platformlarda business process, veri modelleri veya kimlik doğrulama ayarlarında yapılan değişiklikler UI düzgün görünse bile birçok akışı etkileyebilir.
Uygulamanızı suçlamadan önce dış bağımlılıkları elemeleyin. E-posta/SMS sağlayıcıları, ödemeler (örneğin Stripe) ve entegrasyonlar (Telegram, AWS servisleri, AI API'leri) başarısız olabilir veya oran sınırlamasıyla karşılaşabilir. Eğer uygulama yalnızca mesaj gönderirken veya kart tahsil ederken bozuluyorsa, asıl sorun yukarı akışta olabilir.
Basit bir karar kontrol listesi kullanın:
Bir kez şiddet ve kapsam sınıflandırıldığında, "gerçek mi?" sorusundan "önce ne yaparız?" sorusuna tahmin olmadan geçebilirsiniz.
Hemen bir olay kaydı açın. Başlığa etkiyi isimlendiren sade bir ifade verin; şüphe edilen sebebi değil (örneğin “AB müşterilerinde ödeme başarısızlığı”). Başlangıç zamanını (ilk uyarı veya ilk rapor) yazın. Bu, kararlar, zaman damgaları ve neyin değiştiği için tek yer olacaktır.
Çalışmaların çakışmaması için roller atayın. Küçük bir ekipte bile sahiplerin isimlendirilmesi stres yüksekken hataları azaltır. En azından şunlar olmalı:
Yazılı olarak iki şeyi belirtin: kesin bildikleriniz ve mevcut hipoteziniz. “Bilinen” şunlar olabilir: hata oranı yükseldi, belirli bir endpoint başarısız oluyor, sadece mobil etkileniyor. Hipotez yanlış olabilir ama bir sonraki testi yönlendirmeli. İkisini de öğrendikçe güncelleyin.
Durum kararsızken 15 dakikalık bir güncelleme temposu belirleyin. Hiçbir şey değişmediyse bunu söyleyin. Düzenli güncellemeler yan konuşmaları durdurur ve tekrar eden "haber var mı?" bildirimlerini engeller.
İlk kapsama (containment) eylemini seçin. Amaç, kök neden net olmasa bile zararı hızla azaltmaktır. Tipik ilk hamleler arasında arka plan işleri durdurma, riskli bir özellik bayrağını devre dışı bırakma, bir modüle gelen trafiği sınırlama veya bilinen güvenli bir yapılandırmaya geçme vardır. AppMaster'da bu genellikle Business Process Editor'da belirli bir akışı kapatmak veya hataya yol açan UI yolunu geçici olarak gizlemek anlamına gelir.
Containment bir tempo penceresi içinde metrikleri iyileştirmezse, geri alma planlamasına paralel başlayın.
Gerçek bir olay olduğunu doğruladıktan sonra, "hata bulma"dan "kan akışını durdurma"ya geçin. Stabilize etmek zaman kazandırır. Araştırma sürerken kullanıcıları, geliri ve veriyi korur.
Zararı azaltan en küçük değişiklikle başlayın. Containment genellikle tam bir düzeltmeden daha hızlıdır çünkü yeni bir özelliği devre dışı bırakabilir, bir iş akışını duraklatabilir veya yeniden inşa etmeden riski olan bir girdi yolunu engelleyebilirsiniz.
Verinin bozulduğundan şüpheleniyorsanız önce yazmaları durdurun. Bu, formları geçici olarak devre dışı bırakmak, kayıtları güncelleyen otomasyonları duraklatmak veya güncelleme kabul eden bir API uç noktasını engellemek anlamına gelebilir. Kötü veriyi okumak rahatsız edicidir, ama kötü veri yazmak temizliği katlar.
Kullanıcılar kilitlenmişse, giriş öncelikli olsun. Önce kimlik doğrulama ayarlarını ve giriş akışını kontrol edin. Ekip sizin ve kullanıcıların uygulamaya erişememesiyle diğer tüm düzeltmeler yavaşlar.
Uygulama yavaşsa veya zaman aşımı oluyorsa yükü azaltın ve maliyetli yolları kaldırın. Ağır ekranları kapatın, arka plan işlerini duraklatın ve istekleri artıran yeni entegrasyonları devre dışı bırakın. AppMaster'da containment genellikle sorunlu bir business process'i devre dışı bırakmak veya maliyetli zinciri tetikleyen bir UI eylemini geçici olarak kaldırmak kadar basit olabilir.
Her eylemi kasıtlı ve belgelenmiş tutun. Baskı altındayken ekipler adımları tekrarlar veya yanlışlıkla bir düzeltmeyi geri alır. Her değişikliği ve sonucu yazın.
Basit bir stabilize sırası:
Hedefiniz “güvenli ve kullanılabilir” olmak, “tam çözülmüş” olmak değil. Etki sınırlandığında, sakin şekilde teşhis yapıp doğru geri alma veya düzeltme seçeneğini seçebilirsiniz.
Bir şey bozulduğunda hız önemli ama en güvenli hamle kazanır. Genelde üç pratik seçeneğiniz vardır: geri alma (rollback), ileriye düzeltme (forward fix) veya kısmi geri alma (bir özelliği kapatıp kalanları açık bırakma).
Önce "geri alma"nın sizin kurulumunuzda ne anlama geldiğini netleştirin. Bu önceki sürümü dağıtmak, bir yapılandırma değişikliğini geri almak veya bir veritabanı durumunu geri yüklemek olabilir. AppMaster gibi platformlarda bir “sürüm” backend mantığı, web UI, mobil derlemeler ve ortam ayarlarını içerebilir.
Aşağıdaki risk kontrollerini kullanarak geri almanın güvenli olup olmadığını değerlendirin:
Herhangi bir şeyi değiştirmeden önce basit bir git/gitme kuralı belirleyin. Eylemden sonra 10-15 dakika içinde iyileşmesi gereken 2-3 metrik seçin: hata oranı, giriş başarısı, ödeme tamamlama veya API gecikmesi gibi. Eğer metrikler doğru yönde hareket etmezse durun ve stratejinizi değiştirin.
Geri almanın geri alınmasını da planlayın. Eski sürüm yeni sorunlar çıkarırsa nasıl geri döneceğinizi bilin: hangi build yeniden dağıtılacak, hangi konfigürasyon uygulanacak ve bu ikinci değişiklik kim tarafından onaylanacak. Karar değişmemesi için son “yayınla” kararından tek bir kişi sorumlu olsun.
Sessizlik olayları daha da kötüleştirir. Ekip araştırırken insanları bilgilendirmek için basit, tekrarlanabilir bir yol kullanın.
İç güncellemelerle başlayın. Önce soru soracak kişilere ve engelleri kaldırabilecek kişilere söyleyin. Kısa ve olgusal tutun. Genelde ihtiyacınız olanlar:
Dış güncellemeler için bildiklerinizle yetinin. Kök nedeni tahmin etmekten veya bir tedarikçiyi suçlamaktan kaçının. Kullanıcılar çoğunlukla üç şeyi ister: onay, etki ve ne zaman tekrar bilgilendirilecekleri.
Kanallarda tutarlı tek bir durum satırı kullanın:
Kullanıcılar kızgınsa önce kabul edin, sonra spesifik olun: “Kayıt işleminin bazı müşterilerde başarısız olduğunu biliyoruz. Şimdi son değişikliği geri alıyoruz. 30 dakika içinde bir sonraki güncellemeyi paylaşacağız.” Olay sırasında tarih, kredi veya kalıcı düzeltmeler vaat etmeyin.
Ana belirti ortadan kalkmış ve kilit kontroller temizse çözüldü ilan edin (girişler, temel akışlar, hata oranları gibi). Bir düzeltme uygulandıktan sonra tekrarları izlemek için zamana ihtiyacınız varsa monitoring kullanın. Ne izleyeceğinizi, ne kadar süre izleyeceğinizi ve son güncellemenin ne zaman yapılacağını her zaman belirtin.
İşler stabilize olduğunda, yangın söndürmeden tanımlamaya geçin: belirtileri açıklayan en küçük gerçek setini toplayın. Amaç mükemmel bir kök neden bulmak değil. Amaç, olası bir nedeni belirleyip olayı daha da kötüleştirmeden harekete geçebilmektir.
Farklı belirtiler farklı zanlılara işaret eder. Yavaş sayfalar genellikle yavaş veritabanı sorguları, ani trafik artışı veya dış bir servisin gecikmesi anlamına gelir. Zaman aşımı takılan süreç, aşırı yüklenmiş backend veya uzun süre bekleyen bir entegrasyon nedeniyle olabilir. Hatalarda veya yeniden denemelerdeki artış genellikle yakın zamanda yapılan bir değişiklik, hatalı bir girdi veya yukarı akış bir kesinti ile ilişkilidir.
Normal bir test hesabıyla bir gerçek kullanıcı yolculuğunu baştan sona çalıştırın. Bu genellikle UI, mantık, veritabanı ve entegrasyonları aynı anda kontrol ettiği için en hızlı sinyaldir.
Bir avuç kontrole odaklanın:
AppMaster kullanıyorsanız, bu genellikle bir Business Process adımına, bir Data Designer değişikliğine veya bir dağıtım konfigürasyonuna doğrudan karşılık gelir.
Hızlı kontroller açık bir suçluya işaret ediyorsa, en güvenli hamleyi seçin: mevcut hafifletmeyi sürdürün veya küçük kalıcı bir düzeltme uygulayın. Rate limitleri, özellik bayraklarını veya manuel çözümleri yalnızca yolculuk iki kez başarılı olduktan ve hata oranı birkaç dakika stabil kaldıktan sonra kaldırın.
Salı sabahı 10:15. Bir ekip AppMaster üzerinde oluşturulmuş müşteri portalına küçük bir değişiklik gönderiyor. Dakikalar içinde kullanıcılar giriş sonrası boş sayfalar görmeye başlıyor ve yeni siparişler gelmiyor.
Destek üç bilet alıyor: “Giriş çalışıyor, sonra portal hiç yüklenmiyor.” Aynı zamanda izleme web uygulamasında 500 hata artışı ve başarılı API çağrılarında düşüş gösteriyor. Bunu gerçek bir olay olarak ele alıyorsunuz.
Olay lideri hızlı bir doğrulama yapıyor: test kullanıcı ile masaüstü ve mobil üzerinde giriş denemesi ve son dağıtım zamanını kontrol etme. Zamanlama sürümle uyuşuyor; bu yüzden en azından kanıtlanana kadar son değişikliğin işe karıştığını varsayıyorsunuz.
İlk 30 dakika şu şekilde olabilir:
10:40'da hatalar normale dönüyor. Metrikleri gözlemlemeye devam ediyorsunuz ve destek yeni biletlerin azaldığını doğruluyor.
Sonrasında ekip kısa bir inceleme yapıyor: bunu ilk kim fark etti (uyarılar mı yoksa destek mi), sizi yavaşlatan neydi (sahip yokluğu, belirsiz geri alma adımları) ve neyi değiştirmeli. Yaygın bir iyileştirme, portalın en önemli üç akışı için bir sürüm duman testi kontrol listesi eklemek ve geri almayı tek adımlı, belgelenmiş bir işlem yapmak olabilir.
Çoğu olay iki nedenle kötüleşir: insanlar araştırırken sistemin zarar vermeye devam etmesine izin verirler veya çok hızlı çok fazla değişiklik yaparlar. Bu runbook sizi her iki durumdan da korumak için tasarlandı.
Yaygın bir tuzak, uygulama hâlâ kötü veri yazarken araştırma yapmaktır. Bir iş akışı döngüye giriyorsa, bir entegrasyon çoğaltma yapıyorsa veya bir izin hatası yanlış kullanıcıların kayıtları düzenlemesine izin veriyorsa önce ilgili süreci durdurun. AppMaster'da bu bir Business Process'i devre dışı bırakmak, bir modül entegrasyonunu kapatmak veya sorunun yayılmasını durdurmak için erişimi geçici kısıtlamak anlamına gelebilir.
Bir diğer tuzak tahminle “düzeltme yapmak”. Birkaç kişinin tıklayıp ayar değiştirmesi zaman çizelgesini kaybettirir. Olay sırasında küçük bile değişiklikler önemlidir. Bir sürücü üzerinde anlaşın, basit bir değişiklik günlüğü tutun ve bilinmeyenlerin üzerine üst üste değişiklik yapmaktan kaçının.
Tekrarlayan olarak daha uzun kesintilere yol açan hatalar:
İletişim toparlanmanın bir parçasıdır. Bildiklerinizi, bilmediklerinizi ve bir sonraki güncellemenin ne zaman olacağını paylaşın. “Geri alıyoruz ve 15 dakika içinde faturalama olaylarının doğru olduğunu onaylayacağız” demek, "Bakıyoruz" demekten iyidir.
Hatalar durduğu için olayı kapatmayın. Kısa bir doğrulama kontrol listesi ile doğrulayın: ana ekranlar yükleniyor, yeni kayıtlar doğru kaydediliyor, kritik otomasyonlar bir kez çalışıyor ve kuyruklar (retry'ler, zamanlanmış işler) boşaltılmış veya güvenli şekilde duraklatılmış.
Bir şeyler bozulduğunda, beyniniz aynı anda on görev yapmaya çalışır. Bunu kullanarak sakin kalın, insanları koruyun ve servisi geri alın.
Bu bölümü ekibinizin gerçekten göreceği bir yere sabitleyin.
Bir dakika ayırıp bir olay sahibi atayın. Bir kişi karar versin, herkes desteklesin.
Stabilize et ve contain yap (10 dakika): Kök neden peşine düşmeden önce kanı durdurun. Riskli yolu devre dışı bırakın (özellik bayrağı, geçici duyuru, kuyruk duraklatma) ve bir ana yolculuğu baştan sona test edin. İşe en çok zarar veren yolculuğu seçin, en kolay olanı değil.
Servisi geri getir (10-20 dakika): En güvenli hamleyi seçin: bilinen son iyi sürüme geri dönün veya minimal bir düzeltme uygulayın. AppMaster gibi platformlarda bu önceki bir derlemeyi yeniden dağıtmak veya son değişikliği geri almak anlamına gelebilir; ardından hata oranları ve yanıt sürelerinin normale döndüğünü doğrulayın.
İletişim (sürekli): Ne etkilendi, kullanıcıların ne yapması gerektiği ve bir sonraki güncelleme zamanı bulunan kısa bir durum güncellemesi paylaşın. Destek için iki cümlelik bir kontrollü mesaj hazırlayın ki herkes aynı şeyi söylesin.
Temiz bir şekilde kapat (unutmadan önce): Ne olduğunu, neyi değiştirdiğinizi ve servisin ne zaman geri döndüğünü kaydedin. İzleme, test boşlukları, veri temizliği veya takip düzeltmesi gibi bir sonraki adımları sahipleri ve teslim tarihleriyle atayın.
Uygulama geri döndüğünde incident tamamen “bitti” sayılmaz. Gelecekteki kesintileri en hızlı azaltma yolu, olay tazeyken olanları yakalamak ve o öğrenimleri küçük, gerçek değişikliklere dönüştürmektir.
2–5 gün içinde kısa bir olay sonrası inceleme planlayın. Suçlayıcı olmayan ve pratik tutun. Amaç birini suçlamak değil; bir sonraki olayı daha kolay yönetilebilir kılmaktır.
Aylar sonra biri okuyabilsin diye bir kayıt yazın: kullanıcıların ne gördüğü, ne zaman tespit edildiği, ne denendiği, ne işe yaradığı ve servis ne zaman geri döndüğü. Kök nedeni biliyorsanız ekleyin ve eksik uyarılar, belirsiz sahiplik veya kafa karıştıran yayın adımları gibi katkıda bulunan faktörleri not edin.
Öğrenimleri sahipleri ve teslim tarihleriyle görevlere dönüştürün. Aynı hatayı önlemek için en küçük değişikliklere odaklanın:
Her olay için en az bir önleme maddesi seçin, küçük olsa bile. “Rollerdeki her değişiklik ikinci bir onay gerektirsin” veya “Veri geçişleri önce staging kopyasında çalıştırılsın” gibi önlemler tekrar kesintileri engelleyebilir.
Bu runbook'u build ve yayın süreçlerinizin yanında tutun. AppMaster ile inşa ediyorsanız, her uygulamanın nerede dağıtıldığını (AppMaster Cloud, AWS, Azure, Google Cloud veya self-hosted), kimlerin hızlıca yeniden dağıtabildiğini ve kimlerin geri alma yapabileceğini yazın. Belgelerin tek bir yerde olması için AppMaster proje notlarınızın yanında (appmaster.io) saklamak dakikaların önemli olduğu zamanlarda bulunmayı kolaylaştırır.
Kod-siz bir uygulamada bir problemi ne zaman incident olarak değerlendirmeliyiz?Beklenmedik bir sorun, temel görevleri engelliyorsa, uygulamayı kullanılamaz hale getiriyorsa veya yanlış/tehlikeli veri değişiklikleri riski taşıyorsa runbook'u uygulayın. Kullanıcılar giriş yapamıyorsa, ödemeler başarısız oluyorsa, otomasyonlar duruyorsa veya kayıtlar yanlış yazılıyorsa olayı bir incident olarak ele alın ve runbook'u izleyin.
Bir incident'in gerçek olduğunu doğrulamanın ve etkisini ölçmenin en hızlı yolu nedir?Önce kullanıcı etkisine bakın: şu anda kim ne yapamıyor ve ne zamandan beri? Ardından aynı rol ve cihazla sorunu yeniden üretin ve bunun tek bir hesap mı, bir segment mi yoksa herkes mi etkilediğini kontrol edin; böylece yanlış nedene takılmazsınız.
SEV1, SEV2 ve SEV3 arasındaki kararı hızlıca nasıl veririz?Çoğu kullanıcının engellendiği veya para/güvenlik/verinin risk altında olduğu durumlarda SEV1 ilan edin. Önemli bir özellik bozuk ama bir geçici çözüm varsa SEV2; sınırlı kapsamlı veya kozmetik sorunlar için SEV3. Hızlı karar vermek, mükemmel olmaktan daha önemlidir.
Özellikle küçük bir ekipte incident sırasında kim ne yapmalı?Final kararı veren bir incident lead atayın; ardından bir düzeltici (fixer), bir iletişim sorumlusu ve bir not tutan atayın ki insanlar çakışmasın ve yanlışlıkla değişiklik yapmasın. Küçük ekiplerde biri iki rolü üstlenebilir, ama incident lead rolü net olmalı.
AppMaster veya benzeri kod-siz platformlarda “containment” nasıl görünür?Containment, kök neden net değilken bile zararı hızlıca durdurmaktır. AppMaster'da bu genellikle belirli bir Business Process'i devre dışı bırakmak, hataya neden olan UI eylemini geçici olarak gizlemek veya dönen/yanlış veri yazan bir otomasyonu duraklatmaktır.
Ne zaman rollback yapmalı, ne zaman hızlı bir ileri düzeltme yayınlamalıyız?Eğer sorun bir sürüm yayınından hemen sonra başladıysa ve bilinen iyi bir sürüm hizmeti hızla geri getiriyorsa rollback yapın. İleriye yönelik bir düzeltme yalnızca küçük, düşük riskli bir değişiklik yapıp bunu hızla doğrulayabileceğinizde tercih edin.
Kod-siz uygulamalarda rollback'i ne şeyler güvensiz kılar?Veritabanı şeması değiştiyse, geri alma eski sürümün farklı tablolar/alanlar beklemesi nedeniyle başarısız olabilir. Geri alma riskli sayılırsa önce stabilize edin ve eski sürümün ne beklediğini doğrulayın.
Veri bozulduğundan şüpheleniyorsak önce ne yapmalıyız?Eğer veri bozulmasından şüpheleniyorsanız, önce yazmaları durdurun; kötü yazılan veriler düzeltmeyi katlayarak zorlaştırır. Pratikte formları devre dışı bırakın, güncelleme otomasyonlarını duraklatın veya güncelleme kabul eden uç noktaları engelleyin.
Kesinti sırasında ne söylemeliyiz ve ne sıklıkla güncelleme yapmalıyız?Kısa, gerçekçi güncellemeler gönderin ve sabit bir tempo belirleyin: ne etkilendi, ne yapıyorsunuz ve bir sonraki güncelleme ne zaman olacak. Sebebi tahmin etmeyin veya tedarikçiyi suçlamayın; kullanıcılar netlik ve öngörülebilir güncellemeler ister.
Bir olayı 'çözüldü' olarak mı yoksa 'izlemede' olarak mı ilan etmeli miyiz?Ana kullanıcı belirtisi kaybolduktan ve kilit kontroller temizlendikten sonra ancak o zaman “çözüldü” ilan edin (giriş, birincil iş akışı, hata oranları gibi). Bir düzeltme uygulayıp hâlâ tekrarı izliyorsanız durum "monitoring" olarak kalmalı ve neyi, ne kadar süre izleyeceğinizi belirtin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
