4 ms·
I have a question. The fact that an incident review occurs suggests that there was some kind of incident, and one that presumably wasn't anticipated and automat
by joncrocks 10y ago
I have a question. The fact that an incident review occurs suggests that there was some kind of incident, and one that presumably wasn't anticipated and automatically handled.
What does one do in that kind of situation where one has a novel problem and needs to do something about it?
Should the organisation keeps all of the details of how to do things and how things work in their heads (and presumably ensuring that enough people are available whenever you might have an issue), or work out how things work/what does what on the fly? (or maybe a mix of the two?)
- jedberg 10y agoWell, ideally the person who wrote the code is fixing it, and should know how it works. Or at least a close teammate. But if you don't have that luxury, then it means you're hoping that the documentation is up to date, but chances are that if you don't have enough resources to have on call coverage from someone very familiar with the area that's having a problem, then there is a good chance they didn't have time to write or update documentation. So ideally the person who wrote it has it in their head, or you're figuring it out on the fly and hoping you have good comments in the code and good metrics.
- zwischenzug 10y ago> Well, ideally the person who wrote the code is fixing it, and should know how it works. Or at least a close teammate. What if the code is 15 years old, and everyone involved with writing it has left?