diff options
| author | Paul Buetow <paul@buetow.org> | 2022-01-23 16:13:23 +0000 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2022-01-23 16:13:23 +0000 |
| commit | c2a7a5f812ec1fde534adab4c954316643135335 (patch) | |
| tree | 0e3eefbcd9b390db8883d12e2fee297b13287dc4 /gemfeed/2021-10-22-defensive-devops.html | |
| parent | 59d728b079e95876eb27a7169374b3d1060d80e4 (diff) | |
Publishing new version
Diffstat (limited to 'gemfeed/2021-10-22-defensive-devops.html')
| -rw-r--r-- | gemfeed/2021-10-22-defensive-devops.html | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/gemfeed/2021-10-22-defensive-devops.html b/gemfeed/2021-10-22-defensive-devops.html index 166bbc44..7b4b27aa 100644 --- a/gemfeed/2021-10-22-defensive-devops.html +++ b/gemfeed/2021-10-22-defensive-devops.html @@ -17,7 +17,7 @@ (__((__((___()()()------------------------------------' |_____| ASCII Art by Clyde Watson </pre> -<p class="quote"><i>Published by Paul Buetow 2021-10-22</i></p> +<p class="quote"><i>Published by Paul at 2021-10-22</i></p> <p>I have seen many different setups and infrastructures during my carreer. My roles always included front-line ad-hoc fire fighting production issues. This often involves identifying and fixing these under time pressure, without the comfort of 2-week-long SCRUM sprints and without an exhaustive QA process. I also wrote a lot of code (Bash, Ruby, Perl, Go, and a little Java), and I followed the typical software development process, but that did not always apply to critical production issues.</p> <p>Unfortunately, no system is 100% reliable, and you can never be prepared for a subset of the possible problem-space. IT infrastructures can be complex. Not even mentioning Kubernetes yet, a Microservice-based infrastructure can complicate things even further. You can take care of 99% of all potential problems by following all DevOps best practices. Those best practices are not the subject of this blog post; this post is about the sub 1% of the issues arising from nowhere you can't be prepared for. </p> <p>Is there a software bug in a production, even though the software passed QA (after all, it is challenging to reproduce production behaviour in an artificial testing environment) and the software didn't show any issues running in production until a special case came up just now after it got deployed to production a week ago? Are there multiple hardware failure happening which causes loss of service redundancy or data inaccessibility? Is the automation of external customers connected to our infrastructure putting unexpectedly extra pressure on your grid, driving higher latencies and putting the SLAs at risk? You bet the solution is: Sysadmins, SREs and DevOps Engineers to the rescue. </p> @@ -75,7 +75,7 @@ <p class="footer"> Generated with <a href="https://codeberg.org/foozone/gemtexter">Gemtexter</a> | served by <a href="https://www.OpenBSD.org">OpenBSD</a>/<a href="https://man.openbsd.org/httpd.8">httpd(8)</a> | -<a href="https://www2.foo.zone/site-mirrors.html">Site Mirrors</a> +<a href="https://www2.buetow.org/site-mirrors.html">Site Mirrors</a> </p> </body> </html> |