loading...

re: Testing For Success vs. Failure VIEW POST

FULL DISCUSSION
 

will not need to be tweaked in the future even if our infrastructure changes

This alone is an obvious flag your requirements can never be met. It's not unreasonable that a case like

Times when we expect the ratio to not be 1, but we don't need to alert, as we have scheduled a change during that time period

will happen again in the future, but if you add more stuff to the infrastructure, your metrics will be down longer and thus hit the current threshold.


Ignoring the unreasonable demands:

You tested

  1. An alert you wanted alerted (.8)
  2. An alert you didn't want alerted (.9)
  3. No alert (1)

and used existing data points to verify them. The monitor "failing" would either be an alert when you don't want one (which you covered) or no alert when you need one, but aside from guaranteeing the monitor will never crash, I have no clue what he expects. Through your testing, you found the spot that, as long as it's running, you'll get the expected results based on prior knowledge.

 

I've had a lot of problems with this manager; they just go on for so long that, at a point, I wonder if I'm actually getting things wrong and it's not just him negating everything I do, so I appreciate the assessment.

Also, to clarify, the "will not need to be tweaked in the future" demand was not explicit, but implied. The request was "find a case where it doesn't work, and fix that", but with no indication of:

  1. whether if I find a single case, and fix it, it's done
  2. whether or not this is just an endless whack-a-mole problem

I am glad that I'm the only one who finds this vague request to be unreasonable :)

Code of Conduct Report abuse