10 Key Take-outs From a Proven Technology Leader

Specsavers CIO Phil Pavitt has worked for 18 companies in a stellar 35-year career in technology, across organisations as varied as Transport for London, Centrica, Aviva, and HMRC, the UK government department responsible for revenue and customs.

Phil was a star speaker at the recent AppD Summit Europe, where he delivered a compelling and thought-provoking presentation that summarised key learnings during his time in the tech industry. The importance of being passionate about what you do, the need for bravery in terms of challenging existing practices, and prioritising the addressing of everyday obstacles that may be seen as low down the stack rank were all highlighted. The latter can actually do wonders for staff morale and act as indicators of tangible improvement.

In a session full of sage advice and canny observations, a number of themes stood out for me:

1. Technology is at the heart of everything you do. Phil referred to his experience within Specsavers, which has focused on a medical retail store experience. The stores are no longer the home of dial-ups, but rather the fastest broadband available. He also reminded the audience that saying you’re putting technology at the centre is easy, whilst doing it is much harder.

2. Focus on the customer journey, of course, but start with customer-facing colleagues. These are the ones at the coalface of engagement, so make sure they’re fully supported with truly colleague-centric designed applications and infrastructure.

3. Ensure what you develop is designed for what it’s meant to do. Is it really fit for purpose? This may seem like common sense, but after numerous stakeholders and various teams have given their input into the development process, sometimes sight can be lost of what the original purpose of an initiative was.

4. Assemble the right team in the right place for the right purpose. Teams should last for the period they need to stay together to deliver a defined objective, not multiple years during which they can fall victim to stagnation, as well as an absence of fresh ideas and innovative thinking. Dynamically bringing together a different combination of talents focused on a specific challenge fosters collaboration and improves the overall abilities of existing teams.

5. “Split the room”, which means it’s a distinct possibility that upon commencing a new role, 40% of the IT department will hate the way you’re working, whilst 40% are likely to love the changes that are being made. This is actually fine, as it means you’re having an impact and generating a reaction of some sort. The remaining 20% who are in the middle and indifferent are the group to be concerned about. Most are probably disengaged from their roles and indifferent to the organisation achieving its goals.

6. Respect has to be earned by exhibiting the behaviors that you wish to see in your team. Only by demonstrating a true understanding of the organisation and what it needs to do will you earn the right to lead. This reflects the “Be the change you want to see” approach but also referenced the importance of not being deluded into thinking that the CIO title alone wins advocates for your strategy and adherents to your vision.

7. Always follow delivery, not fashion. Don’t rush towards a destiny you don’t truly understand. The IT sector is already awash with three-letter acronyms and new technologies, whilst even newer practices and buzzwords seem to emerge every month, all being touted as having a huge role to play. Don’t fall victim to a rebranding of an existing topic (“big data” was quoted as example of this) and believe it’s the silver bullet, panacea for all ills, or any other clichéd solution. Balancing the “fashion of technology” vs. the need for business processes is a huge challenge for the CIO community.

8. The classic IT department is fundamentally dead — recognise this fact and adapt. IT has become commoditised, and whilst some may hate the arrival of shadow IT, it is now so normal and growing that it must be seen as an opportunity for partnership, not conflict. Phil explored the shifting landscape faced by CIOs, whose traditional roles are now threatened by chief digital officers and other new job functions. He also highlighted the need for automation at every level to eliminate manual errors and labor-intensive repetitive processes.

9. Don’t measure projects by their size. Whilst empire-building and bragging rights around the water cooler over who’s leading the largest project measured by headcount aren’t unusual, this is flawed and outdated thinking. Modular and small projects are still the most successful method to adopt. They’re more agile, quicker to deliver value, and have more realistic expectations.

10. Don’t spend more money on technology than the arrival of technology. If only 30% – 40% of an IT project is invested in training, onboarding, and overall enablement, then change will not land well. The most important aspects are not the technology, they are the people who will use and be affected by the technology that matter most.

Become an Innovation Enabler, Not a Cost Centre

Phil ended the session by explaining how CIOs need to reposition IT in any enterprise, win board ownership, and have them believe in you. Demonstrate the IT department’s value as a broker and an honest partner. Start small and experiment — it’s much easier to gain permission for a $25 – 35k proof of concept that acts a rallying point with your team. It’s also critical to set a vision and journey, and generate dissatisfaction with how things currently are. Sometimes objectives can be very simple yet hugely effective. One example of a mundane but far-reaching goal was the reduction in “lottery” login times within a major energy provider. The team cut logins from up to 25 minutes down to under 20 seconds for 98% of employees. Phil ended by reminding anyone who embarks on the CIO path that it’s the most lonely job you will ever have, as you’re constantly driving change across the whole business without entrenched, enduring, and loyal internal ecosystems. A class-leading CIO must by nature always drive innovation and change, and strive to remain challenging, committed, and inspirational.

Watch Phil’s presentation below:

 

7 Steps to Great APM Dashboards

One of the most highly rated sessions at AppSphere 2016 and again this May at AppD Summit Europe was AppDynamics Senior Sales Engineer Andy Jackson’s dashboard top tips presentation. If you’re an AppDynamics customer, this is a not-to-be missed opportunity to learn how to create dashboards that inform and encourage action. Thought-provoking, educational, and entertaining, Andy delivers a compelling tutorial with real actionable takeaways.

Eliminating “Noise” in the Dashboard

Sharing best practices learnt from supporting multiple enterprise customers, Andy at first explains the inherent challenges with dashboards, namely if it just shows red, it only tells part of the story. He highlights the importance of colors and “noise” — is everything shown in the dashboard relevant, and/or is something missing? If a dashboard shows all problems, all it does is tell you there’s a problem with the application.

There are many pitfalls to avoid, and this session provides best practice guidance, based on processes learnt and dashboards created for enterprise customers.

Dashboard “Dos and Don’ts”

He starts with a commonly created AppDynamics dashboard featuring key customer journeys and major steps.

Screen Shot 2017-05-17 at 5.32.51 PM.png

Screen Shot 2017-05-17 at 5.34.30 PM.png

Andy then asks if something is red, why is it red? We then should go find the problem. Colleagues won’t know if the issue is page loading or Business Transaction response time, so a dashboard needs labels for others to make sense of the data. He explains why graphs are a pet peeve, as they often have no point of reference and are crying out to show the baselining capabilities of AppDynamics.

Andy also dismisses dashboards that just look pretty, but are functionally useless. How much information do you want? How do you want to view it — on a wall or on a desktop, for example?

7 Steps to Take

It’s best to start with a plan, and Andy referenced a series of key steps towards building great dashboards that can be summarized as follows:

1. Identify the audience

Who is the actual audience? Why do you want a dashboard? Prove you need it. What can a dashboard do that isn’t better managed via an SMS alert, an email, or a support ticket raised.

2. Focus on goals

What is the desired outcome? Do we want to dive into the problem or keep senior managers happy?

3. Identify use cases and environments

Will the dashboard be used interactively or just look pretty on a wall? For example, this has an impact on dashboards that need a mouse to double click, but are expected to be wall-mounted.

4. Build the end state vision

Have all stakeholders agreed on the criteria? Do they know what they want to see — e.g., see red for an issue and double click to dive into details, or business metrics to keep a broader, more business-oriented audience happy? Andy suggests that it’s better to start by drawing a draft dashboard.

5. Use “traditional” design tools

Visualize the end state dashboard using paper and pen to draw candidate dashboards and solicit feedback — is this what senior managers are envisaging? It’s much easier updating a sketch than revising a fully built-out dashboard after the fact.

6. Check alignment before moving forward

Review the plan with the customer, and how you intend to build it. Sell the plan back to the customer — can you achieve all your goals?

7. Dashboards are dynamic, living things

Is there any feedback generated by the dashboard? Take a continuous improvement approach — the perfect dashboard is never done. It will change over time and be added to. No updates suggests the dashboard isn’t being used or truly engaged with.

Ideally, customers should follow the “Plan”, “Do”, “Check”, and “Act” stages.

Real-World Examples

The topic is brought to life by showing examples of good and bad dashboards, including one created for a real customer to track performance on Black Friday, with respective Business Transactions.

If you’re interested in how leading retailer Dixons Carphone Warehouse used AppDynamics to make Black Friday successful for them, read this Forrester report. Graphs are shown to be useful if a dynamic baseline is established so we know if a status is good or bad. An example of how to set this up is shown below:

Screen Shot 2017-05-17 at 5.46.28 PM.png

The importance of events is then demonstrated by showing exactly what took place that triggered a drop in traffic, for example.

Andy took the audience step-by-step through his favored approach to building a simple yet impactful dashboard with the help of a few encoder and widget sites. An example of one he created is shown below:

Screen Shot 2017-05-17 at 5.44.48 PM.png

Best explained by watching the presentation, he then shows the specific steps involved in creating an impactful dashboard, such as how an event widget can be very helpful when added to a graph, creating context. While the new 4.3 release does not include extensive new dashboard features, it does have a few real time-savers such as the ability to undo delete.

The session ended with an interactive Q & A, again dispensing valuable guidance on how to create dashboards that really matter.

Don’t Delay Your Dashboard Transformation

There’s much more covered by Andy in his deck, and if you’re interested in building great dashboards (who isn’t?) then it’s well worth watching his presentation — along with the other track sessions from AppD Summit Europe — and it takes less than an hour to watch.

 

 

Okta is Driving Fast, but with Eyes Wide Open

The new “speed” conversation

When you’ve been writing marketing about tech companies since the dawn of the millennium, as I have, you hear the topic of speed come up a lot. And rightfully so. It is, of course, a vital metric and, in a marketing sense, a crucial differentiator when selling your product to the masses.

5X faster than the competition.

Fastest throughput.

Etc.

It’s been interesting to watch those performance metrics explode. But a funny thing has happened to the speed discussion. More and more, it’s not really in terms of the measurable, like speeds and feeds. Now, it’s more conceptual. It’s about how fast you’re innovating or responding to changes in the industry landscape and with the demands of customers. This is the direct result of technology no longer servicing the business, but driving the business.

Yeah, your stuff is really fast. But everyone’s stuff is really fast, so it’s not as much of a focus of differentiation anymore. How many of us even seriously consider the performance specs of a laptop before buying it…with one click…on Amazon Prime…hoping you ordered it fast enough so it comes tomorrow and not — gasp — the day after tomorrow.

“Oh! I can get it same day? Meh. How many hours is that going to take?”

It’s not about being fast, because fast is a given. It’s being fast all the time, and being faster to innovate, and being fast enough to stay just ahead of the competition. Because, let’s face it, pretty much no one gets out way ahead and stays there.

Yeah, tech marketing is way different these days. And so much more exciting.

On this trip together

One company that’s very exciting these days is Okta, an identity management company and an AppDynamics customer. They use AppDynamics application performance management to help them follow through on what Hector Aguilar, Okta’s CTO and SVP of Engineering, describes as their “always on” culture. “Always On” even appears in the tab on your web browser when you go to okta.com.

We’ve recently posted a video that was featured at AppSphere 2016, as well as written a success story about our great relationship with Okta.

In the video, Mr. Aguilar payed us one of the most flattering and clever compliments we could have hoped for:

“If we don’t have AppDynamics, where we’re using it, it would be really like driving a car at 100 miles per hour with your eyes closed.”

And there it is again — speed. But not of their product (which is, of course, always on), but the speed in which Okta is moving within the industry. The speed at which they have to operate to meet the expectations of their customers — and their customers’ customers, employees and partners, who are all touch points of Okta’s solutions.

We’re incredibly proud to be helping Okta and other industry leaders concentrate on this incredibly fast-moving, twisty road that we’re all on together.

Please be sure to read the story.

IT holds more business influence than they realise

A ‘well oiled’ organization is one where IT and the rest of the business are working together and on the same page. In order to achieve this there needs to be good communication, and for good communication there needs to be a common language.

In most organizations, while IT are striving to achieve their goal of 99.999% availability, the rest of the business is looking to drive additional revenue, increase user satisfaction, and reduce customer churn.

Ultimately everyone should be working towards a common goal: SUCCESS. Unfortunately different teams define their success in different ways and this lack of alignment often results in a mistrust between IT departments and the rest of the business.

Measuring success

Let’s look at how various teams within a typical organization define success today:

Operations:
IT ops teams are responsible for reducing risk, ensuring the application is available and the ‘lights are green’. The number ‘99.9’ can either be IT Ops best friend or its worst enemy. Availability targets such as these are often the only measure of ops success or failure, meaning many of the other things you are doing often go unnoticed.

Availability targets don’t show business insight, or the positive impact you’re having on the business. For instance, how much did performance improve after you implemented that change last week? Has the average order size increased? How many additional orders can the application process since re-platforming? Is anyone measuring what the performance improvement gains were for that change you implemented last week?

Development:
Dev teams are focussed on change. The Business demands they release more frequently, with more features, less defects, less resources and often less sleep! Dev teams are often targeted according to the number of updates and changes they can release. But nobody is measuring the success of these changes. Can anyone in your dev team demonstrate what the impact of your last code release was? Did revenues climb? Were users more satisfied? Were there an increased number of orders placed?

‘The Business’:
The business is focussed on targets; last month’s achievements and end of year goals. This means they concentrate on the past and the future, but have little or no idea what impact IT is having on the business in the present. Consulting a data warehouse to gather ‘Business Intelligence’ at the end of the month does not allow you to keep your finger on the pulse of the business.

With everyone focussing on different targets there is no real alignment to the overall business goals between different parts of an organization. One reason for this disconnect is due to the lack of meaningful shared metrics. More specifically, it’s access to these metrics in real-time that is the missing link.

If I asked how much revenue has passed through your application since reading this blogpost, or what impact your last code release had on customer adoption, how quickly could you find the answers? How quickly could anyone in your organization find the answers?

What if answers to these questions only took seconds?

Monitoring the Business in Real-time

In a previous post, I introduced AppDynamics Real-time Business Metrics which enables you to easily collect, auto-baseline, alert, and report on the Business data that is flowing through your applications… as it’s really happening.

This post demonstrates how to configure AppDynamics to extract all checkout revenue values from every business transaction and make this available as a new metric “Checkout Revenue” which can be reported in real-time just like any other AppDynamics metric.

With IT Ops, Dev and Business Owners all supporting business critical applications that are responsible for generating revenue, it is a great example of a business metric that could be used by every team to measure success.

Let’s look at a few examples of how this could change the way you do business, if everyone was jointly focussed on the same business metric.

Outage cost
The below example shows the revenue per minute vs. the response time per minute of an application. This application has obviously suffered an outage that lasted approximately 50 mins and it’s clear to see the impact it has had on the business in lost revenue. The short spike/increase in revenue seen after the outage indicates users who returned to complete their transaction, but this is not enough to recover the lost revenue for the period.

RtBM - outage

Impact of agile releases
This example shows the result of a performance improvement program that has taken place. The overall response time has improved by over a second across three code releases and you can clearly see the additional revenue that has been generated as a result of the code releases.

RtBM - agile releases

Here a 1 second improvement in response time has increased the revenue being generated by the online booking system by more than 30%. The value a development team is delivering back to the business is clearly visible with each new release, allowing developers to focus on the areas that drive the most return and quantify the value they are delivering.

Marketing campaign
This example is a little more complex. At midday there is a massive increase in the number of people visiting this eCommerce website due to an expensive TV advertising campaign. The increased load on the system has resulted in a small increase in the overall response time but nothing too significant. However, despite the increased traffic to the site, the revenue has not improved. If we take a look at the Number of Checkouts, which is a second Business Metric that has been configured, it’s clear the advertising campaign has driven additional users to the site, but these users have not generated additional revenue.

RtBM - marketing

Common metrics for common success

With traditional methods of measuring success in different ways it’s impossible to to align towards a common goal. This creates silo’d working environments that make it impossible for teams to collaborate and prioritise.

By enabling all parts of the business to focus on the business metrics that really matter, organizations benefit from being able to proactively prioritise and resolve issues when they occur. It helps IT truly align with the priorities and needs of the business, allowing them to speak the same language and manage the bottom line. For example, after implementing AppDynamics Real-time Business Metrics Doug Strick, who is the Internet Application Admin at Garmin, said the following:

“We can now understand how the application is growing over time. This data will prove invaluable in guiding future decisions in IT.”
-Doug Strick, Internet Application Admin

AppDynamics Real-time Business Metrics enable you to identify business challenges and react to them immediately, instead of waiting hours, days or even weeks for answers. Correlating performance, user experience, and Business metrics together in real-time and in one place.

