Hata durumu için tasarlamak

Çoğu sistem iyi gün için inşa edilir — her şeyin çalıştığı, her bağlantının yanıt verdiği, her servisin erişilebilir olduğu, her varsayımın tuttuğu durum için. Bu anlaşılırdır, çünkü sık yaşanan iyi gündür. Pek çok sistemin kötü günde çökmesinin nedeni de budur: Hiçbir zaman o gün için tasarlanmamışlardır. Yazılım iyi günde değil, kötü günde değerlendirilir — ve kötü gün, birinin önceden onu düşünüp düşünmediğini ortaya çıkarır.

Bu doküman hata durumu için tasarlamayı ele alıyor — sistemleri, parçalarının kaçınılmaz arızalarına kırılmadan dayanacak şekilde inşa etme disiplinini. Bir araçtan değil, bir tutumdan söz ettiği için framework'ten ve buluttan bağımsız tutulmuştur. Observability'nin madalyonun öbür yüzüdür: Observability bir şeylerin ters gittiğini gösterir; hata durumu için tasarlamak ise bu ters gidişin tüm sistemi sürüklememesini sağlar. Hiçbir rakam verilmiyor.

1. Her şey eninde sonunda arızalanır

Her şeyi değiştiren tek varsayım basittir: Gerçek bir sistemde her parça eninde sonunda arızalanır. Bir bağlantı kopar, bir servis yanıt vermez, bir disk bozulur, bir çağrı çok uzun sürer, komşu bir sistem aşırı yüklenir. Bu, görmezden gelinebilecek nadir bir istisna değil; yeterince uzun çalışan ve yeterince parçadan oluşan bir sistemin olağan hâlidir. Parçaların çalıştığını varsayan, zamanın çürüteceği bir varsayımın üzerine inşa eder.

Bu varsayımı tersine çevirmek — parçaların arızalanacağını kabul edip o zaman ne olacağını sormak — disiplinin özüdür. Bu karamsarlık değil, gerçekçilik gerektirir: Gerçekleşmeyeceğini ummak yerine, kesinlikle gerçekleşecek olana göre plan yaparsınız. Parçalarının arızalanmasına göre tasarlanmış bir sistemin kötü günde bir cevabı vardır; bunu düşünmemiş olanın ise yalnızca sürprizi. Fark, olaydan çok önce, tasarımda belirlenir. Kötü günü önleyemezsiniz — yalnızca ona hazırlıklı mı yoksa hazırlıksız mı yakalanacağınıza karar verebilirsiniz ve bu karar, her şey henüz sakinken verilir.

Trade-off. Arızayı varsaymak, iyi durumdan fazlasını tasarlamak demektir — yalnızca kötü günde karşılığını veren, ama tasarım sırasında görünmeyen bir emek.

Maliyet. Hata durumu için inşa etmek sistemleri o an daha karmaşık ve inşası daha yavaş hâle getirir, çünkü testte nadiren ortaya çıkan durumlarla uğraşırsınız.

Ne zaman farklı karar veririz. Arızası sonuçsuz kalan kısa ömürlü, kritik olmayan bir sistem için tam hata tasarımı abartıdır; değeri parça sayısı, işletim süresi ve bir arızanın vereceği zararla birlikte artar.

2. Bilinen ve bilinmeyen hata modları

Hata modu, bir sistemin başarısız olabileceği yollardan biridir. Bazılarını bilirsiniz: Düşünmüş, ele almış, hatta belki prova etmişsinizdir. Diğerlerini bilmezsiniz — kimsenin öngörmediği koşulların bir araya gelmesinden doğar ve ilk kez production'da ortaya çıkarlar. Olgun yaklaşım tüm hata modlarını bilmek değildir — bu imkânsızdır —; bilinenleri düzgünce ele almak ve sistemi, bilinmeyen bir hatanın bile tümünü hemen sürüklemeyeceği şekilde inşa etmektir.

