Created
October 2, 2018 03:26
-
-
Save djosephsen/fc1f048a2efef47f665b67a5b3b6386a to your computer and use it in GitHub Desktop.
I'm a newly embedded SRE; how do I get to know my dev team and their product?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Open Curiousity | |
| /ALWAYS ask stupid questions/ | |
| Acknowledge design wins, and call out things that don't look right | |
| * If your service has a front-end DNS name, reverse engineer it. What system actually responds to the initial request? An edge cache? A Load Balancer? An Nginx host? | |
| * Make a map of the lifecycle of a request to your team's service that begins at dns, and ends at the service's listening port | |
| * what does a request into your service look like? Is it an API endpoint? can you curl it? If so, craft a CURL request that you can use to test whether or not your service is "up" | |
| * What does the output from your team's service look like? Can you create a unit test using your CURL request and the expected output from a service request? | |
| * Whom, among all the engineers working on your new team, has been working with the service the longest? | |
| * Is your teams service more read sensitive? or Write Sensitive? | |
| * What types of data storage do the engineers on your new team tend to rely upon? RDS? Elasticache? Why did they choose the storage infrastructure they did? | |
| * What other services does your new team's service rely upon? What API calls does it make and under what conditions? | |
| * What SLI's are in use by the team managing your service? Do their SLI's account for things like network boundaries? and queue cardinality? | |
| * Given what you know about the service so far, would you have chosen the same SLI's? | |
| * Design a plan to destroy your service. If you had to attack your service and render it catestrophically offline, what would you do? | |
| * Pick a single feature that your new team is currently working on and explain it to someone who doesn't know anything about the service. | |
| * Pick a single bugfix that your new team is currently working on and explain it to someone who doesn't know anything about the service. | |
| * Find the last 5 tickets that have originated from your new team that have been serviced by ops (re) and categorize them (access request, monitoring request etc..) | |
| Open Curiousity | |
| /ALWAYS ask stupid questions/ | |
| Acknowledge design wins, and call out things that don't look right |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment