The post Calculating Business Value of Automation in PagerDuty Process Automation appeared first on PagerDuty.
]]>Reporting the value delivered by an automation program can be challenging since the value depends heavily on what is being automated. Your project proposal may forecast time and cost savings by automating certain manual tasks. Tracking and reporting those savings is how you show the business impact of your projects. So how can you simplify tracking and reporting?
We have a feature in PagerDuty Process Automation that can help: the ROI Metric Data plugin. The ROI Metric Data plugin follows the simple principle that every time an automation runs, it delivers value. The automation developer specifies value metrics by defining key values such as hours-saved:10 for their automation.
Whenever the job executes, these metric values are added to the log entry of the execution. The plugin also provides an end point to extract the JSON records of these runs, along with other metadata about the executions—making it possible to compile, calculate, and analyze these metrics over time.
Here are some patterns you can follow to track the business value delivered by your automation projects.
The most direct benefit of automating a task is the cost savings of the labor it replaces. Take this use case shared by Robert Powers from Brinks at PagerDuty Summit 2022. Their as-is process was a recurring data transfer job that took a staff member 5 to 10 hours to complete manually.
By automating the process with PagerDuty Process Automation, they turned this process from being ¼ of one person’s job every week into an automated task that takes zero human time.
Cost, opportunity and benefit criteria of a data transfer automation project
To use the ROI Metric Data Plugin to track the value generated in this scenario, you would simply define a metric hours_saved with a value of 10 to include this metric in the execution records of this process. This will give you an easy metric to be able to export to show total hours saved per execution of this process. We chose this arbitrary key-value approach since these values can change over time as you add capabilities to your automated job. This way, you can compare the value of newer versions of your automation to older versions when charting data—provided you don’t change the key names.
For your own scenario, you will want to determine how much time is spent by workers manually completing tasks that you will be automating. This can be as accurate as you want the end result to be. Estimates are OK, or you can develop an average time spent through observations. The average or estimate will be the value you pair with a key such as hours_saved. You can break these out by employee job type if you want to track costs savings, or changes in workload distribution. Simply define more key-value pairs: DBA_hours_saved, senior_engineer_hours_saved. If you want to calculate a return on investment, you’ll also want to keep track of the hours needed to create the automations. You can also define values in monetary value, or convert hours to monetary value during your analysis.
Here we have created two key-value pairs to be logged per job run: Hours_Saved : 1.25, and Dollars_Saved : 250.
Upload the job execution data to your favorite reporting tool, such as Tableau. You can chart the compilation of your different metrics by user, and job over time. For example, you can show hours saved from manual executions by users vs. scheduled job runs. You can calculate money saved either directly from metrics you have defined, or by converting different hours metrics to costs.
Here is an example of charting the logged data showing increasing money and time savings from scheduled job runs and user-invoked job runs.
Converting these metrics to return on investment requires adding the costs associated with the implementation of automation. In the customer scenario we shared above, 20 FTE hours (assuming equivalent labor costs) was the cost to create the automated process. If this includes maintenance over a year, this looks like: 520 FTE Hours Saved – 20 FTE Hours to automate = 500 hours saved in just the first year of operation.
Following the principle that automation delivers value whenever that automation runs, we may wish to calculate value according to the outcome of these runs. This would mean filtering out automation runs that are unsuccessful.
There are different reasons why an automation execution may be unsuccessful. There may be problems with the job definition itself, or errors reported by nodes and workflow steps that don’t otherwise terminate the job. In the case of one of these unsuccessful executions, you may wish to filter them out of your value calculation.
Example job run with a failed step
When running analytics we can choose to filter out unsuccessful runs due to external failures from integrated systems.
Example chart showing hours and money saved and job status
The ROI Metric Data Plugin is available in PagerDuty Process Automation as of Version 4.7, and is also available as part of PagerDuty Runbook Automation. To learn more about working with the ROI Metric Data Plugin, check out the Process Automation Documentation.
If you are not already a user of PagerDuty Process Automation or PagerDuty Runbook Automation, schedule a demonstration or trial today!
The post Calculating Business Value of Automation in PagerDuty Process Automation appeared first on PagerDuty.
]]>The post Five Considerations for Choosing Self-Managed Automation vs. SaaS Automation appeared first on PagerDuty.
]]>Some Luddites might say the same thing about cloud computing. “I won’t put my (app/data) in the cloud! It will be more (secure | reliable | cheaper) if I run it myself in my own data center.”
All kidding aside, there are legitimate reasons why you might choose the self-managed version of PagerDuty® Process Automation On Prem—previously known as Rundeck Enterprise—over our new SaaS offering, PagerDuty® Runbook Automation. No, it’s not that classic is better in this case; it’s actually the same code developed through the Rundeck open source project. It’s that your requirements or use case might be better met when you have more flexibility than what our SaaS automation solution can provide.
Not sure which way to lean? Here are five considerations to help you decide which offer might be better suited for your use case.
Maybe your application and its stack run in your own data center, or a hosting provider other than one of the cloud hyperscalers. This could be because of legacy reasons—where your application was first deployed and it’s too strategic (or not strategic enough) to invest in migrating to the cloud. You could have specific requirements (some of which are covered below) that would be more difficult to meet in the public cloud. Put simply, it’s a reflection of where your company chooses to invest its capital and develop its expertise in IT. In fact, it might be a source of cost control and profitability to run your own infrastructure. After all, AWS is estimated to have a gross margin of over 60%. Finally, maybe your company provides digital services at scale, so running your own infrastructure is part of ensuring quality and speeding up innovation.
PagerDuty® Runbook Automation is built to securely connect to any cloud or self-hosted environment, and can meet many typical use cases. However, running the PagerDuty® Process Automation software yourself could make more sense if your team’s skill set is more geared toward your self-managed environment. In such a case, running PagerDuty® Process Automation On Prem can help you scale your in-house operations by allowing your experienced engineers to apply their expertise to build self-service automation that can then be delegated to other users. The same secure connectivity that lets PagerDuty® Runbook Automation connect to remote environments also allows your team to securely connect your disparate data centers into centralized automation. In fact, it may well allow you to further increase security by reducing or eliminating the need to allow remote SSH access to these environments.
Do you need to meet HIPAA, PCI, and/or FedRAMP requirements? Do you require your IT providers to be SOC2 compliant? If so, at least in the short term, you may be better off running PagerDuty® Process Automation On Prem versus utilizing the SaaS offering.
While PagerDuty® Runbook Automation is built to comply with standards such as these, achieving these standards takes some operating history—and we just launched the service this March. PagerDuty® has significant experience building high-quality services, which were leveraged in the development of PagerDuty® Runbook Automation. We look forward to announcing a SOC2 certification as soon as we can. As we get closer to achieving more certifications, we will communicate the expected availability.
Many countries require that certain kinds of data about their citizens, including personally identifiable information (PII) and financial data, be stored within the borders of their country. PagerDuty® Runbook Automation, as a SaaS offering, can be utilized to automate any IT infrastructure that can be accessed via the internet. However, it is currently hosted in North America, with future plans to host in Europe.
If your company and application are subject to such data sovereignty requirements, it might make sense to utilize PagerDuty® Process Automation On Prem instead. Our SaaS offering doesn’t directly store personal data outside of what’s required for user accounts. However, if the automation you might create could potentially lead to a violation of such regulations, hosting your own automation environment within your own infrastructure may make it easier to show compliance.
PagerDuty® Process Automation On Prem provides a wide range of plugins—both developed and supported by PagerDuty—as well as those developed by the Rundeck open source community. This provides options and flexibility for automation developers to incorporate several types of infrastructure into their automation.
One reason there are so many plugins available in the community is that PagerDuty® Process Automation On Prem has a flexible plug-in API. This makes it seamless for users to develop their own plugins for home-grown or less common infrastructure they wish to utilize in job definitions such as nodes, job steps, UI integrations, and credential storage.
PagerDuty operates our SaaS offering, PagerDuty® Runbook Automation, to meet stringent security and reliability requirements. This means the only plugins we can offer are those that have been tested and certified to meet these requirements. For the same reasons, custom plugins are not supported at this time. Here is a list of plugins that are secure enough to use behind a firewall with PagerDuty® Process Automation On Prem, but are not supported by PagerDuty® Runbook Automation.
If you have a lot of different types of infrastructure you’d like to automate with, you will find PagerDuty® Process Automation On Prem offers the flexibility to meet an abundance of requirements.
PagerDuty® Runbook Automation is built with hardened security to meet stringent requirements, and it can help optimize your own compliance with security and compliance requirements. For example, PagerDuty® Runbook Automation connects to infrastructure using a Runner that calls back to its endpoint using HTTPS. This eliminates the need to open additional ports in your firewalls. Runbook Automation is integrated with cloud SSO such as Okta, Ping, and Azure AD, and secrets management SaaS services such as Hashicorp Vault, CyberArk, and Thycotic. It facilitates access control to privileged actions and reduces the need to distribute super-user credentials. Job-level logging means compliance audits are no sweat. However, in the case of secrets management, PagerDuty® Runbook Automation does not connect to on-premise key stores.
But will this meet your own specific security requirements?
If you need to integrate with on-premise authentication or secrets management, or have other unique needs in this area, you may need the flexibility offered by PagerDuty® Process Automation On Prem instead.
PagerDuty® Runbook Automation | PagerDuty® Process Automation On Prem | |
Best fit | To manage cloud and SaaS operations | To manage on-prem ops and infrastructure |
Plugins | Preset and no custom | All and any + custom |
Keystores | Cloud only | On-prem or cloud |
Data | Managed by PD | Managed by customer |
Upgrades | Managed by PD | Managed by customer |
Scale | Managed by PD | Managed by customer |
Secure infrastructure | Managed by PD | Managed by customer |
If you’d like to explore these differences and compare them to your requirements, start a conversation with our team.
The post Five Considerations for Choosing Self-Managed Automation vs. SaaS Automation appeared first on PagerDuty.
]]>The post Automating Work in Real Time Through the PagerDuty Operations Cloud appeared first on PagerDuty.
]]>These new offerings reflect PagerDuty’s vision to democratize automation for all users. We do this by allowing engineers to delegate automated IT processes to IT users. This way employees can take real-time action themselves to get their work done.
Companies these days are awash in “task automation”. This includes Python and bash scripts, Ansible and Jenkins frameworks, and cloud infrastructure platforms such as the Amazon EC2. These automations are designed for specific purposes. They are often only usable by the experts who deploy them.
Other users have need for the operations performed by this automation. Yet, they must escalate to the experts to have that automation executed for them. We call this disconnect the “Automation Gap”.
Three kinds of disconnects interplay to create the Automation Gap. These are knowledge gaps, skills gaps, and access gaps. Gaps in knowledge are a reflection of how vast and complex our IT environments have become. No single person can know specific context, version, and dependencies, of every component. Specialization is a must. Skills gaps are the reality that different users have different technical skill sets. Not everyone knows how to administer a database, or automate a continuous integration pipeline. In fact, the time of a company’s most skilled technicians are usually in high demand. Anything that can offload their work helps scale the business. Finally maintaining security according to best practices is what causes access gaps. IT staff should not have wide access to super-user credentials.
The Rundeck platform by PagerDuty helps bridge these gaps. Now engineers can delegating automation to stakeholders. This cuts escalations, interruptions, and waiting time. Engineers standardize automation into operational processes. This makes it easier for colleagues to traverse knowledge and skills gaps. Processes can incorporate existing task automation as individual steps in an operational workflow. This abstracts the context of each step allowing a consistent operational experience. Rundeck also helps optimize and improve security. Processes can run privileged operations on resources without needing to share secrets to users. Rundeck integrates with single-sign-on (SSO) to enable role-based access control (RBAC). Rundeck logs all activity at process and step levels to comply with audit requirements. Finally Rundeck plugs into operations platforms and applications that IT users work in. These include Jira, ServiceNow, PagerDuty, and even Slack and Microsoft Teams. This means IT end users can get access to operations they need, in the context of screens they work with.
Rundeck is about enabling your end users to do what before only your expert engineers were able to do. And, it’s in this spirit that we’ve designed our new products, Rundeck Actions and Rundeck Cloud. Now incident responders and other IT end users can get work done in real time instead of waiting. Operations close out faster. IT teams see fewer interruptions. Everyone is a lot less frustrated.
Rundeck Actions connects automation to incident responders in PagerDuty. It allows automation engineers to connect and curate automated calls. Engineers can then publish and delegate this automation for use by first responders. These calls invoke automation in production environments to run diagnostics and repair actions.
See the power you can provide to your responders to run diagnostics and repairs.
Rundeck Actions connects with production environments through an Action Runner. The Action Runner sits behind a firewall calls back to the Rundeck Actions endpoint. It looks for steps to execute. and returns output from automation. PagerDuty then records this feedback into the incident timeline.
Rundeck Actions is now generally available and has an ambitious roadmap ahead of it. Planned features include integrating to Slack and Microsoft Teams, and PagerDuty Event Orchestration. Let us know if you’d like a demo of Rundeck Actions.
Rundeck Cloud provides the benefit of automating IT processes, without having to maintain automation servers. Users work in the same design time and run time user experience as Rundeck Enterprise. The only difference is the operating environment is provided as a service.
Rundeck Cloud delivers the same general automation capabilities as Rundeck Enterprise with these additional features:
Similar to Rundeck Actions, Rundeck Cloud securely connects to your production infrastructure through a Cloud Runner that sits behind your firewall or VPC. Think of the Cloud Runner as a remote execution server that calls back to the Rundeck Cloud endpoint looking for job steps to execute.
A single Rundeck Cloud instance can be associated with multiple runners, which means Rundeck Cloud can act as your process automation control plane across disparate environments, cloud accounts, and SaaS services.
We are accepting limited sign-ups for customers who want to try out Rundeck Cloud in our Early Access program. We expect Rundeck Cloud to be generally available sometime early2023.
The post Automating Work in Real Time Through the PagerDuty Operations Cloud appeared first on PagerDuty.
]]>