Skip to main content

Über dieses Buch

The objective of APM Best Practices: Realizing Application Performance Management is to establish reliable application performance management (APM) practices—to demonstrate value, to do it quickly, and to adapt to the client circumstances. It's important to balance long-term goals with short-term deliverables, but without compromising usefulness or correctness. The successful strategy is to establish a few reasonable goals, achieve them quickly, and then iterate over the same topics two more times, with each successive iteration expanding the skills and capabilities of the APM team. This strategy is referred to as “Good, Better, Best”.

The application performance monitoring marketplace is very focused on ease of installation, rapid time to usefulness, and overall ease of use. But these worthy platitudes do not really address the application performance management processes that ensure that you will deploy effectively, synergize on quality assurance test plans, triage accurately, and encourage collaboration across the application life cycle that ultimately lowers overall application cost and ensures a quality user experience. These are also fine platitudes but these are the ones that are of interest to your application sponsors. These are the ones for which you need to show value. This CA Press book employs this iterative approach, adapted pragmatically for the realities of your organizational and operational constraints, to realize a future state that your sponsors will find useful, predictable and manageable—and something that they will want to fund. In the meantime, you will learn the useful techniques needed to set up and maintain a useful performance management system utilizing best practices regardless of the software provider(s).



Getting Started with APM

Chapter 1. Getting Started with APM

Software systems, the applications and strategies on which your business depend today have become extraordinarily complex. For many organizations, the wide array of applications and tools to develop this software results in application architectures that can overwhelm the capabilities of many organizations to manage them.
Michael J. Sydor



Chapter 2. Business Justification

To justify an APM initiative is to establish the motivations and benefits that the initiative will address from the perspective of the business or sponsor. The justification is usually a written document and often focuses on the financial aspects of the proposal: the initial investment and ongoing maintenance. The emphasis on finances is not only historical but also reflects the lack of any prior experience on which to refer to for the “real” costs and impacts of the initiative—the unique circumstances of a new APM initiative. This is the first clue for the client that they are moving into unfamiliar territory. At this point, no one can tell them what the monitoring initiative is really going to cost!
Michael J. Sydor

Chapter 3. Assessments

This chapter introduces the most useful APM activity—assessments. These are not just for APM practitioners, they are for all the other folks, too. Assessments are simply measurements and observations about your current business practices. I will focus on monitoring, but the technique is fundamental to documenting the state of any variety of systems. Essentially, to figure out where you are going and how to get there, you need to first assess what you are already doing.
Michael J. Sydor

Chapter 4. Staffing and Responsibilities

Monitoring of the IT infrastructure has been a familiar capability ever since the 1960s, when that first programmer sought to see if the soda machine was empty without having to take that long walk down the hall. Any measurement results in a metric indicating some quantity. In this case, the number of a particular soda remaining. An agent makes the measurement and uses a communication protocol to transfer the metric (count of soda remaining) so that someone may evaluate and make a decision. Hence, the Simple Network Management Protocol (SNMP) was born. Now 50 years later, the basic idea remains the same. In order to support business decisions in APM you need to get metrics about capacity and performance. You need to deploy an agent1.
Michael J. Sydor

Chapter 5. APM Patterns

The preceeding chapters have covered the traditional topics in the planning of an APM initiative: architecture, terminology, assessments, roles, and staffing—hopefully, what you expected. This chapter covers the primary gap that may cause your APM initiative to fall short: the absence of processes through which the stakeholders can exploit APM. I have been hinting that something is missing from many efforts to employ APM. Now I can expose this consistent gap, characteristic of unsuccessful APM efforts: processes. To help you understand what these processes are, I introduce a simple but powerful concept to both define and organize your APM processes, and also monitor the progress of the initiative and demonstrate your increasing management maturity: the service catalog.
Michael J. Sydor

Chapter 6. The Pilot Evaluation

The penultimate assessment of the utility of a monitoring initiative is to try out the tools in your own environment. I believe that everyone appreciates this simple concept. My concern is that it is very easy to define a pilot evaluation that completely fails to address the potential for the organization to correctly adopt the technology being considered. When this potential is zero, it can be a tremendous barrier to success in both applying the technology and in helping the organization mature its monitoring capabilities.
Michael J. Sydor



Chapter 7. Deployment Strategies

Part 2 of the book focuses on the implementation of your APM initiative. Part 1 discussed all of the planning concerns and ended with a pilot exercise. Depending on the result of the pilot, you may have deferred the APM initiative or moved ahead and selected an APM technology. If you made a selection, then the next step is to get it deployed, which is what we will discuss in this chapter.
Michael J. Sydor

Chapter 8. Essential Processes

In the previous chapter, I covered a number of process activities that are part of a large-scale deployment. In this chapter, I take a step back and focus on the more critical processes that you need to enable a production deployment on a smaller scale. As you saw earlier, the scope of an APM initiative will vary widely, depending on monitoring and organizational maturity. A large-scale deployment is only possible with a mature organization. You need to fill the gap by focusing on the key processes that will protect the smaller initiatives from failure. However, a small initiative needs to keep the bigger picture in mind, even if some activities will be skipped over. You need to know what you do not know or what you are not yet capable of doing.
Michael J. Sydor

Chapter 9. Essential Service Capabilities

No matter the scope or scale of your APM implementation, there are a few services with which you must be successful. In priority order, they are as follows:
  • Triage
  • Application audit
  • Preproduction review
  • Metrics capacity management
Michael J. Sydor



Chapter 10. Solution Sizing

Sizing is a fundamental systems engineering activity to determine the appropriate hardware (or costs1) and resources to support an application or service. In this case, we are concerned for the APM application and the collection of components that comprise your APM technology solution. How much RAM, CPUs, network, and disk capacity are needed to support your APM technology?
Michael J. Sydor

Chapter 11. Load Generation

This chapter discusses what is perhaps the weakest link in the application life cycle—automated testing, or load testing,1 as part of the QA process. From my firefighting experience, I have found that the more I know about a stakeholder’s QA practices, the easier time I will have getting visibility into their operational issues. Understanding their gaps in application testing often leads me directly to what is troubling them in production. Visibility is what I use to both confirm their suspicions and reveal issues they had not considered.
Michael J. Sydor

Chapter 12. Baselines

Baselines are a key concept in maturing the use of performance information. With a baseline report you effectively take away the private view of the data presented in the APM workstation and share it among all of the application stakeholders. This is critical because access to the APM workstations is often limited both from a “needs some training” to a “we bought it, only we use it” perspective.
Michael J. Sydor

Chapter 13. The Application Audit

The application audit is what I consider the fundamental element of APM technology. It prepares and validates the monitoring configuration, dashboards, and alerts so that the APM tool is tailored to your applications. And it also establishes a foundation for more effective triage. If you learn to do nothing else with APM than to deliver this competency, you will not be disappointed. Trust, but verify.—Ronald Reagan
Michael J. Sydor

Chapter 14. Triage with Single Metrics

The ability to triage is what almost everyone believes will be introduced or enhanced when they undertake an APM initiative. If you dig for a bit more detail, you will also find that IT folks tend to treat triage and root-cause analysis as the same thing. They are not. While they both depend on processes to augment the various tools employed, triage is what you do to eliminate suspects during an incident, and root-cause analysis is what you do to understand how the incident occurred—after triage has confirmed your suspect. In reality, there are four levels of triage capability that an organization will achieve as APM becomes established. You need to understand their goals and limitations so that you can manage the expectations of your stakeholders and keep your APM imitative on track.
Michael J. Sydor

Chapter 15. Triage with Baselines

Kick Off Meeting
The most important piece of history is the baseline. At some point, either in production or pre-production, someone collected metrics on the application when it was performing normally, and generated a report of graphs and tables about the key metrics. For what the key metrics are, and how to find them, please look at Chapter 12. This baseline report is essentially a signature of the application. It is also what most folks are attempting to compare to when they have an incident but they just don’t have ready access to historical information. A baseline eliminates the subjective memory and replaces it with a historical snapshot of performance characteristics.
Michael J. Sydor

Chapter 16. Triage with Trends

The third level of triage is to consider the full perspective of APM by exploiting historical metrics from other sources; this is called triage with trends. Trending is the consideration of data over some period of time, usually via statistical techniques; it’s something that IT is trying to do for all types of availability and performance problems, not simply those that have the benefit of APM visibility. The challenge is to bring together all of these disparate sources of data into something on which correlation techniques may be applied.
Michael J. Sydor

Chapter 17. Firefighting and Critical Situations

Dependence on firefighting, the rapid application of technology to an urgent IT incident, is characteristic of an immature monitoring discipline. It is a purely reactive response to a problem, usually lacking deep understanding of the issue. It is certainly not done with an eye towards preparation for proactive management. You will use the firefighting techniques discussed in this chapter to basically get Management off your back. Management is struggling with a large number of problems throughout their business management life cycle, and they need you to quickly uncover what is vexing their efforts to deliver a successful service. They couldn’t care less about the correct use of APM.
Michael J. Sydor


Weitere Informationen

Premium Partner

BranchenIndex Online

Die B2B-Firmensuche für Industrie und Wirtschaft: Kostenfrei in Firmenprofilen nach Lieferanten, Herstellern, Dienstleistern und Händlern recherchieren.



Best Practices für die Mitarbeiter-Partizipation in der Produktentwicklung

Unternehmen haben das Innovationspotenzial der eigenen Mitarbeiter auch außerhalb der F&E-Abteilung erkannt. Viele Initiativen zur Partizipation scheitern in der Praxis jedoch häufig. Lesen Sie hier  - basierend auf einer qualitativ-explorativen Expertenstudie - mehr über die wesentlichen Problemfelder der mitarbeiterzentrierten Produktentwicklung und profitieren Sie von konkreten Handlungsempfehlungen aus der Praxis.
Jetzt gratis downloaden!