1. Streetlight Anti-Method: This method is actually the absence of a deliberate methodology. The user analyzes performances by choosing observability tools that are familiar, found on the Internet, or just at random to see if anything obvious shows up. This approach is hit or miss and can overlook many types of issues.
Even when this method reveals an issue, it can be slow as tools or tunings unrelated to the issue are found and tried, just because they are familiar. This methodology is therefore named after an observational bias called the streetlight effect.
2. Random Change Anti-Method: This is an experimental methodology. The user randomly guesses where the problem may be and then changes things until it goes away. The approach is as follows:
1) Pick a random item to change (e.g., a tunable parameter).
2) Change it in one direction.
3) Measure performance.
4) Change it in the other direction.
5) Measure performance.
6) Were the results in step 3 or step 5 are better than the baseline? If so, keep the change and go back to step 1.
3. Blame-Someone-Else Anti-Method: This anti-methodology follows these steps:
1) Find a system or environment component for which you are not responsible.
2) Hypothesize that the issue is with that component.
3) Redirect the issue to the team responsible for that component.
4) When proven wrong, go back to step 1.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
