If you ever had a chance to squeeze into developers room, you could hear a lot of talks about “best practices”. Seems like everything is covered. Best practices exist for everything: naming conventions and coding patterns, development processes and standup meetings, black-, grey- and white-box testing. Saying nothing about writing specs. Same story for IT – internet is full of advises of any kind. Although all these “best practices” have been created to make life better, I prefer the balanced world. So it is high time to write some “worst practice” notes.
Here is the list of 7 worst practices for SCOM Management Pack design I can think of now:
- Multiple objects/counters per performance collection rule;
- Using “see ‘alert context’ tab for more details” in alert description;
- Not considering Management Pack to be a product/part of the product;
- Ignore “corner” cases;
- No ways to do historical/retrospective analysis;
- Ignore user and user experience;
- Too narrow, too wide, too complex, too simple;
Update: I’ve added more worst practices noted by readers and updated the post title. Currently we have 7+2=9 points to discuss.
- Discovering properties that are significantly dynamic and at excessively frequent intervals. (Thanks, Craig)
- Using eventlogs for determining healthy and unhealthy states unless it is the only option. (Thanks, Craig)
I will discuss all these points in very details in upcoming posts.
And while you’re waiting for updates, enjoy the picture below and don’t forget to leave a comment or tweet me at @oksandbox about other worst practices you know.