Buradan bitmişliğe dair bir ölçüt çıkar: Hata modlarını kimsenin bilmediği bir sistem bitmiş değil, yalnızca henüz sınanmamıştır. Şu servis çöktüğünde ya da bu bağlantı koptuğunda ne olacağını söyleyemediğiniz sürece, sistemi yalnızca iyi gün için inşa etmişsinizdir. Her parça için “bu arızalanırsa ne olur?” sorusunu sormak, bilinen hata modlarını henüz ele alınabilecekken gün yüzüne çıkaran alıştırmadır — ve arızayı önleyemediğiniz için nerede sınırlamaya güvenmeniz gerektiğini gösterir.

Trade-off. Hata modlarını bilinçli olarak aramak tasarımda zaman ve herkes sistemi bitmiş görmek isterken rahatsız edici “ya şöyle olursa” sorularını sorma iradesi gerektirir.

Maliyet. Arama hiçbir zaman eksiksiz değildir; bilinenleri bulursunuz, bilinmeyenleri değil ve öngörmediğiniz geri kalanla yaşamak zorundasınız.

Ne zaman farklı karar veririz. Bir parçanın açıkça kritik olmadığı ve arızasının sonuçsuz kaldığı yerde derin analizden kaçınılır; dikkat, arızası sistemi ya da kullanıcılarını etkileyen parçalara yöneltilir.

3. Hataları önlemek değil, sınırlamak

Hataları önleyemezsiniz — yalnızca sonuçlarını sınırlayabilirsiniz. Merkezî kayma budur: hiçbir şeyin arızalanmaması gibi umutsuz bir hedeften, bir parçanın arızasının tümünü sürüklememesi gibi ulaşılabilir bir hedefe. Bunun için parçalar birbirinden izole edilir; böylece bir hata yayılmak yerine kendi sınırında durdurulur. Aşırı yüklenmiş ya da çökmüş bir parça diğerlerini peşinden sürüklememelidir; ayrılır, arızası yerel kalır ve sistemin geri kalanı çalışmaya devam eder.

Şema: Sınır olmadan bir arıza tüm sisteme yayılır; sınırla, doğduğu yerde kalır. Sınırlama, önlemeyi yener.

Sınırlamanın bir parçası da başka bir parçayı çağırırken onun yanıtına asla sınırsızca güvenmemektir: Sonsuza kadar değil, yalnızca sınırlı bir süre beklenir ve yanıtın gelmemesi neyse o olarak ele alınır — hazırlıklı olduğunuz bir hata olarak. Zaman sınırı olmayan bir çağrı, bir komşunun arızasının kendi sisteminize sızdığı açık bir kapıdır.

Hata tasarımının en önemli araçlarına genel bakış — her biri sonradan yapılan bir ayar değil, bir tasarım tutumudur:

Sınırlamanın özellikle etkili bir kalıbı, tekrar tekrar arızalanan bir parçayı geçici olarak hiç çağırmamaktır. Kapalı bir kapıya defalarca yüklenip kaynakları bağlamak yerine sistem, bir komşunun şu anda yanıt vermediğini fark eder ve onu bir süre rahat bırakır — hemen öngörülmüş hata işleyişine döner ve ancak bir aradan sonra yeniden dener. Bu iki tarafı aynı anda korur: umutsuz yeniden denemelerde boğulmayan kendi sisteminizi ve isteklerle daha da batırılmak yerine toparlanma şansı verilen aşırı yüklenmiş komşuyu. Burada sınırlama, hatayı yalnızca yerel tutmak değil, onu körü körüne ısrarla daha da kötüleştirmemek demektir.

Trade-off. Sınırlama, dayanıklılığı tasarlanması ve bakımı yapılması gereken sınırlar ve izolasyonla satın alır — iyi durumda gereksiz görünen bir yapı.

Maliyet. Her sınır, her zaman bariyeri, her ayırma; anlaşılması ve test edilmesi gereken kendi sınır durumları olan ek mantıktır.

Ne zaman farklı karar veririz. Parçaları zaten birlikte ayakta kalıp birlikte düşen küçük, sıkı bağlı bir sistemde izolasyon pek bir şey kazandırmaz; değeri parçaların bağımsızlığı ve bir yayılmanın vereceği zararla birlikte artar.