If you want to capture the business performance and measure your success against it in real-time , you can get started today with Real-time Business Metrics by signing up and taking a free trial of AppDynamics Pro here.

How much does downtime cost?

Unscheduled downtime happens all the time. In 2012 alone dozens of big-name websites went down for hours at a time, from GoDaddy.com to, well, almost anything running on Amazon. Every time an outage occurs, the Internet has a field day speculating about everything from the cause of the outage to who got fired for it. Some more transparent companies will publish a post-mortem on their blog with the details, which is nice, but there’s one question that’s almost never answered: how much did the downtime cost?

Various analysts & institutions have taken a stab at trying to answer this question with exhaustive research and surveys. The results are not very conclusive – it seems that the answer depends on the industry, the size of the company, the type of application, and even the year. We took a shot at breaking it all down for you in the infographic below: How much does downtime really cost  you?

Summary: How much does downtime cost?

Downtime is really expensive – especially if you work at a financial services institution that relies on transaction-based fees like credit card transaction fees or trading fees. But there are costs associated with downtime that we don’t imagine – for example, the human cost of having to spend every day firefighting instead of focusing on other projects, or the damage to your company’s brand, which can impact customer loyalty. It may be worth the effort to find out what downtime costs your organization, and how much of it you can afford.

Financial Services White Paper

My Top 3 Automated Tasks for Finding and Fixing Problems

Gears-BrainAutomation sets apart organizations at the top of their game from the rest of the pack. The limiting factor in most organizations is that they are usually too busy putting out fires and keeping up with all of their other obligations to expend the effort required to envision and build out their automation strategy. With that in mind I have created a small list of the automation tasks that I feel provide the most value to an organization. Along with these tasks I explain the type of effort involved and reward associated with each one. All of the information presented is based upon my 15 years of troubleshooting within enterprise operations and applications environments.

IT Operations

