aboutsummaryrefslogtreecommitdiff
path: root/content/posts
diff options
context:
space:
mode:
authorMartin Ashby <martin@ashbysoft.com>2022-12-27 18:59:24 +0000
committerMartin Ashby <martin@ashbysoft.com>2022-12-27 18:59:24 +0000
commitd8d7a2a5ff43f913322473a9714a63f1fd8d2303 (patch)
tree80ac59094309821a96eae8a15d3bc9b664cd2a06 /content/posts
parentbb96b37b11aaa2a3771e17281e925e8cc4c59206 (diff)
downloadmfashby.net-d8d7a2a5ff43f913322473a9714a63f1fd8d2303.tar.gz
mfashby.net-d8d7a2a5ff43f913322473a9714a63f1fd8d2303.tar.bz2
mfashby.net-d8d7a2a5ff43f913322473a9714a63f1fd8d2303.tar.xz
mfashby.net-d8d7a2a5ff43f913322473a9714a63f1fd8d2303.zip
draft post on google SRE book
Diffstat (limited to 'content/posts')
-rw-r--r--content/posts/2022-12-27-book-site-reliability-engineering.md11
1 files changed, 11 insertions, 0 deletions
diff --git a/content/posts/2022-12-27-book-site-reliability-engineering.md b/content/posts/2022-12-27-book-site-reliability-engineering.md
new file mode 100644
index 0000000..84996e7
--- /dev/null
+++ b/content/posts/2022-12-27-book-site-reliability-engineering.md
@@ -0,0 +1,11 @@
+---
+title: "Book - Site Reliability Engineering"
+date: 2022-12-27T16:16:43Z
+draft: true
+---
+
+I've been reading [Site Reliability Engineering](https://sre.google/sre-book/table-of-contents/) from Google/O'Reilly. It's an interesting insight into how Google scales their operations work. So far I'm about 1/3 of the way through.
+
+I'm reading this looking for tips to apply at my current job. It's fairly plain that most of the advice and stories are relevant to a huge organization with sprawling complexity, but also enormous resources to manage it. It's easy to see how some advice like holding meaningful postmortems for incidents, and having and maintaining incident response plans, and having extensive monitoring is possible and useful at Google, but less clear which pieces could be applied at a smaller organization.
+
+A secondary take-away is outsourcing as much as possible: when SRE isn't your core capability, and you aren't big enough to need it, use hosted / fully managed services wherever possible; taking away as much of the maintenance burden as possible.