What you can do is focus on the likely ones, put whatever in place you can that's sane, but focus all the crazy effort you would have to do to track down the diminishing returns of trying to make failure impossible and start spending that time and effort on making recovery quick and easy. It's impossible to actually make it so one person can't cause any problems, because you can't eliminate all dependencies, and you can even accurately know what they all are. It might sound like I'm changing the goal posts, but that's sort of my point, these are all dependencies on each other.
#GODOCS VIDEOGAMES INSTALL#
Someone needs to install and administer the system that pushes the code, and even if they don't have direct access to push the code to where it eventually goes, someone's access credentials (or someone that controls the system that has access credentials) has access somewhere along the way.īut who controls that the code system is up and available even allow checkins? Can one person break that? What about who controls the power state of the systems the code gets checked in on? Is that also ensured not to be a single person? What about office access? What about the power main at your building? Is it really impossible for one person to cause problems there? There's always someone with rights to push code manually, or tell the system to push an older version of code which won't work anymore. > For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code. Other problems you fix by making it hard to happen and putting provisions in place that mitigate the problems if they do.
Some problems you fix by making it so they can't happen. Your office IT personnel? Yep, they can cause you problems too. Got a shared VM infrastuture, whether in house or in the cloud? The people that administer that can cause you problems. You can't really engineer yourself out of that problem without making every team and service a silo that going from top to bottom.
Turn right around and go back to making sure a team can work on this.įinally, realize that sometimes the thing only one team can break is an underlying dependency for many other things, and they may inadvertently affect those. That effectively means only a single person can fix or work on the system too, and congratulations, you've engineered yourself into a bus-factor of one. If only a single person can break the system, you've gone to far.
If only the people on a specific team responsible for a system can affect the system, now you've reached fairly good point, where there's separation of concerns and you're mitigating the potential problems. If any employee that's an engineer, sysadmin or developer can break it, well now you're at least reducing the problem to a more specific set of people. Ever worked for a company with less than ten people? There's probably something any employee can break). If any employee can break it, it's probably broken (there are very small scales where even this doesn't apply. If any random person can break it, it's already broken. Again, why not just call the SME first if they knew who it was and the SME didn't create documentation because they are "too busy".Įh, that's a nice thing to say, but it only makes sense at certain scales, and no matter what, there's always a person that can break it. Well, I didn't know who the SME was and there's no documentation or list of what who is the SME for which part of the system, nor was I instructed to immediately call the SME. So, I asked how I should have handled it without any training or documentation. Why even call me if you're just going to call the SME without giving me time to look at it? I got negative feedback from my manager about the way I handled it. So I'm looking for the issue/fix for 5 minutes and they tell me they know who the SME is for the functionality, so they will call them. Before I could even get halfway through, the person called again (why not leave the voicemail on the final attempt?). I did see a voicemail, so I started listening and logging on. I got a call at 1 am, missed it, and waited one minute to see if there was a message. I was not given any procedures or trouble shooting documents. I was on call as a new developer on a system.
0 kommentar(er)
