Defining scaling rules seems simple.<\/p>\n\n
But in practice, it is one of the main reasons for incidents:<\/p>\n\n
And almost always the problem is not the tool.<\/p>\n\n
\ud83d\udc49 It’s how the rules are defined.<\/p>\n\n
A good scaling rule should:<\/p>\n\n
Not before, not after. At the right time. <\/p>\n\n
Many rules are defined as follows:<\/p>\n\n
\ud83d\udc49 “if no one responds in X minutes, escalate.”<\/p>\n\n
And although it sounds logical, it doesn’t always work well.<\/p>\n\n
Because not all alerts are the same.<\/p>\n\n
Result:<\/p>\n\n
\ud83d\udc49 More noise is generated than value.<\/p>\n\n
To define scaling properly, one must first understand this:<\/p>\n\n
\ud83d\udc49 is the first filter<\/p>\n\n
The goal of scaling is clear: to solve as quickly as possible, with the correct level<\/strong><\/p>\n\n Many times:<\/p>\n\n \ud83d\udc49 Result: N2 and N3 collapse<\/p>\n\n Or the other way around:<\/p>\n\n \ud83d\udc49 Result: the problem escalates late.<\/p>\n\n Efficiency is not in scaling faster.<\/p>\n\n You are in:<\/p>\n\n \ud83d\udc49 better scaling<\/strong><\/p>\n\n That means:<\/p>\n\n Here is something interesting.<\/p>\n\n Much of N1’s work is:<\/p>\n\n \ud83d\udc49 repetitive tasks<\/p>\n\n Today this can be automated.<\/p>\n\n With tools such as 24Brains (24Cevent add-on)<\/strong>, the N1 can be automated:<\/p>\n\n \ud83d\udc49 It’s like having an N1 working in seconds.<\/p>\n\n A lot.<\/p>\n\n \ud83d\udc49 Scaling stops being reactive. It becomes intelligent. <\/p>\n\n Not all alerts should escalate equally.<\/p>\n\n Defines:<\/p>\n\n \ud83d\udc49 each with its own logic.<\/p>\n\n Don’t use one time for everything.<\/p>\n\n Example:<\/p>\n\n Notification is not enough.<\/p>\n\n \ud83d\udc49 someone has to accept the alert.<\/p>\n\n If there is no confirmation:<\/p>\n\n auto-scaling<\/p>\n\n One of the biggest mistakes:<\/p>\n\n scalar without information<\/p>\n\n Each escalation should include:<\/p>\n\n \ud83d\udc49 This greatly reduces resolution times.<\/p>\n\n More scaling \u2260 better operation<\/p>\n\n too much climbing leads to fatigue<\/p>\n\n The objective is:<\/p>\n\n \ud83d\udc49 f ewer but better scalings<\/strong><\/p>\n\n It is not just passing the alert to another level.<\/p>\n\n Es:<\/p>\n\n \ud83d\udc49 and do it fast<\/p>\n\n <\/p>\n\n Scaling rules are not a technical detail.<\/p>\n\n They are one of the most important parts of the operation.<\/p>\n\n And when combined with automation in the N1:<\/p>\n\n \ud83d\udc49 the impact is immediate<\/p>\n\n <\/p>\n\n If today your team feels that alerts are escalating late, poorly or with little context, it’s probably not a problem with the tools, but with how the rules are defined.<\/p>\n\n 24Cevent allows you to set up flexible escalations and ensure responsiveness, and together with 24Brains automates the initial analysis, helping each alert reach the right level at the right time.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Many rules are defined as follows: “if no one responds in X minutes, escalate” And although it sounds logical, it does not always work well.So what happens in practice?<\/h1>\n\n
\n
\n
This is where time is gained (or lost).<\/h1>\n\n
\n
What if the N1 was not manual?<\/h1>\n\n
\n
\n
What does this change?<\/h1>\n\n
Formerly<\/h2>\n\n
\n
Then<\/h2>\n\n
\n
How to define good scaling rules?<\/h1>\n\n
1. Classify your alerts well<\/h2>\n\n
\n
2. Define realistic times<\/h2>\n\n
\n
3. Secure confirmation<\/h2>\n\n
4. Scale with context<\/h2>\n\n
\n
5. Avoid climbing for climbing’s sake<\/h2>\n\n
So, what is good climbing?<\/h1>\n\n
\n
\n
\nBecause not all alerts are equal.
\nResult: critical alerts escalate late
\n, minor alerts escalate unnecessarily, the team loses focus = More noise than value is generated.<\/p>\n","protected":false},"author":2,"featured_media":4990,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[178],"tags":[231,229,182,232,233,230],"class_list":["post-4992","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledge-center","tag-definition-of-scaling-rules","tag-escalation","tag-it-incidents","tag-n1","tag-n2","tag-scaling-rules"],"_links":{"self":[{"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/posts\/4992","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/comments?post=4992"}],"version-history":[{"count":1,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/posts\/4992\/revisions"}],"predecessor-version":[{"id":4993,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/posts\/4992\/revisions\/4993"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/media\/4990"}],"wp:attachment":[{"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/media?parent=4992"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/categories?post=4992"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/24cevent.com\/en\/wp-json\/wp\/v2\/tags?post=4992"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}