Define service level agreements and monitor them

• There is no value in monitoring your servers without the knowledge whether you are good or not
• Define SLAs:
  • Availability of a service
  • Response time goals
  • Maximum concurrent users or requests
• Key values in WebSphere Application Server to monitor
  • Response time
  • Connection pools
  • Heap Size and Garbage Collection behavior
• Benefits:
  • Problem prevention
  • Less discussions due to well defines service level agreements

Build staging environments, run load tests and implement quality gates

• Staging environments are very important to develop and test your
  • application under real circumstances
  • Use at lease a development stage, a pre-production and a productive stage
• Prepare load tests for testing your defined SLAs
  • build automated load and function tests
  • Operation should use this tests for verification
• Quality gates define all necessary deliverables for entering the next stage
  • Service level agreements
  • Results of source code checks
  • Results of disaster recovery tests
  • Documentation
  • Repeatable load tests
• Benefits
  • Quality assurance
  • Trust between operation and development

Create homogeneous infrastructures with suitable baseline settings

• There is nothing worse than maintaining a heterogenous environment
  • Low response times to problems and outages
  • Need for a broader skill set
  • High demand for documentation
• Define a maximum of three different infrastructure options (bronze, silver, gold)
• Baseline settings are the key for more homogeneous and robust infrastructures
• Baseline settings may include
  • Enablement of certain traces (Garbage Collection)
  • Usage of best practice properties e.g. for automated collection of problem analysis data
  • Tuning parameters and Time out values
• Benefits:
  • Standardization, where individually has no benefits
  • Many common parameters across all applications

Use scripting as much as possible for configuration tasks

• There are no misclicks if you use scripting
• Building up a script repository for common tasks
  • You can use the recoding feature of WebSphere Application Server for your first scripts
• Scripts are reusable and can be used by new personnel, as well
• Use script output as documentation for a change
• Use scripts for WebSphere Application Server installation, configuration and Application deployment
• Benefits
  • Fast “cloning” of existing environments
  • Better documentation
  • Save time and costs due to automation

Define rules for all log file entries

• Standardized error codes
  • Use the same error codes across all applications for common problems
  • Define standard behaviors for your defined error codes
• Every log entry is a call for help
  • Do not write application specific information to the log e.g. “product 17 was selected”
  • Do not throw exceptions “you can ignore”
• Better: use separate log files for everything the operation team is not interested in
• Benefits:
  • Easy to monitor
  • Faster response times to real exceptions
  • Easier to identify the responsibilities for problem solving

Bonus: WebSphere Application Server for z/OS additional considerations

• The 5 golden rules apply to WebSphere on distributed and z/OS, as well
• Many customers have a dedicated WebSphere on z/OS support team, but there is no really good reason for that
  • Programming model is the same
  • Administrative console and scripting are the same
  • Best practices are the same
  • Most z/OS specific features are additionally to WebSphere distributed features, not replacing WebSphere distributed features
• You are asking the same questions, but use different ways to get your answers
• Best way: collaboration between your system programmers and your “normal” WebSphere support team
  • System programmer will be responsible for the installation and the interfaces between z/OS and WebSphere
  • WebSphere support team will be responsible for the configuration and Java related stuff