-
"Conceiving of monitoring, alerting, configuration, documentation, and incident response scripts as a unified product where the primary objective is to “increase the reliability of the service” provides another strategy for SRE teams to accomplish their overall goals." @joans/1150759807969837057Permalink
Mood +5 🙂
-
"No need to adopt a new JS framework, just find a way to make your tools easier to use. When looking for places to apply product engineering, ask yourself who your users are, what state they’re in when they come to your tool, and how you can make their task a little easier"Permalink
-
This reminds me of one of the first things I did when I started my job @ericsson. Not SRE, but devs weren't writing many tests . There were two test runners. Unit-style tests went through a very integration-style test runner and API tests went through a webform 😱Permalink
-
We didn't need to test Apache, so I built a simpler test runner (inspired by rspec and junit; this was all perl so used Test::More for help). We started by testing calls that Apache would be making into our perl code, then we discovered how well it could work for unit tests too.Permalink
-
Devs were much happier and tested a lot more.