4. Güvenli yeniden deneme

Pek çok hata geçicidir: Bir bağlantı kısa süreliğine kopar, bir servis bir anlığına aşırı yüklenir, bir çağrı zaman sınırına takılır. Bu tür hatalara yeniden denemeyle karşılık vermek akla yatkındır ve çoğu zaman doğrudur — ama yalnızca operasyon bir yeniden denemeyi güvenle kaldırabiliyorsa. İki kez çalıştırıldığında iki kez etki eden bir operasyonu körü körüne yeniden denemek, zararsız bir geçici hatayı gerçek bir zarara dönüştürür: çift tahsilat, çift sipariş, kimsenin istemediği çift bir etki.

Bu yüzden yeniden deneme ve idempotency ayrılmaz biçimde birbirine bağlıdır. Yalnızca zarar vermeden tekrarlanabilecek olan yeniden denenir — ve durum ve para değiştiren operasyonların, otomatik olarak yeniden denenmeden önce bu özelliğe sahip olması sağlanır. Güvenli yeniden deneme böylece salt bir işletim ayarı değil, bir tasarım kararıdır: Operasyonlar, ikinci denemenin birincisiyle aynı sonucu vereceği şekilde inşa edilir. Bunu sağlamadan yeniden deneyen, hatayı ele almamış, ikiye katlamıştır.

Trade-off. Güvenli yeniden deneme, geçici hatalardan toparlanmayı operasyonları mükerrer işlemleri önleyen (idempotent) hâle getirme emeğiyle satın alır — inşa edilen ve bakımı yapılan bir mekanizma.

Maliyet. Idempotency sağlamak durum (state) ve eşzamanlılıkta özen gerektirir; bu, tekrarlanabilir her operasyon için ortaya çıkan gerçek bir iştir.

Ne zaman farklı karar veririz. Salt okuma işlemleri ve doğası gereği mükerrer işlemleri önleyen (idempotent) operasyonlar ek emek olmadan yeniden denenir; özen, kendiliğinden tekrarlanabilir olmayan operasyonlar içindir — onlar ancak tekrarlanabilir hâle geldiklerinde yeniden denenir (bkz. Dağıtık sistemlerde idempotency).

5. Toptan çöküş yerine zarif kademelendirme

Bir parça arızalandığında neredeyse her zaman ikiden fazla olasılık vardır. “Her şey çalışıyor” ile “hiçbir şey çalışmıyor” arasında geniş bir alan uzanır: Sistem, ikincil bir işlev duraklarken en önemli görevini yerine getirmeye devam edebilir; hiç yanıt vermemek yerine daha eski, önbellekteki bir yanıtı sunabilir; çökmek yerine bir işlevi geçici olarak kapatabilir. Zarif kademelendirme (graceful degradation), bu ara kademeleri bilinçli olarak tasarlamak demektir; öyle ki bir parçanın arızası işlevsizliğe değil, daha az işleve yol açar.

Şema: Tam işlev ile toptan çöküş arasında kademeler vardır. Zarif kademelendirme bu basamakları düşmek yerine iner — kesikli basamağa yalnızca başka hiçbir basamak taşımadığında ulaşılır.

Değeri, bir kullanıcının kısmi bir hizmeti neredeyse her zaman tam bir kesintiye tercih etmesinde yatar. Bir sorun karşısında ikincil bir işlevi kapatıp ana görevi sürdüren bir sistem güvenilir görünür; ilk arızada tamamen duran bir sistem ise — belki yalnızca küçük bir parçası etkilenmiş olsa da — kırılgan görünür. Kademelendirmeyi tasarlamak, hatalar altında neyin korunacak kadar önemli, neyin bırakılabilecek kadar vazgeçilebilir olduğuna önceden karar vermek demektir. Bu sıralama olay anında değil, masa başında belirlenir.

