These are best practices from our experience working on supporting and building large scale production middleware environments
1) Don’t get your Developers to Build your Production Configuration
Despite the term "devops" don’t get the devs to build the ops environment. Now we are all in favour of the agility and mindset of devops, like continuous delivery (see our other best practices), that arises from embracing devops principles but some devs assume devops mean they deliver production infrastructure. This is usually a bad thing as most developers do not have the expertise in creating best practice middleware configurations tuned for HA, Scalability, Security and Performance. Most middleware products "out of the box" are configured for ease of development so devs can get started easily and quickly in building cool stuff. They aren’t configured out of the box for production. Devs don’t have the time (or often the inclination) to track feature updates in minor releases, patch sets or critical security and bug fixes. It’s the job of the ops team to track all these things and define a standard operational build of your middleware infrastructure which devs can deploy to.
2) Put in place in-depth historical Middleware and JVM monitoring
Many of our new customers just don’t have adequate historical monitoring of their middleware infrastructure. Sure they have Nagios or some equivalent monitoring networks, cpu, disk usage, swap etc. but they rarely have anything monitoring JVM stats, Connection pool sizes, JMS queue back logs, JVM thread usage etc… all critical things in a Java middleware environment. Key metrics should be monitored, stored and be available for triage, diagnosis and capacity planning. Even better put in place a full Application Performance Management tool to deep dive into the Java code and JDBC layers. Once in place configure appropriate alerts so action can be taken before an outage. Without these things it is likely your customers will be the first people to notice an outage in the middleware.
3) Ensure Scripted and versioned Installation, Configuration and Deployment
Always script initial creation of your middleware environments and get the developers to script their application deployments. In fact script all changes to your middleware and also ensure you have roll back scripts to reverse the changes you just made. Put those scripts into configuration management and label them and manage them as you would any software product. Once you’ve done this you can rapidly create new production and test environments you can force your developers to really get devops and build applications that can be deployed without hours of manual steps. It removes human error, creates repeatability and aids agility it is generally a good thing. Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.
Blog 
Twitter 
LinkedIn 
Forum 
Wiki
This blog directly follows on from part 2 on watches, so if you haven’t already read that then you should probably go and do that now. You can still create notifications without having any watches configured; you just won’t receive anything on them. In the last post, I had created two watches, one Server Log watch and one Collected Metrics watch. In this post, I will create notifications to work with these watches.