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
An alert you wanted alerted (.8)
An alert you didn't want alerted (.9)
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.
DevOps engineer, jq wizard, API enthusiast, a living embodiment of Caps Lock As A Service. Known to use Bash instead of OOP far past the point of reasonability.
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:
whether if I find a single case, and fix it, it's done
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 :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This alone is an obvious flag your requirements can never be met. It's not unreasonable that a case like
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
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:
I am glad that I'm the only one who finds this vague request to be unreasonable :)