Trade-off. Zarif kademelendirme, kısmi arızada güvenilirliği yalnızca bir hep-ya-hiç yerine birden fazla işlev kademesi tasarlama emeğiyle satın alır.

Maliyet. Her kademelendirme basamağı, inşa edilen, anlaşılan ve test edilen ayrı bir durumdur; çok fazla basamak sistemin kendisini karmaşık ve anlaşılması güç hâle getirebilir.

Ne zaman farklı karar veririz. Kısmi bir işlevin değeri olmadığı yerde — bir işlem ya bütünüyle anlamlıdır ya da hiç anlamlı değildir — kademelendirme tasarlanmaz; işlevin bir kalıntısının kullanıcıya hâlâ hizmet ettiği yerde karşılığını verir.

6. Hata durumunu prova etmek

Bir sistemin bir arızaya dayanıp dayanmadığını, denemeden bilemezsiniz. Dayanıklılıktaki en tehlikeli varsayım, bir önlemin inşa edildiği için zaten çalıştığıdır — hiç geri yüklenmemiş yedek, hiç tetiklenmemiş yedek çözüm, hiç devreye girmemiş zaman sınırı. Bu tür sınanmamış önlemler koruma değil, koruma görüntüsündeki bir umuttur. Hata durumunu bilinçli olarak tetikleyip sistemin düşünüldüğü gibi tepki verip vermediğini gözlemlediğinizde ancak dayanıklılığın gerçek olduğunu bilirsiniz.

Hata durumunu prova etmek bu yüzden bir lüks değil, dayanıklılığı iddia etmek yerine kanıtlamanın tek yoludur. Bir parçayı bilinçli olarak kapatır ve sınırlamanın tutup tutmadığını kontrol edersiniz; bir yanıtın gelmemesini sağlar ve zaman sınırının devreye girip girmediğini kontrol edersiniz; acil durumda yapabileceğinizi bilmek için bir yedeği geri yüklersiniz. Prova etmediğiniz şeyi koruma olarak sayamazsınız. Bu alıştırma tahmin edilen dayanıklılığı kanıtlanmış dayanıklılığa dönüştürür — ve açığı, gerçek bir olayda değil, kapatılması henüz ucuzken ortaya çıkarır.

Trade-off. Hata durumunu prova etmek zaman ve çalışan bir sistemi kasıtlı olarak bozmak için biraz cesaret gerektirir — karşılığında dayanıklılığı ummak yerine bilmenin kazancı gelir.

Maliyet. Prova, alıştırmanın kendisinin gerçek zarar vermemesi için hazırlık ve güvenli bir çerçeve gerektirir — kendini yalnızca önlenen kesintide gösteren bir emek.

Ne zaman farklı karar veririz. Arızası sonuçsuz kalan kritik olmayan bir sistem için önlemleri düşünüp taşınmak yeterlidir; aktif prova, gerçek bir arızanın ciddi zarar vereceği yerde karşılığını verir.

7. Hataları görünür kılmak

Hata durumu için tasarlamak, hata durumunu fark etmeyi gerektirir. Ne kadar iyi bir sınırlama, ne kadar akıllıca bir kademelendirme olursa olsun, şu anda devrede olduklarını kimse görmüyorsa işe yaramaz — o zaman sistem çalışmaya devam eder ama fark edilmeden hasarlı bir durumda; asıl hata ise kötüleşene kadar açıklığa kavuşmaz. Bu yüzden dayanıklılık ve observability birbirine aittir: Biri bir hatanın tümünü sürüklememesini sağlar; diğeri onu görmenizi ve tepki verebilmenizi.

Somut olarak bu, hata durumunun kendisinin görünür olması gerektiği anlamına gelir — yalnızca toptan çöküşün değil, sessiz kısmi arızanın, tetiklenen yedek çözümün, devreye giren zaman sınırının da. Bunu bildirmeden zarifçe kademelendiren bir sistem kendi yaralarını gizler; o kan kaybederken onu sağlıklı sanırsınız. Bu nedenle hata durumu önlemleri, tetiklendiklerinde fark edilecek şekilde tasarlanmalıdır — hatalara tepki verebilmenin ön koşulu olan mimari ilke olarak observability anlayışıyla.

