<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Reliability on Humayun Manzer</title><link>https://humayunhub.com/tags/reliability/</link><description>Recent content in Reliability on Humayun Manzer</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 24 Aug 2025 23:05:00 +0800</lastBuildDate><atom:link href="https://humayunhub.com/tags/reliability/index.xml" rel="self" type="application/rss+xml"/><item><title>Chaos Engineering in Small Teams: Worth It or Overkill?</title><link>https://humayunhub.com/blog/2025/chaosengineering/</link><pubDate>Sun, 24 Aug 2025 23:05:00 +0800</pubDate><guid>https://humayunhub.com/blog/2025/chaosengineering/</guid><description>&lt;div class="paragraph">

 &lt;small>&lt;i>&lt;a href="https://unsplash.com/photos/blue-and-green-peacock-feather-58Z17lnVS4U?utm_content=creditShareLink&amp;amp;utm_medium=referral&amp;amp;utm_source=unsplash">Photo credit&lt;/a>&lt;/i>&lt;/small>

&lt;/div>
&lt;div class="paragraph">
&lt;p>Netflix made Chaos Engineering famous with Chaos Monkey, but what about small teams with only a few engineers? Is it practical, or just a distraction when you’ve already got your hands full with CI/CD, monitoring, and on-call? Here’s a grounded look at when it makes sense and how to keep it lightweight.&lt;/p>
&lt;/div>
&lt;div class="paragraph">
&lt;p>Chaos Engineering is about introducing controlled failures to expose weaknesses before they show up in production. Examples: killing pods, injecting latency, simulating node crashes. For tech giants with hundreds of services, it’s a must. For smaller teams, the question is whether the effort pays off.&lt;/p>
&lt;/div></description></item></channel></rss>