1. Collect troubleshooting metrics – To me this is the no-brainer of automation tasks. For each particular type of problem you always want certain information to help resolve that issue. This is also the easiest of my top three to implement but may provide less value than the other two. Here are some examples…

  • Hung/Unresponsive JVM/CLR – Initiate and store thread dump, restart application on offending node.
  • Slow transactions plus high server CPU utilization – Collect process listing to determine CPU contributors and spin up extra instance of application.
  • Transactions throwing excessive errors – search log files for errors and send list to appropriate personnel, based upon error type possibly probe individial components deeper (see #2 below)

Application Operations

2. Probe application components – This one is really useful for figuring out difficult application problems but requires more effort to set up than #1. The basic concept is that you need to find out from the application support team what steps they would take manually to trouble shoot their application if it were slow or broken. The usual responses are things like “Check this log file for this word”, “Run this query against this database and if the output is -3 then I know what the problem is”, “Hit this URL to see what the response looks like. If the page does not return properly I know there is a problem with this component”, etc…

It may seem like a lot of work to set up this type of automated probing at first but once it is set up it becomes an invaluable troubleshooting tool. Imagine that the application response times get slow so these troubleshooting measures are automatically invoked and you get an email with the exact root cause within minutes of performance degradation. With this type of automation there is usually a known resolution based upon the probing results so that could be automated too. How handy is that?

Business Operations

Blame_Flowchart3. Alert the business to changing conditions – This is where the IT staff has the ability to really make an impression and impact on the business. One of the most overlooked aspects of monitoring and automation is the ability to gather, baseline, alert, and act based upon pure business metrics. Here’s an example scenario…

Bobs business has an e-commerce website that sells many different products. They use AppDynamics Pro to track the quantity of each item sold along with the total revenue of all sales throughout the business day (using the information point functionality). One day Bob gets an alert that the latest greatest widgets are selling way below their typical volume but the automation engine searched the prices of major competitors to find that one competitor lowered prices and is undercutting business. With this actionable information Bob is able to immediately match the pricing of the competition and sales rates return to normal before too much damage is done.

Obviously business operations automation can be the most complex but also the most rewarding. Reaching out to the business and having a conversation about their activities and processes can seem daunting but I can tell you from personal experience that the business is more than willing to participate in initiatives that save them time and money. This type of conversation also normally leads to the business asking about other ways to collaborate to make them more effective so it is a great way to improve the overall level of communication with the business.

AppDynamics Pro enables a new level of automation because it knows exactly what is going on inside of your applications from both a business and IT perspective. Your level of automation is limited only by your imagination. I recommend that you start out small with a single automation use case and build outward from there. You can use AppDynamics Pro for free to try out our application runbook automation functionality on your specific use case by clicking here.

Intelligent Alerting for Complex Applications – PagerDuty & AppDynamics

Screen Shot 2013-04-16 at 2.39.00 PMToday AppDynamics announced integration with PagerDuty, a SaaS-based provider of IT alerting and incident management software that is changing the way IT teams are notified, and how they manage incidents in their mission-critical applications.  By combining AppDynamics’ granular visibility of applications with PagerDuty’s reliable alerting capabilities, customers can make sure the right people are proactively notified when business impact occurs, so IT teams can get their apps back up and running as quickly as possible.

You’ll need a PagerDuty and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of PagerDuty and AppDynamics online.  Once you complete this simple installation, you’ll start receiving incidents in PagerDuty created by AppDynamics out-of-the-box policies.

Once an incident is filed it will have the following list view:

incident

When the ‘Details’ link is clicked, you’ll see the details for this particular incident including the Incident Log:

incident_details

If you are interested in learning more about the event itself, simply click ‘View message’ and all of the AppDynamics event details are displayed showing which policy was breached, violation value, severity, etc. :

incident_message

Let’s walk through some examples of how our customers are using this integration today.

Say Goodbye to Irrelevant Notifications

Is your work email address included in some sort of group email alias at work and you get several, maybe even dozens, of notifications a day that aren’t particularly relevant to your responsibilities or are intended for other people on your team?  I know I do.  Imagine a world where your team only receives messages when the notifications have to do with their individual role and only get sent to people that are actually on call.  With AppDynamics & PagerDuty you can now build in alerting logic that routes specific alerts to specific teams and only sends messages to the people that are actually on-call.  App response time way above the normal value?  Send an alert to the app support engineer that is on call, not all of his colleagues.  Not having to sift through a bunch of irrelevant alerts means that when one does come through you can be sure it requires YOUR attention right away.

on_call_schedules

Automatic Escalations

If you are only sending a notification and assigning an incident to one person, what happens if that person is out of the office or doesn’t have access to the internet / phone to respond to the alert?  Well, the good thing about the power of PagerDuty is that you can build in automatic escalations.  So, if you have a trigger in AppDynamics to fire off a PagerDuty alert when a node is down, and the infrastructure manager isn’t available, you can automatically escalate and re-assign / alert a backup employee or admin.

escalation_policy

The Sky is Falling!  Oh Wait – We’re Just Conducting Maintenance…

Another potentially annoying situation for IT teams are all of the alerts that get fired off during a maintenance window.  PagerDuty has the concept of a maintenance window so your team doesn’t get a bunch of doomsday messages during maintenance.  You can even setup a maintenance window with one click if you prefer to go that route.

maintenance_window

Either way, no new incidents will be created during this time period… meaning your team will be spared having to open, read, and file the alerts and update / close out the newly-created incidents in the system.

We’re confident this integration of the leading application performance management solution with the leading IT incident management solution will save your team time and make them more productive.  Check out the AppDynamics and PagerDuty integration today!

Introducing AppDynamics for PHP

PHP Logo

It’s been about 12 years since I last scripted in PHP. I pretty much paid my way through college building PHP websites for small companies that wanted a web presence. Back then PHP was the perfect choice, because nearly all the internet service providers had PHP support for free if you registered domain names with them. Java and .NET wasn’t an option for a poor smelly student like me, so I just wrote standard HTML with embedded scriplets of PHP code and bingo–I had dynamic web pages.

Today, 244 million websites run on PHP which is almost 75% of the web. That’s a pretty scary statistic. If only I’d kept coding PHP back when I was 21, I’d be a billionaire by now! PHP is a pretty good example of how open-source technology can go viral and infect millions of developers and organizations world-wide.

Application Runbook Automation – A Detailed Walk Through

On Monday AppDynamics announced a new feature called Application Runbook Automation (RBA). The response to this announcement has been great and many people want to see the details on how we implement RBA within AppDynamics, so I’m going to walk you through it step by step in this blog post.

If you don’t already know WHY we built Application RBA please read “Don’t Be An “Also-Ran” – Application Runbook Automation for World Class IT”

Let’s jump right in…

Don’t be an “Also-Ran” – Application Runbook Automation for World Class IT

Your applications are the lifeblood of your business–the culmination of countless hours of development, testing, bug fixes, more testing, and finally deployment to production. No matter how good your coding and testing practices are, though, eventually your applications will slow down, start to throw errors, and crash. How quickly and effectively you remediate these business impacting problems is the difference between world class IT organizations and the “also rans.”

Application Runbook Automation from AppDynamics is a game changing technology that can remediate business impact in a matter of seconds. It can represent a savings of hundreds of thousands of dollars per incident. Read more to find out how…

rba revenue risk 2

This table shows the business impact in USD of reducing MTTR from hours to minutes to seconds by taking advantage of AppDynamics and application run book automation.

 

So What’s a Runbook Really?

In case you’ve been locked in an IT dungeon for your whole career, let’s take a minute to talk about runbooks. Runbooks are the cure for insomnia, the crappy part of application support where you document how to stop and restart your awesome application that will never, ever fail. But just in case, some of you are also forced by the evil management regime to document troubleshooting procedures along with remediation steps for the common problems that could cause your application to misbehave.

All of this documentation (Runbook) is handed off to your friendly operations center staff so that it can be stuffed away in a giant repository never to be heard from again. After all, the job of the NOC (network operations center) is just to receive and route alerts to the proper people–so why even write out those runbooks in the first place?

You know how to restart your application when you get paged at 3 AM, no documentation required. You can recover your application within 30-120 minutes of initial impact half asleep with one hand tied behind your back. Unfortunately, during that time your company just lost revenue, customers, and tarnished their reputation. Tough break, but that’s just the way it is today. But there’s a better way!

Hasn’t Runbook Automation (RBA) Been Around for a While?

Yep, RBA is that expensive software sitting on your corporate shelf right now. It can’t help you with the problem described above. It’s become niche software for infrastructure support personnel who know nothing about your applications (and are offended they consume so much of their resources, kidding of course). Traditional RBA is a colossal failure that knows nothing about your user, business transactions, and applications. It’s this lack of application awareness that has relegated RBA to being used by a handful of infrastructure support personnel in your company.

Application Runbook Automation is a Business Differentiator

The time has come to fulfill the promise of automated remediation of business impact. Consider this:

  • AppDynamics understands exactly what components are being used at any given time by your applications.
  • It knows exactly what your end users are doing all the time and tracks and measures that activity through your application components.
  • It knows what transactions are slow or failing and exactly what code, configuration, and nodes are causing the problems.

Using this granular level of problem detection and isolation, AppDynamics application RBA understands business impact and takes the appropriate action to remediate within seconds of detection. There are many problems that get detected automatically and many remediation’s already available out of the box to take advantage of so you don’t have to code your own. You can also re-use your existing RBA processes and scripts to take advantage of all that hard work that has been done in the past. You can even integrate your Puppet and Chef tools directly with AppDynamics. Why re-invent the wheel?!

Application RBA is powerful and flexible. You have the choice to take action automatically or to be prompted for authorization if you’re not ready to trust in the judgement of machines just yet. Your troubleshooting and remediation actions can be executed on only the impacted nodes, on all associated nodes in a tier, or at the overall application level. Application awareness and flexibility empower you to manage your applications the way you need to for your unique business.

Monitoring, Meet Management

Management has long been the missing dimension from the promise of APM. The lack of focus on this problem by the monitoring industry needs to change and AppDynamics is leading the way. When most applications were run on a handful of servers it was acceptable to overlook the management aspect and just focus on pointing out where the problems were. With modern applications scaling to hundreds and thousands of nodes it’s becoming impossible for humans to keep ahead of the management challenges without using machine automation.

If you need to remediate business impact caused by slow or crashed applications as fast as possible, Application Runbook Automation from AppDynamics is just what you need.

Try AppDynamics with Application Runbook Automation for free today.