Trade-off. Hata durumunu görünür kılmak, tepki verebilme yeteneğini her önlemi — iyi durumda hiç tetiklenmeyenleri de — enstrümante etme emeğiyle satın alır.

Maliyet. Bu enstrümantasyon, nadiren devreye giren yerlerde ek bir iştir ve acil durumda güvenilir şekilde bildirim yapması için bakımı yapılmalıdır.

Ne zaman farklı karar veririz. Bir önlemin sessizce tetiklenmesinin sonuçsuz kalacağı kadar kritik olmadığı yerde enstrümantasyondan vazgeçilebilir; fark edilmeyen bir kısmi arızanın kötüleşebileceği yerde ise zorunludur.

8. Tipik hatalar

Sistemlerin kötü günde başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi yalnızca iyi gün için inşa etmiş olmanın varyasyonlarıdır:

• Parçaların kaçınılmaz arızası için tasarlamak yerine çalıştıklarını varsaymak.
• Bilinen arızalarda ne olacağını bilmeden bir sistemi bitmiş saymak.
• Hataları sınırlamak yerine önlemeye çalışmak — ve öngörülmemiş ilk arızada tüm sistemi kaybetmek.
• Diğer parçaları zaman sınırı olmadan çağırmak; öyle ki bir komşunun arızası kendi sisteminize sızar.
• İdempotent olmayan operasyonları otomatik olarak yeniden denemek — geçici hatayı çift zarara dönüştürmek.
• Zarif bir kademelendirmenin kullanıcıya işlevin bir kısmını koruyacağı yerde yalnızca hep-ya-hiç bilmek.
• Hiç prova edilmemiş önlemleri koruma olarak saymak — hiç geri yüklenmemiş yedek, hiç tetiklenmemiş zaman sınırı.
• Hata durumunda zarifçe kademelendirmek ama bunu bildirmemek — sistem fark edilmeden kan kaybetmeye devam eder.

9. Karar kontrol listesi

Bir sistemi hata durumu için tasarlarken sırayla netleştirilecekler:

• Arıza varsayıldı mı? Sistem, parçalarının çalışmasına göre değil, arızalanmasına göre mi tasarlandı?
• Hata modları biliniyor mu? Her önemli parça için, arızalandığında ne olacağı soruldu mu?
• Sınırlandı mı? Bir parçanın arızası, izolasyon ve zaman sınırları sayesinde yayılmak yerine yerel mi kalıyor?
• Güvenle tekrarlanabilir mi? Yalnızca mükerrer işlemleri önleyen (idempotent) operasyonlar mı otomatik olarak yeniden deneniyor; öyle ki ikinci deneme zarar vermiyor mu?
• Zarif kademelendirme? Tam işlev ile toptan çöküş arasında ana görevi koruyan ara kademeler var mı?
• Prova edildi mi? Önlemler yalnızca inşa edilmekle kalmayıp bilinçli olarak tetiklendi mi — korumak üzere olan şey tutuyor mu?
• Görünür mü? Her önlemin tetiklenmesi, sessiz kısmi arıza da dahil, fark ediliyor mu?
• Orantılı mı? Emek zararla orantılı mı — bir arızanın pahalıya patlayacağı yerde katı, sonuçsuz kalacağı yerde yalın?

Bu sorulara cevap verebilen, yalnızca iyi günde çalışan değil, kötü günü atlatan bir sistem inşa etmiştir.

Sıkça Sorulan Sorular

Hiçbir şeyin arızalanmamasını sağlayamaz mıyız? Hayır. Gerçek bir sistemde her parça eninde sonunda arızalanır — bir bağlantı, bir servis, bir disk, aşırı yüklenmiş bir komşu. Bu istisna değil, olağan durumdur. Bu yüzden hedef arızaları önlemek değil, bir parçanın arızası tüm sistemi sürüklemesin diye sonuçlarını sınırlamaktır.

