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
