Chris's Wiki :: blog/sysadmin/FirewallTestingProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/FirewallTestingProblem?atomcommentsDWiki2010-06-16T13:25:43ZRecent comments in Chris's Wiki :: blog/sysadmin/FirewallTestingProblem.From 69.113.211.148 on /blog/sysadmin/FirewallTestingProblemtag:CSpace:blog/sysadmin/FirewallTestingProblem:c3e24e1f29849a47ac67af9c019f6fa733f5cd57From 69.113.211.148<div class="wikitext"><p>The amount of work that goes into configuring a test environment should be proportional to the danger associated with the changes you're making.</p>
<p>If you're a normal institution, and the biggest danger associated with a rule change on a firewall is that you receive a couple of calls or Nagios alerts and have to take 30 seconds out of your day to roll back the config before you try again, then it's not a big deal -- this is specifically the overbearing kind of change management I argue against when I discuss the failings of process frameworks like ITIL and COBIT with people.</p>
<p>My stance on testing with the team I work with has always been this: if you break something, and can fix it before you cost anyone money, and nobody loses any data, then don't even bother testing it somewhere else first because it's a waste of time.</p>
<p>On the other hand, if you're upgrading a large mail system, ERP application or other critical piece of software with no real downgrade path, you'd better believe your dev network is going to replicate your production network as closely as you can afford.</p>
<p>--Jeff</p>
</div>2010-06-16T13:25:43Z