http___principlesofchaos.org_tr__1.xml
1.1 2.1 3.1 4.1 4.2 4.3 5.1 5.2 6.1 6.2 6.3 6.4 7.1 7.2 7.3 8.1 9.1 9.2 10.1 11.1 12.1 13.1 14.1 14.2 15.1 16.1 16.2 17.1 18.1 18.2 18.3 18.4 19.1 20.1 20.2 20.3 20.4 21.1 22.1 22.2 22.3 23.1 24.1 24.2 24.3 25.1 26.1 26.2 27.1 27.2 27.3 28.1
PRINCIPLES OF CHAOS ENGINEERING Last Update: 2019 March (changes) Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production. Advances in large-scale, distributed software systems are changing the game for software engineering. As an industry, we are quick to adopt practices that increase flexibility of development and velocity of deployment. An urgent question follows on the heels of these benefits: How much confidence we can have in the complex systems that we put into production? Even when all of the individual services in a distributed system are functioning properly, the interactions between those services can cause unpredictable outcomes. Unpredictable outcomes, compounded by rare but disruptive real-world events that affect production environments, make these distributed systems inherently chaotic. We need to identify weaknesses before they manifest in system-wide, aberrant behaviors. Systemic weaknesses could take the form of: improper fallback settings when a service is unavailable; retry storms from improperly tuned timeouts; outages when a downstream dependency receives too much traffic; cascading failures when a single point of failure crashes; etc. We must address the most significant weaknesses proactively, before they affect our customers in production. We need a way to manage the chaos inherent in these systems, take advantage of increasing flexibility and velocity, and have confidence in our production deployments despite the complexity that they represent. An empirical, systems-based approach addresses the chaos in distributed systems at scale and builds confidence in the ability of those systems to withstand realistic conditions. We learn about the behavior of a distributed system by observing it during a controlled experiment. We call this Chaos Engineering. CHAOS IN PRACTICE To specifically address the uncertainty of distributed systems at scale, Chaos Engineering can be thought of as the facilitation of experiments to uncover systemic weaknesses. These experiments follow four steps: - Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior. - Hypothesize that this steady state will continue in both the control group and the experimental group. - Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc. - Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group. The harder it is to disrupt the steady state, the more confidence we have in the behavior of the system. If a weakness is uncovered, we now have a target for improvement before that behavior manifests in the system at large. ADVANCED PRINCIPLES The following principles describe an ideal application of Chaos Engineering, applied to the processes of experimentation described above. The degree to which these principles are pursued strongly correlates to the confidence we can have in a distributed system at scale. Build a Hypothesis around Steady State Behavior Focus on the measurable output of a system, rather than internal attributes of the system. Measurements of that output over a short period of time constitute a proxy for the system’s steady state. The overall system’s throughput, error rates, latency percentiles, etc. could all be metrics of interest representing steady state behavior. By focusing on systemic behavior patterns during experiments, Chaos verifies that the system does work, rather than trying to validate how it works. Vary Real-world Events Chaos variables reflect real-world events. Prioritize events either by potential impact or estimated frequency. Consider events that correspond to hardware failures like servers dying, software failures like malformed responses, and non-failure events like a spike in traffic or a scaling event. Any event capable of disrupting steady state is a potential variable in a Chaos experiment. Run Experiments in Production Systems behave differently depending on environment and traffic patterns. Since the behavior of utilization can change at any time, sampling real traffic is the only way to reliably capture the request path. To guarantee both authenticity of the way in which the system is exercised and relevance to the current deployed system, Chaos strongly prefers to experiment directly on production traffic. Automate Experiments to Run Continuously Running experiments manually is labor-intensive and ultimately unsustainable. Automate experiments and run them continuously. Chaos Engineering builds automation into the system to drive both orchestration and analysis. Minimize Blast Radius Experimenting in production has the potential to cause unnecessary customer pain. While there must be an allowance for some short-term negative impact, it is the responsibility and obligation of the Chaos Engineer to ensure the fallout from experiments are minimized and contained. Chaos Engineering is a powerful practice that is already changing how software is designed and engineered at some of the largest-scale operations in the world. Where other practices address velocity and flexibility, Chaos specifically tackles systemic uncertainty in these distributed systems. The Principles of Chaos provide confidence to innovate quickly at massive scales and give customers the high quality experiences they deserve. Join the ongoing discussion of the Principles of Chaos and their application in the Chaos Community.
1.1 2.1 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 11.1 12.1 13.1 14.1 15.1 16.1 17.1 18.1 19.1 20.1 21.1 22.1 23.1 24.1 25.1 26.1 27.1 28.1
KAOS MÜHENDİSLİĞİNİN PRENSİPLERİ Son Güncelleme: Mayıs 2018 Kaos Mühendisliği, canlı ortamda oluşabilecek çalkantılı koşullara dayanma kabiliyetine olan güveni artırmak için dağıtık bir sistem üzerinde deney yapma disiplinidir. Büyük ölçekli dağıtık sistemlerdeki gelişmeler, yazılım mühendisliği alanında oyunun kurallarını değiştirmekteler. Endüstri olarak, geliştirmenin esnekliğini ve dağıtımın sıklığını artıran değişiklikleri hızlı biçimde benimsiyoruz. Bu değişikliklerin getirdiği avantajları önemli bir soru takip ediyor: Canlı ortamlara sunduğumuz kompleks sistemlere ne kadar güvenebiliriz ? Dağıtık bir sistemdeki tüm servisler ayrı ayrı düzgün çalışıyor olsalar bile, bu servislerin arasındaki ilişkiler beklenmeyen sonuçlar doğurabilirler. Beklenmeyen sonuçlar, canlı ortamları etkileyen nadir fakat yıkıcı gerçek dünya olayları ile birleştiklerinde, dağıtık sistemler doğal olarak kaotik olurlar. Zayıflıkları, sistem çapında anormal davranışlara dönüşmeden önce tanımlamamız gerekir. Sistemsel zayıflıklar: servisin kullanım dışı kalması durumunda geri dönüş planlarının düzgün çalışmamasına sebep olan ayarlar; Yanlış ayarlanmış zaman aşımı süreleri sebebiyle oluşan yeniden deneme kuyrukları; Fazla trafikten kaynaklanan kesintiler; “Tek hata noktası” durumlarının üst üste gelmesi ve benzeri durumlar olarak ortaya çıkabilir. Müşterilerimizin canlı ortamlarını etkilemeden önce, en önemli zayıflıkları proaktif olarak ele almalıyız. Bu sistemlerdeki kaosu yönetmenin, artan esneklik ve hızın avantajlarını kullanmanın ve kompleksitelerine rağmen canlı ortamlarımıza olan güveni artırmanın bir yolunu bulmalıyız. Ampirik, sistem tabanlı bir yaklaşım, dağıtık sistemlerdeki kaosu ölçeklendirir ve bu sistemlerin gerçekçi koşullara dayanma becerisine olan güveni artırır. Bizler, dağıtık bir sistemin davranışlarını, kontrollü bir deney ile gözlemleyerek öğreniyoruz. Biz buna Kaos Mühendisliği diyoruz. UYGULAMADA KAOS Büyük Ölçekli Dağıtık sistemlerin belirsizliklerini özellikle ele almak için, Kaos Mühendisliği, sistemik zayıflıkları ortaya çıkarmak amaçlı deneylerin kolaylaştırılması olarak düşünülebilir. Bu deneyler dört adımdan oluşur: - Normal davranış gösteren bir sistemin ölçülebilir durumunu “Kararlı Çalışma Durumu” olarak tanımlayın. - Bu kararlı durumun hem kontrol grubunda hem de deney grubunda devam edeceğini varsayın. - Çalışmayı durduran sunucular, arıza yapan sabit diskler, kesilen ağ bağlantıları vb. gerçek dünya olaylarını yansıtan değişkenleri tanımlayın. - Kontrol grubu ile deney grubu arasındaki “Kararlı Çalışma Durumu"nda bir farklılık arayarak varsayımınızı çürütmeye çalışın. İstikrarlı Durumu bozmak ne kadar zor ise, sistemin davranışına olan güvenimiz o kadar fazladır. Eğer bir zayıflık tespit edersek, bu zayıflık tüm sistem genelinde problem teşkil etmeden önce düzeltme yapmayı kendimize hedef belirlememiz gerekir. İLERİ DÜZEY PRENSİPLER Aşağıdaki ilkeler, yukarıda tarif edilen deney süreçlerine uygulanan ideal bir Kaos Mühendisliği uygulamasını tanımlar. Bu ilkelerin izlenme derecesi, ölçeklendirilmiş bir sistemde sahip olabileceğimiz güven ile güçlü bir şekilde ilişkilidir. Kararlı Çalışma Durumu Üzerine Bir Hipotez Oluşturun Sistemin iç öznitelikleri yerine bir sistemin ölçülebilir çıktısına odaklanın. Bu çıktının kısa bir süre içindeki ölçümleri, sistemin kararlı durumu için bir örnek oluşturur. Sistem genelindeki iş hacmi, hata oranları, gecikme yüzdeleri vb. kararlı durum davranışını temsil eden ölçütler olabilirler. Kaos, denemeler sırasında sistemik davranış kalıplarına odaklanarak, sistemin nasıl çalıştığını doğrulamaktan ziyade sistemin çalıştığını doğrular. Gerçek Dünya Olaylarını Çeşitlendirin Kaos değişkenleri gerçek dünya olaylarını yansıtır. Olayları ya potansiyel etki ya da tahmini sıklık ile önceliklendirin. Sunucuların çökmesi gibi donanımsal hatalar, hatalı cevap dönüşleri gibi yazılım hataları ve trafikte artış ya da ölçekleme problemi gibi hata olmayan olayları göz önünde bulundurun. Kararlı durumu bozabilecek herhangi bir olay, bir Kaos deneyinde potansiyel bir değişkendir. Canlı Ortamda Deneyler Yapın Sistemler, ortam ve trafik modellerine bağlı olarak farklı davranır. Kullanım davranışı her an değişebileceğinden, talep yoğunluğunu güvenilir şekilde yakalamanın tek yolu gerçek trafiği örneklemektir. Sistemin uygulandığı yöntemlerin gerçekliğini ve mevcut konuşlandırılmış sistemle alaka düzeyini garanti etmek için, Kaos, doğrudan canlı ortam trafiği üzerinde denemeler yapmayı tercih eder. Deneyleri Sürekli Çalışacak Şekilde Otomatize Edin Deneyleri manuel çalıştırmak, iş gücü ister ve sonuç olarak sürdürülemezdir. Deneyleri otomatikleştirin ve sürekli olarak çalıştırın. Chaos Engineering, hem orkestrasyon hem de analiz için sistemin otomatize edilmesini sağlar. Patlama Alanını Küçültün Canlı ortamda deney yapmak gereksiz müşteri acılarına neden olma potansiyeline sahiptir. Bazı kısa vadeli olumsuz etkiler için bir tolerans payı ayırılması gerekliliğiyle birlikte, deneylerden kaynaklanan hasarların en aza indirilmesini ve içerilmesini sağlamak Kaos Mühendisi’nin sorumluluğu ve yükümlülüğüdür. Kaos Mühendisliği, dünya çapındaki pek çok çok-büyük ölçekli operasyonda, yazılımın nasıl tasarlandığını değiştirmekte olan güçlü bir uygulamadır. Diğer metotlar hız ve esnekliğe hitap etmekte iken, Kaos, özellikle dağıtık sistemlerde sistemik belirsizliği ele alır. Kaos İlkeleri, kitlesel ölçeklerde hızlı bir şekilde yenilik yapmaya ve müşterilere hak ettikleri yüksek kaliteli deneyimleri vermek üzere sistemlere olan güveni artırmayı hedefler. Kaos İlkeleri ve bunların uygulamaları üzerine devam eden tartışmalara katılın Google Grubunda Chaos Community.