We may have been in environments where email, texting or messaging alerts of some type are configured. Initially, we feel enthusiasm that we were able to create an alert on an event, but as we add more, we end up in a situation where we're bombarded with noise. Rather than solving the problem (because newer problems arise), we're now faced with an issue of prioritizing alerts. In some cases, we realize that our alerting wasn't as necessary as we thought - maybe a job failure was something that could happen. This issue is everywhere in tech, so don't feel bad if you find that your company is not following the best practices with alerting. You can review the discussion in the video Alerting Best Practices.
We should consider the story of the Boy Who Cried Wolf: false alerts or annoying alerts train people to ignore them. This could have unintended consequences, as technical teams may begin to ignore alerting all together, when some alerting is important. Thus, in the video I address some points you should consider reflected in the following questions:
- In the context of database administration and development, what is the definition of an alert and what should we consider based on this definition?
- If we plan to alert on an event, what should we immediately consider based on that alert? Based on that consideration, how would we design our alert or what would we possibly do for that alert?
- Why is prevention a better strategy than alerting? How should we consider prevention over alerting in our architecture?
- If we do alert on an issue, how can we reduce the troubleshooting time for the team or individual who solves the issue (keep in mind, that it may not be us at the time the alert is issued)?
For mastering data transformation from one form to another form, check out the highest-rated Automating ETL course on Udemy. For a coupon to the course, check out the trailer video on the channel SQL In Six Minutes.
One final question to consider: in an environment where you are being bombarded with an alert, what's the first thing you think of when you get an alert? If it's not how to solve the issue, but whether the alert is noise or not noise, the problem is that your environment is training people to ignore the alert or to delay on the alert. In addition, if you already have many items on your plate, you move the alert down in priority and may not solve it that day or later. This is because you already have many other problems you have to solve; the alert simply carries no meaning to you for that moment. Unfortunately, it's easy to email or text an alert and developers like the feeling of getting emails or alerts when they start, but these same alerts can end up creating a spam situation where the person receiving them cannot respond to all of thenm. This is why I strongly suggest keeping alerting to a minimum.
Are you looking for tech consultants that can assist with design and development? From building custom applications to working with existing infrastructure that's causing you trouble, we can get you connected to consultants who can assist. In the case of poor alerting, we can help you prioritize what you need and possibly automate some of your next steps to save you time. You can contact for assistance.