“Hata modları bilinmeyen bir sistem bitmiş değildir” ne demek? Bilinen arızalarda ne olacağını kimsenin söyleyemediği bir sistemin yalnızca iyi gün için inşa edildiği anlamına gelir. Şu servis çöktüğünde ya da bu bağlantı koptuğunda ne olacağını bilmediğiniz sürece kötü günü düşünmemişsinizdir — ve yazılım kötü günde değerlendirilir.

İdempotency olmadan yeniden deneme neden tehlikelidir? Çünkü iki kez çalıştırıldığında iki kez etki eden bir operasyon, körü körüne yeniden denendiğinde gerçek zarar verir — zararsız bir geçici hatadan doğan çift tahsilat gibi. Yalnızca zarar vermeden tekrarlanabilen yeniden denenir ve durum ya da para değiştiren operasyonlar otomatik olarak yeniden denenmeden önce mükerrer işlemleri önleyen (idempotent) hâle getirilir.

Zarif kademelendirme nedir? Tam işlev ile toptan çöküş arasındaki ara kademelerin bilinçli olarak tasarlanmasıdır: ana görev sürerken ikincil bir işlevi kapatmak; hiç yanıt vermemek yerine daha eski bir yanıt sunmak. Bir kullanıcı kısmi bir hizmeti neredeyse her zaman tam bir kesintiye tercih eder. Hatalar altında hangi işlevin korunacağına ve hangisinin bırakılacağına tasarımda karar verilir.

Hata durumu neden prova edilmelidir? Çünkü prova edilmemiş bir önlem koruma değil, koruma görüntüsündeki bir umuttur — hiç geri yüklenmemiş yedek, hiç devreye girmemiş zaman sınırı. Arızayı bilinçli olarak tetikleyip sistemin düşünüldüğü gibi tepki verip vermediğini gözlemlediğinizde ancak dayanıklılık iddia edilmiş değil, kanıtlanmış olur.

Bunun observability ile ilişkisi nedir? Ayrılmazdır. Dayanıklılık bir hatanın tümünü sürüklememesini sağlar; observability ise onu görmenizi. Bildirmeden sessizce tetiklenen bir önlem sistemin yarasını gizler — sistem hasarlı olarak çalışmaya devam ederken onu sağlıklı sanırsınız. Bu yüzden hata durumuna yönelik her önlemin bir parçası, tetiklenmesinin fark edilmesidir.

İleri okuma

• Observability bir mimari meselesidir — diğer yarı: yalnızca gördüğünüzü savuşturabilirsiniz.
• Dağıtık sistemlerde idempotency — yeniden denemenin zarar vermek yerine iyileştirmesinin ön koşulu.
• Tahminden önce geri alınabilirlik — bir dayanıklılık biçimi olarak zararı geri alınabilir tutmak.
• Queue mu, senkron işleme mi — bir parçanın arızası diğerini sürüklemesin diye işi ayrıştırmak.

Temelinde Batunet Engineering Method yatar: hata durumu için tasarlamak, belirsiz olanı sınırlamak, dayanıklılığı ummak yerine prova etmek, ilk günden observability.

Son mühendislik ilkesi

Bir sistem ancak nasıl başarısız olduğunu bildiğinizde bitmiştir. İyi gün soru sormaz; hiçbir şey ters gitmediği için her ihmali affeder. Birinin onu önceden düşünüp düşünmediğini ancak kötü gün sınar — ve o gün onu düşünmek için artık çok geçtir. Bu yüzden hata durumu için tasarlamak özellikle kritik sistemlere eklenen bir malzeme değil, bir sistemin sonuna kadar düşünüldüğünün işaretidir. Hiç başarısız olmayan bir sistem inşa edilmez — öyle bir şey yoktur —; başarısız olup kırılmayan bir sistem inşa edilir. İkisi arasındaki fark, olaydan çok önce, tasarımın sakin anında belirlenir.

Yazılım iyi günde değil, kötü günde değerlendirilir. İyi gün için herkes inşa eder; fark, birinin kötü gün için de inşa edip etmediğinde ortaya çıkar.